做医疗AI智能体的后端开发，绕不开一个现实问题：没有哪个模型能在所有医疗场景里都做到最好。
千问在中文医疗问答和结构化输出上表现稳健，DeepSeek在长链推理和复杂病例分析上有独特优势。一个症状识别请求可能适合千问的快速响应，而一份病历摘要生成则可能更适合DeepSeek的长上下文能力。如果每换一个场景就重写一遍调用代码，维护成本会迅速失控。
这篇文章从工程落地角度，拆解医疗场景下的多模型路由设计与Prompt工程化实践。附可运行的代码骨架。
为什么医疗场景需要多模型路由
通用聊天机器人用单个模型就能应付大部分场景，但医疗AI面对的是高度分化的任务类型。
症状识别需要快速、结构化输出，对延迟敏感；病历摘要生成需要长上下文理解和专业术语准确性；药物交互检查需要严格的推理链和可追溯的输出。这些任务的特性差异决定了没有单模型最优解。
更现实的问题是，医疗场景对模型可用性要求极高。单一模型服务抖动时，如果没有备用路由，整个智能体就会瘫痪。多模型路由不仅是性能优化，更是高可用架构的组成部分。
路由设计：先分场景，再选模型
路由的核心判断依据不是“哪个模型更强”，而是当前任务需要什么能力。
推荐的路由策略分两层：
第一层：场景分类。根据业务场景标识（SYMPTOM_ANALYSIS、RECORD_SUMMARY、DRUG_CHECK等）决定候选模型池。这个映射关系应该配置化，而不是硬编码。
第二层：动态选择。在候选模型池内，根据当前负载、历史延迟、置信度阈值动态选择。对于症状识别这类需要快速响应的场景，优先选择延迟更低的模型；对于病历摘要，优先选择长上下文表现更好的模型。
在学术研究中，SOLVE-Med采用Router Agent作为多标签分类器，先为每个查询分配相关的专科模型，再由Orchestrator Agent整合各专家输出。这种**“先路由、后整合”** 的架构在医疗场景下被证明有效，因为不同专科的模型对特定症状的理解深度不同。
Prompt工程化：模板外置与版本管理
医疗Prompt和通用Prompt最大的区别是安全约束必须内嵌在模板里，而不是依赖调用方拼装。
症状识别的模板中需要明确写清楚：“不做确定性诊断，仅做分诊参考”、“如果症状包含胸痛、呼吸困难等急症关键词，urgency直接标记为HIGH”。这些约束如果散落在各个Service里，合规审计时根本查不过来。
把Prompt模板外置到配置中心或数据库，让模板成为可独立管理的资产。每个模板有明确的场景标识、版本号和激活状态。修改Prompt不需要发版，但修改必须经过审核。
企业级Prompt管理的一个关键实践是Prompt与Trace的链接：每次模型调用的Trace中注入Prompt的版本标识，这样在观测平台里可以筛选出所有使用了某个版本Prompt的实际会话，用生产数据反向验证Prompt改动的效果。
多模型适配层的实现
千问和DeepSeek的API在字段格式上存在差异。千问的DashScope API中response_format嵌套在parameters对象内，而DeepSeek将其放在请求体顶层。DeepSeek的流式响应在502错误时不关闭连接，千问则要求严格的HTTP/2和TLS 1.3。
这些差异如果散落在业务代码里处理，维护成本极高。适配层应该把所有模型特有的协议差异收口，对外暴露统一的调用接口。
publicinterfaceModelAdapter{StringgetModelName();Set<String>getSupportedScenes();LlmResponseinvoke(LlmRequestrequest);}@ComponentpublicclassQwenAdapterimplementsModelAdapter{@OverridepublicSet<String>getSupportedScenes(){returnSet.of("SYMPTOM_ANALYSIS","DRUG_CHECK");}@OverridepublicLlmResponseinvoke(LlmRequestrequest){QwenRequestreq=QwenRequest.builder().model("qwen-max").input(QwenInput.builder().messages(convertMessages(request)).build()).parameters(QwenParams.builder().resultFormat("message").build()).build();returndoInvoke(req);}}@ComponentpublicclassDeepSeekAdapterimplementsModelAdapter{@OverridepublicSet<String>getSupportedScenes(){returnSet.of("RECORD_SUMMARY","COMPLEX_REASONING");}@OverridepublicLlmResponseinvoke(LlmRequestrequest){OpenAiRequestreq=OpenAiRequest.builder().model("deepseek-chat").messages(convertMessages(request)).build();returndoInvoke(req);}}路由层通过场景标识从适配器池中筛选候选模型，再根据配置的优先级顺序逐一尝试。如果一个模型调用失败，自动切换到同场景的下一个候选模型，这是医疗系统7×24小时稳定运行的基础保障。
降级链的设计原则
降级链不是简单的“主备切换”，需要按场景特性设计顺序。
症状识别场景的降级链可能是：千问-max → 千问-plus → 规则引擎兜底。规则引擎用关键词匹配处理“胸痛”、“呼吸困难”等急症关键词，确保即使所有模型都不可用，系统仍能给出基础分诊建议。
病历摘要场景的降级链可能是：DeepSeek-chat → 千问-max → 模板填充。模板填充用预定义的病历结构模板，把已知字段填入对应位置，虽然缺乏语义理解，但至少保证输出格式完整。
降级链的顺序和触发条件应该在配置中定义，不同医院、不同科室可能有不同的偏好。有些医院可能更信任本地部署的模型，降级链的第一优先级应该是院内模型而非云端API。
可观测性：路由决策必须可追溯
多模型路由引入了一个新的风险：当输出质量波动时，很难判断是模型选错了、Prompt改坏了，还是上游数据有问题。
每次路由决策都应该被记录：请求ID、场景标识、候选模型列表、最终选择的模型、选择理由（是配置指定还是动态评分）、调用耗时、Token消耗。这些日志在合规审计时是必要的证据——每一次AI参与的医疗决策过程都必须可追溯。
Prompt的版本标识也应该注入到Trace中。当某个科室反馈“最近分诊建议不太准”时，可以快速筛选出该时间段内症状识别场景使用的Prompt版本，对比版本间的差异，定位是路由问题还是Prompt问题。
写在最后
多模型路由和Prompt工程化，本质上是在**“模型能力的不确定性”和“医疗系统的高可靠性要求”之间架一座桥**。模型本身的能力我们控制不了，但选哪个模型、用哪个版本的Prompt、失败了走哪条降级路径，这些都是我们可以控制的工程手段。
如果你的团队正在做医疗AI智能体，建议从场景-模型映射的配置化开始。先把路由逻辑从代码里抽出来，让“哪个场景用哪个模型”成为可调整的配置，而不是需要发版的硬编码。这一步的改造成本不高，但收益会随着模型迭代速度的加快而持续放大。
