长周期应用开发的 Harness 设计

过去几个月，我一直在研究两个彼此关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在无人干预的情况下构建完整应用。

这项工作源自我们此前在前端设计 Skill 和长时间运行编码 Agent Harness 上的探索。在那些工作中，我和同事通过提示词工程与 Harness 设计，让 Claude 的表现显著超过基线，但两条路线最终都遇到了性能上限。

为了突破这些限制，我开始寻找一种能够同时适用于两个截然不同领域的新型 AI 工程方法：一个领域由主观审美决定，另一个领域则有可验证的正确性和可用性。

受到生成对抗网络（Generative Adversarial Networks，GAN）的启发，我设计了一种由 Generator Agent 和 Evaluator Agent 组成的多 Agent 结构。

要构建一个能够可靠地、并且真正带有“审美判断”地评价输出的 Evaluator，首先需要制定一套评判标准，把“这个设计好不好？”这类主观判断转化为具体、可评分的指标。

随后，我把这些技术应用到了长时间运行的自主编码任务中，并保留了我们此前 Harness 工作中的两个关键经验：

• 把完整构建过程拆分成可处理的小块；

• 使用结构化 Artifact 在不同会话之间传递上下文。

最终形成的是一个由三个 Agent 组成的架构：Planner、Generator 和 Evaluator。它能够在持续数小时的自主编码会话中生成内容丰富的全栈应用。

为什么朴素实现会失效

我们此前已经证明，Harness 设计会显著影响长时间运行 Agentic Coding 的有效性。

在之前的一次实验中，我们使用一个 Initializer Agent 把产品规格拆分成任务列表，再让 Coding Agent 每次实现一个功能，并通过 Artifact 把上下文传递给后续会话。

更广泛的开发者社区也逐渐得出了类似结论。例如所谓的“Ralph Wiggum”方法，会通过 Hook 或脚本让 Agent 持续处于迭代循环中。

但一些问题依然长期存在。

对于更复杂的任务，Agent 随着时间推移仍然容易逐渐偏离轨道。拆解这个问题后，我们观察到此类任务中有两个常见失败模式。

第一个问题，是当上下文窗口逐渐被填满时，模型在长任务中的整体连贯性会下降。

一些模型还会表现出一种“上下文焦虑（context anxiety）”：当它们认为自己快接近上下文上限时，会开始过早收尾工作。

上下文重置（context reset）能够同时解决这两个问题。

所谓上下文重置，就是完全清空当前上下文窗口并启动一个新的 Agent，同时使用结构化交接文件把上一位 Agent 的状态和下一步工作传递过去。

这和压缩（compaction）不同。

压缩会原地总结对话早期内容，让同一个 Agent 在缩短后的历史上继续运行。

压缩能够保持一定连续性，但不会真正给 Agent 一张“白纸”，因此上下文焦虑依然可能持续存在。

重置则会给 Agent 一个真正干净的起点，代价是交接 Artifact 必须包含足够完整的状态，让下一位 Agent 能够顺利接手工作。

在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑非常明显，单纯依靠压缩不足以让它稳定完成长任务，因此上下文重置成为 Harness 设计中的关键组成部分。

这种方法解决了核心问题，但也带来了额外的编排复杂度、Token 开销和延迟。

第二个此前没有被充分解决的问题，是自我评价。

当要求 Agent 评价自己刚刚完成的工作时，它们往往会非常自信地称赞自己的成果，即使在一个人类观察者看来，其质量显然只能算一般。

这个问题在设计这种主观任务中尤其明显，因为这里不存在类似软件测试那样明确的二元验证。

一个布局究竟显得精致还是千篇一律，本质上属于判断问题，而 Agent 在给自己的成果打分时会稳定地偏向正面。

不过，即使对于有明确可验证结果的任务，Agent 在执行过程中也有时会表现出糟糕判断，从而影响最终结果。

把“做工作”的 Agent 与“判断工作”的 Agent 分离，是解决这一问题的一个强力杠杆。

当然，这种分离本身并不会立刻消除宽松倾向，因为 Evaluator 本身仍然是一个 LLM，也同样容易对 LLM 生成的内容过于宽容。

但相比让 Generator 对自己的工作变得严格批判，单独调教一个专门的 Evaluator，让它更加怀疑和挑剔，要容易得多。

一旦外部评价存在，Generator 就获得了具体的反馈目标，可以围绕这些反馈持续迭代。

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

我首先在前端设计任务上进行了实验，因为自我评价问题在这里最明显。

如果不做任何干预，Claude 通常会倾向于安全、可预测的布局。这些设计在技术上可以正常工作，但视觉上往往平淡无奇。

我为前端设计构建 Harness 时，有两个关键洞察。

第一，审美当然无法完全压缩成一个分数，而且每个人的品味永远不同，但我们可以通过把设计原则和偏好编码进评分标准来提升审美结果。

“这个设计漂亮吗？”很难得到稳定答案。

但“这个设计是否符合我们定义的优秀设计原则？”就为 Claude 提供了具体的判断依据。

第二，如果把前端生成和前端评分分开，就能够建立一个反馈循环，不断推动 Generator 产生更强的输出。

基于这一思路，我设计了四项评分标准，并同时写进 Generator 和 Evaluator 的提示词中。

设计质量

设计是否像一个完整、统一的整体，而不是一堆零散部件？

高质量作品意味着颜色、字体、布局、图像以及其他细节能够组合起来，共同形成鲜明的氛围和身份。

原创性

设计中是否存在明显的定制决策，还是仅仅使用模板布局、组件库默认样式和常见 AI 生成套路？

一个人类设计师应该能够看出其中存在有意识的创作选择。

未经修改的现成组件，或者白色卡片配紫色渐变这种典型 AI 生成痕迹，都无法通过这一项。

工艺水平

这是技术执行能力，包括：

• 字体层级；

• 间距一致性；

• 色彩协调；

• 对比度。

这一项更多是在检查基本功，而不是创造力。

大多数合理实现默认都能取得不错成绩；如果这一项失败，通常意味着基础设计原则本身就出了问题。

功能性

这一项只关注可用性，与审美无关。

用户是否能够理解界面的用途？

是否能够找到主要操作？

能否在不靠猜测的情况下完成任务？

在这些标准中，我更强调“设计质量”和“原创性”，而不是“工艺水平”和“功能性”。

因为 Claude 默认已经能够在工艺和功能方面取得不错表现，这些所需要的技术能力对模型来说相对自然。

但在设计和原创性方面，Claude 经常只能产出平庸甚至乏味的结果。

因此，这些标准会明确惩罚高度通用的“AI 垃圾设计”模式。

通过提高设计质量和原创性的权重，模型就会被推动去承担更大的审美风险。

我还使用带有详细评分拆解的 Few-shot 示例校准 Evaluator。

这样可以让 Evaluator 的判断更加贴近我的设计偏好，同时减少不同迭代之间的评分漂移。

整个循环建立在 Claude Agent SDK 上，因此编排本身相对简单。

首先，由 Generator Agent 根据用户提示词生成 HTML、CSS 和 JavaScript 前端。

随后，我为 Evaluator 提供 Playwright MCP，使它能够直接与正在运行的页面交互，然后分别对各项指标评分，并撰写详细批评。

实际运行中，Evaluator 会自己浏览页面、截取屏幕截图并认真分析实现，再给出判断。

这些反馈会重新传给 Generator，作为下一轮迭代的输入。

每次生成我通常会运行 5 到 15 轮。

随着 Generator 不断回应 Evaluator 的批评，每一轮通常都会把设计推动到更鲜明、更独特的方向。

因为 Evaluator 并不是只查看一张静态截图，而是真正在页面中操作，所以每一次循环都需要真实的运行时间。

完整运行有时会持续四个小时。

我还要求 Generator 在每轮评价之后做一次战略选择：

如果分数走势良好，就继续完善当前设计方向；

如果当前方向效果不好，就彻底放弃，转向另一种完全不同的审美方案。

在多次运行中，Evaluator 的评分通常会随着迭代不断提高，最终进入平台期，不过仍然存在进一步提升空间。

有些生成结果会持续做小幅改良。

另一些则会在不同迭代之间出现明显的审美转向。

评分标准本身的措辞，也会以一些我最初没有完全预料到的方式影响 Generator。

例如，我在标准中写过“最好的设计应该达到博物馆级质量”这样的表述。

结果生成内容逐渐向某一种特定视觉风格收敛，说明评分标准中的提示词会直接塑造最终输出的整体性格。

尽管评分整体会随着迭代提升，但变化并不总是严格线性的。

后期实现整体上通常更好，但我也经常遇到自己更喜欢中间某一轮，而不是最后一轮的情况。

与此同时，实现复杂度也会随着迭代逐渐增加。

为了响应 Evaluator 的反馈，Generator 会越来越倾向于尝试更大胆、更复杂的实现方式。

值得注意的是，即使只是第一轮，在还没有收到任何 Evaluator 反馈之前，结果通常也已经明显优于完全不加提示词的基线。

这说明评分标准以及相关语言本身，就能够在反馈循环开始前把模型从通用默认方案中推开。

有一个很典型的例子。

我让模型为一家荷兰艺术博物馆创建网站。

到第九轮时，它已经生成了一个干净、暗色调的虚构博物馆首页。

视觉完成度不错，但整体基本符合我的预期，没有特别出人意料。

然而到了第十轮，它把此前方案完全推翻，重新把网站想象成一种空间体验：

页面变成了一个使用 CSS 透视绘制的 3D 房间，地板是棋盘格，艺术品以自由布局方式悬挂在墙上，而不同展厅之间则使用“门”进行导航，不再依靠传统滚动或点击。

这是我此前从未在一次单轮生成中看到过的那种创造性跳跃。

扩展到全栈编码

有了上述经验之后，我把这种受到 GAN 启发的模式应用到了全栈开发。

Generator–Evaluator 循环天然对应软件开发生命周期，其中 Code Review 和 QA 扮演的结构角色，与前端实验中的 Evaluator 非常类似。

架构

在之前的长时间运行 Harness 中，我们通过以下结构解决了跨会话编码的一致性问题：

• Initializer Agent；

• 每次只处理一个功能的 Coding Agent；

• 不同会话之间进行 Context Reset。

Context Reset 是一个关键突破。

当时 Harness 使用的是 Sonnet 4.5，而它存在前面提到的“上下文焦虑”。

因此，设计一个能够在上下文重置之后依然稳定工作的 Harness，是让模型持续专注于任务的关键。

Opus 4.5 基本上自己消除了这一行为，因此在新的 Harness 中，我能够完全移除 Context Reset。

整个构建期间，Agent 都可以在同一个连续会话中运行，并依靠 Claude Agent SDK 的自动压缩来处理不断增长的上下文。

在这项工作中，我基于原 Harness 构建了一个由三个 Agent 组成的系统。

每个 Agent 都针对之前实验中发现的一个具体问题。

Planner

之前的长时间运行 Harness 要求用户一开始就提交非常详细的规格。

我希望自动完成这一步，所以创建了 Planner Agent。

它会接收用户的一段简单提示词，通常只有 1 到 4 句话，然后把它扩展成完整产品规格。

我要求 Planner 在功能范围上尽可能有野心，但重点放在产品上下文和高层技术设计上，而不是过早规定详细技术实现。

之所以这样做，是因为如果 Planner 一开始就定义了过于细粒度的技术细节，而这些细节又存在错误，那么这些错误就会不断向后续实现阶段传播。

更合理的方式是：

约束 Agent 最终需要交付什么，然后让它们在真正工作过程中自行决定实现路径。

此外，我还要求 Planner 主动寻找机会，把 AI 功能融入产品规格。

本文末尾的附录中提供了一个示例。

Generator

旧 Harness 中“一次一个功能”的方法对于控制范围非常有效。

这里我采用了类似方法，不过把工作组织成 Sprint。

Generator 每次从产品规格中选择一个功能进行实现。

每个 Sprint 都使用以下技术栈构建应用：

• React；

• Vite；

• FastAPI；

• SQLite，之后改为 PostgreSQL。

Generator 还会使用 Git 进行版本控制。

在每个 Sprint 结束时，我要求 Generator 先自行检查工作，再把结果交给 QA。

Evaluator

此前 Harness 生成的应用往往乍看非常惊艳，但真正使用之后仍然存在实际 Bug。

为了发现这些问题，Evaluator 会使用 Playwright MCP，像真正用户一样点击和操作正在运行的应用。

它会测试：

• UI 功能；

• API Endpoint；

• 数据库状态。

然后根据它发现的 Bug，以及一组改编自前端实验的评分标准，对每个 Sprint 进行评分。

这里的评分标准包括：

• 产品深度；

• 功能性；

• 视觉设计；

• 代码质量。

每一项都有硬性阈值。

只要有任何一个指标低于阈值，这个 Sprint 就会被判定失败，然后 Generator 会收到详细反馈，了解具体出了什么问题。

在每一个 Sprint 开始之前，Generator 和 Evaluator 还会先协商一份 Sprint Contract。

也就是说，在写任何代码之前，双方先对这一个工作块中“完成”的定义达成一致。

引入这一步，是因为产品规格本身刻意保持在高层级，我需要一个中间环节，把用户故事转换成可测试的实现目标。

Generator 会先提出：

• 自己准备实现什么；

• 如何验证成功。

Evaluator 则会审查这个提议，确认 Generator 确实准备构建正确的东西。

双方持续迭代，直到达成一致。

Agent 之间通过文件通信。

一个 Agent 写入文件，另一个 Agent 读取并在这个文件中回复，或者创建一个新的文件，再由前一个 Agent 阅读。

达成 Sprint Contract 后，Generator 会根据合同实施，然后再把结果交给 QA。

这样既能保证实现始终忠于产品规格，又不会过早把技术实现规定得过于死板。

运行 Harness

第一版 Harness 使用的是 Claude Opus 4.5。

我使用同一批用户提示词分别测试完整 Harness 与单 Agent 系统，以进行比较。

之所以使用 Opus 4.5，是因为在我开始这项实验时，它是我们最好的编码模型。

我使用了下面这条提示词，让模型生成一个复古电子游戏制作器：

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

运行结果如下：

Harness	运行时间	成本
单 Agent	20 分钟	9 美元
完整 Harness	6 小时	200 美元

完整 Harness 的成本超过单 Agent 的 20 倍，但输出质量的差距也非常明显。

我原本期待的是这样一个界面：

可以构建关卡及其组成元素，包括精灵、实体和 Tile 布局，然后点击 Play，直接实际游玩这个关卡。

我先打开了单 Agent 运行生成的结果。

最开始看起来基本符合预期。

但随着不断点击和使用，问题开始出现。

布局浪费了大量空间，一些固定高度面板导致大部分 Viewport 都处于空白状态。

工作流也非常僵硬。

当我尝试填充关卡时，系统要求我先创建精灵和实体，但 UI 中没有任何设计能够引导用户理解这个步骤顺序。

更关键的是，游戏实际上坏了。

实体能够出现在屏幕上，但完全不会响应输入。

进一步查看代码后发现，实体定义与游戏运行时之间的连接出了问题，而界面本身没有任何地方提示这个错误。

单 Agent Harness 创建应用后的初始界面。

单 Agent Harness 中的精灵编辑器。

尝试游玩自己创建的关卡，但未能成功。

评测完单 Agent 结果后，我开始查看完整 Harness 的运行结果。

它同样从一句话提示词开始，但 Planner 会先把这句话扩展成一个包含 16 个功能、分布在 10 个 Sprint 中的完整规格。

它的范围远远超过单 Agent 的尝试。

除了核心编辑器和 Play Mode 之外，规格中还包含：

• 精灵动画系统；

• 行为模板；

• 音效和音乐；

• AI 辅助精灵生成器；

• AI 关卡设计器；

• 游戏导出；

• 可分享链接。

我还让 Planner 读取我们的前端设计 Skill，并使用其中的原则，为这个应用定义一套完整的视觉设计语言。

对于每一个 Sprint，Generator 和 Evaluator 都会先协商 Contract，其中定义：

• 本轮要实现哪些具体内容；

• 将通过哪些可测试行为判断是否完成。

应用一打开，就明显比单 Agent 版本更加精致流畅。

Canvas 会充分使用整个 Viewport，面板尺寸更加合理，而且界面具有统一的视觉身份，与规格中定义的设计方向一致。

单 Agent 中的一部分笨拙问题仍然存在。

例如，工作流依旧没有明确告诉用户：应该先创建精灵和实体，然后再去填充关卡。

我仍然需要自己试着点击，才能理解正确流程。

这更像是基础模型在产品直觉方面的不足，而不是 Harness 本身原本试图解决的问题。

但它也说明，如果在 Harness 中增加针对这方面的迭代机制，还有进一步提升输出质量的空间。

继续使用各个编辑器后，完整 Harness 相对单 Agent 的优势更加明显。

精灵编辑器更加丰富完整：

• 工具面板更干净；

• 颜色选择器更好；

• 缩放控制也更加易用。

因为我要求 Planner 在产品规格中加入 AI 能力，所以应用还内置了 Claude 集成，可以直接通过提示词生成游戏中的不同内容。

这显著加快了整个创作流程。

完整 Harness 构建的应用初始界面：创建新游戏。

精灵编辑器更加干净，也更容易使用。

使用内置 AI 功能生成关卡。

使用内置 AI 功能生成关卡。

游玩生成出来的游戏。

最大的差异出现在 Play Mode。

这一次，我真的能够移动自己的实体并玩游戏。

物理系统仍然有一些粗糙之处。

例如，我让角色跳到一个平台上时，角色会和平台发生重叠，这在直觉上明显不对。

但最核心的功能终于真正工作了，而单 Agent 版本没有做到这一点。

继续移动一段时间后，我也发现 AI 构建关卡存在一些局限。

某处出现了一堵很大的墙，而角色无法跳过去，于是我被困住了。

这说明 Harness 仍然可以增加一些常识层面的检查和边缘情况处理，以进一步完善应用。

阅读运行日志之后，可以很清楚地看到 Evaluator 一直在保证实现不偏离规格。

每一个 Sprint 中，它都会逐项执行 Sprint Contract 中的测试标准，并通过 Playwright 操作实际运行的应用。

任何与预期行为不一致的地方，都会被记录成 Bug。

这些 Contract 的粒度非常细。

例如，仅 Sprint 3 的关卡编辑器就包含 27 条标准。

Evaluator 的发现也足够具体，开发者可以直接修复，而不需要再次调查问题。

下面是 Evaluator 识别出的几个问题示例。

Contract 标准	Evaluator 发现
矩形填充工具允许用户通过点击并拖动，用当前 Tile 填充一个矩形区域	失败：工具只会在拖动起点和终点放置 Tile，而不是填满整个区域。fillRectangle 函数已经存在，但没有在 mouseUp 时被正确触发。
用户可以选择并删除已经放置的实体出生点	失败：LevelEditor.tsx:892 中 Delete 键处理器要求 selection 和 selectedEntityId 同时存在，但点击实体时只会设置 selectedEntityId。条件应该是 `selection		(selectedEntityId && activeLayer === 'entity')`。
用户可以通过 API 重新排序动画帧	失败：PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 会把 reorder 当成整数类型的 frame_id，最终返回 422，提示无法把字符串解析为整数。

要让 Evaluator 达到这种水平，需要大量调试。

默认情况下，Claude 并不是一个好的 QA Agent。

在早期运行中，我经常看到它发现了真正的问题，然后又开始说服自己这些问题“其实没那么严重”，最终还是批准了结果。

它也倾向于进行非常表面的测试，而不是主动探索边缘情况，因此一些更隐蔽的 Bug 很容易漏掉。

我的调优循环基本是：

1. 阅读 Evaluator 的日志；

2. 找出它的判断与我的判断不一致的地方；

3. 修改 QA 提示词以解决这些问题；

4. 再次运行。

这个开发循环重复了几轮之后，Evaluator 的评分方式才逐渐达到我认为合理的水平。

即便如此，最终 Harness 输出依然暴露出模型 QA 能力的局限：

• 一些小型布局问题；

• 某些不够直觉的交互；

• 更深层嵌套功能中仍有未发现的 Bug。

显然，通过进一步调优，验证能力仍然还有很大的提升空间。

但和单 Agent 版本相比，完整 Harness 的提升已经非常明显，因为单 Agent 版本连整个应用的核心功能都无法正常运行。

继续迭代 Harness

第一版 Harness 的结果令人鼓舞，但它同时也非常笨重、缓慢而昂贵。

因此，下一步自然就是尝试简化 Harness，同时不降低性能。

这既来自常识，也来自一个更普遍的原则：

Harness 中每增加一个组件，本质上都编码了一个假设，即“模型无法自己做好这件事”。

这些假设值得不断重新验证。

原因有两个：

• 假设本身可能就是错的；

• 随着模型能力提升，原本正确的假设也可能迅速过时。

我们此前关于构建高效 Agent 的文章把这一思想概括为：

尽可能寻找最简单的解决方案，只有在确实必要时才增加复杂度。

对于任何需要长期维护 Agent Harness 的人来说，这个模式都会反复出现。

第一次尝试简化时，我大幅砍掉了 Harness 中的结构，还加入了一些新的创意设计。

但最终无法复现原版 Harness 的性能。

更麻烦的是，此时也很难判断 Harness 中究竟哪些组件是真正不可缺少的，以及它们分别通过什么机制发挥作用。

基于这次经历，我改用更加系统的方法：

每次只移除一个组件，然后观察它对最终结果产生什么影响。

在进行这些迭代时，我们也发布了 Opus 4.6，这进一步推动我减少 Harness 的复杂度。

有充分理由认为 4.6 已经不再需要像 4.5 那样多的脚手架。

在发布介绍中，我们提到：

Opus 4.6 会进行更仔细的规划，能够维持更长时间的 Agentic Task，在大型代码库中运行得更加可靠，并具备更好的 Code Review 和 Debug 能力，可以发现自己的错误。

它的长上下文检索能力也显著提升。

而这些能力，恰恰都是之前 Harness 试图为模型补足的东西。

移除 Sprint 结构

我首先完全移除了 Sprint 结构。

原本的 Sprint 能帮助模型把工作拆成多个小块，使它能够更加连贯地执行。

但考虑到 Opus 4.6 的能力提升，有理由相信模型已经可以原生处理这种任务，不再需要如此明确的分块机制。

我保留了 Planner 和 Evaluator，因为二者仍然能够带来非常明显的价值。

如果没有 Planner，Generator 很容易把产品范围做得太小。

面对原始提示词时，它会直接开始构建，而不会先为整个工作制定足够完整的规格，最终应用的功能丰富度明显低于有 Planner 时的结果。

移除 Sprint 之后，我把 Evaluator 改成只在完整构建结束时执行一次，而不是每个 Sprint 都评分。

因为模型能力已经显著增强，Evaluator 是否仍然关键开始取决于具体任务：这个任务离模型原生能够可靠完成的能力边界有多远。

在 Opus 4.5 上，这个边界很近。

我们的应用本身已经接近 Generator 单独能够做好任务的极限，因此 Evaluator 能够在整个构建中持续发现有意义的问题。

到了 Opus 4.6，模型的基础能力提高，边界被进一步推远。

过去需要 Evaluator 检查才能连贯实现的任务，现在 Generator 往往已经可以自己稳定完成。

对于处在这一能力范围以内的任务，Evaluator 就变成了不必要的额外开销。

但对于那些依然处在 Generator 能力边缘的部分，Evaluator 仍然可以带来真实提升。

因此，实践上的结论是：

是否需要 Evaluator，并不是一个固定的“要”或“不要”的决定。

当任务超出当前模型能够可靠独立完成的范围时，Evaluator 的额外成本才真正值得。

除了简化整体结构之外，我还增加了新的提示词，引导 Harness 更好地为每个应用构建 AI 功能。

更具体地说，我希望 Generator 不只是简单集成一个聊天框，而是真正构建一个 Agent，使其能够通过工具调用来操作应用自身的功能。

这需要相当多的迭代。

相关技术足够新，Claude 的训练数据覆盖相对有限。

但经过足够调优之后，Generator 最终能够正确构建这类 Agent。

更新版 Harness 的结果

为了测试更新后的 Harness，我使用下面这条提示词生成一个数字音频工作站，也就是用于作曲、录音和混音的 DAW：

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

这次运行依然非常漫长而且昂贵。

总时间约为 4 小时，Token 成本约为 124 美元。

绝大多数时间都花在 Builder 上。

在完全没有 Sprint 分解的情况下，它仍然能够连续、连贯地运行超过两个小时，而 Opus 4.5 在之前通常需要 Sprint 结构才能做到这一点。

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 会先把一句话提示词扩展成完整规格。

从日志中可以看到，Generator 对应用结构和 Agent 设计进行了不错的规划，成功完成了 Agent 的连接，并在交给 QA 之前自己进行了测试。

不过，QA Agent 仍然发现了一些真正的问题。

在第一轮反馈中，它指出：

这是一个非常强的应用，设计还原度很高，AI Agent 和后端也表现良好。

最主要的问题是“功能完整性”。虽然应用看起来非常令人印象深刻，而且 AI 集成工作良好，但一些 DAW 核心功能仍然只是展示层面的功能，没有真正的交互深度：

• Clip 无法在时间轴上拖动或移动；

• 没有乐器 UI 面板，例如合成器旋钮、鼓垫；

• 没有可视化效果器编辑器，例如 EQ 曲线和压缩器电平表。

这些并不是边缘情况，而是决定一个 DAW 是否真正可用的核心交互，而且产品规格中明确要求了这些能力。

在第二轮反馈中，它再次发现了一些功能缺口：

仍然存在的问题：

• 音频录制仍然只是 Stub，按钮可以切换状态，但并不会真正调用麦克风采集；

• 尚未实现通过拖动边缘调整 Clip 长度，也没有 Clip Split；

• 效果器可视化仍然只是数字 Slider，没有真正的图形化效果，例如 EQ 曲线。

这说明，当 Generator 完全独立工作时，它仍然容易遗漏细节，或者使用 Stub 代替真正实现。

而 QA 仍然能够在最后一公里中发现这些问题，让 Generator 继续修复，因此依然具备价值。

根据最初提示词，我期待得到的是一个可以：

• 创建旋律；

• 创建和声；

• 创建鼓点；

• 把它们编排成完整歌曲；

• 在过程中获得内置 Agent 帮助；

的音乐制作程序。

最终生成的应用远远谈不上专业音乐制作软件。

Agent 的作曲能力也显然还有很大提升空间。

此外，Claude 实际上听不到声音，这导致 QA 反馈循环在“音乐审美”方面的效果明显受限。

但最终应用已经包含了一个功能性音乐制作程序所需的核心组件：

• 可以运行的 Arrangement View；

• Mixer；

• Transport；

• 全部直接运行在浏览器中。

更进一步，我完全通过提示词制作出了一小段歌曲。

Agent 自动完成了：

• 设置速度；

• 设置调性；

• 写入旋律；

• 创建鼓轨；

• 调整 Mixer 电平；

• 添加混响。

也就是说，作曲所需要的核心 Primitive 已经存在，而且 Agent 能够通过工具自主操作这些能力，从头到尾完成一个简单制作。

可以说，它现在还没有做到真正的“音准完美”，但已经在逐渐接近。

下一步

随着模型持续进步，我们大体可以期待它们能够：

• 工作更长时间；

• 处理更加复杂的任务。

在某些场景中，这意味着模型外围的 Scaffold 随时间推移会越来越不重要。

开发者甚至可以简单等待下一代模型，然后发现某些原有问题自然消失了。

但另一方面，模型越强，我们也拥有越大的空间去设计新的 Harness，让系统完成远远超出模型基线能力的复杂任务。

从这项工作中，有几个值得持续保留的经验。

首先，始终应该对你正在使用的具体模型做实验。

在真实问题上阅读它的 Trace，并不断调优，直到达到你想要的结果。

其次，在面对更加复杂的任务时，通过拆解任务并为不同部分使用专业 Agent，有时仍然存在明显的性能提升空间。

第三，每当一个新模型发布之后，通常都应该重新审视 Harness：

• 删除那些已经不再真正支撑性能的结构；

• 加入新的结构，以利用过去模型能力不足时无法实现的新能力。

这项工作让我更加确信：

随着模型不断增强，有趣的 Harness 组合空间并不会缩小。

它只是在不断移动。

而 AI 工程师真正有趣的工作，就是持续寻找下一种新的组合。