从 Skill 到 MCP：把"可信能力"做成平台级工具的全过程

为什么要从 Skill 走向 MCP

做 Skill 分发久了，三个问题越来越明显：

  1. 用户侧配置摩擦。 Skill 本质是”脚本 + API Key”，用户要注册、拿 Key、配环境变量——每一步都在流失转化；
  2. 平台审核红线。 我们的注册脚本（发验证码、创建 Key、写入 shell 配置）一度被渠道审核模型判定为高风险，被拒了两个版本。注册是刚需，但不适合在公开包里执行；
  3. 生态绑定浅。 Skill 是”货架上的商品”，而 MCP Connector 是”接进平台水电煤的基础设施”——后者才是深度合作。

答案是 MCP：把公司的可信知识服务做成远程 MCP Server，鉴权交给平台的 OAuth，用户零配置。这就是「深知可信工作台」的由来。

工作台里有什么

四个 MCP 工具，覆盖一个 Agent 处理政务/政策/法律问题的完整链路：

工具能力定位
credible_chat可信问答一般咨询、办事问题
trusted_search权威检索政策/法律/标准原文 + 链接溯源
deep_query深度研究多地区、多材料复杂对比
security_check安全风险分类Agent 输入的风险裁决

第四个工具值得多说一句：它底层是公司的安全检测能力，输入一段 Agent 的请求历史，返回结构化风险裁决（SAFE / AGENT_HACK / SYS_FLAG / CONTENT_FLAG）。工作台因此不只是”可信内容供给”，同时给接入方补上了 Agent 输入安全风控——这个组合定位，是我们与普通知识类 MCP 的差异点。

一次由尾部斜杠引发的 401

第一场硬仗是深圳客户的本地化部署联调。客户把我们的 MCP 接进他们的政务智能体平台后，工具调用连环报 401。

我没有接受”权限配置问题”这种模糊结论。排障时我把问题拆成五层，逐层排除：

① MCP endpoint 配置 → ② 工具是否绑定 → ③ 工具名录对不对
→ ④ 后端接口权限 → ⑤ 网关路由

前四层都排掉了，锁定第五层。我先提了个验证假设：“我们刚才直接调接口那个，加一个 / 试试？”

然后推动给 Server 加了三级日志（MCP 调用、后端请求、后端响应各记一层，Key 脱敏）。日志很快揪出了真凶：

后端 URL 拼接时 normalizeBaseUrl 补了一个尾部 /，导致网关路由匹配失败，返回 401。

一个字符的差异，伪装成了权限问题。 修复后三个检索类工具全部打通。这次排障还沉淀了两个资产：一个零依赖的 Python 验证脚本（只带标准库，客户开发可直接上服务器自查，依次验 health、initialize、tools/list、真实调用）；一套”让客户自己验证”的沟通话术——“你现在能看到哪些 MCP 工具？请只列出工具名”，一句话就能定位客户卡在哪一层。

还有一个小判断：平台默认 30 秒超时，我坚持改成 120 秒——政务材料的检索召回链路重，实测单次调用 30 秒起步。后来日志证实了这个判断。

鉴权演进：从 API Key 到 OAuth 2.1

对外生态合作，鉴权走的是完整方案：OAuth 2.1 + PKCE（S256）+ 动态客户端注册 + 授权码 + refresh token + Introspection，通过标准的 Protected Resource Metadata 做发现，无 Token 请求返回 401 并携带元数据地址。

但我坚持保留了一条过渡路径：“我希望还保留 api-key 的方式，就是两种都可以调用。“原因很实际：API Key 是开发者最好的调试后门——我们自己用命令行和压测工具验证链路时，OAuth 流程反而是负担。双轨并行，正式流量走 OAuth，工程验证走 Key。

一场把问题逼到根因的压测

对接 WorkBuddy 生态有硬性的性能门槛：QPS ≥ 50、P50 ≤ 500ms、P99 ≤ 3s、错误率 ≤ 0.5%。于是有了我这段时间做得最过瘾的一场压测。

工具选型先算账。 先用 k6，但海外节点延迟高、免费额度不够；换成本机 wrk，自己写 Lua 脚本补全 MCP 协议生命周期（initialize → notifications/initialized → tools/call），状态码和时间戳全部落盘。

第一轮正式压测就出了大问题： 10 分钟 28,356 个请求，QPS 47.26，但超时 28,292 次——99.77% 超时率。而表面的”非 2xx 响应 = 0”差点让我们误判为”错误率达标”。超时不计入非 2xx，这才是失败的主体。

逐层排除定位瓶颈：

  1. 是网关吗？——发起一轮不携带 Token 的纯压力测试：892,733 次请求全部被 401，QPS 1487。网关和鉴权链路毫无压力，瓶颈不在这；
  2. 是协议交互吗？——补上 notifications/initialized 通知后，小并发轮次 0 错误，排除；
  3. 是业务服务吗？——绕过 MCP 层直压底层安全检测接口：10 并发 1,262 个请求、0 错误、QPS 21、P50 470ms。瓶颈锁定在安全分类模型的推理算力——4B 模型跑在两块消费级显卡上，扛不住 50 QPS 的目标。

结论清晰：扩容模型算力（评估加到六张卡），网关与鉴权链路无需改动。扩容后阶梯复测，指标逐级恢复。

这场压测给我的最大教训不是技术，是指标诚实：WRK 报告里好看的”非 2xx = 0”和真实的”99.77% 超时”可以是同一轮测试；我要求最终报告只放成功轮次的终端截图作为真实运行证据，失败过程全部进附录——压测报告的第一原则是可信，不是好看。

最终交付

提交给平台方的连接器材料包：连接器元数据、最小化 mcp.json 配置、图标、工具路由 Skill（指导 Agent 何时用哪个工具——deep_query 耗时长，定为”用户明确要求才调用”）、压测 HTML 报告、README。提交前按检查清单逐项自检，用命令行独立验证了 metadata 发现和三个工具的真实可用性。

战略回看

回看这三级跳，路径其实很清楚：

Skill 多渠道分发  →  平台级 MCP Connector  →  可信工作台
（铺货架）           （接水电煤）              （内容 + 安全双能力）

用别人的入口（SkillHub、WorkBuddy、各家 Agent 平台），分发自己的可信能力；用 MCP + OAuth，把一次性的商品上架，升级为深度生态绑定。

Skill 时代我们回答的问题是”用户在哪能买到”；MCP 时代回答的是”Agent 的信任链里，我们在哪个位置”。后者才是可持续的。