MCP和Skill，不确定性下的确定选择

说来好笑，MCP和Skill，我一直没有真正使用，尽管我一直关注，尽管我做过一些验证，但是不论我自己的工具还是客户的交付，一直没有落地。 关键的问题，MCP和Skill的触发，具有确定的不确定性，而一旦没有触发，sop就断了，或者偏了，后面的结果可想而知。 尽管真正懂技术的人都懂，还是简单说下为什么会有不确定性？

不确定性

先把一个问题说清楚:不确定性不在MCP和Skill本身,在"谁来决定用不用"。

传统软件里,调用函数是写死的,走哪条路清清楚楚。Agent不是。它启动时只看到每个Skill的名字和描述,每个MCP工具的名字、说明和参数定义。用户说一句话,模型自己判断:这事要不要用工具?用哪个?参数怎么填?判断对了,才去读Skill正文、调MCP;判断错了,或者压根没判断,就当没这回事。

两者的机制其实不一样:

• Skill是流程和知识包。 靠description被发现,命中了才加载正文。不确定性出在"发现"这一步。
• MCP是工具接口。 模型决定调不调,但一旦调了,接口执行是确定的。不确定性出在"调不调、调哪个、参数对不对"。

所以更准确的说法是:入口不确定,过程可以确定。

入口的不确定,主要有这几个来源:

• 描述和用户说法对不上。 你写的是"BOM结构校验",客户说的是"帮我看看这个料号对不对"。语义有距离,就有概率漏掉。
• 工具一多就打架。 描述相近的Skill、功能重叠的MCP工具,模型会犹豫,甚至选错。
• 长对话更容易遗漏。 对话越往后,越容易忘了开头那些工具该用。
• 换个Agent,表现就不一样。 Claude、Codex、WorkBuddy对Skill的加载和触发各有各的实现,这边验证通过,换一个要重测。

但比这四点更要命的是:没触发,不报错。

模型会拿通用知识给你凑一个看起来挺像样的答案。SOP断了,界面上一切正常。你当然能去查日志,看有没有读Skill、有没有调工具,但没人会每次都查,往往是结果出了问题才回头翻。这才是我一直不敢落地的真正原因。

不得不的选择

但是，我不得不真正选择：要使用mcp和skill。为什么？不得不，而且是当下的最佳选择。

1. 取舍 我之前的方案是定制openclaw，后来发现是骨子里技术人的通病在作祟，总想自己开发。Agent迭代之快，竞争之残酷，是无法想象的，而OPC在这个场景下，最好的方案是坐享其成，不要碰，连想都不要想。openclaw、workbuddy、豆包、codex、claude work......谁都行，看客户的选择，看场景的适配，几乎不要有任何定制，最多就是根据Open api做集成。
2. 边界 既然Agent是我不能碰的，那么边界就出来了，我们能做的是Agent和企业对接这块，几乎就集中方式：api、hook、mcp、skill和类似workbuddy专家这种skill+prompt的复合体。真正在sop中能对接的主流就是mcp和skill。

如何提升触发率

先说结论:别指望模型"自觉",也别指望把触发率提到100%。

我的做法是两层。MCP和Skill做承载,外面再包一层显式编排,让确定性从工程里来。具体七条:

1. description当路由条件写,别当说明书写。
别写"这是一个用于XX的技能",要写"什么时候该用我":用户可能怎么说、涉及哪些关键词、哪些情况不该用我。description不用吝啬篇幅,这恰恰是提升触发率最大的空间。尤其要把行业口语写进去:我的客户不会说"BOM校验",他们说"这个料对不对"”领料单怎么回事"。

2. 边界要锋利,不是越小越好。
一个Skill干的事太杂,该触发时不触发,不该触发时乱触发。但拆得太碎也不行,数量一多,彼此又开始抢活。原则是:一个Skill对应一类清晰的场景,和别的Skill语义拉开距离。MCP同理,工具少而精,名字用动词。

3. 关键节点不要赌隐式触发,直接点名。
这条最管用。SOP的关键步骤,明确写"第一步调用XX Skill"”第二步用XX工具查询"。WorkBuddy这类"专家"(Skill加Prompt)的价值就在这:Prompt把顺序写死,模型的任务从"判断要不要用",变成"照着做"。入口让人来定,过程让模型执行。

4. 把确定的事下沉到代码。
Skill里能放脚本的放脚本,MCP里能做成确定性接口的做成接口。能用API和hook直接触发的环节,就不要交给模型判断。模型只负责"何时进入",进去之后每一步不要再让它自由发挥。

5. 每一步要有产物,没有产物就算失败。
这是对付"静默失败"的办法。SOP每个环节必须落一个文件、一份检查单,下一步开工前先检查上一步的产物在不在。不在,就是没触发,直接拦住、重试或报警,而不是带着一个凑出来的答案往下走。

6. 像测代码一样测触发率。
每个Skill准备十几条正例、十几条反例,全是真实的口语化问法,多跑几遍,统计触发率,改了description再跑。把"触发率"写进Spec,当验收标准。做SDD的人,这个习惯应该有。

另外要认账:换一个Agent,这套测试就要重跑一遍。 这是不碰Agent、跟着客户选择走的代价,但代价可控,因为测试集是我自己的资产,换引擎不用重写。

7. 留一个人工兜底。
真漏了,用户能一句话显式点名("用XX技能处理")把流程拉回来。指望的不是100%触发,而是漏了能发现,发现了能补救。

说到底,模型的不确定性我改变不了,但确定性可以靠外面这一圈工程来提供。Agent这个引擎我不碰,但触发率测试集、入口Prompt、产物校验这些,是我自己的资产,值得认真做。

不确定,是可以被管理的。这也是我最后选择它们的原因。

这些建议也只是冰山一角，只有真正经过客户检验，才能积累真实经验，不是坏事，这个领域才是我们程序员的价值。