Dify_Config_Guide.md

Dify 落地配置指南 (Dify Config Guide)

本文档为隐私合规协同场景在 Dify 中的落地提供确切配置方案，特别针对核心交互阶段（B/C/E/F阶段，即智能体调用与人工审核流转节点）的 HTTP 超时、重试机制和 Human Input 分支设置提供详细指导。

一、HTTP 节点配置方案 (针对 B/C/E 等调用外部智能体阶段)

在 Dify 的 Workflow 中，调用本地/服务端智能体（如 AGENT-02 协议重构、AGENT-03 合规校验、AGENT-04 法务审核包生成）主要通过 HTTP Request 节点实现。

1. HTTP Timeout (超时设置)

智能体推理特别是协议重构和合规校验通常需要较长的 LLM 处理时间，默认的 HTTP 超时时间往往不够。

• 连接超时 (Connect Timeout): 建议设置为 10s (本地或内网服务响应极快)。
• 读取超时 (Read Timeout): 建议设置为 120s - 180s (根据大模型并发生成速度决定，协议重构阶段建议至少 180s)。
• 写入超时 (Write Timeout): 建议设置为 30s。

2. 重试机制 (Retry)

为了应对网络抖动或 LLM 偶发的推理失败（如返回 5001 错误码），需要配置合理的重试策略。

• 最大重试次数 (Max Retries): 设置为 1 次到 2 次。不允许无限重试，以防大量消耗 Token。
• 重试间隔 (Retry Interval): 设置为 2000ms (2秒) 或以上。
• 重试条件 (Retry Conditions):
  • HTTP 状态码为 500, 502, 503, 504 时触发重试。
  • 注意: 如果状态码为 400 (如 4001 缺材料、4002 格式错误)，绝对不触发重试，应直接流转至异常处理分支。
• Header 透传: 在 HTTP Request 节点的 Header 中增加 x-retry-count 参数（如果在 Dify 较新版本中支持表达式，可将重试次数变量传入，或者由服务端自行记录重试状态）。

二、Human Input 与分支路由设置 (针对 F 阶段人工法务确认)

F 阶段的核心是拦截 AI 的生成结果，交由人类（法务）进行最后拍板，并根据决策走向不同的后续流程。

1. Human Input 节点配置

• 节点名称: 人工法务确认 (Legal Human Review)
• 展示信息 (Review Information):
  • 绑定 AGENT-04 吐出的 formatted_review_material（法务审核包格式化文本）。
  • 展示 risk_levels 和 pending_items。
• 输入表单配置 (Input Form):
  • 决策字段 (Decision): 单选下拉框 (Select)
    • 选项 1: approve (审核通过)
    • 选项 2: reject (退回修改)
    • 选项 3: need_more_material (补充材料)
  • 审批意见 (Comments): 文本域 (Textarea)，非必填（但在退回或补充材料时建议法务填写具体原因）。

2. 条件分支 (If/Else 节点)

紧接在 Human Input 节点之后，使用条件节点 (Condition) 对流程进行分流：

• 分支 A (通过 - Approve):
  • 条件: Human_Input.Decision == approve
  • 动作: 调用 HTTP 节点，将当前 draft_id 及通过状态推送到“待发布中心”入库。
• 分支 B (退回 - Reject):
  • 条件: Human_Input.Decision == reject
  • 动作: 通过 Template 节点将 Human_Input.Comments 格式化为修改清单，然后循环退回至 AGENT-02 (协议重构) 节点，并在上下文中带上法务的修改指导意见。
• 分支 C (补材料 - Need More Material):
  • 条件: Human_Input.Decision == need_more_material
  • 动作: 结束当前自动化主流程，输出缺漏材料清单与法务意见，提示业务人员重新补充 PRD / 权限 / SDK 材料后再次发起申请。

三、全局系统性配置建议

1. 统一的错误捕获: 在 Dify 的 HTTP 节点后，应优先检查输出的 JSON 中是否存在 error_code 或 HTTP Status 是否异常。如果失败，走统一的“任务失败”终点，避免静默失败。
2. 日志不落盘敏感数据: Dify 端保存的 Workflow 日志可能会保留变量。请确保传递给 Dify 的 materials 字段（如果通过 Dify 前端填入）只在内存中流转，或遵循服务端已实施的日志脱敏规范（即仅落库 case_id 等 metadata）。
3. 幂等性保障: 每次 Dify 触发请求时，务必在 Payload 中带上唯一的 case_id，以触发服务端的幂等控制，防止在网络超时后 Dify 发起重试导致产生重复脏数据。