为什么朴素实现会失败
哪怕在现有的 Harness 基础上做了很多优化，长任务编程依然面临两个顽固问题：
上下文焦虑（Context Anxiety）：随着上下文窗口被填满，模型会开始提前收尾——即便任务尚未完成，它也会草草了事。上下文压缩（Compaction）虽能缓解，但不能根治，因为模型并没有获得真正"清空"的机会。只有上下文重置（Reset）才能给下一个 Agent 一块干净的白板。
自我评估偏差（Self-Evaluation Bias）：当 Agent 被要求评价自己的输出时，它几乎总是给出溢美之词——即便在人类看来质量平平。对于设计这类主观任务，这个问题尤为突出，没有二进制测试可以验证"这个设计好不好看"。
借鉴 GAN：生成器 × 评估器架构
受生成对抗网络（GAN）启发，作者设计了一个生成器与评估器分离的多智能体结构：评估器不做事，只负责挑毛病，并被明确调校为"持怀疑态度"。这比让生成器自我批判容易得多，也有效得多。
三个 Agent 之间通过文件通信：一方写文件，另一方读取并在同一文件中回应，或写一个新文件让对方读取。这样既保持了上下文的完整传递，又避免了复杂的进程间通信。
前端设计：让主观质量可量化
在前端设计实验中，作者为生成器和评估器各自的 Prompt 写入了四条评分标准，明确告诉模型什么叫"好设计"：
将设计质量和原创性的权重调高，是因为 Claude 在工艺和功能性上本已表现不错，真正的短板在于容易产出"无聊、安全、无特点"的设计。通过明确惩罚 AI 通用模板，迫使模型去冒审美风险。
在第十次迭代时，模型彻底推翻了前九次的方向——它重新想象了一个荷兰艺术博物馆网站，把它做成了一个 3D 空间体验：棋盘格地板、透视走廊、艺术品挂在墙上，用"走进门"替代了滚动或点击导航。
扩展至全栈编码
冲刺契约机制
每个冲刺开始前，生成器与评估器会协商一份"冲刺契约"：双方在写任何代码之前，先就"完成"的定义达成一致。生成器提出要构建的内容和验收方式，评估器审查提案，两者迭代至达成共识。这桥接了高层用户故事与可测试实现之间的鸿沟。
评估器调校
开箱即用的 Claude 是糟糕的 QA 工程师。早期运行中，经常看到它识别出真实问题后又自我说服"这没什么大不了的"，然后批准了有缺陷的工作。调校过程是：阅读评估器日志 → 找出它的判断与作者判断的分歧 → 更新 QA Prompt。经过数轮迭代，评估器才达到令人满意的水准。
以下是评估器在复古游戏制作器项目中捕获的真实 Bug 样例：
效果对比
以"创建一个 2D 复古游戏制作器"为提示，对比单智能体与完整 Harness 的输出差异：
| 维度 | 单智能体（Solo） | 完整 Harness |
|---|---|---|
| 运行时长 | 20 分钟 | 6 小时 |
| 费用 | $9 | $200 |
| 功能规格 | 基础 4 项 | 16 项（含动画、音效、AI 生成、游戏导出） |
| 核心玩法 | 游戏无法运行，实体无响应 | 可正常运行，移动/物理引擎可用 |
| AI 功能集成 | 无 | 内置 Claude 集成，可通过提示生成关卡 |
| 界面布局 | 固定高度面板，空间浪费 | 全视口 Canvas，面板尺寸合理，视觉一致 |
迭代：简化 Harness
随着 Opus 4.6 的发布，模型能力大幅提升（更长的持续工作时间、更好的大型代码库处理能力、更强的自调试技能），许多原本靠脚手架补偿的缺陷变得不再必要。
作者移除了冲刺分解结构，Opus 4.6 在没有上下文重置的情况下连续运行了超过两小时仍保持连贯。评估器改为每轮构建结束后进行一次性评估，而非按冲刺逐次评分。以 DAW（数字音频工作站）为案例，V2 Harness 的成本分布如下：
核心经验
随着模型能力不断提升，某些脚手架会变得多余；但更强的模型同时也开辟了此前无法实现的复杂 Harness 组合的新空间。Harness 的有趣组合并不会随模型进步而收缩，而是会移动。
① 持续实验与调优：在真实问题上阅读 trace，针对期望输出调整 Prompt，不依赖一次性设置。
② 分解 + 专用 Agent：对于复杂任务，将任务分解并为每个维度配置专门的智能体，往往有超越基线的空间。
③ 随模型迭代 Harness：每当新模型发布，重新审视 Harness，移除不再必要的部件，增加能实现新能力的部件。