NL_develop 评审答复与画像白名单补发脚本 #6

2026-09-11T19:58:24+08:00

lzf_0626 commented

2026-09-11 19:58:24 +08:00

合并 qyqy_develop_1 第四轮工作：

评审 NL_develop 交付说明与第二轮答复：批准整改、纠正 mypy 归因、裁定 docs/00 不动、明确三个环境前提
新增补发画像工具白名单的脚本（dry-run + 合并前防呆）
docs/08 补充 §8：既有发布脚本会丢提示词的问题

合并 qyqy_develop_1 第四轮工作： - 评审 NL_develop 交付说明与第二轮答复：批准整改、纠正 mypy 归因、裁定 docs/00 不动、明确三个环境前提 - 新增补发画像工具白名单的脚本（dry-run + 合并前防呆） - docs/08 补充 §8：既有发布脚本会丢提示词的问题

lzf_0626 added 4 commits 2026-09-11 19:58:25 +08:00

评审 NL_develop 交付说明：三个环境前提必须先对齐 927a6fecc0

产出 docs/NL_develop交付说明-评审意见.md（可直接转给组员），以及一个只读探查工具
tools/probe_knowledge_collections.py（Milvus 集合 schema 与行数）。

核查中发现的硬矛盾，都有可复核的证据：

1. 配置库不是同一个。对方说 active=216、合并前生效版本是 186；我这边实测 active=201，
   最近 5 条 id 就是 201/198/197/196/195 —— release.id 自增，同库不可能一边 216 一边 201。
   所以他以为已发布的 customer_service:faq=[search_knowledge, query_customer_profile]
   在这边并不存在，而他的画像出口复用的正是这个 key ⇒ 合并后被 ToolExecutor 失败关闭。
   同理他说的 fund_query_demo:fund_quote 缺失，我这边是存在的。

2. Milvus 也不是同一个。对方说现库字段是 knowledge_id/snippet、无 visibility、行数
   106/177/73；我这边实测是 doc_id/content/chapter/section/.../visibility 共 15 个字段、
   行数 125/297/214，且与 knowledge_search_service.py 的 OUTPUT_FIELDS 逐字一致。
   他这次的字段映射改动（doc_id→knowledge_id）在这边会直接报 field knowledge_id not
   exist，把客服知识检索整条打挂 —— 比他自述的"关闭 visibility 隔离"严重得多。
   建议不是 A/B/C 三选一，而是第四种：运行时探测字段名，两套 schema 都能跑。

3. 解释器不同。他用 .venv（项目里不存在，那是他机器上的 gitignore 目录），约定是
   D:\conda\envs\jr_py313。所以"mypy 151→181"跑不到本基线 —— 这边是 138 文件 0 错。

另指出：docs/26-JWT密钥管理与轮换.md 会与已存在的 docs/21-JWT密钥管理与轮换.md 重复，
建议并入 21；驳回删除 docs/04/06/10/13/99。

四项待裁决的答复：同意 agent_type 方案（要求补审计）；字段映射改为运行时探测；
驳回删除编号文档；26 并入 21。

答复 NL_develop 第二轮：批准整改，纠正 mypy 归因，裁定 docs/00 不动 d28ccdd88c

产出 docs/NL_develop评审回复-架构师答复.md（可直接转给对方）。三条核实结论：

1. docs/21 在我这边本来就重号（21-JWT密钥管理与轮换.md + 21-风控业务第二版迁移
   清单.md），tools/check_authoritative_docs.py 当前就是失败的 —— 我此前只跑
   ruff/mypy/pytest，没跑到文档守卫。对方的让号顺手修好了这个既有故障，
   故批准 docs/26 与 docs/27 两处让号。

2. 对方的 mypy 归因需要纠正。他说主因是缺 SQLAlchemy 2.0 类型信息；我这边
   mypy 1.20.2 + SQLAlchemy 2.0.52 + 未装 sqlalchemy2-stubs → 0 错，而
   pyproject.toml 约束是 sqlalchemy>=2.0,<3 / mypy>=1.14,<2。SQLAlchemy 2.0 自带
   py.typed，sqlalchemy2-stubs 是给 1.4 用的，装了反而按 1.4 的 API 报错（他自己也
   观察到"还会换一批新错"）。真实根因是他的 .venv 没满足 pyproject 约束。

3. 他的迁移警告对我不适用。我这边 alembic current = heads = 20260911_risk_rule_index
   （单一 head，只有我自己的迁移），schema audit 报 51 business tables —— 即"表没建、
   版本号也没跑"，与他那边"版本号跑了、表没建"是两种不同的坏状态。合并后我必须补跑
   alembic upgrade heads。

裁定：
- 补发配置（customer_service:faq 加 query_customer_profile）归我做；
- memory_sync_outbox / GraphProjectionWorker 消费端归我（生产者在他那边）；
- 两处让号批准；
- docs/00 不动，另立文档登记场外/推广域 17 张表，并更新 docs/08 审计基线口径
  （依据 AGENTS.md 规则 8：场外基金运营流程独立，不得写入场内交易表）。

新增补发画像工具白名单的脚本（dry-run + 合并前防呆） 6c09cdecbd

tools/publish_profile_tool_whitelist.py：把 query_customer_profile 加进
customer_service:faq，供 NL_develop 合并后在本环境补发配置。

关键设计都来自这轮评审核实到的事实：

1. 继承走 ConfigReleaseService.effective_snapshot()，一次拿全三张受管表
   （platform_config_item / prompt_template_version / model_routing_rule）。
   既有的两个 agent_tools 发布脚本都绕开它、自己写 SQL 只查第一张 —— 用它们发版
   会把 201 里那条客服闲聊提示词一起清掉，而 Agent 侧有兜底、功能看着正常、没有告警
   （这个事故在本项目真实发生过一次）。
2. 同 key 覆盖：继承项里的 customer_service:faq 必须被本次新值覆盖，否则旧值
   ["search_knowledge"] 会被 admin 端校验拦下、整次发布失败。
3. 提示词搬运重分配 version（唯一键含 version），并按 PromptPayload 的 9 个字段挑字段、
   归一化 input_schema/output_schema —— 漏带就是静默丢失。
4. 前置防呆：admin 端校验「配置 ⊆ 代码 allowed_tools」（admin_service.py:219-220），
   合并前跑必然 422，而报错只有"配置超出 Agent 工具上限"。脚本先查代码上限：
   dry-run 给警告后继续预览，正式跑直接中止。
5. JSON 列归一化：SELECT * 读出来的 JSON 列可能是字符串，不解析会静默走进
   "生效版本里没有该 key"的分支（本脚本第一版就是这么错的，诊断打印才定位到）。

实测：--dry-run 打印 9 条配置项 + 1 条提示词（v2→v3 重分配）与唯一变化；
正式跑因代码尚未合并而中止，未产生任何写入。

答复文档补充 §8：两个既有发布脚本会丢提示词（写补发脚本时发现） 8268646b0c

publish_customer_service_config.py 与 publish_risk_agent_config.py 的
active_config_items() 都自己写 SQL、只查 platform_config_item，而
ConfigReleaseService.effective_snapshot() 要读全部三张受管表。用它们发版会把生效版本里的
提示词一起清掉 —— 且没有任何声音：_warn_dropped_items() 只告警不阻断激活，Agent 侧
_chitchat_prompt 有兜底会回落代码默认值，功能看着正常（与 release 174 那次事故同型）。

已在答复文档里建议改用 effective_snapshot()，并列出三个细节：同 key 覆盖（对方已修）、
JSON 列必须归一化（SELECT * 读出来可能是字符串，不解析会静默走进"没有该 key"分支）、
提示词搬家要重分配 version 且按 PromptPayload 字段挑（漏 input_schema/output_schema 即丢）。

另提醒时序：admin 端校验「配置 ⊆ 代码 allowed_tools」，画像工具那一版必须等代码合并后才能发，
否则 422 且报错只有"配置超出 Agent 工具上限"。

lzf_0626 merged commit 9957ddc191 into qyqy_develop

2026-09-11 19:58:29 +08:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AI260626/group_fqcd_jr#6