智能体 vs 技能

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

那个病毒式传播的框架——"停止构建智能体"——在修辞上很响亮，但技术上比听起来更温和。

Barry Zhang和Mahesh Murag在AI Engineer Code Summit上的16分钟演讲（可在YouTube上观看）并不是说"永远不要再构建智能体了"。它说的是：停止为每个领域构建不同的专业化智能体。构建一个通用智能体，并给它一个技能库。

1、真正的诊断

Anthropic的观点是，过去一年的智能体开发追逐了错误的变量。"我们过去认为不同领域的智能体会非常不同。底层的智能体实际上比我们想象的更通用。"一旦你有了一个与运行时结合的模型，拥有文件系统和代码执行能力——基本上就是Claude Code的模式——脚手架就不需要针对每个用例重建。变化的是领域知识。

他们的税务类比完美地捕捉了这个差距：你更愿意要一个从未读过税法的300智商天才，还是一个有20年经验的会计师？今天的智能体很聪明但缺乏专业知识。它们在有适当指导的情况下可以做令人惊叹的事情，但预先缺乏关键上下文，无法吸收你的专业知识，也不会随时间学习。技能填补了这个空白。

2、技能实际上是什么（从机制上讲）

一个技能只是一个包含SKILL.md文件的文件夹。markdown包含YAML前置元数据（名称和一行描述）和指令正文。它还可以捆绑支持文件——参考文档、Python脚本、模板。没有新的API接口，没有框架，没有注册表。

my-skill/ ├── SKILL.md # 元数据 + 指令 ├── reference.md # 深度参考（可选） ├── forms.md # 特定子流程（可选） └── apply_template.py # 可执行脚本（可选）

巧妙的部分是渐进式披露：

启动时，智能体只将每个技能的前置元数据加载到系统提示中——刚好足够知道技能的存在以及何时使用它。这意味着你可以安装数百个技能而没有上下文惩罚。当任务匹配时，它读取完整的SKILL.md。如果那引用了其他文件，它通过bash导航到那些文件。脚本在执行时其源代码根本不会进入上下文窗口。

实际的收益：技能可以包含全面的API文档、大型数据集、大量示例——未使用的捆绑内容有零上下文成本。

3、与MCP的比较（它们是互补的，不是竞争关系）

这对你的技术栈很重要，因为你已经大量使用MCP。两者服务于不同的层：

• MCP = 能力（智能体可以做什么——调用Gmail、查询GSC、发布到Slack）
• 技能 = 技术（如何做好一份工作——检查什么、以什么顺序、如何处理失败、"完成"是什么样的）

标准的MCP设置可以在智能体采取任何行动之前消耗约72%的上下文窗口。在200K模型上连接三个服务器（GitHub、Playwright、IDE），仅工具定义就占用了大约143K个token。MCP在会话开始时完整加载所有工具描述，无论对话是否会使用它们。技能完全绕过了这一点，因为只有元数据预先加载。

在生产中同时运行两者的实践者的诚实中间立场：全力投入技能，你的智能体有出色的操作手册但无法实时访问你的服务。全力投入MCP，你最终会得到蔓延，其中许多只是糟糕的API包装器。同时使用两者——技能描述工作流，MCP服务器提供工作流引用的工具。

4、真正落地的心理模型

Zhang和Murag的处理器/操作系统/应用类比值得记住：

• 模型 = 处理器——大规模投资，巨大潜力，但单独使用价值有限
• 智能体运行时 = 操作系统——围绕处理器编排进程、资源和数据
• 技能 = 应用程序——数百万开发者从独特视角编码领域专业知识的地方

只有少数几家公司制造芯片。几十家构建操作系统。数百万家构建应用。赌注是AI即将迎来相同的分布形态，而技能是他们试图向所有人开放应用层的尝试——包括非开发者。Murag声称会计、法律和招聘领域的人已经在编写技能。

5、何时构建技能，何时不构建

构建技能的情况：

• 你在不同对话中重复相同的指令
• 有程序性知识目前存在于资深人员的脑海中
• 任务有清晰的"完成定义"，因上下文而异
• 你希望在整个工作流中获得一致的输出质量

构建MCP服务器（或使用工具）的情况：

• 你需要实时数据、认证、实时状态或集中治理
• 问题关乎访问，而非专有技术

不要从头构建自定义智能体的情况：

• 一个配备正确技能和工具的通用智能体就可以完成工作。这正是演讲所反对的做法——为每个垂直领域单独搭建定制智能体脚手架，而一个通用智能体加上领域技能可以更快地达到目标且组合性更好。

6、一个值得保留的反面观点

自演讲以来几个月里，"技能杀死了MCP"的说法已经变得薄弱。在生产中同时运行两者的实践者报告了更微妙的情况：对于编码智能体用例，文档MCP通常足以让智能体生成正确的代码，技能很少被调用，且通常不会产生明显更好的结果。结论不是"技能总是赢"——而是正确的选择取决于你的问题主要是访问（MCP）还是主要是技术（技能），而在大多数真实系统中两者兼有。

底线：目前正在浮现的收敛架构是一个通用智能体 + 一个技能库 + 用于外部工具的MCP服务器。"停止构建智能体"这句话实际上是"停止为每个领域重建相同的智能体底盘"。专业知识才是困难的部分。打包一次，懒加载，让通用运行时处理其余部分。

原文链接: Agents vs Skills: The Full Picture

汇智网翻译整理，转载请标明出处