小模型代理栈为何未能成为默认选择，与它们能否工作无关

去年六月，NVIDIA 发表了一篇题为《小型语言模型是代理式 AI 的未来》的立场论文，当时很容易忽略其论点：代理实际执行的大部分工作都是些不起眼的任务，比如读取输入、选择工具、调用工具以及重新格式化输出，这些都不需要背后有 4000 亿参数的模型。该提案建议将那 80% 的常规工作交给小型专用模型，仅当任务确实值得时才回退到昂贵的前沿模型。这是一个干净利落的思路，但几乎无人采纳，在随后的大半年里，业界仍然坚持让每个代理的每一步都由一个巨大的模型来完成。今年春季的发布让这种习惯更难以为继。以下数据将这一观点从可能变为定论： * **Gemma 4 31B** 在 tau2-bench（代理工具使用基准）上得分 86.4%，而上一代产品（Gemma 3 27B）在同一次测试中仅得 6.6%。这 80 个百分点的提升来自于针对任务进行的训练，而非模型尺寸的飞跃。 * **Qwen3.6 27B** 在单张 RTX 4090 上运行，却在 SWE-bench Verified 上击败了阿里巴巴自家的 397B MoE 模型。其 35B-A3B 变体每个 token 仅激活 3B 参数，但在 MCP 基准测试中仍能与前沿代理保持同等水平。 * **Phi-4-reasoning** 是一个 14B 模型，在 AIME 上达到 70B 蒸馏模型的水平。 * **DeepSeek V4-Flash** 的每百万输出 token 定价为 0.28 美元，而 Claude Opus 4.6 为 25 美元，对于许多编程任务而言，两者效果几乎持平，但前者成本便宜约 89 倍。 相比于任何单一的基准测试数据，我更感兴趣的是为什么这种架构仍未成为默认选择，因为成本上的优势已经显而易见数月之久。诚实的回答是：最有能力推广它的人没有理由这么做。前沿实验室靠按 token 计费的方式出租一个大型模型来赚钱，代理平台大多只是围绕同一个模型的包装器，云容量也按此配置。唯一能从一群廉价专用模型中获益的是每月支付推理账单的客户，而客户不会撰写立场论文。NVIDIA 愿意这么做，是因为无论哪种架构胜出，它都出售硬件。 在小模型方面确实存在一个陷阱，值得在任何人拆除现有配置之前仔细思考。今年一月，Laksh Advani 发表了一篇论文《当小模型出于错误原因给出正确答案》，他审计了约 10,000 条来自 7B 到 9B 模型的推理轨迹，发现其中一半到三分之二的正确答案实际上是通过有缺陷的推理得出的。模型只是碰巧得出了正确的数字，而标准的准确率评分无法捕捉到这一点。 对此实际可行的对策才是最有用的部分： * **RAG 有帮助**：因为将模型锚定在真实证据上可以防止它编造推理所依据的值。 * **自我批评适得其反**：让一个 7B 到 9B 的模型检查自己的输出，反而会使推理变得更糟，因为它没有能力进行可靠的二次检查。 * **蒸馏验证器是廉价的解决方案**：Advani 的分类器达到了 0.86 的 F1 分数，运行速度比完整验证快约 100 倍，这使得过程检查可以投入生产环境，而不再是研究上的奢侈品。 因此，接触敏感数据的小模型代理需要围绕检索和验证层来构建，而不能仅仅依赖其准确率得分。包含完整基准表格的全文请见：[https://agenttape.com/articles/slm-agents-2026-empirical-case](https://agenttape.com/articles/slm-agents-2026-empirical-case) 我很好奇那些运行自己代理栈的人们在实践中是怎么做的。有人已经开始按模型大小拆分工作了吗，还是仍然用一个模型处理一切？