核心 GUIDE
Observability 是诊断界面
只有当 Log 与 Trace 能帮助 Operator 重建 Model、Retrieval、Tool 与 Runtime 之间的因果路径时，它们才真正有价值。
核心心智模型
Observability 应该暴露 Causal Execution Path：每个 Boundary 进入了什么、选择了什么证据、做了什么 Decision、Environment 又返回了什么。
为什么重要
AI Failure 很容易被错误归因。Wrong Answer 可能来自 Retrieval 漏证据、Source Authority 过期、Tool Response 异常、Application State Bug，也可能真的来自 Model Behavior。缺少跨层 Evidence 时，团队往往默认去改 Prompt，即使 Prompt 根本不是失败组件。
01
跨 Boundary Trace Decision
记录稳定的 Request 与 Operation ID、关键 Input、Retrieval Candidate 与最终选择的 Evidence、Tool Call、Validation Outcome 与 Release Decision。Trace 应该让 State Transition 可检查，而不是要求 Operator 从大量互不关联的 Timestamp Log 中手工重建 Workflow。
02
例子：发错了 Customer Credit
Support Agent 给用户发错 Credit。最终 Answer 看起来像 Reasoning Error，但 Trace 显示 Retrieval 实际加载了另一个 Customer Plan 的 Policy。真正修复点是 Retrieval Filtering 与 Identity Propagation，而不是把 System Prompt 写得更长。
常见失败模式
- 只记录最终 Prompt 与 Response。
- 收集大量 Log，却没有 Correlation Identifier。
- Dashboard 只能显示 Error，却看不出是哪个 System Layer 产生的。
工程启发
- 在重要 System Boundary 记录 Input 与 Output。
- 使用 Stable ID 串联 Model、Retrieval、Tool 与 Runtime Event。
- 围绕 Operator 在 Diagnosis 时真正需要回答的问题设计 Trace。
关键结论
- 01有用的 Observability 必须支持 Attribution。
- 02State Transition 比孤立 Timestamp 更重要。
- 03高质量 Evidence 能防止 Prompt Tuning 变成所有失败的默认修复方式。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。