最近两周，如果你打开任何一个 AI 工程师的社交媒体，大概都会撞见同一个词：loop engineering。
事情的引爆点很集中。OpenClaw 的创始人 Peter Steinberger 发了条推文："你不应该再手动提示编码 agent 了。你应该设计循环来提示你的 agent。"几天后，Anthropic Claude Code 的负责人 Boris Cherny 跟了一句："我不直接提示 Claude 了。我写循环，让循环去提示 Claude 并弄清楚要做什么。我的工作是写循环。"然后 Google 工程总监 Addy Osmani 写了一篇近 5000 字的文章，给这个概念安上了正式的名字。
然后就吵起来了。有人兴奋地宣布"提示工程已死"。有人嘲讽这是"为了让你多烧 token 而发明的营销词"。Reddit 上有人直接说："能不能别再发明带 engineering 后缀的狗屁 buzzword 了，就为了显得自己更聪明？"
我看了大概十几篇讨论、翻了几份技术博文和一份工程效能报告之后，想说点不一样的。
我不觉得 loop engineering 会像 prompt engineering 那样成为每个开发者的必备技能。也不觉得它完全是炒作。它是一个方向正确的概念，但名字起错了。真正的重点不在 loop 上。
Loop 本身简单到不像话
如果你把"agent loop"剥到最核心，它长什么样？有人翻遍了 Claude Code、Codex、Cursor、LangGraph、smolagents 的源码，发现所有框架的答案几乎一模一样。核心逻辑就是这个 6 行的 while 循环：模型产生工具调用，执行工具，把结果塞回上下文，模型再看结果再决定下一步，直到模型不再要求调用工具，loop 结束。
就这些。
有一个案例特别能说明问题。mini-SWE-agent，一个约 100 行 Python 代码的 agent，只给模型一个 bash 工具，在 SWE-bench Verified 上跑出了 76.8% 的成绩。而完整版 SWE-agent 经过一年多的工程优化，也就高了几个百分点。
这说明什么？说明 loop 本身不是瓶颈。一个 100 行的 agent 就能把事情做到 95% 的水平。真正的功夫全在 loop 外面。
外面是什么？是上下文管理（Manus 团队实测发现工具响应占了 agent 看到的 67.6% 的 token，系统提示词只占 3.4%）。是缓存命中率（缓存 token 和非缓存 token 的价差是 10 倍，保持上下文前缀不变比优化提示词省钱得多）。是成本控制（Anthropic 内部数据显示单 agent loop 比标准对话多烧 4 倍 token，多 agent 系统是 15 倍）。是安全护栏（最大迭代次数、挂钟超时、loop 指纹检测——连续三次相同工具调用就强制中断，有团队在日志里发现 agent 把同一个错误答案重复了 58 次）。
这些才是 loop engineering 真正的"engineering"部分。但它们跟 loop 本身没关系。
Loop Engineering 不会像 Prompt Engineering 那样普及
我知道很多人会把 loop engineering 看成 prompt engineering 的自然接班人。prompt engineering 是 AI 时代的第一波工程范式，人人都要学怎么写提示词。然后依次出现了 agent engineering、harness engineering，现在是 loop engineering。这个叙事逻辑上是通顺的。
但我觉得它不会大规模普及。原因很简单：门槛不一样。
Prompt engineering 的门槛极低。你会用自然语言描述需求就行，不需要理解任何底层机制。Loop engineering 的门槛高得多：你需要设计自动化调度逻辑、理解并行隔离的原理、处理上下文窗口的动态变化、建立成本监控体系、检测循环退化模式。这不是"写提示词"的延伸，这是 DevOps 或平台工程层面的工作。
而且更重要的是，loop engineering 的大部分能力正在被工具原生吸收。Osmani 列出来的五个要素——定时自动化、并行隔离、项目知识固化、外部工具连接、子 agent 分工——Claude Code 和 Codex 都已经原生支持了。随着工具成熟，这些能力会成为默认行为，你不需要手动设计。
一个类比：十年前你还需要手动配置 Webpack 和 Babel 才能跑一个前端项目。现在 Vite 让你一行配置都不用写。Loop engineering 大概率走上同样的路：作为独立概念热一阵，然后被工具消化成基础设施。
真正的问题不是 Loop，是判断
但我写这篇东西不是为了预言一个概念会不会火。我真正想说的是 loop engineering 暴露出来的那个更深层的问题。
Loop 是一个执行结构。它回答的是"怎么跑"。但 loop engineering 真正的质量瓶颈不在执行层，在判断层。你凭什么决定循环该停？
Osmani 在描述 Codex 的 /goal 机制时提到一个关键设计：判断任务是否完成的模型，不是写代码的那个模型，而是一个独立的检查者。"制造者与检查者分离"。这个设计本质上是在 loop 内部嵌入了一个评测系统。Oracle 的技术博文也强调了同一个点：模型停止生成工具调用，不代表用户的目标被满足了。把"模型不说话了"当成"任务完成了"是 agent 设计里最隐蔽的 bug。
所以 loop engineering 的核心矛盾不是循环设计得好不好，而是停止条件的判断确定性高不高。而判断确定性的基础设施是什么？是评测。
评测不是"测试是否通过"那么简单。评测是一套关于"什么叫好"的清晰定义和可验证标准。它需要你对业务有深入理解（什么叫"正确的"报表？什么叫"合理的"推荐？），需要你积累真实的失败案例（不能只靠合成的测试数据），需要你持续维护（业务变了标准要跟着变），还需要你区分"机器能判断的"和"必须由人判断的"。
这些都不是技术问题。这些是你对工作质量的认知沉淀。
数据不会说谎
有个数据让我看完之后情绪比较复杂。Faros AI 在 2026 年 6 月发布了一份工程效能报告，基于 2 年遥测数据、覆盖 22,000 名开发者。几个关键数字：
AI 让 PR 合并率提升了 16.2%，每个开发者的 epics 完成量增加了 66%。但同时，代码变更量（churn）增加了 861%，每 PR 的事故率增加了 242.7%，每个开发者的 bug 数增加了 54%。PR 审查时间中位数延长了 5 倍。未经审查就合并的 PR 增加了 31%。
报告给这个现象取了个名字："加速鞭打效应"。AI 向一个围绕人类速度和人类质量的开发流程中倾注了大量输出，而这个流程的设计从来没有考虑过要吸收这么多、这么快的代码。
更让人担心的是趋势方向：bug 率与 AI 采用率的关系不是随着团队成熟而趋于平坦的，而是在加速恶化。Kent Beck 看完这份报告后的评论只有一句话："打字变快了。思考没有前移。"
这句话精准地概括了 loop engineering 的根本矛盾。Loop 让"打字"变快了，代码产生的速度、测试运行的频率、PR 提交的节奏，所有执行层的动作都被加速了。但"思考"——判断代码是否正确、设计是否合理、质量是否达标——并没有因为 loop 的出现而自动加速。恰恰相反，更多的代码意味着更多的审查负担，而审查是一种线性的人类认知行为，无法像代码生成那样被无限制地加速。
Loop engineering 放大了一个组织里原本就存在的结构性失衡：生成端被指数级加速了，但验证端的带宽几乎没有变化。
评测才是不可外包的东西
我在日常工作中对这个问题的体感越来越强。
现在我们团队在用 AI 做数据分析、做报表生成、做业务异动检测。AI 生成结果的速度远比人工快，但验证结果的速度并没有同步提升。一个同事用 AI 半小时写了 5 个分析维度，然后我们花了两天去验证这些分析方向是不是对的、数据口径是不是一致的、结论是不是可靠的。
这不是 AI 的问题。这是我们之前对"什么叫好的分析"没有做过系统化的定义。我们靠经验、靠直觉、靠"看起来差不多"来判断质量。当产出速度被 AI 提上来之后，这种模糊的判断方式马上就崩了——你来不及看，你也判断不过来。
这让我越来越确信一件事：在 AI 能写代码、能跑 loop 的时代，真正稀缺的能力不再是"写出对的东西"，而是"知道什么叫对的东西"。后者需要你对自己的业务有足够深的理解，对质量标准有足够清晰的把握，对"什么叫完成"有足够精确的定义。
评测不是技术问题。评测是组织的认知沉淀问题。你能把"好"定义得多清楚，你的 agent 就能跑得多可靠。你定义不了，loop 再漂亮也是盲跑。
Loop 不是答案，是问题
Loop engineering 这个名字有误导性。它让你把注意力放在循环设计上，但循环设计是这里面最不重要的部分。一个 6 行的 while 循环就能跑，100 行的 agent 就能在 SWE-bench 上拿高分。你花再多时间优化 loop 的结构，回报也是递减的。
真正该花时间的地方是两件事。第一，你能多清楚地定义"任务完成"的标准。第二，你能多可靠地验证这个标准是否被满足。这两件事合在一起，就是评测。
但评测是苦活。它不性感，不出文章，不适合发推文。它要求你坐下来，仔细想清楚你的工作里到底什么算好、什么算差、边界在哪里。它要求你积累失败案例，要求你维护测试数据集，要求你在业务变化的时候回头更新标准。这些东西写不进一个漂亮的"loop engineering 五要素框架"里，但它们是决定你的 loop 到底是帮你还是害你的唯一变量。
我猜这也是为什么 loop engineering 这个概念在社交媒体上讨论得热火朝天，而几乎没有人认真讨论评测。因为评测没有"范式转移"的叙事张力，没有可传播的一句话 slogan，没有能放进 Keynote 的架构图。但它才是让 loop 从"看上去很酷"变成"真的能跑"的东西。
Osmani 文章的最后一句我很认同："Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
我想加一句：真正的 loop engineer，不是学会设计循环的那个人。是知道什么时候该停下来、并且有底气说"停在这里是对的"的那个人。而这份底气，不来自你的 loop 设计得多精妙，来自你的评测做得多扎实。