用Dify搭建合同审查Agent这件事，听起来技术门槛很高，但实际上只需一个浏览器就能落地——完全不需要写一行Python代码，也无需部署服务器。上传文件后，AI自动完成分析，最终生成一份带批注的Markdown报告，全程通过拖拽操作即可完成。关键能力在于：它能识别出主体不一致、金额逻辑错误、日期冲突、责任条款缺失这四类深层风险，而不仅仅是做表面的关键词匹配。

整个搭建流程其实只有四个步骤：准备环境、文档解析、配置AI识别逻辑、生成报告。下面我们一步步拆解。

准备合同审查工作流基础环境

首先，确保你已经登录Dify平台（v1.1.0或更高版本），并且当前工作区是“工作室”。如果尚未部署，需要在Linux或macOS系统中执行docker compose up -d启动服务；Windows用户请使用WSL2环境，否则文档提取器节点可能无法正常加载PDF内容。

进入“创建应用”→选择“Workflow”类型→命名“合同风险审查Agent”→点击“创建”。这里有一个容易踩的坑：必须选择Workflow，而不是Chatflow。因为合同审查需要结构化输出和多节点串联，Chatflow只支持对话式交互，【无法调用文档提取器和格式转换插件】，如果选中它，后续节点根本无法运行。

创建完成后，工作流画布上会默认有一个“开始”节点。双击它，在“输入变量”中添加：变量名contract_file，类型选“文件”，显示名称设为“待审合同（仅支持docx/pdf）”。注意：不要勾选“允许多文件”。单次只审查一份合同，多文件上传会导致文本混排，AI容易误判主体信息——这个坑我见过不止一次。

配置文档解析与预处理节点

从左侧节点栏拖入“文档提取器”节点，连线到“开始”节点。双击该节点，设置输入来源为contract_file，输出变量名设为raw_text。

这里有一个硬性限制：该节点原生支持docx和pdf，但对扫描版PDF无效。如果用户经常上传扫描件，必须在前面加一个“OCR识别”节点——需要安装TextIn插件并配置API Key，否则提取结果为空字符串，后续所有分析将全部失效，这会让整个流程白跑。

对于doc格式（Word 97-2003老文档），Dify默认不兼容。有两种解决方案：

方案一：在“开始”节点后插入“文件类型判断”分支节点，当检测到扩展名为.doc时，调用自定义Python插件Doc2docxTool进行转换；

方案二：直接在开场白中强制提示用户：“请将Word 97-2003文档（.doc）另存为.docx格式后再上传”，省去插件开发成本。实测方案二更省心，毕竟不是所有人都需要兼容老格式。

设计AI风险识别核心逻辑

拖入“大语言模型”节点，连接至文档提取器。双击配置：选择模型（推荐DeepSeek-V3或GLM-4-Flash），温度值设为0.3——温度太高容易虚构风险点，太低则可能遗漏模糊条款。

在系统提示词框中粘贴以下结构化指令：

你是一名资深企业法务，正在审查一份商事合同。请严格按以下四步执行：
① 提取签约主体全称（首部、正文、签章页三处），比对是否完全一致，不一致则标记“主体不一致”；
② 找出所有金额相关条款（预付款、进度款、尾款、违约金），检查数值总和是否等于合同总额，比例是否符合公司《采购政策V2.1》第3条（预付≤30%，尾款≥10%）；
③ 定位“生效日期”“签署日期”“交付日期”，验证是否存在生效早于签署、交付早于生效等时间倒挂；
④ 扫描“违约责任”“不可抗力”“争议解决”章节，若任一节缺失或仅写“按法律规定执行”，即判定为“责任条款缺失”。
输出必须为纯Markdown表格，字段固定为：风险类型｜位置（页码+段落）｜原文片段｜修正建议。

这一步很关键：不能用通用的法律提示词模板，必须锁定这四类高发漏洞。测试发现，如果去掉“页码+段落”要求，AI常常返回“见第5条”之类的模糊定位，法务拿到报告后很难快速核查原始文件位置，等于白忙。

生成可交付的风险报告

添加“格式转换”节点，输入来源选上一步LLM输出的output，输出格式选“Markdown”。双击该节点，在“模板”栏填入：

# 合同风险审查报告
**文件名**：{{inputs.contract_file.filename}}
**审查时间**：{{now}}

{{outputs.llm_output}}

最后拖入“结束”节点，连接格式转换节点。点击右上角“发布”，系统自动生成唯一访问链接。用户打开链接后，上传合同→等待15～40秒→直接查看带超链接跳转的Markdown报告，风险点原文高亮显示，修正建议可一键复制。整个过程下来，从搭建到交付，前后不到十分钟。