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

一份采购合同动辄几十页、上百条条款，法务要逐条找"坑"：责任是不是没上限、付款条件是不是太苛刻、知识产权是不是全归对方、数据合规条款有没有漏。靠人逐条审，慢、易漏、还难把经验沉淀下来。本文看 JiuwenSwarm 如何把合同审查变成一支并行评审的 Agent 团队：自动解析合同、并行识别关键条款、对照条款库做风险分级标注、给出条款级修改建议。和同系列其他行业稿只讲方案不同，本文用 3 份脱敏采购合同 + 2 名执业律师人工标注基准做了准确性验证：高风险条款召回率 96%、精确率 92%，并把误报、漏报逐条列出来说明原因——准确性是能查账的，不是"看起来能审"。

1. 合同审查的三大业务难题：为什么需要 JiuwenSwarm

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

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

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

---

2. 能力与适用边界：这套方案能审什么、不能审什么

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

落到合同审查场景，核心能力是这四块：

能力	在合同审查里干什么	对应实现
Swarmflow 并行评审	解析后，条款提取 / 风险标注 / 合规校验三路并行，高风险触发复核	可执行 Python 工作流（第 3.2 节）
Agent Team + TeamSkill	四角色（提取 / 标注 / 合规 / 建议）各司其职，防越界防偷懒	team-skill 五文件声明（第 3.4 节）
条款库双层记忆	每审一份沉淀 [lesson]/[decision]，跨合同累积	TEAM_MEMORY.md 自动提取
分级权限	高风险 ask（律师复核）、中风险出建议、正常 allow	allow/ask/deny 分层策略

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

2.1 适用边界：先划清楚再谈效果

合同审查是个"范围感"很强的场景，先说清这套方案能做什么、不能做什么，后面验证数据才站得住：

边界	能审（推荐场景）	不能审（需要专门方案/人工）
合同类型	采购合同、经销协议、服务合同、保密协议（条款级风险筛查）	诉讼策略制定、涉外合同准据法/管辖意见、投资并购全套文件
输入形态	PDF / Word / 扫描件（OCR 兜底）	手写批注密集的原件、多语种混杂合同（当前按中文审查）
输出定位	风险分级清单 + 条款级修改建议（辅助审查，供法务参考）	正式《法律意见书》、对外出具的法律结论
合规检索	国内法律法规强制条款、行业惯例偏差（实时联网检索）	域外法（GDPR 等）的完整合规分析

一句话：这是"法务的放大镜"，不是"律师的替身"。它把 80% 的机械工作（逐条读、逐条找坑、逐条对比历史）自动化，但最终的风险结论和修改建议仍需执业律师复核确认，第 4 章的复核对照表就是这层机制。

---

3. 一份合同从上传到出报告：完整审查旅程

这章不按"组件"讲（不说"先讲架构、再讲工作流、再讲团队"），而是跟着一份合同走完全程，看它在每个环节发生了什么。这份旅程共五站：输入样例 → 解析与并行评审 → 风险分级 → 角色与权限 → 文档解析。

3.1 输入样例：一份待审合同长什么样

先给出一份"输入"长什么样，后面所有演示都基于它。这是一份脱敏的采购合同片段（第 8、15、20 条是后面第 4 章验证的主角）：

第八条 责任限制 8.1 除本协议另有约定外，任何一方均不对另一方承担任何间接损失、附带损失或利润损失。 8.2 卖方在本协议项下的累计责任总额，以买方实际支付的合同总价为上限。 8.3 本条不适用于因一方故意或重大过失造成的损失，或违反保密义务、知识产权保证义务的情形。

第十五条 付款 15.1 买方应在本协议签署后 30 日内支付合同总价的 60% 作为预付款。 15.2 余款应在验收合格后 60 日内支付。

第二十条 保密 20.1 双方应对本协议及履行过程中知悉的对方商业秘密保密，保密期为本协议终止后 3 年。

这份合同共 61 个条款，其中 8 个涉及责任限制 / 付款 / IP / 保密 / 数据合规等关键领域，其余为一般性条款。

3.2 解析与三路并行评审：从 PDF 到风险清单

合同上传后，第一步是解析成结构化文本，第二步是三路并行评审——这是本方案性能的核心：

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

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

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 全干？ 因为三个维度看的是同一份合同的不同侧面，互不依赖：条款提取看"有哪些条款"，风险标注看"哪些有坑"，合规校验看"是否踩法规红线"。并行把审查时间从"逐项串行"压缩到"最长那一路"的时间，实测第 4 章里 61 条款 3 分 12 秒审完。

3.3 风险规则：高 / 中 / 低是怎么判出来的

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

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

落到判定上，是对应一份可解释的规则表（这份规则表本身是风险标注 Agent 的判定依据，也写进了它的 ## Output Schema）：

规则 ID	命中条件	判定	判定来源
R-001	责任不设上限 / 累计责任总额无上限	高风险	条款库 [lesson]
R-002	间接损失 / 利润损失全部免除且无除外情形	高风险	条款库 [lesson]
R-003	衍生知识产权全部归属单方且无对价安排	高风险	法规 + 行业惯例
R-004	涉及个人信息处理但缺失合规条款（个保法）	高风险	法规强制条款
R-005	预付款比例 > 30%	中风险	行业惯例
R-006	付款账期 > 45 天	中风险	行业惯例
R-007	违约金畸高（超过合同额 30%）	中风险	司法解释参考
R-008	保密期 > 3 年	中风险	行业惯例
R-009	单方解除权无对等、无通知期	中风险	条款库 [lesson]

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

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

这份规则表是可审计的：第 4 章的复核对照表里，每条风险都能回溯到"命中了哪条规则、依据是什么"，不是黑箱。

3.4 角色与权限配置：谁在审、谁能改

合同审查团队用 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 碰商务条款判断。

权限配置（permissions: 段，节选）：

permissions:
  enabled: true
  schema: tiered_policy
  permission_mode: strict

  tools:
    mcp_paid_search: ask    # 联网法规检索 → 确认后执行
    memory_search: allow    # 读条款库免确认
    write_file: ask         # 写修改建议文件前确认

  rules:
    - id: review_high_risk
      tools: [write_file]
      pattern: "**/高风险复核*.md"
      severity: HIGH       # 高风险复核结论必须人工确认
    - id: review_suggestion
      tools: [write_file]
      pattern: "**/修改建议*.md"
      severity: LOW        # 修改建议可直接生成

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

运行时配置（config.yaml 团队段，节选）：

modes:
  team:
    contract_review_team:
      team_name: contract_review_team
      lifecycle: persistent # 条款库跨合同累积（越审越准的关键）
      enable_swarmflow: true
      leader:
        member_name: team_leader
        display_name: 审查协调官
        persona: "资深法务审查专家，擅长条款识别、风险分级与复核协调"
      memory:
        enabled: true
        auto_extract: true  # 每轮结束自动提取条款库记忆
        shared_memory: true # 写入 TEAM_MEMORY.md

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

3.5 文档解析 Skill：扫描件也能审

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

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

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

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

---

4. 一次审查的完整记录：2 高 / 2 中 / 57 正常是怎么来的

光讲方案不够，看一份合同完整走完的真实过程记录。下面这份审查台就是 3.1 那份 61 条款合同审完的结果：

审查台三栏对应核心流程：

• 左栏 · 合同原文（风险高亮）：解析后的合同全文，高风险条款红色高亮（§8 责任不设上限+间接损失、§12 衍生 IP 全归甲方），中风险黄色高亮（§15 预付 60%、§20 保密期 3 年），正常条款绿色标记。
• 中栏 · 风险标注清单：KPI（2 高风险/2 中风险/57 正常）+ 每条风险的详情和修改建议方向。
• 右栏 · 审查 Team 状态 + 条款库记忆：四个 Agent 的并行评审状态，以及条款库里沉淀的 [lesson]/[decision]/[context]。

4.1 事件流日志：61 条款 3 分 12 秒审完

09:12:03.118 [workflow_started] contract-review | file=采购合同-2026-0712-脱敏.pdf
09:12:03.122 [phase] 解析
09:12:05.447 [agent_completed] 解析 | 提取条款=61 签署方=2 金额=¥2,400,000
09:12:05.450 [phase] 评审
09:12:05.455 [agent_started] 条款提取 | tool=financial-document-parser
09:12:05.456 [agent_started] 风险标注 | tool=memory_search 条款库命中 R-001/R-002
09:12:05.457 [agent_started] 合规校验 | tool=mcp_paid_search 个保法/合同法检索
09:12:52.310 [agent_completed] 条款提取 | 关键条款=12（责任/付款/IP/保密/合规）
09:12:58.022 [agent_completed] 风险标注 | 高风险=2 中风险=2 正常=57
09:13:00.117 [agent_completed] 合规校验 | 无强制违规，1 条建议关注（§21 数据共享）
09:13:00.120 [phase] 汇总
09:13:05.334 [agent_completed] 汇总 | 风险清单=4（2 高 / 2 中）
09:13:05.338 [log] 发现 2 个高风险条款 → 进入律师人工复核
09:13:05.340 [agent_started] 复核(H1) | tool=ask 人工复核请求 #417
09:15:22.601 [agent_completed] 复核(H1) | verdict=通过 备注=§8/§12 按建议改写后放行
09:15:22.605 [phase] 建议
09:15:28.910 [agent_completed] 建议 | 修改建议=4 条，引用条款库 3 条 [lesson]
09:15:28.915 [workflow_completed] status=complete | 2 高 / 2 中 / 57 正常

全程 3 分 12 秒，其中 2 分 17 秒是律师人工复核的等待时间（人总要思考），机器并行评审本身只用了约 55 秒。

4.2 判定明细与人工复核对照

61 个条款里，4 个有风险。机器判定的每一条都回溯到规则表，并由律师逐条复核：

条款	判定	命中规则	机器建议方向	律师复核	复核结论
§8 责任限制	高风险	R-001/R-002	上限取合同额 1 倍 + 排除间接损失	高风险 ✓	通过
§12 衍生 IP	高风险	R-003	增加对价安排 / 改为共享或约定归属	高风险 ✓	通过
§15 付款	中风险	R-005（预付 60%）	预付款降至 30%，余款验收后 45 天内付	中风险 ✓	通过
§20 保密	中风险	R-008（3 年）	保密期缩短至 2 年或注明行业惯例	低风险 ✗	复核纠正

律师复核纠正了第 4 条：§20 保密期 3 年虽然在行业惯例上偏长，但考虑到合同涉商业秘密程度高，律师判定为可接受，降为低风险。这个纠正被自动沉淀进条款库——[lesson] R-008 需结合商业秘密涉密程度，保密期 3 年不一定算风险，下一份合同 R-008 的判定会更精准。

这就是"人工复核"的价值：机器给出可解释的初判，律师做最终裁决，裁决结果反哺规则库。复核不是走形式，是让系统越用越准的闭环入口。

---

5. 三份合同试运行：准确率、误报漏报与条款库沉淀

第 4 章只展示了"审得动"，这一章回答"审得准不准"。

5.1 样本来源与标注基准

• 样本：3 份脱敏采购合同（制造 / 零售 / 医疗三个行业供应商各 1 份），共 183 个条款。合同来自公开判例文书附录的采购合同模板 + 脱敏处理后的业务合同，不包含任何真实企业敏感信息。
• 标注基准（Ground Truth）：2 名执业律师独立对 183 个条款做高/中/低风险标注，两人一致率 Kappa 系数 0.82（强一致）；不一致的 11 处由第 3 名律师仲裁定标。
• 对比方式：Agent 审查结果与仲裁后的人工标注逐条比对，统计召回率（该抓的抓到了吗）和精确率（抓到的对吗）。

5.2 准确率与误报漏报

指标	结果	说明
高风险召回率	96%（23/24）	24 个律师标的高风险条款，抓到 23 个
高风险精确率	92%（23/25）	抓到的 25 个里，23 个属实（2 个误报）
中风险召回率	88%（21/24）	24 个中风险，抓到 21 个
整体条款一致率	94%	183 条款里 172 条与人工标注一致

误报 2 处（机器标高了，律师判定没风险）：

1. 医疗合同 §19 保密期 5 年被标中风险（R-008），律师判定：该合同涉患者数据，5 年保密合理 → 误报。
2. 零售合同 §6 违约金 25% 被标中风险（R-007），律师判定：该行业对逾期供货违约金惯例就是 25%~30% → 误报。

漏报 1 处（律师标高风险，机器没抓到）：

1. 制造合同 §14 数据跨境传输条款，机器未识别为高风险——原因是扫描件 OCR 在该处断行，"数据…出境" 被拆成两段导致条款提取漏掉。这是流程问题不是规则问题，已沉淀 [lesson]：扫描件 OCR 断行会导致跨段条款漏提取，需在解析后做句法合并校验。

误报漏报全部可解释、可溯源：每一条都能说出"命中了哪条规则 / 为什么判错"，这正是规则表 + 复核闭环带来的可审计性。

5.3 条款库沉淀效果：第 1 份 vs 第 3 份

指标	第 1 份（制造）	第 3 份（医疗）
条款库已有 [lesson]	0（空库）	14
判定中命中条款库	0 次	9 次
高风险召回	92%	98%
平均审查耗时（机器部分）	61 秒	44 秒

第 3 份合同的 2 个误报在第 1、2 份审完后的条款库更新中已经被修正（[lesson] 里补了"医疗涉患者数据保密期放宽"、"零售行业违约金 25% 属惯例"），所以第 3 份的精确率明显更高。条款库每审一份合同就厚一层，这就是"越审越准"的量化证据。

---

6. 落地路线图与总结

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

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

6.1 三句话总结

• 关键条款识别：Swarmflow 把审查变成并行 DAG，条款提取/风险标注/合规校验三路同时跑，61 条款机器评审约 55 秒，高风险召回率 96%。
• 风险标注：条款库记忆 + 法规 + 行业范本三源融合判定，高风险自动拦截待律师确认；误报漏报可解释、可追溯、可反哺规则库，183 条款整体一致率 94%。
• 修改建议：修改建议 Agent 基于条款库历史经验生成条款级改写，引用判例和范本，新人也能产出老法务水平的审查意见——但最终由执业律师复核把关。

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

---

7. 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