Claude Code /loop 和 Codex Goal Mode 熬夜跑 Agent 实战指南

大型重构任务挂了一整夜，早上起来你还得继续按 Enter

你交给 Claude Code 一个跨多个文件的重构任务，或者让它去抓一个烦人的 flaky test。问题在于 agent 只跑一个 turn 就停了，而你又不可能守在屏幕前每隔几分钟就按一下 continue。Claude Code 的 /loop、/goal 和 Codex CLI 的 Goal Mode 就是为了填补这个空缺而生的——但每种工具触发下一轮的方式差异很大，理解错了会让你烧掉无意义的 API credit，或者 agent 过早就停止工作。

为什么 one-turn 模型扛不住长任务

标准 agent 流程是一个闭环：你发 prompt，agent 读文件、跑 CLI 命令、改代码，然后把控制权还给你。这个模式适合原子级别的操作，比如加一个 null check。但面对持续数小时甚至数天的任务——迁移整个代码库、大范围重构、抓 flaky test，或者让一个 PR 一直保持绿灯直到合并——它就扛不住了。以前的土办法是每隔几分钟 paste 一次 continue 命令，或者自己写 shell 脚本包住 CLI。现在 Claude Code 和 Codex CLI 都把这个能力集成进了二进制文件，只是各走各的路。

/loop of Claude Code：按时间驱动的自动化

/loop 命令就像一个内部调度器，管理当前会话中重复执行的任务——它是 session-scoped 的，任务跟随会话存在。有三种主要用法。固定节奏模式下，你声明一个时间间隔，比如 /loop 5m check deployment status，系统会把它映射成一个类似 cron 的日程，秒数会被四舍五入到最近的分钟，这样 agent 就会严格按照你设定的节奏触发。self-paced polling 模式则是留空时间间隔，让 Claude 自己管理节奏——每轮结束后，agent 会分析上下文，根据观察到的活动决定应该等一分钟还是一个小时。Maintenance mode 就是不加任何参数调用 /loop，触发一个默认的日常维护程序，管理 PR comment、CI failure 和分支健康状况——你可以通过 .claude/loop.md 文件全局自定义这个行为。

/goal of Claude Code：按完成条件驱动的自动化

与 /loop 按时间节奏运行不同，/goal 命令——从 2.1.139 版本引入——把重心转移到完成状态上。你定义一个成功条件，每轮结束后，一个更轻量的模型（通常是 Haiku）会把对话历史与那个目标进行比对。如果 evaluator 回答"还没完"，agent 就再跑一个 turn；如果回答"搞定了"，goal 就被标记为完成。这个机制不替代 permission 层，它只是一个permanent hook 用来评估进度——对于那种"跑测试套件直到全部 pass"的任务来说，它表现得极为出色。简化的例子：建一个包含错误函数的目录和对应的测试，然后跑 /goal npx jest --exit 0——agent 会一直循环直到该命令以 0 状态码退出。

Codex CLI 的 Goal Mode：面向多日长任务

OpenAI Codex CLI 的 goal 思路是为持久性设计的，目标是将任务跨度延长到多天而不是几个小时。通过配置启用后（或者通过 --enable goals 标志），agent 通过特定状态运行：pursuing、paused、achieved 和 budget-limited。需要记住的一点：自主权越高，你需要设置的监督级别也得越高——原则被直接说明：始终把最终的 diff 当作一个初级工程师的草稿，不要因为 goal 报告"achieved"就直接合并。

实际例子：在 Docker Sandbox 中运行 Pi coding agent 处理 Java 项目

让 agent 跑上几个小时而不担心它碰到真实的机器，把它跟隔离的 sandbox 配对是下一步合理的做法。Docker Sandbox 为 AI coding agent 提供隔离的 microVM 环境——每个 sandbox 有独立的 Docker daemon、文件系统和网络，所以 agent 可以在完全隔离于你本机的环境中构建容器、安装包、跑开发工具和修改文件。一个具体的例子是社区正在用的：把 Docker Sandbox 和 Pi 配对——Pi 是一个极简的 coding harness 终端，支持 TypeScript extension、skill、prompt template 和 package——来搭建一个可复用的 Java 开发环境。这个组合给你一个简洁的模式：/goal 或 /loop 负责调度循环，Docker Sandbox 负责隔离，而你只需要每天结束前 review diff，而不用全程盯着机器。

Checklist：长任务该用哪个

• Task atomic（加 null check、解释函数）——不需要 /loop 或 /goal，正常跑一个 turn 就行。
• 固定节奏重复的任务（如每隔 5 分钟检查部署状态）——用 /loop 加明确的时间间隔。
• 不确定什么时候能完成但有明确 pass/fail 条件（测试套件、build）——用 /goal 加具体的检查命令。
• 多日任务，需要暂停和继续能力——考虑用 Codex Goal Mode，带 pursuing/paused/achieved 状态。
• 无论选哪种机制，如果 agent 有权限安装包或在当前 repo 范围外跑命令，就在 Docker Sandbox 里跑。

接下来该做的事

如果你在用 Claude Code，先在一个有现成测试套件的真实 bug 上试试 /goal——这是最安全的场景，可以让你感受 evaluator 机制。如果你需要跨多个工作日的长任务，在 production repo 上启用 --enable goals 标志之前，先仔细阅读 Codex CLI Goal Mode 的配置部分。无论选什么工具，都不要跳过最后 review diff 这一步——它仍然是那个 junior engineer，只是一个永远不会疲倦的 junior。