group_fqcd_jr

Files

T

lzf_0626 c0e5c80929 记忆系统：recall 结果接入 prompt + 可观测性（既有改动，代为提交）

## 说明

**这批改动不是本次会话写的**，它们在会话开始前就已在工作区里、一直未提交。
我做的是**验证**它确实成立，然后按你的指示代为提交。

出处：`docs/演示用/记忆系统排查报告-2026-09-14.md` 与同目录
`记忆系统修复文档-2026-09-14.md`（两份都在本次一并入库）。
排查报告的结论是「记忆系统没有坏」——库里有真实数据、170 条抽取事件全部消费成功；
真正的问题是「观测不到」+「召回结果没人消费」。

## 改动内容（按两份文档的编号）

- **F1 `RecalledMemory.content` 断头路**：`base.py` 新增 `memory_context_text()`，
  `risk_agent._agent_system_prompt` 接收并注入记忆段。无记忆时返回空串，
  因此 prompt 逐字不变 —— 这也是它能安全接线的理由。
- **F3 `governance.recall` 员工身份恒空**：补一条明确的语义日志。
  员工身份下召回的是"该用户自身作为客户"的记忆，恒为空属预期，
  但此前没有任何提示，运维看到 `count=0` 只会以为记忆坏了。
- **F4 可观测性**：`GET /api/v1/users/me/memories`（`stored` / `recalled` /
  `downstream` / `pending_events` 四段）+ 抽取与召回的 6 处日志 +
  三个只读探针 `tools/probe_memory_state.py`、`probe_memory_detail.py`、
  `probe_agent_types.py`。

**未实施**（文档明确留作待决，我也不代为决定）：F2 `known` 引用校验永不触发
（需架构确认 memory 类 `source_references` 由业务填还是底座统一附加）、
F5 客服是否读写长期记忆（涉脱敏与复核，需产品+合规）。

## 我做的验证（会话内实测，非照录文档）

- 新接口 `GET /users/me/memories` 以 `cust_t` 调用 -> **HTTP 200**：

      stored:    total=2, by_status={'active': 2}
      recalled:  count=2, degraded=False
      两条记忆：preference:horizon='约三年'(0.95)、preference:risk_level='稳健型'(0.98)

  与排查报告 §〇 列出的那两条**完全吻合**。
- `pytest tests/unit tests/contract` 全绿（这批改动没有破坏既有测试）。

## 未验证的部分

`memory_context_text()` 接进 prompt 后的**端到端效果没有实测** —— 文档自己说明了
原因：当前 `risk` Agent 的召回恒空（员工身份不是客户），所以接线后行为不变，
要用测试替身才能验证注入。我没有为此编造证据。

2026-09-14 20:35:46 +08:00

__init__.py

chore: initialize project repository

2026-09-09 21:55:37 +08:00

admin.py

fix(portal): 照接口逐条核对前端，修掉 5 处「照着表结构写、看着像对」的缺陷

2026-09-14 01:19:22 +08:00

agent_runs.py

袁聪的第二次提交，项目已完整

2026-09-11 16:57:47 +08:00

asset_allocation.py

feat: add advisor rollout gate and rollback playbook