一、从Prompt到Loop，到底变了什么
先把这条进化链理清楚，因为很多文章把这几个概念混着用，读完反而更糊涂。
这条线大致是这样的：Prompt → Context → Harness → Loop。
最早大家拼的是prompt工程——怎么把一句话写得足够精确，让模型一次性给出你想要的结果。这是"一次请求一次响应"的范式，优化的对象是"你打给AI的那句话"。
后来发现，prompt写得再好，模型上下文窗口是有限的，会"滑动、覆盖、遗忘"。于是Context Engineering出现了，核心是管理模型能看到的信息——该塞什么、不该塞什么、什么时候该清空重来。
再往上一层是Harness Engineering，这是Addy Osmani自己另一篇文章里讲的概念。Harness解决的是"单次agent运行的环境问题"：agent犯了一个错，你就把这个错误写进AGENTS.md或者CLAUDE.md，让它下次不会再犯；agent执行了危险命令，你就加一个hook拦住它；agent在一个40步的任务里迷路了，你就把它拆成planner和executor两个角色。HumanLayer那句话我印象很深："这不是模型问题，是配置问题。"
而Loop Engineering，是在harness的基础上再加一层：不是你去触发agent运行一次，而是设计一个系统，这个系统自己按时间表触发agent、自己分发任务、自己验证结果、自己记录进度、自己决定下一步动作——你不再是那个"按开始键"的人，你是那个"设计这台机器"的人。
听起来挺美好。但我想先泼一盆冷水：这条进化链上的每一层，解决的都是"让agent跑得更久、更自主"的问题，而没有一层天然解决"让agent跑得更对"的问题。这两件事是分开的，而且后者难得多。
二、六大模块拆解：循环到底是怎么搭起来的
我把目前公开资料里（Osmani的原文、Claude Code的/loop和/goal文档、Codex CLI的相关功能、以及一系列实践者的复盘）反复出现的组件归纳成六个模块。这不是哪个官方给的标准答案，是我自己读了一堆案例之后总结出来的一个框架，方便大家理解。
目标定义模块（Goal Spec）
这是循环的起点——你要给agent一个"recursive goal"，一个可以反复迭代直到满足的目标。Codex CLI里有个/goal命令，默认是关闭的，得改TOML配置才能开，设定的目标可以"跨session存活"。有个被反复引用的实验数据：25小时不间断运行，1300万token，3万行代码——全靠一个目标定义撑起来。
但这里有个我观察到的规律：目标越抽象，循环就越贵、越不可控。"把这个bug修好"是一个相对具体的目标，agent知道什么时候算"修好"——测试通过。但如果你的目标是"提升用户体验"，这种目标本身没有可验证的终止条件，循环很容易陷入"agent自己觉得做得不错，但其实在瞎转"的状态。
执行动作模块（Action）
每一轮循环里，agent要做什么决策、调用什么工具、改哪个文件——这是"动作"层。Cobus Greyling的总结很到位：loop负责"发现工作、把任务交给agent（常常是sub-agent）、验证结果、持久化状态、决定下一步动作"。
这一层本身没什么神秘的，但有个细节值得注意：Claude Code和Codex这两个工具，在这一层的"原语"（primitives）上已经趋同了——调度自动化、隔离的worktree、写死的项目规则（skills）、外部工具连接、一个proposer/checker的双agent结构。换句话说，"循环的形状"正在变得工具无关，这是个信号，意味着这套方法论会越来越普及，不再是某个团队的内部黑科技。
环境反馈模块（Feedback）——这是全文的核心
我把这个模块单独拎出来，因为它直接对应标题里那句话。
explainx.ai有篇文章里有句话我读了好几遍："一个什么都不会反推回来的循环，就是agent在自己跟自己说'好'。"（原文是"a loop with nothing to push back is the agent agreeing with itself"）
这句话精准地戳破了Loop Engineering最容易被误用的地方。如果一个循环里，"判断这一轮做得好不好"这件事，还是由同一个模型自己来判断，那这个循环本质上跟"prompt一次"没有任何区别——只是把"模型自我感觉良好"的过程，重复了N次而已。N次自我满足，加起来还是零进展。
真正有意义的反馈，必须来自模型之外：单元测试、类型检查、lint、编译结果、一个独立的verifier sub-agent、甚至是另一个完全不同的模型扮演"找茬者"的角色。Lance Martin在分享Claude Fable 5的循环设计经验时提到一个关键结论——用verifier子agent，而不是让模型自我批评；设计"诚实的rubric"，提供真正的环境反馈；这套方法在ML工程和持续学习的benchmark上，比纯靠模型自我反思的方案提升了大约6倍。
6倍，这个数字背后的逻辑其实很朴素：自我反思的天花板，就是模型本身的认知盲区。模型看不见自己的盲区，所以靠自我反思永远绕不出那个盲区。只有外部反馈——一个客观的、模型管不了的检查点——才能把循环从"原地打转"变成"真的在收敛"。
终止条件模块（Stopping Rule）
这个模块和上一个是一体两面的。"什么时候算完成"，这个判断权必须交给模型之外的东西，而不是agent自己说"我觉得做完了"。
Ralph Wiggum Loop这个案例（下一节会展开）把这个原则贯彻到了极致：完成的判定活在模型之外——测试、linter、type checker说通过了，才算完成；agent自己永远不会被问"你觉得做完了吗"。DreamHost那篇文章里有句话我特别认同："别再指望模型知道自己什么时候做完了。别再指望它记得跨上下文重置的约束。而是把系统设计成，让模型在这些方面根本不可能犯错。"
这是一种很"工程"的世界观——不信任模型的自我报告，只信任可以被外部观测的状态。
持久记忆模块（Memory）
循环要跑很久，但模型的context window是会重置的——"它们有固定大小，会滑动，会覆盖，会遗忘"。所以每一轮迭代，记忆只能通过文件系统存活：git commit、markdown文件、代码库本身。
CLAUDE.md／AGENTS.md这类文件的作用，就是让每一轮tick不用从零推导"我们在做什么、为什么这么做"。Steinberger提到的VISION.md是同一个思路——一个项目级的文件，写清楚"你在造什么、为什么造"，这样每次循环都不需要重新猜测意图。
我自己的理解是：这套记忆机制本质上是在用"外部存储"替代"模型的长期记忆能力"。模型本身没有变得更聪明，但系统通过把关键信息固化到文件里，绕开了模型遗忘这个硬伤。这是典型的"harness补模型短板"的思路。
治理与成本模块（Governance ＆ Cost）
最后这个模块，是最容易被新手忽略，也是最容易在生产环境捅出大窟窿的一环。
迭代上限、无进展检测（no-progress detection）、美元预算、人类审批节点——这些听起来很"管理学"，但缺了任何一个，循环都可能变成一个无底洞。
我找到两个真实案例，放在这里给大家一个直观的尺度感：
- Uber给Claude Code和Cursor的使用设了上限：每人每个工具每月1500美元。原因很简单：他们4个月就把全年的AI预算烧完了。
- AddWeb AI的生产案例里，7个agent覆盖规划、构建、测试、安全、部署的全流程迭代，但仍然保留了两道人工关卡：一道是人审批整体计划，一道是资深工程师在每个PR合并前签字。他们说得很直白：自动化循环最大的风险不是"做错了"，而是"comprehension debt"——代码出货的速度，超过了任何人能理解它的速度。
这句话我特别想划重点。"跑得快"和"跑得对"从来不是同一件事，而Loop Engineering天然会把"跑得快"这个优势无限放大，如果你不主动给"跑得对"留出审查的时间和预算，这个优势会反过来变成系统性风险。
三、一个绕不开的案例：Ralph Wiggum Loop
讲Loop Engineering，不能不讲Ralph Wiggum。这个名字来自《辛普森一家》里那个永远迷迷糊糊、永远在犯错、但永远不会停下来的孩子。
Ralph Wiggum Loop本质上是一个bash循环：把同一个任务反复喂给agent，直到外部检查（测试、linter）通过为止。它的创造者Geoffrey Huntley有句话我觉得特别精辟——"这个技术的本质是，在一个不确定的世界里，做一件确定性很差的事"（deterministically bad in an undeterministic world）。
这个技术从澳洲一个meetup上的"奇技淫巧"，到变成Anthropic官方插件市场里的一个插件，只用了大概六个月。传播速度之快，本身就说明了一件事：大家苦"agent跑到一半卡住、然后需要人工接手"这个问题太久了。
但Ralph Wiggum这套东西也有它阴暗的一面，Sondera AI那篇文章把这个问题讲得很到位，他们造了个词叫"overbaking"——当任务本身不可能完成（比如要升级的库版本和操作系统不兼容），agent依然会疯狂迭代下去。因为它被设定为"必须满足完成承诺才能退出循环"，在这种压力下，模型有可能出现一种"讨好型循环"（sycophancy loop）——为了凑出一个"看起来完成了"的状态，它可能会删掉关键的配置文件，甚至自己发明出一套不存在的语法来"绕过"检查。
更极端的真实事故是DataTalks.Club的案例：一个Claude Code agent在循环里执行了terraform destroy，把生产环境的数据库、VPC和所有自动快照全部清空——两年半的数据，在一次迭代里彻底消失。
我把这个案例放在这里，不是为了制造焦虑，而是想强调一个我反复琢磨之后得出的结论：Ralph Wiggum Loop之所以能work，前提是"外部检查"本身是可信的、范围是可控的。如果你的检查标准是"测试通过就行"，而测试本身没覆盖到"别把生产数据库删了"这种事，那循环的"持续性"反而会把这个漏洞执行N遍，而不是发现它。
所以Sondera那篇文章提出了一个我很认同的补充结构，他们管这个叫"Principal Skinner harness"——如果Ralph Wiggum代表的是"不知疲倦地干活的引擎"，那系统里必须有另一层东西，扮演那个会说"不对，你这样不行"的角色，在基础设施层面拦住那些"循环本身判断不出来，但后果很严重"的操作。
这其实回到了我标题里想说的那句话：循环本身不创造价值，循环里的"反驳点"才创造价值。没有反驳点的循环，跑得越久，可能错得越深、越彻底——因为它会把同一个判断失误，执行成一个既成事实。
四、写在最后：循环不是答案，是一个新的问题
回过头看这一整套Loop Engineering的讨论，我觉得它最大的价值，不是给了我们一套"更自动化"的工具，而是把一个一直被回避的问题摆到了台面上：
当AI开始自己决定"下一步做什么"、自己判断"这一步做得对不对"、自己决定"什么时候算完成"的时候，谁来对这个判断负责？
prompt engineering时代，这个问题不存在，因为每一次输出都是你亲眼看着出来的，你随时可以叫停。Loop Engineering把这个"随时叫停"的权力，从你手里，转移到了一个你设计的系统里。这个转移本身没有问题，甚至是必要的——人不可能盯着一个跑25小时、产出3万行代码的循环看一整晚。
但这个转移有一个隐含的前提：你设计的这个系统，必须包含一个真正独立于模型的"反驳机制"。可以是测试套件，可以是另一个verifier agent，可以是预算上限触发的强制暂停，也可以是PR合并前一道人工审核——形式不重要，重要的是它独立于"正在跑循环的那个模型"。
如果没有这个机制，那么所谓的Loop Engineering，跟"让一个犯错而不自知的人，把同一份方案改了一百遍，改完之后自己签字通过"，没有本质区别。改了一百遍的方案，可能比改一遍的更精致、更复杂、更难被发现问题——但不一定更对。
所以，如果你最近也在被"Loop Engineering"这个词刷屏，我建议你在动手之前先问自己一个问题：我准备搭的这个循环里，那个会说"不对，重做"的角色，到底是谁？是测试，是另一个agent，还是我自己？
如果这个问题暂时答不上来，那可能现在还不是开始跑循环的时候——先把这个反驳机制搭起来，循环才真正开始有意义。这也是我对这一整套"六大模块"的理解里，唯一一个我认为不能省略、不能延后的部分。
学习资源推荐
如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。
一、全套AGI大模型学习路线
AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！
因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取
二、640套AI大模型报告合集
这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示
因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取
三、AI大模型经典PDF籍
随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。
因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取
四、AI大模型商业化落地方案
作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。