本文作者飞樰01 背景此前已有不少文章围绕 Agent 自进化这个主题展开过讨论内容涵盖了 Hermes Agent 等自进化框架以及 Skill 自进化等具体技术方向。而最近AI 领域又出现一个新的概念叫做 Loop循环或者叫 Loop Engineering中文翻译一般叫“循环工程”。因此本文将重点聊聊这个话题尽量系统化地介绍一下 Loop 与 Loop Engineering究竟是什么以及它们背后有哪些思考。之所以关注 Loop 以及 Loop Engineering 的技术概念主要是因为最近 AI 行业里不少大佬都在密集讨论这个话题。首先作为 AI 领域的风向标Anthropic 公司 Claude Code 的负责人 Boris Cherny 就明确表示他在使用 Claude Code 时已经不再手写提示词 Prompt 了而是转向编写 Loop用 Loop 来驱动工作流的完成。与此同时小龙虾 OpenClaw 的创始人 Peter Steinberger 也在 X 上指出过不应该再用传统的提示词去指挥 Agent而应该通过设计 Loop 来引导 Agent 的行为。此外AI 大神也是 Vibe Coding 和 LLM-Wiki 的提出人 Andrej Karpathy也在同样强调说“你必须把你自己从 Loop 的执行过程中移除出去”。就在 6 月初也就是上周Google AI 总监 Addy Osmani 专门写了一篇文章正式定义了「Loop Engineering」这个概念[1]并在文章开头就给出了一句核心定义Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.Loop Engineering 就是把你从“给 Agent 提示词的人”这个位置上替换掉。你不需要再亲自去写提示词而是转而设计一套能够自动完成这件事的系统。听到这里可能很多同学会觉得Loop不就是循环吗Agent 本身不就是一个 Loop 吗但需要强调的是此 Loop 非彼 Loop。接下来就重点拆解一下这背后的区别与深意。02 Agent Loop vs Loop Engineering要理解 Loop Engineering首先需要搞清楚这个 Loop 与基础的 Agent Loop 的本质区别。先来看看 Agent Loop。本质上讲Agent 本身就是一个 Loop。正常情况下大模型运行一次就是“输入一段话、输出一段话”它本身并不会在一次回复里自动完成工具调用和推理形成一条很长的Agent 轨迹Trajectory。所以想让 Agent 持续、自动化地运行就必须把它构建成一个 Loop。Agent Loop 的核心逻辑其实很简单当输入进去之后大模型的输出通常有两种情况。一种是直接给出 Response流程就结束了另一种是返回 Function Call。如果把 Function Call 对应的工具执行结果再次作为“输入”喂给大模型这就形成了一个循环。如果下一轮模型输出的是 Response循环就停止如果依然是 Function Call就会继续调用下一个工具进入下一轮循环。换句话说只要把所有关键步骤都设计成 Function Call模型就能在这个过程中不停地循环调用各种工具链同时穿插必要的 Response从而形成一个完整的 Loop。无论现在的 Agent 有多复杂底层都是基于这个简单的原理构建的。当然在实际运行中Loop 也可能会出现不可控的情况比如模型该调用工具时突然断了、产生幻觉或者陷入死循环等等。针对这些问题业界也有很多应对做法。例如可以引入一个额外的 Validation Agent 来做验证发现任务中断时再把它拉起来继续跑也可以设置一个Max Steps 上限让模型在陷入死循环时能够强制跳出避免无谓地消耗 Token 资源。包括大家熟知的 ReAct、Ralph Loop 等本质上都是 Agent Loop 的不同变种。归根结底Agent 最核心的逻辑就是一个 Loop。那问题来了既然 Agent Loop 早就有了为什么最近各路 AI 大佬又开始密集讨论它他们口中的 Loop 和 Loop Engineering 到底是什么其实大佬们说的这个 Loop跟刚才讲的底层 Agent Loop 完全不是一回事。底层的 Agent Loop 是 Agent 最核心的基础循环现在已经是默认的基础设施了没必要再单独拿出来强调。而他们真正想表达的 Loop 以及 Loop Engineering是构建在 Agent 之上或者说 Harness 之上的是一种由人来设计和控制 Agent 使用方式的新的范式。举个例子正常情况下用 Agent大概率是这样的流程提一个需求比如“帮我实现某某系统的代码”或者“搭建一个某某系统”然后 Claude Code、Codex 这些工具就开始执行。虽然底层有 Agent Loop 在跑中间也做了各种任务拆解但最终它会把一个完整的系统交付过来。整体来看这依然是一个“一次性”的过程提需求模型干活最后交付结果。这时候人要做的就是验收跑一下系统、看看效果、调试一下是否满足预期。但在实际使用中经常会发现一次提了的需求Agent 最后的产出结果并不能完全满足预期或者说在测试过程中暴露出来很多问题。于是网上就出现了一个很火的梗以前写代码用的是标准的 QWERTY 键盘到了 AI 时代“键盘”变成了几个固定按钮比如“说中文”、“继续”、“还是报错”、“你改了啥”、“先别重构”、“回滚”等等。用 Claude Code 或 Codex 时指令还真就大概率是这些。虽然是个梗但这确实是当下使用 AI 的真实常态。03「人机协同循环」重构为「自动化验收闭环」当高频地使用“继续”、“报错”、“回滚”这些指令去催促模型完善、调试或修改错误时是不是可以思考这个动作本身是不是也可以自动化所以大佬们提出所谓的 Loop 和 Loop Engineering本质上就是想解决这个问题能不能在提完需求之后模型不用等人再去喊“检查错误或”不符合预期”而是自己先对自己说这些话主动完成验证也就是说让模型把原本需要人来催的环节自动化掉。但光做到这一步可能还不够。因为在实际场景中验证和测试往往比较复杂可能有专门的验证集、测试用例。期望的流程是第一步让模型完成开发第二步让它基于测试集去跑拿到反馈的错误后再去调优系统然后再测试、再调优……这是一个大的循环。以前这叫**「人在循环环路」HITLHuman-in-the-Loop人在这个大循环里做验证和测试而现在的思路是能不能让模型自己在这个外部验收项目的 Loop 里闭环跑起来注意这已经不是底层那个小的执行 Agent Loop 了而是一个更上层的、面向需求验收**的外部 Loop。但问题是如果不去设计这个 Loop不把循环逻辑写清楚模型很可能就不 Loop或者瞎 Loop。这也是为什么现阶段大家都在提倡 Loop Engineering就是为了避免写一次性的 Prompt、提一次性的需求然后人在里面不停地跟 AI 人机协同、反复调试。那种方式既不自动化又耗时耗力人还特别累。如果能提前把开发需求、验证内容、预期目标都定义清楚Agent 是不是就能在整个过程中自己 Loop 起来至少在不万不得已需要人介入的情况下它能尽快自动化地达到想要的目标。这或许才是 Loop Engineering 最近兴起的根本原因人们其实是在原有基础上再次追求效率的提升。回想一下 AI Coding 的演进过程最开始人们不满足于自己写代码于是让 AI 写后来不满足于短任务开始用 Agent 跑长链条任务再后来不满足于 Agent 只在本机运行让它上云端、上移动端有了 OpenClaw 这样的产品接着又不满足于 Skill 是静态固定的希望它能自进化而现在人们已经不满足于使用这些工具本身了因为里面还有大量的人工交互和参与。所以大家希望更进一步把从开发到验证、再到反馈调优的整个循环都设计好让 Agent 自己动起来Loop 出一个更完善的系统。如果一个系统能把这个外部 Loop 跑得又好又稳那才真正体现了它处理长程任务的核心能力。说白了Loop Engineering 本质上就是一种可以循环起来的 Pipeline。这种 Pipeline 的触发方式主要有两种第一种是人工触发就跟现在提需求一样直接写一个 Loop 形式的 Pipeline让它一步步自动执行下去这在现阶段已经完全可以实现了第二种是定时触发适用于那些需要周期性执行的任务。比如在 AI Coding 场景下很多开发者每天都要拉取 PR、做 Review、审核、合并分支只要把评审和合并的逻辑定义清楚这个任务就可以每天自动跑再比如公司里的周报、日报也可以根据预设好的数据源让模型每天自动抽取汇总甚至像股票盯盘系统每天定时抓取信息、选股、交易这些过程都可以写成 Loop 定时完成。所以归根结底这就是一种让 AI 自动运行的机制。这里面其实有一个非常关键的变化脉络从 Coding 到 Vibe Coding是从「写代码」变成了「提需求」而从 Vibe Coding 到 Loop Engineering则是从“提一个需求”变成了“提一套闭环流程”。不再只是告诉模型要做什么而是把从开发、测试、验收、调优再到反馈迭代的完整链路都定义好让模型在这个流程里自己转起来。这或许才是 Loop Engineering 最核心的价值所在。04 Loop Engineering 的六大核心框架其实关于 Loop 这个概念业界已经关注了一段时间但此前一直没有看到系统性的总结文章。主要原因在于它当时还比较零散更多只是大家在提需求时尝试用循环的方式去描述没有形成一套系统化的方法论。直到最近Google AI 总监 Addy Osmani 对 Loop Engineering 做了相对完整的梳理和定义这个概念总算有了比较清晰的雏形也到了可以拿出来系统讨论的时候。做科普的同时也希望大家能借此思考一下在自己的项目或日常工作、生活中是否可以引入这种 Loop Engineering 的思维让 Agent 真正自动化跑起来、闭环起来。根据 Addy Osmani 的定义一个完整的 Loop 主要包含以下六个核心部分下面逐一来看。1. Automations自动化有了 Automations自动化Loop 就可以定时循环了不然就只是手动跑一次的一次性操作。比如使用 Codex 就可以创建一个自动化任务选好项目、定好要跑的 Prompt、设好频率还能选是在本地代码上跑还是在后台分支上跑。要是跑出来发现问题了它就进 Triage 收件箱没发现问题就直接自动归档。比如每天的一些问题分类、CI 失败总结、写提交简报还有排查上周别人引入的 Bug 等等。Codex 还有个命令叫做 /goal会在多轮对话里持续工作一直跑到设定的条件真正满足为止还支持暂停、恢复和清除。Claude Code 也类似只不过它是靠 Cron 调度和 Hook 实现的。可以用 /loop命令让某个 Prompt 或命令按间隔跑可以设 Cron 定时任务也能在 Agent 生命周期的特定节点用 Hook 触发 Shell 命令。核心逻辑也一样定义一个自主任务给它定好节奏然后等着结果就可以了。另外Claude Code 也支持 /goal命令每轮交互之后会有个独立的小模型来检查是不是完成了因此写代码的 Agent 不是给自己打分的那个。只要给它定个目标比如“test/auth 下所有测试都通过且 lint 检查无误”然后就可以不管了。2. Worktrees工作树隔离只要同时跑多个 Agent就很容易有文件冲突的问题也很容易导致任务失败。两个 Agent 同时改同一个文件就有点像两个工程师没打招呼就往同一行代码里提交修改一样那么怎么解决呢其实很简单使用 Git 的 Worktree 就能解决这个问题它本质上是一个独立的工作目录有自己的分支但共享同一个仓库历史所以一个 Agent 的改动根本碰不到另一个 Agent 的代码。Codex 是直接把 Worktree 支持内置进去了这样多个线程可以同时操作同一个仓库而不会互相打架。Claude Code 也提供了相同的隔离能力可以用 --worktree参数在一个独立的 checkout 里开启会话也可以给子 Agent 设置 isolation: worktree让每个 Agent 都拿到一份全新的、用完自动清理的代码副本。这样就让并行任务之间隔离了起来避免打架。3. Skills可进化的技能包关于 Skill之前的文章中已讲过多次这里就不赘述了。Skill 就是一种可渐进式披露、可复用的能力包基本上由 Markdown 文档、代码脚本这些组成。但在 Loop Engineering 这里如果 Skill 具备自我沉淀的能力它就能在 Loop 的每一次循环中不断更新、积累经验变成一种“活的知识”。这样 Agent 就不会每次都在同一个坑里跌倒而是越跑越聪明真正实现能力的迭代与复用。4. Connectors / Plugins连接器 / 插件Connectors / Plugins 本质上就是 MCP 及其延伸的各类工具负责把各种外部 API 工具接入 Agent。有了这些模型才能真正“伸手”触达现实世界中的各类服务与数据源。没有 Connectors 或者 PluginAgent 就只是一个封闭的推理引擎有了它Agent 才具备完成实际任务的行动能力。这也早就是目前大家最熟悉、落地最广泛的基础设施了。5. Sub Agents子智能体第五个核心部分是 Sub Agents也就是子 Agent。可以把它理解为在主 Loop 运行过程中动态生成的「分支智能体」它们各司其职共同支撑整个循环的高质量运转。举个典型的例子当主 Agent 完成开发任务后可以生成一个独立的验收 Sub Agent 来检查结果。这个验收 Agent 拥有自己专属的 Prompt 和验证标准与主 Agent 完全解耦。这种设计刻意制造了一种“博弈”的关系如果主 Agent 的产出不符合需求验收 Agent 就会提出质疑和挑战。之所以不让主 Agent 自我检查是因为它往往“当局者迷”就有点像人一样自己写完代码总觉得完美无缺但换个人一看就能发现问题。引入独立的验证 Sub Agent本质上就是用角色隔离来打破这种认知盲区。当然Sub Agent 的价值远不止于验证。在复杂任务中探索、设计、实现等环节都可以拆分为独立的 Sub Agent 并行执行。它们各自拥有更大的发挥空间又能通过相互制衡提升整体产出质量。不过需要注意的是Sub Agent 并非越多越好。如果缺乏主 Agent 的有效调度多个子 Agent 很容易各干各的导致结果分崩离析、失去一致性。因此是否拆分、如何拆分必须根据具体任务特性来决定。关于这部分更细致的实践技巧之前讨论 Claude Code 的文章中已有详细展开这里不再赘述。核心原则是对于探索性、分析性的子任务可以大胆生成 Sub Agent 来分担但最终结果必须汇总回主 Agent 进行整合而验证类 Sub Agent则务必保持独立避免“既当运动员又当裁判员”。只有这样Loop 才能在自动化运转的同时守住质量的底线。6. 状态State最后是状态管理也就是怎么追踪「哪些事已经做完了」。这块可以用 Markdown 文件来记录比如搞个 AGENTS.md 或者专门的进度文件要是习惯用 Linear 这类项目管理工具也可以通过 MCP 连接器直接对接上去让 Agent 自动同步状态。05 简单实践与思考讲了这么多理论接下来举一个实际落地的 Loop 例子。如果看 Addy Osmani 的原文或者网络上其他文章谈 Loop Engineering 的案例会发现绝大多数都是围绕代码审查、自动 PR、CI/CD 这些场景展开的。这些例子确实经典这里就不再赘述了。这里分享的是一个经过小测试验证过的、用 Claude Code 或 Codex 都能轻松实现的 Loop 实践。具体来说是一个简单的文本分类任务手头有一批文本需要按预设标准分成几个类别。传统方式写一个提示词告诉模型分类标准和数据样例让它输出分类结果然后人工检查准确率发现不准就手动反馈调整最后把调好的提示词沉淀成 Skill供下次复用。整个过程高度依赖“人”在中间反复校验和修正。Loop 方式把“验证”和“迭代”直接写进 Loop 的定义里。具体来说可以这样描述任务“请完成文本分类分类标准为 1/2/3/4/5完成后请严格按照该标准对结果进行自评若发现错误请主动修正分类逻辑或标准直到满足要求最终将稳定的分类能力沉淀为 Skill。”同时设定量化目标比如“在 100 条测试数据上准确率 ≥95% 或者错误率 ≤5%”。那么这个目标写入 Loop 之后Agent 就会自主循环打磨不断逼近这个指标无需人工中途干预。看到这里可能有同学会问这不就是之前文章里提到比如 EvoSkill、SkillOpt 这些 Skill 自进化差不多吗确实很像主要区别就在于这个过程完全由 Agent 自主驱动完成的 Loop不依赖任何外部开源框架或预置代码。Agent 会在 Loop 运行中自己构建一套类似 EvoSkill 的验证与优化机制自己跑测试、自己改逻辑、自己沉淀能力。其实这也是一个值得关注的趋势在 AI 时代未必需要先造一个全新的框架才能实现高级能力只要用 Claude Code 或 Codex 写一个结构化的 Loop很多原本需要工程化封装的能力现在可以直接跑出来。这个小例子也再次印证了 Loop Engineering 的核心意义它不是取代 AI Coding而是在 AI Coding 的基础上进一步压缩了 Human-in-the-Loop 的比例。人不再需要全程盯着、反复纠错只需设定清晰的目标和验收标准然后等待 Agent 自主达到预期水位后再做最终确认。所以 Loop Engineering 概念也没那么复杂它可以被普通人快速上手并在真实任务中显著提升自动化程度与交付质量。上面提到的文本分类的例子就是抛砖引玉做个简单实验大家完全可以照着这个思路在自己的日常工作里多试一试。比如文本分类任务如果每天都要跑也可以设成定时 Loop 每天去运行。不过更推荐的做法是把这类成熟任务沉淀成脚本或者 Skill而不是每天现开一个 Loop 去跑。原因很简单一是每天重跑 Loop 太费 token二是大模型每次跑 Loop 的实现路径不一定一样哪怕需求没变今天和明天的代码、实现方式也可能有较大差别结果就容易漂移不好复现。所以比较合理的建议是如果流程是固定的、不需要模型每次都重新推理那就直接写成脚本如果确实需要模型每天介入、做动态判断那就把它做成可复用的 Skill。这样既用上了 Loop Engineering 的思路又能保证运行的稳定、成本可控。当然这只是一点经验之谈不是什么标准做法。具体怎么技术选型大家还是结合自己的业务、成本和质量要求自己评估着来就好。06 Loop 不是银弹用之前需要先想清楚最后还需要补充几点。虽然 Loop 确实是个提效的好手段但用的时候一定要清醒它不是什么横空出世的全新技术只是在原有基础上把自动化又往前推了一步。AI 的发展本来就是循序渐进的很少有突然蹦出来一个完全颠覆的东西更多是量变引起质变慢慢长出新的效果。另外特别要提醒的是用 Loop 的时候需求和验证标准必须比原来写得更加明确。为什么因为以前提需求哪怕模糊一点也没关系模型先出个初版人在 Human-in-the-Loop 的过程中可以不断纠偏、调整靠人工反馈来保证最终结果的可靠性。但用了 Loop 之后中间过程人不参与了如果开头没把需求写清楚、没把验证逻辑定义明白Loop 很可能从一开始就跑偏了验证也不是按预想来的。跑了一大圈、烧了很多 token最后出来的东西还是跟预期差十万八千里。Loop 虽然好用但它对使用者描述需求和验证的能力要求其实更高了。因为希望模型自闭环跑它就没机会中途确认只能自己发挥。而模型的“自己发挥”跟真实想法之间往往是有 gap 的。对于顶尖大牛来说这可能不是问题所以他们用得飞起但对大多数人来说如果发现很难把需求和验证写清楚、把控不住 Loop 的效果那还是建议老老实实回到 Human-in-the-Loop 的模式先人工迭代几轮再说。毕竟 token 烧起来成本不低盲目让模型自主跑一大通却拿不到想要的结果其实是时间和钱的双重浪费。所以这次聊 Loop Engineering好处和坑都尽量讲清楚了当有明确的需求和清晰的验证标准时Loop 绝对是提效神器能省下大量时间和成本但如果需求和验证都是模糊的那人在中间不停反馈、校正、确认反而可能是更稳妥、更经济的选择。技术方法论没有对错只有适不适合。AI 时代从来没有万金油每种思想都有它的适用边界。这点格外提出来就是希望大家用的时候能多留个心眼别为了用而用。07 总结这篇文章的内容到这里就全部结束了。如果看完之后有什么疑问、不同的看法或者在实践中遇到了什么问题都非常欢迎在评论区留言交流探讨。最后还是要说明一下本文内容只是技术探索过程中的一些心得与总结纯属一家之言、经验之谈。受限于认知和实践范围文中难免存在疏漏、片面甚至错误的地方还请各位读者朋友不吝批评指正。互相学习、共同提升才能更好地将 Agent 技术应用到各自所属的业务领域中。在 AI 时代浪潮奔涌向前的当下技术迭代日新月异唯有保持开放心态、持续精进才能不被落下。愿大家都能在这条路上携手同行一起往前走再进一步08 References[1] Loop Engineeringhttps://addyosmani.com/blog/loop-engineering/[2] Loop Engineering: Build Self-Running Coding Agents 2026https://www.the-ai-corner.com/p/loop-engineering-coding-agents-2026