看不见客户合同，法律智能体如何交付：Legora 的工作流与判断边界

一、嘉宾背景

本集《Latent Space: The AI Engineer Podcast》由 Alessio Fanelli 和 Shawn swyx Wang 访谈 Jacob Lauritzen，时长约67分钟。节目标题将嘉宾标为 Legora CTO，转录开场却称其为 CEO，两处身份称谓并不一致。对话中，他直接讨论了工程组织、产品架构和落地取舍。

Legora 起步于瑞典斯德哥尔摩，正在向美国扩展，为律师开发法律检索、起草、文档编辑、分析与协作工具。Jacob 的介绍围绕这家公司的产品与组织实践展开：如何把模型能力接入专业工作，如何应对客户要求，又如何在实际部署中作出取舍。他对用户、收费和职业变化的判断，也来自这一观察位置。

团队规模的变化反映了产品需求的扩张。Jacob 说，自己曾希望工程团队维持在约20人，访谈时团队已扩大到约100人。他将当前职责概括为用少量核心原语支撑大量产品能力。访谈由此延伸到一组相互关联的问题：模型如何完成任务，工作如何进入系统并交接，以及团队在基本无法查看客户材料的情况下，如何判断结果是否可靠。

二、本期主要内容

据 Jacob 介绍，Legora 最初是接入瑞典法律搜索工具的 ChatGPT，随后逐步扩展到起草、Word 编辑、文件整理和复杂分析。随着代理能够执行更多任务，产品也开始承担工作编排与协作。他区分了两条发展主线：一条是完成法律工作，另一条是组织这项工作。检索回答解决具体问题，请求如何进入、谁来审阅、结果怎样交付，则决定这些能力如何融入日常业务。

Tabular Review 展示了批量任务如何执行：每行对应一份文档，每列对应一个问题。Jacob 以一万份雇佣合同为例，说明系统如何提取通知期、知识产权转让、解雇补偿和薪酬等信息，随后由代理分析异常并起草客户备忘录。一万份合同是流程示例，并非已披露的客户项目规模。他另提到，单次处理规模约可达一百万个单元格，单位是单元格，而非文档。

表格也承载着用户对执行过程的控制。系统先运行前十行，供用户检查问题是否明确、输出是否符合预期，再扩大处理范围。结果支持来源引用，用户可以标记审阅状态和风险，并通过评论协作。异常在哪里、哪些内容已经检查、哪些仍待处理，都能在同一界面中呈现。

Intake 从请求入口组织工作：Slack 中的法律请求被转成指定列表里的任务，法律团队在 Legora 内处理后，再将结果回传。Lists 是可配置数据库，可以通过触发器和自动化连接代理、字段与文档。Jacob 将 Lists、Projects、文件系统和 Agent 等视为可复用的基础能力，希望据此构建专用界面。他介绍的收购标的 Wexler 则面向诉讼材料，能够提取事实，并比较不同证据之间的印证与冲突。

模型使用也按任务拆分。Legora 根据子任务路由模型，同时应客户要求提供主模型选择器。Jacob 估计，约60%的既有法律工作已经能够很好地完成，但复杂分析仍需要更强的智能。这一比例没有附带测量方法，应视为他的判断。长期来看，他希望减少邮件和 Word 版本的反复传递，在保留审计与数据留存的同时，让律师审阅主动代理已经完成的事项。不过，他也明确承认，未来的产品形态尚不确定。

三、核心观点：推理、例子与边界

在 Jacob 看来，评估模型必须细分到法律业务领域和具体任务。Legora 为此绘制表现热力图：新模型可能在一些任务上进步，也可能在另一些任务上退步。项目评测也要分开检查风险发现与报告质量，既看该发现的风险是否找到，也看报告是否完整、分析是否合理、措辞是否准确简洁，以及是否夹杂无关内容。风险漏检和写作失当需要不同的修复办法，合成一个总分容易掩盖问题。

这些评测需要法律专业人员参与。Jacob 称，核心评测团队约有三名工程师和三名律师，还能获得约百名法律工程师的支持。法律工程师通常有三至四年大型律所经历，部分具备计算机科学背景，也参与客户沟通和产品开发。他们能把业务中影响判断的区别带入测试，让法律质量的评估有专业依据。不过，专家参与仍无法消除评测与实际使用之间的差距：材料往往属于律所的客户，Legora 基本看不到真实数据与调用轨迹，只能近似重建使用场景。

产品指标因此只能说明部分问题。Legora 结合续约、回访、活跃度、使用时长和低成本模型在线评测来观察产品，并通过功能开关比较发布效果。这些信号可以帮助识别发布后的变化，却难以完整解释某份法律分析为什么出错。Jacob 没有披露具体活跃率、节省工时或投资回报数字，使用频繁也不能直接证明每项任务都正确。保密限制同样不会因材料被简单去名或改写而自动解除。

引用系统让核查更容易，但核查是否发生，仍取决于使用者。Legora 支持多层追溯：从生成内容定位到表格的行或单元格，再回到原始 PDF 等文件中的高亮出处。这条路径减少了寻找来源的负担，却不能仅凭链接的存在就确认来源支持整个推论，更不能证明律师已经检查过。对话也指出，律师的核验习惯差异很大。可追溯性提供了复核条件，实际复核仍需有人完成。

复杂起草进一步说明，专业能力并不止于生成文本。Jacob 将它描述为检索和组合问题：先寻找律所处理类似交易的先例，判断行业、公司类型等条件是否相近，再找到合适的人，并从多份文档中选择条款。长合同还带来两类困难：全文编辑需要持续追踪定义、顺序和此前修改；逐块检索则可能漏掉跨约两页、组合后才显出相关性的内容。Legora 因此随着模型变化调整分块方式与调用编排。截至访谈，团队尚未微调模型，计划先针对扇出检索等明确任务，对开放权重模型进行后训练。Jacob 认为，检索架构、流水线和法律运行框架也仍有大量优化空间。

对职业变化的判断，同样需要区分任务和岗位。Jacob 不认同律师助理和初级律师已不再需要，认为优秀新人使用工具后可能更有价值；这是他的观察与判断，访谈没有提供就业统计。Legora 自身的并购实践呈现了更具体的分工：产品承担大量尽调，外部律师继续处理跨国风险和交易结构。Jacob 称，团队曾因风险信号停止推进交易，但没有披露具体案例，因而无法据此判断风险拦截的成功率。他还观察到，美国部分低端审阅已采用项目费、固定费率甚至免费服务；这一观察也不能外推为所有法律费用都在下降。并购、诉讼、战略判断和客户关系，在他看来仍承载着重要价值。

知识积累能否转化为收益，是更深一层的组织问题。Jacob 认为，AI 可以帮助律所把先例、方法和专业判断编码为持久资产。但合伙人如果主要因获客获得奖励，退出后又难以分享所建资产的收益，就可能缺少沉淀经验的动力。技术提供了积累知识的手段，收益分配机制却会影响人们是否愿意投入。他预测，企业通过通用代理调用 Legora，与律所直接使用 Legora 将会并存，并以四亿美元并购交易说明产品追求的专业深度。这个金额用于说明目标场景，并非通用产品与专业产品的比较评测结果。

四、学习与应用

从 Tabular Review 的流程可以提炼出一种批量审阅的实施顺序：先试运行，再扩大处理，最后复核交付。先用少量材料检查问题是否明确，确认通知期、补偿等字段的含义，再放大执行；交付时分别检查来源、异常和审阅状态。前十行试运行有助于尽早发现提问错误，却无法保证后续材料中没有罕见条款。高风险结论仍需回到原文确认适用条件，批量处理结束也不意味着法律工作已经完成。

模型采购可以把任务质量、延迟、成本、数据去向、区域可用性和供应商协议放在一起比较。Jacob 解释，Legora 最初采用 Azure，受到律所此前已对微软完成安全审查的影响；数据处理协议也会限制供应商数量。因此，即使某家供应商在单项能力上略强，新增采购与治理成本仍可能影响选择。对其他团队而言，应先确认自身约束，再比较模型；Legora 的既有审查条件并不能直接转化为所有律所的部署依据。

实施分工则应对应问题性质。Legora 的法律工程师负责无代码配置、培训和流程重构，FDE 负责生产代码、复杂集成及 API 扩展。落地时，可以先由熟悉业务的人确认请求如何进入、谁负责复核、结果送到哪里，再判断是否需要扩展平台能力，减少因流程尚未明确而直接启动定制开发的情况。不过，参与实施并不自动带来数据访问权。Jacob 说，FDE 通常也不能接触客户数据，少数情况需要按客户员工的方式入职。

集成前需要列出所需操作，逐项确认接口覆盖范围。Legora 当时提供 API 约半年，尚未承诺覆盖全部网页功能。Jacob 担心，旧版本维护会拖慢快速迭代。让代理接收请求、代替部分操作接口，仍是探索中的方向，效率、成本、延迟和确定性都有待权衡。对于要求执行可预测的流程，可以先限定任务、明确可观察的完成条件，再比较直接接口与代理的表现；访谈没有提供足以支持全面替换 API 的可靠性结果。

故障复现还需要明确材料授权。Legora 可以邀请自愿配合的客户提供匿名化文档与问题，但匿名化不能自动视为使用许可。Jacob 指出，即使收购一家律所，也未必取得其客户数据的使用权。仅有历史输入和最终输出，也可能不足以判断质量或还原中间过程。因此，缺少过程证据时，排错结论应限于已复现的场景，不能据此声称已经定位全部真实故障。

优化可以从具体问题入手：缺少相关先例，遗漏跨块内容，还是报告组织不当？先分别检验检索、调用编排和输出质量，再判断是否需要后训练。主持人建议，RAG 应用不要只依赖通用嵌入榜单或默认模型，也应考察定制方案；Jacob 基本赞同，同时强调多语言覆盖。实际比较应围绕法律问题与服务语言展开，既不能只按榜单选择，也不能预设定制必然带来提升。对话没有提供对照实验或提升数字，更合适的做法是开展可验证的小范围试验，据此决定下一步投入。

来源

• 原始节目：Building Legal Agents When You Can't See the Data — Jacob Lauritzen, CTO of Legora