QUOTE

Uber 的这份实践复盘，展示了律师与工程团队如何共同改进合同修订智能体。以下先呈现译者评，再附全文翻译，保留原文图示，并以译注标明技术披露的边界。

本文看点

我认为，Uber 这篇文章最值得研究的，是它怎样让律师的专业判断持续进入系统迭代。律师提供谈判手册、纠正建议、留下最终条款和理由，通过规则明确公司立场和备选立场，并直接负责语气提示词中的具体内容；工程团队则把这些判断组织成检索、规则、反馈和文档操作机制。系统的改进，来自双方共同调整它怎样工作，而不只是由律师在最后检查答案。

先看清这份经验的时间边界。文章主要复盘的是始于 2024 年、延续至 2025 年建设，并于 2025 年内部试用的第一代系统。这一代已经包含智能体式条款修改流程。截至原文发布时，Uber 还在探索将 Claude Code、OpenCode 等运行框架与技能机制结合，并计划进一步探索法律本体和知识图谱。文章没有披露这些后续探索的完整落地结果。

文中“审查时间减少超过 20%”“AI 生成决策准确率 91%”是 Uber 对内部应用成效的报告，但文章没有交代这两个指标的样本规模、计算口径和评测期间，因此也不宜将指标精确归入原文未说明的某个版本或迭代阶段。它们不能用来证明后续探索的框架已经取得相同效果，更不能据此推断系统已经具备独立处理整个合同谈判的能力。

早期方案暴露的问题与随后的改进，恰好揭示了协同开发为什么重要。最初，团队希望从谈判手册中检索相关内容，交给模型生成合理决策。但检索依据与待处理的修改意图之间存在不匹配，手册之外的情形缺少可用依据，谈判回复的语气也不合适。要解决这些问题，就需要法律人员进一步说明：面对这项具体修改，期望采取什么行动，条款应当怎样写，理由如何表达。

早期反馈已经保存律师决定、原始文本、修订内容和简单的负向信号；后续迭代则进一步记录期望行动、具体反馈意见，以及律师最终采用的修改文本。语气调整的突破，则来自更明确的分工：工程团队负责提示词的结构，律师直接负责定义目标、表达风格和开场句示例。依我理解，这已经把法律人员带入系统行为和输出标准的定义过程：哪些输出算合格、哪些立场应当坚持、哪些表述可以代表团队，都需要他们持续参与决定。

这种协同有具体入口，也能留下供后续任务调用的记录。本文所称的“自学习”，主要体现为检索历史反馈、选择示例并组织后续提示词的上下文，而不是已经披露了一套持续更新模型参数的训练过程。理解这一点，才能准确看待律师反馈究竟怎样影响系统。

这对法律 AI 的建设提出了一个更实在的评价标准：专业人员的纠正，能否在适用情形下被正确继承，并改善后续输出？如果律师每次都要重复解释同一个问题，积累了大量修订记录却无法在后续任务中正确调用，那么这些经验仍未转化为系统可复用的能力。Uber 的反馈检索、规则库和时间加权机制，尝试让过去的修正成为后续任务的参考。本文据此建议，实施者应当明确谁有权维护规则、哪些反馈值得继承，以及旧立场在什么条件下失效。反馈数量本身不能保证经验质量，近期的一次处理也不当然应当成为通用标准。

同时，这套经验有明确的业务条件。原文强调，同一原始合同能够为多轮互动提供相对稳定的参照，模板中的对应条款可以承载规则和历史反馈。这种重复性，降低了把既往经验用于后续任务的难度。对于陌生模板、全新交易结构或缺少既往立场的问题，文章没有证明同样的方法仍能保持相同效果。企业需要检验自己的工作究竟有多少可重复部分，以及这些部分是否足以支撑可靠的检索和规则适用。

未来更广泛的智能体探索，会进一步考验这套协同机制。这里是本文对下一阶段的判断，并非 Uber 已经公布的实现成果：当系统开始组织更广泛的任务，法律团队仍需参与定义它能够采取哪些行动、哪些条款可以改、哪些判断必须交回律师。工具拥有更多行动能力以后，专业判断需要进入任务边界和执行规则，而不只体现在最后一轮文字审核中。

这也使我更看重 Uber 展示的协同方式。具体模型、检索组件和运行框架都可能继续更新，而律师与工程团队共同定义问题、纠正输出、明确立场的机制，可以为这些更新提供持续的专业输入。对法律 AI 项目而言，一项值得建设的长期资产，是让专业判断能够被记录、检验、修订，并持续影响系统行为。评估下一代智能体时，这种协同是否仍然有效，应当成为与技术能力一起检查的问题。

原文：Scaling AI in Legal: Building Uber's Redlining Agent，2026 年 10 月 8 日。

2026 年 10 月 8 日

Austin Greco　资深软件工程师

Meghana Somasundara　产品负责人

Frank Tenente　高级法律总监，产品法务（出行业务与平台）

Sean Po　资深软件工程师

Rush Tehrani　高级工程经理

很少有领域像法律工作这样，对准确性和审慎程度有如此高的要求，因此，将 AI 智能体融入日常法律实践是一项严峻的考验。从 2024 年初开始，一直延续到 2025 年，在今天的智能体运行框架尚未得到广泛应用时，Uber 构建了第一代合同修订智能体（Legal Redlining Agent，LRA）。它帮助 Uber 法律团队处理大量合同谈判，同时不损害信任或合规性，也不取代律师的判断。

最经得起时间检验的经验，并不在于模型或架构，而在于如何成功地让智能体融入律师的日常工作。我们从业务问题出发：持续涌入的合同谈判包含大量可重复的修订工作。我们把工具放进律师原本就在使用的 Microsoft Word®，让 LRA 能够在现有工作流程中标记有风险的修订内容并提出修改建议。随后，我们与律师密切协作，反复调整智能体应当做什么，于 2025 年在法律团队中试用，并将他们的反馈重新纳入产品。

在这篇博客中，我们分享了将第一代系统投入实践的经验：如何界定问题、赢得律师信任，以及利用律师反馈改进智能体。最后，我们会介绍第一代系统的工作方式，以及随着智能体技术的发展，今天我们会如何处理这一问题。

2026 年 3 月 9 日，Uber 法律团队在 ALM Legalweek Leaders in Tech Law Awards 中凭借包含 LRA 的参评方案，获得了“年度最具创新力法律部门”奖。

Uber 每年要谈判数千份合同。每份合同背后，都有一个法律团队负责审查和谈判。这一过程可能耗时很长，包含大量重复工作，而且常常成为交易、接入流程和业务上线的瓶颈。它是一项风险重大、注重细节的工作，准确性至关重要，而任何延误都会波及销售、接入流程和业务上线。

然而，在这一高风险过程中，隐藏着一些结构化程度出人意料的内容：相似的条款、不同客户之间重复出现的修订，以及稳定的法律推理模式。换句话说，其中存在一套清晰的体系。

法律部门的工作对 Uber 至关重要，因此，我们看到了一个机会：将可重复的部分自动化，为律师腾出时间来处理复杂的判断问题，同时不牺牲质量或一致性。

译注｜图 2 文字补译 图中流程为：发送 Uber 模板→客户审阅并提出修订→Uber 审阅并回复→合同定稿，中央标题为“合同谈判生命周期”。一轮指一次修订内容的交换，原图标注每轮耗时 2—10 小时；企业交易平均经过 5 轮完成谈判。这是原图对 Uber 业务的描述，不是行业平均值。

合同修订智能体是一个由 AI 驱动的智能助手，以加载项的形式直接集成到律师日常使用的 Microsoft Word 中。它审查客户的修改，理解修改意图，推荐符合内部政策的应对方式，生成结构化审阅意见，标记风险，并持续从反馈中学习。

它结合了以下功能：

自向法律团队推出以来，我们观察到平均合同审查时间减少了超过 20%，AI 生成决策的准确率达到 91%。我们也收到过这样的反馈：“它确实帮我节省了时间，尤其是审阅意见方面的建议。”

该加载项分析 Microsoft Word 文档，识别外部交易方留下的修订内容。随后，它利用 AI 处理这些修改，尝试理解客户的意图及其法律影响。它将拟议修改与我们团队的内部法律政策和指引进行比对。

基于这项分析，加载项会生成一组建议，其中包括推荐采取的行动、拟向客户提供的审阅意见，以及对每项修改所涉及风险等级的评估；这些审阅意见以法律推理解释推荐行动的理由。Uber 律师随后逐一审查每项建议，决定接受、拒绝还是修改，然后才将其最终纳入对客户的回复。

我们刚才描述的系统，并不是一开始就具备完整形态的。走到这一步经历了四次重大迭代，每次都让我们深刻认识到，法律 AI 究竟需要什么。

在这一过程中，我们使用了 Uber 的生成式 AI 网关，因此可以专注于完善产品逻辑，并与领域专家密切合作。

我们最初的方案，是开发一套基础的检索增强生成（Retrieval Augmented Generation，RAG）系统。法律团队提供了现有谈判手册和谈判轮次的实例。我们的假设是：将这些手册导入系统，找出语义相关的部分，再把这些内容与交易对方提出的修改一并交给大语言模型（Large Language Model，LLM），系统就能生成合理的决策。

我们很快遇到了这种方案的几个问题：

认识到仅依赖谈判手册的局限后，我们意识到，智能体需要有更强的适应性，并持续从真实互动中学习。于是，我们开发了一个由律师直接反馈驱动的自学习闭环。

最初，我们的反馈机制很简单：保存律师的决定（接受／拒绝／修改）、原始文本、修订内容，以及一个“踩”的反馈信号。这能提供基本的错误信号，却缺少重要的细微信息。

为了加深系统的理解，我们改进了反馈闭环，使其能够记录律师期望采取的行动及具体反馈意见。引入由 AI 起草修改文本的能力后，我们进一步扩展了反馈内容，收集律师最终使用的修改文本。这些细粒度数据成为一个转折点。它使我们能够将交易对方的意图，直接映射到律师经改进后的具体措辞。智能体的准确性开始显著提高，并逐步适应团队偏好的表达风格和谈判立场。

我们也开始在建议界面中直接展示相关的既往反馈和规则。这让律师能够清楚了解建议为什么会被生成，帮助建立信任，也让他们能准确看到哪些信息影响了 AI 的输出。

在运行时，智能体会查询反馈存储，其中如今已包含数千次既往互动。系统首先进行带有元数据过滤的相似性搜索，将候选范围缩小到约 20 份相关文档。随后，这些候选文档会进入第二层过滤，由前沿的大语言模型核实其是否与用户及交易对方的意图相符。然后，智能体分析最相关的实例，决定接受还是拒绝拟议修改，并为交易对方生成审阅意见。

我们还实现了一种指数衰减加权算法，用于构造后续提示词的上下文。该机制优先使用近期决策，确保智能体适应法律立场的变化，缓解概念漂移，同时保持同意与不同意实例分布的平衡。这种动态、平衡的少样本提示方式，使合同修订工具能够近乎实时地学习用户偏好和政策细节，而无需人工进行模型微调。

后续改进还包括有针对性地清理数据，以提高搜索结果的准确性。这种迭代优化使应用程序的性能能够持续改进，并产出高质量的标注数据集；这些数据集对于跟踪质量回退和推动持续改进至关重要。

为了应对持续存在的语气问题，我们在处理流水线末端增加了一次大语言模型调用，专门调整输出的语言表达风格。但我们很快发现，在法律谈判中把握好语气，比听起来更难。

早期输出在两种失败模式之间摇摆：有时过于防御、充满对抗性；有时又过度迎合、急于讨好。这两种情况都不符合我们的律师在实际谈判中所采用的审慎、专业的语气。

突破来自与内部法律团队的密切合作。我们认识到语气是法律沟通的关键组成部分，因此让律师直接负责定义所需语气和对话风格的具体表述。工程团队负责提示词的结构，而内部法律团队负责这一三部分提示词结构中的内容。

我们请律师更新的提示词第一部分是目标。这一部分定义语气调整智能体的角色。它采用一种主动以负面预设为起点的 AI 反思技术：先假定智能体生成的回复存在我们此前遇到过的问题。

其他反思技术会通过复杂的循环，使行为收敛到预期状态。我们发现，先假定生成的回复存在语气问题，不会影响原本语气恰当的示例，却能以较高的可靠性充分纠正语气不当的示例，即使只进行一轮处理也是如此。我们认为，这源于复杂度的降低：在单个提示词中，大语言模型少了一项需要作出的判断。不采用循环，也限制了 token 用量和延迟。

接下来，我们在提示词中告知该节点律师偏好的表达风格。由于智能体要代表律师起草回复初稿，我们必须确保它表达直接，使用第一人称，并且不进行无关闲聊。

最后，我们提供了一个部分，让 Uber 内部律师填写对话开场句，作为少样本实例。

几天之内，他们就将它调到了与自己的表达方式精确契合的程度。这带来一个关键认识：直接影响输出格式的提示词，应当由应用程序的领域专家或最终用户编写和管理，AI 团队则提供指导，确保遵循提示词设计的最佳实践。

判断是否接受或拒绝一项修改固然有价值，但真正为律师节省时间的，是起草回应对方修改的替代条款。单纯生成文本，往往会凭空生成术语，或偏离合同中已经定义的术语。

为了解决这一问题，我们从简单的文本生成，转向了智能体工作流。当系统作出 MODIFY（修改）决定时，我们会参考历史反馈和规则来完善条款。

这使工具能够帮助律师起草高质量的折中条款文本，既反映既往法律指引，也纳入公司针对每一具体问题所持的整体风险立场。

最后，我们意识到，律师经常使用自己的模板，而这些模板又往往在不同团队之间共享。这一特点带来了两项优势：

为了利用这些优势，我们为律师开发了规则数据库。律师可以在原始模板文档中选择重要或经常被修改的文本，并为其关联一条规则。一条规则包含 Uber 的立场、任何备选立场，以及一个期望应用程序给出的回复示例。当应用程序检测到修改时，会用修改后的句子对规则索引进行语义向量搜索。如果一条规则以高置信度匹配成功，就会被加入上下文窗口。为了确保严格遵守规则，工作流程还加入了最后一个大语言模型步骤，核实最终输出是否准确符合检索到的要求。

当把这一工具推广到更多业务线时，规则数据库还会带来第二项收益：帮助律师在整个公司范围内保持法律立场的一致性。

系统采用轻量客户端架构：Word 加载项负责文档交互和用户输入，Python 后端则编排所有 AI 操作。当律师触发分析时，后端会运行一个 LangGraph™ 工作流，并行执行意图检测、风险评估和政策查询。向量存储（OpenSearch®）提供记忆层，检索相关规则和历史反馈，为每项决策提供依据。

一个关键的设计决定，是将助手构建为 Microsoft Word 加载项，而不是独立的网页应用程序。律师的工作主要在 Word 中进行，因此，要求他们在不同工具之间复制粘贴，会断送工具被采用的可能性。

该加载项使用 React 和 TypeScript 构建，以任务窗格的形式运行在文档旁边。它通过 Microsoft Office® 的 JavaScript API 与 Word 通信，读取修订记录、应用修改，并突出显示正在审查的条款。

这项集成也遇到了挑战。Office JavaScript API 存在显著限制，需要我们设计应对办法：

这些限制塑造了我们的架构：由轻量客户端谨慎编排 Word 操作，再由后端完成所有繁重的 AI 处理。

我们通过并行运行独立的图节点，同时优化延迟和准确性。例如，当意图节点分析交易对方实质性的意图时，风险等级节点会并发评估条款的风险状况。

为了兼顾灵活性与合规性，我们设计了一个混合系统，对硬性逻辑和软性逻辑采取不同的处理方式。

对于不可谈判的政策，我们使用确定性的规则引擎。与标准 RAG 不同，这个引擎只有在与目标句的语义匹配满足严格要求时才会触发。一旦匹配到规则，它就会充当硬性护栏，覆盖模型的输出。

对于可谈判的细节，例如语气和策略，我们依赖概率性的反馈闭环。

这种双轨方式帮助我们启动了系统：从第一天起，就能基于规则交付高置信度结果；与此同时，反馈闭环逐步积累处理更复杂、非结构化情形所需的数据。

译注｜规则机制的技术边界 “确定性的规则引擎”及“硬性护栏”是作者对该机制的描述。原文同时提到语义匹配和大语言模型校验，未进一步披露各步骤的实现细节，因此不宜将其理解为规则识别与执行全过程均具有确定性保证。

我们自学习能力的核心，是一个无需人工进行模型微调的反馈闭环。我们记录每次律师互动的完整快照。这一结构化数据集包括原始上下文（合同文本、交易对方的修订内容）、AI 的分析（意图、风险等级），以及最为关键的律师完整回复：最终决定、实际作出的任何具体文本修改，以及书面理由。这些细粒度数据使系统不仅能够建模决定了什么，还能够建模为什么作出这一决定，从而在未来相似的情形中复现资深律师判断中的细微差别。

为了防止模型过度倚重过时的法律立场所造成的概念漂移，我们基于指数衰减实现了一个自定义的反馈采样算法。在为上下文窗口检索少样本实例时，我们会为每次历史互动计算一个权重。

weight = exp(-λ * age_days)

其中，λ 与一个可配置的半衰期相对应，目前将半衰期设置为 365 天。这样可以确保模型适应法律立场的变化和概念漂移，而不至于过度依赖过时的既往处理记录。实际上，系统能够近乎实时地学习团队当前的偏好，就像一位同事会逐渐理解新的工作惯例一样。

我们的知识库依赖 OpenSearch，使用 nomic-embed-text-v15 嵌入进行高维语义检索。我们维护了两个主要索引：

当检测到新的修订内容时，系统会对这些索引进行语义向量搜索，检索最相关的规则和既往决策，确保 AI 拥有提出修改建议所需的准确上下文。

在这一问题场景中，我们有一项优势：谈判总是从同一份原始合同开始。这意味着，对于同一份文档的多次互动，我们可以将学到的信息和反馈锚定到相同的段落。

首先，我们以 ;、. 或 \n 字符为分隔符，将法律合同拆分成小块。随后，每当系统遇到修订内容时，就会基于原始合同中的对应句子进行查找，以检索到确定相关的历史记录或明确规则。

每当用户与系统互动并提供反馈时，用于入库的也是原始合同中的对应句子，文本原样保留。

要取得最佳搜索效果，查询嵌入与入库嵌入之间的对称性非常重要。在我们的场景中，存储的嵌入和查询的嵌入都来源于合同，因此能够保证它们相似。相似性搜索仍然必不可少，因为文档可能会随着律师每一轮的批注而发生细微变化。

译注｜检索机制的披露边界 原文分别描述了按修改后的句子检索规则、按交易对方意图向量化反馈，以及按原始合同中的对应句子查询和入库的做法，但未完整说明这些机制在不同步骤或版本中的对应关系。不能据此补写出原文未披露的完整处理顺序。

对于对话界面，我们使用 Redis® 维护会话状态，让律师能够就文档继续提问。在后台，我们持续运行以大语言模型为评判器的评估，监测检索上下文的质量（document_quality_metric），以及模型对公司规则的遵守程度（rule_adherence_metric）。

作为 Uber 整体智能体 AI 工作的一部分，其中也包括法律 AI，我们正在探索 Claude Code®、OpenCode® 等智能体运行框架，并结合技能来组织和自动化工作流程。与此同时，我们还将探索引入法律本体和知识图谱，为表示法律概念及其关系提供语义基础，从而实现更一致的解释和更可靠的推理。

从最初的 RAG 系统，到整合用户反馈、改进语气，再到实现稳健的规则数据库，我们经历的这些迭代表明：构建真正有效的 AI 法律助手，是一个由持续学习和与领域专家紧密合作所驱动的迭代过程。我们遇到的每项挑战，都成为加深理解、改进系统的机会，最终让工具更加准确、更具适应性，也更加以用户为中心，能够在复杂的法律谈判中切实增强人的专业能力。

我们感谢 Alissa McDowell 的密切合作和领域专业支持，也感谢 Uber 法律团队、AI 平台团队及其领导者 Michelle Parker 和 Viv Keswani，支持我们将 AI 引入 Uber 法律部门。

封面图片来源：使用 OpenAI ChatGPT Images 生成。

Claude 及其标识是 Anthropic, PBC 在美国和其他国家的注册商标。使用这些商标，不表示获得 Anthropic, PBC 的认可。

Codex 及其标识是 OpenAI OpCo, LLC 在美国和其他国家的注册商标。使用这些商标，不表示获得 OpenAI OpCo, LLC 的认可。

FastAPI 及其标识是 Sebastián Ramírez 在美国和其他国家的注册商标。使用这些商标，不表示获得 Sebastián Ramírez 的认可。

LangChain、LangGraph 及其标识是 LangChain Inc. 在美国和其他国家的注册商标。使用这些商标，不表示获得 LangChain Inc. 的认可。

Microsoft Word、Microsoft Office、Office JavaScript API、TypeScript 及其标识是 Microsoft Corporation 在美国和其他国家的注册商标。使用这些商标，不表示获得 Microsoft Corporation 的认可。

OpenSearch 及其标识是 LF Projects, LLC 在美国和其他国家的注册商标。使用这些商标，不表示获得 LF Projects, LLC、OpenSearch Project 或 OpenSearch Community 的认可。

Python 及其标识是 Python Software Foundation 在美国和其他国家的注册商标。使用这些商标，不表示获得 Python Software Foundation 的认可。

React 及其标识是 Meta Platforms, Inc. 在美国和其他国家的注册商标。使用这些商标，不表示获得 Meta Platforms, Inc. 的认可。

Redis 及其标识是 Redis Ltd. 在美国和其他国家的注册商标。使用这些商标，不表示获得 Redis Ltd. 的认可。

Austin Greco

资深软件工程师

Austin Greco 是 Uber AI 平台 Michelangelo 的资深软件工程师，曾负责开发者体验，并帮助推动这一平台从早期阶段发展为支持全公司机器学习的系统。

Meghana Somasundara

产品负责人

Meghana Somasundara 是 Uber AI 平台的产品负责人。此前，她曾在其他公司从事 AI 平台建设。

Frank Tenente

高级法律总监，产品法务（出行业务与平台）

Frank Tenente 是 Uber 出行业务与平台产品法务的高级法律总监，领导为出行业务和跨平台业务部门提供支持的法律团队。作为商业及产品律师，Frank 曾推动 B2B 法律团队规模化发展，并倡导运用生成式 AI 改变合同审查与法律工作。

Sean Po

资深软件工程师

Sean Po 是 Uber 智能体平台团队的资深软件工程师和技术负责人。

Rush Tehrani

高级工程经理

Rush 是 Uber AI 平台团队的工程经理。他支持负责传统模型、深度学习模型和生成式 AI 模型部署与服务、移动端机器学习以及生成式 AI API 网关的团队。