当前位置：首页 > news >正文

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

news 2026/5/15 9:53:35

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

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

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

第一章：认识 JiuwenClaw、Agent Team 与集群模式

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

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

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

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

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

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

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

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

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

第二章：搭建 JiuwenClaw 环境

为了避免污染宿主机环境，我采用虚拟环境安装方式，这也是官方推荐的安装方式。推荐使用 Python 3.11，因为它处在 JiuwenClaw 当前依赖兼容范围内，也更适合稳定运行。

基础环境包括：

python3.11-mvenv .venvsource.venv/bin/activate pipinstalljiuwenclaw

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

jiuwenclaw-init

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

exportJIUWENCLAW_HOME="$PWD/.jiuwenclaw-home"jiuwenclaw-init

启动服务：

jiuwenclaw-start

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

#!/usr/bin/env bashset-euopipefailROOT_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中指定：

FRONTEND_PORT=6173 WEB_PORT=20000 GATEWAY_PORT=20001 AGENT_SERVER_PORT=19092 ...其余部分省略

启动后访问：

http://localhost:6173

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

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

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

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

安装 teamskill-creator（当然你也可以不预装，直接通过对话安装即可）
输入任务 Prompt，让其为我们创建 contract-review-helper 合同审查辅助。

请创建一个 Team Skill：contract-review-helper，中文名“合同审查辅助”。 用途：面向法务/商务，辅助合同条款提取、法律与商务风险标注、合同版本比对，并生成 Markdown 审查报告。 请自动设计适合 JiuwenClaw Agent Team 的多角色协作流程、角色分工、输入输出格式和质量标准。要求谨慎专业，不替代正式法律意见，对不确定内容标注需人工确认。

生成完成后，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 Team 帮我处理问题。

使用 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 Team 任务时，他会自行创建，用以创建各个 SubAgent，然后做全局的调度。

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

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

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

[产出片段] 核心条款提取：
服务费用：人民币 300,000 元（含税）。
付款节奏：30%（预付）- 40%（上线）- 30%（验收后 60 日）。
违约金：逾期付款万分之三/日；逾期服务 1%/日。

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

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

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

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