多智能体系统由多个协作的智能体组成,每个智能体专注于特定能力或任务。
上下文膨胀:如果每个智能体都接收完整上下文,Token 消耗会快速增长
信息干扰:无关智能体的信息可能干扰当前智能体的判断
1. 共享黑板模式 (Shared Blackboard)
引入一个共享记忆库或"黑板",所有智能体都可以读取和写入这个公共空间。
工作方式:智能体 A 将发现的证据写入黑板,智能体 B 读取并推理。
2. 通信对话模式 (Message Passing)
智能体之间直接发送消息交换上下文。
工作方式:智能体 A 发送消息给智能体 B:"请根据这些数据生成图表"。
9.3.4 高级协作模式:Chain-of-Agents
Google 提出的 Chain-of-Agents (CoA) 框架专门解决长上下文协作问题,通过让多个智能体 "接力"阅读和处理。
这种模式让上下文在智能体链中逐步传递和累积,而非一次性填满单个智能体的窗口,有效突破了单模型上下文限制。
只传递智能体完成任务所需的最小信息:
角色专属记忆 (Intrinsic Memory)
为每个智能体维护结构化的角色专属记忆。
视角隔离:智能体 A 看到的上下文强调数据分析视角,智能体 B 强调代码实现视角。
定义清晰的信息传递接口:
多智能体需要共享的状态:
多智能体系统交互复杂,需要完善的追踪机制:
1. 消息日志
记录所有智能体间的通信。每一个消息的发送者、接收者、时间戳、内容类型和Payload都应被完整记录。这不仅用于排查错误,也是分析智能体协作模式和效率的重要数据源。
2. 上下文快照
关键节点的上下文状态。在任务的关键转折点(如子任务完成、决策变更时),保存各个智能体的上下文快照。这允许开发者"时光倒流",查看系统在特定时刻的全局状态,复现 Bug。
3. 决策追踪
每个智能体的决策依据。智能体为什么采取这个行动?是基于哪条上下文信息?使用了哪个 Prompt?记录 ReAct 循环中的 "Thought" 过程,使智能体的行为透明可解释。
4. 性能指标
上下文大小、传递延迟。监控上下文在传递过程中的膨胀情况,以及智能体之间的通信延迟。通过可视化图表识别瓶颈:是某个智能体处理太慢,还是上下文过大导致传输耗时?
现代多智能体开发通常基于成熟的框架:
选择建议:
9.3.9 子智能体架构与上下文隔离
子智能体架构不仅是任务分解工具,更是上下文管理策略。
问题:单一智能体执行复杂任务时,上下文会被多个子任务的细节污染,导致:
解决方案:将独立子任务委派给专用子智能体,每个子智能体有自己的上下文窗口。
关键洞察:主智能体只接收子任务的摘要结果,而非全部细节。
Anthropic 多智能体研究系统案例
Anthropic 构建的多智能体研究系统展示了这一架构的实际应用:
系统组成:
主智能体(Lead):规划研究方向、综合结果、撰写最终报告
上下文隔离效果:
搜索智能体处理数百个搜索结果 → 只返回 10 个最相关的
阅读智能体处理 100 页 PDF → 只返回 3 段关键内容
数据对比:
重要提示:子智能体增加了系统复杂度和延迟。只在上下文污染成为问题时使用,避免过度设计。