看不到客户数据，如何构建法律智能体？

核心难题：无法直接查看智能体的工作过程

法律智能体的开发面临一个特殊约束：任务数据属于律所的客户，开发团队不能直接读取智能体为律师工作时产生的执行轨迹。团队因此必须在无法查看真实任务细节的情况下，测试产品并定位问题。

Legora 的 CTO Jacob Lauritzen 围绕这一约束，介绍了团队的评估方式、模型选择和产品演进。以下内容聚焦已披露的做法与判断；部分访谈议题仅提供了讨论方向，没有展开技术细节。

用模拟工作环境开展评估

Legora 的评估团队由三名工程师和三名律师组成，按照客户的实际工作方式构建测试环境。这类环境类似强化学习中的“世界”，让智能体在接近真实法律任务的条件下接受测试。

相关测试涉及包含一万份文件的数据室。访谈还讨论了执行轨迹的转述，以及将失败情形归纳为十到二十类的做法，但现有信息不足以还原具体实现。

这里的关键区别在于：不能直接查看客户任务，并不意味着无法评估产品；团队可以围绕客户工作模式，构建可重复测试的环境。 不过，现有信息并未说明模拟测试与真实业务表现之间的对应程度。

模型能力：已有明显进展，但并非全面胜任

Lauritzen 估计，当前模型已经能够较好地完成约六成法律工作，其余部分仍需要更强的模型。这是他的判断，不应视为适用于所有法律任务的统一测评结果。

他还举了一个引证问题的例子：某项任务的正确率曾为 70%，一次模型版本更新后升至 99%，Legora 无须为此修改产品。

这一例子展示了底层模型升级可能带来的显著收益，但它只描述特定问题，不能据此推断整个系统的准确率或可靠性。

模型选择也在变化：Legora 多年来没有加入模型选择器，后来才提供这一功能。访谈讨论了背后的原因，但现有内容没有给出完整解释。

从法律助手走向工作流智能体

Legora 最初在斯德哥尔摩的一间地下室起步，早期组合是 ChatGPT、瑞典法律资料和搜索工具。如今，产品覆盖的工作包括：

• 文档起草与编辑：在 Word 中处理法律文件。
• 批量合同审查：在同一张表格中审查一万份合同。
• 尽职调查：围绕交易文件开展审阅；Legora 在自身收购过程中也使用了该产品。
• 协作与任务编排：协调律师、客户及其他智能体之间的工作。

其中，Tabular Review 采用表格组织大规模审查任务。访谈将其描述为可达百万单元格的工作界面，并讨论了律师如何通过前十行结果了解任务表现。

团队还介绍了 Slack 中的法律事务受理机器人，以及“智能体创建列表、列表再触发另一个智能体”的工作机制。这些功能体现了产品从回答问题，向组织和执行工作流的扩展。

隐私约束也影响基础设施选择

Legora 将全部系统运行在 Azure 上，Lauritzen 将这一选择与数据隐私要求联系起来。

访谈还涉及开放权重模型、转录模型，以及法律检索模型的后训练。不过，现有信息没有提供完整的部署架构、安全机制或性能对比，不宜据此作进一步判断。

长合同起草为什么离不开搜索

Lauritzen 将长合同起草视为一个搜索问题。相关讨论涉及搜索、检索、智能体运行框架，以及面对百万 token 合同时，如何在分块处理与大上下文窗口之间选择。

这些议题说明，法律智能体的能力不仅取决于文字生成，也涉及如何找到并组织任务所需的信息。但现有内容没有披露具体检索方案，也没有给出两种长文档处理方式的比较结果。

仍待回答的问题

访谈还讨论了律所合伙制、按小时计费、初级律师岗位，以及模型厂商与垂直法律工具之间的关系。这些属于行业影响与未来判断，现有信息并未提供确定答案。

对法律智能体开发者而言，这次讨论最值得关注的实践，是如何在客户数据不可直接查看的条件下，把领域专家、模拟任务环境和模型评估结合起来。至于这些方法能在多大程度上覆盖真实法律工作的复杂性，仍需要更完整的评估证据。