什么是 Loop Engineering？它和 Harness Engineering 有什么不同？-拓冰建站

AI 行业热衷于给旧模式重新命名。但这一次，确实发生了一些真正的变化。一位 Forward Deployed Engineer 视角：企业在开始构建 loops 之前，实际需要什么。

你最近可能读到过类似这样的话：

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”- Peter Steinberger

你的第一反应大概是：等等，那我现在到底该做什么？

不是“这是新东西吗？”也不是“这不是已经存在了吗？”真正让人感到失去方向的是这句话暗含的意思：你一直在做的事——编写 prompts、迭代 prompts、逐渐变得擅长 prompts——已经不再是工作本身。现在的工作上升到了更高一层。

这个转变值得认真对待。因为如果你把它当作炒作而不屑一顾，你会错过其中真实存在的部分。而如果你不加批判地接受它，你会为了那些一个 bash script 在 40 毫秒内就能处理的问题，烧掉大量 tokens。

过去几个月里，我一直以 Forward Deployed Engineer 的身份在企业环境中部署 agents。下面是我对正在发生的事情的真实看法。

在我之前的文章中，我认为 agent harness engineering 有 90% 都是我们一直熟悉的 systems design，只是应用到了一个新的底层载体上。剩下的 10% 确实是新东西，因为你现在是在封装一个 non-deterministic core。这个框架依然成立。但 loop engineering 位于 harness 之上一层，在你把它当作营销词汇而否定之前，这个差异值得仔细拆解。

让我解释一下它到底是什么，哪些质疑是合理的，以及哪些地方确实发生了真实变化。

什么是 loop engineering？

这里有一个最清晰的定义，来自 Peter Steinberger：

“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

Anthropic 负责 Claude Code 的 Boris Cherny 也说过几乎相同的话：“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

当我第一次读到这句话时，我的思路大概和你一样：reactive workflows。Event-driven pipelines。里面放了更聪明任务的 cron jobs。这个形态很熟悉。

差异在于 loop 内部是什么。

传统的 cron job 执行固定步骤。它运行一个 SQL query，写入一个文件，发送一封 email。这些步骤是 deterministic 的，并且在编写时就已经定义好。你完全知道它会做什么。

而 Steinberger 和 Cherny 所描述意义上的 loop，执行的是由模型在 runtime 决定的步骤。loop 说“triage yesterday’s CI failures”，然后模型决定哪些 failure 值得处理、如何排序优先级、尝试什么修复，以及什么时候停止。loop 的行为受到作者从未显式编程进去的 context 影响。

这是一个真实差异。不是革命性的。但是真实存在。

哪些质疑是正确的

下面这些质疑是合理的。

术语被夸大了。每隔三个月就会出现一个新的复合名词，用来描述你已经知道的某种模式。Context engineering、agent harness、agentic workflows、loop engineering。其中一些确实是词汇的自然演进。另一些则是 SEO 和会议演讲标题。合理的默认态度是：在你理解这个词背后的概念之前，先不要信任这个词。

成本问题很严肃。一个按计划运行、生成并行 sub-agents、并持续迭代直到达成目标的 loop，会以高度不稳定的速率消耗 tokens，具体取决于你如何设计它。对大多数团队来说，写一个简单的 Python script 来检查 deployment status，要比每 15 分钟付费让一个 frontier model 思考这件事更好。除非问题确实需要在 runtime 进行动态判断，否则这种能力并不能证明其开销是合理的。

演示案例经过精心挑选。用来说明 loop engineering 的例子——daily CI triage、commit briefings、从上周 commits 中寻找 bug——恰好都是模型的动态判断能力能带来价值的场景。它给人的印象是 loops 普遍优于 scripts。但事实并非如此。只有当工作需要无法预先指定的 reasoning 时，loops 才在特定场景下更好。

harness engineering 和 loop engineering 实际上如何关联

这是大多数解释都会一笔带过的部分。

Harness engineering 关注的是单个 agent 运行其中的执行环境。它处理 context management、tool permissions、retries、logging、跨调用的 state persistence。harness 的作用是防止单个 agent 幻觉出 tool call、在 40 轮对话后忘记自己的目标，或者以高度自信的方式静默地产生错误输出。如果你构建过真实的 backend systems，那么你已经理解了 harness 所做事情的 80%。

Loop engineering 关注的是随着时间推移对多个 agents 和多次 runs 进行 orchestration。它回答这样的问题：谁来发现工作？谁来完成工作？谁来检查工作？明天的 run 如何知道今天的 run 完成了什么？loop 是位于 harness 之上的 control plane。

可以这样理解。harness 是单个 agent 生存其中的环境。loop 决定何时启动一个 agent、给它什么任务，以及如何处理它返回的结果。

你两者都需要，而且它们解决的是不同问题。

来自 Addy 的博客中，loop 的五个结构性组成部分是：

Automations：按计划或由事件触发的 prompts，用来暴露待处理工作。在 Claude Code 中，这就是/loop、/goal和 scheduled tasks。在 Codex app 中，则是带有 Triage inbox 的 Automations tab。
Worktrees：为并行 agents 提供隔离。两个 agents 同时写同一个文件，和两个工程师在没有协调的情况下提交同一批代码行，是同一种 failure mode。
Skills：把项目知识一次性写下来，放在 conversation 之外，这样 agent 不必每次 run 都从头重新推导你的约定。我曾单独写过这部分，称之为 SKILL.md。
Connectors：Model Context Protocol (MCP) integrations，使 loop 能够在你的真实环境中行动，比如打开 PRs、更新 tickets、ping channels。
Sub-agents：maker/checker 分离。写代码的 agent 不应该是给代码打分的那个 agent。

第六个东西，也是整个结构的脊梁，是 state。一个 markdown 文件。一个 Linear board。任何位于 conversation 之外、能够保存已尝试内容、已通过内容、仍未解决内容的东西。模型会在 runs 之间遗忘。repo 不会。

`/goal`primitive 是最有趣的部分

大多数 loop 机制都足够熟悉。但有一个 primitive 没有清晰的 prior-art 类比，值得关注。

Claude Code 和 Codex 都暴露了一个/goalcommand。你给它一个可验证的停止条件：“all tests in test/auth pass and lint is clean。”loop 会持续运行，直到这个条件为真。每一轮之后，一个独立的更小模型会评估 goal 是否已经达成，因此执行工作的 agent 并不是给工作评分的 agent。

把这种 maker/checker 分离应用到停止条件本身，确实是新的设计领域。它不是 cron job。cron job 在 script 退出时停止。这个机制则是在一个独立 judge 确认结果满足 spec 时停止。

这是否值得 token 成本，完全取决于问题。对于“CI 是否通过”，写一个 bash check 就行。对于“考虑到我们的 security conventions，这个 PR 是否可以安全 merge”，模型判断可能值得付费。

诚实的结论

Loop engineering 并不是一个根本性的新范式。它是构建在 agent harness primitives 之上的一种 orchestration pattern，用于解决随时间推进的 autonomous multi-agent work 问题。

新的部分是/goalprimitive，以及针对停止条件的 maker/checker 分离。这是真正的设计贡献，无法干净地映射到以往的 reactive workflow patterns。

被夸大的是这样一种表述：你应该停止 prompting agents，转而开始设计 loops，并把它当作通用原则。对某一类特定问题来说，这是正确方向。但对于人们会立刻尝试套用它的大多数事情来说，这是浪费。

最贴切的类比是：你不会仅仅因为 microservices 存在，就把每个 function call 都替换成一个 microservice。只有当 scaling problem 足以证明这种复杂性合理时，你才会使用它们。loops 也是一样。

在问题需要 loop 的地方构建 loop。也要足够了解你的 harness，才能看出什么时候更简单的方案才是正确选择。

从结论走向生产

Loop engineering 还足够新，目前还没有经过实战检验的 playbooks。大多数尝试它的团队，仍在弄清楚它到底在哪些地方有帮助，哪些地方其实用更简单的 script 就可以。

从 Forward Deployed Engineer 的角度，诚实的建议是：不要从 loop 开始。先识别一个反复出现的 workflow，其中 decision logic 在 runtime 确实是模糊的，是 script 无法预先指定的。先用 agent 手动运行几次。观察它在哪里失败、哪里需要判断、哪里会产出你不经过 review 就无法信任的东西。这些观察就是你的 loop design。还要留意 token consumption，并检查与之相关的 cost。

每一个新的行业 buzzword 都会把团队推向在基础尚未准备好之前就去尝试它。demo 会卡住，或者更糟的是，它进入 production 后失败。

这里给大家精心整理了一份全面的AI大模型学习资源，包括：AI大模型全套学习路线图（从入门到实战）、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费分享！

👇👇扫码免费领取全部内容👇👇