LTM 可观测性与排障
一次 LTM 请求至少包含“写入或读取入口、Space 边界、派生或召回阶段、最终结果”四类信息。排障时先确认请求是否到达正确环境，再判断是异步延迟、边界过滤还是模型旁路。
你应该记录什么
| 信号 | 用途 |
|---|---|
X-Turing-Trace-Id | 将 API、Managed Chat 和平台审计串成一次调用 |
space_id、actor_id、session_id | 确认数据边界和会话归属 |
Event status | 区分请求被接受和派生已经完成 |
| Memory outcome headers | 判断是否执行 Recall、Evidence 注入和 Capture |
source_event_id、revision_id | 解释某条记忆从哪里来、当前是哪一版 |
标准排障路径
- 确认环境和鉴权：检查 Base URL、API Key、项目 Client 和 Space 是否属于同一环境。
- 确认写入语义：
202 Accepted只表示进入异步队列；检查 Event 是否有正确的owner_type、actor_id和session_id。 - 确认派生范围：使用 List memories 查看 Profile、Facts、Summary 是否生成；不要只凭一次 Search 结果判断写入失败。
- 确认读取过滤：检查
include_shared、memory_type、topic、token_budget和abstain_threshold。 - 确认托管对话路径：查看 outcome headers 和 Trace；如果发生 fallback，本次请求不会读取或保存 Memory。
常见现象
| 现象 | 优先检查 |
|---|---|
| 写入返回 202，但暂时查不到 | 异步派生延迟、Space/Actor 是否一致 |
| Search 没有命中 | 查询范围、memory_type、阈值和是否只搜索共享事实 |
| Context 很短 | token_budget、sections、summary_limit 以及当前 Space 是否有记录 |
| Managed Chat 没有保存 | 是否是终态回答、是否触发 fallback、outcome header 和 Trace |
| 同一事件生成多次 | 重试是否复用了相同 Idempotency-Key |
把平台和日志对起来
Developer Platform 的 Memory Explorer 适合查看记录和可视化审计；服务端日志适合按 Trace、Space 和时间窗口聚合。两者应使用同一个 X-Turing-Trace-Id，不要用模型输出文本作为关联键。
完整的请求头定义见 请求追踪 和 Headers 协议。