深入解析Goal模式：AI Agent自动化的核心实现流程

什么是Goal模式

AI Agent面试中有一道常见问题：请详细讲解Goal模式的实现流程。这个问题看似简单，却难倒了不少人。作为处理复杂需求时最经典的自动化实现方式，Goal模式（目标模式）值得每一个想自己编写Agent、或想理解AI如何实现自动化的开发者深入研究。

本文将从四个维度展开：普通对话与Goal模式的区别、Goal模式的详细流程拆解、Plan模式与Goal模式的差异，以及Goal模式的适用场景。理解了这些，你就能明白AI Agent「无人值守」自动化背后的运作逻辑。

普通模式与Goal模式的本质区别

普通模式是我们用得最多的交互方式：发送一轮对话，模型完成后停下来等待我们继续输入，才会接着干活。整个过程是断续的，每一轮都需要我们发送、确认、再安排下一轮。

Goal模式则完全不同。你发送目标内容后，模型会开启一个循环：执行第一轮任务，完成后自我审查（自审），通过后接着跑第二轮，直到所有轮次结束才算完成。整个流程中，模型既要干活，又要验证，还要规划下一轮内容。你只需负责第一步（下达目标）和最后一步（验收），中间环节全部自动循环完成。

有人会问：能不能在普通模式里用while循环的方式模拟Goal模式？比如写一段「直到完成一直循环」的提示词，每次输入都带上历史对话。看起来相似，但存在三个本质区别：

• 无法随时停止/启动：普通循环一旦跑起来，你没法灵活控制；
• 没有自我验证功能：它完全依赖你的提示词，而提示词里的验证条件往往模糊不清；
• 无法按轮次执行：一个大需求可能会连续跑很久，效果还不一定好。

正因为这些痛点，才催生了更智能的Goal模式。

用「远程员工」理解Goal模式

可以用一个生动的比喻理解Goal模式。假设你是老板，有一个远程员工，你给他下发目标和预算，员工收到后自己去完成。同时你安排一个财务监控预算是否花完——预算一旦用尽，执行就会停止，需要你决定是补充预算还是介入处理。

关键在于：员工每天具体做什么，你并不需要知道。如果目标是「把销售额从30%提升到60%」，你只关注这个最终结果，至于他花了多少天、每天做什么，你都不关注。

Goal模式正是如此——高度聚焦于目标。你只给出目标和预算，剩下的交给模型自主规划和执行。

从技术实现角度看，Goal模式本质上是一个ReAct（Reasoning + Acting）循环的工程化封装。ReAct是目前主流AI Agent架构的核心范式：模型先推理（Reasoning）当前状态和下一步行动，再执行行动（Acting），获取环境反馈后再推理，如此循环。Goal模式在此基础上增加了持久化存储（SQLite保存目标与状态）、预算管理、以及每轮强制自审验证，使得长时间无人值守运行成为可能。这也解释了为什么Goal模式对底层模型能力要求较高——每一轮的推理质量直接决定任务能否正确分解和验证，模型越强，轮次分配越合理，自审越可靠。

Goal模式的完整流程拆解

以一个真实开发场景为例：将前端项目src目录中遗留的CommonJS写法迁移为ESM写法。

目标的创建

创建目标是一个长程任务（long-running task），会持续运行，因此对工具要求较高。以Codex为例，你必须明确选择「目标模式」才能创建成功，或者在提示词中告知模型你要创建目标模式才能触发。AI在日常开发中会主动创建子代理、todo list或计划，但目标模式绝不会自动创建，必须由你主动要求，否则极易误触发长任务。

目标提示词怎么写

一个精准的目标提示词应包含五个要素：

• 终态：你最终要完成什么，要具体可实现，而非模糊；
• 证据：如何证明终态达成，告诉模型验证方式；
• 边界：指定改动范围；
• 循环任务：告诉工具如何迭代（可选，多由模型自主决定）；
• 停止规则：什么情况下停止，比如遇到某类阻塞就交给用户介入。

其中终态和证据是必须的，边界、循环、停止规则可视具体情况而定。

以CommonJS转ESM为例：终态就是完成迁移；验证是「rg正则匹配 + test通过 + build成功」；范围是只改指定文件；循环方式是每改一批就重跑搜索和测试；停止规则是遇到无法自动迁移的模块就记录报告，不允许强行跳过。五个要素齐全时，这就是一个极其精准的目标。定义完成后，选择目标模式，模型会将目标提示词和初始状态保存到SQLite数据库中。

轮次（Turn）如何拆分

一个常见误区是：以为模型接到提示词后会预估总轮次，然后按数量执行。实际并非如此。

模型接收提示词后，只预估「第一轮要做什么」，跑完第一轮、做完验证后，再检测任务是否完成。没完成就开启第二轮。也就是说，它把大任务切成许多小块，每一块的具体内容要等到那一轮才知道。

每轮开始时，模型会读取上一轮完成了什么，接着做本轮工作，结束时进行总结，这个总结又成为下一轮的上下文。因此到底有多少轮是未知的，只有当模型判定所有测试通过、任务完成、不再需要动作时，才算真正结束。

这种设计非常智能：模型会合理安排每轮的工作量，保证每一轮都能完成，不会因为任务太大导致单轮耗时过长、拖累后续轮次。这也高度依赖模型本身的强大能力。

单个Turn内部的执行逻辑

聚焦到每一个循环内部。模型收到目标后开始执行，调用工具、返回结果、再调用工具，如此往复。所谓「工具」，指的是本地目录扫描、代码编辑、代码搜索等对本地操作的能力。

判断一轮结束的标志是：模型返回的内容里不再包含任何工具调用，或模型明确返回「这轮应结束」。结束后，模型会对本轮任务进行总结。

流程中还提供了四个钩子（hook），分别订阅开始、结束、停止、继续四个事件。每一轮都会读取上一轮的任务总结，加上初始目标和预算，作为下一轮的提示词。

自审验证的重要性

每一轮结束后必须做自审验证。验证的源头是提示词中「证明」部分的定义，但模型不会仅参考这里——它会结合本轮实际的工作内容和变更，推导出还需要验证什么。比如提示词写了「rg正则匹配」，但模型会根据本次变更内容推导出额外的验证步骤。

正是这套验证机制让Goal模式变得严谨。如果提示词里没写验证条件，模型只能靠自身对代码库的理解来验证，一旦出现疏漏，整体效果就会大打折扣。强烈建议务必写好验证条件。

Goal模式的Token消耗与预算

以Claude为例，有两种订阅方式：API key（用多少花多少）和订阅制（如Pro套餐有5小时或周额度限制）。

订阅制用户在跑Goal模式时，只要窗口还剩额度（哪怕只剩3%），当轮对话就能开始，用超一点没关系；下一轮会把上一轮的消耗补扣回来。一旦周额度用尽（0%），任务会自动停止，等额度恢复后再继续。

API key用户没有额度限制，唯一的约束是可以在配置文件（如config）中设置Goal的最大预算Token数，避免超支。因此订阅制用户无需操心，系统会根据额度自动停止和恢复。如果你自己设计Agent，一定要做好预算兜底措施，否则用户可能会消耗大量Token而不自知。

Token预算在Agent工程中是一个关键的安全边界机制。每一轮对话的上下文不仅包含当前轮次的工具调用与返回结果，还要携带初始目标和上一轮总结，随着轮次增加，单轮的prompt长度会逐渐膨胀。这也是为什么Goal模式会将每轮结果「压缩总结」再传入下一轮，而非直接拼接全部历史——这种设计在保留关键上下文的同时控制了Token增长速率。对于自研Agent的开发者来说，建议同时设置单轮最大Token限制（防止单轮工具调用风暴）和全局预算上限（防止整体超支），并在预算耗尽前触发一次强制总结，避免任务状态丢失。

Goal模式的五种状态

Goal模式常见五种状态：

• 超限：套餐用量超限，停止运行，需自行恢复额度；
• 完成：任务顺利结束；
• Block（阻塞）：单个Turn内连续三次失败或遇到额外阻塞，标记为阻塞，需手动恢复；
• 暂停：用户主动暂停，可随时恢复；
• 删除：直接终止，无法恢复。

Goal模式与Plan模式的对比

在早期弱模型时代，Plan模式和Goal模式差别很大：Plan模式会先生成一份计划，任务大时计划往往粗糙、覆盖不全，执行一会儿就结束了。

但如今模型普遍强调长时间运行任务，当Plan生成的文档足够细致时，Claude、Kimi、DeepSeek^广告等模型都能依据文档运行数小时。所以在长任务运行能力上，两者差别不大。

真正的区别在于：

• 执行方式：Goal模式按轮次循环迭代，每轮都验证再进入下一轮；Plan模式给了计划就一次性执行，不做验证；
• 暂停/启动：Plan模式无法灵活暂停启动，重启只能通过自带session对话，读取历史记录和代码diff后继续；Goal模式可随时重启。

Plan模式的技术原型通常被称为Task Decomposition（任务分解）或Hierarchical Planning：模型先生成一份结构化计划文档（类似项目工单），再按序执行各子任务。其优势在于计划对人类可读、可审查，便于在执行前介入修改；劣势是计划一旦生成便固化，执行中途遇到意外状况时缺乏动态调整能力。Goal模式则更接近Online Planning（在线规划）：不预先生成完整计划，而是在每轮执行后根据最新环境状态决定下一步，具备更强的容错性。两种范式各有适用场景：需要人工审查执行路径时选Plan；追求全自动且有明确验证条件时选Goal。

Goal模式适合什么场景

Goal模式最适合可验证的长任务。这里的「可验证」有两种：一是数字类，比如从30%提升到60%这种明确的增长指标；二是有清晰的验证清单，明确知道如何判断任务完成。

此外，任务要足够大（通常需运行两小时以上），目标要足够具体——越具体效果越好。至于零散的小需求，用普通对话或Plan模式完全够用。

理解Goal模式的核心，就是理解AI Agent如何在「目标驱动 + 自我验证 + 轮次循环」三者结合下实现真正的自动化。这也是自己动手写Agent时最值得借鉴的设计范式。