Anthropic提出的Loop Engineering概念正颠覆这一现状：开发者不再是提示者，而是系统设计者，通过构建自动循环让AI自主完成任务。本文深度解析Loop Engineering的六大核心模块与三个实战场景，揭示如何让AI真正成为生产力而非负担。

一、你还在”喂”AI吗？

如果你现在用 Claude 或者 ChatGPT 写代码，大概率你的工作流长这样：写一个提示，等它输出，看看哪里不对，再补一个提示，运行测试，报错了，把报错信息粘回去，让它修，它修完你再看，又有新问题……

二十分钟过去了，你突然意识到一件事：你在做的，是你最开始最想甩掉的那种活。

你没有在用 AI 解放自己，你只是换了一个对话框在打杂。

这不是 AI 不够聪明，而是用法的问题。2026年，AI 编程工具已经进化到了一个新阶段，但很多人的使用方式还停留在2023年——一问一答，手动推进，靠人肉驱动整个流程。

有人已经不这么干了。

Anthropic 内部负责 Claude Code 的负责人 Boris Cherny，最近在一次采访里说了一句让很多开发者觉得”被说中了”的话：“我已经不再直接提示 Claude 了，我的工作是写loops。”

这句话在开发者社区里迅速传开，Google 工程师 Addy Osmani 随后给这个模式起了个名字：Loop Engineering。

二、Loop Engineering 是什么？

这个词怎么来的？

事情的起点是今年6月，一个叫 Peter Steinberger 的开发者发了一条推文，大意是：你不应该再去提示 AI 了，你应该去设计让 AI 自己提示自己的循环。

这条推文获得了650万次浏览。不是因为它说了什么新鲜的技术，而是因为它说出了很多人隐约感觉到、但没有想清楚的一件事。

随后 Boris Cherny 公开表示自己的工作方式正是如此，Addy Osmani 把这个模式整理成文章，正式叫它 Loop Engineering。一个概念就这样从一条推文，变成了2026年 AI 开发圈最热的话题之一。

它到底是什么意思？

Loop Engineering，直译是”循环工程”，但这个翻译没什么感觉，说清楚点就是：不要再一条一条地喂提示给 AI，而是设计一套系统，让 AI 在这套系统里自己驱动自己完成任务。

你以前的角色是”提示者”，你负责推动每一步。Loop Engineering 之后，你的角色变成了”系统设计者”，你负责搭好框架，剩下的交给 AI 自己跑。

和定时任务有什么区别？

听到”循环自动运行”，很多人第一反应是：这不就是定时脚本吗？每小时跑一次，有什么新鲜的？区别在于循环里面那个”决策者”。

定时脚本跑的是固定逻辑，条件A触发动作B，永远如此。而 Loop Engineering 里面跑的是一个 Agent，它每次都会看当前的状态，自己判断下一步该做什么——继续、重试、回滚，还是停下来告诉你”这个我搞不定”。

脚本是死的，Agent 是活的。 这是本质区别。

这件事在以前做不到，因为模型不够聪明，理解不了复杂的目标和状态。但2025年底之后，模型能力跨过了一个槛，这套玩法才真正变得可行。

一个 Loop 长什么样？

一个能正常工作的 Loop，最少需要两样东西：触发器和可验证的目标。

触发器是让循环启动的信号。可以是一个新的 Pull Request、一次 CI 报错、一条 Slack 消息，或者你手动输入的第一个指令。

可验证的目标是让循环知道什么时候可以停。比如”所有测试通过、CI 变绿”，这是硬标准；或者”让另一个 Agent 来判断输出是否符合要求”，这是软标准。

但不管哪种，必须有一个明确的停止条件。

没有停止条件的循环不叫 Loop Engineering，那叫一台烧钱的机器。

三、一个 Loop 由什么组成？

1. 触发器（Trigger）

Loop 从哪里启动。

可以是外部事件，比如有人提交了代码、CI 跑挂了、定时到点了；也可以是你手动发出的第一条指令。触发器决定的是”什么情况下，这个循环该开始跑了”。

设计触发器的时候有一个容易忽略的点：触发条件要尽量明确，不能太宽泛。 如果触发器是”有任何代码变动就启动”，那你可能会让 Agent 在不必要的时候反复跑，既浪费资源，也容易出乱子。

2. 目标设定（Goal）

这是整个 Loop 里最重要的一块，没有之一。

目标决定了 Agent 努力的方向，也决定了循环什么时候可以结束。目标越清晰，Loop 跑得越稳；目标模糊，Agent 就会开始”自由发挥”，然后你就会得到一个方向不明、结果难以预测的循环。

好目标的标准只有一条：可以被验证。

“把代码写好”不是目标。”让所有单元测试通过”是目标。”优化一下用户体验”不是目标。”让页面加载时间低于1.5秒”是目标。

3. 工具调用（Tools）

Agent 在循环里能用哪些工具。

读写文件、执行命令、调用 API、搜索代码库、发送消息……这些都是工具。工具决定了 Agent 的”手脚”有多长，能做多少事。

这里有一个反直觉的建议：不要一开始就给 Agent 所有工具。 权限越大，出错的影响也越大。先从最小必要的工具集开始，跑稳了再逐步扩展。

4. 记忆与上下文（Memory & Context）

Agent 在循环里”记得”什么。

这是一个很容易被低估的模块。AI 本身没有跨会话的记忆，每次启动都是白板。如果你不主动管理上下文，Agent 在一个长任务里跑到一半就会”忘事”，开始走弯路，甚至重复做已经做过的事。

Claude Code 里有 CLAUDE.md 这类文件，就是用来解决这个问题的——把项目背景、规范、历史决策这些东西写进去，让 Agent 每次启动都能快速”想起来”自己在做什么。

上下文管理做得好，Loop 就稳；做得差，Loop 就像一个每隔几分钟就失忆的助手。

5. 验证机制（Evaluator）

谁来判断这一轮做得对不对。

这是 Loop Engineering 里一个很关键的设计：负责执行的 Agent 和负责验证的 Agent，最好是分开的。

执行 Agent 负责干活，验证 Agent 负责打分——对照目标检查输出，判断是否达标。如果达标，循环结束；如果没达标，把反馈传回给执行 Agent，重新来过。

这个设计的好处是避免”自产自销”——让同一个 Agent 既做事又评价自己的做事质量，它很难发现自己的盲点。拆开之后，验证这一环会客观很多。

6. 预算控制（Budget）

这个循环最多能花多少钱、跑多少次。这是最容易被新手忽略的一块，也是最容易让人心疼的一块。

没有预算控制的 Loop，一旦 Agent 陷入某种错误循环——比如它一直在尝试修一个它根本修不了的 bug——就会一直跑下去，直到你的账单让你清醒。

设定预算不是小气，是负责任。”最多重试5次”、”总花费不超过X美元”、”运行时间不超过30分钟”，这些都是合理的边界。超出边界就停下来，告诉你”我搞不定，请人工介入”。

四、如何设计一个真正能跑的 Loop？

理解了六个模块之后，很多人的第一反应是：好，我知道有这些东西了，但我怎么把它们拼在一起？

下面部分就是回答这个问题的。

Loop 的基本结构：三个角色

一个能正常运转的 Loop，本质上只有三个角色：Generator（执行者）、Evaluator（评判者）、Loop 本身。

Generator 是干活的那个 Agent。你给它一个目标，它去读代码、写代码、调接口、跑命令，产出结果。

Evaluator 是打分的那个角色。它拿到 Generator 的输出，对照你设定的目标和标准，判断这次做得行不行。它可以是另一个 Agent，也可以是一段确定性的程序——比如直接跑测试，看通过率Loop 本身是把这两个角色连起来的逻辑。Generator 产出 → Evaluator 评判 → 没过就把反馈传回 Generator 重新来 → 过了就结束。就这一个循环，反复跑，直到目标达成或者预算耗尽。

结构不复杂，但细节决定成败。

三个真实场景

光说结构还是太抽象，用几个实际场景来感受一下。

场景一：CI 自动修复这是 Loop Engineering 最典型的使用场景之一。

触发器：CI 流水线跑挂，报错了。

目标：让 CI 重新变绿，所有测试通过。

执行过程：Generator 读取报错信息，定位问题，修改代码，提交，触发新一轮 CI。Evaluator 就是 CI 本身——绿了就结束，还是红的就把新的报错传回去，继续修。

这个场景的好处是目标极其清晰，”CI 是否通过”是一个完全客观的标准，不存在模糊地带。这也是为什么它特别适合作为入门 Loop 来练手。

场景二：PR 自动审查触发器：有新的 Pull Request 提交。

目标：找出代码里的问题，给出审查意见。

执行过程：Generator 读取 PR 的改动内容，结合项目规范，生成审查评论。Evaluator 可以是另一个 Agent，专门判断这些评论是否有实质内容、有没有漏掉明显问题。

这个场景的难点在于目标相对软性，”好的审查意见”没有一个绝对的标准。所以 Evaluator 的设计会更讲究，需要给它一个足够具体的评判 rubric，比如”是否覆盖了安全问题、性能问题、代码规范问题”。

场景三：任务自动拆解与执行触发器：你发了一条 Slack 消息，说”帮我把登录模块重构一下”。

目标：重构完成，原有测试全部通过，没有引入新的报错。

执行过程：Generator 先把大任务拆成小步骤，逐个执行。每完成一步，Evaluator 检查一次。全部通过之后，Loop 结束，给你发一条消息说”做完了，你来看一下”。

这是目前最接近”真正自主工作”的场景，也是最容易出问题的场景。任务越复杂，中间可能出现的分叉越多，对上下文管理和预算控制的要求也越高。

最容易踩的三个坑

坑一：目标写得太模糊。

“把这个功能做好”、”优化一下性能”——这类目标对人来说都很难执行，更别说 Agent 了。目标必须可验证，最好是有一个明确的通过/不通过的判断标准。如果你发现自己的目标写出来之后，不知道怎么判断”做完了没有”，那这个目标就需要重写。

坑二：没有给 Loop 设退出条件。

Agent 陷入死循环是真实会发生的事。它可能一直在尝试修一个它理解有误的问题，每次输出都差一点点，但永远过不了 Evaluator 的检查。没有退出条件，这个循环就会一直跑下去。设定最大重试次数和最大花费上限，是最基本的保险。

坑三：上下文管理不做，靠 Agent 自己记。

长任务里，Agent 的上下文窗口是有限的。跑着跑着，早期的信息会被挤出去，Agent 开始”失忆”，做出前后矛盾的决策。解决办法是主动管理上下文——把重要的背景、决策、已完成的步骤写进文件，让 Agent 每次都从文件里读，而不是靠自己的”记忆”。