Anthropic Harness 设计解析：长时自主编码的多智能体架构

2026 年 3 月，Anthropic 工程团队发布了一篇题为《Harness design for long-running application development》的研究文章，系统阐述了如何让 Claude 在数小时的自主会话中完成高质量的全栈应用开发。这篇由 Anthropic Labs 成员 Prithvi Rajasekaran 主导的研究，不是发布一款新产品，而是提出了一种多智能体编排架构（multi-agent harness）的设计范式。本文将梳理该方案的核心概念、实现路径、开源状态与适用边界。

一、它是什么？

Harness 在此语境下指一套围绕大模型能力短板设计的编排架构，用于支撑长时运行的自主软件开发。其最终形态是一个三智能体系统：

• Planner（规划者）：将用户的一句简单 prompt 扩展为完整的产品 spec 和功能清单。
• Generator（生成者）：按 sprint 逐个实现功能，产出代码或设计。
• Evaluator（评估者）：独立运行，扮演 QA / 评审角色，通过实际测试（如 Playwright MCP）发现 bug 和缺陷，并给出生成者可执行的反馈。

该架构受 GAN（生成对抗网络） 启发：生成者与评估者形成对抗/反馈循环，通过多轮迭代将输出质量推到单智能体难以达到的高度。

二、谁提出的？

由 Anthropic Labs 团队的 Prithvi Rajasekaran 提出并主导实验。这项工作建立在 Anthropic 此前的两个项目之上：

• frontend design skill：提升 Claude 的前端设计能力；
• long-running coding agent harness：让 Claude 进行多会话长时间编码。

研究人员发现，仅靠 prompt engineering 和简单的 harness 设计虽然能超越基线，但很快就会触碰到能力天花板，因此需要更系统化的多智能体架构来突破。

三、解决什么问题？

文章指出了长时自主编码中的两个核心失效模式：

1. Context anxiety（上下文焦虑）

在 lengthy tasks 中，随着上下文窗口被填满，模型会逐渐失去连贯性，甚至出现"提前收尾"的行为。Claude Sonnet 4.5 在这方面表现尤为明显。

解法：Context resets。不是简单地把前文摘要压缩（compaction），而是彻底清空上下文窗口，启动一个全新的 agent，通过结构化交接 artifact 把之前的状态和下一步任务传递给新 agent。这能给模型一个"干净 slate"，有效消除焦虑。

2. Self-evaluation bias（自我评估偏差）

当让模型评估自己的作品时，它倾向于过度自信，即使质量明显平庸也会"自信地称赞"。这在设计等主观任务中尤为致命。

解法：生成与评估分离。让独立的 evaluator agent 来评审生成者的输出。通过 prompt 调优让 evaluator 变得 skeptical（持怀疑态度），从而给生成者提供真实、可迭代的反馈。

此外，对于主观质量难以衡量的问题，研究团队将"品味"拆解为可评分标准：

• Design quality：设计是否有整体感；
• Originality：是否有刻意创作，而非模板堆砌；
• Craft：技术执行（排版、间距、对比度）；
• Functionality：可用性。

通过明确惩罚"AI slop"（千篇一律的紫渐变白卡片等），推动模型走出安全区。

四、核心价值是什么？

1. 突破单智能体天花板

文章做了一个对比实验：用同样的 prompt（做一个 2D 复古游戏编辑器），solo agent 花费约 $9、20 分钟产出的版本核心功能（游戏运行）是坏的；而 full harness 花费约 $200、6 小时产出的版本功能完整、界面更精致，还自带 AI 辅助生成功能。

2. 把"品味"变成工程约束

通过明确的设计/评分标准，让 evaluator 能稳定地评判原本主观的东西，驱动生成者迭代。

3. 支撑数小时连贯自主工作

通过 context reset + 结构化交接，harness 能支撑多 session、数小时的长任务，而不受上下文长度或模型焦虑限制。

4. 发现真实 bug

Evaluator 通过 Playwright MCP 实际点击运行中的应用、测试 API 端点和数据库状态，能发现代码层面的真实缺陷（如路由顺序错误、事件处理逻辑错误等）。

五、适合谁，不适合谁？

适合

• 在模型能力边界上工作的 AI 工程师：任务刚好比当前模型单独处理能力复杂一点，需要脚手架辅助。
• 需要产出复杂全栈应用的团队：例如需要 Claude 自主构建 DAW（数字音频工作站）、游戏编辑器等。
• 涉及主观质量判断的任务：前端设计、创意内容生成等，需要把"品味"编码成可迭代标准。
• 愿意为质量支付时间和成本的场景：高复杂度任务下，$200 换一个有核心功能的应用，远比 $9 换一个坏掉的 demo 划算。

不适合

• 模型已能独立搞定的简单任务

文章明确说：如果任务在模型当前能力舒适区内，harness 就是"不必要的开销"（unnecessary overhead）。

• 预算/时间极度敏感的原子任务

Solo agent 可能只需 20 分钟 / $9，full harness 可能需要 4-6 小时 / $100-200。简单任务下这个溢价不值得。

• 追求最低延迟、快速反馈的场景

Harness 运行周期长，不适合需要秒级/分钟级结果的场景。

• 模型升级后仍僵化保留的旧 harness

文章强调核心原则："harness 中的每个组件都编码了一个关于模型无法独自完成某事的假设"。随着模型能力提升（如从 Opus 4.5 到 4.6，上下文焦虑大幅减少），原本必要的组件可能变得不再"承重"，此时应该简化 harness，而非继续维护完整复杂架构。

六、具体该如何实现？

实现 Harness 的关键不是某个单一算法，而是围绕模型短板设计编排架构。根据官方实践，关键要素如下：

1. Context Resets（上下文重置）

每个 session 启动一个全新的 Claude Agent SDK client，强制清空上下文。旧 session 的状态通过结构化文件 artifact 交接：

• app_spec.txt：产品规格
• feature_list.json：功能验收标准及通过状态
• claude-progress.txt：工作总结和下一步指引
• git commits：代码版本记录

2. Generator-Evaluator 反馈循环

• Generator：负责产出；
• Evaluator：独立运行，使用明确标准评分，通过 Playwright MCP 或 Puppeteer MCP 实际点击应用、截图验证 UI；
• 未达标时，Evaluator 的详细反馈回流给 Generator 进行下一轮迭代。

3. Sprint Contract（可选）

在 Generator 动手前，Generator 与 Evaluator 先协商一份"合同"：这个 sprint 做什么、如何验证。这能防止高层 spec 导致的实现偏差。

4. 安全沙箱与权限控制

通过 Claude Agent SDK 的 ClaudeCodeOptions 配置：

• Sandbox：OS 级 bash 隔离；
• Permissions：文件操作严格限制在项目目录内；
• Bash Allowlist：只允许特定命令，危险命令通过 PreToolUse hook 拦截。

七、开源状态与平台依赖

开源状态：部分开源

• 官方开源了一个最小示例：在 GitHub 仓库 anthropics/claude-quickstarts 中，有一个 two-agent harness demo（Initializer + Coding Agent），展示了 context reset、文件交接、git 持久化、安全沙箱等基础机制。
• 博客中的 three-agent 高级架构目前并未作为完整开源框架发布。那篇博客更像是一份工程研究报告，分享的是设计模式与实验结果，而不是一个打包好的现成产品。
• 部分组件已开源：例如博客中提到的前端设计技能在 claude-code 仓库中是公开的。

平台依赖

操作系统：macOS / Linux 最自然。Windows 原生环境可能因 bash 命令兼容性存在问题，建议在 WSL2 中运行。

模型依赖：博客实验主要基于 Claude Sonnet 4.5 和 Opus 4.5/4.6。不同模型对 harness 复杂度的需求不同——Sonnet 4.5 需要 context resets，而 Opus 4.6 可以去掉 sprint decomposition。

八、总结

Anthropic 的 Harness design 不是一种现成软件，而是一种面向长时自主编码的多智能体编排设计模式。它通过 Planner + Generator + Evaluator 的分工与对抗式迭代，解决上下文焦虑和自我评估偏差问题，用 orchestration 复杂度换取单智能体无法企及的输出质量。

它的最佳适用场景是复杂度刚好超出当前模型单独能力边界的任务。对于简单任务或模型已能很好处理的场景，它是一种昂贵且不必要的 overhead。更重要的是，随着模型能力进化，harness 也需要不断被审视和简化——正如文章所言："模型越好，原本承重的脚手架就越应该被拆除。"

参考来源

• Harness design for long-running application development - Anthropic Engineering
• anthropics/claude-quickstarts - GitHub