Loop Engineering：当开发者停止提示AI，开始设计AI的自我循环

2026年6月，OpenAI 旗下 OpenClaw 创始人 Peter Steinberger 在 X 上发出了一条仅12个英文单词的推文，一天之内获得约800万次浏览，在AI工程界引发了一场认知地震：

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

这条推文之所以引发如此巨大的共鸣，是因为它精确地捕捉到了2026年软件工程正在经历的一场根本性范式转移——开发者角色正在从"AI的操控者"转变为"AI循环系统的架构师"。

一、从"人驱动AI"到"系统驱动AI"

1.1 Prompt Engineering 的终结

回顾AI辅助开发的演进历程，大致经历了三个阶段：

第一阶段：手工提示（2022-2024）。开发者坐在终端前，逐条向AI发出指令——"帮我写这个函数""修改这个bug""重构这个模块"。人与AI之间的关系类似于"师傅带徒弟"：人给出具体指令，AI执行。这个阶段的核心能力是Prompt Engineering。

第二阶段：智能体协作（2024-2026上半年）。以Claude Code、Cursor、Copilot Agent Mode为代表的新一代工具开始支持"持续对话+工具调用"循环：AI能够自主读文件、搜索代码、运行测试、修复错误。人类从"给指令"转向"审核AI的行动——批准或拒绝"。Agent开始被视为一个可以"委托任务"的协作对象。

第三阶段：循环工程（2026年中至今）。开发者不再持续地与AI交互——无论是给提示还是审核行动。取而代之的是，开发者设计一个"循环系统"，让这个系统在无人值守的情况下持续运转、迭代、交付成果。人类的角色从"操作者"升级为"系统设计师"。

正如 Claude Code 创建者 Boris Cherny 所说：

"I don't prompt Claude anymore. I have loops running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."

这句话标志着一个时代的终结和另一个时代的开始。

1.2 什么是 Loop Engineering？

Loop Engineering 是由 Google Cloud 首席工程师 Addy Osmani 正式系统化的概念。其核心定义是：用你自己设计的系统，替代你作为"提示AI的那个人"的角色。

传统AI辅助编程的基本模式是：人→提示→AI→输出→人→提示→AI→输出……（人在回路中）

Loop Engineering 的基本模式是：设计循环→系统运行→AI自查→AI迭代→达标退出（人在回路外）

一个完整的 Loop 不是简单的"让AI重复做某事"，而是一个精密的工程系统，包含明确的目标定义、自动化的发现与触发机制、严格的验证标准、持久的记忆层，以及并行执行与隔离机制。

二、Loop 的六大核心模块

Addy Osmani 在他的系统化论述中，将一个完整的 Loop 拆解为五大组件加一个记忆层。

2.1 Automations（自动化触发器）

自动化是循环的"心跳"——它负责按计划自动发现和分诊任务，确保循环持续运转而无需人工干预。

典型实现方式包括：Cron 定时任务扫描代码库中待修复的问题；GitHub Actions 在特定事件（PR合并、Issue创建）时触发；通过 /goal 命令设定高层目标，由系统自动拆解为可执行的Loop任务。自动化的核心价值在于让Loop始终有事可做、有目标可追。

2.2 Worktrees（工作树隔离）

当多个 Agent 并行工作时，代码隔离变得至关重要。Git Worktree 允许每个 Agent 在独立分支上工作，互不干扰，各自拥有独立的工作目录。这种隔离机制的必要性在于：避免多个并行Agent对同一文件集的冲突修改；让每个Agent拥有独立的测试环境，确保验证结果的可信度；支持"竞争式执行"——多个Agent从不同角度尝试同一任务，最终选择最优解。

2.3 Skills（技能固化）

每个代码库都有独特的架构规范、编码惯例和领域知识。每次让Agent从零开始理解这些知识是巨大的浪费。Skills 机制通过声明式的 SKILL.md 文件，将项目知识固化为可被AI直接理解的格式。Skills 不是简单的文档——它们是结构化的、可被AI运行时解析和执行的知识包。一个Skill文件可以包含：代码库的架构决策记录（ADR）、命名规范和代码风格要求、API接口契约和调用方式、已知的"坑"和最佳实践。

2.4 Connectors（连接器）

Agent 需要与真实世界交互——操作GitHub、查询数据库、发送通知、部署服务。Connectors 通过 MCP 协议将Agent接入这些工具链。一个生产级Loop通常需要接入多个Connector：GitHub/GitLab用于代码管理和CI/CD；Slack/Teams用于通知和人工介入；云平台API（AWS/GCP/Azure）用于部署和监控；监控工具 API（Datadog/Prometheus）用于实时反馈系统状态。

2.5 Sub-Agents（子智能体分工）

这是Loop Engineering中最精妙的设计之一——写代码的Agent和检查代码的Agent分开，避免"自己给自己打分"的评估偏见。

典型的子Agent分工包括：实现Agent（负责编写代码）、测试Agent（负责编写和运行测试）、安全Agent（负责安全扫描和漏洞检测）、文档Agent（负责更新文档和变更日志）、评估Agent（负责最终质量评判并决定是否退出循环）。各Agent之间通过共享工作区和消息总线协作，形成"生产线式"的自动化工作流。

2.6 Memory（记忆层）

记忆层是Loop Engineering区别于普通自动化脚本的关键特征。LLM 是无状态（Stateless）的——每次调用之间没有记忆。但在一个持续运行的Loop中，决策必须基于历史经验。

记忆层通常包含：AGENTS.md 文件作为"项目宪法"，定义不可违反的规则和长期的架构约束；进度文件记录循环的当前状态、已完成的工作和下一步计划；决策日志（Decision Log）记录重要决策及其理由，避免在不同会话中重复推理或做出相反决策；经验库累积的错误模式和修复方案，使系统能够"吃一堑长一智"。

三、从工程视角理解 Loop 的本质

3.1 Loop = while-loop + LLM判断 + 确定性执行 + 反馈闭环

如果抛开所有框架和工具的外衣，Loop 在工程本质上就是一个增强版的 while-loop：

while not goal_achieved():
    context = memory.retrieve(relevant_history)
    action = llm.decide(context, goal)
    result = deterministic_execute(action)
    memory.store(action, result)
    if validation_passed(result):
        break
    elif should_escalate(result):
        human_intervention(action, result)

这个伪代码清晰展示了Loop Engineering的核心哲学——真正的Agent系统，本质上是由确定性软件构成、在关键节点穿插LLM决策的系统。这一观点与 HumanLayer 创始人 Dex Horthy 在2025年提出的 "12-Factor Agents" 原则高度一致：可靠Agent的核心是确定性控制流，LLM仅在需要语义理解或判断的节点介入。

3.2 为什么 Loop Engineering 是质变而非量变？

回顾软件工程的历次范式转移，每一次质变都伴随着"人-机分工界面"的根本性重新定义：

• 汇编语言 → 高级语言：人机界面从"机器指令"变为"人为抽象"
• 手动编译 → 自动化构建：人机界面从"人发编译命令"变为"系统自动触发"
• 瀑布模型 → DevOps CI/CD：人机界面从"人提交代码等待部署"变为"合并代码自动上线"
• 人工提示 → Loop Engineering：人机界面从"人给AI下指令"变为"人定义目标，系统自主迭代"

每一次质变都有一个共同特征：人类向更高抽象层次迁移，系统接管更低层次的执行细节。Loop Engineering 正是这一趋势在AI时代的新篇章。

四、产业实践与落地形态

4.1 平台层：谁在做 Loop 基础设施？

虽然 "Loop Engineering" 这一术语在2026年6月才被正式定义，但类似的工程实践已经在多个产品和平台中以不同形式存在：

Cursor Automations 是最早将"自驱动Agent循环"产品化的尝试之一。用户设定条件（如"每天早上检查待重构代码"），Cursor会在后台自动创建Agent会话、执行任务、产出结果。

GitHub Copilot Workspace 引入了"Plan and Execute"模式：开发者提出需求后，Copilot 自主完成理解→规划→实现→验证的全流程，无需逐步提示。

Devin 和 OpenHands（现OpenCode） 从设计之初就采取了"自驱动Agent"架构：接收任务→自主分解→持续执行→交付成果的完整闭环。

Self-Driving Infrastructure 是 DevOps 领域的 Loop 形态——从Datadog的异常检测到PagerDuty的响应编排再到自动Runbook执行的完整自治链路。

4.2 工程实践：一个真实的 Loop 是什么样的？

以一个真实的"自动化代码审查与修复"Loop为例，展示循环工程的实际运作：

阶段一（设计阶段，约2小时）：团队设计Loop的配置——定义目标（保持代码质量分数≥90分）、配置触发机制（每次PR创建+每日定时扫描）、设置验证标准（测试通过率100%、安全扫描零高危漏洞）、定义子Agent分工（审查Agent+修复Agent+验证Agent）、配置通知规则（仅阻塞时人工介入）。

阶段二（运行阶段，持续自动）：PR提交触发GitHub Actions→审查Agent分析变更并生成报告→发现问题后修复Agent自动修正→验证Agent运行测试和扫描→全部通过则Loop退出，结果推送给开发者→发现问题无法自动修复时，Block PR并通知人类开发者介入。

阶段三（进化阶段，按周迭代）：每周审查Loop的运行统计——触发了多少次、自动修复了多少问题、人工介入率趋势、误报率→根据数据调整Loop的验证标准和修复策略→更新项目SKILL.md和记忆层。

一个运行成熟的Loop，人工介入率通常低于15%，且集中在真正的架构决策和模糊需求澄清上。

五、深层启示：Loop Engineering 的未来

5.1 从"组装代码"到"组装能力"

Loop Engineering 的终极愿景，是让开发者像组装硬件一样"组装AI能力"。不再写函数声明，而是声明意图；不再追踪每一行代码执行，而是定义验收标准；不再手动处理每个边界条件，而是让系统在循环中自己发现并修复。

这种转变并不意味着程序员会被替代——而是程序员的定义本身被重新书写。"好程序员"的评价标准正在从"能快速写出正确代码"转变为"能设计出高效、可靠、自适应的AI循环系统"。

5.2 Context Engineering 的下一步

Loop Engineering 是 Context Engineering（上下文工程）概念的工程化延伸。如果说 Context Engineering 关注的是"如何为AI提供正确的上下文以做出正确决策"，那么 Loop Engineering 追问的是"如何让整个上下文管理流程自动化且持续运转"。

这构成了AI原生软件开发的三个能力层次：

• Context Engineering（基础层）：确保每次AI调用获得正确信息
• Agent Orchestration（中间层）：使多个Agent协同完成复杂任务
• Loop Engineering（顶层）：使整个Agent系统自我驱动、自我改进、持续交付

5.3 安全与治理的新挑战

当AI不再是"被操控的工具"而是"自主运转的系统"时，安全治理的复杂度提升了一个数量级。谁来保证Loop的终止条件是正确的？如何防止Loop陷入无效循环（类似传统程序中的死循环）？Loop的"决策日志"是否足够透明以供审计？这些问题的答案正在催生一门新的工程学科——Loop Governance（循环治理）。

六、核心洞察

Loop Engineering 并非某种特定工具或框架，而是对AI时代软件工程本质的重新理解。它揭示了一个深刻的趋势：软件的价值正在从"代码本身"迁移到"生成和维护代码的循环系统本身"。

当 Peter Steinberger 说"你不应该再提示编码Agent了"时，他并不是在否定人机交互的价值，而是在指出——真正有价值的人机交互不再是微观层面的"告诉AI每一步怎么做"，而是宏观层面的"定义系统应该达成的目标、设计验证机制、配置修正策略、建立记忆延续"。

从手动驾驶到定速巡航，从定速巡航到自适应巡航，再到真正的自动驾驶——软件开发的自动化正在沿着同一轨迹加速演进。Loop Engineering 让我们看到了这个演进方向的最终形态：开发者不再开车，而是设计交通系统。

*文章来源：ybb.press | AI技术频道*