Skill 与 MCP 的分工：薄路由与厚规则引擎

上一篇写了 MCP 解决"连得上"，这篇复盘一个更疼的教训：连上之后，我把业务规则写进了 Skill 的 prompt 里，然后花了一个月把它们全部搬走。

事故现场

当时的场景是单据审核：Agent 接收一张单据，判断能不能通过。我图快，把二十多条审核规则直接写进了 Skill 的指令里——"金额超过阈值转人工""日期晚于截止日拒绝"之类。演示效果不错，但很快就出现了三类问题：

• 同一张单据，跑三次可能出两种结论。规则是自然语言，模型的执行是概率性的。
• 规则一多，prompt 互相打架，改一条可能碰倒另外三条，而我完全没有手段做回归验证。
• 换一个入口（另一个对话平台）就要复制粘贴整段规则，几天之后两份就不一致了。

薄路由：Skill 只该干一件事

后来我给自己立了一条规矩：Skill 只做路由，不做判断。它的职责收缩到几件事：识别用户在问什么、抽取出结构化参数、调用后端接口、把结构化结果转写成人话。判断本身——一条也不留在 prompt 里。

薄到什么程度？我的检验标准是：把 Skill 的 prompt 全文删掉重写，判定结果不应该有任何变化。变了，说明有规则漏在了前端。

厚规则引擎：规则住在后端的理由

规则搬到后端之后，用确定性的引擎去执行（表达式求值也好，规则 DSL 也好），我得到了三样在 prompt 里永远得不到的东西：

• 确定性：同样输入永远同样输出，这是审核类场景的底线。
• 可测试：每条规则配评测 case，改规则先跑回归，全绿才发布。
• 可版本化：规则变更有 diff、有历史、可回滚，而 prompt 的改动几乎不可审计。

边界怎么划

我现在的划法很简单：凡是答案需要被追问"依据是什么"的，都放引擎；凡是只影响表达方式的，才可以留给模型。模型负责理解与转写，引擎负责判定，两边通过结构化契约握手。这条边界划清之后，换模型、换对话入口都变成了小事——规则只有一份，住在它该住的地方。

LLM 擅长的是语言，不是纪律。把纪律交给它，等于把公章交给一个很会聊天的实习生。