大概三年前我还在某个团队里做合同审核的活儿每天面对几十份文本眼睛都快看瞎了。后来接触到大模型我就一直想能不能给这种重复性的审查工作找个靠谱的帮手。试了一圈之后我把方案定在了 Dify 上搭了一个合同审查法律文书机器人 Agent现在基本能把合同里的常规风险和条款缺失问题自动筛出来剩下需要人工判断的再交给法务。这篇文章就把我整套搭建思路、踩过的坑、以及实测下来能直接用的配置方案分享出来尤其是如果你想用 Dify 快速落地一个偏向文书的审查机器人这篇文章应该能帮你少走不少弯路。1. 先拆需求你的合同审查机器人到底要干什么1.1 别一上来就堆功能先想清楚审查场景很多朋友一听到“合同审查 Agent”第一反应就是“让 AI 把整份合同读完然后给我挑毛病”。但在实操里这个想法太宽泛了建出来大概率是个四不像。我在开始搭建之前花了整整两天梳理需求最后把问题收敛成三个维度第一类是条款完整性审查。比如一份劳动合同该有的试用期条款、薪酬条款、解除条件、保密义务、竞业限制有没有写全一份采购合同质量标准、验收方式、付款节点、违约救济是不是齐了。这类审查非常结构化适合让模型基于清单去比对。第二类是合规性与风险识别。比如合同中出现了过分偏向某一方的责任条款、过高的违约金比例、空白授权、管辖法院约定不明等。这部分需要结合法条知识还要结合行业惯例去判断。第三类是文书起草与修订建议。不只是“指出问题”还要给出修改后的文本段落或者生成一条风险提示告诉使用者在哪个位置、因为什么理由需要做调整。举个例子我曾经收到一份租赁合同里面有“如出租方因故无法交付房屋承租方同意无条件解除合同”这种表述。这个条款表面上问题不大但“因故”两个字范围太宽对承租方来说风险极高。这个审查点不是靠简单的关键词匹配能发现的需要模型理解语义并且具备基本的法律风险意识。所以在搭建之前我给这个 Agent 定的目标就是三句话能自动识别合同类型能按预设规则做清单比对能对识别出的风险给出修改建议。这三句话贯穿了后面所有配置项的设计是整个搭建的“北极星”。1.2 明确使用对象和输出格式另一个容易踩的坑是不区分使用对象。给法务专家用的审核机器人和给业务人员用的审核机器人完全是两套思路。法务专家要的是“快”和“全”他们自己能判断哪些问题重要所以输出可以是密集的风险列表。业务人员则要“能看懂、能照着改”所以输出必须给出“原条款文本”“风险说明”“修改建议”三段式结构。我在设计时把输出格式固定成了下面这种结构风险等级高 / 中 / 低条款定位原文摘录风险分析为什么有风险修改建议可直接替换的文本参考依据相关法律原则或商业惯例这种结构化输出的好处是后续如果要做二次开发比如对接 OA 系统或者做统计报表直接解析这份 JSON 或者 Markdown 就能用不需要再让模型解释一遍。从一开始就限定了输出格式后面调提示词会省很多时间。模型是最怕“开放式答题”的你给它的格式越清晰它的表现就越稳定。2. 方案选型为什么选 Dify 而不是 LangChain 或 Coze2.1 Dify 适合快速落地但你需要知道它的边界先说明一下我的技术背景早期我用 LangChain 套 Python 代码写过一个小原型改过几天心里就清楚了。LangChain 就像一套积木理论上什么都能拼但一旦涉及“生产环境”这个环节索引管理、日志追踪、版本更新、权限控制每一样都要自己造轮子。Dify 走的是另一条路它把 RAG、Agent、工作流、知识库、模型管理全部以可视化方式集成到一个平台里。对我这种需要快速验证、后续还要交付给团队使用的场景来说它的价值体现在三个方面应用和知识库分离知识库可以单独维护更新不需要改代码。工作流可视化审查过程中的分支判断、节点编排、人工确认环节都能直观地看到。模型无关今天用某个模型明天换另一个只需要在设置里改一下不需要重写代码。2.2 Dify、LangChain、Coze 三者怎么选不少朋友在群里问过我合同审查这个场景用 Dify、LangChain、Coze 选哪个。我自己的对比结论是这样的特性DifyLangChainCoze上手难度低有图形界面高纯代码低图形界面知识库/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 里的模型参数固定为温度Temperature0.1 到 0.2Top P0.2 左右最大 Token 数根据输出格式设置 2000 到 3000为什么温度要低因为合同审查是知识密集、规则明确的场景不需要模型发挥创意需要的是稳定输出。当然这里也有一个副作用温度太低会导致模型有时候过于保守明明能确定的结论也会用“可能需要进一步分析”之类的含混语言。解决办法是在提示词里明确要求“你的回答应该直接、肯定除非证据不足否则不要使用模糊措辞。”这也能部分对冲低温带来的保守倾向。5. 实操过程从零到一搭建一套可用的合同审查 Agent5.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 才算真正发挥了价值。