Codex CLI /goal命令详解：自动循环执行直到目标完成

Codex CLI 0.128.0 版本引入了 /goal 命令，让这个 OpenAI 开源编码代理工具具备了目标驱动的自主循环执行能力。设定目标后，Codex CLI 会持续执行操作、评估进度、判断是否达成目标，直到任务完成或 Token 预算耗尽。这标志着 AI 编码代理在自主性方面迈出了关键一步。

什么是 /goal 功能

从单轮对话到目标驱动的持续执行

传统 AI 编码助手的工作方式是单轮对话：你提出请求，AI 给出回应，然后等你发下一条指令。这种交互模式本质上是「人类在环」（Human-in-the-Loop）的同步协作——每一步都需要人类审查和确认，AI 无法独立推进多步骤任务。/goal 命令彻底改变了这种交互模式。

用户设定一个明确目标后，Codex CLI 会进入自动循环——执行操作、评估当前状态、判断目标是否达成，未达成则继续下一轮操作。这种模式本质上是 Ralph Loop 的 OpenAI 官方实现。Ralph Loop 由 Geoffrey Huntley 提出，其核心思想是让 AI 代理在反馈循环中持续工作，直到任务完成。具体而言，Ralph Loop 定义了一种「观察-行动-评估」的闭环结构：代理在每一轮迭代中先观察当前环境状态（如代码文件内容、测试结果、编译输出），然后执行一个操作（如修改代码、运行命令），最后评估操作结果是否让自己更接近目标。这种模式与强化学习中的「代理-环境交互循环」有异曲同工之处，区别在于 Ralph Loop 利用大语言模型的推理能力来替代传统的奖励函数和策略网络，使得代理能够处理开放式的、用自然语言描述的复杂目标。Huntley 最初在社区中推广这一概念时，主要通过手动构造系统提示词来实现循环，而 Codex CLI 的 /goal 命令则将其产品化，提供了开箱即用的官方支持。

值得注意的是，/goal 命令的引入实际上将人机交互模式从「人类在环」（Human-in-the-Loop）推向了「人类在环上」（Human-on-the-Loop）。两者的区别在于：Human-in-the-Loop 要求人类参与每一个决策节点，人类是流程的必要组成部分；而 Human-on-the-Loop 中，人类退居监督角色，系统自主运行，人类仅在必要时介入干预。这一概念在自动驾驶领域（SAE 自动化等级）和军事自主系统中已有成熟讨论，如今正被引入软件工程领域。/goal 命令通过 Token 预算机制和目标评估检查点，为开发者保留了监督和干预的能力，同时将逐步操作的控制权交给了 AI 代理。

技术实现：基于 Prompt 注入的巧妙设计

从代码仓库来看，/goal 功能的实现方式相当优雅，主要依赖两个 Prompt 模板：

goals/continuation.md：每一轮（turn）结束时自动注入的「续航提示」。它引导模型评估当前进度并决定下一步行动，让模型完成一个步骤后不会停下来等待用户输入，而是自动审视目标完成情况并继续推进。
goals/budget_limit.md：负责处理预算耗尽的情况。当 Token 消耗接近或达到预设上限时，引导模型优雅地停止执行，而非突然中断。

这里的「turn」是大语言模型对话系统中的基本交互单位，指一次完整的请求-响应周期。在传统对话中，每个 turn 通常对应一次用户输入和一次模型输出。而在 /goal 模式下，Codex CLI 在每个 turn 结束后自动注入 continuation prompt 作为下一轮的「伪用户输入」，从而在不需要真实用户参与的情况下驱动对话继续。这种技术有时也被称为「自我提示」（Self-Prompting）或「内循环提示注入」（Inner-Loop Prompt Injection），它巧妙地利用了大语言模型的对话接口设计——模型本身并不区分提示来自真实用户还是系统自动生成，只要上下文窗口中的消息序列合理，模型就会持续生成有意义的响应。

这种通过 Prompt 工程而非硬编码逻辑来实现代理循环的方式，体现了当前 AI 工程的一个重要趋势：用自然语言指令控制代理行为，而不是依赖复杂的程序逻辑。在传统软件工程中，类似的自动化循环通常需要通过状态机（State Machine）或行为树（Behavior Tree）来实现——开发者必须预先定义所有可能的状态、转换条件和异常处理路径。这种方式虽然精确可控，但面对开放式任务时极其脆弱，因为无法穷举所有可能的情况。而 Prompt 工程的方式将控制逻辑「软化」为自然语言指令，利用大语言模型的泛化推理能力来处理各种未预见的情况。当然，这种方式也引入了新的挑战：Prompt 的微小措辞变化可能导致代理行为的显著差异，调试和可复现性也比传统代码更难保证。

这一问题在学术界被称为 Prompt 敏感性（Prompt Sensitivity）或 Prompt 脆弱性（Prompt Brittleness）。为应对这一挑战，业界正在发展 Prompt 工程的可观测性（Observability）工具链，包括 LangSmith、Braintrust 等平台，它们允许开发者追踪每一轮代理决策的推理过程、Token 消耗和行为轨迹。对于 /goal 这样的自主循环功能，可观测性尤为重要——当代理在第 15 轮迭代中做出了错误决策，开发者需要能够回溯并理解是哪个环节的 Prompt 解读出了偏差。此外，Prompt 版本管理和 A/B 测试也正在成为 AI 工程的标准实践，帮助团队系统性地优化和维护 Prompt 模板的质量。

为什么 /goal 功能值得关注

代理式编程的关键演进

/goal 命令代表了 AI 编码工具从「助手」向「代理」转变的关键一步。助手模式下，AI 被动响应指令；代理模式下，AI 主动推进任务。这种转变对处理复杂的多步骤编程任务尤为重要——比如重构一个模块、实现一个完整功能、或修复一系列相关 Bug。

从 AI 代理架构的学术研究角度来看，/goal 功能的设计与近年来几种主流代理框架有密切关联。ReAct（Reasoning + Acting）框架由 Yao 等人于 2022 年提出，其核心思想是让模型交替进行推理（Reasoning）和行动（Acting），每次行动后根据环境反馈调整推理方向。Plan-and-Execute 模式则更进一步，先让模型制定一个完整的执行计划，然后逐步执行并根据实际情况动态调整计划。Codex CLI 的 /goal 实现更接近 ReAct 模式——它并不要求模型预先规划所有步骤，而是在每个 turn 中根据当前状态决定下一步行动，这种方式在面对不确定性较高的编程任务时更具灵活性。

Token 预算机制保障可控性

OpenAI 在设计 /goal 功能时加入了 Token 预算限制，这是一个务实的安全阀。自主循环的 AI 代理如果没有停止条件，可能陷入无限循环或产生高额 API 费用。预算机制确保即使目标评估出现偏差，系统也会在可控范围内停止。

要理解 Token 预算的实际意义，需要了解大语言模型的计费基础。Token 是 LLM 处理文本的基本单位，大致相当于一个英文单词的 3/4 或一个中文字符。每次 API 调用都会消耗输入 Token（发送给模型的上下文）和输出 Token（模型生成的响应），两者分别计费且输出 Token 通常更贵。在 /goal 的自主循环中，每一轮迭代都会累积上下文——之前的对话历史、代码文件内容、命令执行结果等都会作为输入 Token 发送给模型。这意味着随着循环轮次增加，单轮的 Token 消耗会加速增长（除非实施上下文压缩策略）。

这里的上下文压缩策略是当前 AI 代理工程中的核心挑战之一。大语言模型的上下文窗口（Context Window）是指模型单次推理时能处理的最大 Token 数量，目前主流模型的上下文窗口从 128K 到 200K Token 不等。在 /goal 的自主循环中，每轮迭代的对话历史、代码内容和执行结果都会累积在上下文中，很快就会逼近窗口上限。常见的压缩策略包括：滑动窗口（丢弃最早的对话轮次）、摘要压缩（让模型将历史对话压缩为简短摘要）、以及选择性保留（只保留与当前目标最相关的上下文片段）。Codex CLI 如何处理这一问题直接影响 /goal 功能在长任务中的可靠性。

一个复杂的重构任务可能需要数十轮迭代，如果不设预算上限，Token 消耗可能达到数十万甚至上百万，对应的 API 费用可能从几美元飙升到几十美元。budget_limit.md 模板的作用就是在接近预算上限时，引导模型总结当前进度、保存中间状态，并给出后续建议，而不是在 Token 耗尽时被系统强制截断导致工作丢失。

安全沙箱与权限控制

当 AI 代理被授权自主执行 Shell 命令和修改文件时，安全性成为不可忽视的维度。一个错误的 rm -rf 命令或对生产配置文件的误修改可能造成严重后果。Codex CLI 为此提供了多级权限模式：suggest 模式仅建议操作、auto-edit 模式允许自动编辑文件但需确认命令执行、full-auto 模式则完全自主。此外，Codex CLI 利用容器化或操作系统级沙箱来隔离代理的执行环境，限制其文件系统访问范围和网络权限。这种分层权限设计在 /goal 的长时间自主运行场景中尤为关键，因为循环轮次越多，出现意外操作的概率越高。开发者在使用 /goal 功能时，需要根据任务的风险等级选择合适的权限模式，在自主性和安全性之间取得平衡。

开源 AI 编码代理竞争加剧

Codex CLI 作为 OpenAI 基于 Rust 实现的开源项目，此次更新也反映了 AI 编码代理领域的激烈竞争。选择 Rust 作为实现语言本身就是一个值得注意的技术决策——Rust 的内存安全保证和零成本抽象特性使其特别适合构建需要长时间运行的代理系统，避免了 Python 等动态语言在长时间运行时可能出现的内存泄漏和性能退化问题，同时其编译为原生二进制的特性也让 CLI 工具的分发和启动速度更优。

Claude Code、Cursor、Aider 等工具都在持续增强自主执行能力，/goal 命令的加入让 Codex CLI 在功能完整度上更具竞争力。当前 AI 编码代理的竞争格局大致可以分为几个方向：Cursor 和 Windsurf 走的是 IDE 深度集成路线，将 AI 代理能力嵌入编辑器，提供丰富的可视化交互；Claude Code 和 Codex CLI 则走终端原生路线，面向偏好命令行工作流的开发者，强调与现有 Unix 工具链的无缝集成；Aider 作为较早的开源项目，以其对 Git 工作流的深度支持和多模型兼容性著称。值得注意的是，这些工具在自主执行能力上的竞争正在加速——Claude Code 早已支持类似的持续执行模式，Cursor 的 Agent 模式也在不断增强。/goal 命令的推出，某种程度上是 Codex CLI 在补齐与竞品的功能差距，同时也借助 OpenAI 自身模型的优势（如对 Codex CLI 专属 Prompt 的优化调校）来建立差异化竞争力。

实际应用场景

/goal 命令在以下场景中特别实用：

测试驱动开发：设定目标为「让所有测试通过」，Codex CLI 会持续修改代码直到测试全部通过。这与 TDD（Test-Driven Development）的红-绿-重构循环天然契合——测试结果提供了明确的、可机器验证的成功标准，代理可以在每轮迭代后运行测试套件来客观评估进度，而不依赖模型的主观判断。
代码迁移：设定目标为「将所有 JavaScript 文件转换为 TypeScript」，代理逐个文件处理。这类任务通常涉及数十甚至上百个文件，手动逐一转换既枯燥又容易出错，而代理可以在每个文件转换后运行 TypeScript 编译器检查类型错误，形成可靠的反馈循环。
Bug 修复：描述期望行为作为目标，让代理自主定位和修复问题
代码重构：设定重构标准作为目标，代理自动识别并改造不符合规范的代码

需要注意的是，/goal 功能的效果高度依赖目标描述的质量。一个好的目标应该是具体的、可验证的——「让所有测试通过」比「改善代码质量」更适合作为 /goal 的输入，因为前者有明确的成功标准（测试通过/失败），而后者过于模糊，可能导致代理在无意义的修改中消耗预算。

这一观点与软件工程中形式化规约（Formal Specification）的理念相呼应。在传统软件验证中，形式化规约使用数学语言精确描述系统应满足的性质，验证工具可以自动检查实现是否符合规约。/goal 功能面临的核心挑战正是：自然语言描述的目标缺乏形式化的验证标准。「让所有测试通过」之所以效果好，是因为测试套件本质上就是一种可执行的形式化规约。而对于「改善代码质量」这类模糊目标，模型只能依赖其训练数据中的隐式标准来判断，这种判断既不可靠也不可复现。未来的发展方向可能是将自然语言目标与可执行的验证条件（如 lint 规则、类型检查、性能基准）结合，让代理同时拥有灵活的自然语言理解能力和严格的机器验证标准。

总结

Codex CLI 0.128.0 的 /goal 命令在实现上看似简单——主要是两个 Prompt 模板——但它代表了一种重要的范式转变：AI 编码工具正在从响应式的对话助手，进化为目标驱动的自主代理。

随着这类功能逐步成熟，开发者与 AI 的协作方式将发生根本性改变：从「告诉 AI 每一步该做什么」变为「告诉 AI 最终要达成什么」。这种转变在软件工程领域有一个更宏大的对应概念——声明式编程（Declarative Programming）与命令式编程（Imperative Programming）的区别。SQL 就是声明式的典型代表：你描述想要什么数据，而不是告诉数据库如何去查找。/goal 命令将类似的理念引入了人机协作：开发者声明期望的最终状态，AI 代理自主规划和执行达成目标的路径。对于关注 AI 编码代理发展的开发者来说，Codex CLI 的 /goal 功能值得实际体验和持续关注。

核心要点

Codex CLI 0.128.0 新增 /goal 命令，支持设定目标后自动循环执行直到目标完成或 token 预算耗尽
该功能是 Ralph Loop 模式的 OpenAI 官方实现，通过 continuation.md 和 budget_limit.md 两个 prompt 模板注入实现
采用 prompt 工程而非硬编码逻辑来控制代理行为，体现了当前 AI 工程的重要趋势
Token 预算机制作为安全阀，防止自主循环代理陷入无限执行或产生过高费用
多级权限模式和安全沙箱机制为自主执行提供安全保障
标志着 AI 编码工具从响应式助手向目标驱动的自主代理的范式转变