Claude Code 团队把 Loop 定义为"Agent 为了达成某个停止条件而重复执行的工作周期"。2026 年 6 月，他们在官方博客发布了一篇《Getting started with loops》，系统性地梳理了 Agentic Loop 的四种形态。这篇是对原文的翻译、梳理和一些延伸思考。

为什么需要 Loop

如果你用过 Claude Code、Cursor 或类似工具，你大概率经历过这个场景：写一段 prompt，等它执行，检查结果，再写下一段。这种"回合制"交互在简单任务中够用，但当你面对多步骤、跨时间、或者重复性的工作时——比如每天检查 CI 状态、每周做依赖升级、持续处理用户反馈——手动操作就成了瓶颈。

Claude Code 团队解决这个问题的方式是抽象出四种不同层级的 Loop。分类依据是四个维度：

  • 如何触发
  • 如何停止
  • 使用什么技术原语
  • 适合什么类型的任务

核心原则是：不要求所有任务都上复杂 Loop，从最简单的开始，按需升级。

Turn-Based Loop：最基本的循环

Turn-Based Loop 是最基础的模式。每一次你写 prompt 并发出去，就是一个 turn。Agent 在这个 turn 内完成：上下文收集、执行操作、自我验证、返回结果。

这是你和 Agent 之间的手动回合。你写 prompt，它执行；你检查结果，写下个 prompt。

这个模式适合那些探索性的工作——你还不确定要做什么，或者在决定方向。比如：问 Claude 帮你的项目加一个点赞按钮。它读代码、做改动、跑测试、返回一个它认为能跑通的结果。你手动检查，然后决定下一步。

提升 Turn-Based Loop 效率的关键是把人工验证步骤编码进 SKILL.md。比如你可以在项目中定义一个验证前端变更的技能：

验证前端变更的规范
- 1. 启动 dev server 打开页面
- 2. 与新控件交互、确认状态、截图前后对比
- 3. 检查浏览器 console：零新错误
- 4. 用 Chrome Devtools 跑 performance trace
任何步骤失败就修复并从头再来

这套实践是 Loop Engineering 的核心方法论：每次人工检查都是一次优化触发器，编码为技能后就可以由 Agent 自动执行。

Goal-Based Loop：定义完成的标准

当一个 turn 不够时（复杂任务往往如此），你需要的不是更多的 prompt，而是定义一个**“完成"的标准**。

在 Claude Code 中，/goal 命令做了这件事。你告诉 Agent"完成的标准是什么”，它会持续迭代直到目标达成，或达到你设置的最大尝试次数。关键机制：每次 Agent 试图停止时，会有一个评估模型检查你的条件是否真的满足，不满足就继续。

Goal-Based Loop 的精髓在于：确定性越强的标准，效果越好。 比如：

/goal 把首页 Lighthouse 分数跑到 90 以上，最多尝试 5 次

这里的"Lighthouse 分数 ≥ 90"就是一个确定性的、可验证的标准。Agent 不需要自己判断"够不够好"，指标告诉你。

这和我们在内容生产 Loop 中设定的收藏率 > 8% 是同一个思路——用数据而不是感觉来决定"是否完成任务"。

Time-Based Loop：让 Agent 按时间工作

有些工作需要定时重复。比如每天早上整理 Slack 消息、每 5 分钟检查一次 PR 状态。这种场景下，Turn-Based 和 Goal-Based 都解决不了——你不想手动触发每一个周期。

Claude Code 提供了 /loop 命令，让 Agent 按固定间隔重复执行同一个 prompt。比如：

/loop 5m check my PR, address review comments, and fix failing CI

/loop 的局限是它运行在你的本机上——关机就停了。如果希望 Loop 持久运行，可以用 /schedule 把任务搬到云端，变成 routine。

这个和我们的公众号数据复盘 72h 规则其实是同一类结构：不是人工定时去检查，而是设定一个触发器，时间到了自动跑一轮。

Proactive Loop：完全自主的运行

Proactive Loop 是四种形态中最复杂也最强大的。它把前面的模式组合起来，形成一个完全自主的运行系统——没有人在实时 loop 中，Agent 自己处理从触发到完成的全流程。

它的结构是：

  • /schedule 定义触发条件（定时或事件驱动）
  • /goal 定义完成标准
  • skills 编码验证步骤
  • Dynamic Workflows 编排多个子 Agent 协作
  • Auto mode 让 Agent 在循环中无需问询

一个完整的例子：

/schedule every hour: check #project-feedback for bug reports
/goal: 不停止直到本轮发现的所有报告被分拣、处理、回复
修 bug 时，用 workflow 在三个并行工作区探索解决方案，并由评审 Agent 做对抗性审查

这是 Loop Engineering 的终极形态：输入只有规则，系统自行运转、检查、迭代。

维护代码质量与管理 Token 消耗

Loop 的长期运行依赖两个前提：输出质量可控和成本可控。

关于质量，Claude Code 团队的四个建议：

  • 保持代码库本身干净——Agent 会模仿已有的模式和约定
  • 用 SKILL.md 编码"好的样子"——把团队的最佳实践文档化
  • 让文档触手可及——框架和库的文档应有最新的 best practice
  • 用第二个 Agent 做 Code Review——新鲜上下文的评审者不受主 Agent 推理路径的影响

关于 Token 管理，核心是边界清晰：

  • 选对原语和模型——小船不需要核动力
  • 明确成功和停止标准——越具体，Agent 到达解决方案越快
  • 大规模运行前先试点——Dynamic Workflows 能一次起几百个 Agent，先从小规模开始
  • 确定性工作用脚本——脚本比推理便宜得多
  • 不要比实际需要更频繁地运行——间隔匹配被监控对象的变化频率
  • 用 /usage 命令审查消耗

四种 Loop 速查表

类型 你交出 适用场景 工具
Turn-Based 检查 探索/决策 Custom verification skills
Goal-Based 停止条件 知道完成标准 /goal
Time-Based 触发 外部定时工作 /loop、/schedule
Proactive prompt 重复且定义良好的工作 以上全部 + Dynamic Workflows

怎么开始

Claude Code 团队的结语朴素且实用：看看你已经在做的工作。挑一件你成为瓶颈的任务，问自己一个问题——你能交出哪一步？

  • 能否写出验证标准？
  • 目标是否足够清晰？
  • 工作是否按计划到达？

一旦有了想法，就跑起 Loop，观察它在哪卡住、在哪过度执行，然后迭代它。

这和内容生产的 Loop Engineering 如出一辙：先跑第一圈，然后根据数据反馈调整下一圈。 无论是 AI Agent 的循环，还是内容生产的工作流，底层是同一个 pattern——把重复劳动自动化，把判断力留在关键节点。

参考来源：Claude Blog — Getting started with loops，作者 Delba de Oliveira & Michael Segner