Harness 设计如何支撑Claude长时运行应用开发

Harness 设计如何支撑长时运行应用开发

Harness（脚手架 / 运行编排系统）是 agentic coding（智能体式编程）前沿性能的关键。Anthropic 在这篇文章里展示了：如何通过更精细的 harness 设计，把 Claude 在前端设计和长时自主软件开发上的能力继续往上推。

一、文章核心观点

作者的核心结论可以概括为一句话：

当模型本身越来越强时，真正拉开差距的，不只是模型，而是围绕模型构建的整套运行系统。

这套系统包括：

•任务拆解

•上下文管理

•多智能体协作

•评估与反馈

•QA 验证

•结构化交接

也就是说，模型不只是“回答问题”的工具，而是在 harness 的约束和协作下，逐渐成为能持续推进复杂任务的执行体。

二、为什么朴素做法不够

Anthropic 在更早的实验中已经发现：对于长时运行的复杂编码任务，单个 agent 很容易随着时间推移逐渐失控。作者总结了两个典型问题。

1. 上下文越长，模型越容易失去连贯性

随着 context window（上下文窗口）逐渐被填满，模型会越来越难保持一致性。有些模型还会表现出一种类似“上下文焦虑”的倾向：

•还没做完，就提前收尾

•一接近上下文极限，就想结束工作

为了解决这个问题，团队早期使用了 context reset（上下文重置）：

•清空当前上下文

•启动一个新的 agent

•用结构化 handoff artifact 把前一阶段状态交接给下一阶段

作者强调，这和 compaction（压缩上下文）不同。压缩只是把旧内容总结后继续留在同一个 agent 的上下文里，而 reset 是真正给一个“干净起点”。

2. Agent 的自我评估通常不可靠

另一个问题是 self-evaluation（自评）。

当让 agent 检查自己做的东西时，它往往会：

•过度自信

•过度宽松

•即使结果一般，也倾向于给出正面评价

在前端设计这类主观性很强的任务中，这种问题尤其明显，因为这里不像软件测试那样有明确的“对 / 错”标准。

作者的解决办法是：

把干活的 agent 和打分的 agent 分开。

让 generator 负责产出，让 evaluator 负责批判和反馈。独立 evaluator 虽然仍然是 LLM，但更容易被调成严格、怀疑、细致的评审者。

三、前端设计：把“审美”变成可评分的东西

作者首先把实验放在前端设计任务上，因为这里最容易暴露“自评偏宽松”的问题。

没有额外干预时，Claude 往往会生成那种：

•安全

•规整

•可用

•但视觉平庸

的页面。

为此，作者设计了一套评分标准，让前端设计能被结构化评估。主要包括四个维度：

1设计质量（Design quality） 整体是否统一、有明显风格，而不是一堆零散部件拼起来。

2原创性（Originality） 是否体现真实设计决策，而不是模板、默认组件和 AI 常见套路。

3工艺（Craft） 包括层级、间距、配色、对比度等技术基本功。

4功能性（Functionality） 用户是否容易理解界面并完成任务。

作者特别提高了“设计质量”和“原创性”的权重，因为 Claude 默认在工艺和功能上通常不差，真正短板是：不够有风格、不够有个性。

接着作者用 few-shot examples（少样本示例）校准 evaluator，让它的评分更稳定、更贴近人类偏好。

整个流程是：

•generator 先生成 HTML / CSS / JS 前端

•evaluator 借助 Playwright MCP 实际浏览页面、截图、查看细节

•evaluator 按评分维度输出批评

•generator 根据反馈继续改进

这种循环通常会跑 5 到 15 轮，有时整轮耗时可达 4 小时。

一个很有代表性的案例

作者让模型做一个“荷兰艺术博物馆网站”。

前 9 轮已经做出一个不错的暗色调首页，但到第 10 轮时，模型突然彻底换思路，改成了一个空间式的 3D 展厅体验：

•地面是棋盘格

•墙上自由挂画

•页面之间通过“门洞”切换

作者认为，这种创造性飞跃，是在单轮生成中很少见到的。

四、从前端设计扩展到全栈开发

在前端设计实验验证有效后，作者把这套“生成器 + 评估器”的思路扩展到完整的全栈软件开发流程。

这里的核心结构变成了三智能体：

1. Planner（规划者）

Planner 的任务，是把用户输入的 1~4 句简单描述，扩展成完整的产品 spec（规格说明）。

它被要求：

•在 scope 上更大胆

•聚焦产品目标和高层技术方向

•不要过早锁死底层实现细节

作者认为，如果 planner 过早写入错误的技术细节，这些错误会一路传播到下游实现里。

2. Generator（生成器）

Generator 负责真正实现应用。早期版本里，它按 sprint（冲刺）逐步推进：

•每次只做一块功能

•技术栈包括 React、Vite、FastAPI、SQLite / PostgreSQL

•使用 git 管理版本

3. Evaluator（评估器）

Evaluator 负责像真实用户一样测试应用：

•点按钮

•走 UI 流程

•调 API

•看数据库状态

•对照合同检查是否达标

如果任何关键项没达标，就把问题反馈给 generator。

在每个 sprint 前，generator 和 evaluator 还会共同定义一个 sprint contract（冲刺契约），明确：

•这轮要做什么

•什么算完成

•用什么方式验证完成

这一步的价值在于：把高层产品需求桥接成可测试、可交付的开发目标。

五、实验一：做一个复古 2D 游戏制作器

作者先用 Claude Opus 4.5 测试“构建一个复古 2D 游戏制作器”。

成本对比

虽然 harness 的成本高出 20 多倍，但结果质量差异也非常明显。

单智能体版本的问题

单智能体输出乍看还行，但深入使用后问题暴露很多：

•布局浪费空间

•工作流不清晰

•用户不知道要先建 sprite / entity 才能编辑关卡

•最关键的是：游戏根本不能玩

实体虽然出现在画面里，但控制无效。深入代码后发现，实体定义和运行时逻辑的连接本身就是断的。

Harness 版本的提升

而完整 harness 会先由 planner 把一句简单 prompt 扩展成一个更完整的产品规格，包含：

•关卡编辑器

•Sprite 编辑器

•行为系统

•测试模式

•动画系统

•音效和音乐

•AI sprite 生成器

•AI 关卡设计器

•导出与分享能力

最终成品在多个方面明显优于 solo：

•视觉更统一

•面板布局更合理

•编辑器更强

•工作流更顺滑

•最关键的是：游戏真的能运行起来

Evaluator 还会在日志中精确指出具体 bug，例如：

•矩形填充工具没有真正填充区域

•删除实体的快捷键判断条件写错

•FastAPI 路由顺序错误导致接口 422

作者坦言：默认状态下，Claude 并不是一个好的 QA。它经常会发现问题，但又说服自己“没关系”，最后还是通过。因此 evaluator 也需要多轮调优。

不过即便如此，相比“核心功能都跑不起来”的 solo 输出，完整 harness 仍然带来了巨大提升。

六、继续迭代：让 Harness 变轻

第一版 harness 虽然强，但也非常明显地：

•复杂

•缓慢

•昂贵

因此下一步自然是：删减不必要的 scaffold（脚手架）。

与此同时，Claude Opus 4.6 发布，模型能力大幅提升：

•规划更稳

•长任务更持久

•更擅长代码审查和调试

•长上下文检索更强

这些增强意味着：很多原本必须由 harness 补足的能力，现在模型本身开始能承担一部分。

去掉 Sprint 结构

作者首先尝试移除 sprint 结构。

在 4.5 时代，sprint 的作用很大，因为它能帮助模型维持长任务连贯性。但到了 4.6，模型本身已经可以连续工作更久，因此作者尝试让 generator 直接完成更长段的构建。

不过 planner 和 evaluator 仍然保留下来，因为它们依然能提供明显价值：

•没有 planner：generator 往往 scope 不足，做出来的应用功能偏少

•没有 evaluator：模型在能力边缘的任务上仍然会漏细节、留 stub feature

作者得出一个非常重要的判断：

evaluator 不是固定“要 / 不要”的组件，而是取决于任务是否超出当前模型单打独斗的可靠边界。

如果任务本身已经处在模型稳定能力范围内，evaluator 可能只是额外开销；但如果任务还在边缘，它就能带来非常实在的增益。

七、实验二：浏览器中的 DAW（数字音频工作站）

为了测试新版本 harness，作者让系统构建一个运行在浏览器中的 DAW。

成本

整个流程依然很贵：

•总时长约 3 小时 50 分

•成本约 124.70 美元

其中大头仍然是 build 阶段。

输出结果

最终结果显示：

•planner 能把一句话 prompt 展开成完整产品规格

•generator 能较好地规划应用与 agent 结构

•evaluator 仍然能抓到真实缺陷

例如 QA 指出：

•音频录制只是 stub

•clip 的 resize / split 没做好

•效果器界面只是数值滑杆，没有真正的图形化编辑

作者认为，这再次说明：即使模型更强，generator 仍然会漏掉最后一公里的问题，而 QA 仍然能提供真实价值。

虽然这个 DAW 离专业软件还很远，Claude 也听不到声音，因此它在“音乐审美”上的反馈闭环还很有限，但它已经具备了完整的基础骨架：

•arrangement view

•mixer

•transport

•基础作曲与编辑能力

更重要的是，agent 已经能通过工具自主驱动这些能力，完成从 prompt 到简单音乐片段的制作流程。

八、作者最后的结论

作者最后提出了一个很关键的判断：

随着模型能力提升，值得探索的 harness 组合空间不会缩小，只会移动。

也就是说，模型越强：

•一部分旧 scaffold 会失效

•但新的能力边界又会打开新的 harness 设计空间

因此，AI 工程师的工作并不会因为模型变强而减少，反而会变成：

•不断测试模型真实能力

•观察执行轨迹（traces）

•去掉不再承重的部分

•增加新的、当前真正有效的组合

九、我的简短总结

本文由山行翻译整理自：

https://www.anthropic.com/engineering/harness-design-long-running-apps

这篇文章最值得看的地方，不是单纯展示 Anthropic 又做了一个更复杂的 agent 系统，而是它非常清楚地说明了：

1为什么单 agent 长任务会失控

2为什么自评往往不可靠

3为什么把生成与评估分开能显著提升质量

4为什么模型变强后，不是 harness 失效，而是 harness 的重点发生迁移

一句话总结就是：

模型能力提升之后，真正决定复杂任务上限的，越来越不是“模型本身会不会”，而是“你有没有为它设计出一套合适的运行系统与反馈闭环”。