agent 工程师带你了解 loop engineering

Loop engineering 最近常被提起，它指的不是某种职位，而是一种工程实践。下面从一个工程师的视角，说说它到底是什么，核心技能在哪儿，以及它有没有真的改变软件工程。

/loop 和 /goal

在 Claude Code 里，跟 loop engineering 直接相关的是两个命令，/loop 和 /goal。

/loop 让一个 prompt 反复跑，触发间隔既可以固定写死，比如每 5 分钟一次，也可以交给模型自己决定，由它根据情况把下次运行安排在一分钟到一小时之后。本质上它就是个定时任务，最适合拿来做监控，比如持续盯着某个部署的状态。

/goal 是给 agent 设一个完成条件，它每跑完一个 turn，会有一个独立的小模型当裁判，根据 agent 这一轮呈现出来的内容判断条件有没有达成，没达成就接着跑，达成了才停下来。

这两个命令可以叠起来用，由 /loop 定时触发，每次触发都去执行一个带完成条件的 /goal。

背景：从一个开源 bash 循环说起

2025 年年中，Geoffrey Huntley 写过一个叫 Ralph 的做法。按他自己的说法，Ralph 不过是个 bash 循环，用 while true 把同一个 prompt 反复喂给 agent，靠一个最大迭代次数兜底，再依赖模型自己不假报完成来往前推进，办法虽然简单，却确实跑得通。

到 2026 年 3 月前后，Claude Code 把这个思路收进了原生命令，也就是 /loop。/goal 稍晚几个月才出现，它在循环之外多加了独立裁判这一层，不再只靠模型自己说一句做完了。等到 2026 年 6 月前后，X 上开始流行一种说法：真正值得花心思的不是怎么 prompt 一个 agent，而是怎么设计它运行的那个循环，loop engineering 这个名字也是 Addy Osmani 在这时提出的。

这条路不只 Claude 在走，Codex 和 Cursor 也在把 agent 自循环做成原生能力。

工程本质：两个已有的工程实践

以一个工程师的眼光去看这两个命令，会发现它们对应的都是早就存在的工程实践。

/goal 对应的是 hook 检查，它在工程上其实是一个 session 级别的 Stop hook，每跑完一轮就校验终止条件，不满足就不放行，这跟契约测试加 CI 门禁是一回事；而它引入的那个独立裁判，相当于在 agent 之外加了一层旁路校验，核心意思是不能拿 agent 的自评当验收依据。/loop 对应的则是定时任务，它的自适应间隔在朴素定时任务的基础上多带了一层退避，会在没有进展时把触发间隔自动拉长。

再往下还有几层护栏同样有出处。终止护栏对应的是限流、超时、熔断和重试预算这一套，而要防止目标在多轮之间漂移，靠的则是幂等加状态持久化，把仓库当成唯一可信的真相源。这些都不是新东西，只是这一次被放进了 agent 的场景里。

核心技能：如何定义完成

loop engineering 真正的核心技能，是定义任务完成。

门槛不在命令本身，真正难的是你能不能把“任务完成”写成一个可以客观验证、又不依赖 agent 自评的终止条件。下面三个例子，终止条件由弱到强。

最弱的情形是让它生成一份报告。如果只说“写一份报告”，它写完就会宣告完成，可这份报告到底好不好根本无从判断，所以你得加一个可检查的约束，比如要求每条关键结论都能溯源到具体出处。中间一档是让它提交一个 PR，这里设了两道关卡，一道是 CI 这种机器自动判定的客观门禁，一道是 reviewer 的人工评审，只有两道都通过，这次任务才算结束。最强的一档是让它完成某个功能并真正部署上线，光把代码写完、甚至合进主干都还不够，得等它在线上真正跑起来、用户能完整走完整个流程，这次任务才算结束。

这三个例子指向同一条原则：终止条件必须是客观可核验的，而且最好连 agent 自己都动不了。因为它在循环里跑，只要终止判据落在它自己的感觉上，它就有动机为了跳出循环而谎报，你真正能依赖的只剩外部那个硬信号，一条机器跑出来的测试结果、一次人工评审的通过，或者线上一个真实请求的成功。

讨论：它有没有改变软件工程

我的判断是，loop engineering 并没有改变软件工程的底层做法。验证、护栏、可观测性、幂等这些一个都没变，前一节其实已经说清了，把 /loop 和 /goal 拆开看，对应的全是早就存在的老办法。

真正变化的有两层。一层是被控对象：过去你面对的是确定性的代码和服务，跑出来什么就是什么，从不骗你，而现在你面对的是一个不确定、还会主动谎报完成的 agent。另一层是工程师的精力分配，随着具体实现越来越多交给 agent 去填，重心也就从亲手写代码挪到了把“完成”和“边界”界定清楚。

由这两层又引出一个更实在的变化。先界定清楚“什么算完成”再去验证，本是一条老生常谈的最佳实践，执行与否一向有弹性，你省掉这一步、靠人盯着，往往也还是能把东西交付出去。可一旦被控对象换成一个会谎报的 agent，这一步就再也省不掉了，因为完成条件只要定得稍弱，整个循环的产出就不可信，连带前面所有迭代也跟着白做。评审的重心也跟着移了，从逐行读代码转向审这个循环本身，看它的边界和验收标准订得对不对。

所以 loop engineering 谈不上发明了新工程，它真正做的，是把“界定清楚什么算完成”这件早就该做、却常被跳过的事，变成了无法再绕开的核心工作。如果你正在用 /loop 或 /goal，值得回头检查一下自己设的那个终止条件，看它在 agent 谎报完成的时候到底拦不拦得住。