模块 5 · 边界与接缝

两套知识库、合规口径
和一期代码差在哪？

客服线「能答什么」不只看 LangGraph，还看知识库分家和合规文档 vs 一期实现。 指挥 AI 改 RAG 或「放开推荐」前，先对齐下面这张差分表。

两套 RAG：别灌错库

客服 · fin_* 三库

登录客户的对话编排（customer_service.py）和游客试聊编排（visitor_service.py）遇到产品/政策/FAQ 类问题时，都会交给 RAG 检索层（rag_service.py：把问题向量化后查 Milvus），从 fin_product · fin_policy · fin_faq 三个知识集合取片段。

顾问 · kb_product_rules

理财师/风控通用 tool→llm→guard 编排（agent_service.py）的 search_knowledge Tool → 知识库对话 Tool 注册与分发（kb_tools.py）· 集合名不同，不能把顾问文档灌进 fin_*。

风控 · 不开放 search_knowledge

知识库对话 Tool 注册与分发（kb_tools.py）注册表对 risk 关闭——风控对话走 RISK_TOOL_REGISTRY 四只读 Tool。

指挥 AI 误区： 「统一成一个知识库」听起来省事，但会破坏各 Agent 合规过滤与检索策略——要改先对契约和 scripts/kb/ 脚本。

合规允许 vs 一期拒答（你拍板要讲的）

合规文档里，客户 Agent 在过 R-02 + 附免责 + 标注需持证审核时，可以做「匹配说明」——但一期代码对主动推荐/预测类问题走 reject 静态拒答，更保守。

合规文档 · 允许方向 
适当性匹配说明（C-11）
→ 系统判定 + 规则解读 + 免责声明
→ 禁止具体操作指令
一期代码 · 实际行为

suitability_check Tool：「我能买 R3 吗」「有哪些匹配产品」——允许。

「推荐稳赚基金」「买什么好」→ reject + REJECT_ADVICE_TEXT——直接拒。

要「放开推荐」= 产品决策 + 改 intent 路由 + 合规评审，不是只改 prompt 一句。

群聊：同一客户，两种问法

游客与画像：客户看不见 L2/L3

游客走游客试聊 9 节点编排（visitor_service.py）：无 JWT、无 Core 持仓查询、不写登录客户会话表。L1 画像由客服线后台抽槽写入；L2/L3 对客户不可见——合规上客户只能 enrich L1，不能替代正式风评。

AI 建议「把 kb 和 fin 合成一个 Milvus 集合简化维护」，你怎么回？