智能體架構困在"模型忠誠"里

生產環境的AI智能體正在做一件奇怪的事：所有任務都塞給同一個大模型。分類意圖、搜索信息、總結文檔、生成代碼、選擇工具、檢查結果、撰寫回復、判斷是否需要人工審批、等待外部事件、重試失敗任務、錯誤恢復——這些完全不同的工作負載，被強行塞進同一個調用入口。

這種"模型忠誠"有其現實根源。單一模型讓演示更簡單，評估更統一，采購更省事，調試也不至于太混亂。團隊出了問題只需找一個供應商算賬，而不是四處扯皮。但問題在于：生產級智能體本就不是單一工作負載。

Harrison Chase指出，大語言模型正在變貴，開源模型因此變得重要。LangChain的產品方向也印證這一點：Fleet智能體不再受限于單一模型，轉而支持多模型架構。兩種路徑，指向同一個生產現實。

智能體架構必須回答一個問題：什么工作該用什么模型？

令人意外的是，許多現有智能體棧把模型選擇當成環境配置參數，跟批大小、權衡參數并列。設好MODEL=claude-whatever或MODEL=gpt-whatever就部署。聊天機器人這么干沒問題，智能體這么干就是偷懶。

智能體內部天然引入方差。用戶眼中的簡單請求，在系統內部被拆解為檢索、規劃、轉換、檢查、執行、生成、調度等環節。有些步驟需要深度推理，有些追求速度，有些必須便宜。有些需要擅長代碼生成的模型，有些必須用開源權重模型——因為數據不能出境，或者單純因為搬運成本太高。

全鏈路使用同一個前沿模型確實讓人安心，但也掩蓋了浪費。沒有明顯的失敗點，只有緩慢、昂貴、官僚化的生產現狀。團隊盯著儀表盤：成本在漲，延遲在漲，然后抱怨模型太貴、提示詞太長。架構是線性的，所有步驟涌向同一個出口。

真正的問題在于計算單體化。其他領域早就學會了正確分離計算類別：隊列不是數據庫，Lambda不是批處理 worker，CDN不是源站。結果某個"聰明"的智能體一來，所有認知功能都得經過賬戶里最大的那個模型。

模型路由通常以可靠性議題進入討論：OpenAI掛了換Anthropic，部署過載換另一個，觸發限流就換個地方重試。這很重要。LiteLLM的路由文檔詳細說明了負載均衡、冷卻期、降級策略、超時機制——但這些都只是起點。