实测:Codex 单 agent 跑 /goal 在速度和质量上完胜 Claude Code 编排多 agent
哇,我完全没想到会是这个结果。这真的很疯狂、很有洞见,而且彻底改变了我今后的开发工作流:
单次 CODEX /goal 运行是明显的赢家。没有编排,没有衔尾蛇,只有一个小小 agent 就能搞定 🤯
它在速度和质量上彻底碾压了 OPUS 编排器!
我睡觉前,Codex 5.5 xhigh 只用了 1 小时就完成!
完整迁移搞定,一切干净利落。我 review 了 PR,非常满意。
我当时去睡觉时,Claude Code(Opus 4.7)已经跑了 5 小时。我醒来,它还在跑!13 小时了!它其实是停下来问我一个完全无关的问题才停的。
过去我做编排从来没花过这么久。我用的是新的 CC /goal 模式,并在 25%(250k 上下文)时自动压缩,以防超过那个点之后出现上下文腐化。
它慢得离谱(好笑的是它管的只是 GPT 5.5 low、fast 模式,本来不该花那么久),
结果产出的质量还更低!差得不是一星半点!
这让我非常意外,因为在 5.5 出来之前,这种编排方式绝对是最佳、最快、最高效的。
而现在在一个大型关键任务上,它比单个 5.5 /goal xhigh 实例慢了 6 倍以上???
看来压缩是这里变慢的主要原因,因为 Claude Code 会在 25%(250k tokens)自动压缩(这是我在设置里设定的)。
每次压缩它都得花时间把东西全部重读一遍,拿到完整上下文,再执行,再塞满,再压缩,天哪,这效率真的不行。
事实上,它作为编排器的大部分时间都花在压缩、读上下文、然后再压缩上了!
而 Codex 则是一条持续不断的长压缩,一直往前推进。我相信我的 goal ledger skill 在这里帮它保持对齐起了很大作用!
看看这差距,笑死:
- Codex PR #23:后端 Supabase 移除完成,canonical wake 已接好,保留的接口完好无损,typecheck/lint/tests 全绿,已针对本地 Postgres 自测,有一项正确地延后处理并写了文档。现在可直接合并。+4,056/−981。
- Claude 第一次尝试:没达成核心目标(supabase 目录和 9 个引用者仍在),破坏了原本要保留的接口(把 task.service 掏空,把 tasks.router stub 成 emptyBoard —— PRD 明令禁止),删掉了约 5,456 行测试,未提交/工作区脏。那 17,762 行删除是过度删除,不是干了更多活。
哇。我真的很震惊。非常庆幸我在一个大型、完全相同的个人问题上跑了两套不同的工作流。
这彻底改变了我今后的工作流——我再也不会自上而下地编排一个大任务了。
取而代之,我打算在 Codex 上试试下面这套流程:
1. 让 Codex 先把我们代码库的范围摸清,然后就要做的事来回头脑风暴/讨论
2. 据此产出一份主 PRD,并把工作拆分成各自聚焦的分支任务
3. 从对话中并行分出分支,直到遇到需要合并工作的部分,然后再并行化
这样,各个 Codex agent 可以独立工作,每个分支都拥有相同的调研/头脑风暴上下文,然后各自干到彻底完成。
基于这次经验,这感觉是对的方向。我再也不会用这种方式做编排器了(把一份 PRD 一路执行到底)。取而代之,我会更像……分支工作的管理者。
不管我今后怎么做,我都不会再跑这种编排器配置了。笑死
单次 CODEX /goal 运行是明显的赢家。没有编排,没有衔尾蛇,只有一个小小 agent 就能搞定 🤯
它在速度和质量上彻底碾压了 OPUS 编排器!
我睡觉前,Codex 5.5 xhigh 只用了 1 小时就完成!
完整迁移搞定,一切干净利落。我 review 了 PR,非常满意。
我当时去睡觉时,Claude Code(Opus 4.7)已经跑了 5 小时。我醒来,它还在跑!13 小时了!它其实是停下来问我一个完全无关的问题才停的。
过去我做编排从来没花过这么久。我用的是新的 CC /goal 模式,并在 25%(250k 上下文)时自动压缩,以防超过那个点之后出现上下文腐化。
它慢得离谱(好笑的是它管的只是 GPT 5.5 low、fast 模式,本来不该花那么久),
结果产出的质量还更低!差得不是一星半点!
这让我非常意外,因为在 5.5 出来之前,这种编排方式绝对是最佳、最快、最高效的。
而现在在一个大型关键任务上,它比单个 5.5 /goal xhigh 实例慢了 6 倍以上???
看来压缩是这里变慢的主要原因,因为 Claude Code 会在 25%(250k tokens)自动压缩(这是我在设置里设定的)。
每次压缩它都得花时间把东西全部重读一遍,拿到完整上下文,再执行,再塞满,再压缩,天哪,这效率真的不行。
事实上,它作为编排器的大部分时间都花在压缩、读上下文、然后再压缩上了!
而 Codex 则是一条持续不断的长压缩,一直往前推进。我相信我的 goal ledger skill 在这里帮它保持对齐起了很大作用!
看看这差距,笑死:
- Codex PR #23:后端 Supabase 移除完成,canonical wake 已接好,保留的接口完好无损,typecheck/lint/tests 全绿,已针对本地 Postgres 自测,有一项正确地延后处理并写了文档。现在可直接合并。+4,056/−981。
- Claude 第一次尝试:没达成核心目标(supabase 目录和 9 个引用者仍在),破坏了原本要保留的接口(把 task.service 掏空,把 tasks.router stub 成 emptyBoard —— PRD 明令禁止),删掉了约 5,456 行测试,未提交/工作区脏。那 17,762 行删除是过度删除,不是干了更多活。
哇。我真的很震惊。非常庆幸我在一个大型、完全相同的个人问题上跑了两套不同的工作流。
这彻底改变了我今后的工作流——我再也不会自上而下地编排一个大任务了。
取而代之,我打算在 Codex 上试试下面这套流程:
1. 让 Codex 先把我们代码库的范围摸清,然后就要做的事来回头脑风暴/讨论
2. 据此产出一份主 PRD,并把工作拆分成各自聚焦的分支任务
3. 从对话中并行分出分支,直到遇到需要合并工作的部分,然后再并行化
这样,各个 Codex agent 可以独立工作,每个分支都拥有相同的调研/头脑风暴上下文,然后各自干到彻底完成。
基于这次经验,这感觉是对的方向。我再也不会用这种方式做编排器了(把一份 PRD 一路执行到底)。取而代之,我会更像……分支工作的管理者。
不管我今后怎么做,我都不会再跑这种编排器配置了。笑死