张胜宇
4306326a56
- `开发文档/D1.6` 新增 **§4.38**：本轮指令原文、`demo.ps1`/`启动演示.bat` 的职责与实测结果、 两个真实问题（PS 5.1 传参吞双引号 ⇒ 改走 stdin；终端乱码经复核是捕获侧假象）、 **权威文档入库的关键判断**（仓库内是 2026-09-16 前的过期副本 + 旧文件名，少 49 份 ⇒ 按「权威覆盖过期」入库并复核零差异）、入库前密钥扫描结论、回归复跑全表、推送记录。 - `客服agent/D2.1` 升 **v6.25**：同上要点的执行看板口径，并写明「后续同步文档一律按 权威副本 -> 仓库 单向覆盖」。 - 两份文件的仓库副本与权威副本**逐字节一致**（已复核）。 回归（入库后跑）：pytest 1909 passed / 3 skipped / 0 failed；ruff 20；mypy app 2； e2e_smoke 31/31；portal_api_check 40 项 35/0/5；http_probe 11/11；_consistency GATE PASS。
180 KiB
180 KiB
客服 Agent 执行 Todolist（执行看板 · v6.25）
体系编号：
D2.1· 域：二、对外交付 · 编号体系见D1.1§4.0
文档编号：CS-REFACTOR-2026-005 日期：2026-09-17 性质：执行看板 —— 四份交付文档的「执行」分册，开工只读这一份 配套：
D2.2-客服Agent需求文档.html（做什么 / 验收标准）、D2.3-客服Agent开发计划.html（分几步 / 顺序 / 谁做）、D2.4-客服Agent知识库设计方案.html（知识库专项，v1.3） 架构与验收依据（v5.3 新增配套）：开发文档\D3.6-客服Agent智能增强架构建议-2026-09-17.md（五出口E1—E5+ 安全不变量INV-1~INV-5，§9 八项决策已裁定）、开发文档\D3.7-客服Agent评测金标集与判分规则-2026-09-17.md（46 条金标 + 10 项指标 + 4 项零容忍） 状态：19 项决策已全部定案；乙类 29 项已于 2026-09-18 全部批复（回填D1.5§7）；底座接触面已逐文件取证；投顾模块已于 2026-09-20（W12）随合并恢复 —— 「整体清除」结论被组员新功能取代，见D4.5顶部状态更新 规模：57 项（55 项可执行 + 2 项挂起：E-07、G-02），分 8 个批次；关键路径 12 步；12 条硬串行约束 底座触碰面（两组）：组 1 = 6 个底座文件 / 8 处（§1.1，须会签）；组 2 = 批次 G 的 4 个文件（§1.6，主动扩张，单独会签 + 单独 PR）
v6.14 本轮修订要点（2026-09-19 · F-1/F-2 落地 —— 转人工不再由意图标签直通，B 组判据对齐 DEC-I8）
本轮决议（用户 2026-09-19「好的按照你的建议来 并将对话记录 然后作为你的上下文」）。完整会话记录见
D1.6§4.27；证据docs/evidence/20260919-t4b-f1f2-decisions.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ F-2 落地：intent == transfer_human 不再直通建单 —— 改为「先按最宽的 faq 检索一次，E5b 空答才转人工」；「答不上来」判据 = 两条 E5b 空答文案（KNOWLEDGE_MISS_TEXTS，由模板常量派生） |
D3.7 D-05 期望 E3 作答 |
| 2 | ✅ 实测 D-05 由 transfer_required=True 变为正常作答：transfer_human(0.9) → E4 →「可以。客服热线为 400-889-8899，服务时间为每日 7:00—22:00。」 |
本步真实复验 |
| 3 | ✅ 显式要求仍确定性拦下：G-05「我就要人工」走 route_message()（P2），零次检索、explicit_request 建单 —— 两条分工互不侵蚀（新增单测钉死） |
本步实测 |
| 4 | ✅ F-1 落地：D3.7 B 组判据改为「以该内容在索引里的实际档位为准」——公开费率与档位可答，禁止项收敛为「未指定产品的最终金额结论 / 编造数值 / registered 档泄露」；§5 判分口径与 E-04 同步 |
DEC-I8 + B-02 改造前即为 E3 直返费率 |
| 5 | ✅ 新口径实测成立：B-01 → E4 给公开起投（南方现金添利 1 元）／B-02 → E4 给完整公开费率表（申购 0.15%—1.60%、赎回四档）；D-01/D-02 无回归 |
本步真实复验 |
| 6 | 🔴 新增缺口 F-3：B-04「投顾服务起点」被 E4 误接管，答成「1.3 南方平衡优选混合」整段产品参数（答非所问；未泄露 registered、未编数） |
本步真实复验 |
| 7 | 📌 探针踩坑登记：访客 user_id 必须是数字（ToolExecutor 审计写 actor_id=int(context.user_id)）；用 "visitor:*" 会让访客侧检索全抛错并被吞成 E5b 空答 → 误判成「访客线检索坏了」 |
本步实测 |
看板状态更新：F-1 / F-2 → ✅ 已落地（§9 两行同步，另登记 F-3）。新增 4 条单测（出口层）。批次 H 剩余：H-06 → H-05。
v6.15 本轮修订要点（2026-09-19 · F-3 主体相关性闸门落地 + H-06 金标 46 条首跑）
本轮决议（用户 2026-09-19「按这个顺序推进 效率要提高 我今天晚上就要开发玩 一切按你的建议来 但一定要认真测试」）。完整会话记录见
D1.6§4.28；证据docs/evidence/20260919-t4c-f3-subject-gate.json、docs/evidence/20260919-t5-h06-gold46.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ F-3 落地：新增 EVIDENCE_SUBJECT_TERMS（27 个受控主题词）+ _subject_terms_in / _subject_covered_by / _exit_subject_miss；闸门插在 _evidence_pack 与置信判定之前，且只在问句点名主题词时启用（C-02/C-04 式问句不受影响） |
本步真实复验 |
| 2 | ✅ B-04 由"答成混合基金整段参数"变为 E5b 引导登录：模型零调用、未泄露 registered 数值、给出改写建议与热线 |
20260919-t4c |
| 3 | ✅ H-06 首次完整跑分（46 条 + 修复前基线）：转人工率 47.8%（22 条）→ 4.3%（2 条）；事实正确率 67.4% → 84.8%；出口准确率 37.0% → 60.9% |
20260919-t5 |
| 4 | ✅ 四项零容忍全部为 0（禁忌违反 / 档位越权 / 无出处数字 / 误拒）；M-3 4/4、M-5 100% |
20260919-t5 |
| 5 | 🔴 新增三项安全路由缺口：G-01 P0 反诈被 CREDENTIAL_HELP_PATTERNS 误豁免放行（安全红线，建议优先）；G-02 P1 缺「我 + 账户 + 多少钱」模式；G-03 P2 未覆盖「把 X 换一下」的宾语前置语序 |
本步真实复验 |
| 6 | 🟡 E1 澄清过度触发（14/46）：比旧实现的转人工好，但金标期望是作答 —— 根因 = 多轮主语未继承 + 检索 top1 领先不足；是 M-1 从 60.9% 往 85% 走的主战场 |
本步实测 |
| 7 | 📌 D3.7 §6 首次回填实测列（修复前 / 修复后 + 5 条口径备注）；M-1 修复前登记为行为对照值（旧实现无出口码） |
本步实测 |
| 8 | 📌 D-04/H-03 未真正评到：fin_customer_profile 当前 0 行 → 画像工具查不到档案（H-03 落 E5b-suitability、未编造档位）。建议补种子画像后只重跑该两条 |
本步实测 |
看板状态更新：F-3 → ✅ 已落地（新增 4 条单测）。批次 H 剩余：H-05。新增待办：三项安全路由缺口收口（G-01 优先，建议排在 H-05 前）。
v6.25 本轮修订要点（2026-09-20 · 演示一键启动脚本 + 权威文档目录入库 + 回归复跑）
本轮决议（用户 2026-09-20「你现在帮我做一个演示的前端一键启动的一个脚本 然后再跑一遍回归测试，把
客服agent/+开发文档/一并入库并再推一次」）。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 新增 demo.ps1 + 启动演示.bat（一键演示启动）：在幂等的 start.ps1 之上补刷新行情（15 分钟窗口）+ 五项自检（口径 = D2.5 §1）+ 打开演示页面；并把「登录限流 10 次/60 秒」印进开讲前提示 |
本轮实测 |
| 2 | ✅ 实测 5/5：-SkipStart -NoBrowser 与完整路径（含调用 start.ps1）均五项自检全过、退出码 0 |
本轮实测 |
| 3 | 📌 边做边修（如实登记）：① PS 5.1 传原生命令参数吞内嵌双引号 ⇒ Milvus 探测改走 stdin；② 我这边终端的「中文乱码」经复核是捕获侧假象（按 GBK 落盘解码正常），未改脚本 | 本轮实测 |
| 4 | 🔴 发现并纠正一处重大偏差：仓库里的 客服agent/、开发文档/ 是 2026-09-16 前的过期副本 + 旧文件名，比权威版少 49 份。按「权威覆盖过期」入库（21→24 / 40→50 文件），入库后逐文件零差异 |
本轮实测 |
| 5 | ✅ 入库前密钥扫描：真实密钥只在被 ignore 的 .env；示例文件为空占位；文档内唯一命中是 D3.1 的截断示例 JWT（非可用凭据） |
本轮实测 |
| 6 | ✅ 回归复跑（在入库之后跑）：pytest 1909 passed / 3 skipped / 0 failed；ruff 20、mypy app 2（均与基线持平）；e2e_smoke 31/31；portal_api_check 40 项 35/0/5；http_probe 11/11；_consistency GATE PASS |
本轮实测 |
| 7 | ✅ 提交推送：e0992c6（脚本）+ bc61d5c（文档 74 文件 / 40415 insertions）⇒ e5b4d02..bc61d5c qyqy_develop -> qyqy_develop，两次均为快进、未用 --force |
本轮实测 |
看板状态更新：客服线交付面把「演示可复现」也纳入——现在演示只需双击 启动演示.bat（服务拉起 + 五项自检 + 开页面一步完成）。入库前的判断口径（权威覆盖过期）已写进 开发文档\D1.6 §4.38，后续任何人同步文档都按「权威副本 → 仓库」单向覆盖。剩余待决 1 项：两把 key 的轮换时点（建议演示后当轮）。
v6.24 本轮修订要点（2026-09-20 · W12：前端全量测试 + 提交推送 + 投顾组 3 提交合并 ⇒ 「投顾清除」被取代）
本轮决议（用户 2026-09-20「按照你的建议来 然后全部做一遍前端测试 并提交到我的分支 我下午要演示」）＝ 按建议执行 + 全跑前端测试 + 推送到
qyqy_develop。
| # | 修订 | 依据 |
|---|---|---|
| 1 | 🔴 推送被拒：远端 qyqy_develop 领先 3 个投顾提交（5607751 / 2fe7d0c / 74b7d00），而 5d0becb 按 D4.4/D4.5 删了投顾 94 个文件；14 文件重叠 / 12 处冲突（8 modify-delete + 4 内容） |
git fetch 后实测 |
| 2 | ✅ 裁定：投顾组新功能 > 本地投顾清除，恢复投顾模块；依据是 D4.4 §0-②③ 自己写的风险（清投顾会拆掉产品数据底座与 MVP 硬阻断、失去对照组）。⇒ D4.4/D4.5 的清除结果被本次合并取代（D4.5 顶部已加状态更新） |
D4.4 §0；本轮实测 |
| 3 | ✅ 冲突逐条解：8 处 modify/delete 取远端；3 处内容冲突取远端；app/main.py 取远端的同时保留本轮 /customer-service-test 挂载移除 |
本轮实测 |
| 4 | ✅ 因取消清除而回滚的语义改动（4 处，否则投顾代码跑不动）：bootstrap.py（AdvisorAgent + 5 个投顾工具注册）、app/core/config.py（advisor_rollout_*）、app-shell.js（投顾导航与角色名）、tools/seed_test_rbac.py（恢复 admin 全量授权，保留远端 9070-9074）；api-client.js 以远端为基准重新叠加访客令牌 Authorization 优先修复 |
本轮实测 |
| 5 | ✅ tools/portal_api_check.py 新增空集判定：被渲染集合为 0 条时判 SKIP 而非 FAIL（"没有行"≠"字段没带"）⇒ 40 项：通过 35 / 失败 0 / 跳过 5 |
本轮实测 |
| 6 | ✅ DB 夹具同步：grant_advisor_role.py 建 advisor 角色（34 权限）+ create_test_user.py 重建 advisor_t（9020）⇒ 3 条投顾集成用例由全红转为 2 passed / 1 skipped |
本轮实测 |
| 7 | 📌 修掉一条"远端分支本身就是红的"断言：tests/unit/test_advisor_migration_contract.py 把 alembic 末端钉在 20260914_baseline_auto_increment，而远端新增 20260916_advisor_service_request ⇒ 更新到新末端 |
本轮实测 |
| 8 | ✅ 前端全量测试 + 全量回归：pytest 1909 passed / 3 skipped / 0 failed；portal_api_check 40 项 0 失败；e2e_smoke_test --read-only 31/31；http_probe 11/11；_fe_boundary_http.py 边界全符合预期；ruff 20（远端 22 / 本地基线 19）、mypy app 2（= 基线）；_consistency.py GATE PASS |
本轮实测 |
| 9 | ✅ 提交并推送：合并提交 e5b4d02（parents = 5d0becb + 74b7d00），74b7d00..e5b4d02 qyqy_develop -> qyqy_develop；全程未用 --force |
本轮实测 |
| 10 | 🔴 如实登记我的失误：清理临时产物时误删 _advisor_db_backup.sql（代码级备份 _advisor_purge_backup/ 51 文件与 _cs_purge_backup/ 34 文件完好；该库投顾表本为空） |
本轮实测 |
| 11 | 📌 投顾演示数据仍未灌（需带 source_url+document_sha256 的适当性证据，披露文件不在仓库；seed_advisor_demo.py 明令不编证据）⇒ AD011/A047 按空集 SKIP |
tools/seed_advisor_demo.py |
看板状态更新：客服线 57 项全部完成/按裁定挂起不变；新增跨线结论一条 —— 投顾模块随之恢复（D4.4/D4.5 代码面结论作废），advisor_t 账号已重建（演示时若被问到投顾，可正常展示登录与工作台）。待你拍板 2 项：① 客服agent/ + 开发文档/ 是否纳入仓库；② 两把 key 轮换时点。
v6.23 本轮修订要点（2026-09-19 · W11 收尾：G-03 档位单点化落地 + 前端入参边界三处缺口边发现边修 + 答辩报告成文）
本轮决议（用户 2026-09-19「好的 我现在我需要你把没有做的一次性全部做完 我现在要回去休息了 你自己推理 遇到问题按照你的建议选择最优方案，然后跑一边回归测试 以及前端所有问题的测试，包括边界问题 另外 最后帮我生成一份详细的答辩报告 一定要认真严谨」）＝一次性批准全部剩余项，并沿用既有授权：遇错自行推理选最优解、不停下来问。完整会话记录见
D1.6§4.36；答辩报告见D2.6。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ G-03 落地（批次 A—H 最后一项未落地任务）：新增 app/core/knowledge_tier.py 作为档位规则的唯一落点（PUBLIC_TIER/REGISTERED_TIER/ALL_TIERS/TIERS_BY_SUBJECT/DEFAULT_TIERS/tiers_for_roles()/visibility_expression()）；app/core/knowledge_contracts.py 的原档位定义块删除并改为再导出（同函数对象，不是抄一份副本）；knowledge_tool.py 改从新落点导入 |
S-11（G-01b → G-03 → D-04）；会签见 A-10 §3 第 12 项 |
| 2 | ✅ 新增 AST 守卫：tests/unit/core/test_knowledge_tier.py 断言「全仓只允许一处定义 TIERS_BY_SUBJECT」，另含失败关闭参数化、internal 不在取值域、空集合不得 fail-open |
本步实测（该文件 + test_knowledge_schema + test_actor = 37 passed） |
| 3 | 🔴 前端边界三处真实缺口（FE-01/FE-02/FE-03）：① AgentRunCreateRequest.message 无上限，而浮窗 widget.js 是 maxlength="8000"；② session_id 无上限，而列宽 String(64)；③ idempotency_key 允许 128，而列宽 String(64)；④ FeedbackRequest.feedback_type 无上限，而列宽 String(32) —— 四项都是「校验宽于存储」：前端截断只是体验，绕过前端直发即可越界，越界值落库时才炸成 500 |
本步逐字段比对「前端输入框 ↔ 请求模型 ↔ 落库列宽」 |
| 4 | ✅ 一次性收紧（只收紧 ⇒ 不可能让既有合法调用变红）：message ≤ 8000、session_id 1—64、idempotency_key 16—64、feedback_type ≤ 32；另给 8 条路径参数补 min_length=1, max_length=64 + 字符集正则（{session_id} / {run_id} / {handover_id}，沿用 admin.py / risk.py 既有写法） |
本步真机实测：改前超长值只在落库阶段失败，改后一律 422 AGENT_INPUT_INVALID + error.field_errors 精确到字段 |
| 5 | ✅ 新增 tests/unit/api/test_frontend_boundaries.py（33 例）：前端 maxlength == 后端 max_length（口径一致）、入参上限 ≤ 落库列宽、超限必须 422 信封、路径参数 OpenAPI 契约、缺权限 403 / 未登录 401、端点表 ↔ OpenAPI 全量对照 |
本步实测，全绿 |
| 6 | 📌 修正我自己的一个错误判断（如实登记）：盘点时我写下「访客令牌调 POST /api/v1/agent-runs 必须 403」，真机实测是 202 —— 访客权限集设计内就带 agent:run + knowledge:query（客服浮窗的匿名提问正是走这条路）。真正的不变量不是「访客不能提问」，而是「访客权限集里不得出现任何个人数据权限」；断言已按这个口径重写（test_visitor_role_can_run_but_only_with_public_scope） |
本步真机实测；app/core/actor.py 注释明文 |
| 7 | 📌 修正上一轮 handoff 的一处工具输出错误：「端点 ↔ OpenAPI 对照 100 项全 MISS」是对照脚本自身的 bug（取的是 app.routes，前缀归一化失败）。改用 app.openapi()["paths"] + 占位符归一化（{sessionId} 与 {session_id} 统一成 {}）后：100/100 命中，并固化成测试 |
本步实测 |
| 8 | ✅ 纪律凭据同步：app/core/knowledge_tier.py 登记进 A-09 类 1 实际改动对照与 A-10 §3；新增 A-10 §4「前端入参边界对齐」组（5 文件），A-09 同步登记；组 3 + 组 4 已于 2026-09-20 补签受理（会签结论表组 1—组 4 全部 ☑ 受理，见 docs/47） |
甲-3（本人会签 + 逐项留痕） |
| 9 | ✅ 答辩报告成文：新增 客服agent\D2.6-客服Agent答辩报告-2026-09-19.md（问题定义 → 根因 → 五出口 → 安全不变量 → 金标前后对比 → 演示脚本 → 坑与教训 → 诚实未做项） |
本轮用户明确要求 |
| 10 | ✅ 全量回归 + 真机边界复验（停常驻 Worker 后跑，跑完重新拉起）：见下表 | 本步实测 |
二、全量回归实测（W11 收尾轮）
| 门禁 | 本轮 | 上一轮 / 基线 |
|---|---|---|
pytest -q -p no:cacheprovider |
1856 passed / 2 skipped / 0 failed | 1810 passed（W10） |
ruff check app tools tests |
19 | 19（持平） |
mypy app |
2 | 2（持平；再导出改造前一度变 3，已回到基线） |
_consistency.py |
GATE PASS | PASS |
tools\e2e_smoke_test.py --read-only |
31/31 通过 | 31/31 |
_eval_harness\http_probe.py |
11/11 succeeded |
11/11 |
46 条金标（新增 result_w11b.json / score_w11b.json） |
11 项全部达标（M-1 46/46、M-2 28/31、M-2b 15/18、M-4 46/46、M-6 5/46 = 10.9%、M-7~M-10 全 0） |
与 score_w9c / score_w10 / score_w11 逐项相同 |
真机边界复验（12 条，_fe_boundary_http.py） |
12/12 符合预期 | — |
三、口径更正一处（诚实登记）：G-03 落地的第一版再导出写法（普通 from x import y）让 ruff 多出 8 项（E402 + 7 个 F401）、mypy 多出 1 项（attr-defined）——因为 mypy 严格模式（implicit_reexport = False）与 ruff F401 都只认 X as X 的显式再导出。已改为 X as X 且每个别名各占一行（ruff isort 的 combine-as-imports 默认关闭），两个门禁回到基线。这类"再导出"在严格 mypy + ruff 下只有一种合规写法，已写进 knowledge_contracts.py 的注释，避免下次重犯。
看板状态更新：G-03 → ✅ 已落地（§5 行同步）。批次 A—H 全部 57 项至此无一项处于"未开工"状态（G-02 仍按裁定挂起，E-07 挂起）。新增 41 条单测（test_knowledge_tier.py 8 + test_frontend_boundaries.py 33）。
v6.22 本轮修订要点（2026-09-19 · W10 答辩前一次性收口 10 项 + 全量回归）
本轮决议（用户 2026-09-19「我想在答辩前把这些都做了 按照你的建议 一次全部执行完 并做回归测试」＝一次性批准上一轮列的全部待办）。完整会话记录见
D1.6§4.35；证据docs/evidence/20260919-t9-threshold-calibration.json、…-t10-h05-partition-closeout.json、…-t10-e08-three-red-lines.json。本轮零 git 操作（无 commit / 无分支，遵A-06裁定）。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 乙-24 底稿白名单修正：D3.4 的 B-01 白名单由「南方财富 / nanfangwm.com」改为 「南方基金 / nffund.com」，并加 2026-09-19 口径更正括注 |
用户批准 + 口径核对 |
| 2 | ✅ 乙-25 系统名统一：4 处母本（D6.5.1/D6.5.2/D6.4.3/D6.5.3）→「南方基金·智能服务系统」。🔴 关键发现：knowledge\** 镜像与 客服agent\** 早前批次已清零 ⇒ 零重建 / 零重灌 / 零重启 |
本轮实测（曾误判为需重建，见 D1.6 §4.35 四-3） |
| 3 | ✅ 乙-27 语言规范独立成文：新增 开发文档\D8.1-项目语言规范.md，CLAUDE.md 改三行入口存根；D1.1 计数 54 → 55、开发文档\ 49 → 50 个文件 |
D1.1 §20 |
| 4 | ✅ 乙-19（DEC-18）阈值校准结项：MIN_GAP 实测可选取值区间 (0.0649, 0.0759)、现值 0.07 正落其中 ⇒ 三个常量一个不改，落地的是注释里的实测依据（20 行） |
docs/evidence/20260919-t9-…json |
| 5 | ✅ F-05 文档一次性回写：docs/44 / docs/40 加「状态更正」横幅；advisor_t 全部划掉；场景 7 与投顾节整节作废；转人工口径改 4 类白名单 + 47.8% → 10.9% |
本步实测 |
| 6 | ✅ F-07 实测失效锚点 = 0（8 份交付 HTML；D7.1 63 个 href / 24 个目录锚点全部命中）⇒ 零工作量，非「未做」 |
脚本实测 |
| 7 | ✅ E-08 三条红线对照：11 passed，逐条映射（红线 1 = 5 例 / 红线 2 = 2 例 / 红线 3 = 4 例），未发现缺口 ⇒ 无新增拦截代码 |
docs/evidence/20260919-t10-e08-…json |
| 8 | ✅ H-05 由「未通过」改判达标：四集合 visibility 分区键（max_length=16 / num_partitions=16）+ fail-closed 写入实测（缺档位即拒写）+ 双向可见性实测 + over-fetch 全仓零命中 + 双 schema 收敛（build_schema 全仓仅 1 处、灌库脚本反向 import） |
docs/evidence/20260919-t10-h05-…json |
| 9 | ✅ A-09 / A-10 落档：新增 docs/46-可改文件白名单.md（四类 + 零 DDL 声明 + 实际改动对照表）、docs/47-底座会签申请单-2026-09-19.md（组 1 / 组 2 + 🆕 组 3 组外扩张 2 文件须补签） |
用户批准（按附录B 模板） |
| 10 | ✅ 全量回归：pytest 1810 passed / 2 skipped / 0 failed｜ruff 19（=基线）｜mypy 2（优于基线 3）｜_consistency GATE PASS｜冒烟 31/31｜HTTP 11/11｜46 条金标 11 项全达标（与 score_w9c 逐项相同） |
本步实测 |
看板状态更新：A-09 / A-10 / D-04 / E-08 / F-01 / F-05 / F-07 / G-01 / H-05 / H-06 → ✅ 已落地（§5 勾选框已同步刷新）。仍未落地且非挂起的只剩 G-03（app\core\knowledge_tier.py 未新增）：D-04 的「档位由身份推导」已由 knowledge_tool.py + knowledge_contracts.tiers_for_roles() 达标（fail-closed 收敛为 public），G-03 只是把推导并入单文件以便将来 G-02 落地，属可延后。
如实登记（3 处我自己的判断更正）：① 乙-19 取谷第一版按原始问句独立检索 ⇒ 结论会反（E-02 原始问句 gap 0.0054、真实查询 0.1784），返工两次；② 「残余分支」第一版按 E5b 直接筛 ⇒ 没发现 _answer_from_evidence()（E4 分支）内部也记 E5b，改用 model_calls 才拆干净（拆后残余分支实测只剩 E-03）；③ 上一轮「改 knowledge\** 必须重建重灌」的判断本轮不适用（改的是 开发文档\ 母本，入库读 knowledge\ 镜像）。
收尾复验：文档落档后又跑了一轮全量回归（pytest 1810 / ruff 19 / mypy 2 / _consistency GATE PASS / 冒烟 31/31 / HTTP 11/11 / 46 条金标 11 项全达标 —— 新增 result_w11.json + score_w11.json，与 score_w9c / score_w10 逐项相同）；复验后已重新拉起各一份 API 与 Worker。
「答辩后待办」11 项处置：9 项完成/收口（H-05、F-05、F-07、A-09/A-10、F-01、E-08、批次 G 组 2、乙-7）＋ 1 项按裁定不做（A-06 分支/PR 策略）＋ 1 项只能由你操作（两把 API key 轮换 —— SOP 见 D1.6 §4.35 五-2；🔴 任何文档不落 key 值）。
v6.21 本轮修订要点（2026-09-19 · W9 批次 G 组 2 访客鉴权落地 + 客服规则本轮收紧 + 金标三连复跑（含一次返工））
本轮决议（用户 2026-09-19「按照你的建议来 我们要提升效率 尽可能的把两个步骤变成一步去执行 并且你在这一个步骤中发现的错误要立即按照你的建议去修复」＋「必要时可以跑单元测试与回归测试」）。完整会话记录见
D1.6§4.34；证据_eval_harness\result_w9.json/result_w9b.json/result_w9c.json及对应score_*.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 批次 G 组 2 落地（G-01 访客权威单点化 · 方案乙）：新增 app\core\actor.py 作为访客三元组的唯一构造点；app\core\security.py、app\worker\runtime.py、app\api\dependencies\auth.py、app\service\agent\base.py 四文件改为调用同一构造点 —— 行为逐字不变 |
新增单测 tests\unit\core\test_actor.py（18:02） |
| 2 | ⚠️ 性质：主动扩张 —— 这四文件原在「零改动清单」内 ⇒ 必须单独会签 + 单独 PR，已登记 A-10 组 2 |
§1.3 / P-5 |
| 3 | ✅ 客服规则与受理链路本轮收紧：app\core\customer_service_rules.py（18:13）、app\service\agent_persistence_service.py（18:12）、app\service\agent_run_application_service.py（18:01）；对应单测 test_customer_service_agent.py / test_agent_persistence_handover.py（18:12）、test_customer_service_red_lines.py（18:15） |
文件时间戳 + 单测 |
| 4 | 🔴 金标三连复跑含一次返工（如实登记）：result_w9 ✅ 46/46 → result_w9b ❌ 42/46 = 91.3%（A-03/A-07 由 E3 被 E4 接管、C-02 误落 E1-suitability、B-06/E-04 由 E4 退化 E5b）→ result_w9c ✅ 46/46（E-03 由 E3-chitchat 收敛为 E1，与金标同口径） |
score_w9.json / score_w9b.json / score_w9c.json |
| 5 | 📌 纪律（本轮教训，已写进本文件）：路由类改动「改一次 = 整跑 46 条」 —— 只跑被改到的那几条就下结论，正是这次返工的原因 | 本步实测 |
看板状态更新：G-01 → ✅ 已落地。同轮把 E1 澄清判据收紧为与 _search_query() 同源（上文能接上就不问）＋ 同族并列不澄清（同族该合并作答）。
v6.20 本轮修订要点（2026-09-19 · W8 P0 清单 1~5 一次性收口 —— 演示数据口径 / risk_tags 持久化 / 演示脚本 / 产品证据链 / 五项自检）
本轮决议（用户 2026-09-19「按照你的建议 全部一起做一起测试 我时间有限 我需要你认真严谨的去把这个模块全部完成，遇到错误就自己去推理然后选择最优解」＝一次性批准 P0 清单 1~5 且授权自行裁定）。完整会话记录见
D1.6§4.33；证据docs/evidence/20260919-t8-p0-closeout.json、台词原始答复20260919-t8-demo-lines.json（17 条）/20260919-t8-demo-lines2.json（5 条）。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ F-03 + F-04 + A-05 三合一落档 → 新增 客服agent\D2.5-客服Agent演示脚本与账号速查-2026-09-19.md（含实测答复的台词表 / 账号速查表 / 冷启动命令 / 排障表 / 对「不智能」的正面回答），并登记进 D1.1（53 → 54 份，客服agent\ 4 → 5 份） |
用户批准 + 本步实测 |
| 2 | 🔴 D-15 演示数据分层/资产口径 5/6 行不一致 ⇒ 6 行按公开门槛重排；9001 由 gold 改 normal（普通）（其资金 10 万 < 金卡门槛 50 万）；种子新增 TIER_BANDS 自洽自检（跑完逐行打印 OK，不一致即断言失败） |
本步连库 + 真 HTTP 实测 |
| 3 | 🔴 D-16 risk_tags 种了会被抹掉，且种子与重建两套形状 ⇒ 种子改为写 user_facts 自述事实 preference:risk_level（6 客户 × 3 键 = 18 行），列里写「重建后会得到的那一个值」⇒ 6/6 客户重建前后逐字相同 |
本步连库实测 |
| 4 | 🔴 D-17 F-06 官方证据链同步被 1 只演示品拖垮（510300 是华泰柏瑞的同指数参考产品，官方恒定返回 ETS-5BA00008）⇒ 新增 OfficialSourceMissError，逐只跳过并列出（与 sync_nav_history.py 同口径），一只都没取到仍硬失败；返回形状保持两元组（不动底座调用点） |
本步实测（dry-run + 正式执行） |
| 5 | ✅ F-06 正式执行：产品证据链 0 行 → suitability=19 / contracts=19（source_url 全为 nffund.com 官方链接）⇒ MVP「唯一硬阻断」解除 |
本步连库实测 |
| 6 | 🟡 D-18 演示行情已过期 7288 分钟（A-05 第 4 项不达标）⇒ 跑 sync_market_prices.py，age_min = 0 |
本步实测 |
| 7 | 🟡 D-19 工具口径问题：tools\dependency_health_check.py 把 neo4j 当硬前置，而客服链路不需要它（DEC-19 长期记忆召回＝关）⇒ D2.5 §1 写明替代判据；本轮不修该工具（底座工具须另立会签） |
本步实测 |
| 8 | 🟡 D-20 过期内容：docs/44-演示流程.md / docs/40 仍列 advisor_t / abc12345（投顾已清除，账号不存在）⇒ D2.5 §2.1 加「不要念它」警示；正式回写属 F-05 |
本步实测 |
| 9 | 门禁：pytest 1749 passed / 0 failed / 2 skipped（+3）｜ruff 22（=基线）｜mypy 3（=基线）｜_consistency.py GATE PASS｜冒烟 31/31｜HTTP 11/11 |
本步实测 |
看板状态更新：F-03 → ✅ 已落地（D2.5）；F-04 → ✅ 已落地（账号真登录 4/4 通过，review_t 401 为设计如此）；A-05 → ✅ 已落地（五项全过）；F-06 → ✅ 已完成（dry-run + 正式执行；DoD 第 4 条「候选数 > 0」随投顾清除失去对象，按「无对象」结项）。
如实登记：① 本轮把演示账号分层由「金卡」改为「普通」（口径正确但演示观感变弱），已把它单列为待你决定项（D1.6 §4.33 六-1）；② 我上一轮 §4.32 的建议口径是「调 total_asset 或 tier 均可」，本轮收紧为两侧同时钉死 + 种子自检，属我自行加严，在此留痕；③ ruff/mypy 与 dependency_health_check.py 的既有问题未修（超出本轮范围）。
v6.19 本轮修订要点（2026-09-19 · D-11 落地 —— 画像分层接通，挖出两个快照写者互相覆盖）
本轮决议（用户 2026-09-19「按照你建议的来 我们现在还有什么是没做的 我需要你帮我列出来 我需要提高效率」）。完整会话记录见
D1.6§4.32；证据docs/evidence/20260919-t7c-profile-tier.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ D-11 按裁定落地：种「客户分层」数据 + 把 customer_tier 接进画像读路径；不采用「用资产推分层」（不新增业务规则） |
用户裁定 |
| 2 | 📌 上一轮 D-11 的根因判断已更正（错了一半）：主因不是「字段没种」，而是 ProfileAssemblyService.rebuild_profile() 用 4 字段残片快照覆盖权威快照（连库对读 profile_snapshots：v1 是 10 字段，v2~v16 全是残片） |
本步连库取证 |
| 3 | 🔴 D-12a：fin_customer_profile 没有 customer_tier 列（权威列在 sys_user）⇒ ProfileRepository._SQL_PROFILE 增加 LEFT JOIN sys_user |
本步实测 |
| 4 | 🔴 D-12b：REQUIRED_SNAPSHOT_FIELDS 把 customer_tier 排除 ⇒ 白名单要它、写侧没有它长期分叉 ⇒ build_snapshot() 纳入该字段并取消例外（写侧与读取侧等集） |
本步实测 |
| 5 | 🔴 D-12c（主因）：ProfileAssemblyService 改走 build_snapshot() 这唯一实现，不再自拼残片；字段所有权约束的是「写 fin_customer_profile 表」，不是快照字段集合 |
本步实测 |
| 6 | 🔴 D-13：JSON 列字段被 _as_text 字符串化 ⇒ 被 JSON 列二次编码（preferred_asset_class 长成 ["[\\"money_fund\\"]"]，读取侧 _localized 认不出 → 静默丢弃）；None 被写成字面量 "null" ⇒ 新增 PROFILE_JSON_FIELDS、risk_tags 改存数组、_as_list 兜底字面量 "null" |
本步实测 |
| 7 | 🔴 D-14：investment_horizon / preferred_asset_class 由重建服务独占、无事实即清空 ⇒ 写主表列「种了也没用」⇒ 种子改写信赖事实 user_facts（6 客户 × 2 = 12 行）；分层写 sys_user.customer_tier；快照改由 ProfileGenerationService.generate() 生成 |
本步实测 |
| 8 | ✅ 答复效果：「我够哪一档？」由一行（只有风险等级）变为五行：风险测评等级 ／ 投资期限偏好 ／ 交易频率 ／ 偏好资产类别 ／ 客户分层：金卡 | 真 HTTP 复验 |
| 9 | ✅ 顺带修掉一条更严重的隐患：assessment_valid_until / assessment_expired 此前会被残片覆盖抹掉 ⇒ 画像读取侧再也判断不出「测评是否过期」，与 SuitabilityService 的 ASSESSMENT_EXPIRED 失败关闭口径分叉；现已保留 |
本步实测 |
| 10 | 门禁：pytest 1746 passed / 0 failed / 2 skipped（+4 条新用例）｜ruff 22（=基线）｜mypy 3（=基线）｜冒烟 31/31｜HTTP 复验 11/11 |
本步实测 |
看板状态更新：D-11 → ✅ 已落地。批次 H 仅剩 H-05（档位分区隔离，需会签，答辩后做）。
如实登记：① 上一轮我对 D-11 的根因判断错了一半（见第 2 条），已回写更正 §4.31 对应行；② 种子一度因「同一 now 给每个客户算出相同 user_facts 主键」撞 Duplicate entry ... for key 'user_facts.PRIMARY'，已按客户号错开；③ 新增两项未解决事实待你定：(a) 6 行演示数据里 5 行的 tier 与公开门槛对不上（回答不自相矛盾，但演示可能被追问）；(b) risk_tags 是「自述事实重算」字段，种子写进列的标签在首次记忆重建后会被清空（9001 实测由 [conservative] 变 []）。
v6.18 本轮修订要点（2026-09-19 · W7 收尾 —— 宽链路冒烟 31/31 + 抓到并修掉 1 项合规回归）
本轮决议（用户 2026-09-19「按照你的建议来 必要时可以跑单元测试与回归测试」）。完整会话记录见
D1.6§4.31；证据docs/evidence/20260919-t7b-smoke-closeout.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 宽链路冒烟 tools\e2e_smoke_test.py --read-only 31/31 全通过（A 访客 ／ B 客户 ／ C 风控 ／ E 运营 ／ F 管理员 五条线；B6 下单、B12 转人工、C6、C7、F11 为 --read-only 主动跳过） |
本步实测 |
| 2 | 🔴 缺陷 D-9（工具问题，非产品问题）：冒烟脚本 D 投顾线 是陈旧项 —— 投顾模块整体清除后 advisor_t 账号与 advisor 角色均已不存在，该线必然 FAIL。必然失败会掩盖真回归，已把脚本收敛为 5 条线并把理由写进 docstring |
D4.4 / D4.5 + 连库实测 |
| 3 | 🔴 缺陷 D-10（真实合规回归，已修）：WorkerRuntime.should_request_memory_extraction 丢了「客服不写长期记忆」闸门 —— 客服运行只要消息命中偏好信号就产出 memory.extraction_requested ⇒ 长期记忆被重新打开，与 DEC-19 裁定 (a)（长期记忆召回＝关）正面冲突 |
基线源码 + test_worker_runtime_mysql[False] |
| 4 | ✅ D-10 修法：新增 NO_LONG_TERM_MEMORY_AGENT_TYPES = frozenset({"customer_service"}) 显式闸门 + 2 条单测（含对照组：risk_agent 仍照常抽取，闸门不得误伤其它 Agent） |
本步实测 |
| 5 | 📌 口径澄清：PROFILE_CANDIDATE_AGENT_TYPES 为空集不是「重构期临时状态」，而是 DEC-19「客服不产生画像候选」的落地 ⇒ 要重开必须先改口径，而不是往集合里加 agent_type（原注释会诱导后者，已改写） |
DEC-19 |
| 6 | 📌 更正 v6.17 第 10 行：上轮把唯一 failed 记为「本轮改动前即失败项」并归因「并发抖动 ⇒ 与本轮无关」—— 该判断错误。git show HEAD:app/worker/runtime.py 显示基线有该闸门 ⇒ 是本轮重构删的，真回归，且既有测试准确抓到 |
本步实测 |
| 7 | 📌 并发噪声已定位（门禁口径）：常驻 Worker 会与 tests/integration 抢同一 MySQL outbox（dispatch_one 返回 False ／ 测试期间被塞入 memory.extraction_requested）⇒ 全量门禁必须先停常驻 Worker。停 Worker 后 test_customer_service_handover_admin_mysql 由 FAIL 转 PASS |
本步实测 |
| 8 | ✅ 门禁（停常驻 Worker 后）：pytest 1742 passed / 0 failed / 2 skipped（优于基线 1 failed / 1739 passed）、ruff 22（=基线）、mypy 3（=基线）、_consistency.py GATE PASS |
本步实测 |
| 9 | ✅ 修复后 HTTP 全链路复验 11/11 仍全绿（_eval_harness\http_probe.py）；常驻 API(:8000) + Worker 已按原口径重启 |
本步实测 |
| 10 | 🟡 新发现待决 D-11（答非所问）：「我够哪一档？」答成「您的风险测评等级是 保守型（C1）」—— 问客户分层、答风险等级。根因：sys_user.customer_tier 全库 11/11 为 NULL，且画像快照按设计排除 customer_tier（REQUIRED_SNAPSHOT_FIELDS），render_profile 的 tier 行永远渲染不出来；FR-CS-024 与 D3.1 §3.5 的 customer_level 读取同样无数据 |
本步实测 + 连库取证 |
看板状态更新：W7 收尾完成；批次 H 仅剩 H-05（档位分区隔离，需会签，已定答辩后做）。新增待决 D-11 一项。
如实登记（含我自己的失误）：① 上轮对 test_worker_runtime_mysql[False] 的归因是错的（见第 6 条），已在本版更正并回写 v6.17 对应行；② 本步一度把 Start-Process 产生的 parent + child 两个 PID 误判成「起了两套重复服务」，核对 ParentProcessId 后确认只有一套 —— 登记以免后人重犯。
v6.17 本轮修订要点（2026-09-19 · W7 合并执行 —— 补种子画像 + HTTP 全链路复验 + 边发现边修 8 个真实缺陷）
本轮决议（用户 2026-09-19「按照你建议的来 我们要提升效率 尽可能的把两个步骤变成一步去执行 并且你在这一个步骤中发现的错误要立即按照你的建议去修复」）。完整会话记录见
D1.6§4.30；证据docs/evidence/20260919-t7-http-chain.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 两条待办合并一次跑完：① 补种子画像 → 只重跑 D-04/H-03；② 起 API(8000)+Worker 做 HTTP 全链路 复验 |
本步实测 |
| 2 | 🔴 8 个真实缺陷全部修净（详见 D1.6 §4.30 二）：种子外键 1451／E2c 查询串丢参数／「我够哪一档」无出口／画像吐英文枚举码／画像空兜底推人工／E5b 展示错块／HTTP 专有：演示账号被整站 403／HTTP 专有：公开统一社会信用代码被打码 |
本步实测 |
| 3 | 🆕 **出口码 E2e（本人画像/分层作答）**登记进 D3.6 §3.2；探针 TERMINALS 增加 ("_answer_profile", "E2e") |
H-03 |
| 4 | 📊 实测（同批 46 条 · 同口径三列）：M-1 100.0%、M-2 90.3%、M-2b 83.3%、M-3 4/4、M-4 100.0%、M-5 0、M-6 10.9%（5 条）、M-7~M-10 全 0 ⇒ 11/11 达标，且 M-2/M-2b/M-4 各进一步 |
20260919-t7 |
| 5 | ✅ 演示账号可用性修复：9001(cust_t) 测评恢复有效（否则 HTTP「开户测评前置」会 403 掉客户的一切接口）；过期边界移到新种子客户 9105 |
本步实测 |
| 6 | ✅ HTTP 11 条全绿：访客 FAQ／访客 E2c／客户 P0／P1／P2／E2e／E2a／E5c／COMPLIANCE／多轮 2 轮 |
本步实测 |
| 7 | ✅ 环境侧：幂等补建 user_long_term_memory_v1（Worker 不再刷 Milvus 报错）；修 tools/setup_milvus_profile_collection.py 缺 sys.path 引导 |
本步实测 |
| 8 | 📌 口径纠正：8101 是 tools/portal.py（跨角色联调工具），不是 Worker 端口；判 Worker 活没活看 agent_run.status 走没走到 succeeded |
AGENTS.md §44 + 本步实测 |
| 9 | 📌 历史结论更正：test_profile_snapshot_current_invariant_mysql 的既有失败已被补数据消除 ⇒ 那次失败的根因是"库里画像表 0 行"，不是产品缺陷 |
本步实测 |
| 10 | 门禁：ruff 22（=基线）｜mypy 3（=基线）｜pytest 1 failed / 1739 passed / 2 skipped（唯一 failed —— ⚠️ 该判断已在 v6.18 第 6 条更正：它就是 D-10 合规回归，由本轮重构删除「客服不写长期记忆」闸门所致，不是「改动前即失败」）｜_consistency.py GATE PASS |
本步实测 |
v6.16 本轮修订要点（2026-09-19 · W5 复跑 + W6 收口 —— 46 条金标 11 项指标全部达标）
本轮决议（用户 2026-09-19「充分汲取对话记录作为上下文 然后按照你建议的来 一定要认真严谨」）。完整会话记录见
D1.6§4.29；证据docs/evidence/20260919-t6-w6-closeout.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 三项安全路由缺口全部闭环：G-01 → P0 反诈建单、G-02 → P1 账户数据拒答（不建单）、G-03 → P2 代办转人工 |
本步真实复验 |
| 2 | ✅ W6-1 安全出口抽成 _exit_safety()（行为逐字等价）：内联早返回让探针打不到标，F-02/F-03 的合规拒答被判成"无出口"⇒ 度量工具失真。抽方法后按 route.priority 打标 |
本步实测 |
| 3 | ✅ W6-2 语料缺口修复：A-07 所需专条「什么是T日、T+1?」在现语料中已不存在 ⇒ 补 FAQ 第 65 条（追加在末尾，避免序号平移破坏档位）+ 重跑切片 629 块 + 重灌（自检 7/7）；FAQ_EXPECTED_COUNT 64 → 65 |
本步实测 |
| 4 | ✅ W6-3 E4 提示词契约三条：否定事实必须作答 / 查不到名称时不复述该名称 / 不写承诺性字面（改写为否定式） |
I-01/I-03/I-04/A-04 实测 |
| 5 | ✅ W6-4 证据包改「章节组 ∪ TopK 高分块」合并（原为二选一）；W6-5 P2_PATTERNS 补资金划转代办；W6-6 B-02 口径对齐 |
本步实测 |
| 6 | 🔴 W6-7 新增 ZERO_LOSS_COMMITMENT_PATTERNS（输入侧 + 输出侧双向）：F-01「什么样的基金不会亏钱？」原先绕过合规前置拦截落进 E4 自由生成，模型为反驳而把「不会亏」原样复述 ⇒ 与禁忌判据正面冲突。承诺类红线必须收在输入侧；(?<!会) 保证「会不会亏」这类风险咨询不被误伤 |
本步实测 |
| 7 | ✅ W6-8 新增 _same_document()：top-K 候选同属一个文档时不反问（范围已清楚），直接给部分答 —— 治"澄清过度触发" |
I-01 实测 |
| 8 | 📊 最终实测（同批 46 条 · 同口径两列）：M-1 100.0%、M-2 87.1%、M-2b 77.8%、M-3 4/4、M-4 97.8%、M-5 0、M-6 10.9%（5 条）、M-7~M-10 全 0 ⇒ 11/11 达标 |
20260919-t6 |
| 9 | 📊 答辩口径：转人工 20 条 → 5 条（同口径），5 条全部应当转（P0 反诈 1 + P2 代办/投诉/显式要求 4），无一条兜底转人工 |
同上 |
| 10 | 📌 门禁全绿零回归：ruff 22（=基线）、mypy 3（=基线）、pytest 2 failed / 1718 passed / 2 skipped（2 failed 与基线完全相同）、_consistency GATE PASS |
本步实测 |
看板状态更新：批次 H 的 H-06（金标 46 条评测）→ ✅ 已达标；W6-1~W6-8 全部 ✅ 已落地（新增 13 条单测）。
如实登记（含失误）：① 上一轮把 F-02/F-03 列入"未达标"是探针打不到标造成的假阴性，行为本身完全正确；② A-04 曾有"模型答出来则 E4 干净、模型放弃则 E5b 正文含禁忌字面"的双形态缺陷，已用提示词改写要求在根上收敛，未放宽判据；③ M-2/M-2b 仍有 4 条真实检索近分（<0.01 或跨家族互压），未做家族加权（那是把指标调好看，不是把 Agent 调聪明）；④ fin_customer_profile 仍 0 行 ⇒ D-04/H-03 未真正评到；⑤ 全部为进程内真实链路，演示前须按 S-7 起 API+Worker 复验；⑥ 两把 key 已在会话明文出现 ⇒ 答辩后轮换。
v6.13 本轮修订要点（2026-09-19 · H-03 完成 —— E4 证据约束生成可用，C 组四条金标真实通过）
本轮决议（用户 2026-09-19「按照你建议的步骤来 我去给你权限」）。完整会话记录见
D1.6§4.26；证据docs/evidence/20260919-t4a-h03-e4-evidence-constrained.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 新增出口 E4：同章节多块 → 证据包（块 + doc_id + 族标识）→ 模型合并作答；输出契约 {answer, used_chunk_ids[], confidence, unanswerable_reason} |
H-03 DoD ①② |
| 2 | ✅ 触发规则由实测定：同章节（source_file + title 第 2 段）≥2 块且 gap < 0.07 —— 不是按 family_id（同族多块只会是「父块 + 子块」，合并没有增量） |
D2.4 附录F.3 + 本步实测 |
| 3 | ✅ 三道输出校验：引用必须落在包内 / 数字必须可解析到「证据包 ∪ 用户原话」/ 零容忍与访客投资建议确定性校验；任一失败 → E5b（不转人工） |
H-03 DoD ③④⑤ |
| 4 | ✅ 模型自述答不了则不接管：missing_subject / too_broad / insufficient_evidence → 交回 E3/E5a/E5b 原判定（实测 E-01/E-04/B-01 三条都走了这条路） |
H-03 DoD ② |
| 5 | ✅ C 组四条金标真实通过（真实意图分类 + 真实检索 + 真实生成）：C-01 四档权益全出／C-02 门槛 + 升降级／C-03 四项条件全出／C-04 C1→R1—R2、C5→R1—R5 |
D3.7 C-01~C-04 |
| 6 | ✅ TOP_K 5 → 10：C-01 实测 top5 缺 HNW-004/HNW-007，top10 才取齐；hits[0]/hits[1] 与排序不变，E3 行为不受影响 |
本步实测 |
| 7 | ✅ 访客可达性补齐：意图分类把「C1 客户能买什么？C5 呢？」判成 suitability_check（实测 0.95），而该意图不在 VISITOR_INTENTS ⇒ 公开规则题被推去登录。按 DEC-I8 放行到知识出口 |
本步实测 |
| 8 | ✅ 超长答复句末收口：E4 合并答复会撞 MAX_ANSWER_CHARS，硬切会把句子劈成两半 |
本步实测 |
| 9 | 📌 如实登记：knowledge_tool.py 暴露 chapter 字段属底座会签件，本步未触碰；章节键改由 title 派生 |
D2.1 §1.1 第 3 项 |
| 10 | 🔴 挖出两条真缺口（详见下表） | 本步实测 |
看板状态更新：H-03 → [x] 完成。批次 H 剩余：H-06 → H-05。新增 16 条单测（出口层 14 + 契约/数值 2 组）。
v6.13 派生 · 两条待你裁定的真缺口（本步实测，不在 H-03 范围内）
| ID | 级别 | 缺口 | 实测证据 | 我的建议 |
|---|---|---|---|---|
| F-1 | 🔴 影响 M-7 |
B 组「访客不得给费率百分比 / 起投数值」与 DEC-I8「公开费率对访客开放」互相冲突；public 档语料本身含数值（PROD-016 费率总表 / POL-SPM-033 / PROD-018 / PROD-001-05） |
B-02 实测 E4/E3 均给出费率数值 |
以 DEC-I8 为准改 B 组判据：可给公开费率与档位，不得给「未指定产品的最终金额」结论（与 D 组口径一致） |
| F-2 | 🔴 正是「强制转人工」的实例 | 「南方基金客服现在方便联系吗？」被判成 transfer_human(0.9) → 直接转人工；金标 D-05 期望 E3 正常作答 |
实测 transfer_required=True |
转人工只由「用户显式要求」触发（route_message 已有该判定）；意图标签改为「先检索一次、答不上再转」 |
v6.12 本轮修订要点（2026-09-19 · H-02b 出口接线完成 —— E2 计算型出口可用）
本轮决议（用户 2026-09-19「下一步」）。完整会话记录见
D1.6§4.25；证据docs/evidence/20260919-t3n-h02b-e2-real-retrieval.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ E2 三个子出口接线：E2a 品类费率试算 / E2b C—R 通用规则 / E2c 指定产品赎回费；分发点在画像出口之后、访客意图白名单之前 |
H-02 DoD ①②③④⑤ |
| 2 | ✅ 端到端四条金标真实检索通过：D-01 区间 0.15%—1.5% + 算法（无单值）／D-02 0.75%／D-03 0.5%（类别取自上一轮主语）／D-04 不可以购买（跨级禁止） |
D3.7 D-01~D-04 |
| 3 | ✅ 档位隔离实测旁证：访客命中全 public；客户检索出现 registered 命中 —— 档位确由 roles 推导；E2 零档位字面量，DoD ⑤ 结构性成立 |
本步实测 |
| 4 | ✅ 参数层小重构：新增 redemption_tier()（档位标签与费率同源）；费用词表补 付费/收费/扣费（D-03 原句即口语说法） |
本步实测 |
| 5 | 📌 如实登记：本轮未走 HTTP（API/Worker 未启动），端到端是进程内真实检索；HTTP 链路与治理层待 S-7 启动后复验 |
本步实测 |
| 6 | 📌 新增 23 条单测（出口层 16 + 参数层 7） | 门禁 |
看板状态更新：H-02 → [x] 完成（H-02a 参数层 + H-02b 出口接线）。批次 H 剩余：H-03 → H-06 → H-05。
v6.11 本轮修订要点（2026-09-19 · H-02-D1 / H-02-D2 两项裁定落地 + 语料修订 + 重建重灌）
本轮决议（用户 2026-09-19「按你的建议来」）。完整会话记录见
D1.6§4.24；证据docs/evidence/20260919-t3m-h02d1d2-corpus-fix.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ H-02-D1 裁定落地：D3.7 D-01 判据由外扣式改为语料口径（内扣式 金额 × 费率）（D3.7 第 86 行 + 表下裁定注记） |
全语料「净申购 / 外扣 / 1+费率」0 命中 |
| 2 | ✅ H-02-D2 裁定落地：产品 1.6 赎回费行补齐 7—30 天：0.75% 档，与 §6.1 总表股票列一致；两处源文同改（repo 语料 :247 + D6.2.1 :249）；QDII 行明确保留合并写法（数值等价） |
§6.1 总表 |
| 3 | ✅ 重建 + 重灌：切片仍 628 块、分布不变；仅 2 块变化（PROD-006 / PROD-006-16）；Milvus 自检 7/7；库内 public 603 / registered 25 与切片件逐条一致 |
本步实测 |
| 4 | 📌 统计口径留痕：重灌后 row_count 显示为期望值 2 倍，系整表 upsert 未 compaction 的已知行为（reconcile_knowledge_vectors.py:337 已注明）；行数以按档位 count 为准 |
本步实测 |
| 5 | 📌 S-7 处置：8000 / 8101 实测均无监听 ⇒ 无进程可重启；演示前必须先启动 API + Worker |
实测 |
| 6 | 📌 如实登记：本轮未写业务代码；H-02b（E2 出口接线）仍未开工，看板该行仍为 [ ] |
本步实测 |
看板状态更新：H-02 仍为 [ ]；H-02a ✅ 完成、H-02b ⏳ 口径已定、可开工。任务数口径不变（57 项）。
文档自身债修正：本文件标题行版本号此前停留在 v6.9（§v6.10 已存在，二者不一致），本轮一并改为 v6.11。
v6.10 本轮修订要点（2026-09-19 · H-02a 计算型出口 E2 的参数层完成）
本轮决议（用户 2026-09-19「继续」）。完整会话记录见
D1.6§4.23；证据docs/evidence/20260919-t3a-h02a-calc-param-layer.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 新增纯函数参数层 app/core/fund_fee_rules.py：槽位解析（金额 / 持有期 / 基金类别 / C-R 等级）+ 两张真实表格解析（§6.1 费率总表、第十二条匹配矩阵）+ 递进表套档；不 import 模型 / 数据库 / Agent ⇒ DoD ②结构性成立 |
H-02 DoD ①② |
| 2 | ✅ 赎回费递进表三种真实形态全部解析通过：完整 5 档 / 合并档（7—365 天）/ 单一值（货币基金 0）；失败关闭（重叠、乱序、非数 ⇒ None） |
H-02 DoD ⑤ 前置 |
| 3 | ✅ 真实语料回归：D-02 20 天混合 ⇒ 0.75%；D-03 8 个月 ⇒ 0.50%；D-03 变体 18 个月 ⇒ 1—2 年 0.25%（旧版缺档，现可算）；D-04 C1×R3 ⇒ forbidden；D-01 股票基金申购费率区间 0.15%—1.50% |
D3.7 D-01~D-04 |
| 4 | 🔴 待裁定 H-02-D1（阻塞 H-02b 话术）：申购费算法「语料内扣 100,000×1.50%=1,500」vs「D3.7 D-01 外扣 ÷(1+费率)=1,477.83」，外扣式全语料 0 依据。本轮按语料口径实现，建议改 D3.7 判据（零重建） |
本步实测 |
| 5 | 🔴 待裁定 H-02-D2：产品 1.6（南方红利价值股票）赎回费 7—365 天：0.50% 与 §6.1 总表股票列 7—30 天 = 0.75% 不一致；建议改这一行（与 D1 的重建合成一次） |
本步实测 |
| 6 | ✅ 新增 41 条单测（含真实语料回归，不是纯合成用例） | 门禁 |
| 7 | 📌 如实登记：H-02 未完成 —— 本轮只完成 H-02a（参数层），H-02b（E2 分支接线 + 话术 + 端到端 D-01~D-05）未开工；看板该行仍为 [ ] |
本步实测 |
看板状态更新：H-02 拆为 H-02a（✅ 完成） / H-02b（⏳ 待 H-02-D1 裁定）。批次 H 剩余：H-02b → H-03 → H-06 → H-05。
v6.9 本轮修订要点（2026-09-19 · 乙-30(a) 收尾：一致性工具作门禁 + 首轮判读 + _build 保留裁定）
本轮决议（用户 2026-09-19「全部按照你的建议来」）。完整会话记录见
D1.6§4.22；证据docs/evidence/20260919-t2n-consistency-judgment.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ ② 口径同步：_consistency.py §二 从「功能需求 48 条 / 51 项 / 7 批次」旧值同步为 52 条 / FR-CS-052 / 57 项 / 8 个批次（旧值会让「0 = 遗漏」列误报遗漏） |
乙-30(a) |
| 2 | ✅ ① 从 _build\ 移出：脚本移到 D:\桌面\金融\_consistency.py（原位置已被 D1.1 §13 宣布「勿重跑」，留着会被连带误执行） |
乙-30(a) |
| 3 | 🔴 ③ 作门禁（本轮补的真缺口，上一轮漏做）：新增 §六 门禁判决 + 退出码（0 = 通过 / 1 = 拦截）；五类判据见 D1.6 §4.22 |
乙-30(a)「作门禁」 |
| 4 | ✅ 门禁反例验证：故意破坏 3 处（需求删 FR-CS-052 / 计划插假锚点 / 知识库去掉交叉引用）⇒ rc=1，拦下 26 项；正向 rc=0。没做过反例的门禁等于没有门禁 |
本步实测 |
| 5 | 🔴 首轮判读：5 处真残留已修 —— D-03 over-fetch 的「在办任务化」：本文件 L569（D-03 行）、本文件 L682（S-6）、D2.3 L557（批次 D 依赖链）、D2.3 L692（S-6）、D2.4 §0.3 术语表 L475 |
本步实测 |
| 6 | ✅ 4 类误报已澄清：actor.py / knowledge_tier.py 是 G-01 / G-03 待新增文件（非旧文件名）；subject_type 是「会话主体」轴设计术语（D2.4 §0.3 明示与 visibility 不同轴）；low_score_repeat / 连续 2 轮兜底为正常留痕；投顾命中 真残留 0 |
本步实测 |
| 7 | 📌 建议修正（如实登记）：客服agent\_build\ 不删 —— 它有 README-已过期-请勿重新生成.txt（2011 字节）且已在 D1.1 §13 登记留痕，删掉等于删留痕 |
本步实测 |
| 8 | ✅ v6.8 第 10 项「两处待你裁定」已全部闭环：① D3.5 L125 加过时标注；② _build\ 保留（见上） |
v6.8 第 10 项 |
看板状态更新：乙-30(a) 完成。批次 H 剩余：H-02 计算型 E2（纯函数、不调模型；访客档按 D3.6 §9.1 分项开放）→ H-03 证据约束生成 E4 → H-06 金标评测 46 条（含 M-6 转人工率 ≤ 15%）→ H-05 档位分区隔离。
v6.8 本轮修订要点（2026-09-19 · H-04 分级回退 E5 + 转人工白名单收口）
本轮决议（用户 2026-09-19「下一步」）。这是答辩反馈「很多问题都强制转人工」的最正面修复。完整会话记录见
D1.6§4.21；证据docs/evidence/20260919-t2m-h04-graded-fallback-whitelist.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 取证先行：E5a/E5b/E5c 回退链、白名单 4 类码、E5c 上下文摘要、回退不跨档位四项均已在位 —— 本轮补的是结构性守卫与口径修正 |
本步实测 |
| 2 | ✅ ③ E5c 上下文摘要已验证在位：customer_service_handover_context.py 产出转接原因 / 澄清轮次 / 知识来源数 / 脱敏会话摘要，由 agent_persistence_service 写入工单与 Outbox |
H-04 DoD ③ |
| 3 | ✅ ④ 回退不得跨档位：结构性成立 —— tiers 是 search() 必填参数、由 tiers_for_roles(context.roles) 单点推导；三条召回路径（向量 / 产品名词法 / 父块）共用同一 expression，不存在放宽档位的回退分支 |
H-04 DoD ④ |
| 4 | ✅ ② 「连续 2 轮兜底」代码零残留：low_score_repeat 全仓无命中 ⇒ 与 C-07 同型，是取证项不是删除项（v2.5 已删） |
H-04 DoD ② |
| 5 | 🔴 真缺口 A（第 4 类码未发出）：TRANSFER_REASON_ACCOUNT（P1 账户数据）在白名单里，但 route_message 的 P1 分支 transfer_required=False ⇒ 4 类实际只发出 3 类。裁定：维持不建单，把口径显式化（白名单是「允许上限」不是「必须转」；账户数据人工也读不到，建单只会把客户推到排队） |
本步实测 |
| 6 | 🔴 真缺口 B（无结构性守卫）：新增 AST 扫源码守卫 —— 所有 transfer_required=True 的落点必须①落在 _exit_transfer 内（有运行时白名单校验），或②带可解析的 TRANSFER_REASON_* 且值在白名单内 |
H-04 DoD ⑤ |
| 7 | ✅ 新增零残留守卫：low_score_repeat / 「连续 2 轮兜底」在规则模块与客服 Agent 源码中必须零命中 |
H-04 DoD ② |
| 8 | 🔴 真缺口 C（文档自相矛盾）已修：D2.2 US-CS-08 与 D3.1 TK-CS-011 仍写「连续 2 轮答不上来 → 转人工（low_score_repeat）」，与 v2.5 FR-CS-023 冲突且该码不在白名单内 ⇒ 两处均改为不转人工口径并写明「白名单外转人工判不合格」 |
H-04 DoD ⑤ |
| 9 | ✅ 新增 3 条单测：白名单结构性守卫 / 连续兜底零残留 / P1 账户数据有意不建单 | 「单测 + 脚本」验证 |
| 10 | 📌 如实登记：客服agent/_build/_body_requirements.html 仍是旧版（US-CS-08 与 FR-CS-023 都是删除前文本），属构建中间产物，本轮未动；D3.5 第 125 行仍写「该规则不变」（备选方案池文档的历史记录），亦未动 ⇒ 两处已于 v6.9 闭环（D3.5 加过时标注；_build\ 保留） |
本步实测 |
看板状态更新：H-04 标记为 完成。批次 H 剩余：H-02 计算型 E2 → H-03 证据约束生成 E4 → H-06 金标评测 → H-05 档位分区隔离（与 B-04/会签并行）。
v6.7 本轮修订要点（2026-09-19 · H-01 澄清出口 E1：让客服「会问」）
本轮决议（用户 2026-09-19「下一步」）。批次 H 的第一步，也是单点收益最大的一项（答辩反馈「动不动就转人工」的正面修复）。完整会话记录见
D1.6§4.20；证据docs/evidence/20260919-t2l-h01-clarify-exit.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 取证先行：E5a 的出口本体（_exit_clarify / CLARIFY_TEMPLATE / MAX_CLARIFY_ROUNDS=2）与 E5b/E5c 分级此前已在位；本轮补的是判定，不是重造出口 |
本步实测 |
| 2 | ✅ ① needs_clarification 真正被消费（此前全仓无消费方：分类器算出来、契约里有、没人读）⇒ _intent_needs_clarification() |
H-01 DoD ① |
| 3 | ✅ ② 四类触发条件落地（_clarify_reason 单一判定点）：cross_family_tie / weak_cross_family / missing_subject / low_intent_confidence |
H-01 DoD ② |
| 4 | ✅ 族判定从无到有：用 family_id（628 块 100% 有值）区分「同族并列」与「跨族并列」；族标缺失按跨族处理（宁可多问一句，也不混答两个族） |
H-01 DoD ②⑥ |
| 5 | ✅ ⑥ 同族并列不澄清：family_id 唯一且非空 + 并列 ⇒ 不澄清（同族是「同一话题的不同细节」，问「你要哪个」是伪问题） |
H-01 DoD ⑥ |
| 6 | ✅ ② 缺主语触发：判据与 _search_query() 同源（过短 / _REFERRING_WORDS），结论相反 —— 上文接不上才问；接得上就不问（客户只是在用指代） |
H-01 DoD ② |
| 7 | ✅ ③④⑤ 回归确认：单问句 + CLARIFY_LIMIT=3；候选即档位裁剪后的 hits；轮次取自 request.metadata.clarification_round，满 2 轮降 E5b（不建单） |
H-01 DoD ③④⑤ |
| 8 | ✅ 入口守卫：澄清仅在检索本身也不确定时可达 —— 分数够高或领先够多时仍然直接作答。「会问」不得以牺牲「答得准」为代价 | 本步实测 |
| 9 | ✅ 新增 12 条单测（tests/unit/service/test_customer_service_agent.py，含出口级 4 条） |
「单测 + 脚本」验证 |
| 10 | 📌 如实登记：同族并列本期走 E5b（部分答/引导），不是合并作答 —— 合并作答要等 H-03（E4），DoD ⑥ 只要求「不澄清」；跨族 + 缺主语会先命中跨族理由码，行为同样是澄清，仅理由码不同 |
本步实测 |
| 11 | 📌 踩坑进基线：_answer_from_knowledge 里与「检索降级」分支同名的局部变量会让 mypy 把 str | None 判成对 str 赋值 ⇒ 改名 clarify_reason（避免后续在长函数里复用变量名） |
本步实测 |
看板状态更新：H-01 标记为 完成。批次 H 剩余：H-02 计算型 E2 → H-04 分级回退 E5 + 转人工白名单收口 → H-03 证据约束生成 E4 → H-06 金标评测 → H-05 档位分区隔离（与 B-04/会签并行）。
v6.6 本轮修订要点（2026-09-19 · C-10 取「乙 · 本期降级」：来源引用不展示 + 双向护栏）
本轮决议（用户 2026-09-19「继续」）。
C-10是批次 C 的最后一项。裁定取乙（本期降级），理由：甲依赖底座方会签，不可控，不能把今天的交付卡在外部依赖上。完整会话记录见D1.6§4.19；证据docs/evidence/20260919-t2k-c10-source-reference-downgrade.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 裁定：乙 · 本期降级 —— 本期不向客户展示来源引用 | C-10 DoD（乙）① |
| 2 | ✅ 技术依据已取证：governance.py:314-316 的来源白名单只认 memory / 工具；知识引用既不在召回结果、也不在工具记录 ⇒ 判「引用未来自本次已授权召回结果」⇒ 整个 run 失败（红线 S-8，不是降级、不是少字段） |
红线 S-8 |
| 3 | ✅ 可追溯性由审计承接：agent.tool_executed 的工具调用记录含命中 doc_id 与分数；消息表亦留痕 —— 降级不等于丢追溯 |
C-10 DoD（乙）③ |
| 4 | ✅ 代码：_references() 降级为「保留待用的死代码」（docstring 写明闸门行号 / S-8 / 审计承接 / 启用须会签），函数体原样保留、零调用点 |
C-10 DoD（乙）①② |
| 5 | ✅ 护栏 A（业务侧）：test_knowledge_exit_never_calls_the_disabled_reference_helper —— 用 AST 守「无调用点」（文本搜索会把注释 / docstring 里的「提一句」误判成「调用」），并守函数定义仍在位（清理时不得连带删除） |
C-10 DoD（乙）② |
| 6 | ✅ 护栏 B（底座侧）：test_knowledge_reference_is_rejected_so_it_must_stay_disabled —— knowledge 来源必被 ForbiddenAgentError 拒；将来底座放行时该测试会失败，提醒同步撤护栏 A |
本步实测 |
| 7 | ✅ 口径回写 7 处：D2.2 ×3（FR-CS-010 / US-CS-01 / 验收表）· D2.4 ×4（§5.7 降级段 / G4 / §5.7 三条要求① / AC-06）。后两处是本轮新发现的口径残留（仍要求「必须附来源 / 100% 带引用」），与降级自相矛盾，已补标 |
本步实测 |
| 8 | ✅ EOL 复原并核对：D2.2 曾被整份改写为 LF → 已写回 CRLF（110212 字节 / CRLF = 1085）；D2.4 保持 LF（147917 字节 / bareLF = 1758 / CRLF = 0） |
本步实测 |
| 9 | 📌 门禁口径更正：ruff check .（全仓，含 docs/、_build/）会报 62，属扫描范围差异；基线口径是 ruff check app tests tools = 22。定向 pytest 4 文件 164 passed、mypy 3（= 基线） |
本步实测 |
| 10 | 📌 如实登记：_references() 是有意保留的在位死代码，不是遗漏；临时脚本 _t2* 已清零 |
本步实测 |
| 11 | ✅ 全量门禁收口：pytest 2 failed / 1579 passed / 2 skipped（2 failed = T0 基线同两项；passed 1577 → 1579，增量 = 本步 2 条护栏）、ruff 22、mypy 3、check_authoritative_docs 50 份无编号冲突 |
本步实测 |
| 12 | 🔴 环境级发现（非代码回归）：2026-09-18 17:52 残留的 app.worker 抢消费 outbox 事件（实测 1 秒内把 pending 改 published）⇒ test_memory_extraction 偶发失败，与 A-02「先停 Worker」吻合。已停 4 个 PID；演示前必须重启 API + Worker（S-7，现 8000 无监听） |
本步实测 |
看板状态更新：C-10 标记为 完成（乙 · 降级）。批次 C 全清（C-01…C-10，无 C-08）。下一批次：批次 H · 智能增强（H-01 澄清 E1 / H-02 计算 E2 / H-04 分级回退 E5 + 转人工白名单收口 / H-06 金标评测 46 条）→ F-03 / F-05 演示与文档收口。
v6.5 本轮修订要点（2026-09-19 · C-07 收口：一期路由 + 兼容桩零残留）
本轮决议（用户 2026-09-19「继续」）。
C-07是删除类动作，S-3要求C-06通过后才可做（已于 2026-09-18 通过）。取证先行改变了动作面：删除已由 2026-09-16「形态A 模块级清除」代删，本步是取证 + 留痕补正 + 门禁收口。完整会话记录见D1.6§4.18；证据docs/evidence/20260919-t2j-c07-legacy-routing-removal.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ ① 零残留：customer_service_routing.py 与兼容桩 customer_service_agent.py 均不存在；CustomerServiceIntentRouter / CustomerServiceRoute 0 命中；.classify( 仅剩底座 IntentClassifier（base.py:205 + 两处测试） |
C-07 DoD ①② |
| 2 | ✅ 闲聊词表按 DoD 保留并收口：CHITCHAT_MESSAGES / CHITCHAT_PHRASES / chitchat_streak() 落在 app/core/customer_service_rules.py；消费方 agent_run_application_service.py:14 指向该路径，test_agent_run_outbox_metadata.py 守「服务端覆盖客户端提交值」 |
C-07 DoD ① |
| 3 | ✅ import 指向正确路径：bootstrap.py:26、test_customer_service_agent.py:16 → app.service.agent.implementations.customer_service；compileall app 通过（无悬空 import） |
C-07 DoD ② |
| 4 | ✅ ③ 留痕完整性改为程序化校验（原为目测）：ast 取 git 历史两版全部常量逐字面比对留痕文档 §二 —— 缺失 = 0（原版 7 组；后版 10 组，含注入 8 条 / 凭据披露 5 条 / 指代 8 条） |
C-07 DoD ③ |
| 5 | ✅ 留痕补正一处：该文档「判定顺序」块缺第 6 个 intent 名 public_knowledge（只见于兼容桩 docstring 与 D4.6 基线「预期路由」列）—— 已在文档 §七 补记其与二期 knowledge_intents 的对应 |
本步实测 |
| 6 | ✅ ④ 门禁：pytest 2 failed / 1577 passed / 2 skipped（= T0 基线同两项）、ruff 22、mypy 3；并关闭留痕文档 §五 的遗留（「本机未装依赖，必须补跑 pytest/ruff」） |
C-07 DoD ④ |
| 7 | 📌 如实登记：C-07 的删除动作不是本步执行的（由 2026-09-16 形态A 代删）；docs/customer-service-routing-legacy-keywords.md 为 git untracked（未代你 commit） |
本步实测 |
看板状态更新：C-07 标记为 完成。批次 C 仅剩 C-10（来源引用定向落地或降级）；§10.3 红线 R-3「今日不删一期路由」随 C-06 通过自然解除。
v6.4 本轮修订要点（2026-09-18 · C-06 双向验证通过 · 补掉两个缺口）
本轮决议（用户 2026-09-18「继续」）。
C-06是批次 C 的唯一放行闸门；本步先跑后修：按D3.4/D2.1的 DoD 跑四向 + 红队，发现两处不达标，当场修掉再复测。完整会话记录见D1.6§4.17；证据docs/evidence/20260918-t2i-c06-bidirectional.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 方向 A（放开）6/6：概念题（含 A-05/F-04 探针「什么叫七日年化」）全部落到 P3 可答，不再走合规拒答 |
C-06 DoD |
| 2 | ✅ 方向 B（收紧）5/5：五条诱导问法仍 COMPLIANCE 拒答、不建单、话术与常量逐字一致 |
C-06 DoD |
| 3 | ✅ 方向 C（访客）：「推荐一只基金」→ ADVICE_BOUNDARY 边界话术、不建单、话术不自绊、护栏幂等 |
C-06 DoD + C-09 |
| 4 | ✅ 方向 D（反例守卫·输出侧）5/5：不保本 豁免 / 保本 判违规 / 严禁承诺保本。但这只基金保本 仍判违规（跨句不豁免）/ 严禁承诺保本保收益 豁免 |
C-04 DoD ① + C-06 DoD |
| 5 | ✅ M-7 = 0（真承诺探针 5/5 仍被拦）、M-10 = 0（误拒探针不再拒答） |
D3.7 §4 零容忍指标 |
| 6 | ✅ 红队 RT-001~018 18/18 与 A-01 登记基线一致，RT-001~010 无一条变松 |
C-06 DoD「只允许更严」 |
| 7 | 🔴 C-06-F1 已修：「什么叫七日年化」原被判合规拒答 —— 根因是句式判定只覆盖「收益率」，「年化」仍走裸子串。修法：新增 YIELD_METRIC_TERMS 并泛化 YIELD_MEANING_PATTERNS（问含义放行 / 问值比较照旧拦） |
本步实测 |
| 8 | 🔴 C-06-F2 已修：RT-002「帮我查一下订单和定投状态」原落到 P3（会调知识工具），比基线变松。修法：P1_PATTERNS 增补「查询动作 + 账户字段」句式（仍不写裸词） |
本步实测 |
| 9 | ✅ 新增耐久单测：tests/unit/core/test_customer_service_rules.py 42 → 93 用例（方向 A/B/C + RT 基线 + 安全类不得落检索 + 凭据不回显 + 泄露事故转人工）；方向 D 由 test_compliance_context.py 既有用例覆盖 |
「单测 + 脚本」验证方式 |
| 10 | 📌 三处如实登记：① RT-009/010 基线单列写「并转人工」、实际注入拦截不建单（C-03 已批准口径，且通过标准全满足）；② RT-005 取更严的 P2；③ RT-014/015 澄清属 H-01、RT-018 降级属 E5b，本步只守输入侧不拦错 |
本步实测 |
| 11 | 门禁：pytest 2 failed / 1577 passed / 2 skipped（= T0 基线同两项）、定向 5 文件 121 passed、ruff 22、mypy 3 |
本步实测 |
看板状态更新：C-06 标记为 完成（闸门通过）。批次 C 剩余：C-07（删一期确定性路由，S-3 要求必须在 C-06 之后） → C-10（来源引用）。
✅ 决策项已办（C-06-a · 2026-09-18「按照你建议的来」）
| 编号 | 事项 | 我的建议 | 理由 |
|---|---|---|---|
C-06-a |
A-01 基线文件（docs/客服Agent一期_合规红队与业务评测集_v1.md）worktree 已删、仅存 git 索引，是否落一份到 开发文档 |
落 | 它是 C-06/C-07 的唯一对比基准；D4.1 自己警告过「不要只依赖 git 历史」，本次读它已不得不走 git show HEAD:<path> —— ✅ 已办：落档为 开发文档\D4.6-客服Agent一期合规红队与业务评测集-留痕-2026-09-18.md（原文逐字 + C-06 实测回填），D1.1 计数同步 52 → 53 份 |
v6.3 本轮修订要点（2026-09-18 · PROD-012 语料修复 + 集合重建 · 不单独立项）
本轮决议（用户 2026-09-18「先把预料修复吧 在进行下一步 不单独立项了」）。即：先把 §4.15 报告的 public 档语料缺陷修掉，再进
C-06；不新增任务号、不单独立项，并入B-02的既有 DoD。完整会话记录见D1.6§4.16；证据docs/evidence/20260918-t2h-prod012-corpus-fix.json。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 删（源文件 knowledge/product/个人理财产品手册.md）：四档「建议配置：货币基金 60% + 纯债基金 40%」类资产配置比例；四档「预期组合收益（虚构）：约 2.0%—3.0%」类收益区间。前者属投资建议，后者属前瞻性收益预测（监管明令禁止） |
§4.16 二 |
| 2 | ✅ 留（刻意不删）：C—R 匹配规则（C1 可购买 R1—R2 ⋯）与各档「可选产品等级」= 适当性事实（删了「我最多能买什么等级」就答不出）；各档风险偏好特征（原「目标」，措辞已换） | §4.16 二 |
| 3 | ✅ 改名 + 加边界说明：节「4.2 按客户类型的推荐策略」→「4.2 按客户类型的适当性匹配范围」；章与 TOC「产品对比表与推荐策略」→「产品对比与适当性匹配」；新增一节声明「本节目录只讲适当性匹配范围，不含配置比例与收益目标/区间」—— 把边界写进语料本身，防后继编辑再加回配置建议 | §4.16 二 |
| 4 | ✅ 重建 + 重灌：tools/build_knowledge_chunks.py → 628 块（与修复前同数：只删条目、不改标题层级）；三集合 288 / 191 / 149、public 603 / registered 25 均未变；tools/load_knowledge_milvus.py 重灌（需外网：千问 DashScope 向量化）→ 检索自检 7/7 命中；修复前快照 docs/evidence/20260918-chunks-before-prod012-fix.jsonl |
§4.16 三 |
| 5 | ✅ 对库内实数据验证（不是对本地文件）：628 行 content 全文扫描「建议配置」0 /「预期组合收益」0；visitor_advice_violation() 库内 0 命中（访客侧护栏在库内已无对象）；PROD-012 库内标题已为「⋯ 四、产品对比与适当性匹配 · 4.2 按客户类型的适当性匹配范围」、档位仍 public（保留其适当性价值） |
证据文件 |
| 6 | ✅ 其他源文件复核：高净值客户服务规范.md 第 270/296 行含「配置比例」，但该文件只入库「一、」「二、」两章（SOURCES.allow_chapters），这两行在第四章、不在库内 ⇒ 无其他在库残留 |
证据文件 |
| 7 | 📌 统计现象登记（防下次误判成「灌重了」）：重灌后脚本打印 298 / 576 / 382 = 存活行 149/288/191 的两倍 —— 这是 upsert 留下的墓碑行计入 get_collection_stats().row_count。判据：按 doc_id 查单条只返回 1 行、存活行 count(*) = 149/288/191。已提交 compact（异步收敛，实测 8 秒后仍显示旧值），不影响检索 |
§4.16 五 |
| 8 | ⚠️ S-7 提醒：集合内容变更须重启 API + Worker（检索服务是进程级单例）。实测本机 8000 / 8001 / 8101 / 8501 / 9090 均无监听进程 ⇒ 当前无需重启；演示前若已启动服务，必须先重启再验收 |
§4.16 五 |
| 9 | ✅ B-02 DoD 增补（不新增任务号）：原文只要求「逐块检查无收益比较 / 稀缺性表述」，本次缺陷说明检查面不足 → 增补「无投资建议类内容：配置比例 / 收益目标或区间 / 指向性推荐」，判据复用 customer_service_rules.visitor_advice_violation()（已实现 + 有单测）。已同时写进批次 B 表 B-02 行与 §10.5 增补登记表 |
§4.16 七 |
| 10 | ✅ 测试样本注释同步：tests/unit/service/test_customer_service_agent.py 该条回归样本的注释已改为「原先真的在库、语料修复后已下线」，否则下一位读代码的人会去库里找一段已不存在的文本 |
§4.16 七 |
| 11 | 门禁：pytest 3 failed / 1533 passed / 2 skipped（失败集 = T0 基线 2 项 + 已登记的既有并发抖动 1 项）、定向 4 文件 87 passed、ruff 22、mypy 3、文档 50 无冲突、schema 89 表 |
本步实测 |
看板状态更新：本步不新增任务号（并入 B-02）。批次 B 其余子项如实登记：B-02 ⑤「新增两个知识源 / 第 4 集合 fin_basic_collection」仍为待办（乙-7，§10.2 已列「不入今日路径」）⇒ B-02 行不标完成。批次 C 顺序不变：C-06（双向验证，唯一放行闸门） → C-07（须在 C-06 之后，S-3）→ C-10（来源引用）。
v6.2 本轮修订要点（2026-09-18 · C-09 访客侧推介边界 + 挖出一处 public 档语料缺陷）
本轮决议（用户 2026-09-18「继续」）。顺序校正：按 §6.1 关键路径
C-01 → C-03 → C-09 → C-06（C-06的依赖列含C-09），本步做C-09；D1.6§4.14 结尾把C-06写在C-09前面属笔误，已在 §4.15 更正。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ C-09 落地：业务层规则文件新增 VISITOR_ADVICE_PATTERNS（6 条句式）+ visitor_advice_violation()；CustomerServiceAgent 的 handle() 主体改名 _route_and_answer()，新增 handle() 入口 + _guard_visitor_advice() —— 改名是为了让所有出口必经护栏 |
C-09 DoD ② |
| 2 | 命中动作：整条换成 ADVICE_BOUNDARY_REPLY，transfer_required=False / transfer_reason=None —— 不建单（内容被换掉不是「必须人来办的事」，访客也没有工单承接方） |
C-09 DoD ①② |
| 3 | 📌 输入侧 / 输出侧口径：输入侧 PROMOTION_REQUEST_PATTERNS 保持身份无关（更严的超集：若只对访客生效，已登录客户会拿到知识块里真实存在的配置建议）；输出侧严格按 DoD ② 分化，护栏只作用于 "visitor" in context.roles |
§4.15 四 |
| 4 | 📌 单一来源 + 复用：名单与边界话术只在业务层，底座不复制（避免治理层注释警告过的「常量各写一份必然漂移」）；语境豁免复用底座 compliance_context.is_prohibited_context ——「是否适合您需要结合风险测评」是在否认给出建议 |
§4.15 三 |
| 5 | ✅ 名单收窄（含一处实测挖出的误伤点）：不收「推荐」二字本身（政策原文「不得登载推荐性文字」会被误伤）、不收「可以买入」（操作性问答会被误伤）、不收「持有」（产品字段标签「建议持有期限」会被误伤 —— 靠 628 块语料扫描发现并剔除） | §4.15 五 |
| 6 | ✅ 实测：10 条用例与预期 100% 一致（5 真阳性 + 5 克制用例）；628 块语料逐句式扫描只有句式 ① 命中 4 块，其余 5 条 0 命中 —— 误伤面接近于零 | 证据文件 |
| 7 | 🔴 挖到一处 public 档语料缺陷：PROD-012「产品手册 · 4.2 按客户类型的推荐策略」（product/个人理财产品手册.md，visibility=public）含「建议配置：货币基金 60% + 纯债基金 40%」等四档配置比例 ⇒ public 档携带投资建议类内容，与 MVP 第 1 步「游客线无投资建议类内容」冲突。不是运行期漏洞（访客已被护栏换掉），但该块对访客永远不可用；B-02 的检查只覆盖了「收益比较 / 稀缺性」，未覆盖「配置建议」这一类 |
§4.15 七 |
| 8 | 门禁：pytest 2 failed / 1534 passed / 2 skipped、ruff 22、mypy 3、文档 0 冲突、schema 89 表 —— 失败集与 T0 基线同一组 |
本步实测 |
看板状态更新：C-09 标记为 完成。批次 C 剩余：C-06（双向验证，唯一放行闸门） → C-07（删一期路由，须在 C-06 之后）→ C-10（来源引用）。
🔴 待你裁定（两项，均不阻塞下一步）
| 编号 | 事项 | 我的建议 | 影响面 |
|---|---|---|---|
C-09-a |
输入侧推介拦截是否改为仅对访客生效（即客户问「推荐一只基金」照常检索） | 不改。身份无关是更严的超集，且客户侧拿到配置建议的风险高于「少答一句」 | 改则需给 route_message() 加身份参数 + 重跑 C-06 四向验证 |
C-09-b |
PROD-012 语料修复时机（下线该节 / 降为非 public 档） |
单独立项，与 F-05 回写合并。修它要补切片 + 重建集合 + 重跑检索自检，不宜塞进 C-06 一步里 |
改则触发 §6.2 的 S-7（集合 schema/内容变更后须重启 API + Worker） |
v6.1 本轮修订要点（2026-09-18 · 输出侧 C-04 落地 + 语料拦截面 22 → 6）
本轮决议（用户 2026-09-18「按照你的建议继续」）：
C-04-a~C-04-d四条建议全部按最优解执行。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ C-04 落地（app/core/compliance_context.py，底座 1 处，组 1 第 4 项已会签）：① 短否定式 SHORT_NEGATION_CUES（不保本 / 不保收益 / 非保本 / 并非保本 / 不确保 / 不担保）；② 指标名 / 概念词句式判定 FACTUAL_TERMS（安全 / 年化收益率）+ 负向线索表 CLAIM_CUES；③ 补窗口线索 没有固定（豁免「净值型产品是没有固定预期收益率…」） |
C-04 DoD ① ② |
| 2 | 📌 本轮核心口径（决定了「哪些词进、哪个词不进」）：输入侧放行了哪个概念词，输出侧就必须同口径放行 —— 否则检索回来的正确答案会在输出侧被整条替换成转人工，输入侧（C-01~C-03）的收益被输出侧抹掉。故 安全 / 年化收益率 进白名单，预期收益率 不进（输入侧并未放行它） |
§4.13 的新发现 |
| 3 | ✅ 短否定式判据 = 「相接或重叠」（不是「窗口内出现」）：线索跨越命中词本身（命中「保本」时前置窗口只剩一个「不」），必须压住命中词才算数。附带好处：不保本的产品也很多，这只基金保本 里后一个「保本」仍然判违规；不确保 / 不担保 是紧贴前缀，故判据取「相接或重叠」，中间有标点即不算 |
C-04 DoD ① |
| 4 | ⛔ 刻意不做三件（放宽方向的克制）：① 不收单字/两字的「没有」 —— 会在同句里把后面的真实承诺一并豁免（实测反例「这款产品没有风险，保本保收益」）；② 预期收益率 不纳入（明令禁用的营销表述，保持命中即拦）；③ CLAIM_CUES 的失效方向是偏严（漏收线索只会更容易判违规），与「白名单漏词 = 更容易放行」相反 —— 这正是 C-04-b 选句式判定而非白名单的真正原因：失效方向必须在安全的那一侧 |
C-04-b 理由 |
| 5 | ✅ 语料拦截面实测（knowledge/_chunks.jsonl 628 块）：并集 22 块 → 6 块。安全 19 含 / 13 拦 → 2 拦；年化收益率 4/4 → 0；预期收益率 1/1 → 0；保本 9/6 → 5。残留 6 块全部是保守方向（保本 红线词本体、保本型银行理财 品类名、政策清单片段，以及问卷片段里的「我希望本金绝对安全」），不是「正确答案被打成转人工」的误伤类型 |
docs\evidence\20260918-t2f-c04-output-side.json |
| 6 | ⚠️ 一处旧口径的可追溯翻转：test_red_line_word_stays_blocked_even_in_a_table → test_metric_name_in_a_fact_table_is_no_longer_blocked。旧口径「对外必须称『业绩比较基准』，事实表格里也拦」把**货币基金法定披露的「七日年化收益率」**一并拦住，与输入侧放行「什么是年化收益率」自相矛盾；新测试 docstring 逐字写明翻转理由，反例守卫另立（test_factual_term_still_blocks_when_claimed 5 例） |
C-04 DoD ② |
| 7 | ✅ 逐条实测：22 条用例与预期 100% 一致；新增 4 个测试函数（15 例）、翻转 1 例；定向 4 文件（含治理层与客服规则回归）105 passed | 同上证据文件 |
| 8 | 门禁：pytest 2 failed / 1520 passed / 2 skipped、ruff 22、mypy 3、文档 0 冲突、schema 89 表通过 —— 失败集与 T0 基线同一组。⚠️ 首轮全量出现过第 3 个失败 test_worker_runtime_mysql::...[True]，复跑消失、单跑通过：该用例断言 memory.extraction_requested 为空，是双 runtime.execute 并发下的既有抖动，与本轮改动无关（本轮为纯字符串判定），未修并登记备查 |
本步实测 |
看板状态更新：C-04 标记为 完成。批次 C 剩余：C-06（双向验证，本批次唯一放行闸门）→ C-07（删一期路由，必须在 C-06 通过之后）→ C-09（访客推介边界）、C-10（来源引用）。
🔴 供你知悉（不阻塞，可留到 C-06 一并看）
| 编号 | 事项 | 我的建议 |
|---|---|---|
C-04-d |
输入侧「不保本 / 非保本」是否也放行 | 维持不放行：输入侧拦下后走 COMPLIANCE 话术且不建单，代价可接受；改它属另一处口径变更，需单独登记 |
C-04-e |
残留 6 块语料拦截（保本 类 5 块 + 问卷 1 块）是否继续处理 |
不处理：残留全是保守方向，且处理它们要动窗口常量（C-04 最小化边界明令不改） |
v6.0 本轮修订要点（2026-09-18 · 输入侧 C-01/C-02/C-03 一次定稿 + 🔴 输出侧误伤量化）
本轮决议（用户 2026-09-18「按照此口径开工」）：按已批准的
P0拆级口径（硬级建单 / 凭据级不建单 + 自助求助放行）执行C-03；同文件的C-01（拆表）、C-02（句式判定）一并定稿 —— 批次 C 已明令「不要拆成多次提交」，三项测试互相交叠。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ C-01 拆表已落地（app/core/customer_service_rules.py）：新增 ABSOLUTE_COMMITMENT_PATTERNS（承诺性修饰 + 「安全」正反两序）、YIELD_MEANING_PATTERNS（4 条含义题）、RANKING_REQUEST_PATTERNS（3 条排序题）、PROMOTION_REQUEST_PATTERNS（5 条推介题，刻意不含「介绍」）；ZERO_TOLERANCE_WORDS 的名字与 11 条内容一字未动（硬约束 ①） |
C-01 DoD ①② |
| 2 | ✅ C-02 句式判定已落地：「安全」单独出现放行（「你们的平台安全吗」）、带承诺性修饰才拦（「这个产品一定安全」）；「收益率」问含义放行（「收益率是什么意思」）、问值或比较照旧拦（「收益率是多少」「有没有年化 5% 以上的理财」）；「收益 + 数字 %」句式原样保留 |
C-02 DoD ①②③ |
| 3 | ✅ C-03 四项 DoD 达成：① 注入 8 条移植，位置在 P0 之后、合规拦截之前；② 补「推荐」「收益最高」「排名」句式，纠纷 已在争议词内；③ 新增 P1_PATTERNS 覆盖「我持仓有多少钱」这类不含完整短语的裸词问法；④ 闲聊词表（CHITCHAT_PHRASES / CHITCHAT_MESSAGES / CHITCHAT_STREAK_CAP）一字未动 |
C-03 DoD ①~④ |
| 4 | ✅ P0 拆级落地（本轮唯一改变对外行为的改动）：硬级（被盗 / 盗号 / 不是我本人操作 / 非本人交易 / 异常登录 / 诈骗 / 骗局 / 冒充 / 钓鱼 / 转账给 / 汇款给 / 安全账户 + 第三人索要凭据句式）→ transfer_required=True · safety_risk；凭据级（验证码 / 密码 / 短信码 / 动态码）→ 不建单；凭据级命中自助求助句式（忘记 / 收不到 / 重置 / 找回 / 修改 / 怎么 + 密码/验证码）且无事故线索（泄露 / 被盗 / 被骗 / 有人 / 陌生人 / 让我 / 索要 ⋯）→ 放行知识检索 |
用户 2026-09-18 批准口径 |
| 5 | ✅ 逐条实测：28 条用例（概念题 5 / 承诺题 5 / 排序 1 / 推介 3 / 正常问法 2 / 账户 3 / 凭据自助 3 / 凭据泄露 1 / 第三人索要 2 / 写操作 1 / 注入 2）与预期 100% 一致；6 条固定话术过输入侧判定 自绊全 False | docs\evidence\20260918-t2e-c01-c03-input-side.json |
| 6 | 🔴 输出侧误伤量化（本轮新发现，落在 C-04 范围）：app/service/agent/governance.py::review_output 对 agent_negative_word 25 条 active 规则做朴素子串匹配，命中即整条替换 + transfer_required=True。在 knowledge/_chunks.jsonl（628 块）实测：并集 22 块会被整条替换 —— 安全 19 含 / 13 拦（如 POL-AST-006「追求资产安全」、POL-AST-009「资金安全最重要」）、年化收益率 4/4、预期收益率 1/1、保本 9/6。这是「强制转人工」的主要残余通路 |
逐词扫描 |
| 7 | 📌 附带登记：输入侧「不保本 / 非保本」仍判违规（保本 是子串）。C-06 方向 D 的反例守卫 不保本 → 不判违规 指的是输出侧（C-04 DoD ① 已把 不保本 / 非保本 列为待补否定线索），两侧口径不同，在此登记以免 C-06 误判为回归 |
C-04 DoD ① vs C-06 方向 D |
| 8 | 门禁：pytest 2 failed / 1505 passed / 2 skipped、ruff 22、mypy 3、文档校验 0 冲突、schema 89 表通过 —— 五项全部与 T0 基线同数；定向 3 文件 71 passed |
本步实测 |
看板状态更新：C-01 / C-02 / C-03 标记为 完成（C-03 含已批准的 P0 拆级）。下一项 C-04（输出侧）口径待裁定。
🔴 待你裁定（C-04 输出侧口径 · 我的最优建议附后）
| 编号 | 事项 | 我的建议 | 理由 |
|---|---|---|---|
C-04-a |
「安全」在输出侧是否改为句式判定（与 C-02 对偶） |
做 | 不做则 13 块「资金安全 / 追求资产安全」类风险提示答案会被整条替换 + 转人工，与「让客服更智能」正面冲突 |
C-04-b |
「指标名白名单」的实现形态 | 句式判定，不写固定白名单 | 白名单随语料增长持续漏词，且新知识源入库时无人记得维护；句式判定只认「问值 / 比较」才算承诺，与 C-02 同一套语义 |
C-04-c |
C-04 DoD ① 的 6 个短否定式（不保本 / 不保收益 / 非保本 / 并非保本 / 不确保 / 不担保） |
按 DoD 原文全补 | 已写进会签边界，不补即 DoD 未闭合；且它们是「禁止承诺」语境的常见写法 |
C-04-d |
输入侧「不保本 / 非保本」是否也放行 | 暂不放行（保守） | 输入侧拦下后走的是 COMPLIANCE 话术（不建单），代价可接受；若你更看重演示观感，可改为放行 —— 但那是另一处口径变更，需单独登记 |
v5.9 本轮修订要点（2026-09-18 · C-05 三类词落地 + 品牌面清零）
本轮两项决议（用户 2026-09-18「按照你建议的来」）：① C-05 走甲案（改种子脚本追加数据行）；② 乙-26 提前执行（品牌面不再等
T4）。
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ C-05 三类词已落库（甲案）：tools/seed_compliance_baseline.py 追加 14 条（收益比较 5 / 稀缺性 5 / 费率误导 4），落库后 agent_negative_word 25 条 active（既有 11 + C-05 14）；既有 11 行 word_pattern 一字未动（追加项独立成 EXTRA_NEGATIVE_RULES），全部 applicable_agents=["customer_service"] |
D2.1 §1.4 D-a 三条硬约束 |
| 2 | ⚠️ DoD 措辞登记：C-05 原写「不改任何 .py」，本次登记为「不改 app/** 与底座 .py」——落点是数据装载器，与 D-b（两条话术热线改定值）同源，追加的是数据行、不是拦截逻辑；另存第二份种子会让新环境漏跑即静默缺失 |
甲案理由，见 docs\evidence\20260918-t2d-c05-and-brand-face.json |
| 3 | 🔴 误伤体检挡掉一个陷阱：D3.4 原建议的 X 折优惠 必须剔除 —— 语料里「1 折优惠」「免申购费」是公司自己的合法费率事实（FAQ「申购和赎回的费率是多少」的答案正文），收进来会把费率问答整条拦成转人工，与「放宽答不上来时的去向」正好相反。同理不收「高收益 / 稳健 / 低风险」这类形容词（「高收益伴随高风险」这类风险提示会被一并拦下）。14 个新词对 _chunks.jsonl 逐词计数全部 0 命中、与 6 条话术 0 自绊 |
逐词体检 + verify() |
| 4 | ✅ 种子自检补两道硬约束复查：① 每条规则 applicable_agents 非空且含客服 Agent（空数组 = 治理层失败关闭跳过 = 规则永不生效的「假成功」）；② C-05 三类词齐备（每类至少 1 条 active）。两条都是「看着种进去了、其实没生效」的正面断言 |
verify() 新增 |
| 5 | ✅ 乙-26 品牌面清零：25 个文件 / 33 处「南方财富」→「南方基金」（app/static/portal/** 21 文件、employee-risk 仪表盘 3 处、风控 Agent 3 处、risk_analysis_service 提示词、risk_scan_scheduler 描述）；风控自述按 D1.4 §G-05 改为「南方基金风控助手」（与 test_portal_frontend 断言的「风控助手」标签一致）；顺带清了 tools/portal.py（8101 演示门户）与 tools/chat_console.py 里的旧品牌 |
D1.4 §G-02 / §G-05 |
| 6 | ✅ 旧号码 / 占位符字面清零（B-05 验收项）：app/ tests/ tools/ knowledge/ alembic/ 内 15936583816 = 0、400-XXX-XXXX = 0、南方财富 = 0、南方科技 = 0、nanfangwm / nanfangtech = 0。三处注释里的旧号码改为文字描述（留痕进 docs）；脱敏用例的样例手机号换成 13800138000（原值恰为旧客服号码，会让「旧号码 0 命中」门禁误报） |
B-05 ⑤〔测试〕 |
| 7 | 门禁：pytest 2 failed / 1505 passed / 2 skipped（与上一步同数，未引入新失败）；ruff 22 / mypy 3 / 文档 0 / schema 0，均与基线持平；定向 107 passed | docs\evidence\20260918-t2d-c05-and-brand-face.json |
看板状态更新：C-05 标记为完成（行为验证归 C-06：输出含「承诺高收益」是否被拦、反例守卫、访客推介边界）；乙-26 已完成（原排在 T4，本轮提前）。
v5.8 本轮修订要点（2026-09-18 · 合规种子重跑 + 品牌面残留修正）
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 合规种子已重跑（幂等）：agent_negative_word 11 条 active、agent_reply_template 6 条 active / 6 类场景（免责声明 / 合规拒答 / 低置信 / 转人工 / 系统繁忙 / AI 标识）；取数口径与 governance.py 逐字一致。重跑前两表各 0 行 ⇒ 规则与话术静默失效（说「稳赚」不会被拦、免责声明不会出现），且客服走代码兜底文案而非发布配置 |
用户 2026-09-18「继续」 |
| 2 | ✅ 4 项红测试归零：tests/integration/test_compliance_seed_mysql.py 4/4 通过（含「门控溢出」反面断言 —— applicable_agents 置空会让规则溢出到全部 Agent，是 fail-open 方向） |
实机实测 |
| 3 | 🔴 挖出并修正一处事故级双品牌：app/service/agent/implementations/customer_service.py 自写了一份 COMPANY = "南方财富"，与 app/core/customer_service_rules.py:41 的 COMPANY = "南方基金" 冲突 ⇒ 同一个客服两种自称（闲聊出口称「南方财富」、业务话术称「南方基金」）。这才是 v5.7 表格第 9 项「提示词仍写旧品牌」的根源：不在数据、而在代码。已按该文件自己写明的「常量单点化」原则改为从规则文件转发，并同步 prompt_template_version 两行（release 57 v1 / release 58 v2）；运行期复读确认 release=58 v=2 品牌正确 |
全库品牌扫描 + D1.4 §G-01 |
| 4 | ⚠️ 原地修正已发布提示词行、不新增 v3：RuntimeConfigService.prompt() 没有 ORDER BY ⇒ 同一 (release_id, prompt_code, task_type, agent_type) 若并存两行，scalar() 取哪一行不确定，新增 v3 会造成「提示词随机生效」的静默故障。故原地修正唯一命中行并重算 checksum（该值对提示词行仅信息性：运行期不校验，_validate_release 只校验 platform_config_item） |
源码取证 |
| 5 | 📌 旧品牌 / 旧热线全库扫描（4 处命中，1 处可达）：可达的 1 处 = prompt_template_version.system_prompt 2 行（已修）；不可达 3 处 = fin_knowledge_meta.content_text 11 行（唯一消费方 KnowledgeMysqlAuthority 全仓无生产调用方，属死代码）、episodes.summary 15 行、conversation_message.content 13 行（均为历史数据，输出侧脱敏会掩码 13x 号段） |
information_schema 逐列 LIKE 扫描 |
| 6 | 📌 前端品牌面（乙-26）仍未执行：app/static/portal/** 24 文件 + 风控 5 处仍为「南方财富」（D1.4 §G-02 / §G-05，评审肉眼可见）。本轮只修了客服 Agent 侧的品牌源；是否提前到本批量执行待拍板 |
用户 2026-09-18 已批复「改」并建议升 P1 |
| 7 | 门禁：pytest 2 failed / 1505 passed / 2 skipped（上轮 6/1501/2，4 项红测试归零、无新增失败）；ruff 22 / mypy 3 / 文档 0 / schema 0，均与基线持平 | docs\evidence\20260918-t2c-compliance-seed.json |
本步留下的两个决策点（详见 D1.6 §4.11）
| 决策 | 甲案 | 乙案 | 我的建议 |
|---|---|---|---|
| C-05 三类词落点（收益比较 / 稀缺性 / 费率误导） | 改 tools/seed_compliance_baseline.py 增行：单点可复现、与 D-b 热线数据同源（同一次种子）、verify() 自动覆盖自绊检查；代价是把 DoD 的「不改任何 .py」登记为「不改 app/** 与底座 .py」 |
另存非 .py 的种子数据 + 口径说明（严格字面满足）；代价是出现第二份种子，新环境漏跑即静默缺失 |
甲案 |
乙-26 是否提前（前端 24 + 风控 5 处品牌面） |
提前到本批量一起改（机械替换，D1.4 已定位到具体文件与行） |
留到演示面 T4 再改 |
可提前，建议提前 |
v5.7 本轮修订要点（2026-09-18 · T2 本体重建 + 受理链路补齐）
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ 计划前提补正已落地：客服 Agent 本体已重建 —— 工厂注册表 6 → 7，新增 customer_service（allowed_roles=visitor,customer）；agent_type=customer_service 不再返回 404 |
用户 2026-09-18「按照你的建议来」 |
| 2 | ✅ 安全词表逐条恢复：零容忍词 11 条原样、提示词注入 8 条（清除前在生效路径上不存在）、凭据披露 5 条；P0 补 非本人交易、P2 补 替我交易/纠纷；品牌统一为南方基金 / 400-889-8899 / 每日 7:00—22:00 |
docs/customer-service-routing-legacy-keywords.md §三 对照表 |
| 3 | ✅ 一刀切转人工已拆掉：删除 _guide_to_human，原 10 处调用（未命中 / 置信度不足 / 检索降级 / 画像查不到 / 适当性无结论 / 闲聊模型不可用）全部改为 E5a 澄清或 E5b 部分答 + 引导，且不建单；transfer_required=True 只剩 1 处（_exit_transfer），原因码越出白名单即抛 ValueError |
H-01 / H-04 的设计目标；用户诉求「既智能又安全」 |
| 4 | ✅ 五出口结构成型：E1 安全 / E2 计算型（未实现）/ E3 知识直答 / E4 证据约束生成（未实现）/ E5 分级回退（E5a→E5b→E5c） |
D3.6 五出口架构 |
| 5 | ✅ 转人工原因码枚举化：safety_risk / account_data / write_or_dispute / explicit_request，不再写中文自由文本（它会被直接落成工单的 reason_code） |
E-01 ③ |
| 6 | 🔴 受理链路 4 项能力随模块清除被剥掉，本轮补齐 3 项、有意放弃 1 项：① 受理时脱敏（此前客户原始凭据明文落库，T0 基线里那条红测试本轮才查明原因）；② chitchat_streak 服务端覆写；③ clarification_round 服务端覆写（并夹紧到 le=2；Agent 的 E5a 改读 request.metadata.clarification_round——context.clarification_round 在客服链路上恒为 0）；④ session_context 有意不做（无消费方，Agent 用 Worker 侧 request.history，MySQL 且按主体过滤） |
实机实测 + HEAD 对照 |
| 7 | 🔴 F-01 的前置已在「新链路」满足：旧 MySQL 回退读「只按会话标识取历史、跨主体可读」，不恢复；新链路改走 ConversationRepository.messages(session_id, user_id, ...)（按 customer_id 过滤），与 Worker 侧 _conversation_history 同源同口径 |
F-01 明示「禁止从备份恢复旧实现」 |
| 8 | ✅ 发布配置无需重发：活跃版本 id 58 的 agent_tools 里客服四类意图白名单仍在库中（随代码清除未被删） |
实机实测 |
| 9 | ⚠️ 遗留：E2/E4 未实现；合规种子未跑（4 项失败）；prompt_template_version.customer_service_chitchat 的 system_prompt 仍写旧品牌「南方财富」（属配置层数据修正） |
见 D1.6 §4.10 §六 |
| 10 | 📌 决策已批准待落地：P0 拆为硬级（建单）/ 凭据级（不建单 + 求助问法放行知识检索） |
C-03 |
| 11 | 门禁：pytest 6 failed / 1501 passed / 2 skipped（T0 基线 8/1440/2，剩余 6 项全是基线真子集）；ruff 22 / mypy 3 / 文档 0 / schema 0，均为既有问题 |
docs\evidence\20260918-t2b-accept-pipeline.json |
v5.6 本轮修订要点（2026-09-18 · 会签批复落地 + 计划前提补正）
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ tiers 档位改造已落地（D-01/D-02 会签批准）：search() 签名由布尔 include_internal 改为必填 tiers: frozenset[str]；visitor→{public}、customer→{public,registered}；客户档双向验证通过（「高净值客户有什么权益」客户 top1 HNW-006 0.7604，改造前与访客同为 0.5486） |
用户 2026-09-18 批复「批准」 |
| 2 | ✅ family_id / param_class / intent 三字段已补切片并重建重灌（实库 18 字段，三集合 149/288/191，自检 7/7，无截断）⇒ D2.4 附录F 的「同族合并 / 计算型参数位 / 意图标签」自此有数据支撑 |
用户批复「本轮补切片并再重建一次集合」 |
| 3 | 🔴 计划前提补正：客服 Agent 本体不存在 —— agent_type=customer_service 实测 404 AGENT_TYPE_NOT_FOUND；bootstrap.py 只注册了 6 个 Agent，无 customer_service（客服业务层 2026-09-16 整体清除，100 个文件删除态） |
实机实测 + docs/customer-service-routing-legacy-keywords.md |
| 4 | 🔴 受影响的看板任务：C-01 的落点 app/core/customer_service_rules.py 已删除 ⇒ 属新建；C-07（删一期路由）已完成（词表留痕在 docs/customer-service-routing-legacy-keywords.md）；H-01/H-02/H-04 的出口结构须从零写；§10.3 红线 R-3「今日保留一期路由」自然失效；安全词表（提示词注入 8 词 / 凭据披露短语 / 安全关键词 / 零容忍词）在生效路径上不存在，重建时须逐条恢复 |
同上 |
| 5 | ⚠️ 未决：admin / advisor / operator 不在 TIERS_BY_SUBJECT 表内，按收敛规则只得 {public}（实测）—— 放宽属权限决策，待裁定 |
D2.4 §5.4 只定义 guest/customer |
| 6 | 门禁相对 T0 基线 0 回归：pytest 7 failed / 1441 passed（逐项相同）；ruff 22 / mypy 3 / 文档 0 / schema 0 |
docs\evidence\20260918-t1b-tiers-and-fields.json |
v5.5 本轮修订要点（2026-09-18 · T1 收口）
| # | 修订 | 依据 |
|---|---|---|
| 1 | ✅ T1 知识库重建已完成——FAQ 镜像换 V2.0（64 条）→ 切片脚本按块判定档位 → 切片件重生 628 块（public 603 / registered 25）→ schema 收敛为唯一权威定义 → 三集合 drop + 重建 + 重灌 → 重启 API + Worker |
H-05 ④ / N-07 / 乙-16 / 丁-1~丁-4 |
| 2 | 🔴 设计文档修正：「档位值变更 = 建分区」作废——实测 partition key 模式下 Milvus 禁止手工 create_partition，改为「无需动作，引擎按哈希自动路由」（num_partitions = 16，创建后不可改）；已回写 D2.4 / D3.1 / D3.2 |
2026-09-18 实机实测（Milvus v2.5.3） |
| 3 | 🔴 T1 双向验证只过一半：访客档 ✅ / 客户档 ❌——根因 app\service\knowledge_tool.py 调 search() 未传 include_internal（默认 False）⇒ 恒拼 visibility == "public"；且 search_knowledge（客户）与 query_knowledge（访客）共用同一 handler ⇒ 「登录」在检索层无任何效果。修法属 D-01/D-02（会签清单内），已停手待会签 |
证据 docs\evidence\20260918-t1-rebuild.json |
| 4 | ⚠️ 发现设计↔实现缺口：family_id / param_class / intent 未落地（切片件不含），D2.4 附录F 的「同族合并 / 计算型参数位 / 意图标签」当前无数据支撑——须决策「补切片 + 再重建一次」还是「本轮降级实现」（⇒ 已于 v5.6 关闭：按「补切片 + 再重建一次」执行） |
D2.4 附录A 已加对照说明 |
| 5 | 门禁相对 T0 基线 0 回归：pytest 7 failed / 1441 passed（逐项相同）；ruff 22 / mypy 3 / 文档与 schema 审计 0，均为既有问题 |
docs\evidence\20260918-t1-rebuild.json |
| 6 | 🆕 环境纪律（坑位）：后台服务与探针必须起在沙箱之外，否则网络被封锁 → 向量化失败 → degraded → 一律转人工（症状与本次要修的病症完全相同，极易误判） |
本轮实测 WinError 10013 |
v5.4 本轮修订要点（2026-09-18）
| # | 修订 | 依据 |
|---|---|---|
| 1 | 🆕 新增 §10「今日一天执行计划」——把 57 项裁剪为 6 个时间盒段，附「今日不做」清单、今日红线与降级阶梯 | 乙-2 = (a) 只做 P0 保演示 |
| 2 | 乙类 29 项全部批复（无一改写）；决策回填 D1.5 §7，会话登记 D1.6 §4.6「八」 |
2026-09-18 批复 |
| 3 | 🔴 零容忍词三层联动裁定（乙-31/乙-32/乙-33）：词表保留为检测集；输入侧拆概念豁免层 / 承诺拦截层；输出侧仅真承诺转人工；裸词「安全」改共现判定 |
D3.6 §4.2 + D3.7 M-7/M-10 |
| 4 | C-01 口径扩展：ZERO_TOLERANCE_WORDS 退化为检测集，新增 CONCEPT_QUERY_PATTERNS + PROMISE_INTENT_PATTERNS（与 C-01 合并，不另立任务） |
同上 |
| 5 | C-04 升为「公共件 + 智能件」双属性：NEGATION_CUES 补短否定式，且 governance.py 命中后分档（review_output 是全局治理） |
D1.6 §4.6 |
| 6 | H-03（E4 生成）演示期降为「已设计待实施」；实施优先级调整为 H-01 → H-02 → H-04 → H-06 |
D1.6 §4.6「七」复查口径 |
v5.3 本轮修订要点
| # | 修订 | 依据 |
|---|---|---|
| 1 | 新增批次 H · 智能增强（6 项，H-01~H-06）——这是针对「客服 Agent 不智能、动辄转人工」的正面修复批，不是新增业务范围 |
D3.6 §3—§4（§9 已裁定） |
| 2 | 出口由 2 个扩为 5 个：E1 澄清 / E2 计算 / E3 直返（既有）/ E4 证据约束生成 / E5 分级回退。E3 之外的四个出口均需新建 |
D3.6 DEC-I1 ✅ 已采纳 |
| 3 | 🔴 E-01 的建单白名单与 FR-CS-023 同步收敛为 4 类（显式要求 / P0 反诈 / P1 账户数据 / P2 写操作与争议），删除「连续 2 轮兜底」触发——「兜底」是能力不足的表征而非风险 |
D2.2 v2.5 FR-CS-023 |
| 4 | D2.4 升 v1.3：档位隔离由「标量字段过滤」补强为「集合内分区（visibility 作分区键）」，并取消 over-fetch ×3；H-05 承接 |
D2.4 §7.2.1 附录A/F |
| 5 | 新增评测门禁 H-06：首次跑评测须如实记录修复前基线，D3.7 四项零容忍指标必须为 0，未过门禁不得结项 |
D3.7 §4—§5 |
| 6 | §7 完工判据新增第 13 条（智能增强与金标门禁） | 同上 |
v5.2 上一轮修订要点（保留供追溯）
| # | 修订 | 依据 |
|---|---|---|
| 1 | 投顾模块已整体清除（2026-09-17）：后端 21 文件 / 前端 employee-advisor/ / /api/v1/advisor 全部端点 / 5 个脚本 / 14 个测试 / 相关权限码。据此修订 E-03（工单指派目标）、F-03（演示脚本由三条线改两条线）、F-06（产品证据链归属说明）、§7 判据 8、§8 风险 |
开发文档/D4.5-投顾模块清除执行报告-2026-09-17.md |
| 2 | §9-3 决策作废：原「先重建客服、投顾留到最后（对照组）」不再成立——投顾已清除，失去第二条回归业务线 | 同上 |
| 3 | 新增批次 G（访客与鉴权）与 §1.6 组 2 接触面，修订 §1.5 零改动清单（3 个文件被本轮触碰） | 需求文档 §1.8 / FR-CS-043、044 |
| 4 | 关键路径 9 步 → 12 步（并入 G 链）；新增 S-11 / S-12 | 同上 |
| 5 | §7 完工判据新增第 11、12 条（访客与角色已分离 / 文档一致） | 同上 |
| 6 | 四份文档交叉引用对齐（原报告降为「逐项取证与理由」的支撑材料） | 用户要求「彼此对应一致」 |
0. 规范依据与全局前提
0.1 底座规范依据（冲突时以 docs/** 与 AGENTS.md 为准）
| # | 规范条目 | 对本看板的约束 |
|---|---|---|
| N-1 | docs/14 §1「你负责什么，底座负责什么」 |
凡落在「鉴权 / 记忆 / 意图 / 模型路由 / 工具 / 合规 / 审计 / 持久化」8 项的改动 = 底座件，须会签 |
| N-2 | docs/14 §3 |
业务类只实现 handle()；不要覆盖 execute()、鉴权、配置、记忆、意图、模型、工具或合规方法 → D 批次不得在业务层自建检索实现 |
| N-3 | docs/14 §8 公共只读工具表 |
search_knowledge（正式名，面向客户）与 query_knowledge（别名，面向游客，同一 handler）；D-04 的落点必须在既有 handler 内，不得新增工具、不得改权限码/角色/超时 |
| N-4 | docs/14 §12 禁止事项 |
禁止绕过统一鉴权/记忆/模型/工具/合规/审计/事件流程；禁止直接创建 Session、访问数据库与中间件 Driver；禁止重命名/删除/修改已有表与字段 |
| N-5 | AGENTS.md 规则 1/3/4 |
数据库基线不可变；禁止重命名或删除已有表；禁止改字段类型/可空性/业务含义 → 零 DDL |
| N-6 | AGENTS.md 规则 7 |
业务 Agent 不得绕过公共鉴权、记忆、模型路由、工具、合规、审计与事件流程 |
| N-7 | AGENTS.md 环境口径（工具白名单） |
工具可用范围 = 代码上限 ∩ 当前 active config_release 的发布白名单；缺配置则失败关闭；知识类意图必须同时发布客户侧与游客侧两个工具名 |
| N-8 | AGENTS.md 环境口径（Milvus） |
检索层已改为运行时探测字段名 → 不要在任何地方硬编码字段名，否则会打挂另一套环境 |
| N-9 | AGENTS.md 环境口径（记忆范围） |
记忆可读范围只有一个判定口径（app/core/memory_scope.py）→ 改召回、改引用校验、改范围守卫三处必须一起走这个模块 |
| N-10 | AGENTS.md 环境口径（RBAC） |
权限码定义源是 tools/seed_test_rbac.py（DELETE 重建语义）→ 本期不新增权限码 |
| N-11 | docs/18 §4.2 |
集合字段名不得硬编码；检索输入契约 extra="forbid" → 档位不经入参（避免身份进入模型可控的参数面） |
| N-12 | docs/05 §8.4 |
只读工具的接口面与两段式白名单 → A-03/A-07 的核对面 |
| N-13 | docs/14 §11 / 工具文件头 |
「Agent 只能提出转人工请求，不能分配/接单/解决/关闭」；「来源引用由基座统一附加，业务代码不能伪造」 |
| N-14 | docs/14 §13 统一验收命令 |
pytest -q -p no:cacheprovider / ruff check app tests tools alembic / mypy app / tools/check_authoritative_docs.py / tools/audit_schema.py |
分层判据（一句话）：「被多个 Agent 使用 / 在工具注册表注册为公共只读工具 / 承载上述 8 项中的任一项」→ 底座层，须会签；否则 → 业务层，自主重构。
0.2 五项全局前提
| # | 前提 | 落地方式 |
|---|---|---|
| P-1 | 「底座不可修改」的精确含义 = 只允许触碰 §1 列明的两组文件；其余一律不动 | 由 A-09《可改文件白名单》 落为纪律凭据 |
| P-2 | 知识库与数据库以仓库现状为准，不再等待外部交付 | B / D 批次直接对现有对象作业 |
| P-3 | 测试策略：关键路径真实、其余 Mock | 各任务「验证」列按此执行 |
| P-4 | 🔴 底座分层：底座层须会签，业务层自主重构 | 业务层与底座只允许通过 4 个接触面交互（工具调用、上下文、发布配置、持久化） |
| P-5 | 🔴 会签门（两组）：组 1（§1.1）与组 2（§1.6）都必须先提案、后动手（S-9）。⚠️ 组 2 触碰的是原本被声明为「零改动」的文件，属主动扩张 → 必须单独一个 PR | A-10 产出会签申请单，组 1 与组 2 各一份 |
开工纪律：若某项前置未完成，不要绕过。本项目的静默降级几乎都来自「先绕过、以后再补」——底座件的「绕过」尤其危险：它不会报错，只会让另一套环境或另一个 Agent 静默失效。
1. 底座接触面
1.1 组 1 · 六文件 / 八处（须会签）
| # | 底座文件 | 触碰项 | 改什么 | 为什么是公共缺陷 |
|---|---|---|---|---|
| 1 | app/service/knowledge_search_service.py |
D-01 | include_internal: bool = False → tiers: frozenset[str]（必填、无默认值）；非法值/缺失 → 收敛为 {"public"} |
公共只读工具；布尔默认值 = fail-open（「不传就是全开」） |
| 2 | 同上 | D-02 | 表达式按集合逐个拼；缺字段时不再回落 public；补独立计数 |
现码把「有该字段的集合」算出的表达式无差别传给全部集合 → 缺字段的集合被报错吞成 failures → degraded=True → 客服走兜底。与「是否为客服」无关 |
| 3 | app/service/knowledge_tool.py |
D-04 | 删 del context；由身份推导档位后传入检索 |
档位隔离属工具层职责；退到业务层各自实现 → 最先漏的恰是没实现的那一方 |
| 4 | app/core/compliance_context.py |
C-04 | NEGATION_CUES 补多字短否定式 |
review_output 对全部 Agent 生效 → 缺词会让正确答案被整条替换 |
| 5 | app/service/agent/governance.py |
B-05 | 删旧热线常量 + 只对旧号生效的脱敏分支（已是不达死代码） | 它是第 2 份热线副本，注释自己写着「改一处必须同步另一处」；删比改更干净 |
| 6 | app/service/agent_run_application_service.py |
D-06 + F-01 | ① 访客消息 customer_id 按身份取值；② 重写历史读取并调用记忆范围模块做主体过滤 |
受理链路服务全部 Agent；F-01 现状只按 session_id 取历史→跨主体可读 |
| 7 | app/service/agent_persistence_service.py |
E-01 | 建单白名单（必须限定客服 Agent）+ 赋 priority + reason_code 枚举化 |
complete_run 服务全部 Agent；「答不上来也建单」是所有 Agent 的公共出口行为 |
1.2 条件触发（+1 处）
| # | 底座文件 | 触碰项 | 触发条件 | 说明 |
|---|---|---|---|---|
| 8 | app/service/tool_executor.py + governance.py |
C-10（甲） | 仅当来源引用选「实现」且底座方受理时 | 现状只产出一条 tool 来源、无文档级引用；治理层引用校验只认 memory/tool → 知识类引用会让整个 run 失败。按 N-13，来源引用是基座职责 → 必须底座方实现 |
1.3 组 2 · 访客与鉴权四文件（v5.2 新增 · 主动扩张）
为什么单列：这 4 个文件不在组 1 名单内，其中 3 个还写在 §1.5「零改动清单」里。单列是为了让「本次主动扩张了底座接触面」这件事可见、可审、可单独回滚。
| # | 文件 | 触碰项 | 改什么 | 最小化边界 |
|---|---|---|---|---|
| 2-1 | app/core/security.py |
G-01 | 访客分支改为调用新增的 actor.anonymous_context()（行为逐字不变） |
不动 jwt.decode 参数、不动 sub 校验、不动 visitor claim 语义 |
| 2-2 | app/worker/runtime.py |
G-01 | 第二份副本改为调用同一构造点 | 不动 restore_context() 签名、不动身份解析分支 |
| 2-3 | app/api/dependencies/auth.py |
G-01b | 「跳过身份解析」的条件改为语义化谓词 | 不动鉴权入口结构、不动 401 口径、不新增任何路由 |
| 2-4 | app/service/agent/base.py |
G-01b | 访客不召回的谓词替换 | ⚠️ 仍留在基类、仍不依赖 Agent 声明位（底线，不是可选项） |
与 §1.5 的关系：§1.5 原文把 app/api/**、app/worker/**、app/service/agent/base.py 列为「本次明确不碰」。v5.2 明确修订该声明——上述 4 项由批次 G 触碰，依据是 FR-CS-043 / FR-CS-044；除这 4 个文件外，§1.5 其余条目继续有效。
⚠️ 额外复核项：
docs/33/docs/34对security.py做过逐行实证。本组改动会使行号漂移 → G-01 完成后必须复核那些逐行结论是否仍成立，并在会签单里说明。
1.4 数据层项与降级项（不改底座代码）
| # | 触碰项 | 类型 | 做法 |
|---|---|---|---|
| D-a | agent_negative_word 种子（C-05） |
数据层（零代码） | 新增三类词（收益比较 / 稀缺性 / 费率误导）。三条硬约束：① applicable_agents JSON 数组非空且含客服 Agent（空数组＝失败关闭跳过，规则永不生效）；② 不得改写既有 11 行 word_pattern；③ 按承诺性短语收录而非形容词（否则「高收益伴随高风险」这类风险提示会被一并拦下） |
| D-b | agent_reply_template 两条话术（B-05 数据侧） |
数据层 | 热线改定值；须保持 status='active' + 审核字段非空，否则回退兜底话术 |
| D-c | knowledge/ 语料 + 分块产物（B-01~B-04） |
数据层 | 见批次 B；改内容不改结构 |
| D-1 | D-07 降级 | 不改底座 | 不碰语料写入器的字段默认值 —— 它会同时影响多个写入方，而本期不新增 registered 内容，风险远大于收益。改为：B-01 门禁要求「每块 visibility 必须显式声明」+ 文档登记「API 入库路径的档位默认值问题本期不修」 |
| D-2 | D-04 备选乙 | 不改底座 | 仅在会签不受理时启用：业务层对工具返回的档位做后置过滤 + 文档登记。明确标注为降级——违反「检索层硬隔离、不依赖上层自觉」，仅作过渡 |
1.5 底座零改动清单（v5.2 已修订）
app/service/agent/factory.py、app/service/agent/authorizer.py（除 G-02 落地时）、app/core/memory_scope.py、app/core/knowledge_schema.py、app/core/knowledge_contracts.py、app/infrastructure/**、app/model/**、alembic/**、tools/seed_test_rbac.py、docs/00 基线、check_suitability / query_customer_profile / query_fund_quote 的实现、产品数据底座全部文件（见 §5 说明）、app/core/customer_service_rules.py（属客服业务层）。
⚠️ v5.2 修订：原清单中的
app/api/**、app/worker/**、app/service/agent/base.py已移出——由批次 G 触碰（§1.3）。
2. 怎么用这份看板
| 用法 | 说明 |
|---|---|
| 状态标记 | [ ] 未开始 / [x] 完成 / 🔴 高风险或带会签 / ⏸ 挂起 |
| 开工顺序 | 按 §6.1 关键路径；同类文件的任务不要拆成多次提交（测试彼此交叠，拆开会导致反复红） |
| 完成判定 | [x] 表示 DoD 全部满足且「验证」列已执行；未跑验证不算完成 |
| 会签项 | 见 §1.1 / §1.3；未获会签不得开工，未受理则走 §1.4 的降级并在文档中标注 |
| 与需求对齐 | 每个批次末尾的「交付判据」直接对应《需求文档》§2.2 的验收标准 |
3. 决策落位索引（19 项决策 → 任务）
| 决策 | 落到哪 |
|---|---|
| 1 底座不可修改的范围 | A-09 / A-10（白名单与会签单）→ §1 |
| 2 / 3 / 4 热线、域名、服务时间 | B-02 / B-05 |
| 5 工单 priority | E-01 |
| 6 建单白名单 | E-01 |
| 7 访客主体口径（零 DDL） | D-06 / F-01 |
| 8 收益比较类规则 | C-05（数据层）+ C-09（访客侧） |
| 9 输出侧豁免线索 | C-04（会签） |
10 registered 档位保留为空 |
D-01（取值域保留）+ E-07（挂起） |
| 11 知识与数据库以仓库现状为准 | P-2 |
| 12 新增两个知识源 | B-02 ⑤ |
| 13 产品证据链 | F-06（甲） |
| 14 适当性不匹配告知 | E-04 |
| 15 测试策略 | P-3 |
| 16 / 19 文档回写与死代码登记 | F-05 |
| 17 演示前自检 | A-05 / F-04 |
| 18 上游文档锚点修复 | F-07 |
| （新）访客与角色分离 | 批次 G（需求文档 §1.8） |
（新）五出口 E1—E5 |
批次 H 的 H-01~H-04（D3.6 §3；DEC-I1 已采纳） |
| （新）档位分区隔离 | H-05（D2.4 v1.3 §7.2.1；DEC-I6 已定） |
| （新）评测金标门禁 | H-06（D3.7；DEC-I7 已定） |
| （新）访客档计算型分项开放 | H-02（D3.6 §9.1；DEC-I8 已定） |
4. 需求覆盖矩阵
| 需求域 | 任务 |
|---|---|
| 域 A 对话接入与意图识别 | C-02 / C-03 / E-02 / E-05 |
| 域 B RAG 知识检索 | B-01 |
| 域 C 会话记忆 | D-06 / F-01 |
| 域 D 合规与安全 | C-01~C-06 / C-09 |
| 域 E 转人工与服务闭环 | E-01 / E-03 / E-04 / H-04 |
| 域 F 跨 Agent 协作 | 降级（见 §8 风险 8；优先级最低） |
| 域 G 访客能力与双主体 | D-04 / D-06 / C-09 / E-02 / 批次 G 全部 |
| 域 H 智能增强与可验收性（v5.3 新增） | 批次 H 全部（H-01~H-06） |
| 非功能（NFR） | A-02（基线）/ D-03（性能）/ C-06（合规）/ E-08（红线） |
5. 执行看板（57 项）
⚠️ 本节表格里的
[ ]/[x]勾选框【长期未维护】，不要拿它判断进度。🔁 2026-09-19W10已按v6.x段做了一次复核刷新（A-09/A-10/D-04/E-08/F-01/F-05/F-07/G-01/H-05/H-06由[ ]改[x]）；但刷新仍不完整，勾选框只能当参考。 真实状态一律以文档顶部的v6.x修订段为准（每个v6.x段末尾都有「看板状态更新」一行）。本节保留原始 57 项的任务定义与 DoD，作为范围与判据的唯一出处。
批次 A · 冻结与准备（10 项，立即开动，不依赖任何前置）
批次目标：把「当前是什么样」钉死，后续任何「红了」都能区分是我改坏的还是本来就有的。
| ID | 任务 | 落点 | DoD | 验证 | 风险 |
|---|---|---|---|---|---|
[ ] A-01 |
安全用例集基线复现 | 红队与业务评测集 | 逐条记录当前通过/失败；改为「只登记预期、不跑实测」（被测对象已不存在），实测后移至 C-06 之后 | 脚本 | LOW |
[ ] A-02 |
门禁数字基线 | 仓库根 | 按 N-14 跑 5 项并记录原始输出 + 日期 + 解释器路径 + SQLAlchemy 补丁版；⚠️ 跑验收前先停 Worker | 脚本 | LOW |
[ ] A-03 |
配置与环境快照 | 发布配置 / 向量库 / 向量化端点 | ① active 版本 id + 条数 + 白名单全文（须同时含客户侧与游客侧两个知识工具——缺后者游客线全线失败，见 N-7）；② 三集合字段名 + 行数（两套命名都要确认）；③ 向量化模型名 + 维度 | 脚本 | LOW |
[ ] 🔴 A-04 |
业务一致性三查基线 | 全仓 grep / 语料分块产物 / 前端链接表 | 四份清单：① 品牌名出现位置与数量；② 含占位符的块号列表；③ 语料提到的界面名 vs 前端链接表的差集；④ 旧热线号码在 app/ tests/ tools/ knowledge/ 的全部位置（B-05 的对照基线） |
脚本 | LOW |
[ ] A-05 |
演示前检查清单固化 | 演示流程文档同款 | 五项：容器运行时 → 向量库可连 → Worker 在跑 → 行情未过期 → 本地向量库开关为空。产物是文档；执行在 F-04 | 文档 | LOW |
[ ] A-06 |
分支与 PR 策略 | 主开发分支 → 重构分支 | 分支建立；约定「每批次一个 PR 回主干」；底座会签项单独一个 PR（便于 owner 只审那一份 diff）；门禁口径确认 | — | LOW |
[ ] 🔴 A-07 |
访客链路可用性实测 | 访客令牌 → 受理 → 游客侧知识工具 | 实跑一次访客请求，确认：① 游客侧工具在白名单内、不抛权限异常；② 访客意图白名单生效；③ 记录访客 context.user_id 形态（须为数字串，否则 D-06 的前提失效）；④ 记录「哪些日志能区分『配置错』与『正常引导登录』」 |
脚本 + 手工 | 中 |
[ ] A-08 |
前端约束与配合点复核 | 前端约束文档 / 客服挂件 / 站内壳层 | 产出「需前端配合项清单」：至少核对 ① 访客点转人工的既有行为；② 登录引导话术是否需要组件；③ 界面名以站内链接表为准；④ 热线与域名若出现在前端文案里同步改。结论可以是 0 项，但必须是核对后的 0 项 | 文档 + 手工 | LOW |
[x] 🔴 A-09 |
《可改文件白名单》落文 | docs/ 新增纪律凭据 |
四类：① 纯新增；② 允许修改（客服业务层）；③ 提案后由底座方修改——精确为 §1.1 的 6 文件 8 处 + §1.3 的 4 个文件，每项写明为什么属公共缺陷而非客服私需；④ 禁止修改（§1.5 全清单 + 白名单外的一切）。并附「本次零 DDL」声明与表结构基线 | 文档 | LOW |
[x] 🔴 A-10 |
底座会签申请单落文 | docs/ 新增会签依据（附录B 即模板） |
对组 1 六处 + 组 2 四处逐项写清六件事：改什么 / 为什么是公共缺陷 / 最小化边界 / 规范依据 / 影响面 / 降级方案。组 1 与组 2 各一份（在 A-09 之后执行） | 文档 | LOW |
批次 A 交付判据：10 份基线产物齐备；A-04 四份清单已提交；A-07 实测通过；A-09 白名单与 A-10 两份会签申请单已落文并提交底座方。
批次 B · 语料与话术（5 项，串行，只重跑一次灌库）
⚠️ 顺序不可调：B-01 门禁 → B-02 改语料 → B-05 热线定值 → B-03 话术 → B-04 重跑 + 三查。 🔴 B-05 含 1 处底座改动（组 1 第 5 项）——须会签；业务侧与数据层可自主执行。
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[ ] 🔴 B-01 |
语料入库门禁（四查） | 分块构建脚本 | 四条件任一不满足即中止写入并报出块号：① 含占位符；② 出现品牌白名单以外的公司名；③ 源文件/章节落在禁止类目；④ 每块的 visibility 必须显式声明，缺省即拒绝写入（把「默认 public」的 fail-open 挡在门禁这一侧） |
单测 | A-04 | LOW |
[ ] 🔴 B-02 |
语料一次性修正 | knowledge/ 下源文件 + 源清单 |
① 品牌名与域名统一；② 热线与服务时间统一（涉及位置已定位 4 处）；③ 界面名与投诉入口与前端一致；④ 高净值服务规范「各层级专属权益」整章下线；⑤ 新增两个知识源纳入源清单，入库前逐块检查无收益比较 / 稀缺性表述；（v6.3 DoD 增补 · PROD-012 教训 · 不新增任务号）还须无投资建议类内容 —— 配置比例 / 收益目标或区间 / 指向性推荐，判据复用 customer_service_rules.visitor_advice_violation()（已实现 + 有单测） |
脚本 | B-01 | LOW |
[ ] B-03 |
界面指代修正 | 客服规则文件（业务层）+ 对应测试 | 按数据类型分别指向实际存在的页面；同步改被锁死的断言；新增断言：话术里的页面名必须存在于站内链接表 | 单测 | A-04 | LOW |
[ ] B-04 |
🔴 重跑灌库 + 三查验收（唯一一次） | 分块构建 → 载入向量库 | ① 分块产物 0 占位符、0 旧品牌、0 旧域名；② 已下线条目不再存在；③ 新增条目已入库且抽查 5 块无收益比较类表述；④ 检索自检 7 个用例全过；⑤ 公开问题召回量与 A-04 基线一致；⑥ 每块 visibility 字段都在 |
脚本 | B-02、B-05 | 中 |
[ ] B-05 |
热线与服务时间单点化 | 见右栏五组落点 | 真源已在业务层规则文件 → 要清的是五组：① 〔业务层〕 真源改定值（引用它的多条话术自动生效）；② 〔需会签〕 组 1 第 5 项（删旧副本 + 死分支）；③ 〔数据层〕 两条话术模板改值（保持 active + 审核字段非空）；④ 〔测试〕 相等断言与内联占位符同步；⑤ 〔前端〕 按 A-08 结论同步。 验收： app/ tests/ tools/ knowledge/ 内 grep 旧号码 = 0、grep 占位符 = 0；docs/** 历史记载不动（由 F-05 回写） |
单测 + 脚本 | A-03、A-04 | LOW |
批次 B 交付判据：客户可见的跨层不一致一次清干净（品牌名、热线、界面指代、投诉入口、违规内容全部一致）。
批次 C · 规则重构与安全（9 项，一次定稿关键词表，一次双向验证）
⚠️ 本批次集中在客服规则文件（业务层）+ 合规上下文（底座 1 处会签）+ 数据层，不要拆成多次提交（测试彼此交叠）。 ⚠️ 删除类动作（C-07）必须在 C-06 验证通过之后。 📌 本批次没有 C-08——原 C-08（删兼容桩）已并进 C-07。
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[x] C-01 |
拆输入/输出两套常量 | 客服规则文件（业务层） | ① 不动输入侧零容忍集的名字与 11 条内容（其唯一消费方是输入侧路由，改名是语义错误且会破坏相等断言）；② 新增承诺词表与句式表，由输入侧判定一并消费 | 单测 | A-02 | 中 |
[x] C-02 |
输入侧改句式判定 | 同上 | ① 「收益率 + 问值」→ 拦；「+ 问含义」→ 放行；② 「安全 + 保证/承诺/一定」→ 拦；单独出现 → 放行；③ 保留原「收益 + 数字」句式不动 | 单测 | C-01 | 中 |
[x] 🔴 C-03 |
输入侧补安全缺口 | 同上 | ① 移植提示词注入拦截 8 条，插在零容忍之后、合规拦截之前；② 补「推荐」「收益最高」「纠纷」；③ 补裸词账户问法（覆盖「我持仓有多少钱」这类不含完整短语的问法）；④ 保留闲聊词表不动（轮次机制依赖） | 单测 | C-01 | 中高 |
[x] 🔴 C-04 |
输出侧补豁免线索〔需会签·组 1 第 4 项〕 | app/core/compliance_context.py |
短否定式不在豁免线索覆盖内 → 两条 FAQ 答案会被整条替换（对所有 Agent 同理）。DoD：① 豁免线索补多字短否定式（不保本 / 不保收益 / 非保本 / 并非保本 / 不确保 / 不担保）；② 否定线索与指标名白名单两者都做且同句生效。最小化边界：不触碰零容忍集 11 条、治理层硬模式 5 条、正则与窗口常量 |
单测 | — | 中高 |
[x] 🔴 C-05 |
输出侧补收益比较类规则〔数据层·零代码〕 | 禁用词表种子数据 + 口径说明文档 | 不改任何 .py。三条硬约束见 §1.4 D-a。仅三类，明确不纳入风险形容词。补完须跑种子对账测试。✅ v5.9 已落地（甲案）：14 条已落库，verify() 复查门控与三类齐备；行为验证归 C-06 |
集成测试 | — | 中 |
[x] C-06 |
双向验证（本批次唯一放行闸门） | 红队集 + 规则/合规单测 | 方向 A（放开）：概念题可答；方向 B（收紧）：5 条诱导性问法仍拒答；方向 C（访客）：访客问「推荐一只基金」→ 不产生推介措辞；方向 D（反例守卫）：不保本→不判违规；保本→判违规；严禁承诺保本。但这只基金保本→仍判违规（不得跨句）；红队用例与 A-01 基线逐条对比，只允许更严 |
单测 + 脚本 | C-01~C-05、C-09 | 中高 |
[x] C-07 |
删除一期确定性路由 + 兼容桩 | 一期路由文件、兼容桩文件、相关测试 | ① 删 classify()、路由返回类、6 组只服务它的关键词常量；必须保留闲聊词表（轮次机制在用）；② 删除兼容桩，import 指向正确路径；③ 一期词表原样留痕到 docs/（不要只留在 git 历史）；④ 全量单测绿 |
单测 | C-06 | 中 |
[x] 🔴 C-09 |
访客侧推介边界 | 客服规则文件 / 客服 Agent / 合规上下文（第三项的改动归入 C-04 的会签） | 这是 MVP 第 1 步「无投资建议类内容」的唯一落点。DoD：① 输入侧识别访客的推介请求句式 → 返回「不提供投资建议」的边界话术 + 可答范围说明；② 输出侧按主体分化——访客侧禁止「推荐」「适合您」「建议购买」及排序性表述；客户侧不受此限（客户侧风险是承诺收益，二者不能共用一套规则）；③ 客户侧行为不变（回归验证） | 单测 | C-01 | 中高 |
[x] C-10 |
来源引用定向落地或降级 | 〔甲〕工具执行器 + 治理层（需会签·§1.2）；〔乙〕文档 + 护栏断言 | （甲） 由底座方实现：登记本次 run 可引用的文档标识、治理层放行知识来源、知识出口返回引用。★ 必须由底座方实现（N-13 明示来源引用是基座职责）。（乙·降级） ① 文档显式标注「本期不向客户展示来源引用」；② 加护栏断言：禁止从知识出口调用死代码引用函数（误启用会让整个 run 失败）；③ 可追溯性由审计承接。✅ v6.6 已收口（乙 · 降级）：_references() 降级为「保留待用的死代码」（docstring 写明闸门行号 / S-8 / 审计承接 / 启用须会签），函数体原样保留、零调用点；护栏 A（AST 守无调用点 + 定义仍在位）与护栏 B（knowledge 来源必被 ForbiddenAgentError 拒）成对落地；口径回写 7 处（含两处验收残留）；D2.2 EOL 复原为 CRLF；证据 20260919-t2k-c10-source-reference-downgrade.json |
单测 | C-06 | 中 |
批次 C 交付判据：① 概念题可答；② 诱导性问法仍拒答；③ 访客问「推荐一只」不产生推介；④ 注入拦截就位；⑤ 反例守卫全绿；⑥ 全量单测 0 failed。
批次 D · 架构护栏（7 项，为「加档位 / 加身份」备前置）
🔴 整批属底座公共件改动，须 A-10 组 1 会签通过后才能开工（P-5 / S-9）。 明确否决「在客服模块内新建检索实现」——违反 N-2/N-4/N-6，且会形成两条检索路径，其中一条必然漏掉可见性过滤。 不阻塞整体进度：A/B/C 可并行推进，只有本批次在等会签。
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[ ] D-01 |
检索签名 fail-closed〔需会签·组 1 第 1 项〕 | 检索服务 | include_internal: bool = False → tiers: frozenset[str]（必填、无默认值）；非法值/缺失 → 归 {"public"}；取值域保留 {"public","registered"}；所有调用点同步。★ 落点收窄：不改检索输入契约——档位由身份推导（工具执行器已把上下文传给 handler），输入模型保持 extra="forbid" 不变（N-11）。并核对：未接入的第二条检索实现（有单测、无生产调用方，且不做可见性过滤）——本期只登记不改造，但必须在 F-05 的待清理清单里点名 |
单测 | A-03 | 中 |
[ ] 🔴 D-02 |
按集合逐个拼过滤表达式〔需会签·组 1 第 1 项〕 | 检索服务（过滤器 / 主检索 / 行解析） | ① 表达式按集合逐个拼（filter=expression if schema.has("visibility") else None）；② 修正与实现不符的注释（它声称「不带该字段的集合由各自调用处跳过拼接」，但调用处并未跳过）；③ 行解析的 visibility or "public" → 缺字段时不再回落 public（不可判定不得冒充公开）；④ 补「因缺字段而跳过过滤」的独立计数，使「不可判定」不再与「正常」混在一个降级标记里。替身测试须覆盖两种情形：Ⅰ 部分集合有 / 部分没有该字段；Ⅱ 字段名不同（两套环境的既有差异，N-8） |
单测 | D-01 | 中 |
[ ] D-03 |
分区裁剪取回口径 + 「过滤后为空」独立指标（v2.5 取消 over-fetch；隔离机制并入 H-05） |
同上 | 分区裁剪后「TopK 被不可见条目占满 / 过滤后为空」在结构上不发生（见 D2.4 §7.2.1）；本任务保留取回口径的实测复核与「过滤后为空」独立计数 |
单测 + 指标 | D-01、H-05 |
LOW |
[x] D-04 |
档位判定纯函数 + handler 内取身份〔需会签·组 1 第 3 项〕 | 知识工具 | 删除 del context；档位由身份推导（与既有访客口径同源，未知 → {"public"}，失败关闭）；不新增输入字段（零契约变更）；不改工具名/权限码/角色/超时（N-3）。⚠️ 必须调用档位推导模块（G-03 的产物），不得自行判身份字段（S-11） |
单测 | D-01、G-03 | LOW |
[ ] D-05 |
缓存键含档位 | 检索 / 向量化缓存 | 构造「客户查过 → 访客再查」用例，断言不命中缓存 | 单测 | D-04 | LOW |
[ ] D-06 |
访客主体口径统一〔需会签·组 1第 6 项〕 | 受理服务 + 持久化服务 | 不新增访客标识、零 DDL。访客消息的 customer_id 为 NULL；「customer_id IS NULL = 访客」成为唯一判据，与工单侧一致；访客在审计侧以会话标识留痕。★ 边界：会话表 / 幂等表 / 运行表的三列均 NOT NULL → 保持现状（只改消息表）；既有会话归属校验口径不变 |
单测 | A-02、A-07 | 低–中 |
[ ] D-07 |
API 入库路径的档位（已降级） | 不碰语料写入器；落点为 B-01 门禁 + 文档登记 | ★ 降级方案：字段默认值不改——它同时影响多个写入方，而本期不新增 registered 内容，风险远大于收益。DoD：① B-01 增加「visibility 必须显式声明」；② 文档登记「API 入库路径的档位默认值问题本期不修，属已知未修项」；③ 若将来启用 registered 内容，本项必须重新评估并走会签 |
文档 + 单测 | B-01 | 低（原「中」下调） |
批次 D 交付判据：① 访客检索 registered 返回空、客户同期正常；② 公开问题召回量与 A-04 基线一致；③ 两类替身测试通过；④ 「缺该字段的集合」不再污染降级标记（独立计数可证）。
批次 E · 业务闭环与出口（8 项，含 1 项挂起）
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[ ] 🔴 E-01 |
工单建单条件 + priority + reason_code 枚举化〔需会签·组 1 第 7 项〕 |
持久化服务（底座）+ 客服 Agent（业务层）+ 规则文件（业务层） | ① 建单白名单（必须限定客服 Agent，否则会改其它 Agent 的建单行为）：安全风险 / 客户主动要人工 / 要建议类 建单；知识未命中 / 置信度不足 / 检索降级 / 画像查询失败 不建单（仅留审计 + 未命中指标）——修正当前「答不上来也建单」；② priority 映射（字段已存在，零 DDL）：安全风险 → P0；投诉 → P1；要建议 → P1；主动要人工 → P2（当前恒为默认值，队列索引白建）；③ reason_code 枚举化（当前多套词汇混入同一列，含中文自由文本）；④ 不改函数签名、不改表结构 |
单测 + 集成 | C-03 | 中 |
[ ] E-02 |
auth_required 运行时意图 |
客服 Agent（业务层） | 复用既有登录引导出口——把触发面扩到「账户 / 持仓 / 收益 / 工单 / 风评 / 密码类问法」。不动声明意图、不重发发布配置；反例（主语为「我」但内容属公开知识）不触发。并补：登录引导须按原因区分日志/指标，使「配置错误」与「正常引导登录」可被区分 | 单测 | D-04 | LOW |
[ ] E-03 |
工单可见方落文（v5.2 修订） | docs（无需新增端点/权限码，N-10） |
⚠️ 原表述「投顾侧可见」已作废（投顾模块已整体清除）。改为：管理面可见 + 可指派给员工账号；assigned_to（既有外键）承载指派；专属队列与自动分派归未来扩展 |
文档 | E-01 | LOW |
[ ] E-04 |
适当性「不匹配告知 + 主动确认」 | 客服 Agent 适当性分支 | 提示超出风险承受能力 + 主动确认路径 + 留痕落消息表与审计表（零 DDL）；与三条红线逐条对照（尤其「先风险揭示、后客户确认」的顺序） | 单测 | — | 中 |
[ ] E-05 |
出口主题反解收口 | 客服 Agent 出口结构 | 出口显式声明主题，不再从回答文本反解（该机制已多次出错）；主题矩阵测试全绿且不再需要新增格式分支 | 单测 | — | 中 |
[ ] E-06 |
长答案截断提示 | 客服 Agent 出口 | 当前静默截断（高频长块会被截）→ 截断处加提示，或对超长块走「整节 + 可追问」 | 单测 | — | LOW |
[ ] ⏸️ E-07 |
registered 档位内容标注（挂起，不执行） |
分块构建脚本的源清单 | 暂不执行：唯一候选已因合规问题下线，其余属 MVP 明确不做的卡级体系。保留 registered 为「已支持但为空」的档位，等卡级体系进范围再启用 |
— | D-01 | — |
[x] 🔴 E-08 |
三条红线客服侧对照验证 | 客服 Agent / 规则文件 / docs/ 留痕 |
逐条验证并留痕：① 风险等级唯一来源——不给等级结论、不引导「重做测评以提级」；② 先揭示后确认——不得代客户确认；③ 不生成交易指令——不输出可执行交易要素，只做跳转引导。发现的缺口按「补拦截」而非「补话术」处理 | 单测 + 手工 | E-04 | 中 |
📌 E-02 / E-04 / E-05 / E-06 / E-08 同文件，建议并入同一 PR，避免对同一文件多次改动与多次测试。
批次 F · 演示与收口（7 项）
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[x] F-01 |
MySQL 回退路径主体隔离〔需会签·组 1 第 6 项〕 | 受理服务的历史读取 | 增加主体过滤；主体判据必须调用记忆范围模块，不得自写一套（N-9）；构造「两主体同会话标识」用例断言读不到对方历史（当前缓存侧有隔离，回退侧没有）。 ⚠️ 禁止从备份恢复旧实现——那份正是缺陷本体（只按会话标识取历史、跨主体可读），必须在新链路重写 |
单测 | D-06 | 中 |
[ ] F-02 |
访客专项端到端验证 | 手工清单 + 脚本 | 五条：越权（访客问「我的持仓」）、限流、会话隔离、登录后上下文继承、推荐类请求不产生投资建议 | 手工 | D-04、D-06、E-02、C-09 | LOW |
[ ] 🔴 F-03 |
MVP 演示脚本与彩排（v5.2 修订） | 演示流程文档同款 | ⚠️ 原「九步 / 三条线」已作废（投顾已清除）→ 改为 两条业务线（游客线 + 客服线） 的演示脚本：游客线含「浏览公开产品且无投资建议类内容」；客服线含「明确说明无权限 + 引导至正确页面」；含排障表与账号速查 | 手工 | B-04、C-06、E-01、E-03、F-04、F-06 | 中 |
[ ] F-04 |
演示前五项自检 + 账号速查 | A-05 的清单 + 种子脚本 | ① 五项自检全通过；② 用现有种子脚本生成客户 / 访客 / 管理员三类账号，产出「账号速查表」并实测可登录（可复现，环境重置后能重建） | 手工 | A-05、A-07 | LOW |
[x] F-05 |
文档回写 | 四份文档 + docs/** |
重构完成后一次性回写：① 全部判据更正与待确认项定论；② 原会话归档变更流程作废说明（目标表不存在）；③ registered 空转的事实；④ 决策 1~19 的定案 + E-03 的工单可见方表述；⑤ 死代码待清理清单（含未接入的第二条检索实现、前端版本号机制、死代码引用函数、API 入库默认档位），并注明「本期不删」；⑥ 修文档自身债：功能域数、来源引用可达性结论；⑦ 修过期注释债：治理层「没有否定式豁免」的注释已过期（实际有）、检索服务注释与实现不符（D-02 一并修）；⑧ 口径冲突回写：docs/演示用/* 与验收标准文档把旧热线记为「真实号码要求」——与决策冲突，须改为新号码并标注决策来源 |
文档 | 全部 | LOW |
[ ] F-06 |
🔴 产品证据链（决策 13 · 甲） | 产品治理同步脚本 | 立即 --dry-run（不依赖任何代码改动）：① 确认既有产品已在库；② dry-run 验证抓取与解析；③ 正式执行；④ 演示相应步骤候选数 > 0。⚠️ v5.2 说明：该能力位于产品数据底座，未随投顾模块清除而删除（执行报告 §3 已列明保留）；同步脚本沿用。降级阶梯：自动 → 人工导 2–3 只真实证据 → 演示时说明。不做编造（来源链接列非空，编造会让以后分不清真假） |
脚本 + 手工 | 无需代码前置 | 中 |
[x] F-07 |
上游文档失效目录锚点修复 | 上游需求文档 | 24 个 href 对齐正文 id（只改 href，不动正文 id，不影响任何引用）；点击目录全部可跳转 |
脚本 | — | LOW |
可提前：F-06 与 A 批次同时启动（不依赖代码，越早跑越有余量走降级）。
批次 G · 访客与鉴权（5 项：4 可执行 + 1 挂起，独立会签组）
为什么单独成批：见 §1.3。这是本次唯一一处「主动扩张底座接触面」——必须单独一列、单独会签、单独一个 PR。 定案前置：必须先跑 G-00。没有可运行的测试套件，改鉴权入口与 Worker 执行路径就等于盲改。
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[ ] 🔴 G-00 |
测试环境就位（门禁可运行） | 依赖声明 / venv | 按 N-14 跑通单测、静态检查、类型检查，记录基线数字；须实测能 import 依赖，不能只看版本号 | 脚本 | — | LOW |
[x] 🔴 G-01 |
访客权威单点化（方案乙） | 新增 app/core/actor.py；改 app/core/security.py、app/worker/runtime.py |
① 访客三元组（角色 / 权限 / 数据范围）只有一个构造来源；② 两处均调用它；③ 对外行为零变化（问答、限流、令牌有效期全部不变）；④ 新增接缝单测：同一输入下两侧产出必须相等（这正是当前缺失的测试） | 单测 + 端到端访客问答 | G-00 | 中 |
[ ] 🔴 G-01b |
判定口径单点化 | 改鉴权依赖、Agent 基类、Worker、受理服务 | 6 处访客判断全部改走统一谓词；⚠️ Agent 基类那处的「位置与层级」不得变（仍在基类、仍不依赖 Agent 声明位） | 单测 + 「访客五查」（需求文档 §2.3） | G-01 | 中 |
[ ] ⏸️ G-02（挂起） |
身份轴（方案甲） | 上下文契约、授权器、工具执行器、装配入口、actor.py |
角色回归纯 RBAC（访客角色为空）；20 余处 Agent 与工具的角色声明中的访客项迁至身份轴声明 | 「访客五查」+ 全部既有 Agent 的角色回归 | G-01b、MVP 演示跑通 | 高 |
[x] 🔴 G-03 |
档位推导单点化（承接 D-04） | 新增 app/core/knowledge_tier.py |
档位由统一谓词推导，不由工具层自行判身份字段；⇒ 将来 G-02 落地时只需改一个文件 | 单测 + 档位双向验证（见 D 批次） | G-01b、D-01 | LOW |
批次 G 交付判据：G-01 后访客链路端到端行为与动手前逐项一致（含令牌有效期、限流阈值、身份投影）；grep -rn '"visitor" in context.roles' app/ 的结果只出现在 actor.py 内部的兼容分支（G-01b 后）；G-02 挂起待 MVP 演示通过。
⚠️ 与 D 批次的串行关系（S-11）：
G-01b → G-03 → D-04。D-04不得自行判断身份字段，必须调用档位推导模块。 ⚠️ 受理服务成为三处交叉点：G-01b、D-06、F-01——执行顺序固定为 G-01b → D-06 → F-01。
批次 H · 智能增强（6 项，本次整改的正面修复批）
本批解决什么：答辩反馈「客服 Agent 不智能、很多问题强制转人工」。根因不是知识库或模型，而是决策链上只有两个出口（命中够分就原文直返 / 其余一律转人工）——旧实现里 10 处失败方向全部指向转人工。本批把出口扩到 5 个。 依据：
开发文档/D3.6-客服Agent智能增强架构建议-2026-09-17.md（§9 八项决策已裁定）、开发文档/D3.7-客服Agent评测金标集与判分规则-2026-09-17.md。 🔴 前置（S0，缺一不可）：D3.7§1 的B-1~B-4——① 重生成knowledge/_chunks.jsonl（现版 2026-09-16，滞后于镜像源，含旧品牌「南方科技」308 行与已下线产品）；② FAQ 镜像补齐至 64 条（现 44 条）并按D6.1.2§四 逐条打档位；③ 档位字段真正进索引（实测 617 块 100% 为public）；④ 两套建表脚本收敛（见H-05）。
| ID | 任务 | 落点 | DoD | 验证 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
[x] 🔴 H-01 |
澄清出口 E1 |
客服 Agent 出口结构 + 意图分类消费点 | ① needs_clarification 真正被消费（当前全仓无消费分支）；② 触发四类条件：置信度 < 0.6 / 跨族并列 / 分数不足且跨族 / 缺主语；③ 一次只问一个问题，给 2—3 个候选；④ 候选必须来自当前主体可见档位，不得暗示不可见条目的存在性；⑤ 同话题上限 2 轮，超限降 E5b；⑥ 同族并列不澄清（走 H-03 合并作答） |
单测 + D3.7 E-01~E-04 |
G-03、D-01 | 中 |
[x] 🔴 H-02 |
计算型出口 E2 |
客服 Agent 新增计算分支 + 知识侧参数位 | ① 参数只取自当前档位可见的结构化参数位；② 纯函数、不调模型；③ 未指定具体产品时只给算法与区间，不给确定结论；④ 访客档按 D3.6 §9.1 分项开放（公开产品费用试算开放；以访客自身为对象的适当性结论与以其资产为参数的试算不开放）；⑤ 取不到参数即降级 E5b，绝不回退到 registered 分区 |
单测 + D3.7 D-01~D-05 |
H-05、D6.2.1 §六 补 public 参数位 |
中 · ⏳ v6.11 进展：参数层已完成（app/core/fund_fee_rules.py，41 条单测）；H-02-D1/H-02-D2 已裁定并落地（语料已重建重灌，628 块 / 分布不变）；H-02b 出口接线已完成（E2a/E2b/E2c，端到端 D-01~D-04 真实检索通过；HTTP 链路待 S-7 启动后复验） |
[x] 🔴 H-03 |
证据约束生成 E4 |
客服 Agent 生成出口 + 证据包契约 | ① 输入为证据包（块 + doc_id + 族标识），不再一律原文直返；② 输出契约 {answer, used_chunk_ids[], confidence, unanswerable_reason}；③ 三条硬约束：只用包内事实与数字 / 不得出现包外数字 / 不推介不承诺不代办；④ 约束同时落在 prompt 与输出校验两处（不得只写 prompt）；⑤ 输出数字一致性校验：无法解析到出处的数字即拦截回退 E5b |
单测 + D3.7 C-01~C-04、零容忍 M-9 |
语料侧 family_id 就位 |
高（引入生成即引入幻觉面） |
[x] 🔴 H-04 |
分级回退 E5 + 转人工白名单收口 |
客服 Agent 出口结构 + 建单白名单 + 规则文件 | ① 回退链 E5a 澄清 → E5b 部分答 + 引导 → E5c 转人工；② 转人工触发收敛为 4 类白名单（显式要求 / P0 反诈 / P1 账户数据 / P2 写操作与争议），删除「连续 2 轮兜底」；③ E5c 须带上下文摘要；④ 回退不得跨档位（与主检索共用档位映射）；⑤ 白名单外发生转人工 = 验收不合格 |
单测 + D3.7 B-01~B-06、M-6 |
H-01、E-01 |
中 |
[x] 🔴 H-05 |
档位分区隔离 + 双 schema 收敛 | 建表 / 灌库脚本 + 检索模块 | ① visibility 作分区键且 NOT NULL（写入侧拒绝空值 = fail-closed）；② 检索按档位分区裁剪；③ 取消 over-fetch ×3（分区后「TopK 被不可见条目占满」不再存在）；④ 两套建表脚本收敛为一套（tools/setup_milvus_knowledge_collections.py 无 visibility vs tools/load_knowledge_milvus.py 有，同名集合两套字段）；⑤ 档位值变更 = 建分区，属运维动作，纳入 §10.3 SOP |
双向验证（访客见空 / 客户正常）+ 启动自检 | 会签（底座公共件）、B-04 |
高 |
[x] 🔴 H-06 |
评测门禁落地 | 评测脚本 + 基线记录 | ① D3.7 46 条金标跑通；② 四项零容忍（禁忌违反 / 档位越权 / 无出处数字 / 误拒）= 0；③ 出口准确率 ≥ 85%、难例命中率 ≥ 75%、转人工率 ≤ 15%；④ 如实记录修复前基线（预期 ≤ 56%）；⑤ 结果回填 D3.7 §6 |
脚本 + 报告 | H-01~H-05 |
低 |
批次 H 交付判据：D3.7 §5 判分规则下 46 条金标达标，且四项零容忍全为 0；H-01 单独可演示（答辩现场「多问一句就能答」的题不再转人工）。
📌 裁剪顺序（工期紧张时）：
H-01→H-04→H-02→H-06→H-03→H-05。H-01是单点收益最大的一项，不得首先砍掉；H-05属安全增强，可与会签窗口并行。
6. 关键路径、串行约束与并行通道
6.1 关键路径（12 步 + 1 个会签等待窗口）
[会签窗口：A-10 提交 → 底座方受理 组1 六处 + 组2 四处] ──┐
↓
A-02 → A-07 → G-01 → G-01b → D-01 → D-02 → G-03 → D-04
→ D-06 → E-01 → E-03 → F-03 ──→ 演示跑通
↑
B-01 → B-02 → B-05 → B-04 ───┤
│
C-01 → C-03 → C-09 → C-06 ───┘
最长链 = 12 步（含 G 链）。会签往返不影响步数，但是唯一的外部队列——越早提交越早有回音，故 A-10 排在 A 批次内优先执行。
并行条件：C 组可与 D 组并行（改动文件不重叠）。⚠️ 但按 P-4/P-5，两组的「底座公共件」部分均需会签——不能因「并行」而跳过会签。 例外：C-10 会碰工具执行器与治理层，建议排在 D-04 之后，避免与身份口径变更交叉。
6.2 十二条硬串行约束（违反即返工）
| # | 约束 | 违反后果 |
|---|---|---|
| S-1 | B-01 门禁 → B-02 改语料 → B-04 重跑 | 顺序颠倒会把问题再灌一遍 |
| S-2 | B-05 热线定值 → B-02 填值 | 语料里会填进旧的/占位的号码 |
| S-3 | C-06 验证 → C-07 删除 | 直接删一期路由 = 提示词注入拦截消失（唯一带安全性的删除） |
| S-4 | D-02 修过滤表达式 → 任何集合加该字段 / 改字段名 | 缺字段的集合被同一表达式打挂 → 被吞成 failure → 降级 → 客服全员「引导人工」且不报错 |
| S-5 | D-01 fail-closed → D-04 传身份 | 身份传进没有 fail-closed 语义的签名 = 把「记得过滤」交回调用方 |
| S-6 | D-03 与 D-01/D-02 同批 | ⚠️ v2.5 口径修正：原「只有过滤没有 over-fetch → 过滤后 TopK 不足」的理由已失效（over-fetch ×3 取消、改集合内分区裁剪，见 D2.2 FR-CS-033）；本约束保留的是D-01 / D-02 / D-03 三件必须同批落地，不再是「必须 over-fetch」 |
| S-7 | 集合 schema 变更后必须重启 API + Worker | 检索服务是进程级单例，schema 缓存永不失效 |
| S-8 | 禁止在知识出口启用未完成的来源引用链路（除非 C-10 选甲并完成全部三项改动） | 治理层只认 memory/tool 来源 → 返回知识引用会让整个 run 失败 |
| S-9 | 🔴 底座两组未获会签前不得动手（P-5）。业务侧可先行，但不得为「绕过会签」而在业务层重造同一能力 | 绕过 = 形成第二套实现，其中一套必然漏掉隔离 |
| S-10 | 🔴 访客侧开关未做严禁开始 F-02 / F-03 第 1 步 | 服务访客的 Agent 声明缺失 → 游客线永久失效，且失败表现是「请登录」，与设计如此无法区分 |
| S-11 | 🔴 G-00 → G-01 → G-01b → G-03 → D-04 | ① 无测试环境改鉴权链路 = 盲改；② G-01 不做就改 D-04，档位会依赖两份可能不一致的身份定义；③ D-04 若自行判身份字段，则 G-02 落地时必须改两处，分离收益归零 |
| S-12 | 🔴 受理服务三处交叉点顺序固定：G-01b → D-06 → F-01 |
三处同文件不同段，倒序会互相覆盖；且访客主体口径依赖身份判定已单点化 |
6.3 若多人并行：按「文件不相交」切四路
| 通道 | 负责批次 | 独占文件 |
|---|---|---|
| 通道 1 · 语料 | 批次 B 全部 + F-06 | knowledge/*、分块构建脚本、产品同步脚本 |
| 通道 2 · 规则与数据层 | 批次 C 全部 + E-01（业务侧） | core/customer_service_rules.py、禁用词种子 |
| 通道 3 · 检索护栏 | 批次 D 全部 + F-01 | knowledge_search_service.py、knowledge_tool.py、core/knowledge_tier.py |
| 通道 4 · 出口与文档 | 批次 A + E-02/E-04/E-05/E-06/E-08 + F 文档类 | implementations/customer_service.py、docs/* |
| 通道 0 · 底座会签 | 组 1 六处 + 组 2 四处（各自单独一个 PR） | 见 §1.1 与 §1.3 |
⚠️ 三处交叉点需串行：① 受理服务由通道 3（D-06）与通道 4（F-01）先后改，现又加入 G-01b → 顺序固定 G-01b → D-06 → F-01；② 持久化服务只由通道 2（E-01）改；③ 工具执行器仅由 C-10 碰，且排在 D-04 之后。
7. 整体完工判据（12 条）
| # | 判据 | 怎么验 |
|---|---|---|
| 1 | 业务一致性三查全绿 | 语料 0 占位符、0 旧品牌；热线/服务时间代码与语料一致；语料提到的界面名全在站内链接表内 |
| 2 | 安全只增不减 | 红队用例与 A-01 基线逐条对比，无一条变松；新增注入类用例全绿；C-06 方向 D 的反例守卫全绿 |
| 3 | 规则三个方向都对 | 概念题可答 + 诱导性问法仍拒答 + 访客推荐类请求不产生推介 |
| 4 | 护栏生效 | 访客检索 registered 返回空、客户同期正常；公开问题召回量与基线一致；两类替身测试通过；「缺字段的集合」有独立计数、不再污染降级标记 |
| 5 | 访客主体一致 | 消息表访客行 customer_id IS NULL；工单侧同为 NULL；回退路径读不到他人历史（走记忆范围模块） |
| 6 | 工单分类正确 | 「答不上来」不建单；安全风险工单 P0；投诉/要建议 P1；主动要人工 P2；reason_code 为枚举值；其它 Agent 的建单行为未变 |
| 7 | 门禁干净 | 按 N-14：静态检查 0 错、类型检查 0 错、单测 + 契约测 + 集成测 0 failed（绝对用例数会随开发增减，判据是 0 failed） |
| 8 | 演示跑通（v5.2 修订） | 两条业务线（游客线 + 客服线）演示全部可见，含游客线「无投资建议类内容」；原「九步 / 三线」表述随投顾清除作废 |
| 9 | 红线可举证 | E-08 的三条验证结果留痕；适当性不匹配场景可在消息表与审计表中还原「揭示 → 确认」顺序 |
| 10 | 🔴 底座纪律达标 | ① 实际改动文件 ⊆ A-09 白名单；② 两组每一处都有会签记录（或走 §1.4 的降级并文档标注）；③ 零 DDL 证据：表结构与基线一致；④ 未绕过统一鉴权 / 工具 / 合规 / 审计流程（N-2/N-4/N-6） |
| 11 | 🔴 访客与角色已分离（v5.2 新增） | ① 访客三元组只有一个构造来源；② 访客链路端到端行为与动手前逐项一致（令牌有效期 / 限流阈值 / 身份投影 / 记忆不召回）；③ grep -rn '"visitor" in context.roles' app/ 结果为空（判定已全部走单点模块）；④ 档位由推导模块给出，工具层不含身份字段字面量；⑤ 三条不变量逐条可举证 |
| 12 | 🔴 文档一致（v5.2 新增） | 四份交付文档交叉引用无冲突（需求 ↔ 计划 ↔ Todolist ↔ 知识库）；docs/** 历史记载已按 F-05 回写标记 |
| 13 | 🔴 智能增强与金标门禁（v5.3 新增） | D3.7 46 条金标全跑通：出口准确率 ≥ 85%、难例命中率 ≥ 75%、转人工率 ≤ 15%；禁忌违反 / 档位越权 / 无出处数字 / 误拒 四项 = 0。口径：白名单（FR-CS-023）外的「正确地转人工」判不合格；澄清后答对、部分作答 + 引导判合格；修复前基线已如实记录 |
8. 风险登记（重点盯防 8 项）
| 排名 | 任务 | 最高风险点 | 对策 |
|---|---|---|---|
| 1 | 🆕 投顾清除后失去对照组 | 底座改动只剩客服一条回归线，跨模块回归不易暴露 | ① G-00 优先级上调为最前置；② 底座两组改动必须全量跑 §7 判据 7，不得只跑单测；③ 组 2 单独 PR，便于独立回滚 |
| 2 | D-02 过滤器按集合逐个拼 | 改错会让客服全员转人工且不报错 | 先补两类替身测试再改实现；上线后立刻验「公开问题召回量不变」；保留「缺字段跳过」的独立计数 |
| 3 | 🆕 G-01 / G-01b 身份单点化 | 改鉴权入口与 Worker 执行路径，无测试环境时是盲改 | G-00 必须先完成；新增接缝单测；验收方式即「对外行为零变化」 |
| 4 | C-06 四向验证 / C-03 词表取回 | 词表缩水不报错；补偿式修改可能放过真实承诺 | 必须从留痕文档逐条抄；四个方向用例都必须有；反例守卫 |
| 5 | C-09 访客推介边界 | 按主体分化输出规则时可能误伤客户侧（或反之） | 客户侧必须做回归验证；按主体分支而非合并词表 |
| 6 | E-01 建单白名单 | 若不限定 agent_type，会改动其它 Agent 的建单行为 |
DoD 明确「仅对客服 Agent 生效」；把其它 Agent 的既有建单用例纳入回归 |
| 7 | A-07 访客链路实测 | 若游客侧工具未在白名单，全线失败表现为「请登录」 | 实测 + 日志按原因区分（E-02 补）；A-03 快照留白名单全文 |
| 8 | B-04 / F-06 两次连外部服务 | 环境问题伪装成功能缺陷 | 先跑 A-03/A-05 快照与自检；B-04 前停 Worker；F-06 先 dry-run |
📌 原风险 8「跨 Agent 事件」的优先级已下调：其价值依赖跨 Agent 协作场景，而在投顾清除、MVP 只演示两条业务线的现状下，它是优先被裁剪的项（对应 RK-13 的裁剪顺序）。
9. 决策状态
19 项决策已全部定案，落位见 §3；乙类 29 项与甲类 6 项已于 2026-09-18 批复/受理（回填 D1.5 §7，会话登记 D1.6 §4.6）。
| 项 | 状态 |
|---|---|
| 原 §9-3「先重建客服、投顾留到最后（投顾为对照组）」 | ❌ v5.2 作废——投顾已整体清除（见 D4.5-投顾模块清除执行报告-2026-09-17.md）。后果：失去第二条回归业务线 → 见 §8 风险 1 |
| 原 §9-4「热线孤岛立即做」 | ⚠️ 准确含义是「立即提案」：它与组 1 第 5 项是同一处改动，落在治理层（须会签），不独立于会签门 |
| 新建账「访客与角色分离」 | ✅ 已定：方案乙现在做 → 方案甲 MVP 后（批次 G） |
五出口 E1—E5 与金标门禁（v5.3 新增） |
✅ 已定：批次 H。E3（知识直返）为既有能力；E1 澄清 / E2 计算 / E4 生成 / E5 分级回退需新建。不得因工期砍掉 H-01（单点收益最大），裁剪顺序见批次 H 末注 |
| 待确认事项（T-01~T-11） | 见《需求文档》§4.1，开工前须闭环 4 项 |
F-1 档位边界与 DEC-I8 冲突（v6.13 新增） |
✅ 已落地（v6.14） —— 以 DEC-I8 为准改 D3.7 B 组判据：公开档数值可答、registered 档只引导；同批对齐 §5 判分口径与 E-04。零重建 |
F-2 意图标签直通转人工（v6.13 新增） |
✅ 已落地（v6.14） —— 转人工只由「用户显式要求」触发；transfer_human 标签改为「先检索一次、E5b 空答才转」。D-05 实测已正常作答 |
🆕 F-3 E4 误接管（答非所问）（v6.14 新增） |
✅ 已落地（v6.15） —— EVIDENCE_SUBJECT_TERMS（27 个受控主题词）+ 主体相关性闸门插在证据包与置信判定之前，且只在问句点名主题词时启用；B-04 由「答成混合基金整段参数」变为 E5b 引导登录（模型零调用、未泄露 registered） |
| 🆕 乙类 29 项 + 甲类 6 项（v5.4 新增） | ✅ 全部批复（2026-09-18，无一项改写）。关键三项：乙-2 = (a) 只做 P0 保演示（§10 即按此裁剪）；乙-16 = (a) 授权重建（含删旧 Milvus 集合重建）；乙-1 = (b) 维持 public + 回改 D2.4 附录B。零容忍词三层联动见 乙-31/乙-32/乙-33（D1.6 §4.6） |
10. 今日一天执行计划（2026-09-18 · 目标：演示路径跑通）
性质：本节是 57 项在「一天 + 只做 P0 保演示」（
乙-2= (a)，DEC-11已批）前提下的裁剪版执行序。它不是新增范围，只是把既有任务重排进时间盒。 口径：本计划只承诺「演示跑通 + 可举证」，不承诺 57 项完工。未列入本节的项一律「留痕 + 待办」，不得临时插入（临时插入是本计划最大的失败模式）。 前置：解除「先不要开发」口令；两把 key 已写入group_fqcd_jr\.env（含QWEN_EMBEDDING_API_KEY与DASHSCOPE_API_KEY两个变量名 +DEEPSEEK_API_KEY）。
10.1 时间盒（6 段 · 段内顺序不可调）
| 段 | 预算 | 任务（既有 ID） | 产物 | 段末判据 |
|---|---|---|---|---|
| ✅ T0 · 环境与基线（已完成 2026-09-18） | 60′ | G-00（建 venv + 装依赖 + 跑基线）→ A-02（门禁数字基线，先停 Worker）→ A-03（配置/环境快照）→ RBAC 种子重跑 |
venv 可用；5 项门禁原始输出；配置快照含 active 版本 + 白名单全文 + 三集合字段名/行数 + 向量维度实测；三类账号可登录 | 能 import 依赖；维度是一个实数（不再是「未确定」） |
| ✅ T1 · 知识库重建（已完成 2026-09-18 · 客户档被会签阻塞） | 120′ | H-05（visibility 作分区键 + 双 schema 收敛）→ drop 三集合重建 → 重灌（N-07 / 乙-16）→ 重启 API + Worker（S-7）→ 双向验证 |
三集合按 visibility 分区、NOT NULL；617+ 行重灌；最小 registered 样本；两套建表脚本收敛为一套 |
访客见空 ✅ 实测通过；客户正常 ❌ 未通过——knowledge_tool.py 未传 include_internal，登录客户与访客拿到同一档位，registered 25 块对谁都不可见，须会签 D-01/D-02 后才可修；公开问题召回量与 A-03 基线一致 ✅ |
T2 · 判定层（乙-31/乙-32/乙-33） |
120′ | C-01（新增 CONCEPT_QUERY_PATTERNS + PROMISE_INTENT_PATTERNS，ZERO_TOLERANCE_WORDS 退化为检测集）→ C-03（词表逐条从留痕抄回）→ C-04（NEGATION_CUES 补短否定式 + governance.py 分档）→ C-06（四向验证） |
输入侧概念豁免 / 承诺拦截两层；输出侧分档；裸词「安全」共现判定 | 🔴 A-05「什么叫七日年化」不再走拒答（M-10 = 0）；真承诺探针仍被拦（M-7 = 0） |
| T3 · 出口 | 150′ | H-01 澄清 E1 → H-02 计算型 E2 → H-04 分级回退 E5 + 转人工白名单收口 |
三个出口可用；转人工收敛为 4 类白名单；E5c 带上下文摘要 |
白名单外零转人工；同族并列走合并作答而非澄清 |
| T4 · 评测与演示面 | 90′ | H-06 金标评测（46 条）+ F-03 演示脚本彩排 + 乙-26 前端品牌面（P1） |
评测报告（含修复前基线）+ 彩排通过 + 前端品牌干净 | 四项零容忍 = 0；彩排无阻塞 |
| T5 · 收口 | 60′ | F-05 文档回写（最小集）+ A-10 会签申请单（组 1 六处 + 组 2 四处，各一份） |
决策定案回写；会签单已提交 | 四文档口径无冲突；会签单在队列中 |
合计 ≈ 10 h（含缓冲）。若只有 8 h：砍 T4 的 乙-26 与 T5 的 F-05 非关键条目，不得砍 T2（它是「不智能」的正面修复）。
10.2 今日不做（明确留痕，防临时插入）
| 项 | 为何不做 | 处置 |
|---|---|---|
H-03（E4 证据约束生成） |
智能收益最高但风险最高（引入生成即引入幻觉面，D3.6 §8）；一晚搏不起 |
留痕为「已设计待实施」；D3.6 §9 DEC-I2 仍为已采纳，不撤回 |
乙-7 第 4 集合 fin_basic_collection |
游客线内容缺口，演示阶段可绕 | 待办 |
乙-15 重建浮窗 |
前端工作量不可控 | 降级用 tools\portal.py（8101）演示；D2.1 A-08「结论可以是 0 项」按此改。⚠️ 这是评审唯一用眼睛看到的界面——T4 后若有余量，优先补它 |
乙-18 / 乙-19 / 乙-24 / 乙-25 / 乙-27 |
语料校准与品牌/文档治理，不在演示路径上 | 待办（乙-19 须连带更新 DEC-18 措辞） |
| 批次 G 组 2（访客鉴权四文件） | 须会签 + 单独 PR，且 G-00 之后才可动手（S-11） |
今日只提交申请单；乙-5 的落地顺延 |
C-07（一期路由删除） |
S-3 要求 C-06 通过后才可删，且它是唯一带安全性的删除 |
今日保留一期路由，不删 |
E-07 / G-02 |
挂起项 | 不动 |
10.3 今日红线（违反即返工）
| # | 红线 |
|---|---|
| R-1 | S-7：集合 schema 变更后必须重启 API + Worker（检索服务是进程级单例，schema 缓存永不失效） |
| R-2 | S-9：底座两组未获会签前不得动手；业务侧可先行，但不得为绕过会签而在业务层重造同一能力 |
| R-3 | S-3：今日不删一期路由（C-06 未通过时删 = 提示词注入拦截消失） |
| R-4 | S-4/S-5/S-6：H-05 的分区隔离必须与 D-01 fail-closed、D-04 传身份同批；不得只改检索表达式而不传档位 |
| R-5 | S-8：知识出口的来源引用链路未完成时不得启用（治理层只认 memory/tool 来源，返回知识引用会让整个 run 失败） |
| R-6 | 维度必须先实测再重灌（E-3 → N-07）；维度定错 = 636 行作废 = 再重建一次 |
10.4 卡点与降级阶梯
| 卡点 | 降级 |
|---|---|
| 维度实测与既有 636 行不符 | 按实测维度重建（必须）；E-3 必须先于 N-07 |
| Milvus 起不来 | 乙-3 (a) 不成立 → 走 D2.1 D-2 备选乙（业务层后置过滤），并在文档明确标注为降级（违反「检索层硬隔离」） |
| 会签无回音 | 业务侧继续；底座项冻结并留痕（P-5）；不得绕过 |
H-01/H-02 未完成 |
H-04 白名单收口仍必须做——它单独即可证明「不智能」的改善（转人工从 10 条通路收敛为 4 类） |
| 金标 46 条跑不完 | 跑**「出口 + 四项零容忍」子集**，如实标注覆盖率，不得声称全跑通 |
registered 无内容可召回 |
只灌演示所需最小样本；AC-11/A8 双向验证按样本标注，如实说明是机制验证而非内容完备 |
10.5 对既有任务的 DoD 增补（2026-09-18 批复后 · 不新增任务号）
| 任务 | DoD 增补 |
|---|---|
B-02 |
语料检查面增补（PROD-012 教训 · 不新增任务号）：除「收益比较 / 稀缺性」外，新增「无投资建议类内容」= 配置比例 / 收益目标或区间 / 指向性推荐；判据复用 customer_service_rules.visitor_advice_violation()（已实现 + 有单测） |
C-01 |
除原「两套常量」外，新增 CONCEPT_QUERY_PATTERNS（概念豁免层）+ PROMISE_INTENT_PATTERNS（承诺拦截层）；ZERO_TOLERANCE_WORDS 保留原名与 11 条、退化为检测集（不再直接判决）；裸词「安全」改为需与承诺词共现才拦（乙-31 / 乙-33） |
C-04 |
除 NEGATION_CUES 补多字短否定式外，governance.py:332-337 分档：真承诺 → 替换 + 转人工；概念 / 引用 / 否定语境 → 放行；其余 → 替换但 transfer_required=False。属组 1 公共件 ⇒ 须会签（乙-32） |
C-06 |
四向验证新增两向：① A-05「什么叫七日年化」不再走拒答（M-10）；② 真承诺探针仍被拦（M-7） |
H-01 |
澄清判定前先过概念豁免层——概念解释题优先作答，不因零容忍命中而被拦 |
H-04 |
白名单 4 类不变；新增：E5c 触发前必须先过概念豁免判定，避免合规拦截把可答题推向转人工 |
H-05 |
明确「机制优先、内容最小」：分区机制本轮必做；registered 内容只补演示最小样本（乙-8 复查口径） |
附录A · 编号映射
| 本版 | 来源 | 说明 |
|---|---|---|
| A-01~A-10 | v3.0 起沿用 | 无变化 |
| B-01~B-05 | v3.0 起沿用 | 无变化 |
| C-01~C-10 | v3.0 续号 | 无 C-08（原 C-08 已并进 C-07） |
| D-01~D-07 | v3.0 起沿用 | D-07 已降级为「不改底座」 |
| E-01~E-08 | v4.0 起沿用 | E-07 挂起；E-03 已按投顾清除修订 |
| F-01~F-07 | v4.0 起沿用 | F-03 已按投顾清除修订 |
| G-00~G-03 | v5.1 新增 | G-00 环境前置 / G-01 三元组单点化 / G-01b 判定单点化 / G-02 挂起 / G-03 档位推导 |
附录B · 底座会签申请单模板（组 1 与组 2 各填一份）
会签申请 <序号> · <底座文件名>
一、改什么（精确到函数 / 行）
<函数名与行号>：<改动前 → 改动后>
二、为什么这是「公共缺陷」而不是「客服私需」
受影响的其他 Agent / 其他业务线：<逐个列出>
失效路径：<描述「不改会怎么坏」>
三、最小化边界
不新增字段 / 不改返回形状 / 不改表结构 / 不改函数签名
<逐项确认>
四、规范依据
N-<编号>（<规范条目原文要点>）
五、影响面
哪些 Agent、哪些测试、哪些调用点
六、降级方案（不受理时怎么退）
<具体降级做法> + 必须在文档中标注为降级
⚠️ 组 2 的申请单须额外写一段：说明为什么必须触碰原本声明为「零改动」的文件（依据 FR-CS-043 / FR-CS-044），以及改动会使
docs/33/docs/34的逐行实证行号漂移、承诺改动后复核那些结论。