AI Native 时代,工具的边界到底在哪?

图源自Every平台

本文是一次针对MCP、Skill、 Workflow 和Agent 分工边界的复盘。

顺着这条轴，从最确定的一头往回看。

1）MCP：只接确定性，不碰判断力

MCP 做的事，是把外部世界翻译成模型能调用的动作。

数据库、API、文件系统、内部服务，原本对模型都是黑盒。MCP 在中间架一层，把每个具体动作标准化：叫什么名字，需要什么参数，返回什么结构。模型看到的是一份工具清单，点一下调用，拿到结果。

举个例子，一个查订单的MCP tool，输入订单号，输出订单详情。代码怎么写它就怎么跑。同样的输入给同样的输出，不随心情变化，不随上下文漂移。这是MCP 的立身之本：它生产的不是智能，是确定性。

再举个例子，报表里的“本月营收”，正确做法是 MCP tool 去数据库查一次，返回一个数字。而如果你是写进 prompt 让模型结合上下文估算，它会给你一个像模像样的数字，但每一份可能都不一样。在财务报表里，这种差异就是事故。

那怎么判断一件事该不该交给MCP？

看它是不是只有对错一种标准。有唯一正确答案的事，都不该交给模型。

但MCP 也不是越多越好，它也有自己的纪律。

一个是粒度不宜过细，过细的工具会污染上下文。比如，你把“打开文件”“读取第一行”“关闭文件”拆成三个工具，模型要三次调用、三轮推理才能完成一件事。好的工具应该是一个完整的动作单元，语义完整，一步到位。

另一个是，需要大量上下文判断的活不适合交给MCP。那属于模型，不属于工具。比如"帮我判断这份合同有没有风险"，这不是一个确定动作，是一段推理。它属于模型，不属于工具。硬做成 MCP，等于把判断塞进代码，既写不出来，也维护不动。

MCP 的边界很清楚：只接确定性，不碰判断力。

Skill 做的事，是把一类任务该怎么做的方法教给模型。

它封装的是方法：知识、步骤、判断标准、注意事项，可能还带一点辅助脚本。模型遇到对应任务时，把这些方法读进来，改变的是自己处理这件事的思路。

好的Skill 像一本靠谱的操作手册，让模型面对一个陌生领域时，不至于瞎猜。

但注意，手册改变的是倾向，不是结果。

一个人读了菜谱，未必做得出那道菜。模型读了Skill，未必就输出你要的东西，因为最后一步生成依然落在概率里。

因此Skill 常常被两头误解：一头是前面说的，拿Skill去要100%确定性，这是高估；另一头是觉得它可有可无，反正模型够聪明了，这是低估。

Skill 真正的价值，是把一类反复出现的判断，固化成可复用的方法。没有它，模型每遇到一次同类任务都要重新摸索；有了它，经验被沉淀下来，输出质量的下限被抬高了。

那一个Skill要写到什么程度才算好？

市面上教怎么写 Skill 的文章很多：三段式结构，渐进式披露，先 description，再 SKILL.md，再按需加载 reference。道理都懂，可实操里我还是会收到大量调试过不了关的 Skill，输出效果和延迟都不乐观，Agent 调起来纯属浪费 token。

于是在调试Skill前我会先组织各方评估Skill 的好坏，结果很快就变成了拉锯战。翻来覆去，Skill 的版本号都朝两位数去了，却没人说清好的标准在哪。

经过多次实践后，我慢慢找到感觉。

我的经验是，一个好的 Skill，缺了四样就不算完整：明确的输入、明确的步骤、明确的输出标准，还有最容易被忽略的那一样——明确的终止条件。一个不错的 Skill 末尾往往有这么一句话："如果连续失败三次，必须停止尝试，回滚并报告。"没有这个停止条件，Agent 很容易陷进无意义的重试循环。

你不能交付一个没有刹车的引擎。

上面说的，都是一份Skill够格的基准线。换个视角，还有另一个问题：Skill的粒度怎么把握？一个业务域，到底该切成几份？

经常有团队一口气打包了几十份Skill过来，很吓人，我没半点欣喜。逐一看下来发现，很多Skill彼此共用同一个数据源、共用同一套后处理模板、经常被放在一起查，为什么不合并？只有它自己有专属的复杂逻辑，才值得拆出来。

当然，我未必了解其他团队的业务逻辑，那怎么知道交付的Skill粒度对不对？拿真实的问法跑一遍。八成的问题，一个 Skill 就能答完，粒度就是对的；如果经常得先调 A、再调 B、最后合起来才够，说明这两个本来就是一回事，就该合并。

最后再澄清下关系：Skill 是 MCP 的消费者，不是它的替代品。

正确的分层是，MCP 提供原子能力，Skill 注入方法，Agent 负责决策与调用。

这层关系，很多团队搞反了。他们本该让 Agent 调 MCP 拿结果，却把这段逻辑写进 Skill 自己实现，结果既没拿到 MCP 的确定性，也没沉淀 Skill 的方法。

顺着往下推，还能得到一个反直觉的结论：很多 Skill 之所以存在，只是因为 MCP 没写好。一个 tool 的名字、说明、参数足够清楚，模型拿到就知道怎么调，这一层本可以不要。

因此，动手写 Skill 之前，先质疑一下你交付的 MCP。凡是需要反复向模型解释的规则，都应该下沉成 MCP 的参数或枚举。

反复解释，也许正因为它本来就不该靠解释。

4）Agent：只在决策不确定时才上

Agent 是这条轴上最右的一格，也是唯一全程由模型主导的一层。它自己决定下一步做什么、调哪个工具、要不要停下来问。

它存在的理由只有一个：任务的步骤无法预先枚举，下一步取决于上一步的动态产出，你需要一个能处理意外、临场改主意的执行者。

这种场景真实存在，但没有想象中那么多。代价是：路径不固定，结果不可复现，出错也难定位到哪一步。你得到的不是智能，是不确定性。

因此，能用工作流编排的，别用 Agent 硬扛；能写成函数的，就别用 prompt 硬求。

实际合作中，我发现比“用不用 Agent”更容易走偏的，是拿形态给 Agent 设门槛。有些团队把“只接 Skill，不接 Agent”写成了规矩。问为什么，才发现他们的顾虑有一半是对的：Agent 默认给你的是一段语义结果，你拿不到它结构化的接口契约，就没法在代码里接着编排下一步。

问题是，他们把"我要可编排的构件"这件事，翻译成了"我不接 Agent 形态"这条规矩。 可编排性从来不是形态给的，是接口给的。把顾虑升级成一道形态门槛、一刀切写进规矩，那就是一种无脑的形态信仰了。

被拒的一方也无奈，只能换一种活法：有的在外面套一层MCP 协议，把自己包装成一个工具；有的把自己蒸馏成一堆 Skill。形式上都合规了，内核一点没变。它还是那个会临场发挥、路径飘忽的Agent，只是这次学会了穿着确定性的外衣进门。

你以为风险没了，其实只是把风险藏进了看不见的地方。一个明牌的 Agent，你至少知道它飘；一个伪装成工具混进来的 Agent，你连它飘在哪一步都察觉不到。

三、有错位，也有判断方法

半年下来，我遇到的越界，九成逃不出这几种。

它们看着不一样，本质都是同一个：把该确定的事，交给了模型。区别只在交给谁：提供 Skill、写进 prompt、留给模型临场发挥，还是包成一个 Agent。

第一种，用 Skill 干 MCP 的活。

这是我在合作中最高频遇到的情形。

特征很好认：需求里只要出现"必须""确保""稳定输出""固定格式""每次都一样"，你要的就不是 Skill。

这类需求只有两种处理方式：做成 MCP tool，或者做成 Workflow 里的一个确定性节点。让代码兜底，别让自然语言兜底。

我仔细推敲过，为什么大家总往 Skill 上凑？因为它门槛最低？

的确，你写几段文本就能交付，不用定义接口，不用处理错误分支，不用跟后端打交道。看起来是捷径，爽歪歪。

但代价是后置的。

一个确定性逻辑的正确实现，可能是两天的接口开发；用 Skill 糊上去，只要两小时。但它会在往后每一次运行里制造不确定的成本：偶发的格式错误、需要人工复核的输出、说不清谁该负责的故障。开发省下的时间，会在运维阶段加倍还回去。

毕竟Skill 的执行者是概率模型，凡是要求 100% 成立的东西写进 Skill，都是把不变量交给了骰子。

那如果我把想要的数据设为接口必填，是不是就稳了？

不够。接口必填只是静态声明——"这些字段应该必填"，它本身不执行任何东西。只有 MCP Server 的运行时校验才能保证动态执行，不合规就拒。

具体来说，校验分两头：

• 入参校验管调用方，参数不对就拒，别往下打外部 API；

• 出参校验管你自己，外部数据回来后、返回给 Agent 前，保证该有的都有内容。

没有这层运行时校验，"必填"就只是纸面约定，别人依然可以无视。

但也别因此就判 Skill 死刑。

没有 Skill，模型不知道怎么调工具、参数老填错、该追问时瞎编。它作用在决策空间，事前告诉模型该怎么做，降低犯错概率；MCP Server 的校验作用在正确性边界，事后卡住坏结果，封住错误后果。

一个管事前，一个管事后，缺一不可。

第二种，用Prompt干鉴权的活。

前面说的是浪费成本。同样的错位，还有一个更危险的版本。

上周有个团队反馈，他们提供的一批 MCP 工具没做鉴权。理由听着很正当：明明都是对内服务的工具，为什么校验员工业务权限这件事，要 MCP 层单独做，而不是在 Agent 层统一支持？

乍一听挺有道理。但仔细想，在 Agent 层你能怎么做？在 prompt 里约束？

这和在 Skill 里写"必须"是同一个错误——把必须确定的事，交给了一段可以被解释、也可以被绕过的自然语言。一段精心构造的输入，就能让它忘掉那条约束。用 prompt 做权限，等于把保险箱的钥匙挂在门上，再贴一张纸条：请勿拿走。

即使不被攻击，模型也容易产生幻觉。退一万步说，即使你侥幸过关，也过不了安全审计这一关。模型判断该用户能访问，所以放行了——这个答案在任何一家正经公司都过不了审计。

也就是说，安全边界必须在模型之外。MCP Server 侧必须做好认证鉴权、最小权限、危险操作白名单和二次确认。Agent 层能做的只有软约束，它承担不了安全职责。

对于MCP提供方来说同理，你别轻信 Agent 递过来的身份。它说用户是谁，不等于用户就是谁。权限校验要在你自己这一侧重新做一遍，而不是接过那张通行证就放行。

第三种，用模型干接口的活。

最后一种，用 Agent干流程的活。

有些团队本能地觉得 Agent 比工具高级，做 Agent 才算拿得出手。于是你会看到，一个三步能走完的确定任务，做成 Agent 之后可能走五步十步，还可能走岔。

你能画成流程图，就别做成 Agent。Agent 不是更高级的 Workflow，它只配处理一类问题：下一步得看上一步的结果才能定。除此之外，它只会让你多花几倍的钱买回一堆不确定。

几种错位讲完，你可能会问：具体到一个能力，我怎么知道该做成什么？按顺序问四个问题，如下图所示：

图：几种错位的应对方式

第一问，它需要确定性输出吗？唯一正确答案、固定格式、必须一致，只要沾上一样，答案就是 MCP tool，或者 Workflow 里的一个确定节点。

不是，进第二问：它需要模型的判断、生成或组织能力吗？不需要，那它就是个普通流程或代码，别把模型请进来。

需要，进第三问：它的步骤能提前画出来吗？顺序基本固定、分支有限，那就是 Workflow 搭骨架，里面填 Skill 和 MCP。

不能，进第四问：下一步是否取决于上一步的动态结果？是，才轮到 Agent。不是，一次模型调用就够了，不必为它搭一个 Agent。

大部分错位，在前两问就被拦下来了。

四、边界清晰，本质是契约清晰

回到开头那场鸡同鸭讲的谈判。

协作之所以疲惫，核心是因为边界不清，误让每个人都笃定自己才是对的。做Agent 的觉得工具太 low，做 Skill 的觉得 MCP 太死板，做 MCP 的觉得对方在给他添乱。大家都在讨论不同的东西，自然谈不拢。

上一篇我提过一个观点：产品经理的工作，从管界面变成了管契约。放到造工具这件事上，这句话就是全部答案。

契约不抽象，它长得很具体。比如所有Skill 的返回，必须共用同一套结构：成功长什么样、失败长什么样、错误码怎么定义，全平台一个样。少这一条，Agent 那边就得为每个 Skill 写一段 if-else 去兼容，成本会在半年后指数级地涨回来。

契约的价值，在于它让下游不必猜。

• 负责确定能力的，就把它做成MCP。接口稳定，行为可预期，验收标准是接口对不对、稳不稳、异常处理全不全；

• 负责方法的，就把它做成Skill。聚焦“怎么做”，别硬扛确定性。验收标准是它教的方法好不好、用上之后模型表现有没有提升、边界情况有没有覆盖；

• 流程是确定的，就老实编排成Workflow，别为了显得智能而牺牲可靠性。验收标准是流程跑不跑得通、可不可观测、出错能不能定位到具体一步；

• 只有真需要自主决策的地方，才动用Agent。

这么分下来，每个团队交付的东西都有自己的验收标准。MCP 看接口，Skill 看效果，Workflow 看流程。谁的成绩一目了然，不用再抢 Agent 那个头衔。

头衔不产生价值。一个稳定的接口，一套好用的方法，一条跑得通的流程，才产生价值。

如果你也是集成方，或是被集成的一方，你也有同样困扰的话，有个原则能省掉很多拉扯：先别急着定做成什么，先一起把这件事的确定性画出来。确定的部分在哪里，不确定的部分在哪里。边界画出来了，形态自然就有了。

把“该做什么”的争论，换成“有多确定”的讨论，大部分分歧会自己消失。

该确定的，别交给概率；该判断的，别塞进代码。

工具可能会一直换，但这道题会一直在。