1. 律所合同审查的真实痛点：为什么12分钟能成为分水岭
一份50页的租赁合同摆在面前，传统流程是逐字阅读、手动标注风险条款、再写修改建议，两三个小时就没了。我接触过几位做非诉业务的律师，他们最头疼的不是案子难，而是大量重复性条款识别占用了本该用于策略思考的时间。合同审查AI要解决的核心问题，就是把“找风险点”这件事从人肉扫描变成机器初筛，律师只做最终判断。
OpenClaw在这个场景里的定位，是一个可本地部署的文档处理自动化框架。它通过SOUL.md定义角色行为，通过MEMORY.md积累风险条款库，通过docxSkill生成Word报告，最终把单份合同审查压缩到12分钟左右。适合谁用？一是想切入法律科技的技术服务商，二是律所内部想提效的IT负责人，三是独立执业的律师想给自己配一个“初筛助手”。
我试过用三份样例合同跑端到端流程，从PDF解析到报告回传，整个链路跑通后，最耗时的环节其实是风险条款库的初始建设。但一旦库建起来，后续每份合同的审查就是“匹配+生成”的流水线作业。这篇文章会拆解从SOUL.md配置到目录监听、输出模板的完整落地路径，你可以直接复制配置片段去跑自己的样例。
2. TaoToken前置准备：模型接入与API Key配置
OpenClaw本身不绑定特定模型，它需要你提供一个兼容OpenAI接口的模型服务。这里我用TaoToken来做模型接入，因为它支持多模型切换，而且API Key管理比较清晰。你需要先拿到一个可用的Key，然后配置到OpenClaw的模型设置里。
2.1 获取API Key与Base URL
访问TaoToken的API Keys页面（https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys），创建一个新的Key。创建时注意权限范围，合同审查场景只需要对话补全权限，不需要开太多。拿到Key之后，Base URL填https://taotoken.net/api，这个地址不加UTM参数，直接用于代码里的请求地址。
模型ID的选择上，合同审查对长文本理解和指令遵循要求较高，建议选上下文窗口较大的模型。你可以在模型对话页面（https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=chat）先测试一下模型对法律条款的解析能力，确认输出格式稳定后再接入OpenClaw。
2.2 在OpenClaw中配置模型
OpenClaw的模型配置通常放在config/model.yaml或环境变量里。我习惯用环境变量，这样切换环境时不用改文件。在.env文件里写入：
OPENAI_API_KEY=sk-你的TaoTokenKey OPENAI_BASE_URL=https://taotoken.net/api OPENCLAW_MODEL_ID=你的模型ID然后在OpenClaw的Agent配置里引用这些变量。如果你用的是Cline或类似的MCP客户端，配置方式类似，核心就是三件套：Base URL、Key、Model ID。这三者缺一不可，尤其是Base URL末尾不要多加/v1，TaoToken的API地址已经包含了版本路径。
2.3 验证模型连通性
配置完成后，先跑一个最简单的请求确认链路通：
import os from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL") ) response = client.chat.completions.create( model=os.getenv("OPENCLAW_MODEL_ID"), messages=[{"role": "user", "content": "用一句话说明合同审查中'无限责任条款'的风险"}] ) print(response.choices[0].message.content)如果返回了合理的风险说明，说明模型接入没问题。这一步很关键，因为后面OpenClaw的文档处理流程都依赖这个模型通道。如果这里报401，先检查Key是否复制完整；如果报model not found，检查Model ID是否拼写正确。
3. 可复制配置：SOUL.md、MEMORY.md与目录监听
这一节是整篇文章的核心交付物。我会给出完整的SOUL.md配置片段、MEMORY.md风险条款库模板，以及目录监听的实现方式。你可以直接复制到自己的项目里，改一下律所名称就能用。
3.1 SOUL.md完整配置
SOUL.md定义Agent的角色、工作流、输出规范和安全边界。律所场景对数据安全要求极高，所以安全条款必须写死。
# SOUL.md - 律所合同审查专用 ## Soul 你是一个专业的法律文档处理助手，服务于{律所名称}。 你的职责是辅助律师进行合同初审，识别风险条款并生成修改建议。 你不提供法律意见，所有输出仅供律师参考。 ## 工作流 1. 收到合同PDF后，立即解析并提取全文文本 2. 按条款编号或段落结构分割条款 3. 逐条对照风险条款库（MEMORY.md）进行匹配 4. 生成包含以下内容的Word报告： - 执行摘要（不超过1页） - 风险条款清单（高风险红色、中风险黄色、低风险绿色标注） - 修改建议（每个风险条款附具体修改方案） - 遗漏条款提示（常见保护条款缺失检测） 5. 报告通过飞书或指定目录回传 ## 输出规范 - 文档格式：Word（.docx），通过docxSkill生成 - 每份报告必须标注：本报告由AI辅助生成，仅供律师参考，不构成法律意见 - 报告命名规则：{合同编号}_审查报告_{日期}.docx ## 数据安全 - 客户文档不得保存超过72小时 - 不得向任何外部API发送文档原文，仅发送摘要或问题片段 - 所有操作记录写入安全日志（security.log） - 禁止将文档内容用于模型训练这个配置里，工作流部分明确了从解析到回传的每一步，输出规范里强调了免责声明和命名规则，数据安全部分划定了三条红线。律师最关心的就是“文档会不会泄露”，所以72小时删除和禁止发送原文这两条必须写进SOUL.md，让Agent在每次处理时都遵守。
3.2 MEMORY.md风险条款库模板
MEMORY.md是审查准确率的关键。初始版本不需要太复杂，覆盖常见的高频风险条款即可，后续根据律师反馈逐步扩充。
# MEMORY.md - 风险条款库 ## 高风险条款 ### 无限责任条款 - 关键词：任何情况、全部损失、无限连带、不设上限 - 风险说明：可能导致我方承担超出预期的赔偿责任 - 修改建议：将“无限责任”修改为“不超过合同总金额的XX%” ### 单方解约权 - 关键词：甲方有权单方解除、无需任何理由、随时终止 - 风险说明：赋予对方过于随意的终止权，缺乏商业确定性 - 修改建议：增加“需提前XX日书面通知”及“仅在特定违约情形下可解除” ### 知识产权归属不清 - 关键词：知识产权归双方共有、未明确归属 - 风险说明：权属不清可能导致后续商业化障碍 - 修改建议：明确约定知识产权归委托方所有，或按贡献比例分配 ## 中风险条款 ### 保密期限过长 - 关键词：永久保密、无限期、长期有效 - 风险说明：长期保密义务可能影响商业灵活性 - 修改建议：保密期限缩短至合同终止后3年 ### 付款条件模糊 - 关键词：验收后付款、满意后支付、另行约定 - 风险说明：付款触发条件不明确，可能导致回款延迟 - 修改建议：明确验收标准和付款期限，如“验收合格后15个工作日内支付” ## 低风险条款 ### 通知送达地址 - 关键词：以邮件方式送达、仅限书面 - 风险说明：单一送达方式可能被过滤或遗漏 - 修改建议：增加“邮件、短信、邮寄”三种方式，以最早到达为准 ## 遗漏条款提示（常见保护条款） - 知识产权归属条款（若涉及技术开发） - 不可抗力条款（标准格式） - 争议解决条款（明确仲裁机构或法院） - 数据保护条款（若涉及个人信息）这个库的结构是“风险等级→条款类型→关键词→风险说明→修改建议”。匹配时先用关键词做粗筛，再用语义相似度做精排。你可以根据自己服务的律所业务方向，增删条款类型。比如做劳动法业务的，就把竞业限制、加班费计算等条款加进去。
3.3 目录监听与自动触发
OpenClaw支持文件系统监听，你可以配置一个上传目录，当有新PDF放入时自动触发审查流程。配置文件openclaw-config.yaml：
watch: enabled: true directory: "/data/contracts/uploads" pattern: "*.pdf" output_dir: "/data/contracts/reports" cleanup_after_hours: 72 feishu: enabled: true app_id: "your_app_id" app_secret: "your_app_secret" webhook_url: "https://your-server/feishu" docx: template: "/data/templates/report_template.docx" skill: "docxSkill1"目录监听的好处是律师不需要学新工具，把合同拖进共享文件夹就行。输出目录单独设置，方便后续归档。cleanup_after_hours设为72，配合定时任务实现自动删除。
3.4 安全清理与日志审计
定时清理用crontab实现：
# 每天凌晨3点删除72小时前的上传文件 0 3 * * * find /data/contracts/uploads -type f -mtime +3 -delete日志审计记录每次操作：
import logging import json from datetime import datetime logging.basicConfig(filename='security.log', level=logging.INFO) def log_operation(client, file_name, operation, status): log_entry = { 'timestamp': datetime.now().isoformat(), 'client': client, 'file': file_name, 'operation': operation, 'status': status } logging.info(json.dumps(log_entry))这两段代码不复杂，但它们是合规的底线。律所客户如果问“你怎么保证文档安全”，你就把SOUL.md的安全条款、crontab清理任务和日志文件一起给他看。
4. 端到端验证：用3份样例合同跑通全流程
配置写好了，接下来要用真实样例验证。我建议准备三份不同类型的合同：一份租赁合同、一份服务合同、一份NDA。每份合同里故意埋几个风险条款，看看系统能不能准确识别。
4.1 验证步骤
第一步，把三份PDF放入/data/contracts/uploads目录。目录监听触发后，OpenClaw会依次处理。你可以在日志里看到每个文件的处理状态。
第二步，观察PDF解析结果。合同PDF解析后可能丢失条款编号结构，需要检查分割逻辑是否合理。如果条款分割太碎或太粗，调整分割策略。我用的策略是：先按“第X条”正则匹配，匹配不到再按空行分段，最后用LLM辅助判断语义边界。
第三步，检查风险匹配结果。高风险条款应该被红色标注，中风险黄色，低风险绿色。如果某个明显的高风险条款没被识别，检查MEMORY.md里是否有关键词覆盖，或者语义相似度阈值是否设得太高。
第四步，查看生成的Word报告。报告应该包含执行摘要、风险清单、修改建议、遗漏条款提示四个部分。免责声明必须在报告开头或结尾显眼位置。
4.2 成功结果示例
以租赁合同为例，系统在12分钟内输出了以下内容：
执行摘要部分指出“本合同存在3处高风险条款、2处中风险条款，建议重点修改无限责任条款和单方解约权条款”。风险清单里，无限责任条款被标红，附上了“修改为不超过合同总金额的200%”的建议。遗漏条款提示里提醒“未约定争议解决方式，建议增加仲裁条款”。
三份合同跑完，总耗时约36分钟，平均每份12分钟。这个时间包括PDF解析、条款分割、风险匹配、报告生成和回传。如果模型响应快，可以压缩到10分钟以内。
4.3 验证中的关键指标
你需要关注三个指标：召回率、准确率、处理时间。召回率是指风险条款被识别的比例，准确率是指识别出的风险条款确实有风险的比例。初始版本召回率可能只有70%左右，通过扩充MEMORY.md和调整匹配阈值可以逐步提升到90%以上。处理时间主要受模型响应速度和PDF页数影响，50页以内的合同基本能控制在12分钟。
5. 常见报错排查：401、local proxy failed与OAuth问题
接入过程中最容易卡在几个报错上。我整理了自己踩过的坑和对应的排查路径。
5.1 401 Unauthorized
这个报错说明API Key无效或未正确传递。排查顺序：先确认.env文件里的OPENAI_API_KEY是否复制完整，有没有多余空格；再确认Base URL是否写成了https://taotoken.net/api，末尾不要加/v1；最后确认Key的权限是否包含对话补全。如果用的是Cline或MCP客户端，检查配置文件里的Key字段名是否正确，有些客户端用apiKey，有些用api_key。
5.2 local proxy failed
这个报错通常出现在本地代理配置冲突时。OpenClaw如果同时配置了系统代理和模型API地址，可能会走错通道。排查方法：检查环境变量里是否有HTTP_PROXY或HTTPS_PROXY，如果有，把TaoToken的域名加入NO_PROXY列表。另外确认OpenClaw的模型配置里没有重复设置代理。
5.3 reading choices 报错
这个报错说明模型返回的响应结构不符合预期。常见原因是模型ID填错了，或者请求参数里的response_format设置与模型不兼容。排查方法：先用模型对话页面测试同一个模型ID，确认能正常返回；然后检查OpenClaw的请求参数，把response_format暂时去掉，看是否恢复正常。
5.4 OAuth 相关报错
如果你用的是Claude Code或Codex这类需要OAuth认证的工具，报错可能出现在token刷新环节。排查方法：确认auth.json或settings.json里的认证信息是否过期；如果是Codex，检查~/.codex/auth.json里的access token是否有效；如果是Claude Code，检查~/.claude/settings.json里的Base URL和Key配置。这三件套（Base URL、Key、Model ID）在任何工具里都必须完整且一致。
5.5 条款分割异常
如果报告里条款分割混乱，比如把一条完整的条款拆成好几段，或者把好几条合并成一段，需要调整分割策略。我用的正则表达式是第[一二三四五六七八九十百千]+条和\d+\.\d+，匹配不到时回退到按空行分割。如果合同格式特别不规范，可以在SOUL.md里加一条“遇到无法分割的条款，保留原文并标注‘需人工复核’”。
6. 从审查到交付：CTA与长期编码方案
跑通验证之后，下一步是把它变成可交付的服务。如果你只是自己用，把目录监听和定时清理配好就行。如果你要服务律所客户，需要考虑多租户隔离和私有化部署。
多律所隔离的做法是给每个律所创建独立的记忆空间和上传目录。OpenClaw支持通过tag区分不同客户的数据：
openclaw memory import contract.pdf --tag lawfirmA openclaw memory import contract.pdf --tag lawfirmB这样风险条款库和文档互不干扰。私有化部署则把整个OpenClaw实例部署在律所内网，模型调用走TaoToken的API通道，文档原文不出内网。
如果你打算长期做法律科技方向的编码和Agent开发，可以关注Coding Plan（https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan），它适合需要频繁调用模型进行代码生成和调试的场景。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc，里面有完整的API参数说明和示例代码。模型对话入口在 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=chat，你可以先用它测试不同模型对法律文本的理解能力，再决定用哪个模型接入OpenClaw。
最后说一个实用技巧：风险条款库不是一次建完的。每次律师修改了报告里的风险等级或修改建议，你都应该把这条反馈记录到MEMORY.md里。比如律师把某个低风险条款改成了高风险，你就在对应条款下加一条“根据律师反馈，此条款风险等级调整为高”。这样跑三个月，你的风险库会越来越贴合实际业务，审查准确率也会明显提升。
