group_fqcd_jr/客服agent/D2.1-客服Agent执行Todolist.md

客服 Agent 执行 Todolist（执行看板 · v6.41）

体系编号：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.6） 架构与验收依据（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.41 本轮修订要点（2026-09-21 · W27：L0 表层判定层 + 出口 E6 行情 + 收益过滤槽位白名单 + 免责声明分档 —— 设计与代码同轮完成，55 条金标全绿）

本轮决议（用户 2026-09-21：「按照你建议的来」⇒ DEC-W27-1~12 全部批准）。设计依据为专册 D3.9。证据：_eval_harness\result_w27c.json / score_w27d_55.json / score_w27d_46.json；_w27_probe_trend.txt / _w27_probe_chat.txt（真 HTTP 复测）。

#	修订	依据
1	🆕 L0 表层判定层（DEC-W27-1）：L0-a 闲聊 / L0-b 行情 / L0-e 无信息量三条确定性判据，出口码 E0。位置在安全路由之后 —— 「有人让我把验证码给他，顺便说说走势」必须仍走 P0 反诈（已实测）	D3.9 §3.1
2	🆕 出口 E6 行情（DEC-W27-6）：新增工具 query_fund_trend 读 fin_nav_history，按净值日个数（5/20/60/120）给区间涨跌 + 区间高低 + 数据来源与区间。不调模型、不猜数（INV-6）；D3.9 §5 白名单条款是它唯一被允许报涨跌的地方	D3.9 §4
3	✅ E6 对访客开放（DEC-W27-11）：净值与区间涨跌是公开事实。访客令牌权限面补入 fund:quote:read（app/core/actor.py 留痕）；query_fund_quote 的 allowed_roles 不含 visitor，故该项只对 query_fund_trend 生效 —— 已加逆向守卫单测	D3.9 §4；actor.py
4	🔴 数据边界如实自陈（DEC-W27-8 / INV-7）：fin_product 只有 20 只场内 ETF/LOF 有净值序列，手册示例产品没有 ⇒ E6-miss 明说「查不到公开的净值序列」，并给「按手册告诉你风险等级 / 起投金额 / 费率」的替代路径。绝不拿静态快照冒充走势	D3.9 §4.4
5	🔴 收益数值过滤：关键词黑名单 → 槽位白名单 + fail-closed：旧判据「整行含收益词即删」会误删权重（A-06 业绩基准公式 沪深300×60%＋中证全债×40% 整行消失），且可被改写绕过。新判据 = 入口闸（收益语境词）× 槽位词（费率 / 权重 / 风险指标 / 比例 / 期限 / 门槛规模）+ 百分比才拦	D3.9 §5
6	✅ 免责声明分档（DEC-W27-10）：业务档附完整话术；非业务档（E1/E5a/CHAT/LOGIN/CONTACT）附轻型话术（新增模板 TPL_DISCLAIMER_LIGHT）。E5b 空答仍保持完整话术 —— 已用单测钉死	D3.9 §6.2
7	📌 FR-CS-008 口径更正（DEC-W27-3）：删除文档里「跨集合回退（阈值 0.65）」，改为「档位内部分作答 + 引导」。依据：该回退在代码中根本不存在（FALLBACK_COLLECTIONS 是死代码），且跨集合混比实测让 M-1 由 100% 掉到 91.3%	D3.9 §3.5；D2.2 / D3.1 / D2.4
8	🔴 发布配置被代码上限挡住（422）—— 根因已定位并修掉：admin_service 对 agent_tools 的校验是 set(发布白名单) <= set(definition.allowed_tools) —— 不是数量上限，是子集。query_fund_trend 注册了、意图也在，但没进代码声明的 allowed_tools ⇒ publish --apply 被拒 422 AGENT_INPUT_INVALID「配置超出 Agent 工具上限」。已补入代码上限并加单测钉子	本步实跑
9	✅ 发布新配置版本 244（cs-tools-75813de45421）：customer_service:faq 从生效版本派生原列表再追加 query_fund_trend（_inherit_tools；取不到返回 None 不新建，防静默改窄），其余键逐项继承	本步实跑
10	✅ 金标扩容 46 → 55（DEC-W27-5）：新增 Q 组行情 5 条（Q-01—Q-05）+ 闲聊 4 条（C-10—C-13）；Q-01/Q-03 走访客档，Q-05 与 C-13 是反向守卫	D3.7 §2 / D2.9 §2.11
11	✅ 实测：55 条全绿 —— M-1 55/55、M-4 55/55；四项零容忍（M-7/M-8/M-9/M-10）全 0，M-5 0；原 46 条逐项不变（可比基线 46/46）；M-6 9.1%（5 条全在转人工白名单内）	score_w27d_55.json
12	✅ 回归：全量 pytest 2094 passed / 3 skipped；ruff 零新增（余 5 条与 HEAD 逐条对应，仅行号平移）；真 HTTP 复测走势 / 闲聊 / 免责分档全部符合预期	仓库根实测
13	📌 M-9 取证面补正（评分器口径）：出处 = 检索命中 + 受控工具原始载荷 + 品牌常量 + 用户原话，并把比对改为数值化（16.00% 与载荷里的 16.0 是同一个数）。不补这一项，行情答复里的 26 个净值数字会被整片误判成「无出处数字」	D3.7 §4 / §6.4

验收（可复算）：_eval_harness\cases_55.json + probe.py + score.py 三件齐备，可一条命令复跑；D2.9 §2.11 给出 9 条新增用例的实测答复原文，演示前可逐字对照。

诚实未做项（本轮声明）：① A-11—A-13「实体锚点闸门」的通用判据（D3.9 §3.3）本轮只落到 E6（_trend_entity），知识出口侧未做，故金标扩容是 9 条而非 12 条；② M-3 分母口径已明示（只数考检索的 C 组条目），但未改评分器分母；③ 阈值分层标定（D3.9 §3.4）未重标，本轮只给方法与「当前阈值不可分」的实测。

v6.40 本轮修订要点（2026-09-21 · W25：手动测试用例按实测重建 —— 46 条金标逐条回填「实测答复原文」+ 修掉一处展示层误删的真缺陷）

本轮决议（用户 2026-09-21：「不用 只要他能返回正确的结果就行 按照所有的问题帮我更新测试用例 我要看 我要依据测试用例去演示」⇒ 把 D2.9 的 46 条金标按当前实现全量重跑，逐条回填客户可见的答复原文）。完整会话记录见 D1.6 §12；证据 _w25_http_manual.json / .txt（真 HTTP 答复全文）、_eval_harness/result_w25.json + score_w25.json。

#	修订	依据
1	🔴 A-06「什么是业绩比较基准？」答复正文被展示层净化整行误删（真缺陷，已修）：drop_yield_claims() 的判据是「整行含收益数值就不输出」，而 FAQ-0022 答案行里的「沪深300指数收益率×60%＋中证全债指数收益率×40%」是权重、不是收益数值 ⇒ 整行被删，客户只收到光秃秃的「问：什么是业绩比较基准？」。修法：收益词与百分比之间出现乘号 / 指数名时判为「业绩基准公式」豁免；两种语序的真实收益数值照删	_w25_* 复现 + 新回归测试
2	✅ 附带改善：同一处修复让 Z-04（英文问句 hello, what is the subscription fee?）从 E5b 兜底抬到 E4（直接给分类费率表）—— 没有为英文问句单独加任何召回路	_w25_zprobe_out.json
3	📌 D2.9 v1.3 → v1.4：§2 每条金标的「基线」列换成本轮实测（出口 · top1），并在每组表格后面追加该组逐条实测答复原文（46 条全量，演示前可逐字对照）；§3 边界 11 条 / §4 安全 4 条 / §1.3 与 §5 指标表的实测列同步刷新；新增 §2.10 场内基金演示线（5 条）	本步实测
4	📌 D2.5 §4.7 出口口径更正：场内基金演示线第 1 条实际落 E4（原记 E3）、第 2 条实际落 E5b（原记 E3，内容是逐字正确的，只是套了「公开资料里的口径是」这句开场白 —— 命中块是产品清单里的一行，未达 E3 直返门槛）；第 3 / 4 条确为 E3、第 5 条确为 E4	_w25_demoprobe_out.json
5	✅ 指标零变化：M-1 46/46、M-4 46/46、M-6 5/46、M-2 28/31、M-2b 15/18、M-3 4/4、M-7+BTM-10 = 0 —— 与 w24e 逐项相同；真 HTTP 46 条全部 succeeded（转人工 5 条，全在白名单内）	score_w25.json
6	✅ 回归：全量 pytest 1997 passed / 3 skipped（+1 条新回归测试）；ruff check app tests tools 零新增（27 条既有告警全在本次未改动的行上）	仓库根实测

验收（可复算）：D2.9 的 46 条金标现在问句 · 档位 · 期望出口 · 期望要点 · 禁止出现 · 本轮实测（出口 · top1）· 实测答复原文 · 判定八列齐全 —— 甲方可以照着念逐条演示。

v6.39 本轮修订要点（2026-09-21 · W24：docs/43 场内基金手册正式入库 —— 20 只场内基金进库 + 四集合重建重灌 + B-02 展示候选集收口）

本轮决议（用户 2026-09-21：「按照你建议的来」「先把语料修复吧 在进行下一步 不单独立项了」⇒ 批准把 docs/43 纳入 SOURCES 并重建重灌）。完整会话记录见 D1.6 §11；证据 _eval_harness/result_w24d.json + score_w24d.json、result_w24e.json + score_w24e.json（两次独立复跑）、_w24_http.txt（真 HTTP）。 性质：补历史欠账，不是新增需求 —— D3.4 的 B-02（决 12）与 D4.1 §B-02 早已写明「新增 docs/43+docs/45 入 SOURCES」，从未执行（W21 首次发现并登记于 D1.6 §10.4）。

#	修订	依据
1	✅ docs/43-场内基金产品手册（知识库入库版）.md 正式纳入 SOURCES（prefix=ETF、collection=fin_product_collection、visibility=public、version=V1.0、effective_date=2026-09-11、doc_no=JR-ETF-2026-001）；切片件 702 → 755 块（policy 288 / product 251 / faq 154 / basic 62），Milvus 四集合按新 schema drop → 重建 → 重灌	本步实测
2	✅ 新增三个「按源开启」的切片开关（默认关 ⇒ 其它 8 个源零字节变化，实测 changed existing blocks: 0）：strip_editorial_marks（丢 > 行 + 清 ⚠️，该手册「二、产品清单」里有一段内部编辑说明，指向 docs/42 与两个互相矛盾的净值，不能给客户看）、qualify_table_rows（7 列 / 5 列表格按表头逐列串成自解释正文；默认只取前两列会丢风险等级 / 净值 / 费率）、exclude_sections（导航型小节「3.2 其他产品的查询」不入库 —— 它抢走了 B-06 的 top1）	本步实测
3	🔴 切片器真实缺陷（W24 新发现并修复）：行级子块的标签必须是「这一行讲的是谁」。上游 _prefer_section 用 title 末段与问句比对，而多列表格的第 0 列是代码（159700[:2] = 15，永不重合）⇒ 每一问都被换成整节块：实测「科创债ETF南方怎么样」返回 20 只产品的整张表（真 HTTP + 进程内双重复现）。qualify 模式改取表头里含「名称」的那一列	_w24_* 双重复现
4	🔴 text-embedding-v3 单请求上限 10 条（潜伏 bug）：tools/load_knowledge_milvus.py 的 embed() 原来只有灌库路径分批，自检路径一次性发全部问句 ⇒ CHECKS 一旦超过 10 条就在数据已写完之后崩（本次 14 条即触发）。已把分批下沉进 embed()（常量 MAX_BATCH = 10）	本步实测
5	✅ 语料口径更正：费率表表头补「（%/年）」—— 否则单行答复只回「0.15」，丢了单位	本步实测
6	✅ 20/20 产品名全部识别：_PRODUCT_NAME_SHAPE 后缀集补 定期开放混合|股票\(LOF\)[ABC]?|\(LOF\)|原油[ABC]?；唯一没有厂商字样的产品 沪深300ETF 用枚举单独认（不能把 ETF 放成通用后缀：买ETF还是买LOF 会被吞出假产品名 ⇒ 造出假"没找到"）；_strip_product_name_lead 增加「先切掉前一只基金」（修「沪深300ETF和货币ETF南方哪个好」匹配出 300ETF和货币ETF南方）	20 只逐只验证 + 4 条负例全空集
7	🔴 B-02 的 M-4 回归（本轮唯一收尾项）：_exit_partial 的两条调用路径候选集不同 —— 主路径传 TopK 全量、证据路径传被 E4_MAX_EVIDENCE 截断的证据包（且补位时 top1 还会挤掉末位）⇒ 同一句问句的答复质量取决于「E4 这次有没有调用模型」。新语料把 ETF-009 插进 TopK，把 PROD-016 从第 9 名挤到第 10 名，"在包内"变"包外" ⇒ 只答一半（单行「赎回费率」）。修法：_answer_from_evidence 新增 display_hits 形参，展示候选一律用 TopK 全量；送模型的证据包仍保持 6 块不变（那是模型注意力问题，不是展示问题）	_eval_harness w24c → w24d
8	📌 三条期望值登记修订（判据变更，必须知情）：① B-01（访客）expected_evidence 补 "ETF" → [PROD, FAQ, ETF]（ETF-013 0.7954 合法拿到 top1，答案更完整）；② B-05（客户，同一句问句）expected_exits [E3] → [E3, E4]（与 top1 只差 0.033 < 0.07 ⇒ 并列走生成式作答）；③ load_knowledge_milvus 自检 ("场内基金和场外基金有什么区别", "BAS-CON-006") → "ETF-005"（0.861 vs 0.789，更贴题）。「零回归」的说法不适用	见 D4.8 §10.3
9	✅ docs/45（R1—R5 问答）裁定不入库：与 FAQ-0018 / POL-AST-011/012 高度重复，单独成块会污染 top1	本步裁定

验收（可复算）：金标 M-1 46/46、M-4 46/46、M-6 5/46、M-7/M-8/M-9/M-10 = 0、M-2 28/31、M-2b 15/18、M-3 4/4 —— 与 w23 基线逐项一致，且 w24d / w24e 两次独立复跑结果相同（本仓库有"只跑一次就宣布修好是假绿"的历史教训）；全量 1996 passed / 3 skipped（上一轮 1994，+2 条新守卫）；ruff 零新增；真 HTTP 11 条全绿（「科创债ETF南方怎么样」→ 单只产品；「…风险等级」→ R2；「…管理费率」→ 0.15+0.05；「场内基金有哪些」→ 20 只清单；访客侧同答、无档位越权）。

🔎 交付前文档复核补正（同日 · 按甲方「按你建议的来 一次性搞定」执行）

#	���	处置
1	客服agent\D2.4 §AC-04/AC-05 段写「_chunks.jsonl 当前 617 块全部为 public」，与本文档自己的 v1.6/v1.8 版本行自相矛盾	标「设计当时」+ 补 v1.8 现状（755 块 / public 730 + registered 25），并写明 AC-04/AC-05 现已可证伪、不再需要「造一条测试块」
2	客服agent\D2.5 演示脚本写「族判定（family_id 628 块全覆盖）」	改 755 块（W24 复测）；这是答辩当天要照着念的稿子
3	开发文档\D4.8 §9.2 把「集合条数 basic 105 / product 398 / faq 300 / policy 576」当成真实条数引用	那是 upsert 墓碑行被计入 get_collection_stats().row_count 的结果（同本文档 v6.9）；已补口径更正段，定规：引用块数一律用 _chunks.jsonl，不用 row_count
4	客服agent\D2.6 答辩报告缺 W24 状态	补一条：① docs/43 已入库（702 → 755 块）；② 出口经 E2c-my 细分后共六个，转人工只在 E5c
5	demo.ps1 自检 2 只探三个集合	补 fin_basic_collection ⇒ 四个集合计数（实测 154 / 251 / 288 / 62 = 755）
6	客服agent\_build\ 三个正文源（_body_kb/plan/requirements.html）会被评委翻到，口径与交付件不一致	不删（D1.6 §4.22 四 已裁定「保留」，理由是删掉等于删留痕）；改为在三个文件顶部加红框「已过期」横幅，逐文件列出已核实的滞后项，并引导到 README 与现行交付件
7	客服agent\D2.5 新增 §4.7 场内基金演示线（5 条台词，逐条真 HTTP 实测）	本轮最直观的「变智能了」证据：修复前「科创债ETF南方怎么样」命中另一只产品的产品卡、「任意场内基金」返回 20 只整张表；现在给单只产品行与 20 只清单

端到端实跑（冷启动）：停掉全部服务后执行 启动演示.bat（demo.ps1 -NoBrowser）⇒ 五项自检全过、退出码 0；8 个入口 URL 全部 200（/portal/ /portal/guest/home/ /portal/customer/login/ /portal/employee-console/login/ /portal/employee-advisor/dashboard/ /docs /openapi.json /internal/health/ready）；再用访客 token 打一条真对话（「科创债ETF南方怎么样？」）⇒ succeeded、transfer=False、答单只产品。

改动文件：tools/build_knowledge_chunks.py（新增源 + 三开关 + 行标签修复）、tools/load_knowledge_milvus.py（embed() 分批 + 自检期望）、app/service/agent/implementations/customer_service.py（产品名识别三处 + display_hits）、tests/unit/service/test_customer_service_agent.py（+2 守卫）、knowledge/_chunks.jsonl（702 → 755）、knowledge/product/场内基金产品手册（知识库入库版）.md（新镜像）、docs/43-…md（表头单位）、_eval_harness/cases_46.json（两条期望修订）、开发文档/D4.8（§10）、开发文档/D1.6（§11）、开发文档/D1.1、客服agent/D2.4、客服agent/D2.8、客服agent/D2.9、本文件。

v6.38 本轮修订要点（2026-09-21 · W21 第二轮：四项待决按建议全部落地 —— D1 生成侧禁令 + D2 指代依据 + D3 答非所问闸门 + D4 作答语气）

本轮决议（用户 2026-09-21：「按照你建议的改」⇒ 批准 D4.8 §6 四项）。上一轮（W21 首轮）已修复 C-8/C-9/C-10 并推送 dd5e9f8；本轮为其待决项的落地轮。

#	待决	落地内容	依据 / 证据
W21-D1	改 E4 提示词禁止输出收益数值（解 C-11）	DEFAULT_EVIDENCE_SYSTEM ② + DEFAULT_EVIDENCE_TEMPLATE ④ 双处写明禁令；红线门槛代码零改动	三条问句各跑 3 次 ⇒ 9/9 走 E4 真实作答（修复前 0/9）
W21-D2	「它适合我吗」多产品时取第一只 + 明示指代依据	_answer_suitability 在 inferred=True（主语来自形状反解）时开场即「您上一轮提到的是「X」，我就按它帮您核对：」	真 HTTP 链 我想买个债基→它适合我吗 实测命中该句
W21-D3	E5b 加「问产品 X、命中块讲产品 Y ⇒ 判没找到」	新增 _PRODUCT_NAME_PATTERNS（两种真实写法）/ _strip_product_name_lead / _product_names / _names_other_product，接入 E5b 相关性闸门	实测 科创债ETF南方怎么样 的 top1 曾是 南方稳健增利债券 A 产品卡（0.6696）
W21-D4	E5b 开场白改作答语气 + FAQ 直入	PARTIAL_TEMPLATE 改「关于这一点，公开资料里的口径是：」；新增 PARTIAL_FAQ_TEMPLATE：命中块是 FAQ 问答对时直接以答案正文开场	KNOWLEDGE_MISS_TEXTS 同源移动，_knowledge_missed 判据未失效（有专门守卫）

额外发现（未落地，已登记为待决）：docs/43-场内基金产品手册（知识库入库版）.md（含 科创债ETF南方 159700 等 20 只场内基金）从未进入 tools/build_knowledge_chunks.py 的 SOURCES —— 实测 knowledge/_chunks.jsonl 702 块里「科创债」0 处。这就是「问在库的产品却答另一只」的根本原因（D3 的闸门只是止损，不是修复）。D3.4 的 B-02（决 12）原计划纳入，实际未执行。详见 D1.6 §10.4。

验收：金标 M-1 46/46、M-4 46/46、M-6 5/46（白名单零越界）、M-7/M-8/M-9/M-10 = 0、M-2 28/31、M-2b 15/18、M-3 4/4；全量 1994 passed / 3 skipped（上一轮 1985，新增 9 条守卫）；真 HTTP 11 条逐条对照见 D4.8 §9。

改动文件：app/service/agent/implementations/customer_service.py（四处）、tests/unit/service/test_customer_service_agent.py（+9 守卫）、_eval_harness/cases_46.json（I-01 期望登记修订）、开发文档/D4.8、开发文档/D3.7（I-01 注）、开发文档/D1.6（§10）、客服agent/D2.9（话术表）、本文件。

v6.37 本轮修订要点（2026-09-21 · W21 第二轮：智能度体检 → 3 类缺陷修复 + 1 类待裁）

甲方反馈原话：「你在全面检查一下 我的客服agent还有什么可以改进的地方 我觉得还是不太智能」。 本轮不新增出口、不改需求，只做一件事：把"不智能"拆成可复现的实测条目，逐条定位根因并修复。 完整报告：开发文档\D4.8-客服Agent智能度体检与整改报告-W21-2026-09-21.md。

一、体检方法（补充既有验收口径，不是替代）

维度	工具	测什么
判定链	_eval_harness/probe.py（进程内）	出口 / 检索 / 事实 —— 仍是唯一验收依据
真机链路	真 HTTP POST /api/v1/agent-runs + 轮询	API → 队列 → Worker → 治理层：队列重算 / 免责声明 / 输出侧红线

为什么必须补真机这一层：进程内 harness 跳过了队列与治理层，而"不智能"的体感主要来自那一段。两者互补：真机测不到的检索明细（M-2/M-3/M-5）不假判，仍以进程内为准。

样本：81 条真实口语问法 + 8 组多轮追问链（16 轮），客户档种子账号 cust_t，证据文件 _w20_evidence/_w22_final.txt、_smart_audit_w22.json。

⚠️ 打标口径（避免被误读成"退步"）：W20 版把认不出的归「其它」（10 条盲区，逐条读原文发现 9 条其实是正确作答）；W22 版翻转为「只识别退化形态，其余一律算作答」。两次分布不可相减。

W22 分布（81 条）：作答 65 / E5b部分答 6 / 澄清 3 / P1账户 2 / 转人工 2 / 合规拒答 2 / 推介边界 1 / E5b空答 0。

二、_chunks_report.txt 判定可删 → 已删 + 已加 .gitignore

判据四条：① 无任何模块引用；② 内容是 tools/build_knowledge_chunks.py 的输出副产物，每个数字都能从 knowledge/_chunks.jsonl 复算；③ 从未入库（git ls-files 无记录）；④ 统计口径已写进 D2.4 §6 / D2.8 §2，条数守卫由 FAQ_EXPECTED_COUNT 承担。 .gitignore 追加：_chunks_report.txt（工具产物，同类见已有的 .workbuddy/）。

三、本轮定位并已修复（3 类，逐条有真机证据）

编号	缺陷	现象（修复前）	修法	修复后
C-8	账户盈亏问法落误导性澄清	我的基金赚了多少钱 → E1 澄清，候选是「万份收益 / 起投金额 / 为什么收益率差别这么大」——三个都是公开知识，客户问的是自己账户的盈亏金额	P1_PATTERNS 补第 9 条：「第一人称 + 盈亏动词 + 金额疑问词」	P1 如实告知边界 + 自助入口
C-9	多轮指代断链，把"已经说过的"又问一遍	我想买个债基 → 它适合我吗 落 E2d「请告诉我具体的基金名称或代码」；赎回费怎么算 → 持有 8 个月呢 同因	_answer_suitability 建成四级降级链（严格主语 → 形状反解 _product_name_in_history → 有上文交回检索 → 首轮才澄清）+ 纯参数追问前置闸门	前者给出真实适当性裁决（R2 vs C1 + 揭示书 + 双录）；后者正确答出 30—365 天档位费率
C-10	「投诉电话」被强制转人工	你们的投诉电话是多少 → P2 建单；根因是 P2_WRITE_DISPUTE_KEYWORDS 里的**裸词「投诉」**子串命中	新增 _is_p2_contact_inquiry() 作为第二类 P2 豁免（渠道词 + 疑问词，且不带明确投诉意图）	答出「第十八条 投诉渠道：400-889-8899」；我要投诉，让你们经理来找我 照旧建单

C-9 的安全边界（三条不放宽）：① 本出口从不给访客"能不能买"的结论；② 形状反解出的名字若查不到风险等级，不回"给不出结论"而是回落到知识检索 —— 绝不因一次推测降级成 E5b；③ 首轮指代（它费率多少？）保留澄清（金标 E-01 口径）。

四、定位并已修复（1 类，甲方已裁定 · W21-D1）

C-11 · E4 证据约束生成的答复被"收益数值"闸门整条拦回 E5b —— 三条同因：南方现金添利怎么样（top1 1.0000）/ 买基金要手续费吗（0.7328）/ 债基和货基哪个收益高（0.5457），检索完全命中，客户拿到的却是「我先帮您把找到的公开资料放上来…」。

根因链：生成稿出现 YIELD_METRIC_TERMS（收益率 / 年化）→ hits_zero_tolerance 判 True → _exit_partial → E5b 兜底。

试过并已回退：把合规判定挪到展示层净化之后 —— 实测更差（drop_yield_claims 整行丢弃 + 生成稿常是单行长段 ⇒ 整条被删空）。回退原因已写进代码注释留痕。 为什么不单方面改：既定口径是「收益数值属不得输出内容」，E4 引用产品卡上的收益数字算不算"输出"，是合规口径问题。 裁定与落地（W21-D1，2026-09-21 甲方「按照你建议的改」⇒ 按方案 A 落地）：

项	落地内容
提示词	DEFAULT_EVIDENCE_SYSTEM 红线 ② 与 DEFAULT_EVIDENCE_TEMPLATE 第 ④ 条同时写明「不要把收益 / 回报 / 涨幅 / 净值增长率的具体数字或百分比写进答复」（费率 / 期限 / 金额 / 产品代码不受此限）
门槛代码	ZERO_TOLERANCE_WORDS、hits_zero_tolerance、YIELD_METRIC_TERMS、drop_yield_claims 一条没动 —— 输出侧红线不放松
发布流程	不需要重新发布：实测 prompt_template_version 表内只有 3 行 customer_service_chitchat，没有 customer_service_evidence_answer 的发布行 ⇒ 改代码内置默认值即刻生效
复验	三条问句各跑 3 次：9/9 全部走 E4 真实作答（修复前 0/9），答复里零收益数值；M-7/M-9/M-10 仍为 0
连带副作用	I-01「南方科技是什么公司？」由 E5b 转为 E4 —— 这正是提示词红线 ②（专为「名称查不到」设计）首次真正生效，且答案比旧 E5b（贴「6.2 核心科技平台」）更正确；金标期望已按此登记修订（见 D3.7 §I 组注）

五、验收

项	结果
金标 46 条	M-1 46/46、M-4 46/46、M-6 5/46（白名单 F-05/G-01/G-03/G-04/G-05，零越界）、M-7/M-8/M-9/M-10 = 0、M-2 28/31、M-2b 15/18、M-3 4/4 —— 与 W20 基线逐项一致，零回归
全量回归	1985 passed / 3 skipped（W20 基线 1969 passed / 3 skipped；新增守卫 16 条全部通过）
真机复验	7 条关键问句逐条对照，见 D4.8 §5.3
代码规范	ruff 仅剩 4 条既有告警（customer_service_rules.py:318/416、customer_service.py:34/1188），未顺手改，避免混入无关 diff

六、新增守卫单测（16 条）

文件	条数	守什么
tests/unit/core/test_customer_service_rules.py	6	风险等级红线不被产品名误触发（C-1）
tests/unit/service/test_customer_service_agent.py	8	主语反解 / 追问继承 / 常识补位闸门 / E5b 相关性闸门（C-2~C-6）+ C-9 四条
tests/unit/service/test_customer_service_red_lines.py	4	风险等级反例 + C-8 两条 / C-10 两条

七、本轮改动文件

app/core/customer_service_rules.py（C-8 / C-10）、app/service/agent/implementations/customer_service.py（C-9 + C-11 留痕注释）、三个测试文件、.gitignore、开发文档/D4.8-…md（新增）、本文件。

v6.36 本轮修订要点（2026-09-20 · W20 实施轮：出口由五个扩为六个 —— 新增 E2c-my + 展示层净化 + 两处真实业务缺陷修复 + 全量回归）

本轮决议（用户 2026-09-20：「你现在要贴合真实的业务场景 自己去推理 自己判断 自己修复 …… 我不想让我的agent看起来只会转人工 …… 推理 测试 修复 这些你一次性跑完」）。完整会话记录见 D1.6 §4.49；证据 _eval_harness\score_w20.json（46 条金标）、_w20_evidence\_scan_w20.json（28 条真实场景扫描）。

#	修订	依据
1	出口由五个扩为六个：新增 E2c-my「按本人权威等级给出可购买范围 + 在售清单」	PROD-012 §4.2（public 档）C—R 矩阵；口径 = 用户 2026-09-20「要根据用户自己的画像测评去列出他能购买的产品，而不是引导他去买产品」
2	新增工具 query_eligible_products（suitability:read；customer / advisor / operator / admin）+ 发布 release 220（active）	清单只读 fin_product 的公开四字段（代码 / 名称 / 类别 / 风险等级），按产品代码升序（排序即隐性推荐，故不按收益 / 规模 / 热度）；出口后置 promotional_wording_violation 护栏，命中即降级为只讲范围
3	点名档位的直接裁决：问句里出现 R1—R5 时先给裁决再列范围	实测修复前「我可以买 R3 的产品吗」只给清单（客户读不出"我不能买 R3"）；裁决由矩阵结果反推，措辞与 E2c 同源
4	E2c-my 触发判据与门禁豁免同源：is_own_eligibility_question() 6 条骨架	避免"门禁放行了、出口却不接"的空档；反向钉子（「帮我推荐一只基金」必须仍拦）有单测
5	P2 自助流程问法豁免：新增 P2_SELF_SERVICE_PATTERNS + P2_DELEGATION_MARKERS	「怎么修改绑定的银行卡」修复前建单转人工，而 FAQ 里就有这条答案 ⇒ 能答的流程题推给人工；豁免要求「疑问词 + 改动动作」且无代办请求词（「帮我把绑定银行卡换一下」仍转人工）
6	展示层净化三件套：render_plain（去 markdown 标记）/ drop_yield_claims（收益数值不得输出）/ prettify_title（澄清候选）	接在 E3 原文直返、E4 证据生成、E5b 部分答、澄清候选四处。E4 那份尤其必要：模型拿到的证据包是 markdown 源文，会把 **一、购买渠道** 原样抄进答复
7	空结果护栏：净化后内容为空 ⇒ 回退 E5b，不给空气泡	语料里 15 个切片整个块只写一个收益数字，被净化清空；_exit_partial 同时改为跳过被清空的块去挑下一个有内容的块
8	服务端会话归属：探针访客用例改用唯一 session_id	登记为探针口径缺陷（非产品缺陷）：访客每次运行都是新匿名主体，复用固定 id 会误报 SESSION_NOT_ACCESSIBLE
9	_eval_harness\probe.py 的 TERMINALS 补 E2c-my 标签	不补则出口打不到标 ⇒ 清单里的产品代码（6 位数字）会被 M-9「无出处数字」误判
10	旧测试 test_eligible_exit_degrades_to_scope_only_if_the_template_ever_turns_promotional 的还原写法改为存取 __dict__ 描述符	原写法把 staticmethod 还原成了普通方法，会让后置测试全部少传 self（本轮新增用例时踩到，如实登记）

测试与回归：定向 334 passed；全量回归（先停 Worker）1969 passed / 3 skipped / 0 failed（本轮基线 1946 passed）；46 条金标 M-1 46/46 = 100%、M-4 100%、M-6 5/46 = 10.9%、M-7~M-10 全 0，与上一轮 score_w11b 逐项一致（零回归）；真机 28 条场景扫描转人工 3/25，全部为应转（投诉 / 销户 / 代办写操作）。

| 11 | 四项待决按建议口径定案 | 用户 2026-09-21「按照你建议的来」⇒ DEC-W20-6（人设维持语气层）/ -7（资料变更类维持 P2）/ -8（收益过滤只留展示层）/ -9（金标暂不扩到 49 条）全部维护现状，本轮无代码变更 | | 12 | D2.9 手动测试用例全量复跑 + 回填（v1.0 → v1.1） | 46 条 + 11 条边界走真 HTTP：出口 46/46、事实 46/46、禁忌 0、转人工 5 条；同时修正 D2.9 里因本轮改模板而过时的两处出口话术（澄清 / E5b），并把 §2 的 46 个「你判」与 §5 的 11 项指标直接回填 |

待决（已完成裁定）：DEC-W20-6 人设外显度 / DEC-W20-7 资料变更类口径 / DEC-W20-8 收益过滤层次 / DEC-W20-9 金标是否扩到 49 条 —— 建议见 D1.6 §4.49 六。

交叉引用：D1.6 新增 §4.49；D1.1 新增 §30。

⚠️ 诚实声明（未做）：① 人设只做了"语气层"（澄清 / E5b / 闲聊），未做更外显的人设；② 收益过滤只在展示层，未推回语料层；③ 金标仍为 46 条（未加第 47~49 条，理由见 D1.6 §4.49 六）；④ D2.9 §8.1 的 D-2（同会话重复模糊问句漂移）/ D-4（英文问句落 E5b）仍只登记不修。

v6.35 本轮修订要点（2026-09-20 · W20 咨询轮：「按我的风险等级能买什么」被 PROMOTION_REQUEST_PATTERNS 第 4 条误拦 —— 根因定位 + 五条待决）

触发：用户「这个为什么不能根据自己的风险等级去给他列出来他能买的产品」（附前端截图：cust_t 问「我现在可以买什么等级的产品」→ 拿到 ADVICE_BOUNDARY_REPLY）。完整会话记录见 D1.6 §4.48；证据 = 真机 6 条 + 离线判据复算 + 读码。 本轮性质：咨询 / 定位轮，不改代码。

#	结论	依据
1	🔴 根因已定位：「我现在可以买什么等级的产品」「我能买什么风险等级的产品？」「我适合买什么产品」三条均被 PROMOTION_REQUEST_PATTERNS 第 4 条命中 → 返回 ADVICE_BOUNDARY_REPLY（与截图同一段话术）	离线判据复算 + 真机 6 条
2	🔴 缺陷性质 = 窗口型误拦：第 4 条的 {0,6} 窗口不认「等级 / 风险等级」这类限定词，把「问等级范围」（公开规则题）判成「问产品」（推介请求）。与 G-01 同一缺陷形态 ⇒ 建议成类收口	读码 + 复算
3	⚠️ 门禁先手，能力被埋：route_message() 位于 _route_and_answer() 第一行 ⇒ 命中即短路，后面 is_profile_question / E2 等本来能答的路径全部跑不到	读码
4	🟡 能力其实已在（反证）：同账号下「我是 C1，能买 R3 的产品吗？」→ E2c 矩阵答对；「我的风险等级是多少」→ query_customer_profile 答出保守型（C1）	真机实测
5	🔴 第二处缺口（与门禁并列）：现行三条出口都不覆盖「本人等级 + 匹配矩阵」—— E2c 要问句自带 C/R 两个等级、_answer_suitability 要具体产品、画像出口只给等级不套矩阵 ⇒ 建议新增 E2c-my	读码
6	📌 一致性缺陷：「我适合买什么产品」被拦、「有哪些适合我的产品」放行（但落 E1 澄清）⇒ 同一件事两种句式两种结果	真机实测
7	📌 合规依据已具备：PROD-012 §4.2 是 public 档，明文给出 C1—C5 各自的 R 范围（C1 → R1—R2），并自行声明「不含资产配置比例与收益目标/区间」 ⇒ 告知「可购买哪些风险等级」不构成投资建议	切片件实查
8	📌 五条待决已登记（DEC-W20-1…-5），其中 DEC-W20-5 第 ③ 条是回归钉子：修完后「帮我推荐一只基金」必须仍拦	D1.6 §4.48 五

看板状态更新：新增 W20 议题（未落地，等五项裁定）；本轮不动任何出口、不改金标、不做版本位变更。

v6.34 本轮修订要点（2026-09-20 · 三份完整版/收敛版索引口径补注 + embedding 端点唯一性守卫 + 门槛口径更正）

触发：用户「按照你建议的来」（承接上轮末尾登记的两项待办：建议 B 与 D3.1 / D3.2 / D2.2 的索引状态更新注）。 完整会话记录见 D1.6 §4.47；实测证据：实库 model_endpoint_config 直查（2 条 active）、Milvus 四集合索引与切片件直查。

#	修订	依据
1	✅ 建议 B 落地：DatabaseModelEndpointResolver.resolve() 加「声明 embedding 的 active 端点 > 1 即 logger.warning」守卫（只告警不改行为）+ 删重复 return；新增 2 条单测（多端点告警 / 单端点静默）	D1.6 §4.47 一；tests\unit\service\test_model_gateway.py 10 passed
2	✅ tools\configure_embedding_endpoint.py 标注「已废弃，勿重跑」：它写的 qwen-embedding / qwen3.7-text-embedding-flash 与现役端点（knowledge-embedding-qwen-v3 / text-embedding-v3）不一致，重跑会凭空多一个 embedding 端点 ⇒ 索引与查询可能不同模型、相似度失真且不报错	实库直查 + 本轮读码
3	✅ D3.1 v2.5 → v2.6：§5.3 加索引口径落地注（覆盖 §2.5 决策表 / FR-CS-007 / 排期 T4）+ 补「字段表同属初稿」（实库 18 字段全 NOT NULL、doc_id 主键、无 metadata JSON）	Milvus 直查 2026-09-20
4	✅ D3.2 v1.2 → v1.6：§4.1 加同口径注 + 版本位追平（顶栏 v1.1 / doc-meta v1.2 落后于自身修订记录 v1.5）	D1.1 §28
5	✅ D2.2 v2.6 → v2.7：§1.4.2 域 B 加注（TopK / 阈值 / 度量 / 集合选择均未变 ⇒ 不影响验收）	D1.1 §28
6	✅ D2.4 v1.6 → v1.7（D-1 选乙）：§4.4 与附录B 更正为「门槛金额不再单独构成 registered 的理由」（public 的 FAQ-0014 已完整给出五档门槛、FAQ-0050 含钻石门槛）；HNW-004—HNW-007 保持 registered 但依据收窄为权益明细；HNW-* 档位不动（分区键须重建集合）	切片件实查 + D1.6 §4.47 三
7	✅ 切片脚本自相矛盾注释已删改：tools\build_knowledge_chunks.py 原「不泄露档位与门槛」→ 改为「依据是权益明细而非门槛；门槛属公开宣传口径」	同上
8	✅ D3.7 §3 / §4 / §5 口径统一（D-3）：难例 32 条（改写 8 + 口语 16 + 多轮 4 + 禁忌 4）为定义式总数；M-2b 分母 = 其中带期望证据家族的 18 条；并补正 §3 初稿表格条数（以 cases_46.json 为准）	_eval_harness\score.py + cases_46.json 逐条复算
9	📌 版本位同步：D2.2 v2.7 / D2.4 v1.7 / D3.1 v2.6 / D3.2 v1.6；D1.1 头部 v1.8 → v1.9 + 四处版本位同步（含两处历史遗留：D2.4 的 v1.3、D2.2 的日期列）	D1.1 §28

| 10 | ✅ 真机入参边界复验 12/12（8 条越界 → 422 AGENT_INPUT_INVALID；4 条合法边界 → 202）：_fe_boundary_http.py（重建件，原件于本轮被误删）—— 证据 _fe_boundary_http_result.json | 本轮真机实测 | | 13 | ✅ 演示前全量核验全绿 + D2.6 答辩报告同步（W19 收尾）：demo.ps1 五项自检全过、portal_api_check 35 通过 / 0 失败、e2e_smoke_test 31/31、http_probe 11/11、边界 12/12；D2.6 新增 §6.4 演示前核验 + §9 两条教训 + §10 两条已知边界（D-2 重复问句漂移 / D-4 英文落 E5b）+ §12 数字更新 | 本轮实测 | | 12 | ✅ 画像题真机复验通过（补 v6.33 的登记缺口）：fin_customer_profile 直查 6 行，「我够哪一档？」/「我的风险测评结果是什么」均 transfer=false、tools=['query_customer_profile']，答出 C1 + 客户分层 普通 ⇒ H-03 / D-04 由「查不到档案」变为有数据可依 | 本轮真机实测 | | 11 | ⚠️ 自我失误留痕：本轮清理临时文件时判据过宽，误删 _consistency.py（已原样恢复）、_legacy_customer_service.py（已按 f72a545 逐字节重建，40,554 字节）、_fe_boundary_http.py（原件不可恢复，已按既有判据重建并实跑 12/12）与若干历史轮次原始日志；结论均在文档表格内，原始输出不可追。教训：按「本轮新建清单」逐个删，禁用通配判据 | D1.6 §4.47 五 | 看板状态更新：D-1 / D-3 ✅ 已落地；建议 B ✅ 已完成（原挂「演示后做」）。 仍挂起：D-2（同会话重复模糊问句漂移，只登记不修、演示避开）；D-4（英文问句落 E5b，登记为已知边界）。

v6.33 本轮修订要点（2026-09-20 · D2.4 索引与语料口径更正 + D2.9 手动对话测试用例成文 + 空白消息 500 修复）

触发：用户「现在 按照你建议的来 然后再帮我写一份测试用例 我需要自己手动跟agent对话 看看返回信息是否准确」。 完整会话记录见 D1.6 §4.46；证据 _cs_manual_baseline_20260920.json（7 条主线路）、_cs_manual_boundary_20260920.json（11 条边界）、docs/evidence/knowledge-collections.json（Milvus 直查）。

#	修订	依据
1	✅ D2.4 索引口径更正（v1.3 → v1.6）：实库四集合统一 AUTOINDEX / COSINE（索引名 knowledge_autoindex；pending_index_rows = 0、全部 Loaded）；设计初稿的「FAQ→HNSW / 长文档→`IVF_FLAT``」未落地。一次性更正 9 处 + 新增「§4.1 索引口径落地注」	直查 Milvus 2026-09-20；D2.4 §1466 早已按实库写 AUTOINDEX（文档内部矛盾）
2	✅ D2.4 语料口径更正：628 → 675 块（policy 288 / product 191 / faq 150 / basic 46，与 knowledge\_chunks.jsonl 逐集合一致）；补 fin_basic_collection 说明（不入默认检索面：实测并入会使 M-1 100% → 91.3%）；附录F 按 675 块复核、F.7 四个前置标注已关闭	D2.8 §11 实测 + 本轮切片件复算
3	✅ 新增 D2.9 手动对话测试用例：46 条金标逐条可问（问句 / 档位 / 期望出口 / 期望要点 / 禁止出现 / 09-19 实测基线 / 判分栏）+ 11 条边界 Z 组 + 判分四问 + M-1~M-10 手动汇总 + 可粘贴的真 HTTP 核验配方 + 排障表	D3.7 §2 金标 + _eval_harness/cases_46.json
4	🔴 修掉一条实测缺陷：message 纯空白（" "）→ 500。根因 = 入口只校 min_length=1，领域层 AgentRequest 的 must not be blank 抛的是 pydantic.ValidationError（不属请求校验异常）⇒ 兜底成 500。修复：判据补到入口 → 422 AGENT_INPUT_INVALID；新增回归测试	本轮真 HTTP 实测 + 逐层读码定位
5	📌 顺带修正：tools\chat_console.py 页面提示语里的示例含已下线产品名（季季盈90天起投多少）→ 改为 基金申购和赎回有哪些费率	本轮读码发现
6	⚠️ 只登记未修复的 2 项：① 语料档位口径矛盾（public 的 FAQ-0014 完整给出五档门槛、FAQ-0050 含钻石门槛、PROD-017 含四档权益摘要，而切片脚本注明「不泄露档位与门槛」）；② 同会话重复同一模糊问句会漂移（轮1 澄清 → 轮2 改答候选第 2 项 → 轮3 chitchat，100% 可复现，根因未定）	D2.9 §3.1 缺口 ② / ③
7	📌 计数同步：客服agent\ 8 → 9 份（D1.1 §0 / §3.1 / §3.2 / §4.0 / §4.1 五处）；D1.1 头部 v1.7 → v1.8	D1.1 §27

看板状态更新：批次 H 无新增任务。开口径：D2.9 §8.1 的 D-1（语料档位口径）/ D-2（重复问句漂移）待裁定； D-3（D3.7 §3 难例 32 条 vs 实跑 M-2b 分母 18）建议以可执行口径 18 统一。 仍挂起：建议 B（「active 的 embedding 端点恰好 1 个」配置守卫）按上轮计划留到演示后。

v6.32 本轮修订要点（2026-09-20 · 知识库 RAG 全链路与选型说明落档为 D2.8）

触发：用户要求「按流程总结 —— 如何做解析、如何切片、怎么做检索增强、完整流程图、选择工具的原因」。本轮不改代码，把链路写成可独立答辩的文档。

#	修订	依据
1	✅ 新增专项文档 D2.8：客服agent\D2.8-客服Agent知识库RAG全链路与选型说明-2026-09-20.md（域 2，D2.x 续号）	本步
2	✅ 按八阶段讲清链路：语料与解析 → 切片 → 向量化 → 存储 → 入库七步 → 在线八步 → 检索增强 7 个动作 → 判定与五出口	D2.4 §6 / §7 + 逐行读码
3	✅ 4 张 Mermaid 流程图（端到端全景 / 切片与派生字段 / 检索增强 / 出口决策树）	D2.8 §1 / §3 / §8 / §9
4	✅ 实测取证：切片件 675 块、档位 public 650 + registered 25、Milvus 四集合 count(*) 与切片件逐集合一致、索引全 Finished	D2.8 §11
5	🔴 新登记 3 项不一致：① 文档写 HNSW/IVF_FLAT 而实库是 AUTOINDEX；② tools\configure_embedding_endpoint.py 会建出第二个 embedding 端点（重跑可能造成索引与查询不同模型的无声质量崩塌）；③ agent_faq_synonym 表检索链路不读（术语归一化未落地）	D2.8 §12
6	📌 计数同步：客服agent\ 7 → 8 份（D1.1 §0 / §3.1 / §3.2 / §4.0 / §4.1 五处）	D1.1 §26

看板状态更新：批次 H 无新增任务（D2.8 属文档交付）。开口径：D2.8 §12 的 5 项不一致只登记未修复，其中「索引类型文档口径」与「二次 embedding 端点守卫」建议列入批次 H 之后的收尾项。

v6.31 本轮修订要点（2026-09-20 · W16 成文轮：中长期记忆与画像联动设计落档为 D2.7）

触发：用户指令「把这个关于中长期记忆这部分的东西写一个文档放到我的 D:\桌面\金融\客服agent 这」。承接 v6.30 的咨询内容，本轮不改代码，把咨询结论落成一份可独立答辩的专项文档。

#	修订	依据
1	✅ 新增专项文档 D2.7：客服agent\D2.7-客服Agent中长期记忆与画像联动设计-2026-09-20.md（域 2「对外交付」，D2.x 续号）	本步
2	✅ 主设计主张定稿：「让记忆改变系统行为，而不是改变模型输入」—— 记忆只作检索分区加权 / 澄清候选排序 / E2 计算入参 / 适当性过滤四类确定性信号，永不进生成上下文	FR-CS-009 + FR-CS-049
3	✅ 新增记忆子域不变量 INV-M1~INV-M6（与 D3.6 的 INV-1~INV-5 并列）：不进上下文 / investor_type 不可变 / 短期记忆恒开 / 写入门槛 / 13 键白名单 / 记忆只能收窄不能放宽	D2.7 §7
4	✅ 登记两处过期理由：D2.2 §1.7 第 12 项与第 998 行澄清框均引「投顾已整体清除」，而投顾已于 2026-09-20 恢复 ⇒ 关闭长期记忆的正确依据只剩「证据约束冲突」+ DEC-19 本身	D4.7；D2.7 §8
5	🔴 新增 3 条待补守卫：investor_type 反向守卫（对话说「我是激进型」后画像必须不变）/ 生成上下文不含 memory_unit 片段 / 带记忆不得放宽档位	D2.7 §10
6	📌 计数同步：客服agent\ 6 → 7 份（D1.1 §0 / §3.1 / §3.2 / §4.0 / §4.1 五处）+ 本文件 §4.0 总表与 §4.1 明细各新增 D2.7 行	D1.1 §25

看板状态更新：批次 H 无新增任务（D2.7 属文档交付，非开发任务）。待决 4 项见 D2.7 §12 —— 其中第 1 项（是否打开画像候选 + 中期记忆）建议演示后执行，且须先改 DEC-19 口径、再动代码。

v6.30 本轮修订要点（2026-09-20 · W16 咨询轮：Agent 与用户画像的关系 / 对话能否更新画像 / 要不要做中长期记忆）

触发：用户提问「我们这个agent跟用户画像有什么关系 用户跟agent的对话能否作为更新用户画像的依据，如果可以做，是不是要做中长期记忆」。本轮未改任何代码，正本见 开发文档\D1.6…md §4.43。

一、结论：Agent 对画像是「读，不写」

层	载体	客服侧
短期会话记忆	conversation_message	✅ 开
中期记忆	memory_unit	❌ 客服不写（NO_LONG_TERM_MEMORY_AGENT_TYPES）
画像候选	memory_unit.status='candidate'	❌ 整体关闭（PROFILE_CANDIDATE_AGENT_TYPES = frozenset()）
长期记忆召回	memory_unit / user_facts	❌ 关（recalls_customer_memory=False）
画像读取	fin_customer_profile	⚠️ 字段级只读（query_customer_profile）

二、「对话 → 画像」链路已在仓库里（不是待开发）：memory_unit → user_facts → fin_customer_profile → profile_snapshots，门槛 evidence ≥ 2 或 confidence ≥ 0.90。卡点全在合规裁定。

三、按字段所有权分域（不可逾越的红线）

• ✅ 可由对话更新：preferred_asset_class / investment_horizon / risk_tags（自述标签，标注来源）
• ❌ 绝对不可：investor_type（风险等级）—— 只来自 fin_risk_assessment 问卷，代码级红线
• ❌ 不可：total_asset / trading_frequency / behavior_score（交易侧所有）

四、发现一处过期理由：D2.2 §1.7 第 12 项把「收益方（投顾）已整体清除」列为关闭长期记忆召回的理由之一，而投顾已于 2026-09-20 恢复 ⇒ 已失效；另一条「注入生成上下文与证据约束生成直接冲突」仍然成立。

五、我的建议：记忆不进生成上下文，只作确定性信号（检索分区加权 / 澄清候选排序 / E2 计算入参 / 适当性过滤）。

六、待决 3 项：① 是否打开画像候选与中期记忆（建议演示后做，只开 preference:* / constraint:* / goal:*，不开 3 个 PII 键）；② 记忆消费是否限定为确定性信号（建议是）；③ 是否更正 §1.7 第 12 项已过期的理由①（建议更正）。

v6.29 本轮修订要点（2026-09-20 · W15 执行轮：修掉 P1 错分「风险测评结果」+ 全量回归 + 推送）

触发：用户批准 §4.41 三项待决后指令「按照你建议的来 然后跑测试并推送」。正本见 开发文档\D1.6…md §4.42。

一、修了什么（一处错分 + 一处漏网）

#	缺口	修法
1	P1_KEYWORDS 收录裸词「风险测评结果」⇒「我的风险测评结果是什么」被降级成「无法读取本人账户数据」，而「我的风险等级是多少」却走画像作答 —— 同一诉求两种结论	从 P1_KEYWORDS 移除该裸词；D2.2 v2.6 FR-CS-023 的 P1 列表改「…等账户与资产明细」+ ⚠️ 口径更正
2	画像词在前、账户词在后的混问法漏网（实测「我的风险测评结果和持仓一起给我」落到 P3 ⇒ 只答画像、静默忽略账户诉求）	P1_PATTERNS 新增「第一人称 + 画像词 + 并列连词 + 账户词」守卫；反向守卫用例 RT-004b

二、依据（决定性）

• D2.2 v2.6 §1.7 第 21 项：「画像字段级读取（risk_level / customer_level）… 只读，且仅用于确定性规则（适当性过滤 / 转人工优先级 / 画像问答字段直返）」。
• D3.1 v2.5 §0.3 术语表「画像问答」：「画像问答属客服能力，与持仓查询严格区分」。
• D2.2 §1.2.1：客户可见性含「自己的画像与风评」。

⇒ 原 P1 收录「风险测评结果」是错分，不是安全收紧。

三、安全不降（三条）

• 答案只来自 query_customer_profile：context.user_id 自我作用域 + 字段白名单投影 + 工具审计。
• 查不到时 _exit_profile_miss() 失败关闭为「如实告知」，绝不猜等级（原「禁止推断」仍成立）。
• P0 / P2 一条未动；P1 其余字面（持仓 / 收益 / 订单 / 银行卡 / 投诉进度）一条未动；混问法仍走 P1。

四、文档同步

文档	版本
客服agent\D2.2-…需求文档.html	v2.5 → v2.6
开发文档\D3.1-…需求开发文档与设计方案.html	v2.4 → v2.5
开发文档\D4.6-…留痕-….md	追加 §3（不改正文）
本文件	标题 v6.28 → v6.29

五、判断更正（如实登记）

• 上一轮 §4.41 把画像出口误标为 FR-CS-003 —— 实际 FR-CS-003 是澄清（出口 E1），已更正两处。
• 上一轮建议「加一条金标」本轮未采纳：46 条是已发布指标的冻结基线（D2.6 / D3.7 的转人工率、出口准确率、事实正确率均按 46 条计算），中途加第 47 条会让已发布数字全部失效。改落在单元/集成守卫，覆盖等价、成本为零。演示后可再扩到 47 条并重算。

六、实测结果（全绿）

门禁	结果
pytest -q -p no:cacheprovider（全量）	1914 passed / 3 skipped / 0 failed（较 W13 基线 1909 +5，与新增用例数一致）
ruff check app tools tests	20，与 W13 基线一致（5 个改动文件均不在其中）⇒ 未引入新债
tools/check_authoritative_docs.py	54 文档无编号冲突（exit 0）
_consistency.py	GATE PASS
_eval_harness/http_probe.py（11 条真机全链路）	11/11；P0 建单 / P1 不建单 / P2 建单 三条行为逐条未变
_eval_harness/http_probe_w15_profile.py（本轮新增定向复验，9 条）	9/9 符合预期
tools/portal_api_check.py	40 项：通过 35 / 失败 0 / 跳过 5
tools/e2e_smoke_test.py --read-only	31/31（首次 21/22 是登录限流误报，等待 80 秒复跑即 31/31）
_fe_boundary_http.py	12/12
demo.ps1 -SkipStart -NoBrowser	五项自检全过、退出码 0

七、定向真机复验（本轮修复的直接证据）

用例	修复前	修复后实测
「我的风险测评结果是什么」	P1 →「无法读取本人账户数据」	✅ tools=['query_customer_profile']、无 P1_REPLY，答出「您的风险测评等级是 保守型（C1）」等五行
「我的测评结果」／「我的风险测评」	同上	✅ 同上
「我的风险等级是多少」	✅ 画像作答	✅ 无回归
「我的风险测评结果和持仓一起给我」	落 P3 ⇒ 只答画像、静默忽略账户那半句	✅ P1 → P1_REPLY（反向守卫生效）
「我的持仓有多少」／「我账户现在有多少钱？收益多少？」	P1	✅ P1（无回归）
「基金份额和风险等级有什么关系」（规则题）	—	✅ 走知识作答、未被误拦（新正则未扩大误伤面）
访客问「我的风险测评结果是什么」	—	✅ 引导登录（不返回任何画像数据）

八、临时产物：_w15_probe.py 已归档为 _eval_harness/http_probe_w15_profile.py。

九、待决 1 项（可选）：金标集是否扩容到 47 条 —— 建议演示后做。

v6.28 本轮修订要点（2026-09-20 · W15：厘清「客户能不能查本人持仓/交易/账户/画像与风评」→ 实测出 1 处文档矛盾 + 1 处路由缺陷）

触发：用户附 D2.2 §1.2.1 与 §1.4.5 两图提问。解释正本见 开发文档\D1.6-对话上下文提取与开工前补充决策-2026-09-17.md §4.41。

一、口径澄清（两条通道）

通道	本人持仓/交易/账户	本人画像/风评
门户自助（HTTP，*:read:self）	✅ 能（T001/T003/T006/T007/T009，前端 5 个页面已具备）	✅ 能
客服对话（Agent）	❌ 不能（FR-CS-023 P1，Agent 无权限读取）	⚠️ 部分能（FR-CS-003 画像出口，字段级只读）

二、P1 的真实行为：transfer_required=False —— 不建单，是「话术降级 + 指路自助」（H-04 口径，TRANSFER_REASON_ACCOUNT 保留但本期不发出）。四类白名单里真正建单的是 P0 / P2。

三、实测缺陷

#	问题	结论
1	🔴 FR-CS-023 的 P1 括号列表含「风险测评结果」，与 §1.2.1「客户能看自己的画像与风评」+ FR-CS-003 画像出口相反	文档自相矛盾，须修
2	🔴 路由抢跑：route_message() 在画像分支之前 ⇒ 「我的风险等级是多少」画像作答 ✅ ／「我的风险测评结果是什么」被 P1 拦成「读不到」❌	同一诉求两种结论，须修

四、待决 3 项（等用户裁定）

#	事项	我的最优建议
1	P1 裸词含「风险测评结果」	移除该裸词，把画像类字段显式划给 FR-CS-003；文档同句加「画像字段除外」
2	是否补金标	补：我的风险测评结果是什么 ⇒ 画像作答；反向守卫 我的持仓有多少 仍必须 P1
3	total_asset / behavior_score 是否渲染	维持不渲染，把理由（渲染=绕过 P1）写进文档与注释

v6.27 本轮修订要点（2026-09-20 · W14：D2.2 §1.4.3「域 C · 会话记忆」四条的解释与落地取证）

触发：用户附 D2.2 §1.4.3 截图提问「你先解释一下这部分的内容 并告诉我你是怎么做的」。解释正本见 开发文档\D1.6-对话上下文提取与开工前补充决策-2026-09-17.md §4.40。

一、为什么会有这四条

编号	设计意图（一句话）
FR-CS-013	双主体会话生命周期分离：客户可续期（30 分钟滑动、总上限 24h），访客匿名不给续期；renew: bool 显式传参是为禁止隐式续期
FR-CS-014	成本 + 上下文窗口双约束；按 token 对齐模型计费；「成对截断」避免把孤立回答喂给模型造成语义错位
FR-CS-015	合规前置：会话落库不可逆，脱敏必须在写入路径完成，保证「库里的字节本身就是安全的」
FR-CS-016	越权防护：session_id 属客户端可控入参，不带主体过滤即可横向读别人的会话

二、落地现状（如实登记，逐条读码取证）

编号	文档要求	实际实现	判定
FR-CS-013	Redis session:{session_id}:messages，TTL 30 分钟，客户续期 ≤ 24h，访客不续期，renew: bool	MySQL conversation_session + conversation_message（message_count / last_active_at）；Redis 仅用于限流与就绪探活	⚠️ 结构性替换（未按字面实现）
FR-CS-014	Token 预算客户 4096 / 访客 2048，按 token 从最旧成对截断	按条数控制：session_context[-6:]（max_length=6）、_recent_user_messages(limit=3)；无 token 计数代码	❌ 未实现
FR-CS-015	客户会话写 conversation_message（customer_id = user_id），归档前完成脱敏	直接写 conversation_message（无独立 conversation_archive）；sanitize_customer_service_message() 接线 12+ 处，accept() 内先脱敏再算幂等哈希	✅ 表名一致 + 脱敏链更严
FR-CS-016	仅返回当前登录用户自己的会话	GET /api/v1/conversations/{session_id}/messages 强制 customer_id == user_id；同口径覆盖 message() / feedback() / run_result()	✅ 完全落地

三、安全侧必须记住的两条

• 🔴 F-01（一期仅按 session_id 取历史 ⇒ 跨主体可读）已在新链路修掉 —— 修法是带主体过滤的新查询，不是恢复旧实现。
• 服务端重算 chitchat_streak / clarification_round / session_context 三字段（model_copy(update=...) 不做校验）；NO_LONG_TERM_MEMORY_AGENT_TYPES = frozenset({"customer_service"}) 使「客服永不写长期记忆」成为可测不变量（DEC-19）。

四、本轮待决 3 项（等用户裁定）

#	事项	我的最优建议
1	FR-CS-013 文档口径是否改写（Redis → MySQL 会话表）	改写并留痕（删原句 + 说明理由），避免答辩时「文档与代码不一致」
2	FR-CS-014 是否补 token 预算代码	不补代码、改文档口径（写明「按条数控制」的取舍），成本/风险最低且不留「写了没做」
3	是否补「跨主体查不到」的集成用例	补一条（A 的 session_id + B 的令牌 ⇒ 不返回 A 的消息），当前仅有「user_id 透传」单测

v6.26 本轮修订要点（2026-09-20 · W13：密钥轮换工具 + 两份目录的文档审计与口径校准）

本轮决议（用户 2026-09-20「现在就带你走一遍，然后你再检查一遍我这两个文件夹里的文档 看看还有什么需要完善和补充的」）。 完整会话记录见 开发文档\D1.6 §4.39。

一、新增密钥轮换工具（消除一个必须人工、易错、且已在会话中泄露过一次的操作）

#	修订	依据
1	✅ 新增 tools/rotate_api_keys.py（--check 体检 + 交互式轮换）：getpass 不回显、自动备份 .env.bak-<时间戳>（已被 ignore 命中）、三个 Qwen 变量写同一值 / 两个 DeepSeek 变量写同一值、校验不过则整体不写入、不落日志、不落任何文档	本轮实测
2	✅ --check 实测通过：QWEN_API_KEY / QWEN_EMBEDDING_API_KEY / DASHSCOPE_API_KEY 三变量 ✅ 同值且非空；DEEPSEEK_API_KEY / OFFSITE_DEEPSEEK_API_KEY 两变量 ✅ 同值且非空	本步实测
3	📌 边写边修（如实登记）：脚本初稿有两处硬伤 —— ① 第 75 行的提示语用了 ASCII 双引号包中文（"入库/检索"），直接 SyntaxError；② 文档字符串里 22 处「反斜杠 + 反引号」触发 SyntaxWarning: invalid escape sequence。均已修正并跑 ruff check + ruff format 通过	本步实测
4	📌 口径确认：model_endpoint_config.secret_ref 存的是变量名（env:QWEN_API_KEY / env:DEEPSEEK_API_KEY）而非值 ⇒ 轮换只改 .env，不需要动 DB；但必须重启 API + Worker，否则进程里仍是旧 key	连库实测 + 源码
5	✅ 新增操作手册 开发文档\D3.8-模型密钥轮换与凭据安全操作手册-2026-09-20.md（5 步 + 3 个坑 + 复核清单）	本轮用户要求「带一遍」

二、两份文档目录审计（用户要我「仔细推理还缺什么」）

#	发现	处置
1	🔴 docs\ 编号撞车：我方 docs\46 / docs\47（2026-09-20 建）与组员 docs\46-投顾Agent需求文档.md / docs\47-投顾Agent功能架构文档.md（2026-09-16 建）同号，tools/check_authoritative_docs.py（D3.4 N-14 登记的门禁）实测 FAIL	后到者让位：git mv 我方两份 → docs\48-可改文件白名单.md / docs\49-底座会签申请单-2026-09-19.md，并同步 8 处引用（含仓库内自引用）
2	🔴 前端品牌残留 2 处：employee-advisor/dashboard/index.html 与 customer/advisor-plans/index.html 的 <title> 仍是 南方财富（投顾组分支带回）	按 DEC-27（已批「改，并升 P1」）改为 南方基金；全仓 app\ 复查 南方财富 = 0
3	🔴 D1.1 索引版本号严重过期：§4.0 总表与 §4.1 明细把 D2.1 记为 v5.3（实际已 v6.25）	同步为现行版本，并新增 §22（第十八、十九轮）留痕
4	🔴 三份 HTML 交付文档口径过期：D2.2/D2.3/D2.4 仍写「投顾已清除」（W12 已恢复）；D2.2 顶栏徽标 v2.4 与文档元数据 v2.5 自相矛盾；D2.3 徽标 v1.0 · 7 批次 51 项 也过期	全部加「2026-09-20 状态更新」口径；徽标更正为 v2.5 / v1.1 · 8 批次 57 项。关键区分：投顾模块恢复 ≠ 客服可承接投顾能力 ⇒ §1.7 范围与 RK-10 裁定不变
5	🟡 D2.5/D2.6 内部矛盾：D2.5 §2.1 先写「不要念 advisor_t，库里不存在」，同段又写「已重建、重新有效」	改写为一张表的行 + 一段口径更正（可登录，但本演示仍只演游客线 + 客服线）
6	🟡 D2.6 门禁数字落后一轮：仍写 1856 passed / 2 skipped、ruff 19	更新为 1909 / 3 skipped、ruff 20，并补 portal_api_check 行
7	🟡 D2.6 §10 两项已闭环却仍列在「未做项」：密钥轮换（已工具化）、A-10 组 3/4 签字（2026-09-20 已补签）	两项改为「已闭环」，并新增 D3.8 / D4.7 交叉引用
8	🟡 D1.1 §8「遗留与待决」三行已过期：D-5 前端品牌面、D-7 语料入库门禁、开发文档\ 仓库副本未同步	逐行标注已执行 / 已实现 / 已同步，并保留 2 处真实残留
9	🟡 D1.1 §10.2 表述过期：「本区不在任何 git 仓库内」	更正为已入库（W12），并说明「移动/改名必须先整包备份」的理由仍成立
10	🟢 新增 开发文档\D4.7-投顾模块恢复记录-2026-09-20.md：D4.4/D4.5 是「清除」视角，恢复视角此前只在 D4.5 顶部状态更新里	独立成文，给「删了又恢复」这个答辩必问点一份唯一现状态文档
11	🟢 _consistency.py §三 口径同步：原文假设「投顾命中必须出现在『已清除』语境」，恢复后会误报	改为「投顾状态口径检查」，合法语境扩为 清除史 / 恢复史 / 不属本 Agent 范围，并在表头写明判读规则
12	📌 一处未做（如实登记）：投顾 config_release 工具白名单（advisor:*）当前未发布 ⇒ 投顾 Agent 工具调用 fail closed（实测 active_agent_tools 只有 customer_service:* 与 risk:*）。与客服线无关；要演投顾线先跑 tools/publish_advisor_demo_config.py --apply	连库实测

看板状态更新：客服线 57 项全部有终态（55 项落地 / 2 项按裁定挂起）；本轮为交付面收口（工具 + 手册 + 索引校准），未新增批次任务。剩余为答辩后当轮的 1 项动作：跑 tools/rotate_api_keys.py 轮换两把 key（见 D3.8）。

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/48-可改文件白名单.md（四类 + 零 DDL 声明 + 实际改动对照表）、docs/49-底座会签申请单-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-01B-04 / D-01D-05 / F-01 / H-05
域 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-19 W10 已按 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 的逐行实证行号漂移、承诺改动后复核那些结论。