Orchestration Framework Design for Long-Running Agentic Coding

长时运行应用开发的编排框架设计｜译文

发表于 2026 年 3 月 24 日
作者：Prithvi Rajasekaran

原始网址：https://www.anthropic.com/engineering/harness-design-long-running-apps

摘要与动机：跨前端设计与自主构建的编排思路

阐明两大目标与受 GAN 启发的多代理方案。

编排框架（harness）的设计是提升代理式编码（agentic coding）性能的关键。本文将介绍我们如何在前端设计和长周期自主软件工程中进一步拓展 Claude 的能力。

过去几个月里，我一直在攻克两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在无人干预的情况下构建完整应用。这项工作源于我们早期在前端设计能力和长时运行编码代理编排框架（harness）上的探索，通过提示工程和编排框架设计，我与同事们曾大幅提升 Claude 的表现，远超基线水平——但最终这两条路径都触及了上限。

为了突破瓶颈，我寻找能够跨越两个截然不同领域的新颖 AI 工程方法：一个领域依赖主观品味，另一个则以可验证的正确性和可用性为标准。受生成对抗网络（Generative Adversarial Networks，GANs）启发，我设计了一个多代理结构，包括生成器（Generator）和评估器（Evaluator）代理。要构建一个既能可靠评分又具备审美品味的评估器，首先必须制定一套评分标准，将“这个设计好吗？”这样的主观判断转化为具体、可评分的指标。

随后，我将这些技术应用于长时间运行的自主编码任务，并延续了我们此前在编排框架（harness）工作中总结的两条经验：将构建过程拆解为可管理的模块，以及使用结构化工件在不同会话间传递上下文。最终，我们形成了一个由三类代理组成的架构——规划器（Planner）、生成器（Generator）和评估器（Evaluator）——能够在多小时的自主编码过程中产出丰富的全栈应用。

问题诊断：为什么朴素实现难以胜任

定位长任务中的上下文与自评两类失败模式。

背景说明

我们此前已经展示过，编排框架（harness）的设计对长时间运行的代理式编码（agentic coding）效果有着显著影响。在早期实验中，我们使用初始化代理将产品规格拆解为任务列表，再由编码代理逐一实现这些功能点，并通过交接工件在会话之间传递上下文。更广泛的开发者社区也得出了类似的见解，例如“Ralph Wiggum method（社区对通过钩子/脚本持续迭代的一种称呼）”等方法，通过 hook 或脚本让代理持续处于迭代循环中。

但一些问题依然存在。对于更复杂的任务，代理仍然容易随着时间推移而“跑偏”。在剖析这一问题时，我们观察到代理在执行此类任务时有两种常见的失败模式。

失败模式 1：长上下文与“上下文焦虑”

首先，模型在处理长时任务时，随着上下文窗口逐渐填满，往往会出现连贯性下降的问题（详见我们关于上下文工程的文章）。部分模型还会表现出“上下文焦虑”，即在接近它们认为的上下文上限时，会提前结束工作。上下文重置（reset）——完全清空上下文窗口，启动一个新的代理，并通过结构化交接工件传递前一个代理的状态和后续步骤——能够同时解决这两类问题。

这与就地概括（compaction）不同，后者是在对话的早期部分进行就地总结，使同一代理能够在缩短的历史基础上继续工作。虽然就地概括能够保持上下文的连贯性，但它并不会为代理提供一个从零/清空重来（clean slate）的起点，这意味着上下文焦虑（context anxiety）仍可能存在。重置（reset）则能带来一个清空重来的起点，但代价是交接工件（handoff artifact）必须包含足够的状态信息，才能让下一个代理顺利接手。在我们此前的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑表现非常明显，仅靠就地概括不足以支撑长任务的高性能表现，因此上下文重置成为编排框架设计中的关键环节。这解决了核心问题，但也为每次编排框架运行增加了编排复杂度、Token 开销和时延。

上下文重置成为编排框架设计中的关键环节。

失败模式 2：自评偏差与评估器分离

第二个问题，我们此前尚未探讨，是自评（self-evaluation）。当被要求评估自己产出的作品时，代理往往会自信地给予高度赞扬——即使在人类观察者看来，作品质量显然平庸。这一问题在设计等主观任务中尤为突出，因为没有类似可验证软件测试的二元检查。一个布局是否显得精致或普通，完全取决于主观判断，而代理在为自己的作品打分时，总是倾向于给出正面评价。

然而，即便是在有可验证结果的任务中，代理仍可能因判断失误而影响任务表现。将负责执行的代理与负责评判的代理分离，是解决这一问题的有力手段。单纯分离角色并不能立即消除评估时的宽容倾向——评估器本身依然是 LLM，往往会对 LLM 生成的输出偏于宽容。但将一个独立评估器调校得更为审慎、挑剔，比让生成器批判自己的作品要容易得多。一旦有了外部反馈，生成器便有了明确的改进目标，可以据此迭代。

将负责执行的代理与负责评判的代理分离，是解决这一问题的有力手段。

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

用评分标准与生成–评估循环驱动美学提升。

问题定义

我首先在前端设计上进行实验，因为自评问题在这里最为突出。如果不加干预，Claude 往往会倾向于选择安全、可预测的布局，这些布局在技术上虽可用，但在视觉上毫无亮点。

核心判断

我为前端设计构建的编排框架（harness）源于两个关键洞见。首先，审美无法完全量化为分数——个人品味始终会有所差异——但通过评分标准将设计原则与偏好编码进去，可以有效提升整体设计质量。“这个设计美观吗？”难以保持一致的回答，而“这个设计是否遵循我们的优秀设计原则？”则能为 Claude 提供明确的评分依据。其次，将前端生成与前端评分分离，可以形成一个反馈循环，推动生成器（Generator）不断产出更优质的结果.

评分标准（四项）

基于这一思路，我在提示中为生成器和评估器代理制定了四项评分标准：

• 设计质量：设计是否呈现为一个有机整体，而非零散拼凑？高质量作品意味着色彩、字体排版、布局、图像及其他细节相互融合，营造出独特的氛围与身份感。
• 原创性：是否体现出定制化的设计决策，还是仅仅使用模板布局、库默认样式或 AI 生成的模式？人类设计师应能识别出有意识的创意选择。未经修改的素材组件，或明显的 AI 生成痕迹（如白色卡片上的紫色渐变）会在此项被扣分。
• 工艺：技术实现层面的表现，包括字体层级、间距一致性、色彩和谐、对比度等。这是对基本功的检验，而非创意能力。大多数合理的实现默认都能通过；不及格则意味着基础环节存在问题。
• 功能性：与美观无关的可用性。用户能否理解界面的功能、找到主要操作，并顺利完成任务而无需猜测？

我在评分时更强调设计质量和原创性，而非工艺和功能性。Claude 在工艺和功能性上默认表现优异，因为所需的技术能力对模型来说往往是自然具备的。但在设计和原创性方面，Claude 常常只能产出平淡无奇的结果。评分标准明确惩罚高度通用的“AI 糊（AI slop）”模式，并通过提高设计和原创性的权重，促使模型在美学上进行更多探索与冒险。

我使用少样本示例（few-shot）和详细的分数拆解对评估器进行了校准，确保其判断与我的偏好保持一致，并减少了各轮迭代中的评分漂移。

流程机制（生成–评估循环）

我在 Claude Agent SDK 上构建了这个循环，使整个编排框架（harness）保持简洁明了。生成器代理（Generator）首先根据用户提示生成 HTML/CSS/JS 前端页面。我为评估器（Evaluator）集成了 Playwright MCP，使其能够直接与实时页面交互，在评分每一项标准并撰写详细评注前，先实际操作页面。实际运行中，评估器会自主浏览页面、截图并仔细研究实现细节，然后给出评估。评估反馈会作为输入回流到生成器，驱动下一轮迭代。每次生成我通常运行 5 到 15 轮迭代，每轮都会根据评估器的评注，让生成器的设计方向更加鲜明。由于评估器是主动浏览页面而非对静态截图评分，每个循环都需要实际耗时（wall-clock time），完整的一次运行最长可达四小时。我还要求生成器在每次评估后做出策略决策：如果评分趋势良好则继续优化当前方向，若方法效果不佳则彻底转向另一种美学风格。

迭代观察

在多次运行中，评估器的评分在迭代过程中逐步提升，最终趋于平稳，但仍有提升空间。部分生成结果实现了渐进式优化，另一些则在不同迭代间出现了显著的审美风格变化。

评分标准的措辞以我未曾完全预料的方式影响了生成器（Generator）的走向。比如加入“最佳设计应达到‘博物馆级（museum quality）’”这样的表述，会让设计在视觉上趋向某种特定风格，这表明评分标准中的提示语本身就直接塑造了输出的特征。

虽然分数在多轮迭代中总体有所提升，但这种提升并不总是严格线性的。后期实现通常整体更优，但我常常会遇到中间某一轮的方案反而比最后一轮更令我满意。随着轮次推进，实现的复杂度也往往增加，生成器会根据评估器的反馈尝试更具野心的解决方案。即便在第一轮，输出结果也已明显优于完全没有提示的基线，这表明评分标准及其相关表述在评估器反馈带来进一步优化之前，就已引导模型避开通用的默认方案。

在一个颇具代表性的例子中，我让模型为一家荷兰艺术博物馆创建网站。到第九次迭代时，它已生成了一个干净、深色主题的虚构博物馆首页。页面视觉上十分精致，但整体仍在我的预期之内。随后，在第十轮中，它彻底放弃了原有方案，重新构想整个网站，将其变为一种空间化体验：一个用 CSS perspective 渲染的 3D 房间，棋盘格地板，艺术品以自由形式悬挂在墙上，画廊间通过门洞导航，而非滚动或点击。这种创意上的飞跃，是我在单次生成中从未见过的。

扩展到全栈编码

将生成–评估模式嵌入软件生命周期，建立三代理架构。

架构设计

在我们早期的长时运行编排框架（harness）中，我们通过一个初始化代理（initializer agent）、一个每次只处理单个功能的编码代理（coding agent），以及会话间的上下文重置，解决了多会话编码的一致性问题。上下文重置是关键突破点：该编排框架使用的是 Sonnet 4.5，而它表现出前文提到的“上下文焦虑”倾向。设计一个能够在上下文重置下依然高效运行的编排框架，对保持模型专注任务至关重要。Opus 4.5 在这方面几乎完全消除了这种行为，因此我得以在本编排框架中彻底移除上下文重置。所有代理在整个构建过程中以一个连续会话运行，由 Claude Agent SDK 的自动就地概括（compaction）机制动态处理上下文增长。

在这项工作中，我在原有的三代理编排框架（harness）基础上进行了拓展，每个代理都针对我在以往运行中观察到的特定短板进行补足。系统包含以下代理角色：

• 规划器（Planner）：我们之前的长时运行编排框架（harness）要求用户在一开始就提供详细的规格说明。我希望将这一环节自动化，于是创建了一个规划器代理（Planner agent），能够将简短的 1-4 句提示扩展成完整的产品规格说明。我引导它在制定范围时保持雄心，并专注于产品上下文和高层技术设计，而非具体的技术实现细节。强调这一点的原因是担心，如果规划器在前期就尝试指定细致的技术细节且出现错误，这些错误会在后续实现阶段层层传递，影响整体流程。更明智的做法似乎是限定代理需产出的交付物，让它们在实际工作中自行探索实现路径。我还要求规划器在产品规格中主动寻找融入 AI 功能的机会。（具体示例见文末附录。）
• 生成器（Generator）：此前的编排框架采用一次只实现一个功能的方式，有效地控制了范围。我在这里也沿用了类似模式，指示生成器按冲刺（sprint）工作，每次从规格说明中选取一个功能进行实现。每个冲刺都使用 React、Vite、FastAPI 和 SQLite（后期改为 PostgreSQL）技术栈开发应用，并要求生成器在冲刺结束时先进行自评，再交接给 QA 评估器。版本控制使用 git。
• 评估器（Evaluator）：早期编排框架生成的应用虽然看起来颇为吸引人，但在实际使用时仍存在真实的 bug。为捕捉这些问题，评估器使用 Playwright MCP 模拟用户操作，逐步点击运行中的应用，测试 UI 功能、API 端点以及数据库状态。随后，评估器会根据发现的 bug，以及一套基于前端实验并针对产品深度、功能性、视觉设计和代码质量调整后的评分标准，对每次冲刺进行评分。每项评分标准都设有硬性阈值，只要有一项未达标，该冲刺就会被判定为失败，生成器将收到详细反馈，明确具体问题所在。

在每次冲刺开始前，生成器（Generator）和评估器（Evaluator）会协商达成冲刺约定：在任何代码编写之前，先明确本阶段工作的完成标准（即“done”的样子）。之所以设置这一步，是因为产品规格说明刻意保持高层次，我希望通过这一环节弥合用户故事与可测试实现之间的差距。生成器会提出它计划构建的内容以及验证成功的方法，评估器则审核该提案，确保生成器构建的方向正确。双方不断迭代，直到达成一致。

通信通过文件进行：一个代理会写入文件，另一个代理读取后，在该文件内或新建文件中作出回应，前一个代理再依次读取。生成器（Generator）会根据双方达成一致的约定进行构建，然后将工作交接给 QA（评估器）。这种方式既确保了工作忠实于规格说明，又避免在早期对实现细节规定得过于具体。

实验对比：运行编排框架

以复古游戏制作器对比单兵与完整编排框架。

提示（任务定义）

我编写了以下提示词，用于生成一款复古风格的游戏制作器：

制作一个 2D 复古游戏制作器，具备关卡编辑器、精灵编辑器、实体行为以及可试玩测试模式等功能。

参数与成本（对比表）

在该编排框架的首个版本中，我使用了 Claude Opus 4.5，将用户提示分别输入到完整编排框架和单体代理系统中进行对比。我选择 Opus 4.5，是因为在我开始这些实验时，它是我们最强的编码模型。

下表列出了所用编排框架类型、运行时长和总成本。

编排框架的成本高出 20 倍以上，但产出质量的差异立刻显现。

单兵运行（solo run）结果与问题

我原本期待能有一个界面，让我可以构建关卡及其组成部分（精灵、实体、瓦片布局），然后点击播放按钮实际体验该关卡。我先打开了单兵运行（solo run）的输出，初始应用看起来与我的预期基本一致。

然而，当我逐步点击操作时，问题开始显现。布局浪费了大量空间，固定高度的面板让大部分视口空置。工作流十分僵化。尝试填充关卡时，系统要求我先创建精灵和实体，但界面上没有任何提示引导我按此顺序操作。更关键的是，游戏本身已损坏。我的实体虽然出现在屏幕上，却对输入毫无反应。深入查看代码后发现，实体定义与游戏运行时之间的连接已断裂，而且界面上没有任何直观迹象表明问题所在。

初始界面
精灵编辑器
游戏演示

由单体编排框架（solo harness）创建的应用启动界面。

完整编排框架（harness）运行表现

在评估完单体运行（solo run）后，我将注意力转向了编排框架（harness）运行。这次运行同样从一句话提示开始，但在规划器（Planner）步骤中，这条提示被扩展成覆盖十个冲刺、包含 16 项功能的规格说明（spec）。它的范围远远超出了单体运行的尝试。除了核心的编辑器和游玩模式外，规格还要求实现精灵动画系统、行为模板、音效与音乐、AI 辅助的精灵生成器和关卡设计器，以及支持可分享链接的游戏导出功能。我为规划器开放了我们的前端设计技能，它读取后据此为应用创建了一套视觉设计语言，并将其纳入规格说明。每个冲刺中，生成器（Generator）和评估器（Evaluator）会协商达成一份冲刺约定，明确本次冲刺的具体实现细节，以及用于验证完成度的可测试行为。

这个应用立刻展现出比单兵运行更高的精致度和流畅性。画布充分利用了整个视口，面板尺寸合理，界面在视觉风格上保持一致，并且很好地契合了规格说明中的设计方向。我在单兵运行中遇到的一些笨拙之处依然存在——工作流仍未明确提示应先构建精灵和实体，再尝试填充关卡，这一点我还是靠自己摸索才发现。这更像是基础模型在产品直觉上的不足，而非编排框架（harness）本身要解决的问题，不过也提示了一个可在编排框架内部通过针对性迭代进一步提升输出质量的切入点。

在使用各类编辑器的过程中，这次新一轮运行相比单兵运行的优势愈发明显。精灵编辑器功能更丰富、更完善，工具栏更整洁，取色器体验更佳，缩放控件也更加易用。

由于我要求规划器在产品规格中融入 AI 功能，这个应用还内置了 Claude 集成，可通过提示生成游戏的不同部分，从而显著加快了工作流程。

初始界面
精灵编辑器
AI 游戏设计
AI 游戏设计
游戏演示

初始界面：在使用完整编排框架（harness）构建的应用中创建游戏

最大的区别体现在游戏模式下。我真的能够移动我的实体并游玩这个游戏。物理效果还有些瑕疵——我的角色跳上平台后却与平台重叠，这种直觉上不对——但核心功能是可用的，这是单兵运行未能实现的。四处移动了一会儿后，我确实遇到了一些 AI 构建关卡的局限性。有一堵很高的墙，我无法跳过去，结果被卡住了。这说明还有一些常识性的改进和边缘情况，编排框架可以进一步处理，从而让应用更加完善。

质量保障：评估器发现的具体问题（日志摘录）

从日志来看，评估器始终确保实现过程严格遵循规格说明。每一轮冲刺中，它都会逐条核查冲刺约定中的测试标准，并通过 Playwright 实际操作运行中的应用，针对任何与预期行为不符的情况提交 bug。冲刺约定的粒度极为细致——仅第 3 轮冲刺就包含了 27 项覆盖关卡编辑器的标准——而评估器的发现也足够具体，无需额外调查即可直接采取行动。下表展示了评估器识别出的一些典型问题：

评估器调优与能力边界

让评估器达到这一水平并不容易。Claude 默认表现为一个较差的 QA 代理（Evaluator）。在早期运行中，我看到它能识别出真实问题，但随后会自我说服这些问题不重要，最终还是批准了工作。它还倾向于只做表面测试，而不是深入探查边界情况，因此更隐蔽的 bug 经常被漏掉。调优流程是阅读评估器日志，找出其判断与我不一致的案例，然后更新 QAs prompt 针对这些问题进行修正。经过多轮这样的开发循环，评估器才开始以我认为合理的方式进行评分。即便如此，编排框架的输出仍暴露了模型 QA 能力的上限：小的布局问题、部分交互不够直观，以及评估器未充分测试的深层嵌套功能中的未发现 bug。显然还有更多验证空间可以通过进一步调优来补足。但与单兵运行相比——后者应用的核心功能根本无法正常工作——这种提升是显而易见的。

对编排框架的迭代

在能力提升背景下按部就班简化并验证假设。

第一版编排框架的结果令人鼓舞，但它也显得臃肿、缓慢且成本高昂。接下来合理的步骤，是在不降低性能的前提下寻找简化编排框架的方法。这既是出于常识，也源于一个更普遍的原则：编排框架中的每个组件都隐含着对模型“自身无法完成某些任务”的假设，而这些假设值得反复验证——既因为它们可能本身就是错误的，也因为随着模型能力的提升，这些假设会迅速过时。我们的博文《Building Effective Agents》（“构建高效代理”）将这一核心思想概括为：“find the simplest solution possible, and only increase complexity when needed”（“尽可能寻找最简单的解决方案，只有在必要时才增加复杂度”），而对于任何维护代理式编排框架的人来说，这都是反复出现的模式。

“find the simplest solution possible, and only increase complexity when needed”

在我首次尝试简化时，我大幅削减了编排框架（harness），并尝试了一些富有创意的新方法，但未能重现原始框架的性能。同时，也越来越难判断编排框架设计中哪些部分是真正的“承重结构”，以及它们具体发挥了怎样的作用。基于这次经验，我转向更为系统的方法，每次只移除一个组件，并审视它对最终结果的影响。

在我经历这些迭代周期的同时，我们也发布了 Opus 4.6，这进一步促使我们简化编排框架（harness）的复杂度。我们有充分理由相信，4.6 相较于 4.5 需要更少的支撑结构。正如我们的发布博客所述：“[Opus 4.6] 规划更为周密，能够更长时间持续代理式（agentic）任务，在更大的代码库中运行也更可靠，并具备更强的代码评审和调试能力，能够发现自身的错误。”此外，它在长上下文检索方面也有显著提升——这些正是此前编排框架用来补足的能力。

变更试验：移除冲刺构造

去掉冲刺，保留规划器与端到端评估的价值。

我首先彻底移除了冲刺构造。冲刺结构曾经帮助模型将工作拆分为多个部分，从而实现更连贯的处理。鉴于 Opus 4.6 的能力提升，有充分理由相信模型现在能够原生处理这些任务，无需再进行这样的分解。

我保留了规划器（Planner）和评估器（Evaluator），因为它们各自仍能带来显著价值。没有规划器时，生成器（Generator）往往任务范围不足：面对原始提示，它会直接开始构建，而不是先制定详细的工作规格，最终生成的应用功能会比有规划器参与时更少。

在移除冲刺构造后，我将评估器（Evaluator）调整为在整个运行结束时只进行一次整体评估，而不再在每个冲刺阶段分别打分。随着模型能力显著提升，这也改变了评估器在某些运行中的“承重”作用，其实际价值取决于任务距离模型可独立高质量完成的边界有多远。在 4.5 版本时，这条边界很近：我们的构建任务正好处于生成器（Generator）单独完成能力的极限，评估器能在整个构建过程中发现有意义的问题。而到了 4.6 版本，模型的基础能力增强，边界被推得更远。过去需要评估器把关才能实现连贯的任务，现在往往已落在生成器自身能够良好完成的范围内，对于这些任务，评估器反而成了不必要的开销。但对于仍处于生成器能力边缘的构建部分，评估器依然能带来实质性的提升。

实际意义在于，评估器并非固定的“是或否”决策。当任务超出当前模型能够可靠单独完成的范围时，投入评估器的成本是值得的。

在进行结构简化的同时，我还加入了提示工程，以优化编排框架（harness）在每个应用中构建 AI 功能的方式，尤其是让生成器能够构建出真正能通过工具驱动应用自身功能的代理。这一过程需要多次迭代，因为相关知识较为新颖，Claude 的训练数据对此覆盖有限。但经过充分调优后，生成器已能正确构建代理。

更新后的编排框架成果

用新版框架构建浏览器端 DAW，展示成本与 QA 收益。

为了检验更新后的编排框架（harness），我使用了如下提示生成一个数字音频工作站（DAW），这是一款用于作曲、录音和混音的音乐制作程序：

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

本次运行依然耗时较长，约 4 小时，Token 成本为 $124。

大部分时间都花在生成器（Builder）上，生成器连续运行了两个多小时，而且无需再像 Opus 4.5 那样进行冲刺分解。

代理阶段耗时与成本（V2 框架）

与之前的编排框架一样，规划器将单行提示扩展为完整的规格说明。从日志来看，生成器模型在应用规划、代理设计、代理接线，以及测试后交接给评估器的过程中表现出色。

QA 反馈（功能完整性缺口）

尽管如此，评估器（QA 代理）仍然发现了实际存在的缺口。在第一轮反馈中，它指出：

这是一个表现出色的应用，设计还原度高，AI 代理稳健，后端也很扎实。主要的失败点在于功能完整性——虽然应用界面令人印象深刻，AI 集成也运行良好，但几个核心 DAW 功能仅为展示用途，缺乏交互深度：剪辑无法在时间线上拖拽或移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（EQ 曲线、压缩器表）。这些并非边缘用例，而是 DAW 可用性的核心交互，且规格说明中已明确要求实现。

在第二轮反馈中，评估器再次指出了若干功能性缺口：

剩余缺口：

• 音频录制仍为占位功能（按钮可切换，但未实现麦克风采集）
• 剪辑边缘拖动调整大小和剪辑分割尚未实现
• 效果可视化仅为数值滑块，缺乏图形化展示（无 EQ 曲线）

生成器在自主运行时仍可能遗漏细节或仅实现占位功能，而评估器在发现并推动修复这些“最后一公里”问题方面依然发挥着重要作用。

最终成果与限制

根据提示，我原本期待的是一个能够创作旋律、和声和鼓点，并将它们编排成歌曲，同时在过程中获得集成代理协助的程序。下方视频展示了最终成果。

该应用距离专业音乐制作程序仍有很大差距，代理在作曲方面的能力也显然还有不少提升空间。此外，Claude 实际上无法“听”音乐，这使得 QA 反馈环在音乐品味方面的效果大打折扣。

但最终的应用已具备一个功能完整的音乐制作程序的所有核心组件：可用的编曲视图、混音器，以及在浏览器中运行的传输控制。除此之外，我还能仅通过提示让代理完成一段简短的乐曲片段：代理设置了节奏和调性，编写旋律，构建鼓轨，调整混音器音量，并添加混响。用于乐曲创作的核心原语已齐备，代理能够自主驱动这些流程，利用工具从头到尾完成一个简单的作品。你或许会说它还没有做到“恰到好处”，但已经越来越接近了。

接下来

随模型进步动态调整支架，探索新组合空间。

随着模型不断进步，我们大致可以预期它们能够处理更长时间、更复杂的任务。在某些情况下，这意味着围绕模型的支架（scaffold）会随着时间推移变得不再那么重要，开发者可以等待下一代模型发布，让某些问题自然而然得到解决。另一方面，模型能力越强，开发者就有更多空间去构建能够完成超出模型基线能力的复杂任务的编排框架（harness）。

基于以上思考，这项工作带来了一些值得延续的经验。始终建议在开发过程中多做实验，针对所用模型在真实问题上的表现进行观察，并调整其性能以实现预期目标。处理更复杂任务时，将任务拆解并为每个环节引入专门的代理，有时能带来额外的提升。而当有新模型发布时，通常应重新审视现有的编排框架，去除那些对性能已无关键作用的部分，并加入新的组件，以实现此前无法达到的能力。

通过这项工作，我更加确信，随着模型能力的提升，有趣的编排框架（harness）组合空间并不会缩小，而是会发生迁移。对 AI 工程师而言，真正有价值的工作是不断寻找下一个新颖的组合。