用 JiuwenClaw 打造合同审查辅助Agent Swarm：从条款提取到风险标注的实践记录

用 JiuwenSwarm 打造合同审查辅助 Agent Swarm：从条款提取到风险标注的实践记录

在法务和商务协作场景里，合同审查往往不是一个单点任务。它既需要识别主体、金额、期限、违约责任等结构化条款，也需要理解业务背景、交易风险、版本差异和谈判空间。传统做法通常依赖人工逐段阅读，再通过批注、邮件或表格同步意见。这个流程可靠，但耗时，也很容易在多轮修改中遗漏关键变化。

这次实践，我尝试使用 JiuwenSwarm 搭建一个"合同审查辅助"工作流：让多个 Agent 扮演不同审查角色，围绕同一份合同进行法律条款提取、风险点标注和版本比对分析，最后输出给法务和商务都能阅读的审查记录。它不是替代律师意见，而是把重复性、结构化、跨版本对照的工作前置处理，让专业人员把精力放在判断和决策上。

第一章：认识 JiuwenSwarm、Agent Swarm 与集群模式

JiuwenSwarm 是 openJiuwen 社区共建的 AI Agent 应用。官方对它的定位是"懂你所想，自主演进"，它不是一个只负责回答问题的聊天窗口，而是把任务规划、技能、记忆、上下文管理、浏览器操控、Channel 接入等能力组织在一起，让 Agent 能够围绕一个目标持续推进任务。简单说，普通对话更像"问一句答一句"，而 JiuwenSwarm 更像一个可以拆任务、用工具、调用技能、维护工作区的智能工作台。

理解 JiuwenSwarm 的关键，不只是理解"一个 Agent 能做什么"，还要理解"多个 Agent 怎么一起做事"。这就是 Agent Swarm。Agent Swarm 可以理解为一支由 AI 组成的临时项目组：有 Leader 负责理解目标、拆解任务、创建成员、分派工作、跟踪进度；也有不同 teammate 负责具体专业任务。它不是简单地让同一个模型多说几段不同语气的话，而是把复杂任务拆成多个角色、多个阶段、多个交付物，再通过协调机制把结果汇总起来。

以合同审查为例，单个 Agent 当然也能阅读合同并给出风险提示，但它很容易把法律视角、商务视角、版本比对和最终报告混在一起，导致重点不清，也不利于复盘。Agent Swarm 的做法更接近真实公司里的协作：

条款提取专员：先把合同主体、金额、付款节点、交付验收、保密、知识产权、违约责任、解除、争议解决等内容结构化。
法律风险审查官：只从法律合规、责任边界、条款效力、赔偿范围、管辖约定等角度审查。
商务风险审查官：只从付款周期、验收标准、交付范围、成本收益、续费安排、谈判空间等角度审查。
版本比对专员：如果有两个版本，负责识别新增、删除、修改条款，并说明变化影响。
报告整合官：收集各角色输出，合并重复信息，保留分歧观点，形成最终审查报告。

这里就引出了一个更重要的概念：Coordination Engineering，中文可以理解为"协同工程"。如果说 Agent Swarm 解决的是"让多个 Agent 一起工作"，那么 Coordination Engineering 解决的是"怎样设计这支团队才能稳定工作"。它关注的不是某个 Agent 的单点能力，而是整套协作系统的设计：需要哪些角色、谁先执行、谁可以并行、哪些上下文需要隔离、如何处理失败、何时重试、如何汇总、观点冲突时是否调和、最终交付格式是什么。

所以，在本文的合同审查实践里，Agent Swarm 是产品里的运行形态，Coordination Engineering 是背后的设计方法。我们不是简单地说"开几个 Agent"，而是在设计一条可复用的审查流水线：先提取事实，再让法律和商务两个角色独立判断，最后统一汇总。法律审查和商务审查最好相互隔离，因为如果两个角色提前看到对方观点，输出可能会趋同，反而失去多视角审查的价值。

JiuwenSwarm 的"集群模式"就是进入 Agent Swarm 协作的一种使用入口。在普通规划模式下，Agent 更像一个单人任务规划者；切换到集群模式后，系统会出现 team_leader，并允许它创建 teammate、建立任务 DAG、分派任务和汇总结果。实际执行时，可以在任务事件日志中看到 spawn_member、任务创建、成员执行等过程；右侧也会出现团队相关的任务或成员状态。这个过程让多 Agent 协作不再只是概念，而是变成可观察、可追踪、可复盘的执行流程。

进一步说，Swarm Skills 则是把这种协作经验沉淀下来。知乎文章里提到，Agent Swarm 解决的是"当下怎么协作"的问题，而 Swarm Skills 解决的是"协作模式如何沉淀、复用和进化"的问题。一个 Swarm Skill 通常包含 SKILL.md、roles/、workflow.md、bind.md、dependencies.yaml 等文件：SKILL.md 描述团队做什么，roles/ 定义每个成员负责什么，workflow.md 定义执行顺序和并行关系，bind.md 定义边界、失败处理和降级策略。这样一来，合同审查这类复杂流程就不再依赖每次临场写 Prompt，而可以沉淀成一套团队协作 SOP。

这也是我选择用 JiuwenSwarm 做合同审查辅助的原因。它适合的不是"让 AI 随便点评一下合同"，而是把合同审查拆成一套可执行、可复用、可迭代的多角色协作流程。对于法务/商务场景来说，这种 Agent Swarm + Coordination Engineering 的组合，正好可以把合同审查中的重复劳动、专业分工和跨部门沟通组织起来。

第二章：搭建 JiuwenSwarm 环境

为了避免污染宿主机环境，我采用虚拟环境安装方式，这也是官方推荐的安装方式。

基础环境包括：

bash 复制代码

python3.11 -m venv .venv
source .venv/bin/activate
pip install jiuwenclaw

安装完成后初始化工作区：

bash 复制代码

jiuwenclaw-init

如果希望把 JiuwenSwarm 的运行数据也隔离到项目目录，可以设置独立 home：

bash 复制代码

export JIUWENCLAW_HOME="$PWD/.jiuwenclaw-home"
jiuwenclaw-init

启动服务：

bash 复制代码

jiuwenclaw-start

实际使用中，我更推荐写一个本地启动脚本，把虚拟环境、数据目录和端口统一固定下来。例如：

bash 复制代码

#!/usr/bin/env bash
set -euo pipefail

ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
export JIUWENCLAW_HOME="$ROOT_DIR/.jiuwenclaw-home"

exec "$ROOT_DIR/.venv/bin/jiuwenclaw-start" "$@"

如果本机已有服务占用默认端口，也可以在 .jiuwenclaw-home/.jiuwenclaw/config/.env 中指定：

env 复制代码

FRONTEND_PORT=6173
WEB_PORT=20000
GATEWAY_PORT=20001
AGENT_SERVER_PORT=19092

...其余部分省略

启动后访问：

text 复制代码

http://localhost:6173

到这一步，一个相对干净、可重复、可迁移的 JiuwenSwarm 本地实验环境就搭好了。

但是要想使用其能力，还得配置大语言模型，在这里我选择是性价比较高的 deepseek v4 flash，配置完成后记得保存哦，否则不生效。

到此时，你可以可以让 JiuwenSwarm 帮你干活了。点击对话，然后输入你想问，比如：你的模型，正常回复那么说明你的配置是 OK 的了。

第三章：用 TeamSkillCreator 创建"合同审查辅助"Skill

安装 teamskill-creator（当然你也可以不预装，直接通过对话安装即可）

输入任务 Prompt，让其为我们创建 contract-review-helper 合同审查辅助。

请创建一个 Swarm Skill：contract-review-helper，中文名"合同审查辅助"。

用途：面向法务/商务，辅助合同条款提取、法律与商务风险标注、合同版本比对，并生成 Markdown 审查报告。

请自动设计适合 JiuwenSwarm Agent Swarm 的多角色协作流程、角色分工、输入输出格式和质量标准。要求谨慎专业，不替代正式法律意见，对不确定内容标注需人工确认。

生成完成后，TeamSkillCreator 会自动在指定目录下为你构建一套完整的"数字团队架构"。你会发现系统不仅生成了代码，更生成了一套完整的协作逻辑：

核心文件路径位于：.jiuwenclaw/agent/jiuwenclaw_workspace/skills/contract-review-helper-team

这套生成的 Skill 实际上完成了三件大事：

角色工厂化 ：自动定义了 contract_analyst（提取）、legal_expert（法律）、business_reviewer（商务）等独立角色。
流程 SOP 化 ：在 workflow.md 中规定了先提取、后审查、再比对的串并行依赖关系。
交付标准化：强制了输出必须为 Markdown 格式，且包含"人工确认"标注。

相比于传统的临场写 Prompt，这种方式将"个人经验"转化为了"团队资产"。Skill 不再只是一个会读合同的工具，而是变成了一套按照业务团队标准交付结果的自动化流水线。

第四章：Team 模式使用测试

开启团队模式：/mode team。

切换集群模式，输入 Prompt，让 Agent Swarm 帮我处理问题。

text 复制代码

使用 contract-review-helper-team 帮我对这份合同进行处理。

# 技术服务采购合同（示例）

甲方：星河智能科技有限公司  
统一社会信用代码：91110000MA00000001  
地址：北京市朝阳区示例路 88 号  
联系人：张经理  

乙方：云澜软件服务有限公司  
统一社会信用代码：91310000MA00000002  
地址：上海市浦东新区样本文创园 6 号楼  
联系人：李经理  

鉴于甲方拟采购企业知识库系统建设服务，乙方具备相关技术服务能力，双方经友好协商，就本项目达成如下合同条款。

## 第一条 服务内容

1. 乙方应为甲方提供企业知识库系统的需求梳理、系统配置、数据导入、权限设置、上线支持及基础培训服务。
2. 服务范围以本合同附件一《项目服务清单》为准。如甲方提出新增需求，乙方应优先配合完成，相关费用双方另行协商。
3. 乙方应保证服务成果能够满足甲方业务部门的实际使用需要。

## 第二条 服务期限

1. 本合同服务期限为自 2026 年 6 月 1 日起至 2026 年 8 月 31 日止。
2. 如因甲方未及时提供资料、接口、账号或业务确认导致项目延期，项目周期相应顺延。
3. 如乙方原因导致项目延期超过 15 个工作日，甲方有权要求乙方提交整改计划。

## 第三条 合同金额及付款方式

1. 本合同总金额为人民币 300,000 元整（大写：人民币叁拾万元整），含税。
2. 付款安排如下：
   - 合同签署后 10 个工作日内，甲方向乙方支付合同总金额的 30%；
   - 系统完成上线部署后 10 个工作日内，甲方向乙方支付合同总金额的 40%；
   - 项目验收通过后 60 个自然日内，甲方向乙方支付剩余 30%。
3. 乙方应在每次付款前向甲方开具合法有效的增值税专用发票。
4. 如甲方逾期付款，每逾期一日，应按逾期金额的万分之三向乙方支付违约金。

## 第四条 交付与验收

1. 乙方应按照项目计划提交阶段性交付物，包括需求确认文档、系统配置说明、数据导入记录、培训材料和上线报告。
2. 甲方应在收到乙方交付物后 10 个工作日内完成验收。如甲方未在期限内提出书面异议，视为验收通过。
3. 如交付物存在问题，乙方应在收到甲方书面意见后 5 个工作日内完成修改或说明。
4. 验收标准以甲方实际满意为准。

## 第五条 双方权利义务

1. 甲方应按约定向乙方提供项目所需资料、业务规则、测试账号及必要的系统访问权限。
2. 乙方应按照行业通常标准提供服务，并安排具备相应经验的人员参与项目。
3. 乙方未经甲方同意，不得擅自更换核心项目人员。
4. 甲方有权根据业务需要调整项目范围和交付时间，乙方应无条件配合。

## 第六条 知识产权

1. 乙方在履行本合同过程中形成的配置文档、培训材料、项目方案及定制化开发成果，其知识产权归甲方所有。
2. 乙方在项目实施前已经拥有的通用工具、框架、组件、模板及方法论，仍归乙方所有。
3. 未经甲方书面同意，乙方不得将本项目成果用于其他客户或公开宣传。

## 第七条 保密条款

1. 双方应对在合作过程中获知的商业秘密、技术资料、经营数据、客户信息、账号权限及其他非公开信息承担保密义务。
2. 保密期限自信息披露之日起至相关信息公开后终止；如信息未公开，保密期限永久有效。
3. 任一方违反保密义务，应赔偿守约方因此遭受的全部损失，包括但不限于直接损失、间接损失、律师费、公证费、调查费和维权支出。

## 第八条 违约责任

1. 任一方违反本合同约定，应承担继续履行、采取补救措施或赔偿损失等违约责任。
2. 乙方未按期完成服务且无正当理由的，每逾期一日，应按合同总金额的 1% 向甲方支付违约金。
3. 因乙方服务问题导致甲方业务中断、数据损坏、客户投诉或声誉受损的，乙方应赔偿甲方全部损失。
4. 本合同项下乙方承担的赔偿责任不设上限。

## 第九条 合同解除

1. 双方协商一致，可以解除本合同。
2. 如乙方严重违约且在甲方通知后 5 个工作日内未完成整改，甲方有权单方解除合同，并要求乙方退还已收款项。
3. 甲方因业务调整、预算变化或内部管理需要，可提前 7 日书面通知乙方解除合同，乙方应配合完成交接。
4. 合同解除不影响守约方追究违约方违约责任的权利。

## 第十条 不可抗力

1. 因地震、台风、洪水、火灾、战争、政府行为、重大疫情等不可抗力事件导致无法履行合同的，受影响方可部分或全部免除责任。
2. 受影响方应在不可抗力发生后 5 个工作日内通知对方，并在合理期限内提供证明材料。

## 第十一条 争议解决

1. 因本合同产生或与本合同有关的任何争议，双方应先友好协商解决。
2. 协商不成的，任一方可向甲方所在地有管辖权的人民法院提起诉讼。
3. 争议处理期间，除争议事项外，双方应继续履行本合同其他不受影响的条款。

## 第十二条 其他

1. 本合同附件与本合同具有同等法律效力。
2. 本合同未尽事宜，由双方另行签署补充协议。
3. 本合同自双方盖章之日起生效。
4. 本合同一式贰份，甲乙双方各执壹份，具有同等法律效力。

甲方：星河智能科技有限公司（盖章）  
授权代表：  
签署日期：2026 年 5 月 20 日  

乙方：云澜软件服务有限公司（盖章）  
授权代表：  
签署日期：2026 年 5 月 20 日  

> 说明：本合同为虚构示例文本，仅用于测试合同审查辅助流程，不构成真实交易文件或法律建议。

以下截图为运行时的截图，可以看到右侧的团队成员中，包含了 4 位成员，其中版本对的成员没有，因为我的示例合同为但版本的合同，不需要进行版本对比。

Team Leader 是团队的领导，虽然没在我们 roles 角色里面，但是在开启 Agent Swarm 任务时，他会自行创建，用以创建各个 SubAgent，然后做全局的调度。

测试结果显示，JiuwenSwarm 的 Agent Swarm 模式在处理此类复杂合同任务时，展现出了极强的工程化优势。

角色分工带来的专业稳定性

在单 Agent 模式下，AI 往往会把"事实提取"和"风险分析"混淆。而在 Team 模式下，每个成员只做一件事。例如，我们的 contract_analyst（提取员）非常精准地完成了信息结构化：

$产出片段$ 核心条款提取：

服务费用：人民币 300,000 元（含税）。

付款节奏：30%（预付）- 40%（上线）- 30%（验收后 60 日）。

违约金：逾期付款万分之三/日；逾期服务 1%/日。

这种"事实"与"观点"的分离，避免了 AI 在分析时产生幻觉，确保了底层数据的准确性。

深度视角隔离：法务 vs 商务

这是 Coordination Engineering 的核心体现：我们让法律审查和商务审查相互隔离。在最终的报告中，我们可以看到两个角色给出了完全不同的、但都极具价值的反馈：

维度	审查点	风险分析	建议事项
法律视角	赔偿责任上限	第八条第 4 款：赔偿责任不设上限。	高风险：极大增加乙方责任边界，建议设置合同总额 100% 的上限。
商务视角	尾款支付周期	第三条第 2 款：验收后 60 自然日支付尾款。	中风险：付款周期较长，可能影响现金流周转，建议缩短至 30 自然日。
法律视角	知识产权归属	第六条第 1 款：定制开发成果归甲方。	合规：符合行业惯例，但需确认是否包含乙方底层核心框架。

如果是单 Agent，它可能只会泛泛而谈"合同条款偏向甲方"，而 Agent Swarm 则精准地指出了**现金流（商务）与责任无限大（法律）**这两个完全不同的痛点。

结构化的复盘与可观察性

所有的审查结果最终会被汇总成一份清晰的 final-review-report.md。它不仅提供了结论，还保留了待人工确认的事项，这正符合我们"辅助而不替代"的设计初衷。

此外，对于多版本的合同，版本比对 Agent 也会独立产出清晰的对比表。它能精准识别出哪怕是一个字的变化（例如"直接损失"改为"全部损失"），这比肉眼校对或单纯的文本 Diff 要聪明得多，因为它能直接告诉你**"修改背后的法律影响"**。

总结：

这一套流程下来，JiuwenSwarm 的 Agent Swarm 模式实际上是在模拟一个微型法务部。它通过 Coordination Engineering 将复杂的"合同审查"拆解成了可交付、可审计的数字资产。

第五章：发布 Skill

首先登录到 SwarmSkillsHub。

然后点击发布，填写相关信息后点击发布。

发布之后，这个 Skill 就不再只是一次实验，而可以沉淀为团队可复用资产。后续每次遇到合同审查任务，法务或商务都可以直接调用同一套流程，减少重复提示词编写，也让审查口径更一致。

第六章：总结与回顾

这次实践让我最直观地感受到，JiuwenSwarm 的价值不在于让单个 AI 完成一个流程，而在于通过 Coordination Engineering（协同工程）将 AI 组织成一支专业的 Agent Swarm（多角色团队）去重构工作流。

这种基于 Coordination Engineering 的设计，配合其强大的"集群模式"，让 JiuwenSwarm 能够真正实现多 Agent 的并行协作。在执行任务时，它不再是排队式地问答，而是让多个 SubAgent 像一支训练有素的突击队同时切入不同维度。