在单 Agent 的世界里，上下文管理相对直观，对话历史、系统提示词和工具调用记录都在同一个推理过程内流动，Token 窗口是主要约束，工程师们已经有了一套相对成熟的应对手段；当我们把多个专门化的 Agent 编排成一个协作系统时，情形就完全不同了，上下文管理的复杂度不是随 Agent 数量线性增长的，而是沿着 Agent 数量与交互频率双重维度同时扩张，每多一个 Agent，就多了若干条需要维护的上下文通道，每一条通道都面临安全隔离、状态一致性、传输效率三个方向的设计压力。

我们把这个问题称为多 Agent 协作中的上下文共享难题，而这个难题的困难之处，根本上来自三个相互缠绕的矛盾。围绕信息的可见性与隔离性，某个 Agent 需要看到足够多的上下文才能做出正确决策，同时又不应该访问它职责范围之外的信息；围绕完整性与效率，把全量上下文传给每个 Agent 会造成 Token 浪费和推理延迟，截断上下文又会导致 Agent 在关键节点做出错误判断；还有实时性与一致性之间的矛盾，多个 Agent 并发运行时，它们各自持有的上下文快照很快会失去同步，而强制同步又会引入严重的协调开销。

现有技术路线的局限

API 点对点调用是最容易想到的起点，让一个 Agent 在需要时向另一个 Agent 发起请求，显式地传递必要的上下文字段；这种方式的优点在于职责边界清晰，每个 Agent 只拿到它需要的部分，数据流向完全可追溯；但其代价同样明显，随着 Agent 数量增加，点对点调用形成的依赖图会迅速变得难以管理，调用链条上的任何一个节点失败都可能导致整个流程中断；更重要的是，这种方案需要每个 Agent 的开发者提前约定接口格式和上下文的数据结构，而在一个长周期的业务流程中，上下文的形态往往在运行过程中动态演化，提前约定几乎不可能覆盖全部情况。

共享内存或共享数据库是另一条常见路径，所有 Agent 都读写同一个状态存储，通过键值对或结构化文档的方式交换信息；这个方案解决了接口耦合的问题，任何 Agent 都可以随时写入和读取它感兴趣的字段，不需要显式的点对点依赖；但它把上下文共享问题从接口协议变成了状态管理，并发写入的冲突处理、版本控制、读写锁的粒度设计，这些问题在分布式环境下都变得异常复杂；共享数据库方案在权限控制上也缺乏精度，想要做到某个 Agent 只能读写某些字段而非全部这样的细粒度隔离，需要在应用层构建大量额外的访问控制逻辑，维护成本很高。

消息队列和消息总线方案在前两者之间取了一个折衷，Agent 之间通过发布订阅模式异步交换消息，上下文以消息的形式在总线上流动，接收方按需订阅自己关心的主题；这种方案在解耦和扩展性上表现良好，适合事件驱动型的工作流；但它有一个固有的弱点，消息在总线上是无结构的扁平序列，缺乏层次关系和语义索引，当一个 Agent 需要检索过去某轮任务中某类型的所有决策记录时，从消息流里重建这样的查询结果既慢又容易出错；另外，消息队列方案通常不适合需要频繁双向交互的协作场景，因为它的异步特性天然就和等待另一个 Agent 实时反馈这种需求存在摩擦。

从上面这三种方案来看，它们分别解决了接口清晰、解耦广播、异步流动的问题，但共同缺少的是一种对 AI 协作上下文的原生理解，它们都把上下文当作普通的数据来处理，而多 Agent 协作中的上下文有几个普通数据没有的特性，工程师在设计平台层时需要显式地去应对。

上下文在多 Agent 场景中的特殊性

多 Agent 协作的上下文带有强烈的时序语义，在一个工作流中，谁在什么时间做了什么决定、基于什么信息，这类元数据对后续 Agent 的推理至关重要；一个做计划的 Agent 和一个执行计划的 Agent 需要共享的不只是任务描述，还包括计划生成时的推理过程和约束条件；如果这些信息在传递时被剥离，执行 Agent 就会在遇到边界情况时因为缺少背景知识而做出次优决策，这种信息损耗在短任务中不明显，在多轮长流程中却会不断累积。

与时序语义并列的是上下文的层次结构，协作任务通常有嵌套的逻辑层级，一个顶层目标可以分解成若干子任务，每个子任务又有自己的上下文；好的平台设计应该能够让 Agent 在需要时向上查阅父级上下文，也能向下注入子任务级别的约束，而不需要每个层级都把全部上下文复制一份，这既是存储效率的要求，也是认知结构的映射，因为人类在协作时本来就是按层级管理信息的。

此外，在多 Agent 系统中，谁说了什么和谁有权看到什么是两个必须同时处理的问题，我们把这称为上下文的身份绑定；一个负责处理用户个人数据的 Agent，不应该把敏感字段透传给一个只需要统计摘要的分析 Agent；身份绑定机制应该在平台层内置，而不是每个 Agent 开发者自己实现的安全补丁，否则整个系统的权限边界就完全取决于最薄弱的那个 Agent 实现。

上下文压缩与摘要的工程实践

上下文共享还面临一个绕不开的约束，Token 数量和推理延迟的限制使得把一个复杂工作流的全量上下文传递给每个 Agent 这种做法根本行不通，因此上下文压缩和摘要服务是多 Agent 平台不可回避的组成部分。

上下文压缩的难点在于，通用的文本压缩算法不懂任务语义，它无法判断哪些信息对下一个 Agent 的决策是必要的；我们需要的是语义感知的摘要机制，它能根据后续 Agent 的职责描述，从全量上下文中抽取与之相关的部分，同时保留时序关系和决策链条；LLM 驱动的摘要服务在这里有天然的优势，但它也有自己的成本，每次调用都会引入额外的 Token 消耗和延迟，设计者需要在按需生成摘要和预计算缓存摘要之间做出权衡。

增量上下文更新是另一个值得关注的设计点，当一个 Agent 完成一步工作时，它对共享上下文的写入应该是增量式的而非全量覆盖的；增量更新天然携带版本信息，其他 Agent 可以订阅特定字段的变更通知，而不需要轮询整个状态；在实现层面，类似 CRDT（无冲突可复制数据类型）的数据结构在部分上下文场景下是有价值的，它允许多个 Agent 并发修改同一份状态而不产生写冲突，背后的设计思路是把冲突从同步点分散到数据结构层面处理，这在多 Agent 并发写入场景里值得参考。

上下文的生命周期管理同样构成一个值得深入讨论的设计维度，合理的设计是为上下文建立分层存储，热上下文（近期几轮交互的状态）保留在内存或快速缓存中，温上下文（完成的子任务记录）压缩后存入结构化存储，冷上下文（归档的历史工作流）以更低成本的形式长期保存；检索时按需按层拉取，而不是一次性加载全部历史。

平台层需要承担什么

从上面这些分析出发，我们可以描述出一个支持多 Agent 协作的平台层需要具备哪些能力。

在上下文路由方面，平台需要知道每个 Agent 的职责范围，并根据这个范围自动决定哪些上下文字段应该传递给它、哪些应该屏蔽；这种路由能力不应该是静态配置的，而应该能随着工作流的进展动态调整，比如当一个子任务完成后，相关 Agent 应该自动从对应的上下文通道退出，而不需要手动清理订阅关系。

在身份和权限方面，Agent 在平台里应该有明确的身份表示，它能访问哪些上下文、能向哪些通道写入、能调用哪些其他 Agent，这些权限应该在平台层统一管理，而不是由各个 Agent 自己声明；这既减少了单个 Agent 的实现复杂度，也为整个系统提供了一个可审计的权限边界。

在会话结构方面，多 Agent 协作需要的不只是一个扁平的消息流，而是一个能够反映任务层级的结构化空间；对话线程、子任务分支、工作组边界，这些概念都应该在平台层有对应的数据模型，而 Agent 在其中的行为和上下文访问权限也应该随着它所在的层级而变化。

在可观测性方面，工程师需要能够追踪任意一条上下文的完整流转路径，从它被哪个 Agent 写入，到它被哪些 Agent 读取，再到它最终影响了什么决策；没有这种可观测性，多 Agent 系统的调试和优化就几乎无从下手，而这恰恰是目前大多数 Agent 框架最薄弱的环节之一。

Octo 的探索方向

我们在开发 Octo 这款开源 AI 原生团队协作平台（Apache 2.0 协议）时，也在持续思考上述问题；Octo 的设计出发点之一，就是把 IM 层作为多 Agent 协作的分发层，AI Agent 直接加入频道，与人类队友在同一个界面里参与讨论、领取任务、交付工作；IM 天然带有层次结构（Spaces → Categories → Channels → Threads），这为上下文的组织提供了现成的框架，不同粒度的协作发生在不同层级，上下文的边界和可见范围因此有了自然的映射。

Octo 的相关代码和文档已在 GitHub 开源，感兴趣的开发者可以访问 github.com/Mininglamp-OSS 查看组织下的多个仓库，欢迎⭐、Issue、PR~