律所合同审查 Agent 实战：84 页 PDF 拆成 7 类风险点

去年 11 月，朋友介绍一家律所找我。规模不大，60 来个律师，主做公司并购和涉外合规。他们老合伙人开口就是：「我们一天要审 14 份合同，长的 80 多页，主审律师看完一份脑子就空了。你看 AI 能不能帮一把。」

我先去他们办公室蹲了三天，拿了 200 份历史合同样本。看完之后发现问题不是「读不读得懂」，而是优先级——律师不怕条款多，怕漏掉一个藏在第 73 页的单方解除权。

下面是我做这个系统的完整复盘，包括那个差点让我翻车的 187K token 事故。

甲方到底要什么：不是摘要，是风险矩阵

第一次对焦需求我差点走偏。我以为他们要的是「合同摘要」，做了个 demo 过去，合伙人扫了一眼说：「这个没用，摘要我实习生也能写。」

真实需求是这样的：

• 每份合同审完，给出7 类风险点的分布矩阵（付款条款、违约责任、知识产权归属、保密范围、争议解决、单方变更/解除、限制性条款）
• 每个风险点必须引用原文具体条款号，不能只说「存在单方解除风险」
• 风险分级要可量化（高/中/低），并给出律师动作建议（谈判让步 / 修改话术 / 可接受）

这就完全不是摘要问题了，这是分类 + 结构化抽取 + 归因推理的混合任务。

架构：OCR 兜底 + 条款分段 + 多路并行

整体流水线是这样的，我尽量写得具体点：

1. 入口：PDF 上传到 S3，Lambda 触发
2. OCR 兜底：Textract 先识别。扫描版合同占比大概 34%，直接跳过会丢文本
3. 条款分段：自己写了个正则 + Claude Haiku 双校验的分段器，按「第 X 条」「Article X」切分，平均一份合同切出 180-240 段
4. 7 类分类器：每段丢给 Haiku，返回 0-7 的 label（0 = 无风险相关）。这一步过滤掉 70% 左右的常规条款
5. 风险分析：剩下的条款按类别分组，喂给 Sonnet 做逐条分析，输出结构化 JSON
6. 矩阵汇总：最后把 7 类结果拼成一张风险矩阵 PDF，附律师动作建议

我在输出结构化这块专门参考了 Prompt 输出 JSON Schema 的工程实践，schema 约束配合 Claude 的 tool use 稳定性比纯 prompt 强太多。

那个 187K token 的事故

上线第二天就炸了。

有份并购合同是扫描版 + 手写批注 + 附件一起打包的 PDF，84 页。OCR 跑完之后文本膨胀到 187K token。我第一版流水线是整篇丢给 Sonnet做分段的，结果触发了 context 上限，Claude 直接返回 input too long 报错。当时我盯着 Sentry 上的 error trace 懵了十几秒——测试样本里最大才 52 页。

后来改方案，把分段挪到前置流程，不让 Sonnet 吃整篇：

• 用 Haiku 按物理页 + 条款标题做粗切
• 切完的段落单独进风险分析，每次调用输入控制在 4K token 以内
• 整篇的「全局上下文」（当事方、标的金额、合同性质）单独抽取一次，缓存下来，每次调用时注入

这个思路其实就是 context 预算管理，我之前也写过 Context Window 预算分配策略 这篇文章，里面讲得更系统。

改完之后那份 84 页合同处理时长从「直接失败」变成 6 分 23 秒，token 消耗从爆表降到 94K 总输入（拆成 23 次调用）。

Hallucination 是律所最在意的事

合伙人跟我反复强调：宁可漏报，不能乱编。律师最怕的就是 AI 说「第 14 条存在单方解除风险」，结果第 14 条压根不是那个意思。

我做了三层防护：

第一层：强制原文引用。每条风险结论必须包含 original_clause_text 字段，且文本长度 ≥ 20 字符。后处理时做字符串匹配，匹配不上的结论直接丢弃。这一条拦掉了大概 4.2% 的 hallucination。

第二层：双模型交叉验证。高风险条款会再让 Sonnet 用不同 prompt 验证一次，两次结论不一致的打上 needs_review flag。这里用到的思路跟 Chain of Thought vs Direct 回答 有关，验证链用 CoT，主链用 direct output，结果稳定性更好。

第三层：律师反馈回流。律师审完会在系统里点「确认/修正/误报」，这些数据每周回流一次，用来优化 prompt 的 few-shot 例子。上线三个月误报率从 11.8% 降到 3.4%。

成本账

实打实的账单，2026 年 3 月的数据：

• 当月处理合同 387 份
• 总账单 $182.47（含 OCR）
• 平均单份 $0.47
• 其中 Haiku 分类占 $0.11，Sonnet 分析占 $0.29，OCR 占 $0.07

我之前试过纯 Sonnet 方案，单份 $1.62，直接贵了三倍半。分层路由的价值这里特别明显，具体设计思路我写过 多模型路由降本实战。

另外有个小优化挺关键的：prompt caching。7 类风险分类器的 system prompt 是固定的 2.1K token，caching 之后每次调用省 87% 的 prompt 成本。这个我在 Prompt Caching 深度指南 里讲过配置细节。

律师的真实反馈

上线 4 个月，主审律师平均审查时长从 47 分 12 秒降到 8 分 10 秒（他们自己打卡系统拉的数据）。但合伙人跟我说了一句让我印象深的话：「快不是最关键的，最关键的是年轻律师不会漏条款了。」

原来他们有个痛点我没想到：应届律师经验不足，容易漏掉隐藏条款。有了 Agent 托底之后，年轻律师可以把精力放在谈判策略上，不用再花两小时通读合同。

还没解决的问题

• 多语言合同：中英混合的还行，但纯日文、德文合同准确率只有 73% 左右
• 附件链合同：主合同引用了 SOW、SLA、MSA 好几份子合同的，跨文档关联还没做好
• 方言性表达：香港律所发来的合同有些粤语化表达，分类器经常蒙圈

这些是 Q2 要继续啃的。