一次被 Sub-agents“坑醒”后的深度总结

最近一段时间，我在用 Claude Code 的 sub-agents 做全栈开发实验，原本以为创建“一支 AI 工程师团队”会让复杂需求变得轻松。但现实却给了我当头一棒：主 Agent 经常忘记调用专家代理、子代理之间不能有效交流，有时结果甚至不如一个 Agent 独立完成。

反复踩坑之后，我终于摸清了 sub-agents 的真实工作方式，也逐渐理解了三大模型之间的能力差异。下面把这段探索整理成一份清晰的指南，帮你真正把多代理机制用起来。

---

一、Sub-agents 的真实定位：不是“角色扮演”，而是独立专家

很多人第一次使用 Sub-agent 会把它当成“写个角色提示词”的高级版。其实完全不是。

一个真正的 sub-agent 具备三大核心特性：

① 独立上下文（Context Sandbox）

每个 sub-agent 拥有自己的 20 万 token 的独立记忆空间。
例如：
前端专家写组件时，不会被你在主对话里讨论的数据库结构干扰。

② 专业化思维（Deep System Prompt）

你可以给它写几百行的“系统提示”，嵌入专业规范、工程标准、风格守则，甚至公司内部流程。

③ 可复用（Reusable Expert）

设计好的 sub-agent 像一个“能力模板库”，可在不同项目里重复调用，保持稳定质量。

Sub-agent 的结构由两部分组成：

• YAML 配置（决定何时被调用）

• 系统提示词（决定能力与风格）

它们的存储位置也直接影响作用域：

---

二、高级编排：如何让多位专家真正合作？

Sub-agents 的价值在于协作，但这恰恰也是最容易出问题的部分。

1）不要依赖自动调用 —— AI 会偷懒

Claude Code 有两种调用方式：

• 自动路由：Claude 自己判断是否需要调用某个代理

• 显式调用：使用 @agent-name 强制启动特定代理

现实是：
自动路由非常不稳定。有时候全程一个 sub-agent 都不调，有时还会选错专家。

解决方案：
👉 复杂任务必须显式调用。

---

2）多代理协作的关键：用“文件”作为共享记忆

Sub-agents 被隔离在不同上下文中，它们彼此无法直接交流。
要让它们合作，需要一个“公共工作区”。

最有效的做法——让文件系统作为沟通桥梁。

示例工作流（规划 → 开发 → 审查）：

① Planner 负责产出技术方案

② Coder 读取规范并写代码

③ Reviewer 审查代码是否符合规范

这种“共享文档法”极其稳定，是目前最可靠的多代理协作模式。

---

三、什么时候不该用 Sub-agents？

不恰当的使用，会让工作量更大、结果更差。

以下场景用单 Agent 更好：

• 任务简单（写个函数、生成 SQL、修个 BUG）

• 需要用到完整对话历史（总结、推理、深度分析）

• 需要高一致性输出（上下文隔离反而会丢信息）

Sub-agents 的固有限制：

• 看不到完整思考过程（透明度低）

• 每次调用都是独立请求（Token 消耗高）

• 代码质量不一定更好（会出现奇怪的小 bug）

• MCP 工具调用并不总是稳定

---

四、开箱即用的 Sub-agents 模板资源

如果你不想从零写自己的专家代理，可以直接安装社区维护的模板库：

• VoltAgent / Awesome Sub-agents

• wshobson / agents

• vanzan01 / collective sub-agents

把仓库克隆进 ~/.claude/agents/ 就能立即使用。

---

五、总结：ChatGPT、Claude、Gemini 的真实差异（简明版

主打方向完全不同，互相互补。