这阵子 Claude Code 和 Codex 都在动「多 agent」这块。CC 在 2.1.178 把 Agent teams 大改简化，Codex 这边推进 multi-agent v2。表面上两家做的是同一件事，派一队 agent 并行干活，但把最近这几个版本扒开看，方向其实是相反的：CC 在让多 agent 协作更易用、更可交互，Codex 在让子 agent 更隔离、更确定。
这篇就把两边的机制对着看一遍。CC 一侧以官方文档为准、措辞保守；Codex 一侧开源，能落到源码行号的我都标了出处。
一、CC：subagent 和 agent teams
先分清 CC 的两个东西，它们经常被混成一个。
subagent 是会话内的委派。你给一个 side task，它在自己独立的上下文窗口里干完，只把摘要回传给主 agent。它有自己的 system prompt、工具白名单、独立权限。关键是：subagent 之间互不通信，只对主 agent 汇报。它解决的是「别让探索过程把主对话刷爆」，本质是一个隔离的、用完即弃的 worker。
agent teams 是另一回事。一个会话当 lead，它 spawn 出来的每个 teammate 都是一个完整、独立的 CC 会话，各有各的上下文。teammate 之间能直接通信------靠一个 mailbox 消息系统，加一张共享任务表，任务用文件锁认领，避免抢同一个。更要紧的是，你可以直接进某个正在跑的 teammate 的会话给它追加指令、改方向，而不必经过 lead。官方文档把这条差异说得很直白：subagent 只能向主 agent 汇报、彼此不说话；agent teams 的 teammate 共享任务表、互相喊话。
2.1.178 这次改的，是把 agent teams 用起来的门槛砍掉。以前你得先让 Claude 建一个有名字的 team，它用 TeamCreate、TeamDelete 两个工具建好再拆。现在这两个工具直接没了：每个会话隐式就有一个 team，你用 Agent 工具按名字直接 spawn teammate，退出时自动清理。一句话，从「先组队再派活」变成「直接派活，队自动成」。
所以 CC 的分界是清楚的：要不要让 worker 之间互相通信、要不要你能中途介入。不要，就用 subagent；要，就用 agent teams。
二、Codex：v1 到 v2 的收紧
Codex 的多 agent 有 v1 和 v2 两代，最近在推 v2。对着源码看，这一代的取舍和 v1 明显不同。
v1（codex-rs/core/src/tools/handlers/multi_agents/）给的是 spawn 加一个 send_input。这工具带个 interrupt 开关：interrupt=true 就立刻打断子 agent 当前的活、马上处理这条消息（硬重定向），不填就排队（multi_agents/send_input.rs:11、multi_agents_spec.rs:135）。也就是说，v1 的子 agent 可以被中途喂话，甚至硬打断。
v2（multi_agents_v2/）换了套路。它的工具面是 spawn_agent(multi_agents_v2/spawn.rs:28) 加 wait_agent(multi_agents_v2/wait.rs:25)，agent 间通信则拆成两个：send_message 投递消息但不唤醒目标，目标下个 turn 才读到；followup_task 给非 root 的目标派后续任务并唤醒它------idle 就起一个 turn，正在跑就等到消息边界或当前工具调用结束再交付，不硬打断 （multi_agents_spec.rs:156、:188）。关键变化是：v1 那个能 interrupt=true 中途硬打断的 send_input，v2 没了。v0.141 的「拒绝直接给 v2 子 agent 输入」说的是外部客户端那条路，agent 之间能通信，外部不能直接塞。
v2 还在几个地方明显收紧：
spawn_agent按 role 来 spawn，请求里能带的 model override 被reject_full_fork_spawn_overrides限住（spawn.rs:78），不让子 agent 随便改配置；- spawn 的深度有界，靠
next_thread_spawn_depth算 child 的深度（spawn.rs:71），防止子 agent 无限往下再 spawn； wait_agent的超时不是随便填，有min_wait_timeout_ms、max_wait_timeout_ms、default_wait_timeout_ms三个上下界兜着（wait.rs:51--66）。
把这些拼起来，v2 的模型就是：spawn 出一个 role 明确、配置受限的子 agent，然后 wait 等它在超时内跑完。期间外部客户端插不进手，agent 之间要协调就走 send_message / followup_task，但都不像 v1 那样能中途硬打断。一句话，v2 把子 agent 做成了一个 spawn 完、最多在安全点收后续任务的隔离单元。
三、方向相反
把上面两节并到一张表里，差异一眼就出来了。
| 维度 | CC subagent | CC agent teams | Codex 多 agent v1 | Codex 多 agent v2 |
|---|---|---|---|---|
| 上下文 | 独立、用完即弃 | 独立、完整会话 | 独立 | 独立 |
| agent 间通信 | 无，只回主 agent | 有，mailbox + 共享任务表 | 有，send_input |
有，send_message / followup_task |
| 能否中途 steer 在跑的 agent | 不能 | 能，直接进会话给指令 | 能，interrupt=true 硬打断 |
外部被拒；agent 间只能安全点交付，不硬打断 |
| 协调方式 | 主 agent 统管 | 自协调、认领任务 | 编排者发输入 | spawn → wait（超时有界） |
| spawn 约束 | 工具白名单/权限 | 继承 lead 权限 | ------ | role + override 受限 + 深度有界 |
两边最近的动作方向，正好相反。
CC 把 agent teams 简化、强调「你能直接跟某个 teammate 对话、随时纠偏」，是往更可交互的协作走------让一队 agent 边跑边讨论、互相挑刺，你在中间随时插手。
Codex v2 把 v1 的 send_input 砍掉、加上超时界、override 限制、深度限制，是往更隔离、更确定的 spawn-and-wait 收------派出去的子 agent 行为可预期，不被外部中途干扰，跑完回收。
四、怎么选
这俩没有谁更好，是两种工程取舍，对应两种活。
想要一队 agent 并行探索、边跑边讨论、你随时介入纠偏，研究、评审、多假设排查这类，CC 的 agent teams 更顺手。代价是 token 烧得多（每个 teammate 是一个完整会话），而且它还是实验特性，/resume 不恢复 in-process teammate 这类限制都明摆着。
想要派出去的子 agent 行为确定、不被外部干扰、跑完给个干净结果------自动化流水线、跑批、要结果可复现的场景，Codex v2 的 spawn-and-wait 更可控。它牺牲的正是「中途插手」那点灵活，换来的是确定性。
往回收一句，接着上一篇那条边界：这俩------CC 的 subagent / agent teams、Codex 的 v1 / v2------全都是 harness 给你的原语。你的活是「派」和「组合」，按「要不要中途插手、要不要 agent 互相通信」去选档，而不是自己去重写一套派工和调度机制。CC 给你两层、Codex 给你两代，选型的依据是你这个任务到底要协作还是要隔离。
同一个需求------并行加协调，两家工程上的解法走了相反的路。这正是对着看 harness 最有意思的地方：差异往往不在谁有谁没有，而在面对同一个问题，各自押了不同的取舍。