智能法律合同审查Agent系统【附带源码】

在商业合作中，合同审查是法律风控的核心环节，但纯人工模式面临耗时费力、标准不一、遗漏风险等痛点，尤其在合同数量激增时，法务团队极易陷入疏漏危机。伴随大语言模型与法律知识图谱技术的突破，智能法律合同审查Agent应运而生。它能深度理解合同语义，自动比对条款、识别缺失要素与高风险内容，并生成修改建议。其核心价值在于：将审查周期从天级压缩至分钟级，释放人力；统一标准，精准风控。

作者：百度智能云 谭文涛

一、系统总体架构

┌─────────────────────────────────────────────────────────────────┐ │ 合同审查协同环境 │ │ │ │ ┌──────────────┐ │ │ │ 合同解析 │ │ │ │ Agent │ │ │ │ (分段+结构化) │ │ │ └──────┬───────┘ │ │ │ │ │ ┌────────────────┼────────────────┐ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ 合规审查 │ │ 风险识别 │ │ 条款对比 │ │ │ │ Agent │ │ Agent │ │ Agent │ │ │ │ (法规匹配) │ │ (不利条款) │ │ (模板差异) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ │ └────────────────┼─────────────────┘ │ │ ▼ │ │ ┌──────────────┐ │ │ │ 审查报告 │ │ │ │ 生成Agent │ │ │ │ (汇总+建议) │ │ │ └──────────────┘ │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ 规则引擎 │ │ 千帆LLM │ │ 本地数据 │ │ │ │ (硬约束) │ │ (智能审查) │ │ (法规/模板) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ └─────────────────────────────────────────────────────────────────┘

协作模式：并行 Fan-out → 汇聚

核心理念：

• 合同解析必须先于审查（结构化后传给三个审查Agent，避免重复解析）

• 合规/风险/对比三个维度互不依赖，可并行执行，总耗时≈单路

• 双层决策：规则引擎兜底 + LLM增强

双层决策架构

层级	执行者	职责	特点
Layer 1	规则引擎	关键词匹配、格式检查、缺失检测	100%确定性，不经过LLM
Layer 2	千帆LLM	语义理解、法规匹配、风险判断	推理能力，失败自动降级到规则引擎

二、Agent角色定义

1. 合同解析Agent（ParseAgent）

• 职责

  ：将合同全文按条款分段，提取关键要素

• LLM调用

  ：2次（分段 + 结构化提取）

• 输入

  ：合同全文（string）

• 输出

  ：ParsedContract（JSON结构）

• 降级策略

  ：正则分段 + 关键词分类

2. 合规审查Agent（ComplianceAgent）

• 职责

  ：逐条款匹配相关法规，标注合规/不合规/待确认

• LLM调用

  ：N次（N=条款数），每条款一次

• 输入

  ：ParsedContract

• 输出

  ：list[ComplianceResult]

• 外部工具

  ：本地法规检索（regulations.json）

3. 风险识别Agent（RiskAgent）

• 职责

  ：识别不利条款、模糊表述、缺失条款、不对等条款

• LLM调用

  ：1次（整合同+风险判断）

• 输入

  ：ParsedContract

• 输出

  ：list[RiskItem]

4. 条款对比Agent（CompareAgent）

• 职责

  ：与标准合同模板逐条对比，标注偏离项

• LLM调用

  ：1次（模板+合同对比）

• 输入

  ：ParsedContract

• 输出

  ：list[DeviationItem]

• 外部工具

  ：本地标准模板库（template.json）

5. 报告生成Agent（ReportAgent）

• 职责

  ：汇聚三方审查结果，生成分级审查报告

• LLM调用

  ：1次

• 输入

  ：ParsedContract + 三方结果

• 输出

  ：ReviewReport

三、数据流与JSON格式

3.1 合同解析结果（Phase 1 → Phase 2）

{ "contract_title": "技术服务合同", "parties": [ {"role": "甲方", "name": "华创科技有限公司", "legal_rep": "张明", "address": "北京市海淀区..."}, {"role": "乙方", "name": "智联信息技术有限公司", "legal_rep": "李华", "address": "上海市浦东新区..."} ], "clauses": [ {"clause_id": "C01", "clause_type": "期限/时效", "title": "合同期限", "content": "...", "position": 1}, {"clause_id": "C02", "clause_type": "金额/价款", "title": "服务费用", "content": "...", "position": 2} ], "key_elements": { "contract_amount": "¥1,000,000", "contract_period": "2年", "breach_penalty": "千分之五/千分之一", "dispute_resolution": "诉讼/仲裁", "has_confidentiality": true, "has_force_majeure": false, "ip_ownership": "归甲方所有" } }

3.2 合规审查结果（Phase 2）

[ { "clause_id": "C05", "clause_title": "违约责任", "status": "不合规", "risk_level": "MEDIUM", "regulation_ref": "中华人民共和国民法典", "regulation_article": "第五百八十五条", "reason": "甲乙方违约金比例不对等（甲方千分之五 vs 乙方千分之一）", "suggestion": "建议统一违约金比例，或按实际损失赔偿" } ]

3.3 风险识别结果（Phase 2）

[ { "clause_id": "C07", "clause_title": "合同解除", "risk_type": "不对等条款", "risk_level": "HIGH", "description": "甲方可随时单方面解除，乙方不得解除", "impact": "乙方处于被动地位，随时可能被终止合同", "suggestion": "建议对等约定双方解除条件" }, { "clause_id": "MISSING", "clause_title": "不可抗力条款", "risk_type": "缺失条款", "risk_level": "MEDIUM", "description": "合同缺少不可抗力条款", "impact": "遭遇不可抗力时无法免责", "suggestion": "建议增加不可抗力条款" } ]

3.4 条款对比结果（Phase 2）

[ { "clause_id": "C03", "clause_title": "服务内容与标准", "template_content": "乙方应按照合同约定的时间、质量和标准交付服务成果...", "contract_content": "服务质量应达到行业标准，满足甲方合理需求", "deviation_type": "修改", "risk_level": "MEDIUM", "analysis": "合同使用'行业标准'和'合理需求'等模糊表述，缺乏具体量化标准" } ]

四、各Agent核心提示词推导

4.1 合同解析Agent提示词推导

推导思路：解析是最上游环节，需要"分步走"策略，因为一次性让LLM完成"分段+分类+要素提取"三件事容易出错。

推导过程：

1. 第一步：条款分段

• 输入：合同全文（可能很长）

• 核心指令：每个独立条款作为一条 + 分配编号 + 识别类型 + 保留原文

• 关键约束：忠实原文，不做任何修改或概括

• 输出格式：条款列表JSON

2. 第二步：关键要素提取

• 输入：第一步产出的条款列表

• 核心指令：从条款中抽取10项关键要素

• 关键约束：要素必须从原文中提取，不推断

• 输出格式：甲乙方信息 + key_elements字典

系统提示词核心要素：

角色：法律合同解析专家 原则：忠实原文 / 精准分段 / 分类准确 / 关键要素提取 输出：严格JSON

4.2 合规审查Agent提示词推导

推导思路：合规审查需要"法规依据"作为硬约束，每个判定必须关联具体法律条文。逐条款审查而非整合同一次，因为需要精确到条款级别的法规匹配。

推导过程：

1. 法规检索

   ：根据条款类型，从法规库中检索相关条目

2. 逐条审查

   ：每条款一次LLM调用，输入条款+法规+合同要素

3. 分级标注

   ：合规/不合规/待确认 × HIGH/MEDIUM/LOW

系统提示词核心要素：

角色：法律合规审查专家 原则：法规依据 / 严格标注 / 风险分级 / 修改建议 判定标准：合规→✅ / 违反强制规定→🔴HIGH / 合规风险→🟡MEDIUM / 轻微→🟢LOW 输出：每条款一个JSON（状态+风险+法规+理由+建议）

Prompt设计关键决策：为什么逐条款而非整合同？

• 法规匹配需要精确对应，整合同一次调用容易遗漏

• 条款数量通常5-15条，LLM调用次数可控

• 逐条款结果更结构化，便于报告生成

4.3 风险识别Agent提示词推导

推导思路：风险识别需要"全局视角"，必须看到合同全貌才能判断权利义务对等性、条款缺失等问题。因此采用"整合同一次"策略。

推导过程：

1. 四类风险

   ：不利条款 / 模糊表述 / 缺失条款 / 不对等条款

2. 七维评估

   ：权利义务对等性 / 违约责任对称性 / 付款交付公平性 / 保密知识产权 / 争议解决中立性 / 终止解除公平性 / 期限时效合理性

3. 缺失清单

   ：将常见缺失条款显式列出，让LLM对照检查

系统提示词核心要素：

角色：合同风险评估专家 风险类型：不利条款/模糊表述/缺失条款/不对等条款 评估维度：7个维度 缺失清单：10项常见缺失检查项 输出：risk_items数组

Prompt设计关键决策：为什么整合同一次而非逐条款？

• 风险评估需要全局对比（如"甲乙方违约金不对等"需要同时看到双方条款）

• 缺失条款检测需要知道合同有什么、缺什么

• 整合同一次调用效率更高

4.4 条款对比Agent提示词推导

推导思路：对比需要同时看到合同和模板，让LLM自行匹配和比较。偏离分类（缺失/修改/新增）是核心输出。

推导过程：

1. 偏离分类

   ：缺失 / 修改 / 新增

2. 风险分级

   ：根据偏离程度和影响

3. 模板参考

   ：将标准模板条款完整提供给LLM

系统提示词核心要素：

角色：合同条款对比分析专家 偏离类型：缺失/修改/新增 评估维度：完整性/一致性/偏离程度/新增影响 输出：deviation_items数组

4.5 报告生成Agent提示词推导

推导思路：报告生成是汇聚环节，需要将三方结果"融会贯通"，而非简单拼接。核心是综合风险等级判定和优先级排序。

推导过程：

1. 风险聚合

   ：综合三方结果判定整体风险

2. 摘要提炼

   ：3-5句话概括核心发现

3. 建议排序

   ：按紧急程度排列，最多5条

系统提示词核心要素：

角色：合同审查报告撰写专家 原则：客观汇总/分级呈现/突出重点/建议可操作 报告结构：摘要→合规→风险→对比→建议 综合风险规则：有HIGH→HIGH / 2+MEDIUM→MEDIUM / 1MEDIUM→LOW / 全COMPLIANT→COMPLIANT 输出：overall_risk_level + summary + recommendations

五、技术实现方案

技术栈

• 语言

  ：Python 3.10+

• Agent框架

  ：基于原生Python + asyncio实现（零依赖，便于教学理解）

• LLM调用

  ：百度千帆API（ernie-x1-turbo-32k）

• 并行执行

  ：asyncio.gather（Fan-out阶段三路并行）

• 数据格式

  ：JSON（Agent间数据传递）

项目结构

contract-review-mas/ ├── design.md # 本设计文档 ├── main.py # 主入口 ├── config.py # 配置 ├── core/ │ ├── __init__.py │ ├── llm_client.py # LLM调用封装 │ └── orchestrator.py # 主控编排器（Fan-out/Gather） ├── agents/ │ ├── __init__.py │ ├── base_agent.py # Agent基类 │ ├── parse_agent.py # 合同解析Agent │ ├── compliance_agent.py # 合规审查Agent │ ├── risk_agent.py # 风险识别Agent │ ├── compare_agent.py # 条款对比Agent │ └── report_agent.py # 报告生成Agent ├── models/ │ ├── __init__.py │ └── domain.py # 领域模型 ├── data/ │ ├── sample_contract.txt # 示例合同 │ ├── regulations.json # 法规库 │ └── template.json # 标准合同模板 ├── prompts/ │ ├── parse_agent.md # 解析Agent提示词 │ ├── compliance_agent.md # 合规Agent提示词 │ ├── risk_agent.md # 风险Agent提示词 │ ├── compare_agent.md # 对比Agent提示词 │ └── report_agent.md # 报告Agent提示词 └── output/ # 审查报告输出目录

运行方式

# 规则引擎模式（零依赖，开箱即用） python3 main.py # LLM模式（需要千帆API密钥） python3 main.py --llm # 自定义合同 python3 main.py --file my_contract.txt python3 main.py --llm --file my_contract.txt

六、Agent间数据传递规范

ParseAgent ──(ParsedContract JSON)──→ [Fan-out] ├── ComplianceAgent ──(list[ComplianceResult]) ├── RiskAgent ────────(list[RiskItem]) └── CompareAgent ────(list[DeviationItem]) │ [Gather] ──────┘ │ ▼ ReportAgent │ ▼ ReviewReport

关键约束：

• Phase 1 → Phase 2：ParsedContract对象直接传递（内存引用，非序列化）

• Phase 2 并行三路：共享同一个ParsedContract（只读）

• Phase 2 → Phase 3：三方结果列表直接传递

• 所有JSON序列化仅用于LLM Prompt构建和最终报告存储

七、LLM调用统计

Agent	调用次数	调用策略	降级方案
ParseAgent	2次	分段1次 + 提取1次	正则分段 + 关键词提取
ComplianceAgent	N次	每条款1次	规则引擎检查
RiskAgent	1次	整合同1次	规则引擎识别
CompareAgent	1次	整合同+模板1次	类型匹配+文本相似度
ReportAgent	1次	三方结果1次	规则汇总
总计	5+N次	N=条款数	—

八、设计要点与决策记录

8.1 为什么解析先行而非三路都独立解析？

• 避免重复解析，节省LLM调用

• 结构化结果可被三方共享，保证一致性

• 解析只需一次，后续审查都基于同一份结构化数据

8.2 为什么合规审查逐条款，风险识别整合同？

• 合规审查需要精确的法规条款匹配，逐条更准确

• 风险识别需要全局视角（如对等性判断），整合同更有效

8.3 为什么每个Agent都有规则引擎Fallback？

• 教学演示：即使没有LLM也能跑通完整流程

• 生产安全：LLM故障时系统不宕机

• 成本控制：开发测试阶段可零成本运行

8.4 分级输出的设计哲学

• 🔴 HIGH

  → 必须修改才能签署

• 🟡 MEDIUM

  → 建议修改，否则有风险

• 🟢 LOW

  → 可签署但需关注

• ✅ COMPLIANT

  → 无需修改

8.5 示例合同的"陷阱"设计

示例合同故意埋入以下问题，验证系统能否检出：

1. 第七条

   ：甲方可"随时单方面解除"，乙方"非经同意不得解除" → 不对等条款

2. 第五条

   ：甲方违约金千分之五 vs 乙方千分之一 → 违约责任不对等

3. 第八条

   ："或裁或审" → 无效条款

4. 缺少不可抗力条款

   → 缺失条款

5. 第三条

   ："行业标准"、"合理需求" → 模糊表述

6. 第七条第3款

   ：合同解除后乙方返还全部费用 → 不公平

九、项目源码

源码请查看改文章绑定资源包