Loop 工程：Prompt 工程之后，Agent 时代的新分工

最近“Loop 工程”一词突然爆火起来。OpenClaw 作者 Peter 在社媒发帖，声称开发者不应该继续直接写 Prompt，而应该设计 Loop(循环) 来 Prompt Agent。这个帖子引发开发者热议，诞生了新的词汇 "Loop 工程" 与 "Loop 工程师" 等等。

这句话听起来有点像新概念包装，但它背后其实对应的是 AI 编程方式的一次真实变化。

过去两年，我们和 AI 协作的主流方式是 Prompt Engineering。人写提示词，模型生成结果，人再检查，再补充上下文，再继续追问。这个过程中，人本身就是循环的发动机。模型只是一个工具，每一步都要等人来推动。

但当 Claude Code、Codex 这类 coding agent 逐渐成熟之后，其实我们不再需要和大模型进行对话，可以直接依赖于Agent，让大模型可以工作的边界拓宽了。Agent 可以读代码、改文件、跑测试，甚至调用外部工具。于是瓶颈也发生了变化：过去在使用的时候其实大多数都在考虑“怎么写一个好 Prompt”，现在则要求设计一个好用的系统，让Agent能够在上面自主运行，以及怎么判断自己做对了”。这就是 Loop 工程的核心。

所谓 Loop，是一套自动化工作闭环。它通常包含几个步骤：先发现任务，比如读取 issue、CI 失败记录、最近 commit；再给 Agent 注入必要上下文；然后让 Agent 在隔离环境里执行；执行后由测试、规则或另一个 Agent 验证结果；最后把状态写入文件、看板或数据库，决定下一轮继续、提交 PR，还是交给人处理。

这种流程，其实说白了就是让系统可以持续不断的驱动模型自主完成任务。Loop Engineering 是把“由你来 Prompt Agent”替换成“由系统来 Prompt Agent”。人不再站在每一轮对话中间，而是上移到系统设计层：定义目标、边界、上下文、工具、验证器、状态和退出条件。

一个 Loop 到底是什么

Google 工程负责人 Addy Osmani 最近也在认真讨论这个问题。他提到，Claude Code 和 Codex 现在已经原生具备了五个核心构件：

Skills。

可复用的指令集，用来告诉 Agent 如何处理某一类问题。它不是一次性的 Prompt，而是可组合的操作流程。两者区别很关键：Prompt 告诉 Agent “现在要做什么”，而 Skill 告诉 Agent “遇到这一类情况应该怎么思考”。

Context injection，上下文注入。

Loop 会读取当前世界的状态，比如打开的 issue、最近的 commit、昨天失败的 CI，或者其他相关信息，然后在要求 Agent 行动之前，把它真正需要的信息提供给它。Agent 不需要反过来问“现在发生了什么”，因为 Loop 已经提前告诉它了。

Sub-agents，子 Agent。

一个 Agent 可以派生出其他 Agent 来处理更聚焦的子任务。比如 triage Agent 读取 issue 队列，判断哪些问题值得修；然后它派出 worker Agent 起草修复方案，再派出 reviewer Agent 根据现有测试和项目规范检查这个方案。整个协调过程是自动完成的。

Connectors，连接器。

当 Agent 完成任务后，Loop 会处理后续动作。比如打开 PR、更新 ticket、发消息到 Slack。Agent 不需要理解你的项目管理工具，Loop 会负责这些集成。

State files，状态文件。

Loop 会持久记录它尝试过什么、哪些通过了、哪些失败了、还有哪些问题没解决。等它明天再次运行时，不会从零开始，而是会从上次停止的地方继续。

最后把这些东西组合起来，就是一个loop架构，它能够处理某一类工作，只有当事情真正超出它能力范围时，才会转交给你。

这就是一个完整的工程工作流。开发者只需要设计这个 Loop 一次，而不需要手动 Prompt 其中每一个步骤。

与Context Engineering、Harness Engineering有什么区别？

过去一年，Agent 圈连续出现了几个词：Context Engineering、Harness Engineering、Loop Engineering。很多人会觉得这些词互相重叠，甚至有点像“换个壳继续造概念”。但如果仔细拆开看，它们其实不是替代关系，而是层层叠加的关系。

Context Engineering 解决的是：Agent 应该看见什么。

Harness Engineering 解决的是：Agent 怎么稳定地完成一次长程任务。

Loop Engineering 解决的是：系统能不能自己决定什么时候启动 Agent、让 Agent 做什么、做完之后谁来验收、下一轮从哪里继续。

这三层的变化，本质上是人的决策权不断往上移。

以前做 Prompt 工程时，人就是循环本身。你写一句提示词，模型给一个结果，你看完之后继续补充、纠错、追问。整个过程虽然有 AI 参与，但最后还是需要经过我们自己来决定是否完成所有的工作。

OpenClaw 作者 Peter提到的Loop 工程想表达的是：开发者不应该再一轮一轮地手动 Prompt Agent，而应该设计一个循环系统，让这个系统去 Prompt Agent。也就是说，我们不需要亲自按每一次确认Agent是否执行，需要的是设计一个“什么时候该按回车、谁来按、按完怎么验证、失败后怎么重试、什么时候升级”的过程给到Agent。

这里面举个简单例子，你就能够理解什么是Loop工程了~

传统方式是你对 Agent 说：“帮我修这个 bug。”

Loop 的方式则是：系统每天自动扫描 GitHub Issues 和 CI 失败项，挑出可处理任务，拉一个独立分支或 worktree，让 Agent 尝试修复，跑测试，读取错误，再继续修。如果测试通过，就自动开 PR；如果评审不通过，就重新进入下一轮；如果风险太高，就升级给人工处理。

Loop工程本质上就是要设计一个整体闭环来，需要我们自己定义任务的来源，运行环境，任务的目标等等，同时也需要定义验证标准是什么、失败后如何恢复、什么时候必须人工介入。

所以，Loop 工程的核心是 Prompt 被放进了一个更大的系统里。

这也是它和前两个概念最容易混淆的地方。

怎么区分这三个概念？

Context Engineering 主要是在解决上下文问题。Agent 的上下文窗口是稀缺资源，代码库十万行，当前任务到底该给它看哪几段？历史对话很多，哪些信息要保留，哪些可以压缩？工具列表怎么设计，才能让 Agent 自己拿到正确的信息？这一层的关键，是让 Agent 看见该看见的东西。

Harness Engineering 则进一步解决稳定性问题。Agent 跑长任务时，很容易卡住、复读、跑偏、丢记忆、越权操作。所以需要结构化计划、sub-agent、checkpoint、权限黑白名单、工具调用格式修复、循环检测等机制。它的目标是让 Agent 能在一个安全护栏里完成一次复杂任务。

Loop Engineering 再往上走一层。它不只是让 Agent 完成一次任务，本质是让系统持续承担一项职能。Harness 更像厨房：你给厨师菜谱和工具，厨师做完一道菜，这次任务结束。Loop 更像餐厅：你设计营业时间、后厨流程、菜单更新、差评处理、库存补货，餐厅每天自己运转。

所以 Loop 和 Harness 最大的区别，主要是设定的任务时间形态不同。

Harness 服务于一次有限任务。任务来了，Agent 协作完成，验证通过，系统退场。

Loop 服务于一项持续职能。它没有真正意义上的终点，只有下一轮什么时候开始、接着处理什么、哪些问题要升级给人。

这也是为什么有人说 Loop 工程更像 AI Coding 时代的 CI/CD。比如定期检查 Issues、自动探索解决方案、自动 Review PR、自动整理项目 Skills、自动根据 main 分支变化更新知识库。这些东西单看都不神秘，很多只是 cron job、GitHub Actions、worktree、sub-agent、MCP、memory/state 的组合。但组合到一起之后，就可以构成一个完整的Loop工程。

以前是人驱动 Agent。现在是系统驱动 Agent。人的位置从“执行者”变成了“设计者”和“裁决者”。

但也正因为如此，我觉得 Peter 那句“不再 Prompt Agent，而是设计 Loop 去 Prompt Agent”有启发性，也有一点过于激进。

因为在真实工程里，Loop 不可能完全替代 Prompt。它更适合那些目标明确、边界清晰、结果可验证的任务，比如代码测试、CI 修复、批量重构、Issue 预处理、模型训练实验、自动评审、数据处理、报告生成等。

但对于产品判断、架构取舍、复杂安全分析、灰度策略这类问题，Loop 反而容易制造幻觉。因为这些任务没有简单的 pass/fail。系统看起来一直在跑、一直在产出、一直在优化，但不代表方向真的对。

更大的问题是，Loop 会放大错误。

手动 Prompt 错了，通常只是一轮错。Loop 错了，可能是连续错、自动错、批量错。它可能自动改代码、自动开 PR、自动关闭 ticket，甚至自动把错误经验写进项目记忆。越自动化，越需要硬边界。不能只靠 System Prompt 里写一句“不要做危险操作”，而要有真正的权限控制、沙箱、回滚、审计和人工确认机制。

还有一个现实问题是 Token 消耗。

Loop 本质上是在让 Agent 持续运行，尤其是多 Agent、自动验证、反复重试之后，Token 消耗会明显上涨。对于有无限额度的人来说，这可能很自然；但对大多数开发者和企业来说，成本、延迟、稳定性都会变成现实约束。所以 Loop 不是越多越好，也不是越自动越先进。

真正合理的做法，可能不是全面抛弃 Prompt，而是两条腿走路。对于一些高频、重复、可验证、低风险的任务，可以交给 Loop。对于模糊、高风险、需要判断的任务，仍然应该保留 Human in the Loop。

从上面整体看下来，Loop工程不是完全新的技术组件，因为它用的很多东西早就存在：cron、CI、worktree、sub-agent等等。真正新的地方是这些组件被放进了一个持续运转的时间结构里。

到这里，再次总结一下Context、Harness、Loop三种东西的区别：

Context Engineering 让你从“写 Prompt 细节”升级到“设计信息边界”。

Harness Engineering 让你从“设计信息边界”升级到“设计任务执行护栏”。

Loop Engineering 让你从“设计单次任务护栏”升级到“设计一项持续职能的运转方式”。

每往上一层，人都不是更轻松，而是责任更重。因为你不再只对某一次回答负责，而是要对一套系统的持续行为负责。

Prompt 是一次调用，Harness 是一次任务的护栏，Loop 是一项持续职能的运转机制。

使用Loop工程对工作方式意味着什么

从 Prompt 转向 Loop 设计，并不是软件开发独有的变化。只要 AI 在某个领域强到可以自主处理一类任务，这种模式就会自然出现。

人并没有从流程中消失，而是上移到了更高的抽象层。

过去，人负责执行每一个具体步骤：写代码、跑测试、看报错、继续修改。现在，人开始负责定义工作类别、设计成功标准、搭建验证系统，让 Loop 能够判断自己是否完成任务，并在遇到真正超出能力边界的问题时，把它交还给人。

这会真实改变日常工作的形态。

以前，一个开发者可能花四个小时写功能代码；现在，他可能花四个小时设计一个 Loop，让它自动生成代码、运行测试、检查回归、提交 PR。表面上看，还是在完成同一类工程任务，但人的位置已经变了：输出变了，杠杆变了，所需要的能力也变了。

你今天设计的 Loop，未来也可能被一个“元 Loop”取代，由它来设计新的 Loop。到那时，问题就会变成：人到底在哪些地方仍然不可替代？

这其实也是自动化一直以来的核心问题。关键从来不只是机器能不能执行任务，而是机器是否有判断力：它是否知道哪个任务值得做，为什么值得做，以及结果什么时候才算真正好。

这种判断力并不天然存在于 Loop 里。它来自设计 Loop 的人。

写在最后

所以我觉得，Loop 工程并不是一个单纯的新名词，也不是 Prompt 工程的简单替代品。它更像是 Agent 能力发展到一定阶段之后，自然出现的一种工程化抽象：当模型已经可以读代码、改代码、跑测试、调用工具时，真正重要的问题是“如何设计一套系统，让 Agent 持续、稳定、可验证地完成一类任务”。

但这也意味着，人的责任并没有减少，而是变得更重了。Loop 可以放大效率，也会放大错误；可以让一个人的判断力变成多个 Agent 的吞吐量，也可能让一个错误的判断被自动化地重复很多次。

因此，Loop 工程真正值得关注的地方在于：AI 编程正在从“人和模型对话”走向“人设计系统驱动模型”。Prompt 是一次调用，Harness 是一次任务的护栏，而 Loop 则是一项持续职能的运转机制。谁能更早理解这种变化，谁就能更早获得 Agent 时代真正的工程杠杆。