个人知识库

多Agent架构

8分钟阅读

多Agent架构

将复杂任务分解给多个 Agent 协同完成的架构模式，核心挑战是如何正确拆分以避免上下文同步开销超过并行收益

简介

多Agent架构是将单一 Agent 难以处理的复杂任务拆解为多个独立 Agent 协同完成的系统设计模式。表面上看，这种”分而治之”的思路符合直觉，但在实际工程实践中，多 Agent 架构的最大挑战不是如何分工，而是如何避免 Agent 间的上下文同步开销超过并行带来的收益。

关键信息

  • 类型：架构模式 / 设计模式
  • 领域：AI Agent 开发 / 分布式系统
  • 核心挑战：上下文隔离性判断
  • 常见反模式：按人类组织结构拆分
  • 正确原则：以上下文为中心拆分
  • 相关概念：AI Agent 智能体、上下文工程、分布式单体

核心特性

最大误区：按人类组织结构拆分

这是多 Agent 架构最常见的反模式。许多团队看到”多 Agent 是趋势”的文章后，直接按人类分工方式设计系统：

  • 规划 Agent：负责任务分解
  • 编码 Agent：负责写代码
  • 测试 Agent：负责写测试
  • 审查 Agent：负责 Code Review

这看起来很专业，但 Anthropic 工程博客的研究揭示了致命问题：写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案。结果是 Agent 之间反复解释背景、同步上下文，消耗的 Token 甚至超过真正干活的 Token。

正确拆分原则：以上下文为中心

多 Agent 的正确拆分方式不是模仿人类组织，而是以上下文为中心进行判断：

拆分决策树：

两个任务的上下文是否可真正隔离？
├─ 是 → 可以拆分为独立 Agent
│   └─ 每个 Agent 维护独立的状态和知识
└─ 否 → 保持单 Agent
    └─ 通过 Workflow 管理内部流程

可拆分的典型场景：

  • 并行处理多个独立数据源（如多个 KOL 内容同时分析）
  • 职责边界清晰且输入输出标准化（如数据准备 → 分类 → 对账管道）
  • 长期独立运行的子系统（如监控 Agent + 执行 Agent）

不应拆分的典型场景：

  • 需要共享大量决策历史（如”为什么选择这个方案”）
  • 频繁的双向沟通（如反复确认需求）
  • 上下文高度耦合（如前一步的输出深度影响后一步的策略）

多 Agent 的成本陷阱

上下文同步税：当 Agent A 的决策需要 Agent B 理解时，必须付出以下成本：

  1. 显性传递成本：将 A 的思考过程序列化为 B 可理解的格式
  2. 理解成本：B 需要消耗 Token 理解 A 的背景
  3. 往返成本：如果 B 理解错误，还需要多轮澄清
  4. 遗忘成本：如果链路太长，早期 Agent 的关键上下文会被后续 Agent 遗忘

Anthropic 的实测数据显示：在某些场景下，上下文同步消耗的 Token 超过真正干活的 Token——这意味着多 Agent 不仅没有提升效率，反而降低了性能。

分布式单体反模式

当你按组织结构拆分 Agent，但它们的上下文实际上高度耦合时，你得到的不是分布式系统，而是分布式单体（Distributed Monolith）：

  • 表面上是多个独立 Agent
  • 实际上任何一个 Agent 都无法独立工作
  • 修改一个 Agent 的逻辑需要同步修改其他 Agent
  • 调试时需要追踪整条 Agent 链路

这是微服务架构中的经典反模式，在多 Agent 系统中同样适用。

不同素材中的观点

来自 2026-06-17-ai-agent-工程完全指南：

  • 反模式识别：作者通过踩坑发现，按人类组织结构拆分（规划 Agent、编码 Agent、测试 Agent、审查 Agent）是最低效方式。Anthropic 研究明确指出：Agent 间反复解释背景消耗的 Token 甚至超过真正干活的 Token
  • 正确原则：以上下文为中心拆分——只有当两个任务的上下文可真正隔离时，拆分才有意义；否则就是造分布式单体
  • 工程背景：这一观点来自作者半年研究 Anthropic、OpenAI、LangChain 等团队的工程复盘，是大厂实际踩坑后的经验总结
  • 实践建议：默认使用单 Agent + Workflow 管理流程，只有在上下文确认可隔离时才考虑多 Agent

实用信息

多 Agent 拆分检查清单

在决定是否使用多 Agent 架构前，回答以下问题：

  • Agent B 是否需要知道 Agent A “为什么”做这个决策？
  • Agent B 的输出是否会影响 Agent A 需要重新审视之前的决策？
  • 如果 Agent A 失败，Agent B 是否能独立继续工作？
  • 两个 Agent 之间的数据传递是否可以完全标准化？
  • 调试时是否需要追踪整条 Agent 链路才能定位问题？

如果有 3 个以上回答”是”（前 4 题）或”否”（第 5 题），考虑单 Agent 方案。

合适的多 Agent 场景

顺序管道模式（来自 2026-06-03-claude-code-multi-agent-accounting）：

数据准备 → 分类 → 对账 → 报告 → 洞察

每个 Agent 职责清晰，输入输出标准化，通过共享文件夹流转数据。

并行处理模式（来自 2026-05-27-ai-ecommerce-kol-guide）：

用户请求 → Agent 路由 → 多个 KOL Agent 并行分析 → 结果聚合

每个 KOL Agent 维护独立的测评库和风格配置，上下文完全隔离。

从单 Agent 迁移到多 Agent 的信号

  • 单 Agent 的上下文窗口经常被挤爆
  • 任务明确分为多个可完全独立的子领域
  • 需要并行处理大量独立数据源
  • 不同子任务使用完全不同的工具集

关键原则：先证明单 Agent 确实无法胜任，再考虑多 Agent。

相关资源

相关页面

关系图谱

快速导航

反向链接