大概三年前我还在某个团队里做合同审核的活儿，每天面对几十份文本，眼睛都快看瞎了。后来接触到大模型，我就一直想，能不能给这种重复性的审查工作找个靠谱的帮手。试了一圈之后，我把方案定在了 Dify 上，搭了一个合同审查法律文书机器人 Agent，现在基本能把合同里的常规风险和条款缺失问题自动筛出来，剩下需要人工判断的再交给法务。这篇文章就把我整套搭建思路、踩过的坑、以及实测下来能直接用的配置方案分享出来，尤其是如果你想用 Dify 快速落地一个偏向文书的审查机器人，这篇文章应该能帮你少走不少弯路。
1. 先拆需求：你的合同审查机器人到底要干什么
1.1 别一上来就堆功能，先想清楚审查场景
很多朋友一听到“合同审查 Agent”，第一反应就是“让 AI 把整份合同读完，然后给我挑毛病”。但在实操里，这个想法太宽泛了，建出来大概率是个四不像。我在开始搭建之前，花了整整两天梳理需求，最后把问题收敛成三个维度：
第一类是条款完整性审查。比如一份劳动合同，该有的试用期条款、薪酬条款、解除条件、保密义务、竞业限制有没有写全；一份采购合同，质量标准、验收方式、付款节点、违约救济是不是齐了。这类审查非常结构化，适合让模型基于清单去比对。
第二类是合规性与风险识别。比如合同中出现了过分偏向某一方的责任条款、过高的违约金比例、空白授权、管辖法院约定不明等。这部分需要结合法条知识，还要结合行业惯例去判断。
第三类是文书起草与修订建议。不只是“指出问题”，还要给出修改后的文本段落，或者生成一条风险提示，告诉使用者在哪个位置、因为什么理由需要做调整。
举个例子，我曾经收到一份租赁合同，里面有“如出租方因故无法交付房屋，承租方同意无条件解除合同”这种表述。这个条款表面上问题不大，但“因故”两个字范围太宽，对承租方来说风险极高。这个审查点不是靠简单的关键词匹配能发现的，需要模型理解语义，并且具备基本的法律风险意识。
所以，在搭建之前，我给这个 Agent 定的目标就是三句话：能自动识别合同类型，能按预设规则做清单比对，能对识别出的风险给出修改建议。这三句话贯穿了后面所有配置项的设计，是整个搭建的“北极星”。
1.2 明确使用对象和输出格式
另一个容易踩的坑是不区分使用对象。给法务专家用的审核机器人和给业务人员用的审核机器人，完全是两套思路。
法务专家要的是“快”和“全”，他们自己能判断哪些问题重要，所以输出可以是密集的风险列表。业务人员则要“能看懂、能照着改”，所以输出必须给出“原条款文本”“风险说明”“修改建议”三段式结构。
我在设计时，把输出格式固定成了下面这种结构：
- 风险等级：高 / 中 / 低
- 条款定位：原文摘录
- 风险分析：为什么有风险
- 修改建议：可直接替换的文本
- 参考依据：相关法律原则或商业惯例
这种结构化输出的好处是，后续如果要做二次开发，比如对接 OA 系统或者做统计报表，直接解析这份 JSON 或者 Markdown 就能用，不需要再让模型解释一遍。
从一开始就限定了输出格式，后面调提示词会省很多时间。模型是最怕“开放式答题”的，你给它的格式越清晰，它的表现就越稳定。
2. 方案选型：为什么选 Dify 而不是 LangChain 或 Coze
2.1 Dify 适合快速落地，但你需要知道它的边界
先说明一下我的技术背景：早期我用 LangChain 套 Python 代码写过一个小原型，改过几天心里就清楚了。LangChain 就像一套积木，理论上什么都能拼，但一旦涉及“生产环境”这个环节，索引管理、日志追踪、版本更新、权限控制，每一样都要自己造轮子。
Dify 走的是另一条路：它把 RAG、Agent、工作流、知识库、模型管理全部以可视化方式集成到一个平台里。对我这种需要快速验证、后续还要交付给团队使用的场景来说，它的价值体现在三个方面：
- 应用和知识库分离：知识库可以单独维护更新，不需要改代码。
- 工作流可视化：审查过程中的分支判断、节点编排、人工确认环节都能直观地看到。
- 模型无关：今天用某个模型，明天换另一个，只需要在设置里改一下，不需要重写代码。
2.2 Dify、LangChain、Coze 三者怎么选
不少朋友在群里问过我，合同审查这个场景，用 Dify、LangChain、Coze 选哪个。我自己的对比结论是这样的：
| 特性 | Dify | LangChain | Coze |
|---|---|---|---|
| 上手难度 | 低，有图形界面 | 高，纯代码 | 低，图形界面 |
| 知识库/RAG | 内置完善 | 需要自行组装 | 内置但共享属性强 |
| 工作流编排 | 支持复杂分支 | 靠代码自由度高 | 偏轻量 |
| 数据私有化 | 支持 Docker 自部署 | 完全可控 | 云端为主 |
| 适合阶段 | 产品化、交付 | 研究探索 | 个人/轻量使用 |
从搭建合同审查平台这个目标来看，合同审查有大量的知识库依赖（合同范本、法条摘要、内部审查标准），还有复杂的多步判断流程（先识别类型，再按不同清单审查），这些正好是 Dify 的强项。LangChain 适合你不怕写代码、需要深度定制的场景；Coze 适合做轻量问答，但搞复杂工作流时限制会比较明显。
我当时选 Dify 还有个现实原因：团队里不只有程序员，还有法务同事和运营同事。他们需要看得懂这个系统是怎么运转的，甚至希望自己能维护知识库。Dify 的可视化界面能让他们参与进来，这是 LangChain 做不到的。
3. 知识库搭建：审查效果的“天花板”在这里
3.1 语料准备，决定机器人的基础水平
很多初学的朋友以为，把一堆合同文件传到 Dify 知识库里就完事了。这是最大的坑。模型在审查时的“法律直觉”来自两部分：一是大模型本身的预训练知识，二是知识库里注入的专属规则。知识库的质量直接决定了机器的上限。
我自己整理语料时，分成了四类：
- 合同范本库：包括劳动合同、采购协议、销售合同、保密协议、房屋租赁合同、服务外包协议等高频类型，主要是让模型记住“标准长什么样”。
- 审查规则库：把团队内部使用的审查清单转成文本，例如“劳动合同必须明确工资支付周期，未明确为高风险”“违约金比例超过法定上限为高风险”。
- 法条摘要库：选取高频相关的法律原则和条款摘要，例如关于试用期期限上限、竞业限制补偿、定金罚则、违约赔偿范围等。
- 风险案例库：把历史上出现过纠纷或问题的合同条款原文脱敏后整理进去，对模型做 few-shot 增强。
你可能会问，为什么不像微调模型那样，让模型彻底学会审查？因为在多数实际场景里，规则是动态变化的，你今天改了审查标准，不可能明天重新微调一次模型。知识库可以随时新增、修改、删除文档，维护成本低得多。这也是 RAG 方案在合同审查这类高变场景里胜出的核心原因。
3.2 文档预处理和分段参数，直接影响检索命中率
知识库不是纯文本堆积，Dify 导入文档时有一些参数值得认真调。
第一个参数是分段长度。默认可能给的是按 token 或者字符切分，但合同文本的特殊性在于条款之间逻辑独立，一段通常包含完整的意思表达。我实测下来，分段长度设置在 500 到 800 之间比较合适。太短会导致一句完整条款被拆散，检索时上下文残缺；太长又会导致一个片段里混入多个无关条款，检索噪声变大。
第二个参数是分段重叠度。我给到 10%-20%。重叠的作用是防止一个条款刚好被切在边界处导致后半段检索不到。合同里经常出现“（一）…（二）…”这种并列条款，重叠太少会把它们拦腰截断。
第三个是索引清洗。合同文件往往带有页眉、页脚、表格、水印、编号，这些如果不清理，知识库检索时会匹配到一堆无意义信息。比如某合同的页脚写着“本文件仅供内部使用，请勿外传”，如果让它进入索引，用户问“合同是否允许外传”时，模型可能会拿这个干扰项胡乱回答。所以导入前要做一次文本清洗，把页眉页脚、水印、空行、特殊字符全部处理掉。
我在实际整理时还加了一道“人工抽查”环节，把一些重要文档按照常见提问预检一遍。比如问“这份合同里有没有限制承租人转租的条款？”，然后看检索结果返回哪个片段，如果返回的内容明显不对，说明分段参数要调整。
4. Agent 设计与提示词：让 LLM 按律师的思维方式工作
4.1 系统提示词：把角色设定、审查步骤、输出约束一次写满
在 Dify 里创建 Agent 应用时，最核心的就是系统提示词。我见过很多人只写一句“你是专业的法律顾问”，然后就指望模型自己发挥。结果就是模型答得很漂亮，但对你的具体需求完全没对上。
我的写法是分四段：
第一段：角色与目标。明确告诉模型“你是一名合同审查助理，你的任务是对用户提交的合同文本进行完整性审查、合规性审查和风险评估，并输出结构化审查报告”。
第二段：审查步骤。给出一个固定流程，例如：
- 先识别合同类型；
- 列出该类合同应有的关键条款清单；
- 逐项比对原文，标注缺失或模糊之处；
- 对存在的风险条款进行等级评定；
- 给出修改建议。
第三段：知识库使用规则。告诉模型“当涉及法条、审查标准和历史案例时，必须以知识库内容为准，不得凭空编造”。
第四段：输出格式。给出严格的输出模板，要求模型按指定的 Markdown 结构输出。
这套提示词的意义在于什么？在于把模型从“随机的博学者”变成一个“按固定 SOP 工作的实习助理”。你给它的流程越接近真实工作流，它输出的质量就越稳定。
4.2 工作流编排：从单一问答到多节点流水线
如果只是让模型直接读用户传入的合同文本，然后基于对话历史输出结果，也能用，但效果不够稳定。尤其是合同稍微长一点，模型很容易“发挥过头”，比如该重点关注的条款反而一笔带过。
后来我把 Agent 升级成了带工作流的形式。在 Dify 的工作流画布里，我是这样设计的：
- 输入节点：接收用户上传的合同文本或合同文件。
- 合同类型识别节点：用一个单独的 LLM 判断合同属于哪一类。
- 审查清单生成节点：根据合同类型生成应该检查的条款清单。
- 知识库检索节点：按合同类型检索最相关的审查规则和范本。
- 多路审查节点：把合同文本和审查清单交给 LLM，做完整性审查。
- 风险分析节点：将知识库规则注入，做风险条款识别。
- 汇总节点：把结果合并成统一报告。
这里有一个关键设计：不要试图让一个大模型一步完成所有工作。合同审查这个任务拆开之后，每一步的输入输出都变得非常明确，模型的准确率会大幅上升。比如“合同类型识别”只输出一个名词、“审查清单生成”只输出一个清单，单步任务的模糊性大大降低，后面的步骤自然更可靠。
在我实测过程中，这个多步流程比单次大模型输出在“条款遗漏率”上降低了大概三四成。这不只是提示词工程的效果，本质上是任务拆解让每一步都变得更简单。
4.3 模型参数设置：合同审查任务需要低温度的确定性
大模型生成本身有随机性。合同审查这个场景最怕的就是随机性，因为同一个审查点在第一次问和第二次问时给出不同的定级，这对用户来说是不可接受的。
我把 Dify 里的模型参数固定为：
- 温度（Temperature）：0.1 到 0.2
- Top P：0.2 左右
- 最大 Token 数：根据输出格式设置 2000 到 3000
为什么温度要低？因为合同审查是知识密集、规则明确的场景，不需要模型发挥创意，需要的是稳定输出。
当然，这里也有一个副作用：温度太低会导致模型有时候过于保守，明明能确定的结论也会用“可能需要进一步分析”之类的含混语言。解决办法是在提示词里明确要求：“你的回答应该直接、肯定，除非证据不足，否则不要使用模糊措辞。”这也能部分对冲低温带来的保守倾向。
5. 实操过程：从零到一搭建一套可用的合同审查 Agent
5.1 准备 Dify 环境和模型 API
我使用的是 Docker 自部署方式，具体步骤不展开，简单说就是三件事：准备一台带显卡或者可以调用大模型 API 的服务器，安装 Docker 和 Docker Compose，用官方部署脚本把 Dify 跑起来。
模型 API 的选择上，我当时在多个模型之间做了对比测试。测试方法很简单：拿一份标准采购合同，分别让各模型给出风险点，比对数量和准确性。最终留下了两个模型做“模型路由”：主模型负责综合审查，备选模型负责知识库检索相关的增强。整体配置的核心逻辑是，主模型需要足够的上下文窗口和指令跟随能力，至少要能塞下一份完整的中等长度合同文本。
注意：Dify 的知识库嵌入模型和对话模型可以分开配置。如果你用的是 API 方式，嵌入模型选择成本低、速度快的就行，对话模型选能力强的。
5.2 创建知识库并导入审查规则
在 Dify 界面的“知识库”模块，我创建了三个独立知识库：
- 合同范本库：存储标准合同模板
- 审查规则库：存储内部审查清单和风险标准
- 法规摘要库：存储法律原则相关的摘要
为什么分成三个而不是合成一个？因为不同来源的语料检索策略不一样——范本库强调“找相似结构”，规则库强调“精确匹配”，法规摘要库强调“按主题召回”。分开建库后，我可以在工作流里给每个库不同的 top_k 参数，大大提升了召回精准度。
导入文档时，我用的是 Dify 的批量导入功能。文件格式优先用 Markdown 或纯文本，PDF 会自动做 OCR 解析，但排版复杂时容易出错，所以能转成文本的坚决转成文本。
5.3 配置 Agent 应用和提示词模板
在“创建应用”时选择 Agent 类型，然后在提示词区域填入我前面说的四段式系统提示词。
这里贴一个我实际使用的提示词模板，方便你直接复制修改：
你是一名合同审查助理，专门为企业提供合同文本的风险审查与修订建议服务。 你的工作流程如下： 1. 识别用户输入的合同属于哪种类型（劳动合同、采购合同、销售合同、保密协议、租赁合同等）。 2. 基于该类合同应具备的关键条款清单，逐项检查原文，标记缺失或表述不清的条款。 3. 对原文中疑似存在法律风险或商业风险的条款，进行风险分级，并分析风险原因。 4. 对每个风险点给出可直接替换的修改建议，并简要说明理由。 5. 输出结构必须严格按照以下 Markdown 格式： ## 合同基本信息 - 合同类型： - 审查时间： ## 条款完整性审查 | 条款名称 | 状态 | 说明 | |---------|------|------| ## 风险条款识别 | 风险等级 | 条款原文 | 风险分析 | 修改建议 | 参考依据 | |---------|---------|---------|---------|---------| ## 综合建议 注意： - 所有涉及法律法规和审查标准的内容，必须基于知识库提供的信息，禁止编造法条。 - 如果知识库中没有相关依据，请明确说明“当前知识库中未找到对应审查标准”。 - 用中文回答，语言直接，避免模糊表达。这套提示词的关键点在于给模型一个“逼着它按模板输出”的约束。模型一旦被固定在输出格式里，它的发散空间就小了，回答的规范性大幅提升。
5.4 添加知识库作为工具，让 Agent 能实时检索
在 Dify 的 Agent 设置中，除了系统提示词，还需要把知识库作为工具注入。这一步是将“审查工作流”落地的核心。需要注意的是，不要把知识库当成对话上下文的一部分直接塞进提示词，那样会占用大量上下文窗口，还会导致无关内容干扰判断。合理做法是让 Agent 在需要时检索——即使用 Dify 的检索工具，根据当前分析的问题返回相关文本片段。
我实测中发现，如果知识库直接作为上下文输出，模型会把检索到但无关的文本也“解释”进答案里。而改成按需检索后，回答明显干净很多。
5.5 工作流里加入“人工复核”和“可解释”设计
最后我还在工作流里加了一个设计：增强可解释性。每个风险点后面增加一个“依据来源”字段，内容来自知识库中匹配到的片段摘要。用户点开风险点时，能看到“这个风险判断为什么成立”。这个设计在真实使用中非常关键。合同审查是低容错场景，使用者需要对结论有信心。如果模型只是给出一堆结论而没有依据，用户根本不敢采纳。
在 Dify 的节点设置中，我把知识库检索结果存到一个变量里，再利用一个 LLM 节点把它整理成“依据说明”格式，拼进最终报告。
6. 测试调优：从“能用”到“好用”的核心迭代
6.1 准备标准测试集，量化评估审查性能
如果你只是随便拿一两份合同试试，觉得回答还像样，就迫不及待上线，那你一定会后悔。我搭建完成后，专门准备了一套测试集：
- 10 份不同类型的合同模板
- 30 个已知风险点（每个风险点提前标注了原始条款和预期判断）
- 多种输出格式校验样例
测试时把合同文本逐一跑一遍，人工对比 Agent 输出的风险点是否包含预期风险。我统计了两个指标：查全率（预期风险点命中数/总预期数）和误报率（Agent 报出但人工判断不是风险的数量）。
第一轮测试结果让我很受打击：查全率只有六成左右，误报率很高。这说明知识库的检索和提示词的配合还不到位。调整方向有两个：一是优化提示词，把“请重点检查以下高风险点”的表述改为“请将以下高风险点清单作为最低标准，逐项评估”；二是加大知识库中风险案例的覆盖度，把之前遗漏的场景补进规则库。
6.2 常见问题排查：检索不准、回答幻觉、输出格式漂移
我整理了测试过程中遇到最多的几类问题，以及对应的解法。
第一类是明显的检索不准。例如问“这份合同里有没有竞业限制条款”，知识库返回的是保密条款内容，模型答出文不对题的内容。解决方法是先查分段设置，再看 embedding 模型是否需要更换。分段太粗容易混入无关信息，建议把 800 改到 600 试一轮；embedding 模型如果对法律文本语义理解不够，就换一个更擅长中文语义的模型对比测试。
第二类是幻觉问题。模型自己编造了审查标准或法律条文。这个必须零容忍。除了在设计上强调“以知识库为准”，还在每个知识库节点后增加了一个“引用验证节点”，要求模型在输出审查结论时，把知识库中对应的原文片段一并输出，人工复核时直接抽查。这个办法很笨，但能有效降低幻觉风险。
第三类是输出格式漂移。模型有时会跳过表格，直接输出一段文字。解决方法是把输出格式从“请按照以下格式”改成“必须严格按照以下 JSON 结构输出”，并在工作流末尾加入一个格式校验节点，发现格式不符就自动让模型重写一次。
6.3 在 Dify 里做产品级调优的几条经验
这里再分享几条我自己摸索出来的细节经验。
第一，不要忽略提示词更新后的“回归测试”。每次改提示词，都可能影响其他类型的合同审查效果。我习惯每次修改后，把之前测过的测试集完整跑一遍，确认没有引入新问题。
第二，善用 Dify 的“日志”功能。Dify 会把每次运行的输入输出记录在日志里，这个功能非常有用。模型在线上环境产生的错误输出，全都可以从日志里回溯出问题所在。我是靠日志发现了一个非常隐蔽的问题：当合同文本过长时，工作流中间变量会把上下文截断，导致后半段条款完全没有被审查。
第三，建议保留一个人工审核入口。哪怕 Agent 再强，目前也不可能完全替代人工判断。我给这个平台加了一个人工确认环节，高风险条目必须由法务同事确认后才能对外输出。这也是让业务方敢用的重要条件。
7. 上线与维护：让合同审查 Agent 真正跑起来
7.1 发布、权限和团队协作配置
测试稳定后，我通过 Dify 的“发布”功能将应用部署到生产环境，并且设置了访问权限。建议尽量给团队不同角色分配不同的权限：
- 管理员：可以修改提示词、管理知识库、查看日志
- 编辑者：可以调测试集，但不能变更生产配置
- 使用者：只能通过页面或者 API 调用审查功能
Dify 支持分享链接，也支持 API 接口方式集成到公司内部系统。我们最后选了 API 方式，因为业务部门希望能直接在 OA 系统里发起审查请求，不需要单独登录一个新网站。
7.2 知识库的日常更新节奏
知识库不是建一次就一劳永逸。法律环境在变，公司的业务策略也在变，审查标准必须定期更新。我定的维护节奏是：
- 每月更新一次法规摘要库
- 每季度补一轮风险案例库
- 每次发现 Agent 漏掉一个新风险点，当时就把对应规则写入审查规则库
这个更新频率不算高，但足够覆盖大多数业务场景。关键是每次更新后要跑一轮回归测试，确保新增规则没有干扰原有审查逻辑。
7.3 模型的迭代与替换周期
大模型更新换代速度很快。我给自己定了一个原则：每半年做一次模型对比测试，把现有模型和市面上新出的模型放在同一套测试集上跑，如果优势明显（准确率高、延迟低、成本更低），就切换过去。Dify 的这种“模型无关”设计，让切换成本很低。
有一次切换模型时出现了小问题：新模型对长文本的“指令跟随”更严格，但对提示词中某些模糊表述过度扩展，导致输出格式多了一些额外字段。后来我把提示词中的输出模板再收紧，要求“不允许输出任何模板以外字段”，问题就解决了。
8. 最后分享一点我的使用体会和扩展思路
合同审查 Agent 不是一个“装上就能用”的工具，它本质上是一个需要持续投喂规则、持续校验效果的系统。我搭完之后最大的体会是，模型能力只是其中一个环节，知识库质量和任务拆解方式才是决定效果的关键。你给机器人的“记忆”越规范、指令越清晰，它给你的答案就越像出自一个有经验的法务之手，而不是一个看似什么都懂、实际不可靠的答题机器。
如果后续还想扩展，我这里有两个可以参考的方向：一个是在工作流里接入合同管理系统的节点，让审查完之后自动归档并生成审批列表；另一个是加一个“条款修改前后对比”功能，让使用者在界面上看到修改前后的差异，辅助人工决策。这些都不需要推倒重来，在现有 Dify 工作流上继续加节点就能实现。
合同文本处理这行讲究一个词：审慎。机器帮我们做初筛，把明显的问题、缺失的条款、生硬的表述都提前挑出来，背后依然需要真人来做最终判断。能把“人机协作”这个节奏设计好，这个 Agent 才算真正发挥了价值。
