我们构建了自己的云代理基础设施

在过去的一年里，Harvey从一款聊天产品转型为云代理——从回答律师的问题到端到端地完成律师的任务，例如审查数据室并生成涵盖数十万份文档的初步问题清单。当我们开始这项工作时，运行此类代理所需的基础设施还不存在，因此我们自行构建了它。

前沿实验室（如Anthropic的Claude托管代理和OpenAI的代理）以及云提供商（如AWS、Microsoft Foundry和Google）现在开始推出托管代理运行时。它们令人印象深刻，我们与所有这些公司密切合作以塑造其发展方向。因此，有必要精确说明为什么我们仍运行自己的代理：服务律师事务所和受监管企业带来了一系列要求，而这些要求目前没有一个托管运行时能满足，并且在短期内也无法满足。

主要考虑因素有三个：支持多模型、零数据保留以及成本控制。这些要求都不罕见，我们预计随着时间的推移，尤其是云提供商，将能解决这些问题。但每一个目前都是硬性障碍——第一个值得深入探讨，因为大多数人低估了它即将变得多么普遍。

律所不能锁定单一模型

最明显的原因是利益冲突。如果一家律所代理了某个模型提供商的客户，那么该律所面临着使用该提供商模型的商业压力；当大客户自己的技术不是外部律所使用的技术时，关系就会受损。这本身就使得单一模型平台变得尴尬。但更尖锐的问题在于保密性：如果客户自己构建了模型，他们不会允许外部律所通过竞争对手的模型处理敏感法律事务。随着更多公司训练自己的模型，以及实验室扩展到更多行业，受此影响的律所数量会迅速增长。

如今，很容易将其视为少数律所和少数有冲突客户的问题。但情况不会一直这样。几年内，想要服务广泛客户群的律所将需要能够运行任何模型，因为重要客户不可避免地会反对任何特定模型。多模型不仅仅是一个边缘特性的功能；它正在成为代表科技公司的基本门槛。

冲突是硬性要求，但并非支持多模型的唯一原因。质量和成本优化日益关键。不同模型在不同任务上表现更优——我们的法律代理基准（LAB）显示按执业领域和任务类型存在明显差异——而且随着开源模型的改进，这种差异正在扩大而非缩小。行业正在从“哪个模型最好？”转向“对于这个特定任务，哪个模型效率最高？”要回答这个问题，必须访问所有模型。

此外还有平台风险，代理使得这种风险比聊天更加严重。如果你承诺使用单一提供商的托管运行时，而该提供商的模型落后了，或者容量不足、降低了你的优先级、改变了定价或弃用了你依赖的功能，你将陷入困境。而且锁定不再是模型本身，而是你的整个代理员工队伍。你的团队构建、调整并依赖的代理都运行在该提供商的运行时内，使用其格式和编排。你无法将它们迁移出去。对于将运营押注在代理上的律所来说，这是公司层面的风险，也是将运行时保持在自己控制之下的最佳理由。

这也是两种托管运行时之间的分歧点。前沿实验室的运行时将你锁定在该实验室的模型上——最大程度的锁定。云提供商的运行时支持模型灵活选择，这是正确的方向，但它们往往在最新模型上落后于实验室，并且仍然面临冗余和正常运行时间限制。两者单独都不足够，因此我们与所有提供商合作并在它们之间进行路由。

构建这种路由是困难的部分。每个提供商暴露不同的代理框架——不同的工具调用格式、停止条件、流行为和失败模式——以及不同的执行沙箱，针对一个模型调优的同一任务在另一个模型上表现不佳。我们构建了一个抽象层，在单一接口下标准化了框架、沙箱和行为差异，这样对于其上的一切，模型选择只是一个路由决策。

零数据保留是硬性要求

我们签署的每一份律所合同，以及每一份企业合同，都要求零数据保留（ZDR）。这不是买方可能放弃的锦上添花；它是一个门槛，因为涉及的数据是特权且保密的，不能存放在第三方服务器上。前沿实验室的托管运行时不提供ZDR，这意味着通过它们运行律所的事务将使该律所的客户数据保留在实验室的基础设施上。对于我们的客户来说，这完全不可接受。

理解ZDR的关键在于它不能事后添加。有一个诱人的捷径——在运行期间存储数据，然后调用删除端点——但这不是零保留；而是保留后删除，对于律所的目的而言，两者不同。ZDR意味着设计运行时，使得客户数据默认不被写入持久化应用存储。代理沙箱在任务运行时仍然需要临时工作磁盘，但该磁盘的生命周期与沙箱绑定，并在拆除过程中自动清理。这是运行时的一个架构属性，而不是最终切换的设置。

代理使得这一点比聊天更难，原因贯穿整篇文章：代理是有状态的。长时间运行的代理会累积工作记忆、中间文件、工具结果以及用于从中断中恢复的检查点——而托管运行时正是通过在云端持久化所有这些来体现其价值。这种持久化状态是客户数据处于他人环境中的静态数据。自动状态持久化和零保留是互斥的；你不能两者兼得。

因为我们拥有运行时，代理的整个生命周期都在我们的安全边界内运行。状态局限于会话并被清除，因此零保留保证覆盖整个工作流程，而不仅仅是最终的模型调用。

成本正成为主要约束

在这三个考虑因素中，成本可能是最重要的，并且增长最快。我们的使用量正在急剧攀升，以规模化的方式作为代理运行最强大的模型极其昂贵。单个代理运行可以涉及大量模型和工具调用，因此朴素方法（将所有任务路由到最佳前沿模型）的每任务成本是不可持续的。越来越多与我们合作的律所不仅要求我们让代理工作，还要求它们经济实惠。

关键洞察是，对于大多数任务，你不再需要最大的模型。随着模型的改进，越来越多的法律工作已经变得智能饱和：任务完全在小模型或开源模型的能力范围内，而使用顶级前沿模型只是超支了任务不需要的能力。我们的LAB基准证实了这一点——在许多任务类型中，开源模型以一小部分成本达到前沿质量。目标已从寻找最佳模型转变为找到足够好、最便宜且最快的模型。

大规模做到这一点需要对模型路由和执行沙箱进行精细控制，而托管平台目前在这方面存在不足——它们没有提供足够的控制来积极优化。拥有运行时使我们能够将每个任务路由到满足质量阈值的最有效模型，包括我们自己托管的开源模型，并优化沙箱（文件加载方式、工作并行化方式、计算规模调整方式）以专门适应法律工作负载。

综合效果可能很大：根据我们的经验，相对于仅使用前沿模型的方法，成本降低了3-5倍，具体取决于模型和工作负载。这种优化水平对于在他人运行时之上构建的任何人都无法实现。正是这种差异使得为律所的完整文档集（数十万或数百万文件）服务代理变得经济可行，而不是一个失控的预算项目。

为未来构建

我们不期望永远以目前的形式运行自己的代理基础设施。许多差距将随着时间的推移而缩小，我们认为尤其是云提供商会达到目标。他们有强大的动力支持多模型路由、零保留和开源模型，我们正在与他们合作实现这一目标。我们构建自己的运行时是为了在它们到来时吸收这些改进，而不是为了永久绕开生态系统。当某个提供商能比我们更好地完成其中一部分时，我们希望使用它。

拥有运行时也是使法律特定层成为可能的原因，也是长期重要的原因。律所将需要多云弹性和真正的数据驻地，包括将事务保留在特定司法管辖区内的能力。我们最大且最受监管的客户越来越希望主权部署：通过我们在其边界内自行托管自己的云代理基础设施。他们需要冲突感知治理，以编码特定事务甚至允许接触哪些模型，以及每个代理所做工作的完整、可检查记录，用于工作产品和特权。这些都不是通用运行时能解决的法律行业问题，而所有这些都是使拥有这一层变得持久而非临时的原因。还有更多——安全性和隔离，以及更长的受监管行业要求列表——但这些是最重要的。

我们构建自己的云代理基础设施的原因很简单：我们的客户现在就需要生产中的代理，而满足他们对多模型灵活性、零数据保留和成本的要求意味着拥有它们运行所处的运行时。依赖我们的律所不能等待生态系统跟上，而特定于法律工作的部分始终是我们必须正确处理的。