本文来自微信公众号： 智讯智库 ，作者：施展
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时常会困惑：“这和我们现有的Agent框架（如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编程成长的必经之路。
由主目标支配的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的工程理念，足以证明其在生产力环节的潜力。
而其潜力，在于同时拥有「自主性」和「并发性」，更像一个团队作战。在设计了危险边界、明确了路径和验收标准、且加入了多个子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