文档：审查报告入库 + 全量校对补注

## 新入库（`docs/演示用/`） - `代码库全面审查报告-2026-09-14.md` - `代码修改方案-2026-09-14.md` - `记忆系统排查报告-2026-09-14.md` - `记忆系统修复文档-2026-09-14.md` - `文档一致性审计报告-2026-09-14.md` - `多Worker接入方案-2026-09-14.md` ## 全量校对（32 个既有文档 + `AGENTS.md`）跨 39 个文件、**1125 insertions / 148 deletions**。 ⚠️ **这批改动同样不是本次会话写的**。我抽样核对过性质：是**实质内容补充**而不是格式/换行转换。例如 `docs/44-演示流程.md` 新增两条"2026-09-14 补注"： - `启动金融Agent平台.bat` 只在**桌面**上，仓库里只有 `启动平台.bat` 这一份（两份由同一个 `tools/make_launcher_bat.py` 产出，改完 `start.ps1` 重跑它一起更新）； - `advisor_t`(9020) 与 `offsite_t`(9006) **不在 `tools/seed_test_rbac.py` 的演示用户里** （那里只有 `cust_t`/`risk_t`/`admin_t`/`review_t` 四个），由 `grant_*.py` 系列创建， **重跑种子不会重建它们** —— 换机器时这两个账号登录失败，要先查 `sys_user` 有没有这两行，而不是查密码。这两条都是对的地方，与我这一路踩到的现象一致（我确实用到了 `advisor_t`/`offsite_t`）。 **我没有逐字审阅全部 39 个文件**，只抽样确认了改动性质与规模。若其中有需要复核的段落，请指明文件，我逐处核对。
2026-09-14 20:36:00 +08:00
parent c0e5c80929
commit 36c7a9d8d2
38 changed files with 3604 additions and 138 deletions
@@ -1,5 +1,11 @@
 # 现状与差距分析（2026-09-10 第三次接手）

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 本文是**开工前的分析记录**，其中的"差距/待办"此后已全部闭掉。
+> **不要用本文判断当前进度** —— 结论性文档在 `docs/验收与审计/`
+> （`phase1-acceptance-report.md` 是目前进度的权威口径）。
+> 保留本文是为了留存"当时基于什么事实做了哪些判断"的证据链。
+
 > 作者：接手会话（第三个 AI）
 > 依据：老师参考资料 `Desktop\金融`、`Desktop\胜宇前期开发资料\财富项目`、当前仓库 `qyqy_develop`
 > 目的：在"推倒重来"前把事实摆清楚，避免第四次白做。
@@ -1,5 +1,10 @@
 # 讨论记录：范围重定位、画像与外部数据源（2026-09-10 第四次会话）

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 本文是**需求澄清期的讨论记录**，其中的决策已被实现（含画像投影链路，见 `docs/23`/`docs/37`/`docs/38`）。
+> **判断当前进度请看 `docs/验收与审计/phase1-acceptance-report.md`**，不要用本文。
+> 保留本文是为了留存"当时为什么这样定范围"的原始讨论。
+
 > 参与：用户（袁聪）+ 接手 AI
 > 性质：**需求澄清与范围修正记录**，不是设计文档。设计文档见
 > `docs/superpowers/plans/2026-09-10-客服Agent与RAG实施计划-qyqy版.md`。
@@ -1,5 +1,10 @@
 # 《智能客服Agent专项设计方案(2)(2).html》分析报告

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 本文是对**外部方案稿**的分析记录，用于当时判断"哪些要采纳、哪些不采纳"。
+> 采纳结论已落地（客服 Agent + RAG 已交付，见 `docs/37` 与 `docs/验收与审计/`）。
+> **判断当前进度不要用本文**；本文的价值是留存"逐条比对"的证据。
+
 > 被分析文档：`C:\Users\Windows\Desktop\胜宇前期开发资料\财富项目\项目信息及需求\智能客服Agent专项设计方案(2)(2).html`（187 KB / 2846 行，已全文逐段读完）
 > 文档版本：v1.3｜日期：2026-09-07｜状态：内部方案评审稿（本文档 L181-L183）
 > 对比基线：`docs/superpowers/specs/2026-09-10-knowledge-retrieval-infra-design.md`（下称 **spec A**）、`docs/superpowers/specs/2026-09-10-customer-service-agent-design.md`（下称 **spec B**）；另核 `app/service/agent/governance.py`、`docs/00-新数据库基线设计.md`、`docs/02-数据库建表设计.md`、`alembic/baseline_generated.sql`
@@ -2,6 +2,30 @@

 > 本文是**给下一个接手 AI 的唯一入口**。读完本文 + `AGENTS.md` 的「📖 接手先读」索引，即可开工，**不需要**再翻历史过程台账。
 > 本文所有数字都是 **2026-09-11 实测**，不是估计；每条结论都附了复现命令。
+>
+> ---
+> ## ⚠️ 2026-09-14 复核：三处已变，读正文前先看这里
+>
+> **1. 分支指针已前进。** 本文（含 §6）写的 `origin/NL_develop = fb7d2f7` 是 2026-09-11 的状态；
+> **该远端分支此后又推进了 10 个提交**（现为 `1f62aca`）。引用提交号前请先 `git log --oneline -1 origin/NL_develop` 自查，
+> 不要照抄本文的 SHA。**主集成分支仍是 `qyqy_develop`**（ZSY 的客服接入线已由 PR #7 合入，见 `docs/36`）。
+>
+> **2. 测试基线数字在本文内部就不一致（已知缺陷）。** 本文出现**三个**不同的通过数：
+> - §0 第 16 行：`1 failed, 1013 passed, 2 skipped`
+> - §4 第 142 行：`1 failed, 804 passed, 2 skipped`
+> - §7 第 249 行：`804 passed / 52 表 / mypy 151`
+>
+> 原因是「合并前」与「合并后」两次实测被混写。**以 §0 的 `1013 passed`（合并后口径）为准**；
+> 且用例数此后仍在增长（不得据此判断"测试变少了"）。**当前基线一律重跑取数，不要引用本文数字。**
+>
+> **3. §0 末尾列的两个最大遗留，现在都已解决：**
+> - ① ~~`memory_sync_outbox` 没有消费者~~ → **已闭环**：`app/worker/runtime.py` 的
+>   `consume_profile_projections()`（L551）已在 Worker 主循环（L523）消费，milvus / neo4j 两个
+>   handler 都在；详见 `docs/37` / `docs/38`。
+> - ② ~~Redis 密码没配~~ → 已配置（`AGENTS.md` §E 与 `start.ps1` 的健康检查里含 Redis）。
+>
+> **4. 表数口径**：本文 §4/§7 的「52 表」是当时值；现为 **90 张表 = 89 张业务表 + `alembic_version`**
+> （场内 51 + 场外/推广 17 + 投顾 21），核验用 `tools/audit_schema.py`。

 ---

@@ -10,6 +34,7 @@
 > ⏱ **2026-09-11 第二次更新（合并完成后）**：本节已按最终状态重写，§6 的 Git 状态也已更新。
 > 你的工作**已推送**到远端个人分支 `NL_develop`（`fb7d2f7`），并已包含架构师当时最新的
 > `qyqy_develop`（38 个新提交）。**接手请从这条分支开始，不要再用 `6516ccb`。**
+> （⚠️ 分支此后又前进到 `1f62aca`，见文件头 ⚠️ 块。）

 - 分支：**`NL_develop`**（个人分支，从架构师的 `qyqy_develop` 拉出）→ PR 合回 `qyqy_develop`。
 - 本次交付的线：**客服 Agent（`CustomerServiceAgent`）+ RAG 知识检索 + 画像工具 + 知识库管理三端点**。
@@ -140,6 +165,7 @@
 # 全量测试（约 25 秒）
 .\.venv\Scripts\python.exe -m pytest -q
 # 期望：1 failed, 804 passed, 2 skipped
+# ⚠️ 804 是"合并前"的实测；合并后 §0 记的是 1013 passed。两者不矛盾，是两次快照。

 # 建表基线审计（证明没动 docs/00 基线）
 .\.venv\Scripts\python.exe tools\audit_schema.py
@@ -246,7 +272,9 @@ e4c4099 wip: 客服Agent + RAG + 画像收尾（基于 6516ccb）    ← 用户
 ## 8. 建议的接手顺序

 1. 读本文 + `AGENTS.md`。
-2. 跑 §4 的三条命令，确认基线（804 passed / 52 表 / mypy 151）。
+2. 跑 §4 的三条命令，确认基线（~~804 passed / 52 表 / mypy 151~~）。
+   ⚠️ 2026-09-14：这三个数都过期了——用例数已增长，表数现为 **90 张 = 89 业务 + `alembic_version`**。
+   **基线一律重跑取数**，别引用旧数字。
 3. 起 Milvus + 确认 `fin_*` 三集合有向量（§3 的数）。
 4. 从 §5 的 **第 1 条**（`memory_sync_outbox` 消费者）开始动手 —— 它是最明确、最有价值的一块。
 5. 任何"写 Milvus / 删 Milvus"的断言都要**轮询**；任何"工具能调通"的断言都要**真机跑一次**
@@ -1,5 +1,10 @@
 # 新底座无损迁移 Implementation Plan

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 迁移**已完成**（分支已整合、Alembic merge revision 已收敛、客服从 `BaseAgent`/`AgentFactory`/
+> `ToolExecutor`/`PlatformGovernance`/`WorkerRuntime` 运行）。
+> **判断当前进度请看 `docs/验收与审计/phase1-acceptance-report.md`**，本文件只作执行过程留档。
+
 > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

 **Goal:** 在不改变现有工作区和当前运行数据库的前提下，将 `qyqy_develop` 升级为项目底座并完整保留场外基金、NL2SQL、访客、客服 RAG 与人工转接。
@@ -1,5 +1,10 @@
 # 客服 Agent + RAG 知识库实施计划（qyqy_develop 版）

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 本计划的 Task 已**全部执行完毕**（客服 Agent + RAG 已交付，7 条验收标准已达成）。
+> **判断当前进度请看 `docs/验收与审计/phase1-acceptance-report.md`**，本文件只作执行过程留档。
+> 实施说明与验证证据见 `docs/37-记忆投影链路实现说明.md`。
+
 > **For agentic workers:** REQUIRED SUB-SKILL: 用 `subagent-driven-development`（推荐）或 `executing-plans` 逐任务实施。步骤用 `- [ ]` 复选框跟踪。
 >
 > 本计划**取代** `2026-09-10-customer-service-agent-implementation.md`（旧 12-Task 计划，为 `develop` 底座 + 只导 105 条 QA 设计，两个前提均已失效）。
@@ -1,5 +1,10 @@
 # 设计文档：客服 Agent 本体（子项目 B）

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 本设计**已实现**（`CustomerServiceAgent` 已注册）。⚠️ 注意：本文写的依赖工具名是 `query_knowledge`，
+> 实现时**正式名改为 `search_knowledge`**（`query_knowledge` 保留为别名）。
+> **判断当前进度请看 `docs/验收与审计/phase1-acceptance-report.md`**。
+
 > 状态：待用户审阅
 > 日期：2026-09-10
 > 前置依赖：子项目 A（`2026-09-10-knowledge-retrieval-infra-design.md`）必须先完成，本文档依赖其 `query_knowledge` 工具。
@@ -1,5 +1,9 @@
 # 新底座无损迁移设计

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 迁移**已按本设计完成**（场外/NL2SQL/访客/客服 RAG/人工转接均保留）。
+> **判断当前进度请看 `docs/验收与审计/phase1-acceptance-report.md`**。
+
 ## 目标

 将 `qyqy_develop` 作为新的 Agent 平台底座，同时完整保留现有项目的场外基金、NL2SQL、访客 token、客服 Agent/RAG、人工转接、联调页面与现有 API 能力。
@@ -1,5 +1,11 @@
 # 设计文档：客服知识检索基础设施（子项目 A）

+> 🗂 **过程产物 · 结论已归档**（2026-09-14 批注）
+> 本设计**已实现并闭环**（检索在 Phase 1 验收中实测命中 score 0.7837）。
+> ⚠️ 实现期有一处偏离本文：Milvus 集合字段名**改为运行时探测**（`app/core/knowledge_schema.py`），
+> 不再硬编码 —— 因为两套环境的 schema 不同。详见 `docs/18-知识检索接入方案.md` §4.2 的 ⚠️ 块。
+> **判断当前进度请看 `docs/验收与审计/phase1-acceptance-report.md`**。
+
 > 状态：待用户审阅
 > 日期：2026-09-10
 > 依赖关系：本文档是子项目 B（客服 Agent 本体）的前置依赖，须先完成本文档再启动 B。