zhanghongyu_0626
2296a4a002
- Introduced `convert_meta_api` endpoint to fetch the latest NAV date for conversion processes, restricted to users with the "risk_officer" role. - Updated `created_at` field in `AgentMessage` to use UTC timezone for consistency in timestamp handling. - Added `get_max_product_nav_date` method in `CoreReadOnlyRepository` to support the new API functionality. - Enhanced Milvus template loading in `MilvusTemplateVectorStore` to ensure collections are loaded when they exist. This update improves the API's capability to handle conversion metadata and ensures accurate timestamp management across the application.
27 KiB
27 KiB
企业级测试日志 · TEST-2026-09-12-ADV-001
投资顾问 Agent（代理人 Agent）·
/api/advisor-agent/*全端点真实 HTTP 端到端冒烟
1. 文档元数据
| 字段 | 值 |
|---|---|
| 测试记录编号 | TEST-2026-09-12-ADV-001 |
| 缺陷/变更标题 | 顾问线全景端到端验收：63 用例 · 60 PASS / 3 FAIL / 0 SKIP · D1 已关闭，D2/D3 未修 |
| 文档版本 | v1.2 |
| 创建日期 | 2026-09-12 |
| 最后更新 | 2026-09-12（v1.2 · 基线已随 merger 改写 · D3 计数口径更正） |
| 关联分支 | merger（v1.0 时为 integrate/advisor-agent；该分支已合入 merger） |
| 关联拍板 / TODO | 合并说明 §6.3 Scope B 冒烟 · D1~D9 · docs/memory/TODO.md「顾问 Agent 合并」批 |
| 风险等级 | MEDIUM（v1.0 为 HIGH —— 市场异动线已随 D1 修复恢复，剩余 KYC 采集与语义检索两项降级） |
| 缺陷类型 | |
| 发现阶段 | 真实 HTTP 端到端验收（首轮 v1.0 · v1.1 为合并后基线复跑） |
| 修复阶段 | D1 已修复（03fce88）· D2/D3 未修复 —— 本轮定性仍为「先报告、确认后再修」 |
2. 组织与责任
| 字段 | 值 |
|---|---|
| 所属系统 | JinRong 金融四 Agent 智能管家 |
| 所属模块 | 投资顾问 Agent（顾问工作台后端线 · 源分支 xinghuo/advisor-agent） |
| 子模块 / 服务 | advisor_compliance · advisor_script_templates · kyc · market · copy · guard · dashboard/allocation 桩 |
| 模块负责人 | （合并中 · 见 docs/项目框架设计/理财顾问Agent-合并说明.md） |
| 发现人 | Andrew |
| 修改人 | （未修改 · 待确认后再修） |
| 测试执行人 | Andrew |
| 评审人 | （待模块负责人确认） |
| 发布建议 | v1.1 订正：merger |
3. 环境与基线
| 字段 | 值 |
|---|---|
| 测试环境 | development · 本机 Windows 11 · Python 3.13.9 |
| 被测版本 | v1.1：merger @ c09b987（feat(web): 基金转换演示页与 agent 镜像表迁移; Core seed 修复）—— 本轮复跑前已确认 :8000 上无 merge 前的旧进程（/openapi.json 含 convert 路径），git status 干净 |
| v1.0 被测版本（存档） | integrate/advisor-agent @ 64c5db7 —— 该分支已合入 merger，v1.0 的结论仅对旧基线成立 |
| 基线变化（v1.0 → v1.1） | 03fce88 把「基金转换 T+1」整条线并入 merger（110 文件），并在 app/repository/core_ro.py:839,851 补上 list_product_nav_history / list_latest_product_navs —— 这正是 D1 的修复点。c09b987 再补 RiskConvertPage 前端与迁移 |
| 被测服务 | python -m uvicorn app.main:app --host 127.0.0.1 --port 8000（真实进程 · 无 --reload） |
| 数据库 | MySQL jinrong_agent（29 表）+ jinrong_core（12 表）· 顾问 7 张专用表已迁移 |
| 种子 | compliance_rule 50 条 · script_template 20 条（全 is_approved=1）· core_customer 33 · core_customer_advisor 33 · core_product 14 · core_product_nav 5110 行（NAV 最新 2026-09-04） |
| Redis | Docker 6380 · /api/ready = {"ok":true,"degraded":false} |
| Ollama / Milvus | bge-m3（1024 维）已就绪 · Milvus Lite C:/Users/Windows/.jinrong/milvus/milvus.db |
| DeepSeek | 有效 key · market-alerts/generate 必经（失败回退安全模板） |
| Neo4j | 未启动 —— 顾问链路在 app/ 中无任何引用，不依赖 |
| 特性开关 | COMPLIANCE_AI_ENABLED=false · KYC_AI_ENABLED=false（硬规则 + 确定性解析，结果可复现） |
| 基线对照 | python -m pytest → MEMORY §0 记 926 passed / 65 failed（红均为顾问 test_sprint*） |
| 本轮口径 | 真实 HTTP + 真实 MySQL；现有 pytest 全部为 TestClient 进程内 + 内存 SQLite，无任何测试打到真实服务 |
4. 测试目标与方法
| 字段 | 值 |
|---|---|
| 目标 | 只测 API、忽略前端；把 /api/advisor-agent/* 全部 24 个端点逐个打通 |
| 方法 | 真实 uvicorn + 真实 JWT，逐端点正向 + 边界（越权 403 / 注入拦截 / 合规 BLOCK·WARN 门闸） |
| 账号 | advisor STAFF-10086 · compliance STAFF-40001（多 template:write/compliance:rule:write）· analyst STAFF-20001 |
| 脚本 | scripts/dev/advisor_e2e_smoke.py（可重复 · --only G6 单组重跑 · 退出码非 0 即有 FAIL） |
| 用例总数 | 63（G1 鉴权封套 5 · G2 合规 14 · G3 复制门闸 5 · G4 话术模板 12 · G5 市场异动 10 · G6 KYC 10 · G7 输入防护 3 · G8 桩路由 2 · G9 跨线回归 2） |
5. 结果总览
v1.1 复跑结果（当前基线
merger @ c09b987）：60 PASS / 3 FAIL / 0 SKIP 复现：python scripts/dev/advisor_e2e_smoke.py（退出码 1 = 有 FAIL）
| 指标 | v1.1（当前） | v1.0（存档） |
|---|---|---|
| PASS | 60 | 53 |
| FAIL | 3（收敛为 2 个缺陷：D2 / D3） | 5（3 个缺陷） |
| SKIP | 0 | 5（全部被 D1 阻断） |
| 可判定率 | 63/63（100%） | 58/63 |
| 业务线 | 状态（v1.1） | 相较 v1.0 |
|---|---|---|
| 鉴权 / RBAC / 封套 / Trace | ✅ 正常（含越权 403、未知账号 fail-closed、Trace 双向回显） | 不变 |
| 合规检测 + 规则库 | ✅ 正常（keyword/regex 硬规则、BLOCK/WARN/INFO 分级、AI 层降级） | 不变 |
| 复制门闸 | ✅ 正常（BLOCK / WARN 未确认 / hash 一致性 三种门闸全生效） | 不变 |
| 话术模板 CRUD / 使用 / 合规前置 | ✅ 正常（未审核不可用、改内容回落审核态、违禁文案创建被拦） | 不变 |
| 输入防护 | ✅ 正常（注入 40002 且不落库） | 不变 |
| 跨线回归（适当性 / 问数） | ✅ 未被顾问线破坏 | 不变 |
| 市场异动（行情/扫描/解读/反馈） | ✅ 已恢复（10/10 PASS） | 🔴→🟢 由 D1 修复 |
| KYC 对话采集 | ❌ D2 阻断，采集不可用 | 不变 |
| 话术语义检索 | ⚠️ D3 静默降级为纯关键词 | 不变（但根因经本轮实测订正） |
6. 缺陷描述（3 条 · D1 已关闭 · D2/D3 未修复）
D1 · 顾问市场数据 Provider 与 merger Core 仓储接口不一致（阻断 · P1 → 已修复 ✅）
v1.1 状态：CLOSED（由
03fce88修复；merger @ c09b987实测转绿）
项 内容 修复证据（代码） app/repository/core_ro.py:839新增list_product_nav_history、:851新增list_latest_product_navs，与app/service/market_data_service.py:40,61的调用签名对齐修复证据（实测） G5 市场异动 10/10 PASS，含 异动扫描 → 200 scanned=14 created=2 skipped=12、异动解读 → 四段式 used_fallback=False latency=1415；v1.0 时这两项为 500连带解除 v1.0 因 D1 而 SKIP 的 5 项全部恢复可判定，本轮 SKIP = 0 仍潜伏 app/service/agent_tools.py:70的同款错误调用仍在（见下方 D4 记录），当前无 HTTP 入口故不计入分母以下为 v1.0 原始记录，仅作历史存档。
| 字段 | 内容 |
|---|---|
| 缺陷编号 | DEF-ADV-2026-09-12-001 |
| 严重等级 | P1（市场异动整条业务线不可用） |
| 现象 | GET /api/advisor-agent/market/fund/{code} 与 POST /api/advisor-agent/market-alerts/scan 双双 500 |
| 复现 | POST /api/advisor-agent/market-alerts/scan {"nav_date":"2026-09-04","threshold_pct":1.0} |
| 期望 / 实际 | 200 + 行情/扫描结果 / 500 INTERNAL_ERROR |
| 根因 | app/service/market_data_service.py 调用的是顾问源分支方法名，与 merger app/repository/core_ro.py 对不上：:40 调 list_product_nav_history(id, limit=N)，merger 实为 list_nav_history(id, *, days=N, end_date=None)（:499）——方法名与关键字参数名都不同；:61 调 list_latest_product_navs(nav_date=N)，全仓库不存在此方法。线上异常实测：AttributeError: 'CoreReadOnlyRepository' object has no attribute 'list_product_nav_history' / ... 'list_latest_product_navs' |
| 半途痕迹 | _to_nav_point()（:100-111）已改为读 merger 的 daily_chg_pct 字段 —— 合并时改了字段名但漏改方法名 |
| 波及 | scan 不可用 ⇒ 无 alert 落库 ⇒ 异动列表 / 异动解读 / 反馈闭环 4 项后续用例全部 SKIP |
| 同类潜在缺陷 | app/service/agent_tools.py:70 同一错误调用。当前仅被 app/service/agent_graph.py:158 引用，LangGraph 未挂任何端点故暂未暴露，接线即 500 |
| 为何测试没拦住 | tests/test_sprint2_market_alert_scan.py 用 FakeMarketDataProvider、tests/test_step10_agent_tools.py:97 用 MagicMock —— 顾问侧测试全部把 Core 提供方 fake 掉，真实 CoreReadOnlyRepository 契约从未被任何测试校验 |
| 修复方向（待确认） | 改调 list_nav_history(product_id, days=history_limit)；为 list_latest_product_navs 在 core_ro.py 补只读实现（按 nav_date 取各产品最新净值 + join core_product 取 product_name/product_type/min_risk_code），或在 market_data_service 内改为逐产品组合 |
D2 · KYC 对话写 agent_message 时 created_at 显式传 NULL（阻断 · P1）
| 字段 | 内容 |
|---|---|
| 缺陷编号 | DEF-ADV-2026-09-12-002 |
| 严重等级 | P1（KYC 采集不可用；建会话/越权拦截/完成均正常，唯采集一步挂） |
| 现象 | POST /api/advisor-agent/kyc/sessions/{id}/chat 500 |
| 复现 | 建会话 → {"customer_input":"客户今年28岁，女性，未婚"} |
| 期望 / 实际 | 200 + parsed_fields / 500 INTERNAL_ERROR |
| 根因 | app/repository/kyc_session_repository.py:138-159 用 ORM 实体写 agent_message，构造 AgentMessage(...) 未给 created_at；app/model/entities.py:116 该映射列无 Python 侧 default（同表 has_disclaimer 有 default=False 作对照），SQLAlchemy 遂以显式 NULL 写入 —— 显式 NULL 覆盖了 DDL 默认值。实测 pymysql.err.IntegrityError: (1048, "Column 'created_at' cannot be null") |
| 关键对照 | 表 DDL 本身正确：created_at datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3)。宿主链路因走裸 SQL 且不列该字段而正常吃到默认值（app/repository/session_repository.py:184 · app/repository/agent_repository.py:73） |
| 性质 | 同一张表，宿主用裸 SQL（OK）、顾问用 ORM（炸） —— 合并引入的第二套写入姿势不一致 |
| 修复方向（待确认） | 实体列补 default=lambda: datetime.now(UTC)（或 server_default=text("CURRENT_TIMESTAMP(3)")），或在 kyc_session_repository 显式传 created_at。前者更根治且不影响宿主裸 SQL 链路 |
D3 · Milvus 集合从未 load()，语义检索永久静默失效（降级 · P2）
v1.1 复核定论：根因维持 v1.0 原判 —— 且本轮由服务端日志直接坐实。
v1.1 开工前曾提出一条相反的假设并写入 plan：
app/tool/milvus_template_tool.py:136-137用的是 pymilvus 高层MilvusClient，该 API 在 search 时自动 load，不需要显式load_collection，因此match_type恒为keyword更可能是「集合根本没灌向量」。该假设经本轮实测被证伪：
证据 内容 服务端日志（决定性） 被测进程 uvicorn日志中MilvusException: (code=101, message=Collection 'kb_script_templates' is in state 'released'; call load() before search/get/query)—— 5 次独立异常（18:19:25 / 18:25:08 / 18:28:35 / 18:31:42 / 18:34:20），且全 session 无其它 Milvus 错误类型。⇒ 检索确实卡在released状态，高层 client 并未自动 load⚠️ 口径更正（2026-09-12 晚） 本文初版此处写作「出现 10 次」—— 该数字实为日志行数（5 次异常 × 2 行：RPC-error + traceback），不是异常次数。FE-001 收口时按日志原件重新点数为 6 次（本文覆盖时段内 5 次 + 其 18:55 复现验证 +1）。D3 结论不变。日志原文摘录： ../2026-09-12-agent-frontend-e2e/_raw/server-log-evidence.md§2前端侧同一现象 浏览器 E2E 09-advisor-pages.mjsA3.2：搜「亏损」返回 4 行，match_type全为keywordAPI 侧同一现象 G4 Milvus 语义检索生效FAIL：实际仅['keyword']并存的第二层（本轮新增观测） Milvus Lite 数据目录中 kb_script_templates仅 5.0K / 2 文件，而已灌入的fin_faq/fin_policy/fin_product各为 50K / 5 文件 ⇒ 该集合很可能同时是空集。故仅补load_collection未必能让语义召回生效，需一并确认向量已灌结论（订正后）：D3 是两层叠加 —— ①集合状态
released未 load（日志已证）；②集合疑似未灌向量（目录体量佐证，未做写入验证）。修 ① 后可消除异常，但是否恢复语义召回取决于 ②。建议修复后以match_type出现semantic/hybrid作为验收口径，而非仅看异常消失。
| 字段 | 内容 |
|---|---|
| 缺陷编号 | DEF-ADV-2026-09-12-003 |
| 严重等级 | P2（不报错、不 5xx，但能力增量归零） |
| 现象 | GET /api/advisor-agent/script-templates/search 返回 200 但 match_type 恒为 keyword，从不出现 semantic/hybrid |
| 根因 | app/tool/milvus_template_tool.py 只调 has_collection（:50）与 create_collection（:72），全文件无 load_collection。集合跨进程后状态为 released，检索即报 MilvusException (code=101) Collection 'kb_script_templates' is in state 'released'; call load() before search/get/query（v1.1 实测日志 5 次独立异常 —— 初版误记为「10 次」，见上表口径更正；FE-001 时点心为 6 次） |
| 第二层因素 | 集合目录体量 5.0K/2 文件 vs 已灌集合 50K/5 文件 ⇒ 疑似空集，见上方 v1.1 复核 |
| 为何静默 | 该异常被 search_templates 的 except MilvusToolError 吞掉并降级为关键词检索（64c5db7 刻意加的兜底，方向正确），但降级无任何显式标记 —— 日志有异常、HTTP 无异常、响应体无 degraded 字段，调用方无从得知 |
| 影响 | 话术「混合检索」退化为「纯 LIKE 关键词」，同义/近义召回为零。实测 q=市场 仅召回 1 条 |
| 修复方向（待确认） | ①ensure_template_collection() 或 client 构造后补 load_collection(collection_name)；②确认 kb_script_templates 已灌向量（python scripts/sync/sync_template_vectors.py）；③在响应或日志显式标记语义层降级 |
7. 测试执行记录（明细）
| 分组 | 覆盖端点 | v1.1 结果 | v1.0 存档 |
|---|---|---|---|
| G1 鉴权与封套（5） | POST /api/auth/login · 无 token · Trace 透传 · envelope |
5 PASS | 5 PASS |
| G2 合规检测（14） | POST /compliance/content-check · GET/POST/PUT/DELETE /compliance/rules |
14 PASS | 14 PASS |
| G3 复制门闸（5） | POST /copy/track |
5 PASS | 5 PASS |
| G4 话术模板（12） | GET "" · GET /search · POST/PUT/DELETE · POST /{id}/use |
11 PASS / 1 FAIL（D3） | 11 PASS / 1 FAIL |
| G5 市场异动（10） | GET /market/fund/{code} · GET/POST /market-alerts · POST /scan · POST /generate · PUT /{id}/feedback |
10 PASS / 0 FAIL / 0 SKIP ✅ | 3 PASS / 2 FAIL / 5 SKIP |
| G6 KYC（10） | POST /kyc/sessions · GET/POST /sessions/{id}[/chat] · /complete |
8 PASS / 2 FAIL（D2） | 8 PASS / 2 FAIL |
| G7 输入防护（3） | POST /guard/check |
3 PASS | 3 PASS |
| G8 桩路由（2） | /dashboard/ping · /allocation/ping |
2 PASS（仅桩，无业务实现） | 2 PASS |
| G9 跨线回归（2） | POST /api/compliance/suitability-check · POST /api/analyst/chat |
2 PASS | 2 PASS |
7.0 v1.1 G5 由红转绿（D1 修复的实测证据）
| 用例 | v1.0 | v1.1 |
|---|---|---|
G5 基金行情 → 200 |
500 | ✅ 200 nav=1.0 nav_date=2026-09-07 daily_return=0.0 |
G5 异动扫描 → 200 |
500 | ✅ 200 scanned=14 created=2 skipped=12 dup=0 |
G5 异动扫描去重 |
SKIP（被 D1 阻断） | ✅ duplicated=2 |
G5 异动列表 |
SKIP | ✅ n=2 |
G5 异动解读 → 四段式 |
SKIP | ✅ used_fallback=False latency=1415 |
G5 反馈 dismiss |
SKIP | ✅ status=dismissed |
7.1 关键边界用例（全部 PASS）
| 用例 | 期望 | 实际 |
|---|---|---|
| 未知账号登录 | 401 AUTH_401_UNKNOWN_ACTOR |
✅ fail-closed |
| advisor 读/写规则库 | 403（无 compliance:rule:write） |
✅ AUTH_403_PERMISSION |
| advisor 写话术模板 | 403（无 template:write） |
✅ AUTH_403_PERMISSION |
| KYC 建会话越权客户 | 403 40302 |
✅ 归属校验前置生效 |
| 提示词注入（guard） | 400 40002 prompt_injection |
✅ |
| 提示词注入（KYC 对话） | 400 40002 且不落库 |
✅ agent_message 计数 0→0 |
| 复制门闸 BLOCK | 403 40302 |
✅ |
| 复制门闸 WARN 未确认 | 400 40002 |
✅ 确认后放行 |
| 复制门闸 check_id 与 hash 不符 | 400 40002 |
✅ |
| 使用未审核模板 | 400 拒绝 | ✅ |
| 违禁文案建模板 | 400 40002 合规前置拦截 |
✅ |
| 重复完成 KYC 会话 | 409 40901 |
✅ |
7.2 失败明细
v1.1 失败明细（3 条 · 收敛为 2 个缺陷）：
| 用例 | 期望 | 实际 | 缺陷 |
|---|---|---|---|
G4 Milvus 语义检索生效 |
match_type 含 semantic/hybrid |
仅 ['keyword']（已降级为纯关键词） |
D3 |
G6 对话采集推进进度 |
200 且 parsed_fields 非空 progress_pct>0 |
500 parsed=None pct=None |
D2 |
G6 skip_to 回退节点 |
200 且 current_node=basic_info |
500 node=None |
D2 |
v1.0 存档：另有 G5
基金行情 → 200、G5异动扫描 → 200两条 500，均随 D1 修复转绿（见 §7.0）。
7.3 跳过明细
| 用例 | 阻塞原因 |
|---|---|
| —— | v1.1 无 SKIP —— v1.0 的 5 条 SKIP 全部由 D1 阻断所致，D1 修复后已恢复可判定 |
8. 非缺陷澄清（易误判项）
| 项 | 结论 |
|---|---|
| 探针文案「保证赚钱，绝对不会亏」判 INFO 而非 BLOCK | 非缺陷。种子 50 条规则实际 pattern 为 保本保收益 / 稳赚不赔-2 / 高收益无风险-7 / 内幕消息-5 等，该文案确实不含任何 pattern，判 INFO 正确 |
规则 pattern 普遍带 -N 测试后缀 |
非缺陷但需注意。命中要求文案逐字包含 -N 后缀，作为演示语料极易被误判为「规则没生效」 |
scripts/demo/run_demo_smoke.ps1 |
已失效（文档/脚本腐化）。仍调用 /api/v1/* + 旧登录形（username/password、断言 code=="00000"），而 /api/v1 在 app/ 中已无任何路由（决策 D1 明确不保留），按当前代码必然 404。合并说明 §5.1 要求改到 canonical 路径，实际未完成 |
docs/演示文档/功能演示版启动手册.md · 后端接口测试指南.md |
同样残留 alembic upgrade head 与 /api/v1 指引，与现状不符 |
64c5db7 移除 KYC 四端点的 response_model=ApiResponse |
行为无回归（实测封套仍为 {code,message,data,trace_id}，仅由 _advisor_ok 运行时拼装）。但契约层退化：KYC 成为唯一不在 OpenAPI 里声明响应封套的顾问端点（其余端点仍带 response_model），前端 codegen / 类型生成对 KYC 将拿不到封套类型 —— 有 web/src/pages/advisor/AdvisorKycPage.tsx 消费，建议后续统一（本轮仅记录，未改动） |
8.1 D4 · agent_tools.py 七处调用与实现签名不匹配（潜伏 · 不阻断 · 不计入分母）
| 字段 | 内容 |
|---|---|
| 缺陷编号 | DEF-ADV-2026-09-12-004 |
| 严重等级 | P3 潜伏（当前 0 个 FAIL 用例 —— 无任何 HTTP 路由可达） |
| v1.1 实测口径 | app/service/agent_tools.py 中 kyc_service.* / template_service.* / compliance_service.* 共 7 处调用与实现签名对不上：:70 · :113 · :118 · :123 · :128 · :150 · :170（:70 即 D1 同款市场数据调用，随 D1 一并修好） |
| 为何不计入 | 仅被 app/service/agent_graph.py:158 引用；LangGraph 编排未挂任何 HTTP 端点，故真实 HTTP E2E 触达不到 ⇒ 本轮 0 FAIL，不是「没问题」，是「够不着」 |
| 处置 | 本轮仅记录。接线前必须回归，否则一挂端点即 500 |
9. 变更清单（本轮）
| 类型 | 路径 | 说明 |
|---|---|---|
| 脚本 | scripts/dev/advisor_e2e_smoke.py |
新增 · 真实 HTTP 端到端冒烟（63 项 · 可重复 · --only 单组重跑） |
| 文档 | docs/memory/tests/2026-09-12-advisor-agent-e2e/ |
新增 · 本测试包（README + 本日志） |
| 文档 | 本文件（v1.1） | 改 · 按 merger @ c09b987 复跑结果重写 §3/§5/§6/§7/§11/§12；原文以删除线/存档块保留 |
| 业务代码 | —— | 未改动（v1.0/v1.1 一致，定性均为「先报告，确认后再修」） |
9.1 v1.1 本轮相关产出（详见 <2026-09-12-agent-frontend-e2e>）
| 类型 | 路径 | 说明 |
|---|---|---|
| 脚本 | scripts/dev/risk_e2e_smoke.py |
新增 · 风控 API 真实 HTTP E2E（67 项 · R1–R6） |
| 脚本 | C:/Users/Windows/e2e-jinrong/09-advisor-pages.mjs |
新增 · 顾问前端四页真实浏览器 E2E（17 项 · 仓库外） |
| 文档 | docs/memory/tests/2026-09-12-agent-frontend-e2e/ |
新增 · 本轮报告包 |
记录收敛： 首跑时脚本曾把机器矩阵落到
artifacts/advisor-agent-e2e-report.md，内容已全部并入本日志第 5~8 节，该文件已删除。脚本--report同时改为可选项（默认不落盘），避免再次产生旁支记录；复核只需看控制台输出与退出码。
10. 数据准备与重灌结论
| 数据集 | 是否需重灌 | 说明 |
|---|---|---|
jinrong_agent 顾问 7 表 |
否 | 已迁移，compliance_rule 50 条 + script_template 20 条（全已审核） |
jinrong_core（v1.1 基线） |
否 | 33 客户 / 14 产品 · NAV 最新 2026-09-11（v1.0 时为 2026-09-04；03fce88/c09b987 补种后区间已延伸） |
| 脚本副作用 | —— | 每轮会新增：临时合规规则（软删）、临时模板（软删）、KYC 会话与消息、copy_track_log、compliance_check_log、audit_log 行 |
Milvus kb_script_templates |
未灌（v1.1 佐证） | 需 python scripts/sync/sync_template_vectors.py。v1.1 佐证：该集合目录 5.0K / 2 文件，已灌的 fin_faq/fin_policy/fin_product 各 50K / 5 文件。本轮未执行灌入（属写操作，且会掩盖 D3 的待修状态） |
| 未执行的破坏性操作 | —— | 本轮未运行 prepare_all.ps1 / reset.ps1 / 无 --no-reset 的 verify_convert_seed.py（会 DROP DATABASE jinrong_core）；测试数据一律保留取证 |
11. 结论与剩余风险
| 字段 | 结论 |
|---|---|
| 需求是否覆盖 | 顾问线 24 个端点全部触达；未交付能力（KYC Profile、资产配置、看板汇总、导出、LangGraph 编排 F01/F02/F04）不在本轮范围 |
| 旧功能是否破坏 | 未破坏 —— G9 跨线回归：平台适当性 200 · 问数线 200（script_template_service 重命名未伤及问数 template_service） |
| 剩余风险（v1.1） | ① D2 未修 ⇒ KYC 采集不可用（前端取证见 <2026-09-12-agent-frontend-e2e> A4.2：页面 INTERNAL_ERROR）；② D3 未修 ⇒ 语义检索静默降级，且集合疑似空集，仅补 load() 未必恢复；③ D4 潜伏 ⇒ app/service/agent_tools.py:70,113,118,123,128,150,170 七处签名/方法不匹配，无 HTTP 入口故本轮 0 FAIL，但 agent_graph.py:158 已引用，接线即 500；④ run_demo_smoke.ps1 已失效，演示链路无可用脚本；⑤ 既有 test_sprint* 65 红仍全部把 Core 提供方 fake 掉，无法替代真实端到端信号 |
| 建议人工再验 | 修完 D2/D3 后重跑 python scripts/dev/advisor_e2e_smoke.py，目标 0 FAIL / 0 SKIP（当前 3 FAIL / 0 SKIP） |
| 是否可发布 | v1.1 订正： |
12. 修订历史
| 版本 | 日期 | 作者 | 说明 |
|---|---|---|---|
| v1.0 | 2026-09-12 | Andrew | 首版 · 63 用例 · 53 PASS / 5 FAIL / 5 SKIP · D1~D3 定性未修（基线 integrate/advisor-agent @ 64c5db7） |
| v1.1 | 2026-09-12 | Andrew | 基线改至 merger @ c09b987 复跑：60 PASS / 3 FAIL / 0 SKIP。 ①§3 被测版本改写并留 v1.0 存档；②D1 关闭（附代码 core_ro.py:839,851 与实测 G5 10/10 双证据），§7 新增 §7.0 转绿明细；③D3 根因经实测坐实并订正：v1.1 开工时的「高层 client 会自动 load」假设被 uvicorn 日志 code=101 … 'released' 证伪，同时新增「集合疑似空集」第二层观测；④§5/§11 结论由「不建议合并」改为「D1 已修，剩余 D2/D3 交模块负责人判定」；⑤D4 潜伏项按实测更新为 7 处 |
| v1.2 | 2026-09-12 | Andrew | 计数口径更正（D3 结论不变）。 §6 D3 原记「日志出现 10 次」—— 收口时按日志原件（18:19:25 → 18:55:05 单 session 全文 3,592 行）重新点数，实为 5 次独立异常（10 = 5 异常 × 2 行，把 RPC-error 行 + traceback 行 当成两次了）。D3 根因、证据链、结论均未变，仅计数表述订正。同时：⑥补 pymysql.err.IntegrityError (1048, "Column 'created_at' cannot be null") 逐字报文，D2 根因由「推断」升级为「日志直证」（失败 SQL 明确列出 created_at 列 + 参数 created_at: None）；⑦日志摘录入库 ../2026-09-12-agent-frontend-e2e/_raw/server-log-evidence.md，结论可被第三方查阅 |