AI Agent Loop到底是什么？多数人一上来就用错了丨Greg

AI Agent Loop到底是什么？多数人一上来就用错了丨Greg AI Agent Loop到底是什么？多数人一上来就用错了丨Greg Modified June 16 🔗 原文链接： https://mp.weixin.qq.com/s/ 3uMah1y... 原创 Capihom Capihom 晚点再听LaterCast2026年6月15日 21:27 北京我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "除非你有钱可烧，否则别这么干。" "人留在环里，仍然是最好的 loop。" "代码评审能跑 loop，因为它有固定反馈。" 当大家被 Boris、Peter 和各种演示视频带得热血上头时，多数人手里的订阅预算、产品定义能力、反馈机制，都还撑不起那种一键放手的闭环。访谈也很照顾实操顺序：前面先讲 loop 到底是什么，中段拆 /goal 为何烧钱，后段拿出一条今天就能跑起来的代码评审链路。Mic 最有价值的地方，是把 human in the loop 、 agentic loop 和代码评审 loop 拆成三种不同工作法。工程师、PM、独立开发者看完以后，能立刻判断自己该在哪一步把手伸回方向盘。人人都在说 loop，先把两种工作流画清楚 Mic 开场先画了一个最朴素的图：普通人平时的 AI 开发流程，是自己在 Cursor、Claude、Codex 里下指令，让代理先做 landing page，再做登录，再接后端。landing page 做完以后，你会先看看 waitlist 页面是否能见人；登录接好以后，再决定要不要把数据库、权限、邮件通知继续往后推。每一步结果出来以后，你会自己去看、去测、去改，再决定下一步往哪走。这套节奏里，AI 的速度当然重要，决定成败的仍是人一直盯着方向、边界和取舍。他把这叫作 human in the loop。 "human in the loop 的意思是，代理在建，但由你来指挥、治理和批准。" 另一种被热捧的 agentic loop，则是人只进场一次：你把 spec.md、prd.md 或任务单丢进去，代理生成结果，再把结果喂回自己，继续往前跑。Mic 说，这听上去像未来，因为人像是点火的人，机器像是自动巡航系统。两者差别不在于“有没有 AI”，而在于反馈链条由谁持有。这一步如果没想清楚，后面的争论都会变成各说各话。 spec.md 一交出去，假设也一起外包了 Mic 给了一个很直白的类比：假设你和合伙人正在做创业项目，招了一个很聪明的开发，把产品需求讲完以后就让对方自己把整套东西做完，中间一句都不回头确认。开发一定会替你补全很多细节，包含界面怎么摆、流程怎么走、架构怎么选。问题不在于对方不努力，而在于这些补出来的细节，常常对不上你脑子里的产品轮廓。 "你以为计划文档已经覆盖了一切，事实是永远不会。" 他把这件事映射到 loop 上：当你把一摞 markdown 文档交给代理，让它在结果上继续叠结果，代理也会自己补假设。产品里最容易偏掉的，偏偏就是这些没人写进文档的缝隙：按钮文案、错误路径、权限分层、极端输入、移动端细节。Mic 还提到一个服务团队非常熟悉的场景，哪怕你已经和客户反复开会，最后上线前依然会听到一句“我想的是另一种意思”。一旦 loop 获得“自己决定”的空间，速度会上去，偏航概率也会上去。这也是 Mic 反复提醒的第一层风险。 /goal 热归热，20 美元套餐先别上车 Greg 追问得很具体：那最近最火的 /goal 算不算 loop？Mic 的回答非常干脆，名字再多，本质都是同一路东西。你给它一个大任务、附上文档、要求“别停，做完，别出错”，它就会开始自驱工作，还会在每一轮把上一次产物继续当成下一轮输入。Mic 先拦住的是成本账。如果你还在 20 美元或 100 美元档位，光是让它多跑几轮，就可能把当月额度烧穿。他点名提到 Ralph loops、slash loop 之类的玩法，意思都差不多，烧钱速度也差不多。 "如果你不在 200 美元月付档，连想都别想。" 更麻烦的是，用户会被“自动完成整个产品”这层叙事迷住，以为自己只差一份更完整的 PRD。Mic 说，现实正相反：你今天觉得完整的文档，明天就会因为设计趋势、用户反馈、业务目标变化而失效。节目里还提到 Peter 一个月烧掉 130 万美元 token 的例子，那更像是前沿实验预算，不是大多数人该复制的工作方法。预算有限的人最该防的，是自己被自动化的幻觉带进一笔本可避免的 token 账单。小工具和原型能放手，正式产品别放任 Mic 并没有把 loop 一棍子打死。他举了自己做 Among Us 模型模拟器的小项目：他只想要一个能跑的 benchmark，用来测试哪种模型更会撒谎，不在意交互是否精致，也不在意页面长什么样。于是他把目标交给 loop，放手让它跑了大概一个半小时，很多细部都偏了，但项目依然达成了目的。那次任务里，他根本没打算把产品推给真实用户，也没打算花时间抠视觉和文案。当你只要一个能用的实验体，而不追求成品感，loop 的确能替你省掉不少机械工。 "AI 能复制 sauce，做不出 sauce。" 但只要你开始做有真实用户、有品牌感、有细部取舍的产品，Mic 的态度就立刻收紧。因为用户真正买单的，经常是微小的判断：入口顺序、页面密度、动线停顿、描述语气、异常情况怎么收口。这些地方最像手艺活，最依赖人的口味和上下文，也正是 loop 最容易用“差不多”糊过去的地方。所以他承认 loop 有用，但只愿意把它放在失败成本很低的地带。真能每天跑的闭环，是 GitHub 里的代码评审 Mic 自己每天真正在用的 loop，不在产品生成，而在代码评审。他用 Cursor 作为主工作台，用 GitHub 做版本控制，再在 GitHub 里装一个代码评审 agent。Mic 选的是 Greptile ，也顺口提到 Code Rabbit、Microscope 这类同类工具。每次 feature push 上去，评审 agent 都会回一轮 review，指出安全边界、遗漏的 edge case、潜在 bug。Mic 说他最喜欢的也不是长篇评论；最有用的是那个 5 分制打分，它把“代码到底能不能放行”变成了一个更清楚的判断。和一键做产品相比，这一层天然多了一个外部评分器。 "除非分数高于 4/5，我不会让代码进生产。" Mic 给自己定的上线门槛很直：分数不到 4/5，代码就别进生产。于是 loop 的目标不再抽象，它只需要读懂 review、修掉问题、重新 push、等待新一轮打分。当目标被压缩成“把分数拉高”这类可衡量任务时，loop 不再像一辆没人看路的列车，更像一个围着明确信号灯打转的自动工位。 Greptile 打分以后，Cursor 才知道下一轮改什么 Mic 把这套流程包进了一个名叫 grep loop 的 skill。它做的事情并不玄：去 GitHub 读 Greptile 的 review，把里面的缺陷拉回 Cursor，根据建议修代码，再 push 回 GitHub。只要分数还停在 2/5、3/5、4/5，它就继续转，最多五轮，或者一路修到 5/5 为止。每一轮的目标都很窄，代理不用重新理解整个产品愿景，只需要盯着 review 里那几条指出的问题修补。这里的闭环更像代办返修：代理围着别人已经给出的反馈补作业。 "读 GitHub review，改完再 push，直到 5/5 或五轮后停下。" 这也是 Mic 判断 loop 能否落地的标准：它有没有固定反馈引擎。代码评审里，GitHub review 就是那个引擎；SEO 批量页里，公式和模板也能承担类似职责。可一旦任务变成“做一个用户愿意留下来的新产品”，反馈源会从一个分数器变成一堆模糊的人类感受。用户会不会在 onboarding 第三步流失，付费墙是不是出现得太早，按钮文案会不会把人劝退，这些都要靠真实使用和回访才能知道。没有外部信号给方向，loop 跑得越勤，返工概率往往越高。超过 1000 行，连好用的 loop 也会失真 Mic 还专门补了一句让人很清醒的话：哪怕是他最认可的代码评审 loop，也不是无上限好用。只要一次提交超过 1000 行，Greptile 往往就很难把上下文吃透，他几乎拿不到 5/5。回到工程现场，这很好理解：改动面一大，依赖关系、边界条件、回归影响都会暴涨，任何评审 agent 都会开始抓不稳重点。Mic 自己也承认，这时候哪怕模型还在认真工作，review 的噪声也会上升。闭环体积越大，误差越容易堆起来；很多场景收小以后反而更准。 "一旦超过 1000 行代码，我几乎拿不到 5/5。" 所以 Mic 的做法也很工程化：把大的改动拆成多个 PR，让 Cursor 分批推，给 Greptile 留出足够可读的粒度。一个登录改动是一批，一个账单改动是一批，必要时连数据库迁移都单独拆出去。这里能看出一个很实际的判断：你没必要追求“一个 loop 干完所有事”，更成熟的用法是给不同环节配不同大小的循环。 loop 可以是生产力工具，前提是它先服从你的拆分策略，你的工作节奏也要围着可验证粒度来设计。全自动做产品还太早，先把人放回驾驶位 Greg 在后半段给了一个很形象的比喻：很多创业者想像的 loop，就像从迈阿密一路开到查尔斯顿的全自动驾驶，中途没有机会临时靠边、进去一家小餐馆、跟用户聊几句，再根据反馈改路线。产品开发恰恰需要这些中途停车时刻：把东西发给人看，收回吐槽，改掉误判，再决定还往不往前冲。少了这些回头看的站点，loop 很容易把你送到一个“代码完成、产品没成”的终点。 "做产品时，我连自己想要什么都还没完全看清。" Mic 并不否认未来。他明确说，长期看，完全自治的 loop 很可能会到来；Boris 和 Peter 这些站在模型一线的人，本来就在替全行业试错自愈 agent 和大规模 harness。站在 2026 年 6 月 9 日这个时间点，他愿意给出的结论只有一句：人留在环里，依然是现在最好用的 loop。对创业者来说，这是一种更现实的资源分配。你做的是 app、website、SaaS、micro SaaS，还是 agent first startup，都绕不开同一件事：把有限 token 用在最值钱的地方，把用户反馈留在最前面，把方向判断握在自己手里。写在最后如果你今天就想把 agent loop 用起来，更稳的落点，是先把它关进边界清楚、反馈明确、失败成本可控的环里。先把代码评审、测试、批量页面这类工作跑顺，再考虑要不要把产品方向盘交出去。一个很实用的自检方法是看三件事：有没有外部评分器，有没有明确停止条件，有没有你愿意承担的 token 上限。三样都没有，先别把它当生产流程。你也可以给自己设一条更硬的线：凡是需要真实用户审美、业务优先级排序、模糊需求澄清的环节，都先别追求全自动；凡是结果能被打分、能被比对、能被回滚的环节，才值得让 loop 多跑几圈。哪怕只是把“先给 5 个用户试用、收回 10 条吐槽、再改第二版”这种人工检查点写进流程，项目最后跑偏的概率都会低很多。等你把这些护栏装好，再谈无人值守，顺序会健康得多，也更省钱，团队心态也更稳，返工也更少，推进节奏通常更稳。很多时候，克制比炫技更接近交付。内容来源："WTF Is an "AI Agent Loop"? Genius or Hype?"丨Greg Isenberg（嘉宾：Ras Mic）原视频：https://www.youtube.com/watch?v=7clJ8IH784Q No access 08062b25b727e43b76b982692492a5adeb137a5234f3899fed1283412f6dee89 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/ 3uMah1y... 🔗 原文链接： https://mp.weixin.qq.com/s/ 3uMah1y... https://mp.weixin.qq.com/s/ 3uMah1y... 原创 Capihom Capihom 晚点再听LaterCast2026年6月15日 21:27 北京我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "除非你有钱可烧，否则别这么干。" "人留在环里，仍然是最好的 loop。" "代码评审能跑 loop，因为它有固定反馈。" 当大家被 Boris、Peter 和各种演示视频带得热血上头时，多数人手里的订阅预算、产品定义能力、反馈机制，都还撑不起那种一键放手的闭环。访谈也很照顾实操顺序：前面先讲 loop 到底是什么，中段拆 /goal 为何烧钱，后段拿出一条今天就能跑起来的代码评审链路。Mic 最有价值的地方，是把 human in the loop 、 agentic loop 和代码评审 loop 拆成三种不同工作法。工程师、PM、独立开发者看完以后，能立刻判断自己该在哪一步把手伸回方向盘。人人都在说 loop，先把两种工作流画清楚 Mic 开场先画了一个最朴素的图：普通人平时的 AI 开发流程，是自己在 Cursor、Claude、Codex 里下指令，让代理先做 landing page，再做登录，再接后端。landing page 做完以后，你会先看看 waitlist 页面是否能见人；登录接好以后，再决定要不要把数据库、权限、邮件通知继续往后推。每一步结果出来以后，你会自己去看、去测、去改，再决定下一步往哪走。这套节奏里，AI 的速度当然重要，决定成败的仍是人一直盯着方向、边界和取舍。他把这叫作 human in the loop。 "human in the loop 的意思是，代理在建，但由你来指挥、治理和批准。" 另一种被热捧的 agentic loop，则是人只进场一次：你把 spec.md、prd.md 或任务单丢进去，代理生成结果，再把结果喂回自己，继续往前跑。Mic 说，这听上去像未来，因为人像是点火的人，机器像是自动巡航系统。两者差别不在于“有没有 AI”，而在于反馈链条由谁持有。这一步如果没想清楚，后面的争论都会变成各说各话。 spec.md 一交出去，假设也一起外包了 Mic 给了一个很直白的类比：假设你和合伙人正在做创业项目，招了一个很聪明的开发，把产品需求讲完以后就让对方自己把整套东西做完，中间一句都不回头确认。开发一定会替你补全很多细节，包含界面怎么摆、流程怎么走、架构怎么选。问题不在于对方不努力，而在于这些补出来的细节，常常对不上你脑子里的产品轮廓。 "你以为计划文档已经覆盖了一切，事实是永远不会。" 他把这件事映射到 loop 上：当你把一摞 markdown 文档交给代理，让它在结果上继续叠结果，代理也会自己补假设。产品里最容易偏掉的，偏偏就是这些没人写进文档的缝隙：按钮文案、错误路径、权限分层、极端输入、移动端细节。Mic 还提到一个服务团队非常熟悉的场景，哪怕你已经和客户反复开会，最后上线前依然会听到一句“我想的是另一种意思”。一旦 loop 获得“自己决定”的空间，速度会上去，偏航概率也会上去。这也是 Mic 反复提醒的第一层风险。 /goal 热归热，20 美元套餐先别上车 Greg 追问得很具体：那最近最火的 /goal 算不算 loop？Mic 的回答非常干脆，名字再多，本质都是同一路东西。你给它一个大任务、附上文档、要求“别停，做完，别出错”，它就会开始自驱工作，还会在每一轮把上一次产物继续当成下一轮输入。Mic 先拦住的是成本账。如果你还在 20 美元或 100 美元档位，光是让它多跑几轮，就可能把当月额度烧穿。他点名提到 Ralph loops、slash loop 之类的玩法，意思都差不多，烧钱速度也差不多。 "如果你不在 200 美元月付档，连想都别想。" 更麻烦的是，用户会被“自动完成整个产品”这层叙事迷住，以为自己只差一份更完整的 PRD。Mic 说，现实正相反：你今天觉得完整的文档，明天就会因为设计趋势、用户反馈、业务目标变化而失效。节目里还提到 Peter 一个月烧掉 130 万美元 token 的例子，那更像是前沿实验预算，不是大多数人该复制的工作方法。预算有限的人最该防的，是自己被自动化的幻觉带进一笔本可避免的 token 账单。小工具和原型能放手，正式产品别放任 Mic 并没有把 loop 一棍子打死。他举了自己做 Among Us 模型模拟器的小项目：他只想要一个能跑的 benchmark，用来测试哪种模型更会撒谎，不在意交互是否精致，也不在意页面长什么样。于是他把目标交给 loop，放手让它跑了大概一个半小时，很多细部都偏了，但项目依然达成了目的。那次任务里，他根本没打算把产品推给真实用户，也没打算花时间抠视觉和文案。当你只要一个能用的实验体，而不追求成品感，loop 的确能替你省掉不少机械工。 "AI 能复制 sauce，做不出 sauce。" 但只要你开始做有真实用户、有品牌感、有细部取舍的产品，Mic 的态度就立刻收紧。因为用户真正买单的，经常是微小的判断：入口顺序、页面密度、动线停顿、描述语气、异常情况怎么收口。这些地方最像手艺活，最依赖人的口味和上下文，也正是 loop 最容易用“差不多”糊过去的地方。所以他承认 loop 有用，但只愿意把它放在失败成本很低的地带。真能每天跑的闭环，是 GitHub 里的代码评审 Mic 自己每天真正在用的 loop，不在产品生成，而在代码评审。他用 Cursor 作为主工作台，用 GitHub 做版本控制，再在 GitHub 里装一个代码评审 agent。Mic 选的是 Greptile ，也顺口提到 Code Rabbit、Microscope 这类同类工具。每次 feature push 上去，评审 agent 都会回一轮 review，指出安全边界、遗漏的 edge case、潜在 bug。Mic 说他最喜欢的也不是长篇评论；最有用的是那个 5 分制打分，它把“代码到底能不能放行”变成了一个更清楚的判断。和一键做产品相比，这一层天然多了一个外部评分器。 "除非分数高于 4/5，我不会让代码进生产。" Mic 给自己定的上线门槛很直：分数不到 4/5，代码就别进生产。于是 loop 的目标不再抽象，它只需要读懂 review、修掉问题、重新 push、等待新一轮打分。当目标被压缩成“把分数拉高”这类可衡量任务时，loop 不再像一辆没人看路的列车，更像一个围着明确信号灯打转的自动工位。 Greptile 打分以后，Cursor 才知道下一轮改什么 Mic 把这套流程包进了一个名叫 grep loop 的 skill。它做的事情并不玄：去 GitHub 读 Greptile 的 review，把里面的缺陷拉回 Cursor，根据建议修代码，再 push 回 GitHub。只要分数还停在 2/5、3/5、4/5，它就继续转，最多五轮，或者一路修到 5/5 为止。每一轮的目标都很窄，代理不用重新理解整个产品愿景，只需要盯着 review 里那几条指出的问题修补。这里的闭环更像代办返修：代理围着别人已经给出的反馈补作业。 "读 GitHub review，改完再 push，直到 5/5 或五轮后停下。" 这也是 Mic 判断 loop 能否落地的标准：它有没有固定反馈引擎。代码评审里，GitHub review 就是那个引擎；SEO 批量页里，公式和模板也能承担类似职责。可一旦任务变成“做一个用户愿意留下来的新产品”，反馈源会从一个分数器变成一堆模糊的人类感受。用户会不会在 onboarding 第三步流失，付费墙是不是出现得太早，按钮文案会不会把人劝退，这些都要靠真实使用和回访才能知道。没有外部信号给方向，loop 跑得越勤，返工概率往往越高。超过 1000 行，连好用的 loop 也会失真 Mic 还专门补了一句让人很清醒的话：哪怕是他最认可的代码评审 loop，也不是无上限好用。只要一次提交超过 1000 行，Greptile 往往就很难把上下文吃透，他几乎拿不到 5/5。回到工程现场，这很好理解：改动面一大，依赖关系、边界条件、回归影响都会暴涨，任何评审 agent 都会开始抓不稳重点。Mic 自己也承认，这时候哪怕模型还在认真工作，review 的噪声也会上升。闭环体积越大，误差越容易堆起来；很多场景收小以后反而更准。 "一旦超过 1000 行代码，我几乎拿不到 5/5。" 所以 Mic 的做法也很工程化：把大的改动拆成多个 PR，让 Cursor 分批推，给 Greptile 留出足够可读的粒度。一个登录改动是一批，一个账单改动是一批，必要时连数据库迁移都单独拆出去。这里能看出一个很实际的判断：你没必要追求“一个 loop 干完所有事”，更成熟的用法是给不同环节配不同大小的循环。 loop 可以是生产力工具，前提是它先服从你的拆分策略，你的工作节奏也要围着可验证粒度来设计。全自动做产品还太早，先把人放回驾驶位 Greg 在后半段给了一个很形象的比喻：很多创业者想像的 loop，就像从迈阿密一路开到查尔斯顿的全自动驾驶，中途没有机会临时靠边、进去一家小餐馆、跟用户聊几句，再根据反馈改路线。产品开发恰恰需要这些中途停车时刻：把东西发给人看，收回吐槽，改掉误判，再决定还往不往前冲。少了这些回头看的站点，loop 很容易把你送到一个“代码完成、产品没成”的终点。 "做产品时，我连自己想要什么都还没完全看清。" Mic 并不否认未来。他明确说，长期看，完全自治的 loop 很可能会到来；Boris 和 Peter 这些站在模型一线的人，本来就在替全行业试错自愈 agent 和大规模 harness。站在 2026 年 6 月 9 日这个时间点，他愿意给出的结论只有一句：人留在环里，依然是现在最好用的 loop。对创业者来说，这是一种更现实的资源分配。你做的是 app、website、SaaS、micro SaaS，还是 agent first startup，都绕不开同一件事：把有限 token 用在最值钱的地方，把用户反馈留在最前面，把方向判断握在自己手里。写在最后如果你今天就想把 agent loop 用起来，更稳的落点，是先把它关进边界清楚、反馈明确、失败成本可控的环里。先把代码评审、测试、批量页面这类工作跑顺，再考虑要不要把产品方向盘交出去。一个很实用的自检方法是看三件事：有没有外部评分器，有没有明确停止条件，有没有你愿意承担的 token 上限。三样都没有，先别把它当生产流程。你也可以给自己设一条更硬的线：凡是需要真实用户审美、业务优先级排序、模糊需求澄清的环节，都先别追求全自动；凡是结果能被打分、能被比对、能被回滚的环节，才值得让 loop 多跑几圈。哪怕只是把“先给 5 个用户试用、收回 10 条吐槽、再改第二版”这种人工检查点写进流程，项目最后跑偏的概率都会低很多。等你把这些护栏装好，再谈无人值守，顺序会健康得多，也更省钱，团队心态也更稳，返工也更少，推进节奏通常更稳。很多时候，克制比炫技更接近交付。内容来源："WTF Is an "AI Agent Loop"? Genius or Hype?"丨Greg Isenberg（嘉宾：Ras Mic）原视频：https://www.youtube.com/watch?v=7clJ8IH784Q No access 08062b25b727e43b76b982692492a5adeb137a5234f3899fed1283412f6dee89 00:00 No access 08062b25b727e43b76b982692492a5adeb137a5234f3899fed1283412f6dee89 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣

在小宇宙note 阅读完整内容