你大概最近读过类似这样的话：
"你不应该再去 prompt 你的 coding agent 了。你应该去设计 loop，让 loop 去 prompt 你的 agent。— Peter Steinberger"
第一反应大概是：那我们一直在做的事情算什么呢？
其实这句话暗示着：精心构造 prompt、不断迭代已经不再是工作的核心了。agent harness engineering 本质上 90% 是早已熟知的系统设计（systems design）。而 loop engineering 位于 harness 之上更高的一层
本文解释一下它到底是什么，哪些质疑合理，哪些地方确实发生了变化。
什么是 loop engineering？
Peter Steinberger 给出的定义最简洁：
"Loop engineering 就是把自己从'去 prompt agent 的人'这个角色中替换掉。设计一个系统，让系统代替你去做这件事。"
Boris Cherny，负责 Anthropic 的 Claude Code，说过几乎一模一样的话："我已经不再 prompt Claude 了。我有一些 loop 在运行，它们去 prompt Claude，并且自己判断该做什么。我的工作是写 loop。"
第一次读到这句话，我们可能想到的是：反应式工作流（reactive workflows）、事件驱动的 pipeline、内部装了更聪明任务的 cron job。
不过他们的区别在于 loop 内部是什么。
传统的 cron job 执行固定的步骤：跑一个 SQL 查询，写入一个文件，发一封邮件。这些步骤是确定性的，在编写时就已经定义好，完全知道它会做什么。
Steinberger 和 Cherny 所说的那种 loop 不一样，它执行的步骤是在运行时由模型决定的。loop 说"梳理昨天的 CI 失败"，模型自己决定什么算是值得处理的失败、如何排优先级、尝试怎样的修复、什么时候停止。这个 loop 的行为由作者从未明确编程过的上下文塑造出来。
质疑合理的地方
以下是可以合理质疑的地方。
术语被过度包装。 每隔三个月就会有一个新的复合名词冠在早已熟悉的模式上：Context engineering、agent harness、agentic workflows、loop engineering。有一部分确实是词汇的真正演化，有一部分是 概念和会议演讲标题的产物。所以要想真正理解这个词底层的概念之前，先不要相信这个词。
成本问题。 一个按计划运行、生成并行子 agent、不断迭代直到达成目标的 loop，会以变化很大的速率消耗 token。对多数团队来说，写一个检查部署状态的简单 Python 脚本，要比花钱让一个模型每 15 分钟去判断一次这件事划算得多。除非问题本身确实需要运行时的动态判断，否则这种能力并不能证明这笔花费合理。
演示案例是精心挑选过的。 用来说明 loop engineering 的那些例子——每日 CI 梳理、commit 简报、从上周的 commit 中找 bug——恰好都是模型的动态判断能发挥价值的场景。这会给人留下一种印象：loop 在所有场景下都比脚本更好。事实并不是这样，因为它们只是在特定情境下更好，即工作需要那种无法预先指定的推理时。
Harness engineering 与 loop engineering 的关系
目前多数解释都略过了这部分。
Harness engineering 关注单个 agent 运行所处的执行环境：上下文管理、工具权限、重试、日志记录、跨调用的状态持久化。它的作用是防止单个 agent 产生幻觉般的工具调用、在第 40 轮对话时忘记自己的目标，或者悄无声息地、高置信度地产出错误结果。搭建过真正的后端系统的人，其实已经了解 harness 所做事情的 80%。
Loop engineering 关注的是随时间推移编排多个 agent 和多次运行，回答的是这样一些问题：谁去发现工作？谁去执行工作？谁去检查工作？明天的运行如何知道今天的运行完成了什么？Loop 是 harness 之上的控制平面（control plane）。
可以这样理解：harness 是单个 agent 生活于其中的东西，loop 决定的是何时启动一个 agent、给它什么、以及如何处理它返回的结果。
两者解决的是不同的问题，并且都需要。
Addy 的博客里，loop 的五个结构性组成部分是：
- Automations（自动化）：按计划或按事件触发、用来发现工作的 prompt。在 Claude Code 中对应
/loop、/goal和 scheduled tasks；在 Codex app 中是 Automations 标签页里的 Triage 收件箱。 - Worktrees（工作树）：为并行 agent 提供隔离。两个 agent 同时写同一个文件，和两个工程师在没有协调的情况下提交同一行代码，是同一种失败模式。
- Skills（技能）：把项目知识写下来一次，放在对话之外，agent 就不用每次运行都从头重新推导约定。另一篇文章专门写过这个，称之为 SKILL.md。
- Connectors（连接器）：Model Context Protocol（MCP）集成，让 loop 能够在真实环境中行动——开 PR、更新工单、在频道里发通知。
- Sub-agents（子 agent）：maker/checker（制作者/检查者）的分工。写代码的 agent 不是给代码打分的那个。
第六个要素是整个结构基础：状态（state）。一个 markdown 文件，一个 Linear 看板，任何存在于对话之外、记录着"尝试过什么、通过了什么、还有什么没解决"的东西。模型在多次运行之间会遗忘，但是仓库不会。
/goal
是最有意思的部分
多数 loop 的机制都足够眼熟，但有一个原语（primitive）没有干净的先例可以类比。
Claude Code 和 Codex 都提供了一个
/goal
命令。给它一个可验证的停止条件——"test/auth 中的所有测试都通过，并且 lint 检查干净"，loop 会持续运行，直到这个条件为真。每一轮结束后，一个单独的、更小的模型会去评估目标是否已经达成，做这项工作的 agent 就不是给自己打分的那个。
把 maker/checker 分工应用到停止条件本身，是真正的新设计领域。这不是 cron job——cron job 是脚本退出时就停止，这个是当一个独立的裁判确认结果符合规范时才停止。
是否值得付出对应的 token 成本，完全取决于问题本身。"CI 是否通过"这种问题，写一个 bash 检查就够了；"这个 PR 按照安全约定是否可以安全合并"这种问题，模型的判断可能值得花钱。
结论
Loop engineering 不是一个根本性的全新范式（paradigm），而是建立在 agent harness 基本组件之上的一种编排模式，被应用于随时间推移进行自主多 agent 工作这个问题上。
真正新的是
/goal
这个原语，以及把 maker/checker 分工应用到停止条件上——这是一个真实的设计贡献，无法干净地映射到此前的反应式工作流模式上。
被过度包装的，是"应该停止 prompt agent、转而设计 loop"这个说法被当成普遍原则来讲。这只是对某一类特定问题正确的做法，对多数人马上会想要拿它去试的场景来说，其实是浪费。
最贴切的类比：不会仅仅因为微服务（microservices）存在，就把每一次函数调用都替换成一个微服务，只在扩展性问题能够证明其复杂性合理时才用。Loop 也是同样的道理。
在问题确实需要的地方构建 loop，要足够了解自己的 harness，这样才能看清什么时候一个更简单的方案才是正确的选择。
从结论到落地生产
Loop engineering 还太新，目前没有经过实战检验的操作手册。多数尝试它的团队，仍在摸索它到底在哪些地方真正有用，哪些地方一个更简单的脚本原本就够了。
从 Forward Deployed Engineer 的视角看：不要一开始就构建 loop。先找出一个反复出现的工作流，其中的决策逻辑在运行时确实模糊不清，是脚本无法预先指定的那种。用 agent 手动跑几次这个工作流，观察它在哪里失败、哪里需要判断力、哪里产出的结果不经过审核就不敢信任。这些观察结果，就是 loop 设计的依据。也要留意 token 消耗，核算相关成本。
每一个新的行业流行词，都会把团队推向"在基础工作做好之前就先去尝试"的方向。结果要么是演示阶段就卡住了，要么更糟——真的进入了生产环境，然后失败了。