Codex CLI 0.128.0 加了一个小命令：/goal。
小到像一条 release note，意思却不小。以前你让 Codex 改代码，它更像一个高级终端助手：你说一句，它干一轮。现在你可以给它一个目标，让它自己一轮接一轮跑下去，直到它判断目标完成，或者 token 预算被花光。
这不是“AI 程序员来了”。别急着贴神话。
它更像 OpenAI 正在把 Agent 的三个关键部件摆上台面：持续执行、预算约束、停止条件。放在 Codex 并入主线、Azure 独占松动的背景下看，这条小更新反而把旧问题说得更清楚了：OpenAI 的重心正在从“卖更强模型”，转向“卖能持续干活的系统”。
相比只看 Codex 并线和 Azure 松绑，/goal 补上的信息更贴近产品现场：Agent 不只是战略叙事，它已经开始进入命令行、进入开发流程、进入 token 账单。
这条更新到底发生了什么
几秒钟读完：
| 项目 | 事实 | 影响 |
|---|---|---|
| 产品 | Codex CLI 0.128.0 新增 /goal | 终端里的编码代理开始支持目标循环 |
| 工作方式 | 用户设定目标，Codex 持续执行多轮 | 从“响应命令”靠近“持续任务” |
| 停止条件 | 模型自评完成，或 token budget 耗尽 | 自动化有刹车，但刹车不等于可靠 |
| 实现线索 | 主要依赖 goals/continuation.md 和 goals/budget_limit.md 两类回合末注入 prompt | 更像流程编排，不是底层模型突然突破 |
| 路线参照 | OpenAI 版 Ralph loop | 把 agentic engineering 圈里的循环机制产品化 |
Ralph loop 的核心并不玄：模型完成一轮后，继续追问自己目标是否完成；没完成，就规划下一步；继续跑。
这类思路在 Agent 圈不新。OpenAI 这次真正做的是产品化：把循环机制放进 Codex CLI，给用户一个可触发的入口，再用 token budget 设成本边界。
最先受影响的人也很明确：
- 重度使用 CLI 的开发者；
- 试图把 AI 编程代理塞进日常工程流的团队；
- 正在评估 Agent 成本、权限、回滚和审计的企业技术负责人。
普通用户不会立刻感到变化。开发者会。
因为命令行是最容易暴露真问题的地方。聊天框可以糊弄，工程目录不会。代码改坏了，测试会报；上下文污染了，下一步会歪；循环停不下来，账单会响。
Codex 并线、Azure 松绑，都是同一件事的不同侧面
单看 /goal，它只是 Codex CLI 的一个功能。
放到 OpenAI 最近的动作里，它的味道就变了。
Codex 并入主线，说明编码能力不再只是一个旁支产品。它正在变成 OpenAI Agent 体系里的核心入口。写代码是最适合 Agent 落地的场景之一：任务明确、结果可验证、用户愿意付费、失败成本也能被工程流程兜住一部分。
Azure 独占松动，则是另一条线：OpenAI 不能永远把自己的增长绑在单一云入口上。模型越强，Agent 越能跑，算力、分发、企业采购和平台谈判就越重要。
这两条线合在一起，就是一句话：OpenAI 想从模型供应商，变成 Agent 执行层的控制者。
/goal 的价值在这里。
它不是证明 Codex 突然变聪明了，而是证明 OpenAI 正在把“持续执行”做成产品默认能力。模型回答一次，是问答；模型围绕目标持续行动，才开始接近工作流。工作流一旦跑起来，商业模式也跟着变了。
Agent 的账单，不是按“你问了几句”算，而是按“它替你跑了多久、调用了多少上下文、改了多少文件、触发了多少验证”算。
模型公司最喜欢的，不是一次性聊天，而是可重复、可消耗、可嵌入流程的动作。
天下熙熙，皆为利来。AI 行业讲理想很热闹，最后还是会落回使用频次、token 消耗、云成本和客户续费。
真变量不是能不能循环，而是凭什么停
我更在意停止条件。
一个 Agent 能连续执行，并不稀奇。难的是它什么时候知道自己该停。
/goal 目前有两个阀门：
- 模型自评目标完成；
- token budget 耗尽。
第一个是软阀门。模型判断自己是否完成目标，本质上还是模型给模型打分。它可能过度谨慎，反复跑无用回合；也可能过度自信，测试没补、边界没看，就宣布任务完成。
第二个是硬阀门。它不能保证任务完成，只保证损失有上限。
这点很现实。
对个人开发者，budget 是账单边界。对企业团队，budget 是治理边界。没有预算阀门，Agent 就不是助手，而是一个会自动消耗资源的黑箱。
早期工厂引入自动化机床时，关键不只是机器能连续转。更关键的是限位器、急停按钮、质检流程。没有这些，效率会变成事故放大器。
编码 Agent 也一样。
它越能跑，越要问四个问题：
- 能不能验证自己改对了？
- 能不能发现自己走偏了？
- 能不能把修改范围限制住？
- 停错了，谁负责？
/goal 至少把其中一个问题摆出来了：跑下去可以，但要有预算。
这比很多“全自动开发”的演示诚实。演示喜欢展示完成那一刻，真实工程更在意失败怎么收场。
OpenAI 做对了一半，另一半还在工程地狱里
这次更新值得肯定。
因为它没有把自动化包装成魔法。/goal 的实现线索显示，它很大程度上依赖回合末自动注入 prompt，比如继续执行、预算限制之类的指令模板。
这听起来不性感，却更接近真实产品。
今天很多 Agent 能力，不是一个模型突然开悟，而是模型、提示词、工具调用、权限系统、日志、预算、回滚机制拼出来的。谁把这些拼得稳，谁就更接近可用。
我不太买账的是另一种叙事：只要 Agent 能自循环，就等于具备可靠自主开发能力。
差得还远。
持续执行只是门票。可靠完成才是生意。
真正的门槛在三处：
- 完成状态识别.它知道什么叫“做好了”吗？
- 错误路径刹车.它发现自己越改越偏时，会停吗？
- 成本控制.它的收益能覆盖 token、时间、审查和返工吗？
这也是 OpenAI 从卖模型转向卖 Agent 时绕不开的难题。
卖模型时，用户还能把失败归因于 prompt 写得不好。卖 Agent 时，用户会直接问：你替我干活，为什么干坏了？你自动跑了十轮，为什么账单涨了、代码还没过测试？
产品责任变重了。
平台控制也变重了。
OpenAI 如果要让 Codex 成为开发者工作流的一部分，就不能只给一个会说话、会改代码的模型。它还得给权限控制、变更审计、测试集成、回滚路径、团队策略和成本预警。
模型看着更像工人，产品就必须更像工厂。
否则，跑得越勤，错得越贵。
接下来该看什么
接下来别只盯着 Codex 写代码准不准。
更该看这些硬指标：
/goal是否能和测试、lint、CI 更紧密结合；- token budget 能不能做成团队级策略，而不只是个人配置；
- Codex 是否提供更清楚的日志、回滚和权限边界；
- OpenAI 是否把 Codex 的 Agent 能力进一步并入主线产品和企业套餐；
- Azure 松绑之后，OpenAI 会不会给 Agent 工作负载找更多分发和算力出口。
这些东西不如模型参数好看，但决定 Agent 能不能进入日常工程。
PC 时代的软件工具，最后赢的往往不是最会演示的，而是最能嵌进工作流的。互联网平台战争也一样，入口、账单、权限、分发，最后都会比单点功能更硬。
今天的 OpenAI 也在走这条老路。技术换了皮，商业逻辑没换。
/goal 看起来只是一个命令。它真正提醒开发者的是：Agent 已经不满足于回答你，它要开始替你连续行动。而连续行动一旦发生，问题就从“它聪不聪明”，变成“它受不受控”。
这才是 Codex 并线、Azure 松绑和 /goal 放在一起后最值得看的地方。
OpenAI 不再只卖更强模型。它在卖一种会持续消耗资源、也可能持续创造价值的执行系统。
好生意。
也是更难甩锅的生意。