医院AI系统崩溃三次后，我重新设计了架构

单一大模型（大型语言模型）撑起的智能系统，在早上8点流量高峰时连续三天宕机。这不是压力测试，是真实发生在医院营收报表生成时刻的事故。

作者用血淋淋的教训换来一套新方案：10个专业智能体（AI Agent）分布在4家大模型服务商之间，自动故障转移。过去几个月，早晨的报表再没缺席过。

一图读懂：三层路由架构

整个系统的核心是一张架构图。不是那种画给投资人看的概念图，是实打实跑在医院的生产代码。

最顶层是路由器（Router）。它不玩正则表达式匹配关键词，而是调一次轻量级大模型，用结构化输出做意图识别。代码里明确定义了意图类型：临床、预约、分析、人事调度……

置信度低于0.4时，系统不瞎猜，直接问用户澄清。这比答错再纠正便宜得多。

路由器本身有三层保命机制：第一层走大模型结构化输出；解析失败就进第二层，从文本回复里抠关键词；万一连大模型都挂了，第三层纯本地正则，零外部依赖。

作者的原话很直白：「路由器是单点故障中的单点故障，必须过度设计。」

专业分工：该省省该花花

财务智能体配的是复杂模型，20多个工具，10轮推理迭代，支持并行调用多个接口。营收、保险、预测……这些活儿不能省。

预约智能体完全另一套配置：简单模型，两个工具（创建预约+取消预约），3轮迭代搞定。便宜、快、够用。

这种粗细搭配省了约60%的API成本，关键业务的质量没掉。

为什么医院场景特别残酷

早上8点的营收报表有硬 deadline。大模型服务商的限流策略不会因为你救急就网开一面。Twitter上那些炫酷的单模型演示，在真实业务连续性面前像个玩具。

多服务商架构的本质是把「供应商风险」当成一等公民来设计。不是锦上添花，是底线思维。

这套方案现在跑在HISDashboard系统里。作者没提具体医院名字，但从工具集看，覆盖了临床、财务、人事、预约完整链条。一个中等规模医院的管理复杂度，被10个智能体拆分得明明白白。

最讽刺的细节：第一次失败是因为OpenRouter限流。作者没换一家服务商了事，而是把「任何单点都可能挂」写进了架构假设。这种被迫的悲观主义，反而造出了真正韧性的系统。

对做B端AI产品的团队来说，这是个清醒剂。演示视频的流畅不等于生产环境的可靠，用户不会容忍「服务商那边有点问题」这种借口。医院等不了，其他行业也一样。