我们如何将Playbook Review重建为多智能体系统
Harvey将合同审查从固定流水线重构为多智能体系统，以质量换延迟，实现风险分类+18%、红线质量+34%，并开启自我改进的合同智能。
企业依靠合同运营，而几乎所有的合同都需要经过谈判。据Gartner统计，法务部门将21%的工作精力投入到合同事务上，这一比例超过了其他任何活动。审查一份合同通常需要20分钟到5小时不等，具体时长取决于合同的类型和规模。
当公司收到交易对手方发来的合同时，法务部门的人员会逐条对照公司的剧本进行比对；所谓剧本是公司内部的一套规则手册，其中明确了哪些条款是可接受的、可协商的，或是不可触碰的底线。随后，他们会在文档上进行修订标注、添加批注，并将其发回给对方审阅。这一过程会持续进行，直到双方就彼此都能接受的条款达成一致。
今年早些时候，我们从头重建了Harvey的剧本审查引擎，旨在更有效地减轻用户在合同审查中的繁琐负担。本文将带您了解旧系统的运作方式、我们做出这一改变的原因、如何评估这一问题的质量（这一问题极具主观性且依赖法律判断），以及这个全新的多智能体系统如何对照剧本分析文档、标记风险，并提出律师可以信赖的精准修订建议。
为什么合同审查比看上去更难
规则手册在概念上简单明了，包含以下要素：
- 标准立场：公司希望在合同中看到的理想条款
- 可接受的偏差：公司愿意谈判的备选条款
- 不可接受的偏差：合同的底线条款
- 指导原则：如何根据具体交易背景解释和应用规则
- 可选：合同中是否允许缺失某一条款
但审查真实合同之所以复杂，还有几个原因，尤其对AI系统而言：
合同包含复杂的条件逻辑： 合同具有复杂的条件逻辑，条款跨越数页，相互引用，并描述某些条件何时触发或不触发。而且，即使制定了规则手册，交易对手方的合同几乎不会使用你手册中的原话。立场往往以条件逻辑加以限定。因此，审查条款的代理需要理解这些条件性、句法性与语义性差异背后的含义及影响，而非仅仅进行文字匹配。
规则在文档中相互交织： 一条关于转让权利的规则可能触及文档中四个不同部分，而同时另一条规则可能对同一句话提出修改建议，从而产生冲突。这使得并行审查变得复杂。
正确答案取决于交易背景： 律师审查自己起草的合同（一方文件）与审查对方起草的合同（第三方文件）的方式不同。律师谈判合同的方式取决于诸多因素：你代表哪一方？合同是基于己方模板还是对方模板？这是第一轮谈判还是第七轮？同一条款在一种交易姿态下可以接受，在另一种下则不可接受。如果对方已拒绝了之前的建议，再次提出同样的建议并非明智之举。
最好的编辑通常是最小的改动： 你发出的每一处修订都会受到对方律师的仔细审视。如果一个条款只需改动三个词，而代理却重写了整个条款，这不仅会拖慢交易进程，还会给人工审阅者增加额外工作。律师们称之为最轻触感，这是现成的AI模型和代理往往达不到的质量标准。
某些决策无法委派： 仅靠操作手册无法捕捉交易中的细微差别。如果对方是重要客户，合同审阅者可能会给予更多通融。一个好的系统应当能识别出何时需要将条款升级给人类处理，并根据交易背景阐明理由。
除了在特定交易背景下理解文档的细微之处外，处理可能长达数百页的文档和操作手册的规模也是一项挑战，因为随着token数量增加，LLM的响应质量会下降。对于Harvey平台而言，我们需要确保在处理可能跨越数百页的真实合同时保持同样高的质量，并仍能及时生成修订意见。
我们的首个系统：提示词流水线
与同时代大多数生产级LLM系统相似，Harvey最初的剧本审查是一个工作流：一系列固定顺序的模型调用，在代码中编排，每个调用都配有一个精心设计的提示词。
该系统包含两个阶段：分类与红线标注。分类阶段以状态匹配的瀑布流形式进行。对于每批规则，一次模型调用会询问：合同是否符合规则的标准位置？未通过的规则则进入第二次调用，检查可接受的偏差是否匹配；仍未通过的规则则进入第三次调用，检查不可接受的偏差。分类完成后，一个独立的检索步骤会定位文档中的支持性文本，最后一步调用则撰写总结。
红线标注则来自另一次单一的模型调用：给定一个条款、一个位置以及合同中定义术语的列表，模型返回该条款的修订版本。我们将修订版与原文进行差异对比，该差异便成为追踪的变更。
这种设计有其利弊。它可预测、易于调试且成本效益高。每次调用都有单一职责。但流水线的每个阶段都硬编码了关于合同审查如何分解的假设，这些假设导致系统在复杂的剧本审查中遇到困难：
- 上下文在LLM调用与合同审查子任务之间丢失： 由于每次LLM调用独立工作，分类的上下文在引用和红线标注过程中丢失。这有时会导致最终输出的不一致。
- 编辑按条款范围进行： 红线模型每次调用仅获取一个条款的上下文，只能编辑或删除该条款。它无法将语言移至其所属章节、添加缺失条款，或保持编辑与文档其余部分的一致性。建议文本有时会落在错误位置，或相关章节顺序错乱。
- 建议孤立提出： 每条规则被独立评估，因此两条规则可能对同一句子提出相互矛盾的编辑，且没有针对这些边缘情况的改写。最终用户不得不手动修复这些错误。对于跨段落存在复杂依赖关系的规则和文档，由于单次LLM调用预算有限，无法深入思考并提供准确输出，以解决复杂文档和操作手册的问题。
受这些限制影响，审查可能过度标记红线、遗漏标记、在错误位置插入建议，并弄不清合同归属哪一方。逐步的提示修复仅能改善个别指标，但最终我们需要不同的架构。在选择架构之前，我们需要一个基准来衡量改进。
让法律判断可量化
启动这次改版时，没有任何公开基准能端到端地衡量这一工作流程，因此我们与内部法律团队共同构建了一套专属评估体系。
核心数据集将合同与各类合同类型的操作手册配对，覆盖数百项条款。该基准评估合同审查的不同方面：
- 风险分类： 根据风险级别识别和归类问题的能力。
- 修订质量： 一份由称职律师修订时应考虑的清单，涵盖实质内容和风格两方面。这些评分标准为每个示例单独定义。
风险标记最适合作为分类问题来理解和评分，这是一个直接的任务。修订质量则更为复杂，因为它需要对编辑是否最小化、位置恰当且法律正确做出判断。在从律师处获取评分标准后，我们建立了一个评估框架，利用LLM评审员依据这些标准打分。随后，我们采用由三个前沿模型组成的评审团独立评分并汇总投票结果。
多智能体系统
在评估就绪后，我们探索了几种复杂度递增的架构，并根据质量、延迟和复杂度进行了评分：
| 方法 | 质量 | 延迟 | 复杂度 |
|---|---|---|---|
| 基于规则的LLM工作流 | 中等 | 优秀 | 低 |
| 单一智能体审查员 | 优秀 | 不可接受 | 中等 |
| 协调者智能体与子智能体 | 优秀 | 良好 | 高 |
单一智能体审查员
智能体系统之所以强大，是因为它们允许LLM持续解决问题，直到满足特定条件。这在规模化应用中效果良好，因为智能体可以配备工具来搜索文档中的各个关键部分，然后查找所需规则和其他信息，直到它满意地找到一份适用于特定交易和策略手册的修订文档。
为了验证这一假设，我们构建了一个单一智能体，它拥有审查文档和策略手册的上下文，并允许其使用文档编辑工具迭代文档，直到满足策略手册的要求。这是最简单的智能体解决方案，在基准测试中表现良好，但延迟非常高，会导致用户体验不佳。
协调者智能体与子智能体
通过单一智能体原型，我们证明了质量问题可以通过智能体解决。通常改善延迟的最佳方法是寻找并行化工作的途径。基于这一想法，我们实现了一种协调者-工作者模式，由一个主导智能体负责在并行智能体之间分配工作。每个子智能体专注于特定任务，在本例中为审查某条规则，最终由主导智能体协调结果，确保最终输出质量优良。
我们发现，这种架构在质量、延迟和工程复杂度之间取得了良好平衡：
工作代理处理单独的规则： 编排代理被提示担任审查的主审律师角色。它会生成一组子代理，分别审查手册中的每一条规则，最多可并行运行数十个。每个子代理的工作方式类似律师助理：它会阅读自己负责的规则，阅读或搜索合同，判断合同是否符合手册要求，选择要采取的立场（标准立场或特定的备选立场），然后起草一份建议修改清单。
关键的是，它是一个真正的代理，而不是简单的函数：如果某条款引用了附件，它会主动去阅读该附件。为了让代理能够快速、精确地引用和搜索文档的不同部分，我们为文档的每个组成部分赋予了唯一标识符。这使代理能够明确地引用和编辑特定元素。每个子代理完成工作后，会提交一份简短备忘录，说明其对规则的分类、对合同的修改建议，以及各步骤的理由。
工作代理在文档副本上工作： 数十个代理同时编辑同一份文档会造成混乱，因为它们经常需要针对不同规则，对同一段落或句子进行修改。这会导致文档状态不一致，一个代理先前完成的工作会被另一个代理覆盖。为解决这个问题，我们构建了分支机制：每个子代理在版本化文档模型的独立分支上工作，每一项拟议修改都作为该分支上的跟踪更改，并标注产生该修改的规则。
当子代理完成后，会有一个协调步骤，以类似版本控制系统的方式合并各分支：无冲突的修改会干净地应用到最终文档，而两条规则触及同一文本的冲突，则升级交由主代理解决。
编排器确保一切均获审查： 编排器负责分派审查者、汇集其工作成果，并以资深律师的方式解决文档中的冲突，即起草符合所有冲突规则的编辑内容。随后，它进行最终审阅，以验证整体审查质量。这确保了每条规则均被分类，并在需要时获得相应的编辑。
编排器与工作者共享上下文： 系统考量律师审查合同时所用的相同上下文：他们代表的当事方、合同基于己方模板还是对方模板、本次谈判应严格还是宽松，以及任何针对交易的特定指示。审查还可参考用户附加的先例文档作为额外上下文。层级中的每个代理均能看到此上下文，并相应调整其行为。
状态持久化以确保连续性： 每个代理的状态——分类、所选立场、编辑摘要、推理过程——随审查持续保存。当用户提出后续问题、切换所选立场，或采纳部分建议并要求重新考虑其余部分时，我们复用相关代理，而非从头到尾重新运行整个代理循环。
评估结果
我们在识别和分类风险及红线质量方面取得了显著进步。另一方面，使用该系统审查合同耗时更长，但鉴于我们追求输出质量，这一权衡是合理的。
| 指标 | 之前 | 之后 | 变化 |
|---|---|---|---|
| 风险分类 | 59% | 77% | +18% |
| 红线标准 | 53% | 87% | +34% |
| 平均延迟（分钟） | 2.6 | 3.8 | +47% |
实现可扩展性
代理式重新设计提升了审查质量，但也带来了新的挑战。由于采用代理端到端完成任务，令牌使用量和系统整体延迟显著增加，尤其是在规则数量较多的长合同或剧本中。我们的系统在离线评估中表现良好，但为了使其在实际生产中具备可扩展性，我们围绕代理团队构建了一套防护措施，以确保审查快速、可靠，并符合基础设施限制：
- 自定义超时与针对性重试。 在评估运行期间，某些模型调用偶尔会在异常条款上陷入低效循环。该问题通常通过重试即可自行解决。为缓解此情况，我们根据模型、审查阶段和文档大小设置了超时，并仅对受影响的规则进行重试。这防止了一个不良子代理拖垮整个审查过程。
- 限制并发。 由于剧本中的每条规则都会派生一个子代理，我们增加了并发限制和指数退避策略，以避免共享模型基础设施过载。
- 提示缓存。 对于长文档和剧本，输入令牌会呈指数级增长，导致剧本审查成本过高。然而，每条规则审查的是同一份底层文档的大部分内容。我们利用这一事实重新设计了提示，以优化前缀缓存命中率。这显著降低了模型成本，并改善了延迟。
- 流式结果输出。 即便经过所有优化，首次结果生成的时间仍然较长。为解决此问题，我们启用了流式结果输出，使得每条规则的结果在其子代理完成后即可立即获取。这让最终用户能在几秒内开始审阅输出，而无需等待最终结果。流式输出还使我们能够展示进度，并隔离运行缓慢或需重试的规则，而不影响其余审阅流程。
- 为每项任务选用最佳模型。 我们的评估显示，在合同审阅的子任务中，没有单一模型表现最佳。我们构建了系统，使其能在同一审阅的不同阶段切换模型，根据各模型在特定任务上的质量、延迟和成本进行选择。
- 多模型协调框架。 我们构建了代理协调框架，以标准化不同模型提供商之间的差异。这有助于系统的未来适应性，因为我们能够以最小开销快速切换到表现最佳的模型。
代理式审阅带来的新可能
我们对可靠的首轮审阅所开启的可能性感到兴奋。
合同审阅现在可以在后台运行。每当新合同通过电子邮件或共享文件系统到达时，Harvey 会启动审阅工作流，提前处理工作，并为用户提供一个论证充分的草稿作为起点。
实现自我改进的闭环成为可能。每一条被接受、修改或拒绝的修订标记都能帮助代理理解法律团队的偏好。这将使我们能够构建一个从用户到账户的个性化系统，使得每份新合同所需的指导和努力都比上一份更少。
团队的历史合同成为新的输入，以促进更优质的审阅。这开启了跨数千份文档搜索以往示例的能力，以信任代理输出，并快速了解团队过去批准了什么及其原因。
这就是我们通过合同智能所努力实现的目标——让每一次合同审查都能优化下一次，使法律团队在业务量增长时仍能保持掌控。
作者：@pfelgueres、Maharshi Patel、Zach Huang
致谢
感谢 Harvey 团队以下成员在 Playbook Review 项目中的贡献：Karl De La Roche、Rina Kim、Scott Werwath、Jianan Zhang、Sakshi Pratap、Kunal Baweja、Will Huang、Andy Pham 及 Alex Conrad-Dormoy。