长程AI Agent深度解析：/loop、/goal与Codex Goal Mode对比

无论你使用哪款 AI 编程智能体，最终都会撞上同一堵根本性的架构之墙：任务耗时超过单轮对话的极限，而作为驾驭它的人类开发者，你显然有比连续六小时按回车键更重要的事。无论是执行复杂的代码库迁移、实施大规模重构、追踪出了名的不稳定测试，还是维护一个 Pull Request 直至 CI 变绿——你面对的早已不是简单的一次性提示词，而是漫长的战役。到 2026 年，Anthropic 和 OpenAI 都已推出原生的解决方案。Claude Code 有 /loop 和 /goal 这两种独立机制，而 OpenAI 的 Codex CLI 则实现了自有的 /goal。尽管它们的目标一致——让智能体无需人工持续干预即可持续运行，但在何时触发下一轮的决策逻辑上，两者存在显著差异。误解这些细节，要么浪费 API 额度，要么导致智能体过早终止工作循环。

单轮范式的问题

在标准的智能体工作流中，交互是一个封闭的往返：你提交提示词，智能体解析文件、执行 CLI 命令、修改代码，然后交还控制权。这种模式非常适合原子级任务，比如"写一个空值检查"或"解释这个工具函数"。然而，当任务需要数小时甚至数天时，这种范式就会在重压下崩溃。历史上，开发者只能靠手工 workaround：每隔几分钟重新粘贴 continue 命令，或者写自定义 shell 脚本包装 CLI。现代 AI 工具已经将这些能力直接集成到二进制文件中，但它们走上了不同的路径以达到同一个目的。

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

/loop 命令是一个内置的任务重复调度器，作用于你当前活跃的会话中。它明确是会话作用域的，这意味着只要对话存活，任务就会持续存在。

主要有三种使用方式：

固定节奏：你可以指定一个间隔，比如 /loop 5m check deployment status。系统会将其映射为类 cron 的调度计划。秒数会四舍五入到最近的整分钟，确保智能体按照你定义的心跳节奏触发。

自主节奏轮询：不指定间隔，则指示 Claude 自己管理节奏。每轮迭代后，智能体会分析上下文，根据观察到的活动情况决定是等待一分钟还是长达一小时。它通常会优先使用 Monitor 工具来流式输出结果，而不是执行开销昂贵的提示词重跑。

维护模式：调用时不带任何参数，则触发一个默认例程，管理 PR 评论、CI 失败和分支健康状况。你可以通过 .claude/loop.md 文件全局自定义此行为。

Claude Code 的 /goal：条件驱动的自动化

/goal 命令于 2.1.139 版本引入，它将焦点从时间间隔转移到了基于状态的完成判断。你定义一个成功条件，每轮对话结束后，一个次要的轻量级模型（通常是 Haiku）会对照你的目标评估对话历史。

逻辑：如果评估器说"否"，智能体执行下一轮。如果"是"，则目标标记为完成。

实现：它不替换权限层；它只是作为一个持久化的钩子来评估进度。它在"运行测试套件直到全部通过"这类任务上表现出色。

Codex /goal：多日目标

OpenAI 的 Codex CLI 对目标的处理方式以韧性为核心。它旨在处理跨越多天的任务。通过配置启用（或 --enable goals 标志）后，智能体会沿着特定状态运作：pursuing（追求中）、paused（暂停）、achieved（已达成）和 budget-limited（额度耗尽）。

自主性与审查的权衡：与所有自主智能体一样，自由度越高，就越需要加强监督。请始终将最终的 diff 视为来自初级工程师的草稿。

实践实现：一个最小化示例

要测试这个功能，创建一个包含 bug 函数和对应测试套件的目录。以 Node.js 配合 Jest 为例，你只需运行：

/goal `npx jest` exits 0

智能体会解析测试失败、修改源代码，并反复尝试运行命令，直到测试套件返回退出码 0。这展示了条件循环相比标准定时轮询的强大之处。

技术考量与边缘情况

当部署需要运行数小时乃至数天的智能体时，请考虑以下几点：

Token 预算：始终关注成本。如果条件定义不当或环境发生了阻止问题解决的变化，一个失控的循环会消耗大量 API 额度。

环境稳定性：如果你的智能体依赖外部 API 或数据库状态，请确保网络连接和认证 Token 是持久化的。对于长期任务，使用无头服务器或远程持久化机器比本地笔记本更优。

错误处理：一个定义良好的目标应该包含约束条件。如果你的条件是"修复所有错误"，请同时加入"最大尝试次数"的约束，以避免陷入幻觉的智能体进入无限循环。

工具可靠性：使用 Monitor 或 ScheduleWakeup 这类工具时，请注意它们依赖于特定的终端集成。如果你使用高级功能，请确保你的 shell 环境支持后台流式传输。

从本地实验到长期的线上任务生产，需要一种思维方式的转变。你不是在写代码，而是在维护一个流程。使用 --verbose 标志来调试智能体为何可能陷入循环。当智能体报告"unmet"状态时，通常意味着它遇到了需要人工干预的终结性错误。不要把这些工具当作"设置后就不管"的黑箱。它们的最佳定位是高性能助手——它们生成的每个 commit 都需要人工最终审查。

在基于定时器的 /loop 和基于条件的 /goal 之间做出选择，关键在于你是否清楚自己的终点线。如果终点线是基于状态的（比如测试通过），就用条件驱动。如果任务需要周期性轮询（比如等待一个长时间运行的 CI 流程），就用定时器。将这些与稳健的日志记录和人工 PR 审查相结合，你就能在保持开发速度的同时显著夺回自己的时间。