夜雨聆风
智能法律合同审查Agent系统【附带源码】
一、系统总体架构
┌─────────────────────────────────────────────────────────────────┐
│ 合同审查协同环境 │
│ │
│ ┌──────────────┐ │
│ │ 合同解析 │ │
│ │ Agent │ │
│ │ (分段+结构化) │ │
│ └──────┬───────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 合规审查 │ │ 风险识别 │ │ 条款对比 │ │
│ │ Agent │ │ Agent │ │ Agent │ │
│ │ (法规匹配) │ │ (不利条款) │ │ (模板差异) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └────────────────┼─────────────────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 审查报告 │ │
│ │ 生成Agent │ │
│ │ (汇总+建议) │ │
│ └──────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 规则引擎 │ │ 千帆LLM │ │ 本地数据 │ │
│ │ (硬约束) │ │ (智能审查) │ │ (法规/模板) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────┘协作模式：并行 Fan-out → 汇聚
核心理念：
-
合同解析必须先于审查（结构化后传给三个审查Agent，避免重复解析） -
合规/风险/对比三个维度互不依赖，可并行执行，总耗时≈单路 -
双层决策：规则引擎兜底 + LLM增强
双层决策架构
|
|
|
|
|
|---|---|---|---|
| Layer 1 |
|
|
|
| Layer 2 |
|
|
|
二、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字典
系统提示词核心要素：
角色：法律合同解析专家
原则：忠实原文 / 精准分段 / 分类准确 / 关键要素提取
输出：严格JSON4.2 合规审查Agent提示词推导
推导思路：合规审查需要”法规依据”作为硬约束，每个判定必须关联具体法律条文。逐条款审查而非整合同一次，因为需要精确到条款级别的法规匹配。
推导过程：
- 法规检索
：根据条款类型，从法规库中检索相关条目 - 逐条审查
：每条款一次LLM调用，输入条款+法规+合同要素 - 分级标注
：合规/不合规/待确认 × HIGH/MEDIUM/LOW
系统提示词核心要素：
角色：法律合规审查专家
原则：法规依据 / 严格标注 / 风险分级 / 修改建议
判定标准：合规→✅ / 违反强制规定→🔴HIGH / 合规风险→🟡MEDIUM / 轻微→🟢LOW
输出：每条款一个JSON（状态+风险+法规+理由+建议）Prompt设计关键决策：为什么逐条款而非整合同？
-
法规匹配需要精确对应，整合同一次调用容易遗漏 -
条款数量通常5-15条，LLM调用次数可控 -
逐条款结果更结构化，便于报告生成
4.3 风险识别Agent提示词推导
推导思路：风险识别需要”全局视角”，必须看到合同全貌才能判断权利义务对等性、条款缺失等问题。因此采用”整合同一次”策略。
推导过程：
- 四类风险
：不利条款 / 模糊表述 / 缺失条款 / 不对等条款 - 七维评估
：权利义务对等性 / 违约责任对称性 / 付款交付公平性 / 保密知识产权 / 争议解决中立性 / 终止解除公平性 / 期限时效合理性 - 缺失清单
：将常见缺失条款显式列出，让LLM对照检查
系统提示词核心要素：
角色：合同风险评估专家
风险类型：不利条款/模糊表述/缺失条款/不对等条款
评估维度：7个维度
缺失清单：10项常见缺失检查项
输出：risk_items数组Prompt设计关键决策：为什么整合同一次而非逐条款？
-
风险评估需要全局对比（如”甲乙方违约金不对等”需要同时看到双方条款） -
缺失条款检测需要知道合同有什么、缺什么 -
整合同一次调用效率更高
4.4 条款对比Agent提示词推导
推导思路：对比需要同时看到合同和模板，让LLM自行匹配和比较。偏离分类（缺失/修改/新增）是核心输出。
推导过程：
- 偏离分类
：缺失 / 修改 / 新增 - 风险分级
：根据偏离程度和影响 - 模板参考
：将标准模板条款完整提供给LLM
系统提示词核心要素：
角色：合同条款对比分析专家
偏离类型：缺失/修改/新增
评估维度：完整性/一致性/偏离程度/新增影响
输出：deviation_items数组4.5 报告生成Agent提示词推导
推导思路：报告生成是汇聚环节，需要将三方结果”融会贯通”，而非简单拼接。核心是综合风险等级判定和优先级排序。
推导过程：
- 风险聚合
：综合三方结果判定整体风险 - 摘要提炼
：3-5句话概括核心发现 - 建议排序
：按紧急程度排列，最多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调用统计
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 总计 | 5+N次 |
|
|
八、设计要点与决策记录
8.1 为什么解析先行而非三路都独立解析？
-
避免重复解析，节省LLM调用 -
结构化结果可被三方共享，保证一致性 -
解析只需一次，后续审查都基于同一份结构化数据
8.2 为什么合规审查逐条款，风险识别整合同？
-
合规审查需要精确的法规条款匹配，逐条更准确 -
风险识别需要全局视角（如对等性判断），整合同更有效
8.3 为什么每个Agent都有规则引擎Fallback？
-
教学演示：即使没有LLM也能跑通完整流程 -
生产安全：LLM故障时系统不宕机 -
成本控制：开发测试阶段可零成本运行
8.4 分级输出的设计哲学
- 🔴 HIGH
→ 必须修改才能签署 - 🟡 MEDIUM
→ 建议修改，否则有风险 - 🟢 LOW
→ 可签署但需关注 - ✅ COMPLIANT
→ 无需修改
8.5 示例合同的”陷阱”设计
示例合同故意埋入以下问题，验证系统能否检出：
- 第七条
：甲方可”随时单方面解除”，乙方”非经同意不得解除” → 不对等条款 - 第五条
：甲方违约金千分之五 vs 乙方千分之一 → 违约责任不对等 - 第八条
：”或裁或审” → 无效条款 - 缺少不可抗力条款
→ 缺失条款 - 第三条
：”行业标准”、”合理需求” → 模糊表述 - 第七条第3款
：合同解除后乙方返还全部费用 → 不公平
通过网盘分享的文件：contract-review-mas-v2.zip
链接: https://pan.baidu.com/s/1hHqA2Tz_oePUPqeYrSAZXA?pwd=9m7t 提取码: 9m7t
–来自百度网盘超级会员v4的分享