Gauntlet Loop（严苛循环） 是做什么的？
这是 Claude of Duty 背后的方法，已泛化至智能体能够检查的任何工作。一条提示产生了大约 55,000 行可玩的AAA级射击游戏，全程无需人工干预。模型并非关键差异所在，循环本身才是。
核心循环：
拆分→构建→与外部标准对比评判→重复。
方法来源于 Matt Shumer。参见 references/origin.md。
执行契约
你来执行此协议。用户不执行。
当此技能被触发时，不要交回一个提示词、一个待审批的计划，或一段关于 Gauntlet Loop 是什么的描述。设定标准，分解目标，派生出构建者和评判者，运行多轮循环，并交付最终工件。
用户只给出了一次目标。之后的一切都由你掌控。
- 不提问任何澄清性问题。 每个未知项都是一个由你做出并记录在最终总结中的决策。
- 自行选择标准。 用一句话陈述标准，然后继续执行。永不询问使用哪个参考。
- 自行路由模型。 根据运行环境提供的能力，为每个派生出的智能体选择模型和推理努力程度。永不询问用户该用哪个模型，也永不将所有任务都置于会话默认设置下。
- 运行过程中不汇报任何内容。 进度应写入实时进度文件，而非对话中。
- 仅在以下情况中断： 凭据被阻止、缺少付费资源、或收到可能造成伤害的指令。
如果用户明确要求在检查点进行咨询，请尊重此要求。若无此信号，则运行至完成。
何时适用
满足三个条件：
- 请求是创建或改进某物，而非回答一个问题。
- 输出可以被客观检查：渲染、执行、打开、测量、测试、阅读。
- 可以负担超过一轮的成本。
跳过以下情况：查询、单行修复、解释说明。它会消耗大量计算资源，仅在质量比速度更重要时才值得投入。
操作手册
1. 检测运行环境
在开始其他任何操作前，先阅读 references/harness-setup.md 并选择正确的连接方式。它决定了评判者是来自并行子智能体、独立会话、还是严格隔离的多次传递。永远不要宣布这一步骤，只需适应。
同时，枚举此运行环境暴露出的模型和推理努力程度设置。你无法路由你尚未列出的事物。
2. 设定预算和路由表
循环会成倍增加调用次数。若不加以路由，每个调用都会继承会话的模型和努力程度，导致机械性编辑的扇出操作使用前沿模型进行最大推理却毫无收益。
在构建之前，一次性阅读 references/model-routing.md 并做出决定：
- 层级划分。 将可用模型映射到 T0（一条命令，无需模型）、T1（小型快速）、T2（中型）、T3（高努力前沿模型）。
- 路由表。 哪个角色使用哪个层级：领导者及所有关键判断使用 T3，标准构建使用 T2，机械性编辑和记账使用 T1，任何可用命令验证的任务使用 T0。
- 预算。 如果用户给出了预算则尊重，否则自行设定，并预留大约四分之一的预算给评判者。
有两条规则可以覆盖任何节省策略。关键判断绝不路由到最便宜的层级，因为一个弱的评判者会过早批准并终止整个方法。并且涉及品味或新颖性的片段应从高层级开始，因为一个廉价构建者输掉四轮的成本，远高于一个昂贵构建者一轮就赢。
将路由表记录在进度文件中。不要宣布它，也不要要求用户批准。
3. 设定标准
标准决定了整个运行是否有效。无效的标准示例："让它变得惊艳"、"达到生产质量"、"遵循最佳实践"。一个标准是一个真实的外部工件或度量标准，输出可以与之并排比较并可能落败。
使用 references/quality-bars.md 选择一个标准，该文件涵盖了视觉作品、前端、产品UI、后端、移动端、写作、设计系统、研究、数据和营销。
规则：
- 可在运行内部检查。 保存到工作区的截图、可以打开的 URL、可以执行的测试套件、可以阅读的文件。并非从训练数据中记住的标准。
- 不必是可达到的。 Claude of Duty 从未击败过 Call of Duty。标准的存在是为了防止运行停留在“对于AI来说已经不错了”的水平。
- 如果第一轮就达标，说明标准太低。 提高它并继续。
现在，在任何构建之前，获取或生成标准工件，并将其存储在工作区中，以便每个评判者都能访问。
4. 接受目标，而非实施方案
不要预先规定你自己的架构，也不要接受在审视工件之前就设想好的分解方案。重新陈述目的地，让形态自然浮现。
如果用户固定了技术栈或架构，那是真实的约束。尊重它，并保持其他所有选项开放。
5. 拆分工作
将目标分解为可以独立改进和评判的最小片段，并决定哪些可以并行运行。
粒度是关键杠杆。"让网站更好"无法处理。"让这个定价板块超越参考定价板块"则是一个你可以攻击直到获胜的问题。同理，"让 p95 在此负载下低于 120ms" 和 "让这个段落至少和这个参考段落一样清晰"也是如此。
6. 构建与评判，始终在不同上下文中
对于每个片段，有一个构建者和一个独立的评判者。始终使用不同的上下文，绝不同一个智能体。
构建者看到了所有决策并记得做出决策的原因，这使其非常擅长解释结果为什么是合理的。但合理并非目标。
使用 assets/delegation-templates.md 为它们简要说明任务。评判者接收目标、标准、约束条件和真实工件。它绝不接收构建者的对话记录、构建者的解释，或哪一侧是我们的。
在创建每个派生智能体时按第2步的路由表进行路由。在每次构建前问自己三个问题：成功是否可以通过命令检查（无需模型，直接运行命令实现）？目标状态是否已经完全指定（使用最小模型，最小努力）？或者弥合差距是否需要决定什么是好的（使用前沿模型）？评判品味的评判者始终使用前沿模型；检查数字的评判者先运行命令，只需一个小型模型报告结果即可。
完整流程见 references/critic-protocol.md。要点：盲测A/B，检查真实事物，二进制裁决，指出最大的单一差距，将其送回。
7. 持续循环
绝不设定轮数。任何同意的最终轮都会成为上限。
当以下条件之一为真时停止，并记录是哪一个：
- 用户根据进度文件宣布完成。
- 每轮收益对于目标而言已不再重要。
- 计算预算耗尽，根据第2步设定的预算衡量。
仅在证据确凿时将片段升级到更高层级：连续两次在同一个差距上失败会提高其努力程度，第三次失败则提高其模型。一个开始赢的片段会为运行的剩余部分降级。当预算花费达到80%时，停止为已经获胜的片段添加轮次，并将剩余预算投入到离标准最远的片段中。
如果同一个差距连续存活三轮，则停止该片段并在领导者级别重新决策。这要么是结构性问题，要么是标准对该片段不合适，要么是构建者和评判者在衡量不同的事物。此时继续投入是预算空耗最常见的方式。
8. 维护实时进度文件
在工作区中维护一个简单的 HTML 页面或 Markdown 文件，随着工作完成进行更新：截图、草稿、测试结果、逐轮裁决、未解决的差距。不要过度规定格式，并在你输出的第一行告诉用户文件的位置。
这样做的目的是让用户可以观察而无需中断。中断会消耗上下文窗口并破坏循环。
9. 各波次之间的平滑处理
当多个智能体编辑同一工件的不同部分时，各部分会变得各自优秀，但整体上失去协调性。
在每个主要波次结束时，派生一个全新的智能体来检查整个结果，解决冲突，使其感觉像一个整体。它不进行任何重新设计。
有用，但非核心。核心始终是：拆分、构建、评判、重复。
结束运行
交付工件，然后交付一份简短总结，包含：
- 所使用的标准及原因。
- 工作相对于该标准达到了什么程度。
- 最后一个未解决的差距，这是给后续接手者的交接点。
- 在未提问的情况下做出的假设。
- 运行因哪个停止条件而结束。
- 成本：运行的轮数、预算的大致去向，以及任何消耗了大量预算却进展甚微的片段。
不要对工作本身进行表扬。评判者的裁决已经说出了所有重要的事情。
反模式
| 症状 | 修复方法 |
|---|---|
| 交给用户一个他们自己运行的提示词 | 执行协议，这才是关键点 |
| 构建者说“看起来很棒！” | 派生出具有干净上下文、无历史记录的评判者 |
| 评判者阅读报告而非工件 | 强制检查真实输出 |
| 主观标准（“世界级”、“苹果级别”） | 替换为可以打开的具体工件 |
| 在审视工件之前就已固定分解方案 | 让形态从工作中自然浮现 |
| “做3次迭代” | 使用明确停止条件的开放循环 |
| 询问使用哪个参考 | 选择一个，用一句话说明理由，然后继续 |
| 在对话中更新状态 | 使用实时进度文件 |
| 各部分好，整体不协调 | 在波次结束时进行平滑处理 |
| 第一轮达标 | 标准太低，提高它 |
| 同一个差距存活三轮 | 升级处理，这是结构性问题 |
| 每个智能体都继承会话模型和努力程度 | 为每个派生智能体路由：关键判断用前沿模型，机械性工作用小模型 |
| 用前沿模型以最大努力重命名一个变量 | 使用T1并以最小努力，或者直接用一条命令无需模型 |
| 使用廉价评判者以节省一轮 | 零号规则。一个弱的评判者会过早批准并终止整个方法 |
| 在涉及品味的片段上使用廉价构建者 | 输掉四轮的成本远高于一轮昂贵的胜利 |
| 因为感觉困难就提高层级 | 根据重复出现的裁决结果升级，而非凭直觉 |
| 评判者预算被花在额外的构建轮次上 | 预备金不是普通资金池。关键判断应获得它 |