别再神化 Loop Engineering：看完 Peter和Claude的最新解释，我终于理解了它

Peter：从 10 个窗口到一个"经理"

在这两天的 AI Engineer World's Fair 2026 上，Peter Steinberger 做了一个 10 分钟左右的演讲，这是他在提出这个概念之后，第一次对外解释他理解中的 Loop Engineering 到底是什么？

从年初到现在，Peter 的工作模式发生了很大变化。1 月的时候，Peter 会同时开着 10 个以上的窗口，等着某一个窗口的任务完成，然后给它安排新的工作，当时，这张照片看起来像极致生产力的代表，不过放到 6 个月之后的今天，他自己也承认，这看着有点”傻“。

Peter 1月工作状态：同时打开多个窗口

在当时，人，也就是 Peter 自己是那个统筹全局的角色，他做调度、做路由、以及记清楚每一个窗口的上下文。

之后，他开始用 Agent 来协调所有的工作，他给自己安排了 10 个 Agent，相当于有 10 个直接汇报的下属。

现在，他给自己安排了一个“经理”，然后由这个“经理”去管理 10 个 Agent，做好工作分配，他只需要管好这一位下属。

Peter 当前工作流：一个经理 Agent 统筹 10 个下属 Agent

这个转变很关键。持久上下文、委托分配和自动化触发是形成这个结果的主要三个原因，而这样一个体系，就是 loop。

我相信，看到这里，Peter 已经讲清楚了当他说 loop 的时候，他实际说的是什么：是一个长期运行的多 Agent 系统。

如果说在初期的时候，限制工程师的主要是 token，之后是算力，那现在主要是“注意力”。也就是“人”成为了整个系统的瓶颈。

loop 就是为了解决这个问题。Peter 描述了一个场景来让大家更好的理解这个概念：

当有人提交了 PR，他的“经理”会把这个内容跟项目目标进行对照，决定它是否适合，如果适合，就会交给一个 Agent 开始工作，然后另一个 Agent 负责审查工作结果，在这个过程中，Peter 本人的时间和精力被大幅节省了。

遇到需要决策的问题，“经理”会把 PR、原始问题和建议 diff 给到 Peter，Peter 决定是否拍板。

用一句话总结就是：Agent 在内部循环做执行，Peter 在外部循环中指方向、做决策。内层是 Agent 的自动循环，外层是人类的战略判断。两层循环嵌套运转，人就不再是瓶颈了。

Claude Code 团队：四种 Loop 类型

如果说 Peter 的解释来自一个资深工程师工作方式的转变，那 Claude Code 则是从产品角度给出了定义。

Claude Code 团队在《Getting started with loops》里说：Loop 是 Agent 重复工作循环直到满足停止条件。

这个定义简单而清晰。按照触发条件、停止条件、使用命令和适合任务类型来做区分，可以分为四种类型：Turn-based loop（轮次循环）、Goal-based loop（目标循环）、Time-based loop（时间循环）、Proactive loop（主动循环）。

第一种是 Turn-based loop，也就是最基础的手动循环。触发条件是你发一条 prompt，Claude 收集上下文、做事、自查、回复，然后你再检查，再发下一条。

这个其实我们早就在用了，只是以前不叫 Loop。想让这种循环更可靠，团队特别强调要把人的验证步骤写成 SKILL.md，让模型可以自己进行端到端验证。

第二种是 Goal-based loop，对应 /goal 命令。触发方式仍然是手动 prompt，但停止条件变成了“目标达成或者达到最大轮次”。

这背后的关键设计是，每次 Claude 想停下来交差的时候，都会有一个独立的评估模型去检查你定义好的条件，不满足就把它踢回去继续干活。所以确定性的、可以量化的成功标准变得特别重要。

第三种是 Time-based loop，对应 /loop 和 /schedule。它按时间间隔触发，适用于周期性工作或者需要跟外部系统交互的任务，比如每隔一会儿检查 PR 有没有新的评论、CI 是不是挂了，自动去处理。

第四种是 Proactive loops，这是把前面几种原语组合起来，加上 auto mode 和动态工作流，做成完全没有人在实时的、事件驱动的长运行任务。这也是最接近 Peter 那个“经理”形态的东西。

Claude Code 团队与 Boris 对于 loop 的理解和判断基本一致：你不再做那个手动敲提示词的人，你设计一个系统来代替你做这件事。

Loop 工程解构：Addy Osmani 的五块积木

Addy Osmani 是谁？他是 Google 工程总监、长期研究 AI 编码工作方式的知名写作者，他把 Loop Engineering 做了彻底的工程化解构。

你构建一个小型系统，它自己去发现工作、分发工作、检查工作、记录已完成的事、然后决定下一步，让这个系统去戳 Agent 而不是你自己来。Addy 把这个系统拆成了五块积木，加一个记忆层。

五块积木 + 一个记忆层

第一块：Automations：让 Loop 成为真正的 Loop。 没有自动化触发机制的 Loop 只是单次调用。在 Codex 里是 Automations Tab，在 Claude Code 里是 /loop、/schedule、hooks 和 GitHub Actions。

一个独立的小模型会检查停止条件是否满足，同样的，干活的 Agent 不能给自己打分。这是整个 Loop 的心跳，让工作主动浮现出来。

第二块：Worktrees：并行不变成灾难。 多个 Agent 同时写同一个文件就会撞车。Git Worktree 提供独立工作目录，一个 Agent 的物理修改不可能碰到另一个 Agent 的工作目录。不过 Worktree 解决了机械碰撞的问题，但你的 review 带宽仍然是天花板。

第三块：Skills：别把项目解释八百遍。 一个 SKILL.md 文件，写上项目约定和指令。Agent 每次会话都是冷启动。

Skill 就是把意图写在外部，让 Agent 每次运行时都能读到。一次定义，每次循环受益于它。没有 Skills 的循环每次都从零推导你的项目，有 Skills 的循环是在积累理解。

第四块：Connectors：让 Loop 触达真实工具。 基于 MCP 协议，让 Agent 读 issue tracker、查数据库、打测试环境 API、往 Slack 发消息。Connectivity 决定了 Loop 是在你的工作流里干活，还是只能在旁边说一个 plan。

第五块：Sub-Agents：让干活的别判自己的卷子。 写代码的 Agent 太会给自己放水了。解法是拆分：一个 Agent 写，另一个 Agent 审。

第二个 Agent 带着不同的指令和模型，跟第一个没有共情，所以评判更客观。Loop 恰恰是在你不在场的时候运行的，不在场时你更需要信任那个验证者。代价是更多 token，花钱花在刀刃上。

记忆：循环的脊柱。 一个 markdown 文件或 Linear 看板，记录什么做过了、什么还没做。模型在两次运行之间把一切忘得干干净净，所以记忆必须在磁盘上。没有记忆，循环就没有连续性。

Addy 的这套拆解非常工程化，也把 Loop Engineering 从一个概念落到了可操作层面。一个 loop 要真正跑起来，需要触发、隔离、知识、工具、审查和状态。缺一两个也能运行，但越长期、越复杂、越自动化，缺失部分带来的问题越明显。

这里 Addy 也提醒不要把 Loop 神化，一个人可以用 loop 加速自己熟悉的工作，也可以用同样的 loop 逃避理解。工具看不出这两者的区别，使用者必须看得出。

吴恩达：产品经理的三层 Loop

吴恩达上周也在 X 上讲了自己对 Loop Engineering 的理解。他把把自己做 0 到 1 产品时的过程拆成了三个循环：agentic coding loop、developer feedback loop 和 external feedback loop。

第一层，Agentic coding loop（智能编码循环）。 这一层最贴近大家讨论的 Loop Engineering。给定产品规格，最好再给一组 eval 或测试数据，AI agent 可以写代码、测试代码、继续迭代，直到代码符合规格。

他举了自己周末给女儿做打字练习 app 的例子：智能体独自工作近一个小时，用浏览器反复检查产物，全程不需要他介入。

第二层，Developer feedback loop（开发者反馈循环）。 开发者审查当前产物，从更高层次给编码智能体反馈：比如视觉设计哪里不对、该解锁哪些猫主题服装、家长引导流程怎么调整。这个循环的节奏在几十分钟到几小时。

他特别提到，去年包括他自己在内的很多开发者还在充当智能体的 QA，手动找 bug 再让它改；现在智能体能更好地自测，人终于可以把注意力放到产品决策上。

第三层，External feedback loop（外部反馈循环）。 包括让朋友试用、上 Alpha 测试、A/B 测试等。周期从几小时到几天甚至几周。

外部反馈汇入后，影响开发者的产品愿景，再进一步细化成规格，驱动内层的编码循环。

这三层里面，第一层直接对应 Peter 和 Claude Code 团队所讨论的 Loop Engineering 技术范畴。后两层，包括开发者反馈循环和外部反馈循环，本质上描述的是产品研发中一直存在的人类决策闭环和用户验证闭环。

吴恩达把它们纳入“循环”框架来讨论，是想说明在一层层嵌套的循环结构中，人始终在更外层的循环中扮演不可替代的角色。

从个人角度，我觉得也没有必要把 Loop Engineering 做进一步泛化，反而会把这个概念复杂化。

把集中理解放在一起看

Peter、Claude 官方、Addy Osmani 和吴恩达，其实分别站在不同位置解释了同一个变化。

Peter 看到的是个人工作模式的变化。多个 agent 同时工作后，人的注意力成为瓶颈，所以需要一个经理 agent 或一个调度系统，把分配、跟踪、审查和上报组织起来。

Claude 官方给的是产品和工程定义。Loop 是 agent 重复执行工作循环直到满足停止条件，不同 loop 的差别在触发方式、停止方式和适用任务上。这个定义克制，也最适合用来校准概念边界。

Addy Osmani 补上了系统构件。他告诉我们，一个可运行的 loop 往往需要自动触发、工作区隔离、项目知识、工具连接、子 agent 审查和外部状态。这些东西让 loop 从一句口号变成可搭建的工程系统。

吴恩达把视角拉到产品开发。他的第一层 agentic coding loop 和 Loop Engineering 关系最直接，第二层和第三层更多是在提醒我们：AI 加速了工程执行之后，人类会更频繁地参与需求澄清、产品判断和用户反馈。

把这几种理解合起来，Loop Engineering 可以被更朴素地理解为：把过去由人手动推进的一连串提示、执行、检查、修正和再提示，设计成一个带触发、状态、验证、边界和停止条件的系统。这个系统可以是一个 /goal，也可以是一个定时检查 PR 的 /loop，可以是一个带多个 sub-agent 的 workflow，也可以是一个每天自动整理 issue 的 routine。

关键不在于它有多复杂，而在于它能不能让 agent 在合适的范围内持续工作，同时让人类保留最重要的判断位置。

所以，Loop Engineering 不是 Prompt Engineering 的终结。一个好的 loop 背后，仍然需要写得很清楚的目标、约束、工具使用方式和验收条件。区别在于，过去你把这些东西说给模型听一次，现在你把它们写进一个会反复运行的系统里。

对于普通开发者或内容创作者，开始做 loop 也不需要一上来就搭复杂多 agent 系统。更实际的做法，是先找那些你已经重复做很多次的工作。

比如你总是让 AI 修完代码后再跑测试，总是让它检查移动端，总是让它看 PR 评论，总是让它改文章里的重复表达，总是让它根据同一套风格规则润色。只要一件事反复出现，而且检查标准相对明确，它就可能适合被 loop 化。

看清这些来龙去脉之后，Loop Engineering 就没有那么神秘了。

回到第一性原理，它更像 AI agent 时代的工程化补课：当模型能做更多事，我们就要更认真地设计它做事的系统，给它清楚的目标、标准、边界、状态和停止条件。

未来这个词可能会退烧，很多具体技巧也可能被其他的新概念取代，但事情的本质不会变。

Loop Engineering 本质：人从执行层退出，进入决策层

JOTO 企业落地观察

• Loop Engineering 的落地成败高度依赖企业已有知识资产的结构化程度。SKILL.md 等指令文档若缺乏版本控制、领域分类与变更审批机制，多 Agent 协同时极易因语义歧义导致执行偏差，这对 RAG 知识工程提出新要求：需从静态文档检索转向支持指令继承、上下文绑定与执行验证的可执行知识图谱。
• Proactive loop 的工程价值取决于企业工具链的开放能力。若 CI/CD、代码评审、监控告警等系统未提供符合 MCP 等标准协议的接入点，Loop 将被迫退化为低效轮询，无法实现真正的事件驱动。企业需优先评估核心工具链的 API 成熟度，而非直接堆砌 Agent 数量。
• 吴恩达三层循环框架揭示了一个关键治理盲区：外部反馈循环引入的真实用户行为数据，未经脱敏与权限分级即接入 Loop，会使自动化系统成为数据合规风险的传导节点。企业需在 Loop 设计初期嵌入数据主权控制模块，而非事后补救。
• Peter 所述‘经理 Agent’作为调度中枢，其透明度直接决定 FDE 驻场共创的有效性。若调度策略不可解释、不可干预、不可审计，驻场工程师将无法在关键路径上及时介入。企业需在架构设计阶段预设人工熔断开关、决策日志快照与回滚锚点。