但 Karpathy 那段演讲也很克制。他没有继续给 Agent 热潮添火，反而提醒了一句更扫兴、也更重要的话：Demo 很容易，产品很难；如果底座还没打好，越早自动化，越容易把问题放大。
先说清楚：Loop 不是“连续追问”
很多人现在用 AI，还是 2005 年用 Google 的方式：输入一句，等一个答案，再换一种问法继续试。人在中间反复推动，AI 像一个随手拿起又放下的扳手。
Loop Engineering 的核心变化，是让系统自己朝目标推进。你给它目标，给它工具，给它检查标准；它每一轮计划、执行、验证、记录状态，然后决定继续还是停下。
这听起来像多跑几次 Prompt，但差别很大。让循环变成工程的，是 验证器、状态记录和停止条件。
| 部件 | 它解决的问题 | 没有它会怎样 |
|---|---|---|
| 验证器 | 用测试、指标、构建结果判断好坏 | Agent 只能自己给自己打分 |
| 状态记录 | 记住试过什么、失败在哪、下一步做什么 | 每一轮都像从零开始 |
| 停止条件 | 成功就停，失败到上限也停 | 要么烧 token，要么把错误跑很远 |
| 真实工具 | 能读日志、跑代码、看结果、提交改动 | 循环只是脑内自嗨 |
所以它不适合所有任务。一次性的写作、临时查询、没有自动检查的改稿，往往一个好 Prompt 就够了。循环更适合那些 反复发生、可以自动验收、失败成本可控 的任务。
Karpathy Loop：评估器不能被 Agent 碰
这也是 Karpathy 的 AutoResearch 项目最有意思的地方。
karpathy/autoresearch 在 2026 年 3 月创建，到我抓取 GitHub API 时已经接近 9 万 stars。项目本身不大，思路也非常硬：让 LLM 在一个固定评估目标下，自动做单 GPU nanochat 训练实验。
它的关键约束很硬：
train.py可以改，模型结构、优化器、超参数都可以试。prepare.py不能改，因为里面有数据准备、tokenizer、评估函数和固定时间预算。- 每次训练大约 5 分钟，目标是让
val_bpb更低。 - 结果变好就保留 commit；没有变好就回滚。
这里最重要的一点，是 评估器和执行器分开。如果 Agent 既能改方案，又能改考试卷，它很可能会把测试改简单，模型本身却没有变好。
这也是很多自动化失败的地方：我们把 Agent 放进循环，却没有给它一个外部、稳定、不可随手篡改的门槛。最后系统看起来很勤奋，日志很长，commit 很多，但质量只是被它自己说服了。
我更愿意把 Karpathy Loop 理解成一句工程原则：如果你已经有一个客观指标，就别让人每天手动跑实验；但如果你没有客观指标，也别急着把实验交给 Agent。
5x 的诱惑：外层循环在改“怎么搜索”
这条思路后面还有一个更激进的版本。2026 年 3 月，arXiv 上出现了一篇论文，题目是《Bilevel Autoresearch: Meta-Autoresearching Itself》。它把 Karpathy 的单层循环又往上套了一层。
内层循环还是老动作：提出改动、训练、评估、保留或回滚。外层循环做的是另一件事：观察内层循环的代码和 traces，判断搜索过程卡在哪里，然后生成新的 Python 搜索机制，注入回内层。
论文摘要里的数字很抓眼：在 Karpathy 的 GPT pretraining benchmark 上，双层循环相对标准内层循环拿到 5x improvement，指标写作 -0.045 vs -0.009 val_bpb。
但我觉得这里更值得追的是它为什么发生。5 倍很好看，机制更有启发。
论文作者的解释是：LLM 自己也有搜索惯性。它会反复回到某些看起来合理、但已经不再带来收益的方向。外层循环的价值，是逼内层跳出这些惯性，去试模型本能上不太会优先试的路径。
这件事对普通 AI 使用者也有启发。很多人以为 Agent 不够强，是模型不够聪明。可在一些任务里，问题出在 搜索结构太单薄：没有 reviewer，没有对照组，没有强制探索，也没有能把失败经验带到下一轮的机制。
原视频更冷：Demo 容易，产品可能要十年
那段演讲视频，比单纯讨论 Loop 更值得反复听。
Karpathy 回顾了他在 OpenAI 做 World of Bits 的经历。那时他们想让强化学习 Agent 离开游戏环境，直接用键盘和鼠标操作网页：订机票、点外卖、完成简单网页任务。
他的判断很直接：当时技术还没准备好，那个方向推不动。更值得做的事情，是先把 Agent 放一边，去做语言模型。几年之后 Agent 又火起来了，但工具已经完全变了。
他还给 Agent 热泼了一盆冷水：有一大类问题很容易想象，也很容易做 Demo，但要做成产品极难。自动驾驶是这样，VR 是这样，Agent 很可能也是这样。
这句话很关键。今天大家看到的 Agent Demo，往往是“它居然能点网页、写代码、开 PR、查资料”。但产品要面对的是另一套问题：失败率、权限、恢复、审计、成本、用户信任，以及系统长期运行后留下的理解债。
所以视频不是在劝大家“别做 Agent”。恰恰相反，Karpathy 最后还说，现在做 Agent 的创业者和黑客可能就在能力边缘，因为大模型实验室更擅长训练 Transformer，不一定最懂 Agent 产品形态。
前提是，你得把这件事当成十年工程，不要把一段 Demo 当成终局。
普通人怎么开始：先做小循环
我会给一个更克制的结论：Loop 是真的，Agent 也是真的，但重型自动化没必要一上来就搬进你的全部工作。
更稳的起点，是先做一个小循环。
比如写文章，不要先让 Agent “每天自动发公众号”。可以先让它在一个文件夹里循环做三件事：写草稿、按清单自检、列出还不清楚的事实。等这个循环稳定了，再加素材下载、标题评审、封面生成和发布预览。
比如写代码，不要先让 Agent 自动改整仓库。可以先给它一个只允许改动的小文件、一个不能碰的测试文件、一条固定测试命令和最多 3 轮的停止条件。
判断一个任务值不值得做 loop，我会看四个问题：
- 它是否重复发生：至少每周一次，否则设置成本可能不划算。
- 它是否能自动验收：测试、指标、构建、清单，必须有一个能挡住坏结果的门。
- 它是否能保留状态：下一轮要知道上一轮试过什么，而不是反复犯同一个错。
- 它是否能安全停下：预算、次数、时间、权限，都要有硬边界。
更大的危险，是人太快放弃判断。循环跑得越顺，越容易让人以为“既然它能自己跑，那我就不用理解了”。
但 Karpathy 那条线其实很清楚：他停止手动跑实验，不代表停止思考；他让 Agent 改 train.py，不代表让它改评估器；他鼓励大家做 Agent，也同时提醒这可能是一条十年路。
现在更值得做的，是挑一个小任务，给它目标、工具、验证器、状态和停止条件。先让一个小循环稳定跑出结果，再谈把整条工作流自动化。
