--- title: "Loop Engineering：从对话走向系统" author: Miles Ma date: 2026-06-21 section: Agent 系统 url: https://immilesma.com/blog/loop-engineering/ description: "人不再逐轮提示 Agent，而是设计一个会自动规划、执行、验证和修正的循环。这是 AI 工作方式从技巧走向系统的关键变化。" --- # Loop Engineering：从对话走向系统 > 人不再逐轮提示 Agent，而是设计一个会自动规划、执行、验证和修正的循环。这是 AI 工作方式从技巧走向系统的关键变化。 我第一次看到 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 的系统”。