 lzf_0626
|
d4a895c643
|
fix: 修好访客客服浮窗、投顾工作台数据口径，恢复访客页来源声明
组员这次提交的两套新页面方向都对，但各有一处"接不上"的地方，这里补齐。
1) 访客客服浮窗（此前一问即失败）
客服 Agent 让访客走 query_knowledge（访客令牌的角色是 visitor、权限只有
agent:run + knowledge:query），但发布配置里三个知识意图只发了 search_knowledge，
于是 ToolExecutor 直接抛 ForbiddenAgentError，而客服代码对白名单失败是
「必须冒泡」的 —— 访客拿不到任何回答，登录客户侧却完全正常。
发布脚本的知识类意图改为同时发 search_knowledge 与 query_knowledge：
访客走前者、客户走后者，缺任一条对应人群就失败关闭。
（suitability_check 不发 query_knowledge：访客意图白名单不含它，访客到不了。）
2) 发布脚本会静默丢提示词
旧写法只查 platform_config_item 就当作"继承"，而 config_release 是整版本替换
语义，新版本没带上的行等于被删除 —— 实际把 customer_service_chitchat 提示词
漏在了旧版本里（admin 端只在激活时打一句 stderr 警告）。
改为走 ConfigReleaseService.effective_snapshot() 读全三张受管表，补上提示词
搬运（version 重分配、带上 input_schema/output_schema），并在激活后硬校验
配置项与提示词条数，条数不符即失败退出。
（model_routing_rule 本环境为空；不为空则直接中止，不假装支持。）
丢失的那条提示词已按原文恢复，active 版本现为 9 条配置项 + 1 条提示词。
3) 投顾工作台永远为空
published() 取的是 customer_id == 自己 user_id，而投顾是员工账号、不可能是
客户；且只认 advisor_recommendation_plan + approved，而投顾交付的主产物是
investment_goal_book，发布后状态是 published。三重不匹配下页面永远显示空态。
改为按「本人 + sys_customer_assignment 里名下归属客户」过滤（不用 data_scope：
投顾因持有 all 级权限会把整个身份的 scope 抬到 all，那会放开到全部客户），
并覆盖两类 content_type 与两种已发布取值。
实测：投顾可见归属客户 9001 的方案书，客户仍只见自己的，风控仍 403。
4) 访客页把"演示数据"声明删了但假数据还在
mock-data.js 的 MOCK_SOURCE_NOTICE 与两个页面的 data-source-notice 区块被删除，
而 MOCK_PRODUCTS/MOCK_RANKING_CHANGE 仍在渲染（详情页含历史净值曲线）。
恢复声明常量、页面区块与样式，并给 products/product-detail 的 link 与 script
加上版本参数 —— 此前没有版本号，浏览器会命中旧缓存，改动看不见。
其他：投顾页显示交付物类型与客户编号（后端新返回的字段），README 补上投顾页
数据口径、访客/客户两条检索工具的差别，以及"渲染 mock 必须带来源声明"的约定。
|
2026-09-13 18:54:09 +08:00 |
|
|
lzf_0626
|
f09ea9e988
|
Merge origin/NL_develop：客服画像出口、知识管理三端点、合规语境与知识向量链路
NL 线（含其并入的袁聪场外/推广域）。唯一冲突是 .gitignore —— 双方都往同一区域加了
.workdir/，取对方版本（他的更完整，含 .tmp/ 与说明），顺带修掉我之前用
Add-Content -Encoding utf8 造成的编码混合（read 工具当时报 invalid UTF-8）。
合并后修的问题 —— 都不是"改别人业务逻辑"，是让门禁能绿：
1. 缺运行依赖 python-docx。document_parser.py 解析 .docx 用它，但 requirements.txt 与
pyproject.toml 都没声明 —— 别人环境跑知识入库会直接
ModuleNotFoundError: No module named 'docx'。已补声明。
2. ruff 7 项：其中 tests/conftest.py 的 F821 Undefined name 'Path'（他的 tmp_path 修复
写了字符串注解 "Path" 却漏 import，运行时不求值所以没炸，但 mypy/ruff 会抓）、
tools/publish_customer_service_config.py 的 F841 inherited_keys 死变量（他改同 key
覆盖、换成 inherited_only 后忘删旧的）、3 处 E501，另 2 项 ruff --fix 自动修复。
3. 合规基线种子未跑：integration 的 test_compliance_seed_mysql 4 个用例要求
agent_negative_word 有 7 条 active 且已复核、agent_reply_template 覆盖 6 场景。
跑 tools/seed_compliance_baseline.py（11 条 active 规则 / 6 个场景模板）后 80 passed。
验证：ruff 干净 / mypy 180 文件 0 错 / unit+contract 1140 passed /
integration 80 passed / 表数 68（alembic 已在 20260911_merge_risk_heads）。
唯一失败 tests/unit/repository/test_fund_readonly_contract.py 是双方一致的既有缺陷：
它断言 Base.metadata 里的 fin_* 表集合，而实测为空集 —— 即该测试依赖别的测试先导入模型的
副作用，单独跑必失败。NL 方也明确"不修不报"，此处照办，仅记录。
|
2026-09-11 20:22:59 +08:00 |
|
 qyqy
|
395bad25b7
|
fix(knowledge): 检索服务适配现库集合 schema、发布对齐的工具白名单、免责声明只由治理层注入
合并暴露的三个真机问题（单测全绿但线上必挂）：
1. 检索服务字段名与现库集合不符 -> 静默零召回
架构师那套按 load_knowledge_milvus.py 的 schema 读 doc_id/content/chapter/section/
visibility，而现库三集合的真实字段是 knowledge_id/title/snippet/tags/version/intent。
Milvus 对不存在的字段直接报错 -> 三集合全失败 -> degraded -> 客服一律转人工。
改法：只改读取侧，用 _FIELD_ALIASES 映射；KnowledgeHit 对外形状不变（下游与测试不动）。
代价已注明：没有 visibility 字段 -> 检索层内部资料硬隔离失效（现库 356 行均为对外知识）。
2. 发布白名单与代码上限不匹配 -> AGENT_PERMISSION_DENIED
active 版本白名单是 query_knowledge，而合并后代码上限是 search_knowledge/check_suitability/
query_customer_profile -> 交集为空 -> 所有知识问题 failed。
改法：publish_customer_service_config.py 补 PROFILE_TOOL 进 faq 白名单，并让同 key 的
继承项被本次定义覆盖（旧值原样继承会被子集校验 422 拒掉整次发布）。已激活版本 216。
3. 免责声明重复出现
Agent 自己拼一句 + 治理层追加权威话术 -> 客户看到两条。改为只由治理层注入
（话术属发布配置，改文案不该改代码）。风控等内部 Agent 不注入（结构化输出不被污染）。
测试：934 passed / 1 failed（test_fund_readonly_contract 既有空集缺陷，与本线无关）
真机：知识问答两问 succeeded 且只带一条声明；画像问答 succeeded；知识库三端点全绿
|
2026-09-11 15:27:16 +08:00 |
|
|
lzf_0626
|
33fbb0eb01
|
feat(customer-service): 接入适当性裁决，回答"我这个等级能不能买它"
客户实测反馈：「c1客户能买它吗」答的是 C1 的通用规则，没回答"能不能买季季盈90天"。
根因是这个问题需要**组合两个事实**——产品的风险等级（R2）与客户档案等级能不能匹配——
而检索只能给出"最像的那段原文"，给不出结论。基座早就有了 check_suitability 裁决工具，
接口留好了但客服没接线（这个项目里第三次遇到同一类情况）。
改动三处：
1. 新增 suitability_check 意图，意图码三处对齐（AgentDefinition.supported_intents、
agent_intent_config 的 active 行、发布版 agent_tools 白名单）。
2. 新出口 _answer_suitability：产品风险等级**从知识库查出来**（不猜、也不采信问句里
出现的"R2"字样），产品名只取上一轮回答里的主语（来自知识块字段，可信），客户等级
交给 check_suitability 按档案解析——**不采信客户自称**。任何一步拿不到确定值就转人工：
这个出口会给出"能不能买"的结论，宁可答不了也不能答错。
3. 发布脚本加意图注册与工具白名单，并做成幂等（重跑不会因为"已经审过了"而 409）。
实测：意图正确路由到新出口，裁决链路走通。9001 因为在 fin_risk_assessment 里没有测评
记录，系统给出"暂时无法购买 + 您目前没有在有效期内的风险测评结果"——这正是适当性管理
要求的行为，不是故障：不能卖给一个没有有效测评结果的客户。措辞也据此改过，不写
"您的等级为未记录"这种客户看不懂的句子。
顺带修了前端一处误导标记：它用"是否含客服热线"判断"已引导人工"，而正常的适当性回答
里也会建议拨打客服热线，于是"已经给出结论"被误报成"已引导人工"。
|
2026-09-10 22:42:17 +08:00 |
|
|
lzf_0626
|
13bab7c3d0
|
feat: 客服 Agent 端到端跑通（知识直返 + 答不了引导人工客服）
按业务方确定的取向实现：金融场景确定性优先，能溯源到公司资料的才答，答不了就
引导客户拨打客服热线，绝不用模型猜答案。端到端验收 8/8 通过。
新增：
- app/service/knowledge_search_service.py：知识检索。未复用记忆的 VectorMemoryAdapter
是因为它只返回 (memory_uuid, score)，会丢掉知识块的标题与正文，而客服回答必须能把
原文与出处一起交付。检索失败一律返回 degraded 而不抛异常，由 Agent 走兜底。
- app/service/knowledge_tool.py + app/core/knowledge_contracts.py：只读工具 search_knowledge。
走 ToolExecutor 而不是让 Agent 直接持有检索服务，是为了让白名单、权限、审计、超时
都归基座统一管理；工具只读也符合 ToolRegistry 的硬约束。复用既有权限码
knowledge:reference:read（customer 角色已具备），不新增权限点。
- app/service/agent/implementations/customer_service.py：Agent 本体，刻意保持薄——
意图分发 + 四条出口（faq/产品/政策直返、闲聊走模型、其余与异常引导人工）。
直接返回知识原文而不经模型改写，答案的字面内容全部来自公司已发布资料。
- tools/publish_customer_service_config.py：发布意图工具白名单。
- tools/customer_service_check.py：端到端验收（8 个用例，含越界请求与知识库外问题）。
装配：
- bootstrap 新增 get_knowledge_search_service 工厂，注册 search_knowledge 工具与
customer_service Agent。
- runtime_config_service 新增 load_active_prompt：提示词绑定 release_id，按当前生效
版本读取，未发布时回落代码默认值。闲聊话术因此可审核、可回滚，不必改代码发版。
过程中发现并处理的三个问题：
1. 自造 source_references 被基座合规闸门拒绝。governance.review_output 只接受
「本次召回的记忆」与「本次成功调用的工具」两类引用（用于防止伪造来源），
knowledge 类型会被判非法并使整个 run 失败。处理方式是**不放开那道校验**，
而把知识出处（文件标题与内部编号）写进正文，source_references 交给基座自动附加。
2. 发布配置是整版本替换语义：新版本会清空旧版本的全部配置项。若只发客服白名单，
示例 Agent 的 fund_query_demo:fund_quote 会被静默清空。故发布脚本先读取当前生效
版本的全部配置项并原样继承，再追加新增项。
3. 验收脚本自身两处自伤：打印 emoji 触发 GBK UnicodeEncodeError、以及读错结果字段
（RunQueryService 返回的答案键是 content 不是 text）。
已知缺口（未修，已记录）：
- CoreResult.transfer_required 未持久化：conversation_message 不存该标记，
API 读不到"本次是否引导了人工"。当前靠正文里的固定话术判断。
- 知识块引用（source_type=knowledge）尚未启用，需先让 ToolExecutor 把工具返回的
doc_id 登记为本次可引用来源。
验证：ruff 通过、mypy 107 文件无错、unit+contract 447 passed；
tools/customer_service_check.py 8/8 通过（含越界请求、投诉、知识库外问题三类
必须引导人工的场景，以及 7 个零容忍负面词零命中）。
|
2026-09-10 20:22:42 +08:00 |
|