Agent 系列（六）：什么是 Loop Engineering？

这两天 Loop Engineering 这个概念又又又被炒起来了....，简单理解下！

今天的 Coding Agent 已经是一个相对成熟的工程系统。以 Claude Code、Codex、Cursor Agent 这类工具为代表，Agent 已经可以读仓库、改文件、执行命令、跑测试、调用工具、维护上下文，也可以在 Harness 的约束下完成一段完整的工程任务。

所以 Loop Engineering 讨论的重点，已经越过了 “让 Agent 会不会写代码” 这个阶段。它要处理的问题是，当 Agent 已经能完成单个任务以后，怎样让一批任务持续、稳定、可控地向前推进。

这就是我理解的 Loop Engineering。

Harness 让 Agent 把一次任务做完，Loop 让 Agent 不断拿到下一件该做的事，并且知道什么时候停下来。

成熟 Coding Agent 之后，新的瓶颈在哪里

现在很多团队使用 Coding Agent 的方式，仍然很像 “手动派活”。绝大多数场景里，Agent 的单次执行能力通常已经够用，真正消耗人的地方，是每次都要人来点火。

人要发现任务，组织上下文，选择工具，启动 Agent，看执行结果，再决定下一步。如果只是偶尔用一次 Agent，这个成本可以接受，一旦把 Agent 放进日常研发流程，这些重复动作就会变成新的摩擦。

Loop Engineering 解决的就是这个摩擦。

它把 “发现任务、启动 Agent、验证结果、记录状态、进入下一轮” 这件事，设计成一个可以持续运行的工程循环，Agent 仍然负责执行具体任务，人负责定义循环的边界、验收标准和退出条件。

它和单纯的 Prompt Engineering 处在不同层面，Prompt 主要影响一次调用的质量，Loop 影响的是任务能不能持续流动。

Harness 解决执行，Loop 解决流转

这里我避免把 Loop Engineering 讲成概念堆砌，最重要的是分清它和 Harness Engineering 的边界。

Harness 关心 Agent 拿到任务以后怎么执行，上下文怎么组织，工具怎么暴露，命令怎么跑，沙箱怎么隔离，权限怎么控制，日志怎么记录，失败以后怎么恢复，这些都属于 Harness 的工程范围。

换句话说，Harness 是 Agent 的运行底座，它把模型、工具、文件系统、命令行、测试系统和权限策略接在一起，让 Agent 可以像一个工程执行者那样工作。

Loop 关心 Agent 完成一次执行以后，系统接下来怎么走，结果通过了，是否生成 PR，结果失败了，是否重试，连续失败了，是否交给人；任务池里还有下一项，是否继续启动新的 Agent，旧状态要不要带入下一轮，哪些上下文应该丢弃。

所以 Loop 的边界天然跨过多次 Agent 执行，它管理的是一组任务的生命周期，范围远大于某一次工具调用。

可以用一个很简单的类比：Harness 像一台可靠的加工设备，Loop 像一条小型生产线。设备决定单件产品能不能加工出来，生产线决定原料从哪里来、加工失败怎么处理、合格品流向哪里、什么时候停机维护。

一个例子：从修一次 CI 到治理一类 CI

以 CI 失败为例。

如果只使用 Coding Agent 加 Harness，一个典型流程是这样的：研发复制失败日志，交给 Agent ---> Agent 定位问题，修改代码，运行测试，给出 diff。 这个流程已经很完整，也足够工程化。

但它只解决了 “这一次 CI 怎么修”。

如果改成 Loop，流程会变成另一种形态。系统每天定时读取 CI 结果，过滤掉已知环境波动，把真正需要处理的问题写入任务队列。每个任务进入独立 worktree，Agent 尝试修复并运行对应测试。测试通过后生成 PR 和摘要。测试失败时记录原因，达到重试上限后停止，把阻塞信息交给人。

第二天循环继续运行，它会读取昨天留下的任务状态，只处理新增问题和未完成问题，已经确认是环境波动的失败不会反复打扰人，已经失败多次的问题也不会无限消耗 token。

这样他的的价值就体现出来了：人从每天打开 CI 面板找活，变成只处理 Loop 推上来的有效结果。

这才是 Loop Engineering 解决的问题，它没有让 Agent 获得一种神秘的新能力，它让 “发现 CI 问题、分配修复、验证结果、沉淀状态” 变成 持续流程，所以这玩意和保障单次长任务执行的稳定性还不大一样，它关注的是更加主动和持续。

Loop 真正难的是收敛

很多文章讲 Loop Engineering，会把 Automations、Skills、Worktrees、Sub-agents、MCP 全部列一遍。这些都是有用的工程材料，但只列材料会把问题讲散。

Loop 能不能工作，核心看收敛条件。

比如 “优化登录模块” 这类任务，直接放进 Loop 很容易失控。Agent 可以一直重构、补测试、改命名、抽方法，看起来每一轮都有产出，实际上很难判断离目标更近了多少。

更适合进入 Loop 的任务，通常有清晰边界。比如 把旧认证 SDK 的调用全部迁移到新 SDK，auth 目录下测试必须通过，公共 API 入参和返回结构保持兼容，迁移完成后生成变更摘要，连续三轮无法通过测试就停止并输出阻塞原因。

这个任务之所以适合循环，是因为它有范围、有检查、有停止条件、有失败出口。

这也是 Loop Engineering 比较吃工程经验的地方，它要求我们判断一个任务能不能被自动验证，失败能不能被归因，结果能不能被审查，成本会不会失控；写 Prompt 主要考验表达能力，设计 Loop 考验的是工程边界感。

模糊任务直接进入 Loop，最终很容易变成技术债生产线，Agent 生成越快，理解债积累越快。

状态必须放在模型外面

Ralph Loop 很适合用来理解这件事。Thoughtworks Technology Radar 在 2026 年 4 月把它列为值得关注的技术实践，它的方式很简单：Agent 从任务列表里取一个未完成项，执行修改，运行测试，记录结果，然后进入下一轮。

它看起来没有复杂架构，但抓住了长期 Agent 任务里非常关键的一点：状态要放在模型外面。

长时间运行的 Agent 最容易出现两个问题:

• • 一个是上下文越来越脏，前面尝试过的方案、临时判断、失败路径都堆在对话里，后面越跑越偏。
• • 一个是进度只存在聊天记录里，一旦窗口压缩、进程中断或者任务切换，下一轮就接不上。

Ralph Loop 的处理方式很简单：每一轮尽量用干净上下文启动，任务状态写在外部文件里，执行结果写入日志，代码变化落到 Git 历史中。

这背后的思想其实就是 模型负责当前轮次的判断，外部系统负责保存长期状态。

总结

可以把 Loop Engineering 理解成 Agent 时代的研发流程工程，它把那些反复出现、边界清晰、可自动验证的工作放进循环里，让 Agent 持续消化；同时保留人工 review、人工决策和规则更新的位置。

Loop Engineering 的价值，来自 Coding Agent 进入日常研发流程之后的持续调度问题。

它解决的是 Coding Agent 工程化之后的下一个问题：当单次执行已经足够可靠，怎样让任务持续流动，并且在可控边界里收敛。

判断一个 Loop 是否成立，可以看三个问题：

• • 任务来源是否稳定。
• • 完成条件是否可验证。
• • 失败以后是否有明确出口。

把这几个问题搞清楚，Loop 才有工程意义，否则再多的 Skills、MCP、Sub-agents 和 Worktrees，也只是把一次性 Agent 调用包装得更复杂。