我写 goal-mode.sh 的第一版 prompt 时犯了一个错误——把整个需求塞进一句话里，指望 Agent 自己拆。
"帮我搭建一个完整的博客系统，要有用户认证、文章管理、评论功能和部署脚本。"
Agent 跑了 8 轮，每轮都在重新理解需求，最后一轮 confidence 给了 0.3 ，勉强标记 achieved 。代码能跑，但风格混乱，文件组织像随机生成的。
这个教训让我重新审视：当 Agent 在 Goal Mode 下自主循环时， prompt 不只是"输入"，而是整个执行循环的操作系统的源代码。
什么是 Goal Mode
先简单回顾。 Goal Mode 是我给 Agent Swarm 设计的自愈循环机制：一个 goal 描述 + 一个项目路径， Agent 自主循环执行，每轮评估进度，直到目标达成或触达上限。
核心循环的逻辑写在一百多行的 Shell 脚本里。脚本本身不复杂——初始化状态、构建 prompt 、调用 Claude CLI 、解析决策 JSON 、更新状态、循环。复杂的是 prompt 模板怎么设计，它直接决定了 Agent 每一轮的行为质量。
Goal Prompt 的三层结构
经过多次迭代，我发现有效的 Goal Prompt 必须有三层：Goal 描述层、约束条件层、决策框架层。
第一层： Goal 描述——粒度决定成败
先看 template.md 里 Goal 部分的设计：
## Current Goal
{{GOAL}}
## What To Do This Round
1. **Assess current state** — Check what exists in the project
2. **Identify the gap** — Compare current state vs goal
3. **Plan next steps** — Break down what needs to happen
4. **Execute** — Make the changes needed
5. **Verify** — Confirm your changes are correct and complete
注意，{{GOAL}} 是用户传入的原始描述，但模板强制包裹了 5 步执行框架。这解决了"Agent 不知道怎么开始"的问题。
关键经验：Goal 的粒度应该是"一个可验证的交付物"。
坏例子：
"做一个好看的官网"
好例子：
"为 StackRadar 创建一个落地页，包含： hero section （标题 + 副标题 + CTA 按钮）、功能特性展示（ 3 个特性卡片）、用户评价区（ 2 条引述）、页脚（版权 + 链接）。使用项目现有的 Tailwind CSS 配置，深色主题，与 thespots.tech 风格一致。部署到 Cloudflare Pages 后验证页面可访问。"
区别在哪？好的 Goal 描述做到了三点：可枚举（能逐项打勾）、可验证（有明确的"完成"标准）、有边界（明确了用什么技术栈，不包括什么）。
第二层：约束条件——预算、轮次、时间
goal-mode.sh 里有硬性上限设计：
HARD_MAX_ROUNDS=50
HARD_MAX_HOURS=8
这些不只是脚本层面的保险阀。每一轮的 prompt 里都会注入当前消耗：
- **Round**: {{ROUND}} / {{MAX_ROUNDS}}
- **Elapsed**: {{ELAPSED_TIME}} (limit: {{MAX_HOURS}}h)
- **Budget used**: ~{{TOKENS_USED}} tokens (limit: {{BUDGET_TOKENS}})
为什么要在 prompt 里重复告诉 Agent 这些信息？因为 Agent 需要根据剩余资源调整行为策略。
实际观察到的差异：当 prompt 里没有预算信息时， Agent 在第 15 轮之后依然在做"锦上添花"的优化（重构变量名、调整注释风格）。有预算信息后， Agent 在接近上限时会自动收窄范围，优先完成核心需求。
除了硬约束，还有一类软约束同样重要——写进 prompt 的规则：
## Rules
-Workincrementally: eachroundshouldmakemeasurableprogress
-Don't redo what'salreadydone — checkfirst
-Ifyouencounterablocker, describeitclearly
"Check first" 这条规则，是我在第 3 轮踩坑后加的。当时 Agent 连续两轮重写同一个文件，因为它不检查上一轮的产出。
第三层：决策框架——什么时候停
这是最被低估的部分。 continuation.md 定义了 Agent 判断"任务是否完成"的标准：
{
"continue":true|false,
"reason":"brief explanation",
"progress":"what was accomplished this round",
"remaining":"what still needs to be done",
"confidence":0.0-1.0
}
严格规则：continue: false 只在 confidence > 0.9 且所有需求项都 ✅ 时才能触发。
这个设计解决了一个核心问题——Agent 什么时候该停？
没有这个框架时， Agent 有两种极端行为：要么第一轮就报 done （ confidence 上溢），要么永远不满足（无限优化）。结构化的决策模板强迫 Agent 逐项对照需求，给出量化信心值。
任务拆分的原子化原则
Andrej Karpathy 在 2025 年提过一个观点：把 LLM 当 CPU ， context window 当 RAM ，你的 prompt 就是在给这个 CPU 写操作系统。这个比喻对 Goal Mode 的任务拆分特别适用。
实际操作中，我总结了一个简单原则：每轮只让 Agent 动 1-2 个文件。
这不是技术限制，是认知限制。当一轮的改动涉及 5+ 个文件时， Agent 的"验证"步骤几乎一定是走形式。反之，每轮 1-2 个文件， Agent 能真正检查改动的正确性， confidence 评分也更可靠。
在 goal-mode.sh 里，这体现为每轮的 prompt 都携带"Previous Rounds Summary"和"What Remains"——让 Agent 看到全局进度的同时，本轮只聚焦一个可完成的切片。
失败模式分析
跑了几十次 Goal Mode 后，我归纳出三种典型的失败模式。
模式一： Confidence 上溢
Agent 在第 1-2 轮就报 continue: false + confidence: 0.95，但实际只完成了 30%。
根因： Goal 描述太模糊， Agent 的完成标准和用户的期望不对齐。
修复： Goal 描述加入可验证的交付清单（见第一层），同时在 continuation.md 中强制要求逐项 ✅/❌ 对照。
模式二：无限循环
Agent 持续 continue: true，每轮都在"优化"已完成的部分，不推进新内容。
根因：缺少"What Remains"的显式追踪。 Agent 看不到全局进度，只能在当前范围内反复打磨。
修复： prompt 模板注入前几轮的 progress 摘要和 remaining 列表。 Agent 能看到"还差什么"，就不会在已完成的部分上空转。
模式三： blockers 不上报
Agent 遇到权限问题或依赖缺失，但不明确报告，而是尝试各种 workaround ，浪费大量轮次。
根因： continuation.md 没有要求 Agent 区分"我做不到"和"我需要更多轮次"。
修复：在决策框架中加入 blockers 字段，并设置规则——如果 blocker 是外部依赖问题（权限、网络、缺少依赖），直接 continue: false 并说明原因，不要浪费轮次。
一个好 Goal Prompt 的模板
把上面的经验压缩成一个可直接使用的结构：
Goal: [一个可验证的交付物，包含具体的完成标准]
Scope: [用什么技术/工具，不包括什么]
Verification: [怎么判断"完成了"——测试命令、页面截图、 API 响应等]
Constraints: [文件数限制、代码风格要求、依赖版本等]
这四行比一段 500 字的自然语言描述有效得多。因为每一行都在回答 Agent 在执行循环中会反复问自己的问题："我要做什么？""用什么做？""怎么确认做对了？""有什么限制？"
写在最后
Goal Mode 的 Prompt Engineering 和普通的 prompt 技巧不在一个层面上。普通 prompt 是单次对话——写错了可以追问、纠正、重来。 Goal Mode 的 prompt 是一份无人值守的执行计划——写错了， Agent 会在错误方向上循环 20 轮，烧完 token 预算，然后告诉你 "achieved"。
这不是理论推演。我有一个 state.json 文件，里面躺着十几次失败的 goal 记录，每一行的 confidence: 0.95 和 status: "achieved" 都在提醒我：让 Agent 能正确判断"做完了"，比让它"做得快"重要一百倍。
粤ICP备14082021号
免费POC，
零成本试错
