读懂 Codex（10.8）：多 Agent 的收益、容量和恢复成本

具体问题与边界

把任务拆给多个 Agent 可以并行探索，也会复制模型采样、工具会话、上下文和恢复状态。收益只在子任务相对独立、结果能压缩汇总时成立；写热点相同或依赖链很长时，协调成本会超过并行收益。Codex 通过身份、Mailbox、注册容量、执行 Guard、Residency 和 AgentGraph 把这些成本显式化。

本节不把某个当前容量数值当作通用经验，也不主张 Agent 数量与吞吐线性增长。

资源与所有权

资源	所有者	约束什么	释放条件
agent/thread identity	Registry	可寻址性与唯一性	Close/删除策略
spawn reservation	Registry	并发创建穿透	成功注册或失败回滚
execution slot	Execution limiter	同时活动的子任务	Guard drop
resident slot	Residency manager	已加载 Thread 内存	空闲终态可卸载
mailbox	Agent record	消息反压和投递语义	消费/关闭
AgentGraph edge	AgentGraphStore	父子拓扑与恢复	Closed/删除约束
final notification	child lifecycle	父 Agent 一次性唤醒	终态发送一次

适合并行的正常路径

根 Agent 为独立子任务预留容量、启动子 Agent 并汇总结果的流程图 — 图 10.8-1：先按独立性拆任务，再分别申请注册、执行和驻留资源；父 Agent 接收摘要而非全部中间噪声。

根 Agent 判断任务是否能按只读探索、测试或互斥文件边界拆分，并定义每个子任务的交付合同。
Spawn 先做角色/深度/总量校验与 reservation，再创建子 Thread 和持久拓扑边。
子任务启动时申请 execution guard；已创建不等于正在占用执行槽。
运行中的输入通过有界 Mailbox 投递，QueueOnly 与触发新 Turn 的语义分开。
子 Agent 到达终态后只发送一次 final notification；父 Agent汇总结论、冲突和未决项。
空闲终态 Thread 可以从 Residency 卸载，路径、历史和 AgentGraph 仍支持后续 Resume。

多 Agent 降低的是主线程上下文污染与可并行墙钟时间，不会减少总 token，也不会自动解决冲突。父 Agent 仍是需求、合并和最终验证的所有者。

Python 风格伪代码

async def delegate(tasks: Sequence[BoundedTask], pool: AgentPool) -> list[AgentSummary]:
    assert tasks_are_independent(tasks)
    children: list[AgentHandle] = []
    for task in tasks:
        reservation = await pool.registry.reserve(task.role)
        try:
            child = await pool.spawn(task, reservation)
            children.append(child)
        except BaseException:
            reservation.release()
            raise

    summaries: list[AgentSummary] = []
    for child in children:
        async with await pool.execution.acquire(child.id):
            terminal = await child.wait_terminal()
        summaries.append(await child.final_summary_once(terminal))
        await pool.residency.mark_evictable(child.id)
    return summaries

真实 Runtime 允许并发等待；伪代码串行书写收集阶段只是突出 reservation/guard/terminal 的不同作用域，不表示生产实现顺序运行子 Agent。

容量与恢复失败

多 Agent 在注册、执行、驻留、邮箱和拓扑恢复阶段的失败状态图 — 图 10.8-2：Agent“存在”“正在运行”“已加载”和“可恢复”是四种不同状态，不能用一个数量上限表达。

故障/反模式	残留状态	处理
reservation 后创建失败	尚无完整子 Thread	回滚 reservation，不泄漏总量
execution slots 已满	Thread 可已存在	等待或返回容量错误，不重复 Spawn
Residency 满且无可卸载项	现有 Agent 保持	拒绝加载，等待终态/清理
Mailbox 满	消费者落后	put 反压，不无界积累消息
子 Agent 崩溃	历史/Graph 可能存在	记录 Error terminal，通知父一次
父 Agent 退出	子 Agent 可仍运行	明确关闭/孤儿策略，不静默丢拓扑
多 Agent 同改文件	外部副作用冲突	预先分区或由父 Agent 串行合并

设计判断

多 Agent 值得迁移的是“任务独立性门槛、容量分层、可寻址 Mailbox、单一终态和持久拓扑”，不是工具名称或 V1/V2 协议。对于规模较小或写热点集中的任务，一个 Agent 配合工具并发通常更便宜。

产品级实现需要付出 token、调度、状态 UI、关闭语义、恢复和版本兼容成本。若系统不能展示各子任务当前所有者和残留状态，多 Agent 只会把失败藏得更深。

证据与 Mini Codex

生产锚点为 agent/registry.rs、agent/control/execution.rs、agent/control/residency.rs、 agent-graph-store/src/store.rs；7.1—7.23 已拆清 V1/V2、Mailbox、容量与恢复。

Mini Codex 只测试 AgentPool 身份、容量、有界 Mailbox 与 final once：

cd examples/mini-codex
uv run pytest -q -k 'agent or mailbox'

它没有子 Session 模型循环、角色 Prompt、Residency 或 AgentGraph，不能证明真实协作吞吐。

本节边界

多 Agent 是一种 Runtime 能力；怎样把外部工作流、工具和宿主内能力接入 Runtime，则需要区分不同扩展面。详细源码映射由研究仓库中的配套索引维护。