当 Agent 的每次模型请求和工具调用都有 Trace，调试会方便很多。但“可以看见调用链”与“可以拿来评测或训练”之间，还有一段工程距离。
这篇笔记采用一种职责划分：Trace 侧重解释执行过程，Trajectory 侧重组织任务的完整交互记录。不同平台的具体命名可能不同，关键在于数据契约。
Trace 解释哪里发生了问题
Trace 能把接入、排队、模型请求和工具执行关联起来，帮助定位耗时、异常与调用关系。对于并发工具和跨 Worker 的恢复，父子关系或 Span Link 也需要反映实际执行语义。
只有 Query 和 Response，通常不足以解释全部故障。还需要执行代次、步骤标识、工具结果、超时与重试记录，以及关联的环境版本。
轨迹组织可复用的任务记录
轨迹资产需要明确任务从哪里开始、观察到了什么、采取了什么动作、环境返回了什么，以及任务如何结束。模型、工具、环境和评分版本也会影响后续解释。
诊断 Trace 可能经过采样，正文可能因权限而被裁剪。用于数据集的轨迹应有自己的完整性校验和准入规则，不能默认每一条 Trace 都是完整样本。
从执行记录到数据集
一种处理链路是：接收执行事件，按任务与步骤整理，去重并校验完整性，再关联产物、反馈和版本。经过权限处理后，形成带血缘的数据集版本。
任务失败的轨迹也有价值，但应保留失败原因。平台超时、工具不可用与模型决策错误，不应该被不加区分地视作同一种能力失败。
trajectory = assemble(committed_events, artifact_refs)
validate_order_and_completeness(trajectory)
trajectory.failure_class = attribute_failure(trajectory)
asset = apply_access_and_retention_policy(trajectory)
dataset.add_versioned(asset, lineage=source_refs)与算法迭代连接
工程侧可以提供稳定的轨迹格式、数据版本、执行环境与实验入口；算法侧围绕这些接口定义样本选择、奖励与优化方式。
两个边界都需要协作：轨迹缺少关键观察，算法难以还原决策条件；评分规则没有版本，工程也难以解释实验差异。
因此，数据契约应在双方之间共同定义。训练后的候选版本再经过独立评测和发布门禁，才能闭合迭代流程。
可在 平台全景 中查看可观测、轨迹资产与实验发布之间的关系。