一层层都是 loop：loop engineering 和 harness engineering 到底替代了什么

最后更新于 2026-06-10

有个 loop，你已经跑了两年，却一直没给它起名字。Agent 做完一段活，你看一眼它输出了什么， 判断行不行、接下来做什么，然后敲下一条指令；Agent 再做下一段。这个「看结果、做判断、再 prompt」的过程， 本身就是一个 loop，而跑这个 loop 的人，是你。

想清楚这一点，2026 年到处都在说的两个词就不再像是互相打架的概念了。harness engineering（脚手架工程）和 loop engineering（循环工程）其实各管一摊：一个让 Agent 自己那个 loop 跑得更久，另一个，要替掉的是你这个 loop。

三层 loop，一个套一个

往上数，一共三层 loop，层层相套，外面那个包着里面那个。

• 最里面是 ReAct loop。一次运行之内，Agent 先想、再调工具、看结果、接着再想。 这是 Agent 自己的循环，一个任务里它自己一轮一轮地转。
• 外面包着 harness。它本身不是你来跑的循环， 而是决定「里面那个 loop 在卡住之前能跑多远」的那套东西：工具、状态、上下文管理、hooks、出错恢复。
• 再外面是你。一次运行结束、或者卡住了，事情就回到人手里：你看结果、定下一个目标、 再发起一轮。这就是那个一直没被起名字的 loop。

先记住这张图，因为关键问题就一个：每个词到底想动哪一层 loop。

harness engineering 动的是里层

光有模型还不算 Agent。得拿一层脚手架把它裹起来，它才成为 Agent，这层脚手架就是 harness。 Viv Trivedy 有一句话概括了它的形状：Agent = 模型 + Harness；你要不是那个模型，那你就是 harness。所谓 harness engineering， 就是把这层脚手架当成一件正经的工程产物来打磨：Agent 每犯一次错，就去改环境，让这个错再也犯不出来， 然后接着往下拧。

说白了，harness 就是「除了模型之外」的所有东西：

• 一份系统 prompt 加规则手册（比如 AGENTS.md 或 CLAUDE.md）， 每一轮都塞进去。
• 工具、skills 和 connectors，外加那些告诉模型「什么时候该用哪个」的描述。
• 上下文策略：压缩、把大段工具输出转存出去、用到了才把指令亮出来，都是为了对抗 context rot（上下文越长越糊）。
• 一个沙箱，让代码能安全地跑、让 Agent 能自己验证结果。
• hooks，用来确定性地兜底规则：拦掉破坏性命令、改完代码自动跑测试、推送前要审批。
• 可观测性：日志、调用链、token 成本和延迟。

有个很根本的现象反复出现：同一个模型，换个更好的 harness，表现能天差地别。 有团队光是换 harness，就把一个编码 Agent 从榜单中游做到了前五。模型从来都不是唯一的变量。

但要看清它到底帮你换来了什么。harness 做得好，单次运行就能跑得更远：步子更多、过程更连贯、翻车更少， 然后才需要把控制权交回给你。它拉长的是「一口气能推多远、推得多稳」。 Anthropic 工程团队有句话说得很到位：harness 里的每个组件，背后都藏着一个「模型自己搞不定什么」的假设； 所以模型越强，脚手架并不会消失，只是挪到新的天花板那边去了。

但 harness engineering 有件事做不到：它没法把你从最外层那个 loop 里摘出去。 脚手架再好，一轮运行总会结束，总得有个东西来看结果、然后说一句「行，接着干这个」。 过去两年，这个东西一直是个人。

loop engineering 冲着外层来

loop engineering 这个说法是 Addy Osmani 带火的，Peter Steinberger 和 Claude Code 的 Boris Cherny 也是这个意思。 它要自动化的，正是你一直手动在跑的那个 loop。不再是每做完一段就去看、去 prompt， 而是把目标一次性定下来，再搭一套系统，让它推着 Agent 一直干到目标真正达成。

而且它不只是「帮你自动敲下一句 prompt」这么简单。你那个 loop 从来就不只是「定下一步」， 它还默默干着另一件事：发现「有活要干」。所以一个真正的外层 loop，连发现和分流也得接过去： 一个定时的、或者由事件触发的开关，把该做的事捞出来，loop 自己派下去，只有它搞不定的才回到你面前。 调度、派活、一轮一轮盯着，这三件事你一下子都不用做了。

把一个能用的 loop 拆开，里头是五个零件加一块记忆：

• 自动化：一个定时的、或由事件触发的开关，负责把活捞出来。这是心跳。
• 隔离：worktree 或各自独立的上下文，让并行跑的 Agent 不会互相踩到。
• skills：把项目知识写下来一次，省得 loop 每个循环都从头重推一遍你的规矩。
• connectors：接上活儿真正要碰的那些工具和数据。
• 子 Agent：也就是「干活的」和「检查的」分开，这点重要到下面专门有一节讲。
• 落盘的记忆：一个文件或一块看板，能跨多次运行留下来，因为模型两次之间什么都不记得。

这些已经不是纸上谈兵了。Claude Code 提供了 /loop 和 /goal， OpenAI Codex 提供了 Automations 和它自己的 /goal 命令。这些原语如今就长在你天天用的工具里， 这也是这个词能火起来的一部分原因。

真正变的是这里。重心从「这一条 prompt 写得好不好」， 挪到了「那套替你写 prompt、又替你判断结果的系统，搭得好不好」。 外层 loop 设计得好，能把一个好工程师放大；设计得糟，也会用同样的速度把一个糟糕的决定放大， 而且盯着它的人还更少。

陷阱：人这个 loop 同时也在做检查

幼稚版本的 loop engineering 就栽在这儿。要是你只是把人撤掉，让系统自己朝着目标反复 prompt， 你撤掉的就不只是那个说「接着做这个」的人，连那个会喊「等等，上一步错了」的人也一起没了。 最外层这个 loop，一直是一顶帽子下面塞着两份活：定下一步，和验上一步。

所以真能用的 loop，必须把验证收进自己肚子里。常见做法是把「干活的」和「检查的」拆开（maker-checker）： 另起一个验证 Agent，专门给中间结果打分、判断目标到没到。注意，它绝不能是那个干活的 Agent， 因为模型给自己的活打分，每次都往高了打。有了这个验证者，「loop 说它干完了」这句话才算数。 这跟把 Agent 评估做扎实是同一个道理： 生成和判断必须分开，不然你信的不过是一个理直气壮的猜测。

就算有了验证者，人也没法彻底离开检查这摊事。你只是从「一轮一轮地盯」里退出来，挪到了两个位置：

• 动手之前，先把 loop 设计好。目标是什么、验证者拿什么标准判定「算干完了」、 多久跑一次、哪些不可逆的操作要卡一道审批。把「怎样算完成」白纸黑字写下来，最能挡住跑偏。
• 跑完之后，只看要紧的。不是每一轮都看，而是那些影响大、不好回头的结果。 「干完了」只是 loop 单方面的说法，要不要真的合进去，还是你说了算。

所以那句实在话不是「人只看最后状态就行」，而更接近这样： loop engineering 把你从「每轮都得开车」里拽出来，挪去设计 loop、把关重要产出； 而你过去一笔一笔手动做的检查，交给验证 Agent 接着做。

放到手机上长什么样：Memex

这套说法对我们来说不只是几个词。早在这两个词火起来之前，Memex 就已经在手机上跑着外层 loop 的一个版本了： 一个本地优先、没有后端的应用，一套多 Agent 系统，把你的记录整理成结构化卡片、抽取知识、找出洞察， 全程都在手机上完成。这里的 harness 就是 dart_agent_core， 我们开源的 Dart 框架，实现了完整的 ReAct loop，外加工具调用、用 FileStateStorage 落盘的会话、 上下文压缩和出错恢复。有意思的是那层约束：没有服务器、没有 shell、没有 CI。 外层 loop 得扛得住应用被杀掉、手机重启，这正是为什么「状态落盘」和「事件触发」在这里是顶梁柱， 而不是可有可无的点缀。（这些在 Memex 背后的工程那篇里讲得更细。）

这个外层 loop 是靠事件转的，不是靠聊天。你不会看完一张卡片再去告诉系统下一步干嘛， 而是一条记录事件经过全局事件总线，直接交给订阅了它的那个 Agent， 触发条件、工作目录、技能集都写在磁盘上的 CustomAgentConfig 里。 Super Agent 在上面调度一组专门的 worker（Card、PKM、Insight、Comment、Memory）， 通过 delegate_task 把活派下去，每个都在各自隔离的状态里跑。没有人去敲下一句 prompt。

而「算干完了」的判定也是写进代码里的，不是听它一面之词。Card Agent 跑完时，Memex 会跑一遍 CardRunCompletionEvidence：磁盘上卡片在不在、fact_id 对不对、 状态是不是 completed、有没有标题和 UI 配置，运行记录里有没有一次成功的 save_timeline_card 调用。全满足才算完成；缺一样，就把具体缺的东西塞回去让它再跑， 直到跑满重试上限。再加上碰到破坏性操作能先停下来的 AgentController hooks， 和专抓重复调用的循环检测器，这就是前面说的验证者和完成判定，实打实地跑在一部手机上。

真正有意思的是那层约束。讲 loop engineering 的文章，大多默认你有服务器、有 shell、有 CI。 Memex 一样都没有。它的外层 loop 得扛得住应用被系统杀掉、手机重启、网络断掉。 这恰恰说明，为什么「状态落盘」和「事件触发」在这里不是可有可无的点缀， 而是外层 loop 在手机上能跑起来的唯一办法。

风险不会消失，只是往上挪了一层

那些本来藏在「人这个 loop」里的麻烦，并不会因为你把它自动化就凭空消失。它们只是换了地方，其中几个还更扎手了。

• 验证还是最难的那块。你只是把它从自己的眼睛，挪给了一个验证 Agent， 再加上你对重要结果的复核。验证者一旦不靠谱， 这个 loop 会比当年那个人肉 loop 更快、更理直气壮地把错活交出去。
• 「看不懂」的债越欠越多。loop 越快地产出你没亲手写的改动， 「实际存在的东西」和「你真正搞懂的东西」之间，差距就拉得越大。
• 成本是跟着 loop 走的，不是跟着任务走。一个定时跑、每轮还带验证者、 底下挂着好几个子 Agent 的 loop，不管有没有捞到活都在烧 token。先慢慢跑，盯着账单， 等它产出的东西你真的愿意留下，再把频率往上加。

所以结论不是「把人肉 loop 自动化，然后甩手走人」，而是这活儿换了个形状。 harness engineering 让一次运行靠得住；loop engineering 让一次靠得住的运行， 在没有你开车的情况下不停地重复。这两件事划不划算，就看两点： 你过去一笔一笔手动做的验证，有没有原样搬进 loop 里； 以及你还是不是那个设计这套系统的工程师，而不是只负责按下「开始」的人。

FAQ：loop、harness，以及到底什么被替代了