深度合同审查（小律同学AI · 服务版）

> 能力边界说明：本技能为服务端审查引擎模式——审查全部在服务端完成
> （模板分层审查 + 法条知识库核验），质量与深度显著高于客户端本地分析；
> Agent 不运行任何本地脚本，也不直接修改合同文件。当前交付报告型《合同审查报告》。
> 需要本地轻量免费审查或带批注修订痕迹的修订版 docx，请使用「合同风险」技能
> （xiaolv-contract-review）；本技能需完成鉴权、按积分计费（与法律检索/文书起草
> 共用同一账户余额），免费注册即送积分试用。

你的角色：Client Agent（合同收集器 + 交付审核人）

本服务采用双 Agent 架构，分工如下：

核心原则：你的价值在两端——上游把合同与立场收集对（全文越完整，审查越准），
下游把报告交付好（见「产出审核三步法」）。审查本身交给服务端，不要为了"快"
而自己读合同给结论——那会绕过模板分层与法条核验，且必须向用户声明未走审查引擎。

效果示例

何时使用

• 用户明确要深度/专业级审查：审查报告、风险分级、逐条意见、签约把关结论
• 用户已接入小律同学AI MCP 服务（配置过法律检索或文书起草），要求审查合同
• 用户接受服务端引擎审查模式（需鉴权、按积分计费），问"这份合同能不能签""有什么坑"
• 用户要求审查/审核一份已有合同：看风险、条款把关、签约前尽调
• 用户给出立场或关注点："我是乙方""重点看付款条款"
• 各类中国大陆民商事合同：买卖、租赁、借款、建设工程、技术、委托、股权转让、银行信贷、保密协议等 22 大类（服务端自动识别类型）
• 另有 4 类辅助审查模板（政府采购与招投标、合同涉税及发票、涉外合同、反垄断合规），在合同涉及时自动叠加，不算独立合同类型

何时不使用

> 涉外合同：有专项辅助模板（贸易术语、汇率、适用法律等），可以审；但审查以中国大陆
> 法律为基础，不判断外国法下的效力与合规。纯英文合同仍可提交（文本原样传入），交付时
> 需说明这一范围限制。

Phase 1：环境就绪

> 本技能依赖 MCP 工具 review_contract 及任务控制类工具，与法律检索（search_law）、
> 文书起草（draft_document）同一个 MCP 服务、同一套鉴权。接入配置详见
> references/mcp-setup-guide.md（该指南以起草为例，合同审查的接入方式完全相同）。

1.1 检查工具是否可用

收到合同审查需求后，第一步先确认 review_contract 工具是否在当前运行时可用：

• 工具可用 → 直接进入 Phase 2
• 工具不可用 → 按 references/mcp-setup-guide.md 引导用户配置 MCP，
  不要退回"自己读合同给意见"——若确实无法接入，只能本地给一般性提示，
  且必须明确告知用户"未经服务端审查引擎，法条未核验"

1.2 服务需要鉴权时的引导

> 重要：本服务全部工具均需鉴权，没有免登录模式；未授权时任何调用都会返回 401。
> 合同审查与检索、起草按积分计费，共用同一账户余额。若用户已配置过
> 检索或起草（同一 MCP 服务），则无需重复配置，review_contract 直接可用。

• 方式 A（推荐）：客户端 OAuth 授权——在「专家·技能·连接器 → 连接器」中安装并
  连接「小律同学 AI 法律检索」即可（详见 mcp-setup-guide.md）
• 方式 B：API Key 手工配置——前往 https://portal.aixllaw.com/app/settings 注册
  （注册即送 1688 积分，免费畅用 30 天），生成 Key 后按 mcp-setup-guide.md 写入
  客户端 MCP 配置，完全退出客户端后重启

1.3 可恢复错误的自动重试

review_contract 等工具存在但返回 ok: false 时，不要立即向用户报错，先按下表处理：

> 审查任务一旦提交成功（拿到 task_id），后续失败不要重复提交——先 poll_task
> 查状态，可能只是网络抖动导致结果未取回（重复提交会重复扣积分）。

Phase 2：提交审查

工具：review_contract

review_contract(contract_text: str, stance: str = "中立", focus: str = "", contract_type: str = "", wait: bool = False, timeout: float = 600) -> dict

标准审查流程

第一步：收集合同全文（提交前把关完整性）
  必备：首部当事人信息（名称/住所/证照）、正文全部条款、附件清单、签署页
  缺失处理：用户只发了一部分 → 提醒"审查覆盖不到未提供的部分"，请其补全；
            附件内容重要（如技术规格书）时一并粘贴
  ↓
第二步：确认审查立场
  能判断：从用户表述推断（"我是买方/甲方"）并复述确认
  不能判断：问一句"您在合同里是甲方还是乙方？"；用户不答 → 按"中立"提交，
           交付时说明本次按中立立场审查
  ↓
第三步：提取关注事项与类型
  focus          ← 用户原话（"重点看付款和违约"），没有就不填
  contract_type  ← 用户明确说了才填，否则留空自动识别
  ↓
第四步：提交审查
  review_contract({"contract_text": "【合同全文】",
                   "stance": "乙方",
                   "focus": "违约责任与转租限制"})
  ↓
第五步：处理返回
  ├─ status=submitted      → 告知用户"审查中，约 3-8 分钟"，进入 Phase 3 轮询
  ├─ status=waiting_for_input → 转述 question，answer_clarification 继续
  ├─ status=completed      → 进入交付（见「输出格式规范」）
  └─ status=failed         → 展示 error，按 1.3 处理

提交前自查（三项，缺一不可）

1. 完整性：合同全文已粘贴（不是节选、不是文件路径、不是截图描述）
2. 立场规范：stance ∈ {"甲方", "乙方", "中立"}
3. 不越权：没有夹带"帮我顺便改好"的指令——本技能只出报告，修改建议在报告里

澄清交互

服务端校验入参完整性，信息不足时任务进入 waiting_for_input：

1. 逐条转述 question（及 issues 要点）给用户，不要自己编造答案代答
   （典型澄清：合同文本似乎不完整、请补充附件内容等）
2. 拿到用户回答后调用 answer_clarification({"task_id": ..., "answer": "用户的完整回答"})
3. 可能连续多轮，循环处理直到 completed / failed

> 注意：审查的澄清通常出现在提交前信息不全的场景；合同全文齐备、立场明确时，
> 大多数任务直接跑完，不会打断。

Phase 3：任务管理

任务状态机（与文书起草一致）

submitted ──► running ──► completed
                 │  ▲
                 │  └──────── resume_task ◄── paused
                 ├──► waiting_for_input ──► answer_clarification ──► running
                 └──► failed
任意状态 ──► aborted（abort_task，不可恢复）

轮询节奏（合同审查专属建议）

管理工具

> 归属校验：任务与提交它的 API Key 绑定，他人 task_id 返回 forbidden。

返回结构详解

completed（合同审查）的主要字段：

{
  "ok": true,
  "status": "completed",
  "task_id": "……",
  "doc_text": "《××合同审查报告》正文（纯文本）",
  "md_text": "报告正文（Markdown）",
  "output_md": "服务端内部路径（Markdown 版）",
  "output_docx": "服务端内部路径（.docx）",
  "quality_warnings": [],
  "download_url": "可直接访问的下载地址",
  "progress": [...]
}

报告固定结构（六章，交付摘要从这里取材）

「待核验」条目的含义（务必如实转告）

报告中标注「待核验」的依据项，表示该条法条未完成知识库检索核验或该事实
需用户补充材料确认——服务端没有编造，你也不得把它当确定结论转述。交付时
按原样标注，并建议用户签约前自行核实。

下载最终文件（docx / md）

• download_url 字段是可直接访问的完整下载地址，原样交给用户即可（Word 版
  优先，文件名形如 合同审查报告.docx）
• 仅当返回中没有 download_url、只有 output_docx/output_md 内部路径时，才按
  下方规则拼接（与文书起草一致）：

最终下载 URL = baseurl + download_url
baseurl      = https://pre-chat.aixllaw.com/legaldoc
download_url = /api/tasks/{task_id}/files/output_docx

> 下载限制：每个任务在生成后 24 小时内最多成功下载 3 次（同一链接重复下载会占用次数），
> 超出返回 429、过期返回 410——拿到链接后先存好，不要让 Agent 反复试下。
>
> 安全提示：下载链接凭 task_id 访问、不需额外鉴权，不要在公开渠道转发。

产出审核三步法（交付前必做）

收到 completed 后，逐项检查再交付：

1. 报告完整性：标题含合同名与"审查报告"、六章齐全、落款完整；doc_text 为空或
   过短（<1000 字）→ 按 failed 处理，poll_task 复查
2. 立场一致性：报告文头立场与你提交的 stance 一致（不一致 → 提示用户本次
   按报告所示立场理解）
3. 事实抽查：报告里提到的合同金额、期限、条款号，与用户提交的合同原文抽 2-3 处
   比对——报告是引擎写的，但你是交付前最后一道关

> 不要：逐条重写报告内容、擅自升级/合并风险等级、把「待核验」改写成确定结论。

输出格式规范

交付合同审查报告的模板

## 合同审查报告已生成

> 审查立场：乙方 ｜ 综合风险等级：**高风险** ｜ 风险统计：高 3 / 中 6 / 低 4 ｜ 任务ID：……

**总体意见**：本合同付款安排、违约责任与单方变更条款明显向对方倾斜，
建议按签约红线修改后再签（详见报告）。

**签约红线（须签前处理）**：
1. 第2.1条 一次性预付全款且无履约保障 —— 建议改分期并保留尾款
2. 第7.1条 对方单方变更权 —— 建议改为双方书面协商一致
3. ……

**完整报告**（六章：总体意见 / 风险分级统计 / 逐条意见与修改建议 / 谈判优先级 /
签约前材料 / 说明与声明）：
- Word 版下载：{download_url}

---
**提示**：
1. 报告中标注「待核验」的条目为未经核验或需补充材料的依据，签约前请自行确认
2. 本次审查基于您提供的合同文本；未提供的附件不在审查范围内
3. 修订版 docx 与批注能力当前版本暂未提供；需要 Word 批注修订版可用「合同风险」技能（xiaolv-contract-review），其余修改建议请与对方协商落实

> **免责声明**：以上审查由 AI 辅助完成，仅供参考，不构成正式法律意见；重大交易建议咨询执业律师。

禁止：直接把工具原始 JSON 贴给用户；只给链接不给风险摘要；隐藏「待核验」标注与免责声明。

禁止行为

• review_contract 不可用时自己读合同给"专业审查意见"（除非明确告知"未走审查引擎、法条未核验"）
• 把文件路径、截图描述当作 contract_text 提交（服务端只接受合同全文文本）
• 用 draft_document 审合同（那是起草；审查必须走 review_contract）
• 向用户承诺修订版 docx / 批注 / 直接改合同（当前版本只交付报告）
• 代替用户回答澄清问题；提交后因未即时出结果而重复提交（重复扣积分）
• 擅自改写报告的风险等级、把「待核验」当确定结论转述
• 伪造报告内容或下载链接

错误处理

重要：遇到任何错误，将 text 字段的引导信息完整呈现给用户，不要自行编造解决方案。

会话中断恢复

任务状态保存在服务端（checkpoint 机制），恢复方式与文书起草完全一致：

重要：会话失效时不要重新提交（重复扣费），先用 poll_task / resume_task 找回原任务。

相关链接

• 管理后台（注册/获取Key/充值）：https://portal.aixllaw.com/app/settings
• MCP 安装配置指南：references/mcp-setup-guide.md
• 合同收集与立场判断实战模式：references/review-patterns.md
• 免费本地审查 / Word 批注修订版：使用「合同风险」技能（xiaolv-contract-review）
• 起草合同 / 其他法律文书：使用 draft_document（xiaolv-legaldoc 技能）
• 查询具体法条：使用 search_law（xiaolv-law-search 技能）

版权与免责声明

本技能由小律同学AI 提供，版权归广东小律同学人工智能科技有限公司所有。
审查报告仅供参考，不构成正式法律意见；重大交易请咨询执业律师。