Loop Engineering 正在重新定义"程序员"这个职业

深度科普 | 2026年6月16日 | 阅读约 12 分钟

2025年11月，有个人干了一件让整个技术圈炸锅的事——他把电脑上的代码编辑器删了。

这个人叫 Boris Cherny，Anthropic 的工程负责人，Claude Code 的缔造者。他不是换工具，也不是硬盘满了，他是真的觉得不需要了。接下来一个月，他提交了259个 Pull Request，每一行代码都是 Claude Code 自己写的。到了2026年3月，Claude Code 已经实现了100%由自己编写——一个程序完成了对自身的递归式创造。

但真正让我反复咀嚼的，是他在 Anthropic 开发者大会上说的一句话：

"我不再向 Claude 发送提示词了。我写循环，让循环去提示 Claude。我的工作变成了设计循环。" —— Boris Cherny，Claude Code 创造者

几乎同一时间，OpenClaw 的创造者、后来加入 OpenAI 的 Peter Steinberger 在社交媒体上发帖："你不应该再手动提示编程代理了。你应该设计循环，让循环去提示你的代理。" 一周内520万次浏览。

两家竞争公司，同一个判断。Google 工程师 Addy Osmani 给这个新范式起了个名字——Loop Engineering（循环工程）。

今天这篇文章，我想把这件事讲透。不是因为这是个热词，而是因为它标记了一条分界线：在这条线的一侧，人是操作者；在另一侧，人是设计者。

先搞清楚：Loop Engineering 到底是什么？

用大白话讲就是——以前是你一遍遍地给 AI 下指令，现在你设计一套系统，让这套系统自己去给 AI 下指令、检查结果、决定下一步做什么。

一句话定义： Loop Engineering 是把"那个不停 prompt AI 的人"，换成"一个不停 prompt AI 的系统"，而你的角色从操作者变成了设计者。

注意这里的关键区别——它不是简单的定时任务（比如每天早上跑个脚本）。定时任务只知道"到点了该干活了"，不知道活干得怎么样、要不要再来一轮。Loop 有明确的终止条件："把所有 CI 报错修完"、"测试覆盖率提到90%"、"清理所有已关闭但未归档的工单"。系统持续运转，直到条件达成，或者遇到必须人工介入的情况才停下来。

打个生活化的比方：Harness 时代的你就像一个手工作坊的老师傅，每件产品都亲自上手、亲自验收；Loop 时代的你则像工厂的设计师，你设计好生产线、质量标准和异常处理流程，然后看着机器自己跑起来。

四级台阶：我们是怎么走到这一步的？

要理解 Loop Engineering 的位置，需要先看清它脚下的三级台阶。这不是什么新鲜概念堆砌，而是过去四年里整个行业一步步踩出来的路：

层级解决的核心问题你优化的对象年份Prompt Engineering 提示词工程怎么向 AI 提一个好问题？单条指令的措辞和结构2022Context Engineering 上下文工程AI 的"视野"够不够宽？喂给 AI 的信息：文档、历史、环境2024Harness Engineering 容器工程AI 在什么样的环境里干活？运行环境：工具集、权限、沙箱、反馈2025Loop Engineering 循环工程 ⭐谁来决定什么时候干什么？自主运行的系统设计和终止条件2026

这四层的关系很关键——它们不是互相替代的，而是一层层叠上去的。

Prompt Engineering 不会消失。一个 loop 内部的每一次调用仍然依赖好的 prompt，prompt 写得烂，loop 只会更快地产出垃圾。

Context Engineering 也不会消失。loop 每一轮执行仍然需要把正确的文件、历史记录、工具定义摆到模型面前。

Harness 更没有过时——每一个在 loop 里跑的 agent，仍然需要一个完整的运行环境。Loop 叠在 Harness 之上，就像操作系统叠在硬件之上一样。Harness 是工人的身体，Loop 是工厂的大脑。

唯一改变的是杠杆点的位置：从优化单条指令的质量，移到了优化"生成指令并校验结果"的系统。

为什么 Harness 不够用？三个真实的痛点

你可能想问：现在的 AI 编程助手已经很好用了啊，为什么要搞这么复杂的东西？

原因很简单——Harness 遇到了三个结构性的天花板，在实际工程中反复碰壁：

痛点一：你是唯一的调度瓶颈

Harness 架构下，每一项任务都要你手动触发、输入指令、判定结果。你就是整个系统的调度中枢。 Cherny 曾经一天合并150个 PR，如果每个都要他手动启动和审查，一天24小时根本不够用。这不是效率问题，这是人的认知带宽有上限的问题。

痛点二：并行就是灾难

一个 Harness 只管一个 Agent。当你同时处理十个 bug 修复、三个功能开发时，多个 Agent 在同一个仓库里操作同一批文件——文件覆盖、分支冲突几乎不可避免。Steinberger 日常同时跑 5~10 个编程代理，没有隔离机制的话，合并阶段就是车祸现场。

痛点三：每次都失忆

这是最让人崩溃的。每次会话结束，Agent 就忘得一干二净。下次启动同一个任务，你得从头讲解项目背景、编码规范、历史踩坑记录。这不只是浪费时间——反复灌输的过程中，遗漏和偏差不断累积，模型出错的概率越来越高。

本质问题： Harness 是一个"能干活但不会自己找活干的工人"。它有手有脚，但没有日程表，没有同事，也没有长期记忆。小任务还行，一旦场景变复杂、周期变长，瓶颈就会被持续放大。

六个齿轮：一个真正能自己跑的 Loop 长什么样？

好了，理论讲够了。一个能无人值守运行的 Loop 到底需要什么东西？答案是六个核心组件，缺一不可。我用最通俗的方式逐个拆解：

1️⃣ 自动化调度 —— Loop 的心跳

这是让 Loop 真正"活"起来的东西。它决定什么时候启动一轮新的执行：

• 时间触发： 每天早8点扫描昨天的 CI 失败
• 事件触发： 有人提了新 issue、CI 构建挂了
• 状态触发： 某个任务标记为完成后启动下一个

Claude Code 用 做定时循环，用 做"目标达成即停止"。OpenAI Codex 则提供了可视化配置面板。没有自动化调度，Loop 就退化成了需要人按按钮的 Harness——那还不如直接用。

/loop

/goal

2️⃣ 隔离工作区 —— 并行的防火墙

基于 Git Worktree 技术，给每个 Agent 一个独立的工作目录和分支。所有实例共享仓库历史，但各自改各自的文件，物理上互不干扰。这就是 Steinberger 能同时跑十几个代理不翻车的底层保障。

没有这一层，并行就是空话。

3️⃣ 外置记忆 —— 最被低估的组件

我个人认为这是整个体系里最容易忽视、却最重要的部分。

AI 模型本质上是无状态的——对话一关就什么都忘了。但 Loop 要跨越多轮、多天甚至数周的执行周期。怎么办？答案朴素到你可能不信：用 Markdown 文件或看板来存状态。

每次循环启动时，Agent 先读状态文件——上次做到了哪、哪些完成了、哪些失败了、下一步该干嘛。这看起来简单到不值一提，但它解决的是一个根本性问题：让无状态的模型在有状态的工程世界里持续运转。

记住这句话： "模型在两次运行之间会忘掉一切，所以状态必须落在磁盘上，而不是上下文窗口里。Agent 会忘，仓库不会。"

4️⃣ 子智能体 —— 让"造"的和"验"的分开

这是 Loop 质量控制的关键防线。

一个 Agent 既写代码又审代码，等于自己批改自己的卷子——太宽容了，疏漏不可避免。Loop 的做法是把职责拆开：执行 Agent 负责写，验证 Agent 负责查。两者甚至可以用不同的模型——执行用快速的轻量模型省成本，验证用更强的模型保质量。

这种"对抗式审查"的架构，是无人值守状态下你能信任输出结果的唯一理由。

5️⃣ 技能库 —— 别每次都重新教

用 SKILL.md 文件把项目知识固化下来：编码规范是什么、构建流程怎么走、哪些坑不能踩。Agent 每次启动自动加载，不用你每次重复灌输。

Skill 是让意图不再反复花钱的地方。 没有 skill，loop 每轮都从零推导项目；有了 skill，知识跨运行复利累积。

6️⃣ 连接器 —— 接入真实世界

只看得见文件系统的 Loop 是个很小的 Loop。通过 MCP 协议连接工单系统、CI/CD 平台、即时通讯工具——让 Loop 不是孤立运行，而是嵌入你现有的研发工作流。这才是"修复 bug 的 Agent"和"CI 一绿就自动开 PR + 关联工单 + 在群里通知一声的 Loop"之间的本质区别。

一个真实的工作流对比

光说概念没感觉，来看一个具体的场景：

假设你们团队每天早上要处理前一晚 CI 构建失败的报错。

Harness 时代（现在大多数人在做的事）：

1. 工程师早上打开电脑，看到昨晚 CI 挂了
2. 逐条查看失败日志，定位问题
3. 手动修复代码，跑本地测试
4. 提交 PR，关联 issue
5. 在群里喊同事 review
6. 整个过程耗时半天起步，且全部人工驱动

Loop 时代（正在发生的事）：

1. 每天早8点，自动化调度自动触发
2. 系统读取状态文件，梳理待修复清单
3. 为每个报错创建隔离工作区（互不干扰）
4. 排查 Agent 分析日志 → 修复 Agent 改代码 → 评审 Agent 审查
5. 连接器自动创建 PR、关联工单、推送通知
6. 状态文件更新，等下一轮
7. 工程师上班看到的是一组已创建好的 PR 和一份摘要，只需做最终复核

日常 80% 的重复性工作被循环吸收了。你的角色从"操作者"变成了"设计者+最终裁判"。

清醒一点：四个真实存在的风险

如果文章到这里结束，那就是一篇吹捧稿了。Loop Engineering 的落地远没有听起来那么干净，有几个风险每一个实践者都必须正视：

⚠️ Token 成本可能失控

多 Agent、多轮迭代、全天候运行——Token 消耗可以飙升到你不敢看账单的程度。Steinberger 团队的 Agent 循环，一天的 Token 账单超过两万美元。如果不设置轮次上限、优先级策略和成本监控，Loop 会变成一台精密的烧钱机器。

建议：先用慢节奏+紧目标起步，观察几天成本，确认真的产出有价值的结果再放大。

⚠️ 输出质量可能悄悄下降

行业内有个词叫 "Slop"——指 AI 敷衍产出、跳过边缘场景、生成"能跑但不够好"的代码。在无人值守状态下，这个问题会被放大。Agent 可能走捷径、简化测试、忽略异常路径。多层级校验子智能体 + 保留人工终审，是目前的主要应对手段。

⚠️ 认知负债：最隐蔽的风险

这是我个人的判断——这也是最容易被忽视的风险。

当 Loop 持续自动产出代码，如果你长期不亲自读这些代码，你会逐渐丧失对项目逻辑的真实理解力。代码能跑、测试能过、PR 能合——但没有人真正知道为什么这样写。这种隐性的理解力流失，在系统出现超出 Loop 处理能力的复杂故障时，会变成致命的技术债。

"Loop 分不清'用它加速深刻理解的工作'和'用它逃避理解工作'这两种情况。但你分得清。"

⚠️ 设计门槛比你想的高得多

设计一个好的 Loop，比写一条好的 prompt 难至少一个数量级。你需要同时具备系统架构能力、工作流编排经验、边界管控意识和风险防控思维。终止条件设得太松 → 循环空转烧钱；设得太紧 → 有效任务被提前中断。这种平衡感只能靠大量实践打磨。

核心观点： 两个人搭出一模一样的 Loop，可以得到完全相反的结果——一个用它在自己深刻理解的工作上跑得更快，另一个用它来逃避思考。同一个动作，相反的结局。Loop 工具本身分不清这两者，只有你自己分得清。

我的判断：方向不可逆，但节奏很重要

写到这，我想说几句自己的判断。

首先，这不是"程序员要完蛋了"的故事。Cherny 自己说得很清楚——"杰出的工程师比以往任何时候都重要"。总得有人决定做什么、跟客户沟通需求、协调优先级、判断哪个 Loop 值得设计。工作没有消失，只是升了一个海拔：从写代码，变成写"那个写代码的东西"。

其次，前三级台阶没有任何一个被"废弃"。好的 prompt 仍然是 Loop 内部每一次调用的基础；精准的上下文决定了 Agent 的视野；稳固的 Harness 是每个 Agent 的运行底座。Loop 不是推翻前面所有东西，而是站在它们之上。

第三，两大主流工具 Claude Code 和 OpenAI Codex 已经在产品层面收敛出了几乎相同的组件形态。底层架构趋同意味着——你设计的 Loop 可以跨工具复用。基础设施不再是瓶颈，真正的瓶颈是你是否愿意走下驾驶座。

最后，也是最重要的一点：

"搭 Loop，但要像一个打算继续当工程师的人那样搭它。"

Cherny 删 IDE 的那一刻，也许日后会被视为一个标志性瞬间。不是因为一个人做了戏剧化的选择，而是因为背后的逻辑正在成为共识：人不再是循环的一部分，而是循环的设计者。

至于我们会不会因此变成一群不理解自己代码的人——这个问题的答案不在工具里，在每个坐到循环外面的工程师自己手上。