Loop 工程 vs Harness 工程：你的 AI Agent 到底是"刹车坏了"还是"没装方向盘"？

一个 AI Agent 在原地无限转圈，另一个 AI Agent 你不敲键盘它就永远不动——它们俩其实是同一个病因。

没人搞清楚自己到底在解决两个完全不同问题中的哪一个。

我认识一个团队，花了三周时间跟第一种问题死磕。他们的编程 Agent 会改一行代码 → 跑崩一个测试 → 修复那个测试 → 又跑崩另一个测试 → 无限循环，永远落不了地。

他们的解决方案是：再加一层重试机制。

结果更糟了。

问题根本不在"循环"本身。在那之前，没有任何东西在检查 Agent 的每一次修改是否安全。他们需要的是一个 Harness（安全笼），而不是另一个 Loop（循环），但他们花了整整三周才看清这个区别。

这种混淆正在大量团队里上演，代价是数周、甚至数月的时间。

两个新概念，一年之内同时炸场

2026 年，但凡聊到生产级 AI Agent，两个词就绕不开：Loop Engineering（循环工程） 和 Harness Engineering（约束工程）。

它们听起来像是一回事，但实际上完全不是。选错了方向，你的 Agent 要么脆弱得像纸糊的，要么迷茫得像没头苍蝇。

先快速捋一下背景，这两个词可不是凭空冒出来的。

• Prompt Engineering（提示工程）：你发给模型的那几句话。
• Context Engineering（上下文工程）：Shopify 的 Tobi Lütke 在 2025 年中定义的概念——为任务提供所有必要的上下文信息，让它"可解"。Andrej Karpathy 把它形容为"一门精妙的艺术和科学，用恰到好处的信息填满上下文窗口"。

然后，Agent 开始不再只是跑几秒钟就完事，而是无人监督地跑好几个小时。于是两个新问题出现了，而 Prompt Engineering 和 Context Engineering 都解决不了：

Harness Engineering（2026 年初进入主流视野）解决第一个问题：Agent 自己跑的时候，怎么保证它安全、可靠？

Loop Engineering（2026 年 6 月一篇爆款文章之后迅速传播）解决第二个问题：Agent 怎么知道什么时候继续、什么时候停下、下一步该干嘛——不用你每次都敲指令？

两者都是正经的工程学科，解决的是截然不同的问题。下面我们来看看，到底差在哪。

图：AI 工程学科的演进路线——从 Prompt 到 Context，再到 Harness 和 Loop

🏗️ Harness Engineering：给 Agent 装上安全带、刹车和气囊

Harness Engineering 是这样一个学科：设计一切包裹在 Agent 周围的东西，让单次运行变得可靠。

包括：它能访问什么工具、什么护栏能阻止它干出危险的事、什么反馈回路能让它发现自己的错误、以及什么可观测性能让人类看到它在干什么。

Agent 本身不是 Harness。Harness 是 Agent 周围的一切，决定它的行为是否可信。

Harness = 模型 + 让它能在真实世界里有用的所有东西

这里有一个让我醍醐灌顶的区分：

在 Prompt 里告诉 Agent "请遵守我们的编码规范"——这叫请求，靠的是模型自己选择遵守。

在 PR 流程里接入一个 Linter，不符合规范就自动拒绝合并——这叫约束，Agent 物理上无法绕过去。

# 概率性方案（靠 Prompt，指望它听话）
system_prompt = "请遵循我们的代码风格指南。"

# 确定性方案（靠 Harness，它根本绕不过去）
def on_pull_request(pr):
    if not linter.passes(pr.diff):
        return reject(pr, reason="代码风格违规")
    if not tests.pass_all(pr):
        return reject(pr, reason="测试未通过")
    return allow_merge(pr)

Spotify 内部的 AI PR 系统已经用这种验证门控的方式合并了超过 1500 个 AI 生成的 Pull Request。Claude Code 和 Claude Agent SDK 内置了权限模型和 Hooks 系统，也是出于同样的原因。Cursor 更是直接把循环检测和规则文件嵌入了 IDE。

这些都不是在"告诉模型要乖"，而是在让"不乖"这件事在结构上就行不通。

🔄 Loop Engineering：让 Agent 自己找活干，干完自己停

Loop Engineering 解决的是另一个问题：设计一个系统，让它决定 Agent 什么时候跑、干什么活、什么时候真的算干完了。

Google 的 Addy Osmani 说得特别直白：

"Loop Engineering 就是——把你这个'负责给 Agent 下指令的人'替换掉。你设计一个系统来代替你干这件事。"

Anthropic 的 Boris Cherny（Claude Code 负责人）也描述了自己的转变：

"我现在不再给 Claude 发 Prompt 了，我写的是 Loop。我的工作就是写 Loop。"

一个 Loop 不需要人类保姆，只需要三样东西：

1. 找到活干的方法
2. 一个能告诉它什么时候停的完成条件
3. 一个能在两次运行之间保存状态的地方，不至于每次都从零开始

while not goal_met(state):
    task = find_next_task(backlog, state)
    result = agent.run(task)
    state = update_state(state, result)
    if attempts_exceeded(state) or blocked(result):
        notify_human(state)
        break

这就是一个每天晚上自动扫描 GitHub Issues 的 Agent 的核心逻辑。放大规模，就是那些能在几十个文件之间持续工作数小时、却不需要任何人敲下一行指令的 Agent 背后在跑的东西。

图：Loop 工程的核心循环——找活 → 执行 → 验证 → 更新状态 → 决定下一步

🚗 一句话讲清楚：把它想象成一辆车

• 引擎 = AI 模型。光有引擎，它能产生动力，但没法安全上路。
• Harness = 刹车、安全带、气囊、方向盘、传感器、仪表盘、ABS。这些东西不会让引擎更"强大"，但能保证每一次旅程都安全、可控、可观测。
• Loop = 导航系统 + 驾驶员。它决定下一步去哪、要不要继续开、要不要换路线、要不要加油、要不要结束行程。

一个回答的是："这趟旅程能安全完成吗？"

另一个回答的是："下一站该去哪？"

一辆 Harness 做得极好但没有 Loop 的车：完美地安全……停在停车场里。

一辆引擎强劲、导航野心勃勃但刹车失灵的车：灾难倒计时。

图：用汽车来理解 AI Agent 架构——引擎是模型，Harness 是安全系统，Loop 是驾驶员和导航

🧩 最干净的区分方式

AI 研究者 Cobus Greyling 把这件事讲得比大多数正式定义都清楚：

Harness 装备的是单次 Agent 运行，而 Loop 是那个不断去戳 Agent 的东西——按计划启动、生成子任务、给自己喂下一个任务。

• Loop Engineering 关心的是目标。
• Harness Engineering 关心的是目标被解决得有多可靠、多安全。

一个关心的是"单次运行是否安全可靠"。另一个关心的是"系统是否持续运行，以及朝什么方向运行"。

顺便说一句：不是所有人都同意它们怎么分层。

Osmani 把 Harness Engineering 放在 Loop Engineering 下面一层，形成一个严格的递进关系。而 MindStudio 的实践者们则把它们当作两个并行的关注点——恰好同时重要，而非严格的层级。两种说法都有道理。比"组织架构图"更重要的是：它们解决的是不同的故障模式。

💥 搞混了会怎样？

一个 Loop 很强但 Harness 稀烂 的 Agent：它停不下来，不断尝试，偶尔干出你绝对不想让它干的事——因为没有任何东西拦着它。

一个 Harness 很强但没有 Loop 的 Agent：它脆弱得悄无声息。每次单独运行可能都安全、有防护，但一旦任务需要超过一轮，就必须有人手动踢每一脚下一步。没有任何东西决定接下来该发生什么。

LangChain 的 Deep Agents 团队发现了一个证据，证明 Harness 一侧有多重要：他们在 Terminal-Bench 2.0 基准测试上获得了可测量的提升——只改了 Harness，模型本身没换。

这个规律反复出现，足以成为一条经验法则：

一个好 Harness 配一个普通模型，往往比同一个 Harness 配一个更好的模型更强——对于大多数 Agent 任务来说。

模型只能看到 Harness 为它组装好的东西，也只能拿到 Harness 允许它拿到的重试次数。

图：Harness Engineering vs Loop Engineering 核心区别一览

🧭 一个你现在就能用的决策框架

按顺序问自己这几个问题：

1️⃣ 你的 Agent 在单次任务中干了不安全或不可靠的事？

👉 这是 Harness 问题。 加护栏、权限检查、确定性验证——在这些搞定之前，别碰任何调度或重试相关的东西。

2️⃣ 你的 Agent 单个任务完成得挺好，但每次都需要人来启动？

👉 这是 Loop 问题。 你不需要更多安全护栏，你需要一个能自己找活干、自己决定什么时候完成的系统。

3️⃣ 你的 Agent 既不安全又没人监督？

👉 先修 Harness。 一个没有护栏的无人监督 Agent，是你能犯的最贵的那种错误——而且一个好的 Loop 只会让一个破 Harness 运行得更频繁。

4️⃣ 感觉一切都能跑，但没你在场就什么都交不出去？

👉 你的 Harness 大概还行。缺的是一个能把你从"启动按钮"位置上移除的 Loop。

图：15 分钟诊断决策树——按顺序回答，找出你的 Agent 缺的是什么

🎯 结语

这两个不是互相竞争的框架，抢的不是同一份工作。

它们是两个不同问题的答案——这两个问题直到 Agent 开始跑得足够久、足够独立之后，才同时变得紧迫。

Harness Engineering 问的是：我能信任这一次运行中发生的事吗？

Loop Engineering 问的是：我能信任这个系统自己决定下一步——不用我在场吗？

大多数在生产环境中感觉"不可靠"的 Agent，缺的只是其中一个，不是两个都缺。找出缺哪个，只需要十五分钟诊断。把它补回来，才是真正的工程。