本文来自微信公众号： 智讯智库 ，
，作者：施展

Loop又是什么新看法？？？？

从ReAct到Loop：

一个看法的四次演化

6月2日，
，Claude Code创作者Boris Cherny在果真活动中说，
，他已经不再亲自提醒Claude，
，而是让Loop去提醒Claude，
，判断下一步做什么。。[1]

6月7日，
，OpenClaw创作者Peter Steinberger在X上发帖：“你不应该再提醒编码Agent，
，而应该设计那些提醒Agent的Loop。。”阻止6月22日，
，这条帖子的浏览量已经凌驾800万。。[2]

统一天，
，AddyOsmani揭晓长文《Loop Engineering》，
，系统化梳理了这套做法。。[3]

这些都不约而同指向统一个趋势：AI编程从Prompt升级到Loop新阶段。。

简朴来说，
，Loop是指让AI Agent自主执行“触发→事情→评估→重试或竣事”这一系列方法的闭环机制。。[3][4]

已往，
，开发者需要手动为AI编写每一条提醒词、检查每一次输出、决议下一步操作，
，类似于“写剧本”（划定好每句话怎么说），
，而Loop工程则是“建流水线”。。

许多开发者在初接触Loop时
；；；；；；嵋尚模骸罢夂臀颐窍钟械腁gent框架（如OpenClaw、Codex等）有什么区别？？？？我该去那里下载Loop？？？？”

事实上，
，Loop不是一个详细的工具或代码库，
，而是一种系统设计模式与要领论（就犹如“面向工具编程”是一种头脑，
，而Java/C++是实现它的工具）。。现有的优异Agent框架，
，其底层通常已经具备了实现Loop的基础能力（如准时使命、状态坚持等）。。

而这一范式，
，履历了四个要害里程碑：

2022年的ReAct论文首次涤讪了AI“边想边做”的理论起点
；；；；；；2023年AutoGPT的问世将其起源工程化为可松手运行早期产品
；；；；；；2025年业界醒觉了自动“设计Loop”的工程意识
；；；；；；随着Google CloudAI总监Addy Osmani在2026年6月7日揭晓的长文《Loop Engineering》，
，Loop正式落地为一套系统化的工程系统。。

《Loop Engineering》给出了五要素框架，
，将Loop的看法进一步具象化：Automation（触发机制）、Worktree（事情隔离）、Skill（手艺封装）、Connector（外部毗连）、Sub-Agent（子Agent），
，外加一个贯串始终的Memory层。。

Automation（触发机制）：系统的“起念头”，
，决议了整个Loop流程在什么条件下被叫醒。。

已往，
，AI事情的触发器是“人类在谈天框里敲回车”
；；；；；；在Loop工程中，
，触发是剥离人工干预的。。它可以是准时驱动（例如：天天早上8点自动抓取新闻）、事务驱动（例如：数据库里新增了一条工单、收到了特定客户的邮件），
，或者是基于外部API的Webhook信号。。它让AI系统从“被动问答”酿成了“全天候待命”的服务。。

Worktree（事情隔离）：系统的“清静沙箱与操作台”，
，为AI的自主运行提供一个自力、清静、可控的暂时物理情形。。

AI在一直“循环（Loop）”试错的历程中，
，会天生许多中心产品（好比写了一半的代码、下载的暂时图片、天生的日志）。。Worktree就像是给AI分配的一张“暂时势情台”或“沙箱（Sandbox）”。。它确保了AI的操作不会越界破损宿主机的焦点文件，
，同时也利便在使命完成后，
，将这个事情台一键打包生涯或清空销毁。。

Skill（手艺封装）：系统的“工具箱”，
，将其影响规模扩展到现实或数字天下的原子化功效？？？？。。

开发者将特定的能力预先写好并封装起来，
，好比“执行一段Python代码”、“将网页转化为Markdown”、“盘算数学公式”等。。在Loop运行时代，
，AI会凭证目今的需要，
，自主决议从工具箱里“掏出”哪个Skill来使用。。

Connector（外部毗连）：系统的“神经触角”，
，认真买通AI系统与企业现有SaaS软件、数据库或第三方平台的通道。。

若是说Skill是通用的能力，
，那么Connector就是详细的营业桥梁。。好比毗连飞书/钉钉用来自动发通知，
，毗连GitHub用来提PR（拉取请求），
，毗连Salesforce用于更新客户数据。。Connector解决了权限认证和数据名堂转换的问题，
，是Loop真正融入人类营业流的要害。。

Sub-agent（子Agent）：系统的“专业外包团队”，
，为了阻止简单AI模子处理重大使命时“脑容量过载”或爆发幻觉，
，将其拆分为多个职责简单、专业对口的微型Agent。。

好比在一个“自动化代码修复Loop”中，
，不再只用一个重大的Agent包办一切。。而是设置一个“测试Sub-Agent”只认真找Bug，
，一个“编码Sub-Agent”只认真写补丁，
，一个“评审Sub-Agent”认真代码Review。。主Loop认真统筹和路由，
，Sub-Agent认真在各自善于的领域内单点突破。。

贯串始终的Memory（影象层）：系统的“海马体”,认真状态治理与信息留存。。没有这一层，
，AI每次循环都会“失忆”。。

只管看起来是一个系统工程模式的立异，
，但也有人对其内在发出质疑：Reddit上有人说“这就是戴了顶帽子的cron job（类似一个准时使命）”。。更有人说：从Prompt Engineer到Context Engineer到Harness Engineer到Loop Engineer——统一人换差别马甲。。[4]

但现实上，
，Loop是在三者演进蹊径上的必定效果。。举个例子，
，Prompt是你在教新人做简朴的相同
；；；；；；Context就类似员工手册或项目配景
；；；；；；Harness是执行手册和规范，
，让他能最先干活
；；；；；；而Loop就是给新人制订的OKR，
，让他在相识配景、明确规范的情形下，
，自主完成既定的目的。。

这既是一个新人生长的路径，
，也是AI编程生长的必经之路。。

从“跑不起来”到“完整可用”，
，

但Loop有可能会让账单爆表

由主目的支配的Sub-Agent则能更高效地提升编程效率，
，你可以想象，
，当一个营业从单打独斗的大头兵单干，
，升级为一个小团队协同作战，
，效率更高，
，但也有可能犯更大的错。。

Anthropic Labs团队成员Prithvi Rajasekaran曾较量单Agent和多Agent Harness：面临统一个2D复古游戏编辑器使命，
，单Agent运行20分钟、本钱9美元，
，但焦点玩法无法事情
；；；；；；三个Agent Harness运行6小时、本钱200美元，
，妄想出16项功效，
，并交付了一个焦点流程可运行的原型（只管还保存交互、物理和深层功效的缺陷）。。[8]

凌驾20倍的模子挪用本钱，
，换来了从“焦点流程不可用”到“可运行原型”的质变。。

这不是效率提升，
，这是能力曲线的跃迁。。但价钱是明确的：Token账单有可能会成倍增添。。

True Foundry的剖析指出，
，Loop并不是免费的生产力提升。。无人值守模式下，
，若是没有Token预算、步数上限、限流和异常监控，
，Agent可能在无人察觉的情形下一连重试，
，让本钱快速失控。。[4]

Reddit社区上，
，有开发者自述隔夜挂着Claude Code跑循环使命，
，第二天发明账单凌驾6000美元——该开发者将原因归因于缓存逾期时间转变，
，导致每30分钟重新提交约80万Token上下文。。[9]

另一个由Medium匿名账户宣布的帖子体现：其组建了一个由四个LangChain Agent组成的市场调研Loop，
，两个Agent在相互“要求对方做更深入剖析”，
，没有任何人或机制来打断这个循环——11天后账单抵达，
，高达47000美元。。[10]

这些数字背后有一个结构性矛盾：Loop工程的价值在于“无人值守”，
，但“无人值守”恰恰是本钱失控的温床。。没有人的判断力做刹车，
，一个Agent可以在你把咖啡喝完之前跑出一个token天价账单的惊悚故事。。

比烧钱更危险的，
，

是人逐渐失去判断力

本钱问题还不是最危险的。。更隐藏的风险是“认知风险”。。

Osmani在他的博客里提出了三个风险，
，每一个都直指工程实践的焦点矛盾：

第一，
，验证责任仍在人。。Loop输出的“完成了”只是声明，
，不是证实。。系统可以跑完整个流程、提交PR、甚至发通知说“搞定”，
，但没有人真正审查过输出质量。。

第二，
，明确债务。。Loop产出越快，
，人现实明确的代码与系统真实状态之间的差别越大。。你只看了几个要害节点的输出，
，但系统在你睡觉时跑了300次迭代。。

第三，
，认知投降。？？？？⒄咦柚剐纬勺约旱呐卸，
，盲目接受Loop输出。。[3]

这三个风险不是理论推演。。

相关研究将这类征象称为“目的漂移Goal Drift”—系统在局部越来越有能力，
，但对使命的原始意义越来越不认真任。。

一个头脑实验诠释“目的漂移”[11]，
，好比老板让AI：“提高客服效率，
，同时真正解决用户问题。。”

AI一轮轮自我优化后酿成：“回复越快越好”→“少问几个问题”→“多用模板回复”→“尽快把工单标成已解决”。。

它依然逻辑清晰、执行力很强，
，甚至比以前更智慧，
，只是它起劲维护的工具已经变了。。

你省下的每一分钟“手动提醒”时间，
，都在累积一笔看不见的手艺债。。这笔债什么时间到期，
，取决于你的系统设计有多结实——以及你对“完成”的界说有多清晰。。

Loop工程仍是被低估的

生产力杠杆，
，

但焦点是学会设计“好的Loop”

只管Loop是一个全新的范式看法，
，但在生产情形里，
，已经有类似的框架设计。。

这些案例只管表述差别，
，但都不约而同接纳了类似Loop的工程理念，
，足以证实其在生产力环节的潜力。。

而其潜力，
，在于同时拥有「自主性」和「并发性」，
，更像一个团队作战。。在设计了危险界线、明确了路径和验收标准、且加入了多个子agent的并行处理后，
，单个项目内拥有了自主可迭代、可控制的小团队，
，

一个设计优异的Loop系统，
，可以在你睡觉时同时跑50个实验、测试100种设置、修复20个Bug，
，且每一次迭代都不需要对齐聚会，
，不需要stand up，
，不需要等code review排队。。

虽然，
，这里有个条件：你得把Loop设计对——即你这个小团队里的人是干活的（SKILL是对的）、关系是买通的（Connector是有用的）、SOP（执行规范）是对的、老板脑子是清晰的（能验证效果、控制本钱）。。

设计一个优异的Loop，
，更主要的是回覆三个问题（一个头脑清晰的老板该回覆的问题）：

阻止条件是什么？？？？不是“完成了就停”，
，而是“什么叫完成”。。若是答不上来，
，Loop就会在“完成”和“还没完成”之间永远振荡，
，或者更糟——在过失的地方停下来。。

谁来验证输出？？？？AI声明“完成”和人确认“可用”是两件事。。一个没有验证环节的Loop，
，是一台有发念头没刹车的机械。。

出了问题，
，我能在几多钱花出去之前知道？？？？监控不是可选项，
，是Loop设计的第一道工序。。LangChain事务，
，不是由于Loop失控了才被发明——是由于账单来了才被发明。。这两者之间差了11天。。

这三个问题，
，是设计可靠Loop时最容易被跳过的治理环节。。大大都失败的Loop，
，都是由于有人兴冲冲地把“触发”和“事情”设计好了，
，然后跳过了“评估”和“终止”——就像造了发念头却没装刹车。。

构建一个包括“触发器→使命界线→状态/影象→执行Agent→外部验证→阻止条件→本钱/步数上限→人工接受”的“好Loop最小结构”，
，才华推动AI编程在极大释放产能的条件下，
，依然坚持可控与可信。。

2026年AI编程，
，正在履历一个类似于2004年前后的时刻：那时云盘算从“听起来不靠谱”酿成了“不必就落伍”，
，过渡期或许花了五到七年，
，AI的进化则会更快。。

【声明】本文图表及剖析框架基于果真信息整理，
，仅供工业研究参考，
，不组成对任何上市公司的投资建议或生意依据。。

参考资料：

[1]https://x.com/steipete/status/2063697162748260627

[2]https://explainx.ai/blog/loop-engineering-coding-agents-claude-code-guide-2026

[3]https://thenewstack.io/loop-engineering/

[4]https://addyosmani.com/blog/loop-engineering/

[5]https://arxiv.org/pdf/2210.03629

[6]https://mitchellh.com/writing/my-ai-adoption-journey

[7]https://martinfowler.com/articles/harness-engineering.html

[8]https://www.anthropic.com/engineering/harness-design-long-running-apps

[9]https://metr.org/blog/2026-1-29-time-horizon-1-1/

[10]https://www.makeuseof.com/someone-left-claude-code-running-overnight-and-it-cost-6000/

[11]https://dev.to/dingdawg/how-an-ai-agent-ran-up-a-47000-bill-in-11-days-and-how-to-stop-it-1fk

[12]https://www.163.com/dy/article/KVFDE8IC0534A4SC.html

[13]https://www.zendesk.com/newsroom/articles/relate-2026/

[14]https://arxiv.org/abs/2505.02709

本内容由作者授权宣布，
，看法仅代表作者自己，
，不代表虎嗅态度。。如对本稿件有异议或投诉，
，请联系 tougao@huxiu.com。。

本文来自虎嗅，
，原文链接：https://www.huxiu.com/article/4874380.html?f=wyxwapp