引言
在单体 Agent 时代，上下文工程的核心动作是压缩：如何把海量信息像塞行李箱一样，强行塞进一个有限的上下文窗口。
到了多 Agent 时代，问题发生了质变。我们不再面对一个窗口，而是面对一组物理隔离、逻辑关联的窗口集群。
多 Agent 架构的失败，往往不是因为 Agent 不够聪明，而是因为上下文在流动中“腐蚀” ：
- 隔离过度：Agent 之间像断了网的电脑，陷入“盲人摸象”的困境，输出互相打架。
- 共享过度：上下文在全量复制中撑爆了预算，KV-Cache 全面失效，成本指数级爆炸。
- 继承过度：历史信息在串行链路中无限膨胀，信号被噪声淹没，最终导致系统“失忆”或“精神分裂”。
从上下文工程视角看，多 Agent 协作的本质，就是设计一套信息拓扑协议。
这套协议的核心，是回答三个关于“信息流动”的核心问题：
- 权限界定：谁拥有“写权限”？谁能修改全局状态？谁只能拥有“读权限”？
- 变更通知：当状态变更时，是“事件通知”（轻量）还是“全量复制”（重量）？
- 一致性粒度：为了节省成本，我们愿意接受多大程度的信息延迟和损失？
Cognition 等团队的实践表明：多数团队应该避免多 Agent。但当业务场景确实需要时，理解这四种信息流动的基本形态，是构建稳健系统的前提。
一、 四种常见的交互模式
Cognition 在技术博客中列举了 Agent 处理复杂任务的四种典型编排流程，这构成了我们讨论的“现象层”基础。
1.1 并行执行，无上下文共享
主任务拆分为多个子任务，分别由不同的 SubAgent 独立执行，彼此之间没有共享上下文信息，也没有交互。 特征：像拼图游戏，每块都找不同人拼，但没人知道最终图长啥样。优势是极致的经济和并行效率，劣势是缺乏补救机制，整合风险极高。
1.2 并行执行，有上下文共享
子任务执行前都能访问一个共享上下文，但执行仍是独立完成。 特征：像后厨团队看了同一份菜单，但切配和炒菜之间没交流。优势是任务理解统一，劣势是输出仍可能冲突，且复制成本高昂。
1.3 串行执行，逐步构建上下文
任务由多个 SubAgent 串行完成，前一个 Agent 的输出成为后一个 Agent 的输入。 特征：像接力跑，交接棒时信息传递清晰，但跑道（上下文）越来越拥挤，容易溢出。
1.4 串行执行，引入压缩模型
在流程中加入专门的“上下文压缩模型”，将历史压缩为关键细节。 特征：像企业里的“层级汇报”，信息被层层提炼。优势是突破窗口限制，劣势是一旦提炼失真，决策就会走样。
二、上下文流动的四种策略
透过现象看本质，上述四种模式实际上是上下文在多 Agent 间流动的四种不同工程策略。
2.1 策略一：上下文隔离
对应模式：并行执行，无上下文共享
这是最“经济”的上下文策略。每个 SubAgent 被设计为一个无状态的纯函数。
工程特征
- 输入极简：SubAgent 仅接收一条指令，无历史继承，无背景噪音。
- 缓存友好：System Prompt 和输入高度稳定且短小，KV-Cache 命中率极高，推理成本最低。
- 信息熵最高：输入中的每一个 Token 都是指令本身，没有冗余。
核心风险：上下文孤岛
上下文是 Agent 认知的唯一来源。当上下文被物理隔离时，Agent 的决策只能依赖那条单薄的指令。如果任务之间存在隐含的依赖关系（例如风格一致性、接口对齐），Agent 就会因为“看不见”而犯错。
工程判决： 默认策略。只有当任务满足 “信息无依赖” 特征时才使用。
- 判定标准：如果任务 A 的结果不会改变任务 B 的执行逻辑，则适用。
2.2 策略二：上下文共享
对应模式：并行执行，有上下文共享
这是为了解决“孤岛问题”最直觉的策略，也是成本陷阱最深的地方。
工程特征
- 全量预填充：在 SubAgent 启动前，将主 Agent 的完整上下文复制一份，强行写入 SubAgent 的窗口。
- 制造“平行宇宙” ：所有 SubAgent 都拥有了相同的上帝视角。
致命伤：KV-Cache 的全面崩塌
KV-Cache 的核心机制依赖于前缀稳定。
- SubAgent 的 System Prompt 发生了变化（角色变了）。
- 注入的共享上下文是动态生成的（每次内容都不同）。
这导致 SubAgent 的每一次调用，前缀都是全新的。 结果：缓存完全失效，每一次调用都是昂贵的“冷启动” 。在 Manus 的实践中，这种模式会导致 Token 成本呈指数级上升。
工程判决： 慎用。只有在 “背景一致性价值 > 复制成本” 时才使用。
- 适用场景：所有 SubAgent 必须严格对齐同一个“宪法”（如 PRD、法规）。
- 避坑：严禁共享“实时变化的状态”，只共享“相对稳定的背景知识”。
2.3 策略三：上下文继承
对应模式：串行执行，逐步构建上下文
这是把上下文视为 “账本” 的策略。前一个 Agent 的输出，直接追加到后一个 Agent 的上下文中，形成一种时间线上的单向传递。
工程特征
- 线性熵增：随着 Agent 链条的延伸，上下文长度线性增长，同时信息熵（混乱度）也在增加。
- 被动背负：后继 Agent 被迫接受前驱 Agent 的所有历史，无法“拒绝”其中的噪声或错误。
核心风险：上下文腐败
这是长链路 Agent 最棘手的问题。就像传声筒游戏，信息在传递中必然发生变异：
- 噪声放大：早期 Agent 的一次试错、一句闲聊，都会被永久记录并传递下去，干扰后续决策。
- 注意力漂移：模型容易被上下文中大量的“中间过程”带偏，忘记了最初的“顶层指令”。研究表明，当上下文过长时，模型对关键信息的注意力会显著下降，出现“迷失在中间”现象。
- 窗口溢出：一旦超过 Token 限制，系统被迫截断，可能导致最早期的关键设定（如角色定义、核心约束）被丢弃。
工程判决： 限制使用。仅适用于链路短（< 5步）、且每一步输出都是下一步必要输入的场景。
- 关键对策：必须严格控制“继承的内容”，只传递“决策结果”，不传递“思考过程”。
2.4 策略四：上下文压缩
对应模式：串行执行，引入压缩模型
这是解决“继承陷阱”的高级策略。不再保留全量历史，而是通过压缩模型，将历史提炼为“精华”。
工程特征
- 有损压缩：把海量 Token 压缩为“关键决策点”、“约束条件”、“当前状态”。
- 信息提纯：试图剔除噪音，只保留对后续决策有价值的信息。
核心难点：业务判决瓶颈
这是上下文工程中的 “智能瓶颈” 。压缩本质上是一次信息判决：哪些该留，哪些该扔？
- 扔错了：后续 Agent 丢失关键约束，导致幻觉或决策失误。
- 扔少了：压缩比不够，依然面临膨胀问题。
这已经超出了 Prompt 技巧的范畴，接近“业务知识工程” 。正如 Cognition 团队所强调的，这需要投入大量精力去定义“什么是关键信息”，甚至需要专门微调模型来做这件事。
工程判决： 高阶使用。适用于长周期、多步骤的复杂任务。
- 关键动作：必须建立 “信息保留标准” （如：只保留决策结果，不保留决策过程；只保留错误教训，不保留错误日志）。
三、 决策框架：路径选择逻辑
多 Agent 上下文工程的难点不在于“知道这四种策略”，而在于如何在该用的时候用对，在不该用的时候忍住。
我们可以遵循以下决策逻辑：
核心原则总结：
| 策略 | 核心权衡 | 适用信号 | 工程红线 |
|---|---|---|---|
| 隔离 | 用“孤岛”换“性能” | 任务间零依赖 | 存在隐式协同需求时禁用 |
| 共享 | 用“成本”换“对齐” | 必须全员看同一份文档 | 实时状态共享时禁用 |
| 继承 | 用“风险”换“连贯” | 短链路、强因果依赖 | 长链路无压缩时禁用 |
| 压缩 | 用“细节”换“空间” | 超长任务、终身学习 | 缺乏业务知识定义时禁用 |
结语
多 Agent 架构的落地，本质上是在设计上下文的流动协议。
我们要做的，不是让 Agent 变得多聪明，而是要让信息在多个窗口间流动时，保持精准、低成本且不失真。
这才是多Agent上下文工程的实质——在有限的窗口与算力约束下，寻求系统整体效用的最优解。
