当Claude Code的创造者删掉自己的IDE，让AI完全接管代码编写时，一个名为Loop Engineering的新范式正在成型。从Prompt Engineering到Context Engineering，再到Harness Engineering，AI编程经历了三次迭代后，终于迎来了人机协作的终极形态——工程师不再是循环的一部分，而是站在循环之外的设计者。本文将深入解析Loop Engineering的六大核心组件，揭示它是如何实现代码的自我演化，并探讨这一范式转移背后的人力依赖、并行缺失、记忆断裂等根本性问题。

2025年11月的某一天，Boris Cherny把电脑上的IDE删了。不是因为硬盘满了，也不是换了新工具。他是Claude Code的创造者，Anthropic的工程负责人，而他决定自己不再需要一个代码编辑器了。

接下来的一个月里，他提交了259个Pull Request，每一行代码都由Claude Code自己写成。到了2026年3月，他宣布Claude Code已经100%由Claude Code自身编写。一个程序完成了对自身的递归式创造。这个场景在两年前还属于科幻小说的范畴。

但真正让我停下来反复咀嚼的，不是这些数字，而是他在Anthropic年度开发者大会上说的一句话：”我不再向Claude发送提示词了。我写循环，让循环去提示Claude。我的工作变成了设计循环。”

差不多同一时间，OpenClaw的创造者、后来加入OpenAI的奥地利工程师Peter Steinberger在社交媒体上发了一条帖子，一周内获得了520万次浏览：”你不应该再手动提示编程代理了。你应该设计循环，让循环去提示你的代理。”

两个人，两家竞争公司，同一个判断。当行业最顶尖的实践者同时指向同一个方向时，通常不是巧合，而是一个范式正在凝固。

这个范式有了名字：Loop Engineering，循环工程。Google工程师Addy Osmani在2026年6月的一篇长文中正式定义了它。但它的根系早已在过去一年的工程实践中生长。我试图在这篇文章里把它讲透。不是因为它是一个新词，而是因为它标记了一条分界线。在这条线的一侧，人是操作者；在另一侧，人是设计者。

四级台阶：从手动提示到系统自治

要理解Loop Engineering的位置，需要先看清它脚下的三级台阶。

第一级是Prompt Engineering，提示词工程。2022年ChatGPT出圈后的头号显学，核心问题是”如何向AI提一个好问题”。工程师的工作是打磨指令的措辞、结构和语气，让模型输出更精准的答案。这一层解决的是人机沟通的效率问题。

第二级是Context Engineering，上下文工程。当任务变得复杂，一条提示词已经不够用。工程师需要决定”喂给AI哪些信息”。把项目文档、代码库、历史对话、环境变量组织起来，塞进模型的上下文窗口。Andrej Karpathy等人推动了这个概念的普及。这一层解决的是AI的”视野”问题。

第三级是Harness Engineering，智能体容器工程。单纯有好的提示和上下文还不够，智能体需要一个完整的运行环境：工具集（文件读写、命令行、测试框架）、权限边界、安全沙箱、反馈机制、异常处理。Martin Fowler网站上Birgitta Böckeler的长文系统阐述了这一层。行业形成了一个简洁的等式：Agent = 大模型 + Harness。这一层解决的是”AI在什么环境下干活”的问题。

这三级台阶各有价值，但它们共享一个前提：人是驱动者。每一轮任务都由人发起，每一个结果都由人判读，每一次迭代都由人触发。工程师坐在方向盘后面，全程手动驾驶。

Loop Engineering是第四级台阶。它跨过了一条线：人不再坐在方向盘后面了。人设计自动驾驶系统，然后走下驾驶座。

Harness的天花板：一个能干活的孤儿

为什么Harness不够？因为它有三个结构性瓶颈，在工程实践中会反复碰壁。

第一个瓶颈是人力依赖。Harness架构下，每一项任务都需要手动触发、手动输入指令、人工判定结果。工程师是唯一的调度中枢。当任务数量超过一个人的认知带宽，整个系统就会堵塞。Cherny曾经一天合并150个PR，如果每个PR都要他手动启动和审查，一天24小时也不够用。

第二个瓶颈是并行缺失。一个Harness只管一个Agent。当你需要同时处理十个bug修复、三个功能开发、两个代码审查时，多个Agent在同一个代码仓库里同时操作，文件覆盖和分支冲突几乎不可避免。Steinberger日常同时跑5到10个编程代理，如果没有并行隔离机制，产出的代码会在合并阶段变成灾难。

第三个瓶颈是记忆断裂。每次会话结束，Agent就失忆了。下次启动同一个任务，你得从头讲解项目背景、编码规范、历史踩坑记录。这不只是效率问题。反复重新灌输信息的过程中，遗漏和偏差会不断累积，模型幻觉的概率随之上升。

概括起来，Harness是一个”能干活但不会自己找活干的工人”。它有手有脚，但没有日程表，没有同事，也没有长期记忆。在小规模、短周期的任务上，它表现良好。一旦工程场景变成周期长、链路复杂、多任务并行，Harness的瓶颈就会被持续放大。

行业开始意识到一件事：我们缺的不是一个更好的运行环境，而是一套能自己运转的系统。

Loop Engineering：让系统提示自己

Addy Osmani给出的定义足够精确：”Loop Engineering是把你自己替换掉。你不再是那个提示代理的人，你设计一个系统来做这件事。一个循环可以理解为一个递归目标：你定义目的，AI持续迭代，直到完成。”

我把这个定义拆开来看。

“递归目标”是第一个关键词。Loop不是定时任务（Cron）。Cron只负责在固定时间点触发一个动作，它不知道任务做到了什么程度，不判断结果的质量，也不决定是否需要再来一轮。Loop的逻辑完全不同：它有明确的终止条件。修复所有CI报错、将测试覆盖率提升到90%、清理所有已关闭但未归档的工单。系统持续运行，直到条件被满足或触发人工介入的阈值。

“替换你自己”是第二个关键词。不是替换你的判断力，而是替换你在循环中的位置。在Harness时代，你是循环的一部分，每一轮都经过你的手。在Loop时代，你是循环的设计者，站在循环之外观察和调优。Cherny的原话更直接：”你不应该提示Claude。你应该构建一个能自己提示自己的系统。”

Loop和Harness的关系不是替代，是层叠。每一个Loop内部运行的Agent，仍然各自拥有独立的Harness环境，继承其工具、权限和反馈能力。Harness管的是”单个Agent如何执行任务”，Loop管的是”多Agent执行什么任务、何时执行、如何协作、什么时候停下来”。打个不太恰当的比方：Harness是工人的身体，Loop是工厂的大脑。没有身体，大脑无处落地；没有大脑，身体只能等着别人下达指令。

六个齿轮：Loop如何运转

一个能真正无人值守运行的Loop，需要六个核心组件协同工作。我不打算逐个展开全部细节，但会挑出其中最关键的几个说透。

自动化调度是循环的心跳。它决定什么时候启动一轮新的执行。触发源可以是时间（每天早八点）、事件（CI构建失败、新工单被创建）、或状态变化（某个任务标记为完成）。没有自动化调度，Loop就退化成了需要人手动启动的Harness。Claude Code用/loop命令实现定时循环、用/goal命令实现”目标达成即停止”。OpenAI的Codex则提供了独立的Automations面板，可视化配置规则。

隔离工作区是并行运行的防火墙。基于Git Worktree技术，为每一个运行中的Agent创建独立的工作目录和分支。所有实例共享代码仓库的历史，但文件编辑和提交互不干扰。任务结束后，成果可以无缝合并回主分支，临时工作区自动清理。这是Steinberger能同时跑十几个代理而不翻车的底层保障。没有这一层，并行就是一句空话。

外置记忆是我认为整个Loop体系中最容易被低估的组件。会话级别的记忆随对话窗口关闭而消失，但Loop需要跨越多轮、多天甚至多周的执行周期。解决方案并不花哨：用Markdown文件、JSON文件、项目看板或数据库来存储已完成的工作、待办事项、执行结果和进度状态。这些文件独立于会话之外，永久留存在代码仓库或本地文件系统中。每次循环启动时，Agent首先读取状态文件，知道自己上次做到了哪里，这次该从哪里继续。

这个设计看起来朴素到有些平庸，但它解决的是一个根本性问题：让无状态的模型在有状态的工程世界里持续运转。没有外置记忆，长周期的自治循环根本不可能成立。

子智能体实现了写和审的分离。一个Agent既写代码又审代码，等于自己批改自己的试卷，疏漏难以避免。Loop体系把职责拆开：执行Agent负责编写和修改代码，验证Agent负责运行测试、校验规范、检查边界情况。两者独立运行，甚至可以使用不同的模型。执行任务选用快速的轻量模型压缩成本，验证任务选用精度更高的模型保障质量。这种”对抗式审查”的架构，是无人值守状态下质量控制的关键防线。

其余两个组件我简要带过。技能库（Skills）是项目知识的沉淀载体，用SKILL.md文件固化编码规范、构建流程、历史经验，Agent每次启动自动加载，解决反复灌输的效率损耗。连接器（Plugins & Connectors）通过MCP协议对接工单系统、CI/CD平台、即时通讯工具，让Loop不是孤立运行，而是嵌入现有研发工作流。

六个组件，缺一不可。但真正决定一个Loop好坏的，不是组件的齐全程度，而是终止条件的设计。什么时候循环应该停下来，什么情况下必须把控制权交还给人。这才是Loop工程师最核心的设计功力。

范式变了，人的位置在哪里

让我从一个具体的场景说起。

假设一个团队每天早上需要处理前一晚CI构建失败的报错。在Harness时代，工程师的一天从打开失败日志开始：逐条查看报错信息、定位代码问题、修复、跑测试、提交PR、关联工单、通知同事。一个普通的CI修复周期可能耗费半天。

在Loop时代，同样的工作流变成了这样：每天早8点，自动化调度触发任务。系统读取状态文件，梳理出待修复的CI报错清单。为每个报错创建独立的隔离工作区。排查Agent解析日志、定位根因。修复Agent改代码、跑本地测试。评审Agent对照项目规范做代码审查、执行全量测试。通过后，连接器自动创建PR、关联工单、向团队推送通知。最后，状态文件更新，记录执行结果，等待下一轮。

工程师上班打开电脑时，看到的是一组已经创建好的PR和一份执行摘要。他只需要做最终的人工复核。日常80%的重复性工作被循环吸收了。

范式变迁的具体含义就在这里。工程师从”操作者”变成了”设计者”。执行模式从”单次串行”变成了”持续并行”。知识管理从”每次重复灌输”变成了”一次沉淀、持续复用”。质量保障从”人工全审”变成了”系统自验加人工终审”。

我需要在这里加一句直言：这不是工程师被取代的故事。Cherny自己说得很清楚，”杰出的工程师比以往任何时候都重要。”有人仍然要决定造什么、跟客户沟通需求、协调团队优先级、判断哪些循环值得设计。工作没有消失，只是升了一个海拔。从写代码，到写那个写代码的东西。

清醒的代价：四个不能回避的风险

如果文章到这里结束，它就只是一篇布道稿。但Loop Engineering的落地远没有概念那么干净，有四个真实的风险需要每一个实践者正视。

Token成本的失控。 多Agent、多轮迭代、全天候运行，Token消耗量可以飙升到超出直觉的程度。Steinberger曾经晒出一张截图：他所在团队的Agent循环，一天的Token账单超过两万美元。如果不设置轮次上限、优先级策略和成本监控，Loop会变成一台精密的烧钱机器。

输出质量的退化。 行业内把AI敷衍产出、跳过边缘场景、生成低质量代码的现象叫做Slop。在无人值守状态下，这个问题会被放大。Agent可能走捷径、简化测试、忽略异常路径。严格的技能库、多层级校验子智能体和保留人工终审环节，是目前的主要应对手段，但它们增加了系统复杂度和成本。

认知负债的累积。 这是我个人认为最容易被忽视的风险。当循环持续自动产出代码，工程师如果长期不亲自阅读和理解这些代码，会逐渐丧失对项目逻辑的掌控力。代码能跑、测试能过、PR能合，但没有人真正理解它为什么这样写。这种隐性的理解力流失，在系统出现超出循环处理能力的复杂故障时，会变成致命的技术债。

设计门槛的陡增。 Loop工程的复杂度远超写一条好的提示词。设计者需要同时具备系统架构、工作流编排、边界管控、风险防控的综合能力。终止条件设得太松，循环空转烧钱；设得太紧，有效任务被提前中断。这种平衡感不是读一篇文章就能获得的，需要大量的工程实践打磨。

回到那个删掉IDE的人

2026年6月7日，Steinberger在社交媒体上发帖：”这是你每月一次的提醒。你不应该再手动提示编程代理了。”帖子底下，认同和反对几乎对半分。有人激动地分享自己的Loop实践成果，也有人愤怒地说这会制造一代不理解自己代码的工程师。

两边都有道理。但争论本身说明了一件事：这条分界线已经出现了。

在分界线的一侧，Prompt Engineering、Context Engineering、Harness Engineering仍然有各自的适用场景，没有任何一个被”废弃”。好的提示词仍然是Loop内部每一轮调用的基础。精准的上下文仍然决定了Agent每一步的视野。稳固的Harness仍然是每一个Agent的运行底座。Loop不是推翻前三级台阶，而是站在它们之上。

在分界线的另一侧，一种新的工作方式正在快速凝固。两大主流工具（Claude Code和OpenAI Codex）已经在产品层面收敛出了几乎相同的组件形态：自动化调度、隔离工作区、技能库、连接器、子智能体、外置记忆。底层架构走向统一，一套循环设计可以跨工具复用。基础设施不再是瓶颈，瓶颈是工程师是否愿意走下驾驶座。

Cherny删掉IDE的那个十一月，也许日后会被视为一个标志性的时刻。不是因为一个人做了一个戏剧化的选择，而是因为那个选择背后的逻辑正在成为整个行业的共识：人不再是循环的一部分，而是循环的设计者。这条路上的风险真实存在，收益也真实存在。但方向已经不太会逆转了。

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