Span

执行轨迹（Trace）指一次完整任务执行过程中所有操作步骤的结构化记录，包括每次 LLM 调用的输入输出、工具调用的参数与返回值、中间推理状态及时间戳与耗时信息

在Agent场景中，应将一次完整的Agent任务视为一个Trace，每次LLM调用、工具调用、记忆检索都是一个Span

AI Agent的会话本质上是独立的运行时上下文，在初始化阶段完成工具注册并将工具注册表固定为启动时的快照，存续会话无法动态感知配置变更

事件日志中的事件天然对应分布式追踪中的Span概念，每个事件可携带TraceID和SpanID来还原完整的因果链路

Trace 和 Span 的概念源自分布式追踪系统（如 Jaeger、Zipkin），一次完整的请求链路被建模为一条 Trace，链路中的每个操作单元则是一个 Span，Span 之间通过父子关系构成有向无环图。

telemetry.dev 将 AI Agent 的每次运行映射为一条 Trace，每个模型调用和工具调用是 Trace 中的一个 Span，附带耗时、Token 用量、成本和错误信息。

在分布式追踪中，Trace代表一次完整的端到端请求流程，Run通常指Agent执行的一次完整任务生命周期，Span是Trace内部的最小工作单元，一个Run往往包含数十甚至数百个Span，通过parent_id构成树状因果关系。

解决方案是把采样单元从Span提升到Run：一次运行要么被完整记录，要么被完整摘要，不存在部分运行或孤儿Span。

将高维嵌入向量（如 768、1536 维浮点数组）存入 Span 属性会膨胀报文、增加序列化开销并耗尽下游存储引擎内存，且对人类不可读。

在 LLM 应用中，一次用户提问通常对应一条 Trace，内部的模型调用、向量检索、工具执行各自是一个子 Span。

Span 是分布式追踪的最小工作单元，代表一次有开始时间、结束时间和元数据的操作，多个 Span 通过父子关系或链接组合成一条 Trace。

OTel的核心数据模型是Span——代表一次操作的结构化记录，包含名称、起止时间、状态、属性（attributes）以及与其他span的父子关系；Trace由一组共享同一trace ID的span构成的有向无环图。

Phoenix 中展示的追踪结构本质上是一棵 Span 树，每个 Span 代表一次离散操作并记录开始时间、结束时间、输入参数与返回值

OpenTelemetry等主流追踪框架通过在代码中埋点生成Span，只能记录明确指定要记录的内容

将关键配置和权限范围作为Span属性快照进trace，是防御配置漂移问题的有效手段

Trace（链路追踪）概念借鉴自分布式系统领域的 OpenTelemetry 标准，核心思想是为一次完整请求生成全局唯一的 Trace ID 并传递给每个子调用（Span）