Harness 设计不是包装器，而是长时任务的节律控制器

Anthropic 公司的工程实践

发布于 2026 年 3 月 24 日

Harness 设计（Harness design）是突破代理式编程（agentic coding）性能前沿的关键。本文介绍我们如何借助该设计进一步提升 Claude 在前端设计（frontend design）与长时间运行的自主软件工程（long-running autonomous software engineering）方面的能力。

作者：Prithvi Rajasekaran，Anthropic 实验室（Labs）团队成员。

过去数月，我聚焦于两个相互关联的问题：一是让 Claude 生成高质量的前端设计（frontend design），二是使其在无需人工干预的前提下构建完整应用程序。这项工作起源于我们早期对前端设计能力（frontend design skill）与长时间运行编码代理（long-running coding agent）Harness 的探索——当时我和同事们通过提示工程（prompt engineering）与 Harness 设计显著提升了 Claude 的表现，远超基线水平；但二者最终均遭遇性能瓶颈。

为突破瓶颈，我探索了适用于两个差异显著领域的新型人工智能工程方法：一个领域以主观审美（subjective taste）为特征，另一个则以可验证的正确性（verifiable correctness）与可用性（usability）为标尺。受生成对抗网络（Generative Adversarial Networks, GANs）启发，我设计了一种含 生成器（generator） 与 评估器（evaluator） 代理的多代理（multi-agent）结构。构建一个能可靠评分、且具备审美判断力的评估器（evaluator），首先需确立一套评判标准，将“这个设计是否优秀？”这类主观判断转化为具体、可分级的指标。

随后，我将这些技术应用于长时间运行的自主编码（long-running autonomous coding），并沿用了此前 Harness 工作中的两条关键经验：一是将构建过程（build）分解为可处理的模块化片段（tractable chunks），二是利用结构化产物（structured artifacts）在不同会话（sessions）间传递上下文（context）。最终成果是一种三代理架构——规划器（planner）、生成器（generator）与评估器（evaluator）——可在持续数小时的自主编码会话中产出功能丰富的全栈应用（full-stack applications）。

我们此前已证明，智能体编排框架（harness design）对长时程智能体编程（agentic coding）的有效性具有显著影响。在早期实验中，我们使用初始化智能体（initializer agent）将产品需求文档（product spec）分解为任务清单，再由编码智能体（coding agent）逐项实现功能，并通过交付产物（artifacts）在会话间传递上下文（context）。更广泛的开发者社区也得出了类似洞见，例如采用“拉尔夫·维古姆”（Ralph Wiggum）方法——借助钩子（hooks）或脚本维持智能体持续迭代循环。

但某些问题依然顽固存在。对于更复杂的任务，智能体仍倾向于随时间推移而偏离正轨（go off the rails）。在对该问题进行归因分析时，我们观察到智能体执行此类任务时存在两种常见失效模式（failure modes）。

第一种是模型在处理长任务时容易丧失连贯性（coherence），因为上下文窗口（context window）逐渐填满（参见我们关于上下文工程（context engineering）的博文）。部分模型还会表现出“上下文焦虑”（context anxiety）：即当模型感知自身接近上下文长度限制时，会提前草草收尾。上下文重置（context reset）——即彻底清空上下文窗口、启动一个全新智能体，并辅以结构化交接（structured handoff），将前一智能体的状态及后续步骤明确传递——可同时缓解上述两类问题。

这与压缩（compaction）不同：后者是在原对话中就地总结早期内容，使同一智能体得以基于缩短的历史继续运行。虽然压缩保留了连续性，却未赋予智能体一张白纸（clean slate），因此上下文焦虑仍可能持续。而重置提供了真正的白纸，代价是交接产物（handoff artifact）必须承载足够状态信息，确保下一智能体能无缝接续工作。在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑尤为明显，仅靠压缩不足以支撑其在长任务中表现优异，因此上下文重置成为编排框架设计的关键环节。该方案解决了核心问题，但也带来了编排复杂度上升、每次框架运行的 token 开销增加以及延迟升高。

第二个此前未予讨论的问题是自评估（self-evaluation）。当被要求评估自身产出成果时，智能体往往自信地给出高度赞扬——即便在人类观察者看来，成果质量显然平庸。这一问题在设计（design）等主观性任务中尤为突出：这类任务缺乏软件测试（software test）那样可验证的二元判定标准。布局是否显得精致抑或泛泛，本质上是主观判断；而智能体在自我评分时则一贯偏向乐观。

然而，即便在具备可验证结果的任务中，智能体有时仍会表现出不良判断力，从而阻碍其任务执行效果。将执行工作的智能体（generator）与评估工作的智能体（evaluator）分离开来，被证实是应对该问题的有力手段。这种分离本身并不能立即消除宽松倾向（leniency）；毕竟评估者仍是大语言模型（LLM），天然对其他 LLM 生成的内容持宽容态度。但将一个独立评估器调优为持怀疑态度（skeptical），远比让生成器对其自身产出保持批判性更为可行；而一旦外部反馈机制建立，生成器便拥有了具体可依的迭代依据。

我首先从前端设计（frontend design）入手开展实验，因为在此领域中自我评估（self-evaluation）问题最为明显。若不加干预，Claude 通常会倾向于选择安全、可预测的布局——这些布局在技术上功能完备，但视觉上平淡无奇。

有两个关键洞见塑造了我为前端设计构建的约束机制（harness）。第一，尽管美学（aesthetics）无法被完全归约为一个分数（score）——个体审美偏好永远存在差异——但借助能编码设计原则（design principles）与偏好的评分标准（grading criteria），其质量仍可提升。“这个设计美吗？（Is this design beautiful?）”难以一致作答，但“该设计是否遵循我们定义的良好设计原则？（does this follow our principles for good design?）”则为 Claude 提供了一个具体、可衡量的评判依据。第二，通过将前端生成（frontend generation）与前端评分（frontend grading）分离，我们可以构建一个反馈闭环（feedback loop），从而驱动生成器（generator）产出更高质量的结果。

基于此，我编写了四条评分标准（grading criteria），并将它们同时写入生成器代理（generator agent）和评估器代理（evaluator agent）的提示词（prompt）中：

• 设计质量（Design quality）：该设计是否呈现出一个有机整体（coherent whole）的感觉，而非一堆零散部件（collection of parts）的拼凑？在此项上表现优异，意味着色彩（colors）、排版（typography）、布局（layout）、图像（imagery）及其他细节协同作用，共同营造出独特的情绪（mood）与身份认同（identity）。
• 原创性（Originality）：是否存在定制化决策（custom decisions）的证据？还是仅套用了模板布局（template layouts）、库默认样式（library defaults）或 AI 生成模式（AI-generated patterns）？人类设计师应能识别出刻意为之的创造性选择（deliberate creative choices）。未经修改的现成组件（stock components）——或 AI 生成的典型痕迹（如白色卡片上叠加紫色渐变色（purple gradients over white cards））——在此项上即判定失败。
• 工艺水平（Craft）：技术实现层面：排版层级（typography hierarchy）、间距一致性（spacing consistency）、色彩协调性（color harmony）、对比度比值（contrast ratios）。这是一项能力检验（competence check），而非创意检验（creativity check）。大多数合理实现默认即可达标；此项失败意味着基础能力存在缺陷（broken fundamentals）。
• 功能性（Functionality）：独立于美学的可用性（usability）。用户能否理解界面功能、快速定位主要操作（primary actions）、无需猜测即可完成任务？

我强调设计质量与原创性，权重高于工艺水平与功能性。Claude 在工艺水平与功能性方面本就表现良好——所需的技术能力往往天然具备。但在设计质量与原创性上，Claude 的输出常常至多平庸乏味（bland）。这些标准明确惩罚高度泛化的“AI 垃圾”（AI slop）模式，并通过提高设计质量与原创性的权重，推动模型承担更多美学层面的风险（aesthetic risk-taking）。

我使用少量样本（few-shot examples）并附详细分项得分（detailed score breakdowns）对评估器进行了校准（calibrated）。此举确保评估器的判断与我的偏好保持一致，并减少了跨轮次迭代中的评分漂移（score drift）。

我基于 Claude Agent SDK 构建该闭环，使编排（orchestration）保持简洁明了。首先，生成器代理（generator agent）根据用户提示（user prompt）生成 HTML/CSS/JS 前端代码。我为评估器赋予 Playwright MCP（Model Control Protocol），使其能直接与运行中的网页（live page）交互，再逐项评分并撰写详尽评述（detailed critique）。实践中，评估器会自主导航页面，截取屏幕截图（screenshotting）并细致审阅实现细节后才生成评估结果。该反馈随即作为输入返回给生成器，用于下一轮迭代。每组生成任务运行 5 至 15 轮迭代，每轮迭代通常促使生成器朝更具辨识度的方向演进，以响应评估器的批评意见。由于评估器是主动导航真实页面而非对静态截图（static screenshot）打分，每轮循环均需真实的挂钟时间（wall-clock time）；完整运行耗时最长可达四小时。此外，我指令生成器在每次评估后作出战略性决策：若分数呈上升趋势，则深化当前方向；若路径失效，则彻底转向一种全新的美学风格（entirely different aesthetic）。

在各次运行中，评估器的评分质量随迭代次数增加而提升，最终趋于稳定，但仍留有提升空间。部分生成过程呈现渐进式精修；另一些则在轮次间发生剧烈的美学转向（sharp aesthetic turns）。

评分标准措辞（wording of the criteria）以我未曾完全预料的方式引导了生成器。例如加入短语“最佳设计应达博物馆级水准（the best designs are museum quality）”，便使产出设计趋向某种特定的视觉收敛（visual convergence），表明与标准关联的提示语言（prompting）本身即直接塑造了输出的特质（character of the output）。

尽管分数总体随迭代提升，但改进路径并非总是清晰线性。后期实现整体更优，但我常发现中间某一轮次的输出反而优于最终版本。实现复杂度（implementation complexity）也随轮次递增：生成器为回应评估器反馈，不断尝试更雄心勃勃的方案（more ambitious solutions）。即使在第一轮，输出亦显著优于无任何提示词（no prompting）的基线版本，表明评分标准及其配套语言本身即在评估反馈介入前，已将模型从泛化默认态（generic defaults）中引导出来。

在一个典型案例中，我要求模型为一家荷兰艺术博物馆（Dutch art museum）创建网站。至第九轮迭代，它产出了一款简洁、深色主题（dark-themed）的虚构博物馆着陆页（landing page）。该页面视觉精致，且基本符合我的预期。然而，在第十轮循环中，它彻底摒弃原有方案，将网站重构为空间化体验（spatial experience）：一个采用 CSS 透视（CSS perspective）渲染的棋盘格地板（checkered floor）三维房间（3D room），画作以自由布局（free-form positions）悬挂在墙面，导航方式由“门道”（doorway-based navigation）在不同展厅（gallery rooms）间切换，而非依赖滚动（scroll）或点击（click）。这是一种我在单次生成（single-pass generation）中从未见过的创造性跃迁（creative leap）

基于这些发现，我将这种受生成对抗网络（Generative Adversarial Network, GAN）启发的模式应用到了全栈开发中。生成器-评估器（generator-evaluator）循环天然映射到软件开发生命周期（software development lifecycle），其中代码审查（code review）和质量保证（QA）所承担的结构性角色，与设计评估器（design evaluator）完全一致。

架构（architecture）

在我们早期的长时运行测试框架（long-running harness）中，我们已通过一个初始化智能体（initializer agent）、一个逐个实现功能的编码智能体（coding agent），以及会话间的上下文重置（context resets），解决了连贯的多会话编码问题。上下文重置是一个关键突破：该测试框架使用 Sonnet 4.5 模型，而该模型表现出前文提到的“上下文焦虑”（context anxiety）倾向。构建一个能在多次上下文重置下稳定工作的测试框架，是让模型始终聚焦于任务的核心。Opus 4.5 模型自身已基本消除了这一行为，因此我得以彻底移除本测试框架中的上下文重置机制。各智能体在整个构建过程中以单次连续会话（one continuous session）方式运行，由 Claude Agent SDK 的自动上下文压缩（automatic compaction）功能沿途处理上下文增长问题。

本次工作建立在原始测试框架（harness）的基础之上，采用三智能体（three-agent）系统，每个智能体专门弥补此前运行中观察到的某一类能力缺口。该系统包含以下智能体角色（agent personas）：

规划者（Planner）：我们先前的长时运行测试框架要求用户预先提供一份详尽的产品规格说明（spec）。我希望自动化该步骤，因此创建了规划者智能体——它仅需接收一条简短的 1–4 句提示（prompt），即可将其扩展为一份完整的产品规格说明书。我提示它在范围（scope）上保持雄心，同时聚焦于产品上下文（product context）和高层次技术设计（high-level technical design），而非具体的技术实现细节（detailed technical implementation）。这一侧重源于如下担忧：若规划者在前期就试图指定过于颗粒化的技术细节，且其中某处出错，则规格书中的错误将级联（cascade）至下游实现环节。相较之下，更明智的做法是仅对交付物（deliverables）施加约束，而让各智能体在推进过程中自主探索实现路径。此外，我还要求规划者主动寻找机会，将人工智能（AI）特性有机融入产品规格说明中。（参见文末附录中的示例。）

生成器（Generator）：早期测试框架中“一次实现一个功能”（one-feature-at-a-time）的方法在范围管控方面效果良好。我在本框架中沿用了类似模型，指示生成器以冲刺（sprint）为单位工作，每次从规格说明中选取一个功能进行实现。每次冲刺均基于 React、Vite、FastAPI 和 SQLite（后期升级为 PostgreSQL）技术栈构建应用；生成器被要求在每次冲刺结束时对自身产出进行自我评估（self-evaluate），再移交至 QA 环节。它还集成了 Git 作为版本控制系统（version control）。

评估器（Evaluator）：早期测试框架产出的应用程序表面看来令人印象深刻，但实际使用时仍存在真实缺陷（bugs）。为捕获此类问题，评估器调用 Playwright MCP（Model Context Protocol）工具，以真实用户的方式点击并遍历正在运行的应用程序，测试其用户界面（UI）功能、API 端点（API endpoints）及数据库状态（database states）。随后，它依据两套标准对每次冲刺进行评分：一是其所发现的缺陷，二是借鉴前端实验（frontend experiment）建模的一组评判准则——此处适配为覆盖产品深度（product depth）、功能完备性（functionality）、视觉设计（visual design）与代码质量（code quality）。每项准则均设有硬性阈值（hard threshold）；若任一指标未达标，则该次冲刺判定为失败，生成器将收到关于具体问题的详细反馈。

每次冲刺开始前，生成器与评估器会协商一份冲刺合约（sprint contract）：在任何代码编写之前，双方即就本次工作模块的“完成”（done）标准达成一致。此举源于产品规格说明本身刻意保持高层抽象（high-level），而我需要一个中间环节来弥合用户故事（user stories）与可测试实现（testable implementation）之间的鸿沟。生成器提出其拟构建内容及成功验证方式，评估器则审核该提案，确保生成器正在构建正确之物；双方持续迭代，直至达成共识。

智能体间通信通过文件（files）完成：一个智能体写入文件，另一个智能体读取该文件，并在其内直接响应，或另建新文件供前者后续读取。生成器随后依据双方达成的合约开展构建，并将成果移交 QA。该机制既确保了产出严格忠实于规格说明，又避免过早过度规定实现细节。

运行测试框架（harness）

在该测试框架（harness）的第一个版本中，我使用了 Claude Opus 4.5，将用户提示（user prompts）同时输入完整的测试框架与单智能体系统（single-agent system）进行对比。我选用 Opus 4.5，是因为在我启动这些实验时，它是我们性能最强的代码生成模型（coding model）。

我编写了以下提示词（prompt）来生成一款复古视频游戏制作工具：

创建一个二维复古游戏制作工具（2D retro game maker），功能包括关卡编辑器（level editor）、精灵编辑器（sprite editor）、实体行为（entity behaviors）以及可游玩的测试模式（playable test mode）。

下表展示了测试套件类型（harness type）、运行时长以及总成本。

| Harness（挂载装置） | Duration（持续时间） | Cost（费用） | | Solo（单人挂载） | 20 分钟 | 9 美元 | | Full harness（全副挂载） | 6 小时 | 200 美元 |

测试框架（harness）的成本高出 20 倍以上，但输出质量的差异立竿见影。

我原本期待的是一个能让我构建关卡（level）及其组成部分（如精灵 sprite、实体 entity、瓦片布局 tile layout）的界面，然后点击“播放”（Play）按钮即可实际运行该关卡。我首先打开了单次运行（solo run）的输出结果，初始应用界面看起来符合上述预期。

然而，当我逐页点击浏览时，问题开始浮现。布局浪费了大量空间：固定高度的面板使视口（viewport）大部分区域留空。工作流（workflow）僵化死板。尝试填充关卡（level）时，系统提示我先创建精灵（sprite）和实体（entity），但用户界面（UI）中没有任何引导暗示这一操作顺序。更关键的是，游戏本体（actual game）根本无法运行：我的实体虽显示在屏幕上，却完全不响应任何输入。深入代码后发现，实体定义（entity definition）与游戏运行时（game runtime）之间的连接（wiring）已断裂，而问题位置在表层上毫无提示。

单独 harness（solo harness）创建的应用首次打开时的初始界面。

使用独奏套件（solo harness）制作的精灵编辑器（sprite editor）创建一个精灵（sprite）。

尝试播放我创建的关卡（level）但失败了

在完成单次运行（solo run）的评估后，我将注意力转向了“套件运行”（harness run）。该运行同样始于同一句提示词（prompt），但规划器步骤（planner step）将该提示词扩展为一份涵盖十个迭代周期（sprint）、共计 16 项功能的规格说明（spec）。其覆盖范围远超单次运行所尝试的内容。除核心编辑器（editors）和播放模式（play mode）外，该规格说明还要求实现精灵动画系统（sprite animation system）、行为模板（behavior templates）、音效与音乐（sound effects and music）、AI 辅助的精灵生成器（AI-assisted sprite generator）与关卡设计师（level designer），以及支持导出游戏并生成可分享链接（shareable links）的功能。我向规划器开放了我们的前端设计技能（frontend design skill），它读取并利用该技能，在规格说明中构建了一套应用的视觉设计语言（visual design language）。针对每个迭代周期，生成器（generator）与评估器（evaluator）协商达成一份合约（contract），明确该周期的具体实现细节，以及用于验证完成度的可测试行为（testable behaviors）。

应用立即展现出比单次运行（solo run）更精致、更流畅的体验。画布（canvas）占满整个视口（viewport），面板（panels）尺寸设置合理，界面具备一致的视觉身份（visual identity），准确呼应了设计规范（spec）所确立的设计方向。不过，单次运行中曾观察到的部分笨拙感（clunkiness）依然存在——工作流（workflow）仍未清晰传达“应先构建精灵（sprites）和实体（entities），再尝试填充关卡（level）”这一逻辑，我只能通过反复试探（poking around）自行摸索。这反映出基础模型（base model）在产品直觉（product intuition）层面存在固有短板，而非编排框架（harness）本意要解决的问题；尽管如此，它确实指明了一个方向：可在编排框架内开展有针对性的迭代（targeted iteration），以进一步提升输出质量（output quality）。

通过编辑器操作，新版本（run）相较于单机模式（solo）的优势愈发明显。精灵编辑器（sprite editor）功能更丰富、更完整，工具调色板（tool palettes）更简洁，颜色选择器（color picker）更优，缩放控制（zoom controls）更易用。

因为我要求规划器（planner）将 AI 功能融入其规格说明中，该应用还自带 Claude 集成（Claude integration），使我能够通过提示词（prompting）生成游戏的各个部分。这显著加快了工作流程。

初始界面：创建新游戏，使用完整工具链（full harness）构建的应用

精灵编辑器（sprite editor）感觉更简洁、更易用。

使用内置 AI 功能（built-in AI feature）生成关卡

使用内置 AI 功能（built-in AI feature）生成关卡

玩这个游戏时我生成的

最大的区别在于游戏模式（play mode）。我实际上能够移动自己的实体（entity）并游玩游戏。物理引擎（physics）存在一些粗糙之处——我的角色跳上了一个平台，却最终与平台发生了重叠，这在直觉上明显错误——但核心功能确实运转起来了，而单次运行（solo run）并未实现这一点。四处移动一段时间后，我确实遇到了 AI 在游戏关卡构建（game level construction）方面的一些限制：有一堵很高的墙，我无法跳过去，因而被困住了。这表明，该框架（harness）尚需加入一些常识性改进（common sense improvements）和边界情况（edge cases）处理能力，以进一步完善应用。

通读日志后可以明确看出，评估器（evaluator） 始终确保实现严格符合规范（spec）。每个迭代（sprint），它都会遍历该迭代合约（sprint contract）所列的测试标准，并通过 Playwright 对正在运行的应用程序执行端到端验证，一旦发现实际行为与预期行为存在偏差，即提交缺陷报告（bug）。这些合约颗粒度极细——仅第 3 次迭代（Sprint 3）就包含 27 条标准，覆盖关卡编辑器（level editor）的方方面面；而评估器所发现的问题足够具体，开发团队可直接据此修复，无需额外调查。下表展示了我们的评估器识别出的若干问题示例：

| 合约准则（Contract criterion） | 评测员发现（Evaluator finding） | | 矩形填充工具（Rectangle fill tool）支持点击并拖拽，以用选定图块（tile）填充一个矩形区域 | 失败（FAIL） — 该工具仅在拖拽起始点和结束点处放置图块，而非填充整个区域。fillRectangle 函数已存在，但在 mouseUp 事件中未被正确触发。 | | 用户可选择并删除已放置的实体生成点（entity spawn point） | 失败（FAIL） — 删除键（Delete key）处理器位于 LevelEditor.tsx:892，要求同时设置 selection 和 selectedEntityId 才能执行删除；但点击某个实体时仅设置了 selectedEntityId。条件应改为 selection || (selectedEntityId && activeLayer === 'entity')。 | | 用户可通过 API 重排动画帧（animation frame）顺序 | 失败（FAIL） — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 'reorder' 错误匹配为整型 frame_id，因而返回 422 错误：“无法将字符串解析为整数”。 |

要让评估器（evaluator）达到这一水平，需要付出大量努力。开箱即用（out of the box）状态下，Claude 是一个表现欠佳的问答（QA, Question-Answering）代理。在早期运行中，我观察到它能识别出真实的缺陷，却随后自我说服、认定这些问题“无关紧要”，最终仍批准交付。此外，它倾向于进行表面化的测试，而非深入探查边界情况（edge cases），因此更隐蔽的缺陷常常漏网。调优循环（tuning loop）的具体做法是：阅读评估器的日志，找出其判断与我的判断出现分歧的样例，并据此更新 QA 提示词（QA prompt），针对性解决那些问题。经过多轮这样的开发迭代，评估器才开始以我认为合理的方式进行评分。即便如此，评估框架（harness）的输出仍揭示了该模型在 QA 能力上的固有局限：细微的布局（layout）问题、局部交互体验显得反直觉（unintuitive）、以及在更深嵌套（deeply nested）功能中未被充分执行测试而遗漏的缺陷。显然，通过进一步调优，仍有可观的验证能力提升空间。但相比单人开发（solo run）阶段——当时应用的核心功能根本无法运行——此次改进的效果已十分显著。

迭代优化 harness（测试框架）

首批 harness（测试框架）结果令人鼓舞，但该框架也显得臃肿、运行缓慢且成本高昂。逻辑上的下一步，是寻找在不损害其性能的前提下简化 harness 的方法。这既源于常识判断，也源于一条更普遍的原则：harness 中的每个组件都隐含着一个关于‘模型自身无法独立完成什么’的假设；而这些假设值得被严格验证——不仅因为它们可能本就不成立，更因为随着模型能力的持续提升，这些假设会迅速过时（go stale）。我们在博客文章《构建高效智能体（Building Effective Agents）》中将这一底层理念概括为：‘寻找尽可能简单的解决方案，仅在必要时才增加复杂性’；这一模式在所有维护 agent harness（智能体测试框架）的实践中反复出现。

在我首次尝试简化时，我大幅削减了 harness 的组件，并试验了几种富有创意的新思路，却未能复现原始版本的性能表现。同时，我也难以分辨 harness 设计中哪些部分真正承担关键功能（load-bearing），以及它们各自以何种方式起作用。基于这次经验，我转向一种更为系统化的方法：每次仅移除一个组件，并仔细评估其对最终结果的影响。

在我进行这些迭代循环的过程中，我们同步发布了 Opus 4.6 版本，这进一步强化了降低 harness 复杂性的动机。有充分理由预期：相较于 Opus 4.5，4.6 版本所需的 scaffolding（脚手架/辅助结构）将显著减少。根据我们的发布博客所述：“[Opus 4.6] 规划更加审慎，能更持久地维持智能体（agentic）任务，在更大规模代码库中运行更可靠，并具备更强的代码审查（code review）与调试（debugging）能力，可自主发现并修正自身错误。” 此外，它在长上下文检索（long-context retrieval）方面也实现了大幅提升——而这些，恰恰正是此前 harness 所着力弥补的能力短板。

移除 sprint（冲刺）结构

我首先彻底移除了 sprint（冲刺）结构。sprint（冲刺）机制原本用于将工作分解为若干模块（chunks），从而帮助模型更连贯地开展任务。鉴于 Opus 4.6 的能力提升，我们有充分理由相信：模型已能原生（natively）胜任该任务，无需此类显式分解。

我保留了 planner（规划器）和 evaluator（评估器）两个组件，因为二者仍持续提供明确价值。若移除 planner，generator（生成器）会出现任务范围界定不足（under-scoped）的问题：面对原始 prompt（提示词），它会直接开始构建，而未先行明确工作规格（speccing），最终产出的应用功能丰富度远低于由 planner 主导所构建的结果。

在移除 sprint 结构后，我将 evaluator（评估器）调整为仅在整轮运行（run）结束时执行一次单次评估（single pass），而非原先按每个 sprint 分别评分。由于模型整体能力大幅提升，evaluator 在某些运行场景中的关键程度（load-bearing）也随之改变——其实际效用取决于具体任务与模型当前独立可靠完成能力（reliably solo）之间的相对位置。在 Opus 4.5 上，这一能力边界非常接近：我们的构建任务正处于 generator 独立完成效果良好的临界边缘，因此 evaluator 能在整个构建流程中捕获大量实质性问题；而在 Opus 4.6 中，模型的原生能力（raw capability）增强，导致该边界向外扩展。过去需依赖 evaluator 校验才能实现连贯构建的任务，如今大多已落入 generator 可独立高质量完成的范围内；对于处于该能力边界内的任务，evaluator 已成为不必要的开销。但对仍处于 generator 能力边缘的构建环节，evaluator 依然带来切实有效的提升。

其实际含义在于：是否启用 evaluator 并非一个固定的‘是/否’决策，而应视任务难度是否超出当前模型独立可靠完成的范围而定——当任务超出该范围时，启用 evaluator 才具有成本合理性。

在结构层面简化的同时，我还通过优化 prompt（提示词）来提升 harness 将 AI 功能（AI features）集成进各应用的方式，尤其促使 generator 构建出真正的智能体（agent），使其能借助工具（tools）自主驱动应用自身功能。这一过程经历了大量反复调优，原因在于相关知识较为新颖，Claude 的训练数据对此覆盖稀疏（covers it thinly）；但经过足够细致的调参，generator 最终能够正确构建智能体（agent）

更新后的测试框架（harness）结果

为了验证更新后的测试框架（harness），我使用以下提示词（prompt）生成一个数字音频工作站（Digital Audio Workstation, DAW）——一种用于作曲、录音和混音的音乐制作程序：

使用 Web Audio API 在浏览器中构建一个功能完备的数字音频工作站（DAW）。

该次运行仍耗时较长且成本高昂，总计约 4 小时，令牌（token）费用达 124 美元。

大部分时间消耗在构建器（builder）阶段，该阶段连续运行超过两小时，且未依赖 Opus 4.5 所需的冲刺式分解（sprint decomposition）。

| 代理（Agent）与阶段（Phase） | 耗时 | 费用 | | 规划器（Planner） | 4.7 分钟 | 0.46 美元 | | 构建（第 1 轮） | 2 小时 7 分钟 | 71.08 美元 | | 质量保障（QA，第 1 轮） | 8.8 分钟 | 3.24 美元 | | 构建（第 2 轮） | 1 小时 2 分钟 | 36.89 美元 | | 质量保障（QA，第 2 轮） | 6.8 分钟 | 3.09 美元 | | 构建（第 3 轮） | 10.9 分钟 | 5.88 美元 | | 质量保障（QA，第 3 轮） | 9.6 分钟 | 4.06 美元 | | V2 测试框架（Harness）总计 | 3 小时 50 分钟 | 124.70 美元 |

与此前的测试框架（harness）一样，规划器（planner）将单行提示词扩展为完整规格说明（spec）。从日志中可见，生成器模型（generator model）在应用设计与代理（agent）架构设计、代理连接（wiring the agent up）以及移交质量保障（QA）前的自测环节均表现良好。

话虽如此，质量保障（QA）代理仍成功识别出真实存在的缺陷。其第一轮反馈指出：

这是一个设计保真度（design fidelity）优异、AI 代理（AI agent）稳健、后端（backend）良好的强健应用。主要失效点在于功能完备性（Feature Completeness）——尽管应用外观出色、AI 集成运行良好，但若干核心 DAW 功能仅限于静态展示（display-only），缺乏交互深度：音轨片段（clips）无法在时间轴（timeline）上拖拽或移动；缺少乐器用户界面面板（instrument UI panels，如合成器旋钮 synth knobs、鼓垫 drum pads）；亦无可视化效果编辑器（visual effect editors，如均衡器曲线 EQ curves、压缩器表头 compressor meters）。这些并非边缘用例（edge cases），而是使 DAW 具备可用性的核心交互；而规格说明（spec）已明确要求实现这些功能。

在第二轮反馈中，它再次识别出多项功能性缺口（functionality gaps）：

剩余缺口：

• 音频录制（Audio recording）仍仅为存根实现（stub-only）（按钮可切换状态，但无麦克风采集）
• 尚未实现通过边缘拖拽调整片段尺寸（clip resize by edge drag）及片段切分（clip split）
• 效果器可视化（Effect visualizations）仅以数值滑块（numeric sliders）呈现，而非图形化界面（如均衡器曲线 EQ curve）

生成器（generator）在独立运作时仍易遗漏细节或仅提供存根（stub）式功能实现，而质量保障（QA）环节持续在‘最后一公里’（last mile）问题上发挥关键价值，帮助生成器定位并修复这些问题。

依据该提示词，我预期得到一个支持创建旋律（melodies）、和声（harmonies）与鼓组节奏型（drum patterns）、将其编排为完整歌曲（song），并在整个流程中获得集成代理（integrated agent）协助的程序。下方视频展示了最终成果。

该应用远未达到专业级音乐制作软件水准，且代理（agent）的歌曲创作能力显然亟待大幅提升。此外，Claude 实际上不具备听觉能力（cannot actually hear），导致质量保障（QA）反馈闭环在音乐审美（musical taste）相关判断上效力受限。

但最终应用已具备功能性音乐制作程序所需的全部核心组件：可在浏览器中正常运行的编排视图（arrangement view）、混音器（mixer）与传输控制（transport）。更进一步，我全程仅通过提示词（prompting）便完成了一段简短的乐句（song snippet）：代理设定了节拍速度（tempo）与调性（key），铺陈了主旋律（melody），构建了鼓组轨道（drum track），调节了混音器电平（mixer levels），并添加了混响（reverb）。歌曲创作所需的核心基元（core primitives）均已就位，且代理能自主驱动这些基元，借助工具（tools）端到端地完成一次简易音乐制作。你或许会说它尚非‘音准完美’（pitch-perfect）——但它正稳步趋近。

随着大语言模型（LLM）持续进步，我们大致可以预期它们将能处理更长时间、更复杂的任务。在某些情况下，这意味着围绕模型构建的框架（scaffold）会逐渐变得不那么重要，开发者只需等待下一代模型发布，部分问题便会自然解决。另一方面，模型能力越强，就越有空间去开发更强大的模型编排系统（harness），从而完成超出模型基线（baseline）能力的复杂任务。

鉴于此，本研究提供了几条值得延续的经验：始终应针对你正在构建的模型开展实验，阅读其在真实问题上的执行轨迹（trace），并调优其性能以达成预期目标；在处理更复杂任务时，有时可通过任务分解（task decomposition）并为问题的每个子模块配备专用智能体（specialized agent），从而获得性能提升空间；当新模型发布时，通常应重新审视现有编排系统（harness），移除那些已不再对性能起支撑作用（load-bearing）的组件，并加入新组件，以实现此前无法达成的更高能力。

基于本研究，我确信：随着模型能力提升，值得探索的模型编排组合（harness combination）空间并不会缩小，而只是发生位移；对 AI 工程师而言，持续发现下一个新颖有效的组合，正是其中最富价值的工作。

特别感谢 Mike Krieger、Michael Agaby、Justin Young、Jeremy Hadfield、David Hershey、Julius Tarng、Xiaoyi Zhang、Barry Zhang、Orowa Sidker、Michael Tingley、Ibrahim Madha、Martina Long 和 Canyon Robbins 对本工作的贡献。

同时感谢 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 在成文过程中的协助与建议。

规划智能体（planner agent）生成的示例计划。

RetroForge - 2D Retro Game Maker

概览
RetroForge 是一个基于网页的创意工作室（creative studio），用于设计和构建 2D 复古风格（retro-style）电子游戏。它融合了经典 8-bit 与 16-bit 游戏美学（aesthetics）的怀旧魅力与现代直观的编辑工具——使从业余创作者（hobbyist creator）到独立开发者（indie developer）的各类用户，都能在无需编写传统代码（traditional code）的前提下，将游戏构想变为现实。

该平台提供四个集成的创意模块：基于瓦片（tile-based）的关卡编辑器（Level Editor），用于构建游戏世界；像素艺术（pixel-art）角色图像编辑器（Sprite Editor），用于制作视觉素材；可视化实体行为系统（visual Entity Behavior system），用于定义游戏逻辑；以及即时可玩测试模式（instant Playable Test Mode），支持实时游戏性（gameplay）测试。通过在整个工作流中嵌入人工智能辅助（AI assistance）（由 Claude 驱动），RetroForge 加速了创作流程——帮助用户通过自然语言交互（natural language interaction）生成角色图像（sprite）、设计关卡（level）并配置实体行为（entity behavior）。

RetroForge 的目标用户是热爱复古游戏美学但追求现代便利性的创作者。无论用户是想复刻童年时代的平台跳跃游戏（platformer）、角色扮演游戏（RPG）或动作游戏（action game），还是希望在复古约束条件（retro constraints）下创造全新体验，均可借助该平台快速原型化（prototype rapidly）、可视化迭代（iterate visually），并与其他用户分享作品。

功能
1. 项目仪表盘（Project Dashboard）与管理
项目仪表盘是 RetroForge 中所有创作工作的主界面（home base）。用户需要一种清晰、有序的方式管理自己的游戏项目——新建项目、返回进行中的项目，并能一目了然地了解每个项目的构成。

用户故事（User Stories）：作为用户，我希望：

- 创建一个带名称和描述的新游戏项目，以便开始我的游戏设计
- 以可视化卡片形式查看所有已有项目，每张卡片显示项目名称、最后修改日期及缩略图预览，以便我能快速定位并继续工作
- 点击任一项目进入完整的游戏编辑工作区（game editor workspace），以便开展游戏开发
- 删除不再需要的项目，并弹出确认对话框以防误操作，以便保持工作区整洁
- 将现有项目复制为新项目的起点，以便复用先前的工作成果

项目数据模型（Project Data Model）：每个项目包含：

项目元数据（metadata）（名称、描述、创建/修改时间戳）
画布设置（Canvas settings）（分辨率：例如 256x224、320x240 或 160x144）
瓦片尺寸配置（Tile size configuration）（8x8、16x16 或 32x32 像素）
配色方案（color palette）选择
所有关联的角色图像（sprite）、瓦片集（tileset）、关卡（level）及实体定义（entity definition）

...

产品更新、操作指南（how-to）、社区亮点报道等资讯，每月推送至您的邮箱。

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

本文由英文原文全文翻译;阅读英文原文

• 旧 Wiki 原文 · Harness 设计不是包装器，而是长时任务的节律控制器

  收录日期：2026-10-11

• 原文引用 · www.anthropic.com

  收录日期：2026-10-11