多Agent协作中上下文交接的Token优化策略探讨

背景

在多智能体（Multi-Agent）协作架构中，主智能体（Main Agent）与子智能体（Sub-agent/Worker）之间的上下文交接是一个普遍存在的痛点。用户在实际部署中发现，虽然将任务拆分给子智能体旨在保持上下文的“洁净度”和模块化，但在交接过程中，主智能体读取并重新传输给子智能体的上下文导致了 Token 消耗翻倍。这种冗余不仅增加了成本，还使得整体运行效率低于简单的顺序任务执行。用户当前的尝试包括任务规划优化、主智能体仅负责调度、引入 CodeGraph 等技术手段，但仍未解决 Token 消耗过快的问题，因此寻求更优的上下文交接策略及开源参考方案。

核心内容

该讨论聚焦于多智能体系统中主智能体与子智能体之间上下文传递的效率与正确模式。核心矛盾在于：上下文隔离带来的洁净性优势与重复读取导致的 Token 冗余成本之间的平衡。

用户描述了其现有的工作流架构：

1. 任务规划策略：尽可能将具有上下文相关性的任务分配给同一个 Agent Worker，以减少跨 Agent 的上下文切换。
2. 主智能体角色：主智能体仅负责派发任务、监控进度和管理任务列表，避免深度解析任务相关的详细上下文。
3. 子智能体角色：负责具体的代码开发以及修复由 Review Agent 提出的问题。
4. 结果审查机制：Review Agent 的结果由主智能体进行中转和处理。
5. 技术增强：引入了 CodeGraph（代码图谱）供子智能体 Worker 使用，以辅助理解代码结构。

尽管采取了上述优化措施，用户反馈 Token 的消费速度依然很快，甚至超过了顺序执行任务的速度。这反映出即使减少了主智能体的深度解析，上下文在“主 -> 子”的传递过程中依然存在显著的冗余。用户希望找到一种“正确姿势”，既能保持子智能体上下文的独立性，又能最小化交接过程中的 Token 浪费，并询问是否有相关的开源方案可供参考。

关键要点

• 上下文交接的 Token 冗余问题：主智能体读取上下文后再次发送给子智能体，导致相同信息被处理两次，造成 Token 消耗翻倍。
• 任务聚合策略：通过将相关性强的任务打包分配给同一个 Agent Worker，试图减少上下文切换和重复传输。
• 主智能体的轻量化角色：主智能体退化为调度器，仅负责任务分发和进度管理，不进行深度的上下文解析。
• 子智能体的专注职责：子智能体（Worker）专注于代码开发和修复 Review 反馈的问题。
• 引入 CodeGraph：利用代码图谱技术辅助子智能体理解代码结构，可能旨在减少对冗长代码上下文的直接依赖。
• 效率瓶颈：当前的多智能体并行或调度模式在 Token 消耗上表现不佳，甚至劣于简单的顺序执行。
• 缺乏标准范式：目前尚无公认的“正确姿势”来解决这一效率问题，社区正在寻求开源方案和最佳实践。

意义与影响

这一讨论揭示了当前多智能体系统落地过程中的关键挑战：可扩展性与成本效率的矛盾。

1. 架构设计的必要性：传统的“主从”模式如果简单地进行上下文广播，将导致严重的资源浪费。未来的多智能体架构需要更精细的上下文管理机制，例如只传递必要的摘要、指针或结构化数据，而非完整的原始上下文。
2. 工具增强的价值：引入 CodeGraph 等外部知识表示工具，是减少 LLM 上下文窗口压力的有效方向。这表明，将“记忆”和“结构”从 Prompt 中剥离，转而通过工具调用获取，是降低 Token 成本的关键路径。
3. 开源生态的需求：目前缺乏成熟的开源解决方案，说明该领域仍处于探索阶段。社区对于高效的多智能体通信协议、上下文压缩算法以及智能体间状态共享机制有迫切需求。
4. 性能评估标准的转变：在多智能体系统中，评估指标不应仅关注任务完成率，还需将 Token 效率、延迟和上下文管理开销纳入核心考量。顺序执行在某些场景下可能比复杂的智能体协作更具成本优势，除非协作能带来质的飞跃。