造工具还是雇专家？AI Agent 扩展的黄金法则

目标读者：AI 应用开发者、Agent 系统架构师、对构建复杂 AI 智能体感兴趣的技术人员
核心价值：清晰界定 Skills（技能）与 SubAgents（子智能体）的边界，提供实用的架构选型指南，帮助开发者构建更强大、更模块化的 AI 系统
阅读时间：10 分钟

一句话摘要：Skills 是 AI 的"手"，负责具体执行；SubAgents 是 AI 的"脑"，负责独立思考——掌握两者的协作艺术，是构建超级 Agent 的关键。

引言

“为什么我的 Agent 在处理复杂任务时总是’顾此失彼’？”

这是很多开发者在从简单的 Chatbot 转向构建复杂 Agent 系统时遇到的第一个瓶颈。当你试图让一个 Agent 既能写代码、又能查文档、还能做架构设计时，它的 Context Window（上下文窗口）很快就会被撑爆，推理能力也会因为干扰信息过多而显著下降。

这时候，我们通常会寻求"扩展"Agent 的能力。但在当前的 AI 架构语境下，这种扩展主要通过两条路径实现：赋予它更多的 Skills（技能/工具），或者雇佣更多的 SubAgents（子智能体）。

这两者听起来似乎都是"让 AI 变得更强"，但它们在本质上有着天壤之别。选错了方向，不仅无法提升效率，反而会制造出一个臃肿、迟钝的"缝合怪"。

今天，我们就来彻底拆解这两个核心概念，看看在打造 AI 系统的军火库时，何时该造"工具"，何时该雇"专家"。

一、Skills：不只是工具，更是认知协议

Skills（技能），在很多框架中也被称为 Tools（工具）或 Actions（动作）。

表面上看，Skill 是一个被封装好的、确定的函数或能力单元。 它是 Agent 的"手"。当 Agent 需要与外部世界交互，或者执行某个标准化的计算任务时，它会调用 Skill。

但这只是 Skill 的"初级形态"。

Skills 的两个层次

第一层：工具型 Skill

这是最基础的 Skill 形态——原子化的工具调用：

• 原子性（Atomic）：只做一件事，且把这件事做好。比如"读取文件"、“发送邮件”、“查询天气”。
• 确定性（Deterministic）：输入参数 A，通常能得到预期的结果 B。逻辑是硬编码的（Code），而不是概率性的（Model）。
• 无状态（Stateless）：不关心上下文的历史，只是被调用、执行、返回结果。

第二层：认知协议型 Skill

当你开始认真设计 Skill 时，会发现一个更深层的真相：

Skill 改变的不是 AI 知道什么，而是 AI 如何思考。

真正强大的 Skill 不是"知识库"——不是往里面塞文档、塞最佳实践、塞代码规范。它是一套认知协议，重塑 AI 处理某类问题的路径。

举个例子。当用户问"我的列表组件渲染太慢"时：

Skill 类型	AI 的反应
知识库型	“用 React.memo 包裹子组件”
认知协议型	“这是状态设计问题还是性能优化问题？状态为什么放在父组件？子组件真的需要全部 props 吗？”

区别在哪里？知识库型 Skill 做的是模式匹配：重渲染 = 用 memo。认知协议型 Skill 教会 AI 的是追溯推理：从表面问题追溯到根本原因，再推导出正确方案。

知识库装的是答案，认知协议装的是问法。

Skills 的核心价值

理解了 Skill 的双层本质后，我们可以总结它的三个核心价值：

1. 固化流程：把多步骤的复杂操作变成一键触发
2. 调用工具：整合 Bash 命令、API 调用、文件操作，提供确定性执行
3. 重塑认知：改变 AI 处理某类问题的思考路径

Skills 是 Agent 的外骨骼，它不负责思考，只负责让思考落地——或者，让思考更有章法。

什么时候你需要一个 Skill？

当你发现 Agent 缺乏某个具体的执行能力或特定的思考框架时，你需要一个 Skill。

场景示例：

• Agent 需要计算两个日期的间隔天数 → 工具型 Skill calculate_date_diff
• Agent 需要获取实时的股票价格 → 工具型 Skill fetch_stock_price
• Agent 需要按固定流程生成技术博客 → 流程型 Skill tech-blog
• Agent 需要用专家思维分析 React 性能问题 → 认知协议型 Skill react-performance-analyzer

二、Skill 的三大反模式

在实践中，很多开发者容易陷入"万物皆 Skill"的误区。以下是三个最常见的反模式：

反模式一：角色扮演包装

“让 AI 扮演资深架构师”——这不需要 Skill，一句 Prompt 就够了。

# 差：包装成 Skill
---
name: senior-architect
description: 以资深架构师的视角回答问题
---
你是一位有 15 年经验的系统架构师...

# 好：直接用 Prompt
"请以资深架构师的视角，分析这个设计方案的优缺点"

为什么不该用 Skill：角色设定是纯文本，不涉及流程和工具。包装成 Skill 增加了维护成本，却没有带来额外价值。

反模式二：一次性任务

“帮我分析一下这个 CSV 文件”——一次性的、不会重复的任务。

就算你创建了一个 csv-analyzer Skill，用完这一次之后呢？它会静静躺在目录里，占用认知空间，直到你某天清理时才想起来。

判断标准：如果这个任务你不会重复做三次以上，直接用 Prompt。

反模式三：纯知识堆砌

把一堆"最佳实践"、“设计原则”、"代码规范"堆成一个文件，命名为 Skill。

# 差：纯知识堆砌
---
name: react-best-practices
---
## 组件设计原则
1. 单一职责...
2. 组合优于继承...
...（2000 字的规范文档）

这不是 Skill，这是文档。放在 CLAUDE.md 或项目的 context 文件里就行。

判断标准：如果内容是"AI 应该知道的知识"而不是"AI 应该执行的流程"或"AI 应该遵循的思考路径"，用 Context 而非 Skill。

一个 Prompt 包装成 Skill，不会让它变得更强大，只会增加维护成本。

三、SubAgents：独立思考的专家团

SubAgents（子智能体），则是完全不同的物种。

本质上，SubAgent 是一个拥有独立 Prompt、独立上下文甚至独立记忆的"小 Agent"。 它是主 Agent 的"分脑"或"下属"。当主 Agent 遇到一个庞大且复杂的任务时，它会将任务拆解，委托给 SubAgent 去完成。

SubAgents 的核心特征

• 自主性（Autonomous）：它不仅仅是执行命令，它需要理解目标、规划步骤、自我反思。
• 有状态（Stateful）：SubAgent 通常维护自己的对话历史和短期记忆，这样它的推理过程不会污染主 Agent 的上下文。
• 专业化（Specialized）：通过特定的 System Prompt 设定，它被扮演成某个领域的专家（如"资深前端工程师"或"安全审计专家"）。

如果说 Skill 是你手中的菜谱，那么 SubAgent 就是帮你做饭的米其林厨师。

什么时候你需要一个 SubAgent？

当你需要并行处理任务，或者任务的复杂度需要多步推理且容易干扰主流程时，你需要一个 SubAgent。

场景示例：

场景	为什么用 SubAgent
代码审查	主 Agent 写完代码后，唤起"CodeReviewer Agent"专门挑刺，不干扰生成思路
长篇写作	主 Agent 负责大纲，分别唤起"章节撰写 Agent"填充每章内容
深度调研	需要多轮搜索、阅读、总结，中间状态对主任务是噪音
代码重构	需要理解上下文、规划步骤、验证结果，是完整的推理链

SubAgent vs 认知协议型 Skill：微妙的边界

这里有一个容易混淆的点：认知协议型 Skill 也能改变 AI 的思考方式，那它和 SubAgent 的区别是什么？

关键区别在于上下文隔离和自主程度：

维度	认知协议型 Skill	SubAgent
上下文	共享主 Agent 的上下文	独立的上下文窗口
自主性	遵循预设的思考路径	可以自主规划和调整
中间过程	对主 Agent 可见	可以隔离，只返回结果
适用场景	单一问题的深度分析	复杂任务的完整执行

简单的判断法则：

• 如果你只是想让 AI “换一种方式思考同一个问题” → 认知协议型 Skill
• 如果你想让 AI “独立完成一个子任务，只告诉我结果” → SubAgent

四、巅峰对决：Skill vs SubAgent

为了更直观地对比，我们来看一张完整的维度分析表：

维度	Skills (技能/工具)	SubAgents (子智能体)
隐喻	工具箱里的锤子、计算器	团队里的初级工程师、研究员
主要驱动	代码逻辑 / 认知协议	模型推理 (LLM + Prompt)
上下文消耗	低 (工具型) / 中 (认知协议型)	高 (需维护独立的上下文窗口)
任务类型	单步/明确/标准化 或 单问题深度分析	多步、模糊、探索性任务
控制力	高 (结果可控/路径可控)	中 (依赖模型的遵循能力)
错误处理	抛出异常，由调用者处理	自我修正，或返回自然语言解释
复用性	高度可复用	通常针对特定任务类型
调试难度	低 (逻辑透明)	高 (黑盒推理)

Skill 追求的是输入输出的精确和思考路径的规范，SubAgent 追求的是解决问题的智能和自主性。

五、架构决策：五步决策法

在实际开发中，很多开发者容易陷入两个极端：要么"过度 Skill 化"——把一切都包装成 Skill；要么"过度 SubAgent 化"——为了看起来高大上，把本该写成 Skill 的功能强行做成 SubAgent。

这里有一套**“五步决策法”**，助你做出正确选择：

Step 1：复杂度测试

这个任务是否可以通过一个简单的 API 调用或几行代码解决？

• Yes → 工具型 Skill（不要为了做加法而雇佣一个数学教授）
• No → 进入下一步

Step 2：流程固化测试

这个任务是否需要遵循特定的、非通用的流程？

• Yes → 流程型 Skill（如果流程是固定的，就用 Skill 固化它）
• No → 进入下一步

Step 3：思考路径测试

这个任务是否需要 AI 用特定的思维框架来分析？

• Yes → 认知协议型 Skill（教 AI 如何思考，而非告诉它答案）
• No → 进入下一步

Step 4：交互性测试

完成这个任务是否需要与环境进行多轮交互（搜索 → 阅读 → 再搜索 → 总结）？

• Yes → SubAgent（它需要独立的上下文来维护中间状态）
• No → 进入下一步

Step 5：上下文隔离测试

这个任务产生的中间过程是否对主任务有价值？

• No（我只要结果，过程是噪音）→ SubAgent（在沙箱里完成，只返回结果）
• Yes → 也许主 Agent 自己做更好

快速判断表

问题	答案	选择
能用一个 API 调用解决吗？	Yes	工具型 Skill
需要固定流程吗？	Yes	流程型 Skill
需要特定思考框架吗？	Yes	认知协议型 Skill
需要多轮交互吗？	Yes	SubAgent
中间过程是噪音吗？	Yes	SubAgent
会重复使用 3 次以上吗？	No	直接用 Prompt

能用 Prompt 或 Context 搞定的文本，不要强行包装成 Skills；能用 Skill 固化的流程，不要浪费一个 SubAgent。

六、最佳实践：组合拳架构

最强大的架构往往是两者的结合：Orchestrator（指挥家）模式。

架构示意

┌─────────────────────────────────────────────────────────────┐
│                    Main Agent (Orchestrator)                │
│                         指挥家                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │ Investigator│  │   Coder     │  │  Reviewer   │        │
│  │  SubAgent   │  │  SubAgent   │  │  SubAgent   │        │
│  │             │  │             │  │             │        │
│  │ ┌─────────┐ │  │ ┌─────────┐ │  │ ┌─────────┐ │        │
│  │ │  grep   │ │  │ │  write  │ │  │ │ analyze │ │        │
│  │ │  Skill  │ │  │ │  Skill  │ │  │ │  Skill  │ │        │
│  │ └─────────┘ │  │ └─────────┘ │  │ └─────────┘ │        │
│  │ ┌─────────┐ │  │ ┌─────────┐ │  │ ┌─────────┐ │        │
│  │ │  read   │ │  │ │  test   │ │  │ │ security│ │        │
│  │ │  Skill  │ │  │ │  Skill  │ │  │ │ protocol│ │        │
│  │ └─────────┘ │  │ └─────────┘ │  │ └─────────┘ │        │
│  └─────────────┘  └─────────────┘  └─────────────┘        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

主 Agent 作为指挥家，手下管理着几个 SubAgents。而每个 SubAgent 手中又握着特定的 Skills——既有工具型的，也有认知协议型的。

实战案例：修复一个 Bug

主 Agent："我们需要修复这个 Bug。"
    │
    ▼
Investigator SubAgent 接单
    ├── 使用 grep Skill 搜索代码库
    ├── 使用 read Skill 读取相关文件
    └── 使用 root-cause-analysis 认知协议 Skill 分析根因
    │
    ▼
Investigator 汇报："问题在 user.ts 第 50 行，根因是状态竞争。"
    │
    ▼
主 Agent："好，Coder 你来修。"
    │
    ▼
Coder SubAgent 接单
    ├── 使用 write Skill 修改代码
    └── 使用 test Skill 运行测试
    │
    ▼
主 Agent："Reviewer，检查一下。"
    │
    ▼
Reviewer SubAgent 接单
    ├── 使用 analyze Skill 分析代码变更
    └── 使用 security-review 认知协议 Skill 检查安全风险
    │
    ▼
Reviewer 汇报："代码逻辑正确，无安全风险，建议合并。"

组合拳的优势

1. 关注点分离：每个 SubAgent 专注于一类任务
2. 上下文隔离：Investigator 的搜索过程不会污染 Coder 的上下文
3. 能力复用：Skills 可以在多个 SubAgents 之间共享
4. 可观测性：每个环节的输入输出都清晰可见

七、设计 Skill 的四个原则

如果你决定创建一个 Skill，以下四个原则能帮助你设计出真正有价值的 Skill：

原则 1：定义"元问题"，而非罗列答案

# 差
Q: 组件重渲染怎么办？
A: 用 React.memo 包裹。

# 好
当遇到重渲染问题时，问自己：
- 这个状态真的需要放在这个层级吗？
- 哪些组件真正依赖这个状态？
- 这是"状态设计问题"还是"渲染优化问题"？

原则 2：建立追溯路径，而非直接给结论

# 差
重渲染 → 用 React.memo
依赖警告 → 加上依赖

# 好
| 表面问题 | 追问 |
|---------|------|
| 子组件频繁重渲染 | 这个状态为什么在父组件？子组件真的需要全部 props 吗？ |
| useEffect 依赖循环 | 这个副作用的职责是否单一？是否混合了多个关注点？ |

原则 3：约束输出格式，强制展示推理

## 输出要求

回答必须包含：
### 推理链
+-- 表面问题: [具体描述]
+-- 根因分析: [追溯到的根本原因]
+-- 设计决策: [基于根因的解决方案]

### 推荐方案
[架构正确的方案，而非语法层面的 quick fix]

原则 4：确保触发机制

Skill 定义再好，不被触发也白搭。确保：

• 触发条件明确且不冲突
• 关键词覆盖用户可能的表达方式
• 必要时使用 Hook 机制自动注入

最好的 Skill，是让 AI 学会问正确的问题。

总结

AI Agent 的扩展之路，本质上是在**“确定性"与"智能性”**之间寻找平衡。

• 用工具型 Skills 来锚定确定性：确保计算准确、数据有据、操作合规
• 用认知协议型 Skills 来规范思考：教 AI 如何分析问题，而非直接给答案
• 用 SubAgents 来扩展智能性：处理复杂流程、隔离上下文、实现分工协作

不要手里拿着锤子（Skill），就把所有问题都看成钉子；也不要因为招了一群专家（SubAgents），就连拧螺丝这种小事都要开会讨论。更不要把 Prompt 强行包装成 Skill，那只是自欺欺人。

只有理清了这两者的边界，你的 AI Agent 才能从一个"笨拙的聊天机器人"，进化为一支"精锐的特种部队"。

好的工具观不是"拥有更多工具"，而是"知道什么时候用什么工具"。

参考

本文的分析基于当前主流 AI Agent 框架（如 LangChain, AutoGen, Claude MCP）的设计理念，以及开源社区对 Claude Code Skills 机制的实践探索。