可观测性为什么对 Agent 尤其困难？
- 概念来源: 借自分布式系统领域——无法直接打开系统内部看它在做什么，只能通过日志、指标和追踪数据来推断;
- 类比: 医生不能直接看到患者体内情况，只能通过体温、血压、影像等外部信号诊断;
- 额外难度: 同样的输入可能产生不同的输出，多轮推理和工具调用使执行路径极其复杂，而模型的 “思考” 过程对外完全不透明;
可观测性带来哪四类价值？
- 问题诊断: 完整的轨迹让开发者能回放全过程，而非靠猜测;
- 持续优化: 能看到哪些任务需要多轮迭代、哪些工具成功率最低、哪些检索查询总是返回空结果;
- 成本管理: Agent 运行成本在不同任务上可能差一两个数量级，追踪可以识别异常高成本的案例;
- 数据积累: 积累的轨迹数据为模型后训练提供基础;
追踪（Trace）的数据结构是什么？
- trace: 一次任务执行对应一条 trace;
- span: 每个 LLM 调用、每次工具调用、每次检索都是一个 span，记录输入输出、起止时间、token 消耗与错误信息;
- 树形结构: span 之间的父子关系构成一棵执行树，如 “Agent 主循环” span 之下挂着若干 “LLM 调用” 和 “工具调用” 子 span;
标准协议带来什么好处？
- OpenTelemetry: 通用的分布式追踪标准;
- OpenInference: 在 OpenTelemetry 之上定义 LLM 应用特有的语义约定，如如何记录提示词、模型参数、token 用量;
- 好处: 采集与分析解耦，同一份追踪数据可以对接不同的分析后端，避免被单一平台锁定;
可观测性平台提供哪些能力？
- 代表平台: LangSmith，类似定位的还有 Langfuse、Arize Phoenix，将可观测性、评估、优化整合为闭环;
- 记录粒度: 每次执行创建一个追踪会话，模型调用、工具使用、知识检索被记录为独立执行单元，通过因果关系链接形成执行树，每个单元记录完整输入输出、时间、成本与错误信息;
- 性能保障: 采用异步批量数据采集，确保追踪本身不影响 Agent 的响应延迟;
- A/B 测试: 将一部分用户流量路由到新版本，自动对比各项指标，支持快速回滚或渐进扩量;
- 提示词版本管理: 每个版本都关联运行时的性能数据;
- 协作式开发: 团队成员可共享追踪数据和问题案例;
- 数据价值: 生产环境的海量真实数据能发现未曾预料的场景，识别最需要优化的功能点;
轨迹如何回流为评估资产？
- 闭环: 从生产轨迹中筛选失败与可疑案例 → 脱敏处理（去除用户隐私、密钥等敏感字段）→ 沉淀为评估集的新用例和回归测试;
- 效果: 评估集不再是一次性构造的静态集合，而是随产品演化、持续贴近真实用户分布的活资产;
- 表述: 今天线上暴露的失败模式，明天就成为守住这条底线的回归用例;
- 相关: 回流用例的归因与改造见 失败归因、端到端与轨迹前缀回归;
- 约束: 数据收集的隐私合规设计见 内部评估基础设施;