智能体架构困在"模型忠诚"里

生产环境的AI智能体正在做一件奇怪的事：所有任务都塞给同一个大模型。分类意图、搜索信息、总结文档、生成代码、选择工具、检查结果、撰写回复、判断是否需要人工审批、等待外部事件、重试失败任务、错误恢复——这些完全不同的工作负载，被强行塞进同一个调用入口。

这种"模型忠诚"有其现实根源。单一模型让演示更简单，评估更统一，采购更省事，调试也不至于太混乱。团队出了问题只需找一个供应商算账，而不是四处扯皮。但问题在于：生产级智能体本就不是单一工作负载。

Harrison Chase指出，大语言模型正在变贵，开源模型因此变得重要。LangChain的产品方向也印证这一点：Fleet智能体不再受限于单一模型，转而支持多模型架构。两种路径，指向同一个生产现实。

智能体架构必须回答一个问题：什么工作该用什么模型？

令人意外的是，许多现有智能体栈把模型选择当成环境配置参数，跟批大小、权衡参数并列。设好MODEL=claude-whatever或MODEL=gpt-whatever就部署。聊天机器人这么干没问题，智能体这么干就是偷懒。

智能体内部天然引入方差。用户眼中的简单请求，在系统内部被拆解为检索、规划、转换、检查、执行、生成、调度等环节。有些步骤需要深度推理，有些追求速度，有些必须便宜。有些需要擅长代码生成的模型，有些必须用开源权重模型——因为数据不能出境，或者单纯因为搬运成本太高。

全链路使用同一个前沿模型确实让人安心，但也掩盖了浪费。没有明显的失败点，只有缓慢、昂贵、官僚化的生产现状。团队盯着仪表盘：成本在涨，延迟在涨，然后抱怨模型太贵、提示词太长。架构是线性的，所有步骤涌向同一个出口。

真正的问题在于计算单体化。其他领域早就学会了正确分离计算类别：队列不是数据库，Lambda不是批处理 worker，CDN不是源站。结果某个"聪明"的智能体一来，所有认知功能都得经过账户里最大的那个模型。

模型路由通常以可靠性议题进入讨论：OpenAI挂了换Anthropic，部署过载换另一个，触发限流就换个地方重试。这很重要。LiteLLM的路由文档详细说明了负载均衡、冷却期、降级策略、超时机制——但这些都只是起点。