当 AI 编程代理运行超过 4 小时、耗费 200 美元 Token 成本，却能自主构建出一个可运行的数字音频工作站时——工程师们做对了什么？
引言：智能体编程进入"长跑"时代
2026 年 3 月 24 日，Anthropic 工程团队发布了一篇重磅技术博客，题为《Harness Design for Long-Running Application Development》。文章由 Anthropic Labs 团队成员 Prithvi Rajasekaran 撰写，系统性地展示了团队在两个看似迥异却深度关联的领域——前端设计质量提升与长时自主软件工程——所取得的工程突破。
这篇文章之所以值得深入解读，不仅因为它展示了令人印象深刻的工程成果（一个由 AI 自主编写的、功能完备的浏览器端数字音频工作站），更因为它揭示了一套在智能体时代具有普适意义的系统设计方法论：如何通过精心设计的 Harness（编排框架），将大语言模型的能力推到远超基线表现的水平。
让我们从工程细节入手，逐层拆解这篇文章的核心洞察。
一、问题的起点：朴素实现为何失效？
1.1 上下文窗口的"焦虑症"
在深入解决方案之前，我们需要理解 Anthropic 团队面临的两个根本性挑战。
第一个挑战来自模型本身的上下文窗口管理 问题。当 AI 编程代理执行长时间任务时，随着对话历史不断积累，上下文窗口逐渐被填满，模型的连贯性开始下降。更有趣的是，Anthropic 观察到了一种被称为**"上下文焦虑"（Context Anxiety）**的现象——模型会在自认为接近上下文上限时，开始过早地"收尾"工作，仓促结束本应继续深入的任务。
这个现象在 Claude Sonnet 4.5 上表现得尤为明显。团队曾尝试使用上下文压缩（Compaction）——即对对话历史的早期部分进行摘要，保留近期上下文继续工作——但发现这种方法无法从根本上解决问题。因为压缩虽然释放了窗口空间，却没有给模型一个"重新开始"的心理暗示，上下文焦虑依然存在。
最终有效的方案是上下文重置（Context Reset）： 彻底清空上下文窗口，启动一个全新的代理实例，同时通过结构化的**交接文档（Handoff Artifact）**将前一个代理的状态和后续任务传递过去。这相当于给模型一块干净的白板，代价是需要额外的编排逻辑和交接开销。
1.2 自我评估的"自恋陷阱"
第二个挑战更为深层：模型在评估自己生成的工作时，倾向于过度自信地给出正面评价——即便在人类观察者看来，输出质量明显平庸。
这个问题在主观性任务（如前端设计）中尤为突出。不存在像单元测试那样的二元判定标准来检验一个页面布局是否"好看"。但即使在有明确可验证结果的编程任务中，模型也会表现出类似的判断力偏差，影响任务执行质量。
Anthropic 的关键洞察是：将"做事"的代理和"评判"的代理分离开来， 比试图让一个代理既做又评要有效得多。分离本身并不能消除模型的宽容倾向，但调整一个独立的评估器使其变得严格和审慎，远比让生成器对自己的作品保持批判性要容易得多。一旦外部反馈存在，生成器就有了具体的改进方向。
这一设计灵感直接来源于深度学习中的经典架构——生成对抗网络（GANs）： 生成器负责创造，判别器负责评判，两者在对抗中共同进化。
二、前端设计实验：让主观品质变得可量化
2.1 从"好不好看"到"是否符合设计原则"
Anthropic 团队首先在前端设计领域验证了"生成-评估"分离架构。这是一个极具挑战性的选择，因为"美"是一个高度主观的概念。
然而，团队发现了一个关键的认知转换：虽然审美无法完全还原为一个分数，但可以通过编码设计原则和偏好的评分标准 来显著改善设计质量。"这个设计漂亮吗？"是一个难以一致回答的问题，但"这个设计是否遵循了我们定义的优秀设计原则？"则给了模型一个具体可评分的锚点。
2.2 四维评分体系的设计
团队制定了四个维度的评分标准，同时提供给生成器和评估器：
设计质量（Design Quality）——考察的核心问题是：设计是否作为一个连贯的整体存在，而非零散部分的拼凑？颜色、排版、布局、意象等元素是否共同营造了独特的情绪和身份认同？这个维度关注的是"整体感"和"调性统一"。
原创性（Originality）——检验设计中是否存在定制化的决策痕迹。人类设计师能否从中辨识出刻意的创意选择？未经修改的组件库默认样式，或者 AI 生成的典型特征——如紫色渐变覆盖白色卡片——在这一维度将被明确扣分。这个标准直接针对的是所谓的"AI 审美惰性"问题。
工艺水准（Craft）——技术层面的执行质量，包括排版层次、间距一致性、色彩和谐度、对比度比值等。这是一项能力检查而非创造力检查。大多数合理的实现默认就能通过这项标准，不达标意味着基本功有缺陷。
功能性（Functionality）——独立于美学的可用性评估。用户能否理解界面功能、找到主要操作入口、不靠猜测就能完成任务？
关键策略在于权重分配： 团队刻意将设计质量和原创性的权重设置得高于工艺水准和功能性。原因是 Claude 在后两个维度上默认表现就不错（技术能力是模型的天然优势），但在设计品味和原创性上，模型倾向于生成"安全、可预测、技术上可用但视觉上平庸"的布局。通过加大对设计和原创性的权重，系统推动模型承担更多"审美风险"。
2.3 评估器的校准与反馈循环
评估器的校准使用了**少样本示例（Few-shot Examples）**加详细评分分解的方式。这确保了评估器的判断与工程师的个人偏好对齐，并减少了跨迭代的评分漂移。
整个系统基于 Claude Agent SDK 构建。工作流程如下：生成器首先根据用户提示创建 HTML/CSS/JS 前端页面；评估器通过 Playwright MCP 以实际用户的方式与页面交互——它会自主导航页面、截图、仔细研究实现效果，然后对每个维度进行打分并撰写详细评论；反馈被传回生成器，作为下一轮迭代的输入。
每次生成运行 5 到 15 轮迭代。每轮迭代通常会将生成器推向更具特色的方向。由于评估器是在实际导航页面而非评分静态截图，每个周期需要真实的时间消耗，完整运行可长达四小时。
2.4 荷兰艺术博物馆：创意跃迁的惊喜时刻
文章中最引人注目的案例发生在一次以"荷兰艺术博物馆网站"为主题的生成实验中。
前九轮迭代中，模型逐步打磨出一个干净的深色主题博物馆着陆页——视觉效果精致，但基本在预期范围内。然后，在第十轮迭代中，模型做出了一个出人意料的决定：它彻底抛弃了之前的方案，将网站重新构想为一个空间体验——一个用 CSS 透视效果渲染的 3D 房间，棋盘格地板，画作以自由位置悬挂在墙壁上，通过"门廊"式导航在不同展厅之间穿行，而非传统的滚动或点击交互。
这种创意跃迁是 Anthropic 团队此前在单轮生成中从未观察到的。它说明了两件事：一是对抗式反馈循环确实能推动模型突破安全舒适区；二是评分标准的措辞本身就会影响生成方向——标准中"最好的设计达到博物馆级别品质"这样的表述，直接引导了模型向特定的视觉风格收敛。
2.5 非线性进化的观察
团队也注意到迭代过程并非严格单调递增。总体趋势是分数随迭代提升后趋于平稳，但具体到每一轮，工程师经常发现自己更偏好某个中间迭代版本而非最终版本。实现复杂度也随着迭代轮次增加而提升——生成器在评估反馈的推动下，倾向于尝试更激进的解决方案。
一个值得关注的发现是：即便在第一轮迭代（尚未收到任何评估反馈），输出就已经明显优于完全无提示的基线。这说明评分标准本身及其关联的描述性语言，已经在评估反馈介入之前就将模型从默认的平庸中拉了出来。
三、全栈编程：从单代理到三代理架构
3.1 架构全景
在前端设计实验验证了"生成-评估"模式的有效性后，团队将这一范式扩展到了全栈应用开发。在软件开发生命周期中，代码审查和质量保证天然扮演着与设计评估器相同的结构性角色。
团队设计了一个三代理系统， 每个代理针对此前观察到的特定能力缺口：
规划器（Planner）——此前的长时运行 Harness 要求用户预先提供详细的产品规格说明。团队希望自动化这一步骤，因此创建了一个规划代理，接收简短的 1-4 句提示，将其扩展为完整的产品规格文档。规划器被提示在范围上要有雄心，但要聚焦于产品上下文和高层技术设计，而非细粒度的技术实现细节。这一设计决策基于一个务实的考量：如果规划器在前期就试图指定具体的技术实现并出现错误，这些错误会级联传导到下游实现中。更明智的做法是约束代理的交付物，让它们在工作过程中自行探索路径。此外，规划器还被指示在产品规格中寻找嵌入 AI 功能的机会。
生成器（Generator）——沿用了此前 Harness 中"一次一个功能"的方法。生成器被指示按 Sprint 工作，每次从规格文档中取一个功能进行实现。技术栈为 React + Vite + FastAPI + SQLite（后期切换为 PostgreSQL），配备 Git 进行版本控制。生成器在每个 Sprint 结束时先进行自评，再移交给 QA。
评估器（Evaluator）——使用 Playwright MCP 像真实用户一样点击、浏览运行中的应用程序，测试 UI 功能、API 端点和数据库状态。它根据发现的 Bug 以及一组评分标准（从前端实验中改编而来，覆盖产品深度、功能完整性、视觉设计和代码质量）对每个 Sprint 进行评分。每个标准都有硬性阈值，只要任何一项低于阈值，Sprint 即判定失败，生成器会收到关于问题所在的详细反馈。
3.2 Sprint 契约：弥合规格与实现的鸿沟
一个精巧的机制设计是Sprint 契约（Sprint Contract）。 在每个 Sprint 开始前，生成器和评估器会进行"谈判"：就该阶段工作的"完成"标准达成共识。生成器提出将要构建的内容和验证成功的方式，评估器审查该提案以确保生成器在构建正确的东西。双方迭代直至达成一致。
这一机制的存在是因为产品规格被刻意保持在高层次，团队需要一个步骤来弥合用户故事与可测试实现之间的鸿沟。通信通过文件进行——一个代理写入文件，另一个代理读取后在文件内或通过新文件进行回应。
3.3 案例实证：复古游戏制作器
为了验证架构的有效性，团队使用了一个简洁的提示来生成一个 2D 复古游戏制作器：
"Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode."
单代理对照组运行了 20 分钟，花费 9 美元。应用初看之下似乎符合预期，但深入使用后问题不断浮现：布局浪费空间（固定高度面板导致大量视口留白），工作流程僵硬（需要先创建精灵和实体才能填充关卡，但界面没有引导），最关键的是——游戏核心功能完全损坏， 实体出现在屏幕上但不响应任何输入，实体定义和游戏运行时之间的连接存在断裂，且界面没有任何线索指示问题所在。
完整 Harness 运行了 6 小时，花费 200 美元——成本高出 20 倍以上。但输出质量的差距一目了然。规划器将单句提示扩展为覆盖 16 个功能、分布在 10 个 Sprint 中的产品规格。除了核心编辑器和游玩模式，规格还包含精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及可分享链接的游戏导出功能。
最直观的差异体现在游玩模式中：用户真正能够移动角色并进行游戏。 虽然物理效果存在粗糙之处（角色跳上平台后与平台重叠），但核心功能是工作的——而单代理运行完全没有实现这一点。
3.4 评估器的真实价值：精确定位 Bug
文章中展示了评估器捕获的具体问题实例，充分说明了其价值所在：
对于"矩形填充工具应支持拖拽填充"这一契约标准，评估器的发现是：工具仅在拖拽的起点和终点放置瓦片，而非填充整个区域，fillRectangle 函数存在但在 mouseUp 事件中未被正确触发。
对于"用户应能选择并删除已放置的实体生成点"这一标准，评估器定位到 LevelEditor.tsx 第 892 行的 Delete 键处理器同时要求 selection 和 selectedEntityId 两者被设置，但点击实体只设置了 selectedEntityId，条件应改为 selection || (selectedEntityId && activeLayer === 'entity')。
对于"用户应能通过 API 重排动画帧"这一标准，评估器发现 PUT /frames/reorder 路由定义在 /{frame_id} 路由之后，FastAPI 将字符串 reorder 匹配为 frame_id 的整数参数，返回 422 错误。
这些发现的精确程度——定位到具体文件、具体行号、具体的根因分析——展示了评估器作为自动化 QA 代理的真实能力。
3.5 调教评估器：一个持续的工程过程
然而，让评估器达到这种表现水平并非一蹴而就。文章坦率地指出：开箱即用的 Claude 是一个糟糕的 QA 代理。
在早期运行中，团队观察到评估器会识别出合法的问题，然后说服自己认为这些问题不太重要， 最终批准通过。它还倾向于表面化测试，不深入探索边界情况，导致更微妙的 Bug 溜过。
调优循环是：阅读评估器的日志，找到其判断与工程师判断分歧的实例，更新评估器的提示以解决这些问题。经过数轮这样的开发循环，评估器的评分才达到工程师认为合理的水平。即便如此，Harness 输出仍显示出模型 QA 能力的局限：细小的布局问题、部分交互的不直觉感，以及评估器未深入测试的嵌套功能中未被发现的 Bug。
四、迭代简化：当模型变强时，框架该如何瘦身？
4.1 核心原则：Harness 中的每个组件都是对模型能力不足的假设
文章提出了一个深刻的设计原则：Harness 中的每一个组件，都编码了一个关于"模型自身无法做到什么"的假设，而这些假设值得持续压力测试。 原因有二：一是假设可能本来就不正确；二是随着模型迭代，假设会迅速过时。
这与 Anthropic 此前在《Building Effective Agents》一文中提出的核心理念一脉相承——"找到可能最简单的解决方案，只在需要时增加复杂性"。
4.2 从 Opus 4.5 到 Opus 4.6：Sprint 机制的移除
随着 Opus 4.6 的发布，团队有了充分的理由重新审视 Harness 的复杂度。Opus 4.6 在长上下文检索、代理任务持续性、大型代码库可靠性、自我审查和调试能力等方面都有显著提升——而这些恰恰是 Harness 此前需要补充的能力。
团队首先尝试了激进的简化——一次性削减多个组件并引入新想法——但无法复现原始 Harness 的性能，且难以判断哪些部分是真正承载重量的。于是转向更系统的方法：逐个移除组件，观察对最终结果的影响。
最终的关键简化是移除 Sprint 机制。 Sprint 结构此前帮助将工作分解为模型能连贯处理的块，但 Opus 4.6 的改进使模型能够原生处理这种分解。生成器在没有 Sprint 分解的情况下连续连贯工作了超过两小时。
评估器则从逐 Sprint 评分改为在运行结束时进行单次通过评估。 团队发现评估器的价值变得任务依赖性更强：对于落在模型自身能力范围内的任务，评估器成为不必要的开销；但对于仍在模型能力边界处的任务，评估器继续提供真实的质量提升。
4.3 数字音频工作站：简化 Harness 的实战验证
为了验证简化后的 Harness，团队使用了一个更加雄心勃勃的提示：
"Build a fully featured DAW in the browser using the Web Audio API."
最终运行耗时约 4 小时，总成本 124.70 美元。各阶段的资源分配如下：
规划阶段仅用了 4.7 分钟和 0.46 美元——这个投入产出比极为惊人，因为规划器将一句话的提示扩展成了一份包含多个功能模块的完整产品规格。第一轮构建是最大的投入，耗时 2 小时 7 分钟、花费 71.08 美元，生成器在没有 Sprint 分解的情况下保持了连贯的长时间工作。第一轮 QA 发现了关键缺口，指出尽管应用外观出色且 AI 集成工作良好，但多个核心 DAW 功能仅为展示性质而缺乏交互深度——剪辑无法在时间轴上拖拽移动、没有乐器 UI 面板、没有可视化效果编辑器。第二轮 QA 继续捕获了录音功能仍为桩实现、剪辑边缘拖拽和分割未实现、效果可视化仅为数字滑块等问题。
最终的应用虽然远非专业的音乐制作软件，但具备了功能性音乐制作程序的所有核心要素：工作的编排视图、混音器和传输控制全部在浏览器中运行。更重要的是，用户能够完全通过自然语言提示来制作音乐——内置的 AI 代理可以设置节拍和调式、铺设旋律、构建鼓轨、调整混音电平、添加混响效果，自主驱动从零到一的简单音乐制作。
五、方法论提炼：面向 AI 工程师的实践指南
5.1 生成-评估分离的核心价值
文章通过两个截然不同的领域——主观的设计审美和客观的软件功能——验证了同一架构模式的有效性。这一发现具有重要的普适意义：无论任务性质如何，将执行和评判分离到不同代理中，都能提供优于自我评估的反馈质量。
关键在于"可调性不对称"：让一个独立的评估器变得严格，比让执行器对自己的作品保持批判，在工程上要容易得多。
5.2 评分标准设计的杠杆效应
评分标准不仅仅是评分工具，它们本身就是一种隐性的提示工程。标准中的措辞直接塑造了生成器的行为方向。例如，"博物馆级品质"的表述推动了设计向特定风格收敛；对"AI 审美惰性"特征的明确惩罚，促使模型主动规避默认模式。
这意味着设计评分标准时，不仅要关注"评什么"，还要关注"怎么说"——用词本身就是对模型行为的编程。
5.3 上下文管理的策略选择
文章提供了关于上下文压缩与上下文重置两种策略的实证比较。压缩保持连续性但不能消除上下文焦虑；重置提供干净的开始但增加编排复杂度。选择哪种策略取决于具体模型的行为特征——Sonnet 4.5 需要重置，Opus 4.6 则可以仅靠压缩。
这再次印证了 Harness 设计必须与模型能力共同进化的核心观点。
5.4 复杂度的动态平衡
文章中最具洞察力的观点或许是：随着模型改进，有趣的 Harness 组合空间不是在缩小，而是在移动。 模型能力的提升不是让 Harness 工程变得不重要，而是将工程关注点推向新的边界。
今天承载关键质量提升的组件，明天可能因模型改进而变得多余；而今天看似不可能的任务复杂度，明天可能通过新的 Harness 设计变得可行。AI 工程师的工作是持续追踪这条移动中的前沿线。
六、更广阔的视角：对行业实践的启示
6.1 "模型能力 × Harness 设计"的乘数效应
这篇文章最有力地论证了一个观点：在 AI 应用开发中，最终效果 = 模型基础能力 × Harness 设计质量。 两者不是加法关系，而是乘法关系。
一个强大的模型在简陋的 Harness 中运行，输出可能只是"勉强可用"（如案例中的单代理运行）；同一个模型在精心设计的 Harness 中运行，可以产出"令人印象深刻"的结果（如完整 Harness 运行的游戏制作器和数字音频工作站）。
6.2 从"提示工程"到"系统工程"
文章展示的工程实践已经远远超出了传统"提示工程"的范畴。它涉及多代理编排、状态管理、自动化测试、反馈循环设计、评分标准校准、模型行为分析等多个维度。这是一种系统级的 AI 工程， 需要的技能集更接近传统软件架构师，而非简单的提示词优化。
6.3 成本与价值的权衡
文章诚实地展示了 Harness 运行的高成本——200 美元用于一个游戏制作器、124 美元用于一个 DAW。这些数字在当前阶段看似高昂，但需要放在正确的语境中理解：一个人类全栈工程师构建同等功能的应用，所需的时间和成本将远超这些数字。更重要的是，随着模型推理成本的持续下降和 Harness 效率的持续优化，这些成本将快速变得更加可接受。
6.4 AI 工程师的新定位
文章结尾传达的信念值得每一位从业者深思：AI 工程师的核心价值不在于弥补模型的不足（这些不足会随模型迭代自然消失），而在于持续发现新的、有价值的 Harness 组合， 将模型推向此前不可能达到的能力边界。
这是一个永远在移动的前沿，也是一个永远不会消失的工程空间。
结语
Anthropic 这篇技术博客不仅是一份工程案例报告，更是一份关于"人与 AI 如何协作"的方法论宣言。它告诉我们：在智能体时代，最大的杠杆不在于模型本身，而在于我们围绕模型构建的系统。
生成与评估的分离、评分标准的精心设计、上下文管理的策略选择、复杂度的动态调整——这些看似技术性的设计决策，实质上是在回答一个更根本的问题：我们如何信任但不盲从 AI，如何引导但不束缚 AI，如何与 AI 共同进化？
当一个 AI 代理在第十轮迭代中突然决定将一个艺术博物馆网站重构为 3D 空间体验时，它展示的不仅是技术能力，更是一种在正确框架下被激发出的创造力。而设计这个框架——那就是工程师的艺术。
参考来源：Anthropic Engineering Blog, "Harness design for long-running application development", 2026年3月24日
