Codex 在 0.128.0 引入了 /goal，一个不达目的不罢休的 Agent 设计，轻轻松松跑七八个小时，烧 Token 也很猛。 它跟 Spec-Driven Development 不太一样，实现上比较直接，约等于把社区流行的 Ralph loop 内置到了 TUI 里：while :; do cat PROMPT.md | codex; done。 /goal 既不做任务规划，也不做流程编排，它只提供约束和目标。只要目标没达成，它就让模型持续干活。 那它是如何不忘记任务的呢？其实也很简单，它把目标写进了数据库🥲，默认放在 ~/.codex/state_5.sqlite，每次 loop 都会读一遍数据库。当前的设计里，一个 session 只支持一个 goal，无论是进程重启还是 ctrl+c 中断都会自动恢复目标任务。 在任务的恢复机制上倒是做了一些优化，为了避免跟用户抢控制权，/goal 会严格检查当前线程是否处于空闲状态，然后再自动注入一个 continuation prompt 推进下一个 turn，prompt 拼接的内容大概做了这么几件事情：1）把目标转成可验证交付物；2）构建 checklist；3）检查真实产物（文件、输出、测试）。 在 prompt 里还做了比较强硬的检测声明：不接受看起来完成，不要因为 token 预算焦虑就提前完成，不要相信之前的记忆，只要有不确定性就继续干。 这种设计最大的问题就是巨量的 token 消耗，/goal 没有采用对话追加模式，每轮都会发送完整的对话历史，这会导致 token 消耗随轮次 n² 增长，而烧钱的问题完全靠服务器端的 prompt cache 机制来缓解。cache 也不是完全免费，只是成本更低而已，Claude Code 的 cache-hit 价格是 1 折左右，估计 Codex 的价格会更低。 可以这么理解，/goal = 目标驱动（objective）+ 状态感知（budget/time）+ 验收机制（audit）。每一步要做什么，完全交给模型自己来判断，相当于把模型当成一个负责交付结果的工程师。