AI 长任务该怎么交给 Agent？先 /plan 定方向，再 /goal 执行到验收

这篇写给这样的人：你会用 ChatGPT，也听过 Codex、Claude Code、AI Agent，但还没真正让 AI 独立跑过一个长任务。

很多人第一次用编程 Agent，还是把它当成“更懂代码的聊天机器人”：

我问一句，它答一句。
我让它改一处，它改一处。
它停了，我再说一句“继续”。

这当然能用，但这不是 Agent 最有价值的地方。

真正的变化是：你可以给它一个清楚的目标、边界和验收标准，让它自己读文件、跑命令、改代码、看结果、再继续下一步。

一句话：

人负责判断方向、设定标准、评估结果；Agent 负责拆任务、执行、验证、修正。

如果你只想记住一个工作流，记这个：

/plan 先产出方案 → 人选方向 → /goal 执行第一个可验收阶段 → 人验收 → 再进入下一阶段

不要一上来追求“全自动”。先做一个能被评估的小闭环。

先给你一个能复制的最小练习

如果你今天只想试一次，可以先复制这个：

/plan 我想让 AI 帮我整理最近 24 小时某个主题的资料。
请先不要执行，只给我：
1. 最小流程；
2. 需要我提供什么；
3. 如何验收；
4. 哪些步骤不应该自动化。

等计划看起来靠谱，再复制第二段：

/goal 根据刚才确认的计划，只完成第一步：生成一份 Markdown 草稿。
完成标准：
1. 有标题；
2. 有 5 条资料；
3. 每条都有来源链接；
4. 标出不确定信息；
5. 不自动发布。
如果资料不足或来源不可靠，停止并说明原因。

注意最后一句：不自动发布。

新手第一次做长任务，最好先让 Agent 产出草稿，由人审核，再决定是否自动化。

/plan、/goal、/loop 到底有什么区别？

这些命令通常出现在 Codex、Claude Code、OpenClaw 这类 Agent 工具里。它们不是普通 ChatGPT 网页对话里的通用按钮，不同工具的名字和能力边界也会略有差异。

但心智模型是相通的。

/plan：先别动手，先把路线画出来

OpenAI Codex CLI 文档里，/plan 用来进入 plan mode，让 Codex 在实现前先提出执行计划。

它适合：

• 你还不确定怎么做；
• 任务可能影响很多文件；
• 你想先比较几条路线；
• 你需要确认成本、风险、回滚方案；
• 你不希望 Agent 一上来就改代码。

一句话：

/plan 是“请先想清楚，不要急着做”。

错误示范：

帮我重构整个账号系统

更好的写法：

/plan 我想把账号系统拆成 token 解析、session 加载、权限判断三个模块。
请先扫描代码，给我一个迁移计划：
1. 每一步改哪些文件；
2. 每一步如何验证；
3. 如果出问题怎么回滚；
4. 哪些地方风险最高。
不要先改代码。

这里你要的不是执行，而是判断。

/goal：目标清楚了，就持续执行到可验收

OpenAI Codex 的 Goal mode 会给 Codex 一个持久目标。这个目标既是起始提示，也是完成标准。Codex 会围绕它持续工作，并判断任务是否完成。

Claude Code 也有 /goal：它会设置一个完成条件，每轮结束后由一个小模型检查条件是否满足；如果没有满足，就继续下一轮。

但要注意边界：

• /goal 不是无限后台任务；
• 它通常绑定在当前线程/会话里；
• 会受暂停、清除、中断、预算、权限、环境和阻塞条件影响；
• 如果目标写得模糊，它可能“看起来很努力”，但你无法验收。

一句话：

/goal 是“目标已经明确，请持续工作，直到证据证明完成”。

例如：

/goal 修复 settings 页面保存后刷新丢失的问题。
完成标准：
1. 能按以下步骤复现旧问题：打开 /settings，切换 Enable alerts，点击 Save，刷新后状态不应丢失；
2. 修复后上述步骤通过；
3. 增加一个最小回归测试；
4. 相关测试通过；
5. 不改变现有 API 形状。
如果无法复现或测试环境无法运行，停止并报告阻塞原因。

这比“修一下 bug”强很多。

因为它告诉 Agent：

• 什么叫成功；
• 用什么证据证明成功；
• 哪些东西不能破坏；
• 遇到阻塞时不要装作完成。

/loop：不是目标，而是定时回来看看

Claude Code 的 /loop 更像一个会重复触发的巡检机制。

官方文档里的例子是：

/loop 5m check if the deployment finished and tell me what happened

也就是每 5 分钟回来检查一次部署是否结束。

它适合：

• 等 CI；
• 等部署；
• 盯 PR 评论；
• 定时检查某个状态；
• 做短周期巡检。

一句话：

/loop 是“隔一段时间回来检查或处理一次”。

它不是正式长期 cron 的替代品。Claude Code 文档也说明，/loop 属于 session-scoped scheduling：会话、机器、恢复状态、7 天过期等都会影响它。真正要长期稳定跑的任务，更适合用 cron、routine、GitHub Actions 或平台级定时任务。

什么时候用 /plan，什么时候用 /goal？

小白可以直接看这张表。

场景	推荐方式	原因
你还不知道怎么做	/plan	先让 Agent 扫描、比较路线、暴露风险
任务会改很多文件	先 /plan，再 /goal	先确定分阶段方案，再执行某个阶段
目标明确、可验证	/goal	可以让 Agent 连续执行直到达标
只是问一个概念	普通提问	没必要启动长任务
只改一行文案	普通 prompt	/goal 成本太高
等部署/等 CI	/loop	本质是定时检查，不是持续推理
每天/每小时做一次固定任务	cron / routine / 定时任务	这是自动化任务，不该绑在临时会话里
涉及付款、删库、群发、生产迁移	先人工确认	不要让 Agent 自己做不可逆动作

最稳的路线是：

先 /plan，把不确定性摊开；
人选一个小阶段；
再 /goal，让 Agent 执行到可验收；
人检查结果，再决定下一步。

一个好 /goal，不是“大提示词”，而是“验收合同”

OpenAI Cookbook 里说得很清楚：Goal 适合那些“终点清楚，但路径不确定”的任务，比如性能优化、修 flaky test、依赖迁移、多步重构、研究审计。

我建议把英文六要素翻译成小白能用的六个问题：

1. 要做到什么？
2. 怎么证明做到了？
3. 不能破坏什么？
4. 允许改哪里、用什么？
5. 每轮要记录什么？
6. 卡住时怎么停？

套成模板就是：

/goal 达成 <结果>，通过 <测试/指标/产物/报告> 验证，
同时保持 <约束> 不被破坏。
只允许使用/修改 <边界>。
每轮记录 <尝试、结果、下一步>。
如果 <阻塞条件>，停止并报告：已尝试路径、证据、阻塞点、需要人提供什么。

弱目标：

/goal 优化首页性能

强目标：

/goal 把首页可交互时间降到 1 秒以内，
通过本地性能报告验证，
同时保持现有测试通过。
只修改首页渲染链路相关文件。
每轮记录改动、指标变化和下一步实验。
如果本地无法稳定复现指标，停止并报告原因和替代验证方案。

为什么这很重要？

因为 Agent 最容易失败的地方，不是不会做事，而是：它以为完成了，但你没有办法验收。

真实案例和官方示例：长任务到底长什么样？

下面分清楚：哪些是我们实测，哪些是官方示例。

UseClaw 实测案例：AI HOT 小时报

今天我们做了一个真实的小自动化：

• 数据源：AI HOT 的公开接口 /api/public/items；
• 频率：每小时抓取一次；
• 逻辑：只看精选，按 URL 去重；
• 输出：整理成 UseClaw 小时报；
• 发布：发到 UseClaw 的 claw-daily；
• 保护：没有新内容就不发；运行过程保留日志，失败提醒可按平台能力配置。

这不是一个“问答任务”，而是一个长任务系统的雏形。

它里面已经有完整的 Agent 分工：

人负责	Agent/脚本负责
定义为什么收集	定时请求 API
决定收录标准	去重、整理、生成稿件
判断是否值得发布	有新内容才发布
看每日效果	记录运行历史和链接

这个任务如果用 /goal 描述，可以这样写：

/goal 构建一个每小时 AI 新闻收集与发布流程。
完成标准：
1. 能从 AI HOT items 接口抓取过去 1 小时精选内容；
2. 能按 URL 去重，避免重复发布；
3. 能生成 UseClaw 兼容 Markdown；
4. 能成功发布到 claw-daily；
5. 无新内容时跳过发布；
6. 保留运行日志；
7. 手动测试至少成功一次。

这类任务适合新手练习。因为结果可见、风险可控、验收清楚。

OpenAI Cookbook 示例：性能优化目标

OpenAI Cookbook 的 Codex Goals 示例里，有一个典型目标：把 checkout 的 p95 latency 降到 120ms 以下，同时保持 correctness tests 通过。

翻成白话：

让结账流程变快，但不能把正确性弄坏。

这类任务特别适合 /goal，因为它有明确指标。

但不要只写：

/goal 优化性能

要写：

• 用哪个 benchmark 验证；
• 哪些测试必须通过；
• 可以改哪些服务和测试；
• 每轮实验要记录什么；
• 如果 benchmark 跑不起来怎么办。

人决定：120ms 是不是业务真正需要的目标，能不能接受架构改动，是否值得继续投入。

Agent 负责：跑 benchmark、找热点、改局部代码、复测、汇报变化。

Claude Code 官方示例：拆大文件

Claude Code /goal 文档里提到一个例子：把一个大文件拆成更聚焦的模块，直到每个文件低于某个大小预算。

这也适合 /goal，前提是你把标准写清楚：

/goal 将 src/legacy/BigService.ts 拆分为职责清晰的小模块。
完成标准：
1. 拆分后没有单个文件超过 500 行；
2. 对外 public API 保持兼容；
3. 相关测试通过；
4. 不引入循环依赖；
5. 输出一份迁移说明，列出每个新模块的职责。

但如果你还不知道怎么拆，先别 /goal，先 /plan：

/plan 分析 BigService.ts 的职责边界，提出 2-3 种拆分方案，比较风险和验证方式。不要改代码。

等人选了方案，再进入 /goal。

OpenAI Cookbook 研究示例：不是“给我结论”，而是“给我证据账本”

OpenAI Cookbook 还展示过研究型 Goal：围绕 Deep Hedging 论文做复现与证据审计。

重点不是让 Codex 说“复现成功”，而是要求它区分：

• 哪些机制可以验证；
• 哪些结果只是近似支持；
• 哪些因为缺少随机种子、训练路径、checkpoint 而无法精确复现；
• 最后输出一份证据报告。

这对小白很重要。

因为很多人用 AI 做研究时，最危险的不是慢，而是它把“不确定”讲得像“确定”。

研究型 /goal 可以这样写：

/goal 对某篇论文/某个产品能力做证据审计。
完成标准：
1. 列出核心 claim；
2. 每个 claim 对应来源和证据；
3. 标记 confirmed / partially supported / blocked / uncertain；
4. 输出最终报告；
5. 不允许把近似结果写成完全复现。

这就是“人做评估”的价值。你不是让 Agent 替你相信，而是让 Agent 替你收集证据。

长任务最重要的不是自动化，而是可量化评估

如果只能记住一句话，请记这句：

没有评估标准的长任务，只是在让 Agent 长时间瞎忙。

可量化评估不一定都必须是数字，但必须能判断“过没过”。

任务类型	好的评估标准
修 Bug	复现步骤通过、回归测试通过
性能优化	延迟、构建耗时、性能报告
迁移	编译通过、测试通过、接口兼容
文档	链接检查通过、命令与当前版本一致
内容生产	来源完整、事实无编造、读者知道下一步
新闻收集	抓取成功率、去重率、有效发布数、人工保留率
研究分析	claim-evidence 表、确定/不确定边界、阻塞原因

对于 UseClaw 这类内容和数字员工场景，我尤其建议加三个指标：

1. 有效产物数：不是跑了多少轮，而是产出了多少能用的稿件、报告、PR、线索；
2. 人工采纳率：人最后采纳了多少，改掉了多少，否掉了多少；
3. 阻塞原因分布：是数据源不够、目标太模糊、权限不足，还是验证方式不存在。

这些指标比“Agent 工作了 3 小时”重要得多。

因为长任务不是为了显得自动，而是为了让人把时间花在更高价值的位置：判断、选择、验收。

新手开始前，先避开这 4 个坑

1. 不要把模糊愿望写成 /goal

弱：

/goal 把项目变好

强：

/goal 让 auth 相关测试通过，并修复当前失败用例，不改 public API。

2. 不要让 Agent 自己定义成功

你可以让 Agent 提建议，但最终成功标准要由人确认。

否则它很可能选择最容易完成的标准，而不是业务真正需要的标准。

3. 不要没有日志

长任务必须留下：

• 做了什么；
• 改了什么；
• 跑了什么验证；
• 哪些失败过；
• 为什么停下来。

没有日志，就没有复盘。

4. 第一次不要自动做危险动作

第一次不要让它自动：

• 付款；
• 删数据；
• 群发消息；
• 修改生产数据库；
• 自动发布未经审核的内容。

先让它产出草稿、报告、PR 或测试结果。人确认后，再逐步放权。

最后：长任务 Agent 的本质，是重新分工

很多人理解 AI Agent，会卡在“它能不能替我做完全部工作”。

我更建议换个问题：

哪些工作应该由人判断，哪些工作可以交给 Agent 反复执行？

人适合做：

• 判断方向；
• 定义成功；
• 选择取舍；
• 评估结果；
• 决定是否发布、上线、合并、继续投入。

Agent 适合做：

• 读大量文件；
• 跑重复命令；
• 试多个修复路径；
• 整理证据；
• 生成草稿；
• 按标准持续验证；
• 把过程记录下来。

所以，/plan 和 /goal 不是两个炫酷命令。它们代表的是一种新的工作方式：

• /plan 让 Agent 先帮你想清楚路线；
• /goal 让 Agent 围绕验收标准持续执行；
• /loop 让 Agent 定时回来检查状态；
• 人类负责更重要的事：方向、判断、评估和最终责任。

如果你是新手，今天就从一个低风险小任务开始。

不要追求一开始就“全自动”。

先做一个能被评估的小闭环。
这才是构建自己 Agent 的第一步。

UseClaw 持续记录 Claude、Codex、OpenClaw、AI Agent 与数字员工的真实案例、方法和产品化实践。
了解更多：https://useclaw.net/

参考资料

• OpenAI Codex Prompting：Goal mode 说明
  https://developers.openai.com/codex/prompting#goal-mode
• OpenAI Cookbook：Using Goals in Codex
  https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
• OpenAI Codex CLI Slash Commands：/plan 与 /goal 说明
  https://developers.openai.com/codex/cli/slash-commands
• OpenAI Codex Workflows：规划、云端委托与验证工作流
  https://developers.openai.com/codex/workflows
• Claude Code Docs：Keep Claude working toward a goal
  https://code.claude.com/docs/en/goal
• Claude Code Docs：Run prompts on a schedule，/loop 说明
  https://code.claude.com/docs/en/scheduled-tasks
• UseClaw 实测：AI HOT 小时报自动发布任务
  https://useclaw.net/contents/ai-hot-2026-05-22-1304-mpgggldv

版本与边界说明

• Codex Goals 需要支持 Goals 的 Codex 版本；部分环境可能需要启用 features.goals。
• Claude Code /goal 需要 v2.1.139 或以上。
• Claude Code scheduled tasks / /loop 需要 v2.1.72 或以上。
• 不同工具对命令、权限、自动审批、后台执行的支持不同，正式使用前请以当前工具文档和本地 /status 为准。