五个 Codex 同时在跑，先管哪个在等你

说个你可能很熟的下午。

你在三个终端里各开了一个 Codex，一个改搜索接口，一个修 CSV 导出，一个整理发布说明。你去接了杯水，顺手开了个会，一个半小时后回来。第一个终端停在一条命令的批准提示上，等你按 y。第二个早就跑完了，输出滚了三百行，你不知道哪一行是结论。第三个在二十分钟前就因为缺一个 .env 里的变量停了，屏幕上那句「需要你确认」被后面的日志淹了。

你一直以为自己在并行三个任务。实际情况是，三个任务里有两个卡在你身上，而你根本不知道。

这里的问题不在模型。该干活的都在干活。坏掉的是另一半：你在多个会话之间怎么知道谁在等你、怎么在不切窗口的情况下把一个补充要求递进去。这一半以前基本没人管。

Codex CLI 0.149.0 补的就是这一半。这个版本在 2026 年 8 月 20 日发布，带了两个东西：codex agents 打开的一块面板，和一个叫 codex queue 的命令。它们不会让任何一行生成的代码变好，只处理人的这一侧。

面板只报三种状态，但顺序不是随便排的#

在终端里敲 codex agents，面板就开了。它把本机上所有 Codex 任务列出来，按工作目录分组，每个任务给状态、名字、所在目录和当前分支。子 agent 的动作会挂在自己那个主任务下面，不单独占一行。

状态只有三种：

状态	含义	该做什么
Need input	卡在你身上，等你回答、批准或做选择	马上看
Working	正在跑	一般别动它
Ready	这一步做完了，等你验收	排队看输出

面板顶部给的是这三种状态的计数。这个设计里真正的信息是排序：Need input 排第一位。Working 的任务不需要你，Ready 的任务晚十分钟看也不会变，只有 Need input 的那些，是你不动它就不动的。你把它们当成待办队列从上面往下清，就把「到底该管哪个」这个问题消掉了。

键位大概是这样：上下选任务，回车打开完整对话，Ctrl+F 搜任务，Ctrl+S 换分组方式，Ctrl+R 改名，Ctrl+X 停掉。从某个任务的会话里回到面板，用 /agents，或者按默认快捷键 Alt+A。这些键是可配的，以你面板底下那行提示为准。

名字是地址，不是备注#

codex queue 全靠名字找任务，所以起名不是审美问题，是这个命令能不能用的前提。

Codex 自动给的名字通常长这样：「Fix the header and then adjust…」，截断在中间。这种名字你记不住，也没法当地址用，第二天打开面板你还是得逐个点开看。给正在跑的任务起个短名字：

frontend-accessibility
backend-rate-limits
docs-release-notes

改名字有两个入口，面板里选中按 Ctrl+R，或者进任务敲 /rename 新名字。改名只动标签，对话记录和历史都不会丢。

递话的时候名字要完整，带空格就整个用引号包起来。任务叫 Fix checkout page，你传 checkout 或者 Fix checkout 都匹配不上，得传全名。脚本里别用名字，用 session UUID（任务里敲 /status 能看到），名字是人随手改的，UUID 是机器认的，跑自动化的时候更稳。

从另一个终端递一句话#

codex queue 干的事很单一：把一条消息送进一个已经存在的会话。

codex queue \
  --thread "frontend-accessibility" \
  --message "最后再过一遍焦点顺序和键盘导航"

你正在另一个任务里写东西，突然想起来「对了，那里还要加个边界判断」。以前你得切窗口、翻回那个终端、等它当前这一步跑完再把话打进去。现在在手上这个终端里敲一行就够了，目标任务自己会在它的下一轮收到这句。远程会话加对应的 --remote 地址和认证参数。

这就是它的全部价值，一次省几十秒。但一天里你可能会想起来七八次。

底下是一个本机常驻服务#

有个细节能解释后面几个坑。

面板不是任务的第二份拷贝，它是同一个 app-server 守护进程上的一层视图。任务、状态、对话记录都活在那个 daemon 里，面板只是把它们读出来、排好序给你看。

有三个实际后果：

面板空着或者找不到某个任务，先确认你在同一个操作系统账号下，连的是同一个 daemon。排查用 codex doctor。
远程会话要用同一套 --remote 地址和认证，否则本地面板看不见它，codex queue 也找不到它。
「名字必须精确」这件事通了：queue 不是去硬盘上翻文件，是让 daemon 在它管的那个会话列表里做查找，查不到就是查不到，不会给你模糊匹配。

它治「看得见」，不治「打架」#

面板管的是你能不能看见每个任务的状态。另有一类问题它一点忙都帮不上：两个 agent 在同一个仓库里同时改文件。

两个 Codex 跑在同一个工作目录，改的是同一棵工作树、同一个分支。一个 agent 写到一半的改动会让你另一个 agent 的测试跑不过，两个任务可能动同一个 lockfile，最后你拿到一份混了两个需求的 diff，只能手工拆。这个问题得靠 git worktree 解决，一个任务一个独立 checkout、一条独立分支。Codex CLI 自己也往这个方向走了，0.154.0（2026 年 9 月 9 日）加了实验性的 worktree 支持，0.156.0 起默认开启。

所以这两个东西是配套的，不是二选一。worktree 负责让任务之间不互相踩，面板负责让你知道它们各自什么情况。缺前者，你看见的是三个互相污染的任务；缺后者，你有了干净的隔离，却不知道哪个在等你。想把并行这条线跑顺，两个都得有。

什么时候它反而多余#

开一两个任务的时候，这块面板是绕路。你敲 codex agents，看见唯一那个任务在 Working，然后还是得挪回它的终端。多按了两次键，什么也没省下。分界线大概在三个以上，低于这个数量，原来的终端切换反而更快。

还有一件事它不是。任务标着 Need input，面板只告诉你「它在等你」，它不会替你批准一条命令，也不会替你做那个选择。它把注意力该往哪儿放告诉你，放不放还是你自己的事。

那条状态是它自己报的#

Ready 的意思是 Codex 认为「我这一步做完了」。它不等于是「做对了」。

一个任务可能把测试全跑绿了，顺手把你没让它改的一个文件也改了。它可能自认为实现完成，代码里留着一个只覆盖了正常路径的分支。面板会老老实实把这些都标成 Ready，因为从它的视角看，确实做完了。

这不是面板的缺陷，是这类工具的通病：状态由被观察者自报。所以面板真正的用法是决定你的注意力先落在哪，而不是决定你可以不用看。它把你从「花半小时翻三个终端」里省出来的时间，应该花在你打开的那个任务上。

小结#

并行跑 agent，卡点很少是算力，基本是人。你不需要更聪明的模型，你需要知道谁在等你、哪句话该递给谁，然后按这个顺序一件件清掉。

codex agents 和 codex queue 做的事就这么小。但从「开一个任务」到「开五个任务」，心理负担的差距，很大程度上就是这两个小东西填掉的。