夜雨聆风browser_use 创始人 Gregor Zunic 在 X 上发了一条短帖："/goal is one of the best things openai ever shipped。" 426 人点赞，2.7 万次查看。这个看起来平平无奇的斜杠命令，背后藏着 OpenAI 对 coding agent 产品形态的一次关键升级——让 AI 围绕一个长期目标持续工作，能暂停、能恢复、能审计完成度、能在预算耗尽时主动收口。
一个短帖，点出了 AI 编程工具最缺的那块拼图
2026 年 5 月 9 日，开发者 Gregor Zunic（@gregpr07）在 X 上只写了一行字：
"/goal is one of the best things openai ever shipped"
「/goal 是 OpenAI 发布过的最好的东西之一。」
▲ Gregor Zunic 原帖，426 赞，2.7 万次查看
Gregor 是 browser_use 的创始人，长期做 AI agent 方向的产品。他没有在夸某个模型跑分提升了几个点，也没有在聊代码生成的准确率。他称赞的是一个交互功能。
这种评价角度很少见。
在 AI 编程工具的讨论里，大部分热度都集中在模型能力——谁的补全更准，谁的上下文窗口更长，谁能一次改更多文件。但 Gregor 关注的是另一个维度：当 agent 执行一个需要几十分钟才能跑完的工程任务时，用户怎么知道它还在朝着正确的方向走？
`/goal` 要解决的，就是这个问题。
翻了源码才知道，`/goal` 远比想象中重量级
要理解 `/goal` 到底做了什么，最直接的方式就是看 OpenAI Codex 的开源代码。
在 GitHub 仓库 `openai/codex` 的 `codex-rs/tui/src/slash_command.rs` 中，`/goal` 被定义为内建 slash command，官方描述只有一行：
"set or view the goal for a long-running task"
「为长时间运行的任务设置或查看目标。」
▲ GitHub openai/codex 源码，`Goal` 是内建 slash command
描述很短，但它划定了 `/goal` 的核心边界：长任务。
当你输入 `/goal improve benchmark coverage`，你就把一段自然语言目标注册成了当前会话的 active objective。之后 agent 的所有动作都围绕这个目标展开。
更关键的是裸命令 `/goal` 的效果。在 `goal_menu.rs` 里，直接输入 `/goal` 会弹出一个目标状态面板：
- Goal
：当前目标 - Status
：active / paused / limited by budget / complete - Objective
：具体目标描述 - Time used
：已用时间 - Tokens used
：已消耗 token - Token budget
：预算上限（如有）
▲ GitHub openai/codex 源码，bare `/goal` 命令展示完整目标状态面板
支持pause（暂停）、resume（恢复）、clear（清除）。暂停时会问你要不要恢复，恢复描述写的是 "Mark it active and continue when idle"——标记为活跃，空闲时自动继续。
这已经构成了一套任务生命周期管理系统。
它到底解决了什么痛点？
如果你用过任何 AI coding agent 跑超过 10 分钟的任务，你大概率遇到过这些场景：
agent 跑着跑着就偏了。你让它重构一个模块，它改了三个文件之后开始"顺便"优化另一个完全不相关的函数。没有目标锚定，agent 的注意力会在长对话中自然漂移。
你不知道它到底完成了没有。agent 说"我已经完成了"，但你打开 PR 发现测试没跑、边界情况没处理、有些 TODO 还留着。对于复杂工程任务，"完成"是一个需要被严格定义的状态。
预算耗尽，任务烂尾。token 用完了，agent 停在半路。你不知道它做了多少，也不知道还剩多少。下次重开对话，又要从头解释一遍上下文。
断点续做？别想了。关掉终端再打开，之前的进度全没了。你只能靠自己的记忆重新组织 prompt。
`/goal` 针对的就是这四个场景。
源码里还藏着一个更狠的设计：完成审计
如果说状态面板解决的是"可见性"，那 `/goal` 背后的 runtime 机制解决的是"可靠性"。
在 `goals/continuation.md` 模板里，OpenAI 对 agent 提出了严格要求。当 agent 认为目标可能已经完成时，它必须执行一次completion audit（完成审计）：
"Before deciding that the goal is achieved, perform a completion audit against the actual current state."
「在判定目标已达成前，必须根据实际当前状态执行完成审计。」
审计流程：
1. 把目标重述为具体交付物和验收标准2. 每个显式要求、命名文件、命令、测试、交付物，都要映射到具体证据3. 检查相关文件、命令输出、测试结果、PR 状态 4.不能用代理信号充数——不能因为"测试通过了"就认为目标完成了，不能因为"花了很多时间"就觉得差不多了
只有审计通过，agent 才能调用 `update_goal status complete`。
还有 `goals/budget_limit.md` 处理预算耗尽的情况：当 token budget 用完，agent 必须停止新的实质工作，总结已完成的进度和剩余工作，不能因为预算耗尽就把目标标成"完成"。
OpenAI 在产品层面给 agent 画了一条底线——努力程度不等于完成度，你必须拿证据说话。
放回 Codex 的大图里看
OpenAI 对 Codex 的产品定位，早已超出了"代码补全工具"的范畴。
官方产品页的定位：Codex 是"A coding agent that helps you build and ship with AI"（一个帮你用 AI 构建和交付的 coding agent）。官方博文进一步描述它是"a cloud-based software engineering agent that can work on many tasks in parallel"（一个可以并行处理多个任务的云端软件工程 agent）。
▲ OpenAI Developers 官方文档，Codex CLI 产品首页
Codex 能做什么？写功能、修 bug、做 refactor、跑 migration、提 PR。每个任务在独立的云端沙箱里运行，可以读写文件、运行测试、检查 lint 和类型。任务完成通常需要1 到 30 分钟，完成后提供终端日志和测试输出作为可验证证据。
一旦任务时长拉到这个级别，用户和 agent 之间的关系就变了。你不再是"每隔几秒看一眼补全建议"，你是把一个工程目标交给 agent，然后等它给你结果。
在这个模式下，目标管理就是产品核心。agent 必须知道自己在做什么、做到哪了、什么时候该停。用户必须能随时查看进度、暂停任务、恢复执行。
`/goal` 就是这个核心的产品入口。
开发者在乎的，从来都是控制力
Hacker News 上关于 Codex CLI 的讨论里，有一个观点值得注意。知名开发者 swyx 把 Codex CLI 和 Claude Code 这类工具放在一起讨论，认为它们可以像Linux utility一样使用——把 AI 能力嵌入 CI、PR review、自动化脚本，不用绑定一个完整的 SaaS 产品。
这个视角解释了为什么 `/goal` 会让开发者兴奋。
开发者习惯的交互模式是：命令 + 状态 + 控制流。你启动一个进程，查看它的状态，暂停或终止它，读取它的输出。`/goal` 完全符合这个心智模型——一个 slash command 启动目标，`/goal` 查看状态，`/goal pause` 暂停，`/goal resume` 恢复，`/goal clear` 清除。
它天然就是开发者文化里的东西。
最后看回这件事
Gregor Zunic 只写了一条短帖，但他指向的趋势很大：AI coding 的竞争正在从"谁的模型更强"扩展到"谁的任务系统更好"。
模型能力当然重要。但当 agent 开始接手需要几十分钟才能完成的真实工程任务，用户需要的就不只是"更好的回答"，还有目标追踪、进度可见、预算控制、断点续做、完成审计。
这些能力，单靠模型升级解决不了。它们属于产品设计的范畴。
`/goal` 做的就是这件事：给 coding agent 加上一个目标层，让 AI 从"会写代码的聊天框"变成"可以持续执行工程目标的任务系统"。
一个小小的斜杠命令，可能就是 agent 产品进化的分水岭。
— END —
