---
layout: single
title:  "Anthropic：面向长时间运行应用开发的 Harness 设计"
date:   2026-03-29 08:00:00 +0800
categories: [AI 与大模型, 编程开发]
tags: [Agent, HarnessEngineering, Anthropic, Claude]
---

在智能体（Agentic）编程的前沿领域，Harness 设计（测试与运行框架设计）是性能表现的关键。以下是我们如何推动 Claude 在前端设计和长时间运行的自主软件工程中进一步突破的实践。

**作者：Prithvi Rajasekaran，Labs 团队成员**

**发布日期：2026年3月24日**

<!-- more -->

- [Harness design for long-running application development](https://www.anthropic.com/engineering/harness-design-long-running-apps)

在过去的几个月里，我一直致力于解决两个相互关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在无需人工干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计能力和长时间运行编程智能体 Harness 方面的尝试。当时，我和同事们通过提示词工程（Prompt Engineering）和 Harness 设计，能够将 Claude 的性能提升到远高于基准线的水平——但两者最终都遇到了瓶颈。

为了实现突破，我寻求了一种能够跨越两个完全不同领域的全新 AI 工程方法：一个由主观审美定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GAN）的启发，我设计了一种包含**生成器（Generator）**和**评估器（Evaluator）**智能体的多智能体结构。要构建一个能够可靠且具审美感地对输出进行评分的评估器，意味着首先要开发一套标准，将“这个设计好吗？”这种主观判断转化为具体的、可量化的条款。

随后，我将这些技术应用于长时间运行的自主编程，并继承了早期 Harness 工作中的两个经验：将构建过程分解为可处理的块（Chunks），并使用结构化的“制品”（Artifacts）在不同会话之间传递上下文。最终的结果是一个由**策划者（Planner）**、**生成器**和**评估器**组成的三智能体架构，它能够在长达数小时的自主编程会话中生成功能丰富的全栈应用。


## 为什么朴素的实现方式会失效

我们之前已经证明，Harness 设计对长时间运行的智能体编程效率有重大影响。在早期的实验中，我们使用一个“初始化智能体”将产品需求分解为任务列表，再由一个“编程智能体”逐一实现功能，并在会话间移交制品以携带上下文。广大开发者群体也得出了类似的见解，例如“Ralph Wiggum”方法，即通过钩子（Hooks）或脚本让智能体处于持续的迭代循环中。

但一些问题依然顽固存在。对于更复杂的任务，随着时间的推移，智能体往往会“跑偏”。在分解这个问题时，我们观察到智能体在执行此类任务时有两种常见的失效模式。

**首先是模型在长任务中容易失去连贯性，因为上下文窗口会被填满**（参见我们关于上下文工程的文章）。一些模型还会表现出“上下文焦虑”（Context Anxiety），即当它们认为自己接近上下文限制时，会过早地结束工作。**上下文重置**（Context Resets）——即彻底清空上下文窗口并启动一个新的智能体，结合携带前一个智能体状态和后续步骤的结构化移交——解决了这两个问题。

这与“压缩”（Compaction）不同，压缩是在原地总结之前的对话，以便同一个智能体能在缩短的历史记录上继续工作。虽然压缩保持了连续性，但它没有给智能体一个“干净的底板”，这意味着上下文焦虑可能依然存在。重置提供了一个干净的起点，代价是移交制品必须包含足够的足迹，以便下一个智能体能顺畅接手。在我们早期的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑表现得非常明显，仅靠压缩不足以支持强劲的长任务性能，因此上下文重置成为了 Harness 设计的核心。这解决了核心问题，但增加了每次框架运行的编排复杂度、Token 开销和延迟。

**第二个问题是自我评估，这是我们之前未曾解决的。** 当要求智能体评估自己产出的工作时，它们往往会自信地赞美这些成果——即便在人类观察者看来，质量明显很平庸。这个问题在设计等主观任务中尤为突出，因为这类任务没有等同于软件测试的二进制检查。布局是否感觉精致或普通是一种主观判断，而智能体在给自己的作品打分时总是习惯性偏高。

然而，即使是在具有可验证结果的任务中，智能体有时也会表现出判断力不佳，从而阻碍任务完成。**将负责工作的智能体与负责评判的智能体分离**，被证明是解决这一问题的强力杠杆。这种分离本身并不能立即消除偏袒；评估器仍然是一个倾向于对 LLM 生成内容表现宽容的 LLM。但事实证明，调优一个独立的评估器使其保持怀疑态度，比让生成器对自己的工作进行挑剔要容易得多。一旦这种外部反馈存在，生成器就有了具体的迭代目标。

## 前端设计：让主观质量变得可量化

我首先在前端设计上进行实验，因为自我评估问题在那里最为明显。在没有任何干预的情况下，Claude 通常倾向于选择安全、可预测的布局，这些布局在技术上可行，但在视觉上平淡无奇。

两个见解塑造了我为前端设计构建的 Harness。首先，虽然美感不能完全还原为一个分数——且个人口味各异——但可以通过编码了设计原则和偏好的评分标准来提升。回答“这个设计美吗？”很难保持一致，但“这是否遵循了我们的优秀设计原则？”则给了 Claude 一个具体的评分依据。其次，通过分离前端生成和前端评分，我们可以创建一个反馈循环，驱动生成器产出更强大的输出。

基于此，我编写了四个评分标准，并在提示词中提供给生成器和评估器：

1.  **设计质量（Design Quality）：** 设计是否感觉是一个连贯的整体，而非零件的堆砌？优秀的表现意味着色彩、排版、布局、图像和其他细节共同营造出独特的情绪和身份感。
2.  **原创性（Originality）：** 是否有自定义决策的证据，还是使用了模板化布局、库默认设置和 AI 生成的模式？人类设计师应当能识别出刻意的创意选择。未修改的素材组件，或明显的 AI 生成迹象（如白色卡片上的紫色渐变）在此项会失败。
3.  **工艺（Craft）：** 技术执行力：排版层级、间距一致性、色彩和谐度、对比度。这是能力检查而非创意检查。
4.  **功能性（Functionality）：** 独立于美学的易用性。用户能否理解界面功能、找到主要操作并完成任务？

我强调了设计质量和原创性，而非工艺和功能性。Claude 在工艺和功能性上默认得分就很高，因为所需的技术能力对模型来说很自然。但在设计和原创性上，Claude 经常产生平庸的内容。这些标准明确惩罚了高度通用的“AI 废料”（AI slop）模式，通过加大设计和原创性的权重，迫使模型在审美上进行更多冒险。


我使用带有详细评分说明的少样本示例（Few-shot examples）来校准评估器。这确保了评估器的判断符合我的偏好，并减少了迭代过程中的分数漂移。

我基于 **Claude Agent SDK** 构建了这一循环，使编排变得简单直观。生成器智能体首先根据用户提示词创建一个 HTML/CSS/JS 前端。我给评估器配备了 **Playwright MCP**，使其能在评分前直接与实时页面交互。在实践中，评估器会自主导航页面，截取屏幕并仔细研究实现细节，然后给出评估。反馈流回生成器作为下一轮迭代的输入。我通常运行 5 到 15 次迭代，每次迭代通常都会随着生成器响应评估器的批评而将其推向更独特的方向。由于评估器是在主动导航页面而非评分静态截图，每个周期都需要真实的物理时间。完整的运行过程可能长达四小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好则深化当前方向，如果方法无效则转向完全不同的审美。

在多次运行中，评估器的评估在达到平台期前随迭代而提升。有些生成过程是循序渐进的，有些则在迭代间发生了剧烈的审美转向。

标准的措辞以我未完全预料到的方式引导了生成器。加入“最优秀的设计具有博物馆品质”这类短语，将设计推向了一种特定的视觉趋同，这表明与标准相关的提示词直接塑造了输出的性格。

虽然分数通常随迭代而提高，但模式并不总是线性的。后期的实现整体上往往更好，但我经常发现自己更喜欢中间的某个迭代。随着轮次增加，实现的复杂度也趋于提升。即便在第一次迭代中，输出也明显优于无提示词的基准，这表明评分标准和相关语言本身就在评估器介入前，将模型引离了通用默认值。

在一个显著的例子中，我要求模型为一个荷兰艺术博物馆创建一个网站。到第九次迭代时，它产出了一个干净的、深色主题的虚拟博物馆落地页。页面视觉精美，但基本符合预期。然而在第十个周期，它完全抛弃了原有方案，将网站重新构思为一种**空间体验**：一个带有棋盘格地板的 3D 房间（通过 CSS 透视渲染），艺术品自由悬挂在墙上，页面间的导航不再是滚动或点击，而是通过门口进行。这是我在单次生成中从未见过的创意飞跃。

## 扩展到全栈编程

有了这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期中，其中代码评审（Code Review）和质量保证（QA）在结构上扮演着与设计评估器相同的角色。

### 架构设计

在早期的长时间运行 Harness 中，我们通过初始化智能体、逐个功能开发的编程智能体以及会话间的上下文重置，解决了多会话编程的连贯性问题。上下文重置是一个关键突破：当时的框架使用 Sonnet 4.5，它表现出了前述的“上下文焦虑”。创建一个能在上下文重置中运行良好的 Harness 是保持模型专注于任务的关键。而 **Opus 4.5** 本身就在很大程度上消除了这种行为，因此我得以在这一框架中完全舍弃上下文重置。智能体在整个构建过程中作为持续会话运行，由 Claude Agent SDK 的自动压缩处理随之增长的上下文。

在这项工作中，我在原框架基础上构建了一个三智能体系统，每个智能体针对我在之前运行中观察到的特定短板。系统包含以下智能体角色：

* **策划者（Planner）：** 之前的框架要求用户预先提供详细说明。我希望自动化这一步，因此创建了一个策划者智能体，它接受 1-4 句简单的提示词，并将其扩展为完整的产品说明书。我要求它在范围上要有雄心，并专注于产品背景和高层技术设计，而非详细的技术实现。这是因为担心如果策划者预先指定了过于细碎的技术细节且出错，这些错误会级联影响到下游。限制交付物并让智能体在工作中寻找路径似乎更聪明。我还要求策划者寻找机会将 AI 功能织入产品说明中。
* **生成器（Generator）：** 早期框架中的“一次一个功能”方法在范围管理上表现良好。我在这里采用了类似模型，指示生成器进行“冲刺”（Sprints），从说明书中一次领取一个功能。每个冲刺都使用 React、Vite、FastAPI 和 SQLite（后改为 PostgreSQL）技术栈。生成器被要求在每个冲刺结束移交给 QA 前进行自我评估。它还拥有用于版本控制的 Git。
* **评估器（Evaluator）：** 早期框架产出的应用通常看起来令人印象深刻，但在实际使用时仍存在真实的 Bug。为了捕捉这些问题，评估器使用 Playwright MCP 像用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。然后，它根据发现的 Bug 以及一套改编自前端实验的标准（涵盖产品深度、功能性、视觉设计和代码质量）给每个冲刺打分。每个标准都有硬性阈值，如果任何一项低于阈值，冲刺即告失败，生成器会收到关于出错原因的详细反馈。

在每个冲刺（Sprint）开始前，生成器会创建一个新的 Git 分支。在冲刺结束时，如果评估器通过了该分支，代码就会被合并到主分支（`main`）中。

这种“生成-评估”循环的一个关键发现是，**评估器的质量直接决定了生成器的上限**。如果评估器的标准太低，生成器就会偷懒；如果评估器无法发现深层 Bug，那些 Bug 就会留在最终产品中。因此，我花费了大量时间来调优评估器的提示词，使其成为一个“严厉的批评家”。我给它提供了多张应用运行时的截图，并要求它不仅检查 UI 是否存在，还要检查交互是否符合逻辑。

## 简化框架的尝试与 Opus 4.6 的突破

第一套框架（Harness）的结果令人振奋，但它也非常臃肿、缓慢且昂贵。逻辑上的下一步是寻找在不降低性能的前提下简化框架的方法。这部分出于常识，部分源于一个更普遍的原则：**框架中的每个组件都代表了对模型“无法独立完成某事”的假设**。随着模型的改进，这些假设值得不断进行压力测试，因为它们可能会过时。我们的博文《构建高效智能体》提出了核心观点：“寻找尽可能简单的解决方案，仅在需要时增加复杂度”，这对于维护智能体框架的人来说是一个贯穿始终的模式。

在我第一次尝试简化时，我激进地削减了框架结构，尝试了一些新的点子，但未能复制原始版本的性能。而且，很难判断框架设计中的哪些部分是真正起支撑作用的。基于此，我转而采用一种更系统的方法：每次移除一个组件，并回顾其对最终结果的影响。

在我进行这些迭代周期时，我们发布了 **Opus 4.6**，这为降低框架复杂度提供了进一步的动力。有理由期待 4.6 所需要的“脚手架”比 4.5 更少。正如我们在发布博客中所言：“[Opus 4.6] 计划更周密，能更长时间维持智能体任务，在大型代码库中运行更可靠，并拥有更好的代码评审和调试技能来纠正自己的错误。”它在长上下文检索方面也有了实质性提升。而这些能力原本都是该框架旨在补充的。

### 移除“冲刺”结构

我首先完全移除了“冲刺”结构。冲刺原本是为了将工作分解为块，以便模型能连贯地工作。鉴于 Opus 4.6 的改进，有理由相信模型原生就能处理这类任务，而无需这种人为分解。

我保留了策划者和评估器，因为两者仍在持续提供显而易见的价值。如果没有策划者，生成器会缩减范围：在只有原始提示词的情况下，它会直接开始构建而没有预先规划，最终生成的应用功能远不如策划者规划的那样丰富。

在移除冲刺结构后，我将评估器改为在运行结束时进行单次扫描，而不是按冲刺评分。由于模型能力显著增强，评估器对特定任务的支撑作用发生了变化，其用途取决于任务相对于模型独立可靠完成能力的边界。在 4.5 上，这个边界很近：我们的构建任务处于生成器独立完成能力的边缘，评估器能捕捉到贯穿整个构建过程的实质性问题。而在 4.6 上，模型的原生能力提升，边界向外推移。

## 结论与展望

通过这一系列的实验，我们得出了一些关于开发长时间运行智能体应用的核心教训：

1.  **分离关注点：** 将“做”和“评”分开是提升质量最有效的杠杆。通过这种对抗式的结构，我们不仅提升了代码的正确性，更重要的是，我们第一次在生成式 AI 中实现了可扩展的主观审美控制。
2.  **动态框架设计：** 随着模型每一代的进步，曾经必要的复杂编排可能会变成阻碍。最好的框架应该是模块化的，能够随着模型能力的增强而“自我瘦身”。
3.  **标准即生产力：** 当我们把模糊的“好设计”转化为具体的、可评分的维度（如原创性、工艺、功能感）时，我们实际上是为智能体提供了一张通往卓越的地图。

在未来，我们预计智能体将能够自主处理更加庞大且跨度更长的工程任务。而这种“多智能体协作、严格外部评估”的模式，将是通往全自主软件工程的必经之路。

## 附录：策划者生成的规格说明示例

以下是策划者智能体将简单的“荷兰艺术博物馆”提示词扩展后的部分内容：

* **项目愿景：** 创建一个沉浸式的、受蒙德里安启发的数字空间，打破传统的网格布局。
* **关键 AI 功能：** 集成多模态智能体，允许用户通过自然语言描述其情绪，由 AI 实时生成匹配该情绪的虚拟画廊导览。
* **技术栈要求：** 使用 React Three Fiber 处理 3D 空间，FastAPI 处理后端逻辑，通过向量数据库检索艺术品元数据。