本文永久链接 – https://tonybai.com/2026/07/02/loops-md-notes-on-agents-that-run-for-days
大家好，我是Tony Bai。
在过去的一两年里，几乎每个与大模型打交道的开发者都经历过这样一种“深夜玄学”：
为了让 Agent 完成一个复杂的任务，你坐在屏幕前，疯狂地修改 System Prompt，不断地增减词汇、调整语气、甚至加上“我会给你 200 美元小费”或“这对我真的很重要”这种情绪诱导。
然而，一旦任务的复杂度提升，或者运行时间拉长到几个小时甚至几天，你会发现仅凭 Prompt 构建的 Agent 系统脆弱得像一座沙雕：上下文开始腐化、模型开始自我谄媚、稍微遇到一点网络抖动或编译报错，整个任务就会彻底跑偏、原地崩溃。
“Demo 很惊艳，落地就抓狂”，成为了当下 Agent 创业和工程化道路上最大的拦路虎。
近期，坊间流传着前特斯拉 Autopilot 负责人、OpenAI 联合创始人、今年才加入Anthropic的独立研究员 Andrej Karpathy的一篇技术手记——《LOOPS.md: Field Notes on Agents That Run for Days》，如同一记重锤，砸醒了所有还在和 Prompt 死磕的开发者。
Karpathy 敏锐地指出：制约 Agent 落地的瓶颈，早已不再是模型本身的智商，而是我们为模型搭建的Harness。
随着模型理解力的飞跃，纯粹调整提示词的“Prompt Engineering”正在迅速贬值；取而代之的，是关注系统控制流、状态持久化和多角色博弈的 “Loop Engineering（循环工程）”。
在这篇干货满满的现场笔记中，Karpathy 毫无保留地分享了他如何让 Agent 独立、稳定地自主运行数天，并最终交付真正可用产品的 9 条黄金法则。
无论你是在进行 AI 创业、还是正在做 Agent 落地，这篇短小精悍的指南，都将彻底刷新你的工程世界观。以下为译文全文：
市面上大多数 Agent 系统的失败，根源往往不在于模型能力太弱，而在于其底层的Harness设计得太差。模型会写代码、会审查代码，甚至能对照自己十分钟前刚同意的评估标准来验证自己的输出。
但是，模型自己无法决定什么时候该停下来、什么时候该推倒重来，以及把最终结果写到哪里。
这些控制流的工作，必须由循环（Loop）来完成。本文提出了一种设计范式，将“循环”视为系统中的一等公民（First-Class Object）：角色彻底分离、状态持久化到磁盘、在写第一行代码前先完成 Agent 间的合同协商，并在出错时像阅读调用栈（Stack Trace）一样去审视Harness。
极简的循环、简单的状态、清晰的合同。除此以外，皆是点缀。
关键词：Agent 循环（Agentic Loops）、Claude Code、框架设计、生成-评估模式、Sprint 规划、文件系统状态、合同协商、Trace 阅读、可拆卸脚手架。
别再写 Prompt 了，去写循环（Write the Loop, Not the Prompt）
Prompt 是一种“写完一次就扔”的东西。而循环（Loop），则是你躺在床上睡觉时，依然在后台为你不知疲倦运行的系统。
在模型已经聪明到无需人类监督就能遵循复杂流程的那一刻起，提示词（Prompt）的杠杆效应就已经见顶了。现在真正拉开差距的，是流程（Procedure）。如果你发现自己凌晨三点还在反复调试某一个 Prompt，那你还停留在“提示词时代”。请关掉那个 Playground 标签页，开始写循环吧。
一个标准的循环其实非常精简：收集、推理、行动、验证、重复（Gather, Reason, Act, Verify, Repeat）。本文接下来的所有内容，不过是这五个动词的注脚。
彻底分离角色（Separate the Roles）
你需要准备三个角色、三个上下文窗口、三套系统提示词（System Prompts）：
- 规划者（Planner）：负责将人类模糊的语言转化为具体的 Sprint 开发需求（Spec），它绝不能碰代码。
- 生成者（Generator）：负责编写所有代码，但严禁给自己的工作打分。
- 评估者（Evaluator）：负责读取代码差异（Diff）、启动 Playwright、实际运行并测试应用。它从被唤醒的第一秒起，就被告知“这代码肯定有 Bug”，它的唯一任务就是找出证据来证明这一点。
把这些角色混为一谈，是我见过最常见的系统设计失败。一旦模型开始“既当裁判又当选手”（自我评分），它就会立刻变得谄媚，整个循环最终会悄无声息地收敛出一堆毫无用处的代码垃圾（Slop）。
先协商“合同”（Negotiate the Contract First）
在生成者写下第一行代码之前，它必须先提出一份“如何才算完成”的定义，而评估者则会予以反驳。
这两个 Agent 应该通过磁盘上的 Markdown 文件进行反复拉锯和辩论，直到它们达成共识，并输出一份由一系列可测试的断言（Testable Assertions）组成的清单。
对于一个小型应用，27 条评估标准是一个很合理的规模；10 条通常太少，容易让评估者放水放行。规划者给出的原始 Spec 是这个系统的边界，但只有这份协商出的“合同”，才是最终决定考核成绩的唯一标准。
这是我个人在开发 Agent 时，让系统从只能跑跑“破碎的 Demo”，到能真正交付“可用产品”的最关键的一次改变。
状态写入磁盘，别塞进上下文（Write to Disk, Not to Context）
LLM 的上下文窗口（Context Window）是会撒谎的。它们会发生信息压缩、会随着对话变长而退化、会把你一小时前说的话悄悄隐藏在一段它自己生成的摘要后面。
但磁盘上的文件不会撒谎。
在你的工作目录里保持这几个文件：feature_list.json（功能列表）、progress.md（进度）、contract.md（合同），以及一个只允许追加写入的 log.md（日志格式为：## [YYYY-MM-DD] op | title）。
你的 Agent 应该具备这样的鲁棒性：即使它中途崩溃、会话丢失，也能够仅仅通过阅读这三个文件，就完美地在断点处重新接起任务。如果你无法用三个文件向模型描述清楚当前的状态，说明你的系统状态设计得太复杂了。
允许循环“推倒重来”（Let the Loop Restart）
这可能有些违反直觉：在目前最前沿的模型中，我观察到的最佳行为之一，是当它们发现开发走进了死胡同、代码被改烂时，表现出了一种极强的“把所有东西扔掉，彻底重来”的意愿。
老一代的模型会不断地给坏代码打补丁，直到整个代码库看起来像一个层层堆叠的考古遗迹；而新一代的模型，在拥有一个干净的评估器和一份写在磁盘上的合同的前提下，会在第 9 次迭代时果断删掉整个项目，并在第 11 次迭代时交付一个完好无损的版本。
不要去打断这种“删库重来”的行为。重启，正是循环在正确发挥作用的体现。
只有当“合同本身定错了”时才需要人类介入，构建失败（Build Failures）不需要你插手。
给主观体验量化打分（Score the Subjective）
只要你肯把它写下来，“审美和品味”就是可以被评分的。
在你的评估器中设置四个加权维度：设计、原创性、工艺、功能性（Design, Originality, Craft, Functionality）。
如何对评估者进行校准？告诉它：这三个参考网站是“好品味”的典范，而另外那三个则是“工业垃圾(Slop)”。最终的输出应该是一个 0 到 1 之间的数字，外加一段解释差距在哪里的段落。
模型不会自己凭空创造出独特的品味，它只会向你描述的那个“品味指标”去收敛。这整场游戏的核心，就在于把你的评估标准制定得足够小心和精准，使得模型向它收敛的过程，恰好就是你真正想要的结果。
像读栈追踪一样读日志（Read the Traces）
我对 Agent 循环的所有调试灵感，无一例外来自于阅读原始的运行日志（Transcript/Traces），而不是来自盲目地做下一次实验。
将 Agent 的完整输出重定向到一个文件中。用 grep 去搜索那个“它的判断开始与你的意图产生分歧”的瞬间。针对那个特定瞬间的上下文去修改 Prompt，然后重新运行。
这和你阅读程序的 stack trace 锻炼的是同一块肌肉。唯一的区别在于，这里的 Trace 是用自然语言的英文写的，而且大部分是模型在自言自语。跳过这一步，你就是在仅凭“玄学和感觉（Vibe）”来调优系统。
随时准备删除你的Harness（Delete the Harness）
Harness的存在，本质上是为了弥补当前模型的缺陷。
随着模型能力的迅速迭代，你上个季度写的一半控制代码，在今天都会变成多余的开销。比如，会话之间的上下文重置，在上一代模型中是关键的支柱设计，到了新一代模型里就成了累赘；又比如，任务的 Sprint 级拆解，曾经是维持四小时长构建不跑偏的唯一手段，现在却成了限制新模型的枷锁（因为新一代模型已经能轻松在大脑中塞下两小时的上下文）。
每当有新模型发布时，对照它重新审视你的Harness，删掉所有模型现在已经能自主搞定的逻辑。一个只会单调膨胀、只加不减的Harness，说明你已经看不懂、也不再阅读它了。
瓶颈永远在移动（The Bottleneck Always Moves）
当编写代码（Coding）不再是瓶颈时，系统规划（Planning）就变成了瓶颈。
当规划问题被解决，结果验证（Verification）就变成了瓶颈。
当验证实现自动化后，主观品味（Taste）就变成了瓶颈。
在这个领域，你永远没有“大功告成”的那天；你只是在不断寻找下一个需要修补的漏洞。
设计循环的唯一目的，就是为了让下一个瓶颈清晰地暴露出来。 如果你的系统运行得无比顺滑、毫无阻碍，那只能说明你观察得还不够仔细。
找到那个新出现的瓶颈，干掉它，把Harness重构得更轻量，然后——
开启下一次循环。
小结
如果说过去一两年是“提示词工程师（Prompt Engineer）”的狂欢，那么这篇《LOOPS.md》笔记无疑标志着我们正式步入了“系统级循环工程师（Loop Engineer）”的时代。
正如 Karpathy 在文中反复强调的那样：在极其聪明的下一代大模型面前，过度的微操反而是对其潜力的压抑。用“规划-生成-评估”的稳定三层结构分离角色，用真实的本地文件（而不是脆弱的上下文）固定状态，把验收标准前置为可执行的“合同”——这套流程实际上与最经典的人类软件工程方法论不谋而合。
技术的形式在变，但工程的本质从未改变：管理复杂性，消除不确定性。 也许下一次，当你面对一个频频跑偏的 Agent 时，不妨停下修改提示词的手，审视一下支撑它运转的那条“循环”。
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
