生态位：不是每一步都需要旗舰模型
一个智能体完成一次任务，背后可能是几十次甚至上百次模型调用：理解指令、拆解计划、选择工具、填参数、读结果、纠错、汇总。如果把每一次调用都交给最贵的旗舰模型，成本与延迟都会以任务步数为倍数放大——一个跑一百步的智能体任务，用旗舰模型的账单可能是小模型的几十倍，端到端延迟也完全不同。而智能体的每一步并不是同等重要的：读一个网页把价格字段抽出来、判断这条评论是正面还是负面、把日期格式化成标准格式，这些机械步骤与「决定下一步该做什么」的战略步骤，对模型能力的要求天差地别。智能体的工程优化里，模型选型是杠杆最大的一根——选对了，成本与延迟同时下降一个量级；选错了，要么烧钱要么出错。本库旧篇谈性能优化竞赛时，梳理的是推理基础设施层面的速度之战；本篇把视角收到应用层，讨论模型能力与任务需求的匹配：小模型到底能不能跑智能体？可行域在哪里？混合路由怎么做才不掉坑？
这个问题在当下有特殊的现实意义。一方面，开源模型社区的追赶速度惊人，小尺寸模型的工具调用能力以肉眼可见的速度逼近上一代旗舰；另一方面，智能体的商业模型普遍脆弱，token 成本占了运营成本的大头，「用更便宜的模型跑同样的任务」几乎是最直接的降本手段。理解能力边界，是所有智能体团队绕不开的功课。
Agent 任务的能力拆解：模型到底需要会什么
五项核心能力
把「跑智能体」这个模糊的说法拆开，模型需要的能力可以归纳为五项。第一是结构化输出的可靠性：智能体与世界的接口是工具调用，模型必须把意图转换成严格符合参数定义的调用格式——字段名不能编造、枚举值不能越界、类型不能错乱；格式错误一次，任务链条就断一次。第二是长上下文的保鲜度：任务做到第五十步时，模型是否还记得第一步的用户约束；几十万 token 的上下文里，它能否准确找到那条关键信息而不是被无关内容淹没。第三是指令跟随的稳定性：系统提示词里写了「金额超过一千必须询问用户」，模型在第一百次调用时是否还在遵守——长任务里的规则漂移是小模型的常见软肋。第四是多步规划与状态跟踪：把「订一张下周二靠窗的机票并同步到日历」拆解成可执行序列，记住哪些子任务已完成、哪些失败需要重试。第五是从错误中恢复的能力：工具返回报错、网页结构变了、参数被拒绝，模型能否读懂错误信息并调整策略，而不是原样重试三次然后放弃。
能力要求的错配：机械步骤与战略步骤
关键观察是：这五项能力在智能体循环的不同步骤里，要求的强度完全不同。信息抽取、格式转换、分类路由、模板填充这类机械步骤，主要依赖第一、三项能力的浅层部分——输入输出模式固定、判断空间狭窄，小模型在足够窄的任务定义下完全胜任，甚至在微调之后可以超过通用大模型的发挥，因为大模型的「聪明」在窄任务里反而是噪声。而任务分解、歧义消解、方案取舍、错误恢复这类战略步骤，依赖第四、五项能力的深度——需要在开放可能性中做判断、需要在长程上下文里保持一致性、需要对「哪里可能出错了」做推理，这里仍然是大模型的领地。对真实智能体任务的步骤分布做统计，多数任务里机械步骤占七八成，战略步骤占两三成——这个比例就是小模型的机会空间，也是混合路由的经济学基础。
开源小模型的可行域
结构化任务上的快速逼近
开源社区的追赶成绩在结构化任务上最为显著。以函数调用能力为口径的公开评测（如伯克利的函数调用基准）上，新一代七到十四亿参数级的小模型在简单与中等复杂度的调用场景里，正确率已经逼近甚至追平部分上一代旗舰模型；中文语境下，通义千问的开源系列在尺寸与能力的平衡上表现出色，Llama、Mistral 等开源家族的小尺寸版本也在持续迭代工具调用与指令跟随。更进一步，针对特定任务做监督微调后的小模型，在窄域任务上往往可以稳定超过通用旗舰——用几千条高质量的抽取样本微调一个三十四亿参数模型，让它在「从发票里抽字段」这一件事上做到接近满分的准确率与极低的延迟，这件事在今天已经是成熟工艺。代码补全是另一个小模型证明自己的领域：主流编码工具的自动补全环节普遍采用数亿到数十亿参数量级的小模型，因为补全场景高频、低延迟要求苛刻、上下文局部性强，小模型的性价比无可替代。
开放式规划的短板与能力悬崖
但可行域的边界同样清晰。在需要长程规划、复杂工具编排、从意外错误中恢复的场景里，小模型与旗舰的差距不是线性缩小而是存在「悬崖」：任务复杂度超过某个阈值后，小模型的任务完成率断崖式下跌——它不是做得慢一点或差一点，而是整个链条的逻辑崩塌：计划里漏掉关键步骤、参数凭空幻觉、错误后反复原样重试、长上下文里的约束被遗忘。开源小模型在接近真实生产复杂度的软件工程基准（如以真实仓库问题为题的评测）上的表现与旗舰模型的差距，至今仍是数量级的差距。小模型的能力曲线是「窄任务近乎满分、宽任务突然归零」的悬崖形，而旗舰模型是「宽任务也有六七十分」的缓坡形——智能体产品的设计者必须知道自己的任务分布落在曲线的哪一段。还有一个工程现实不能忽略：同样标注「支持函数调用」，不同模型的实现质量差异巨大——小模型在高并发、嵌套调用、中文参数值等边缘场景的稳定性，往往要靠自建评测集实测才能暴露，公开榜单的分数不能直接外推到你的业务场景。
成本与延迟的量化
成本与延迟的差距支撑着整个混合路由的经济学。按公开定价口径，旗舰模型的 API 价格与开源小模型的托管价格相差一个数量级上下，自建部署的小模型推理成本可以更低——在自有显卡上跑一个七十亿参数的量化模型，边际成本几乎只有电费与硬件折旧。延迟的差距同样显著：小模型的 首 token 延迟普遍只有旗舰的几分之一，吞吐更高，这对交互式智能体是体验级差异——用户对「响应快但不总是最聪明」的容忍度，远高于对「每次都聪明但每次都慢」的容忍度。端侧是另一个战略维度：手机与电脑的本地算力已经足以运行数十亿参数级的模型，苹果等厂商的端侧智能功能采用的就是三亿参数量级附近的端侧模型——端侧跑智能体的价值不在省钱，而在隐私与离线：数据不出设备、无网环境可用，这两点是云端方案永远给不了的承诺。当然，自建部署有隐性成本：显卡的资本开支、推理服务的运维、模型升级的迁移成本，对中小团队来说，托管的开源小模型 API 通常是比自建更理性的起点。
混合路由的工程实践与陷阱
路由设计的三个层次
混合路由的工程实现可以分三个层次递进。第一层是规则路由：按步骤类型静态分配模型——抽取与分类走小模型，规划与决策走大模型；实现简单、行为可预测，适合任务结构稳定的产品。第二层是分类器路由：训练一个轻量的路由模型或用规则加启发式，按输入的复杂度信号（长度、任务类型、历史失败率）动态分配；RouteLLM 一类的学术工作给出了系统的框架——用大模型与小模型的偏好对训练路由器，在质量损失可控的前提下显著降本。第三层是置信度升级：默认小模型执行，执行结果的置信度不足或下游校验失败时升级到大模型重跑；这一层的前提是「失败必须可检测」——输出有校验器（格式校验、规则断言、交叉一致性检查）才能触发升级，没有校验机制的升级路由形同虚设。市面上的成熟实践已经不少：主流编码工具的模型选择功能让简单补全走小模型、复杂重构走旗舰；开源智能体框架普遍支持按步骤配置模型；一些团队干脆维护「任务类型到模型」的映射表，像管理依赖版本一样管理模型分配。
三个典型陷阱
混合路由的陷阱与它的收益一样具体。陷阱一是路由错误级联：小模型在关键步骤悄悄出错且错误通过了表面校验，下游步骤基于错误结果继续执行，最终产物面目全非——应对之道是把路由粒度从「步骤的类型」升级为「步骤的风险」，不可逆或高影响的步骤一律走大模型加人工确认，路由器为每一步标注风险等级而不是任务类型。陷阱二是上下文迁移成本：不同模型之间切换要重新传输甚至重新压缩上下文，token 费用与延迟可能吃掉省下的差价；对话式任务尤其明显——为了省一毛钱把一次摘要调用路由到小模型，额外传输的上下文可能值五毛钱。应对之道是按「上下文复用簇」划路由边界，同一工作上下文内的连续步骤尽量用同一模型。陷阱三是双套提示词的维护负担：同一任务在小模型与大模型上的行为不一致，提示词、参数、后处理逻辑都要分别调教，回归评测的工作量接近翻倍；模型升级时两套都要重测。混合路由不是免费的午餐，它用工程复杂度换成本，这笔交换只有在任务量大、结构清晰、校验完备的产品里才是划算的。
可行性边界的判断清单
把本篇的分析收拢成判断清单。第一，给智能体的每一步标注两个属性——机械程度与风险等级：高机械、低风险的步骤是小模型的领地；低机械、高风险的步骤绝不妥协。第二，建自建评测集再选模型：公开榜单分数与你的业务场景之间隔着分布差异，用自己的一两百条真实任务样本实测候选模型，比看任何排行榜都可靠。第三，算总账而不是算单价：把上下文迁移、重试率、失败返工、双套维护成本都计入，小模型方案的总成本优势经常比单看 token 价钱的预期小得多。第四，用校验器武装每一条小模型输出：格式断言、规则校验、置信度阈值，失败可检测才配谈降本。第五，把「模型升级即重测」写进流程：开源模型迭代速度以月计，每一次更换候选模型都要全量跑回归评测——模型是依赖项，按依赖管理。第六，端侧与隐私需求单独评估：数据敏感场景下，端侧小模型的战略价值超过它能力上的让步。
小结
「小模型能不能跑智能体」这个问题的答案是条件式的：在机械步骤上能，在战略步骤上不能；在窄任务上能，在开放任务上不能；在失败可检测的环节能，在失败即灾难的环节不能。把条件式答案当作绝对答案的团队，要么在错误的环节省了不该省的钱，要么在可以省钱的地方烧了不必要的预算。
开源小模型的进步是真实且快速的：函数调用与结构化输出的评测分数持续逼近上一代旗舰，微调后的小模型在窄域任务上已经可以稳定超过通用大模型，代码补全等高频低延迟场景早已是小模型的主场。但能力悬崖同样真实：长程规划与错误恢复的复杂度阈值一过，小模型的表现断崖式下跌，公开榜单的分数不能外推到真实生产任务。
混合路由是当下的最优工程实践，也是最容易踩坑的实践。规则路由、分类器路由、置信度升级三层递进，路由的粒度要按风险而不是按类型标注；上下文迁移成本与双套提示词的维护负担，是这笔「工程复杂度换成本」交易里最容易被低估的两项开支。
更长远地看，模型选型正在从一次性决策变成持续性运营：开源社区以月为单位出新模型，旗舰与开源的差距在每个能力维度上独立变化，团队需要的是一套持续评测、持续路由、持续迁移的机制，而不是某个「正确答案」。在这门功课上投入的工程能力，会成为智能体产品真正的成本护城河。
读者留言
COMMENTS 暂无还没有留言，来说第一句？