Agent 法律服务：先把法源检索、引用校验和律师复核串起来，再谈自动法律建议
法律 Agent 最容易被写成一个自动给意见的黑盒，但真正能落地的，通常是把法源检索、草稿生成、引用核验、保密控制和律师复核串成受控流程。
01.法律 Agent 最危险的误区，是把它当成自动法律意见生成器
法律场景和普通知识问答最大的区别，不在于文本更长，而在于责任更明确。
一旦系统输出：
- •错误引用
- •过时法源
- •不完整的合同分析
- •没有复核的结论性意见
后果就不只是“答案不太准”，而可能直接影响客户决策、交易推进甚至司法程序。
所以法律 Agent 更适合被设计成“法律工作流协作者”，而不是能独立出具法律判断的黑盒顾问。
02.先从研究和审阅辅助切入，而不是直接生成正式法律意见
如果第一版就要做“自动出具法律意见书”或“自动生成可直接提交法院的文件”，风险会非常高。
更现实的切入点通常是：
- •法规、案例和内部模板检索
- •合同条款比对和异常标记
- •尽调材料摘要
- •合规清单整理
以“合同审阅助手”为例，一个可交付的第一版通常已经很有价值：
- •从知识库和模板库里检索相关条款
- •对比待审合同和标准条款差异
- •标出高风险缺口和待确认问题
- •生成律师可继续修改的审阅草稿
- •不直接把草稿当成最终法律结论发出去
这条链路既能提效，也更符合律师复核和责任归属的现实要求。
03.一条可靠的法律工作流，通常由四层组成
1. 事项 intake 与边界层
法律任务一开始就要搞清楚：
- •当前事项是什么
- •适用哪个法域
- •目标是研究、审阅、起草还是合规核对
- •可使用哪些资料
- •哪些内容涉及保密或特权
没有这层，系统很容易把不相关的法源和模板混进来。
2. 检索与引用层
法律 Agent 的核心不是“说得像律师”，而是能不能基于正确来源工作。
更重要的能力通常是：
- •检索适用法条、判例、政策或内部规范
- •标记法源时间和适用范围
- •明确每个结论对应了哪些依据
- •区分原文依据和模型推断
如果没有可回溯的引用，法律输出很难真正被信任。
3. 起草与对比层
这一层很适合模型承担高重复劳动，例如：
- •生成研究 memo 初稿
- •起草合同审阅意见清单
- •对比两版条款差异
- •把复杂法律表达改写成业务可读版本
但这些内容都应该被视为“待复核草稿”，而不是可以直接对外使用的终稿。
4. 复核与交付层
法律场景里，终稿责任必须清楚落在专业人员身上。尤其在下面这些情况：
- •对外出具法律意见
- •向法院或监管机构提交材料
- •涉及客户重大商业判断
- •涉及保密、特权或敏感事实
没有这层复核，系统越流畅，风险反而可能越大。
04.模型负责检索辅助和初稿整理，律师负责判断和签发
在法律场景里，一个更稳的职责拆分通常是：
更适合模型处理的部分
- •读取大量合同、政策和材料
- •提取条款差异和关键事实
- •根据检索结果整理 memo 初稿
- •把专业术语转成业务语言
更适合系统和律师处理的部分
- •选择最终适用法源
- •判断结论是否成立
- •审查保密与特权边界
- •决定是否可以对外发送或提交
- •对最终法律意见承担责任
如果让模型直接跳过这些环节给出“最终结论”，系统就很容易在最关键的地方失真。
05.先让模型输出结构化法律任务，而不是直接出结论
相比一句 prompt 让模型“分析这个案子”，更稳的方式是先把任务结构化，再决定检索、比对还是起草。
from typing import Literal
from pydantic import BaseModel, Field
class LegalTask(BaseModel):
lane: Literal["research", "contract_review", "policy_check", "drafting", "handoff"]
jurisdiction: str
source_ids: list[str] = Field(default_factory=list)
deliverable: str
requires_lawyer_review: bool = True
def run_legal_workflow(task: LegalTask, tools):
authorities = tools.retrieve_authorities(task.jurisdiction, task.source_ids)
draft = tools.generate_legal_draft(task.lane, task.deliverable, authorities)
checks = tools.verify_citations_and_privilege(draft, authorities)
if task.requires_lawyer_review or checks.has_blockers:
return tools.route_to_lawyer(draft=draft, checks=checks)
return tools.prepare_internal_note(draft=draft, checks=checks)这个模式的价值在于：
- •先明确法域、任务类型和交付物
- •所有输出都能回到已检索的依据
- •引用校验和律师复核可以独立执行
06.法律场景特别依赖检索，而不是“记忆”
法律 Agent 的一个常见误区，是把模型当成一个知道所有法条和案例的超级记忆体。实际上，法律工作更依赖：
- •当前法域是否匹配
- •法源是否最新
- •条款和事实是否真的对应
- •引用有没有被准确表达
所以比起问模型“你知道什么”，更重要的是让系统明确：
- •去哪里检索
- •允许引用哪些来源
- •如何展示依据
- •如何拦截无法验证的引用
这也是为什么法律 Agent 特别适合和检索、结构化输出、引用校验结合在一起。
07.保密和特权控制，不能等到上线前再补
法律工作天然会碰到大量敏感信息，例如：
- •客户资料
- •交易谈判文件
- •尽调文档
- •内部法律分析
只要系统接触这些材料，就必须先搞清楚：
- •哪些数据允许进入模型上下文
- •是否有企业级数据保护边界
- •谁能访问哪些事项
- •日志和追踪里是否暴露敏感内容
如果这些边界没有提前设好，系统很难进入真实律师工作流。
08.引用核验要成为主流程，而不是补充步骤
很多法律 Agent 的失败，不是因为草稿完全不能看，而是因为它会在最关键的地方犯“看起来很像真的”错误：
- •案例不存在
- •条款编号错位
- •适用法域搞错
- •模型把摘要写成结论
所以更稳的做法是把引用核验做成强制步骤：
- •没有来源的结论不能直接过
- •来源和结论对不上时必须标红
- •需要人确认的地方单独列出来
这样系统才更接近真实法律工作的谨慎节奏。
09.评估不要只看文字像不像律师，要看依据和复核成本
法律 Agent 的评估，最好围绕这些问题展开：
- •检索到的法源是否相关
- •引用是否真实、准确、可回溯
- •草稿里哪些部分最常被律师改写
- •保密与权限控制是否被触发
- •律师完成终审所需时间是否下降
如果一个系统写得很像律师，但引用经常错、法域经常偏，那它仍然不适合正式使用。
10.三个常见误区
1. 让模型跳过检索直接给法律结论
没有法源支撑的流畅答案，在法律场景里价值非常有限，风险却很高。
2. 把初稿当终稿发出去
无论是合同 redline、研究 memo 还是对外意见，草稿都不应绕过律师终审。
3. 只关注生成速度，不重视保密和引用校验
法律工作对保密、准确和责任链的要求，通常比速度更重要。
11.总结
法律 Agent 真正可交付的价值，不是做一个自动出具法律结论的机器人，而是把原本分散在检索、比对、起草和复核里的工作组织成一条更稳的链路：
- •事项先分型
- •法源先检索
- •草稿只作为待复核产物
- •引用和保密控制前置
- •最终判断和签发仍由律师承担
只要把这些原则守住，Agent 就能成为法律团队的提效工具，而不是制造新型错误和责任不清的风险源。