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 时常会困惑：" 这和我们现有的 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 正式落地为一套系统化的工程体系。
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 每次循环都会 " 失忆 "。
但实际上，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
