多 Agent 协同

结论：这不是“群体智能调度器”，而是一组可组合的委派生命周期

这个结论很重要：看到 subagent 并不能推出子 Agent 是否继承历史、是否能继续对话、是否由 Job 管理，甚至不能推出它运行在同一进程。Provider 只承诺它明确声明的能力；不支持的 outputSchema、深度限制、工具过滤和 persona 会在启动前失败，而不是被静默忽略。MULTIAGENT-SEAM

1. 真实拓扑：Provider 建子节点，Manager 管可继续会话

模型工具（名称可配置）
  subagent / subagent_fork
        │
        ├─ foreground ─────────→ SubagentRuntime.start(provider)
        │                            └→ provider.start() → SubagentRun
        ├─ one-shot background → Jobs → provider.start() → SubagentRun
        └─ continuable bg ─────→ ContinuationManager
                                     ├→ provider.prepareContinuable()（仅 seed 数据）
                                     ├→ Agent create / resume + inbox
                                     └→ durable Session + Activation epoch

全局控制：send_message / interrupt_agent / list_agents
子级返回：report（仅 continuable in-process child）

SubagentProvider.start() 拥有一次性 child 的发布前创建；返回 run 后，持有者负责等待结果并 dispose。对 continuable child，provider 只贡献“是否 seed 父历史”这份 detached data；身份、组合、Agent handle、消息、冷恢复、所有权和销毁全部由 continuation manager 接管。MULTIAGENT-SEAM

2. 一个工具定义，实际分成三条执行路线

因此“后台 Agent”不是一种状态：one-shot 后台是普通 Job，continuable 后台是有 durable Session ID 的对话。把两者都画成 running/done 会丢掉最重要的控制差异。

3. Provider 矩阵：同一个 seam，六种不同隔离边界

Spawn/fork 是真正进入本地父子图的 backend；外部 provider 不继承父对话，唯一可能来自父级的上下文是 workspace cwd（ACP/SDK 也可改用配置的 cwd），并通过 one-shot result seam 返回。ACP、Codex、Claude Code 与 SDK package 是可选能力，不等于默认产品面：Standard/Code preset 中 Codex 与 Claude Code 的工具行明确 disabled。MULTIAGENT-SPAWN-PROVIDERMULTIAGENT-FORK-PROVIDERMULTIAGENT-ACP-PROVIDERMULTIAGENT-SDK-PROVIDERMULTIAGENT-CODEX-PROVIDERMULTIAGENT-CLAUDE-PROVIDERMULTIAGENT-STANDARD-PRESETMULTIAGENT-CODE-PRESET

4. Spawn 与 Fork 的差异只在会话 seed，不在 child 是否“独立”

两种 in-process child 都会加入父级正在运行的同一 preset generation——同一批 plugin instance、工具注册和 prompt section，而不是按 preset 名重新读取可能已变化的配置。MULTIAGENT-PRESET-INHERITANCE

5. 继承矩阵：路线、工作区和能力是不同维度

不会继承的内容同样重要：spawn 不看父 transcript；fork 不看 open Turn；一次性授权不会下放；部署 sandbox 默认值不会被快照；child 的 persona 和工具过滤只在自身 scope 中生效，不污染父级或 sibling。MULTIAGENT-CHILD-INHERITANCEMULTIAGENT-CHILD-COMPOSITIONMULTIAGENT-DELEGATED-POLICY

6. 递归预算和权限边界都沿父子 lineage 单调收紧

Tool loader 的默认 maxDepth 是 3；provider-managed 用于无法由父 runtime 强制的外部 provider。底层 depth 读取持久 header 与 runtime option 的较大值，再加一生成 child，因此恢复后的 child 不能伪装回 depth 0。Direct apply 若省略 cap 则可无上限，这说明“默认 3”属于工具配置，不是 service 的全局定律。MULTIAGENT-TOOL-CONFIGMULTIAGENT-DEPTH

这不是 role-based team：没有 leader/member 角色表，也没有 sibling 直发通道。现有 authority 是树形且窄化的；想做 team、共享队列或任意 Agent 路由，需要新增显式协议，而不是把现有 parentSession 当成万能 ACL。

7. One-shot 的核心合同：发布前 provider 所有，发布后 run holder 所有

validate provider + capabilities + schema + descriptor
  → provider.start()
      → unpublished setup / rollback on failure
      → publish child or external run
  → emit subagent/start
  → await run.result ──────────→ emit subagent/end
  → map stopReason / preserve partial output
  → holder runs dispose() to quiescence

结果从 seed/activation boundary 后的 child-owned suffix 读取。completed、aborted、error、max-tokens、refusal 不会被压成一个布尔值；取消或截断仍可携带 partial output。One-shot 的 subagent/end 跟随 result settlement，可能早于 holder 完成 dispose；continuable epoch 的 end 则等待 teardown outcome。后台 Job 只有 completed 才把 final text 当成功输出，其他 reason 映射为 killed/failed，并且总在 settle 后 dispose。MULTIAGENT-ONE-SHOT-RESULTMULTIAGENT-LIFECYCLEMULTIAGENT-RUN-SETTLEMENT

8. “最终答案”与“结构化结果”是两套独立提交协议

普通输出的统一选择规则是最后一条非空 assistant message；若没有，则使用累计 text delta；都没有才为空。选择与 stop reason 独立，因此 error/max-tokens 也可能携带诊断价值很高的 partial answer。MULTIAGENT-ASSISTANT-OUTPUT

这解释了 external provider 为什么声明零 capabilities：工作目录相同不代表父 runtime 能强制其工具 catalog、persona、递归预算或结构化提交点。

9. Continuable 的 durable Session 与 process-local Activation 必须分开看

Activation 是一个驻留 epoch，不是 durable Task。它持有 exact handle、弱引用 ancestry、owned-child set、accepted message IDs 和一次性 disposal transaction；稳定的是 child Session ID，每次冷恢复会获得新的 lifecycle runId。MULTIAGENT-ACTIVATION-MODELMULTIAGENT-ACTIVATION-OWNERSHIPMULTIAGENT-LIFECYCLE

10. Follow-up 的权威提交点是 inbox acceptance；冷恢复不再调用 provider

send_message(childId)
  ├─ resident + running → 排入同一 Agent inbox，等当前 Turn 结束
  ├─ resident + waiting → 唤醒同一 Agent
  └─ no Activation      → inspect durable Session
                           → 校验 exact direct parent
                           → fold own descriptor suffix
                           → ctx.agents.resume()
                           → 排入 inbox

每个 child 的 delivery、release 和 disposal 先经过同一把 ChildLock；Agent inbox 是唯一 FIFO。调用方 AbortSignal 只拥有 acceptance 之前的阶段，消息被接受后不能通过这次 send_message 取消。MULTIAGENT-FOLLOWUP

11. 返回通道有四种，完成与报告绝不能混为一谈

send_message 只返回被接受的 messageId，不是 child 的回答。Child-scoped report 只能发给 direct parent，可按 wakeup 或 quiet 调度，且报告不会结束 Turn/Activation。MULTIAGENT-CONTROL-TOOLSMULTIAGENT-REPORT-TOOLMULTIAGENT-REPORT-DELIVERY

12. list_agents 是发现面，不是任务结果面

底层 listing 从 live Session store 与可选 persistence 合并 corpus，按 durable header 的 origin:subagent 找 direct children/descendants，再通过 projection 分类 mode/label。冷读并发固定为 4；单个 child 损坏或暂时读不到会成为 corrupt/unavailable diagnostic，而不是让整次 listing 失败。它不读取 Activation manager 或 provider 状态。MULTIAGENT-LIST-SERVICEMULTIAGENT-LIST-CONCURRENCY

模型工具过滤掉 one-shot child，因为它们不能被 send_message；descendants 仍会穿过这些节点做稳定 pre-order 遍历。Depth 1 才能 follow-up，更深节点只可作为 ancestor interrupt 候选。MULTIAGENT-LIST-TOOL

13. 并发策略是“跨 child 可重叠、单 child 线性化”，不是全局调度

Subagent 层没有全局 worker pool、公平队列、优先级、配额分配或结果归并器。它提供正确的并发边界；“派几个、何时派、如何合并”仍由模型 prompt、Job 层或更高阶 workflow 负责。

14. Interrupt 只停当前 Turn；Drain 才销毁整棵 Activation 子树

Interrupt 对 absent/已完成/one-shot ID 是 accepted no-op；它不是 subtree kill。外部 one-shot provider 在本地取消赢得竞态时把结果归一化为 aborted，并由幂等 handle teardown 等到子进程树退出。MULTIAGENT-INTERRUPTMULTIAGENT-OUTPROCESS-SETTLEMENT

15. 耐久性来自 Session descriptor，不来自驻留 Agent 或 Task queue

Session header
  parentSession / origin=subagent / delegationDepth / seedLength / agentPreset

subagent/descriptor v2（model-hidden, log-only）
  one-shot:    mode / provider / optional label
  continuable: mode / provider / label / agentProvider / agentModel / persona / toolFilter
  intentionally omitted: outputSchema / maxTokens / subagentDepth

Continuable creation 把 fork prefix（若有）之后追加一个 between-turn descriptor seed，再接受初始 prompt。Descriptor 先做 lossless JSON snapshot；当前版 parser 拒绝未知字段，版本不支持则不可恢复。MULTIAGENT-DESCRIPTORMULTIAGENT-DESCRIPTOR-SEEDMULTIAGENT-DESCRIPTOR-FOLD

进程重启后可恢复的是 child 对话及其声明式 composition，不是旧 Activation、run handle、accepted set 或 background Job。最终 flush 失败时，runtime 仍释放 graph，明确选择“可能 stale 的恢复”而不是“确定死锁的祖先”。MULTIAGENT-FINAL-FLUSH

16. Codex 对比：DeepSeek seam 看到一个 one-shot worker，Codex 内部仍可能编排 subagent

仓库里的 codex provider 每次委派启动新的官方 codex app-server --stdio，只继承父 Session 的 cwd。它声明零 start capabilities、没有 prepareContinuable、不共享父 transcript/preset/tool scope，也不返回本地 Agent handle。换言之，DeepSeek Harness 只把整个 Codex 运行包装成一个 one-shot child；即使该 Codex Turn 内部使用自己的 subagents，那棵内部树也不会成为 DeepSeek continuation graph 的可寻址节点。MULTIAGENT-CODEX-PROVIDERMULTIAGENT-CODEX-RUN

Wire 只把最后一个 final_answer（无显式 final 时退回最后个 unphased answer）作为输出；commentary 与 reasoning 不返回。Context window exceeded 映射为 max-tokens，其他异常经 shared out-of-process settlement 变成 error/partial output。MULTIAGENT-CODEX-RUNMULTIAGENT-CODEX-WIRE

Codex 公开多 Agent 合同与本 seam 的差异

Codex 一侧仅使用 OpenAI 公开的 Subagents 文档，检索于 2026-08-13。DeepSeek 一侧是固定 commit 的源码级证据；这个对照不推断任何未公开实现。

17. 失败分层：在哪个提交点失败，决定谁负责善后

Service 在 provider dispatch 前做 capability 检查；out-of-process helper 把发布后 transport rejection 变成稳定 result；listing 把读损坏隔离到单行。MULTIAGENT-RUNTIME-DISPATCHMULTIAGENT-OUTPROCESS-SETTLEMENTMULTIAGENT-LIST-SERVICE

18. Pinned baseline 的两项 composition 审计结论

Codex 的边界同样需要写准确：provider package 完整存在，但 preset 只提供 disabled 的模型入口。MULTIAGENT-CODEX-PROVIDER

19. 保证矩阵与最终评价