在商业合作中合同审查是法律风控的核心环节但纯人工模式面临耗时费力、标准不一、遗漏风险等痛点尤其在合同数量激增时法务团队极易陷入疏漏危机。伴随大语言模型与法律知识图谱技术的突破智能法律合同审查Agent应运而生。它能深度理解合同语义自动比对条款、识别缺失要素与高风险内容并生成修改建议。其核心价值在于将审查周期从天级压缩至分钟级释放人力统一标准精准风控。作者百度智能云 谭文涛一、系统总体架构┌─────────────────────────────────────────────────────────────────┐ │ 合同审查协同环境 │ │ │ │ ┌──────────────┐ │ │ │ 合同解析 │ │ │ │ Agent │ │ │ │ (分段结构化) │ │ │ └──────┬───────┘ │ │ │ │ │ ┌────────────────┼────────────────┐ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ 合规审查 │ │ 风险识别 │ │ 条款对比 │ │ │ │ Agent │ │ Agent │ │ Agent │ │ │ │ (法规匹配) │ │ (不利条款) │ │ (模板差异) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ │ └────────────────┼─────────────────┘ │ │ ▼ │ │ ┌──────────────┐ │ │ │ 审查报告 │ │ │ │ 生成Agent │ │ │ │ (汇总建议) │ │ │ └──────────────┘ │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ 规则引擎 │ │ 千帆LLM │ │ 本地数据 │ │ │ │ (硬约束) │ │ (智能审查) │ │ (法规/模板) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ └─────────────────────────────────────────────────────────────────┘协作模式并行 Fan-out → 汇聚核心理念合同解析必须先于审查结构化后传给三个审查Agent避免重复解析合规/风险/对比三个维度互不依赖可并行执行总耗时≈单路双层决策规则引擎兜底 LLM增强双层决策架构层级执行者职责特点Layer 1规则引擎关键词匹配、格式检查、缺失检测100%确定性不经过LLMLayer 2千帆LLM语义理解、法规匹配、风险判断推理能力失败自动降级到规则引擎二、Agent角色定义1. 合同解析AgentParseAgent职责将合同全文按条款分段提取关键要素LLM调用2次分段 结构化提取输入合同全文string输出ParsedContractJSON结构降级策略正则分段 关键词分类2. 合规审查AgentComplianceAgent职责逐条款匹配相关法规标注合规/不合规/待确认LLM调用N次N条款数每条款一次输入ParsedContract输出list[ComplianceResult]外部工具本地法规检索regulations.json3. 风险识别AgentRiskAgent职责识别不利条款、模糊表述、缺失条款、不对等条款LLM调用1次整合同风险判断输入ParsedContract输出list[RiskItem]4. 条款对比AgentCompareAgent职责与标准合同模板逐条对比标注偏离项LLM调用1次模板合同对比输入ParsedContract输出list[DeviationItem]外部工具本地标准模板库template.json5. 报告生成AgentReportAgent职责汇聚三方审查结果生成分级审查报告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. 第一步条款分段输入合同全文可能很长核心指令每个独立条款作为一条 分配编号 识别类型 保留原文关键约束忠实原文不做任何修改或概括输出格式条款列表JSON2. 第二步关键要素提取输入第一步产出的条款列表核心指令从条款中抽取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 / 2MEDIUM→MEDIUM / 1MEDIUM→LOW / 全COMPLIANT→COMPLIANT 输出overall_risk_level summary recommendations五、技术实现方案技术栈语言Python 3.10Agent框架基于原生Python asyncio实现零依赖便于教学理解LLM调用百度千帆APIernie-x1-turbo-32k并行执行asyncio.gatherFan-out阶段三路并行数据格式JSONAgent间数据传递项目结构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 2ParsedContract对象直接传递内存引用非序列化Phase 2 并行三路共享同一个ParsedContract只读Phase 2 → Phase 3三方结果列表直接传递所有JSON序列化仅用于LLM Prompt构建和最终报告存储七、LLM调用统计Agent调用次数调用策略降级方案ParseAgent2次分段1次 提取1次正则分段 关键词提取ComplianceAgentN次每条款1次规则引擎检查RiskAgent1次整合同1次规则引擎识别CompareAgent1次整合同模板1次类型匹配文本相似度ReportAgent1次三方结果1次规则汇总总计5N次N条款数—八、设计要点与决策记录8.1 为什么解析先行而非三路都独立解析避免重复解析节省LLM调用结构化结果可被三方共享保证一致性解析只需一次后续审查都基于同一份结构化数据8.2 为什么合规审查逐条款风险识别整合同合规审查需要精确的法规条款匹配逐条更准确风险识别需要全局视角如对等性判断整合同更有效8.3 为什么每个Agent都有规则引擎Fallback教学演示即使没有LLM也能跑通完整流程生产安全LLM故障时系统不宕机成本控制开发测试阶段可零成本运行8.4 分级输出的设计哲学 HIGH→ 必须修改才能签署 MEDIUM→ 建议修改否则有风险 LOW→ 可签署但需关注✅ COMPLIANT→ 无需修改8.5 示例合同的陷阱设计示例合同故意埋入以下问题验证系统能否检出第七条甲方可随时单方面解除乙方非经同意不得解除 → 不对等条款第五条甲方违约金千分之五 vs 乙方千分之一 → 违约责任不对等第八条或裁或审 → 无效条款缺少不可抗力条款→ 缺失条款第三条行业标准、合理需求 → 模糊表述第七条第3款合同解除后乙方返还全部费用 → 不公平九、项目源码源码请查看改文章绑定资源包