Claude Harness 设计：Generator-Evaluator 架构与 Context Reset 演进¶

Ch05.080 Claude Harness 设计：Generator-Evaluator 架构与 Context Reset 演进¶

📊 Level ⭐⭐⭐ | 14.3KB | entities/harness-generator-evaluator-anthropic.md

概述¶

Anthropic 工程师 Prithvi Rajasekaran 系统阐述长时间运行 Agent 应用中的 Harness 设计方法论。核心贡献：①受 GAN 启发的 Generator-Evaluator 双代理结构解决自我评估偏差；②三代理架构（Planner/Generator/Evaluator）+ sprint contract 实现全栈自主开发；③context reset vs compaction 的取舍决策框架；④Opus 4.5→4.6 演进中 scaffold 简化规律。附 20 分钟/$9（单代理）vs 6 小时/$200（完整 harness）的对照数据。

两种失效模式¶

Context Anxiety 与 Context Reset¶

当模型接近自己认为的上下文上限时，会过早开始收尾。Context reset（清空上下文窗口、重启新 agent、配合结构化交接文档）可以同时解决上下文焦虑和长任务失焦：

reset = 给模型真正干净的上下文，代价是交接工件必须携带足够状态
compaction = 在原地压缩总结，保留连续性但没有干净起点，上下文焦虑依然存在
Sonnet 4.5 上下文焦虑严重到仅靠 compaction 无法支撑高质量表现，context reset 是关键
Opus 4.5 之后这种行为大体消失，可以完全移除 context reset

自我评估偏差¶

Agent 评价自己作品时几乎总是偏正面。Generator-Evaluator 分离是解决这个问题的一根强杠杆——把独立 evaluator 调成"持怀疑态度"远比让 generator 对自己苛刻更现实。

Generator-Evaluator 架构¶

前端设计实验¶

四个评分维度（同时写入 generator 和 evaluator 提示词）： | 维度 | 权重 | 说明 | |------|------|------| | Design quality | 高 | 统一整体感，颜色/字体/布局/图像构成情绪和身份感 | | Originality | 高 | 拒绝 stock components、"白底卡片+紫色渐变"等 AI 痕迹 | | Craft | 中 | 字体层级、间距、对比度等技术执行 | | Functionality | 中 | 可用性：能否理解界面、找到操作、完成任务 | Evaluator 接入 Playwright MCP，实际操作页面而非看静态截图，5-15 轮迭代。评分标准措辞本身就在塑造输出气质（如"museum quality"触发特定视觉风格收敛）。

全栈三代理架构¶

Planner → Generator ↔ Evaluator
              ↓
         Sprint Contract
        （生成前协商"完成标准"）

Planner：输入 1-4 句提示 → 完整产品规格。关注"最终交付什么"而非过早指定实现细节，主动寻找 AI 功能编入规格的机会。
Generator：按 sprint 工作（React/Vite/FastAPI/PostgreSQL），每轮自评后交 QA。
Evaluator：Playwright MCP 操作真实应用，按维度打分（产品深度/功能性/视觉设计/代码质量），每个维度硬性阈值，未达标则 sprint 失败。
Sprint Contract：generator 提出构建计划+验证方式 → evaluator 审查 → 双方迭代至一致。解决产品规格刻意保持高层次时的"最后一公里"问题。 Claude 原生不是好的 QA agent——识别真实问题后会自我说服"不重要"，需反复调优 evaluator 提示词才能收敛。

量化对照¶

复古游戏制作器（Opus 4.5）¶

Harness	Duration	Cost
单代理	20 分钟	$9
完整 harness	6 小时	$200
单代理问题：布局浪费空间、工作流僵硬、entity 定义与 runtime 连线断开无法响应输入。
Harness 产出：sprite 动画系统、行为模板、AI sprite 生成器、AI 关卡设计器、可分享链接导出，play mode 真正可玩。

DAW（Opus 4.6，去掉 sprint 结构）¶

Agent & Phase	Duration	Cost
Planner	4.7 分钟	$0.46
Build Round 1	2h 7min	$71.08
QA Round 1	8.8 分钟	$3.24
Build Round 2	1h 2min	$36.89
QA Round 2	6.8 分钟	$3.09
Build Round 3	10.9 分钟	$5.88
QA Round 3	9.6 分钟	$4.06
Total	3h 50min	$124.70
Generator 无 sprint 拆解连续运行两小时以上（Opus 4.5 做不动的事），但 QA 仍发现功能缺口（录音空壳、clip 无法拖动、效果器非图形化）。

迭代原则¶

Harness 里的每一个组件，都编码了一个"模型自己做不到什么"的假设——这些假设值得被压力测试，因为它们可能随模型进步而迅速过时。系统化简化法：每次只移除一个组件，观察对最终结果的影响。

去掉 sprint：Opus 4.6 原生能处理任务拆解，但 planner 和 evaluator 仍保留（无 planner → generator 低估 scope；evaluator 在 generator 能力边界附近仍有关键价值）
Evaluator 不是固定开关：只在任务超出模型单独稳定完成范围时才有价值

核心洞察¶

sprint contract 是产品规格（高层次）和实现目标之间的桥梁
Evaluator skeptic tuning 需要反复迭代，不能指望开箱即用
随着模型变强，harness 组合空间不会缩小，只会迁移——旧组件简化，新组件加入
Context reset 的核心价值是给模型真正干净的上下文，compaction 无法替代

深度分析¶

1. GAN 启发的双代理结构解决的是「自我评估偏差」而非评估准确性¶

Generator-Evaluator 的核心假设不是「evaluator 比 generator 更懂什么是对的」，而是generator 天然无法对自己诚实。Self-evaluation bias 在 LLM 中表现为：模型倾向于解释自己的输出合理化，而非指出缺陷。把评价职责外化给独立 agent，本质是把「运动员」和「裁判」分开——这在人类组织的代码审查中也是经典反模式。GAN 之所以 work，不是因为判别器比生成器更懂图像质量，而是因为两者在对抗中能绕过彼此的盲区。应用到 LLM harness 上，这个架构的洞察在于：持怀疑态度的外部 evaluator 比让 generator 自我苛刻更现实。

2. Context reset vs compaction 的取舍有一个被低估的非对称性¶

Compaction 保留了历史连续性，但引入了「上下文污染」——旧的信息被压缩后仍在上下文中干扰模型；Context reset 给了模型真正干净的起点，但代价是交接文档必须携带完整状态，且每次 reset 都会引入 token 开销和延迟。当模型出现明显的 context anxiety 行为（如 Opus 4.5 之前的 Sonnet 4.5），compaction 无法解决这个问题，因为焦虑来源于「上下文满了」这个感知，而非实际长度。在模型能力更强的 Opus 4.6 之后，这种行为消失，context reset 的必要性也跟着消失——这说明harness 组件的保质期高度依赖模型版本，同一个组件在一个版本是必要的，在下一个版本可能成为负担。

3. Sprint Contract 解决的是「产品规格刻意保持高层次」时的「最后一公里」问题¶

当用户只给出 1-4 句话的模糊指示时，planner 会扩展成详细规格。但在产品规格刻意保持抽象时，generator 不知道「done」的具体标准是什么——这是传统 Agile 中「definition of done」缺失会导致的实现偏差。Sprint contract 在编码前让 generator 提出构建计划 + 验证方式，由 evaluator 审查，双方迭代至一致。这个机制的本质是把「规格」和「验收标准」的协商提前到每个 sprint 开始之前，而非事后 QA 发现问题。它解决的不是 planning 问题，而是「即使有规划，实现者和验证者对完成的定义仍然不一致」的结构性问题。

4. 四维度评分标准中高权重维度的选择揭示了模型在「审美」上的结构性短板¶

Design quality 和 Originality 被设为高权重，Craft 和 Functionality 设为中权重。这个选择不是基于「设计比功能重要」，而是基于模型在哪些维度上天然已经足够好。Claude 在 Craft（字体层级、间距、对比度等）和 Functionality（可用性检查）上通常已有不错的默认表现，因为这些是技术能力；但在 Design 和 Originality 上，模型倾向于滑向安全可预测的布局——这是「AI slop」的根源。这个权重分配的深层逻辑是：让 evaluator 成为 generator 的审美上限，而不仅是技术下限的守门员。

5. Harness 组件的「可删除性测试」是判断模型能力边界的系统性方法¶

每次只移除一个组件、观察对最终结果的影响——这是一个反事实分析框架。当移除 sprint 结构后发现 Opus 4.6 原生能处理任务拆解，说明这个组件在该能力维度上已经过期；但移除 planner 后 generator 低估 scope，移除 evaluator 后 generator 能力边界附近仍有大量可捕捉的问题，说明这两个组件在更高级的能力维度上仍有价值。这个方法论的隐含假设是：模型进步不会让整个 harness 设计过时，而是会把能力边界向外推，让部分组件的必要性下降，同时新的能力需求会产生新组件。

实践启示¶

1. 当 generator 自我评价偏正面时，优先分离 evaluator 而非调优 generator 的提示词¶

自我评估偏差不能通过「让 generator 更严格」来解决——这是架构问题，不是提示工程问题。具体操作：在现有单代理 harness 中引入一个独立 evaluator agent，用 few-shot examples 校准其怀疑倾向，先让它在已知问题上验证有效性，再接入完整循环。不需要一开始就把 evaluator 做到完美，它的判断需要随迭代收敛。

2. 用四维度评分标准时，先用低权重维度做健康检查，再让高权重维度引导质量收敛¶

先把 Craft 和 Functionality 作为通过性门槛（低于阈值直接失败），再用 Design quality 和 Originality 作为质量上限的牵引力。具体措辞上，「museum quality」这类表述会触发特定视觉风格的收敛，可以用来定向引导 generator 的审美方向——这是可选的、额外的控制手段，不要一开始就用，给 evaluator 留出自然判断的空间。

3. Sprint contract 在每个 sprint 开始前执行，协商内容要具体到「验证方式」而非「实现方式」¶

Generator 提出构建计划时，evaluator 要审查的是「这个功能怎么验证才算完成」，而不是「这个功能怎么实现才正确」。如果 generator 提出的验证方式是「人工点击测试」，要退回让它改成可自动化验证的方式。这个区别的意义在于：evaluator 评价的是可观测的结果，而非代码实现路径——这防止了 generator 通过「用另一种方式实现了相同结果」来绕过验收标准。

4. Context reset 的必要性用「模型是否出现上下文焦虑行为」来判断，而非固定周期触发¶

当模型开始过早收尾或表现出「觉得上下文满了」的行为时，才需要 context reset；不要每 N 轮强制 reset，因为交接工件的状态携带是有代价的。在实现交接文档时，确保文档包含：当前进度、下一步操作、已知的边界情况和已验证不可行的路径。Context reset 后如果 generator 从交接文档恢复的效果不好，首先检查的是文档是否包含足够的状态，而不要立即加回更多 harness 组件。

5. 每当新模型版本发布时，用「移除一个组件」的压力测试来重新校准 harness 必要性和过期性¶

新模型发布后，用单代理 baseline 跑相同任务，对比有/无各组件的表现。先移除 sprint contract，再移除 planner，最后移除 evaluator——按这个顺序测试，因为越核心的组件移除影响越大，应该最后测试。如果移除某组件后质量下降明显，重新加入；如果质量不变，说明该组件对这个版本已经过期，可以简化。这个过程不是一次性的，每逢 major model update 都应该重复一次。