 lzf_0626
|
0c642133d4
|
修复长期记忆向量链路：投影入队 + 集合名三侧同源 + 召回按客户过滤
语义召回"恒空"的根因分四层，本提交修掉投递层与读取层（另两层——重试计数
门禁、episode 不投 rebuild 事件——已在前两个提交修复）。
R2 投递层：dispatch_profile_rebuild 只做图投影，没有任何 Milvus 投递，
长期记忆的向量从未被写入过（实测客户 9001 在 memory_sync_outbox 里 0 行）。
新增 _enqueue_memory_vector_projection()，在画像重建后投
MemorySyncOutbox(target_store="milvus")。走事件而不是同步写，是为了拿
Outbox 的重试/退避/死信，且不把 embedding 的网络等待拖进事务。
⚠️ payload 必须带 version（正整数）：适配器 _coerce_profile_version 缺它
直接抛 ValueError（实测踩到，事件立刻 failed）。
R4 读取层：写的集合与读的集合不是同一个 ——
写（MilvusProfileProjection）用 "user_long_term_memory_v1"，
读（bootstrap.get_vector_memory_adapter）与删（projection_cleanup_service）
却用 settings.milvus_collection = "jr_memory"，而该集合从未被创建。
⇒ 召回：MilvusClient 构造不校验集合存在，适配器"构造成功"但每次 search
抛异常被 VectorMemoryAdapter 吞成 degraded → 召回恒
degraded_reasons=('milvus_unavailable',)、向量命中恒 0 条；
⇒ 清理：jr_memory 不在集合列表 → 走 vector_collection_absent 分支 →
报清理成功但一个向量都没删，陈旧向量永久留存。
修法：PROFILE_COLLECTION 成为唯一常量，读/删两侧直接引用它；
并删除 Settings.milvus_collection 配置项、清掉 .env.example 的
MILVUS_COLLECTION —— 写侧从来没读过它，一个只在契约一侧生效的配置项
比没有配置项更危险（Settings 的 extra="ignore" 会让其他环境残留的该
变量被安全忽略）。
顺带：
- 语义检索把客户过滤下推到 Milvus（filter="customer_id == N"）。此前不带
过滤，别家客户的命中会白占 limit 名额，稀释本客户的召回条数。
- upsert 在 sources 为空时先返回，不再无条件 load_collection ——
"本来就没有可写内容"不该被记成投递失败（10001/10002 那两条事件即如此
重试 5 次进死信）。
回归守卫：tests/unit/infrastructure/test_memory_vector_collection_consistency.py
断言读侧与删侧用的都是 PROFILE_COLLECTION，且被删掉的配置项不得回归。
这个缺陷能活下来，正是因为两侧单测全绿而接缝无人守。
验证（走生产装配、进程内调用，未重启你正在跑的 API 窗口）：
读侧集合打印 user_long_term_memory_v1（修前为 jr_memory）；
召回 degraded=False / reasons=() / sources 含 milvus，且排序随 query 语义
变化（投资期限→horizon 0.288 > risk_level 0.201；风险偏好→risk_level 0.287）；
query="进取型" 双通道合并且 vector_score=0.9987；query=None 走 mysql 全量。
pytest tests/unit tests/contract → 1432 passed, 2 skipped, 1 failed
（唯一失败是同事正在改的投顾页面，与记忆链路无关）。
文档：docs/演示用/记忆召回恒空-根因与修复-2026-09-14.md（新增，四层根因+证据）、
docs/37-记忆投影链路实现说明.md（补集合名三侧契约）。
|
2026-09-14 21:26:03 +08:00 |
|
|
lzf_0626
|
6516ccb385
|
feat: 第二版——接口契约对齐 docs/05，修复静默故障与数据库基线
相对第一版 46fc976 的完整变更。组员迁移对照表见 docs/20。
一、对外契约对齐 docs/05（破坏性，共 4 处，组员需按 docs/20 调整）
1) 配置发布端点改为文档规定的复数资源名：submit→validations、
approve→reviews（需 body decision）、activate→activations、
rollback→rollbacks；第一版这 4 个动词式路径 docs/05 从未定义过。
2) 错误码由 8 个笼统码改为 15 个具体语义码（FORBIDDEN→AGENT_PERMISSION_DENIED、
UNAUTHORIZED→AUTHENTICATION_REQUIRED、CONFLICT→RESOURCE_VERSION_CONFLICT、
RESOURCE_NOT_FOUND→RUN_NOT_FOUND/SESSION_NOT_FOUND 等），
输入类错误状态码 400→422。
3) POST /api/v1/agent-runs 与 GET /api/v1/agent-runs/{run_id} 统一为
{data, meta} 信封（data 内字段名与语义未变）。
4) 错误响应体统一为 {error:{code,message,retryable,field_errors}, meta:{trace_id}}，
不再返回 FastAPI 默认的 {"detail": ...}。
二、数据库基线与约束
新增 39 张表的基线迁移（链根）与联合唯一键纠偏（4 张表、删 8 增 4，幂等收敛）；
撤下 config_release 的双人复核 CHECK（应用层已允许自审，审核节点保留，
自审如实写入 reviewer_id）；记忆 active key 生成列与唯一键；
activate 开始记录 supersedes_release_id 使版本链可追溯。
docs/00 基线未修改，未重命名或删除任何表与字段。
三、修复会静默出错或无报错的缺陷
- 跑完集成测试后平台会静默失去生效配置：清理只删自己创建的版本，却没有恢复被它
顶成 superseded 的原生效版本，且审计一并删除因而完全无痕，表现为所有工具被拒
但没有任何报错。已修清理逻辑并加恢复。
- Worker 单轮异常导致进程退出；记忆抽取调用方的“事务已开始”异常；
召回缓存丢失 degraded 标记；连接时区未生效导致 created_at/updated_at 差 8 小时；
.env 与 os.getenv 密钥来源分裂导致“没有可用的已批准模型端点”。
- 记忆信号识别漏判与跨键误命中；SSE 未带 Accept 的协商行为。
四、功能补齐
记忆链路 P1/P2/P3（抽取、受控词表、召回与缓存、生命周期级联及投影事件）、
fin_* 场内交易只读 ORM 层、agent_intent_config 状态流转并在运行期真正生效、
限流（Redis 固定窗口、故障一律放行）、游标校验、trace_id 中间件、
示例业务 Agent fund_query_demo 与一键端到端验证脚本，以及审计/指纹/迁移状态工具。
五、文档与验证
新增 docs/19（业务 Agent 接入实操）、docs/20（第一版迁移指南）与 docs/evidence 证据；
docs/01/02/06/08/09/17 同步实现现状。
验证结果：ruff 通过、mypy 103 文件无错、unit+contract 447 passed、
integration 29 passed、acceptance_check --production 7 PASS、
demo_agent_e2e 9/9 PASS（含失败关闭反证）。
|
2026-09-10 15:55:54 +08:00 |
|
Codex