【译】长时运行应用的 Harness 设计

原文：Harness design for long-running application development 作者：Prithvi Rajasekaran 发布日期：2026 年 3 月 24 日

Harness 设计是 Agentic Coding 前沿性能的关键。本文将介绍我们如何在前端设计和长时间自主软件工程中，进一步提升 Claude 的能力。

作者：Prithvi Rajasekaran，Anthropic Labs 团队成员。

在过去几个月里，我一直在处理两个相互关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在没有人工干预的情况下构建完整应用。这项工作起源于我们此前在前端设计 skill 和长时运行 coding agent harness 上的探索；当时我和同事们通过 prompt engineering 与 harness design，让 Claude 的表现显著高于基线，但这两条路线最终都遇到了上限。

为了突破这一点，我开始寻找能够同时适用于两个截然不同领域的新型 AI 工程方法：一个领域由主观品味定义，另一个领域则由可验证的正确性与可用性定义。受生成对抗网络（GAN）启发，我设计了一种由 generator agent 和 evaluator agent 组成的多 Agent 结构。要构建一个既能稳定打分、又“有品味”的 evaluator，第一步是先建立一套标准，把“这个设计好吗？”这类主观判断，转化成具体、可评分的维度。

随后，我又把这些技术应用到了长时间自主编码中，并沿用了我们此前 harness 工作中的两个经验：把构建过程拆解成可处理的块，以及通过结构化 artifact 在会话之间交接上下文。最终结果是一套由 planner、generator 和 evaluator 组成的三 Agent 架构，能够在持续数小时的自主编码会话中产出丰富的全栈应用。

为什么朴素实现会失效

我们此前已经展示过，harness design 会对长时运行的 agentic coding 效果产生显著影响。在一次更早的实验中，我们使用 initializer agent 将产品规格拆成任务列表，再由 coding agent 一次实现一个 feature，并在会话之间通过 artifact 传递上下文。更广泛的开发者社区也得出了类似结论，例如 “Ralph Wiggum” 方法，就是通过 hook 或脚本让 agent 持续处于迭代循环中。

但有些问题仍然一直存在。对于更复杂的任务，agent 仍然会随着时间推移逐渐偏离轨道。在分解这个问题时，我们观察到 agent 在执行这类任务时常见的两种失效模式。

首先，随着上下文窗口逐渐填满，模型在长任务中往往会失去一致性（参见我们关于 context engineering 的文章）。有些模型还会表现出“context anxiety（上下文焦虑）”：当它们接近自己所认为的上下文上限时，就会开始过早收尾。Context reset——彻底清空上下文窗口、启动一个全新的 agent，并通过结构化 handoff 将上一个 agent 的状态与下一步计划传给下一个 agent——可以同时解决这两个问题。

这与 compaction 不同。Compaction 是把对话早期内容原地总结压缩，让同一个 agent 在更短的历史上继续工作。虽然 compaction 保留了连续性，但它不会给 agent 一个真正的“干净起点”，因此 context anxiety 仍可能持续存在。Reset 则提供了一个全新的起点，代价是 handoff artifact 必须携带足够状态，才能让下一个 agent 顺利接手工作。在我们更早的测试中，我们发现 Claude Sonnet 4.5 的 context anxiety 严重到仅靠 compaction 无法支撑强健的长任务表现，因此 context reset 成为了 harness design 中的关键组成部分。它解决了核心问题，但也为每次 harness 运行带来了更高的编排复杂度、token 开销和延迟。

第二个问题是我们此前尚未处理过的：自我评估。当 agent 被要求评价自己做出的工作时，它们往往会自信地称赞自己的结果——即便在人类观察者看来，质量明显只是平庸水平。这个问题在设计这类主观任务中尤其突出，因为它没有类似可验证软件测试那样的二元检查。一个布局究竟是精致还是平庸，本质上是判断问题；而 agent 在评价自己的作品时，几乎总是倾向于给出偏正面的判断。

不过，即使在那些结果可以验证的任务里，agent 在完成任务的过程中有时也会表现出不佳的判断力，从而影响整体表现。把“执行工作的 agent”和“评判工作的 agent”拆开，是应对这个问题的一个强有力手段。这种拆分本身并不会立刻消除宽松倾向；evaluator 仍然是一个 LLM，仍然倾向于对 LLM 生成的输出更宽容。但相比之下，把一个独立 evaluator 调教得更怀疑、更苛刻，显然要比让 generator 严厉地审视自己的工作容易得多。而一旦这种外部反馈存在，generator 就有了明确的迭代依据。

前端设计：让主观质量可评分

我首先在前端设计上做实验，因为自评问题在这里最为明显。如果不做任何干预，Claude 往往会自然倾向于安全、可预测的布局：技术上能用，但视觉上平平无奇。

我为前端设计构建的 harness，受两个洞见驱动。第一，虽然审美无法被完全压缩成一个分数，而且个体品味始终会不同，但我们仍然可以通过编码设计原则与偏好的评分标准来改进它。“这个设计美吗？”很难稳定回答，但“它是否遵循了我们的优秀设计原则？”则给了 Claude 一个可以实际评估的依据。第二，通过把前端生成与前端评分拆开，我们可以构建一个反馈回路，驱动 generator 向更强的输出靠拢。

基于这个想法，我写了四条评分标准，并把它们同时给到了 generator 和 evaluator：

• 设计质量（Design quality）：这个设计是否给人一种统一整体的感觉，而不是零散部分的拼接？在这一维度上表现优秀，意味着颜色、排版、布局、图像等细节共同构成了清晰的氛围与身份感。
• 原创性（Originality）：是否存在定制化决策的证据，还是说只是模板布局、库默认值和典型 AI 生成模式？一个人类设计师应该能看出其中有刻意的创作选择。未经修改的现成组件，或是“白卡片 + 紫色渐变”这类明显的 AI 生成痕迹，在这一项中都会失败。
• 工艺（Craft）：技术执行质量，包括排版层级、间距一致性、色彩和谐度、对比度比例等。这更像是能力检查，而不是创造力检查。大多数还算合理的实现默认在这一项都不差；如果失败，就意味着基本功出了问题。
• 功能性（Functionality）：不考虑审美时，它是否足够好用？用户能否理解这个界面是做什么的，找到主要操作，并在不靠猜的情况下完成任务？

我刻意把“设计质量”和“原创性”的权重放得高于“工艺”和“功能性”。Claude 在工艺和功能性上默认就已经表现不错，因为所需的技术能力对模型来说通常是自然具备的。但在设计质量和原创性上，Claude 给出的结果往往最多只能算平淡。评分标准会明确惩罚高度通用的“AI slop”模式，而通过提高设计质量与原创性的权重，可以把模型推向更愿意承担审美风险的方向。

我还用少样本示例对 evaluator 进行了校准，这些示例中包含详细的评分拆解。这样做既让 evaluator 的判断更贴近我的偏好，也减少了多轮迭代中的分数漂移。

我基于 Claude Agent SDK 构建了这个循环，因此整体编排比较直接。generator agent 会先根据用户 prompt 生成一个 HTML/CSS/JS 前端。我为 evaluator 配置了 Playwright MCP，让它可以直接与在线页面交互，再对每个评分维度打分并写出详细评论。实际运行中，evaluator 会自行浏览页面、截图并仔细查看实现细节，然后给出评估结果。这个反馈再作为下一轮迭代的输入回流给 generator。每次生成我通常会跑 5 到 15 轮迭代，而每一轮，generator 往往都会在 evaluator 的批评下向更鲜明的方向推进。因为 evaluator 不是只对静态截图评分，而是真的在页面上导航和操作，所以每一轮都需要真实的墙钟时间。完整运行最长会拉到四小时。我还要求 generator 在每一轮评估后做一个策略判断：如果分数走势良好，就继续打磨当前方向；如果这条路线效果不佳，就彻底转向另一种美学。

在多次运行中，evaluator 的评分通常会随着迭代提升，然后在某个位置趋于平台期，但仍然留有上升空间。有些生成是渐进式打磨出来的；也有些会在迭代之间突然发生剧烈的审美转向。

这些评分标准的措辞，也会以我事先没有完全预料到的方式影响 generator。比如加入“最好的设计具有 museum quality”这类表述，会把结果推向某种特定的视觉收敛，说明与标准相关的 prompt 本身也在直接塑造输出的性格。

虽然分数总体上会随着迭代提升，但这个过程并不总是线性。后期实现通常整体更好，但我也经常会偏爱中间某一轮胜过最后一轮。随着轮次推进，实现复杂度往往也会上升，因为 generator 会根据 evaluator 的反馈尝试更有野心的方案。甚至在第一轮里，结果也明显优于完全没有提示时的基线，这说明评分标准及其语言本身，就已经在 evaluator 反馈产生之前，把模型从通用默认套路中拉开了。

在一个尤其典型的例子里，我让模型设计一个荷兰艺术博物馆的网站。到第九轮时，它已经做出了一个虚构博物馆的深色主题首页，页面干净、成熟，也基本符合我的预期。但到了第十轮，它完全推翻了这个方案，把网站重构成一种空间化体验：一个采用 CSS 透视渲染的 3D 房间、带棋盘地面的展厅、墙面上自由悬挂的画作，以及通过门洞在展厅之间切换，而不是依靠滚动或点击导航。这种创意上的跳跃，是我以前从单轮生成中从未见过的。

扩展到全栈编码

在得到这些发现之后，我把这套受 GAN 启发的模式扩展到了全栈开发中。Generator-evaluator 循环与软件开发生命周期天然契合：代码评审和 QA，在结构上正好扮演了设计 evaluator 的同类角色。

架构

在我们之前的长时运行 harness 中，我们已经解决了多会话编码的一致性问题：通过一个 initializer agent、一个一次处理一个 feature 的 coding agent，以及会话间的 context reset。Context reset 是当时的重要突破：那套 harness 使用的是 Sonnet 4.5，它表现出了前面提到的 “context anxiety” 倾向。要让模型始终围绕任务工作，就必须构建一套能跨 context reset 正常工作的 harness。而到了 Opus 4.5，这种倾向基本被模型自身显著减轻了，因此我能够在这套新 harness 中完全去掉 context reset。所有 agent 在整个构建过程中都运行于一个连续会话中，由 Claude Agent SDK 的自动 compaction 来处理上下文增长。

在此前 harness 的基础上，我构建了一套三 Agent 系统，其中每个 agent 都在填补我在先前运行中观察到的一个特定缺口。这套系统包含如下角色：

Planner：我们此前的长时运行 harness 需要用户一开始就给出非常详细的规格。我希望把这一步自动化，所以我创建了一个 planner agent：它接收 1 到 4 句的简短 prompt，然后把它扩展成完整产品规格。我要求它在范围上保持雄心，同时聚焦于产品上下文和高层技术设计，而不是过早下探到具体技术实现。这样做是因为，如果 planner 一开始就在细粒度技术细节上写错了东西，这些错误就会沿着规格一路级联到后续实现中。相比之下，更明智的做法似乎是：约束 agent 最终要产出的 deliverable，而把具体路径留给它们在执行过程中自己解决。我还要求 planner 主动寻找机会，把 AI 功能编织进产品规格中。（示例见文末附录。）

Generator：此前 harness 中“一次一个 feature”的方法在范围管理上效果很好，因此这里我沿用了类似模型，要求 generator 以 sprint 方式工作，每次从规格中取一个 feature 来实现。每个 sprint 都基于 React、Vite、FastAPI 和 SQLite（后续换成 PostgreSQL）技术栈来实现应用，并要求 generator 在每个 sprint 末尾先对自己的工作做自评，再交给 QA。它同时也使用 git 做版本管理。

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 再读取。随后 generator 按照双方已经达成一致的 contract 去实现，再把结果交给 QA。这样既能让工作忠实于原始规格，又不会过早把实现细节写死。

运行这套 harness

在这套 harness 的第一版中，我使用了 Claude Opus 4.5，并让同一批用户 prompt 分别跑完整 harness 与单 Agent 系统做对比。之所以选用 Opus 4.5，是因为在我开始做这组实验时，它是我们最强的 coding model。

我写下了这样一个 prompt，来生成一个复古风格的视频游戏制作器：

Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.

下表展示了 harness 类型、运行时长和总成本：

这套 harness 的成本高了 20 多倍，但输出质量的差异也立刻变得非常明显。

我原本期待的是这样一个界面：我可以构建关卡及其组成部分（sprite、entity、tile 布局），然后点击 play，真的把关卡跑起来。我先打开了单 Agent 运行的结果，最初看起来，它似乎符合这些期待。

但随着我开始点击操作，问题逐渐显现。布局浪费了大量空间，固定高度的面板让绝大多数视口处于空置状态。工作流也非常僵硬。我要往关卡里放东西时，系统会先要求我创建 sprite 和 entity，但 UI 并没有引导我走这个顺序。更关键的是，真正的游戏坏掉了。屏幕上的 entity 确实出现了，但输入完全没有响应。继续阅读代码后，我发现实体定义与游戏运行时之间的连接是断的，而且界面上没有任何线索告诉你问题出在哪。




看完单 Agent 结果后，我转向了 harness 版本。它从同样的一句 prompt 开始，但 planner 会先把这句 prompt 扩展成一个包含 16 个 feature、分布在 10 个 sprint 中的完整规格。它远远超出了单 Agent 尝试的范围。除了核心编辑器与 play mode 之外，这份规格还要求实现 sprite 动画系统、行为模板、音效与音乐、AI 辅助 sprite 生成器与关卡设计器，以及可分享链接的游戏导出功能。我还给 planner 提供了我们的 frontend design skill，它会读取它，并把应用的视觉设计语言一起写进规格里。对每个 sprint，generator 和 evaluator 都会先协商出一个 contract，定义这轮的具体实现细节，以及之后用于验证完成度的可测试行为。

这版应用一上来就比单 Agent 版本更精致、更流畅。画布会充分利用整个视口，面板尺寸合理，界面也具有与规格中设计方向一致的统一视觉身份。单 Agent 版本里的一些笨拙感仍然存在——比如工作流依然没有明确提示你应该先创建 sprite 和 entity 再去填充关卡，我还是得自己摸索。这更像是基础模型产品直觉上的缺口，而不是 harness 专门设计来解决的问题；不过这也提示了一个后续可以继续迭代、进一步提升输出质量的点。

继续深入各个编辑器后，harness 版本相较单 Agent 的优势就更加明显了。Sprite editor 更丰富也更完整，工具栏更清爽，取色器更好用，缩放控制也更可用。

由于我要求 planner 在规格中织入 AI 功能，应用里还内建了 Claude 集成，让我能够通过 prompt 来生成游戏的不同部分。这显著加快了工作流。






最大的差异出现在 play mode 中。我真的可以移动我的实体并玩这个游戏。物理效果还有一些粗糙之处——例如角色跳上平台后会和平台发生重叠，直觉上显得不太对——但核心功能确实工作了，而单 Agent 版本并没有做到这一点。不过在我继续移动和尝试后，也发现 AI 构建游戏关卡的能力仍有限制。有一堵大墙我根本跳不过去，所以卡住了。这说明还有一些常识性改进和边缘情况，是 harness 后续可以处理、从而继续提升应用质量的。

查看日志后可以清楚看出，evaluator 在让实现保持与规格一致方面起到了关键作用。每个 sprint 中，它都会对照 sprint contract 里的测试标准，用 Playwright 去操作运行中的应用，并把任何偏离预期行为的问题都报成 bug。这些 contract 非常细——仅 Sprint 3 的 level editor 就有 27 条标准——而 evaluator 给出的发现也足够具体，不需要额外调查就可以直接采取行动。下表展示了 evaluator 识别出的几个问题示例：

要让 evaluator 达到这种表现并不容易。默认情况下，Claude 并不是一个优秀的 QA agent。在早期实验里，我经常看到它先识别出真实问题，然后又说服自己“这也不算大事”，最后依然通过了实现。它也往往只做浅层测试，而不是去探查边缘情况，因此更隐蔽的 bug 很容易漏掉。我的调优循环是：阅读 evaluator 日志，找出它的判断与我不一致的地方，再修改 QA prompt 去解决这些问题。这个开发循环往返了好几轮，evaluator 才终于开始以一种我认为合理的方式打分。即便如此，harness 输出中仍然清楚暴露出模型在 QA 上的上限：一些小布局问题、局部不够直觉的交互，以及 evaluator 没有深入覆盖到的深层功能中的遗漏 bug。显然，这里仍然存在大量可通过继续调优而提升的验证空间。但和单 Agent 版本相比——后者甚至连应用的核心功能都没能工作——这种提升已经非常明显。

对 harness 继续迭代

第一批 harness 结果很令人鼓舞，但它也确实庞大、缓慢且昂贵。接下来的合理步骤，就是寻找简化 harness 的方法，同时不损害它的表现。这一方面是常识，另一方面也源自一个更普遍的原则：harness 中的每一个组件，本质上都编码了一个关于“模型单靠自己做不到什么”的假设；而这些假设都值得被持续做压力测试，因为它们可能一开始就是错的，也可能随着模型进步而很快过时。我们在《Building Effective Agents》一文中把这一底层思路概括为：“找到尽可能简单的方案，并且只有在必要时才增加复杂度。” 这也是所有维护 agent harness 的人都会不断遇到的模式。

在我第一次尝试简化时，我非常激进地砍掉了大量结构，并尝试了一些新的创意想法，但结果无法复现原始 harness 的表现。与此同时，也变得越来越难判断 harness 设计里哪些部分才是真正承重的，以及它们究竟是以什么方式发挥作用的。基于这次经验，我改用一种更系统的方法：一次只移除一个组件，然后观察它对最终结果造成了什么影响。

而就在这一轮迭代过程中，我们发布了 Opus 4.6，这进一步推动我去降低 harness 的复杂度。我们有充分理由认为，相比 4.5，4.6 所需的 scaffolding 会更少。正如发布博文所说：“[Opus 4.6] 会更仔细地规划，能更长时间维持 agentic task，在更大的代码库中工作得更可靠，并且拥有更好的 code review 与 debugging 能力，能更好地发现自己的错误。” 它在长上下文检索方面也有显著提升。所有这些，原本都是 harness 被设计出来用于补足的能力。

移除 sprint 结构

我首先移除了 sprint 结构本身。Sprint 结构原本帮助模型把工作拆成多个块，以便保持一致性地推进。鉴于 Opus 4.6 的改进，我们有充分理由相信，模型已经可以原生处理这项工作，而不再需要这种额外分解。

我保留了 planner 和 evaluator，因为这两者都仍然持续提供明显价值。如果没有 planner，generator 就会低估任务范围：面对原始 prompt，它会直接开始构建，而不会先把工作 spec 化，最终产出的应用功能也会比 planner 生成的版本更少。

在去掉 sprint 结构后，我把 evaluator 从“每个 sprint 评估一次”改成了“在整次运行结束后做一次单次评估”。由于模型能力已经更强，这也改变了 evaluator 在不同任务中的承重程度：它是否有用，取决于任务落在模型单独完成能力边界的哪一侧。在 4.5 时代，这条边界很近：我们的构建基本处在 generator 单独完成能力的边缘，因此 evaluator 在整个构建过程中都能抓到有意义的问题。而到了 4.6，模型原始能力提高，这条边界被向外推远了。过去那些必须依赖 evaluator 检查才能连贯实现的任务，现在往往已经落入 generator 能自行较好完成的范围；对这类任务来说，evaluator 就变成了不必要的额外负担。但对于那些仍然卡在 generator 能力边缘的部分，evaluator 依旧能带来真实的提升。

这带来的实际含义是：evaluator 不是一个固定不变的二元选择。当任务超出了当前模型单独可靠完成的范围时，它的成本就是值得的。

在简化结构的同时，我也加入了新的 prompt 设计，以改进 harness 在每个应用中植入 AI 功能的方式，具体来说，就是让 generator 构建一个真正能通过 tools 驱动应用自身功能的 agent。为此我做了很多迭代，因为相关知识还很新，Claude 的训练数据对此覆盖得比较薄。但经过足够多的调优后，generator 已经能够正确构建这类 agent。

更新后 harness 的结果

为了测试更新后的 harness，我给它下达了这样一个任务：生成一个数字音频工作站（DAW，Digital Audio Workstation），也就是一个用于作曲、录音和混音的音乐制作程序：

Build a fully featured DAW in the browser using the Web Audio API.

这次运行仍然漫长且昂贵，总共大约花了 4 小时，token 成本约为 124 美元。

大部分时间都花在 builder 上：在没有 Opus 4.5 所必需的 sprint 分解结构的情况下，它仍然可以连贯地运行两个多小时。

和之前的 harness 一样，planner 会先把一句话 prompt 扩展成完整规格。从日志里可以看到，generator model 在应用规划、agent 设计、agent 接线以及在交给 QA 之前自行测试这些方面，表现都不错。

即便如此，QA agent 依旧抓到了真实缺口。在第一轮反馈中，它指出：

这是一个很强的应用，设计还原度很高，AI agent 很扎实，后端也不错。主要失分点在于功能完整性——虽然应用看起来很惊艳，AI 集成也工作得很好，但若干核心 DAW 功能仍然只是展示层，没有真正的交互深度：clip 不能在时间线上拖拽/移动，没有乐器 UI 面板（如合成器旋钮、鼓机打击垫），也没有可视化效果编辑器（如 EQ 曲线、压缩器电平表）。这些不是边缘问题——它们正是让 DAW 真正可用的核心交互，而且规格里明确要求了它们。

在第二轮反馈中，它又再次指出了几个功能缺口：

剩余缺口：

• 录音仍然只是 stub（按钮能切换，但没有真正的麦克风采集）
• 尚未实现通过拖拽边缘调整 clip 大小，以及 clip split
• 效果器可视化仍然只是数值 slider，而不是图形化编辑（没有 EQ 曲线）

也就是说，如果完全放任 generator 自己发挥，它依然会漏掉细节或把某些功能做成半成品；而 QA 在捕捉这些最后一公里的问题、再交还给 generator 修正方面，仍然具有明确价值。

基于这个 prompt，我原本期待的是这样一个程序：我可以创建旋律、和声和鼓点，把它们编排成歌曲，并在过程中得到一个集成 agent 的帮助。最终结果如下图所示。

这个应用距离专业级音乐制作软件还差得很远，agent 的作曲能力显然也还有大量提升空间。另外，Claude 实际上“听不见”，这也让 QA 反馈循环在涉及音乐审美时变得不那么有效。

但最终产物已经具备了一个功能性音乐制作程序应有的核心组成部分：浏览器中可运行的编排视图、mixer 和 transport。除此之外，我还能够完全通过 prompting 拼出一小段歌曲：agent 会设置 tempo 和 key，铺一条旋律，生成鼓轨，调整 mixer 电平，并加入 reverb。作曲所需的核心原语已经存在，而这个 agent 也能够通过 tools 自主驱动它们，从头到尾完成一个简单制作。你可以说它还远远称不上“音准完美”——但它确实已经在接近那个方向了。

下表是这套 V2 harness 的时间和成本拆解：

接下来会怎样

随着模型持续改进，我们大致可以预期：它们会能够工作得更久，也能处理更复杂的任务。在某些情况下，这意味着围绕模型搭建的 scaffold 会随着时间推移而变得没那么重要，开发者只要等待下一代模型发布，就会发现某些问题“自己消失了”。但另一方面，模型越强，也就越有空间去开发新的 harness，让它们完成那些基线模型本身仍然做不到的复杂任务。

基于这一点，这项工作里有几条经验值得继续带走。针对你正在使用的模型进行实验、在真实问题上阅读它的 trace、并通过调优让它达到你期望的结果，这始终是良好实践。面对更复杂的任务时，把任务拆解并让专门化 agent 各自负责问题的一部分，往往仍然存在可挖掘的提升空间。而当新模型到来时，一个普遍的好习惯，就是重新审视现有 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 生成的示例计划。

欢迎关注我的其它发布渠道

WeChat