这篇文章基于 Lawrence 在 X 上发布的一组长帖整理而成，原帖：https://x.com/lawrencew_zen/status/2035949835124351009?s=46。

我这里不是逐字照搬，而是按博客阅读习惯重新组织了一遍，也补上了我自己觉得真正有价值的那层判断。

我先说结论

我觉得这条思路很值得抄：让 Claude Code 继续做主控，把规划、判断和交互留给它；再把 Codex 拉出来当执行层 SubAgent，专门处理那些更适合“埋头干活”的任务。

表面上看，这只是一个“省 Claude Token”的小技巧；但往深一点看，它其实是在回答一个更现实的问题：当我们手里不止一个模型时，工作流该怎么分层，成本和体验才能同时在线？

起因很真实：Claude 好用，但真不适合包办一切

原帖作者长期在用 Claude Code，给出的判断很直白：能力强、理解快、当总控非常舒服，但 Token 也确实烧得快。

这件事一旦进入真实开发流程，问题就会放大。因为消耗的不只是几轮问答，而是整套上下文链条：

于是矛盾就出来了：很多任务明明重要，但并不一定需要“最贵的脑子”全程亲自下场。

比如方案设计、任务拆解、架构取舍，这些高价值判断很适合交给 Claude；但像局部文件修改、重复性实现、批量执行这些活，其实完全可以交给别的模型去扛。

核心不是“换模型”，而是“换分工”

这也是我觉得原帖最聪明的地方。作者并没有把问题理解成“Claude 不行了，换 Codex 试试”，而是直接改了角色分工：

  1. Claude Code 负责主控、理解需求、拆任务、做判断。
  2. Codex 负责接具体执行任务，单开一个执行位去干活。
  3. 人 继续和 Claude 对话，并随时盯住执行过程。

这一下子就不是单模型工作流了，而是一个非常轻量的“总控 + 执行分包”模型。它像一个迷你团队，而不是一个万能助手。

为什么执行层选 Codex

按作者的描述，Codex 被选中并不是因为它在所有维度都最强，而是因为它很适合当执行层：

这点我很认同。很多人讨论模型时，习惯只问“谁最强”；但一旦真正进入生产环境，更重要的问题往往变成了：谁最适合当前这份活，谁的成本结构最合理。

真正关键的一步：执行过程必须看得见

如果只是把任务偷偷丢给后台跑，这套方案其实并不新鲜。原帖里更让我在意的，是作者对“可见性”的要求。

他不是要一个静默黑盒，而是想随时知道：

这个感觉很像什么？像你把活交给旁边工位的同事，人没离线，你一抬头就能看到他现在到底在认真干活，还是在越改越歪。

我觉得这点特别重要，因为真实工程里，大家真正怕的从来不是“AI 不会写”，而是它悄悄写歪了，但你很晚才发现。所以可观测性不是附加项，而是这种多 Agent 协作能不能落地的前提。

这件事背后，其实是一个更成熟的 Agent 范式

把原帖抽象一下，会发现它已经很接近一套可扩展的 Agent 协作模型了：

  1. 主 Agent 负责理解问题和做决策
  2. 子 Agent 负责领取任务并执行
  3. 执行过程必须可观测、可纠偏
  4. 模型选择按任务等级和成本做分层

这比“一个模型从头干到尾”更像真实团队，也更像我认为未来会越来越常见的 AI 工程形态：不是追求某一个模型把所有事都做完，而是开始认真设计协作关系。

我最想记下来的，不是工具细节，而是这三个判断

1. 贵模型应该做更贵的决策

强模型最有价值的地方，不是去批量改十个小文件，而是做判断、做取舍、做高层规划。把它浪费在纯执行层，本质上就是资源错配。

2. 自动化一旦进工程，就不能是黑盒

能跑当然重要，但只会“跑完告诉你结果”并不够。越是复杂任务，越需要过程透明、状态明确、可随时中断和纠偏。工程系统和玩具脚本，差别往往就在这里。

3. 好工具不是一下子做成平台，而是先解决一个真问题

作者的切口非常小：先解决 Claude Token 成本，再把 Codex 接进来做执行层。这个起点一点都不宏大，但因为问题够真，后面自然能往 CLI、并行执行、Worker Pool、DAG 编排这些方向长。

为什么我觉得这篇帖子值得单独写一篇

因为它讨论的根本不是某个脚本，而是一个已经越来越清晰的趋势：AI 编程工具的竞争，不会只停留在“谁更聪明”，而会逐步转向“谁更适合被组织进工作流”。

当 Claude、Codex、Gemini 或其他模型，不再只是被拿来二选一，而是被当成不同岗位来调度时，AI 才真正开始从“单点能力”走向“系统生产力”。

所以这篇东西表面写的是一个 SubAgent 小工具，底层写的其实是一件更大的事：我们开始从“我在用一个 AI”走向“我在指挥一组 AI 一起干活”。

原帖后续为什么也值得继续看

从原帖给出的目录看，这还只是一个开头。作者后面准备继续展开：

这说明他想做的不是一次性的效率小 hack，而是一套真正能演进的 Agent Team 工具链。对做 AI 工程的人来说，这个方向比“又一个 prompt 技巧”有意思得多。

原帖信息