开发者 Flavio Copes 让 Codex 在 Goal 模式下照着重造一遍 PocketBase，两套技术栈，连续跑了超过 24 小时，产出的两个原型都相当能看，却仍然需要大量手工返工。他的结论是：与其把这笔预算押在一次长跑上，不如换成十个能逐个审阅的小任务。本文拆解这个判断背后的可观测性逻辑，Plan 模式与 Goal 模式的真实分工，为什么「静默失败」比「写错代码」更贵，长会话里的子 agent 究竟在解决什么问题，以及在生产服务器磁盘只剩 1% 的时候，他为什么宁可自己一条一条敲命令。

同一个模型，在 Claude Code 里改代码顺顺当当，换到另一个 harness 上就开始报「String to replace was not found」。问题不在模型的聪明程度，而在编辑原语这一层：精确字符串替换、上下文补丁、两段式 Apply 模型，三条路线各有代价。这篇文章拆解三种编辑原语的设计张力、七个真实失败模式，以及 Codex 为什么会为了一个补丁语法去训练模型。

一次设计评审留下 12 个待修项，父 agent 带着 16 个廉价 worker 用一个夜晚全部修完：13 小时、118 个文件、16369 行新增、158137319 个 token。但真正值得读的不是交付成绩，而是账单结构：95.4% 的 token 是重复读取已经缓存的上下文，模型真正新写出来的文字只有 0.42%；66 次「还没好」的空轮询烧掉 6.5% 的总量。这篇文章拆解父 worker 编排里的两个成本杠杆、一个最贵的等待习惯，以及 Codex 上那个至今无解的「父 agent 叫不醒」问题。

有人问：你们用什么 IDE 管理多个 coding agent？六百个工程师回答，没有一个人给出相同答案。这个「零共识」本身就是最有价值的信号。行业已经把 agent 造出来了，却没把工作台造出来。这篇文章拆解 Codex CLI 已经内置但极少被配置的三块拼图（codex queue、auto_recap、Guardian history），为什么「哪个刚跑完就看哪个」是错误的调度信号，以及把并发压到六条以内背后的管理逻辑。

Codex 的 /goal 让 Agent 跨轮次追一个目标，直到完成或预算耗尽。但真正决定长任务成败的不是模型能力，而是三件事：压缩之后审计要求会不会丢、谁给完成结果判卷、预算是闸门还是断路器。这篇文章拆解三个失效点，以及把实质写进文件、把人工审批变成可判定检查项这两个具体解法。