> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 智能体 vs 技能
- URL: https://www.hubwiz.com/blog/agents-vs-skills/
- Published: 2026-05-08T11:45:38.000Z
- Updated: 2026-10-13T16:09:37.000Z
- Description: 停止为每个领域构建不同的专业化智能体。构建一个通用智能体，并给它一个技能库。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

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

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 # 可执行脚本（可选）

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

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-m9jASZ08h3ieasV1Nt1ltQ.png)

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

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

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-aU8Ev_Ik_mwmQ10nZ0Vcaw.png)

## 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](https://medium.com/@jsong%5F49820/agents-vs-skills-the-full-picture-f16422ec7f9b?ref=hubwiz.com)

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

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)