Claude Code 智能体循环：从写提示词到设计循环的工程范式转移
Anthropic 2026年6月30日正式定义了 Claude Code 四种智能体循环模式。本文从工程落地角度拆解设计原理、token 成本与代码质量保障，给技术负责人一份可操作的落地路线图。
Claude Code 智能体循环：从写提示词到设计循环的工程范式转移
Anthropic 在 2026 年 6 月 30 日发布了一篇被严重低估的文章——不是 Sonnet 5 的 benchmark，而是《Getting started with loops》。当所有人都在讨论新模型跑分时，开发团队悄悄把「智能体循环」从社区黑话变成了有明确定义和工程基元的正式概念。这件事的意义比跑分大得多。
我们团队在过去三个月里把这套工具从「高级自动补全」用到了「让它自己跑完整段流程」，踩了一遍坑——这其实正是Agentic Coding 从「写代码」到「做项目」那条路径的下一步。这篇文章把四种模式讲透，带上 token 成本和代码质量的工程权衡——不讲 benchmark，讲落地。
为什么「写提示词」这套打法开始不够用了
大部分工程师和 AI 编程工具的交互还停留在：写提示词 → 改代码 → 人工检查 → 再写提示词。Anthropic 把这叫 Turn-based 模式——每次交互是一个 turn，人类是循环的扳机和质检员。
当你一天要交互 30-50 次，每次都要肉眼确认「这个改动对不对」时，人就变成了瓶颈。更致命的是：人工检查的可靠性随疲劳指数下降，下午四点和早上九点，检查质量不在一个水平线上。
官方定义很精确：智能体循环 = agent 重复执行工作周期，直到满足停止条件。按触发方式与停止方式分为四类，它们不是替代关系，是递进关系——每往上一层，把更多判断从人转移到了系统。这种递进逻辑在AI 编程进入 Agent 时代的演进中已有端倪，但 Anthropic 这次给出了精确的工程基元。
四种模式的设计逻辑与工程基元
第一级是上面提到的 Turn-based：用户提示触发，agent 自行判断何时完成。这一级最大的工程改进空间在于 SKILL.md——把人工验证步骤编码为可执行检查清单。官方给的 verify-frontend-change 示例：启动 dev server → 交互操作并截图 → 确认控制台零错误 → 跑 Chrome Devtools MCP 做性能审计。任何一步失败就回退重来。定量检查越精确——「控制台零错误」而非「看起来没问题」——自我验证越可靠。我们实践数据：写了 SKILL.md 后，人工复审发现问题率从约 40% 降到 15% 以下。
第二级是质变：定义一个可验证的成功标准，交给独立的评估模型去检查——不满足就送回继续干活，满足或达到最大轮次才停止。这就是为什么确定性标准远比主观标准有效。好的写法：get the homepage Lighthouse score to 90 or above, stop after 5 tries。不好的写法：「把首页性能优化好」——评估模型没法判断「好」是什么意思。我们做内部后台项目时用这个模式跑过「让全部 47 个 API 的 P95 响应时间低于 200ms，最多试 8 轮」，第 7 轮达标。没有评估模型的强制回环，大概率第 3 轮就停了——当时 P95 还在 350ms。这一级比上一级多消耗约 2-5 倍 token，但换来的是不需要你盯着。
第三级按时间间隔自动触发：每 5 分钟检查 PR 有没有新 review、每小时确认 CI 状态。通过 /schedule 可以迁到云端，关机也不停。
第四级是终极形态：把定时触发、目标条件、动态工作流和自动模式拼在一起。官方示例是 bug triage 管道——每小时扫描反馈频道，对每个 report 并行探索三种修复方案，用对抗评审选出最佳。信息密度极高，但 token 风险也最大——动态工作流可能 spawn 出上百个 agent。
| 模式 | 触发方式 | 停止条件 | 适合场景 | Token 风险 |
|---|---|---|---|---|
| Turn-based | 用户提示 | 自判完成 | 探索、单次决策 | 低 |
| Goal-based | 命令触发 | 达标或轮次上限 | 可量化验证标准 | 中 |
| Time-based | 时间间隔 | 取消或任务完成 | 周期性重复工作 | 中高 |
| Proactive | 事件或计划 | 子任务各自达标 | 重复性明确工作流 | 高 |
Token 成本与代码质量：五个控制杠杆
Token 消耗是技术负责人最关心的问题——推理成本的控制在 agentic 场景下比单次对话复杂得多。Anthropic 给的策略：
- 选对模型和原语：小任务不要动用多 agent 或复杂配置，有些场景用便宜模型即可。
- 明确停止条件：模糊的「做好了」会让 agent 提前交差或多跑无效轮次。
- 先小切片试点：动态工作流能 spawn 几百个 agent，务必先跑小块看消耗。
- 用脚本替代推理：确定性工作写一次脚本重复执行，不要每次都重新推理——比如 PDF 表单填充。
- 实时监控用量：
/usage按 skills 和 subagents 拆解消耗；/workflows显示每个 agent 的消耗，随时可终止。
代码质量方面，官方强调四点：保持代码库本身干净（agent 会遵循现有风格）、通过 skills 编码验收标准、让文档易于被检索到、用第二个 agent 做独立代码审查。当单次结果不达标时，不要只修这一次的问题——把它编码进系统，让未来所有迭代受益。
落地三步：试点 → 编码 → 规模化
这不是一套需要一次性推平的方案：
第一步：找一个你是瓶颈的任务。问自己：「哪一段是我必须坐在电脑前盯着的？」挑一个——比如前端变更后的人工 UI 检查，或 PR 合并前的代码审查。
第二步：把验证规则编码。写 SKILL.md 或目标条件。关键是把「我觉得可以了」变成「Lighthouse > 90」「控制台零错误」「全部测试通过」。这一步决定了自我检查的可靠性上限。
第三步：观察哪里卡住，迭代。第一次跑大概率不会完美——可能在某个步骤反复卡住，或过早交差。不要放弃机制本身，去修 SKILL.md 或目标条件。Anthropic 团队的建议是："Run the loop, observe the results like where it stalls or over-reaches, and don't be afraid to iterate on it."
走通三步之后再考虑升级到第四级 Proactive。它对质量保障体系要求更高：干净的代码库、成体系的 skills 文件、以及独立审查 agent。
常见问题
Turn-based 和 Goal-based 什么时候选哪个？
如果任务没有明确「完成」标准——比如还在探索架构方案——用前者。一旦能说清楚「什么叫做好了」，就切换到后者。规则很简洁：你把「检查」交给循环时用 Turn-based，把「停止条件」交给循环时用 Goal-based。
最大轮次设多少合适？
简单任务（lint 错误）设 3-5 轮；中等任务（性能优化）设 5-10 轮；复杂重构设 10-20 轮。太低可能留半成品，太高浪费 token。经验法则：先不带上限跑一次观察消耗，再设合理值。
SKILL.md 应该写多细？
越细越可靠，但维护成本也越高。建议先写 3-5 条核心检查项，跑一周，看 agent 在哪一步最常出错，再针对性细化。它是活的文档，和代码一样需要迭代。
第四级 Proactive 会不会烧穿预算？
可控。三个关键动作：(1) 设明确的每任务 token 上限；(2) 用 cheaper model 跑 routing 层，只在需要判断力时调用最贵模型；(3) pilot 先行——先在 10 个 bug report 上跑一遍看消耗模式，再决定是否全量。
你的团队现在可以做什么
我们正在帮多个技术团队把 Claude Code 从 Turn-based 升级到 Goal-based——核心工作是 SKILL.md 编写和评估模型搭建。如果你已经让团队用上了 AI 编程但卡在「每天还是要盯几十次屏幕」的阶段，可以直接联系我们聊一下当前瓶颈在哪。另外，站内 AIcoding 商业化落地：从个人提效到团队 10x 交付 这篇复盘了从 8 人到 5 人的完整数据，可以作为落地前的对照参考。