醫院AI系統崩潰三次后，我重新設計了架構

單一大模型（大型語言模型）撐起的智能系統，在早上8點流量高峰時連續三天宕機。這不是壓力測試，是真實發生在醫院營收報表生成時刻的事故。

作者用血淋淋的教訓換來一套新方案：10個專業智能體（AI Agent）分布在4家大模型服務商之間，自動故障轉移。過去幾個月，早晨的報表再沒缺席過。

一圖讀懂：三層路由架構

整個系統的核心是一張架構圖。不是那種畫給投資人看的概念圖，是實打實跑在醫院的生產代碼。

最頂層是路由器（Router）。它不玩正則表達式匹配關鍵詞，而是調一次輕量級大模型，用結構化輸出做意圖識別。代碼里明確定義了意圖類型：臨床、預約、分析、人事調度……

置信度低于0.4時，系統不瞎猜，直接問用戶澄清。這比答錯再糾正便宜得多。

路由器本身有三層保命機制：第一層走大模型結構化輸出；解析失敗就進第二層，從文本回復里摳關鍵詞；萬一連大模型都掛了，第三層純本地正則，零外部依賴。

作者的原話很直白：「路由器是單點故障中的單點故障，必須過度設計。」

專業分工：該省省該花花

財務智能體配的是復雜模型，20多個工具，10輪推理迭代，支持并行調用多個接口。營收、保險、預測……這些活兒不能省。

預約智能體完全另一套配置：簡單模型，兩個工具（創建預約+取消預約），3輪迭代搞定。便宜、快、夠用。

這種粗細搭配省了約60%的API成本，關鍵業務的質量沒掉。

為什么醫院場景特別殘酷

早上8點的營收報表有硬 deadline。大模型服務商的限流策略不會因為你救急就網開一面。Twitter上那些炫酷的單模型演示，在真實業務連續性面前像個玩具。

多服務商架構的本質是把「供應商風險」當成一等公民來設計。不是錦上添花，是底線思維。

這套方案現在跑在HISDashboard系統里。作者沒提具體醫院名字，但從工具集看，覆蓋了臨床、財務、人事、預約完整鏈條。一個中等規模醫院的管理復雜度，被10個智能體拆分得明明白白。

最諷刺的細節：第一次失敗是因為OpenRouter限流。作者沒換一家服務商了事，而是把「任何單點都可能掛」寫進了架構假設。這種被迫的悲觀主義，反而造出了真正韌性的系統。

對做B端AI產品的團隊來說，這是個清醒劑。演示視頻的流暢不等于生產環境的可靠，用戶不會容忍「服務商那邊有點問題」這種借口。醫院等不了，其他行業也一樣。