最近一段时间，越来越多人开始讨论一个词：Loop。

尤其是在 Coding Agent 圈子里，大家经常说，接下来真正重要的已经不只是怎么写 Prompt，而是怎么设计 Loop。

刚开始看到这个说法，我也觉得有点抽象。Agent 本身不就会反复思考、调用工具、修改代码吗？为什么还要专门设计一个 Loop？

周末两天看完 Claude Code 团队写的一篇文章，我才发现，这件事其实没有那么玄乎。

https://x.com/ClaudeDevs/status/2074208949205881033

他们对 Loop 的定义很简单：

让 Agent 重复执行一段工作，直到满足某个停止条件。

比如让 Agent 修改代码、运行测试、检查报错。如果测试没通过，它就继续修改。全部通过之后，任务结束。

这就是一个最简单的 Loop。

再比如，每隔一个小时检查一次 GitHub 上有没有新的 Issue。有的话就分类、分析原因、尝试修复，没有的话就等待下一次检查。

这也是一个 Loop。

它和我们平时说的多试几次、定期跑个脚本很像。

区别在于，传统脚本只能执行提前写好的固定步骤，Agent 可以根据每一轮的结果，重新判断下一步应该做什么。

Claude Code 团队按照 Loop 如何触发、如何停止，以及人交出了哪一部分控制权，把它分成了四种类型：

对话式 Loop、目标式 Loop、定时式 Loop，以及流水线 Loop。

这四种 Loop 并不是完全独立的。它们更像一条逐渐递进的路线：一开始由人推动每一轮，后来把验收条件、触发时机，甚至整条工作流逐步交给 Agent。

#01

第一种：对话式 Loop

我们平时使用 Agent，其实已经在跑这种 Loop。

很多人会把 Loop 想成一套很复杂的自动化系统。其实我们每天和 Codex、Claude Code 对话的时候，就已经在跑一种最简单的 Loop。

比如我让 Codex 帮我修一个前端 Bug。

它会先读一下代码，找到可能的问题，修改文件，然后运行测试。它觉得任务完成之后，把结果返回给我。

接下来，我打开网页看一眼，发现按钮虽然能点，但手机上的样式错位了。于是我再补一句：移动端的布局还有问题，继续修改。

Agent 再执行一遍。

在这个过程中，Agent 跑完一圈，我检查一次，然后决定要不要继续。我们两个人在接力跑圈。

Claude Code 团队把它叫作 Turn-based Loop，也就是由一轮轮对话推动的循环。

这种方式非常适合探索性的工作。比如第一次分析一个陌生项目、尝试实现一个新功能、写一篇文章，或者研究一个还没有明确答案的问题。

因为任务刚开始的时候，我们自己可能也不知道最终应该做成什么样。Agent 每完成一步，我们看一下结果，再决定下一步往哪里走。

这时候，人依然是 Loop 里很重要的一环。

问题在于，我们经常重复做相同的检查。

每次 Agent 修改完前端，我都要打开页面，分别检查电脑和手机的显示效果；点击几个按钮；看看浏览器控制台有没有报错；再跑一遍测试。

既然检查流程每次都差不多，就可以把它写成一个 Skill，或者一份固定的验收说明。

以后 Agent 完成修改之后，先按照这份说明自己检查一遍。发现问题就继续改，全部通过以后再来找我。

这样一来，原本需要我亲自完成的一部分 Loop，就被固化进了系统。

这个思路不只适用于代码。写文章也一样。

可以把自己的检查标准写下来：有没有事实错误，开头是不是太慢，有没有重复表达，案例是否真实，是否出现了自己不喜欢的句式。

做数据分析时，也可以要求 Agent 检查数据口径、异常值、时间范围和计算结果。

Skill 的价值，不只是教 Agent 怎么干活，它还可以把我们平时怎么验收工作固化下来。

#02

第二种：目标式 Loop

复杂任务，需要先告诉 Agent 什么叫完成。普通对话式 Loop 有一个很明显的问题：Agent 经常不知道什么时候应该停止。

你让它优化一下这个页面，它改了字体、调整了间距，可能就认为自己已经完成了。

但你心里的优化，可能是让 Lighthouse 分数超过 90，让首屏加载时间低于两秒，或者让所有移动端测试全部通过。

“优化一下”很模糊，“Lighthouse 分数达到 90”就清楚多了。这类任务更适合 Goal-based Loop，也就是目标驱动的循环。

在 Claude Code 里，Anthropic 提供了 /goal。不过这套思路并不属于某个产品。无论使用 Codex、Claude Code，还是自己搭的 Agent，核心都一样：

提前定义一个可以验证的完成条件，让 Agent 没达到目标之前继续工作。

比如：把首页的 Lighthouse 性能分数提高到 90 以上，最多尝试 5 轮。

Agent 每完成一轮修改，都要重新测试。如果分数只有 83，就继续分析瓶颈；达到 91，Loop 才结束。

这里有两个条件。

一个是成功条件：分数达到 90。另一个是兜底条件：最多尝试 5 轮。

只有成功条件，Agent 可能为了一个无法实现的目标不停消耗 Token。只有轮数限制，它又可能在任务还没有真正完成时提前结束。

目标驱动的 Loop，适合所有结果可以明确验收的任务。

代码测试全部通过、页面没有控制台报错、表格中没有空值、迁移的数据量与原系统一致、研究报告覆盖指定的十家公司，都可以成为停止条件。

它和普通 Prompt 最大的差别，在于我们不再只告诉 Agent 做一个动作，还会告诉它做到什么程度。

过去我们经常写：帮我检查一下这个产品。换成 Loop 的思路之后，可能会变成：

分别在电脑端和移动端测试注册、登录、支付和退款流程。每个流程至少覆盖正常路径和一个异常路径。

发现问题后尝试复现，并记录操作步骤、截图和控制台日志。所有测试完成，且每个问题都有明确记录后结束。

Agent 能不能持续工作，很多时候并不取决于模型够不够聪明，关键在于我们有没有把“完成”说清楚。

#03

第三种：定时式 Loop

有些任务一次做完就结束了，还有一些任务会按照固定节奏反复出现。

比如每天早上汇总昨天的行业新闻，每半个小时查看一次 CI，每周整理一次销售数据，或者持续关注客户反馈。

这时，Loop 需要解决另一个问题：什么时候开始下一轮？

最简单的方式是按照时间触发。

在 Claude Code 中，可以用 /loop 每隔一段时间重复执行同一个任务，也可以通过 /schedule 把它放到云端长期运行。

其他 Agent 产品里，可能叫定时任务、自动化或者 Routine，名字不同，逻辑差不多。

假设一个 PR 正在等待审核，可以让 Agent 每隔十分钟检查一次：

如果收到新的 Review 评论，就读取评论、修改代码并重新提交；如果 CI 失败，就查看日志并尝试修复；如果 PR 已经合并，Loop 自动结束。

这种方式特别适合需要和外部系统打交道的工作。因为外部状态一直在变化，Agent 必须隔一段时间看一眼，才能知道要不要行动。

不过，定时检查也很容易浪费 Token。如果一个频道一天只有几条新消息，却让 Agent 每分钟检查一次，大部分运行都没什么实际价值。

所以，能用事件触发的地方，最好用事件触发。

收到新邮件时启动、出现新的 Issue 时启动、CI 失败时启动，通常比不断轮询更省 Token。

暂时接不上事件系统，再考虑定时检查。检查频率也要根据实际变化速度来设置。

#04

第四种：流水线 Loop

再往前一步，就是 Proactive Loop，也就是

流水线

 Loop。

这时候，Loop 不再只负责重复一个动作，而是变成一条长期运行的工作流水线。

比如，公司有一个产品反馈频道。过去每天都需要有人进去查看消息，把反馈分成 Bug、功能建议和使用问题，再分别转给产品、研发或客服。

如果使用 Proactive Loop，可以把整套流程连起来：

系统收到新反馈后，Agent 自动读取内容，判断类型，检查是否存在重复问题。

如果是 Bug，就尝试复现，收集日志，创建 Issue；如果能够明确定位，就让 Coding Agent 创建分支并尝试修复。

另一个 Agent 负责 Review；确认无误后，再给用户回复处理进展。人不需要在每一个步骤中点一下继续。

只有遇到高风险操作、信息不足或者多个方案难以取舍时，Agent 才把任务交回来。

这类 Loop 的特点，是输入会源源不断地出现，但处理流程相对稳定。Bug 分拣、数据迁移、发票处理、客户反馈、内容审核，都很适合这种模式。

Loop 的演进过程，本质上是人逐渐退出执行链路的过程。但退出不等于完全不管。

人的工作会往前移动到：设计流程、定义边界、写验收标准、处理例外情况。

#05

Loop 怎么保证质量

Loop 最危险的地方，是它会放大系统原有的问题。

一次调用做错了，可能只产生一个错误结果。一个长期运行的 Loop 如果缺少检查，可能连续制造几百个错误。

所以，Loop 只是一个不断重复执行的壳。真正决定质量的，是周围的环境。

做 Coding Loop 时，代码库本身要尽量干净，目录、命名和测试方式要保持一致。Agent 很擅长模仿已有代码。

项目里到处都是临时方案，它也会继续生成临时方案。

文档也要放在 Agent 容易找到的位置。使用什么框架、接口如何调用、哪些目录不能修改、发布流程是什么，都应该写清楚。

更重要的是，Agent 必须有办法看到自己的结果。

比如修改网页之后，要能打开浏览器实际操作一遍。

写完代码要能跑测试，生成数据要能用脚本核对。做 Research 也一样，最后要能回到原始来源逐项检查。

很多任务失败，并非 Agent 不会做，而是它做完以后看不到结果，只能凭感觉宣布完成。

对于重要任务，还可以引入第二个 Agent 做 Review。

负责写代码的 Agent 容易顺着自己的思路继续往下走。换一个拥有全新上下文的 Agent 检查，更容易发现遗漏。写作、研究和数据分析同样可以这样做。

一个 Agent 负责生产，另一个 Agent 负责挑错，最后再由规则或人做决定。

还有一个很重要的习惯：某次 Loop 出错以后，不要只修这一次的结果。

需要继续追问：为什么系统没有提前发现？能不能增加一条测试？能不能把判断标准写进 Skill？能不能增加一个必须经过的 Review 环节？

这样，每次失败都能让下一轮 Loop 更稳定。

#06

设计 Loop，也是在设计成本

Agent 可以无限尝试，钱不可以无限烧。

Loop 最容易出现的情况，就是任务目标模糊、停止条件缺失，几个 Agent 互相讨论了很久，最后没有产生多少有效结果。

控制成本，第一步仍然是缩小任务。

能一次调用解决的问题，没有必要启动三个 Agent。能够用脚本完成的固定动作，也不要每次都让模型重新推理。

比如把数据转换成固定格式，写一个脚本通常更快、更稳定。Agent 只负责判断什么时候运行脚本、参数应该填什么，以及运行失败以后如何处理。

模型也可以分层使用。

读取消息、提取字段这类固定动作，可以交给更快更便宜的模型。遇到架构层面的判断或者比较复杂的排错，再用能力更强的模型来处理。

对于批量任务，先拿十条数据试跑一下。确认效果和成本之后，再扩大到一千条。不要一上来就让动态工作流启动几百个 Agent。

一个可靠的 Loop，通常都带着明确的边界：最多运行多少轮、最多处理多少条、消耗达到多少时暂停、哪些操作必须经过人确认。

没有边界的自动化，很容易从生产力工具变成 Token 粉碎机。

#07

怎么开始第一个 Loop？

我觉得不用一开始就搭一套庞大的多 Agent 系统。

先观察自己每天的工作，找到那个反复出现、结构比较稳定，又总需要自己盯着的环节。

可能是每次发布文章之前检查错别字和事实，可能是每天整理客户反馈，也可能是代码修改完成后反复测试几个页面。

然后把这件事拆成几个问题：

什么情况会触发它？Agent 每一轮需要完成什么？它如何看到并验证结果？什么条件代表任务完成？最多允许尝试多少次？什么情况必须停下来找人接管？

甚至可以直接套用一个很简单的模板：

当某件事发生时，Agent 执行某项工作。完成后使用某种方法检查结果。

如果没有通过，就根据反馈继续修改，最多重试若干次。满足某个条件后结束。遇到某类风险或不确定情况时，交给人处理。

先跑起来，再观察它容易卡在哪里，又会在哪些地方冲得太快，然后不断补充工具、验收条件和边界。

过去，我们使用 Agent，更多是在研究一句 Prompt 应该怎么写。到了 Loop 这一步，我们开始设计一整段工作该怎么持续运行。

Prompt 决定 Agent 这一轮做什么。Loop 决定它如何根据结果继续工作，什么时候再次启动，又在什么地方真正停下来。

推荐我们 9 月 12 日在上海举办的 AI Maker Summit 大会。现在 6 折售票中。这次邀请到了不少一线的实战讲师，内容非常有料。

大会一共设计了八个专题，包括：

AI Native 产品、Harness Engineering、AI Agent、AI Maker、OPT 一人团队、AI Coding、Eval、AI 投资。

四个分会场并行，一天时间，36 个 talk。

我们想做的事情是，让大家来一天，就能快速了解这个行业正在发生什么，有趣的人正在思考什么。