AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
190 Commits 12 Branches 0 Tags
ZSY_develop
Commit Graph
17 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
qyqy 58849addcc docs: 交付说明补第二轮批复（含 mypy 归因纠正）；修正残留过期数字 
上一轮我只更新了接手文档，**漏了交付说明**——它的末次更新（19:15）早于架构师 19:43 的
第二轮答复，导致它还写着已被推翻的结论。本次补齐：

- 新增 §0-B：架构师第二轮的 9 条批复逐条落地对照（含"mypy 归因纠正""docs/00 不改另立登记"
  "两件事归他""那 2 个失败按新引入对待"）
- §5.2 整体重写：**认错并给出四组对照实验**（SQLAlchemy 2.0.34+1.14→173、2.0.52+1.14→6、
  2.0.52+1.20→3），说明真因是 SQLAlchemy **补丁版**而非"缺类型存根"；环境已升级到
  2.0.52+1.20.2，mypy 184→3；并列出剩余 3 个错全在同事那条线的文件里
- §5.1 接受架构师口径：那 2 个失败**不是"双方共有的既有失败"**，应作为合并后**新引入的失败**跟踪
- §2 净差异分两段重算：本线增量 16 模块/17 测试/5 工具 vs 同事那条线 334 文件/11 迁移
- §6/§7 更新为第二轮后的状态（哪些已批准、哪些归他、哪些已落地）
- 修正残留过期数字：结构审计 51→68 张表、去掉"缺 SQLAlchemy 2.0 类型信息"的错误论断
- 章节号整理：两个同名 "## 0" → "## 0-A / ## 0-B"

文档守卫 35 份无重号；mypy 3 错；测试 1218 passed。
 2026-09-11 20:06:23 +08:00
qyqy f7a666fb5a fix(env)+docs: 按架构师第二轮纠正 mypy 根因（环境版本）；补场外/推广域表登记 
架构师第二轮答复里有一条技术纠正是对的，我原归因错了：
- 我原判断"184 个 mypy 错是因为缺 SQLAlchemy 2.0 类型信息"——**方向对了一半、结论反了**。
  SQLAlchemy 2.0 自带 py.typed，根本不需要 sqlalchemy2-stubs（那是 1.4 用的）。
- 实测复现矩阵（决定性证据）：
    SQLAlchemy 2.0.34 + mypy 1.14.1 → 173 错（我原来的环境）
    SQLAlchemy 2.0.34 + mypy 1.20.2 → 173 错
    SQLAlchemy 2.0.52 + mypy 1.14.1 →   6 错
    SQLAlchemy 2.0.52 + mypy 1.20.2 →   3 错
  ⇒ 主因是 SQLAlchemy 的**补丁版本**（173→6），mypy 版本是次因（6→3）。
- 已把环境升到 SQLAlchemy 2.0.52 + mypy 1.20.2（均在 pyproject 约束内），
  mypy 从 184 降到 **3 个错**（剩下的 3 个全在同事的 offsite 文件里，非本线代码）。
- 没有把 sqlalchemy2-stubs 写进依赖（采纳架构师明确要求）。
- 交接文档已重写该条，并留下"两个反面教训"：不要装 1.4 的存根包；补丁版差异会造成量级差异，
  若要门禁稳定需把 SQLAlchemy 钉到具体补丁版（属公共约定，未擅自改）。

按架构师裁决补文档（他裁定：不动 docs/00，另立登记）：
- 新增 docs/28-场外与推广域数据表登记.md：17 张表逐表登记（表名/来源迁移/归属域/当前行数），
  并做规则 8 的**两向边界核对**——场内代码零引用这 17 张表（config.py 里的 offsite_ 只是配置项名）、
  场外代码零写场内交易表
- docs/08 审计口径更新为「场内 51 + 场外/推广 17 = 68」，并新增"第四种坏状态"
  （alembic_version 已指向新 revision 但表没建）的处置说明
- 澄清一个易误读点：audit_schema.py 的期望集合是**动态推导**的（读 baseline_generated.sql
  + 扫描 alembic/versions/*.py），表数 51→68 是自动结果，**没有人手工改期望值**；
  代价是只增不减（DROP 表会报 missing 假失败）

测试：3 failed（1 既有 + 2 环境相关）/ 1218 passed；文档守卫 35 份无重号；
mypy 3 错（180 文件）；结构审计 68 张表通过。
 2026-09-11 20:00:56 +08:00
qyqy f1b8cb859a docs: 新增《接手文档 · NL_develop 这条线（给架构师）》 
面向"接手维护"而非"review"的第三份文档，与另两份分工明确：
- 交付说明 → review 用（我动了你什么、为什么）
- 评审意见回复 → 对照你的评审意见
- **本文** → 接手维护用（起点在哪、有哪些坑、哪些待裁决）
- 给下一位开发者 → docs/superpowers/handoff/…

内容要点：
- §1 三条最要紧的结论：① 两台机器不是同一套环境（附三处实测证据）并由此立下两条硬纪律
  （环境相关结论必须带环境限定、禁止硬编码 Milvus 字段名）；② **表数已从 51 变 68**
  （同事 11 个迁移新建 17 张 offsite_*/promotion_* 表），而 docs/00 基线与 docs/02 未更新
  —— 已提示、未擅自改不可变基线；③ 测试 3 failed 均非代码缺陷（附证据）
- §2 环境口径（含 Docker Desktop 不常驻、mypy 不可比的实测根因）
- §3 分支与提交 + 两个可回退的备份分支
- §4 交付清单（8 项，含状态与位置）
- §5 必须知道的 5 个坑（Milvus 读一致性与字节截断、config_release 整版本替换、
  两个 outbox 不能混、审计表无 agent_type 列）
- §6 待你裁决的 3 件事（白名单补发归属、接线归属、两处文档让号）
- §7 建议你拍板的两件事（文档体系口径、docs/00 是否补 17 张新表）
- §8 接手后先跑的 5 条自检命令
- §9 四份文档的分工表（防止读串）
 2026-09-11 19:32:19 +08:00
qyqy c6a52a36a8 docs: 新增《评审意见回复》，逐条对照架构师的评审意见 
按评审意见结构逐条回复，每条都给实测证据与落地位置：
- §1 环境不是同一套（三处独立证据：config_release 总 4 条 vs 最高 201、
  Milvus 字段/行数三项全不同、代理表命名不同），并据此提出团队纪律
  "环境相关结论必须带环境限定"
- §1.3 承认我原先的 A/B/C 三分法**前提就错了**（以为是"选哪套 schema"的决策问题，
  实际是"两套环境"的兼容问题），已按架构师方案改为运行时探测并用双 schema 测试锁住
- §1.4 给出 mypy 差异的根因（本机缺 SQLAlchemy 2.0 类型信息，装 sqlalchemy2-stubs
  181→43、卸载回 184），明确不再拿该数字当结论，也不擅自改 mypy 公共配置
- §2 澄清 docs/26 是重命名而非并存（21 已被风控迁移清单占用）
- §3.1 审计留痕已补并有真机证据（含改动前 false 的对照行）
- §4 给出 memory_sync_outbox / GraphProjectionWorker 的**双环境对照表**，
  证明与架构师的发现同源（组件写好、线没接），且我方更进一步（事件已写进表里）
- §3 告知同事那条线已并入、11 个 alembic 迁移已执行（此前"版本号跑了表没建"），
  并说明我方修的两处重号与测试临时目录问题
- §5 列出需要架构师确认的三件事（配置补发归属、接线归属、两处让号）
 2026-09-11 19:15:50 +08:00
qyqy f2ac8a4460 docs: 交付说明按评审意见第二次修订；修同事带入的文档重号 
评审意见逐条落地（详见文档新增的 §0 对照表）：
- §1.1/§1.2/§4：确认两台机器连的**不是同一套 MySQL/Milvus**（我方 config_release 总共 4 条、
  最高 216；架构师侧 201 + 9 条白名单），据此把"216 已在共享库生效"整体改写为
  "**我方环境**已发布，你那台需补发"；补发由架构师做（配置属环境数据，不随代码合并）
- §1.3：字段映射已改为运行时探测（见上一提交），文档里的 A/B/C 三选一整体替换为探测方案说明
- §1.4：mypy 那条改写——查清主因是**本机缺 SQLAlchemy 2.0 类型信息**（装 sqlalchemy2-stubs
  181→43，卸载回 184），明确"本机数字不可作为质量结论、两边不可比"；我文件里的 8 个真实错误已修
- §2：明确 docs/26 是**重命名**（原 21，因 21 已被风控迁移清单占用），不是新增、不会并存
- §3.1：审计留痕已补（agent_type + governance_rewrite）
- §3.3：5 份文档删除**已撤回**（上一提交）
- §5/§7：更新验证数字（1218 passed）、两个环境相关失败的证据、memory_sync_outbox 双环境对照表

另修一处**同事那条线带入的重号**：docs/15-金融NL2SQL工具接入说明.md 与既有
docs/15-Agent组员详细开发与使用手册.md 撞号 → 新那份让号到 docs/27
（依据：手册被 docs/16、docs/17、AGENTS.md 三处引用，改名代价更大）。守卫恢复通过（32 份）。
 2026-09-11 19:15:23 +08:00
qyqy 8cff6b35f9 fix(tests): tmp_path 落点改到仓库内，消除 33 个与缺陷无关的 setup 失败 
问题：本机 `%TEMP%\pytest-of-Windows` 被权限更高的会话建过，当前用户无权写入，
于是所有用 `tmp_path` 的用例在 setup 阶段批量 ERROR（WinError 5）——实测 33 个，
散布在 offsite 附件预览、通知发送、promotion、worker 等处。这类噪声会让
"到底哪里坏了"完全看不出来（同事这批新用例首次把它暴露出来）。

修法：在 tests/conftest.py 覆盖 `tmp_path`，把根目录改到仓库内 `.workdir/pytest-tmp`
（已在 .gitignore）。语义不变——每个用例仍拿到一个**新建的空目录**（残留目录会污染断言）。
只覆盖 `tmp_path` 而不动 `tmp_path_factory`：后者是 pytest 私有构造，参数随版本变化
（实测直接实例化 `TempPathFactory(...)` 会 TypeError），而本仓库用例只用 `tmp_path`。

同时把 pyproject.toml 里那条 `basetemp = ...` 删掉：pytest **只在命令行认 basetemp**，
写在 ini 里会被静默忽略（实测无效），留着会让人误以为已配好。改为注释指向 conftest。

效果：不带任何参数 `pytest -q` 从「3 failed + 33 errors」变为「3 failed，0 error」。
 2026-09-11 19:13:43 +08:00
qyqy 636dcbbe7e chore: 修我文件里的 mypy 类型错误（8 处） 
源自评审 §1.4「数字不可比」引发的核查，结论比预想更有价值：

**mypy 报错的主因不是代码质量，而是本机缺 SQLAlchemy 2.0 的类型信息。**
装上 `sqlalchemy2-stubs` 后 181 → 43（该类存根是 2.0 之前的旧包，会换一批新错：
`mapped_column`/`DeclarativeBase` 不存在），卸载后回到 184。**本机 mypy 数字不可作为
质量结论，双方也不可比。** 但那 184 里有 8 个是**我文件里的真实错误**，已修：

- `knowledge_retrieval_service`：返回类型 `Mapping` → `dict`（回表后要就地补写
  `score`/`intent`，而 `Mapping` 是只读协议）；`ids` 显式标注并过滤 `None`；
  去掉 3 处已失效的 `type: ignore`（strict 下 unused-ignore 本身是错误）
- `knowledge_management`：服务工厂返回类型 `Any` → `KnowledgeManagementService`
  （`TYPE_CHECKING` 期导入，运行时仍惰性，不引入循环依赖），消掉 3 个 `no-any-return`

未动的：`model_gateway` 2 处 `dict-item`（`ModelEndpointConfig` 实际具备协议要求的
全部字段，属 SQLAlchemy `Mapped[T]` 在缺存根时的消解问题，不是真缺陷，不用 cast 掩盖）。
 2026-09-11 19:13:43 +08:00
qyqy 7677aeaee1 merge: 并入同事的场外申购/推广/行情/NL2SQL 线（11 提交、334 文件） 
冲突仅 3 个文件，全部取并集（双方都没有需要丢弃的改动）：
- app/main.py：import 双方路由（我方 knowledge_management + 同事的 offsite_fund/
  promotion_material）；include_router 段本已自动合并
- app/service/agent/bootstrap.py：import 与工具注册均取并集
  （query_customer_profile + query_financial_data 都注册）
- tests/integration/test_config_release_mysql.py：outbox 清理同时保留
  架构师的 event_type 限定（防误删其它域 outbox 行）与同事新增的 peer_release_id

同事这轮带入：11 个 alembic 迁移（建 offsite_* / promotion_* 等表）、
场外申购与推广素材 Agent、financial NL2SQL 工具。
注意：本库尚无 offsite_*/promotion_* 表，跑相关测试前需要执行 alembic upgrade。

边界核对：同事的场外代码未写入场内交易表（fin_sim_order/fin_capital_flow/fin_cash_ledger），
符合 AGENTS.md 规则 8。
 2026-09-11 18:56:26 +08:00
qyqy 928d0bcea3 chore: 按评审恢复 5 份文档、审计补 agent_type、修订环境口径 
评审意见落地（§3.3 驳回删除 / §3.1 审计补充 / §1.4 解释器 / §2 编号）：
- docs/04、06、10、13、99 全部恢复（评审：删除收益为零、保留成本同样为零）；
  AGENTS.md 改为"保留但仅作历史参考"并列入 D 类，ARCHIVE 归档说明加作废声明
- 治理审计补留痕：interaction_audit.detail 增加 agent_type 与 governance_rewrite
  （治理层会改写对外输出，事后必须能追溯到是哪个 Agent 触发的；不改表结构，detail 是 JSON 列）
  新增 tests/unit/service/test_agent_persistence_audit.py 锁住该契约
- AGENTS.md 修订环境口径：解释器各用本机可用的那个（.venv 被 gitignore、不进仓库）；
  config_release 与 Milvus schema 均属环境数据、不随代码合并，相关结论必须带环境限定；
  测试基线 1034；mypy 数字双方不可比（本机未装 sqlalchemy2-stubs，报错集中在模型层）
- docs/26 JWT 文档：因 21 已被风控迁移清单占用而改名，PR 描述里会单独说明
 2026-09-11 18:42:46 +08:00
qyqy 5f82ac5107 feat(knowledge): 检索字段名改为运行时探测，两套集合 schema 都能跑 
评审意见 §1.3 要求的修法。背景（双方实测共同确认）：同一批集合名在两个开发环境里是两套不同 schema：
  我方：knowledge_id / snippet（无 visibility），行数 106/177/73
  架构师：doc_id / content / chapter / section / doc_no / visibility，行数 125/297/214
上一轮我把字段名硬编码成我方那套，在架构师环境会让 Milvus 报 field doc_id not exist
→ 三集合全失败 → 客服一律转人工（反向亦然）。硬编码任一套都会打挂另一套。

改法（采纳评审建议）：
- 新增 app/core/knowledge_schema.py：describe_collection → 逻辑名到物理名映射，按集合缓存；
  缺必需字段的集合明确判为不可用并如实记 degraded，不静默零召回
- 检索服务改为逐集合探测：output_fields 只请求实际存在的字段；visibility 过滤有该字段才拼
- KnowledgeHit 对外形状不变，检索逻辑（字面召回/父子块/去重/置信判定）一行未改

测试：新增 17 个探测单测；架构师的关键词召回测试参数化为两套 schema 各跑一遍。
 2026-09-11 18:42:42 +08:00
qyqy e342670130 docs: 修正交付说明的净差异计数（新增本文档自身后 92→93、新增 50→51） 2026-09-11 16:09:16 +08:00
qyqy ac0b973006 docs: 新增给架构师的交付说明（PR 评审用） 
- 与'接手 AI 交接文档'定位区分：这份讲'动了架构师什么、为什么、要不要他点头'
- 逐文件列出对其 7 个核心文件的改动与理由（base.py 协议变更、knowledge_search_service
  字段映射的三选一裁决、governance 免责声明范围、model_gateway 映射并入、bootstrap/runtime 并集）
- 明示 6 项待裁决/知晓事项（含 5 份文档删除、config_release 216 已生效、fund_query_demo 白名单缺失）
- 证据段附可复现命令与真机结果；mypy 181 的错数按'谁引入'拆分为 170/8/3
- 已知限制 4 条（memory_sync_outbox 无消费者、mypy 归属、Redis 降级、文档删除的连带说明）
 2026-09-11 15:59:29 +08:00
qyqy 96a6e01634 docs: 交接文档与 AGENTS.md 同步到合并后状态 
- 交接文档 §0/§5/§6 重写：分支改为 NL_develop、测试基线 1013、已知问题逐条标注当前状态、
  Git 段改为已推送 + PR 注意事项（5 份文档删除/26 号新增/字段映射三处跨分支决策）
- AGENTS.md 入口指向与基线数字同步：工具名改 search_knowledge、生效版本 id=216、
  测试 1013、mypy 181（含归属说明）、新增 Agent 与文档编号现状
 2026-09-11 15:41:49 +08:00
qyqy fb7d2f7b6d merge: 跟进架构师最新 qyqy_develop（38 提交） 
- model_gateway 冲突取并集：保留本线对 intent_classification→chat 的修正与空集回退，
  并入架构师补充的 5 个风控 task_type；未登记 task_type 的告警留痕一并保留
- docs/25 撞号（本人 JWT 文档 vs 架构师风控评审报告）→ 本人让号到 docs/26，同步 docs/19 引用
- 架构师恢复的 5 份编号文档（04/06/10/13/99）保留其版本（那 5 份已无引用，仅编号占位）
- bootstrap/model_gateway/docs/05/test_risk_agent_contract 自动合并成功

测试：1013 passed / 1 failed（既有空集缺陷）
真机：知识问答 succeeded 且声明仅 1 条；画像问答 succeeded；三端点 403/201/200/404 全绿
配置：release 216 仍为生效版本，工具白名单未被顶掉
 2026-09-11 15:40:32 +08:00
qyqy cbd6de2721 Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-latest 
# Conflicts:
#	app/service/model_gateway.py
 2026-09-11 15:38:11 +08:00
qyqy 395bad25b7 fix(knowledge): 检索服务适配现库集合 schema、发布对齐的工具白名单、免责声明只由治理层注入 
合并暴露的三个真机问题（单测全绿但线上必挂）：

1. 检索服务字段名与现库集合不符 -> 静默零召回
   架构师那套按 load_knowledge_milvus.py 的 schema 读 doc_id/content/chapter/section/
   visibility，而现库三集合的真实字段是 knowledge_id/title/snippet/tags/version/intent。
   Milvus 对不存在的字段直接报错 -> 三集合全失败 -> degraded -> 客服一律转人工。
   改法：只改读取侧，用 _FIELD_ALIASES 映射；KnowledgeHit 对外形状不变（下游与测试不动）。
   代价已注明：没有 visibility 字段 -> 检索层内部资料硬隔离失效（现库 356 行均为对外知识）。

2. 发布白名单与代码上限不匹配 -> AGENT_PERMISSION_DENIED
   active 版本白名单是 query_knowledge，而合并后代码上限是 search_knowledge/check_suitability/
   query_customer_profile -> 交集为空 -> 所有知识问题 failed。
   改法：publish_customer_service_config.py 补 PROFILE_TOOL 进 faq 白名单，并让同 key 的
   继承项被本次定义覆盖（旧值原样继承会被子集校验 422 拒掉整次发布）。已激活版本 216。

3. 免责声明重复出现
   Agent 自己拼一句 + 治理层追加权威话术 -> 客户看到两条。改为只由治理层注入
   （话术属发布配置，改文案不该改代码）。风控等内部 Agent 不注入（结构化输出不被污染）。

测试：934 passed / 1 failed（test_fund_readonly_contract 既有空集缺陷，与本线无关）
真机：知识问答两问 succeeded 且只带一条声明；画像问答 succeeded；知识库三端点全绿
 2026-09-11 15:27:16 +08:00
qyqy 57c4add7d8 merge: 客服Agent+RAG+画像 与 架构师最新 qyqy_develop 合并 
- customer_service.py 以架构师实现为骨架（三档置信/适当性/会话记忆/话题矩阵），嫁接本人画像出口
- 知识检索契约合并两条链路：架构师 search_knowledge(KnowledgeSearchInput) + 本线
  query_knowledge 链路所需常量（ALLOWED_CONSTANTS/VECTOR_DIM/intent_for_qa_id）
- bootstrap 保留架构师 6 工具/3 Agent，补回 query_customer_profile 与 get_milvus_knowledge_writer
- model_gateway 能力映射修正 intent_classification→chat，保留空集回退兜底
- governance 免责声明限定面向客户 Agent（agent_type 由定义透传），风控结构化输出不再被追加
- 修 JWT 密钥路径(config/jwt/dev)、文档 21 号撞号→25
- 测试基线 934 passed / 1 failed（既有空集缺陷）
 2026-09-11 15:06:44 +08:00