上下文隔离与共享
多智能体系统最隐蔽的失败模式不在协作逻辑，而在记忆管理：该隔离的没隔离（互相污染），该共享的没共享（各干各的）。
隔离：默认姿态
子 Agent 默认应该拿到全新窗口（fresh context），这是多智能体的第一原则：
- 污染防护。主 Agent 的猜想、挫败感和半成品结论，对子 Agent 是偏见而非帮助。全新窗口让子 Agent 只对任务描述负责。
- 注意力保护。子 Agent 的工作记忆全部留给自己的子任务，不被无关历史稀释。
- 费用独立核算。子 Agent 的 token 消耗清晰可查，失败的探索可以整窗丢弃。
反向也要隔离：子 Agent 的过程不回流。几十万 token 的探索过程留在子窗口里，回传的只有结论。如果发现主 Agent 需要子 Agent 的某个细节，正确做法是再发一个定向的子任务去取，而不是把整个轨迹倒进来。
共享：三种介质
完全隔离的系统无法协作，信息必须通过某种介质共享：
1. 消息传递（窄管道）
派发时传任务描述、回收时传结构化结论——前一节的模式。优点是边界清晰、易审计；缺点是带宽有限，大块中间产物过不去。
2. 共享文件系统（宽平台）
主流 Coding Agent 的做法：所有 Agent 读写同一个文件树。
- 子 Agent 把产出写成文件（报告、补丁、测试结果），任务描述里给路径，主 Agent 按需读。
- 文件系统天然承担了“大块数据不进窗口”的外置存储职能——这正是 Context Engineering 的“环境外置”策略在多智能体下的延续。
3. 共享状态存储（结构化）
LangGraph 等框架提供的共享状态对象（blackboard 模式）：每个节点读取状态、更新自己负责的字段。适合流程式协作，但要注意字段所有权——两个 Agent 同时改一个字段就是竞态。
一致性：共享的代价
共享介质一宽，新问题就来了：
- 写冲突。两个 Worker 并行改同一个文件，后写的覆盖先写的。工程对策：一个文件一个写者——编排层在拆任务时保证写入域不重叠，冲突只发生在合并点。
- 脏读。A 基于文件 X 的版本 v1 展开工作，B 中途改了 X。对策：任务描述里钉住版本或快照；或约定“只追加不改写”的交接协议。
- 缓存失效。共享的系统提示或上下文前缀若含共享状态，状态一变缓存全失效——共享状态尽量走外部存储，不要烘进 prompt。
决策速查
| 信息类型 | 处理方式 |
|---|---|
| 任务目标与验收标准 | 隔离地给（派发时写入子 Agent 窗口） |
| 探索过程、中间草稿 | 隔离（留在子窗口，用完即弃） |
| 结论与证据指针 | 共享（结构化消息或落盘文件） |
| 大块中间产物 | 共享文件系统，窗口里只留路径 |
| 可变的全局状态 | 外部存储 + 明确的字段所有权 |