procurement-contract-review

name	procurement-contract-review
description	采购合同专项知识注入审查 skill

0. 目标

作为资深的法务对用户上传的合同进行审查，检查其中存在的风险（包括文本内部不一致、法律风险、商业风险、条款缺漏风险）并提出修改意见。

1.1 读取合同并获取基础信息

读取主合同与全部附件 / 附录 / 补充协议

记录：

• {file_id}：主合同的真实 file_id（多文件取主合同）；不得改用文件名/标题
• {contract_type}：合同类型

应当通过合同的核心交易目的和主要给付义务判断合同类型，标题仅可作为参考。例如，例如，合同约定甲方向乙方购买一批服务器、交换机及配套软件，乙方负责按附件清单供货，并完成基础安装、调试和验收，则为典型的【采购合同】。

##1.2 让用户选择清单与审查立场

向用户输出：

合同类型：[ ]
已识别当事方：
[当事方展示文本 1]
[当事方展示文本 2]

请确认本次代表哪一方审查。

依次调用 RecommendChecklist → CollectRiskReviewContext，等用户回答后从对话上下文提炼并记录用户选定的审查立场，即 {user_party}（用户在 CollectRiskReviewContext 中选定的当事方展示文本原文；不得缩写、改写或补充角色）。

2. 生成审查计划

需要读取 references/planning.md，按照指引排派出多个subagent执行分层审查计划。

调用一次 result 初始化工具并记录 {available_result_tags}（含 name 与可能为空的 description）；result 初始化不绑定清单。 如果测试环境或当前运行环境没有 result 初始化工具，不得中断审查；记录为“无 result 工具，最终使用聊天输出兜底”。

3. 并行审查

3.1 并行启动 L1 / L2 / L3 /L4(如有）/ C1

L1：文本/结构基础校验。 L2/3/4（如有）：采购合同法律和商业风险校验调度。 C1：独立机制补漏复核。

-本步骤不得把 L1、L2、C1 的审查对象相互混同：L1 只做文本/结构基础校验，L2 只审查既有条款内部的法律和商业风险，C1 只审查现有文本之外的独立机制缺漏。 -启动 subagent 时，不得在 skill_id 为空时传入 skill_ref_paths；否则会导致子任务启动失败。如果需要子任务读取某个 reference，应在子任务说明中写明“读取/参考 references/xxx.md”，或在工具支持时同时传入当前 skill 的 skill_id 与对应 skill_ref_paths。 -主 agent 在 references/planning.md 中生成的 review_point_groups、候选风险清单、交易环节分组和重点审查点，只能用于 L2/L3/L4（如有）的任务派发。L1 和 C1 均为独立审查任务，不得接收、继承或受限于主 agent 为 L2/L3/L4(如有） 生成的审查点；派发 L1/C1 时只传入合同文本、用户审查立场、合同类型、任务边界和对应 reference。

3.2 L1 文本/结构基础校验

L1 需要读取 references/l1_text_structure.md进行审查。L1为不同合同类型的通用步骤。

任务目标：

• 检查合同文本、附件、签署页、引用条款、编号、定义、主体信息、金额、期限、签署与生效、附件效力顺位等基础完整性问题。
• 检查文本缺失、引用断裂、附件缺漏、前后不一致、主体/签署/收款/开票信息不一致等问题。
• 不展开采购法律和商业风险专项分析；如发现明显采购风险，只作为结构或信息缺失问题提示。

3.3 L2/3/4(如有） 法律和商业风险校验

仅当合同类型为采购合同时读取 references/procurement.md。执行L2/3/4（如有）任务的subagent均须读取该reference并参考其中所涉及或对应的部分。

任务目标：

• L2/3/4(如有）应当参考references/procurement.md中的采购合同审查清单并结合AI自身的推理能力，对合同的法律风险和商业风险进行审查，站在用户选定的立场，只输出对用户选定立场不利或需确认的既有条款问题。
• L2/3/4 负责已有机制内部的模糊、不可执行、证明困难、权责失衡、救济不足、内部要素不足、管辖不利、责任过重等风险；一级机制缺漏的问题不得交给 C1。例如，没有知识产权约定应当由C1检查，约定了知识产权问题、但没有具体约定应受知识产权保护的范围和有关的违约责任则应当由L2检查。

3.4 C1 独立机制补漏复核

仅当合同类型为采购合同时读取 references/completeness.md。

任务目标：

• C1 的任务是检查现有文本之外是否还缺少应独立约定的关键机制或处理路径。需要结合合同的具体内容和类型，结合references/completeness.md中的基本必要条款和AI自身的推理能力检查是否有应约定但未约定在文本中的条款或机制。
• C1 不重新评价已有机制内部写得是否充分、合理或完整；已有机制内部的条款模糊、要素不足、责任失衡、救济不足等问题均由 L2/3/4 处理。

5. 聚合与输出

5.1 聚合

全部并行任务返回后，先读取 references/consolidation.md；读取完成前不得整理结果、合并风险或生成最终结论。

按 references/consolidation.md 完成：

• 默认信任 L1/L2/L3/L4(如有）/C1 已完成有效性判断，聚合阶段不重新审查合同。
• 先建立来源发现承接表；每条 L1/L2/L3/L4(如有）/C1 来源发现必须被标记为：保留为独立结果、合并进某个结果、删除。
• 删除只限于明显重复、明显对 {user_party} 有利、明显无合同事实或缺失机制支撑、明显越界的事项；不得因同一条款已有其他风险，就丢弃损害路径不同的来源发现。
• 按 group_key 分组、按 dedupe_key 去重；不做无必要的全量两两比较，但必须完整承接每条来源发现的处理去向。
• dedupe_key 相同的保留信息更完整、风险等级更高的一条；dedupe_key 不同的，即使同一条款也作为独立子问题保留。
• 输出前不得暴露 group_key、dedupe_key、issue_type 等内部字段。

5.2 输出

随后读取 references/output.md，生成最终审查结果。聚合阶段仍应内部统一风险等级和结果标签，至少包括：

• 高风险
• 中风险
• 低风险
• 仅提示

最终面向用户输出时，不强制使用 【风险等级｜结果标签】 标签样式；应在 审查结论 中自然体现风险类别和处理建议。

最终面向用户输出时，不输出任务来源、内部并行过程、聚合去重过程或其他内部工作记录；只输出聚合后的审查意见、需确认事项和建议补充材料。

最终结果中的每个问题至少包含：

审查结论:
风险分析:
原文定位:
建议增加位置/建议修改位置: <缺失类风险输出建议增加位置；非缺失类输出建议修改位置>
建议条款文本:

如果当前环境提供 result_* 结构化结果工具，应优先通过工具提交最终审查结果；聊天中只做极简说明。提交和修复时必须遵守：

• 先提交已确认可定位、可执行的结果；不要为了一个定位不确定的结果阻塞全部结果。
• 调用 result_add_entries 前必须完成提交前自检：定位格式、anchor_text 命中、缺失类新增方式、同一实际修改位置合并、法律依据覆盖均已检查通过；未通过的条目先修正或转为需确认事项，不得先提交等待 verify_result 报错。
• 定位格式自检：risk_description、原文定位和用户可见定位中不得裸写 L数字、L数字-L数字、合同L数字、第L数字行，必须写成 @@L数字@@ 或 @@L数字-L数字@@；不需要定位时删除裸行号。
• 合并自检：按实际修改位置分组检查待提交结果；同一 line_ref、同一表格行、同一条款句子或同一建议新增/修改位置下有多个子问题时，先合并为一个结构化结果后再提交。
• 合并不是覆盖：被合并来源发现的审查点/子问题名称、核心风险事实、修改目标必须进入保留结果的 review_point、risk_description 或 modifications；不得只保留同条款的其他风险。
• 法律依据自检：如本轮启用法规检索或结果中需要引用法律依据，应在第一批结果提交前完成检索，并确保至少一条相关结果已填写合法的 legal_basis_ids。
• 若 result_add_entries、result_patch_entries 或 verify_result 返回 rejected / failed / pending-failed-result，只修复返回中列明的失败条目，不重复提交已 applied 的条目。
• 若 verify_result 返回 duplicate-modification-line-ref 或提示多个结果修改同一条款/同一行/同一修改位置，必须先 result_patch_entries 补强保留结果，显式承接将被删除结果的核心风险事实和修改目标，再 result_delete_entries 删除重复结果；不得裸删。
• 修复定位失败时，优先读取对应 line_ref 附近原文，重写该条的定位和修改建议；不得凭记忆或表格坐标继续提交。
• 如果失败原因为 anchor_text 未在合同中命中、missing-location-token 或“缺少定位信息”，必须将 anchor_text 改成合同原文中逐字存在的最短必要文本；不要把“表格第3行第6列”“附件表格”“L31”这类定位说明写进 anchor_text。
• 修复完成后再次调用校验工具；只有校验通过，或只剩无法由 AI 安全修复且已转为“需用户确认/人工复核”的事项时，才结束。