多 agent 协作里的上下文断裂问题

最近我在认真做一件事：让多个 AI agent 协作完成工作。过程中遇到的最核心的问题，不是模型能力，而是上下文断裂。这篇文章把这个问题拆开讲清楚。

什么是上下文断裂

假设你把一个任务分给三个 agent，一个负责调研，一个负责写代码，一个负责审核。理想情况下，三个 agent 共享全部上下文，互相知道对方在干什么。

实际情况是：每个 agent 的上下文窗口是独立的。负责写代码的 agent 不知道调研 agent 找到了什么，负责审核的 agent 看不到写代码的 agent 做了哪些取舍。信息要传递，只能靠显式的交接，而交接必然有损耗。

这就是上下文断裂。它不是 bug，而是多 agent 架构的结构性问题：上下文窗口是有限的，多 agent 就是要把一个长任务切成多个短任务，切的过程就是断裂的过程。

我把它分成三个层次看：

第一层：任务交接断裂。 A 做完调研，把结论交给 B。B 拿到的是一份总结，不是原始材料。总结就是压缩，压缩就会丢信息。这一层最明显，也最好解决，做好交接文档规范就行。

第二层：隐性上下文断裂。 有些上下文是没写在交接文档里的，比如为什么当初选了这个方案、哪个方向试过失败了、团队默认的代码风格是什么。这些隐性知识，在单人工作流里靠记忆，在多 agent 里直接丢失。这一层很难解决，因为它根本没有显式载体。

第三层：状态同步断裂。 多个 agent 如果同时改同一个东西，状态就会冲突。写代码的 agent 改了一个函数，审核的 agent 还在看旧版本。这一层是工程问题，需要版本控制、锁、或者更聪明的编排策略。

针对这三层，我的应对策略：

第一层，用结构化的交接格式。调研结果、决策依据、未决问题，分门别类写清楚。宁可啰嗦，不要缺项。

第二层，把”为什么”写进交接。每个关键决策，附一句理由。刚开始觉得麻烦，后来发现这是最有价值的部分，因为只有理由能传递判断力，结论不能。

第三层，编排层统一调度。设计一个协调者，管理任务分发和状态汇总，避免多个 agent 并行写同一个文件。这个编排层现在是我花时间最多的地方。

接触这个问题的过程中，我越来越觉得，多 agent 的瓶颈不在模型，在编排。模型会越来越强，但上下文窗口的物理限制、多智能体之间的信息损耗，是结构性的，只能靠架构去缓解。

这也是我为什么对编排层这么感兴趣。未来的工作流大概率是这样的：一个协调者，多个专业 agent，清晰的交接协议，加上一个靠谱的记忆系统。谁先把这套架构做顺，谁就解决了真正的问题。