Delete 方案.md

方案.md

@@ -1,1124 +0,0 @@
-隐私合规协同场景——智能体服务层实施 SPEC
-
-版本：V1.0
-状态：开工版
-适用范围：本地/服务端智能体服务开发，不含桌面端与 Dify 前端实现
-
-1. 文档目标
-
-为“同业隐私协议跟踪与客户协议重构协同场景”提供可直接研发的智能体服务层规格。
-本规格只覆盖：
-
-4 个角色智能体服务
-智能体之间的输入输出合同
-Dify 调用这些服务的接口协议
-结果结构和验收标准
-
-本规格不覆盖：
-
-桌面端安全底座
-文件脱敏/反脱敏实现
-FileBay 上传能力
-Dify 页面设计与工作流画布实现
-法务最终人工确认逻辑本体
-同业抓取服务本体实现（如已有外部抓取服务）
-2. 系统边界
-2.1 本轮研发边界
-你负责开发
-同业/监管变化摘要智能体服务
-协议重构智能体服务
-合规校验智能体服务
-法务审核包生成智能体服务
-统一的数据模型与接口协议
-可选：共享规则库 / Prompt 模板管理方式
-外部依赖
-桌面端负责脱敏、文件上传、FileBay 存储
-Dify 负责工作流编排、知识库检索、人工法务确认节点
-待发布中心由现有业务服务承接，或后续补建
-同业抓取服务负责输出头部银行协议变化结果，不在本轮内开发
-3. 总体业务目标
-
-围绕“同业隐私协议跟踪与客户协议重构”场景，形成以下可执行能力链：
-
-同业/监管变化摘要
-→ 客户材料解析
-→ 协议重构建议
-→ 合规校验
-→ 法务审核包生成
-→ Dify人工法务确认
-→ 待发布版本落库
-
-本轮智能体层的目标是：
-让 Dify 能稳定调用 4 个角色智能体服务，完成从材料到审核包的完整 AI 处理链。
-
-4. 非目标
-不开发桌面端文件处理与脱敏功能
-不开发 Dify 页面与前端
-不替代法务最终决策
-不直接自动发布线上协议
-不构建抓取爬虫系统本体
-不在本轮支持多行业泛化，仅聚焦银行 APP 隐私协议场景
-5. 角色智能体定义
-AGENT-01 同业/监管变化摘要智能体
-职责
-汇总头部银行隐私协议变化
-汇总监管文件、处罚案例变化
-产出可供后续重构使用的“变化摘要”
-输入
-同业协议变化列表
-监管变化列表
-可选：业务线标签、APP 类型标签
-输出
-同业变化摘要
-监管变化摘要
-推荐参考条款
-风险提醒项
-不负责
-直接生成客户协议条款
-做最终合规判断
-替代合规或法务审核
-AGENT-02 协议重构智能体
-职责
-基于客户当前协议、PRD、权限清单、SDK 清单
-结合同业/监管变化摘要
-生成客户协议差异分析与修订建议
-输入
-当前隐私协议文本
-PRD / 功能说明文本
-权限清单文本或结构化列表
-SDK 清单文本或结构化列表
-同业变化摘要
-监管变化摘要
-输出
-差异分析报告
-建议修订条款列表
-红线稿生成输入
-风险项初筛
-不负责
-输出最终合规结论
-替代法务审核
-AGENT-03 合规校验智能体
-职责
-校验修订建议是否覆盖主要监管要求
-校验协议与 PRD / 权限 / SDK 是否一致
-标出高风险项、待确认项
-输入
-当前协议文本
-修订建议稿
-PRD / 权限 / SDK 材料
-监管依据摘要
-可选：内部制度摘要
-输出
-合规缺口清单
-风险等级
-待法务确认项
-校验说明
-不负责
-直接修改协议文本
-作出“已合规”最终结论
-AGENT-04 法务审核包生成智能体
-职责
-整理前 3 个智能体的结果
-输出法务可以直接阅读的审核包
-汇总重点条款、依据和建议动作
-输入
-同业变化摘要
-监管变化摘要
-差异分析报告
-修订建议稿
-合规缺口清单
-风险等级
-待确认项
-输出
-法务审核包
-审核建议（建议通过 / 建议退回 / 建议补材料）
-重点关注条款
-最终待审版本摘要
-不负责
-替代人工法务拍板
-6. 智能体协作关系
-AGENT-01 同业/监管变化摘要
-→ AGENT-02 协议重构
-→ AGENT-03 合规校验
-→ AGENT-04 法务审核包生成
-→ Dify Human Review（人工法务确认）
-回退关系
-人工法务确认
-├─ 通过 → 待发布中心
-├─ 退回 → 返回 AGENT-02
-└─ 补材料 → 返回材料导入阶段
-7. 输入输出数据模型
-7.1 通用输入对象：CaseContext
-{
-  "case_id": "case_001",
-  "customer_id": "cust_001",
-  "customer_name": "某银行",
-  "app_name": "手机银行APP",
-  "business_line": "retail",
-  "language": "zh-CN",
-  "materials": {
-    "current_policy_text": "...",
-    "prd_text": "...",
-    "permission_items": [],
-    "sdk_items": []
-  },
-  "external_context": {
-    "peer_updates": [],
-    "regulatory_updates": []
-  },
-  "metadata": {
-    "submitted_at": "2026-04-18T10:00:00Z",
-    "source": "desktop+filebay"
-  }
-}
-7.2 权限项结构 PermissionItem
-{
-  "name": "相��权限",
-  "purpose": "身份证识别",
-  "trigger_page": "开户流程",
-  "required": true
-}
-7.3 SDK 项结构 SdkItem
-{
-  "name": "某推送SDK",
-  "vendor": "某厂商",
-  "purpose": "消息推送",
-  "data_items": ["设备标识", "网络信息"],
-  "privacy_url": "https://example.com/privacy"
-}
-7.4 同业/监管变化摘要输出 PeerRegSummary
-{
-  "peer_summary": "头部银行近期在第三方SDK披露、权限用途描述上更细化。",
-  "reg_summary": "近期监管强调最小必要原则和第三方共享透明度。",
-  "reference_clauses": [
-    {
-      "source": "某大行 2026-04 版本",
-      "clause": "..."
-    }
-  ],
-  "risk_alerts": [
-    "第三方SDK用途披露不足"
-  ]
-}
-7.5 差异分析输出 GapAnalysis
-{
-  "gaps": [
-    {
-      "type": "permission_mismatch",
-      "severity": "high",
-      "description": "PRD中存在相机权限使用，但协议未明确用途",
-      "evidence": ["prd", "current_policy"]
-    }
-  ],
-  "rewrite_suggestions": [
-    {
-      "section": "权限说明",
-      "old_text": "...",
-      "new_text": "...",
-      "reason": "补充相机权限用途说明"
-    }
-  ],
-  "redline_seed": {
-    "old_policy": "...",
-    "suggestions": []
-  }
-}
-7.6 合规校验输出 ComplianceCheck
-{
-  "risk_levels": {
-    "high": 2,
-    "medium": 3,
-    "low": 1
-  },
-  "compliance_gaps": [
-    {
-      "severity": "high",
-      "item": "SDK共享说明缺失",
-      "basis": "监管要求/同业样本"
-    }
-  ],
-  "pending_legal_items": [
-    "是否需要单独披露某第三方SDK用途"
-  ],
-  "conclusion": "需法务确认后方可进入待发布"
-}
-7.7 法务审核包输出 LegalReviewPack
-{
-  "review_pack": {
-    "background": "...",
-    "key_changes": [],
-    "risk_summary": [],
-    "pending_items": [],
-    "references": []
-  },
-  "review_recommendation": "need_legal_review",
-  "focus_items": [
-    "第三方共享条款",
-    "相机权限用途说明"
-  ]
-}
-8. 接口定义
-API-01 同业/监管变化摘要
-
-POST /api/agents/peer-reg-summary
-
-request
-{
-  "peer_updates": [],
-  "regulatory_updates": [],
-  "business_line": "retail",
-  "app_name": "手机银行APP"
-}
-response
-
-返回 PeerRegSummary
-
-API-02 协议重构
-
-POST /api/agents/policy-rewrite
-
-request
-{
-  "case_context": {},
-  "peer_reg_summary": {}
-}
-response
-
-返回 GapAnalysis
-
-API-03 合规校验
-
-POST /api/agents/compliance-check
-
-request
-{
-  "case_context": {},
-  "gap_analysis": {}
-}
-response
-
-返回 ComplianceCheck
-
-API-04 法务审核包生成
-
-POST /api/agents/legal-pack
-
-request
-{
-  "case_context": {},
-  "peer_reg_summary": {},
-  "gap_analysis": {},
-  "compliance_check": {}
-}
-response
-
-返回 LegalReviewPack
-
-9. 与 Dify 的集成契约
-Dify 负责调用顺序
-调 peer-reg-summary
-调 policy-rewrite
-调 compliance-check
-调 legal-pack
-进入人工法务确认节点
-Dify 提供给智能体服务的能力
-当前任务上下文
-知识库检索结果
-FileBay / 桌面端材料文本化结果
-人工审核节点状态
-本地智能体服务对 Dify 的要求
-输入字段完整
-同一 case_id 可幂等重试
-每次响应都返回结构化 JSON
-所有高风险结论必须给出处说明字段
-所有服务必须支持超时和错误码返回
-10. 错误码与失败处理
-错误码建议
-4001 输入材料缺失
-4002 输入格式错误
-5001 智能体推理失败
-5002 外部上下文缺失
-5003 结果结构化失败
-失败处理原则
-缺材料：直接返回 need_more_material
-推理失败：允许 Dify 重试 1 次
-结构化失败：返回原始结果和错误说明
-任何情况下不输出“已完全合规”
-11. 非功能要求
-NFR-01 安全
-不接收未脱敏敏感原文作为长期存储对象
-日志中不落完整敏感材料
-所有输出需带 case_id 和时间戳
-NFR-02 可观测性
-每次调用记录：
-case_id
-agent_name
-started_at
-ended_at
-status
-error_code
-NFR-03 幂等性
-同一个 case_id + stage + input_hash 重试时，允许返回同一结果或同一版本结果
-NFR-04 输出一致性
-所有智能体输出必须严格符合 JSON schema
-不允许返回自由散文式主结果
-NFR-05 可扩展性
-后续能平移复用到：
-制度评审
-监管报送
-合同审核
-12. 验收标准
-AC-01 同业/监管变化摘要
-
-Given 输入头部银行变化列表与监管变化列表
-When 调用 peer-reg-summary
-Then 返回同业摘要、监管摘要、参考条款和风险提醒
-And 至少包含 1 条可引用参考条款
-Verification programmatic + human review
-
-AC-02 协议重构
-
-Given 输入当前协议、PRD、权限、SDK 和变化摘要
-When 调用 policy-rewrite
-Then 返回差异分析报告和建议修订条款
-And 输出必须包含：
-
-gaps
-rewrite_suggestions
-redline_seed
-Verification programmatic
-AC-03 合规校验
-
-Given 输入重构结果
-When 调用 compliance-check
-Then 返回风险分级、合规缺口和待法务确认项
-And 不允许输出“已完全合规”绝对结论
-Verification programmatic + human review
-
-AC-04 法务审核包生成
-
-Given 输入前 3 个智能体结果
-When 调用 legal-pack
-Then 返回完整审核包、审核建议和重点关注项
-And 审核包必须可被 Dify 直接渲染为结构化文档
-Verification programmatic + human review
-
-AC-05 幂等性
-
-Given 相同 case_id、相同输入重复调用
-When 重试同一阶段接口
-Then 服务不得产生冲突性结果结构
-Verification programmatic
-
-AC-06 错误处理
-
-Given 缺少 PRD / 权限 / SDK 任一核心材料
-When 调用相关接口
-Then 返回标准错误码与缺失材料提示
-Verification programmatic
-
-13. 研发拆解建议
-Sprint 1
-定义统一 JSON schema
-完成 AGENT-01 / AGENT-02 接口
-打通 Dify 基本调用链
-Sprint 2
-完成 AGENT-03 / AGENT-04
-补全错误码、日志、幂等
-联调法务审核节点
-Sprint 3
-优化提示词、规则、输出一致性
-联调待发布中心落库
-准备 demo 数据与回归用例
-14. 研发开工前必须确认的 4 个输入
-
-这 4 个如果不定，研发会反复返工。
-
-1. 当前协议输入格式
-纯文本
-文件解析结果
-章节结构是否需要保留
-2. PRD / 权限 / SDK 的最小字段集
-
-至少要确定有没有统一模板。
-
-3. 同业/监管变化摘要来源格式
-
-是全文、结构化差异，还是摘要结果。
-
-4. 待发布中心落库格式
-
-即使本轮不开发，也要先定义字段。
-
-最终结论
-
-对，你现在本地研发范围可以收敛为“智能体服务层”，所以这份最优修订版 spec 也应该针对智能体。
-
-但要记住，不是只针对 Prompt，而是针对：
-
-角色智能体服务 + 输入输出合同 + Dify 集成契约
-
-
-《4 个智能体的 Prompt 草案 + JSON Schema + Dify 节点映射表》。
-按你现在的边界，建议这样落地：
-
-4 个智能体服务由你本地/服务端开发；Dify 负责入口、检索、编排、人工法务确认、结果整合。
-
-Dify 这层最适合用 Workflow + User Input 作为主入口；材料解析用 Document Extractor；监管与同业样本走 Knowledge Retrieval；调用你本地智能体服务走 HTTP Request；人工法务确认走 Human Input；结果整合和文档化走 Template；中间的标准化与字段整理用 Code。这些能力都在 Dify 当前官方文档里有对应节点定义。
-
-记忆点
-不是 1 个万能 Prompt，而是 4 个角色智能体各司其职。
-所有智能体输出都必须是 JSON，不能返回散文式长文。
-法务最终结论不由智能体给出，只输出审核建议和待确认项。
-Dify 不做你的核心业务判断，Dify 做编排、检索、审核节点、结果组装。
-最重要的是统一输入输出合同，否则 4 个智能体接不起来。
-先保结构稳定，再调 Prompt 质量。
-一、总体协作链
-输入材料
-（协议 / PRD / 权限清单 / SDK清单 / 同业变化 / 监管变化）
-→ AGENT-01 同业/监管变化摘要
-→ AGENT-02 协议重构
-→ AGENT-03 合规校验
-→ AGENT-04 法务审核包生成
-→ Dify Human Input 人工法务确认
-→ 通过 / 退回 / 补材料
-二、统一输入上下文
-
-4 个智能体都建议吃统一对象，避免每个接口各说各话。
-
-统一输入对象 CaseContext
-{
-  "case_id": "case_001",
-  "customer_id": "cust_001",
-  "customer_name": "某银行",
-  "app_name": "手机银行APP",
-  "business_line": "retail",
-  "language": "zh-CN",
-  "materials": {
-    "current_policy_text": "当前隐私协议全文",
-    "prd_text": "PRD/功能说明全文",
-    "permission_items": [
-      {
-        "name": "相机权限",
-        "purpose": "身份证识别",
-        "trigger_page": "开户流程",
-        "required": true
-      }
-    ],
-    "sdk_items": [
-      {
-        "name": "某推送SDK",
-        "vendor": "某厂商",
-        "purpose": "消息推送",
-        "data_items": ["设备标识", "网络信息"],
-        "privacy_url": "https://example.com/privacy"
-      }
-    ]
-  },
-  "external_context": {
-    "peer_updates": [],
-    "regulatory_updates": []
-  },
-  "metadata": {
-    "submitted_at": "2026-04-18T10:00:00Z",
-    "source": "desktop+filebay"
-  }
-}
-三、4 个智能体 Prompt 草案
-
-下面给的是 System Prompt 草案。
-建议你本地服务采用：
-
-system_prompt
-developer_prompt
-user_payload_json
-
-三段式结构。
-这里先给最关键的 system_prompt。
-
-AGENT-01 同业/监管变化摘要智能体
-目标
-
-把同业协议变化、监管变化整理成后续可消费的“变化摘要对象”。
-
-System Prompt
-你是银行APP隐私合规场景中的“同业/监管变化摘要智能体”。
-
-你的职责只有四项：
-1. ��纳头部银行隐私协议的关键变化；
-2. 归纳监管文件、处罚案例、通报中的关键变化；
-3. 提炼出可供客户协议重构参考的条款方向；
-4. 标记高风险提醒项。
-
-你不是协议重构智能体，不负责直接改写客户协议，也不负责最终合规结论。
-
-输入会包含：
-- peer_updates：同业协议变化记录
-- regulatory_updates：监管变化记录
-- app_name / business_line：场景上下文
-
-输出必须满足以下要求：
-- 只输出 JSON，不要输出 Markdown，不要输出解释性废话；
-- 必须区分 peer_summary 和 reg_summary；
-- reference_clauses 只保留最有代表性的参考条款；
-- risk_alerts 只输出真正影响后续协议重构的风险点；
-- 若信息不足，明确写入 insufficient_context=true，不得臆造。
-
-输出语言：中文。
-输出 JSON 示例
-{
-  "insufficient_context": false,
-  "peer_summary": "头部银行近期在第三方SDK披露、权限用途描述上更细化。",
-  "reg_summary": "近期监管强调最小必要原则、第三方共享透明度和用户知情权。",
-  "reference_clauses": [
-    {
-      "source": "某大行 2026-04 版本",
-      "topic": "第三方SDK披露",
-      "clause": "我们接入第三方SDK用于消息推送，并披露其处理信息类型与用途。"
-    }
-  ],
-  "risk_alerts": [
-    "第三方SDK用途披露不足",
-    "相机权限用途描述不充分"
-  ]
-}
-AGENT-02 协议重构智能体
-目标
-
-基于客户材料 + 同业/监管摘要，生成差异分析和修订建议。
-
-System Prompt
-你是银行APP隐私合规场景中的“协议重构智能体”。
-
-你的职责只有三项：
-1. 对比客户当前协议、PRD、权限清单、SDK清单之间的一致性；
-2. 结合同业变化摘要和监管变化摘要，识别协议缺口；
-3. 生成建议修订条款和红线稿输入。
-
-你不是合规校验智能体，也不是法务审核智能体。
-你不能输出“已完全合规”“可直接发布”之类的最终结论。
-
-输入会包含：
-- 当前协议全文
-- PRD全文
-- 权限清单
-- SDK清单
-- 同业变化摘要
-- 监管变化摘要
-
-你的输出必须：
-- 只输出 JSON；
-- 每个 gap 必须有 type、severity、description、evidence；
-- rewrite_suggestions 必须给出 old_text/new_text/reason；
-- 若某个判断缺少明确依据，必须放入 uncertain_items；
-- 不允许生成没有依据来源的强结论。
-
-输出语言：中文。
-输出 JSON 示例
-{
-  "insufficient_context": false,
-  "gaps": [
-    {
-      "type": "permission_mismatch",
-      "severity": "high",
-      "description": "PRD中存在相机权限使用，但协议未明确用途",
-      "evidence": ["prd.camera_usage", "policy.permissions_section"]
-    }
-  ],
-  "rewrite_suggestions": [
-    {
-      "section": "权限说明",
-      "old_text": "我们可能会申请设备权限。",
-      "new_text": "为完成身份证识别与开户验证功能，我们会在开户流程中申请相机权限。",
-      "reason": "补充相机权限用途说明"
-    }
-  ],
-  "uncertain_items": [
-    "某第三方SDK是否需要单独披露其数据共享目的"
-  ],
-  "redline_seed": {
-    "old_policy": "当前协议全文",
-    "suggestions": [
-      {
-        "section": "权限说明",
-        "new_text": "..."
-      }
-    ]
-  }
-}
-AGENT-03 合规校验智能体
-目标
-
-校验修订建议是否覆盖监管要求，标出高风险与待法务确认项。
-
-System Prompt
-你是银行APP隐私合规场景中的“合规校验智能体”。
-
-你的职责只有三项：
-1. 校验协议重构结果是否覆盖主要监管要求；
-2. 校验修订建议与PRD、权限清单、SDK清单是否一致；
-3. 输出风险等级、合规缺口和待法务确认项。
-
-你不负责直接修改协议文本，不负责最终法律意见。
-你绝对不能输出“已完全合规”“无需法务审核”这类结论。
-
-输入会包含：
-- 当前协议文本
-- 协议重构结果
-- PRD / 权限 / SDK 材料
-- 同业变化摘要
-- 监管变化摘要
-
-你的输出必须：
-- 只输出 JSON；
-- 对每个风险项标出 severity、item、basis；
-- pending_legal_items 只放真正需要法务拍板的问题；
-- conclusion 只能是“需法务确认后进入待发布”或类似审慎表达；
-- 若依据不足，必须写入 insufficient_context=true。
-
-输出语言：中文。
-输出 JSON 示例
-{
-  "insufficient_context": false,
-  "risk_levels": {
-    "high": 2,
-    "medium": 3,
-    "low": 1
-  },
-  "compliance_gaps": [
-    {
-      "severity": "high",
-      "item": "SDK共享说明缺失",
-      "basis": "监管要求强调第三方共享透明度"
-    }
-  ],
-  "pending_legal_items": [
-    "是否需要单独披露某第三方SDK的数据共享场景",
-    "是否需要在未成年人条款中补充说明"
-  ],
-  "conclusion": "需法务确认后方可进入待发布"
-}
-AGENT-04 法务审核包生成智能体
-目标
-
-把前 3 个智能体结果整理成法务可直接阅读的审核包。
-
-System Prompt
-你是银行APP隐私合规场景中的“法务审核包生成智能体”。
-
-你的职责只有三项：
-1. 汇总同业/监管变化摘要、协议重构结果、合规校验结果；
-2. 生成适合法务阅读的审核包结构；
-3. 输出审核建议与重点关注条款。
-
-你不替代人工法务做最终审批。
-你不能输出“审核通过”最终决定，只能输出“建议通过 / 建议退回 / 建议补材料”。
-
-输入会包含：
-- 同业变化摘要
-- 监管变化摘要
-- 差异分析报告
-- 修订建议稿
-- 合规缺口清单
-- 风险等级
-- 待法务确认项
-
-你的输出必须：
-- 只输出 JSON；
-- review_pack 中必须有 background、key_changes、risk_summary、pending_items、references；
-- review_recommendation 只能取：suggest_approve / suggest_reject / suggest_more_material；
-- focus_items 只保留最关键的法务关注点；
-- 不得出现最终审批语气。
-
-输出语言：中文。
-输出 JSON 示例
-{
-  "review_pack": {
-    "background": "本次更新基于同业协议变化与监管强调项，对客户协议进行重构。",
-    "key_changes": [
-      "补充相机权限用途说明",
-      "补充第三方SDK共享说明"
-    ],
-    "risk_summary": [
-      "第三方共享条款不充分",
-      "权限申请用途描述不清"
-    ],
-    "pending_items": [
-      "某SDK是否需要单独列示",
-      "历史采集项描述是否需要追溯修订"
-    ],
-    "references": [
-      "某监管通报 2026-03",
-      "某大行协议版本 2026-04"
-    ]
-  },
-  "review_recommendation": "suggest_more_material",
-  "focus_items": [
-    "第三方SDK共享条款",
-    "相机权限用途说明",
-    "未成年人信息处理条款"
-  ]
-}
-四、JSON Schema
-
-下面给研发直接能用的 简化版 JSON Schema。
-你可以先按这个版本开发，后面再细化字段。
-
-1. PeerRegSummary.schema.json
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "PeerRegSummary",
-  "type": "object",
-  "required": [
-    "insufficient_context",
-    "peer_summary",
-    "reg_summary",
-    "reference_clauses",
-    "risk_alerts"
-  ],
-  "properties": {
-    "insufficient_context": {
-      "type": "boolean"
-    },
-    "peer_summary": {
-      "type": "string"
-    },
-    "reg_summary": {
-      "type": "string"
-    },
-    "reference_clauses": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["source", "topic", "clause"],
-        "properties": {
-          "source": { "type": "string" },
-          "topic": { "type": "string" },
-          "clause": { "type": "string" }
-        }
-      }
-    },
-    "risk_alerts": {
-      "type": "array",
-      "items": { "type": "string" }
-    }
-  }
-}
-2. GapAnalysis.schema.json
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "GapAnalysis",
-  "type": "object",
-  "required": [
-    "insufficient_context",
-    "gaps",
-    "rewrite_suggestions",
-    "uncertain_items",
-    "redline_seed"
-  ],
-  "properties": {
-    "insufficient_context": {
-      "type": "boolean"
-    },
-    "gaps": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["type", "severity", "description", "evidence"],
-        "properties": {
-          "type": { "type": "string" },
-          "severity": {
-            "type": "string",
-            "enum": ["high", "medium", "low"]
-          },
-          "description": { "type": "string" },
-          "evidence": {
-            "type": "array",
-            "items": { "type": "string" }
-          }
-        }
-      }
-    },
-    "rewrite_suggestions": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["section", "old_text", "new_text", "reason"],
-        "properties": {
-          "section": { "type": "string" },
-          "old_text": { "type": "string" },
-          "new_text": { "type": "string" },
-          "reason": { "type": "string" }
-        }
-      }
-    },
-    "uncertain_items": {
-      "type": "array",
-      "items": { "type": "string" }
-    },
-    "redline_seed": {
-      "type": "object",
-      "required": ["old_policy", "suggestions"],
-      "properties": {
-        "old_policy": { "type": "string" },
-        "suggestions": {
-          "type": "array",
-          "items": {
-            "type": "object",
-            "required": ["section", "new_text"],
-            "properties": {
-              "section": { "type": "string" },
-              "new_text": { "type": "string" }
-            }
-          }
-        }
-      }
-    }
-  }
-}
-3. ComplianceCheck.schema.json
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "ComplianceCheck",
-  "type": "object",
-  "required": [
-    "insufficient_context",
-    "risk_levels",
-    "compliance_gaps",
-    "pending_legal_items",
-    "conclusion"
-  ],
-  "properties": {
-    "insufficient_context": {
-      "type": "boolean"
-    },
-    "risk_levels": {
-      "type": "object",
-      "required": ["high", "medium", "low"],
-      "properties": {
-        "high": { "type": "integer" },
-        "medium": { "type": "integer" },
-        "low": { "type": "integer" }
-      }
-    },
-    "compliance_gaps": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["severity", "item", "basis"],
-        "properties": {
-          "severity": {
-            "type": "string",
-            "enum": ["high", "medium", "low"]
-          },
-          "item": { "type": "string" },
-          "basis": { "type": "string" }
-        }
-      }
-    },
-    "pending_legal_items": {
-      "type": "array",
-      "items": { "type": "string" }
-    },
-    "conclusion": {
-      "type": "string"
-    }
-  }
-}
-4. LegalReviewPack.schema.json
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "LegalReviewPack",
-  "type": "object",
-  "required": [
-    "review_pack",
-    "review_recommendation",
-    "focus_items"
-  ],
-  "properties": {
-    "review_pack": {
-      "type": "object",
-      "required": [
-        "background",
-        "key_changes",
-        "risk_summary",
-        "pending_items",
-        "references"
-      ],
-      "properties": {
-        "background": { "type": "string" },
-        "key_changes": {
-          "type": "array",
-          "items": { "type": "string" }
-        },
-        "risk_summary": {
-          "type": "array",
-          "items": { "type": "string" }
-        },
-        "pending_items": {
-          "type": "array",
-          "items": { "type": "string" }
-        },
-        "references": {
-          "type": "array",
-          "items": { "type": "string" }
-        }
-      }
-    },
-    "review_recommendation": {
-      "type": "string",
-      "enum": [
-        "suggest_approve",
-        "suggest_reject",
-        "suggest_more_material"
-      ]
-    },
-    "focus_items": {
-      "type": "array",
-      "items": { "type": "string" }
-    }
-  }
-}
-五、Dify 节点映射表
-
-你现在最适合的 Dify 形态是：
-
-1 个主 Workflow：隐私合规协同工作台
-1 个辅助 Trigger Workflow：同业/监管变化摘要更新
-可选 1 个 Chatflow：法务追问助手
-
-Dify 的 Workflow/Chatflow、User Input、Document Extractor、Knowledge Retrieval、HTTP Request、Human Input、Template、Code 节点都能直接支撑这套设计。User Input 适合作为用户入口；Document Extractor 负责把上传文档转成文本；Knowledge Retrieval 负责把知识库检索结果交给下游节点；HTTP Request 连接你的本地/服务端智能体 API；Human Input 负责人工审核；Template 用 Jinja2 格式化多源数据；Code 适合做复杂数据整形。
-
-A. 主 Workflow：隐私合规协同工作台
-顺序	Dify 节点	节点用途	输入	输出	对应智能体/逻辑
-1	User Input	收集 case 基本信息和文件	customer_name, app_name, policy_file, prd_file, permission_file, sdk_file	原始输入变量	场景入口
-2	HTTP Request（可选）	若文件已在 FileBay，拉取材料文本或元信息	file_id / path	file text / metadata	材料读取
-3	Document Extractor - Policy	解析协议文本	policy_file	policy_text	材料解析
-4	Document Extractor - PRD	解析 PRD 文本	prd_file	prd_text	材料解析
-5	Document Extractor - Permission	解析权限清单	permission_file	permission_text	材料解析
-6	Document Extractor - SDK	解析 SDK 清单	sdk_file	sdk_text	材料解析
-7	Code	标准化 CaseContext，补默认值，做缺材料校验	上述文本与表单变量	case_context, missing_items	输入标准化
-8	Knowledge Retrieval - Regulatory	检索监管依据库	app_name / 关键词	regulatory_context	外部依据
-9	Knowledge Retrieval - Peer	检索同业样本库	app_name / 行业关键词	peer_context	外部依据
-10	HTTP Request	调 AGENT-01	peer_updates + regulatory_updates	peer_reg_summary	同业/监管变化摘要
-11	HTTP Request	调 AGENT-02	case_context + peer_reg_summary	gap_analysis	协议重构
-12	HTTP Request	调 AGENT-03	case_context + gap_analysis	compliance_check	合规校验
-13	HTTP Request	调 AGENT-04	case_context + 上游三段结果	legal_review_pack	法务审核包
-14	Template	组装差异分析报告、审核摘要、红线稿展示体	上游 JSON	formatted_review_material	结果格式化
-15	Human Input	人工法务确认	formatted_review_material	approve / reject / need_more_material + comments	最终法务确认
-16	Code / 条件逻辑	根据法务结果分流	human decision	branch result	流程分支
-17A	HTTP Request	写入待发布中心	审核通过结果	draft_id / version	通过分支
-17B	Template	生成退回修改清单	法务 comments	reject_summary	退回分支
-17C	Template	生成补材料清单	missing_items + comments	material_request	补材料分支
-18	Answer / Output	对前端返回最终结果	分支结果	最终可展示结果	工作流结束
-B. 辅助 Trigger Workflow：同业/监管变化更新
-顺序	Dify 节点	用途	输入	输出
-1	Trigger / Webhook	定时或外部事件触发	schedule / webhook	trigger params
-2	HTTP Request	调外部抓取服务	target list	peer_updates / regulatory_updates
-3	HTTP Request	调 AGENT-01	peer_updates + regulatory_updates	peer_reg_summary
-4	Template	生成变化摘要文本	peer_reg_summary	summary_doc
-5	HTTP Request	写入样本库服务/消息中心	summary_doc	sync result
-C. 可选 Chatflow：法务追问助手
-节点	用途
-User Input	法务追问
-Knowledge Retrieval - Regulatory / Peer	检索监管与同业依据
-LLM	生成解释型回答
-Answer	输出追问结果
-
-这个助手不要做审批，只做“为什么这样改”“依据是什么”的解释层。
-
-六、推荐的本地/服务端 API 形态
-1. POST /api/agents/peer-reg-summary
-
-输入：
-
-peer_updates
-regulatory_updates
-app_name
-business_line
-
-输出：
-
-PeerRegSummary
-2. POST /api/agents/policy-rewrite
-
-输入：
-
-case_context
-peer_reg_summary
-
-输出：
-
-GapAnalysis
-3. POST /api/agents/compliance-check
-
-输入：
-
-case_context
-gap_analysis
-
-输出：
-
-ComplianceCheck
-4. POST /api/agents/legal-pack
-
-输入：
-
-case_context
-peer_reg_summary
-gap_analysis
-compliance_check
-
-输出：
-
-LegalReviewPack
-七、Prompt 落地建议
-
-这 4 个 Prompt 不建议直接写死在 Dify 里。
-最优方式是：
-
-Prompt 主体放你本地智能体服务
-Dify 只传：
-结构化输入
-知识库摘要结果
-当前任务上下文
-
-这样后面你调 Prompt、做 A/B、做版本管理都会更好。
-
-八、研发最容易踩的坑
-1. 输出不结构化
-
-必须强制 JSON。
-不要让任何一个智能体返回“自然语言段落 + 半结构化列表”。
-
-2. AGENT-02 和 AGENT-03 职责混掉
-AGENT-02 负责 重构
-AGENT-03 负责 校验
-
-绝对不能混。
-
-3. AGENT-04 越权
-
-它只能输出审核包和建议，不能输出最终审批结论。
-
-4. Dify 承担太多业务逻辑
-
-Dify 负责编排，不要把规则判断都塞进 Dify 画布。
-
-九、最优的最小可跑版本
-
-第一版只要做到这 4 点就能开跑：
-
-4 个 API 可用
-4 个 JSON Schema 稳定
-Dify 主 Workflow 能串起来
-法务 Human Input 能完成“通过 / 退回 / 补材料”
-
-这样你就已经有了一个可演示、可试用、可继续优化的样板场景。
-
-十、最终结论
-
-这套东西现在已经可以直接给研发了。
-最关键的不是再补概念，而是：
-
-先把 4 个智能体的 JSON 输出做稳定，再把 Dify 工作流串起来。