升级率：离线测试遗漏的评估信号

每个智能体（agent）功能都有一个“后门”。有的团队称之为“转人工支持”，有的称之为“路由至人工审核员”，还有的则使用模板化的回复：“我无法处理此事——让我为你联系能提供帮助的人。”无论标签是什么，每个生产环境中的智能体都有一条放弃用户请求并将其移交给人工的路径。而生产流量采取该路径的比例，是少数几个不依赖标注员、评审员或手动构建测试集的信号之一。这是系统在生产环境中告诉你，模型无法处理用户实际发送的请求。

这个信号几乎总是被错误的团队读取。在大多数公司中，转人工率（Escalation rate）是一个劳动力规划指标：它决定了下一季度排队系统需要多少人工客服。它存在于运营团队审查的仪表板上，其审查频率与 AI 团队读取评估分数（eval scores）的频率完全不同。30% 的周环比转人工增长在周一的运营审查中表现为一个人员配备问题，而 AI 团队的评估套件依然显示绿色，领导层的报告也显示功能状态良好。两个团队看着同一个生产系统，却得出了截然相反的结论：运营团队认为他们需要更多人手，而 AI 团队认为模型运行良好。

这种矛盾中隐藏着一个架构层面的认知：智能体能力最真实的信号，是生产环境用户“逃离”智能体的比例。评估分数衡量的是智能体处理你选择的问题的能力。转人工率衡量的是智能体处理用户实际带来的问题的能力。这是两种不同的分布，当它们发生背离时，生产环境的分布才是决定功能是否真正起作用的唯一标准。

为什么评估分数保持绿色，而转人工率却在攀升

离线评估是从团队几个月前策划的固定测试集中抽样的，随着时间的推移，团队会根据想到的案例进行增补。而生产流量是从用户决定的所有问题的整个空间中抽样的，且这个空间是会发生偏移的。新产品的发布会改变话题组合。营销活动会将不同细分市场的用户引向同一个入口。竞争对手的宕机会导致来自从未出现在你训练分布中的人群涌向你的支持智能体。季节性模式会带来你的团队从未想过要包含的问题，因为没有人会为“如何在假期截止日期两天后询问退货截止日期”编写基准测试。

这些分布偏移都不会改变评估分数，因为评估并不会对它们进行抽样。但转人工率会立即发生变化，因为输入是真实的，而智能体决定逃避这些输入，则是对模型无法取得进展的如实承认。这个信号一直存在，只是它被当作了成本杠杆，而非质量杠杆。

一个具有启示意义的行业基准：在混合成本模型的规划计算中，通常假设 AI 到人的转人工率约为 22%，健康的平台根据任务复杂度落在 15% 到 30% 之间。这个数字被视为人员配备计划中近乎常量的输入，而不是一个通过评估反馈来降低的变量。这种计算隐含的意思是“这就是 AI 能力的底线，围绕它进行规划即可”。评估团队很少被告知这个数字的存在，更不用说它比他们运行的任何基准测试都更能准确界限真实的 AI 能力。

区分“正常转人工”与“放弃处理”的分类法

首要建立的规程是具备路由感知的分类法。并非每一次转人工都是失败。如果政策规定只有人工才能授权退款，那么智能体拒绝处理支付争议请求并转人工是正确的做法。但如果智能体因为用户措辞方式未触发其检索查询而拒绝退款问题，那就是失败。从队列的角度看，这两者是相同的：产生了一个工单，由一名人工处理。但从 AI 团队的角度看，它们应该产生截然相反的信号。

一个可行的分类法至少应区分以下四种情况：

• 政策性转人工（Policy escalation）：智能体本可以回答，但路由规则要求人工介入（超过限额的退款、受监管的决策、身份验证流程）。这些在版本发布中应该是平稳的。趋势变化通常意味着路由 bug，而非模型 bug。
• 能力性转人工（Capability escalation）：智能体尝试了请求，尝试了工具，检索了上下文，生成了草稿回复，但由于置信度低或后验检查失败而选择移交。这些是 AI 团队的核心信号——它们对应于智能体应该学习处理的输入。
• 拒绝性转人工（Refusal escalation）：智能体出于安全原因拒绝了请求。这些需要针对实际内容进行审查，因为在队列中，过度拒绝看起来与正常拒绝完全一样。
• 放弃性转人工（Abandon escalation）：用户在对话中途放弃，并通过其他渠道联系人工。这些是转人工流程本身未能捕捉到的质量失败，需要跨渠道整合会话数据才能发现。

如果没有这种分类法，这四种情况对人员配备的影响是相同的（都需要人工处理），但每种情况对 AI 的影响却不同（路由修复、评估缺口、校准漂移、交互损耗失败）。只汇报单一数字的团队在结构上无法对此采取行动。

斜率告警优于阈值告警

关于转接率（Escalation rate）的阈值告警是错误的原语。“当转接率 > 25% 时告警” 的触发太晚，起不到作用 —— 当绝对数值触发阈值时，评测差距（eval gap）已经存在数月，而扩招报告（headcount memo）都已经写好了。关于 SLO 告警的 SRE 手册中有一种对此类信号更实用的模式：多窗口消耗率告警（multi-window burn-rate alerting），即观察指标在不同时间窗口内的斜率，当短窗口和长窗口同时恶化时触发告警。

对于转接率，对应的原语如下：

• 短窗口检查（过去 6 小时）：捕捉急性回归 —— 例如一次错误的 Prompt 部署、某个工具损坏、或是一个改变了拒绝姿态（refusal posture）的模型升级。
• 长窗口检查（过去 7 天）：捕捉任何定点评审都无法察觉的缓慢漂移 —— 逐渐演变的话题组合、在用户群体中蔓延的 Prompt 注入模式、或是逐渐过时的检索索引。
• 按话题、用户细分和路由路径进行的分群拆解（cohort breakdown）：确保全局平均值不会掩盖某个切片中 4 倍的飙升。

其目标是将转接率转化为 AI 团队以对待延迟或准确度回归一样的紧迫感来处理的指标 —— 基于斜率告警，而非绝对水平。六周内从 18% 到 24% 的缓慢漂移应该在第三周之前触发调查，而不是在第八周触发一份人员编制报告。

将转接后的对话记录挖掘回评测集

另一项准则是完成闭环。今天的转接案例就是明天的评测用例，如果不将转接后的对话记录导回评测套件，团队就是在支付了信号的代价后却白白浪费了它的价值。

以下几种生产模式可以让这一流程生效：

• 转接追踪的自动聚类。 按失败面进行分组 —— 哪个工具没有返回结果，哪个检索调用返回了错误的文档，Agent 在决定转接前执行了哪一步。近期的 Agent 可观测性工具已趋向于将 40 个失败案例聚类为一个带有频率统计和代表性追踪记录的“问题”（issue），而不是 40 个独立的告警。这种聚类原语使“生产失败 → 评测用例”变得可行；如果没有它，AI 团队面对的将是人类规模无法评审的海量数据流。
• 人机协同的治理步骤（human-in-the-loop curation）。 并非每个转接都应成为评测用例 —— 用户放弃和政策性转接对评测团队来说是噪音。能力缺失导致的转接需要被整理、脱敏，并作为带有标注预期行为的新测试用例加入。整理队列本身变成了一个带有 SLA 的工作流：运行 72 小时整理周期的团队比运行季度批处理的团队拥有更快的评测反馈环。
• 将评测增长映射到转接群体的覆盖率报告。 如果“国际物流”群体的转接率上个月增长了 40%，那么该群体的评测集也应按比例增长。覆盖率报告让闭环变得可见，并在领导层询问“模型是如何变好的”时，为 AI 团队提供具体的答案。
• 评测驱动的 Prompt 或检索变更。 一旦某个群体有了评测覆盖，团队就可以发布针对性的修复 —— 检索模式的更改、新的工具描述、或是在小规模数据集上的微调 —— 并观察下个月该群体的转接率变化。这就是将转接转化为能力的闭环。

这是一个让系统从“我们靠雇人来消化失败”转变为“我们靠发布来减少失败”的闭环。每一个被整理进评测用例的转接，都是下一个版本不会再犯的失败模式。每一个转接率下降的群体，都是在真实生产流量中衡量出的真实能力提升。

组织层面的修复比技术层面更难

技术部分 —— 分类法、斜率告警、追踪聚类、整理流水线 —— 一个优秀的平台团队在单季度内就能构建完成。组织变革才是阻碍大多数公司实现这一点的门槛。

转接率必须呈现在 AI 团队自己的仪表盘上，并拥有与延迟或准确度相同的值班严重级别。当这个数字波动时，AI 团队必须与运维团队保持相同的评审节奏。运维团队必须清楚哪些趋势线代表“模型回归”，哪些代表“业务量真实增长”，这样关于人员编制的讨论才能与模型投资的讨论合流，而不是平行运行。并且必须有人 —— 通常是偏向平台的 PM 或跨团队背景的工程主管 —— 来负责定义某一周的转接波动到底是人员编制问题还是模型问题，因为在大多数公司，这个问题从未被明确提出过。

做得好的公司将转接率视为考核 AI 团队的产品指标。做得差的公司将其视为运维成本项，留在劳动力管理看板上，并一直困惑于为什么他们的评测分数不断上升，而排队等待处理的任务却在不断增长。Agent 没有通过评测，是因为评测没有看到 Agent 真实的工作表现。

前瞻性要点

如果你在 2026 年发布了一个 AI Agent，却不知道上周按群组 (cohort) 细分的转人工率 (escalation rate)，那么该模型的反馈闭环运行速度比你还快——生产环境的用户正在教它什么是它做不到的，而你却充耳不闻。请将该指标接入 AI 团队的评审周期。建立一套分类体系，将“正向的转人工”与“隐性失败”区分开来。针对斜率变化设置告警。按照你能实际达成的策展 SLA，将转人工的对话记录导回评测集 (eval set)。从生产环境“逃逸案例”中成长起来的评测套件，是唯一能跟上生产分布偏移 (production distribution shift) 的评测套件；而建立这种闭环的团队，才能以真实数据而非用户根本见不到的测试集差异 (test-set deltas) 来论证能力的提升。