Appearance
Multi-Agent 为什么容易失控：Context Isolation 与 Planning Failure
前置：常见编排模式怎么选：Router、Fan-out、Manager 与 Handoff
核心问题：什么时候 Multi-Agent 的专业化/并行收益值得引入额外的 Context、权限和协调复杂度，怎样避免多个 Agent 互相污染状态？
多一个 Agent，不只是多一次模型调用
单 Agent 里，Planner 错了通常还能沿一条 Run trajectory 排查。拆成 researcher、coder、reviewer、deployer 后，系统同时增加了：谁看到什么、谁能调用什么、输出怎样交给下一个、失败归谁、是否允许回退/重试等新的协调状态。
因此 Multi-Agent 的成本不是简单的：
text
N agents = N × model call而更接近：
text
agent decisions
+ context copies
+ handoff contracts
+ capability boundaries
+ coordination states
+ additional failure edges只有这些新增复杂度解决了真实问题，多 Agent 才值得存在。
Context Isolation：每个 Agent 只拿完成职责所需的信息
假设代码审查 Agent 只需要 diff、测试结果和 review policy；部署 Agent 需要已批准 artifact、环境目标和 deployment capability。把整个开发 transcript、所有 repo secret、所有 tools 都复制给两个 Agent，不仅浪费 token，还扩大 prompt injection 与误操作面。
更合理的 handoff 是显式构造：
python
@dataclass(frozen=True)
class ReviewInput:
patch_ref: str
test_report_ref: str
policy_version: str
@dataclass(frozen=True)
class ReviewDecision:
approved: bool
findings: tuple[str, ...]下游拿的是任务所需 artifact + structured facts，不是上游完整“思考历史”。
Context isolation 和 Security isolation 相关但不相同：前者决定模型能看到什么，后者决定执行层事实上能访问什么。即使部署 Agent 的 Prompt 没有 secret，只要其 Tool capability 可以读取 secret，安全边界仍然过宽。
🔍 源码对照：Turn Scope 在 Runtime 创建时就已经被约束
完整源码与通用分析见 09-01 Run Lifecycle / State Machine。这里不重复代码；这里关注 isolation：每个 Agent / Turn 的 scope、tool session、privacy 与资源 owner 应在 Runtime 创建阶段确定，隔离不能只靠 Prompt。
源码说明
单独存在的 subagent-runtime.ts 和 agent-isolation/ 很适合用来抵抗“Multi-Agent 就是多开几个 prompt”的误解。即使不深入每个实现细节，也能从工程边界看到：子 Agent 带来新的 execution owner、context boundary、resource lifecycle 和 failure surface。
工程边界
不能从目录存在就推断所有 isolation 机制都已达到安全隔离；这里主要用于理解 ownership/context 隔离问题，真正 security boundary 仍要回到 Sandbox/Security 模块。
Shadow Harness 对照
- 只有当并行、专业隔离、context isolation 或 ownership transfer 带来可测收益时才创建 subagent。
- Subagent 输出必须经显式 handoff/result contract 回到 parent，不共享可变隐式上下文。
验证
给两个 subagent 注入冲突的局部事实，验证它们的 context/state 不互相污染，并检查 parent merge 时 provenance 是否保留。
Handoff 必须转移责任，而不是只转一段文本
一个可靠 handoff 至少回答：
text
who owns next step
what input artifact/version it received
what completion contract applies
what capabilities it may use
where result will be persisted
what happens on reject/failure例如 reviewer 返回“LGTM”不能自动等价于 deploy-ready。Runtime 应接收结构化 ReviewDecision，验证 required checks，再把 approved artifact identity 交给 deployment node。
如果两个 Agent 都认为“对方会做最后验证”，就会出现典型责任空洞；如果两个都做同一验证，又会产生重复工作和冲突状态。
Planning Failure 和 Runtime Failure 必须分开
看一个错误依赖：
text
A: generate_patch
B: run_tests
C: deploy真实依赖应该是：
text
A → B → CPlanner 却生成：
text
A → B
A → CScheduler 按计划并行启动 B/C，C 因没有测试批准而失败。这里 scheduler 没有 bug，它正确执行了错误 plan。
因此 Trace 至少要区分：
text
plan_version
node dependencies
validation result
replan reason
runtime execution result否则所有失败都会被笼统归到“Agent 不稳定”。
Multi-Agent 最常见的失控方式
上下文复制失控。 每个 specialist 都拿全历史，token 和污染面随 Agent 数量放大。
能力复制失控。 researcher、reviewer、deployer 都拿相同高权限 Tool set，职责隔离只存在于 Prompt。
无限 delegation。 manager 把任务交给 specialist，specialist 又重新交回 manager，没有 hop/budget/termination 限制。
stale handoff。 reviewer 审的是 patch v3，deployer 实际拿到 patch v4；文本描述相同也不能证明 artifact identity 一致。
责任不可归因。 没有 plan/handoff version，出错后无法判断是 planner、specialist 还是 Runtime。
这些问题不能靠“让每个 Agent 更聪明”统一解决，需要结构化 contract 和系统事实。
什么时候应该坚持 Single Agent / Workflow
如果任务路径稳定、权限高度敏感、handoff 没有独立信息边界，优先用 Workflow 或一个 Agent + deterministic nodes。Multi-Agent 更适合存在真正的职责/上下文/能力分区，例如：
text
research (external read-only web)
→ coding (workspace write + test)
→ security review (read-only diff + policy)
→ deployment (approved artifact only)评估 Multi-Agent 时不要只比较最终成功率，还要看 token、latency、handoff failures、重复 Tool calls、错误归因难度和权限面。增加 Agent 数量本身不是能力指标。
关联源码
自测
- 两个 Agent 共用同一 Context 后互相覆盖假设和工具结果。Context isolation 应保护哪些信息边界？
- 什么时候引入第二个 Agent 只是增加协调成本，而没有带来并行、专业隔离或 ownership 转移的可测收益？