做医疗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();SetStringgetSupportedScenes();LlmResponseinvoke(LlmRequestrequest);}ComponentpublicclassQwenAdapterimplementsModelAdapter{OverridepublicSetStringgetSupportedScenes(){returnSet.of(SYMPTOM_ANALYSIS,DRUG_CHECK);}OverridepublicLlmResponseinvoke(LlmRequestrequest){QwenRequestreqQwenRequest.builder().model(qwen-max).input(QwenInput.builder().messages(convertMessages(request)).build()).parameters(QwenParams.builder().resultFormat(message).build()).build();returndoInvoke(req);}}ComponentpublicclassDeepSeekAdapterimplementsModelAdapter{OverridepublicSetStringgetSupportedScenes(){returnSet.of(RECORD_SUMMARY,COMPLEX_REASONING);}OverridepublicLlmResponseinvoke(LlmRequestrequest){OpenAiRequestreqOpenAiRequest.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智能体建议从场景-模型映射的配置化开始。先把路由逻辑从代码里抽出来让“哪个场景用哪个模型”成为可调整的配置而不是需要发版的硬编码。这一步的改造成本不高但收益会随着模型迭代速度的加快而持续放大。
