按提示长度路由LLM翻车：12词请求拖垮生产Agent

构建自己的OpenAI兼容聊天网关时，分层路由几乎是必选项：便宜的模型处理琐碎调用，昂贵的模型负责真正的推理。问题在于——用什么指标来决定一个请求该走哪条路？一位开发者分享的实战经历，揭示了一个看似合理却埋着大坑的启发式规则。

一个过于简单的路由规则

最初的方案简单到有些尴尬：按提示（prompt）总长度来分流。字符数低于约500的走经济（eco）层，高于500的走高级（premium）层。这条规则通过了作者写的每一个测试用例，上线时看起来毫无破绽。

逻辑上这很符合直觉——长提示意味着更复杂的任务，自然需要更强的模型。但这里混淆了两个本质不同的维度：长度衡量的是成本，而不是能力需求。一个请求消耗多少token，和它需要模型具备什么样的能力，是两件事。

12个单词如何拖垮整条Agent循环

问题在生产环境中暴露得猝不及防。一个Agent开始陷入死循环：同一个请求重复执行二十次，始终无法收敛。

作者拉出调用追踪后发现，用户的提示极短——“summarize this and call the report tool”（总结这段内容并调用报告工具），满打满算十来个单词。但这个请求随身携带了六个工具定义（tool definitions）和一个JSON模式标志。

路由器只看到一个短提示，于是把它发给了机群里最便宜的模型。那个模型写散文没问题，但在工具调用上很不可靠：大约有一半的概率，它会用自然语言作答，而不是真正触发任何工具调用。Agent把这种回答判定为失败，于是重试，然后再次失败，循环就此形成。

工具定义（tool definitions）是OpenAI函数调用（Function Calling）协议的核心组成部分。每个工具定义包含函数名称、描述和参数的JSON Schema，模型需要理解这些结构化定义并在合适时机输出符合格式的调用指令，而非普通文本。这对模型的指令遵循能力（instruction following）和结构化输出能力要求很高。不同模型在工具调用上的能力差距远大于在普通文本生成上的差距——一些经济型模型在基准测试中写作表现尚可，但在工具调用场景下准确率断崖式下降。JSON模式标志（JSON mode flag）则要求模型的每一次输出都是合法的JSON，同样属于对模型格式控制能力的强约束。这两类约束都属于"非此即彼"的硬性能力门槛：模型要么能可靠地做到，要么就会以不可预测的方式失败，没有中间地带。

70%的成功率在循环里等于零

这个案例最有价值的洞见，是关于概率在Agent循环中的复合效应。

带有工具定义、结构化输出约束或图像输入的请求，存在一个硬性的能力下限（capability floor）——无论文本多短，模型都必须具备对应能力才能正确响应。一个预算型模型或许能在70%的情况下正确执行，但在一个需要反复迭代的Agent循环内部，70%的单次成功率会被不断复合，最终的表现趋近于“永远不会成功”。

换句话说，单看一次调用，70%听起来还行；但放进需要连续多步正确的循环里，这个数字会迅速坍缩。这是很多Agent系统“偶发卡死”背后被忽视的数学真相。

这里的数学可以量化地说明问题：假设单次工具调用成功率为70%，一个需要连续4步工具调用都正确才能完成的Agent任务，整体成功率为0.7的4次方，约为24%。如果需要连续6步，整体成功率跌至约12%。更现实的Agent循环往往不止于此——当模型失败后Agent会重试，而重试本身也消耗成功率预算，系统很快陷入"越重试越失败"的负反馈。这一现象在可靠性工程中被称为"串联系统失效"（series system failure）：链条上每个环节的不可靠性都会被放大，而不是互相抵消。这也是为什么Agent系统对底层模型的能力要求，比单轮对话场景严苛得多——单轮调用中可以接受的成功率，在多步自动化流程中可能是完全不可用的。

修复：能力优先，长度其次

真正的修复只花了一个下午，核心是调整了判断顺序：

• 先检查能力标志：请求是否声明了工具（tools）？是否带有JSON schema？是否包含图像？任何一项命中，就直接路由到经过验证的最低可用层级。
• 长度只在能力类别内部起作用：在确定了能力等级之后，长度才用来做层级内的进一步细分。
• 增加响应验证器：如果一个请求声明了工具，但返回的回复里没有任何工具调用，路由器会自动升一级重试，而不是把一堆无用的内容扔回给调用方。

这套“能力优先、长度其次”的规则，本质上是把路由决策从单一的成本维度，拆解成了“能力准入 + 成本优化”两层。

结果与可复用的经验

改动上线后，使用工具的Agent循环率从“持续的涓涓细流”降到了近乎为零。更重要的是，经济层的开销几乎没有上升——因为真实流量中的绝大多数，本就是不带工具的聊天长度提示，它们依然安稳地走在便宜的通道上。

作者最终把这套路由逻辑打包成了一个OpenAI兼容的LLM Chat API，提供auto/eco/premium三个层级，其中auto层编码的正是这条规则。

对于正在搭建带工具调用的Agent循环的开发者，这个教训值得记在心里：不要让一个纯成本的启发式规则，仅凭提示长度来决定路由。成本可以优化，但能力是不可妥协的准入门槛。先确保模型“做得到”，再去谈“做得便宜”。