Multi-Agent

定义

多 Agent 架构，通过多个专门的 Agent 协同工作来完成复杂任务。

核心挑战

Multi-Agent 架构虽然解决了不同 Agent 隔离问题，却将复杂度转移到了 Agent 之间的通信带宽与协同上。如果想要保证 Agent 效果，就需要投入巨大的成本去打磨 Agent 之间的通信过程，设计精细的摘要策略等等。

Agent 之间的通信

比喻

就像你是一个老的管理者，新来了一个管理者，你需要教会这个新管理者如何给下属布置任务，而且要让下属更好的完成任务。

关键点

• 你得告诉他有哪些下属（Agent 列表）
• 你得告诉他什么时候该自己干、什么时候该委派（When NOT to use）
• 你得教他怎么写工作说明（Writing the prompt）
• 你得防止他瞎指挥（反模式警告）

Claude Code 的实践

在 Claude Code 中，AgentTool 里面的 Prompt 就是做这件事的，它最后动态组装的 Prompt 不是给用户看的，而是给主 Agent 看的指导手册，教主 Agent 怎么使用 AgentTool 来派遣子 Agent。

六大系统内置 Agent Tool

1. General-Purpose Agent：万能打工人，拥有所有工具的使用权限
2. Explore Agent：代码库侦察兵，速度优先的只读搜索专家
3. Plan Agent：软件架构师，制定实施方案
4. Verification Agent：质量检验官，红蓝对抗，想办法把代码搞崩
5. Claude Code Guide Agent：Claude Code 使用说明书
6. Statusline Setup Agent：状态栏安装
7. Fork Sub Agent：主 Agent 的"分身"，继承完整对话历史

设计考虑

• Token 成本：Explore、Guide 都用 Haiku，比 Opus 便宜很多
• 安全隔离：Verification Agent 不能改文件，Explore Agent 不能写文件，通过禁用工具实现"最小权限原则"
• 上下文管理：子 Agent 的工具输出不会污染主 Agent 的上下文窗口
• 并行效率：Verification Agent 在后台运行，不阻塞用户

三种技术路线对比

真正贵的不是 token，真正贵的是失控。

来源

• 深度解析Claude Code在Prompt_Context_Harness的设计与实践
• Harness Engineering 工程化落地指南