--- title: "吴恩达三层Loop：Agent越快，人越要管慢反馈" source_url: "https://mp.weixin.qq.com/s/PGpe6EnVNnig2cuZ9VbnuA" ingested: 2026-07-03 sha256: cab38c66506a628b2162e122bfc41b7623fc675da3845a153b2e31719f500616 author: 若飞 publisher: 架构师 --- 最近几周，Loop Engineering 这个词越来越热。 Peter Steinberger 的说法很直接：重点会从一轮轮提示 Coding Agent，转向设计"提示 Agent 的循环"。Boris Cherny 那句"我的工作是写 loop"，也被很多人反复引用。 放在《架构师》今年一直梳理的 Agent 工程里，这个转向并不突然。 前面几个月，我们基本沿着同一条线往前走：先拆 Coding Agent 外面的仓库上下文、工具、状态、记忆、子 Agent 和权限；再看 Harness 怎么把 Agent 接进可观察、可恢复、可追踪的工作现场；最近聊 Loop Engineering，重点则落到反馈循环、停止条件、状态账本和反馈契约。 吴恩达在 The Batch 里把这条线又往外推了一层。 他的重点从"代码怎么自己改好"，移到了"产品怎么从 0 到 1 长出来"。 这个角度值得单独看。 当 Agent 把最内层工程循环压到分钟级，稀缺能力并没有消失，只是往外迁移了：人要把模糊愿景翻译成规格，也要从真实世界拿回反馈，再修正愿景。 Agent 越快，人越要管慢反馈。 三层 Loop 吴恩达把 0 到 1 产品开发拆成三层： • Agentic coding loop：分钟级。Agent 根据规格写代码、测试、修复，再继续迭代。 • Developer feedback loop：几十分钟到几小时。开发者看当前产品，调整规格、交互、功能范围和下一步方向。 • External feedback loop：小时到数天，甚至数周。真实用户、Alpha / Beta、A/B Test、市场变化，把信号带回产品愿景。 放进我们最近这条 Loop Engineering 线索里看，三层 Loop 补上了一条更完整的链路：内层看代码能不能跑起来，中间看规格是不是还对，外层看这个问题还值不值得继续做。 很多讨论容易停在最内层。让 Agent 自己跑测试、自己修 Bug、自己开浏览器检查页面，这些都很有价值，但它们主要解决的是一个已知目标怎么更快完成。 更麻烦的往往是另外两个问题： 目标本身怎么变清楚？ 真实用户回来以后，目标又该怎么改？ 放到产品开发里看，三层 Loop 不太像三个并列流程，更像三种时间尺度上的接口。 愿景变成规格，规格变成代码，代码变成证据，证据再回到人的判断。外部反馈回来以后，又要重新改愿景、改规格、改验证方式。 这条链如果断了，最内层跑得越快，偏差也可能积累得越快。 图 1：三层 Loop 的时间尺度和交接方向 内层快了，但方向不会自动变对 最熟悉的是 Agentic coding loop。 给 Agent 一份产品规格，再配一组可以验收的评测或测试，它可以写代码、跑测试、发现问题、继续修，直到结果符合规格。 这和我们前面聊 /goal 时的判断很接近：一个可运行的目标，不能只写"把它做好"。范围、不变量、验证方式、预算边界和停止条件，都要尽量放进去。 吴恩达在原文里举了一个周末做打字练习应用的例子。Coding Agent 可以自己工作大约一小时，还会多次用浏览器检查自己做出来的东西，再回来汇报。 这种体验正在变得常见。 Addy Osmani 在 Loop Engineering 长文里拆得更工程化一点：自动化负责触发循环，worktree 负责隔离并行任务，skills 负责沉淀项目知识，connector 负责连接真实工具，sub-agent 负责把"做"和"查"拆开，状态文件负责记住这一轮做了什么。 这些部件听起来琐碎，但它们对应的是今年反复出现的几个老问题：工作现场怎么隔离，过程资产怎么沉淀，验证者怎么独立，状态怎么交接。 少一块，循环未必跑不起来，只是后面容易变成"看起来一直在推进，实际很难接手"。 这里要补一个边界：Agentic coding loop 再顺，也只是在规格内部迭代。它能把"怎么做"压快，却不知道"该不该做"。 一个规格写错了，Agent 可能会非常认真地把错误规格实现得很完整。 所以，把 Loop Engineering 只理解成"让 Agent 一直跑"，会漏掉最关键的约束。没有验证、状态、权限和停止条件，循环会把问题放大；没有更外层反馈，循环会把错误方向做得更精致。 人的位置，是上下文接口 吴恩达这封信里，我最喜欢的一个说法，是他把"品味"换成了"上下文优势"。 很多人会说，人类在产品上比 AI 强，是因为人有品味。这个说法没错，但有点玄。品味很难传递，也很难调试。 "上下文优势"更适合工程团队理解。 上下文可以拆开成很多具体信息：用户是谁，在什么场景里用，业务边界在哪里，哪些约束不能碰，竞争对手最近做了什么，团队过去踩过哪些坑，哪些方向已经验证过，哪些只是直觉。 这些信息现在大多还在人脑里，或者散落在会议、工单、文档、客户聊天记录里。Agent 并不知道。 所以 Developer feedback loop 的关键，不是人继续给 Agent 当 QA。 去年很多开发者还在亲自找 Bug，再让 Agent 修。现在 Agent 自测能力强了以后，人花在低层 QA 上的时间会下降。人的工作会往上走：看第一版产品，判断功能范围是否合理，交互是否顺，规格是否需要改，愿景本身是否要调整。 这件事放到架构师视角里，意思很直接。 以前我们常说，把业务需求翻译成系统设计。现在中间多了一层：把产品愿景翻译成 Agent 能执行、能验证、能回滚的规格。 这里的规格不只是 prompt。 一份能交给 Agent 长时间执行的规格里，通常会有目标、非目标、用户场景、不变量、验收证据、权限边界、预算边界，以及这轮循环什么时候该停。 这些内容写清楚以后，Agent 才不是靠猜在补洞。团队也能在下一轮回看：当时为什么这么做，哪些判断后来被证伪了，哪些约束还有效。 我们之前梳理 Harness 时，也反复遇到这个问题：Agent 真要进入团队流程，很多上下文最后会落到仓库规则、Skill、Runbook、权限策略、状态文件和 trace 里，而不是只留在一次对话里。 慢反馈最容易被省掉 第三层是 External feedback loop。 这层最慢，也最容易被忽略。 找几位真实用户试用，收集反馈，做 Alpha 或 Beta，放到生产环境里做 A/B Test，看数据和用户行为。这些事情很少几个小时就能完成，有时要等几天，甚至几周。 在今天这个节奏里，它显得很慢。 但它承担的纠偏价值最高。因为前两层都发生在系统内部：Agent 按规格写代码，开发者按自己的理解改规格。只要产品还没有碰到真实用户，很多判断仍然只是想象。 吴恩达提到一个细节：外部数据的路径更长，先影响 developer vision，再影响 detailed spec，最后才驱动 coding agent。 这条顺序决定了反馈能不能进入下一轮。 真实用户反馈回来以后，如果只是停留在会议纪要里，或者被 AI 总结成"用户希望体验更好"，它没有进入系统。 它要变成新的产品判断，新的规格约束，新的验收方式，甚至新的非目标。这样下一轮 Coding Loop 才会真的改变。 AI 可以帮我们收集、清洗、归纳这些信号，但信号本身不能靠模型脑补。 这个判断我还不想说得太满。不同团队、不同产品、不同组织分工，变化一定不一样。 但方向上我认同：当实现速度被压缩，产品判断、用户理解和外部反馈会变得更贵。 一个团队如果只升级了最内层 Coding Loop，却没有升级外层反馈机制，很可能每天产出很多版本，内部看起来都完整，真实用户反馈回来以后，才发现方向一直没对齐。 问题往往不在 Agent；慢反馈没有进系统，偏差就不会自动消失。 图 2：慢反馈进入系统的路径 三层之间，要有交接物 换成架构师更熟悉的语言，吴恩达的三层 Loop 可以这样理解。 Agentic coding loop 是执行面，负责把规格变成可运行的软件。这一层要看测试、浏览器检查、静态分析、日志、沙箱、权限和停止条件。 Developer feedback loop 是产品控制面，负责把人的上下文、判断和取舍写回规格。这一层的产物不只是 prompt，更像可版本化的规格、验收标准、非目标、约束条件和决策记录。 External feedback loop 是环境反馈面，负责把真实世界的信号带回来。用户行为、访谈、支持工单、竞品变化、市场约束，都会改变团队对问题的理解。 这三层可以先粗略放成这样： 层级 | 输出产物 | 需要留下的证据 执行面 | 代码变更、测试结果、运行日志 | 测试、截图、指标、diff 产品控制面 | 新规格、取舍记录、非目标 | 人工评审、决策记录、可复现问题 环境反馈面 | 愿景修正、优先级调整 | 用户数据、反馈样本、A/B 结果 这张表不是为了把产品开发变成流程表。 它只是在说一件事：每层 Loop 的输出，最好能被下一层读懂。 这也是我们最近反复讨论输入、权限、验证、停止、反馈契约和状态交接的原因。它们都在给工程内循环打桩。 这些文章主要解决的是第一层，以及第二层里比较偏工程的部分。 吴恩达这封信把剩下的部分推出来了：第二层和第三层也需要一点工程化。重点不在把产品判断做成流水线，重点在让愿景、规格、证据和真实用户反馈之间有一条能回看的路径。 落到团队里，先收小 落到普通团队里，一开始没必要搭复杂平台。 可以先用一个低风险场景跑一周，比如内部工具的小功能、管理台页面的体验优化、一段可回滚的批处理，或者一次文档到测试的补齐。 核心交易链路、权限系统、线上事故修复这类事，可以等团队把状态、证据、权限和回滚跑顺以后再纳入。 试跑时，三份轻量记录就够了。 SPEC 写清这轮要改变什么，哪些事情先不碰，用户和场景是什么，哪些接口、数据、权限、体验不能破坏，最后用什么证据验收。 STATE 记录当前基线、已经尝试过的方案、已经通过的验证、暂时否掉的路径，以及下一轮从哪里继续。Addy 提到的 state file，说的就是这类东西。它不花哨，但长任务很需要它。 FEEDBACK 记录真实世界回来什么信号：来自访谈、工单、埋点、A/B，还是销售反馈；证据强度如何；它影响愿景、规格、验证，还是只影响文案。 这三份记录的价值不在格式，而在交接。 如果交接物写不出来，也许说明这层循环还不适合急着自动化。 图 3：团队试跑一周时的三份交接物 几个边界 Loop 跑起来以后，团队最先感受到的通常是速度。 但速度只是体感，问题往往藏在接口里。 内层 Coding Loop 做得很漂亮，外层反馈没进来，团队会得到一堆内部自洽的版本。 上下文只留在临时聊天里，几轮之后就很难复盘：哪些是事实，哪些只是某个人当时的判断。 自写自审很顺手，质量门槛也会悄悄变松。一个写代码的模型，天然更容易相信自己的解释。这里我更倾向于 maker/checker 分离：实现和验收用不同上下文、不同指令，必要时甚至用不同模型。 还有一个不太显眼的问题是成本和可理解性。 sub-agent、长循环、定时任务都会消耗 token，也会制造审查压力。更麻烦的是，如果长寿命代码在没人理解的情况下持续被循环修改，团队会慢慢欠下理解债。 Armin Ronacher 在《The Coming Loop》里提醒过一个很现实的问题：今天的模型容易做局部防御，看到一个失败就补一个 fallback，久而久之系统看起来更稳，实际变得更难理解。 这个担心我很认同，也和我们在《架构排熵：Loop Engineering 的持续清理系统》里聊过的问题是同一类：Agent 会加速产出，也会加速复杂度沉积。 所以，Loop 更适合先放在实验、迁移、性能探索、安全扫描这类可验证、短寿命或者机械转换任务里。对核心链路、持久化数据结构、权限系统、计费系统这类长期资产，Loop 可以参与，但不变量、设计边界和代码可理解性，仍然由人来把关。 不然，循环会把复杂度也自动化。 想想，也挺可怕的。。。 最后 Loop Engineering 这波讨论，表面上是 prompt 工作方式变了。 更深一层看，它是在重新分配软件开发里的时间尺度。 过去，人几乎卡在每一步实现里。现在最内层实现循环越来越快，人开始被推到更外层：写清目标，补足上下文，设计反馈，判断什么时候继续，什么时候停。 这并不轻松。 内层快了，外层慢反馈反而更容易被忽视。团队很容易沉迷在"今天又让 Agent 跑了多少轮"，却忘了问：这些轮次有没有让我们更接近真实用户的问题？ 我的理解会更保守一点。 Agentic coding loop 值得用，但它只是三层系统里的最内层。我更关注三层之间的接口：愿景怎么变规格，规格怎么变验证，验证怎么变证据，证据怎么回到下一轮判断，真实用户反馈又怎么修正愿景。 等这些接口清楚以后，Loop 才会从单纯自动化，往产品开发系统靠近：能持续学习，能被接手，也能及时停下来。 参考资料 • DeepLearning.AI / The Batch：Three Key Loops for Building Great Software https://www.deeplearning.ai/the-batch/three-key-loops-for-building-great-software • Andrew Ng X 帖 https://x.com/AndrewYNg/status/2071988145667928442 • Peter Steinberger X 帖 https://x.com/steipete/status/2063697162748260627 • Addy Osmani：Loop Engineering https://addyosmani.com/blog/loop-engineering/ • Armin Ronacher：The Coming Loop https://lucumr.pocoo.org/2026/6/23/the-coming-loop/ • Business Insider：Forget prompt engineering: 'Loop engineering' is all the rage now https://www.businessinsider.com/what-are-loops-ai-engineering-tips-2026-6