# 把 Agent 的方向盘交给小模型，谁来踩刹车？

> 级联省钱的前提不是小模型够聪明，是刹车踩得住。

```text
[读者] 正在给 Agent 降本的后端 / 平台工程师
[痛点] 全量走大模型账单太高，换小模型又怕任务崩
[现在读] 因为你正准备上「小模型先答、拿不准再回退」这一版
[读完] 能拿到置信度校准 + 回退闸门的可执行落地方案
```

```text
[旧方案] 一次任务里所有决策点，一律调大模型
    |
    v
[新需求] 成本和延迟都要压下来，任务成功率不能明显掉
    |
    v
[冲突] 小模型单题答得对，串成整条任务就崩
    |
    v
[后果] 省下的 Token，被返工和重跑吃回去
```

我是老李，在腾讯云做 Agent 平台相关的事。最近被问得最多的一句话是：级联到底能不能上？

我的一般回答是：能上，但你要先回答一个更难的问题——小模型答错的时候，你怎么知道它错了？

大部分团队卡在这里，不是卡在模型选型，而是卡在「没有刹车」。所以这篇不谈哪个小模型更强，只谈一件事：把方向盘交出去之后，刹车装在哪。

小模型在孤立题目上答对，是不是就等于整条任务能跑通？

决策点是按「题目类型」拆着交给小模型，还是按「置信度」统一交给一个全局阈值？

如果这个阈值是拍脑袋定的，任务成功率掉下来的时候，你靠什么把车停下来？

# 01、故事

我们平台上有一个 Agent 负责「查订单 → 判断异常类型 → 选工具 → 填参数 → 生成回复」这条链路。任务是：在十几秒内完成一次售后咨询的自动处理。

V1 很朴素——链路里每一个决策点，全部走同一个大模型。选工具问一次，填参数问一次，判意图问一次，决定要不要转人工再问一次。它能跑通，也能上线，但账很难看：一次任务要串行调好几次大模型，延迟叠起来，成本也叠起来。

真正让这件事变成问题的，是需求变了：业务方要求把单次任务成本压下来，P95 延迟压进可接受区间，同时任务成功率不能明显掉。于是「级联」被提上桌：简单决策先问小模型，拿不准再回退大模型。

听起来很合理。可我们第一次跑的时候，端到端任务成功率是往下走的。而那篇讨论 Agent 决策的论文里恰好有一句很扎心的话：孤立题目答得好，不等于整任务成功；未调整阈值的工具委托，曾让任务成功率下降 19 个百分点（见 [arXiv:2610.21412](https://arxiv.org/abs/2610.21412)，具体数值属该论文实验条件，不可直接外推）。

我们踩的，大概就是同一个坑。

> 单题答得对
> 整链未必通
> 省一笔小钱
> 赔一轮返工

# 02、问题

旧方案失效的点，不是小模型不够强，而是「单点正确率」这个指标本身失效了。

业务影响是清楚的：一次错误的工具选择会触发一次错误的工具调用，前端拿到错误结果，用户重问，整条任务重跑。省下来的是几次小模型调用，赔进去的是一次完整重跑加上用户的信任。

技术表现有三条，都很典型。第一，单点准确率看着还行，但一条链路上有七八个决策点，误差是乘起来的，不是加起来的。第二，错误会传播：参数填错，后面每一步都错，可日志里每一步都显示「成功」。第三，你无法区分「小模型很自信地答错」和「小模型明显拿不准」——因为这两者在日志里长得一模一样。

所以这一版的完成标准，我写成四条可验证的：在固定评测集上，端到端任务成功率不低于全大模型基线（容差事先声明）；单位任务成本下降；P95 延迟不劣化；每一次回退都能在轨迹里被定位，看得见 kind、置信度、阈值、是否回退。

做不到第四条，前面三条都是运气。

> 指标看单点
> 失败看整链
> 差在传播处
> 补在观测点

# 03、原理

芒格讲的系统一与系统二，用在这里特别贴：系统一是熟悉且低风险的选择，快速完成；系统二把复杂情境交给审慎判断。级联就是让系统一先上，系统二兜底。

但真正决定成败的，是机会成本怎么算。机会成本不只是省掉的 Token，还包括错误路径导致的返工——重跑一次任务、重新调一次大模型、重发一次消息、多一次人工介入。写成一句话：级联的净收益 = 省下的调用成本 − 回退成本 − 错误路径返工成本。前半项很好算，后面两项才是账本的主体。

反直觉判断：小模型单点准确率的提升，几乎不改变级联的净收益；真正改变净收益的，是你能否在它答错的那一刻识别出它错了。

第二个反直觉判断：级联省下的不是「模型调用」，而是「重复决策」。同一种决策类型在一条链路里、在成千上万条任务里被反复问，开销才显著；一次性、高风险、不可回滚的决策交给小模型，是纯亏。

生活里的类比很好懂：老司机开车，路口下意识打方向，那是系统一；下暴雨、上结冰路面，就必须切回系统二。级联的置信度阈值，就是「下暴雨」的判据——它不该是一个全国统一的气温值，而该是按路况分开的判据。

> 快脑管熟路
> 慢脑管险途
> 机会成本里
> 返工最昂贵

# 04、架构

```text
[输入] 一次任务中的单个决策请求（kind + prompt + 有限候选项）
    |
    v
[模块] 路由器 Router：小模型推理 + 阈值表 + 回退闸门
    |
    v
[数据/状态] 置信度、按 kind 校准的阈值、完整轨迹
    |
    v
[处理] 置信度 ≥ 阈值 → 采用小模型；否则回退大模型
    |
    v
[输出] 决策结果 + 来源标记 + 可回归的轨迹
```

边界在哪里：只有能列出有限候选项、且结果可被结构校验的决策点，才适合放进这条链路。开放式生成、需要长上下文推理、不可回滚的写操作，直接走大模型，不要放进级联。

收益是什么：把重复决策的开销从大模型挪到小模型，同时保留一条能兜底的路径。代价是什么：决策路径变复杂，可观测要求变高，你还得维护一张阈值表，并且这张表会随模型和业务漂移。

适用条件是三条同时成立：决策点可枚举、错误可被发现、错误可回退。少一条，级联就是在赌。

> 一档分快慢
> 一闸定放行
> 一轨留证据
> 一线可回退

# 05、实战一次

环境：Python 3.10+，不依赖特定模型 SDK（模型版本与参数以当前官方文档核验为准）。目标是把最小闭环跑通：先只做 shadow，不真正执行小模型结果。

```python
from dataclasses import dataclass, field
from typing import Callable

@dataclass
class Decision:
    kind: str                 # 决策类型，如 tool_choice / param_fill / intent
    prompt: str
    options: list[str]        # 有限候选项

@dataclass
class Result:
    answer: str
    source: str               # shadow / small / large
    confidence: float
    traced: dict = field(default_factory=dict)

# 阈值先给保守初值，后续用真实轨迹重新拟合
THRESHOLDS = {'tool_choice': 0.90, 'param_fill': 0.95, 'intent': 0.85}

def decide(d: Decision,
           small: Callable[[Decision], tuple[str, float]],
           large: Callable[[Decision], str],
           shadow: bool = True) -> Result:
    ans, conf = small(d)
    thr = THRESHOLDS.get(d.kind, 1.0)
    traced = {'kind': d.kind, 'threshold': thr, 'confidence': conf}

    if shadow:
        # 只记录不执行：小模型答案与大模型答案并存，供事后拟合阈值
        return Result(ans, 'shadow', conf, traced)

    if conf >= thr:
        return Result(ans, 'small', conf, traced)
    return Result(large(d), 'large', 1.0, traced)
```

为了能直接跑，配两个占位实现（真实场景替换为模型调用）：

```python
def fake_small(d: Decision) -> tuple[str, float]:
    return d.options[0], 0.71

def fake_large(d: Decision) -> str:
    return d.options[0]

if __name__ == '__main__':
    d = Decision('tool_choice', '订单还没到，能退款吗',
                 ['refund', 'query_logistics', 'transfer_human'])
    r = decide(d, small=fake_small, large=fake_large, shadow=True)
    print(r.source, r.traced)
```

运行：

```bash
python cascade.py
```

示例输出（占位实现，仅验证链路可通）：

```text
shadow {'kind': 'tool_choice', 'threshold': 0.9, 'confidence': 0.71}
```

未在当前环境实测，以上为预期结果。V1 到此为止，故意留下两个问题：shadow 不执行，等于没有收益；阈值是拍脑袋的，等于没有校准。这两个问题正好是下一章要查的。

> 先跑通最小
> 再记录影子
> 不急着执行
> 先攒够证据

# 06、排查

**诊断链一。** 现象：shadow 日志里置信度几乎全落在 0.7–0.9 之间，按初版阈值几乎全部要回退，等于白干。怀疑：阈值定得太高。检查：拉出各 kind 的置信度直方图，再对每段置信度统计该段在真实轨迹里的正确率。证据：某个 kind 在 0.7 分段的实际正确率并不低。根因：置信度未校准——模型输出的分数与实际正确率不单调对应。修复：按 kind 分箱，画出可靠性曲线，再定阈值。

**错误尝试：** 直接把全局阈值从 0.90 统一降到 0.70。为什么错：不同 kind 的「置信度—正确率」曲线形状完全不同，统一降阈值等于把高风险决策一起放出去，成功率掉得比成本省得多。这是我们第一次真正吃到「一刀切」的苦。

**诊断链二。** 现象：上线后任务成功率下降，可每一步的日志都显示成功。怀疑：小模型选错了工具。检查：按 trace_id 把轨迹还原，逐个决策点与全大模型基线比对，找第一个分歧点。证据：分歧集中在 param_fill，且几乎都出现在低置信区间被放行的情况下。根因：错误传播——单步无异常，整链失败，日志层根本反映不出来。修复：param_fill 提高阈值，并加 schema 校验，校验不过直接回退。

两条链的共性：能不能查到，取决于你有没有留轨迹。

> 一处先定位
> 一证定根因
> 一刀切阈值
> 一改全盘错

# 07、优化

根因明确之后，V2 只做四件事，每一件都对应上一条证据。

第一，按 kind 拟合阈值。用 shadow 阶段积累的（置信度，是否正确）样本，从高置信往低放，只要累计精度还满足目标准确率就继续放。

```python
def fit_threshold(rows: list[tuple[float, bool]], target_precision: float) -> float:
    rows = sorted(rows, key=lambda r: -r[0])   # 按置信度降序
    threshold, kept, ok = 1.0, 0, 0
    for conf, correct in rows:
        kept += 1
        ok += int(correct)
        if ok / kept >= target_precision:
            threshold = conf               # 仍达标，可以再往下放
        else:
            break
    return threshold
```

第二，高风险 kind 进白名单，直接不走小模型。第三，回退链路带 trace_id，任何一次回退都能回溯到具体任务和具体决策点。第四，加结构校验：工具名必须在候选项里，参数必须过 schema，校验失败即回退——把「自信地答错」挡在执行之前。

原因说清楚：前两条解决校准，后两条解决发现。新行为是同样的输入下，低置信请求自动落回大模型，且每一步都有来源标记。验证方式不写虚的：把端到端成功率、单位任务成本、P95 延迟、风险事件数四项放在同一张 A/B 报表里看，任何一项劣化都要能解释。

关于论文里 81.1–89.0% 的降本和至多 2.5 倍提速，必须说清楚：那些数字来自其特定实验条件，不能视为所有 Agent 的通用收益。我们的报表只能由我们自己的轨迹产出。相关工程侧的展开，可参考 [JevAgentHarness 深度解析](https://cloud.tencent.com/developer/article/2766335)。

> 按类分箱看
> 按需拟合闸
> 校验挡错参
> 回退兜风险

# 08、演进

```text
[同一输入] 一次任务里的同一个决策请求
    |
    +--[V1] 全局阈值 + shadow 记录
    |       代价：阈值未校准，回退率极高，收益接近零
    |
    +--[V2] 按 kind 校准阈值 + 结构校验 + 高风险白名单
    |       代价：需要离线拟合流程，需要维护阈值表并持续重拟合
    |
[Trade-off]
得到：在成功率可控前提下压成本；失去：路径更复杂、可观测要求更高；
边界：只有可枚举、可校验、可回退的决策点才适合进级联
```

比较一下。正确性上，V2 把「发现错误」提前到了执行之前，V1 只能事后统计。稳定性上，V2 依赖阈值表，表漂移就会退化，这是新的运维负担。复杂度上，V1 一个人半天能写完，V2 需要一条拟合流水线。成本上，V2 首次收益取决于回退率是否真的降下来，而不是模型有多便宜。适用范围上，两者都只覆盖有限候选的决策点。遗留问题仍然存在：置信度分数本身的可靠性，取决于小模型自身的校准水平，而这需要按当前官方文档核验并按版本重跑。

> 同输入两路
> 各付各的价
> 得在省与稳
> 失在复杂度

# 09、洞见

## 9.1 级联的收益来自「重复」，不来自「便宜」

反直觉判断：把最贵的那个决策点交给小模型，往往省不了多少；把最高频的那个决策点交给小模型，收益才显现。定位级联收益的正确姿势，是统计决策类型的分频次，而不是分单价。

## 9.2 置信度不是数字，是一张按类型分开的表

一个全局阈值之所以危险，是因为它把不同风险等级的判断压成了同一个刻度。分开拟合，本质上是在给每一种决策类型单独定义「什么叫拿不准」。

## 9.3 回退不是兜底，是可观测性的一部分

反直觉判断：回退机制的价值，一半在正确性，一半在让你看见小模型在哪里不行。没有轨迹的回退，只是把问题藏起来——成功率掉了，你连第一个分歧点都找不到。

## 9.4 论文的数字是实验条件，不是你的账

那 19 个百分点的下降、81.1–89.0% 的降本、至多 2.5 倍提速，都绑定在特定实验设定上。可以借鉴的是方法和结论方向——阈值要校准、要保留回退——不能直接搬的是数字。

> 便宜不是源
> 重复才是源
> 阈值不是数
> 是分类型的表

# 10、系统落地

原来有什么：一条全大模型的决策链，能跑通，但成本高、延迟长，且没有任何分级判断的能力。

本篇新增什么：一个路由器、一张按 kind 分开的阈值表、一条 shadow 通道、一个结构校验闸门、一份带 trace_id 的轨迹。

现在能做什么：在不明显牺牲任务完成率的前提下，把重复决策的开销降下来，并且任何一次异常都能回溯到具体决策点。

还缺什么：阈值表的自动重拟合与漂移告警；小模型版本升级后的回归基线；以及跨决策类型的联合评估——现在还是一个点一个点地看，缺少整链视角的自动归因。

下一步怎么演进：把 shadow 从「记录」升级为「常态对照」，让每一版小模型上线前都先跑一段影子流量；把阈值拟合嵌进 CI，模型换代即重算；再把四条指标做成固定看板，作为放量前的准入条件。

> 先有观测轨
> 再有阈值表
> 后有回退闸
> 才谈得上省

# 11、小结

```text
Q1 → 单题答对不等于整链成功，验收要看端到端成功率而不是单点准确率
Q2 → 按决策类型分别拟合阈值，高风险类型走白名单强制回退
Q3 → 阈值必须由真实轨迹校准，并保留可回溯的回退闸门
状态 → 一套能跑 shadow、能拟合阈值、能结构校验、能回退的最小级联闭环
```

> 单点不作数
> 整链才算数
> 阈值要校准
> 回退要留门

# 12、作业

## 12.1 理解题：为什么「小模型单点准确率 90%」不足以支撑级联上线？

参考答案：因为链路是多决策点串联，误差乘起来会放大；更重要的是单点准确率不告诉你错在哪、能不能发现、能不能回退。机会成本里返工占大头，而这部分在单点指标里完全不可见。

## 12.2 实战题：把本文的 shadow 模式改造为按 kind 分别拟合阈值，并给出验证方式。

参考答案：先用 shadow 收集（置信度，是否正确）样本，按 kind 分组；对每组调用 fit_threshold 得到候选阈值；写入阈值表前先在一段影子流量上回放，比较端到端成功率、成本、P95 延迟与风险事件数四项，全部不劣化才放量。

## 12.3 排障题：上线后任务成功率下降，但每一步日志都显示成功，你从哪里查起？

参考答案：先从 trace_id 还原整条轨迹，与全大模型基线逐决策点比对，找第一个分歧点；再统计该点所在 kind 的置信度分布与阈值，判断是校准问题还是阈值问题；最后加结构校验把这类错误挡在执行之前。

## 12.4 架构判断题：所有决策点都接级联，是否合理？

参考答案：不合理。级联只适合可枚举、可校验、可回退的决策点。开放式生成、长上下文推理、不可回滚的写操作应当直接走大模型，否则回退成本会吞掉全部收益。

> 题在纸上练
> 证在轨上找
> 判在取舍间
> 行在闸门后

# 13、思考

把方向盘交给小模型这件事，本身没有对错。有对错的是：你有没有在交出去的同时，装上一只能被验证的刹车。

芒格的双系统告诉我们快慢要分工，机会成本告诉我们账要算全。合起来就是一句工程判断：省钱要以不明显牺牲任务完成率为约束，而约束的执行点，是那张按决策类型分开的阈值表和那条随时能回退的路。

下一次有人问你「级联能不能上」，别急着报模型名字，先问一句：小模型答错的时候，你怎么知道？

> 一快辨熟路
> 一慢审险局
> 一闸定取舍
> 一轨见真章

我是老李，在腾讯云做 Agent 平台相关的事。最近被问得最多的一句话是：级联到底能不能上？

技术思考问题44：Jev级联省钱会误判？

级联不校准阈值就上线，省下的 Token 会被返工吃回去。本文讲清按决策类型拟合置信度、保留回退闸门的最小闭环，以及论文数字为何不能外推。

架构师

人工智能

架构设计

后端

级联Agent降本核心在于构建可验证的“刹车系统”：按决策类型分箱校准置信度阈值，仅对可枚举、可校验、可回退的决策点开放小模型。通过shadow模式收集轨迹、拟合阈值、加结构校验，以端到端任务成功率而非单点准确率为验收标准，确保省下的Token不被返工成本吃回。

代码解释

平台工程

路由器

路由

Agent

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

技术思考问题44：Jev级联省钱会误判？-腾讯云开发者社区-腾讯云

技术思考问题44：Jev级联省钱会误判？

技术思考问题44：Jev级联省钱会误判？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐