法律合约比较工作流程:使用Dify的传输节点和Human-in-the-Loop进行实际设计
简介
在公司法律事务中,审查合同是最耗时的工作之一。检查新合同的草稿与公司自己的模板之间的差异,掌握业务伙伴发送的修订版本(红线版本)的变化,检查多个相关合同之间的条款一致性——尽管这些工作需要高度的专业知识,但大部分时间都花在“提取常规差异”上。
本文使用 Dify 的工作流程功能来解释法律合同审查系统的设计和实现,该系统可以自动对多个文件进行合同比较,同时需要人工确认高风险条款。
背景和问题
合同审查现状
| 挑战 | 影响 |
|---|---|
| 每个案例所需时间 | 标准外包合同 2-4 小时,复杂合同几天 |
| 忽视条款的风险 | 自动续订条款、适用法律的变更等很可能在人工检查中被忽视 |
| 版本控制的复杂性 | 当Word的更改历史记录被多次合并时,跟踪更改变得困难 |
| 个性化 | 只有特定的律师和法律工作人员才了解判断标准 |
| 拥堵等待点评 | 法务部瓶颈导致业务速度放缓 |
这个工作流程解决什么问题
- 常规差异提取的自动化:委托逐条比较LLM
- 风险分类标准化:使用一致的标准确定每个条款的风险级别
- 人在环:高风险、低置信度的决策总是传递给人类。
- 多文件支持:使用迭代节点进行顺序处理
整体架构
flowchart TD
A[契約書ファイルアップロード<br>主契約 + テンプレート + 附属書] --> B[ファイル解析ノード]
B --> C[契約タイプ分類]
C --> D[迭代ノード:<br>ファイルごとに条項抽出]
D --> E[条項マッピング・差異検出]
E --> F[リスク分級ノード]
F --> G{高リスク条項あり?}
G -->|Yes| H[Human-in-the-Loop:<br>法務担当に確認依頼]
G -->|No| I[レビュー結果出力]
H --> J{承認 / 差戻し}
J -->|承認| I
J -->|差戻し| K[修正指示付きで再レビュー]
K --> E
I --> L[構造化レポート出力]
工作流节点设计细节
节点1:文件接收/预处理
在 Dify Workflow 中的启动节点上传文件。接受多个文件时,向每个文件添加元数据。
{
"files": [
{
"name": "master_agreement_v2.pdf",
"role": "review_target",
"type": "主契約",
"version": "v2.0"
},
{
"name": "standard_template_2024.pdf",
"role": "template",
"type": "業務委託契約テンプレート",
"version": "2024年版"
},
{
"name": "appendix_a.pdf",
"role": "attachment",
"type": "別紙A(SLA条件)",
"version": "v1.0"
}
]
}
节点2:文本提取
从 PDF 中提取文本。 Dify 中提供了以下方法。
| 方法 | 应用案例 | 备注 |
|---|---|---|
| 文本PDF直接分析 | Word → PDF 转换 | 最准确且成本低 |
| OCR(Tesseract等) | 扫描 PDF | 注意日语OCR的准确性 |
| VLM(视觉语言模型) | 包含表格、图形和印章混合的文档 | 利用 GPT-4o / Claude的视觉功能 |
由于合同通常是文本 PDF 格式,因此首先尝试直接分析它们是有效的。
节点 3:合同类型分类(LLM 节点)
System Prompt:
あなたは日本の企業法務の専門家です。
アップロードされた契約書のテキストを分析し、以下の契約タイプに分類してください。
- 業務委託契約
- 秘密保持契約(NDA)
- ソフトウェアライセンス契約
- SaaS 利用規約
- 売買基本契約
- 共同開発契約
- その他(具体的に記述)
出力フォーマット:
{"contract_type": "...", "confidence": 0.0-1.0}
根据合同类型切换后续风险标准和模板。
节点 4:迭代节点提取子句
使用 Dify Workflow 中的 迭代节点 对每个上传的文件应用相同的子句提取过程。
迭代ノードの設定:
- 入力配列: files[]
- 各イテレーションの処理:
1. テキスト抽出
2. LLM ノードで条項単位に分割
3. 各条項をJSON配列として出力
子句提取的 LLM 提示示例:
以下の契約書テキストから、主要条項を抽出してください。
各条項について以下のフィールドを出力してください。
- clause_id: 条番号(例: "第3条第2項")
- clause_title: 条項名(例: "秘密保持義務")
- clause_text: 条文全文
- clause_category: カテゴリ(以下から選択)
[契約主体, 契約期間, 業務範囲, 報酬・支払条件,
知的財産権, 秘密保持, 損害賠償, 解除条件,
自動更新, 準拠法・管轄, 反社会的勢力排除, その他]
JSON配列で出力してください。
使用迭代节点的原因:如果将所有文件的文本一次性输入LLM,由于上下文窗口的限制,子句很可能会被忽略。通过按顺序处理每个文件并保留中间结果,您可以稍后准确地跟踪在哪个文件中检测到此差异。
节点 5:子句映射/差异检测(LLM 节点)
接收传输节点输出的每个文件的条款列表,并将模板与待审核的条款进行匹配。
System Prompt:
あなたは契約書の比較分析エキスパートです。
テンプレート条項とレビュー対象の条項を比較し、
以下のフォーマットで差異を報告してください。
各条項について:
{
"clause_category": "...",
"template_clause": "テンプレート側の条文",
"review_clause": "レビュー対象側の条文",
"status": "identical | modified | added | deleted | missing",
"diff_summary": "差異の要約(日本語)",
"risk_level": "high | medium | low | info",
"risk_reason": "リスク判定の根拠"
}
リスク判定基準:
- high: 損害賠償上限の撤廃、自動更新の無制限化、排他的拘束、
準拠法の変更、データ越境義務、競業避止の過度な拡大
- medium: 支払条件の変更、解除条件の非対称性、保証範囲の縮小
- low: 通知期間の軽微な変更、形式的な文言修正
- info: 差異はあるが実質的影響なし
节点6:风险分类和汇总
聚合差异检测结果并生成审核摘要。
{
"total_clauses_compared": 24,
"identical": 15,
"modified": 6,
"added": 2,
"deleted": 1,
"high_risk_count": 2,
"medium_risk_count": 3,
"requires_human_review": true,
"high_risk_clauses": ["..."]
}
人在环审核节点设计
为什么不完全自动化?
人工智能在合同审查中的作用是“检测和分类差异”,而不是做出“法律判断”。法律责任最终落在人类身上,因此将高风险决策委托给人工智能无论从合规性还是实践的角度来看都是不可接受的。
设计触发条件
| 状况 | 判断逻辑 | 分行目的地 |
|---|---|---|
| 有一个高风险条款 | high_risk_count >= 1 | 请务必将其发送给人工 |
| 对差异的信心不足 | LLM表示缺乏证据 | 转移到人类 |
| 合同结构异常 | 缺少主要条款(损坏赔偿、取消等) | 转移到人类 |
| 越权的可能性 | 合同金额超出审批权限门槛 | 升级 |
| OCR 质量差 | 文本提取质量得分低于阈值 | 传递给人类 |
人类输入节点分支
Dify 的人工输入节点本身支持三个分支:
- 接受:法律部门确认并批准→继续报告输出
- DENY:法律部门发回→给出更正指示并返回有条件分支
- 超时:在一定时间内没有响应 → 保持搁置状态而不自动批准
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
契約書レビュー: 人間による確認が必要です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 高リスク条項:
1. 第12条(損害賠償)
テンプレート: 賠償上限は委託料の12ヶ月分
レビュー対象: 賠償上限の記載なし(無制限)
→ リスク: 損害賠償上限の撤廃
2. 第15条(自動更新)
テンプレート: 1年ごとの自動更新、解約通知3ヶ月前
レビュー対象: 3年ごとの自動更新、解約通知6ヶ月前
→ リスク: ロックイン期間の大幅延長
■ 判断をお願いします: [承認] [差戻し]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
条款比较清单
主要比较术语
| 类别 | 检查点 | 典型风险 |
|---|---|---|
| 合同实体 | 更改各方描述/关联公司的范围 | 义务归属不明确 |
| 合同期限 | 开始日期、结束日期、自动续订条件 | 意外锁定 |
| 补偿/付款 | 金额/付款地点/延误损坏费 | 现金流风险 |
| 知识产权 | 归属和许可范围 | 作品权利的丧失 |
| 保密 | 定义、期限、例外情况、剩余期限 | 信息泄露的责任范围 |
| 损害赔偿 | 上限、豁免和间接损害的处理 | 意想不到的高额补偿 |
| 取消条件 | 未经通知而取消/未经通知而取消/影响 | 突然终止合同的风险 |
| 适用法律/司法管辖区 | 适用法律/管辖权/仲裁条款 | 发生争议时不利的管辖权 |
| 数据处理 | 个人信息/跨境转移/删除义务 | 违反个人信息保护法 |
| 排除反社会势力 | 声明和保证/取消权 | 合规风险 |
设计输出报告
结构化输出 (JSON)
以结构化 JSON 格式输出,假设与下游合同管理系统和工作流程审批系统协作。
{
"review_id": "REV-2026-0412-001",
"review_date": "2026-04-12",
"reviewer_ai": "Dify Workflow v1.2",
"reviewer_human": "法務部 田中",
"contract_type": "業務委託契約",
"review_target": "master_agreement_v2.pdf",
"template": "standard_template_2024.pdf",
"summary": {
"total_clauses": 24,
"differences": 9,
"high_risk": 2,
"medium_risk": 3,
"human_review_status": "approved_with_comments"
},
"high_risk_details": [
{
"clause_id": "第12条",
"category": "損害賠償",
"diff_summary": "賠償上限の記載が削除されている",
"recommendation": "上限条項の追記を交渉"
}
],
"recommendations": [
"第12条の損害賠償上限を明記するよう交渉を推奨",
"第15条の自動更新期間を1年に短縮するよう修正依頼"
]
}
实现说明和反模式
不该做的事情
- 立即将整个合同放入LLM并询问“有什么区别?” - 如果你不将其分解为条款,重要的差异将被隐藏。
- 不区分处理主合同、附录和变更备忘录——版本和应用优先级混淆
- 将AI判断结果作为最终判断——以法律责任由人类承担为前提进行设计。
- 风险等级判断标准与组织规则分离——与审批权限、合规政策挂钩
- 不要定义Human-in-the-Loop的触发条件——如果不清楚在什么条件下所有病例应该发送给人类,就会出现两个极端:所有病例都发送给人类,或者所有病例都被传递。
实施步骤
| 相 | 期间 | 内容 |
|---|---|---|
| 第一阶段 | 2 周 | PoC 具有简单的合同类型,例如 NDA。与模板一对一比较。 |
| 第二阶段 | 1 个月 | 扩大到业务外包合同。支持传输节点中的多个文件,包括附件。 |
| 第三阶段 | 1-2个月 | 人在环的全面运作。根据法律团队的反馈调整风险标准。 |
| 第四阶段 | 继续 | API与合同管理系统联动。积累审核绩效数据,提高判断准确性。 |
API合作示例
Dify Workflow 可以作为 REST API 发布,因此可以从现有合同管理系统中调用。
curl -X POST 'https://dify.example.com/v1/workflows/run' \
-H 'Authorization: Bearer {api_key}' \
-H 'Content-Type: multipart/form-data' \
-F 'inputs={"contract_type":"業務委託契約"}' \
-F 'files=@master_agreement_v2.pdf' \
-F 'files=@standard_template_2024.pdf' \
-F 'response_mode=blocking' \
-F 'user=legal_team_tanaka'
总结
法律合同比对工作流程的本质不是“让人工智能读合同”,而是构建一个系统,自动提取可标准化的差异,并将高风险决策可靠地委托给人类。
Dify 的传输节点可以实现多个文件的顺序处理,Human-in-the-Loop 节点的 ACCEPT / DENY / TIMEOUT 分支保证了 Workflow 层面法律审查所需的“人类做出最终决定”的原则。
重要的是,不要将此工作流程定位为“法律部门的省力工具”,而是“合同风险可视化和标准化的基础”。人工智能发现差异,对风险进行分类,人类进行决策——不断重复这个循环,就可以提高整个组织的合同风险管理能力。