[译] 长时间运行的应用开发中的 Harness 设计

原文信息
标题：Harness design for long-running application development
作者：Prithvi Rajasekaran
来源：Anthropic Engineering
原文：https://www.anthropic.com/engineering/harness-design-long-running-apps
发布时间：2026-03-24

这篇文章来自 Anthropic 工程团队博客，作者是 Anthropic Labs 团队的 Prithvi Rajasekaran。原文发布于 2026 年 3 月 24 日，标题是 Harness design for long-running application development，讨论的是 Anthropic 如何通过更精细的 harness 设计，把 Claude 推向更长时、更复杂的自主应用开发任务。

我推荐读这篇文章，原因很简单：它谈的不是泛泛的“模型变强了”，而是一个真正落到工程实践里的问题，当你希望 AI 连续工作数小时，真的把一个完整应用做出来时，harness 到底该怎么设计。

Anthropic 给出的思路也很清楚：不要把 agent 当成一个单体黑箱，而要把它拆成多个角色，让它们彼此约束、彼此校验。这对现在正在做 AI Coding、Agent workflow、自动化研发流程的人，都很有参考价值。

下面是正文翻译。

---

作者 Prithvi Rajasekaran，来自 Anthropic Labs 团队。

过去几个月里，我一直在做两个彼此关联的问题：一是让 Claude 产出高质量的前端设计，二是让它在没有人工干预的情况下构建完整应用。

这项工作起源于我们更早之前的两项尝试：一个是前端设计 skill，一个是长时运行的 coding agent harness。在那两项工作里，我和同事们已经通过 prompt engineering 与 harness design，把 Claude 的表现显著推高到了 baseline 之上，但两者最终都撞上了天花板。

为了突破这个瓶颈，我开始寻找一种能同时适用于两个截然不同领域的 AI 工程方法：一个领域由主观审美定义，另一个领域则由可验证的正确性与可用性定义。受生成对抗网络（GAN）的启发，我设计了一个包含 generator 与 evaluator 的多 agent 结构。

而要造出一个既能稳定评分、又“有审美”的 evaluator，首先就得建立一套标准，把“这个设计好不好看？”这种主观判断，转化成具体、可评分的条目。

随后，我又把这些方法应用到长时间运行的自主编程任务上，同时继承了我们早期 harness 工作里的两个经验：第一，把构建过程拆成可处理的块；第二，使用结构化工件在不同 session 之间交接上下文。最终结果是一套由 planner、generator、evaluator 组成的三 agent 架构，它可以在持续数小时的自主 coding session 中，产出较为丰富的全栈应用。

为什么“朴素做法”不够用

我们之前已经展示过，harness design 会显著影响长时运行 agentic coding 的效果。在更早的一次实验里，我们使用了一个 initializer agent，把产品规格拆成任务列表；再由一个 coding agent 按“每次实现一个 feature”的方式推进，并通过工件在不同 session 之间传递上下文。

更广泛的开发者社区，其实也已经收敛到了类似认识上。比如 “Ralph Wiggum” 方法，就是通过 hooks 或脚本让 agent 持续处在迭代循环里。

但有些问题始终存在。任务一复杂，agent 就仍然容易随着时间推移逐步跑偏。我们在拆解这个问题时，观察到了两种常见失败模式。

第一种，是模型在长任务里随着上下文窗口逐渐填满，会开始失去连贯性。有些模型还会表现出一种“上下文焦虑”：它一旦觉得自己快接近上下文上限，就会提前收尾。
解决这个问题的一种方法是 context reset：彻底清空上下文窗口，启动一个新的 agent，再通过一个结构化交接件把前一个 agent 的状态和后续步骤传过去。

这和 compaction 不一样。compaction 是把前面的对话内容就地压缩总结，让同一个 agent 在缩短过的历史上继续工作。它虽然保留了连续性，但没有给 agent 一个真正干净的起点，因此“上下文焦虑”依然可能存在。reset 的代价是，你必须准备足够完整的交接工件，让下一个 agent 能顺利接手。

我们之前测试时发现，Claude Sonnet 4.5 的“上下文焦虑”明显到仅靠 compaction 还不够，因此 context reset 在当时成了 harness design 里的必要组成部分。这个方法能解决核心问题，但也会增加编排复杂度、token 开销和每次运行的延迟。

第二个问题，是我们之前没有重点处理过的：自我评估。当 agent 被要求评价自己刚做出的东西时，它往往会充满自信地夸自己，哪怕在人的眼里，这个结果其实相当平庸。

这个问题在设计这类主观任务中尤为明显，因为这里没有软件测试那种清晰的二元验证机制。一个布局是“精致”还是“普通”，本来就是判断题，而 agent 在给自己打分时，几乎总会偏乐观。

但即便是在那些可以验证结果对错的任务中，agent 也还是会在执行过程中展现出糟糕的判断力，拖累整体表现。把“负责做事的 agent”和“负责评判的 agent”拆开，是解决这个问题的一个强力杠杆。

这种拆分并不会立刻消除宽松倾向，因为 evaluator 本质上仍然是一个 LLM，它天然也会对 LLM 产出的东西偏宽容。但事实证明：把一个独立 evaluator 调到足够怀疑，远比让 generator 对自己变得苛刻要容易得多。 一旦外部反馈存在，generator 就有了可以围绕其迭代的具体目标。

前端设计：把主观质量变成可评分项

我首先在前端设计上做实验，因为这里的“自我评估失真”最明显。如果不做任何干预，Claude 往往会自然滑向那些安全、可预测、技术上能工作但视觉上很平庸的布局。

我为前端设计构建 harness 时，主要有两个关键认识。

第一，审美虽然不可能被完全压缩成一个分数，而且每个人口味都不同，但我们仍然可以通过一套编码了设计原则与偏好的评分标准，来改善输出质量。
“这个设计美不美？”很难稳定回答；但“它是否遵循了我们认定的好设计原则？”就变成了 Claude 可以具体判断的事情。

第二，把“前端生成”和“前端评分”拆开之后，我们就能建立一个反馈回路，推动 generator 逐步走向更强的输出。

基于这个思路，我写了四条评分标准，并把它们同时放进 generator 与 evaluator 的 prompt 中：

• 设计质量：这个设计是否像一个完整统一的整体，而不是零件的堆砌？好的设计应该让配色、排版、布局、图像和其他细节共同构成一种明确的氛围和身份。
• 原创性：这里有没有自定义决策的痕迹，还是只是在套模板、默认组件库和常见 AI 图样？一个人类设计师应该能看出其中存在有意识的创意选择。未经修改的 stock 组件，或者那种典型 AI 痕迹很重的设计，比如白卡片上叠紫色渐变，都应该判失败。
• 工艺：也就是技术执行层面的完成度，比如字体层级、留白一致性、色彩协调、对比度等。这更像能力检查，而不是创意检查。大多数合理实现默认都不会太差；如果这里出问题，说明基础功已经坏了。
• 功能性：不考虑审美，仅看可用性。用户是否能理解界面在做什么，能否找到主要操作，并且不靠猜测就把任务完成？

我刻意把“设计质量”和“原创性”的权重设得高于“工艺”和“功能性”。因为 Claude 默认在工艺与功能性上本来就还不错，模型天然就具备一定技术实现能力；但在设计和原创性上，它给出的东西往往最多只能说“不难看”，远远谈不上出彩。

这套标准明确惩罚那些高度通用化的 “AI slop” 模式，而当我把设计质量与原创性权重拉高后，模型就会被推着去承担更多审美层面的风险。

我还用 few-shot 示例加详细打分拆解，对 evaluator 做了校准。这样能让 evaluator 的判断更贴近我的偏好，也减少迭代过程中评分漂移。

整个循环是基于 Claude Agent SDK 搭起来的，编排并不复杂。generator 先根据用户 prompt 生成一个 HTML/CSS/JS 前端；evaluator 则拿到 Playwright MCP，可以直接和运行中的页面交互，然后按各项标准打分并写出详细评语。

实际运行中，evaluator 会自己浏览页面、截图、认真查看实现，再给出评估。随后，这份反馈会回流给 generator，作为下一轮迭代输入。每次生成我通常会跑 5 到 15 轮，而随着一轮轮批评反馈进入，generator 往往会把产物推向越来越鲜明的方向。

因为 evaluator 不是在对一张静态截图打分，而是在主动浏览页面，所以每一轮都需要实打实的墙钟时间。完整运行最长可以拉到 4 个小时。

我还要求 generator 在每轮评估后都做一个策略判断：如果分数走势不错，就沿着当前方向继续打磨；如果这条路明显不行，就彻底换一种审美方向。

在多次运行中，evaluator 的评分通常会随着迭代提高，然后逐步进入平台期，但依然留有继续提升的空间。有些生成只是渐进式优化；也有些会在中途突然发生明显的审美转向。

有意思的是，评分标准里的措辞本身，也会影响 generator 的风格走向，甚至超过了我的预期。比如我把“最好的设计应当具有 museum quality”这样的说法写进去后，产物就会收敛到一种特定视觉气质上。这说明：与评分标准绑定的 prompt 文案，本身就在塑造输出的性格。

尽管分数整体会在迭代中提高，但这个过程并不总是线性上升。后面的版本通常整体更好，但我也经常会更喜欢中间某一版，而不是最后一版。与此同时，实现复杂度也常常会随着轮次增加，因为 generator 会在 evaluator 的反馈刺激下尝试更激进的方案。

甚至在第一轮输出时，结果就已经明显好于“完全不加 prompt 限制”的 baseline。这说明，哪怕 evaluator 还没开始反馈，单是这套标准和相关语言本身，就已经把模型往远离通用默认值的方向推了一步。

一个很典型的例子是，我让模型做一个荷兰艺术博物馆的网站。到第九轮时，它生成的是一个干净、深色调的虚构博物馆落地页，视觉上已经挺精致，也基本符合我的预期。

但到了第十轮，它把原先方案整个推翻，重新把这个网站想成一种“空间体验”：用 CSS 透视做出一个带棋盘地面的 3D 房间，把作品以非规则形式挂在墙上，再通过“门洞”而不是滚动或点击来穿行不同展厅。
这是一种我过去从单轮生成里几乎没见过的创造性跳跃。

扩展到全栈开发

有了这些发现之后，我把这个受 GAN 启发的模式进一步迁移到了全栈开发上。generator-evaluator 这个循环，天然就能映射到软件开发生命周期里：代码评审和 QA，在结构上扮演的正是设计 evaluator 的角色。

架构设计

在我们之前那版长时 harness 中，我们已经通过 initializer agent、按 feature 推进的 coding agent，以及 session 间的 context reset，解决了多 session coding 的连贯性问题。
context reset 当时是一个关键突破点，因为 Sonnet 4.5 确实存在前面提到的“上下文焦虑”问题。

但到了 Opus 4.5，这种行为基本已经显著缓解，所以我这次直接把 context reset 整个拿掉了。所有 agent 都在一个连续 session 中完成整次构建，靠 Claude Agent SDK 自带的自动 compaction 来处理上下文增长。

在原始 harness 的基础上，我这次做的是一个三 agent 系统，每个 agent 都对应我在之前实验里观察到的一类短板：

1）Planner

以前那套 harness 要求用户一开始就给非常详细的 spec。我想把这一步自动化，于是做了一个 planner agent：它接收一个只有 1 到 4 句话的简短 prompt，然后把它扩展成完整产品规格。

我要求 planner 在 scope 上更有野心，同时把重点放在产品语境和高层技术设计上，而不是一开始就写死细节实现。

原因很简单：如果 planner 一上来就在细节技术设计上出错，这些错误就会沿着 spec 一路级联到后续实现里。相比之下，更聪明的做法是把 agent 约束在“必须交付什么结果”上，而把具体路径留给它们在执行过程中自己找。

我还专门要求 planner 尽量把 AI feature 编织进产品规格里。原文底部附录里也给了一个 planner 生成 spec 的示例。

2）Generator

我们之前那种“一次只做一个 feature”的方法，在 scope 管理上效果很好，所以这里我延续了类似思路，让 generator 以 sprint 为单位工作，每次从 spec 里拿一个 feature 来完成。

每个 sprint 用的技术栈是 React、Vite、FastAPI 和 SQLite（后面部分实验换成了 PostgreSQL）。同时我要求 generator 在每个 sprint 结束时先自评，再把结果交给 QA。它还可以使用 git 做版本控制。

3）Evaluator

以前 harness 产出的应用经常“看着很厉害”，但你真点进去用时，仍然会发现不少真实 bug。为了抓这些问题，evaluator 使用 Playwright MCP，像真实用户一样点击和操作运行中的应用，测试 UI 功能、API endpoint 以及数据库状态。

然后它会按照两套东西打分：一套是自己实际找出的 bug；另一套则是一组参照前端实验改造过来的标准，包括产品深度、功能性、视觉设计和代码质量。

每条标准都有硬门槛，只要其中任意一项低于阈值，这个 sprint 就算失败，generator 会收到非常具体的失败反馈。

另外，在每个 sprint 开始之前，generator 和 evaluator 还会先协商一个 sprint contract：在一行代码都没写前，先约定这一小段工作什么样才算 done。

之所以需要这个步骤，是因为产品 spec 本身是故意保持高层抽象的，我需要有一个桥梁，把 user story 连接到“可测试的实现目标”上。generator 会先提议：这轮要做什么、如何验证成功；evaluator 再去审核这个提议，确认 generator 正在造的是对的东西。双方会反复来回，直到达成一致。

整个沟通是通过文件进行的：一个 agent 写文件，另一个 agent 读文件，并在同一文件或新文件里给出回应，前一个 agent 再回来读取。随后 generator 按双方确认好的 contract 开始构建，再把结果交给 QA。

这种方式既能保持实现对 spec 的忠实，又能避免太早把实现细节写死。

运行这套 harness

这套 harness 的第一版，我使用的是 Claude Opus 4.5。我把用户 prompt 同时喂给完整 harness 和一个单 agent 系统来做对照，因为在我开始做这些实验时，Opus 4.5 还是我们最强的 coding model。

我当时给出的测试 prompt 是：

创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为系统，以及可试玩测试模式。

下表是两种 harness 的运行时长与总成本：

Harness	时长	成本
单 agent	20 分钟	9 美元
完整 harness	6 小时	200 美元

完整 harness 的成本高出了 20 倍以上，但输出质量上的差异几乎是一眼可见。

我原本期待的是一个可以让我搭关卡、做精灵、定义实体和 tile 布局，然后点一下 play 真正跑起来的界面。打开单 agent 版本时，表面上看它似乎也朝这个方向靠拢了。

但随着我开始点击和操作，问题很快出现。布局浪费空间，固定高度面板让大部分视口都空着；工作流很生硬；如果你想往关卡里放内容，它会让你先去做 sprite 和 entity，但界面又完全没有告诉你这件事。更关键的是，游戏本身其实是坏的：实体能出现在屏幕上，却完全不响应输入。

我再往代码里挖，发现是 entity 定义和游戏运行时之间的连接线断了，而且界面上没有任何明显迹象能指向这个问题。

接着我去看完整 harness 的版本。它从同样一句 prompt 出发，但 planner 会先把这句话扩展成一个覆盖 16 个 feature、拆成 10 个 sprint 的完整 spec。它远远超出了单 agent 版本尝试的范围。

除了核心编辑器和 play mode 之外，这份 spec 还包括精灵动画系统、行为模板、音效与音乐、AI 辅助的 sprite 生成器与关卡设计器，以及可通过链接分享的游戏导出功能。

我还给 planner 开了我们自己的 frontend design skill 读取权限，让它把一套视觉设计语言一起写进 spec。每个 sprint 里，generator 和 evaluator 都会先协商一份 contract，明确这轮的具体实现细节，以及完成后要如何测试验证。

从一开始，这个应用就比单 agent 版本更完整、更顺滑。画布能吃满整个视口，面板尺寸更合理，界面也形成了和 spec 中设计方向一致的视觉身份。

当然，单 agent 版里我见到的一些笨拙之处也没有完全消失。比如它依旧没有明确告诉我“应该先建 sprite 和 entity，再去布置关卡”，我仍然需要自己摸索出来。这更像是底层模型产品直觉上的不足，而不是 harness 专门在解决的问题，但它也提示了一个方向：如果在 harness 里继续定向迭代，这类问题也许还能继续改善。

随着我继续使用编辑器，完整 harness 相对单 agent 的优势就越来越明显了。sprite editor 更丰富、更完整，工具面板更清爽，颜色选择器更好用，缩放控制也更顺手。

因为我要求 planner 把 AI feature 也织进 spec，所以这个应用还自带了 Claude 集成，允许我通过 prompt 直接生成游戏的不同部分，这大幅加快了工作流。

最大的差异出现在 play mode。这个版本里，我真的能移动自己的实体，并把游戏玩起来。虽然物理系统还有些粗糙，比如角色跳上平台后会和平台发生一点重叠，直觉上不太对，但核心能力至少已经成立了，而这是单 agent 版本根本没做到的。

再继续玩，我也确实碰到一些 AI 设计关卡时的局限，比如有一道高墙我根本跳不过去，导致游戏卡死。这说明 harness 依然还有继续处理常识问题与边界情况的空间。

原文这里还附了一段 RetroForge 的演示视频，我已同步下载到本地：assets/videos/retroforge-demo.mp4。如果需要在线对应源链接，可查看原文视频地址：RetroForge demo。

看日志时，我能很清楚地看到 evaluator 是如何把实现拉回 spec 轨道上的。每个 sprint，它都会对照 sprint contract 里的测试标准，通过 Playwright 去操作运行中的应用，只要发现与预期不符的地方就记成 bug。

这些 contract 写得非常细，单是 Sprint 3 就有 27 条验证标准，光关卡编辑器这一部分就拆得很细；而 evaluator 找出来的问题，也足够具体到 generator 不需要额外排查就可以直接修。

原文给了几个 evaluator 抓到的问题例子：

• 合同要求：矩形填充工具应支持拖拽填充一个矩形区域。
  实际发现：失败。工具只会在拖拽的起点和终点放 tile，并没有真正填充中间区域。fillRectangle 函数虽然存在，但没有在 mouseUp 时正确触发。
• 合同要求：用户可以选中并删除已经放置的实体出生点。
  实际发现：失败。LevelEditor.tsx:892 里的删除按键处理同时要求 selection 和 selectedEntityId 都被设置，但点击实体时实际上只设置了 selectedEntityId。条件应改成 selection || (selectedEntityId && activeLayer === 'entity')。
• 合同要求：用户可通过 API 重新排序动画帧。
  实际发现：失败。PUT /frames/reorder 路由写在 /{frame_id} 路由之后，FastAPI 会把 reorder 当成 frame_id 整数去解析，最终返回 422。

要把 evaluator 调到这种水平，并不是开箱即用的。Claude 默认并不是一个优秀 QA agent。早期实验里，我经常看到它明明识别出了真实问题，却又自己把自己说服，最后觉得“问题也没那么大”，然后把活批准通过。

它还很容易只做表层测试，不去深挖边界情况，所以很多更隐蔽的 bug 会漏掉。我的调参循环基本就是：读 evaluator 日志，找出它的判断和我不一致的例子，然后修改 QA prompt 去修正这些偏差。

要做到我觉得“还算合理”的评分方式，中间反复迭代了好几轮。即便如此，最终输出依然暴露出模型 QA 能力的上限：还有一些小布局问题、一些操作上并不顺手的交互，以及一些藏得更深、evaluator 没充分走到的功能 bug。也就是说，继续调的话，验证层面依旧有不少上升空间。

但和单 agent 那个“应用最核心功能压根不能用”的版本相比，提升已经非常明显了。

继续迭代 harness

第一版 harness 的结果很鼓舞人，但它也确实又大、又慢、又贵。下一步自然就是想办法在不明显降低效果的前提下，把 harness 简化下来。

这既是工程直觉，也来自一个更普遍的原则：harness 里的每一个组件，都隐含着你对“模型单独做不到什么”的一个假设。 这些假设本身值得不断被压力测试，因为它们可能一开始就不对，也可能随着模型进步很快过时。

Anthropic 在《Building Effective Agents》那篇文章里把这件事概括为一句话：先找尽可能简单的方案，只有在确实需要时再增加复杂度。只要你在维护 agent harness，这个模式几乎一定会反复出现。

我第一次尝试简化时，做法很激进，直接大幅削掉了一堆结构，还试了一些新的创意点子，但结果没能复现原始版本的效果。与此同时，也越来越难分辨到底哪些组件是“真正承重”的，以及它们究竟在什么层面起作用。

有了这次经验之后，我改用更系统的方法：每次只移除一个组件，然后观察它对最终结果到底造成什么影响。

就在我做这些迭代的时候，我们也发布了 Opus 4.6，这进一步强化了“应该降低 harness 复杂度”的动机。因为很明显，4.6 理应比 4.5 需要更少脚手架。

Anthropic 在发布博客里是这么描述 4.6 的：它“规划更谨慎、能更长时间维持 agentic task、在大代码库里更可靠、代码审查和调试能力更强，能更好地发现自己的错误”，而且在长上下文检索上也有显著提升。
这些，恰恰都是我们之前那套 harness 原本想补上的能力。

移除 sprint 结构

我做的第一步简化，就是把 sprint 结构整个拿掉。sprint 原本的作用，是把工作切成更小块，让模型更稳定地推进。考虑到 Opus 4.6 的能力提升，我有充分理由相信：模型也许已经能在没有这种分解结构的情况下，直接处理这份工作。

不过，我还是保留了 planner 和 evaluator，因为它们依然明显有价值。没有 planner 的话，generator 往往会 scope 不足：面对原始 prompt，它会直接开干，却不先把工作规格化，最后做出来的应用特性就明显少于 planner 版本。

在去掉 sprint 之后，我把 evaluator 调整为只在整轮构建结束后做一次总评，而不再按 sprint 打分。随着模型能力提升，evaluator 的“承重程度”也发生了变化：它到底值不值，开始越来越取决于任务相对于当前模型能力边界的位置。

在 4.5 上，这条边界离得很近。我们的构建任务本来就处在 generator 单兵能力的边缘，因此 evaluator 能在整个构建过程中抓出很多关键问题。但到了 4.6，模型的原生能力提高了，这条边界就被往外推了。

那些过去必须依赖 evaluator 才能保证实现不跑偏的任务，现在很多已经进入了 generator 自己就能稳定完成的范围。在这些任务上，evaluator 反而变成了纯额外开销。

但对于那些仍然处在 generator 能力边缘的构建部分，evaluator 依然能带来非常真实的提升。

现实含义就是：是否需要 evaluator，并不是一个静态的“是或否”问题。 当任务超过当前模型单兵可靠范围时，它值得那个成本；否则，它可能只是负担。

除了结构上的简化，我还额外加了一些 prompt，让 harness 在每个 app 中更好地生成 AI feature，尤其是让 generator 去真正构建一个能通过 tools 驱动应用自身功能的 agent。

这部分也花了不少调试时间，因为相关知识太新，Claude 的训练数据覆盖得还不够厚。但在足够多的 prompt 调整之后，generator 最终的确能把 agent 正确搭出来。

更新后 harness 的结果

为了测试新版 harness，我给了它这样一个 prompt，让它生成一个 DAW，也就是数字音频工作站：

用 Web Audio API 在浏览器里构建一个功能完整的 DAW。

这次运行依然很长、也依然不便宜，大约跑了 4 个小时，token 成本约 124 美元。

大部分时间都花在 builder 上。它在没有 sprint 分解的情况下，依然连贯运行了两个多小时，而这正是 Opus 4.5 时代还做不到的。

Agent / 阶段	时长	成本
Planner	4.7 分钟	0.46 美元
Build（第 1 轮）	2 小时 7 分钟	71.08 美元
QA（第 1 轮）	8.8 分钟	3.24 美元
Build（第 2 轮）	1 小时 2 分钟	36.89 美元
QA（第 2 轮）	6.8 分钟	3.09 美元
Build（第 3 轮）	10.9 分钟	5.88 美元
QA（第 3 轮）	9.6 分钟	4.06 美元
V2 Harness 总计	3 小时 50 分钟	124.70 美元

和前一版 harness 一样，planner 会先把一句话 prompt 扩展成完整 spec。从日志里看，generator 在规划应用与 agent 设计、把 agent 接进系统，以及在交给 QA 前先自己测试这些事情上，整体表现都不错。

不过，QA agent 依然能抓到真实缺口。它在第一轮反馈里写道：

这是一个很强的应用，设计一致性很好，AI agent 也可靠，后端也不错。主要失分点在于“功能完整度”：虽然应用看起来很像样，AI 集成也工作正常，但几个核心 DAW 功能仍然只是展示层，没有真实交互深度。比如 clip 不能在时间线上拖拽移动，没有乐器控制面板（比如合成器旋钮、鼓垫），也没有可视化效果编辑器（比如 EQ 曲线、压缩器表盘）。

这些并不是边角问题，而是让一个 DAW 真正可用的核心交互，而且 spec 里明确写了这些要求。

它在第二轮反馈里又继续抓出了几类功能缺口：

• 音频录制仍然只是 stub，按钮会切换，但并没有真正采集麦克风输入
• 还没有实现通过拖拽边缘调整 clip 长度，也没有 clip split
• 效果器的可视化仍然只是数字滑杆，不是图形化编辑器，例如 EQ 曲线

这说明 generator 如果单独工作，仍然会漏细节，或者把一些 feature 先用 stub 敷过去；而 QA 在这种最后一公里问题上，仍然有明确价值。

按照 prompt，我期待的是一个能让我写旋律、做和声、编鼓点、把它们排成一首歌，并在过程中得到内建 agent 辅助的程序。原文的视频展示说明，最终结果已经相当接近这个方向。

原文这里也附了一段 DAW 演示视频，我已同步下载到本地：assets/videos/daw-demo.mp4。对应源链接是：DAW demo。

当然，这个 app 距离专业音乐制作软件还差得远，agent 在作曲上的能力也明显还有很大提升空间。再加上 Claude 实际上“听不见”，所以在音乐审美这件事上，QA 反馈闭环天然没那么有效。

但最终版本已经具备了一个可用音乐制作程序的核心积木：浏览器里可运行的编曲视图、mixer 和 transport 都已经齐了。更重要的是，我真的能仅通过 prompt 拼出一个短歌曲片段：agent 会设置速度和调性、铺旋律、做鼓轨、调混音、加混响。

也就是说，做歌所需的核心原语已经存在，而且 agent 可以通过 tools 自主驱动这些原语，把一段简单制作从头到尾跑通。你可以说它离“完美音准”还差很远，但它确实正在逼近。

接下来会怎样

随着模型继续提升，我们大致可以预期：它们会越来越能长时间工作，也越来越能处理复杂任务。

在某些情况下，这意味着围绕模型搭建的脚手架会随着时间推移变得没那么重要。开发者可以等下一代模型出来，然后看着某些老问题自己消失。

但另一方面，模型越强，可供 harness 发挥的空间其实也越大。因为你可以把 harness 设计到一个更高层级，让它完成那些“单模型 baseline 仍然做不到”的复杂任务。

基于这项工作，我觉得有几条经验值得带走：

• 无论如何，和你正在使用的模型做充分实验、读它在真实问题上的 traces，并围绕你想要的结果去调它，始终是好习惯。
• 当任务更复杂时，把问题拆开，并为问题的不同部分配上专门 agent，很多时候确实还能榨出额外 headroom。
• 每当新模型发布，最好都重新审视一次自己的 harness：把那些已经不再承重的部分拆掉，再加入一些以前做不到、但现在也许可以做到的新结构。

这项工作让我形成了一个越来越强的判断：随着模型变强，有趣的 harness 组合空间并不会缩小。它只是在移动。
而 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 是一个基于 Web 的 2D 复古游戏创作工作室，面向想做 8-bit / 16-bit 风格游戏的创作者
• 它整合了四个核心模块：关卡编辑器、像素风精灵编辑器、可视化实体行为系统，以及即时试玩模式
• Claude 驱动的 AI 辅助会贯穿创作流程，用自然语言帮助用户生成精灵、设计关卡、配置行为
• 目标用户是喜欢复古游戏美学、但又想要现代工具便利性的创作者

附录的作用，主要是展示 planner 会把一句非常短的 prompt，扩展成一份怎样粒度的完整产品规格。