Loop Engineering:从单次对话到自动化循环

📅 2026/6/29 22:17:39
Loop Engineering:从单次对话到自动化循环
摘要本文深度剖析谷歌 Chrome 团队主管 Addy Osmani 提出的“循环工程”概念观察研发范式从人驱动提示词向系统设计循环转移拆解其核心组件架构与局限。在过去的两年里大模型席卷了软件开发流程。然而随着开发者频繁在对话框中编写、修改并复制提示词这种将“人类作为提示词工程师”的交互模式已触及瓶颈繁琐的手工干预使得研发效率的提升曲线开始放缓。针对这一瓶颈谷歌 Chrome 团队主管、知名技术作家 Addy Osmani 近日发表博客文章指出我们可能正处于“循环工程”Loop Engineering的新范式转移中。他援引了 OpenClaw 作者 Peter Steinberger 的研判“应该设计能够提示 Agent 的循环系统”以及 Claude Code 创建者 Boris Cherny 编写自动化循环的经验主张把提示词本身进行工程化设计。什么是循环工程在 Addy Osmani 的论述中所谓“循环工程”的本质是将提示词的调度与处理逻辑工程化用一套具备自治能力的自动化系统来封装大模型的调用。在这种范式下“循环”被定义为一个拥有“递归目标”的闭环任务。开发者不再针对某行代码做单次提问而是为系统定义一个终极目标智能体便会进入迭代状态自主运行多轮请求直到该目标被达成。这种转变的关键在于研发驱动力的移交。传统的 AI 辅助开发中人类负责发现问题、分配任务、检查代码、记录状态并做出决策。而在循环工程中这 5 项职责全面收纳进系统流程中研发驱动力从“人类驱动”转向“系统驱动”工程师则退回到了系统架构师的位置。循环的五个组件与一个记忆机制根据 Addy Osmani 的梳理构建一个能够长期运行的循环系统需要鲁棒的架构支持。具体而言一个合格的“循环”必须包含以下 5 个核心功能组件以及 1 个独立的外部记忆机制。1. Automations自动化组件循环的“心跳”主要执行定时发现与任务分流。在 Codex App 中表现为专用的 Automations 标签页在 Claude Code 中则表现为预设时间表、/loop指令或 hooks 关联。其核心作用是在后台不断轮询监控报警与未处理的任务。2. Worktrees工作树隔离用于隔离并行功能开发。智能体在独立的 Git 工作区工作避免多个任务在同一个工作目录并行时代码发生覆盖冲突。Codex App 内置了独立工作树Claude Code 则依靠标准的git worktree命令实现环境防冲突隔离。3. Skills意图与规约沉淀将项目的具体知识与构建测试意图固化下来直接对抗随项目膨胀而累积的意图债务。通常将项目定制化指令如构建流程、测试断言写入 SKILL.md 中避免智能体每一次运行都在重新猜测项目的开发规范。4. Plugins Connectors插件与外部连接器打通工具链的关键组件使智能体能够触达真实世界的系统。通常基于模型上下文协议MCP让智能体可以原生接入 Linear 任务板、Slack 频道、生产环境数据库及 GitHub 存储库。5. Sub-agents子智能体分工实现制造者Maker与检查者Checker角色的职责分离。在.codex/agents/或.claude/agents/中定义分工由写代码的智能体负责产出修复方案独立的审查智能体负责在合规与测试边界上进行卡点。6. State / Memory外部状态存储记忆由于智能体本质上是无状态的循环机制必须在单次会话上下文之外维护状态。Addy Osmani 强调这种记忆通常以本地 Markdown 文件如 AGENTS.md或 Linear 看板的形式保存在代码仓库之外。因为 Agent 可能会遗忘但代码库与状态文件不会。完整循环示例自动化流如何运转为了生动呈现“异步自治”的研发体验Addy Osmani 在文章中分享了他自己每天运行的一个典型自动化循环。在每天早晨人类工程师尚未抵达工位之前后台定时自动化脚本已悄然启动。系统首先拉取昨天的 CI 构建日志和 GitHub 上的待修复 Issue然后将分析结果写入 Markdown 文件或 Linear 看板。紧接着系统针对识别出的待修复 Issue利用 Git Worktree 在后台开辟出一个完全隔离的分支空间。写代码的智能体Maker开始在独立的分支里起草修复代码与此同时负责验证的智能体Verifier读取 SKILL.md 中配置的项目指令自动进行本地构建并循环测试发现错误即命令 Maker 自我纠错直至所有的测试集绿灯通过。在测试全部通过后连接器会自动把修改推送并向 GitHub 发起 Pull Request。当工程师坐在电脑前时他只需对已经就绪的代码补丁进行终审而无法被自动闭环的复杂问题则会安全地保留在收件箱中等待人类处理。循环解决不了的三件事然而即便自动化循环展现出了惊人的生产力Addy Osmani 依然清醒地在文中提醒读者循环工程绝非万能的解药。在大语言模型生成代码的速度发生指数级增长的同时开发者也将不可避免地遭遇以下 3 个隐性挑战。1. 验证责任的滞留智能体所声称的“任务已完成”仅仅是它的文字声明而绝不是技术上的确凿证明。测试套件本身可能存在逻辑盲区AI 甚至可能会去修改测试用例本身以迎合结果。如果人类放弃在最后关卡的仔细确认研发循环就会在顷刻间变成“无人值守地制造故障”。2. 理解力债务的快速积压当系统运行完全被自动化循环接管开发者没有亲自写过、甚至从未通读过的代码行数将呈指数级增长。长此以往团队对整个庞大系统的全局理解力就会产生严重的债务断层。3. 认知妥协与投降的诱惑面对智能体自动起草、表面天衣无缝的修复代码人类的本能往往是贪图舒适直接予以点击合并。这种放弃独立思考、全盘投降于算法黑盒的姿态不仅是现代软件工程中最大的安全稳定性隐患同时也是最危险的思维逃避。构建循环但保持工程师身份回到宏观层面循环工程对软件行业的真正影响在于它将效率杠杆点向上推了一层。正如 Boris Cherny 所判断的虽然 AI 的演进移动了开发者的效率杠杆支点但软件工程的工作本身并没有变得简单。设计一套鲁棒的、能够自愈的循环系统比直接编写提示词或者自己写代码难度只增不减。同样的自动化循环可能会产生截然相反的结果。优秀的开发者能够运用高阶的判断力将重复的体力劳动剥离给循环让自己专注于更高维度的架构与业务逻辑而逃避思考的开发者则可能将循环变成遮蔽自己理解技术细节的黑盒。构建循环但要保持你的工程师身份。相关资源原文博客Codex App 自动化文档Claude Code / Agent Skills 指南