最近一两个月，我看到不少团队在做“合同AI审查”时用的是一个很像话术模板的流程：把合同扔进来，给模型一条很长指令，让它“逐条风险分析”，再拿输出结果去会签。

问题不在模型理解不够，而在于“模型当了万能中间人”。
我见过一次看起来合理的审查结论，最后还是因为版本、付款条款和条款衔接问题卡死：
文本里有“已修订”字样，但系统默认读取的是旧版本；
付款节点写了“验收后”，但合同正文对应的是“里程碑验收前预付款”；
法务要求的授权条款是第三版修订，却沿用了第一版模板。

这种错不是“模型不聪明”。是流程设计里没有把“谁负责什么、什么时候停、怎么回写”说清楚。

先说真实发生过的坑

坑一：把“找风险”当成“能放行”

当时我们拿到的合同里，AI给出的结论通常是“风险较低、建议先行谈判”。这句话很顺耳，但它没告诉我两个关键问题：

• 哪个条款是高风险？
• 能不能自动放行，为什么不能？

如果连判断边界都不写，后面很容易把“可疑”当“可通过”。这类项目最后最怕的不是错过某一个点，而是错把一个待确认当成已确认。

坑二：一个Agent把“提取—判断—修改”都做了

我早期也喜欢让一个模型做全程，结果问题很快出现。它会先提取关键条款，再判断是否合规，再给修改建议。

第一遍看起来像“自洽”——因为修改建议就是它自己认同的判断。
第二遍复核的时候就会发现：有些建议和最初提取冲突，尤其在付款、交付和违约条款上最容易出现“自循环修正”。

坑三：法条、规则和版本没做到“硬闸”

合同场景里有些问题很机械，但模型最擅长的是文本生成。比如版本变更顺序、附件生效范围、签署页编号、附件与正文映射。
这些点靠自由输出很容易“写得像样”，却没有执行到位。

我们后来加了一个做法：
只要版本字段不稳定、付款条件含糊、关键附件缺失，就直接阻断，不让任务走到“可签发”分支。
先阻断比后补更省时。

为什么要用多 Agent：不是追求炫技，而是追求可追责

多 Agent 的本质不是让智能体“更多”，而是让职责更清楚。
在合同联审里，最重要的不是“生成了多少条风险”，而是“每条风险能不能从规则、证据、责任人三条线同时复核”。

我们的最小可用分工

这里我特意把“报告Agent”放到最后。
它的职责是“收敛”，不是“判断一切”。
判断要在前面的角色里完成，且每一步都要带证据与边界。

这套链路里，技能（Skill）到底起什么作用

很多人以为 Skill 是“提示词集合”。
我这边更接近“审查制度的可执行化”：

• 规则是什么：比如付款条件必须显式绑定发票/验收节点；
• 哪些输入无效就阻断：版本号缺失、页码无法定位、附件与正文不一致；
• 复核后续怎么回写：每次人工改动都要回到规则仓库，作为下一次任务默认检查项。

这部分最关键的是“可学习性”。
第一次人工纠错不是只改这份合同，而是让 Skill 记下：以后再遇到同类条件，先按这个边界处理。