MCP与Agent Skill之争：AI Agent的「能力单元」该长什么样

2026 年做 Agent，绕不开一个问题：Agent 的能力单元，应该封装成什么形态？

两条路线正在分庭抗礼：一条是工具调用协议（以 MCP 为代表），把能力封装成可远程调用的 Server，暴露一组工具；另一条是技能包（Agent Skills），把能力封装成带说明文件的本地知识+脚本目录。

这不是”哪个更好”的问题，而是两种不同的抽象边界。搞混了，Agent 会变得又贵又不听话。

一、两种抽象的差别

MCP：远程过程调用

MCP Server 给 Agent 暴露的是一份工具清单：名称、参数 schema、描述。Agent 决定调用哪个、传什么参数。执行发生在 Server 端。

• 强项：跨进程、跨机器、跨组织复用；权限可以按 Server 粒度控制；状态在服务端。
• 弱项：每个工具定义都占用上下文；工具之间的编排逻辑不在 Server 里，要由模型现场决定。

Agent Skill：本地说明书 + 脚本

Skill 是一个目录，里面通常有：说明文件（什么时候用、怎么做、注意事项）、脚本、模板、参考文档。

• 强项：渐进式加载——先只读一小段说明，需要时再读细节；可以封装”多步流程 + 中间判断”，这是工具清单表达不了的；纯本地，零网络开销。
• 弱项：分发与权限控制弱；容易被写成一堆只有作者看得懂的脚本。

二、关键差异：上下文开销

这是最实际的差别。

假设有一个”处理客户退款”的能力。

• 用 MCP 封装：你需要暴露查订单、查政策、算退款额、提交退款、发通知五个工具。五个 schema 常驻上下文，每个都要写清参数含义。Agent 要自己判断先查哪个。
• 用 Skill 封装：上下文里只有一句”处理退款时读 refund/SKILL.md”。Agent 读了说明书，发现里面写着”先查订单，再按 2025 版政策计算，超过 500 元要人工确认”，然后照着脚本调用。

**工具数量越多、编排逻辑越固定，Skill 的优势越明显。**反之，能力原子化、组合方式随场景千变万化时，工具的弹性更好。

三、组合能力：Skill 能表达、工具不能的东西

工具清单表达不了一件事：“做完 A 之后如果出现 B，就改走 C”。

这类知识在 MCP 里只能写在系统提示词里，而提示词会被稀释、会被压缩掉。写在 Skill 说明书里，它就在正确的时间被读到——这是按需加载的最大价值。

三个典型应该做成 Skill 的场景：

1. 有标准作业流程的任务：对账、发布、审核、上架。
2. 团队内部约定：命名规范、提交格式、字段含义。
3. 需要多步判断的工作：故障排查、数据修正。

三个应该做成 MCP 的场景：

1. 跨系统集成：CRM、ERP、工单、日历。
2. 需要统一鉴权的资源：按租户、按角色隔离。
3. 高频、原子、参数简单的动作：查询、发送、创建。

四、一个可落地的混用架构

推荐分层：

Agent
 ├─ Skill 层：流程、规则、模板、判断逻辑（按需加载）
 ├─ MCP 层：系统连接器、鉴权、幂等写入（远程调用）
 └─ 脚本层：Skill 内部调用的本地确定性逻辑

原则是：Skill 管”怎么想”，MCP 管”怎么连”，脚本管”怎么算”。

具体做法：

• 把系统连接全部收敛到少数几个 MCP Server，不要让每个 Skill 自带一套连接代码。
• Skill 的说明书里只写”调用哪个 Server 的哪个工具”，不写鉴权细节。
• 计算类逻辑（金额、日期、单位换算）放脚本，不要让模型手算。

五、评测：怎么知道封装方式选对了

跑同一批任务，看三个数：

• 每任务的上下文 token 消耗：Skill 方案通常显著更低。
• 首轮工具选择正确率：工具过多时，模型选错工具的比例会上升。
• 流程步骤遗漏率：Skill 方案在这一项通常更好，因为步骤写在说明书里而不是靠模型记忆。

六、别掉进两个坑

坑一：把所有东西都做成工具。 结果上下文被几十个 schema 塞满，Agent 反而更笨。

坑二：把 Skill 写成脚本集合。 没有说明书，没有”什么时候用”的判断，Agent 根本不知道自己有这个能力。

能力封装的本质是信息架构问题：什么信息该常驻，什么信息该按需加载。想清楚这一点，选哪种协议都是次要的。