上下文传递与共享状态

用途：决定多 Agent 之间该传什么、状态放哪里

三种传递方式

方式	做法	优点	风险
消息传递	上游把结果文本塞进下游提示	简单	上下文膨胀、失真（摘要丢失关键约束）
文件/工件	上游产出结构化工件（代码、报告、JSON），下游按需读	可版本化、可审计、可并行	需要契约与所有权管理
共享状态存储	中央 KV/DB/黑板，各 Agent 读写	灵活、支持复杂协作	竞态、责任不清、难复现

默认选择：工件传递。 它天然可版本化、可复现，并且允许下游只读所需部分（避免上下文塞满）。

上下文预算原则

1. 传结论与约束，不传过程：把推理链全文转发是最常见的膨胀来源。
2. 传引用，不传数据：给出文件路径 + 片段定位（行号、锚点），让下游按需取。
3. 显式携带不变约束：任务边界、禁止事项、验收标准必须原样传递，不能被摘要吞掉（摘要丢约束是多 Agent 系统最隐蔽的失败）。
4. 分层摘要：长链路每层维护“给下游的最小必要上下文”模板，而不是无限累积。
5. 可回溯：摘要必须能追溯到原文工件，避免“以摘要为真”。

共享状态的所有权模型

若必须共享状态（进度表、决策记录、任务清单）：

规则	说明
单一写入者	每个字段/文件有唯一 owner Agent，其他只读
追加式日志	决策与事件用 append-only 记录，便于复现时间线
乐观并发	版本号/条件写，冲突时重读再改，禁止最后写入静默覆盖
快照点	关键阶段固定快照，便于回滚与调试
可见性分层	区分“全局事实”与“Agent 私有草稿”，避免私有假设污染公共状态

外部记忆的设计

长期任务需要跨会话记忆时：

• 结构化存储（任务清单、决策日志、事实库）优于对话历史重放。
• 检索要带来源与时间，避免旧事实与新事实混淆。
• 写入要有准入（不是所有中间想法都值得记），并支持失效与更正。

常见误区

误区	修正
把所有历史转发给每个 Agent	上下文成本与噪声同时上升，质量下降
摘要丢约束	约束字段单独原样传递，不参与摘要
多 Agent 写同一文件无协调	单一写入者或分区（各写各的文件/目录）
以对话上下文为权威状态	状态外置到工件与存储
私有草稿进公共状态	分层可见性
记忆只增不改	需要更正与失效机制

延伸阅读

• 本站：编排拓扑、任务分解粒度、冲突与 diff 归属
• 关于 LLM 长上下文与检索增强（RAG）的公开资料