Appearance
Trace、Eval 和 OpenTelemetry 怎样共用同一条 Run Identity
前置：恢复、重试和人工审批怎样共享同一执行事实
核心问题：Trace、Eval、OTel 都要观察同一次 Run，怎样共享证据模型而不让三套 SDK/Schema 侵入 Runtime？
Model、Tool、Checkpoint 都产生统一 domain events；Eval 读取同一套 Run/Trace artifact，OTel Exporter 再把它们映射到标准字段。关键是 先有内部证据模型，再做评估和导出，而不是让 OTel SDK 或 Eval 数据结构渗透进 Runtime。
Trace Pipeline
Runtime 发布 typed domain events；TracePipeline 负责把它们映射成 spans/metrics、做 redaction/sampling/export。业务组件不直接拼 OTel attributes。
telemetry backend 故障可以降级，但不能改变 RunState；trace id/span link 必须能回到 run/node/tool_call identity。
Evaluation Harness
Evaluation Harness 复用生产 domain contracts，但运行在离线/CI 路径：加载固定 dataset + manifest，执行 Scripted/Fake 或真实 provider，最后由 grader 比较结果和 trajectory。
Eval 读取 Run/Trace artifact，不写生产 RunState；deterministic software contract 仍由 tests 负责。
OpenTelemetry Export Wiring
内部 trace model 保持 domain 语义，再通过 mapper 输出 OTel GenAI/W3C 标准，降低 vendor lock-in。标准字段演进时只更新 exporter mapping。
同一次失败怎样被三条路径看到
search_docs 超时后，Runtime 产生一次 canonical ToolExecution event：
text
run_id=r-42 node_id=n-3 tool_call_id=tc-8 attempt=2 status=TIMED_OUTTracePipeline 把它变成线上 span；Evaluation Harness 把同一 identity 纳入 trajectory；OTel exporter 再映射到外部 semantic conventions。这样 CI 中看到“tc-8 第二次尝试超时”时，可以直接跳回生产 trace，而不是靠 tool 名和时间戳猜测是不是同一次动作。
Failure Modes
Trace、Eval 与 OTel 使用不同 identity
症状： Runtime 用 tool_call_id，Eval 用数组下标，OTel 又重新生成 operation 名称。
为什么危险： 一次失败无法从离线评估追到线上 span，也无法可靠比较两次 Run。
处理： run_id / node_id / tool_call_id / attempt 由 domain 统一定义；Trace、Eval、Exporter 只做映射，不重新发明 identity。
如何验证
| Case | 断言 |
|---|---|
| 同一 Tool failure 进入 Trace、Eval 与 OTel | 三条路径都能通过相同 run_id/tool_call_id/attempt 关联，Exporter 故障不改变 RunState。 |
自测
- 为什么 model call、tool call、retry、queue event 应共用同一个 Run identity，才能让 Eval 与 Trace 对上同一次执行？
- OTel export 失败时是否应该让业务 Run 一起失败？这个选择暴露了 observability 与 execution 的什么边界？