去年我们团队在给一家年产值过亿的机械制造企业做合同管理系统改造时，遇到一个棘手的需求：法务部3个人，一年要审2000多份采购合同，审不过来，业务部门天天催。
传统的做法是写规则引擎：把法务的审查规则写成if-else逻辑，自动跑一遍。但规则引擎有个致命问题：合同条款的表述方式千变万化，同一条"违约金不超过合同总金额的30%"，100份合同里能有80种写法。规则引擎的维护成本比人工审查还高。
我们最后选择了多代理（Multi-Agent）架构。这篇文章记录我们踩过的坑和最终的方案设计。
为什么要多代理，而不是一个大模型干所有事
一开始我也想过偷懒：把合同全文丢给GPT-4，让它输出审查意见。试了20份合同，效果不太行。原因有三个。
第一，上下文窗口装不下。一份完整的采购合同动辄1-2万字，加上附件可能3-5万字。大模型处理长文本时注意力会衰减，合同后半部分的条款审查质量明显不如前半部分。
第二，审查任务太多样。合同审查包括条款提取、风险评分、合规检查、缺失条款检测、与历史合同比对等多个子任务。一个Prompt塞太多任务，模型容易顾此失彼，每个任务都做60分。
第三，结果不可追溯。法务审完合同后，如果AI说"这条有风险"，法务会问"凭什么？"一个黑盒大模型给不出有说服力的依据。
多代理架构的核心思路：把合同审查拆成多个专业子任务，每个Agent专注做一件事，做到90分。Agent之间通过结构化数据传递中间结果，最终汇总成完整的审查报告。
架构设计：7个Agent的分工
┌─────────────────────────────────────────────────┐
│ Orchestrator (编排器) │
│ LangGraph 状态机 + 任务路由 │
└──────┬──────┬──────┬──────┬──────┬──────┬────────┘
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐┌──────┐
│Extract││Risk ││Comply││Missing││Compare││Redline│
│Agent ││Agent ││Agent ││Agent ││Agent ││Agent │
│条款提取││风险评分││合规检查││缺失检测││历史比对││红线标注│
└──┬───┘└──┬───┘└──┬───┘└──┬───┘└──┬───┘└──┬───┘
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌─────────────────────────────────────────────┐
│ Result Aggregator (结果聚合器) │
│ 统一审查报告 + 条款级引用 + 风险热力图 │
└─────────────────────────────────────────────┘Extract Agent --- 条款提取
输入：合同全文（PDF/DOCX，经OCR处理后的文本）
输出：结构化条款列表，每个条款附带原文位置引用
这个Agent负责把非结构化的合同文本拆成结构化数据。我们用JSON Schema约束输出格式：
json
{
"clauses": [
{
"type": "payment_terms",
"content": "买方应在收到货物后30天内支付货款",
"source_ref": "第3.2条, 第4页第12行",
"entities": {
"payment_deadline_days": 30,
"payer": "买方",
"condition": "收到货物后"
}
}
]
}关键设计：source_ref字段是整个系统的信任基础。后续所有Agent的风险判断都能追溯到原文具体位置，法务可以点击引用直接跳转到对应条款。没有引用的判断，法务不信任。
Risk Agent --- 风险评分
输入：Extract Agent输出的结构化条款列表 + 风险规则库
输出：每条条款的风险等级（低/中/高/极高）+ 风险原因
风险规则库是我们和法务部一起构建的。规则不是写死的if-else，而是用自然语言描述的判断标准，让大模型去匹配。比如：
规则R-015: 违约金条款
标准: 违约金上限不应超过合同总金额的30%
风险等级: 超过50%为极高，30-50%为高，低于30%为低
说明: 超过30%的违约金在司法实践中可能被法院调整Risk Agent拿到条款后，逐条匹配规则库，输出风险评分。对于没有匹配到规则的条款，Agent会基于通用法律常识判断是否需要人工关注。
这里有个工程细节：规则匹配不能靠embedding相似度，因为法律条款的语义相似度和风险相关性不是线性关系。我们用的是混合检索（稠密向量 + BM25关键词 + RRF融合），加上规则的元数据过滤，准确率从单纯embedding的68%提升到了89%。
Comply Agent --- 合规检查
这个Agent检查合同是否符合行业法规和企业内部制度。制造业的合规要求比互联网行业复杂得多。
我们给Comply Agent准备了三个知识源：
- 国家法律法规库（《民法典》合同编、《政府采购法》等）
- 行业标准（ISO 9001质量管理体系条款对采购合同的要求）
- 企业内部制度（客户公司的采购管理制度、供应商准入标准）
Comply Agent的工作方式：拿到条款后，先在三个知识源中检索相关条款，然后比对合同条款与法规要求的一致性。如果不一致，输出差异点和建议修改。
Missing Agent --- 缺失条款检测
这个Agent不审已有条款，专门找"合同里缺了什么"。
制造业采购合同的必备条款包括：质量标准与验收方式、交货期限与延迟处理、付款条件与发票要求、知识产权归属、保密义务、不可抗力、争议解决方式。
Missing Agent拿着必备条款清单，逐项检查合同中是否存在。如果某项缺失，标记为风险并给出建议条款模板。
实际测试中，Missing Agent发现了大量"感觉不对但说不出来哪里不对"的问题。比如一份设备采购合同里没有约定验收标准，供应商发了货就算交付，买方事后发现质量不达标时已经被动了。
Compare Agent --- 历史合同比对
这个Agent把当前合同与同一供应商的历史合同比对，找出差异条款。
制造业跟固定供应商合作多年，合同条款应该趋于稳定。如果某次新合同的条款突然变了（比如付款条件从"货到付款"变成了"预付50%"），可能是供应商在试探，也可能是业务条件变化。无论哪种情况，法务需要知道。
Compare Agent的实现：用pgvector存储历史合同的条款向量，当前合同条款入库后做相似度检索。相似度低于0.75的条款标记为"显著变化"，推送给法务重点审查。
Redline Agent --- 红线标注
这是法务最喜欢的Agent。它不只说"这条有问题"，还给修改建议。
Redline Agent针对高风险条款，生成三档修改方案：
- 保守方案：最小改动，仅修正最严重的风险点
- 中等方案：适度调整，平衡双方利益
- 激进方案：大幅修改，最大化己方权益
每个方案都附有修改前后的条款对比，法务可以直接采纳或在此基础上微调。
工程实践中的几个关键决策
决策一：用LangGraph还是自建编排
我们选了LangGraph。原因很简单：合同审查的流程不是线性的。Extract Agent跑完后，Risk、Comply、Missing三个Agent可以并行跑。如果Risk Agent发现某条违约金条款风险极高，需要先等Comply Agent确认这条是否违规，再决定要不要让Redline Agent生成修改方案。
LangGraph的状态机模型天然支持这种有条件分支的流程编排。自建的话要自己管理状态传递和并发控制，投入产出比不高。
决策二：大模型选型
我们没有用单一模型，而是根据Agent的特点分配不同的模型。
Extract Agent对结构化输出要求高，用GPT-4o，因为它对JSON Schema的遵循度最好。Risk Agent和Comply Agent需要法律推理能力，用Claude 3.5 Sonnet，法律领域表现更稳定。Missing Agent和Redline Agent的创意性要求高，用GPT-4o。
BYOK（Bring Your Own Key）模式让企业可以用自己的API Key，不绑定单一供应商。对于有数据合规要求的企业，我们也支持Ollama本地部署开源模型（Llama 3、Qwen等），虽然效果打折扣，但数据不出服务器。
决策三：人类审查环节
AI输出的审查意见必须经过法务确认才能生效。我们在系统里设计了"AI建议-法务确认"的双轨机制：
AI标记为"低风险"的条款，法务可以快速过一眼批量确认。AI标记为"高/极高风险"的条款，系统会高亮显示并强制要求法务逐条审查。
法务确认或修改后，系统记录"AI判断 vs 人工判断"的差异，用于后续优化规则库和Prompt。运行半年后，AI与法务判断的一致率从最初的62%提升到了85%。
决策四：RAG检索架构
合同审查涉及大量法律知识检索。我们用的是混合检索方案：
用户查询 → [pgvector 稠密向量检索] + [Elasticsearch BM25稀疏检索]
↓
RRF (Reciprocal Rank Fusion) 融合排序
↓
Top-K 结果 → 送入Agent上下文稠密向量抓语义相似性（"违约金"和"罚金"是近义词），BM25抓精确匹配（法条编号、金额数字）。两路检索结果用RRF融合，取长补短。
pgvector的HNSW索引让条款级别的相似度搜索从全表扫描变成毫秒级。我们库存了3万条合同条款向量，平均检索时间12ms。
效果数据
上线运行6个月后的数据：
- 法务初审时间从平均45分钟/份降到8分钟/份（AI预审+法务确认）
- 合同审查覆盖率从62%（人工只能审重点合同）提升到100%（AI全量预审）
- 风险条款检出率比纯人工审查高了23%（AI不会疲劳，也不会因为赶工跳过条款）
- 误报率（AI标记高风险但法务确认无风险）稳定在15%左右，可接受
有一个我们没有预料到的好处：AI审查报告成了法务和业务部门沟通的桥梁。以前法务说"这条有问题"，业务部门会问"以前也是这么签的，怎么现在不行了？"现在有了AI的条款引用和规则编号，沟通效率高了很多。
关于成本
有人会问，跑7个Agent，API费用不便宜吧？
实际上，一份合同的AI审查成本在0.3-0.8元之间（取决于合同长度和模型选择）。一年2000份合同，总成本大概1000-1600元。而一个法务专员的年薪至少15万。算下来AI审查的成本不到人工的1%。
如果选择Ollama本地部署，硬件投入一台A6000显卡服务器（约3万），之后零边际成本。对于合同量大的企业，本地部署更划算。
这套架构不是银弹。它解决不了合同条款的法律解释问题，也替代不了法务对复杂商业条款的商业判断。但它确实把法务从"逐行读合同"的低效劳动中解放出来了，让他们有时间做更有价值的事。