可观测性：任务关联、时间线与故障定位

用户说“资料核验卡住了”，运维看见模型接口正常，开发看见工具没有报错。这两项信息都可能真实：任务也许还在队列里，也许等待审批，也许已经完成写入却迟迟没进入验收。

可观测性要能区分排队、等待、执行和验收。为此，同一任务经过的模块需要保留可关联的标识与状态。

三类标识承担不同职责

同一 Run 可以跨多个 Trace，同一 Operation 可以跨多个网络尝试。Trace 被采样丢弃时，操作键仍然必须保留在持久记录中。反过来，拥有操作键也不意味着能看清这次请求为什么慢。

不要把所有标识塞进指标标签。任务编号、资料 URL 和用户编号通常具有高基数，更适合受控日志或 Span 属性；指标可以按模型路由、工具类型、错误类别和发布版本等有界维度聚合。

一条任务的耗时可以包含排队、上下文准备、模型请求、工具执行、人工等待和验收。应分别记录，让“模型响应慢”不再成为所有延迟的默认解释。

下面是一份虚构时间线，仅用于说明计量口径：

端到端时间是 10 秒，不是各段相加的 13 秒。并行阶段应看关键路径和汇总等待；费用则需要统计两条分支实际消耗。用户等待时间与算力消耗不能共用一个总时长。

任务需要人工补充时，可以同时报告“用户经历的总时长”和“系统活跃处理时长”，但必须固定各自分母和暂停规则，不能通过把慢步骤标成等待来美化指标。

同步调用通常通过父子 Span 表达。经过消息队列、跨天恢复或异步子任务时，可以依据实际因果关系选择继续上下文或建立关联，而不是强行维持一个无限长的父 Span。

OpenTelemetry 的 Span Links 可以关联不同调用链中的相关工作，适合表达某些异步关系。需要同时保留业务 Run ID，才能从用户任务找到不同执行片段。OTel Traces 文档

业务标识连接跨时间的运行片段。箭头表示关联关系，不代表所有节点必须共享同一个 Trace。埋点 SDK 和 GenAI 语义字段也需要版本管理。不要假设某个示例里的字段会永久稳定；升级时核对所用约定的版本、稳定性和后端映射。OTel GenAI 字段注册表

先查询可信任务状态：尚未领取、等待输入、派发中、验收中还是终态。再沿发生问题的阶段检查证据。

模型生成的解释可以作为调查线索，但不是内部原因的可靠证明。显式计划、实际工具参数和可读取的资源终态通常比一段自述更容易核查。

头部采样在请求早期决定是否保留，无法预知后续所有错误。尾部采样可依据更完整的链路选择错误或慢请求，但需要缓存和处理资源；它也无法找回上游已经丢弃的数据。OTel Sampling 文档

如果优先保存失败 Trace，直接用这批 Trace 计算任务成功率就会产生偏差。业务指标应来自定义清楚的完整任务账本或适当设计的统计样本；诊断样本负责解释，不负责假装代表全部流量。

记录模型输入也要控制范围。可默认保留来源引用、摘要和配置标识，将必要原文放在受控存储；是否保存敏感正文应由具体业务与授权要求决定。日志、制品和缓存都需要自己的访问与留存规则。

选择故障实验的“写入后中断”场景，画出从 Run 到 Operation，再到实际工单的查询路径。接入真实观测平台时，补上 Trace 和故障分类，但保留独立账本。

在工作簿中写清三件事：一线人员先看哪里，什么证据允许安全重试，什么情况下应交给对账负责人。诊断完成后，把最小失败条件加入回归系统。