1. 先掰扯清楚：tsm-hub 到底在解决什么
干 AI 应用开发这两年，我最大的感受是：写业务逻辑的复杂度，正在从“模型调不了”变成“乱七八糟的东西太多，不知道该调哪个”。LLM、Tools、MCP、Skills，每一个都在快速膨胀，但工具链是碎成一地的。tsm-hub 这个项目的核心，就是把这几样东西收进一个统一的网关入口，对外暴露一套稳定的 API，对内统一做注册、路由、鉴权和观测。
先说痛点。一个典型的中等复杂度智能体项目，代码里大概率会同时出现这些东西：直接调 OpenAI 的 Chat Completions 接口、本地或私有化的 LLM 服务、十几个散落在 utils 目录里的工具函数（查天气、查库存、查订单状态）、几个 MCP server（文件系统、浏览器自动化、数据库）、还有一堆“技能”类资产——比如一些写好的提示词模板、多步操作脚本、领域知识指令。这些东西各自有各自的格式、鉴权方式、超时策略和错误码。业务代码里全是 if-else 和硬编码地址，新来一个模型要改调用层，加一个工具要动主流程，MCP server 挂了整个链路跟着遭殃。
tsm-hub 的定位，说白了就是给这些“会思考也长手脚”的 Agent 体系做一个服务总线。所有模型统一从网关走，所有工具统一挂在网关下面，所有 MCP server 统一由网关拉起和管理，所有 Skills 统一注册成语义化的可调用任务。上层业务不用再关心“这个模型是哪儿来的”“这个工具有没有鉴权”“这个 MCP 走的是什么传输协议”，只管对着网关说“我要什么”就够了。
这套思路对谁最有用？我觉得三类人应该早点上手。第一类是正在做智能体应用、但被模型和工具散装集成折磨得想骂人的后端开发；第二类是给团队做 AI 基础设施、想让多个业务方共用同一套模型能力和工具资产的平台工程师；第三类是喜欢折腾本地大模型和各类 MCP 生态、想有条理地把它们组装成一个可控系统的折腾型玩家。下面我把这个项目的设计思路、实操步骤和踩坑记录一步步拆开讲。
2. tsm-hub 的核心设计：四类资源怎么抽象、怎么流动
2.1 模型路由层：它不是简单地转发请求
网关最重要的一层是模型路由。直接调 LLM 和通过网关调 LLM，体验上的差别在于：网关可以把 provider 之间的差异抹平。OpenAI 的 messages 格式、Anthropic 的 messages 格式、本地 Ollama 或 vLLM 的 OpenAI 兼容格式、甚至国产模型的私有格式，在网关上统一收敛成一种内部表示，对外则暴露成和 OpenAI Chat Completions 兼容的 API。这么做业务方几乎零学习成本——一套代码，换模型只换配置不换逻辑。
我见过很多人在自己项目里“抽象”过一层模型调用，但做着做着就变成了 if (provider === 'openai') 这种硬编码。tsm-hub 的思路正好相反：模型提供方只是一个可插拔驱动，每个驱动内部负责把标准请求转成目标模型要的报文、再把响应转回统一结构。路由策略可以按模型名直接指定，也可以做别名映射，比如把 “fast” 这个别名指向 gpt-4o-mini 或本地一个 7B 模型，把 “smart” 指向更强的模型。这样业务方调用时可以写 model: “fast”，实际哪个模型响应，由网关说了算，后续模型降本、迁移、灰度替换，全都不用动业务代码。
参数归一化也是容易被忽视的点。temperature、max_tokens、top_p、stop 这些参数在不同 provider 间有细微差别，有的模型不支持 frequency_penalty，有的对 stop 序列有数量限制。网关统一做参数白名单和默认值兜底，可以有效避免“同样的参数换个模型直接报错”的尴尬。另外，多模型 fallback 也可以在路由层实现——第一个 provider 超时或返回 5xx，自动切到备用的 provider，这对线上稳定性来说是刚需。我自己跑下来，最常用的策略是“成本优先 + 失败切换”，与其反复调优单个模型，不如让网关聪明一点。
2.2 工具层：函数调用的本质是把决策权交给模型
LLM 的 Tools 机制，本质上是把“人的工具清单”转成模型能读的 JSON Schema 列表，模型根据对话内容决定要不要调用某个工具、参数怎么填，然后由应用侧真正执行。这一步说起来简单，实际落地时最大的坑是工具 Schema 写得不够规范。模型没有“常识”，它只能根据你给它的字段描述、类型、required 标记来推断怎么传参。字段描述模棱两可，模型就会频繁填错参数、漏填字段。
tsm-hub 在工具层的做法是：每个工具注册时不仅给一个执行函数，还要附带完整的 OpenAPI/JSON Schema 描述、超时时间、幂等标记和权限标签。网关在把工具列表组装给模型前，会做一次 schema 校验，过滤掉不合规的注册或者自动修正为宽松模式。工具执行时，网关统一处理参数解析、调用结果包装（统一转成文本或结构化 JSON）和错误捕获，绝不让底层异常直接爆到模型那里——模型一旦收到五花八门的报错格式，它的“思考”就会被带偏。
还有一个细节是工具调用的并发控制。很多人在本地实验时不觉得，一旦接进生产，多个请求同时触发同一个工具，比如同一个写操作或者同一个高耗时的分析任务，很容易把下游服务打挂。网关里给每个工具配置最大并发数和排队策略，是成本很低但效果极好的做法。我甚至建议所有写操作类工具默认串行或加信号量，别让模型十万火急地并发写同一个资源。
2.3 MCP 接入层：生态进来的标准插座
MCP（Model Context Protocol）是这半年 AI 圈最值得关注的协议之一。你可以把它理解成给 LLM 应用装上了 USB-C 口——外围工具只要做成 MCP server，任何支持 MCP 的客户端都能直接插上用。如果 Tools 是网关内部自带的“手”，那 MCP 就是网关对外界生态开放的“万能插座”。tsm-hub 的架构里，MCP 是一等公民：你只需要在网关配置里声明要启用哪些 MCP server，网关负责拉起、鉴权、健康检查和工具自动发现。
MCP server 目前主流有两种通信方式：stdio 和 streamable HTTP。stdio 适合本地进程式的 server，网关直接把它作为子进程拉起来，走标准输入输出通信，比如文件系统操作、本地命令执行这类；streamable HTTP 适合远程服务，比如部署在另一台机器上的浏览器自动化服务，通过 HTTP 长连接交互。网关接 MCP 时，会自动从 server 拉取它声明的工具列表，把这些工具翻译成标准的 Tool Schema，一起并入统一的推理工具集。这意味着业务同学根本不用感知“某个功能是内部工具还是 MCP 工具”，对模型来说它们都是一样的可调用函数。
我在实践中的一个偏好是：能用 MCP 解决的，尽量不自己造内部工具。原因很简单，MCP 生态一天天在涨，今天有人发布了更好的代码搜索 MCP，明天可能有人做了更顺手的数据库查询 MCP，网关这边只是改一行配置的事情，但如果是自己写的内部工具，就得重新开发、测试、上线。当然，内部工具的优势是可控性强、调试方便，所以最终形态一定是两者共存——内部工具管核心且高频的操作，MCP 管长尾和外部生态。tsm-hub 的配置模型对这两种接入方式是一视同仁的，统一注册、统一授权、统一观测。
2.4 Skills 层：把指令和脚本变成可复用资产
Skills 这个词在 AI 应用里其实有两层含义。一层是给模型用的“技能”，本质上是一段精心设计的提示词加上若干工具的使用配方，告诉模型遇到某类问题应该遵循什么步骤、调用哪些工具；另一层更像一个可执行的任务流，类似“先做 A 再做 B 再汇总 C”，由网关节奏性地编排。tsm-hub 里的 Skills 我把它们统一设计成“带参数的指令包”——一个 Skill 由三部分构成：触发描述（什么时候该用它）、执行逻辑（提示词模板 + 工具调用序列）、输出格式要求。
最实用的一个场景是“代码审查”。以前的写法是把一大段审查规则贴在系统提示词里，每次对话都带着跑，浪费 token 又难以维护。现在可以做成一个 code_review 的 Skill，里面写好审查的维度、需要调用的工具（比如读 diff、查文件内容、跑静态检查），模型在合适的时机自动选择这个 Skill 去执行。你可能会问：这跟普通的工具调用有什么区别？区别在于 Skills 是“组合指令”，它可能内部编排了多个工具和多次模型交互，是比单工具更高一层的抽象。多个 Skills 还可以互相调用，比如“写单元测试”这个 Skill 内部会先调用“代码解读”Skill 来理解逻辑，再接测试框架工具生成用例。
这块我认为反而是 tsm-hub 有别于普通模型网关的地方。只做模型转发的那叫代理服务器，能把模型、工具、协议、技能统一治理的，才配叫“统一网关”。Skills 的沉淀需要时间积累，一开始可能只是把零散的提示词整理成模板，慢慢地会形成一套团队共用的“操作手册”。这也是我建议团队从第一天就按 Skill 的格式来沉淀经验的原因——它比 Wiki 更适合被模型直接消费，放着也是放着，为什么不喂给模型用呢。
3. 实操：从零把 tsm-hub 跑起来
3.1 最小化部署：目录结构、环境变量与配置文件
下面这套最小化部署方案，是我跑了多个项目后沉淀下来的模板。不需要复杂的容器编排，一台 Linux 机器或者开发机就能跑通，后续要上生产再套 Docker Compose 或 K8s。
tsm-hub/ ├── config/ │ ├── config.yaml # 主配置：模型、工具、MCP、Skills │ ├── models.yaml # 模型 provider 清单 │ ├── tools.yaml # 内部工具注册 │ ├── mcp_servers.yaml # MCP server 清单 │ └── skills.yaml # 技能资产 ├── internal/ │ ├── server/ # 网关核心：路由与 API 实现 │ ├── drivers/ # LLM provider 驱动目录 │ ├── tools/ # 内部工具实现 │ └── skills/ # Skills 编排逻辑 └── logs/# config.yaml 核心片段 server: port: 8080 api_prefix: /v1 auth: type: apikey keys: - sk-test-123456 engine: default_model: fast db: sqlite # 用于记录请求日志和用量 models: aliases: fast: { provider: openai, model: gpt-4o-mini, temperature: 0.3 } smart: { provider: openai, model: gpt-4o, temperature: 0.2 } local: { provider: ollama, model: llama3.1:8b, temperature: 0.4 } mcp: servers: - name: filesystem-demo transport: stdio command: npx args: ["-y", "@modelcontextprotocol/server-filesystem", "./sandbox"] - name: browser-demo transport: http url: http://127.0.0.1:8931/mcp这份配置的阅读门槛很低。engine段定义了网关主入口，models段定义了别名路由，mcp段声明要启用的两个 MCP server。我个人习惯把内部工具注册从主配置里拆出去，因为工具数量多了以后，主配置会变得臃肿，拆分后便于不同团队各管各的文件。
启动前至少要准备两样东西：API Key 环境变量和模型 provider 的密钥。tsm-hub 支持从环境变量读取 provider 密钥，避免把密钥写进 Git 仓库。启动命令很简单——tsm-hub start --config ./config/config.yaml，日志会输出到logs/目录。第一次启动建议把日志级别调到 debug，你会看到它自动发现了 filesystem-demo 这个 MCP server 并拉取了工具列表。
3.2 注册你的第一个模型、工具、MCP 与 Skill
走一遍完整的注册流程，可以让你对全貌更有手感。四个东西按顺序来。
第一步，注册模型。把你要用的 provider 写进models.yaml，比如加一个 DeepSeek 或通义千问。每个驱动要做的无非就是告诉网关 base_url、api_key_env、模型名。注册完重启网关，调用/v1/models接口就能看到模型列表，说明网关已经接上了这家模型服务。
第二步，注册内部工具。以“查订单状态”为例，工具实现无非是一个函数。关键是要在注册信息里写好 schema描述，比如“根据订单号查询订单当前状态，返回 JSON 对象，字段包含 id、status、created_at”。如果你用 Python 写网关，工具注册代码大概长这样：
@tool.register( name="query_order_status", description="根据订单ID查询订单当前状态，适用于售前、售后、物流查询等场景", schema={ "type": "object", "properties": { "order_id": {"type": "string", "description": "订单ID，如 OD20250101001"} }, "required": ["order_id"] }, timeout=5, permission="order:read" ) def query_order_status(order_id: str) -> dict: # 实际查询数据库或第三方系统 return {"id": order_id, "status": "shipped", "eta": "2025-01-05"}这段代码里最值得琢磨的是description的写法。我见过太多人写“查询订单”，模型根本分不清它跟“查询订单列表”有什么区别，结果就是误调用。描述一定要写清楚适用的业务场景和排除项，比如“不要在未提供订单ID时调用”这种负面约束，对提高调用准确率有奇效。
第三步，接入 MCP server。在mcp_servers.yaml里新增一条记录，就像前面配置示例里那样。如果你是本地调试，优先用 stdio 方式，启动时把日志打出来，能直观看到它和网关之间的通信过程。如果用的是远程 server，走 http 模式，记得在配置里加token或者让网关的鉴权层把关。启动后调用/v1/mcp/servers列表接口，确认 server 健康状态为 online，它暴露的工具会被自动合并进工具总表。
第四步，写一个 Skill。拿“周报生成”举例。Skill 的定义是：触发条件——用户要求生成周报时；执行步骤——调用工具get_work_logs拉取本周事项，按“已完成/进行中/风险项”三块整理；输出要求——Markdown 格式，不超过 500 字。在skills.yaml里声明这个 Skill 后，你在普通对话里说“帮我总结一下这周的工作”，模型会自动路由到这个 Skill，而不会傻乎乎地凭记忆胡编。
3.3 通过统一 API 调一次完整的推理加工具调用
等注册工作做完，就可以体验统一入口的爽感了。下面是调用示例，和 OpenAI 官方 API 几乎一模一样：
curl http://127.0.0.1:8080/v1/chat/completions \ -H "Authorization: Bearer sk-test-123456" \ -H "Content-Type: application/json" \ -d '{ "model": "fast", "messages": [ {"role": "user", "content": "帮我查一下 OD20250101001 这个订单到哪了"} ], "tools": ["auto"] }'注意这里的tools: ["auto"]，它表示由模型自己决定是否需要调用工具。网关收到请求后，会先找fast这个别名对应的实际模型，再把订单查询工具的 schema 拼进去。模型如果判断需要查订单，会回一个 function call，网关收到后执行本地函数，把结果以 tool 消息塞回去，让模型生成最终回复。整个链路你在网关日志里都能看到一步步的耗时记录。
第一次跑通这个流程你会有一种很踏实的感觉：模型、工具、配置全都在网关的控制之下，业务侧只是发了个普通请求。而且你会发现，就算换了模型——把fast从 gpt-4o-mini 换成某个本地小模型，只要模型能力支持 function calling，同一个 curl 请求依然能工作。这就是路由抽象层的价值。
3.4 可观测性：从一次请求看到全链路
网关这类中间件，最怕的就是变成黑盒。tsm-hub 在可观测性上的做法值得一说。每个进入网关的请求都会生成一个 trace_id，从请求进入、模型选中、工具调用、MCP 交互到响应返回，每个环节的关键节点都记录时间戳和 token 消耗。日志格式建议用结构化 JSON，方便接入 ELK 或 Loki。
我强烈建议你在网关层面记录三个维度的数据：请求维度（哪个业务方、哪个模型、耗时多少）、工具维度（被调了几次、成功与否、平均耗多少）、成本维度（每次请求的 token 数和估算费用）。把这三个维度的数据揉到一张看板里，你就能说清楚“谁在用、用了什么、花了多少钱”。很多团队在 AI 应用上花的钱失控，就是因为缺了这层计量。
4. 踩坑记录与排查实录
4.1 “provider rejected the request schema or tool payload” 怎么解
这是你在接入模型网关时几乎一定会撞上的报错，我至少见过五种不同的触发原因。最常见的一种是：目标模型对工具参数 Schema 的格式有严格限制，比如某家模型的 function calling 要求strict模式，或者不接受anyOf这类组合类型，而你给的 Schema 是直接从别处抄来的。网关在转发前最好统一做一遍 schema 规范化，把嵌套类型拍平、移除模型不支持的字段，能避免大量问题。
其次是工具名冲突。如果内部工具和某个 MCP server 暴露的工具重名了，模型看到的工具列表里就会出现两个同名但行为不同的家伙，provider 直接拒掉整个 payload 是完全正常的。我在网关里加了自动重命名策略，重名工具按来源加前缀，比如internal_query_order和mcp_filesystem_read，同时把每个工具的 description 里标清楚来源。这个命名规范建议从第一天就执行，后面省太多事了。
还有一类不算少见的原因，是模型本身不支持 function calling。有些轻量模型或者某些本地导出模型，并没有真正训练出工具调用的能力，你硬塞给它工具列表，它就回你一句“我不支持”。遇到这种情况，要么换模型，要么用提示词模拟工具调用——让模型输出一个特殊格式的 JSON，网关自己解析成工具调用。这个方案虽然回调准确率差点，但至少可以让不支持 function calling 的模型也跑通基础流程。
4.2 MCP server 连不上或状态反复横跳
stdio 型 MCP server 最经典的坑是“本地能启动，网关里起不来”。排查思路有四个：一是确认启动命令里的路径对不对，npx在网关进程的环境里有没有被正确识别，建议在配置里写绝对路径或先which npx确认；二是子进程启动时的工作目录对不对，比如文件系统类 server 要求操作某个目录，工作目录错了自然读不到文件；三是环境变量是否缺失，有的 MCP server 需要特定 token 才能连外部服务，网关子进程不会自动继承你 shell 里的变量，要显式配置；四是有没有多实例冲突，同一个 MCP server 被多个网关实例同时拉起，可能争抢同一个本地端口或锁文件。
HTTP 型 MCP server 的问题则更偏网络侧。超时时间要单独设置，不要用默认值——有些浏览器自动化任务执行一次得好几秒甚至十几秒，网关默认超时如果设成 3 秒，你会看到一片红的失败记录。另外，HTTP 型 MCP 的鉴权和流式响应处理各家实现有差异，接之前先看一下它的文档，确认它用的是不是标准 streamable HTTP，避免把不支持流式的 server 硬接进来。
我的经验是，尽量让 MCP server 保持“无状态 + 可重拉”的特性。网关在健康检查发现 MCP server 挂了之后，最有效的恢复策略不是原地重试，而是直接重启这个子进程或者重新建立连接。配置里把这个策略设成 auto-restart，能大幅减少人工介入的次数。
4.3 Skills 的优先级和命名冲突
当 Skills 仓库里的条目超过二三十个，就容易出现“此路不通”。最典型的情况是，两个 Skill 都声称自己擅长处理“用户问题”，比如一个叫 general_qa，一个叫 faq_bot，模型的判断开始不稳定，有时候走这个，有时候走那个。我把这称之为“Skill 意图重叠”。
解法有两个方向。第一个方向是给每个 Skill 写更精确的触发条件和排除条件，在描述里写清楚“当用户询问退货政策时使用本 Skill，普通闲聊不属于本 Skill 范畴”。第二个方向是在网关里支持 Skill 的命名空间和优先级配置。同一条用户问题，如果多个 Skill 的匹配分数都超过阈值，取优先级高的那个；如果优先级相同，则按最近更新时间和历史调用成功率排序。这个策略跑了一段时间后，可以人工干预权重，把效果不好的 Skill 降权，逐步逼近最优组合。
还有一个小坑是 Skill 内部引用的工具名变了之后，Skill 没有同步更新，运行时报“工具不存在”。我建议在 Skill 加载时做一次依赖校验，所有引用的工具和 MCP server 必须存在且健康，否则这个 Skill 直接标记为 disabled，并在日志里给出明确原因。这样不至于在运行时才爆出来。
4.4 网关自身的性能、限流和密钥管理
统一网关把所有流量都收进来，它自己就变成了关键路径。性能出问题，所有业务方一起遭殃。我遇到最头疼的是模型 provider 响应慢导致的连接池耗尽。网关默认给每个 provider 维护连接池时，空闲连接数不要设太大，因为很多 provider 的并发能力有限，你这边囤一百个空闲连接，人家那边直接给你限流。建议连接池大小跟目标 provider 的并发配额对齐，超出的请求排队等待而不是无限创建连接。
限流是网关必备功能。我的做法是给每个 API Key 配置独立的 RPM（每分钟请求数）和 TPM（每分钟 token 数）限制。这个不仅是为了防滥用，也是为了让不同业务方互相隔离——某个业务方的流量高峰不能把其他人的模型配额全部吃掉。
密钥管理这方面，最大的教训是“不要在模型驱动配置里明文写密钥”。网关启动时从环境变量或密钥管理服务读取，日志里永远不要打印任何密钥信息。另外 API Key 一定要支持轮换和吊销，至少留出两条有效 key，方便切换时无缝过渡。
5. 实战场景：tsm-hub 的三种落地姿势
5.1 内部 Copilot：让团队共享一套模型与工具能力
把 tsm-hub 部署成团队内部 Copilot 的后端，是我觉得性价比最高的场景。所有成员通过统一 API 接入，网关统一做鉴权和配额管理。前端可以是聊天窗口、IDE 插件、甚至命令行工具，后端都是同一套网关。
这个场景下，我比较推荐把 Skills 当成团队的“组织资产”来运营。比如新员工入职时，他想了解“项目发布流程”，与其翻文档，不如直接让 Copilot 调用 release_process 这个 Skill，它内部会拉取发布检查单工具、查最近的发布记录、生成一份针对当前项目状态的发布指引。知识库和提示词模板被 Skill 化之后，团队经验就能被模型真正“用起来”，而不只是躺在 Wiki 里当摆设。
设计上有两个注意点。一是权限必须细分到 Skill 级和工具级，不能让所有人都能调用生产环境的写操作工具。二是用量统计要跟团队或项目维度挂钩，月底跟老板汇报的时候，你能清楚说出哪个团队消耗了多少模型调用、多少 token，钱花得明明白白。
5.2 浏览器自动化加 MCP：让 Agent 真正“动起来”
浏览器自动化是把 MCP 生态价值体现得最淋漓尽致的一个场景。Playwright MCP server 可以把浏览器操作能力暴露成工具，让模型能“看网页、点按钮、填表单”。配上 tsm-hub 网关，你实际上是给整个团队提供了一套可以远程控制的浏览器操作能力——谁要跑一个端到端测试，谁想验证一个页面的用户流程，直接让 Agent 接管浏览器去执行。
实际跑起来你会发现，模型驱动浏览器操作比传统脚本要“皮实”得多。以前 Playwright 写的端到端测试，选择器一换就挂；模型驱动的浏览器操作可以根据页面实际情况调整策略，比如按钮没找到就换个方式找。当然它也有代价：慢、token 消耗大、偶发误操作。所以我把这类 MCP server 的调用权限做得比较谨慎，默认只有“只读”类操作开放给所有人，写操作和表单提交类工具单独授权。
这类场景的技术要点是超时和重试策略要单独调优。浏览器操作动辄好几秒，一个流程可能要十几步，中间的某一步超时了不能整体重来，要做好单步超时和失败降级。把 Playwright MCP 注册进网关后，我还顺手配置了一个“操作前截图”的 Skill，每一步都让模型确认页面状态再继续，虽然慢一些，但心安。
5.3 私有知识库问答：把 RAG 的每一步也纳入网关
知识库问答是另一类高频需求。以前做 RAG 是把向量检索、重排、模型生成这些步骤全塞在应用代码里，链路长、难排查、换模型牵一发动全身。在 tsm-hub 里，我把检索、重排都封装成普通工具，再让一个叫 rag_answer 的 Skill 来编排整个流程。
这样设计有一个好处：你可以随时替换检索实现——比如从 Elasticsearch 换成向量数据库，或者加上一个 rerank 模型作为工具，这些改动只动配置和工具实现，上层完全不用感知。更重要的是，RAG 链路里的每一步都被网关记录在案，哪一步慢、哪一步检索为空、哪个环节 token 消耗异常，一眼就能定位。
我在这个场景里还接了 Llama 本地模型作为快速兜底，当远程大模型服务不可用时，网关自动切换成本地模型继续服务。效果虽然比 gpt-4o 差一点，但至少知识库问答不会全军覆没。这种劣化降级的策略，在核心业务场景里比追求单点极致重要得多。
5.4 授权、审计与多业务方隔离
最后聊一下多业务方共用网关时的治理姿势。我强烈建议从第一天就把 API Key 的粒度划分清楚：每个业务或每个团队至少一把独立的 Key，而不是所有人共用一把。这样限流、计量、审计才能落到具体的业务头上。
审计日志这个事容易被拖到“以后再说”，但我劝你早点做。网关层天然是审计的完美位置——谁在什么时候调用了什么模型、触发了哪些工具、传了什么参数，全都留下结构化日志。出问题的时候（比如某个工具被异常调用），你能在一个小时内把完整时间线拉出来，而不是靠问人、翻聊天记录。对合规要求高的企业，这一步更是刚需。
6. 我个人的几个体会与后续扩展方向
tsm-hub 这样的统一网关，做了一段时间之后，我对它的价值判断有了更清晰的感觉。它最厉害的地方不是“转发模型请求”这个动作本身，而是把 Agent 系统里容易失控的变量全部收敛到了可控的配置层。模型想换就换，工具想加就加，MCP 生态想接就接，Skills 想沉淀就沉淀，上层业务几乎是稳定的。这对团队持续迭代的节奏感特别重要——你不会因为底层切换被拖住，也不会因为工具混乱而四处救火。
踩过几次坑之后，我给自己定了三条规矩，写在这里送给打算上手的朋友。第一，任何工具和 Skill 都必须写清描述和边界条件，别偷懒，模型真的会因为你少写一句“不要用于XX场景”而跑偏。第二，所有外部交互默认失败重试一次，但重试要有退避，别像个莽汉一样撞了南墙还给南墙磕头。第三，能进配置的就别写死在代码里，后期治理的灵活性全看配置化程度。
这个项目后续可以扩展的方向也很多。比如把网关跟内部发布系统打通，让模型驱动的变更操作自动走到审批链路；再比如把用量数据和成本账单接到财务系统，自动分摊到各个业务线。还可以做一套 Skills 市场，团队之间互相分享高质量的技能资产，让整个组织的模型使用水平一起往上走。
我现在最常干的一件事，是把新发现的好用 MCP server 注册进网关，在沙箱环境里跑一遍真实场景，好用才开放给团队。这个习惯让网关的生态位越来越丰富，也让团队的 Agent 能力一直在悄悄变强。做中间件这事，真的是一分治理一分回报。
