7.2 KiB
title, tags, source, confidence_score, last_updated
| title | tags | source | confidence_score | last_updated | ||||
|---|---|---|---|---|---|---|---|---|
| Anthropic Harness 设计 |
|
|
高 | 2026-04-07 |
Anthropic Harness 设计
Anthropic Harness 设计是 Anthropic 团队 Prithvi Rajasekaran 提出的多智能体架构，用于长时间运行的应用开发。该设计受生成对抗网络（GAN）启发，使用生成器和评估器智能体的组合。
问题背景
朴素实现的不足
之前的工作已经表明，Harness 设计对长时间运行的智能体编码的有效性有重大影响。但对于更复杂的任务，智能体仍然倾向于随着时间推移偏离轨道。观察到两种常见的失败模式：
-
上下文窗口填充和"上下文焦虑"：模型在冗长任务上随着上下文窗口填充而失去连贯性。一些模型还表现出"上下文焦虑"，当它们接近认为的上下文限制时会提前结束工作。
-
自我评估问题：当被要求评估它们自己生成的作品时，智能体倾向于自信地赞扬作品——即使，对于人类观察者来说，质量明显平庸。这个问题对于主观任务（如设计）特别明显，没有二进制检查相当于可验证的软件测试。
核心架构
三智能体系统
Anthropic 最终构建了一个三智能体系统，每个智能体解决先前运行中观察到的特定差距：
| 角色 | 职责 |
|---|---|
| Planner（规划者） | 将简单的 1-4 句话提示扩展为完整的产品规格 |
| Generator（生成者） | 一次一个功能地实现规格，带有 git 版本控制 |
| Evaluator（评估器） | 使用 Playwright MCP 测试运行中的应用，分级并提供详细反馈 |
上下文重置 vs 压缩
上下文重置：清空上下文窗口并启动一个新的智能体，结合携带先前智能体状态和下一步的结构化交接。
上下文压缩：将对话的早期部分就地摘要，以便同一个智能体可以在缩短的历史上继续。
虽然压缩保留了连续性，但它没有给智能体一个干净的状态，这意味着上下文焦虑仍然可能存在。重置提供了一个干净的状态，但代价是交接工件必须有足够的状态让下一个智能体干净地接手工作。
在早期测试中，发现 Claude Sonnet 4.5 表现出足够强的上下文焦虑，以至于仅靠压缩不足以实现良好的长任务性能，因此上下文重置成为 Harness 设计的必要条件。
前端设计：使主观质量可分级
两个洞见
- 虽然美学不能完全简化为分数——而且个人品味总是会变化——但它们可以通过编码设计原则和偏好的分级标准来改善。
- 通过将前端生成与前端分级分离，可以创建一个推动生成器朝着更强输出发展的反馈循环。
四个分级标准
| 标准 | 描述 |
|---|---|
| 设计质量 | 设计感觉像是一个连贯的整体而不是部分的集合吗？ |
| 原创性 | 是否有自定义决策的证据，还是只是模板布局、库默认值和 AI 生成的模式？ |
| 工艺 | 技术执行：排版层次结构、间距一致性、色彩和谐、对比度。 |
| 功能性 | 独立于美学的可用性。用户能理解界面做什么吗？ |
强调设计质量和原创性超过工艺和功能性。Claude 已经默认在工艺和功能性上得分很高，因为所需的技术能力往往自然而然地出现在模型中。但在设计和原创性上，Claude 经常产生充其量是乏味的输出。
生成-评估循环
构建在 Claude Agent SDK 上的循环：
- 生成器智能体首先根据用户提示创建 HTML/CSS/JS 前端
- 给予评估器 Playwright MCP，让它在评分每个标准并编写详细批评之前直接与实时页面交互
- 该反馈流回生成器作为下一次迭代的输入
- 每次生成运行 5 到 15 次迭代
在每次评估后，指示生成器做出战略决策：如果分数趋势良好则改进当前方向，或者如果方法不起作用则转向完全不同的美学。
扩展到全栈编码
架构演变
Opus 4.5 基本上自行消除了上下文焦虑行为，因此可以完全从 Harness 中删除上下文重置。智能体作为一个连续会话在整个构建中运行，Claude Agent SDK 的自动压缩处理沿途的上下文增长。
冲刺契约
在每个冲刺之前，生成器和评估器协商一个冲刺契约：在编写任何代码之前就该工作块的"完成"看起来像什么达成一致。
这存在是因为产品规格故意是高级的，需要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提议它将构建什么以及如何验证成功，评估器审查该提议以确保生成器正在构建正确的东西。两者迭代直到达成一致。
结果对比
使用"创建一个带有关卡编辑器、精灵编辑器、实体行为和可玩测试模式的 2D 复古游戏制作器"提示进行的测试：
| Harness | 持续时间 | 成本 |
|---|---|---|
| Solo | 20 分钟 | $9 |
| 完整 Harness | 6 小时 | $200 |
Harness 贵了 20 多倍，但输出质量的差异立即显而易见。
Harness 简化迭代
移除冲刺构造
从 Harness 中完全移除了冲刺构造。保留了规划器和评估器，因为每个都继续增加明显的价值。将评估器移动到运行结束时的单次通过，而不是每个冲刺分级。
模型改进的影响
Opus 4.6 的发布提供了进一步减少 Harness 复杂性的动力。Opus 4.6 更仔细地规划、更长时间地维持智能体任务、可以在更大的代码库中更可靠地操作，并且具有更好的代码审查和调试技能来捕捉自己的错误。它还在长上下文检索方面有了实质性改进。
更新后的 Harness 结果
使用"使用 Web Audio API 在浏览器中构建功能完整的 DAW"提示进行的测试：
- 总持续时间：约 4 小时
- 总成本：$124.70
大部分时间花在构建器上，它在没有 Opus 4.5 所需的冲刺分解的情况下连贯运行了两个多小时。
关键经验教训
随着模型继续改进，可以大致期望它们能够工作更长时间，处理更复杂的任务。在某些情况下，这将意味着随着时间推移，模型周围的支架变得不那么重要，开发人员可以等待下一个模型并看到某些问题自行解决。另一方面，模型越好，开发能够实现超出模型在基线水平所能做到的复杂任务的 Harness 的空间就越大。
有几个经验教训值得向前推进：
- 用你正在构建的模型进行实验总是好的做法
- 在处理更复杂的任务时，有时可以通过分解任务并将专门的智能体应用于问题的每个方面来获得提升
- 当新模型落地时，重新检查 Harness 通常是好的做法，剥离那些不再对性能有负载作用的部分，并添加新部分以实现以前可能无法实现的更大能力
相关概念
参考来源
- Anthropic - Harness design for long-running application development
最后更新：2026-04-07
本文档由 WikiLLM 编译