Loop Engineering：AI开发新范式，替代Prompt工程

近期，两位AI工具领域的核心从业者先后抛出了一个新的行业观点：不再需要手动给AI模型编写提示词，而是应该设计自动化的循环来驱动模型工作。这一观点标志着AI工程实践正在进入一个新的阶段——Loop Engineering时代。

2026年6月，Anthropic旗下Claude Code的负责人Boris Cherny表示：“我不再手动给Claude编写提示词了，我现在会运行自动化循环，由这些循环来完成提示词编写和任务判断的工作，我的职责变成了设计这些循环本身。”几乎在同一时间，OpenClaw的创始人Peter Steinberger也提出了类似的理念：“你不应该再手动给编码类AI代理编写提示词，而是应该设计能够驱动代理工作的循环流程。”

这两位行业先锋在不同场景下得出了相同的结论，并非偶然，而是AI工程实践自然演化到了一个关键拐点。本文将系统梳理Loop Engineering的发展脉络、核心本质，以及判断是否需要构建自己的Loop的标准。

一、Loop Engineering的演化路径：从Prompt到闭环

要理解Loop Engineering，我们需要先回顾AI工程实践的发展历程：

1. Prompt Engineering阶段（2024年）：这一阶段的核心是通过优化提示词的措辞、示例和格式，让AI模型输出符合预期的结果。但这种方式存在根本性局限：必须在单次交互中包含所有必要的背景、规则和约束，模型只能基于给定的信息进行处理，无法自主获取额外信息。

2. Context Engineering阶段（2025年初）：随着实践深入，人们发现问题的核心不在于提示词的措辞，而在于模型获取的信息总量。这一阶段的重点是优化模型的输入上下文，通过系统提示词、小样本示例、RAG检索等方式，为模型提供更完整的背景信息，减少模型的猜测空间。

但上下文优化依然无法解决复杂任务的多步执行问题：比如重构代码模块，需要先读取代码、修改接口、更新调用方、验证测试结果，这些步骤无法通过单次提示完成。模型需要自主规划执行步骤、调用工具、根据中间结果调整方向，于是Harness Engineering应运而生。

3. Harness Engineering阶段：这一阶段的核心是为AI代理配备完整的工具链，包括shell命令、文件系统操作、MCP连接器、沙箱环境等，并加入重试机制和权限控制，让代理能够在单次会话中完成多步复杂任务。Claude Code、Cursor等工具本质上都属于这类Harness产品，能够根据用户的任务自主规划步骤、调用工具并验证结果。

但Harness依然存在一个关键瓶颈：人工介入。即使拥有功能完备的代理，用户依然需要每天手动检查运行状态、复制错误日志、提交给代理修复、审核结果并批准合并。这种重复的人工操作不仅低效，还会成为整个流程的卡点。

4. Loop Engineering阶段：这一阶段的核心目标是将“人工触发代理→人工判断结果→人工决定下一步”的手动循环，替换为自动化的系统闭环。这类系统能够定时触发任务、验证执行结果、记录运行状态、自主决定继续执行、终止任务或上报异常。用户不再是提示词编写者，而是成为循环系统的设计者。

二、Loop的核心组件：以CI修复场景为例

行业通用的Loop Engineering包含六个核心组件，我们可以用日常开发中常见的CI失败修复场景来具体说明：

假设团队每天都会遇到CI构建失败的情况：某个测试用例未通过，或者类型检查报错。没有Loop时，流程是手动打开CI页面、复制错误日志、提交给代理修复、等待测试通过、提交PR。而引入Loop后，流程会完全自动化：

1. 触发层（Automations）：系统通过定时任务、CI失败的WebHook或者代理心跳检测自动启动循环。如果CI状态正常则不执行任何操作，一旦检测到失败，就自动读取错误日志并确定当日的修复目标。没有这个触发机制，再完善的Loop也无法主动运行。

2. 隔离工作区（Worktrees）：修复操作会在独立的Git工作区中执行，避免多个并行修复任务之间的代码冲突，确保每个子任务都拥有独立的代码副本，互不干扰。

3. 项目知识（Skills）：代理启动时会自动读取项目的规范文档，比如编码约定、架构设计、常见问题解决方案等，避免每次运行都重新推导项目规则，减少Token消耗和执行时间。

4. 外部连接器（Connectors）：修复完成后，代理需要能够自动提交PR、关闭相关工单、发送通知到团队渠道，这就需要通过MCP协议连接GitHub、Slack、项目管理工具等外部系统，实现与真实工作环境的交互。

5. 独立验证（Sub-agents）：修复代码后需要自动运行测试进行验证，但这里的关键设计是使用独立的代理进行检查：就像学生不能自己批改试卷一样，修复代码的代理无法有效发现自身的逻辑盲区，需要另一个代理或模型来完成验证工作。

6. 状态存储（Memory/State）：每次运行的结果都会被记录下来：如果测试通过则更新状态文件并提交PR；如果失败则记录本次尝试的内容和卡住的环节。下一次循环启动时，可以读取历史状态，避免重复尝试已经失败的路径，弥补AI上下文窗口无法持久化的局限。

这就是一次完整的Loop运行流程：用户早上打开电脑时，看到的不再是“CI构建失败”的提示，而是“有一个PR等待审核”或者“某个问题经过两次尝试仍未解决，需要人工介入”。

很多人会疑惑，Loop看起来和普通的定时任务（Cron）有什么区别？两者的核心差异在于决策逻辑：Cron的执行逻辑是硬编码的，比如“如果CI失败则执行修复脚本”，而Loop的决策中心是大语言模型，能够根据实时情况灵活调整策略。比如同样遇到CI失败，Loop可以判断这是一个不稳定的测试用例直接跳过，或者判断这涉及多个文件的依赖变更需要分步处理，其行为是在运行时动态决定的。

三、Loop的本质：控制论视角下的闭环系统

目前很多关于Loop Engineering的讨论都聚焦于组件的编排，比如如何使用工作区隔离、如何连接外部系统，但很少有人解释这些组件背后的底层逻辑。实际上，Loop的核心本质就是经典的控制论（Cybernetics）。

控制论研究的是系统如何通过反馈机制维持目标状态，其核心结构包含三个基本角色：

控制器：负责读取反馈信号，决定下一步的执行动作。在Loop场景中，控制器就是整个编排逻辑，它会读取验证结果，判断是否达到目标，如果未达标则生成新的提示词再次执行。控制器要做出准确的决策，需要两个关键支撑：一是项目的规范知识（Skills），避免每次都从零推导规则；二是持久化的状态存储（Memory），记录历史运行情况，避免遗忘之前的尝试。

执行器：负责将控制器的决策转化为对真实世界的操作。在AI代理场景中，执行器就是工具调用层，包括文件编辑、Shell命令、API调用等。为了确保执行的准确性和安全性，执行器需要能够连接外部系统（Connectors），同时提供隔离的运行环境（Worktrees）避免冲突。

传感器：负责在执行完成后测量结果，反馈偏差信号。在Loop场景中，传感器就是验证环节，它会输出实际结果与目标之间的差异，让控制器能够调整后续策略。传感器的独立性至关重要：如果由执行任务的代理同时担任验证角色，很容易因为自身的逻辑盲区无法发现错误，因此需要使用独立的Sub-agents来完成验证。

除了这三个核心角色，还有一个关键的启动机制：Automations，也就是触发Loop运行的条件，没有这个机制，整个闭环系统无法主动启动。

当Loop运行起来后，通常会有三种结局：

1. 收敛到正确状态：代理成功完成任务，验证结果准确无误，没有出现幻觉，这是最理想的结局。

2. 收敛到错误状态：Loop看似完成了任务，但验证结果存在错误：比如测试通过是因为测试用例本身存在缺陷，或者构建通过是因为问题路径未被触发，这种虚假的成功比持续失败更糟糕。

3. 发散：Loop无法达到验证接受的状态，持续修改却越来越偏离目标，最终达到运行上限后终止。

对于需要高质量结果的复杂AI任务，我们无法通过固定的计划来掌控系统，而控制论给出的解决方案是：提高收敛到正确状态的概率，或者限制后两种结局的损失。

在这三个角色中，决定收敛速度的关键是传感器。如果传感器只能返回简单的“通过/失败”信号，控制器只能盲目猜测下一步的调整方向；但如果传感器能够返回详细的偏差信息，比如“哪个测试用例失败、哪个断言未通过、哪段代码引入了问题”，控制器就可以针对性地修复具体缺陷，大幅压缩搜索空间。

很多开发者会陷入一个误区：花费大量资源购买最强的模型来编写代码，却只用简单的对话式验证来检查结果，最终反复出现幻觉，离目标越来越远。实际上，高杠杆的优化方向是设计优秀的传感器，而不仅仅追求更强的模型性能。正如行业总结的规律：“优秀的提示词+薄弱的验证会失败；普通的提示词+强大的验证会成功。”传感器本身就是Loop设计的核心。

四、如何判断你是否需要构建Loop

既然传感器是Loop的核心，那么判断“是否应该构建Loop”的问题，就可以转化为一个更具体的标准：你能否编写一个不需要人工盯守就能自动拒绝不合格输出的检查机制？

如果答案是肯定的，那么你就具备了构建闭环系统的前提；如果答案是否定的，那么“任务完成”就依赖于主观判断，无法通过自动化循环来实现。

即使具备了前提条件，还有几个现实约束需要考虑：

1. 任务的重复性：只有当任务至少每周出现一次时，构建Loop的投入才值得，否则只是一个昂贵的一次性脚本。

2. Token预算的可承受性：Loop会反复读取上下文、重试失败路径，每一次探索都会消耗Token成本，需要确保预算能够覆盖这类开销。

3. 足够的观察工具：代理需要能够获取足够的信息来判断执行结果，否则就是在盲目修复问题。

还有一类常见的错误场景，就是为没有明确客观标准的任务设计Loop。比如“帮我重构代码让它更优雅”“写一篇好的技术博客”“设计一个优秀的API”，这类任务没有明确的通过/失败标准，“优雅”“好”都属于主观判断。即使使用另一个大语言模型来打分，也会因为模型本身的幻觉和评分标准的不稳定性，导致验证结果不可靠，最终形成虚假的闭环。

如果你确认自己满足所有条件，构建Loop的正确顺序应该是：先编写项目知识文档（Skills），明确代理的执行规则；再设计验证机制（传感器），精确定义任务完成的标准；最后再添加触发机制（Automations）。简单来说，先做Inspector，再做Loop。

Loop本身并不关心操作者是谁，它只会按照固定的流程运行“读取传感器→判断决策→执行下一步”。但传感器的设计质量完全取决于你对系统的理解深度，Loop本质上放大的是你的判断力。

附录：参考资料

1. Loop Engineering: The New Way to Use Claude Code & Codex — Addy Osmani

2. Loop Engineering Is NOT What Everybody Thinks It Is — Agent Native Dev

3. How Claude Code, Codex, and Cursor Do Loop Engineering — AI All In

4. Loop Engineering — Cobus Greyling

5. Why Is Loop Engineering Trending — 海外AI技术社区

6. Loop Engineering Is Replacing Prompt Engineering — Coding Nexus

7. What is Loop Engineering? How it is different than Harness Engineering — Akshay Kokane

8. Loop Engineering Is Here. Most of You Should Not Build One Yet — Alireza Rezvani

9. How To Build a Claude Loop Engineering Better Than 99% of People — Data Science Collective

塔猴是一个专注于为用户提供系统学习、内容创作与商业连接的AIGC综合服务平台，致力于为每一位AI探索者打造理想的创作、成长家园。在塔猴，你不仅可以学习众多AIGC类实战课程，获得与时俱进的AIGC技能和视野，还有机会获得长期商业合作和接单机会！点击进入：https://www.tahou.com/

AI生成内容提示：本文由人工智能辅助创作，内容仅供参考，不代表平台观点。请注意核实信息的准确性，并理性判断。