我第一次看到 Loop Engineering，第一反应：AI 圈又他妈在炒冷饭。
human-in-the-loop 两年前就在讲，LangChain 和 LangGraph 也早有 agent loop、状态机、失败重试、人工审批。
后来看到 Addy Osmani（小龙虾作者）对这个词的拆解才发现：重点不在 loop 这个词，而在工作方式变了，人不再逐轮提示 Agent，人开始设计“提示 Agent 的系统”。

一、为什么第一眼像冷饭

AI 界确实很会造概念。Prompt Engineering、Context Engineering、Harness Engineering，一个接一个冒出来。Harness 这个词刚热起来，现在又来了 Loop Engineering，听上去很像把 engineering 前面换一个词，再造一个新赛道。
而且 loop 本来就不新。human-in-the-loop 早就在讲：AI 做完一轮，人进来判断结果，给反馈，决定要不要继续。LangChain、LangGraph 也一直在讲 loop：Agent 调工具，拿到 observation，再决定下一步；graph 从 A 节点走到 B 节点，失败了回到前面，条件满足才往后走，中间还能加人工审批节点。
Loop Engineering 完全称不上一个凭空冒出来的新发明。控制论里的“目标、执行、反馈、修正”比这些词都早。这次值得看的，是它把 loop 放到了哪一层。

二、这次到底讲的是什么

Loop Engineering 要做的事很直白：把“亲自提示 Agent 的那个人”换掉，改成设计一个代替你提示 Agent 的系统。
这句话把人的位置换掉了。过去你用 coding agent，是你写一句 prompt，它回一段代码；你看结果，指出问题；它再改；你跑测试；测试挂了，你把日志贴回去；它再修。Agent 像一个工具，人一直握着它。
Loop Engineering 讲的是让一个系统去发现任务、布置任务、检查结果、记录状态，并决定下一步。你不再是每一轮 prompt 的作者，你变成那套 prompt 生产系统的设计者。
差别在这一层。LangGraph 里的 loop，处理的是一个 workflow 里面怎么分支、怎么重试、怎么等人审批。human-in-the-loop 处理的是人什么时候进来做判断。Loop Engineering 问的是更外层的问题：谁来发现今天该处理什么，谁来启动 Agent，谁来分配 worktree，谁来验证结果，谁来写状态文件，第二天谁接着跑。
以前 loop 藏在 Agent 的工作流里；现在它被拿到 Agent 外面，变成一套会自己转下去的生产制度。

三、为什么会从 Prompt 走到 Loop

这几年 AI 工程的概念一直往外推。模型每强一层，瓶颈就往外移一层。Prompt 解决怎么问，Context 解决给它看什么，Harness 解决它在哪里干活，Loop 解决这套系统怎样自己转起来。
最早瓶颈在“怎么说”。模型像一个聪明但不稳定的实习生，同一个需求，换一种说法，结果差很多。于是大家研究 Prompt Engineering，盯的是这一轮怎么问得更好。
后来模型会写代码、会查文件、会连续做一点任务，瓶颈就变成“给它看什么”。提示词写得再好，它没看见仓库、不知道规范、不知道上次为什么不能这么改，它还是会猜。于是 Context Engineering 出现了：哪些代码进上下文，哪些文档常驻，哪些历史记录只能临时搜索，哪些项目约束要写进 AGENTS.md 或 CLAUDE.md。
再往后，模型能干更长的活，问题又变了。它要跑测试、看日志、开浏览器、查 issue、改文件、开 PR、接监控，还要被权限和审计约束住。于是 Harness Engineering 出现了。Harness 是围绕 Agent 搭出来的执行环境：上下文、工具、权限、评估器、记忆、日志、trace、回滚、审批，把这些组织起来，让 AI 的产出能被团队信任。
走到 Harness 以后，新的瓶颈露出来了：模型有了，材料有了，执行环境也有了，但整条链路还需要一个人手动驱动。你想到该检查 CI 了，敲一句 prompt；测试挂了，你贴日志；它没开 PR，你再提醒它。工具越来越强，人却变成流程里的手动触发器。
Loop Engineering 卡在这个位置：把“人每一轮按回车”从流程里拿出去，让系统自己按节奏跑。

四、一个真实 Loop 怎么跑

想象一个项目每天早上都会冒出一批新信号：昨天的 CI 失败、open issues、最近合进去的 commit、监控里的错误日志。
过去的做法是工程师打开一堆页面，扫一遍，挑几个最值得处理的，再去问 AI：“帮我看看这个失败是什么原因。”AI 改一轮，你跑测试。测试挂了，你贴日志。它再修。
Loop 的做法会换成另一种形状。每天早上，Automation 自动触发，调用 triage skill 读取 CI、issue、recent commits，把值得处理的问题写进状态文件或 Linear 看板。对值得修的问题，系统开一个隔离的 git worktree，让 sub-agent 进去读项目 skills、理解代码、起草修复。另一个 sub-agent 再审查它有没有符合规范、有没有补测试、有没有回归风险。
测试失败，失败信息送回实现 Agent。测试通过，connector 开 PR、关联 ticket、发摘要。最后状态文件记录这一轮发生了什么，下一轮从哪里继续。
变化很简单：你没有在每一步写 prompt。你设计了一次循环。 然后循环自己去发现任务、分配任务、检查结果、写下状态，再决定下一步。
普通自动化脚本处理确定流程：输入确定，步骤确定，输出大致确定。Loop 面对开放任务，需要根据上下文、工具反馈和验证结果继续调整。它更像一个带闸门、带反馈、带记忆的工程控制系统。

五、一个 Loop 需要哪些部件

这套说法把 Loop 拆成五个部件，再加一个外部记忆。这个拆法有用，因为它能把“循环”这个词从口号拉回工程。
Automation 是心跳。 没有自动触发，loop 只是你手动执行了一次任务。它可以每天扫 CI，每小时看 PR 状态，每次合并后做架构检查。这里必须写清楚停止条件，比如“auth 目录下所有测试通过，lint 干净，PR 描述已更新”。没有停止条件的循环，就是一台按 token 烧钱的机器。
Worktree 解决并行冲突。 一个 Agent 重构登录模块，另一个 Agent 也在修同一块边界条件，如果共用目录，很快就会互相覆盖。git worktree 给每个 Agent 一个独立 checkout，历史共享，工作目录隔离。
Skills 解决项目知识冷启动。 怎么跑测试，哪些目录别碰，上次事故留下了什么约束，这些东西不能每次都靠人重新解释。没有 Skills，Loop 每一轮都要重新理解项目；有了 Skills，项目知识才会在循环里积累。
Connectors 让 Loop 进入真实工具链。 真实开发在 issue tracker、PR、CI、数据库、监控、Slack、Linear 里发生。一个普通 Agent 会告诉你“可以这么修”，一个完整 Loop 会自己开 PR、更新工单、等 CI 变绿后通知频道。
Sub-agents 负责分工，尤其是把写的人和查的人分开。 写代码的模型给自己的作业打分，天然会偏向相信自己的方案。让一个干净上下文里的 reviewer agent 来挑刺，效果会稳定得多。/goal 类设计也是这个思路：干活的 agent 每轮推进，另一个独立模型判断停止条件是否满足。
Memory 是命根子。 模型会忘，仓库不会。长任务跨天、跨会话、跨模型版本，状态必须放在对话之外。它可以是 markdown 文件、Linear board、progress.md，也可以是 git log。它记录试过什么、通过什么、失败什么、下一轮从哪里继续。
Ralph Loop 这个案例把记忆说得很清楚。Initializer Agent 只在项目开始时跑一次，负责搭环境、拆任务、写第一份 progress.md、做首次 commit；Coding Agent 每个新窗口都先读 git log 和 progress.md，从未完成列表里挑下一项，做完验证、提交，再更新进度。对人来说这只是“写进度文档”，对 Agent 来说这是跨上下文的存档点。

六、为什么现在才值得讲

一年前你想搭一个 Loop，大概率要写一堆 bash，自己维护状态、审批和工具连接。它能跑，但很脆，而且只有你自己懂。
现在 Codex 和 Claude Code 这类产品已经把大部分部件内置了：Automations 或 /loop 做触发，worktree 做隔离，Skills 沉淀项目知识，MCP connectors 接工具，sub-agents 做分工，外部文件或看板做记忆。
它现在被单独拿出来讲，原因也在这里：过去 loop 是框架作者和少数工程团队才会关心的底层机制。现在这些部件被产品化以后，普通工程师也开始面对同一个问题：我到底要设计什么循环？
工具争论的重要性会下降。该积累的是 loop 的设计图纸：哪些任务值得自动发现，哪些动作必须人工确认，哪个验证信号可信，哪些状态要写入长期记忆，哪个 sub-agent 值得花 token 买第二意见。

七、几个案例说明它解决什么问题

ProgramBench 的结果很刺眼：让一线模型从零重建真实开源项目，不联网，只看最终行为，完成率全是 0%。这并不说明模型不会写代码。它会写函数，会补模块，会产出大量看起来像样的代码。但真实工程有结构、状态、依赖、测试、架构边界和长期维护。裸模型在这里很容易把所有东西塞进一个单体文件，最后通不过行为验证。
LangChain 的实验刚好从另一边说明问题。同一个模型权重不变，只优化模型周围的工程结构，Terminal-Bench 2.0 从 52.8 分涨到 66.5 分，排名从 Top 30 开外冲进 Top 5。模型没有变，变的是它工作的环境、反馈和约束。
OpenAI Codex 团队那个“三个人、五个月、约一百万行代码、约 1500 个 PR”的案例，也不能理解成三个人突然变成了超人。他们做的是把开发环境改造成 Codex 可读、可操作、可验证：worktree 自动起应用实例，日志、指标、trace 暴露给 AI 查询，架构约束写进 custom linter，后台任务定期扫描技术债并开小 PR。
Vercel 的 text-to-SQL 案例更反直觉。他们一开始给 Agent 配了很多专用工具，成功率大约 80%。后来删掉 80% 的专用工具，只保留 grep、cat、find、ls 这类基础工具，让模型自己读 schema 文件再写 SQL，成功率到 100%，速度快 3.5 倍，token 省 37%。Loop 和 Harness 都不能做成堆工具比赛。工具越多，模型每一步的选择空间越大，选错路径的概率也会变大。
ASR 那个弱模型案例更接近 Loop 要处理的问题。作者没有 Claude，也没有 GPT 配额，只有 GLM-4.7-FP8。他没有赌模型一次变聪明，直接做了一个 AI Software Runtime：Builder 生成代码，Tester 跑测试，Analyzer 对照 DESIGN.md 做语义裁决，Controller 根据反馈决定继续修、回滚还是停止。裸用 opencode CLI，通过率 28.6%；longdoc 方案 12.3%；加上 ASR 的收敛运行时以后，10 轮收敛到 96.5%。
ASR 最硬的一层是闸门。它有 pytest 全部通过的硬约束，有 Analyzer 检查实现和设计是否一致，有 3 轮都通过的收敛 streak，有改坏就自动回滚的防退化闸门，还有 max iterations 防止无限烧 token。它还用事件总线把失败注回系统，让 Builder 收到精确修复指令后再生成 patch、重新测试。
Loop 和“让 AI 多跑几次”的边界在这里。多跑几次只是重复。Loop 要知道目标差距在哪里，反馈从哪里来，怎么判断变好还是变坏，什么时候继续，什么时候停，什么时候回滚。

八、最后要防的是人的位置错了

Loop Engineering 这个词有用，是因为它把人的位置说清楚了。
在 Prompt 阶段，人是提问者。在 Context 阶段，人是资料整理者。在 Harness 阶段，人是环境和边界的设计者。到了 Loop 阶段，人开始变成循环的设计者、闸门的制定者、异常的处理者。
表面上看，人被移出了流程；落到工程里，要求反而更高。第一笔账是 token。Automation、长上下文、sub-agents、反复验证都会放大消耗。一个没有触发条件、停止条件和优先级的 Loop，很容易在低价值任务上烧资源。
第二笔账是无人值守错误。Loop 可以在你睡觉时干活，也可以在你睡觉时犯错。sub-agent review 能提高可信度，但 review 结论仍然只是一个信号。
第三笔账是理解债。AI 写得越快，仓库里实际存在的代码和你脑子里理解的代码之间，距离就越容易拉大。代码可能能跑，但你不知道它为什么这么设计，也不知道边界在哪里。
第四笔账是认知投降。当 Loop 太好用，人很容易进入一种舒服状态：它给什么，我收什么。Loop 本身分不出你是在加速理解，还是在逃避理解。这个区别只能由你自己分。
回到开头那个问题：Loop Engineering 算不算炒冷饭？有一部分。human-in-the-loop、LangChain、LangGraph、控制论，都早就有 loop 的影子。
值得讲的地方在后半句：loop 的位置变了。 它从“Agent 工作流里面的一段控制逻辑”，变成了“工程师组织 AI 工作的一套外部系统”。
提示词工程问的是：这一句话怎么让 AI 答得更好。上下文工程问的是：这一轮它该看见什么。Harness 工程问的是：它在什么环境里工作，怎么被约束、验证、审计。Loop 工程问的是：这套环境怎样自己跑下去，怎样发现任务、分派任务、检查结果、记录状态，并在没有你每一步催促的情况下逼近正确结果。
如果说 Harness 的公式是 Agent = Model + Harness，那么 Loop 可以理解成：
Loop = Harness + Cadence + Gate + Feedback + Memory
到这里就别再纠结这个词新不新了。更该问的是：你有没有开始从“我怎么提示 Agent”，切到“我怎么设计一个能提示 Agent 的系统”。