What Is ARIA, and How Did We Build It?

ARIA是什么，以及我们是如何构建它的

发布于

2026年9月25日

9

分钟阅读

由

CoreWeave团队

已复制

ARIA的聊天面板与它创建并验证的固定工作区部分并排显示，展示了训练运行的激活图表对比。

最初发布于CoreWeave的Weights & Biases博客，2026年9月25日。

当我们在2026年6月29日发布ARIA公开预览版时，最直观的展示是代理聊天体验：向它询问实验相关问题，观看它检查证据并给出答案。聊天是ARIA的主要交互方式，但这并不是展示ARIA核心能力的部分。

我们最初有一个相对常规的想法：在W&B中植入一个能使用工具的智能代理，这里已经存在Runs、指标、制品和生产追踪。我们认为主要优势在于上下文。研究人员不应该在代理提供帮助前，需要将项目的一半内容复制到提示词中。

上下文确实重要。但当ARIA开始进行有用的研究后，更困难的问题发生了变化。聊天关闭后，工作能否继续？其他人能否检查证据？长时间的调查能否从失败中恢复？代理能否在不悄无声息地剥夺研究人员控制权的情况下采取行动？当ARIA出现错误时，我们能否将这些失败转化为更完善的产品版本？

产品正是围绕这些问题发展起来的。我们构建的内容仍然是W&B中的一个代理，但更准确地说，它是一个以对话为起点的研究过程。

我们从上下文开始

想象一下，因为训练运行变慢而打开一个W&B项目。你已经有了一个过滤后的工作区，选择了几个可疑的Runs，并注意到某个指标在上次配置更新后发生了变化。你询问发生了什么。

一个通用助手看到这句话。在它提供帮助前，你需要描述项目，粘贴相关指标，解释过滤条件，并决定哪些制品适合提示词。在调查真正开始前，你已经完成了一半的调查工作。

ARIA从问题周围的W&B上下文开始。它可以检查实验数据和生产追踪，跨Runs追踪证据，并创建一个工作区或报告，将发现结果与支持它的数据并列展示。如果下一步有用的操作是另一个实验，ARIA可以准备这项工作并请求研究人员批准启动。

图1. 在研究人员能够检查对话旁边的生成图表时，ARIA创建并验证了一个固定工作区部分。图片来自官方ARIA发布报告。

持久化输出改变了我们对良好答案的定义。随着对话消失而消失的精心润色段落难以复查，对未参与讨论的同事几乎毫无用处。报告可以共享，工作区可以随着新Runs的到达持续更新。其他研究人员可以打开任一内容，对结论提出异议，并从相同证据继续工作，而不是从截图中重建工作。

我最初认为这些制品只是呈现答案的一种更友好的方式。但在实践中，它们成为了答案本身的一部分。研究人员在对话中提出请求；持久化的制品才是让研究对团队其他成员产生价值的地方。

在W&B工作也迫使我们更明确地界定权限。查看选定的Runs是调查的一部分。创建报告会改变共享项目。启动实验会消耗实际计算资源。ARIA可以处理这些决策的繁琐工作，但模型表现出的自信不能赋予它更多权限。研究人员仍然需要批准具有重大影响的操作。

图2。ARIA缩短了从观察结果到启动下一个实验之间的工作流程。只有在研究人员批准操作后，循环才会闭合。改编自CoreWeave的AI Loop。

研究超出了聊天的范围

代理循环的第一个版本很容易想象。ARIA接收请求，选择工具，检查结果，直到得出答案。一个框架组装了提示信息和项目上下文，暴露允许使用的工具，保存对话历史，并强制执行限制。

实际调查使这个循环变得不那么整洁。像“为什么这些运行变慢了？”这样的问题可能取决于研究人员查看的页面、应用的过滤器、特定指标以及早期实验生成的工件。我们将页面状态转化为结构化上下文，使ARIA能够判断其来源以及研究人员选择了什么。我们还明确保留限制：一个经过过滤的页面只是一个有用的起点，而不是证明代理已经查看了整个项目的证据。

然后任务变得更为复杂。ARIA可能需要检查数百个Runs，生成可视化图表，等待远程工作，从失败的工具调用中恢复，或在研究人员关闭浏览器后继续执行。当调查可能持续超出浏览器会话时间后，我们需要一个持久化存储来保存工作，并且需要一个能够恢复工作的执行器。

生产环境中的ARIA服务将一个用户请求及其后续的代理工作存储为一个持久化的Turn。一个Turn包含提示信息、可重建的历史记录、配置的代理和环境，以及继续执行所需的状态。Turns形成一棵树，使研究人员能够返回到更早的节点并以其他方向继续工作。一个工作线程会认领一个Turn并记录其进度。活跃的工作在隔离的沙箱中运行，其文件和状态可以快照并恢复。

这些都不是代理演示中引人注目的部分。这些是决定演示能否成为产品的关键部分。对话历史帮助ARIA继续执行任务，但服务仍然需要持久化保存工作并在发生故障时恢复工作。浏览器可以显示进度，但不能负责调度任务或在标签页关闭后保持任务运行。

随着这些责任的积累，我们有意识地将它们拆分。ARIA服务负责授权、持久化、分发和进度跟踪。代理决定下一步要做什么。环境暴露状态和工具。沙箱隔离执行。一个共享的驱动程序协调一个Turn在这些组件之间的执行。

图3。相同的调查获得了结构化页面上下文、持久化的Turn、可恢复的执行和可恢复的文件。关闭浏览器只会移除查看器，而不会删除工作内容。

这种分离并非为了架构本身而存在。它为故障提供了更有价值的定位信息。如果代理选择了错误的工具，我们可以调查代理的行为；如果工作者丢失了状态，我们可以修复恢复机制；如果沙箱在任务开始前失败，我们无需假装代理回答错误。它还让我们可以在不重建整个服务的情况下修改代理，并在不声称ARIA变得更智能的前提下调整基础设施。

生产故障成为有用的证据

当ARIA开始执行实际工作后，我们需要一种更好的方式来从其失败案例中学习。我们的第一反应很熟悉：阅读追踪日志，记住关键部分，然后编写一个更清晰的评估任务来重现核心问题。

问题在于，重写过程常常会移除故障发生的原因。提示内容得以保留，但页面上下文丢失了。预期结果得以保留，但之前的对话轮次或环境状态却消失了。最终，我们测试的是一个简化的故障故事，而非用户实际经历的情况。

持久化的Turn为我们提供了更好的起点。它已经包含了请求、可重建的历史记录、配置好的代理和环境，以及可恢复状态的引用。生产工作者使用的相同驱动器可以离线运行受控任务。这使评估候选者更接近我们实际可以部署的ARIA版本，而不是创建一个行为几乎但不完全像产品的基准测试专用版本。

Weave使这一桥梁不仅成为可能，更变得实用。Weave是W&B用于代理和LLM应用的可观测性与评估系统。它将代理操作记录为调用（Calls），并将其连接成追踪日志，使我们能够通过相同的证据模型检查生产故障和离线对比。我们可以从评估结果追溯到生成它的模型和工具调用，比较不同尝试，添加评分，并将证据与正在评估的变更保持关联。

W&B代理工厂（WBAF）则在该证据基础上提供了ARIA专用的研究环境。它导入与生产对齐的ARIA配置，并运行测试拟议变更所需的任务、环境和评分器。所有权设计有意保持简单：ARIA服务仍然是生产环境的真理来源，Weave记录生产与评估的证据，WBAF执行对比，任何看似良好的变更在部署前仍需返回正常生产审查流程。WBAF不会部署第二个ARIA实例。

这个故事有一个重要的限制。我们可以保留对话和沙箱状态，但周围的W&B项目可能继续变化。新的运行记录会不断出现，工件位置会移动，服务返回的数据也会不同。因此，要完全复现一个旧的Turn，需要为外部关键证据准备不可变引用或预置固定装置。保存代理状态并不等同于冻结它所能观察到的世界。

在说出这句话后，这个注意事项似乎显而易见。但当初Turn和沙箱成功恢复、整个任务看起来可重放时，这一点并不那么明显。构建ARIA的过程中，我们不断发现一个令人兴奋的主张的精确版本通常比其令人兴奋的表述更有用。

ARIA能否帮助改进自身？

将生产工作与评估连接起来，使一个更宏大的想法变得可行：给ARIA它自己的故障，并让它协助修复过程。

我们并不声称ARIA目前能够自主地进行自我重写。当前的工作流程范围更有限：我们检查失败的Turn（回合），它接收到的上下文以及相关的代码或指令，然后使用代理来帮助提出一个有针对性的修改建议。可编辑的部分可能是系统指令、脚本、工具合同，或Skill（一个用于特定任务的指令、参考和脚本包）。

查看代码和对话内容同样重要。假设一个追踪记录显示代理请求了过多数据，超时后又重复了相同的计划。如果我们只阅读对话记录，诱人的修复方式是再添加一句让它更谨慎的提示。但实际原因可能是某个Skill教授了错误的查询模式，某个工具未提供有界读取功能，或者重试行为恢复了相同的不良状态。我们不得不频繁添加额外的提示规则，这些规则虽然经常有效，却演变成了提示词打地鼠游戏。

代理可以提出修改建议，我们也可以重新运行驱动该修改的案例。如果下一次尝试使用了正确的证据并顺利完成，这就有价值。它告诉我们这个修改值得进一步调查。

但它并不能说明ARIA整体上有所改进。项目本身可能发生了变化。某个服务可能已经恢复。这个修改可能解决了当前对话的问题，却破坏了三个相关任务。失败的Turn帮助我们定位问题；而受控对比才能告诉我们提出的修复是否值得上线。

这是我们信任的自我改进方式。ARIA可以帮助检查失败，提出修改，并收集相关证据。人们仍然决定什么才是正确的行为，对比是否公平，以及结果是否足够可靠以发布。ARIA不会给自己打分，也不会合并答案。

第0篇《我们如何对ARIA进行基准测试——以及为什么它在Weave上运行》解释了我们如何构建这些对比，基准测试包含哪些内容，以及人类审核在哪些环节仍然发挥作用。

系列后续内容

本系列文章将跟进ARIA在初始代理循环接触实际应用后变得有趣的四个部分：

• 将研究代理嵌入研究平台背后的产品理念；
• 支持密集型、并行和长期任务的接口；
• 保持这些任务持续运行的工作者、环境和沙盒；
• 将生产失败转化为已审查修改的评估流程。

部分文章将解释当前已存在的系统。其他文章将描述我们仍在探索的方向，并会明确标注。目标是展示这些组件是如何构建的以及它们的边界在哪里，而不是过早让路线图听起来已经完成。

评估工作还让我们面临一个更普遍的问题。其他代理也需要我们为ARIA实验设置的相同控制机制：锁定候选任务，执行前向人展示计划，隔离运行环境，并在运行后将结果与证据进行核对。我们将这些控制机制提取到Fugue中，这是一个独立的实验治理项目。Fugue不属于ARIA的运行时环境，也不会替代WBAF的ARIA专用任务或诊断功能。Fugue系列文章将涵盖这一分支的工作。

我们最初是将一个使用工具的代理嵌入到W&B中。自那以后的工作重点是让其研究在对话中持续存在，保持对其他人的可检查性，并在不悄无声息地赋予代理对“更好”定义的权威性的情况下实现改进。

将代理置于实验旁边只是简单的一部分。真正困难的是在不剥夺研究者权威的前提下，让其研究持续时间超过对话本身。

分享这篇文章： /think