AI 合同审查 Agent 怎么做？条款抽取、风险标注、版本比对与法务复核

先给结论

AI 合同审查智能体不能替代律师，也不应该直接给最终法律结论。它适合做条款抽取、风险标注、版本差异比对、证据定位和法务复核清单生成，把人工审查从“通读全文”变成“重点复核”。

适合谁读

• 正在做合同审查、条款抽取、版本比对或法务知识库的开发者。
• 需要把 AI 输出绑定到原文条款、页码、证据和人工复核状态的产品负责人。
• 想构建合规辅助工具，但不想让模型直接越权判断的人。

本文解决的问题

• 合同文件如何切分、抽取和保留原文证据。
• 风险条款如何分级，并交给人工复核。
• 版本比对和条款变更如何进入审计记录。
• 如何避免 AI 合同工具变成不受控的法律建议生成器。

[!NOTE] 适用场景：适用于法务合同预审、高风险条款拦截与合规比对。 本文已归档至「文档理解 Agents」专题。若需系统阅读智能体完整路径，请前往：文档理解 Agents。

痛点分析与目标读者

在传统的企业合同审查流程中，法务和业务风控人员常常需要耗费大量时间逐字阅读数十页的文件，以找出潜在的条款风险（例如：单方解除合同不退款、争议解决管辖地位于不利地区、或者自动续约条款未设定提前提醒天数）。对于非标准合同或谈判过程中的多轮修改，人工核对极易因为视觉疲劳漏掉关键的增删字句。

然而，如果盲目迷信大模型并开发一个“一键自动审批合同”的简易 Agent，在实际业务中无异于饮鸩止渴。大模型在面对复杂的复合句和脚注时，极易发生“中间信息丢失（Lost in the Middle）”；如果缺乏物理证据链，AI 输出的风险列表将完全无法被法务人员核实与采纳。

本文适合正在构建 LegalTech（法律科技）系统的全栈开发者、寻求利用 AI 降低法务初筛成本的企业风控总监，以及需要规划高风险业务工作流的企业技术架构师。

AI 合同审查不是替代法务签字

AI 合同审查的价值不是替代法务，而是减少初筛、定位、比对和证据整理成本。

一个生产级的合同审查系统应当将自己定位为“法务的智能放大器”，而不是取代律师最终签字的机器。普通 Demo 往往只做全局文本摘要，然后输出几个模糊的风险建议。真正的工业级方案则要求每一个风险点都有精确的条款原文引用、页码指引，并与公司的标准模板条款进行物理差异标红（Diff Output）。

通过自动识别缺失条款、比对历史版本和定位原文证据，智能体可以减少法务在机械检索与字面比对上的时间，把更多精力留给商务判断和法律风险权衡。到底节省多少时间必须用同类型合同、同一复核标准和真实工时数据测量，不能预设“省 80%”。

推荐架构：从合同上传到法务复核

生产级合同审查智能体必须采用从多模态解析、条款抽取、模板碰撞到版本差分、人工复核的流水线架构。

我们设计的系统推荐流程如下：

1. 多模态解析层（Document Parser）：对上传的扫描 PDF/图片/Word 合同进行解析，执行 OCR 并重建页面物理布局结构。
2. 条款抽取器（Clause Extractor）：按语义层级拆解段落，将合同核心条款提取为强类型的数据对象。
3. 模板比对引擎（Template Matcher）：对照公司的“黄金标准条款库”（Golden Standard），匹配并计算条款偏离度。
4. 风险规则筛查器（Risk Checker）：基于特定的合同类型，利用法务预设的判定规则识别潜在风险。
5. 版本差分层（Version Diff）：比对当前版本与前一版本的物理差异，标注出被偷偷修改或删除的敏感字句。
6. 法务复核看板（Legal Review Dashboard）：可视化展示审查意见草稿、原文证据与偏离对比，挂起至法务人员的待办队列。
7. 审计归档（Audit Log）：记录全套决策 Trace，用于系统迭代和企业内控审计。

文档解析：OCR 只是第一步

OCR 置信度低的页面不能直接进入风险判断，否则可能把识别错误当成法律风险或漏掉关键条款。

在真实的企业环境中，大量合同是以扫描件、拍照传真件或包含大量印章的水印 PDF 形式提交的。如果只是使用开源 OCR 工具简单地从左到右提取字符，分栏排版的表格、侧边栏修订标记以及骑缝章周围的文字就会混在一起，破坏语义的完整性。

我们必须构建布局恢复层：

• 识别表格边界：将合同中的付款计划表、违约金比例表转化为结构化的表格实体（Markdown Tables）。
• 过滤无关噪点：剥离页眉、页脚、页码及签署页上的手写签名噪点，防止干扰条款的提取。
• 记录置信度与解析异常元数据：对低置信度、版面错序、手写批注或表格结构不确定的页面标记 low_confidence_pages，并进入人工核对。阈值不能固定写成 90%；不同 OCR/文档类型的 confidence 语义不同，应使用真实扫描合同做校准，并结合字符/字段级抽样误差判断。

合同类型识别：不同合同风险规则不同

不能用同一套规则审所有合同。NDA、采购合同、SaaS 服务协议、数据处理协议的高风险条款完全不同。

智能体在接收到文档流后，第一步需要对其进行分类（Classifier）。因为销售合同我们重点关注的是收款账期与交付验收，而数据处理协议（DPA）我们核心审查的是数据外泄赔偿上限与欧盟 GDPR 合规性。

系统会识别并标记以下核心分类信息：

{
  "contract_metadata": {
    "contract_type": "SaaS_Service_Agreement",
    "counterparty_name": "某外部云服务商",
    "effective_date": "2026-06-25",
    "term_months": 12,
    "total_amount": 150000.00,
    "currency": "CNY",
    "governing_law": "中华人民共和国法律",
    "jurisdiction": "北京市朝阳区人民法院",
    "renewal_type": "automatic_renewal"
  }
}

识别出正确的合同类型后，下游的风险Checker节点才会动态挂载针对该类合同的专属审计规则集，从而避免误报与漏报。

条款抽取：必须定位到原文

合同审查意见必须能回到原文位置。只输出“存在风险”但没有页码、条款和原文证据，法务无法复核。

为了实现精确的定位，我们不能让大模型自由生成总结，而是要求模型提取出具体的条款结构体。

以下是一个基于 Pydantic 编写的 ClauseExtraction 强类型模型示例：

from pydantic import BaseModel, Field

class ExtractedClause(BaseModel):
    clause_type: str = Field(description="条款语义类别，例如付款周期、保密期限、争议管辖地")
    clause_text: str = Field(description="条款的原始未修改文本片段")
    page_number: int = Field(description="该条款在原始文档中的绝对页码")
    section_title: str = Field(description="该条款所属的章节标题，如‘第七条 违约责任’")
    evidence_sentence: str = Field(description="模型得出风险结论的核心句子证据")
    confidence_score: float = Field(description="模型提取该条款的置信度评分，0.0 到 1.0")

大模型填充完该模型后，系统会用 evidence_sentence 与 OCR 的原始输出进行物理匹配，确保页码与原文是绝对真实的。一旦发现模型编造了不存在的句子，系统会立刻抛出异常，防止幻觉信息误导法务。

标准模板比对：不要只靠模型自由判断风险

风险判断应基于公司模板、法务规则和业务政策，而不是让模型凭经验判断“是否合理”。

许多开发团队在写 Prompt 时，会让大模型“请帮忙找出合同中不合理的条款”。这是一个非常初级的做法。什么是合理？对于小微初创公司，15 天付款账期是合理的；对于大型跨国集团，90 天才符合其财务规则。

因此，审查必须是对照标准条款库进行偏离匹配：

• 提取出的付款账期（如：发票开具后 60 天内付款）。
• 对比公司标准模板（如：发票开具后 30 天内付款）。
• 计算出偏离类型为：延期付款；严重级别为：中等风险；生成推荐修改方向：建议修改回 30 天，或者要求对方支付预付款。

这种基于规则与语义相结合的碰撞，比让模型盲目猜测要可靠得多。

风险标注：每个风险都要有证据链

风险的判定不仅要有结论，更要有推导逻辑与对应的条款原文。

典型的法律风险大类包括：

• 付款风险：未约定发票开具条件直接要求付款。
• 违约责任失衡：我方违约金比例为日千分之一，对方违约金为日万分之一。
• 赔偿限额过低：限制了供应商的最高赔偿额，且该限额低于合同总金额。
• 自动续约：未约定提前多少天通知即可终止续约，导致合同无限期自动续签。

对于每一个判定出的风险，智能体必须将其结构化为带有 business_impact（业务潜在影响）和 evidence_text（原文证据）的风险对象，不允许输出任何悬空的风险结论。

版本比对：合同谈判中最容易漏风险

很多合同风险不是原始条款本身，而是谈判过程中悄悄改掉的关键句子。

在一份合同的生命周期中，业务人员会与对方进行多次邮件往来，频繁改动 Word 文档。在这个多轮谈判流转中，对方可能会发回一个已经“接受所有修订”的干净版本，但私底下却把某个关键数字从 10% 改成了 1%。

为了拦截这一隐蔽欺诈，版本比对（Version Diff）层必须发挥作用。

以下是一个基于 Python 计算两个合同段落物理差异并生成差异标记的示例：

import difflib

def generate_clause_diff(old_text: str, new_text: str) -> str:
    # 模拟对前后两版合同条款进行段落差异比对
    diff_generator = difflib.ndiff(old_text.splitlines(), new_text.splitlines())
    diff_lines = []
    for line in diff_generator:
        # 检测是否包含删除或新增字句
        if line.startswith("- "):
            diff_lines.append(f"[DELETED: {line[2:]}]")
        elif line.startswith("+ "):
            diff_lines.append(f"[ADDED: {line[2:]}]")
        elif line.startswith("  "):
            diff_lines.append(line[2:])
    return "\n".join(diff_lines)

通过这一物理差异分析，任何未经我方确认的私自删改都会在对比报告中被标红展示，帮助法务快速定位。

业务上下文：合同不能脱离项目审查

同一条合同条款，在不同金额、不同客户、不同业务场景下风险等级不同。

一笔金额为 5,000 元人民币的软件测试合同，即便其中有条款写着“发生纠纷时在对方所在地起诉”，对于公司来说，诉讼成本也远远低于重新找律师谈判的商务成本，因此可以被评定为低风险。但如果是涉及 5,000 万元的核心采购合同，同样的管辖地条款就是不可接受的高风险。

因此，智能体在做最终风险评级时，必须通过受控 API 从 ERP、CRM 或 PO 系统中抓取该合同关联的商务背景：

• 供应商的历史评级与合规表现。
• 该合同关联的项目预算以及付款计划的现金流进度。
• 预先核准的业务风险承受阈值。

法务复核：高风险条款必须人在回路 (HITL)

高风险、证据不足或超出企业法务规则边界的合同条款应挂起并进入人工复核队列，智能体只提供决策辅助信息、原文证据和差异说明。

对于会产生法律承诺的审批场景，不应让 Agent 独立拥有“一键同意合同”或直接写入最终 Passed 状态的权限。AI 可以给出低风险/高风险建议，但最终签署、批准和对外发送应按企业授权矩阵进入相应的人工作业或确定性规则门禁。

法务复核看板的设计重点在于高效的数据聚合：左侧展示合同原图或 PDF 渲染图，右侧展示智能体提取出的条款偏离报告，法务可以对 AI 生成的“修改建议”进行一键编辑并复制到最终的修改意见函中。这极大保留了专业人员的终审控制力。

工具权限：合同 Agent 不能直接改合同或发审批

智能体的工具使用权限必须受到严格的分级限制，限制其对敏感业务的直接写操作。

为了保障内部控制合规，我们为智能体定义了清晰的权限分级：

• 低风险只读工具（可自主调用）：读取合同 PDF、匹配标准模版、查询历史版本。
• 中风险受控写入工具（可调用，但生成结果需法务质检）：生成带修订痕迹的 CLM 建议文档、创建法务部内部备注标签。
• 高风险物理动作（严禁 Agent 自主调用，必须通过人工网关授权）：对外发送合同修改稿给外部供应商、在企业审批流中对合同执行批准操作、触发数字证书签署接口。

这一权限边界能显著减少模型直接触发法律承诺或外部写操作的风险，但不能替代审批系统本身的 RBAC、审计、双人复核和异常处理。

审计日志：合同审查必须可追踪

合同审查系统应保留足以复盘决策的版本、证据、工具事件和人工修改记录；具体保留字段、保留期和审计要求应由企业内控、法务与适用监管共同确定。

Trace 可以写入 ClickHouse 或其他审计存储，但 ClickHouse 本身不等于“不可篡改”。如果业务要求 tamper-evident / append-only 证据，还需要对象锁/WORM、签名或哈希链、访问控制、备份与独立审计等机制。发生争议时，审计人员应能调取：

• 审查当时所使用的 Prompt 模板版本以及底层推理大模型的具体指纹参数。
• 针对每一项偏离，Agent 提取出的 evidence_sentence 原文行号证据。
• 法务复核人员在修改 AI 生成的意见时所做的具体改动日志。

这不仅可以为内控检查提供详实的物理链路凭证，也能作为系统后期微调 Prompts 的真实数据集来源。

评估指标

我们建立了一套量化评估体系，用于持续监控 AI 合同审查辅助系统的表现：

指标名称	类型	解释	如何设门槛
clause_extraction_precision / recall	技术	核心条款类型与原文范围是否抽取正确	在按合同类型分层的人工金标准集上建立基线；高风险条款优先看 recall
missed_risk_rate	技术	已标注高风险条款未被系统提示的比例	按风险等级单独统计，并由法务定义不可接受的漏报类型；不要假设可以做到绝对 0%
false_alarm_rate	技术	正常条款被错误标成风险的比例	与人工复核容量一起校准，防止告警疲劳
ocr_parse_error_rate	技术	OCR/布局解析造成字段或原文错误的比例	按扫描件、电子 PDF、表格/手写等文档类型分层统计
contract_review_cycle_time	业务	从上传到法务完成复核的实际周期	与同类合同人工基线比较，不预设固定 65% 降幅
manual_override_rate	业务	法务修改/否决 AI 风险判断的比例	用于发现规则或模型漂移，不设置通用“低于 8%”目标

最小可上线版本（MVP）实施路径

在冷启动阶段，我们建议开发团队限制使用场景，走增量上线路线：

• 第一阶段（聚焦单一类型）：仅支持标准的中英文保密协议（NDA）和标准的采购框架协议审查。
• 第二阶段（只读审查）：不开启任何自动生成修订稿（Redline）的写入工具，仅在界面上为法务提示缺失条款和管辖地偏离。
• 第三阶段（版本比对）：加入 difflib 段落差分能力，并在系统中全量透传 Trace ID，开启全链条审计日志。

生产环境常见坑与排错指南

合同审查系统常见的失败点包括：复杂版面造成条款顺序错乱、关键风险藏在非典型章节，以及模型输出被错误当成最终法律判断。下面只把这类问题作为可复现的测试场景，不把示例日志冒充真实生产事故。

1. 双栏排版合同样本导致段落提取顺序错乱

• 常见现象：一些标准合采用左右双栏排版。初级 OCR 提取时会横向跨栏提取字符，导致左栏的段落与右栏的段落被拼接在同一行，破坏了条款的语义。
• 报错文本：

[ERROR] 2026-05-11T12:00:05.123Z - LayoutExtractionException: Row merging detected in column split zones page 12. Text ordering corrupted. Clause matcher bypassed.

• 解决方案：必须引入基于 YOLO 等视觉布局检测模型的物理列边界划分，在 OCR 前将页面切分为左右独立的物理文本区块，再分别进行字符提取。

2. 条款过于隐蔽导致关键“自动续期”风险漏报

• 常见现象：合同没有独立的“自动续期”章节，而是将“合同到期前 30 天未提出书面异议则自动延长一年”写在“第十二条 杂项条款”的最后一句，导致模型因为上下文过长漏掉了该信息。
• 报错文本：

[WARN] 2026-05-11T12:05:44.892Z - MissedRuleDetection: Term clause matches standard '12 months' but failed to parse automatic_renewal tag hidden in miscellaneous text block on page 34.

• 解决方案：在条款提取阶段，对于涉及期限（Term）、终止（Termination）和杂项（Miscellaneous）章节的文本，大模型必须进行多轮循环扫描，或者使用针对法律领域微调的专用分类小模型进行二次召回。

方案对比表

对标维度	XBSTACK 自研合同辅助系统	商业 CLM 系统的 AI 插件	传统人工手动审查
条款规则自定义	自建方案可直接接企业自己的规则库、模板和 Prompt，但需要自行维护版本与测试	取决于 SaaS 产品开放的规则/模板配置能力	人工规则最灵活，但一致性取决于流程与审查人员
原文证据链定位	可以把页码、段落 ID、原文片段做成强制输出字段；准确性仍需对解析结果回验	能力因产品而异，应实际验证是否提供页码/原文引用	人工可以直接圈选原文，但也需要版本和审计记录
多语言处理	可按选定模型/翻译流程处理多语言，但法律语义仍需要对应语言能力的法务复核	能力、语言覆盖和数据处理方式因供应商而异	依赖团队语言能力或专业翻译资源
企业私有数据边界	可部署在内网/VPC，并自行控制模型、日志与存储；仍需审计备份、管理员权限、OCR/模型调用和远程访问	需按 SaaS 供应商的数据处理、区域、保留期和子处理方评估	文档可留在本地流程中，但人员、邮件、共享盘与终端设备仍构成泄露面

常见问题解答

扫描件中有手写的修改批注，AI 合同审查智能体如何处理？

当解析层检测到手写笔迹或非打印字符时，可以把这些区域单独裁剪并交给 OCR/VLM 转写，同时保留原图坐标供法务回看。是否进入人工复核不应写死为 confidence < 75；应根据所用模型的置信度定义、手写样本验证结果和该批注的法律重要性共同决定。涉及修改法律义务的手写批注应优先人工确认。

如果合同中的争议解决条款包含了多个管辖法院，系统如何评定风险？

系统会使用 Pydantic 抽取出管辖地法院列表，然后对比公司法务部预设的白名单（如：我方所在地法院）和黑名单（如：对方所在地法院）。如果出现黑白名单混合或管辖地指代不明（例如“由守约方所在地法院管辖”），智能体会判定为中高风险，并在审查意见中指出该表述容易在发生纠纷时引发诉讼管辖权争议，建议修改为唯一的确定性管辖法院。

大合同处理中，如何解决大模型上下文窗口“中间信息丢失”的经典问题？

不建议把长合同不加结构地一次性塞给模型做风险审查。更稳妥的是按章节、条款和页面布局形成可定位 chunk，先做局部条款抽取，再把结构化结果汇总到全局规则检查。4000 token 可以作为某个模型/任务的示例起点，但不是通用切块标准；chunk 大小要根据条款完整性、模型上下文、召回测试和跨段依赖来调。

延伸阅读

• AI Agent 架构：构建自主智能体系统的 5 个核心模块
• AI Agent Tool Use 实战：工具注册、权限控制、参数校验与调用审计
• AI Agent Planning 实战：从任务分解到动态修正的工程实现
• AI Agent Observability 实战：Trace、Tool Call、状态、成本与质量监控体系
• AI Agent Evaluation 实战：任务成功率、工具调用、失败恢复与回归测试体系
• AI Agent Deployment 实战：任务队列、状态持久化、模型路由与高并发部署
• AI 供应商管理智能体实战：供应商准入、采购合规、ERP 对接与审计闭环
• AI Agent 框架选型指南：LangChain / LangGraph、AutoGen、CrewAI 如何用于生产系统？
• AI Agent 全栈指南 2026：从架构、工具调用到评估部署的生产化路线图

生产化防守与安全风险控制

在将该智能体部署到真实生产环境时，小白建议必须硬编码以下物理防御机制，防止模型幻觉引发系统灾难：

• 「权限隔离限制」：该 Agent 仅被赋予最小可行性 API 权限。所有写操作必须物理隔离在独立沙箱中进行，禁止赋予直接执行 SQL 的权限。
• 「双重审批拦截」：对高危业务决策（如确认付款、删除文件、自动提交代码）强制接入 Human-in-the-loop 人机协同机制，非物理人类复核不可越权通过。
• 「全面审计日志」：保留所有工具调用的入参、出参和模型的推理轨迹（Trace Log），在系统发生行为抖动时提供充足的对账凭证。
• 「任务循环限额」：硬编码限制模型单次任务的最大循环轮次（如限制为 10 轮），防止模型在工具报错时陷入无限震荡死循环导致 Token 额度耗光。

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作，让每篇文章都回到明确的主题主页面。

进入 AI Agent 专题 → 查看架构指南 订阅