Goal 模式：让 Agent 围绕目标持续工作

Goal 模式把一次性的指令变成一份跨多轮有效的完成契约：用户定义目标和完成证据，Agent 每轮执行一部分工作，外层 Harness 保存任务状态，并在满足条件时安排续跑。

它的关键不是让模型一直生成，而是把目标、续跑资格、完成判定和停止条件放进一个可管理的闭环。

一、普通对话、外循环和 Goal 模式

普通对话的节奏是：用户提出一项任务，Agent 执行并回复，然后停下来等待用户的下一条指令。

1
2

普通对话：指令 → 执行 → 回复 → 等待
Goal：    执行 → 检查状态 → 继续或结束

在普通对话外面套一个循环，可以重复发送提示词和历史记录，但循环本身不会自动带来目标持久化、暂停恢复、完成审计或预算控制。要具备这些能力，外层程序还得保存进度、检查证据、管理状态，并决定何时允许继续。

Plan 和 Goal 也解决不同问题：Plan 描述“准备怎么做”，Goal 说明“做到什么状态才算完成”。计划可以帮助用户先审阅路线；Goal 则让最终目标在后续轮次中持续有效。

二、Goal 模式的核心实现组件

一套典型 Goal Harness 可以拆成五个部分。具体状态名和实现方式会因工具而异，下面描述的是常见架构，不是所有产品都使用完全相同的实现。

通常一个 Goal 的多轮执行会沿用同一个逻辑线程；每轮是线程中的新一轮执行。只有委派给子代理或系统需要隔离任务时，才可能另开线程。

后续轮次通常由 Harness 重新组装上下文，不是把全部历史对话原封不动地再发一遍。

一般会从几处取信息：

• 目标和完成标准：从持久化的 Goal 状态中读取，可能保存在任务记录、线程状态、数据库或文件里。
• 上一轮进度：从线程历史、轮次摘要或检查点中读取，包括做过什么、验证结果、剩余事项和阻塞点。
• 当前事实：需要时重新读取工作区文件、代码和测试结果，避免只依赖旧摘要。

然后续跑机制把这些内容整理成下一轮的提示。上下文太长时，系统通常传入摘要和相关片段，而不是整段历史。

1. 目标状态与持久化

Harness 把目标、完成标准、当前状态、预算和进度保存在会话状态、线程记录、数据库或文件中。这样即使当前 turn 结束，后续轮次仍能取回目标和进展。

状态机可以抽象成这样：

这只是常见的状态模型。实际系统可能合并、改名或省略其中一些状态。

2. 自动续跑引擎

续跑引擎通常监听 turn 结束、会话空闲等事件，再检查目标是否仍为 Active、是否已暂停、预算是否可用、是否有用户输入或其他工作等待处理。条件满足时，Harness 才启动下一轮；因此，模型不能单靠一句“继续”无限开启新 turn。

启动下一轮时，系统会生成续跑提示，重新带入目标、当前进度、预算信息和本轮需要完成的检查。具体注入哪些字段、使用什么 Hook 或消息模板，取决于实现。

3. 完成评估器

“能不能继续运行”和“目标是否已经完成”是两个不同判断。Harness 可以用以下方式评估完成条件：

• 执行模型自审：模型读取文件、测试结果和日志，按目标中的证据标准判断是否完成，并通过工具或结构化结果报告判断。
• 独立评估器：另一个模型或规则检查器只负责审阅目标和证据，返回“未完成、已完成、无法完成”等有限结果。

独立评估器能把执行和裁决分开，但会增加成本和延迟。高风险任务还可以组合确定性测试、独立评估或多评估器投票。是否需要这些机制，要根据错误代价决定。

4. 目标重注入与防遗忘

长任务会跨越很多轮，而模型每轮能直接读取的上下文有上限。历史对话太长时，系统可能压缩旧消息、生成摘要，或只保留最近一部分内容。如果目标、约束和完成标准只存在于最初那段对话里，它们就可能在后续轮次中变得不可见，Agent 也可能把“最近做了什么”误当成“最终要做什么”。

因此，稳妥的实现会把持久化的目标状态和当前轮可见的上下文分开管理。对话记录可以被压缩，但作为任务依据的目标不应只靠完整聊天记录来保存。Harness 通常会在每轮开始时组装一份续跑上下文，至少带上：

• 原始目标、完成条件、范围和停止规则；
• 当前状态，以及已完成、未完成和受阻的事项；
• 最近一轮做了什么、改动了哪些文件，以及验证结果；
• 当前预算或其他会影响能否续跑的信息。

这不代表每一轮都要重新塞入全部历史。续跑提示应保留做当前决策所需的信息；更早的日志、文件内容和细节可以按需重新读取。这样既能让目标持续可见，也能给实际执行留出上下文空间。

上下文过长时，压缩什么

上下文压缩不是把旧对话随便缩短，而是把对下一轮仍有用的信息整理成检查点。比较稳妥的压缩时机是在上下文接近上限、但当前操作已经到达一个安全节点时；若已经触发上下文限制，也应先保存状态，再开始下一轮。检查点可以包含：

1. 目标契约：保留目标、完成证据、范围和停止规则，最好从持久化状态中重新读取，而不是只依赖模型转述。
2. 已完成工作：概括完成了哪些批次、改动涉及哪些文件，以及重要决策和原因。
3. 验证证据：记录实际运行过的命令、结果和对应的改动。测试尚未运行、结果不确定或只验证了一部分，都要明确标记，不能压缩成“基本通过”。
4. 当前状态：列出剩余事项、已知阻塞、尚未确认的假设，以及预算或轮次是否接近上限。
5. 续跑入口：指出下一轮最合适的检查或动作，并说明哪些旧日志或文件需要重新读取。

例如，目标是给现有任务列表增加标题筛选时，压缩后的检查点可以长这样：

1
2
3
4
5
6
7

目标：在现有任务列表页面增加按标题筛选功能，忽略大小写。
完成条件：输入关键词只显示标题匹配的任务；清空关键词恢复完整列表；相关测试通过，项目构建成功。
已完成：筛选逻辑和匹配结果测试已完成并通过；构建尚未运行。
待处理：补充清空关键词后恢复完整列表的测试。
约束与范围：只修改任务列表页面及相关测试，不改接口和依赖。
下一步：补充清空关键词测试，再运行相关测试和项目构建。
停止规则：如果实现需要修改后端接口，先说明原因并请求用户确认。

压缩摘要只是恢复工作的索引，不等于完成证据。恢复后，Agent 仍应查看实际文件和当前工作区状态；对于摘要里声称通过的测试，必要时重新运行验证。若检查点与代码、日志或测试结果不一致，应以重新读取和验证得到的事实为准，再更新任务状态。

不同 Harness 的实现会有差异：有的在每轮续跑时注入结构化状态，有的通过摘要和检查点恢复，也有的会在上下文压缩时专门保留目标信息。共同的设计原则是，压缩可以减少历史细节，但不能悄悄改写目标，也不能把尚未验证的进展写成已完成。

5. 预算与熔断

持续运行需要边界。常见保护机制包括累计 Token 或轮数上限、连续无进展检测、重复阻塞计数、用户中断和暂停开关。触发停止条件后，Harness 应停止续跑并报告已完成部分、证据、阻塞点和恢复所需的信息。

这些熔断项是常见的工程选择；具体阈值需要结合任务设置，不能默认所有 Goal 系统都实现了相同的检测规则。

三、完整流程：谁决定继续，谁判断完成

Goal 的工作流程可以拆成两条判断线：评估器检查目标是否达成；调度器检查是否允许再启动一轮。前者回答“做完了吗”，后者回答“现在能继续吗”。

下面这张图把状态保存、执行、证据评估和续跑条件连在一起：

总轮数通常不会在开始时预先固定。Agent 每轮根据新发现选择下一步；验证通过但终态尚未达成，就继续；目标达成则结束；阻塞、预算耗尽或用户中断则暂停或汇报。

这也是 Goal 能持续数小时甚至更久的原因：目标状态留在 Harness 中，轮次之间由调度器衔接，完成判断依赖明确证据，预算和熔断机制限制了无止境运行。

四、怎样写好 Goal

用户应把 Goal 写成一份可检查的完成契约，至少说清终态和证据；复杂任务再补充约束、范围、迭代方式和停止规则。

例如，要给一个现有任务列表增加标题筛选功能，可以这样定义 Goal：

1
2
3
4
5
6
7
8
9

目标：在现有任务列表页面增加按标题筛选功能。用户输入关键词后，只显示标题包含该关键词的任务；匹配时忽略大小写，清空输入后恢复完整列表。

证据：为匹配、忽略大小写、无匹配结果和清空关键词恢复列表这几种情况补充测试；运行项目测试和构建，确认全部通过。

约束与边界：只修改任务列表页面及相关测试，不改后端接口、数据结构和依赖版本；保持现有列表展示和其他筛选功能不变。

迭代：先检查任务列表的数据流和现有测试，再实现筛选逻辑；每完成一部分就运行相关测试，根据失败结果修复，最后运行完整测试和构建。

停止：如果现有数据不包含任务标题，或实现必须修改后端接口，先记录原因和影响并请求用户确认，不要擅自扩大修改范围。

五、什么时候适合用 Goal

Goal 适合终点清楚、证据可检查，但具体路径要根据过程中发现的信息调整的任务，例如多模块迁移、性能优化、间歇性故障排查、基准调优和需要最终审计报告的研究。

如果用户只需要一次性的小修改或简单问答，普通对话更直接；如果目标本身还不清楚，可以先用 Plan 把路线理顺，再定义 Goal。

结语

Goal 模式的核心是一套围绕目标运行的 Harness：状态机保存目标，续跑引擎安排下一轮，评估器核对完成条件，重注入机制维持目标连续性，预算与熔断负责停止。

用户编写 Goal 时最需要明确两件事：终点是什么，证据如何检查。系统可以负责接力，但“做完”的定义仍要由目标和验证标准说清楚。