Agent 的下一步：从单 Agent 到多 Agent 协作的架构演进-平芜编程栈

Agent 的下一步：从单 Agent 到多 Agent 协作的架构演进

一、单 Agent 的天花板：工具、上下文与决策的三重边界

2025 年是 Agent 工具体系爆发的一年。大多数团队已经完成了"LLM + Tool Calling"的基础搭建，Agent 能调用搜索引擎、数据库、API 和代码解释器完成中等复杂度的任务。但把单 Agent 推到更复杂的生产场景时，三个天花板迟早会撞上。

第一个天花板是上下文窗口的有效长度。一个 Agent 执行 15 步以上的操作链时，第 16 步的决策质量会因为中间信息过载而下降。这不是模型容量的物理限制——200K token 的窗口本身够大——而是注意力稀释的信息论问题。指令、工具返回、中间结果、错误信息混合在同一个上下文中，模型在关键信息上的注意力分配被摊薄了。

第二个天花板是工具调用的冲突管理。当 Agent 需要同时操作数据库、文件系统和远程 API，工具之间的副作用可能相互干扰。一个 AWS 权限变更工具修改了 IAM 策略，5 步之后一个数据库迁移工具因为权限不足而失败——回溯 10 步日志找到根因，浪费的时间和 token 成本可能超过任务本身。

第三个天花板是决策范式。单个 Agent 的 ReAct 循环本质上是"贪心决策"——每一步选择当前看起来最优的工具调用，没有全局规划能力。这在多步骤、有依赖关系的任务中会反复进入死胡同。

二、多 Agent 架构的三种协作范式

多 Agent 协作不是"多创几个 Agent 实例"，而是不同的 Agent 角色承担不同的认知职责。

三种典型的协作范式目前在工业界并行演进：

编排模式 (Orchestrator-Worker)：一个主 Agent 负责任务分解和分配，多个 Worker Agent 各司其职。这种模式最接近人类团队的协作方式，也最容易调试——每个 Worker 的上下文是隔离的，故障排查时可以单独审查。代价是主 Agent 的规划能力决定了整个系统的上限——如果规划出错，Worker 再强也无济于事。

辩论模式 (Multi-Agent Debate)：多个 Agent 独立解决问题，然后通过辩论/投票机制达成共识。在数学推理和代码审查场景中，多个模型的交叉验证能显著减少幻觉。但辩论的 token 成本是单 Agent 的 N 倍，且投票机制可能在所有 Agent 都犯错时强化错误共识。

分层模式 (Hierarchical RAG + Agent)：将知识检索和行动执行分层。上层 Agent 负责语义理解和意图识别，通过 RAG 检索相关文档和代码；下层 Agent 根据检索结果执行具体操作。这种模式在代码库理解和 API 文档自动化场景中效果突出——上层理解"用户想做什么"，下层知道"怎么做"。

三、Agent 间通信协议：从自然语言到结构化消息

多 Agent 协作的最大工程挑战不在模型能力，而在 Agent 之间的通信协议。

自然语言通信的模糊性：两个 Agent 用自然语言传递信息，解析误差会逐层放大。Agent A 说"数据库连接异常，可能是网络问题"，Agent B 可能理解为"网络不通"，去重启网络组件而非检查连接池配置。信息每传递一次，准确率按 95% 算，5 次传递后降为 77%。

结构化消息与共享记忆：工程层面的解法是强制 Agent 间通信使用结构化 Schema。不是"用 JSON"，而是定义每种消息类型的必填字段——任务描述、预期输出格式、已知约束、优先级。同时引入全局共享记忆（Blackboard 模式），让所有 Agent 读写同一个状态对象，避免状态在多轮通信中漂移。

中断与重规划机制：单 Agent 的 ReAct 循环被打断后可以原地恢复。多 Agent 系统中，一个 Worker 执行失败可能影响整个任务图。架构上需要一个"Plan & Replan"层——当某个 Worker 报告不可恢复的错误时，规划 Agent 重新评估剩余任务是否仍然可完成，如果不可完成，降级为部分结果返回或触发人工介入。

// 多 Agent 通信消息的简化 Schema 设计 type AgentMessage struct { From string `json:"from"` // 发送 Agent ID To string `json:"to"` // 接收 Agent ID Type MessageType `json:"type"` // task/result/error/replan TaskID string `json:"task_id"` // 任务追踪 ID Payload json.RawMessage `json:"payload"` // 结构化数据 Constraints []string `json:"constraints"` // 需要遵守的约束 Priority int `json:"priority"` // 0-10, 10 最高 Deadline *time.Time `json:"deadline"` // 超时时间 } type MessageType string const ( MsgTask MessageType = "task" // 任务分配 MsgResult MessageType = "result" // 执行结果 MsgError MessageType = "error" // 错误上报 MsgReplan MessageType = "replan" // 触发重规划 )

这个 Schema 的核心思想是：让消息自己携带"后续 Agent 需要知道的全部上下文"，而不是依赖 Agent 自己去推理缺失信息。明确Constraints和Deadline字段可以让 Worker 在限定范围内自主决策，不需要频繁回调编排 Agent。

四、边界分析：什么时候不应该用多 Agent

多 Agent 有明确的适用边界。以下情况用多 Agent 是过度设计：

任务步骤数少于 5 步：单 Agent + 工具调用已经足够覆盖。多 Agent 的通信和编排开销在这类短任务中占比过高。

任务需要全局状态一致性：如果所有步骤共享同一个数据库事务或文件系统状态，拆分给多个 Agent 会造成状态同步复杂度指数增长。这种情况下，单 Agent 的顺序执行反而更可靠。

对延迟极度敏感（P99 < 2s）：多 Agent 交互至少涉及 3-5 次 LLM 调用，每次 500ms-2s，端到端延迟很难控制在 2 秒以内。如果你的场景是用户实时交互（如聊天助手），单 Agent 是唯一选择。

成本敏感的批量任务：多 Agent 的 token 消耗是单 Agent 的 2-4 倍。如果你在跑每天百万级的批处理任务，先优化 Prompt 和模型选择，而不是加 Agent。

五、总结

多 Agent 协作不是"下一个 LLM 能力升级"能跳过的问题，它是工程架构问题。三个关键的工程方向在 2026-2027 年会持续演进：Agent 间通信协议的标准化（类比 HTTP 对 Web 的意义）、共享记忆与状态管理（类比数据库对 Web 应用的意义）、中断与重规划机制的工程化（类比 Kubernetes Controller 的 reconcile 循环）。

对于正在落地的团队，务实的三步建议。第一步，先把单 Agent 做到极致——Prompt 优化、工具函数的错误处理、Token 预算管理——这些基础没做好，多 Agent 只会放大问题。第二步，在单个 Agent 复杂度超过 10 步操作链时引入编排 Agent，把任务分解和执行的职责分离。第三步，只在发现"不同 Agent 需要不同系统 Prompt/工具集/模型"时，才拆分出专门的 Worker Agent。多 Agent 是解决问题的工具，不是追求的目标——基础设施不需要漂亮话。