我的七个 AI Agent 从不互相通信：为什么 Agent 间协作可能是过度设计
一位开发者在 Dev.to 上分享了一个反直觉的经验：他运行着七个处理同一领域的 AI Agent，但它们从来没有互相发送过一条消息。这与最初的计划完全不同——最初的计划是构建一个协调器，在专家 Agent 之间分配工作，让 Agent 互相调用、共享上下文、协同决策。但实际运行证明，Agent 间的直接通信可能是一种过度设计。
最初的计划：多 Agent 协作系统
和很多人一样，作者最初构建 AI Agent 系统时，设想的是一个复杂的多 Agent 协作架构：
- 协调器 Agent：负责任务分配和进度跟踪
- 专家 Agent：每个 Agent 专注于一个特定领域（如代码审查、测试编写、文档生成等）
- 通信机制：Agent 之间通过消息传递共享信息和请求帮助
- 共享内存：所有 Agent 共享一个公共的知识存储
- 工作流编排：复杂任务被分解为多个子任务，由不同 Agent 协作完成
这是目前很多 AI Agent 框架和教程中推荐的架构。听起来很合理：就像人类团队一样，不同专长的 Agent 协作完成复杂任务。
实际运行：Agent 从不通信
但在实际运行了一段时间后，作者发现了一个有趣的现象：他的七个 Agent 从来没有互相发送过消息。
原因不是通信机制有问题，而是没有必要。每个 Agent 都能够独立完成自己的任务，不需要其他 Agent 的帮助。当一个 Agent 遇到自己无法处理的问题时，它不是请求其他 Agent 的帮助，而是：
- 将问题升级给人类用户
- 使用预设的工具和 API 解决
- 跳过该问题并继续处理其他任务
- 将问题记录到日志中，供后续分析
为什么 Agent 间通信可能是过度设计
作者总结了 Agent 间直接通信往往不必要的几个原因：
1. 大模型已经是通才
现代大语言模型（如 GPT-4、Claude、Llama 3 等）本身就是通才，能够处理各种类型的任务。将任务拆分为多个专家 Agent 并让它们协作，往往不如直接让一个通才模型处理整个任务高效。
每个专家 Agent 都需要加载自己的上下文和系统提示词，这增加了延迟和成本。而一个通才模型可以在同一个上下文中处理多个子任务，避免了上下文切换的开销。
2. 通信增加了复杂性和故障点
Agent 间通信引入了大量复杂性：
- 消息格式和协议的设计
- 消息队列和传递机制
- 超时和重试策略
- 错误处理和恢复
- 消息顺序和一致性
- 死锁和活锁的避免
每一个环节都可能出问题。而一个不通信的系统，故障点大大减少，更加可靠和易于调试。
3. 共享上下文比消息传递更高效
当 Agent 需要共享信息时，共享上下文（如共享数据库、共享文件系统、共享向量数据库）往往比消息传递更高效：
- 不需要设计复杂的通信协议
- 信息可以被多个 Agent 同时访问
- 信息的更新和同步更加简单
- 不需要处理消息丢失和重复的问题
作者的七个 Agent 虽然不直接通信，但它们通过共享的数据库和文件系统间接共享信息。这种方式更加简单和可靠。
4. 人类在回路中比 Agent 协作更有效
当遇到真正复杂的问题时，让人类参与决策往往比让多个 Agent 互相讨论更有效：
- 人类能够提供 Agent 无法获得的领域知识和业务上下文
- 人类能够做出 Agent 无法做出的价值判断和权衡
- 人类能够发现 Agent 无法发现的隐含问题和风险
- 人类的决策往往比多个 Agent 的"讨论"更加高效和准确
作者的系统设计中，复杂问题总是升级给人类，而不是在 Agent 之间传递。
5. 简单性是可靠性的基础
简单的系统比复杂的系统更加可靠。一个不通信的 Agent 系统：
- 更容易理解和维护
- 更容易测试和调试
- 更容易扩展（添加新 Agent 不需要考虑与现有 Agent 的交互）
- 更少的意外行为和边缘情况
什么时候 Agent 间通信是有价值的
虽然作者的经验表明 Agent 间通信往往是过度设计，但他也承认在某些场景下 Agent 间通信是有价值的：
1. 真正需要专业知识的场景
当任务确实需要多个领域的深度专业知识，而单个模型无法同时掌握所有领域时，多 Agent 协作可能有价值。例如：
- 法律合同审查需要法律专家和领域专家的协作
- 医疗诊断需要多个专科医生的协作
- 复杂系统设计需要架构师、安全专家、性能专家的协作
但即使在这些场景下，也可以通过让单个 Agent 调用不同的专业工具或 API 来实现，而不一定需要 Agent 间直接通信。
2. 并行处理大量独立任务
当有大量独立的任务需要并行处理时，多个 Agent 并行工作可以显著提高吞吐量。但这种场景下，Agent 之间也不需要通信——它们只是并行处理独立的任务，最后由一个聚合器收集结果。
3. 长流程的流水线处理
当任务是一个长流程，每个步骤需要不同的处理时，流水线式的 Agent 架构可能有价值。例如：
- 代码审查流程：静态分析 Agent → 安全检查 Agent → 风格检查 Agent → 人工审查
- 内容生成流程：研究 Agent → 大纲 Agent → 写作 Agent → 编辑 Agent → 校对 Agent
但即使在流水线场景下，也可以通过共享的任务队列和状态存储来实现，而不需要 Agent 间直接通信。
实用建议
基于作者的经验，对于构建 AI Agent 系统的开发者，他给出以下建议：
- 从简单开始：先构建一个不通信的单 Agent 系统，验证核心价值。只有在确实需要时才引入多 Agent 协作。
- 优先使用共享存储：当需要共享信息时，优先使用共享数据库、文件系统、向量数据库等，而不是设计复杂的 Agent 间通信协议。
- 人类在回路中：对于复杂决策，优先考虑让人类参与，而不是让多个 Agent 互相讨论。
- 避免过度抽象：不要为了"架构优雅"而引入不必要的复杂性。简单、直接的解决方案往往更好。
- 监控和度量：仔细监控系统的运行，度量每个组件的实际价值。如果某个组件（如 Agent 间通信）没有被使用或没有带来价值，就移除它。
总结
"我的七个 AI Agent 从不互相通信"这个反直觉的经验提醒我们：在 AI Agent 系统设计中，简单性和实用性比架构的"优雅"更加重要。
多 Agent 协作是一个吸引人的概念，很多框架和教程都在推广它。但在实际应用中，很多场景并不需要 Agent 间的直接通信。一个简单的、不通信的、通过共享存储间接协作的系统，往往比一个复杂的、消息驱动的多 Agent 系统更加可靠、高效和易于维护。
这并不是说多 Agent 协作没有价值，而是说它应该是在确实需要时才引入的工具，而不是默认的架构选择。在构建 AI Agent 系统时，我们应该始终问自己：这个复杂性真的有必要吗？
原文链接：https://dev.to/salparvez/my-ai-agents-dont-talk-to-each-other-166e