25｜生产运行：Trace、成本、队列、灰度与回滚

术语带虚线时可点击速查。公式中的字母先看定义；不要用猜缩写替代推导。

本章不把“加日志、做监控”当作答案。我们要能从一条慢任务的轨迹中分离等待、模型、工具、恢复和验证，并解释系统在哪个环节接近容量边界。所有数字都是教学假设，不是厂商报价或生产实测。

继续看相关机制：F24 · 任务状态不是聊天里的一句总结O06 · 连续组批：有座位空出来，就接下一位O12 · 模型路由：便宜一次，不一定便宜一项成功任务

Q097｜一个Agent任务应该怎样记录Trace，才能定位“慢、贵、错”？

核心回答

把一次用户任务作为逻辑根，把检索、模型调用、工具执行、压缩和验证作为子操作；记录因果关系、输入版本、输出状态和资源消耗。Trace回答“这次发生了什么”，指标回答“总体怎样”，日志和证据对象回答“具体细节是什么”。三者不能互相替代。[SRE][OTEL]

一条轨迹里的对象与关联键

设任务t7经过检索r2、模型请求m3、工具调用c19、恢复rec1。m3产出c19，但c19可能由另一个工作进程执行。关联应依赖稳定ID，而不是“看时间差不多”猜它们是一组。

任务 t7
  检索 r2：索引 rev42，命中 doc8@v3
  模型 m3：上下文 manifest17，生成 tool-call c19
  执行 c19：资源 fileA@r42 → 结果 unknown
  核验 rec1：读取 fileA@r43，确认副作用已发生
  模型 m4：看到核验结果，不重复修改
  验证 v9：在工作区 r43 上运行测试

每次模型调用至少区分请求模型、返回模型标识、输入量、可观测的缓存量、输出量、响应状态和耗时。推理用量是否单列、如何计费取决于接口，不应自行由最终文本长度猜测。每次工具调用记录参数摘要或受控引用、权限结果、执行状态与外部操作ID。完整敏感参数不应默认进入公共日志。

若两个工具并行，各自耗时8秒和10秒，不能把18秒直接算成这段用户等待；关键路径可能约10秒加调度成本。若跨度间存在队列等待，却只给执行函数打点，监控会显示“工具很快”而用户仍等很久。应分别记录入队、开始、完成。

追问：不存完整Prompt，还能调试上下文遗漏吗？

可以存上下文清单：片段ID、来源版本、角色、加载原因、Token估计、裁剪状态和最终排序。它不能重建全部文本，但可发现“本该加载的文件没有进入请求”。需要内容重放时，再使用有权限、有限保留的证据存储。清单与正文分离是诊断能力和隐私的折中。

追问：为什么不要把用户ID、完整Prompt放进指标标签？

这些值数量极大，会产生高基数时间序列，增加存储和查询成本；还可能泄露信息。指标适合有限集合，如工具类别、结果类型、版本组。单个任务的高基数字段放到受控Trace或日志中，用指标异常跳转查看。

追问：Trace里的“成功”应该由谁决定？

模型API成功只说明调用完成；工具成功只说明工具返回成功；任务成功应由验收结果决定。根跨度最好同时保存终止原因和业务验收结果。否则“生成了一段答案”会掩盖零测试、部分完成或外部写入失败。

Q098｜为什么“每Token便宜”不等于“完成工作便宜”？成本应怎样算？

核心回答

成本单位应是满足质量要求的一次任务，而不是一次模型请求。总成本包含成功和失败尝试、检索、工具、验证、人工返工以及运行资源；缓存、模型路由和并行只有在质量与总成本一起比较时才有意义。[LATENCY][PCACHE][EVALS]

从单请求账单走到任务成本

设第i次调用的未缓存输入、缓存输入、输出分别为uᵢ,cᵢ,oᵢ，单价为pᵤ,p꜀,pₒ，则模型成本是各调用的pᵤuᵢ+p꜀cᵢ+pₒoᵢ之和。若产品另收缓存写入、工具或其他费用，需要按其口径加项，不能把未知费用默认为零。

两个教学方案：A每次尝试成本1单位，成功率0.8；B每次成本0.6，成功率0.4。假设失败后独立同分布重试、没有重试上限、成功质量相同，成功前期望尝试次数为1/p，所以成本分别1.25与1.5。B单次便宜，成功一次反而更贵。现实中独立假设常不成立：同样缺证据的重复运行可能持续失败，所以不能盲目用此公式预测生产账单。

实践应在同一任务集比较：总花费、成功数、失败类型、总延迟分位数、人工介入量。还要分层看简单与复杂任务；总体均值可能掩盖便宜模型在某类高风险任务上的明显退化。

追问：缓存命中率越高越好吗？

不一定。不断携带大量无关历史可能提高缓存命中，但增加逻辑上下文、解码注意力读量或信息干扰。缓存命中是中间指标，最终仍看质量、账单和耗时。删除无用前缀也可能牺牲一次命中却降低后续长期成本。

追问：什么时候选更强模型反而更省？

当更强模型显著减少错误工具调用、无效搜索、返工或人工审查时。需要在控制任务和工具条件的对照试验中确认。不能只根据模型名称或单个精彩案例断定；也不应让简单确定性任务默认使用最大推理预算。

追问：预算耗尽时应该丢掉验证步骤吗？

通常先缩小承诺或停止新增修改，而不是把未验证结果包装为完成。可预留验证与收尾预算；若已不足，输出已完成、未验证、风险与恢复位置。一个“看起来完成”的未核验结果，可能把成本转嫁给后续维护者。

Q099｜并发越大吞吐越高吗？怎样从排队理解Agent延迟？

核心回答

并发只在资源尚有余量时帮助提高利用率；超过模型、工具、数据库或配额的容量，新增任务主要进入队列。稳定系统中Little定律L=λW连接平均在途任务数、平均到达率和平均停留时间，但它不是无条件的容量规划保证。[SRE][SLO]

从请求进入到离开

任务到达后先入队，等待可用执行槽；取得槽位后仍可能等待模型配额或外部工具。若一个任务持有昂贵工作进程却长期等远程网络，会降低资源利用率。可将可恢复任务状态与短时执行资源解耦，但这会引入持久化和调度复杂度，不能为了架构漂亮而一开始全拆开。

教学例：平均每秒进入2个任务，平均停留30秒，在稳定观测范围内平均在途约60个。若只准备20个同步工作槽，系统能否稳定取决于每个任务实际占用槽位的时间，不能只用最终回答延迟推算。若每个槽完整占用30秒，理论服务率上限约20/30，低于到达率2，积压就会持续增长。

尾延迟来自长任务、服务时间方差、队头阻塞、重试风暴和资源争用。对交互式短任务和批量长任务采用不同队列或配额，可减少相互干扰；但优先级不能无限饿死低优先级任务。应有最大等待、取消传播、背压与明确拒绝，而不是无上限接收。

追问：为什么增加超时可能让故障更严重？

它延长了资源占用与在途请求寿命。下游变慢时，上游继续接收并延长超时，内存、连接和工作槽会被堆满。超时应与任务语义和端到端截止时间匹配，重试有总预算，不能每层独立把重试次数成倍叠加。

追问：CPU利用率不高，为什么仍然排队？

瓶颈可能是GPU显存、KV容量、每分钟Token配额、外部API并发、数据库锁或人工批准。监控应覆盖队列与稀缺资源，而不是只看CPU。大量等待型任务甚至会出现CPU很低、用户体验很差的组合。

追问：SLO应该只规定P95响应时间吗？

还应包含任务正确性、可用性或人工介入等目标，并定义哪些任务纳入分母。否则系统可以通过快速拒绝或输出空答案“优化延迟”。异步长任务可把受理延迟、有效进展与最终完成分开，不宜套用普通网页响应指标。

Q100｜Agent系统上线时究竟要版本化什么？回滚为什么不只是换回模型？

核心回答

最终行为由模型、提示、工具Schema、技能、检索索引、记忆策略、权限、运行器和评测规则共同决定。上线要保存可追溯组合，灰度观察结果；回滚必须处理已写入状态和外部副作用，而不仅切换模型名。[EVALS][SLO]

一个能解释回归的版本清单

模型：明确版本或服务返回标识
上下文：组装策略、模板与技能版本
检索：语料版本、embedding版本、索引构建ID
工具：schema版本、执行器版本、权限策略
状态：checkpoint与记忆schema版本
验证：测试集、grader版本、验收规则

假设同一天更换模型、压缩摘要格式和代码索引，成功率下降。没有版本清单就很难区分原因；一次只改变可归因的少数变量，先离线回归，再小范围真实流量观察，更利于判断。灰度不是把危险操作随便分给少量用户；高风险能力仍应先有权限与验收保障。

回滚前检查新版本写入的记忆和checkpoint是否能被旧版读取。若摘要schema变化，旧运行器误读“unknown”为“failed”可能重复写入。外部订单、邮件、部署不会因程序回滚自动撤销；需要按业务语义核验与补偿。更安全的回滚可能是停止新增写操作，保留只读核验与人工接管，而不是继续跑不兼容旧代码。

追问：为什么不能只用最新Benchmark分数选模型上线？

Benchmark任务、工具、资源和成功标准未必与你一致。应把候选模型放进自己的Harness和历史失败集测试，尤其检查结构化输出、工具遵循、长上下文和成本。公开成绩提供候选信号，不替代本地验收。

追问：提示只改了一个词，需要版本吗？

若该提示影响生产行为，就应能追溯具体内容；但不需要为每个文字变化建立复杂审批层。版本化用于归因与回退，审批深度取决于风险。不要把“可追溯”误解为“每次都要多级Review”。

追问：如何知道优化已经可以停止？

当主要失败模式已被解决，新增机制在代表性任务上没有可辨认收益，或收益小于成本与维护风险，就不应继续堆规则。保留监测与真实失败回流，等待新证据触发改动。这比持续追求完美流程更符合工程目标。