Files
wecom_it_smart_desk/docs/12-重构记录/00-v4.0重构总方案.md
T

4.9 KiB
Raw Blame History

智能回复系统深度重构总方案(v4.0

日期2026-07-17 前置版本v3.0(后端 ApprovalMatcher 统一匹配)/ v3.1Dify 无 action 降级 + 超时降级) 问题基线:20 项已验证问题(后端 8 + 前端 6 + 配置 6),全部对照源码核实 用户决策Redis 密码立即轮换 / Triage 分诊链路整体删除 / D1 意图合并采用激进方案 工作方式:敏捷批次交付 + DevOps(文档与代码同 PR、每批次 RELEASE-NOTES


一、目标分层架构

接入层 Ingressh5.py / ws.py
  └─ 只鉴权、落库用户消息、立即返回、投递任务
编排层 Orchestrationh5_ai_task.py 管线化)
  └─ 只做流程编排,不直接发起外部调用
推理层 Inferenceai_service.py,全系统唯一 Dify 调用点)
  └─ 真单例;native 12s + proxy 12s 超时预算;一次调用返回 intent/路由/审批字段
匹配层 Matchingapproval_matcher.py,纯函数)
  └─ match_and_build_card / match_by_keywords / get_all_categories
渲染层 Rendering(前端纯渲染)
  └─ WS 契约单点 build_message_ws_payload();审批卡片渲染点 ≤ 2 处

单一职责红线ApprovalMatcher 不碰 WS/DBAIService 不认识"审批/路由/BYOD";编排层不 new httpxWS 推送统一出口。

二、关键设计决策

# 决策 理由
D1 意图识别并入主 Dify 调用 routing detect 与主对话是同一 Dify 应用同一 key,消除 15s+30s 串行叠加(最坏 45s → ~15s)
D2 超时预算内化 httpx native 12s + proxy 12s < wait_for 30s,修复 proxy 兜底数学不可达问题
D3 匹配失败不静默 ApprovalMatcher 末路返回全量卡片(get_all_categories),前端永不空白
D4 WS 消息契约单点化 修复 new_message 前端白名单丢字段(坐席图片/文件不渲染)
D5 triage 分诊链路删除 前端零挂载点(已确认,grep 无引用)
D6 快捷申请走新端点 GET /approval/all-categories-card,修复 showApprovalCard 空白气泡 P0

三、批次计划

批次 1(P0,~2 天,彼此独立可单独上线)

内容 工作量
P0-1 生产 workers=2 → 1(删除/修改 override 与 deploy-server compose 0.5d
P0-2 DIFY_NATIVE_* 生产配置(compose environment + .env.production 0.5d
P0-3 快捷申请空白气泡修复(新 all-categories-card 端点 + store 改造) 0.5d
P0-4 RecommendCard invokeApproval ReferenceError 修复 0.5d
P0-5 WS new_message 前端全字段透传 1d
P0-6 超时预算切分(native 12s / proxy 12s 1d

上线前 git tag pre-v4-refactor;文档同步:本目录 01-批次1-P0执行记录.md + RELEASE-NOTES v4.0.0。

批次 2P1 基础,~3 天)

P1-1 AIService 真单例(修复 httpx 连接泄漏)→ P1-2 统一 Dify 调用点(删除 approval/byod detect-intent 死链路、routing 改调 chat_native)→ P1-4 Matcher 死分支删除 + 失败兜底(D3)→ P1-7 配置治理(APP_ENV=production、Redis 密码轮换(低峰期)、os.getenv 旁路收敛、3 个潜伏 bug 修复:app_root/AsyncIOSScheduler 拼写/config.py logger)→ P1-6 dynamic_recommend 死逻辑清理。

文档同步:架构文档 v2 §15.4.5 重写(v3.0 纯渲染架构)。

批次 3(P1 核心,~4 天,观察 24h)

P1-3 编排层管线化(D1 激进合并:先 5 条真实消息验证 Dify intent 字段稳定性,不稳定退回 gather 并行)→ P1-5 WS 死路由清理(ai_reply_chunk/pending_close_request/quiz_diagnostic_answer)。

观察指标:AI 回复到达率 ≥99%、平均响应 ≤20s、转人工率不升。文档同步:架构文档新增「智能回复链路 v4」章节。

批次 4P2,按需)

P2-1 死代码大扫除(含 3 个 .bak 文件、构建产物目录入库)→ P2-2 triage 整链删除 → P2-4 测试补齐 → P2-3 前端 store 拆分 → P2-5 审批回调 TODO 收口。

四、验收清单

  • 生产 --workers 1AI 回复 WS 到达率 100%
  • 日志走「Dify 原生 API」,无 proxy 路径、无 [object Object]
  • Dify 调用点全系统唯一
  • process_h5_ai_reply < 100 行,try/except ≤ 3 对;路由消息端到端 < 35s
  • ApprovalMatcher 任意输入均有卡片输出(无 None)
  • H5 快捷申请/AI 卡片/关键词兜底三场景渲染一致
  • 坐席发图片/文件,H5 WS 实时渲染
  • pytest + npm run build 全绿;/version 返回真实 git hash

五、回滚策略

每批次独立 PR + 独立部署;git tag pre-v4-refactor 全量回滚点;配置类(DIFY_NATIVE/APP_ENV/Redis)改回旧值重启即可;批次 3 异常回滚至批次 2 状态。


执行记录:见本目录 01-批次1-P0执行记录.md(批次 1 完成后填写)等。