F38｜看懂生产运行：Trace、队列、成本和回滚

从具体对象与小例子开始，理解计算过程与适用条件。

一次任务到底慢在哪里

总时间可能包括排队、上下文检索、模型输入处理、生成、工具等待、重试和验证。只记录“总计60秒”不能说明该换模型、改检索还是减少工具轮次。

Trace（调用轨迹）把同一任务的相关步骤关联；Span记录一个具体操作的开始、结束与属性；Log日志记录事件细节；Metric指标汇总大量运行的统计值。三种观察互补。

用一条教学轨迹分账

排队2秒
检索1秒
模型调用5秒
工具测试8秒
模型总结2秒
总计18秒（这个例子假定顺序执行）

若工具测试是最大项，仅压缩最后总结的Token不会把总时长降低一半。若步骤并行，总时间要看关键路径，不能把每个span耗时盲目相加。

TTFT、TPOT与端到端延迟

TTFT是从请求开始到第一个输出Token到达的时间；TPOT描述后续每Token生成时间的某种统计；端到端延迟是用户任务整体完成时间。

首字出来很快，后续工具执行很慢，用户仍会觉得任务慢。输出很多无用文字可以让界面显得活跃，却不改善完成时间。

吞吐与延迟不是一对同义词

吞吐量throughput是一段时间完成多少工作；延迟latency是一项工作等待多久。批量处理可能提高吞吐，却增加部分请求排队时间。

当请求到达速度逼近系统可处理速度，排队可能迅速变长。平均值还会掩盖尾部慢请求；p95表示某统计窗口中约95%的观测不超过该值，不是最大值。

在稳定系统和相应条件下，Little定律常写L=λW：平均在系统中的任务数=平均到达率×平均停留时间。它帮助核对队列与延迟，但不是无条件适用于任何瞬时波动的精确预测。

成本应算整个任务

模型输入、输出、缓存命中、工具、失败重试和人工介入都可能有成本。不要只比较“每百万Token价格”，忽略便宜模型导致的多轮返工。

也不要为了降低Token把关键证据删掉。更好的目标是在满足质量与风险要求下，减少无效读取、重复分析、无进展调用和不必要审查。

SLI、SLO是什么

SLI是服务水平指标，例如规定时间内正确完成的请求比例；SLO是该指标目标，例如某业务对可靠性和时间的要求。目标应连接用户结果，而不是只保证API返回200。

错误预算描述在可靠性目标允许范围内可承受的失败量，用于平衡变更速度和稳定性。这是管理思路，不要求个人实验也建立复杂运营平台。

灰度、回滚和版本组合

灰度发布canary先让小范围流量使用新版本，观察后再扩大；回滚退回已知较稳定的配置。Agent系统版本可能包含模型、Prompt、工具、Skill、索引、权限与记忆规则，不能只记模型名。

若新版本已写入错误记忆或修改外部系统，仅换回旧模型未必消除影响。需要核验派生数据和副作用，必要时单独修复。

追踪也要保护隐私：默认不要保存全部敏感Prompt和凭据。记录足够定位问题的身份、版本和脱敏证据，比无条件日志越多越好更合理。

课后自检

机制依据：[SRE][SLO][OTEL][LATENCY]。本节数值与情景除另注外均为原创教学示例；来源不代替中文讲解。