📄 本文综合改写自 Codex Knowledge Base 与 InfoWorld 的公开分析材料，原文链接见文末。

上午十点，你的机器上同时跑着三个 Codex 会话。第一个在追查支付服务上线后 p95 延迟的那个尖峰，第二个在翻依赖树里所有今年之后才披露的 CVE，第三个在起草报表模块从 REST 迁到 gRPC 的方案。

三个会话都很健康，没有任何一个报错、卡死或者超预算。模型能力也完全够用。真正拖慢你的，是另一件事：你在三个终端之间来回切换时，脑子里那笔重建成本。刚才那个 agent 问到哪了？它为什么选了这个方案？我上次的回复是不是还留了个尾巴？

这笔成本不会出现在任何仪表盘上，但它会精准地吃掉你并行省下来的每一分钟。

有人问了一个问题，六百个人没能给出同一个答案#

Steve Yegge 在 X 上问了一句：你们用什么 IDE 来管理多个 coding agent？

六百个工程师回复了。答案从「开三十个终端标签」到「自己写了一个会话管理器」，再到「半打互相不知道对方存在的工具」都有。没有共识。

这个「没有共识」，比任何一个具体答案都更有信息量。它说明的不是工程师不够聪明，而是这一层的产品还不存在。

行业在过去两年里把 agent 造出来了，Codex CLI、Claude Code、Antigravity CLI 都能独立完成相当复杂的工作。但没有人把工作台造出来，也就是那个负责把多个 agent 的进度、决策点和依赖关系收敛到人眼前的东西。

这一步缺席的后果很具体。当三个 agent 并行时，瓶颈从算力转移到了你自己的上下文带宽：你能不能同时持有三份会话的状态，在对的时机回到对的那一份，并且在不必从零重建前因后果的前提下做出判断。

Codex CLI 其实已经给了三块拼图#

大多数人的多 agent 工作流停留在「多开几个终端」，是因为以为 Codex CLI 只是单会话工具。实际上它内置了三件专为这件事设计的东西，而且默认都没被打开。

第一件是 codex queue。 它的设计目标恰好就是 Yegge 描述的那个场景：多个任务并发推进，每个任务在不可预测的时间点要求你做一次决策。

# 三件事同时扇出
codex queue "investigate p95 latency spike in payments-service since deploy 4.2.1"
codex queue "audit dependency tree for packages with known CVEs filed after 2026-01-01"
codex queue "draft migration plan from REST to gRPC for the reporting module"

队列默认六线程并发，每个任务完成就往你的方向推结果。你不需要盯着每一个终端，也不会丢掉「我刚才让它干什么」这个前提，因为任务描述是跟着结果一起回来的。

第二件是会话持久化。 从 v0.153.0 起，--session 参数和 tui.auto_recap 组合起来，给了你命名的会话句柄和自动的上下文摘要。你中途回到一个正在跑的 agent 时，看到的是结构化摘要：它在哪一步、做过哪些决定，而不是让你翻一屏回滚日志自己拼。

# config.toml
[tui]
auto_recap = true
auto_recap_interval = 10   # 每 10 轮摘要一次

第三件是 Guardian history。 同样在 v0.153.0 引入（PR #41879 与 #42065），它把审批记录跨会话持久化。如果上一个会话里某个 agent 请求过一个破坏性操作、而你拒绝了，这个上下文在新会话里依然存在，agent 不会像什么都没发生过一样再问一遍。

这三件事拼在一起，才是一个 Codex 原生的多 agent 工作台底座。现实是绝大多数人都没配，然后继续开着三十个终端标签。

真正的失效点是认知性的，不是技术性的#

这一层的问题不能怪模型质量，它是人的调度问题。

一个同时管着三个 agent 的开发者，面对的是一道优先级判断题：现在该看哪一个，为什么？

最直觉的答案是「哪个刚跑完就看哪个」。这大致等于按通知新鲜度排序，而它是错的。五分钟前完成的那个 agent，可能刚刚抛出了一个阻塞性决策，这个决策每多等一分钟，另外两个任务的返工量就涨一点。而另一个还在跑的 agent，可能正需要你中途纠偏，否则它会沿着一个错误方向越挖越深。

完成时间不是正确的信号，你要的是决策影响度：哪一次完成带来的选择会波及另一个正在运行的任务？哪一个问题如果答错，会强制触发一轮返工？

这个信息目前 Codex CLI 不会以可查询的形式输出。这就是为什么有那么多开发者忍不住在业余时间自己写仪表盘和会话切换器，他们缺的正是这个字段。

今天就能做的四个动作#

生态还没补齐不等于只能干等。原文给出的缓解手段是可以立刻落地的，我按「今晚就能改完」的顺序重排了一下。

第一，把依赖关系显式写进 AGENTS.md。 如果你已经知道 gRPC 迁移必须等依赖审计先结束，就把这句话写下来，而不是等冲突暴露出来再处理：

## Task Dependencies
Migration tasks must not begin until the dependency audit for the affected module is
committed. Reference: `codex queue --session audit-001` must reach status `complete`
before `codex queue --session migrate-001` proceeds past the design phase.

这很手动，要求你在开工之前就把依赖图画完。但它挡住的是一类很贵的错误：agent 在上游任务结论还没定时，就沿着一个注定要被推翻的方向推进了几十分钟。

第二，用标签做里程碑分组。 Yegge 那条帖子里有几位工程师描述了「按冲刺目标分组会话」的工作区，而不是按时间或任务类型分组。Codex CLI 没有原生的里程碑视图，但 codex queue 的标签能给出一个够用的近似：

# 把任务挂到同一个里程碑标签下
codex queue --tag "sprint-47-perf" "profile hot paths in payments-service using async-profiler"
codex queue --tag "sprint-47-perf" "identify N+1 queries in order-history endpoint"
codex queue --tag "sprint-47-perf" "draft caching strategy for catalogue lookups"

# 列出这个里程碑下的全部任务
codex queue list --tag "sprint-47-perf"

标签只是轻量标记，它不强制顺序、也不会阻塞等待。但它给了你一个按目标过滤的视图，这是走向里程碑式工作台的第一步。

第三，写十行 shell 把信息压成一张表。 如果你真的按标签用起来了，一个包装函数值回它的十分钟开发时间：

# 放进 .bashrc 或 .zshrc
cq-sprint() {
  local tag="${1:-current-sprint}"
  codex queue list --tag "$tag" --format json \
    | jq -r '.tasks[] | "\(.status)\t\(.id)\t\(.description[:60])"' \
    | column -t -s $'\t'
}

它做的事和那六百个回答里自制的工作区切换器高度重叠：按标签过滤，把状态和描述排成一列，让你一眼扫完。

第四，把并发上限守在六条。 队列默认六线程不是随手定的数字。超过这个量级之后，每个决策点上的重建成本会开始超过并行带来的收益。这不是机器的限制，是你的限制。

生态还欠三件事#

上面这些动作的边界很清楚：它们都是绕过缺口的补丁。真正要等的是下面三件事。

决策影响度评分。 一个任务到达决策点时，它的输出应该带一个信号，说明这个结论会影响哪些其他正在运行的任务。这要求 agent 能推理任务之间的相互依赖，而目前这不在它的职责范围内。

跨任务的「被否决方案」记忆。 Guardian history 在会话内持久化审批决定，但它不会把 A 任务里被否决的方案，传递给 B 任务的并行执行。如果这两个任务在探索同一个设计空间，A 里的否决对 B 明显是相关信息，现在却丢了。

统一任务面。 codex queue list 是一条命令，不是一个常驻的显示器。当你陷在另一个任务里时，你不会看到它的输出。真正缺的是一块常驻的侧边栏，放在终端复用器、编辑器扩展或独立 TUI 里，能在不打断你当前上下文的前提下显示任务状态和待决事项。

这三条都不是使用 Codex CLI 做多 agent 的 blocker，但它们是「三到十个并发 agent」的开发者开始自制工具的原因。

我的判断：这是管理问题，不是界面问题#

把上面这些线索串起来，我反而觉得该换个类比。

从「一个人写代码」走到「一个人管三个 agent」，你扮演的角色已经换了，从操作员变成了项目经理。你手上那点注意力，就是团队的全部管理带宽。

而人类团队早就撞过同一堵墙，也早就有解：站会、看板、依赖图，以及看板上那个 WIP 上限。

WIP 上限存在的原因，不是机器跑不动这么多任务，而是并行度一旦超过人的注意力带宽，切换成本就会吃光所有收益。看板上限在三条、五条还是七条，是团队自己试出来的。

那么 codex queue 默认的六线程，本质上就是一条工程化的 WIP 上限。这条默认值值得被当成产品设计者的判断来读，而不是当成一个可以随手调大的参数。

顺着这个类比往下推，会得到一个有点反直觉的结论：多 agent 的收益不来自「你能同时跑几个」，而来自「你能不能把不需要你判断的部分彻底交出去」。

如果你手上这批任务里，平均每三个就有一个会在中途冒出一个需要你拍板的岔路口，那么最优并行度可能就是一。与其把第二个槽位用来再开一个需要你盯的任务，不如把它用来跑一个独立的审查者：一个没有实现上下文的干净会话，只读需求、读改动，然后回答一件事，做的东西和要的东西是不是同一个东西。

我前面写过这条路线在单次重构上的表现，它不提高并行的吞吐，但它把「需要你判断」的频率直接压下来了。而在一个注意力就是瓶颈的系统里，压低判断频率比提高并发数更划算。

展望#

工作台会是 agent 工具的下一个战场。Yegge 那条帖子有六百个回答、零个共识，说明这个类目还没有赢家，甚至还没有公认的形状。

对 OpenAI 来说这是一次一等公民级别的机会。它已经把 queue、session、Guardian history 三块基础件放在那里了，缺的只是把它们缝成一张常驻的、按影响度排序的决策面板。

在那之前，能做的事很清楚：

  • 今天就打开 codex queue、auto_recap 和 Guardian history
  • 用 --tag 给并发任务分组
  • 开工之前把依赖约束写进 AGENTS.md，而不是事后收拾冲突
  • 队列守在六条以内
  • 实在不够用，就写个薄薄的 shell 层，按标签过滤、优先展示被阻塞的任务

Codex CLI 的多 agent 工作台不是某个 IDE。它是一套排队纪律、一个把依赖写下来的习惯，加上一层在正确时机把正确决策推到你眼前的外壳。

先把习惯建起来，工具会跟上。

参考来源