我用一个“不会说话”的模型砍掉了 Agent 里五分之四的大模型调用先说结论我改造了一个内部使用的多工具 Agent把它每天的大模型调用量从日均十多万次降到了两万次左右。没有牺牲明显的回答质量用户可感知的延迟反而下降了近一半。核心思路并不复杂——我把“必须生成内容”的任务和“只需要做判断”的任务拆开了后者全部从大模型手里拿走交给一个只会输出向量和标签的“哑巴”模型。“不会说话”的模型指的就是嵌入模型、向量检索、小型分类器这类非生成式模型。它们不会写文案、不会推理解释、不会跟你聊天但它们能做一件事快速告诉你“这个输入属于哪个类别”“这两段话是不是一个意思”。我踩了不少坑之后才意识到Agent 里绝大多数大模型调用其实都是在让一个“全科专家”去干“判断题”的活费钱、费时还费上下文。这篇文章不聊算法创新就聊工程取舍什么场景适合用哑巴模型替代大模型替换后怎么维持兜底质量成本账怎么算以及我实际踩过的几个坑。如果你手里也有一个每天烧 token 的 Agent这篇文章应该能帮你在不降体验的前提下把账单打下来一大截。1. 为什么需要动这个手术调用分布里的“必将浪费”先看一个典型的 Agent 工作流用户发来一个问题系统先识别意图再决定用哪个工具然后从记忆里翻找相关信息生成回答之前可能还要判断工具返回的结果是否合法最后如果用户反馈不对还要重新调整一遍。拆开看这一整套流程里塞了至少四到五次大模型调用。问题是这几个环节并不都需要“生成”。意图识别是典型的选择题候选意图是固定的工具选择也是选择题工具列表就摆在那里记忆召回本质上是检索不需要大模型把每段历史都读一遍再做阅读理解。但是很多 Agent 在上线初期图省事统一用大模型去处理这些事。最典型的场景就是为了让 Agent 判断用户说的一句话该走哪个分支你直接把整句话拼进 Prompt让大模型输出一个意图标签。一次调用成本可能不高但每天几万次请求积少成多账单就非常可观了。在我的模拟项目 X 里改造前的基线是这样的日均请求数约 1.5 万次平均每个请求在大模型侧消耗 4.5 次调用单次调用平均延迟 750 毫秒到 1 秒。算下来每天大模型调用量超过 6 万次如果遇到用户来回追问实际数值能到 10 万次以上。从调用链的火焰图看意图识别和记忆判断这两环占了大头但这两环恰恰是判别式任务杀鸡用了宰牛刀。另一个被忽视的问题是上下文污染。每个环节都给大模型塞上一大段上下文既有系统提示词又有动态插入的候选数据调用次数一多整体延迟和 token 消耗就会互相叠加。更不要说大模型偶尔还会“自由发挥”在固定分类任务里输出个似是而非的标签下游拿到这种标签还要再做一层解析。用一个词概括就是浪费。所以我做的第一件事不是优化 Prompt也不是换更强的模型而是把调用分布拉出来逐个环节问自己这一步真的需要大模型吗这一步是在“做决定”还是“做表达”如果是前者那就把它从大模型链路里摘出去。2. 怎么判断哪些调用能砍判别与生成的分界线很多人问我的第一个问题是你怎么确保砍了之后不出问题我说关键是先分辨每个调用到底在做什么。大模型擅长的是生成——根据上下文造出新文本。但 Agent 链路里大量环节需要的只是一个“决策结果”不是一段话。决策结果可以是一个分类标签、一个相似度分数、一个抽取出的结构化字段。这些都不需要语言生成能力只需要判别能力。我给团队定了一个“可替换判据”三条同时满足就可以考虑把调用从大模型换成轻量模型候选集有限且稳定。比如你只想让 Agent 支持五类指令这就是有限候选集如果候选集每天都增减改造难度就大了。输出形式是固定标签或数值。例如“调用工具A还是工具B”“给这段文本打情感正负标签”输出形态简单适合用分类器或阈值判断。输入结构与分布相对稳定。比如用户问法变化不大或者说这个环节只接收固定 Schema 的结构化数据。反过来如果任务需要理解开放语境、输出新文本、多步推理、处理超长尾的新意图那大模型仍然不可替代。我保留了大模型调用的环节包括生成最终回复内容、工具调用后的结果总结、多步推理过程中的复杂规划、以及用户输入明显超出已知意图时的兜底回答。拿记忆召回做例子。改造前我的代码会把最近 20 条历史消息全部塞进 Prompt让大模型判断“当前问题跟哪几条历史记录相关”。这本质上就是一个检索任务而我用大模型做检索算法上完全不占优——向量检索在小范围和超大规模下都更稳定还能做得更快。改造后就变成先把历史会话切片做嵌入向量存进向量库收到新问题时只需要把当前问题编码成向量算一下余弦相似度取 Top-K 条相关记录。这一步彻底移出了大模型链路。用一张表可以看得更清楚任务环节本质类型改造前改造后意图识别多分类大模型输出 JSON嵌入向量小分类器记忆召回检索排序大模型阅读历史并判断向量检索 Top-K工具选择候选集匹配大模型逐个分析工具描述嵌入相似度 阈值输出格式校验规则校验大模型自我纠错重试JSON Schema 校验开放域回答生成文本生成大模型大模型保留当然边界不是一成不变的。后续如果意图数量膨胀到几千种或者用户输入风格发生剧烈漂移我会再把一部分任务交回大模型处理。判断的标准永远是“要不要创造力”没有创造力的环节能用哑巴模型解决的就不该浪费大模型。3. 我用什么模型替换怎么工程化落地方案选型上我没有一上来就搞微调而是先用现成的向量编码模型做嵌入再在外面套一个轻量分类器。原因是项目初期样本量不足直接训练端到端模型很容易过拟合而嵌入模型能复用自己的语义理解能力。具体链路是输入文本 → 向量编码 → 分类器得到意图标签和置信度 → 超过阈值的直接走路由置信度过低的再升级给大模型兜底。这样既能保证准确率又不会让用户感觉到系统“变笨了”。3.1 意图识别路由嵌入向量加线性分类器我以“工具选择路由”为切入点用现有工具名称和对应的描述作为候选集。实现上分三步第一步收集历史请求。从项目日志里抽出用户较常用的若干种问法大概每类意图攒了 200 到 500 条真实请求覆盖主动询问、反悔改口、口语化简写等不同变体。第二步把文本转成向量。我用的是一个通用向量编码模型将单条输入编码成固定维度向量不需要任何微调。这一步多花了几台机器的算力但收益是省下了大模型 token 费用一进一出很划算。第三步训练轻量分类器。我选用了一个多分类逻辑回归模型输入向量输出各类别的置信度。代码逻辑大致如下from sklearn.linear_model import LogisticRegression from sklearn.model_selection import cross_val_score # X 为历史请求编码后的向量y 为意图标签 clf LogisticRegression(max_iter1000, C1.0) scores cross_val_score(clf, X, y, cv5, scoringf1_macro) print(f交叉验证 F1: {scores.mean():.3f})模型本身推理耗时在毫秒级占用资源远小于大模型 GPU 推理。分类器输出的置信度会进入一个路由模块逻辑是置信度大于 0.7直接返回意图标签置信度在 0.4 到 0.7 之间返回候选集合和分数低于 0.4直接降级调用大模型。这种分级处理保证了一点新玩法出现时系统不会瞎猜而是会把问题交给能猜的大模型。3.2 记忆召回从逐条阅读改成向量检索 Top-K记忆召回是这次改造里收益最大的环节。原来的流程是拼历史记录让大模型判断相关性又慢又费 token改造后我用了一个轻量向量库存储会话切片的嵌入向量。对新问题做同样的向量化检索出最相关的 K 条记录再把这些记录拼进 Prompt留给大模型做的只剩一件事基于召回结果生成简洁回复。这里不再需要大模型“判断”生成质量也没有明显下降。关键细节是切分历史记录的方式。直接按条切分会把一句话上下文切碎我改成按“用户提问 系统回复”的回合组合作为一个文档切片这样切出来的片段语义更完整。检索时我用了混合权重final_score 0.7 * semantic_score 0.3 * recency_bonus加时间衰减的权重是因为 Agent 业务场景里用户最近聊的内容通常比很久之前的历史更相关。单纯的向量相似度往往会找出一堆泛泛相关的旧内容加这一项之后召回质量肉眼可见提升。3.3 工具选择与参数校验结构化优先生成后置工具选择的改造有点特殊。我们内部有十几个工具每个工具的候选描述比较固定我用工具名称加功能描述建了一个小索引请求进来时用向量相似度匹配工具排序后取前两名作为候选再交给后续的规则模块决定到底调哪个。之前大模型要做的是读几十个工具描述再挑一个现在候选集只有一个很小的目标准确率和速度都有保障。参数校验这一环以前经常出现大模型返回的 JSON 格式不对系统让大模型“重试修正”。后来发现最靠谱的校验工具是 JSON Schema跟模型完全无关。我在需要结构化输出的地方先定义好 Schema然后直接对生成结果做本地校验失败时用词法层面的修复手段而不是再花一次大模型调用去“自我纠错”。这一项直接省掉了约 20% 的额外调用。3.4 输入守卫用规则加小分类器过滤无效请求上线之后我发现日常请求里有相当一部分根本不需要大模型任何生成能力。比如用户连发了几个感叹号或者直接发了个“在吗”又或者发送的是乱码和无意义字符。以前的流程会把这串东西原封不动扔给大模型请它抽出意图然后大模型一本正经地回一句“对不起我没看懂你的问题”。这看起来没有很贵但考虑到每天都有大量这种无效请求累计起来就是一笔不小的开销。我加了一个输入守卫层先用正则和长度统计把明显乱码、空内容拦截掉再用一个简单的短文本分类器判断“这是一个有效用户请求”还是“无效输入”。只有通过守卫的请求才进入后面的轻量路由和重模型生成链路。效果非常显著一天的调用总量里大概有 12% 到 15% 的无效请求被拦在了大模型链路外面。这条经验也值得复用任何 Agent只要是面向真实用户的就一定会出现大量无关输入。不要指望大模型帮你免费过滤它只会帮你把钱花掉。4. 成本账五分之四是怎么省出来的改造前我在日志系统里加了两个关键指标每次请求的大模型调用次数和总延迟。改造后的数据显示单个请求平均大模型调用次数从 4.5 次降到 0.9 次绝对值降幅正好是 80%。这 0.9 次来自哪里主要是最终回复生成和低置信度情况下的降级兜底。其他环节包括意图识别、记忆召回、工具选择、输入守卫全部跑到了轻量模型和规则逻辑上。我把日请求量 1.5 万次、单次调用成本假设为 0.002 美元做了个估算改造前15000 × 4.5 × 0.002 每天 135 美元改造后15000 × 0.9 × 0.002 每天 27 美元折合下来光是大模型 token 费用每天就能省 100 美元出头。加上延迟收益——轻量模型环节耗时从原来的 800 毫秒降到 50 毫秒左右——用户侧感知的整体响应速度明显更快了。之前我担心省了钱会不会以牺牲质量换回来实际上由于大模型承担的“判断题”少了它在真正需要生成的环节里反而表现得更稳定。再补充一个容易忽略的收益稳定性的提升。大模型推理是有随机性的同一个分类问题这次返回标签 A下次可能给你返回标签 B。而分类器不会这样——固定输入固定向量固定权重输出结果永远一致。这带来的好处是下游逻辑更容易调试不需要为了“大模型偶尔抽风”这种事件写一堆兼容逻辑。成本收益的量化对照可以参考这个简表指标改造前改造后降幅平均大模型调用次数/请求4.50.980%平均响应延迟端到端约 3.2 秒约 1.8 秒44%单日 token 成本估算135 美元27 美元80%高频意图识别错误导致的重试率约 6%1.5%75%当然这里有个前提是必须有足够的历史数据来训练或校准轻量模型。如果从零开始没有历史请求记录直接就上分类器那是不现实的。我在项目早期靠的就是大模型在跑跑了一个月之后积累出样本才敢动手改造。5. 踩过的坑与排查实录整个改造并非一帆风顺。几个典型问题我列出来供你参考。5.1 向量相似度不等于语义正确性第一个大坑发生在意图识别环节。我用向量相似度顶替大模型做意图分类时发现系统把“我想取消我的订单”识别成了“修改订单”。从语义上讲取消和修改确实接近但对业务而言这是完全不同的动作。原因在于纯向量检索是“找最像的文本”而不是“理解命令的意图”。后来我在向量层之上加了小分类器用历史标注样本修正边界同时保留低置信度兜底这才解决了问题。光靠相似度做意图识别真的是看似省事实则翻车。5.2 冷启动阶段标注量不足分类器在冷启动阶段效果不佳因为每个意图只有 20 多条数据过拟合严重。我的应对方法是两条腿走路一是用大模型的输出作为“伪标签”先生成一批标注数据二是每个意图至少积累了 50 到 100 条人工确认过的真实样本后才把它纳入分类器的路由范围。宁可用大模型多顶几天也不要不成熟地硬上线。5.3 置信度阈值调不好兜底调用反而飙升最初我把阈值设得很高0.85 以下全部降级给大模型结果兜底率高得离谱省了个寂寞。后来我画了一下置信度分布图发现大量正确预测的置信度集中在 0.6 到 0.8 之间真正错误的预测往往低于 0.4。所以我调成了三段式0.7 以上直接走轻量路由0.4 到 0.7 走候选集人工确认或二次小模型判断低于 0.4 再降级给大模型。调整之后兜底率从 35% 降到 12%但整体准确率基本没掉。5.4 缓存与记忆混淆我还做过一个蠢事把常见问答的答案直接缓存以为能省更多调用。但业务场景里不少问题是带个人上下文的我不能拿一个人的回答去回复另一个人。后来我设计缓存时严格区分两类一类是纯知识型、无个性化的问题可以缓存答案另一类是涉及用户订单、账号状态的问题绝不缓存只允许走实时生成链路。这块如果做混了轻则体验变差重则出严重事故。5.5 监控指标要盯全面最后一条经验是监控。不要只看降了多少调用量还要看这三个指标用户反馈的负面评价率、低置信度兜底率、意图分类的定期抽检准确率。我每周会抽 200 条请求做人工标注对照系统决策看偏差。哪怕成本已经降下来了我也要保持这个抽检动作因为用户说法会漂移今天的新热词明天可能就变成意图里的新分支。还有一个我自己踩到的细节大模型和哑巴模型之间要保持一个平滑的“逃生通道”。我的实现是在路由代码里加了开关配置一旦小模型效果下滑可以一键把某个环节恢复成大模型处理不用改一行代码。这种逃生通道在早期很关键否则一旦小模型出问题你连回滚都要大动干戈。从我个人的实际体会来说Agent 优化这件事大多数时候不是靠更聪明的模型而是靠更克制的使用。让会说话的模型专注于说话让不会说话的模型去干分类和检索这样每一分成本都花在刀刃上。这个项目做完之后我还想把同样的思路扩展到更多场景比如把高频知识问答完全做成嵌入检索加规则回复只在真正需要创作内容时才把大模型请出来。这套减配策略后续应该还能继续磨得更细。