1. Goal 模式到底在解决什么问题
我最初接触 Codex 的 Goal 模式，是被它的名字吸引的。过去我们用 Codex 做代码任务，基本是一问一答：我告诉它"把这个接口改一下"，它改完，对话结束，我再告诉它下一件事。这种方式对简单任务没问题，但一旦任务是"把这个模块的测试补齐并保证全部通过"、"把整个项目的 TypeScript 类型错误清零"这类多步骤、需要自主决策的工作，传统交互就非常低效——你得一直盯着，不断给它喂下一步指令。
Goal 模式做的正是这件事：你把最终目标交给它，它自己拆解步骤、执行命令、检查结果、失败重试、继续推进，直到它认为目标完成，或者遇到它自己无法解决的障碍停下来问你。这背后有一套完整的"自动续跑"和"任务完成判定"机制，值得认真拆一拆。
我写这篇是系列第二篇，假设你已经把 Codex 装好、跑通过基础对话。如果你还在配置阶段卡着，这篇的最后一章会覆盖几个高频的配置报错，包括那个很典型的cc switch local proxy failed while handling codex endpoint问题，我踩过的坑都会写出来。
2. 自动续跑机制：Codex 是怎么在无人看管下持续干活的
2.1 续跑的底层循环：不是"一直跑"，而是"小步快跑"
Goal 模式的自动续跑，不是像脚本一样从头到尾执行一个固定流程。它是一个循环：思考 → 调工具 → 观察结果 → 再思考。每一轮循环结束，Codex 会评估当前状态，然后决定下一步是继续执行、重试、还是停下来汇报。
以一个实际的例子来说明。我做过一次这样的任务：给一个 Python 项目补充数据校验逻辑，要求所有失败场景都有单元测试覆盖。这个目标听起来简单，但拆开之后涉及：阅读现有代码、确定校验规则、修改业务逻辑、编写测试、运行测试、修复失败的测试。如果让我手动一条条下指令，可能要发二十几条消息。Goal 模式下，我只需要说清楚目标和验收标准，然后让它跑。
实际运行时，Codex 的每一轮动作都是原子的。它会先读取一个文件，然后决定改哪一行，再执行测试命令，观察输出。每一个动作完成，它都会把自己的状态写入会话记录，这样即使进程中断，重新启动时也能从最近的断点继续。这个机制有点像游戏存档——不是每一秒都在存，但关键的转场点一定存。
2.2 续跑触发的三种时机
自动续跑并不是无条件进行的。我观察下来，Codex 会在三种情况下主动推进下一轮：
第一，工具调用成功并且结果符合预期。比如测试命令返回PASS，它会自动进入下一个子任务。
第二，工具调用失败，但错误信息给了它新的线索。比如编译报错提示某个函数不存在，它会去查找函数定义并修正。这种失败其实是推进力，每次失败都排除了一个错误路径。
第三，任务列表中存在尚未完成且优先级更高的子目标。Goal 模式通常会先建立一个小目标队列，完成一项就划掉一项，自动进入下一项。
这里有个很容易误解的点："自动续跑"不等于"无限续跑"。Codex 对单次会话的步数有限制，默认配置下如果反复尝试同一步并且总是得到相同的结果，它会产生一个固定的失败认知，这时候它会主动停下来向你汇报，而不是死循环钻进牛角尖。这个停止机制很重要，它事实上扮演了"安全阀"的角色。
2.3 续跑过程的上下文管理
自动续跑最大的技术难点不是执行，而是上下文管理。Codex 每轮思考都会积累大量的工具输出，如果全部塞给模型，上下文窗口很快就会被撑爆。
实际处理上，Codex 会做两件事：一是对工具输出做截断和摘要，长的测试日志只保留错误摘要和退出码；二是维护一个持久化的工作目录和任务清单，上下文里只保留当前焦点相关的信息。这有点像大脑的工作记忆和长期记忆的区分——不是所有信息都放在桌面上，而是把关键信息归档到文件里，需要时再取出来。
这就解释了为什么 Goal 模式下的任务往往需要配合AGENTS.md这类项目说明文档。Codex 会在续跑过程中反复读取这些文档来保持上下文对齐。如果你的项目没有写清楚目标和约束，它会频繁停下来问你，续跑效率就会大打折扣。
2.4 断点恢复的实际操作
有一次我在跑一个长的重构任务，机器中途重启了。重新打开 Codex 恢复会话之后，它没有从头开始，而是读取会话历史中的状态快照，从最后完成的动作继续推进。我当时挺惊讶，因为在大部分对话式工具里，中断基本等于任务作废。
后来我查了一下机制，原来 Codex 在 Goal 模式的每个重要节点都会保存两点信息：一是当前已完成动作的摘要，二是剩余待办列表。恢复的时候它会核对这两个信息，如果发现待办列表和当前文件状态不一致（比如某个文件已经被手动改过），它会重新读文件来校准认知。
2.5 什么情况会打断续跑
虽然 Goal 模式强调自主，但有些情况它一定会停下来找你：
- 它发现有两种以上路径都可以完成任务，且它没有足够信息判断哪条更好。
- 某个操作有副作用风险，比如删除文件、覆盖大范围代码、修改数据库结构。
- 连续多次尝试同一动作失败，且错误类型没有变化。
- 用户配置了
require_user_confirmation这样的安全策略，要求敏感操作前必须确认。
这个行为设计非常像带一个有自主性但知道边界的高级工程师。你要做的不是事无巨细地指挥它，而是把边界和安全策略定义清楚。
3. 任务完成判定：谁说了算
3.1 三重判定体系：自评 + 用户 + 显式验证
"任务完成"这个判断，很多第一次用 Goal 模式的人会有误解：以为 Codex 只要自己觉得做完了就收工。实际并非如此，它有三层判定机制叠加。
第一层是模型自评。Codex 在每一轮结束时会回顾目标，判断当前状态是否满足目标的显式描述。比如目标的描述是"所有测试通过"，而测试输出确实全部PASS，那它就会进入收尾流程。
第二层是可执行验证。这是最可靠的一层。Codex 强烈倾向于用实际命令验证而不是靠读代码判断。它在改动代码之后，通常至少会运行一次测试命令、类型检查或者构建命令来确认改动没有引入回归。我会要求它在目标里显式写明"以测试结果为准"，这样它会更严格。
第三层是用户确认。在最关键的目标上，Codex 会把最终结论和关键证据（比如测试报告摘要）展示给你，由你来做最终裁决。它不是自动收工，而是"提交审核"。
3.2 判定标准怎么定义：Goal 描述里的验收条件
在实际操作中我发现，任务完成判定是否准确，90% 取决于你在 Goal 描述里怎么定义验收条件。如果你只说"帮我优化这个模块的性能"，它可能改了三个函数就宣布完成——因为没有客观的验证标准可供判断。
正确的做法是把验收条件写得可观测、可执行。举个例子，一个合理的 Goal 描述是这样：
优化
process_data函数的性能。完成标准：对 10 万行输入数据的处理时间从当前约 8 秒降到 3 秒以内，原有单元测试全部通过。性能测试用benchmark.py验证。
这样的描述给 Codex 提供了三个判断锚点：具体的函数名（定位范围）、可量化的性能目标（判定标准）、验证方式（执行命令）。它的完成判定就从"我觉得改好了"变成"测试数据证明达标了"。
我见过太多人把 Goal 写得太抽象，结果就是 Codex 努力干了一堆活，但判断完成时双方对"完成"的理解不一致。所以记住：让 Codex 自己检验自己，而不是让它自己定义标准。
3.3 验证命令的优先级：为什么测试结果胜过模型自信
Codex 的规范里有一个原则我特别认同：当模型自评和执行结果冲突时，以执行结果为准。也就是说，如果它读代码觉得逻辑没问题，但测试就是红着，那它不能宣布任务完成。它会先把测试修绿，再走完成流程。
这个原则也意味着，如果你的项目没有测试基础设施，Goal 模式完成判定的可靠性会大打折扣。它只能依赖编译、构建这类基础检查，而这类检查覆盖不到逻辑正确性。所以在启用 Goal 模式做重构前，最好先给项目补上基础测试。这不是 Codex 的缺陷，而是任何自动化完成判定的通用前提——你没有可执行的验收标准，机器就无从判断。
3.4 一个完整完成流程的现场还原
我用一个真实任务还原完整流程。目标是"给购物车模块加上优惠券分摊功能，并补充单测"。整个流程大致是这样的：
第一轮，Codex 读取购物车相关文件，梳理计算逻辑，建立任务清单：读取现有类结构 → 设计分摊算法 → 修改计算逻辑 → 补测试 → 跑测试。
中间的每一轮它都在干活和自检交替进行。修改完分摊逻辑后，它补写了一个测试文件覆盖三种场景：整单满减、多商品按比例分摊、分摊金额四舍五入边界。
最后一轮，它运行pytest，看到全部通过，然后把改动摘要和测试结果列出来，停在待确认状态。我检查了关键的分摊计算逻辑，发现问题：按比例分摊时遇到金额为 0 的商品会有除零风险，测试里没覆盖这个场景。
这说明什么？说明三层判定体系里用户确认不是走形式，它仍然是最终的安全网。模型自评和测试验证覆盖的是"它认为的验收条件"，而用户确认补上的是"你真正关心的验收条件"。所以使用 Goal 模式时，别因为自动化就放弃最后的审查，尤其是涉及财务计算、权限控制这类高风险逻辑时。
3.5 多目标拆解时的完成策略
当 Goal 涉及多个子目标时，Codex 通常会把它们按依赖关系排序，完成顺序不可随意颠倒。比如"重构 A 模块再跑集成测试"，它就一定先改完 A 再跑测试，而不是先跑测试看失败。
这种情况下，完成判定是逐级传递的：每个子目标有自己的验收条件，全部子目标验收通过，整体目标才算完成。这中间如果某个子目标被卡住，它会停下来汇报，而不是跳过它继续做后面的。
我建议你在描述复杂目标时，用编号把子目标和依赖关系写清楚。这样 Codex 不仅知道每个环节的验收条件，还知道先后顺序，判断完成时也会更精确。
4. Goal 自动续跑的运行闭环：一次全流程实操
4.1 完整配置一个 Goal 任务
先说配置。Codex 使用配置文件来维持行为一致性，命令行接口有对应的子命令。安装之后，每一步配置都要留意系统提示的输出信息，最好逐行检查。
任务的启动方式通常是这样的：
codex "给 shopping_cart.py 添加优惠券分摊功能，要求： 1. 支持按商品金额比例分摊优惠 2. 单测覆盖比例分摊、整单减免、除零边界三个场景 3. 完成标准：pytest 全部通过，新增测试覆盖率不低于 90%"如果不指定模式，Codex 默认走交互模式；要使用目标模式，需要显式声明使用对应的启动方式。实际使用时，你自己去确认当前 CLI 版本取的是哪种模式名称，以官方帮助为准，不同版本的叫法可能有差异。
配置里有一个关键参数是最大迭代次数。如果你预期任务很复杂，给足次数限制，避免中途因为步数耗尽而停下来。
exec_timeout: 600 working_dir: /path/to/project这个配置的意思是单次命令执行最多 10 分钟，工作目录指向项目根目录。工作目录如果设错，Codex 会在错误的路径下找文件，后续所有判断都会乱套。
4.2 启动后的观察策略
启动后，任务如果是长耗时的，建议以分钟为单位观察输出。Codex 的工作模式是串行的，它不会同时执行两个互不相干的工具调用，因为它需要保持对项目状态的掌控。
我在实践中总结出一个观察策略：不要实时盯着滚动日志，而是定期检查它产出的中间文件和状态摘要。因为 Goal 模式每完成一个阶段会输出一个阶段摘要，里面有关键变更点。你只需要看摘要就能判断方向是否跑偏，而不用逐行看日志。
如果发现它跑偏了，比如在改一个无关的文件，可以打断它，在回复里纠正方向，然后让它继续。纠正之后它会把新信息合并进上下文，继续自动跑。
4.3 验证最终完成的三个动作
当 Codex 报告任务完成时，我建议做三个手动验证动作，别直接收尾：
第一个动作，独立跑一遍它声称通过的验证命令。不要用它的输出截图，自己在终端重新执行一遍。这一步排除"模型误报"或"环境差异"。
第二个动作，检查差异化改动清单。Codex 在收尾时会列出改动文件清单，我一般会用git diff --stat核对这些文件，顺便看一眼有没有意外改动。有一次它改了两个我完全没预期到的文件，排查后发现是某个工具调用了自动格式化的功能，虽然无害，但这种意外还是值得注意。
第三个动作，手动触发一两个边角场景。比如它补了一个接口函数，你手动传一个极端的输入值，确认行为符合预期。这步是补上测试盲区，因为测试终归是它自己写的，容易有"自己填空自己判对"的问题。
4.4 失败后的自动重试与降级
自动续跑的过程中，失败一定会发生。关键在于 Codex 怎么对待失败。我观察到它有几种典型的失败处理模式：
- 命令失败但输出有线索 → 直接修复后重试。
- 命令失败且输出无意义 → 更换验证方式，比如改用调试输出。
- 多个修复尝试均失败 → 向用户汇报，附上尝试记录和当前状态，请求建议。
这里有个经验规律：连续三次修复尝试得到的结果基本相同，说明不是小问题，这时候不要让它继续耗，直接介入。给它提供新的方向，比如换一种实现方式，而不是让它重复走同一条路。
5. 常见问题与排查技巧实录
5.1 常见的报错与对策速查
日常使用 Codex 的过程中，我收集了几类高频问题，直接整理成表格，方便对照解决。
| 现象 | 典型原因 | 处理方案 |
|---|---|---|
| 启动任务时提示本地代理切换失败 | 本地网络状态异常，且系统试图切换连接通道时找不到可用路径 | 检查相关配置中的 endpoint 指向是否正确，确认本地网络状态正常后重启任务 |
| 提示存在不被识别的配置项 | 配置文件里写了错位的键名 | 逐行核对配置项名称，删除无效字段，只保留当前版本支持的键 |
| 一直显示重连中 | 长连接被中断，且会话无法恢复 | 先确认网络稳定性，再重启会话；中断频繁时优先检查配置里的连接超时参数 |
| 模型名称不兼容 | 配置里的模型名与当前 CLI 版本支持的范围不匹配 | 换成兼容的模型指定方式，参考当前版本的支持列表 |
| 任务跑到一半停在思考状态 | 上下文过长或遇到不可决策的分支 | 打断它，浓缩当前结论，重新明确目标后让它继续 |
有位朋友的报错信息我印象很深，它说某个目标模块执行失败。排查后发现根本不是代码问题，而是他在配置里把项目路径写错了，导致 Codex 在空目录里找不到任何模块。这类环境类报错经常伪装成业务逻辑问题，排查时先看路径和配置，再查代码。
5.2 "本地代理切换失败"背后的逻辑判断
把最常见的那个报错单独拎出来说：cc switch local proxy failed while handling codex endpoint。
这个报错的关键在于"切换"两个字。Codex 在面对端点请求时，会尝试选择一条可用的通信通道。报错出现在本地代理无法被切换到目标状态的情况下。我遇到这个报错时常伴随网络重启或者 DNS 波动。
排查步骤我建议按顺序来：先确认本机网络的连通性是否正常（比如访问一个常用站点）；再检查 Codex 配置中的端点地址是否清晰、可解析；最后看系统层面是否有代理类软件正在抢占端口。如果这三步都正常，基本就是临时性故障，重启 Codex 进程往往能解决。
5.3 配置文件里那些容易踩的坑
配置文件有一套自己的规则，最容易踩的坑有三个。第一个是键名拼写错误，Codex 会提示存在不被识别的配置项。第二个是目录路径使用了相对路径，但工作目录是启动时的环境变量，任何相对路径都可能指向错误位置。第三个是模型名字配置成当前版本不支持的型号，任务一启动就会报错。
举个实际例子，有的报错信息原文是不支持某个模型，解决办法很简单：把配置里的模型名改回当前环境支持的范围。这类问题本质上都是版本匹配问题，不必过度分析。
这是我在项目里会放的配置模板，供参考：
model: 当前版本支持的模型标识 exec_timeout: 600 max_iterations: 50如果你刚接触 Codex，建议最开始用最小配置——只设置项目目录和模型名，其他都用默认值。减少变量，方便定位问题。
5.4 关于自动续跑的一些实战心得
最后分享几个我在实际使用中总结的体会。
第一个体会：Goal 模式的粒度不是越粗越好。有人说"既然它能自动跑，那我就把整个项目重写交给它"，这绝对是灾难。我试过一次让它做一个大范围跨模块重构，结果它改了二十多个文件，测试红了七天，最后我花了一整天才把改动回滚。正确做法是把大目标拆成几个中等粒度的目标，每个目标之间有清晰的验证节点。
第二个体会：写 Goal 描述时，把"不允许做什么"也写进去。比如"不要改动依赖配置文件"、"不要升级第三方库版本"，这类负向约束能避免很多意外。Codex 很擅长按照你给的边界活动，问题是你经常忘记给边界。
第三个体会：自动续跑会掩盖"错误的方向被高效执行"的问题。如果目标描述本身有偏差，它跑得越快，偏差被放大得越严重。所以前几个阶段摘要一定要勤检查，确认方向正确再放它继续。
第四个体会：关于任务完成判定，我对"测试全绿"保持适度的怀疑。因为测试是它自己写的，天然存在"自己出题自己做"的盲区。我的习惯是至少在最终审查时看一遍关键测试是不是真正覆盖了核心逻辑，而不是仅仅为了覆盖率数字凑场景。有一次它写的测试覆盖率到了 95%，但核心的一个数据一致性问题根本没测到，因为那个分支在入口处就被挡掉了。这种盲区只能靠人补。
6. 总结一点个人经验
Codex 的 Goal 模式是个非常趁手的工具，但它不是"丢一个目标就能不管"的神器。它的自动续跑建立在清晰的验收标准、充足的安全配置、以及你自己的阶段性审查之上。别把它当自动驾驶，把它当一位能力强但需要你定期校准方向的高级协作工程师。校准方向最省力的方式，就是在初始的目标描述里多花十分钟，把验收条件和禁止事项写清楚。这十分钟省下的是后面一小时甚至一天的返工时间。
