深度科普 | 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 在什么样的环境里干活？运行环境：工具集、权限、沙箱、反馈2025**Loop 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 用 /loop 做定时循环，用 /goal 做"目标达成即停止"。OpenAI Codex 则提供了可视化配置面板。没有自动化调度，Loop 就退化成了需要人按按钮的 Harness------那还不如直接用。
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 时代（现在大多数人在做的事）：
- 工程师早上打开电脑，看到昨晚 CI 挂了
- 逐条查看失败日志，定位问题
- 手动修复代码，跑本地测试
- 提交 PR，关联 issue
- 在群里喊同事 review
- 整个过程耗时半天起步，且全部人工驱动
📌 Loop 时代（正在发生的事）：
- 每天早8点，自动化调度自动触发
- 系统读取状态文件，梳理待修复清单
- 为每个报错创建隔离工作区（互不干扰）
- 排查 Agent 分析日志 → 修复 Agent 改代码 → 评审 Agent 审查
- 连接器自动创建 PR、关联工单、推送通知
- 状态文件更新，等下一轮
- 工程师上班看到的是一组已创建好的 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 的那一刻，也许日后会被视为一个标志性瞬间。不是因为一个人做了戏剧化的选择，而是因为背后的逻辑正在成为共识：人不再是循环的一部分，而是循环的设计者。
至于我们会不会因此变成一群不理解自己代码的人------这个问题的答案不在工具里，在每个坐到循环外面的工程师自己手上。