Codex 和 Claude Code 处理长任务的方式大不同：Token 消耗谁更省？

最近在折腾 AI 写代码工具的时候，发现了一个挺有意思的细节。同样是在跑那种可能需要好几分钟的长任务（比如跑测试、打包部署），不同的 AI 助手处理起来逻辑居然差这么多。

Codex 为什么要一直轮询？

有人吐槽 Codex 在处理长任务时，似乎一直在“傻等”，也就是所谓的轮询模式。简单说，就是 AI 发出一个命令后，并没有真正挂起去休息，而是像个急性子一样，时不时去问一句“完事儿了没？”

如果你去翻一下日志，你会发现一个扎心的事实：每次轮询，它的请求里居然都带着完整的上下文！

这就很要命了。假设你要运行一个稍大的项目构建，可能需要好几分钟。为了等这个结果，Codex 可能会每隔几秒就发一次请求，带着长长的一串代码历史、之前的对话记录去刷新状态。这简直就是 Token 碎钞机，大把的算力就这样浪费在了“查岗”上。

Codex与Claude Code处理长任务的对比

Codex与Claude Code在处理长任务时的机制对比：Codex采用高频轮询携带全量上下文，Claude Code采用后台挂起的事件驱动模式。

Claude Code 是怎么做的？

相比之下，Claude Code 的处理方式就显得聪明很多。当你让它跑长任务时，它会把命令真正挂到后台去执行。在这期间，AI 本身会进入一种“休眠”或“挂起”状态，它不会一直保持连接并发送消耗 Token 的请求。

一旦后台的那个命令运行结束，有了 stdout（输出结果），系统才会把 Claude Code 唤醒，然后把结果喂给它看。这样一来，在整个任务执行的期间，几乎不占用对话的上下文窗口，Token 消耗自然就降下来了。

为什么会有这种差异？

这其实涉及到两种不同的技术实现思路。

主动推拉模型： Claude Code 这种属于典型的“事件驱动”或者回调机制。任务结束通知我，我才醒过来。这种方式需要更复杂的系统架构支持，比如 WebSocket 长连接或者专门的任务队列服务，但对 API 调用者来说，成本最低。
轮询模型： Codex 这种做法在某些早期的系统集成里很常见。因为实现最简单，不需要复杂的状态维持，就是最朴素的 HTTP 请求——响应循环。缺点就是大家都看到了：浪费资源，尤其是在 LLM（大语言模型）这种按字数算钱的场景下，简直是负优化。

这给我们什么启示？

如果你在使用 AI 开发工具，或者自己正在开发类似的 AI Agent，这里有个很重要的优化点：

避免无意义的全量上下文刷新： 如果你的 Agent 只是在等待一个外部脚本执行，千万别把这一整段等待时间变成聊天记录的一部分。
学会“挂起”任务： 真正的生产级工具，应该具备分离“思考”和“执行”的能力。把耗时操作扔给沙盒环境，等结果回来再让 LLM 分析，这才是把钱花在刀刃上。

下次再看到你的 AI 助手在疯狂刷日志跑进度条，不妨留意一下，它是不是也像 Codex 一样正在“烧钱”查岗。