什么是 Loop Engineering？
单次调用 Agent 的效果已经到头了。
你是不是也厌倦了天天给 AI 充当人肉搬运工，每天把问题复制过去、把结果复制回来？
当大多数人还在卷 Harness Engineering 的时候，大厂和顶级开发者已经悄悄换了新赛道。
就在前几天，Chrome 团队的 Addy Osmani 就发了一篇推文，昭示着 Loop Engineering 的到来。
Left 帮你们把长文读完了，直观感受是，这套理念与 OpenAI 和 Anthropic 近期的密集动作高度吻合。
它正在把人类从枯燥的介入循环中解放出来，让 AI 的任务完成度直接上一个台阶。
那么 Loop Engineering 到底是什么东西？
结合 Left 自己的经验，今天和大家彻底聊透。
1. 为什么 Harness Engineering 的效果已经到头了？
因为在真实场景下，任务只要稍微复杂一点，目标可能模糊，解法可能跑偏，Agent 很难通过单次调用就产出完美的结果。
很多人正在做的 Harness Engineering，本质上都在试图卷单次调用的完成度。
在各种 Prompt 框架和工程加持下，单个 Agent 的任务得分确实可以从 60 分飙到 90 分。
但想要再往上走，继续死磕单次调用，收效甚微。
这就像让人类去干活一样，任务复杂了谁都会出纰漏。
这时有人会说：那就让它做完自己检查一下行不行？
答案是不行。
人如果既当球员又当裁判，在做裁判的时候就会本能地偏袒自己。
人类身上这种自我检查流于表面的毛病，在单个 Agent 身上完美重现了。
Agent 写完了代码后，会极其自信地告诉你：我已经为您搞定了，不管任务是否完成。
行业的解决方案是，引入裁判机制，让裁判评判 Agent 的产出，实际使用下来比单个 Agent 自查效果更好。
但是这样又带来新的问题，我们不得不被迫介入，把人机协同的过程变成了极其机械的人肉 SOP 循环：
派发任务 → Agent 执行 → 人类验收结果 → 人类提交反馈 → Agent 重新执行 → 人类再次验收 → 派发下一个任务
为了减少这种折腾，有些团队尝试把某些节点用 AI 替代，比如让一个固定的 AI 扮演裁判来验收结果。
只要标准足够明确，这确实能解决一小部分问题。
但这并没有解决根本矛盾，整个流程的运转依然卡在人机交互的环节上，人类成了那条把各个节点串联起来的肉体协调器，每天的大量精力都被卡在枯燥的循环里，极大拖慢了任务的效率。
既然单个 Agent 效果已经达到天花板，而人类的精力又被严重消耗在机械的节点跳转中。
如何让一套系统接管这个 SOP 循环，把人类从人肉搬运中解放出来，成了当前最迫切的工程问题。
2. 什么是 Loop Engineering？
回到开头的问题：到底什么是 Loop Engineering？
过去，我们在工程上习惯了以人类为中心的交互模式。
人类扮演了外部调度器的角色，手动去驱动每一个流程节点，效率天花板极其明显。
为了让系统彻底代替人类去接管、驱动、监督 Agent 的状态流转，直至达成最终目标——在这个演进过程中诞生的所有自动化闭环架构与工程解决方案，行业称之为 Loop Engineering（循环工程）。
如果说 Harness Engineering 关注的是如何提升单个 Agent 的单次执行质量，那么 Loop Engineering 关注的就是如何构建一套具备状态感知与自我修正能力的闭环系统，在无需人类介入的前提下，通过多轮次迭代达到期望结果。
说白了，这只是应用层在架构设计上的自然演进。
我们的关注点，从最初的怎么优化单个 Prompt 的输出，真正回到了如何去构建一个长生命周期的自治系统上。
3. 行业内的四次尝试
3.1. Anthropic 团队：从命令到 /loop 插件
Anthropic 团队的项目仓库里，每天都有几十个 GitHub Issue 排队等待处理。
以前工程师得手动复制信息、喂给 Claude Code 处理，处理完人类再测试、提交。
天天干这种机械的、手动复制的活，简直是浪费生命。
于是他们开发了 /loop。
/loop 直接把 Agent 挂在定时任务上：
每隔一小时自动去拉取最新 Issue，自己翻代码、改 Bug、跑测试，直到修好并自动提交 PR。
如果努力 5 轮失败，则自动贴出解题思路和日志报告退出。
Claude Code 负责人 Boris Cherny 对 /loop 很满意说道：“我不再手动 prompt Claude 了，我的工作是写 Loop。”
3.2. Andrej Karpathy：验证者（Verifier）多轮试错循环
传统调模型或跑实验时，工程师需要根据跑出来的结果，人肉分析参数，再手动改代码跑下一轮。
人在其中充当了肉体协调器，效率极低。
Karpathy 在他的开源项目 AutoResearch 中引入了验证者（Verifier）角色。
在限定时间内自动化跑多轮循环，每一轮的任务效果都要经过验证者的打分和反馈，并将这个反馈自动带入到下一轮循环中。
Karpathy 个人测试中，自动化狂跑 2 天、700 次实验，模型训练效率直接提升 11%。
AI 靠着极其高频的"试错-回滚-再试"循环，在很多任务上的调优能力已经超越了普通人类工程师。
3.3. Codex 团队：用 /goal 插件消灭"任务完成幻觉"
Codex 团队在用 AI 写代码时，经常被 AI 气得发笑。
很多时候 AI 只写了一半，或者写了一堆根本跑不通的垃圾代码，就极其自信地回复一句：“已经为您写好了！”
工程师过去一跑却满屏飘红。
为了解决任务完成幻觉的现象，他们开发了 /goal 插件。
引入了测试驱动开发（TDD）的自治循环模式：
人类下达任务与完成指标
↓ /goal 拦截请求，解析为 "自动化测试/判定标准"
↓ Agent 闭门写代码 → 进入独立沙盒（Docker MiniVM）运行测试
↓ [测试未全绿] → 提取真实报错日志重新喂给 Agent → 强制继续修改
↓ [测试彻底全绿] → 终结自治循环，向人类交付代码
Codex 团队用确定性的测试环境做强力约束，把"球员"和"裁判"剥离开来，彻底消灭 AI"任务完成幻觉"的问题。
3.4. 解决通用任务的 Dynamic Workflow（动态工作流）
前面的三个尝试虽然牛，但工程师们很快发现了一个致命瓶颈：它们的循环路线全都是程序员提前硬编码写死的。
AI 只能在固定的流程执行，遇到复杂的、没见过的多分支任务，硬编码的循环立刻就没用了。
于是，业界开始探索更高级的形态：Dynamic Workflow（动态工作流）。
它不再用固定的代码去卡死流程，而是把决策权交给 AI。
一个复杂的突发任务进来，AI 会根据当前的动态变化，自己从模式集里抽调模式：
- 它觉得目标不明确，就自己切成"赛马模式"让几个子 Agent 互卷
- 它发现步骤太长，就自己动态路由切成"分类-行动模式"把任务剁碎
- 它发现中间某一步翻车了，就自己临时组装一个"验证者"去打回重跑
整个工作流的下一步往哪走、怎么循环、调用什么能力，完全是系统在运行过程中根据实时反馈动态而来的。
这直接把 Loop Engineering 从在固定流程中死循环，推向了 AI 自己看情况、调整动作的完全体形态。
4. 要把人解放出来，到底还差临门哪几脚？
想要彻底把我们人类从循环里解放出来，建立一套完全自治的 Loop 系统。
结合原文，我认为以下这七个维度是需要攻克的技术难点：
- 自动触发机制（Automations）：如何让系统在没有人类点下运行按钮时，自己感知到任务的开始，比如通过定时任务、Webhooks 或者是特定事件来自动触发
- 任务分发调度（Schedulers）：如何把一个庞大且复杂的宏观任务，精准拆解成多个互不干扰、具备前后依赖关系的独立子任务
- 子智能体调度（SubAgents）：在复杂的业务场景下，如何像用户那样，去按需调动不同的子 Agent 去执行这些被剁碎的子任务
- 并行任务隔离（Worktrees）：子 Agent 在改代码、跑编译的时候，工作环境如何做到彻底隔离互不干扰，不至于把主任务搞得一团糟
- 生命周期管理（Verifiers / State）：如何保持长时运行任务的连贯性，系统必须能死死记住任务的当前进度、每个子 Agent 的完成情况以及失败反馈日志
- 跨系统连接器（Connectors）：如何让系统真正拥有与外界环境顺畅交互的能力，目前行业公认的最佳实践是基于 MCP 和 Plugin 去实现
- 行业领域能力（Skills）：如何让特定的子 Agent 拥有对应的垂类能力，比如视觉审美能力或者是数据分析能力
这七个方向，就是从仍需人类介入协同的 Harness Engineering，走向完全体自动化 Loop Engineering 的必经之路。
当然，不管是 Harness Engineering 也好，Loop Engineering 也罢，它管的仅仅是系统任务完成度的提升，任务的最终责任人依然是我们自己。
完全放任不管容易把事情搞得一团糟，在关键节点上保留必要的人工验收与干预，才是最稳妥的人机协同常态。