深度科普 | 2026年6月16日 | 阅读约 12 分钟2025年11月有个人干了一件让整个技术圈炸锅的事——他把电脑上的代码编辑器删了。这个人叫 Boris ChernyAnthropic 的工程负责人Claude Code 的缔造者。他不是换工具也不是硬盘满了他是真的觉得不需要了。接下来一个月他提交了259个 Pull Request每一行代码都是 Claude Code 自己写的。到了2026年3月Claude Code 已经实现了100%由自己编写——一个程序完成了对自身的递归式创造。但真正让我反复咀嚼的是他在 Anthropic 开发者大会上说的一句话我不再向 Claude 发送提示词了。我写循环让循环去提示 Claude。我的工作变成了设计循环。 —— Boris ChernyClaude 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 内部的每一次调用仍然依赖好的 promptprompt 写得烂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 是让意图不再反复花钱的地方。没有 skillloop 每轮都从零推导项目有了 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 的那一刻也许日后会被视为一个标志性瞬间。不是因为一个人做了戏剧化的选择而是因为背后的逻辑正在成为共识人不再是循环的一部分而是循环的设计者。至于我们会不会因此变成一群不理解自己代码的人——这个问题的答案不在工具里在每个坐到循环外面的工程师自己手上。