合同智能审查与风险追踪：关键条款识别 + 风险标注 + 修改建议

一份采购合同动辄几十页、上百条条款，法务要逐条找"坑"：责任是不是没上限、付款条件是不是太苛刻、知识产权是不是全归对方、数据合规条款有没有漏。靠人逐条审，慢、易漏、还难把经验沉淀下来。本文看 JiuwenSwarm 如何把合同审查变成一支并行评审的 Agent 团队：自动解析合同、并行识别关键条款、对照条款库做风险分级标注、给出条款级修改建议——而且每审一份合同，"踩过的坑"就自动沉淀进条款库，越审越准。

目录

• 合同审查的三道老难题
• JiuwenSwarm 凭什么能“审合同”
• 并行评审的合同审查团队
• 让关键条款自己浮出来
  • 审查的工作流长什么样
• 风险怎么标注、怎么分级
• 修改建议是怎么生成的
• PDF 和扫描件怎么进来
• 合同审查台长什么样
• 落地建议与总结
• 相关引用

---

合同审查的三道老难题

把"审合同"这件事做好，传统方案几乎都卡在三个环节：

难题	典型表现	传统解法的痛点
① 关键条款识别	几十条条款里，哪些是责任限制、付款、知识产权、数据合规等关键条款？得逐条读	纯人工，长合同容易看漏；不同人审标准不一
② 风险标注	责任不设上限、付款条件偏离惯例、IP 全归对方——这些"坑"怎么系统性地标出来	靠法务经验，新人审不出深坑；经验难传承
③ 修改建议	发现风险后，怎么给出既合规又能谈成的条款改写？要引用历史判例和行业范本	每次从零写，耗时；历史谈判经验留不下来

JiuwenSwarm 的解法是：把合同审查变成一支并行评审的 Agent 团队——一个审查协调官（Leader）把合同解析后分发给条款提取、风险标注、合规校验三个 Agent 并行评审，再由修改建议 Agent 整合输出条款级改写；每审完一份，新发现的"坑"自动沉淀进条款库 TEAM_MEMORY.md，下一份合同自动参考。

---

JiuwenSwarm 凭什么能“审合同”

JiuwenSwarm 是一款让多智能体真正协作起来的 Agent 系统，帮助用户通过自然语言驱动多 Agent 协作、Skill 自演进和工具调用，实现从意图到结果的端到端交付。

落到合同审查场景，本文会用到这几项能力：

• Swarmflow（蜂群流）：把"审这份合同"自动拆成解析 → 并行评审（条款提取/风险标注/合规校验同时跑）→ 汇总 → 生成建议的可执行工作流，高风险条款触发条件分支走人工复核。
• Agent Team + TeamSkill：声明式定义审查团队的四个角色，三路并行评审是天然适合 parallel 原语的场景。
• 双层团队记忆：条款库——每审一份合同，新发现的苛刻条款、谈判策略沉淀为 [lesson]/[decision]，跨合同累积，越审越懂甲乙双方的套路。
• 工具权限与安全防护：高风险条款（如无上限责任）标记后触发 ask，必须法务人工确认才放行。

一句话理解：JiuwenSwarm 不是"再写一个合同关键词检索工具"，而是把审查协作从 "靠人逐条看" 变成 "并行评审 + 经验沉淀 + 越审越准"。

---

并行评审的合同审查团队

先看全貌。下图把合同审查映射成了三层：

• 顶层 · 蜂群协作层（合同审查 Team）：一个 Leader（审查协调官）+ 四个专业 Teammate（条款提取 / 风险标注 / 合规校验 / 修改建议），其中前三个并行评审，最后由修改建议 Agent 整合。
• 中层 · 条款库 TEAM_MEMORY.md：跨合同累积的审查经验，所有成员只读。这是"越审越准"的核心。
• 底层 · 文档输入层：合同 PDF/扫描件（OCR 解析）、Word 协作稿、历史条款库、法规库/行业范本。

注意一个关键设计：条款提取、风险标注、合规校验三路并行——它们看的是同一份合同的不同维度，互不依赖，正好适合 parallel 原语同时跑。风险标注 Agent 在判定时会去读条款库里"这类条款历史怎么处理"的 [lesson]，而不是从零判断。

---

让关键条款自己浮出来

"审这份合同"这句话，背后是一个有并行/串行/条件分支的工作流：

解析合同全文 →（条款提取 ‖ 风险标注 ‖ 合规校验 三路并行）→ 风险汇总 →（高风险？律师人工复核）→ 生成修改建议

JiuwenSwarm 的 Swarmflow 把这套流程写成一段可执行的 Python：

几个关键点：

1. 三路并行评审（parallel）：T1a 条款提取、T1b 风险标注、T1c 合规校验同时进行——它们彼此独立，并行能把审查时间从"逐项串行"压缩到"最长那一路"的时间。
2. 风险汇总后分级：T2 把三路结果合并，按高/中/低分级排序。
3. 条件分支 + 人工复核：若出现高风险条款（如责任不设上限），自动进入 H1 律师人工复核节点——人作为"有状态算子"确认或改写，复核通过才进入建议生成。

审查的工作流长什么样

Swarmflow 的工作流是一段真实的 Python，基于仓库里 SwarmSkill 工作流模板 的结构。改成合同审查后：

from swarmflow import agent, compact, log, parallel, phase

META = {
    "name": "contract-review",
    "description": "合同智能审查：解析→并行评审（条款/风险/合规）→汇总→修改建议",
    "whenToUse": "用户提供合同文件要求做法律审查、风险排查时复用",
    "phases": [
        {"title": "解析",   "detail": "解析合同全文（PDF/Word/OCR）"},
        {"title": "评审",   "detail": "条款提取、风险标注、合规校验三路并行"},
        {"title": "汇总",   "detail": "合并三路结果，风险分级排序"},
        {"title": "建议",   "detail": "高风险人工复核 → 生成条款级修改建议"},
    ],
}

CLAUSE_SCHEMA = {  # 结构化输出
    "type": "object",
    "properties": {"clauses": {"type": "array"}, "risks": {"type": "array"}, "verdict": {"type": "string"}},
}

async def run(args):
    # —— 阶段1 解析 ——
    phase("解析")
    full_text = await agent(
        build_prompt("解析合同", {"file": args["file"]}),
        label="解析", phase="解析", schema={"type": "object", "properties": {"text": {"type": "string"}}},
    )

    # —— 阶段2 评审：三路并行 ——
    phase("评审")
    review = await parallel([
        lambda: agent(build_prompt("条款提取", full_text),
                      label="条款提取", phase="评审", schema=CLAUSE_SCHEMA),
        lambda: agent(build_prompt("风险标注", full_text),
                      label="风险标注", phase="评审", schema=CLAUSE_SCHEMA),
        lambda: agent(build_prompt("合规校验", full_text),
                      label="合规校验", phase="评审", schema=CLAUSE_SCHEMA),
    ])
    review = compact(review)  # 某一路异常不阻断整体

    # —— 阶段3 汇总分级 ——
    phase("汇总")
    summary = await agent(
        build_prompt("风险汇总", {"review": review, **args}),
        label="汇总", phase="汇总", schema={"type": "object", "properties": {"risks": {"type": "array"}}},
    )
    risks = extract_json(summary).get("risks", [])

    # —— 阶段4 高风险复核 + 修改建议 ——
    phase("建议")
    high_risks = [r for r in risks if r.get("level") == "high"]
    if high_risks:
        log(f"发现 {len(high_risks)} 个高风险条款 → 进入律师人工复核")
        review_result = await agent(build_prompt("高风险复核", {"risks": high_risks}),
                                    label="复核", phase="建议", schema={"type": "object"})
        if extract_json(review_result).get("verdict") == "驳回":
            return {"status": "degraded", "reason": "高风险条款需重新谈判"}

    suggestions = await agent(
        build_prompt("生成修改建议", {"risks": risks, "review": review}),
        label="建议", phase="建议", schema={"type": "object", "properties": {"suggestions": {"type": "array"}}},
    )
    return {"status": "complete", "risks": risks, "suggestions": extract_json(suggestions).get("suggestions")}

这段代码的核心是 parallel([...]) 把三路评审同时拉起，compact([...]) 保证任一路失败不阻断。工作流跑起来后持续吐进度事件（workflow_started → phase → agent_started → agent_completed → …），事件派发表见仓库 workflow_state.py。

过去要法务逐条看完一份合同才能下结论，现在三路并行评审 + 高风险自动拦截，审查效率和覆盖面都上了一个台阶。

---

风险怎么标注、怎么分级

风险标注不是"拍脑袋"，而是多源融合判定。风险标注 Agent 在判断一个条款是否有风险时，会综合三个来源：

• 条款库（TEAM_MEMORY.md）：历史审合同沉淀的 [lesson]——比如"无上限责任条款近 12 份合同谈判均被否，标准策略是上限取合同额 1 倍 + 排除间接损失"。命中已知坑直接判高风险。
• 法规强制条款：违反法律法规的强制规定（如缺失个人信息处理条款违反个保法），直接判高风险。
• 行业范本/谈判惯例：偏离行业惯例（如预付款惯例 ≤30%、账期 ≥45 天），判中风险。

判定逻辑落到权限体系上，就是分级处理：

风险等级	处理方式
高风险	触发 H1 律师人工复核（对应权限的 ask），必须确认或改写
中风险	由修改建议 Agent 给出改写方向，提示但不强制
低/正常	自动放行（对应权限的 allow）

团队记忆的写入机制和餐饮篇一致：在 lifecycle: persistent 的团队里，Leader 每轮结束派一个提取 Agent，把本轮新发现的"坑"蒸馏成 [lesson]/[decision]/[context] 写入条款库，文件自动保持在 200 行以内（旧的合并/淘汰）。这意味着第 100 份合同审完，前 99 份的经验都在条款库里。

记忆写入用的是仓库的 memory_tools.py（write_memory 工具，路径校验只允许 memory/*.md，且群聊模式下禁用写入防污染）。

---

修改建议是怎么生成的

合同审查团队用 TeamSkill（团队技能） 标准定义，和餐饮采购团队一样是五文件结构（/teamskills validate 硬校验）：

contract-review-team/
├── SKILL.md              # kind: team-skill + roles[] 四角色
├── roles/
│   ├── clause-extractor.md     # 条款提取
│   ├── risk-auditor.md         # 风险标注
│   ├── compliance-checker.md   # 合规校验
│   └── suggestion-writer.md    # 修改建议
├── workflow.md           # 协作流程（mermaid + 质量门控）
├── bind.md               # 并发/预算/失败兜底
└── dependencies.yaml     # skills + tools 声明

SKILL.md frontmatter（基于仓库 medical-consultation-team 范例结构）：

---
name: contract-review-team
version: 1.0.0
description: |
  合同智能审查团队，协调官组织条款提取、风险标注、合规校验并行评审并整合修改建议。
  Use when 需要对合同做法律风险审查、关键条款排查、修改建议生成。
  Do NOT use for 合同商务条款的非法律性谈判策略制定。
kind: team-skill
roles:
  - id: coordinator
    purpose: 解析合同、分发条款、汇总风险、高风险人工复核
    skills: []
    tools: [send_message, create_task, read_file]
  - id: clause-extractor
    purpose: 结构化提取关键条款（付款/违约/IP/保密/终止等）
    skills: [financial-document-parser]
    tools: []
  - id: risk-auditor
    purpose: 对照条款库+法规，对条款做高/中/低风险分级标注
    skills: []
    tools: [memory_search, mcp_paid_search]
  - id: compliance-checker
    purpose: 数据合规/反垄断/行业监管红线检查
    skills: []
    tools: [mcp_paid_search]
  - id: suggestion-writer
    purpose: 生成条款级修改建议文本，引用历史判例/范本
    skills: []
    tools: [write_file]
---

每个 roles/<id>.md 文件同样有 5 个必填段落，其中 ## Identity 的座右铭是防趋同的关键：

• 风险标注 Agent：> *"我对任何'看起来合理'的条款都保持警惕，宁可误报也不漏报。"*
• 合规校验 Agent：> *"我只认法规红线，行业惯例在我这里不构成豁免理由。"*

## Boundary 里的 **Forbidden**/**Mandatory** 防止角色越界：风险标注 Agent 被 Forbidden 改写条款（那是 suggestion-writer 的活），合规校验 Agent 被 Forbidden 碰商务条款判断。

这里用到的 mcp_paid_search、memory_search、read_file、write_file 都是仓库 harness/common/tools/ 里真实注册的工具：mcp_paid_search 做法规检索、memory_search（语义+BM25 混合检索）查条款库、read_file/write_file 读写合同文件。

---

PDF 和扫描件怎么进来

合同大多是 PDF 或扫描件，先得把文字"抠"出来。JiuwenSwarm 仓库内置的 financial-document-parser 技能正好能干这事——它用 pdfplumber 解析文本 PDF、用 pytesseract + pdf2image 对扫描件做 OCR 兜底，输出结构化文本：

| 类型 | 格式 | 提取内容 |
| 合同 | PDF | 条款全文、签署方、日期、金额 |
| 扫描件 | PDF/图片 | OCR 识别全文（兜底） |

在审查团队里，条款提取 Agent（clause-extractor）调用这个技能解析合同 PDF，把"第八条 责任限制……应全额赔偿包括间接损失"这种条款文本抠出来，再喂给风险标注 Agent 判定。OCR 兜底意味着即使是扫描的纸质合同也能审。

对于结构化条款管理，还可以配合仓库的 llm-wiki 技能建一个本地的"标准条款范本库"，新合同自动对照范本找差异。

---

合同审查台长什么样

把上述能力拼起来，审一份合同时产出这样的审查台：

审查台分三栏，对应本文的核心流程：

• 左栏 · 合同原文（风险高亮）：解析后的合同全文，高风险条款红色高亮（§8 责任不设上限+间接损失、§12 衍生 IP 全归甲方），中风险黄色高亮（§15 预付 60%、§20 保密期 3 年），正常条款绿色标记。
• 中栏 · 风险标注清单：KPI（2 高风险/2 中风险/57 正常）+ 每条风险的详情和修改建议方向。比如 §8 命中条款库 [lesson]（无上限责任历史谈判均被否），给出"上限取合同额 1 倍+排除间接损失"的建议。
• 右栏 · 审查 Team 状态 + 条款库记忆：四个 Agent 的并行评审状态（条款提取 ✓、风险标注 ✓、合规校验 ⚠ 发现缺数据条款、修改建议 ✓），以及当前条款库里沉淀的 [lesson]/[decision]/[context]——正是这些经验让审查能"越审越准"。

这份审查台背后：合同上传后自动解析，三路 Agent 并行评审，高风险自动拦截待律师确认，修改建议引用条款库历史经验——审查、标注、建议、经验沉淀一条龙。

---

落地建议与总结

如果你也想在自家法务/合规团队上落地，建议按这个节奏来：

1. 先跑通单类合同：选一类高频合同（如采购合同），1 个 Leader + 3 个评审 Teammate，手动触发验证 Swarmflow DAG 和并行评审逻辑。
2. 积累条款库：团队设 lifecycle: persistent，把过去审过的合同的"坑"和谈判策略沉淀进 TEAM_MEMORY.md，跑一个月后条款库就有足够经验支撑自动判定。
3. 配好风险分级策略：高风险条款（无上限责任、IP 全归对方、违约金畸高）用条件分支强制走律师复核；中低风险自动出建议。
4. 接入 OCR + 法规检索：用 financial-document-parser 处理扫描件，mcp_paid_search 做实时法规检索，保证审查依据的时效性。

三句话总结

• 关键条款识别：Swarmflow 把审查变成并行 DAG，条款提取/风险标注/合规校验三路同时跑，几十条条款几分钟扫完。
• 风险标注：条款库记忆 + 法规 + 行业范本三源融合判定，高风险自动拦截待律师确认，每审一份合同条款库就厚一层。
• 修改建议：修改建议 Agent 基于条款库历史经验生成条款级改写，引用判例和范本，新人也能产出老法务水平的审查意见。

随着 Agent 协同在法务合规场景深入，"经验沉淀 + 并行评审 + 自动建议"的合同审查模式将大幅提升法务效率与风险覆盖面——而 JiuwenSwarm 让这条路触手可及。

---

相关引用

1. JiuwenSwarm 官网：https://openjiuwen.com
2. JiuwenSwarm 仓库（GitCode）：https://gitcode.com/openJiuwen/jiuwenswarm
3. 官方文档：
   • TeamSkill 团队技能指南
   • Agent Team 使用指南
   • 记忆系统
   • 工具权限与安全防护
4. 相关技能：financial-document-parser、llm-wiki、openJiuwen-DeepSearch