如何让AI Agent在Goal Mode下高效执行？关键在于prompt设计的三层结构：任务拆分、约束条件与失败预判。
核心内容：
Goal Mode的核心循环与prompt作为“操作系统”的重要性
有效Goal Prompt的三层结构设计
任务粒度、约束条件与失败模式的具体实践
我写 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 Round1. Assess current state — Check what exists in the project2. Identify the gap — Compare current state vs goal3. Plan next steps — Break down what needs to happen4. Execute — Make the changes needed5. 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 里有硬性上限设计：
HARDMAXROUNDS=50HARDMAXHOURS=8
这些不只是脚本层面的保险阀。每一轮的 prompt 里都会注入当前消耗：
Round: {{ROUND}} / {{MAXROUNDS}}- Elapsed: {{ELAPSEDTIME}} (limit: {{MAXHOURS}}h)- Budget used: ~{{TOKENSUSED}} 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 能正确判断"做完了"，比让它"做得快"重要一百倍。
[登录查看剩余 70% 内容](javascript:void (0);)
提示词技巧提示词框架提示词编写技巧
分享：
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
用微信扫描二维码
53AI，企业落地大模型首选服务商
产品：场景落地咨询+大模型应用平台+行业解决方案
承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业
上一篇：AI时代产品范式和工作范式已彻底改变下一篇：Anthropic 工程师发文：别用 Markdown 了，HTML 才是 AI 的终极语言！
返回列表
相关资讯
2026-07-02 Claude团队：别再逐条喂Prompt，学会给Agent设计循环2026-07-02 Agent 怎么沉淀技能:把一个好 prompt 变成全队资产2026-07-01 从 Prompt 到 Skill：专业工作流的结构升级2026-07-01 别让 AI 写的文档误导用户：从单次 Prompt 到高可信文档工程化实践2026-06-30 网传 Karpathy 的 CLAUDE.md 曝光，10条铁律管住Claude Code！2026-06-29 AI Coding 的底层框架：一切优化都是在对抗熵增2026-06-29 给模型写方法论：拆解一个跨法域隐私审计Skill2026-06-28 别再手工调 prompt 了，让 Agent 自己改自己的"操作系统"
联系获取
联系获取
160+中大型企业正在使用53AI
[立即咨询](javascript:void(0))[预约演示](javascript:void(0))
把握AI发展的机遇，共同探索、共同进步 2025-01-22如何打造基于GenAI的员工服务机器人 2025-01-22
