昨天刷到雷科技那篇关于 Loop 工程的文章，封面写的是「杀死比赛」。

我当时就想，一个技术概念要是真能杀死比赛，不会是靠标题杀死的，得看它能不能解决我们每天面对的那些具体问题。所以我花了几个小时，把 Anthropic 的博客、Claude Code 的实际行为、还有我自己用 LangGraph 和 Spring AI 做的一些小项目翻出来，想清清楚这个被吹得很热的 Loop 工程，到底是啥。

先说结论。Loop 工程不是新东西，但它确实把 Agent 的讨论从「怎么记住更多上下文」拉到了「怎么让程序正常转起来」。这个转移本身很重要，但同时也被很多人误读成「给大模型套个 while True，它就能自己干活」。

真相要复杂一些。Loop 工程不是魔法，它是一整套让模型持续、可观测、可终止地工作的机制。做得好，Agent 会像一个能接住任务的人；做得不好，它就是一个会把错误快速复制很多次的自动装置。

一、从提示词到 Harness 再到 Loop，Agent 到底多了什么

两年前我用 GPT-3.5 写代码的时候，整个流程很简单。把问题打进去，它给一段代码，我拷走自己跑一下。如果报错，我把报错信息丢回给它，它再改。这个过程中，每一次迭代都是我手动推动的。

后来出现了各种 Copilot，提示词工程也开始被强调。但提示词工程到底是什么？实际上你不是在教模型说话，你是在给一个无状态、无工具、无记忆的系统设计一次性输入。你输入越精巧，输出越稳定，但模型不会自己打开文件，不会自己跑测试，也不会在不行之后自己重试。

所以引出了 Harness 工程，也就是给模型加上工具调用、上下文管理、权限控制这一套。到这一步，模型还是模型，只不过被装进了一个能接触外部世界的框架里。

但 Harness 工程解决的是「能不能做」的问题，不一定解决「怎么持续做」的问题。

Loop 工程又往前走了一步。它不是在讨论模型本身，而是在讨论模型和外部世界的互动为什么要不断循环、每一次循环应该干什么、什么时候停下来。它关心的不是单次调用，而是多次调用之间的结构。

这个区别看起来很模糊，但很关键。如果你写过一点 LangGraph，你应该熟悉它的 StateGraph 里有一种节点叫「条件边」，可以根据某个状态决定跳到哪个节点。从某种意义上说，LangGraph 就是在图的层面帮你设计 Loop，你不用自己写 while True，但你依然要想清楚，什么时候继续，什么时候结束，这两个判断标准是什么。

二、Anthropic 说的四种 Loop，到底是分类还是提醒

Anthropic 在那篇「Getting Started with Loops」的博客里，把 Loop 分成四类，turn-based、goal-based、time-based 和 proactive。

我先并不觉得这个分类多么翻天覆地，因为它按的就是两个维度，触发条件和停止条件。但它之所以引起讨论，是因为它把这个一直隐藏在程序里的逻辑拉到了表面上。

举个例子。过去你在 Claude 网页版里输入一个问题，它给你一个答案，你再输入下一个问题，它再给答案。这其实就是 turn-based loop，只不过每一次循环都是你视觉触发的，停止条件是模型觉得已经给出满意回答。

Claude Code 就不一样了。你输入「帮我把这个登录页面的测试修上」，它不会只输出一段修复建议，它会自己打开文件、看报错信息、修改代码、跑测试、看结果。如果测试还是不通过，它就在同一个目标下继续修。这就是 goal-based loop。

这里有个细节我觉得很重要，但很多人没看到。goal-based loop 的关键不是「模型多跑几步」，而是「停止条件要求比较精确」。如果你说「把页面修好」，模型很难判断什么叫好；如果你说「测试全部通过且首页访问不报错」，那就有了一个可验证的停止条件。所以 Loop 工程一半是在设计循环，另一半是在设计怎么让模型知道自己停下来。

再往后两类更容易被误解。time-based 并不是让 AI 每五分钟死循环做同一件事，而是它会在固定间隔去检查某个外部状态。比如每小时看一下你的 PR 有没有新评论，有的话就帮你修复。proactive 更容易被过度活化，因为人们总想象它自己发现问题、自己开干。但目前为止，主流产品里的 proactive 大都还是围绕预定规则触发的，比如你设置了「测试覆盖率下降就补用例」，而不是真的让模型随便看到什么就干什么。

所以我的看法是，四种 Loop 不是帮你作业分类，而是在提醒你一件事，设计一个 Agent 时，你必须同时回答触发和停止这两个问题。你回答得越清晰，它就越不容易出现「停不下来」和「做无用功」的情况。

三、我在自己项目里踩过的几个坑

上个月我用 LangGraph 给内部工具加了一个简单的 Agent 流程，让它能根据用户的自然语言请求去操作数据库。我当时觉得自己设计得挺好，结果上线第一天就出了两个问题。

第一个问题是停不下来。有一次用户问，「帮我查一下最近三个月有哪些项目超过预算」。Agent 一开始执行得挺对，查出来三个项目。但它不甘心，觉得可能还有更多没被发现，就继续搜。搜了十几轮之后，时间越来越久，最后用户等不及直接关掉了窗口。

事后我反思，问题出在停止条件上。我当时只设计了「找到答案就结束」，但没有定义「找到多少答案才结束」。如果我提前说，「找到最近三个月的 Top 3 就停」，这个问题就不会出现。

第二个问题更幽。有一次 Agent 调用了一个批量更新的工具，然后在反馈里看到「操作成功」，就以为自己作对了。但其实那个工具只返回了影响行数，没有做数据校验，结果操作的数据不对。事后我发现，我需要的不是更好的提示词，而是更严的验证器。每次工具调用之后，模型应该自动调用另一个工具去对比数据，而不是仅仅信任第一个工具的返回值。

第三个坑是没有断点机制。有一次模型走到一个很偏的方向，一直在尝试用一个根本不存在的表名。它转了很久才给我一个错误报告。这时候我才意识到，Loop 里必须有一个给人看的中间瞬间。不然用户不知道它在干什么，只会觉得它在卡死。

这三个坑让我清醒过来。Loop 工程不是象征性地让模型自己转，而是要让模型在一个可观测、可验证、可终止的结构里转。

四、为什么这一波开始在产品里落地

其实 Loop 不是今年才有的。之前各种提示词里的「请逐步思考」、「请先做 A 再做 B」，到底也是在手动设计循环。为什么到了 2026 年，Claude Code、Codex、ZCode、Kimi Work 突然都开始讲 Loop 了？

因为前提条件到位了。

第一个前提是工具调用的可靠性。如果模型每次调用工具都像在捞鱼，那循环越多次只会越乱。现在模型调用代码编辑、终端、搜索这些工具的准确率明显提高了，循环的每一圈才能累积进度，而不是累积错误。

第二个前提是上下文管理。之前很多 Agent 框架把对话历史往模型里一塞，跑几圈就爆了。现在大家开始用文件系统、索引、记忆模块做结构化存储，让 Loop 能转更多圈。

第三个前提是验证环境。代码场景之所以最先被打穿，就是因为这里反馈比较及时、清晰、可重复。测试通过没有？CI 红没红？diff 有多少行？这些是确定性的。在不确定性很高的场景里，Loop 很容易陷入「我觉得做完了」和「你觉得没做完」的拖拉中。

这也解释了为什么目前 Loop 落地最好的地方还是代码。不是因为程序员特殊，而是因为编码有这么一套反馈比较及时、清晰、可重复的验证体系。

但其他场景并不是没机会。研究报告、法务检索、招聘筛选、运营监控，这些工作都有一个共同特点，任务不是一句话能做完，但成功标准可以被写出来，过程可以被记录，结果可以被检查。

这也是我觉得 Loop 工程最有趣的地方，它不是把人从循环里踢出去，而是让人从每一步都要盯的驱动者，变成目标和验收标准的定义者。

五、Loop 和 CI/CD 有一个很像的地方

这几天我一直在想，一个好的 Loop 应该像一个好的 CI/CD 流水线。你不是让它随便跑，你是用测试、门禁、回退、检查点这些机制把进度和质量绑在一起。如果没有这些机制，它就只是一个等待爆炸的黑盒子。

但 CI/CD 的输入是代码，而 Loop 的输入是目标。代码可以被 diff、被 review、被回滚，目标却很难被这样处理。所以 Loop 的难点从来不在循环本身，而在你怎么把目标翻译成可验证的状态。

这里有一个我自己踩过好几次的坑。我曾经以为只要给模型一个清晰的目标，它就能自己分解任务。结果发现，模型分解出来的任务经常和我不在一个频道上。它可能会把「优化查询性能」分解成「加索引」，但忽略了「这个表已经在其他地方被锁住了」这种业务上下文。

所以我现在做 Loop 设计时，会额外加一步，让模型把它的计划先写出来，等人确认或者等规则匹配通过后再执行。这听起来像拖慢了速度，但其实是减少了在错误方向上狂奔的风险。LangGraph 的 interrupt 节点和 human-in-the-loop 节点就是干这个的，它让你能在循环中间插一个「先停一下，给人看一眼」的检查点。

六、设计一个 Loop，我会从哪里开始

如果你现在想给自己的项目加一个 Loop，我建议不要先纠结是 turn-based 还是 goal-based，而是先回答下面四个问题。

第一个，任务的成功标准是什么？这个标准必须是可以被程序化验证的。如果你自己都不清楚「什么叫做好」，模型就更说不清楚了。

第二个，什么时候必须停下来问人？有些决策不能交给模型，比如涉及资金、涉及敏感数据、涉及上线发布。这些地方你必须在设计里提前给出中止点，而不是等它出了错再揪回来。

第三个，每一圈的反馈是什么？反馈不能是模糊的「成功」、「已完成」，应该是具体的数据。比如测试通过率、签入率、距离目标的误差等等。

第四个，给用户看的中间状态在哪里？用户需不需要知道 Agent 正在干什么？如果需要，你怎么展示？如果不需要，你怎么让他们相信结果是对的？

答完这四个问题再去看 LangGraph、Spring AI、Claude Code 这些底层工具，你会发现它们只是不同类型的放大器。LangGraph 放大的是状态和边的组织能力；Spring AI 放大的是与 Java 生态的整合能力；Claude Code 放大的是终端环境里的实时工具调用能力。

七、写在最后

最后我说说自己的判断。

我相信 Loop 工程会成为下一个阶段的主流话语，不是因为它新鲜，而是因为产品和模型终于到了能让它可靠走通的时候。

但我不觉得它会杀死提示词。提示词会变成 Loop 里的一个组件，而不是被替代。正如软件工程没有杀死代码，只是把代码装进了更稳定的结构里。

同时我也必须警告一点，Loop 设计得不好，会让错误以更快的速度自我复制。如果你的验证器不足、停止条件不清、权限边界模糊，那就不是一个自动化助手，而是一个自动化闹剧。

唯一不同的是，CI/CD 的输入是代码，而 Loop 的输入是目标。当目标能被写清楚，进度能被验证，结果能被检查，模型就不再只是一个回答问题的工具，它开始像一个能接住任务的协作者。

可能真正要杀死的，不是提示词，而是我们之前对于「用 AI 就得一句一句指挥」的认知。

参考链接