lzf_0626
a876e9ead7
对四份需求文档（智能客服方案 v1.3、基金运营流程、风控模块详细业务流程、投资顾问流程） 与现有底座逐项比对后的实现拆解，用于开工前明确边界、工作量与决策点。 核心结论：可实现。底座 52 张表与流程设计高度吻合——风控的 ack_status/is_escalated/close_reason/trigger_rule_codes、客服的 svc_handover_ticket.confidence、 投顾的 client_facing_content.review_status、biz_work_order 的双录与风险揭示字段均已在位； 客服方案的七步骨架与 BaseAgent 骨架完全一致；适当性 C1-C5/R1-R5 已实现且不接受调用方传值； 风控文档定义的 SSE 事件（start/tools/delta/replace/done）与底座现有实现完全一致。 文档内容： 1. 覆盖度总览 + 四模块逐项拆解（已就绪 / 需新写 / 必须业务补充）。 2. 指出两处真实缺口：邮件 SMTP 在 app/ 中零实现；规则引擎只有 trigger_rule_codes 字段 而无引擎本体（风控明确要求"规则引擎产生预警、Agent 不产生"，属确定性逻辑，不能用模型代替）。 3. 指出场外运营是唯一需要新建表的模块（底座 15 张 fin_* 全为场内模拟交易， AGENTS.md 要求场外流程独立，不得写入场内交易表）。 4. 列出 6 个必须先决策的事项：接口形态（底座异步 + SSE vs 方案的同步 chat/customer）、 模型与 embedding 维度（直接决定 Milvus 集合 schema）、RAG 混合判定公式（方案未给）、 规则引擎的承载方式、场外运营排期、合规校验前置还是后置。 5. 建议开工顺序：客服 → 投顾 → 风控（规则引擎宜单独立项）→ 场外运营（缺真实单据样本）。 说明：本提交只含拆解文档，不含需求原文。需求原文的纯文本提取物位于 _flows/（未跟踪）， 是否入库待定；临时提取脚本已删除。