摘要。这份文件存在的原因是：大多数 Agent 系统的死法不是模型太弱，而是 Harness 太弱。模型可以写代码：生成器可以审阅代码：模型能把自己的输出当成 10 分钟前已经达成的契约去验证。模型自己停不下来、不知道何时重启、不知道把结果写到哪里——这些是 loop 的工作。
本文中我把 loop 当作"一阶对象"：roles 分离、状态写盘、合同在第一行代码写之前已经谈好、Harness 像栈追踪一样可读。短 loop 简单；简单状态、干净合同；其他都是装饰。
关键词：agentic loopsClaude代码harness 设计生成器-评估器模式sprint 规划文件系统状态契约谈判栈追踪阅读可删除脚手架
Prompt 是一次性输完就忘的东西。Loop 是一直跑下去、直到你来关掉它的东西。模型的真正效用从某个时刻开始不再靠"被提示词触发"——而是你找到一个无需监督就能一直运行下去的程序。如果你发现自己在凌晨三点还在迭代同一段消息，你还在 prompt 时代。关掉 tab。写 loop。
Loop 应该是短的：gather、reason、act、verify、repeat。本文中的一切都基于这五个动词。
三个 role、三个上下文窗口、三套系统 prompt。规划师把一段模糊的人类句子转成 sprint spec，碰都不会碰代码。生成器闭门写代码，禁止给自己 grading。评估器读 diff、跑 playground、点开 app，从第一条消息起就被告知"代码是坏的、你的工作是证明它"。
混 role 是最常见的失败。我看见：模型开始自评的那一刻，loop 就悄然滑进 slop。
在生成器写下第一行代码之前，它先提出"完工的成品看起来是什么样"，评估器推回来。两边在 markdown 文件上拉扯，直到达成可测试断言的 checklist。27 条标准对一个 app 已经够用：10 条通常太多，剩下是评估者的橡胶图章。规划师定的 spec 是边界，contract 是达成的终点。
这"达成一次的单次变更"把我自己的 loop 从坏 demo 推进到能用的产品。
Context 窗口是骗人的。它会压缩、腐坏、隐藏一小时之前你说过但没有写下来的东西。把文件放在磁盘上。Keep feature_list.json，progress.md，contract.md，以及 append-only log.md 配 ## [YYYY-MM-DD] op | title entries。模型应该可以 crash、丢会话、从零开始——只要读三个文件就能重新拾起状态。如果不能用三份文件描述你的状态，那你的状态太复杂了。
反直觉的是，目前前沿模型展现出的最好行为是"愿意在 run 走偏时扔掉一切，从头来过"。更老一些的模型会补丁式修补补丁，codebase 因此变得考古学般混乱；更新一些的模型会给一个干净的评估器和 contract 替换盘，让项目在第 9 次迭代时停掉，在第 11 次迭代时出货。合同本身没毛病、运行方式不对时不要打断。合同本身在错而不是 build 错时，才需要人介入。
品味是写得下来的。四个维度，加权：design、originality、craft、functionality。三档 reference 网站，评估器"足够好"与三档全 slop 之间做对比校准。输出是 0-1 的数字和一段解释评分差距的文字。模型没法凭空发明品味；它只会收敛到你所描述的品味。整场游戏就是：把评分标准写得好到"朝着它收敛"恰好是你真心想要的结果。
我关于 agent loop 的每一个调试洞察，都来自读 raw transcript，不是另开一次实验。把 agent 的输出导入文件，grep 一下模型判断跑偏的那一步；把 prompt 改成那一瞬那一刻，再跑一次。这是同样的肌肉和阅读 stack trace 一样，跳过这步去排错就是 vibe。
Harness 存在是为了补偿模型。随着模型变强，你上个季度写的一半内容变成累赘。模型每发一次新版本，Context 重置之间的会话曾是生成器之间的承重墙，sprint 分解曾经是让四小时构建保持连贯的唯一约束——而今都成了单个 0.5 秒就烧掉的承重墙。删掉 harness 跟着模型走、不再免费保留。每次模型变强就删掉 harness；增长中的 harness 就是你不再读它了。
当写码不再卡，规划变卡。当规划解掉，验证变卡。当验证被自动化，品味变卡。你不会 finish；你会找到下一个 bottleneck 来 fix。整个把 loop 摆到下一个 bottleneck 可见处的过程。如果一切顺利，你不会足够小心：找到新的瓶颈，修好它，发一个更小的 harness，重复。