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 发起重试导致产生重复脏数据。