很多人在给 Agent 选模型时，习惯先看跑分、看参数、看谁的榜单排第一。但对真正要把 Agent 放进生产环境的人来说，问题不是"哪个模型最聪明"，而是"哪个模型你敢用"。
敢不敢用，主要看三件事：
一、工具调用正确率
Agent 和普通问答最大的区别，是它要靠调用工具来完成实际任务：查数据库、调接口、操作文件。工具调用一步调错，后面的步骤全部跟着错。所以选模型时，与其比谁写文章写得好，不如比谁把"调工具"这件事做得稳。
二、拒答能力
模型不知道的事，是老实说"不知道"，还是一本正经地编？在 Agent 场景里，编造的后果会被放大：错误的参数、错误的数据、错误的下游动作。一个敢说"不知道"的模型，比一个什么都敢答的模型更安全。
三、长任务稳定性
一个 Agent 任务往往要连续调用模型 5~20 次，中间任何一次抽风，整个任务就断了。长任务稳定性，指的是在长时间、多步骤的调用里，模型始终保持在可用状态，而不是前两步很好、第五步开始乱来。
别迷信榜单，建自己的 eval 集
公开榜单用的是别人选的任务，不代表你的场景。更靠谱的做法是建自己的评估集：挑 20~50 个你业务里真实会发生的任务，先用当前最稳的模型跑一遍，作为基线；再拿候选模型在同样的任务上对比，谁在你的场景里更稳，就用谁。这一步花半天时间，能避免上线后返工几周。
分阶段选型，不必一步到位
- 原型阶段：目标是快速跑通，选接入最简单、文档最全的模型；
- 生产阶段：目标是稳定，重点看工具调用正确率和长任务表现；
- 放量阶段：目标是成本与性能的平衡，可以引入模型路由，把简单任务分给便宜的小模型，复杂任务留给强模型。
模型之外，别忘了 API 通道本身
模型选得再好，接入的通道不稳也白搭。要关注：限流策略（429 怎么处理、要不要重试）、故障响应（服务挂了有没有人响应、恢复要多快）、售后支持，以及最重要的——计费是否透明，账单能不能看懂。
一句话总结：给 Agent 选模型，先别问哪个聪明，先问哪个你敢用。
