lzf_0626
6516ccb385
相对第一版 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（含失败关闭反证）。
43 lines
1.8 KiB
Markdown
43 lines
1.8 KiB
Markdown
# 记忆链路修复前基线（2026-09-09）
|
|
|
|
本文件记录修复开始前的真实数据状态，用于修复后的前后对比。全部数据来自本地 `jr` 库只读查询。
|
|
|
|
## 一、Outbox 事件真实分布
|
|
|
|
| event_type | status | count |
|
|
|---|---|---|
|
|
| `agent.run_requested` | pending | 262 |
|
|
| `agent.run_requested` | failed | 1 |
|
|
| `agent.run_requested` | dead | 1 |
|
|
|
|
**关键事实：不存在任何 `memory.extraction_requested` 事件。** 当前没有任何业务 Agent 注册
|
|
（底座只提供框架与工厂，业务组员负责接入），`POST /api/v1/agent-runs` 对未知 `agent_type`
|
|
返回 404，运行从未进入 `complete_run()`，因此记忆事件从未产生。
|
|
|
|
262 条 pending 的 `agent.run_requested` 说明 Worker 未常驻运行；记忆链路的验收必须先启动
|
|
`python -m app.worker`，否则事件不会被任何消费者领取。
|
|
|
|
## 二、记忆相关表状态
|
|
|
|
| 表 / 对象 | 状态 |
|
|
|---|---|
|
|
| `memory_unit` | 0 行 |
|
|
| `memory_evidence` | 0 行 |
|
|
| `memory_conflict` | 0 行 |
|
|
| `outbox_delivery` | 0 行 |
|
|
| `memory_unit.active_memory_key` 生成列 | 不存在 |
|
|
|
|
## 三、结论与修复验收判据
|
|
|
|
链条上的三处断点（Worker 未注册记忆消费、事件 payload 不含正文而 worker 期望 `content`、
|
|
抽取语义与幂等错误）属于**静态缺陷**，在业务 Agent 接入前不会通过现有数据自然暴露。
|
|
因此记忆链路验收不能依赖生产数据，必须使用显式端到端探针：
|
|
|
|
```text
|
|
注册探针 Agent → POST /api/v1/agent-runs → Worker 执行 → complete_run()
|
|
→ 写入 memory.extraction_requested → Worker 消费 → memory_unit 非空
|
|
→ 同一事件重复消费不产生第二条记忆
|
|
```
|
|
|
|
判据：修复后 `memory_unit` 行数由 0 变为非 0，且重复消费同一 `event_id` 不增加行数。
|