feat: 建客服知识库（Milvus 三集合）并修复模型端点筛选缺陷

一、知识库建设
- 新增 tools/build_knowledge_chunks.py：把 knowledge/ 下文档切成可检索知识块。
  采用「叶子标题」策略（其后没有更深标题的标题即切分点），同时覆盖三种真实结构：
  带子条款的按子条款切、无子条款的条款单独成块、无小节的章整章成块。
  第一版按固定标题级别切是失败的——适当性指南的条款是 ### 而没有 ####，产品手册的
  ### 1.1 又不匹配「第X条」，两条规则互相打架，导致 4 个文件一块都没切出来。
- 新增 tools/load_knowledge_milvus.py：向量化并写入 Milvus，用 upsert 保证幂等。
  schema 按方案 §4.2 统一字段，另加 chapter/section/source_file/doc_no/visibility 五个
  检索与合规必需字段；索引 IVF_FLAT + COSINE + nlist=128；向量输入取「标题+正文」，
  标题含条款号与章节名，是比正文更干净的检索信号。
- 知识内容按业务范围裁剪：反洗钱合规操作手册不入客服知识库（业务只做公募基金、
  不涉及资金划付，且该手册标注内部机密、禁止向客户透露可疑交易信息），留给后续风控；
  高净值客户服务规范只保留「客户分层标准」与「各层级专属权益」两章，
  家族信托、资产配置流程、客户经理考核、隐私应急预案等内部管理章节不入库。
- 入库现状：fin_faq_collection 61 块、fin_product_collection 26 块、
  fin_policy_collection 73 块，合计 160 块。检索自检 5/6——未命中的一条分数 0.660
  落在中置信区间，按三档兜底策略本应提示信息可能不完整，属于预期行为。

二、embedding 端点
- 新增 tools/configure_embedding_endpoint.py：走管理 API（draft→approved→active）
  配置并激活 qwen-embedding 端点，而不是直接写库。理由是状态机与审计都要留痕，
  且 DatabaseModelGateway 只认 status='active'，手工写错状态会报成与病因无关的
  「模型端点未注册或未激活」。脚本先查 endpoint_code 是否已存在，幂等可重跑。

三、修复模型端点筛选缺陷（app/service/model_gateway.py）
- 原 DatabaseModelEndpointResolver 忽略 agent_type 与 task_type、直接返回全部 active
  端点，而 ModelDispatchService 只按顺序尝试前 max_attempts（默认 2）个。两者叠加使
  「能否选到支持该任务的端点」取决于端点表顺序：实测每次 embedding 都先拿文本生成
  端点失败一次再落到向量端点（0.61s，修复后 0.42s）。
- 新增 TASK_CAPABILITY 显式映射后按能力筛选。用映射而不是同名筛选是必需的：
  memory_extraction 并不是任何端点的能力名（deepseek 声明的是 text_generation 等），
  按同名筛会得到空集、把记忆抽取打成失败关闭——这是本次修复最容易引入的回归。
- 保守兜底：未映射的 task_type、以及没有任何端点声明该能力时，都退回全部端点，
  让配置缺口表现为调用失败，而不是让上层收到「解析为空」这种与病因无关的报错。
- 验证结果：embedding→[qwen-embedding]、intent_classification→[deepseek-flash]、
  memory_extraction→[deepseek-flash]、未映射 task_type→全部；ruff 通过、
  mypy 103 文件无错、unit+contract 447 passed。

四、需求文档提取物
- 新增 _flows/：三份流程文档（智能客服 Agent 专项设计方案、投资顾问流程、基金运营流程）
  的纯文本提取，供开发期对照。原始 .docx/.html 保留在业务方目录侧。

说明：本次仅本地提交，未推送远程仓库。knowledge/ 内含公司内部制度与产品资料，
是否入远程库待确认。

_flows/投顾_投资顾问流程.txt

@@ -0,0 +1,72 @@
+投顾的完整工作流程
+一、第一阶段：客户认知
+1. 了解客户情况
+关键动作：客户注册时填写问卷，采集身份、职业、年收入、资产规模、投资经验等信息。
+主要输出：客户基础档案与初步画像。
+合规要点：执行客户身份识别，留存身份资料；敏感信息按规则脱敏存储，不得进入对外材料与日志。
+2. 风险测评与适当性匹配
+关键动作：依据问卷结果评定客户风险承受能力等级 C1-C5，并与产品风险等级 R1-R5 做匹配；不符合的产品不予推荐。
+匹配矩阵（硬约束，不可绕过）：
+客户等级
+| 可购产品风险等级
+|
+C1
+| 仅 R1
+|
+C2
+| R1-R2
+|
+C3
+| R1-R3
+|
+C4
+| R1-R4
+|
+C5
+| R1-R5
+|
+主要输出：客户风险等级、可购产品范围。
+合规要点：越级产品一律拦截，不得推荐；客户主动要求越级的，须签署《风险不匹配自愿购买确认书》并完成双录；风险测评有效期 12 个月，超期须重新测评后方可继续购买。
+二、第二阶段：方案制定
+3. 确定投资目标与投资期限
+关键动作：明确收益目标、可承受回撤、流动性需求与可投资期限（<1 年 / 1-3 年 / 3-5 年 / >5 年）。
+主要输出：投资目标书（目标收益区间、最大可承受回撤、流动性约束）。
+合规要点：不得承诺收益，须以业绩比较基准口径说明并提示"基准不等于收益承诺"。
+4. 匹配投顾策略
+关键动作：按客户风险等级与期限选择策略类型（保守 / 稳健 / 平衡 / 进取 / 激进），确定大类资产配置比例。
+主要输出：目标资产配置比例（债券、混合、股票、QDII、现金）。
+合规要点：配置比例不得超出该客户的可购风险等级上限。
+5. 筛选基金并构建组合
+关键动作：在可购范围内筛选产品，按"核心 + 卫星"结构构建组合，每次推荐多只产品以分散单一产品与单一行业风险。
+主要输出：推荐组合（产品清单、配置比例、费率、业绩基准、推荐理由）。
+合规要点：执行集中度与重复持仓检查；输出为草稿态，须经投顾审核后对客；附来源引用与免责声明。
+三、第三阶段：交易执行
+6. 签署协议、确定授权范围
+关键动作：签署投资顾问服务协议，明确授权范围（是否代客操作、审批方式、费用标准、信息披露方式）。
+主要输出：已签署的服务协议、授权范围确认书。
+合规要点：完成风险揭示书签署，必要时双录；明确约定 AI 与系统不代客交易。
+7. 申购、赎回
+关键动作：由客户发起申购或赎回申请，由负责该客户的投顾审批后执行。
+主要输出：交易工单与成交记录。
+合规要点：留痕申请人、审批人、申请与审批时间、金额与产品；异常交易（大额、快进快出、代付等）触发风控复核。
+四、第四阶段：持续管理
+8. 持续监控组合与市场变化
+关键动作：跟踪净值、持仓集中度、行业暴露、费率水平与流动性，关注市场波动与产品事件（基金经理变更、停售清盘等）。
+主要输出：组合监控看板与风险预警清单。
+9. 触发调仓与再平衡
+关键动作：当配置偏离目标超过阈值或触发风控规则时，生成调仓建议，并重新执行适当性校验。
+主要输出：调仓建议（分优先级、含具体产品与调整比例）。
+合规要点：调仓为建议，须经客户确认与投顾审核后走工单执行。
+10. 提供报告、解释与投资陪伴
+关键动作：定期出具持仓与业绩报告，解释净值波动与操作依据，开展投资者教育与预期管理。
+主要输出：定期报告、沟通与陪伴记录。
+合规要点：报告须附免责声明；禁止"保本""稳赚""承诺收益"等表述。
+五、合规红线
+AI 仅作投资分析辅助，不代客交易、不触及资金与下单环节。
+面向客户的全部输出须经持证投顾审核签发后方可交付。
+适当性匹配不可绕过：C1 客户不得购买 R2 及以上产品。
+所有报告与方案须附免责声明，禁止收益承诺与保本表述。
+敏感信息脱敏：身份证、手机号、姓名、银行卡按规则遮盖后再存储与展示。
+六、留痕与归档要求
+每环节须留存：操作人、时间、输入、输出、判断依据（来源引用）、审批意见。
+业务留痕保存，会话记录与工具调用记录完整保留，确保全流程可追溯、可举证。

_flows/运营_基金运营流程.txt

@@ -0,0 +1,20 @@
+场外申购赎回单的确认核对
+传统业务流程：场外不同代销机构申购/赎回单 → 中国结算 → 运营人员（提取申购/赎回金额，基金代码等关键字，判断是否有：单一投资者申购后持有比例超过阈值；单日投资者申购金额超过上限；触发巨额赎回；金额日期不符合格式；赎回份额大于可份额；涉嫌反洗钱；汇总申购赎回规模通知资金清算岗） → 内部风控 →运营人员 → 中国结算。
+Agent功能：自动检测申购赎回单、解析申购赎回扫描件关键字段（异常数据标记和规则格式清洗）、智能对比实际情况进行风险提醒、智能回复风控和中国结算（需要人在回路确认）、标准化输出申购赎回整合数据
+具体流程图：中国结算发送不同申购/赎回单给运营邮箱（LLM自动提取邮箱有关中国结算邮件） → LLM自动解析各类文件（进行关键字段提取，并做格式校验） → LLM自动把关键字段与公司实际产品进行对比（自动标注异常数据和字段格式） → 运营人在回路进行NL2SQL进行确认（确认完成的进行产品申购赎回汇总数据统计） → 是否上报风控（异常数据） → 是否需要把汇总数据给资金清算岗（确认申购和赎回的） → 返回申购/赎回单给中国结算。
+核对字段：
+申购：
+申购后单一持有份额比例是否超过基金总份额规定上限；（产品表）
+申购金额是否超过产品单日上限金额；（产品表）
+检查金额格式；（小数点两位，金额格式为：人民币 万元）
+日期格式字段；（年月日）
+赎回：
+是否巨额赎回；（产品表）
+赎回金额是否大于该账户可用金额，申购金额是否大于最低申购金额；（个人账户表）
+通用：
+日期是否在开放期；（产品表）
+根据申购金额和用户画像判断，是否涉嫌反洗钱；（用户画像表）
+待工作：不同的申购赎回单子，以作实际操作案例。
+新成立产品推介材料的自动生成
+传统业务流程：收集基金经理头像照、制作基金经理最新的历史业绩表、整理产品的基本信息、整理管理人及团队信息，然后给专业的人员进行制作推介材料。
+Agent功能：把新产品的基本信息，最新基金经理业绩给Agent后，Agent自动根据公司内部的风格一键生成实时的推介材料 → 推介资料保存到本地的同时发送给投顾端