一个 Agent 在模型 A 上运行正常换成模型 B 后却开始“犯怪病”字段名不对该调用工具时没调用把 temperature 调到 0问题少了但偶尔仍走错路径再换 reasoning model准确率提高延迟又明显增加。这些问题看似分别属于 Schema、测试、采样参数和推理速度其实指向同一个核心不要把模型当成稳定函数而要把它当成能力、接口和随机性都会变化的外部依赖。Agent 要稳定靠的不是找到“永远不出错的模型”而是把变化隔离在系统边界内。模型变了业务代码别跟着变不同模型的 Tool Calling 格式、Schema 支持范围、并行调用方式和错误处理习惯可能不同。如果业务逻辑直接绑定某一家模型的原生格式换模型就会牵动大量代码。更稳的办法是在模型与业务工具之间加一层适配器。内部只保留一套统一协议工具名、参数、调用 ID、依赖关系、执行结果和错误类型。各模型的原生输出先转换成内部格式再通过校验后执行。假设业务只有一个“查订单”工具并且内部统一要求order_id。至于某个模型把参数放在什么字段、工具消息如何组织都由适配层处理。这样换模型时改的是边缘不是核心。还有一条不能省模型输出先验证再执行。类型、枚举、必填字段、权限和参数范围都应由程序检查而不是相信模型“应该会按 Schema 来”。Regression Test 测行为不测文风很多团队换模型时会拿几十条 Prompt 看答案“像不像以前”。对普通聊天有点用对 Agent 不够。Agent 真正要回归的是行为链路该不该调用工具调用哪个参数是否正确多个工具的顺序是否合理工具失败后会重试、改参数还是停止最终回答有没有忠实使用工具结果比如用户说“把我明天下午的会议推迟一小时。”重点不是最终回复写得多自然而是 Agent 有没有找到正确会议、计算新时间并避免改错其他事件。建议维护固定的 golden set同时加入历史真实失败案例。更换模型后关键样例不要只跑一次而要重复运行。因为 Agent 常见的问题不是“必错”而是“偶尔错”。Temperature 不是可靠性的总开关Tool Calling 不稳定时很多人的第一反应是把 temperature 调到 0。它可以减少随机性但不能保证理解正确也不能修复模糊的工具定义、重叠的职责和缺失的参数约束。如果一个工具叫search另一个叫lookup描述几乎一样再低的 temperature 也可能选错。对执行型 Agent更现实的做法是能低随机就低随机但可靠性建立在 Schema 校验、工具选择约束、幂等设计、权限检查和重试策略上。头脑风暴类任务可以容忍更高随机性发邮件、付款、删数据、改日程等操作则应降低随机性并给关键动作增加确认。风险取决于动作是否可逆不只是 temperature。别追求“模型绝对确定”要追求“系统确定”如果 deterministic decoding 指同样输入必须得到完全相同的输出不应把 Agent 的稳定性押在这件事上。更值得追求的是确定性的系统边界参数必须通过固定校验相同调用 ID 不能重复扣款危险操作必须满足权限规则超出范围直接拒绝失败后走预定义恢复路径。可以把模型想成一个聪明但偶尔犹豫的同事而业务系统像财务制度。你不需要要求同事每次措辞完全一样但金额、权限和收款对象必须被规则锁死。Reasoning Model 太慢先减少“必须深想”的任务Reasoning Model 的常见误用是所有请求默认走最强推理。结果是简单任务也付出高延迟。更好的架构是路由简单意图识别、格式转换、单工具查询交给更快模型复杂规划、多约束决策、异常恢复再升级到 reasoning model。还可以限制最大工具轮次、推理预算和超时并设计降级路径。工具彼此独立时可以并行稳定且重复的信息可以缓存长链路任务可以拆成“规划”和“执行”避免每一步都重新深度推理。最终也别只看准确率。任务成功率、P95 延迟、平均工具调用次数、重试率和成本应该一起看。一个更准但慢很多、还频繁多调用几轮工具的模型未必更适合生产环境。把模型当成可替换部件Agent 工程成熟的标志不是某个模型表现特别好而是模型换掉后系统依然可测、可控、可恢复。如果你正在升级模型可以先做四件事统一内部 Tool Schema建立包含失败案例的回归集把高风险动作放进确定性的程序约束按任务复杂度做模型路由。做到这些以后Temperature、模型版本甚至供应商都会从“架构风险”变成“可调参数”。模型可以继续快速变化而你的 Agent 不必跟着失控。
