Agent loop 长任务实战笔记

Enivia

2026年7月2日 • 5 分钟阅读

大约 6 周前，Andrej Karpathy 加入了 Anthropic 团队。

他的使命是组建一个新的团队，专门利用 Claude 加速 Claude 自身的训练，并通过模型辅助训练自己的下一个版本。所以这意味着 Karpathy 每天都在处理真正意义上的“长任务”，对 Agent 长时间自主运行有非常宝贵经验。

前几天，他刚刚发布了一份关于长时间运行 Agent Loop 的工作笔记。内容不长，但句句都是干货。

Andrej Karpathy 发布的 loop.md 原文

下面是我的翻译和整理👇。

摘要：这篇笔记之所以存在，是因为大多数 Agent 系统运行效果不佳并非由于模型本身不够强大，而是因为其外壳和运行环境不够健全。

模型可以编写代码、可以评审代码，甚至能够对照十分钟前刚达成的标准来校验自己的输出。然而，它唯独无法独立决定何时停下来、何时重新开始以及把结果写到哪里。而这正是循环（loop）的工作。

本文所阐述的模式将重点讨论循环。角色分离，状态持久化，在写代码之前，不同 Agent 之间就必须协商好契约，且每当运行出错时，就像分析调用栈一样去阅读运行环境的日志。

编写循环，而非编写 prompt

Prompt 是你输入一次便随手抛之脑后的东西，而循环（loop）则是能在你安然入睡时持续运转的程序。

在模型强健到足以在无人看管的情况下遵循特定流程的那一刻起，Prompt 就不再是效率提升的底层杠杆了，真正重要的是流程。

如果你发现自己凌晨三点还在反复微调同一条提示词，那你仍停留在 Prompt 时代。

循环其实非常简单，包含收集、推理、执行、验证、重复几个动作。这份文档中的一切，都是对这五个动词的解释。

角色分离

一次任务的执行，应对应划分三个角色、三个上下文窗口，以及三份系统提示词。

一个规划器，负责将人类模糊的语言转化为开发计划，且绝不触碰代码。
一个生成器，负责编写所有代码，但严禁对自己的工作进行评分。
一个评估器，负责读取代码 diff、运行 playwright 检查应用，并且从一开始就被告知代码是有问题的，而它的任务是证明这一点。

我见过最常见的失败原因就是将这些角色混合使用。

一旦模型开始给自己的作业打分，它就只会一味肯定，导致整个循环最终悄无声息地变成垃圾代码。

先立契约

在「生成器」写下第一行代码之前，它必须先确认“怎么样才能算完成”，然后由「评估器」进行反驳。两者通过磁盘上的 Markdown 文件进行博弈，直到达成一份包含可测试断言的 checklist。

对于一个小型应用而言，27 条衡量标准是个合理的测试规模。如果最终生成的测试只有 10 条数据，最终结果往往就会验证项过少而导致评估器流于形式地“盖章签字”。

「规划器」给出的原始规范是底线，最终参与结果评估的是这份契约。正是这一个小小的改变，让我的自动化运行从只能跑通简单的 Demo，变成了能交付真正可运行的产品。

写入磁盘，而非只考上下文

上下文窗口会撒谎。它们会压缩、会退化，还会用一段并非你所写的摘要将你一小时前说过的话掩藏起来。但磁盘上的文件从不撒谎。

请在项目中保留 feature_list.json、progress.md、contract.md，以及一个仅允许追加内容的 log.md（格式如 ## [YYYY-MM-DD] op | title）。

即使模型中途崩溃、丢失会话，它也应该能通过读取这三个文件快速恢复并继续工作。

如果你无法用三个文件描述你的系统状态，那说明你的状态设计过于复杂了。

允许循环重启

这听起来有点反直觉，但我从目前的尖端前沿模型中看到的最优表现，正是当运行陷入困境时，它们愿意抛弃一切并推倒重来。

老一代的模型会不断打补丁，直至把代码库弄得像屎山一样杂乱无章；而新一代的模型在拥有干净的「评估器」以及磁盘上的「契约」时，会在某次迭代时删掉整个项目，并在之后的几次迭代后交付一个完好的版本。

不要打断这个过程，重启操作正是循环正常运转的表现。只有当「契约」本身出了问题时才需要人工介入，而不是在构建失败的时候。

量化主观审美

只要你能将其写下来，审美也是可以分级评分的。

可以设置四个加权维度：设计、原创性、工艺以及功能性。预先提供「评估器」3 个“优秀”的参考网站，以及 3 个“垃圾”的参考网站来进行校准。输出结果为一个介于 0 到 1 之间的数值，外加一段解释差距的文字。

模型不会凭空创造审美，它只会向你所描述的审美标准靠拢。

整个过程的关键在于，将评分细则写得足够精准，以至于模型在逼近该标准时，所呈现的正是你心中所想。

阅读运行记录

我对 Agent 循环的所有调试感悟，都来源于阅读 Agent 原始的交互轨迹，而不是反复运行新的实验。

把 Agent 的输出重定向到文件中，通过 grep 过滤出它的判断与你的预期发生偏差的那一瞬间，针对该特定时刻修改提示词，然后重新运行。

这与阅读调用栈的逻辑如出一辙。唯一的区别在于，这里的“栈轨迹”是用自然语言写的，且大部分都是模型在自言自语。

越过这一步，你就是在凭感觉进行调试。

精简/删除运行环境

harness/运行环境的存在是为了弥补模型能力的不足。

随着模型的演进，你上个季度写下的代码可能有一半都会变成累赘。之前在每次会话之间重置上下文对某个模型版本来说还是刚需，但在下一代模型中就变得毫无用处了。

任务拆解原本是维持一个四小时构建项目连贯性的唯一手段，如今对于一个能在大脑中装下两小时记忆的模型来说，却反倒成了一种限制。

每当新模型发布时，请重新审视你的 harness，并删掉那些模型现在能够自主搞定的部分。

如果一个 harness 只是在一味的膨胀，那意味着你已经停止阅读它了。

瓶颈永远在转移

当编码不再是瓶颈时，规划就会成为新的瓶颈。规划解决后，验证就成了瓶颈。当验证实现自动化后，审美就成了瓶颈。你永远无法彻底解决所有问题，只能不断寻找下一个需要修复的问题。

循环的全部意义，就在于让下一个瓶颈显现出来。

如果一切运转得过于顺利，说明你观察得还不够仔细。找到新的瓶颈，解决它，交付一个更精简的 harness，如此循环往复。