如何撰写有效的 Goal Mode Prompt 任务拆分与约束条件分析

如何让AI Agent在Goal Mode模式下高效执行任务？关键在于掌握Prompt设计的三层核心架构：任务拆分、约束条件与失败预判。这套结构是提升Agent自主循环效率的基石。

许多开发者在编写goal-mode.sh的初始Prompt时，常陷入一个误区：将复杂的整体需求直接塞入一句话中，期望Agent能自行完成理解和拆解。

例如：“请帮我搭建一个包含用户认证、文章管理、评论功能和部署脚本的完整博客系统。”

结果往往是：Agent运行了8个循环，每一轮都在重新解析需求，最终仅以0.3的信心值标记为“完成”。生成的代码虽然能运行，但风格混杂，文件组织如同随机生成。

这一教训揭示了一个核心原则：当Agent在Goal Mode下自主循环时，Prompt已不再是简单的“指令输入”，而是整个执行循环的“操作系统内核代码”。其质量直接决定了Agent的行为轨迹与最终产出。

什么是 Goal Mode

Goal Mode是一种为AI Agent设计的自愈式循环执行机制。它基于一个明确的目标描述和项目路径，让Agent自主评估、决策并执行，每轮循环后评估进度，直至目标达成或达到预设的循环/时间上限。

其核心逻辑通常封装在一百多行的Shell脚本中。脚本本身并不复杂——核心流程是初始化状态、构建Prompt、调用大模型API、解析决策JSON、更新状态、然后循环。真正的复杂性在于Prompt模板的设计，它直接决定了Agent在每一轮循环中的行为逻辑与决策质量。

Goal Prompt 的三层核心结构

经过大量实践验证，一个高效的Goal Prompt必须包含三层结构：目标描述层、约束条件层和决策框架层。这三层共同构成了指导Agent行动的“操作手册”。

第一层：目标描述——粒度决定成败

首先看模板中Goal部分的设计：

## Current Goal

{{GOAL}}

## What To Do This Round

1. **评估当前状态** — 检查项目中已存在的内容
2. **识别差距** — 对比当前状态与目标要求
3. **规划下一步** — 拆解需要完成的具体步骤
4. **执行** — 实施必要的更改
5. **验证** — 确认更改正确且完整

这里的关键在于，虽然{{GOAL}}是用户传入的原始描述，但模板强制其包裹在一个五步执行框架内。这直接解决了“Agent启动时不知从何入手”的初始问题。

核心经验是：Goal的粒度必须是一个“可验证的交付物”。

来看一个反面案例：“设计一个美观的官网”。这种描述过于模糊，Agent的理解可能与你的期望大相径庭。

而一个优秀的案例应该是：“为StackRadar项目创建一个产品落地页，需包含：1. Hero区域（主标题、副标题、CTA按钮）；2. 功能特性展示区（3个特性卡片）；3. 用户评价区（2条引述）；4. 页脚（版权信息与链接）。要求使用项目现有的Tailwind CSS配置，采用深色主题，设计风格需与thespots.tech保持一致。最终需部署至Cloudflare Pages并验证页面可正常访问。”

两者的本质区别在于：优秀的Goal描述做到了三点：可枚举（能逐项验收）、可验证（有明确的“完成”标准）、有边界（明确了技术栈和范围，排除了不确定性）。

第二层：约束条件——预算、轮次与时间管理

在goal-mode.sh脚本中，通常会设置硬性上限：

HARD_MAX_ROUNDS=50
HARD_MAX_HOURS=8

这些不仅是脚本层面的保险阀。更重要的是，每一轮的Prompt里都会动态注入当前的资源消耗情况：

- **当前轮次**: {{ROUND}} / {{MAX_ROUNDS}}
- **已耗时**: {{ELAPSED_TIME}} (限制: {{MAX_HOURS}}小时)
- **Token消耗**: 约{{TOKENS_USED}} tokens (预算: {{BUDGET_TOKENS}})

为什么需要在Prompt中反复告知Agent这些信息？因为Agent需要根据剩余资源来动态调整其行为策略。

实际观察到的差异非常显著：当Prompt中不包含预算信息时，Agent在第15轮之后可能仍在进行“锦上添花”式的优化，例如重构变量命名、调整注释格式。而当注入预算信息后，Agent在接近上限时会自动聚焦于核心需求，优先完成最关键的工作。

除了这些硬约束，还有一类软约束同样至关重要，它们通常被写入Prompt的规则部分：

## 规则

- 增量式工作：每一轮都应产生可衡量的进展
- 不要重复已完成的工作 — 执行前先检查
- 若遇到阻碍，请清晰描述问题

以“执行前先检查”这条规则为例，它是在某次任务第3轮踩坑后添加的。当时Agent连续两轮重写了同一个文件，因为它没有检查上一轮已经完成的工作。

第三层：决策框架——何时应该停止

这是最容易被低估，却也最关键的一层。continuation.md文件定义了Agent判断“任务是否完成”的决策标准：

{
  "continue": true|false,
  "reason": "简要解释",
  "progress": "本轮完成的工作",
  "remaining": "仍需完成的工作",
  "confidence": 0.0-1.0
}

这里有一条严格规则：continue: false只有在confidence > 0.9且所有需求项都确认完成时才能触发。

这个设计解决了一个核心痛点——Agent应该在何时停止？

在没有此框架时，Agent往往表现出两种极端行为：要么在第一轮就草率地报告完成（信心值虚高），要么陷入完美主义循环，永远觉得不够好而无限优化下去。结构化的决策模板强制Agent逐项对照需求清单，给出量化的信心评估，使得“完成”的判断变得客观、可追溯。

任务拆分的原子化原则

Andrej Karpathy在2025年曾提出一个精妙的比喻：将LLM视为CPU，context window视为RAM，那么你的Prompt就是在为这个CPU编写操作系统。这个比喻对Goal Mode下的任务拆分尤为适用。

在实际操作中，可以总结出一个简单而有效的原则：每轮只让Agent修改1-2个文件。

这并非技术上的限制，而是认知负载上的优化。当一轮的改动涉及5个以上的文件时，Agent的“验证”步骤几乎必然流于形式。反之，每轮聚焦于1-2个文件，Agent才能真正细致检查改动的正确性，给出的信心评分也会可靠得多。

在goal-mode.sh的实现中，这体现为每轮的Prompt都携带“前几轮摘要”和“剩余工作”信息——让Agent在看清全局进度的同时，将注意力精准聚焦于当前轮次这个可完成的“任务切片”上。

典型失败模式分析

在运行了数十次Goal Mode任务后，可以归纳出三种典型的失败模式。

模式一：信心值虚高（Confidence 上溢）

Agent在第1-2轮就报告continue: false，并给出confidence: 0.95的高分，但实际上只完成了30%的核心工作。

根本原因：Goal描述过于模糊，Agent内部的完成标准与用户的期望严重不对齐。

修复方案：在Goal描述中加入可验证的交付清单（参考第一层），同时在continuation.md中强制要求Agent进行逐项的✅/❌对照检查。

模式二：无限优化循环

Agent持续报告continue: true，但每轮都在“优化”已经完成的部分，而不推进新的工作内容。

根本原因：缺少对“剩余工作”（What Remains）的显式追踪。Agent看不到全局进度，只能在当前已完成的范围内反复打磨。

修复方案：在Prompt模板中注入前几轮的进度摘要和明确的剩余工作列表。让Agent清楚地看到“还差什么”，就能有效避免在已完成部分上的空转消耗。

模式三：阻塞问题不上报

Agent遇到权限问题或依赖缺失时，不明确报告阻塞，而是尝试各种变通方法，浪费大量轮次。

根本原因：continuation.md没有要求Agent区分“我做不到”和“我需要更多轮次”。

修复方案：在决策框架中加入blockers字段，并设置明确规则——如果阻塞原因是外部依赖问题（如权限不足、网络错误、缺少包），则直接报告continue: false并说明原因，而不是浪费轮次去尝试不可能完成的工作。

一个高效的 Goal Prompt 模板结构

将上述经验压缩，可以得到一个可直接使用的四行结构：

• 目标: [一个可验证的交付物，包含具体的完成标准]
• 范围: [使用什么技术/工具，明确不包括什么]
• 验证方式: [如何判断“完成了”——例如运行测试命令、查看页面截图、验证API响应等]
• 约束条件: [文件数限制、代码风格要求、依赖版本等]

这四行结构比一段500字的自然语言描述要有效得多。因为每一行都在精准回答Agent在执行循环中会反复自问的核心问题：“我要做什么？”“用什么做？”“怎么确认做对了？”“有什么限制？”

总结与建议

Goal Mode下的Prompt Engineering，与普通的Prompt技巧完全不在一个层面上。普通Prompt是单次对话——写错了可以追问、纠正、重来。而Goal Mode的Prompt是一份无人值守的执行计划——一旦设计存在缺陷，Agent就会在错误的方向上循环数十轮，耗尽Token预算，最终给出一个“achieved”的虚假成功报告。

这并非理论推演。在许多实践者的state.json文件里，往往记录着十几次失败的goal运行记录，每一行那confidence: 0.95和status: "achieved"的标记，都在反复印证一个关键事实：让Agent能正确判断“做完了”，比让它“做得快”重要一百倍。这才是设计高效Goal Mode的核心所在。