AI Agent:多智能体架构设计规范,是协作,不是魔法

很多人对多智能体（Multi-Agent）的第一印象，来自 CrewAI、AutoGen 这类框架的宣传视频：几个 Agent 坐在一起开会，一个说"我是CEO"，另一个说"我是CTO"，然后它们开始聊天、争论、输出文档……

看起来很酷，但也暴露了老式多智能体框架的几个深层问题：

• Agent 之间的"聊天"缺乏结构性约束，容易跑偏
• 角色扮演式的顶层设计，让上下文迅速膨胀
• 缺乏明确的职责边界和停止条件，Agent 可能陷入循环争论
• 没有合理的任务拆分和结果聚合机制

不是放几个 Agent 到一起让它们"聊"，就叫多智能体系统。 真正的多智能体，核心只有一个词：协作（Coordination）。

在讨论怎么设计之前，先判断要不要上多智能体。

这个判断标准其实很简单——如果你有一个任务，单个 Agent 加一套工具链就能完成，且质量可接受，那就不要上多智能体。多一个 Agent 就多一层上下文开销、状态同步成本、错误传播面。

典型的"单 Agent 更好"场景：

• 一个检索增强生成（RAG）查询问答
• 一个代码审查工具
• 一个网页信息提取器
• 一个结构化数据分析任务

▎关键不是"能不能用多智能体"，而是"多智能体带来的收益是否显著超过其增加的系统复杂度。"

1. 每个 Agent 有清晰的角色边界

不是"你是CEO他是CTO"这种模糊角色，而是：

• Planner（规划者） ：接收用户意图，拆分为子任务，分配给下游 Agent
• Executor（执行者） ：执行具体工具调用，返回结果
• Reviewer（审查者） ：审查 Executor 的输出质量，给出修改建议
• Critic（批评者） ：从对立视角找漏洞
• Router（路由器） ：根据任务类型，路由到不同的专用 Agent

每个角色必须有明确的 输入输出 Schema 和 停止条件。

2. 用 Supervisor 或 Graph 来编排，而不是自由对话

最坑的设计就是让 Agent 之间随便发消息。"你一句我一句"的模式缺乏收敛性，Agent 很容易陷入自我论证的循环。

正确的做法：

• Supervisor 模式：由一个中央调度 Agent 负责任务分配、进度跟踪、结果聚合。所有 Agent 只和 Supervisor 通信，不互相直接对话。
• Graph 模式：用有向无环图（DAG）定义任务流程，每个节点是一个 Agent，边是数据流转。这种方式状态可控、可恢复执行。

这两种模式都能有效避免"争论循环"和"任务漂移"。

3. 明确的上下文隔离

多智能体最大的隐形杀手是上下文膨胀。

当 Agent A 的完整对话历史不断被传递给 Agent B 时，上下文窗口很快被无关内容填满，模型的有效推理能力急剧下降。

解决方案：

• 每个子 Agent 运行在自己的独立上下文中
• Agent 之间的消息传递应该是摘要级的结构化数据，而不是完整对话
• 使用 Context Compaction（上下文压缩）技术，定期总结和压缩历史

当前最值得研究的子 Agent 实现，是 Anthropic 的 Claude Code Subagents。

它的设计亮点：

• 上下文隔离：每个 Subagent 运行在自己独立的上下文窗口中，主会话不受影响
• 自定义系统提示：每个 Subagent 有自己的 System Prompt、工具权限、模型选择
• 自动委派：Claude 会根据 Subagent 的描述自动决定何时将任务委派给它
• 分层权限：内置 Subagent（Explore 只读、Plan 只读、General-purpose 全功能）各有不同的工具集
• Fork 机制：支持将当前会话 Fork 到一个新 Subagent，保留上下文但独立执行

官方文档中特别提到：

Subagents 帮助你在主会话上下文之外完成探索和实现工作，避免搜索日志、文件内容等无关信息污染主会话上下文。

Claude Code 还有一套强大的 Hooks 机制，允许在 Agent 生命周期的每个节点插入自定义逻辑——会话开始、用户提交提示词、工具调用前/后、子 Agent 启动/停止、上下文压缩前/后，等等。

这就是我们所说的可编排性：不是黑箱里的魔法聊天，而是每个步骤都可以被拦截、检查和修改的工程系统。

多智能体不仅涉及单个框架内的 Agent 协作，还涉及不同系统、不同厂商、不同框架的 Agent 之间的互操作。这需要协议层面的标准化。

这里有三份关键协议值得关注：

A2A（Agent-to-Agent Protocol）

由 Google 推出，解决的是：不同 Agent 之间如何发现彼此、通信、协作。

核心思想：Agent 发布自己的"能力卡片"（Agent Card），其他 Agent 发现后可以根据卡片信息决定如何协作。通信使用 JSON-RPC 格式，支持流式响应。

ACP（Agent Client Protocol）

解决的是：宿主应用（编辑器、终端、IDE）和 Agent 之间的统一接口。

如果 A2A 是 Agent 和 Agent 通信，那 ACP 就是 App 和 Agent 通信。这个接口统一之后，一个 Agent 可以在多个宿主应用中使用，一个宿主应用也可以接入多个 Agent。

MCP（Model Context Protocol）

解决的是：Agent 如何连接外部工具和数据源。

MCP 让 Agent 能够标准化地发现和调用工具、访问数据源。它不是 Agent 之间的协议，而是 Agent 和"外部世界"之间的协议。

这三者共同构成了多智能体生态的协议基础设施：

• MCP 把工具接入 Agent
• A2A 把 Agent 接入 Agent
• ACP 把宿主应用接入 Agent

这是一个非常好的入门实践，因为它包含了多智能体设计的全部核心要素：

1. 任务拆分：把"写一篇文章"拆成"研究素材 -> 撰写 -> 审查 -> 修改"
2. 角色定义：Research Agent（只读、只搜索）、Write Agent（生成）、Review Agent（只审查、不修改）
3. 编排逻辑：按顺序执行，Review 发现的问题回传给 Write Agent
4. 结果聚合：最终的版本由 Review Agent 确认通过后输出
5. 停止条件：Review Agent 返回"无问题"或达到最大修改轮数

推荐的研究资源：

• Claude Code Subagents 文档 — 当前最值得拆解的子 Agent 实现
• Google Agent Development Kit (ADK) — Google 的多 Agent 开发框架
• A2A 协议规范 — 跨 Agent 互操作
• Claude Code Hooks 文档 — Agent 生命周期编排

多智能体不是魔法，不是把几个 Agent 放在一个群里聊天。它是设计。

是明确每个角色的职责边界，是定义清晰的输入输出接口，是用 Supervisor 或 Graph 控制执行流程，是在协议层面确保不同的 Agent 能流畅通信，也是把任务拆得足够合理、把上下文隔离得足够干净——最终让 1+1 真正大于 2。

如果你正在搭建多智能体系统，记住这句话：

把 Agent 当工人，不要当超人。用编排替代聊天，用协议替代耦合。