医疗场景的 AI 落地和互联网行业完全是两回事。两年前我带队做通用知识库问答系统时以为把大模型接进去、把知识挂上去就能交付结果在合作医院的试用现场被问得哑口无言——医生要的不是能聊而是能辅助做决策。后来我们花了大半年时间把方案推倒重来做了一套专门面向临床诊断辅助场景的 Agent 系统。这个项目谈不上多前沿但架构思路和踩坑过程比较有代表性想着整理出来给准备做垂直行业 Agent 落地的团队一些参考。先说清楚这套系统是什么它不替代医生做诊断而是在医生输入主诉、病史等关键信息后由 Agent 完成病历信息结构化提取、疑似方向检索、检查建议生成、鉴别诊断要点提示等辅助工作。整个过程有明确的边界控制输出必须带证据来源和置信度标识所有交互留痕可审计。这套东西适合谁参考如果你正在做医疗信息化、临床决策支持系统或者准备把 Agent 架构引入其他强合规、强专业的垂直领域比如法律、金融风控这篇拆解会很有价值。我会把整体设计思路、核心模块实现、评测方法、工程落地中的坑一条一条讲清楚。1. 为什么医疗场景必须做垂直落地1.1 通用大模型在医疗场景的失灵现象先泼一盆冷水拿通用大模型直接做医疗问答效果非常不靠谱。我们早期做过一轮实测用同一个模型问胸痛伴大汗可能是什么问题它给出的答案确实覆盖了急性心肌梗死、肺栓塞、主动脉夹层等方向但问题是它把每个方向的紧急程度写得几乎一样也没有提示主动脉夹层一旦误判后果极严重这类临床决策的关键约束。这个问题不是模型不够聪明而是通用模型的训练目标决定了它的输出均衡化倾向。在互联网问答场景里给出全面的、涵盖各种可能性的答案是正确的但在临床辅助场景里信息的决策权重比信息覆盖度重要得多。医生需要知道的是这个主诉下最需要排除的致命性疾病是什么什么检查能快速帮助鉴别哪些信息缺失可能导致误判。通用模型的另一个问题是知识时效性。医学知识更新很快诊疗指南每年都有修订通用模型的知识截断日期决定了它无法感知最新指南。如果让系统直接引用过时的用药建议在临床应用中是绝对不可接受的。1.2 医疗场景真实需求的四个维度垂直落地不是简单地把模型换掉而是整个系统的交互逻辑、知识组织方式、评价标准都要跟着业务需求走。我在和临床医生反复沟通后把真实需求拆成了四个维度第一结构化程度。临床工作高度依赖结构化信息。患者说我胸口疼了两天医生需要的是胸痛、持续时长48小时、疼痛性质待明确这样的结构化字段而不是一段自然语言描述。Agent 必须先做信息抽取和结构化否则下游所有逻辑都无法处理。第二决策边界。医生不需要 Agent 告诉他这是什么病而是需要 Agent 提供这个方向的可能性较大需要优先排除的疾病有哪几个建议补充哪些检查。辅助和决策之间必须有一条清晰的线系统永远站在辅助位置。第三可追溯性。任何一条建议都必须能回溯到具体的知识来源——是哪版指南、哪个共识、哪条文献。没有来源的输出临床医生不会信任出了问题也无法追责。第四容错偏好。医疗场景的容错是宁可有假阳性提示不能漏掉致命性误判。也就是说对于急性心梗、主动脉夹层这类高致死率疾病系统的召回率优先级最高哪怕多给几条干扰提示也不能让真正危险的信号被过滤掉。这个偏好会直接影响后面注意力机制的设计和阈值设置。通用 Agent 架构在互联网场景的假设——海量用户、低交互成本、可接受误差——在医疗场景完全不成立。只有把上面四个维度的需求前置到架构设计里做出来的系统才能真正进得了科室。2. 系统总体架构与核心协作流程2.1 四层架构设计与模块划分整个系统我们用了四层架构接入层、编排层、能力层、数据层。每一层的职责都刻意收敛避免模块间职责交叉导致后续维护失控。接入层负责统一接诊标准。无论是医生的自然语言输入、护士站的结构化录入还是后续接入 HIS医院信息系统都先转换成统一的中间表示CMIClinical Message Intermediate。接入层做了消息归一化、敏感信息脱敏和基本校验确保进入系统的数据是干净、合规的。编排层是整个 Agent 的中枢。它接收归一化后的请求由决策编排模块判断当前会话需要哪些能力组合——是单纯做信息抽取还是需要走检索增强生成或者是触发多路径鉴别推理。编排层还管理着会话状态和上下文记忆并负责调用能力层的各个子模块。能力层是核心业务逻辑所在包括六个子模块医学实体识别与归一化、意图识别、检索增强模块、诊断方向推理引擎、检查建议生成器、可解释性输出格式化模块。这些模块之间相互独立通过编排层调度后续任何一个模块单独升级都不会影响整体流程。数据层独立于能力层存放医学指南库、药品知识库、院内历史脱敏病历库和会话档案库。数据层只提供标准化的查询接口不参与业务逻辑这样做的目的很明确——医学知识的更新频率高、来源权威性要求高把数据层独立出来可以让知识库的维护变成一个纯数据任务不涉及代码变更。2.2 主流程协作与关键节点控制一个典型的辅助诊断请求完整的协作流程是这样跑的第一步患者主诉文本进入接入层脱敏和归一化后生成 CMI 结构。这一步会做分词、错别字纠偏医疗场景里患者口语化描述非常多以及关键字段对齐比如主诉、现病史、既往史、生命体征。第二步编排层拿到 CMI 后先调用医学实体识别模块把症状、体征、时间、部位、程度等要素抽出来形成结构化病历草稿。同时意图识别模块并行运行判断用户这次是要初步分析可能方向还是鉴别两个已知方向或者是评估检查方案的合理性。第三步根据意图结果编排层决定走哪条推理路径。如果是初步分析触发检索增强模块从知识库召回相关指南片段构建提示上下文然后调用诊断方向推理引擎在限定范围内生成可能的疾病方向每个方向标注置信度和必需的鉴别依据。第四步检查建议生成器基于当前信息完整度输出还需要补充哪些检查、为什么补这些检查、检查的核心鉴别价值是什么。所有输出最后统一到可解释性格式化模块附带证据来源编号和置信度等级推送给医生端。整个流程中有一个关键控制点任何一步的信息不完整系统不会硬推。比如患者只说胸痛但没说持续时间和性质系统会先输出信息缺口提示——建议补充血压、心率、疼痛放射情况等信息而不是直接给出疾病列表。这个控制点来自临床医生的反馈强行推结果在真实场景里不仅没用还会打断医生的思路。2.3 数据流与记忆管理的特殊设计医疗会话和普通客服对话最大的不同在于会话的上下文不只是聊了什么还包括检查结果、生命体征变化这类实时更新的结构化状态。我们把记忆分成了三层管理。第一层是会话级记忆保存当前这次交互的完整对话记录包含用户补充的症状细节和系统中间推理状态会话结束后归档。第二层是病例级记忆跨会话保存同一个患者在本次住院/就诊周期内的关键信息比如之前已经做过哪些检查、结果如何避免重复建议检查或者忽略已有信息。第三层是缓存级记忆保存常用检索结果和常见主诉的推理模板用于加速响应。三层记忆之间通过一个统一的会话标识Session ID关联并且有严格的过期策略。会话级记忆默认保留24小时病例级记忆跟随住院周期出院后归档不销毁便于复诊调用缓存级记忆按 LRU 策略滚动淘汰。数据流的每个节点都记录访问日志和变更记录这个设计是为了后面的合规审计需求当时我们就想清楚了医疗系统的每一个数据流动都不能有黑盒。3. 核心模块设计与实现要点3.1 医学实体识别从自然语言到结构化病历医学实体识别是整个系统的地基这一步做不好后面的推理全是空中楼阁。我们不建议直接用大模型做端到端的实体抽取因为在医学命名上同一实体的别名实在太多——胸闷和胸口发闷、心悸和心慌在临床术语体系里可能是同一个概念但在字符串层面完全不一样。我们采用的是领域模型冷启动 大模型在线抽取的双通道方案。离线阶段用一个规模较小的医学预训练模型底层用的是经过医学语料微调的编码器模型在历史病历上做命名实体识别输出标准的医学实体标签以此构建一个高质量的医学实体锚点库。在线阶段大模型负责理解上下文把文本中的候选实体映射到锚点库的标准术语上。实体归一化这一步非常关键。举例来说患者说我胃不舒服有一个多礼拜了归一化后得到部位上腹部排除胃这个不精确说法、时长8天一个多礼拜取近似值、体征不适归类到General Discomfort。归一化规则里我们建了一个同义词映射表同时配合语义相似度计算兜底确保新出现的口语化表达也能被识别。这一模块的工程提示是医学实体抽取必须保留原始文本的偏移量索引。也就是说知道上腹部是从原句第几个字到第几个字映射来的。这个信息在后续生成信息回显——告诉医生我理解到的信息是 XX来自您刚才说的 XX——时是必须的也是赢得医生信任的关键细节。3.2 诊断方向推理引擎辅助决策的核心逻辑这个是系统里争议最大、也最需要克制的一部分。我们做的诊断方向推理引擎有三条设计原则每一条都是从临床反馈里逼出来的。第一条多路径并行推理不做单路径最优解。一个主诉往往对应多个可能方向它们之间存在鉴别关系。引擎会把候选方向组织成一张怀疑方向图节点是可能疾病边是支持排除需进一步检查确认的关系。这一步我们用了基于概率图模型的框架节点的先验概率来自人群流行病学数据和就诊科室分布条件概率来自指南中的统计数据和专家经验规则。比如胸痛主诉下急性心梗的先验概率会显著高于胃食管反流同时主动脉夹层虽然概率低但权重极高会在图上被单独标记为高致命风险节点。第二条信息缺失感知。引擎不只在当前信息上推理它还会反向检查当前怀疑的疾病有哪些诊断标准是必须确认但当前信息缺失的这些缺失项会作为建议补充信息输出。比如怀疑肺栓塞那么 D-二聚体结果、是否有深静脉血栓风险因素、有无咯血症状这些信息如果还没有就会进入检查建议清单。第三条反事实校验。这是我自己加进来的一个机制。引擎生成候选方向后会做一个反向检查——假设患者是另一个方向的疾病当前已有的信息是否矛盾比如患者胸痛且心电图提示 ST 段抬高那么胃食管反流的证据强度就会被显著压制。这个反事实校验过程让引擎的输出更接近医生的实际思维模式不是只看支持证据也要看有没有关键反对证据。需要说明的是这个引擎的输出从来不是最终诊断而是一种排序后的、带置信度标签的鉴别方向集合。置信度不是一个单点的概率值而是一个区间加一个离散等级高/中/低/极低极低置信度的方向不会出现在最终界面上但会保留在审计日志里。这样做的原因是临床决策辅助领域的共识是宁可让系统低置信度方向不出现在医生视野里也不要用一个精确但虚假的数值制造权威感。3.3 医学知识库构建与检索增强医学知识库的质量直接决定系统输出的证据感。我们建了三个子库指南库、药品库、院内知识库。指南库收录的是公开权威诊疗指南和专家共识按照疾病分类做了层级目录每条指南拆分成推荐意见条级别每条意见都保留原文引用、发布机构和版本年份。指南拆解这一步不能靠大模型自动做我们投入了医学专业人员逐条审核大模型只负责初筛和格式预标注因为指南里的措辞稍有偏差语义就可能反转比如推荐和可考虑在临床里的证据等级完全不同。药品库聚焦的是用药安全信息包括适应症、禁忌症、常规剂量、肝肾功调整剂量、药物相互作用。这个库的关键在于结构化程度要高因为检查建议生成器和用药提示模块需要按结构化字段查询。我们为每个药品建了属性表比如禁用于字段不但包括疾病名还包括生理状态妊娠、哺乳、实验室异常肌酐清除率低于阈值等字段粒度越细后续规则匹配的准确性越高。检索增强模块用的是混合检索关键词稀疏检索基于 BM25配合向量稠密检索基于医学语料微调的嵌入模型然后经过一个重排序模块用一个小型排序模型把最相关的内容排到前面。重排序模块是我们踩了不少坑才加上的不加它的时代经常出现检索到内容相关但无法回答当前具体问题的干扰片段加了之后提示上下文的质量提升非常明显实测答案的引用满意度涨了一大截。知识库更新有一个固定的流程医学人员定版、算法团队同步、灰度发布。灰度发布时只对限定量比例的会话启用新知识版本同时跑离线对比集确认新版本没有引入明显回归才全量放开。这个流程保证了知识更新的节奏是可控的不会出现今天改一个指南、明天系统行为就大变的情况。3.4 可解释输出与合规审计机制医疗场景的 Agent 输出必须有证据链意识。我们界面上输出的每一条建议下面都带一个来源区域列出依据的指南名称、具体条款、置信度、以及当前病历中与该建议相关的信息字段。医生把鼠标悬停在来源处还能展开查看原文摘录。这个设计短期内增加了前端工作量但带来的是医生对系统的信任度指数级上升。合规审计这块我们从一开始就下了狠功夫。每一个交互周期都会生成一个不可篡改的审计记录包包含用户输入的原始脱敏文本、系统生成的 CMI 结构、所有中间模块的输出快照、每条建议的知识来源编号、时间戳、使用的模型版本号。这套记录存储在独立的审计库中定期做完整性校验。虽然系统出错了怎么追责是个复杂话题但至少从工程侧我们把每一笔操作的前因后果都留了案底这对于过信息安全审查是必须的。另外一个容易被忽略的点是模型的版本锁定。在医疗系统里同一个问题在模型升级前后的答案不应该有显著差异因为临床路径依赖稳定的行为。我们上线时做了行为一致性测试为压测集里的每一条输入生成基准输出指纹模型升级时先跑指纹对比差异率超过阈值则阻止上线。这个机制保证医疗 Agent 的升级是进化而不是漂移在辅助诊断这种高风险场景里极为重要。4. 评测体系与效果验证4.1 评测集构建真实与安全之间的平衡评测医疗 Agent 最大的困难是数据。真实病历涉及患者隐私直接拿去评测在合规上过不去。我们走了两条路一条路是公开数据集改造。用公开的医学考试题集和病例库做初筛但它们和真实临床场景的分布差异很大——考题里的信息是齐备的真实场景的信息是碎片化的、不完整的。所以我们做了一个转换流程把完整病例用信息遮蔽的方式随机挖掉部分字段模拟真实场景下的信息残缺情况再人工校对生成的评测样本是否合理。这个过程做了三轮筛选留下的样本覆盖了内、外、急诊的主要病种。另一条路是模拟患者路径。我们请有多年临床工作经验的医生设计了大量标准化病人对话脚本以医患对话的形式模拟患者主诉再让医生撰写理想情况下的辅助建议期望输出。标准化病人脚本特别适合用来测多轮会话——真实场景里患者很可能一开始只说一个表象追问下才暴露真正的关键信号比如胸痛追问出活动后加重、休息缓解这一串追问链路的评测靠静态病例是测不出来的。4.2 核心评测指标设计评测指标不能只看准确率。辅助诊断系统真正要看的指标我梳理成五个维度。第一维度是召回敏感度针对高致命风险疾病。比如主动脉夹层、急性心肌梗死、脑出血这类病系统有没有出现在候选方向里这个权重最高。它不是单一数字而是按疾病类别分头统计。第二维度是信息结构化准确率。实体抽取的精度和召回、属性对齐的正确率、时间单位的归一化正确率——这些越高下游推理越可靠。第三维度是建议合理性。每一条检查建议是否与该怀疑方向一致、是否有明确的鉴别价值。这个指标我们用了一个替代方案让临床医生对建议打分3分制必须做/可以做/不建议最后汇总成平均分。第四维度是过多无用信息率。医疗场景最怕系统把不重要的方向一股脑推给医生我们统计了每个病例输出的候选方向数量以及前3个方向中包含真实正确诊断的比例。期望是前3个方向就能覆盖绝大多数正确诊断如果正确诊断排到了第6、第7位就说明推理权重分配有问题。第五维度是信息缺口识别的覆盖率。系统对每一条信息缺失项的提示是否准确是否漏掉了某种高危疾病的必需鉴别信息也是重点检查项。五个维度分开评测、分开汇报而不是合成一个综合分这样在模型迭代时能清晰看到改哪里、影响了哪项指标。4.3 医生在环的人工复核闭环光靠离线评测集还不够。我们建立了一个医生在环的常态化复核机制每月请合作医院的临床医生抽检系统在真实脱敏数据上的输出按固定模板打分同时标注他们发现问题时的错因类型——是知识库缺失、推理权重不对、还是信息抽取错了。这个环节的价值在于它能把离线评测和真实体验之间的差距暴露出来。有一次医生反馈系统在上腹痛的检查建议里频繁加入腹部 CT但实际上对门诊患者来说超声是最常用也最合理的初步筛查手段。我们查了推理引擎的权重配置发现引擎给腹部 CT 设置的诊断信息增益权重偏高而对检查成本、辐射剂量这些因素完全没有建模。这个反馈直接推动了引擎加入初步检查 vs 进阶检查的层级判断逻辑。人工复核的反馈不止用在模型迭代上也沉淀成规则库。很多临床经验类的约束比如育龄期女性腹痛必须排除宫外孕这类原则大模型难以从统计语料里稳定学出来我们就通过复核反馈整理成显式的专家规则在推理引擎里以强约束的形式存在。5. 工程落地中的常见坑与排查实录5.1 私有化部署与算力博弈医院环境里做 Agent 系统绕不开私有化部署。很多医院不允许核心医疗数据出内网意味着模型推理必须在院内基础设施上跑。我们踩过的第一个坑是算力规划严重不足。最开始我们按并发10个会话、单次响应8秒内的目标规划 GPU 资源结果上线后发现术前谈话、门诊高峰期的并发远超预想高峰时期的响应时间直接飙到20秒以上整个体验完全不可用。后来做了三个改动才缓解第一把响应时间要求改成分级——纯结构化抽取任务走快速通道目标2秒内需要多路径推理的复杂任务走慢速通道目标10秒内第二引入请求队列和优先级调度急诊优先第三对高频主诉做推理结果缓存同一个主诉相似信息组合直接在缓存层命中不重复跑推理链路。另一个经验是模型蒸馏。我们把线上推理模型从全量大模型逐步蒸馏成不同规模的版本按任务复杂度自动选择模型。简单任务用轻量模型能力和成本平衡复杂任务才动用大模型。这个分层推理策略在私有化环境里是把性能和成本压下来的关键手段。有条件的团队建议在项目规划阶段就预留模型服务层避免后期把推理逻辑硬编码在业务代码里那样改模型就变成一场灾难。5.2 多轮会话中的记忆漂移问题Agent 的上下文管理在医疗场景有特殊的坑。系统在多轮会话后经常会生成自我矛盾的病历摘要比如患者第一轮说胸痛3天第二轮说活动后加重系统在做信息合并时可能因为提示上下文过长把3天和活动后加重错误归入不同的疑似疾病方向导致推理结果前后不一致。我们把这类问题统称为记忆漂移。排查之后发现根因有两个一个是上下文窗口截断策略太粗暴。当对话超过模型上下文长度时我们简单地把最早的历史对话丢掉了但最早的信息往往包含最核心的主诉这样一丢记忆就出现了断裂。后来的方案是分层摘要不会直接丢弃早期内容而是先把早期信息压缩成结构化摘要症状、时长、已做检查、尝试处理完整原文存到会话记忆中只有摘要进入上下文窗口。这样既控制了上下文长度又保留了信息的结构化完整性。另一个是信息冲突检测缺失。患者第二轮说喝了硝酸甘油有没有缓解如果第一轮已经记录胸痛系统应该识别出这是在问药物反应而不是把它当作一个新的孤立症状。我们加了冲突检测和关联模块新输入先和既有 CMI 结构做对齐自动识别这是对既有症状的补充还是新症状。这个模块上线后记忆漂移导致的推理前后矛盾问题少了大概半数。5.3 误报与漏报的权衡策略医疗 Agent 在真实使用中最让医生反感的不是漏报医生本来就会自己做判断而是这个系统怎么什么都往外说——被大量无关提示干扰信任感降低得很快。我开始时为了追求高召回把所有低置信度方向都列出来结果医生说这个系统像百度前十条——什么都有、什么都没用。后来我们调整了过滤策略对每个候选方向做三层过滤第一层按置信度等级卡阈值极低方向一律不进界面第二层按致命风险复核即使置信度低但如果是高致死风险疾病必须保留并单独标红提示第三层按与当前病历的信息支撑度过滤有明确支持证据的方向才显示缺乏证据的缩入其他可能方向折叠区。这样既保住了致命性疾病的敏感性又大幅减少了无价值输出的数量。这个权衡策略的逻辑是一句话在医疗场景召回率的优先级体现在高危疾病上而不是所有疾病上。对于低危疾病精确率优先级高于召回率。想清楚这一点阈值设计的思路就通透了。5.4 常见问题速查表我把项目过程中遇到过的高频问题整理成一个速查表给正在做或者准备做类似系统的团队一个参考问题类别典型表现根因分析推荐排查路径实体抽取口语化症状无法归一化同义词锚点库覆盖不足先查归一化日志看是未识别还是映射冲突再扩充锚点库检索质量提示上下文包含无关指南内容重排序模块缺失或权重不当按检索日志查 Top-5 命中相关性针对性调整重排序模型数据推理权重正确方向排名过靠后先验概率或条件概率字段不合理用评测集分病种统计头部命中率定位到具体病种权重上下文管理多轮后病历摘要出现矛盾截断策略丢失早期关键信息检查会话摘要模块是否生效确认结构化摘要完整度响应延迟复杂任务响应超时模型规模过大或推理链路过长分析任务级耗时评估缓存命中率考虑模型蒸馏合规审计审计日志不完整中间节点未接入审计采集按数据流全链路检查埋点覆盖率补全快照序5.5 冷启动阶段的一个特别提醒最后单独说一件容易被忽视的事冷启动阶段不要追求功能完整先跑通一个最小闭环。我跟很多团队聊过大家最容易犯的毛病就是第一版就把所有模块都堆上去意图识别、多路径推理、复杂知识检索、生成式推荐全部上线然后发现每个模块都不稳出了问题根本定位不到是哪个环节。我们的经验是第一个可交付版本只需要三个能力一是结构化信息抽取二是基于检索增强的方向推荐三是简单的检查建议模板。这三条链路跑通、拿到临床医生的真实反馈之后再逐步叠加推理引擎、冲突检测、复杂记忆管理这些深度模块。医疗领域客户对稳定性的要求远高于对功能数量的要求。一个只有三项能力但每次结果都靠谱且可解释的系统远胜于一个功能很全但经常说些不痛不痒的话的系统。这个理念贯穿了我们整个开发周期的资源分配。另外提醒一点医疗 Agent 的模型行为一致性测试要尽早做。越往后模型版本迭代越频繁如果没有一个自动化的输出指纹对比机制上线回归只能靠人工翻案例根本翻不过来。把行为一致性测试纳入 CI和代码测试一起跑是控制长期维护成本最划算的一笔投入。套用我们项目总监说过的一句话医疗场景不是给 Agent 找了很多活干而是把 Agent 能干的活精确地圈出来然后把圈外的活全部挡掉。这套架构拆解下来核心不在模型多强而在边界画得多清楚、证据链多完整、反馈闭环多及时。垂直行业落地的本质大致就是这样——把通才磨成专才再给专才配上严明的纪律。 
长河君 · 2026/10/19 4:21:52 · 阅读 1.2k 医疗AI Agent垂直落地：临床辅助诊断系统架构与实战拆解
医疗场景的 AI 落地和互联网行业完全是两回事。两年前我带队做通用知识库问答系统时以为把大模型接进去、把知识挂上去就能交付结果在合作医院的试用现场被问得哑口无言——医生要的不是能聊而是能辅助做决策。后来我们花了大半年时间把方案推倒重来做了一套专门面向临床诊断辅助场景的 Agent 系统。这个项目谈不上多前沿但架构思路和踩坑过程比较有代表性想着整理出来给准备做垂直行业 Agent 落地的团队一些参考。先说清楚这套系统是什么它不替代医生做诊断而是在医生输入主诉、病史等关键信息后由 Agent 完成病历信息结构化提取、疑似方向检索、检查建议生成、鉴别诊断要点提示等辅助工作。整个过程有明确的边界控制输出必须带证据来源和置信度标识所有交互留痕可审计。这套东西适合谁参考如果你正在做医疗信息化、临床决策支持系统或者准备把 Agent 架构引入其他强合规、强专业的垂直领域比如法律、金融风控这篇拆解会很有价值。我会把整体设计思路、核心模块实现、评测方法、工程落地中的坑一条一条讲清楚。1. 为什么医疗场景必须做垂直落地1.1 通用大模型在医疗场景的失灵现象先泼一盆冷水拿通用大模型直接做医疗问答效果非常不靠谱。我们早期做过一轮实测用同一个模型问胸痛伴大汗可能是什么问题它给出的答案确实覆盖了急性心肌梗死、肺栓塞、主动脉夹层等方向但问题是它把每个方向的紧急程度写得几乎一样也没有提示主动脉夹层一旦误判后果极严重这类临床决策的关键约束。这个问题不是模型不够聪明而是通用模型的训练目标决定了它的输出均衡化倾向。在互联网问答场景里给出全面的、涵盖各种可能性的答案是正确的但在临床辅助场景里信息的决策权重比信息覆盖度重要得多。医生需要知道的是这个主诉下最需要排除的致命性疾病是什么什么检查能快速帮助鉴别哪些信息缺失可能导致误判。通用模型的另一个问题是知识时效性。医学知识更新很快诊疗指南每年都有修订通用模型的知识截断日期决定了它无法感知最新指南。如果让系统直接引用过时的用药建议在临床应用中是绝对不可接受的。1.2 医疗场景真实需求的四个维度垂直落地不是简单地把模型换掉而是整个系统的交互逻辑、知识组织方式、评价标准都要跟着业务需求走。我在和临床医生反复沟通后把真实需求拆成了四个维度第一结构化程度。临床工作高度依赖结构化信息。患者说我胸口疼了两天医生需要的是胸痛、持续时长48小时、疼痛性质待明确这样的结构化字段而不是一段自然语言描述。Agent 必须先做信息抽取和结构化否则下游所有逻辑都无法处理。第二决策边界。医生不需要 Agent 告诉他这是什么病而是需要 Agent 提供这个方向的可能性较大需要优先排除的疾病有哪几个建议补充哪些检查。辅助和决策之间必须有一条清晰的线系统永远站在辅助位置。第三可追溯性。任何一条建议都必须能回溯到具体的知识来源——是哪版指南、哪个共识、哪条文献。没有来源的输出临床医生不会信任出了问题也无法追责。第四容错偏好。医疗场景的容错是宁可有假阳性提示不能漏掉致命性误判。也就是说对于急性心梗、主动脉夹层这类高致死率疾病系统的召回率优先级最高哪怕多给几条干扰提示也不能让真正危险的信号被过滤掉。这个偏好会直接影响后面注意力机制的设计和阈值设置。通用 Agent 架构在互联网场景的假设——海量用户、低交互成本、可接受误差——在医疗场景完全不成立。只有把上面四个维度的需求前置到架构设计里做出来的系统才能真正进得了科室。2. 系统总体架构与核心协作流程2.1 四层架构设计与模块划分整个系统我们用了四层架构接入层、编排层、能力层、数据层。每一层的职责都刻意收敛避免模块间职责交叉导致后续维护失控。接入层负责统一接诊标准。无论是医生的自然语言输入、护士站的结构化录入还是后续接入 HIS医院信息系统都先转换成统一的中间表示CMIClinical Message Intermediate。接入层做了消息归一化、敏感信息脱敏和基本校验确保进入系统的数据是干净、合规的。编排层是整个 Agent 的中枢。它接收归一化后的请求由决策编排模块判断当前会话需要哪些能力组合——是单纯做信息抽取还是需要走检索增强生成或者是触发多路径鉴别推理。编排层还管理着会话状态和上下文记忆并负责调用能力层的各个子模块。能力层是核心业务逻辑所在包括六个子模块医学实体识别与归一化、意图识别、检索增强模块、诊断方向推理引擎、检查建议生成器、可解释性输出格式化模块。这些模块之间相互独立通过编排层调度后续任何一个模块单独升级都不会影响整体流程。数据层独立于能力层存放医学指南库、药品知识库、院内历史脱敏病历库和会话档案库。数据层只提供标准化的查询接口不参与业务逻辑这样做的目的很明确——医学知识的更新频率高、来源权威性要求高把数据层独立出来可以让知识库的维护变成一个纯数据任务不涉及代码变更。2.2 主流程协作与关键节点控制一个典型的辅助诊断请求完整的协作流程是这样跑的第一步患者主诉文本进入接入层脱敏和归一化后生成 CMI 结构。这一步会做分词、错别字纠偏医疗场景里患者口语化描述非常多以及关键字段对齐比如主诉、现病史、既往史、生命体征。第二步编排层拿到 CMI 后先调用医学实体识别模块把症状、体征、时间、部位、程度等要素抽出来形成结构化病历草稿。同时意图识别模块并行运行判断用户这次是要初步分析可能方向还是鉴别两个已知方向或者是评估检查方案的合理性。第三步根据意图结果编排层决定走哪条推理路径。如果是初步分析触发检索增强模块从知识库召回相关指南片段构建提示上下文然后调用诊断方向推理引擎在限定范围内生成可能的疾病方向每个方向标注置信度和必需的鉴别依据。第四步检查建议生成器基于当前信息完整度输出还需要补充哪些检查、为什么补这些检查、检查的核心鉴别价值是什么。所有输出最后统一到可解释性格式化模块附带证据来源编号和置信度等级推送给医生端。整个流程中有一个关键控制点任何一步的信息不完整系统不会硬推。比如患者只说胸痛但没说持续时间和性质系统会先输出信息缺口提示——建议补充血压、心率、疼痛放射情况等信息而不是直接给出疾病列表。这个控制点来自临床医生的反馈强行推结果在真实场景里不仅没用还会打断医生的思路。2.3 数据流与记忆管理的特殊设计医疗会话和普通客服对话最大的不同在于会话的上下文不只是聊了什么还包括检查结果、生命体征变化这类实时更新的结构化状态。我们把记忆分成了三层管理。第一层是会话级记忆保存当前这次交互的完整对话记录包含用户补充的症状细节和系统中间推理状态会话结束后归档。第二层是病例级记忆跨会话保存同一个患者在本次住院/就诊周期内的关键信息比如之前已经做过哪些检查、结果如何避免重复建议检查或者忽略已有信息。第三层是缓存级记忆保存常用检索结果和常见主诉的推理模板用于加速响应。三层记忆之间通过一个统一的会话标识Session ID关联并且有严格的过期策略。会话级记忆默认保留24小时病例级记忆跟随住院周期出院后归档不销毁便于复诊调用缓存级记忆按 LRU 策略滚动淘汰。数据流的每个节点都记录访问日志和变更记录这个设计是为了后面的合规审计需求当时我们就想清楚了医疗系统的每一个数据流动都不能有黑盒。3. 核心模块设计与实现要点3.1 医学实体识别从自然语言到结构化病历医学实体识别是整个系统的地基这一步做不好后面的推理全是空中楼阁。我们不建议直接用大模型做端到端的实体抽取因为在医学命名上同一实体的别名实在太多——胸闷和胸口发闷、心悸和心慌在临床术语体系里可能是同一个概念但在字符串层面完全不一样。我们采用的是领域模型冷启动 大模型在线抽取的双通道方案。离线阶段用一个规模较小的医学预训练模型底层用的是经过医学语料微调的编码器模型在历史病历上做命名实体识别输出标准的医学实体标签以此构建一个高质量的医学实体锚点库。在线阶段大模型负责理解上下文把文本中的候选实体映射到锚点库的标准术语上。实体归一化这一步非常关键。举例来说患者说我胃不舒服有一个多礼拜了归一化后得到部位上腹部排除胃这个不精确说法、时长8天一个多礼拜取近似值、体征不适归类到General Discomfort。归一化规则里我们建了一个同义词映射表同时配合语义相似度计算兜底确保新出现的口语化表达也能被识别。这一模块的工程提示是医学实体抽取必须保留原始文本的偏移量索引。也就是说知道上腹部是从原句第几个字到第几个字映射来的。这个信息在后续生成信息回显——告诉医生我理解到的信息是 XX来自您刚才说的 XX——时是必须的也是赢得医生信任的关键细节。3.2 诊断方向推理引擎辅助决策的核心逻辑这个是系统里争议最大、也最需要克制的一部分。我们做的诊断方向推理引擎有三条设计原则每一条都是从临床反馈里逼出来的。第一条多路径并行推理不做单路径最优解。一个主诉往往对应多个可能方向它们之间存在鉴别关系。引擎会把候选方向组织成一张怀疑方向图节点是可能疾病边是支持排除需进一步检查确认的关系。这一步我们用了基于概率图模型的框架节点的先验概率来自人群流行病学数据和就诊科室分布条件概率来自指南中的统计数据和专家经验规则。比如胸痛主诉下急性心梗的先验概率会显著高于胃食管反流同时主动脉夹层虽然概率低但权重极高会在图上被单独标记为高致命风险节点。第二条信息缺失感知。引擎不只在当前信息上推理它还会反向检查当前怀疑的疾病有哪些诊断标准是必须确认但当前信息缺失的这些缺失项会作为建议补充信息输出。比如怀疑肺栓塞那么 D-二聚体结果、是否有深静脉血栓风险因素、有无咯血症状这些信息如果还没有就会进入检查建议清单。第三条反事实校验。这是我自己加进来的一个机制。引擎生成候选方向后会做一个反向检查——假设患者是另一个方向的疾病当前已有的信息是否矛盾比如患者胸痛且心电图提示 ST 段抬高那么胃食管反流的证据强度就会被显著压制。这个反事实校验过程让引擎的输出更接近医生的实际思维模式不是只看支持证据也要看有没有关键反对证据。需要说明的是这个引擎的输出从来不是最终诊断而是一种排序后的、带置信度标签的鉴别方向集合。置信度不是一个单点的概率值而是一个区间加一个离散等级高/中/低/极低极低置信度的方向不会出现在最终界面上但会保留在审计日志里。这样做的原因是临床决策辅助领域的共识是宁可让系统低置信度方向不出现在医生视野里也不要用一个精确但虚假的数值制造权威感。3.3 医学知识库构建与检索增强医学知识库的质量直接决定系统输出的证据感。我们建了三个子库指南库、药品库、院内知识库。指南库收录的是公开权威诊疗指南和专家共识按照疾病分类做了层级目录每条指南拆分成推荐意见条级别每条意见都保留原文引用、发布机构和版本年份。指南拆解这一步不能靠大模型自动做我们投入了医学专业人员逐条审核大模型只负责初筛和格式预标注因为指南里的措辞稍有偏差语义就可能反转比如推荐和可考虑在临床里的证据等级完全不同。药品库聚焦的是用药安全信息包括适应症、禁忌症、常规剂量、肝肾功调整剂量、药物相互作用。这个库的关键在于结构化程度要高因为检查建议生成器和用药提示模块需要按结构化字段查询。我们为每个药品建了属性表比如禁用于字段不但包括疾病名还包括生理状态妊娠、哺乳、实验室异常肌酐清除率低于阈值等字段粒度越细后续规则匹配的准确性越高。检索增强模块用的是混合检索关键词稀疏检索基于 BM25配合向量稠密检索基于医学语料微调的嵌入模型然后经过一个重排序模块用一个小型排序模型把最相关的内容排到前面。重排序模块是我们踩了不少坑才加上的不加它的时代经常出现检索到内容相关但无法回答当前具体问题的干扰片段加了之后提示上下文的质量提升非常明显实测答案的引用满意度涨了一大截。知识库更新有一个固定的流程医学人员定版、算法团队同步、灰度发布。灰度发布时只对限定量比例的会话启用新知识版本同时跑离线对比集确认新版本没有引入明显回归才全量放开。这个流程保证了知识更新的节奏是可控的不会出现今天改一个指南、明天系统行为就大变的情况。3.4 可解释输出与合规审计机制医疗场景的 Agent 输出必须有证据链意识。我们界面上输出的每一条建议下面都带一个来源区域列出依据的指南名称、具体条款、置信度、以及当前病历中与该建议相关的信息字段。医生把鼠标悬停在来源处还能展开查看原文摘录。这个设计短期内增加了前端工作量但带来的是医生对系统的信任度指数级上升。合规审计这块我们从一开始就下了狠功夫。每一个交互周期都会生成一个不可篡改的审计记录包包含用户输入的原始脱敏文本、系统生成的 CMI 结构、所有中间模块的输出快照、每条建议的知识来源编号、时间戳、使用的模型版本号。这套记录存储在独立的审计库中定期做完整性校验。虽然系统出错了怎么追责是个复杂话题但至少从工程侧我们把每一笔操作的前因后果都留了案底这对于过信息安全审查是必须的。另外一个容易被忽略的点是模型的版本锁定。在医疗系统里同一个问题在模型升级前后的答案不应该有显著差异因为临床路径依赖稳定的行为。我们上线时做了行为一致性测试为压测集里的每一条输入生成基准输出指纹模型升级时先跑指纹对比差异率超过阈值则阻止上线。这个机制保证医疗 Agent 的升级是进化而不是漂移在辅助诊断这种高风险场景里极为重要。4. 评测体系与效果验证4.1 评测集构建真实与安全之间的平衡评测医疗 Agent 最大的困难是数据。真实病历涉及患者隐私直接拿去评测在合规上过不去。我们走了两条路一条路是公开数据集改造。用公开的医学考试题集和病例库做初筛但它们和真实临床场景的分布差异很大——考题里的信息是齐备的真实场景的信息是碎片化的、不完整的。所以我们做了一个转换流程把完整病例用信息遮蔽的方式随机挖掉部分字段模拟真实场景下的信息残缺情况再人工校对生成的评测样本是否合理。这个过程做了三轮筛选留下的样本覆盖了内、外、急诊的主要病种。另一条路是模拟患者路径。我们请有多年临床工作经验的医生设计了大量标准化病人对话脚本以医患对话的形式模拟患者主诉再让医生撰写理想情况下的辅助建议期望输出。标准化病人脚本特别适合用来测多轮会话——真实场景里患者很可能一开始只说一个表象追问下才暴露真正的关键信号比如胸痛追问出活动后加重、休息缓解这一串追问链路的评测靠静态病例是测不出来的。4.2 核心评测指标设计评测指标不能只看准确率。辅助诊断系统真正要看的指标我梳理成五个维度。第一维度是召回敏感度针对高致命风险疾病。比如主动脉夹层、急性心肌梗死、脑出血这类病系统有没有出现在候选方向里这个权重最高。它不是单一数字而是按疾病类别分头统计。第二维度是信息结构化准确率。实体抽取的精度和召回、属性对齐的正确率、时间单位的归一化正确率——这些越高下游推理越可靠。第三维度是建议合理性。每一条检查建议是否与该怀疑方向一致、是否有明确的鉴别价值。这个指标我们用了一个替代方案让临床医生对建议打分3分制必须做/可以做/不建议最后汇总成平均分。第四维度是过多无用信息率。医疗场景最怕系统把不重要的方向一股脑推给医生我们统计了每个病例输出的候选方向数量以及前3个方向中包含真实正确诊断的比例。期望是前3个方向就能覆盖绝大多数正确诊断如果正确诊断排到了第6、第7位就说明推理权重分配有问题。第五维度是信息缺口识别的覆盖率。系统对每一条信息缺失项的提示是否准确是否漏掉了某种高危疾病的必需鉴别信息也是重点检查项。五个维度分开评测、分开汇报而不是合成一个综合分这样在模型迭代时能清晰看到改哪里、影响了哪项指标。4.3 医生在环的人工复核闭环光靠离线评测集还不够。我们建立了一个医生在环的常态化复核机制每月请合作医院的临床医生抽检系统在真实脱敏数据上的输出按固定模板打分同时标注他们发现问题时的错因类型——是知识库缺失、推理权重不对、还是信息抽取错了。这个环节的价值在于它能把离线评测和真实体验之间的差距暴露出来。有一次医生反馈系统在上腹痛的检查建议里频繁加入腹部 CT但实际上对门诊患者来说超声是最常用也最合理的初步筛查手段。我们查了推理引擎的权重配置发现引擎给腹部 CT 设置的诊断信息增益权重偏高而对检查成本、辐射剂量这些因素完全没有建模。这个反馈直接推动了引擎加入初步检查 vs 进阶检查的层级判断逻辑。人工复核的反馈不止用在模型迭代上也沉淀成规则库。很多临床经验类的约束比如育龄期女性腹痛必须排除宫外孕这类原则大模型难以从统计语料里稳定学出来我们就通过复核反馈整理成显式的专家规则在推理引擎里以强约束的形式存在。5. 工程落地中的常见坑与排查实录5.1 私有化部署与算力博弈医院环境里做 Agent 系统绕不开私有化部署。很多医院不允许核心医疗数据出内网意味着模型推理必须在院内基础设施上跑。我们踩过的第一个坑是算力规划严重不足。最开始我们按并发10个会话、单次响应8秒内的目标规划 GPU 资源结果上线后发现术前谈话、门诊高峰期的并发远超预想高峰时期的响应时间直接飙到20秒以上整个体验完全不可用。后来做了三个改动才缓解第一把响应时间要求改成分级——纯结构化抽取任务走快速通道目标2秒内需要多路径推理的复杂任务走慢速通道目标10秒内第二引入请求队列和优先级调度急诊优先第三对高频主诉做推理结果缓存同一个主诉相似信息组合直接在缓存层命中不重复跑推理链路。另一个经验是模型蒸馏。我们把线上推理模型从全量大模型逐步蒸馏成不同规模的版本按任务复杂度自动选择模型。简单任务用轻量模型能力和成本平衡复杂任务才动用大模型。这个分层推理策略在私有化环境里是把性能和成本压下来的关键手段。有条件的团队建议在项目规划阶段就预留模型服务层避免后期把推理逻辑硬编码在业务代码里那样改模型就变成一场灾难。5.2 多轮会话中的记忆漂移问题Agent 的上下文管理在医疗场景有特殊的坑。系统在多轮会话后经常会生成自我矛盾的病历摘要比如患者第一轮说胸痛3天第二轮说活动后加重系统在做信息合并时可能因为提示上下文过长把3天和活动后加重错误归入不同的疑似疾病方向导致推理结果前后不一致。我们把这类问题统称为记忆漂移。排查之后发现根因有两个一个是上下文窗口截断策略太粗暴。当对话超过模型上下文长度时我们简单地把最早的历史对话丢掉了但最早的信息往往包含最核心的主诉这样一丢记忆就出现了断裂。后来的方案是分层摘要不会直接丢弃早期内容而是先把早期信息压缩成结构化摘要症状、时长、已做检查、尝试处理完整原文存到会话记忆中只有摘要进入上下文窗口。这样既控制了上下文长度又保留了信息的结构化完整性。另一个是信息冲突检测缺失。患者第二轮说喝了硝酸甘油有没有缓解如果第一轮已经记录胸痛系统应该识别出这是在问药物反应而不是把它当作一个新的孤立症状。我们加了冲突检测和关联模块新输入先和既有 CMI 结构做对齐自动识别这是对既有症状的补充还是新症状。这个模块上线后记忆漂移导致的推理前后矛盾问题少了大概半数。5.3 误报与漏报的权衡策略医疗 Agent 在真实使用中最让医生反感的不是漏报医生本来就会自己做判断而是这个系统怎么什么都往外说——被大量无关提示干扰信任感降低得很快。我开始时为了追求高召回把所有低置信度方向都列出来结果医生说这个系统像百度前十条——什么都有、什么都没用。后来我们调整了过滤策略对每个候选方向做三层过滤第一层按置信度等级卡阈值极低方向一律不进界面第二层按致命风险复核即使置信度低但如果是高致死风险疾病必须保留并单独标红提示第三层按与当前病历的信息支撑度过滤有明确支持证据的方向才显示缺乏证据的缩入其他可能方向折叠区。这样既保住了致命性疾病的敏感性又大幅减少了无价值输出的数量。这个权衡策略的逻辑是一句话在医疗场景召回率的优先级体现在高危疾病上而不是所有疾病上。对于低危疾病精确率优先级高于召回率。想清楚这一点阈值设计的思路就通透了。5.4 常见问题速查表我把项目过程中遇到过的高频问题整理成一个速查表给正在做或者准备做类似系统的团队一个参考问题类别典型表现根因分析推荐排查路径实体抽取口语化症状无法归一化同义词锚点库覆盖不足先查归一化日志看是未识别还是映射冲突再扩充锚点库检索质量提示上下文包含无关指南内容重排序模块缺失或权重不当按检索日志查 Top-5 命中相关性针对性调整重排序模型数据推理权重正确方向排名过靠后先验概率或条件概率字段不合理用评测集分病种统计头部命中率定位到具体病种权重上下文管理多轮后病历摘要出现矛盾截断策略丢失早期关键信息检查会话摘要模块是否生效确认结构化摘要完整度响应延迟复杂任务响应超时模型规模过大或推理链路过长分析任务级耗时评估缓存命中率考虑模型蒸馏合规审计审计日志不完整中间节点未接入审计采集按数据流全链路检查埋点覆盖率补全快照序5.5 冷启动阶段的一个特别提醒最后单独说一件容易被忽视的事冷启动阶段不要追求功能完整先跑通一个最小闭环。我跟很多团队聊过大家最容易犯的毛病就是第一版就把所有模块都堆上去意图识别、多路径推理、复杂知识检索、生成式推荐全部上线然后发现每个模块都不稳出了问题根本定位不到是哪个环节。我们的经验是第一个可交付版本只需要三个能力一是结构化信息抽取二是基于检索增强的方向推荐三是简单的检查建议模板。这三条链路跑通、拿到临床医生的真实反馈之后再逐步叠加推理引擎、冲突检测、复杂记忆管理这些深度模块。医疗领域客户对稳定性的要求远高于对功能数量的要求。一个只有三项能力但每次结果都靠谱且可解释的系统远胜于一个功能很全但经常说些不痛不痒的话的系统。这个理念贯穿了我们整个开发周期的资源分配。另外提醒一点医疗 Agent 的模型行为一致性测试要尽早做。越往后模型版本迭代越频繁如果没有一个自动化的输出指纹对比机制上线回归只能靠人工翻案例根本翻不过来。把行为一致性测试纳入 CI和代码测试一起跑是控制长期维护成本最划算的一笔投入。套用我们项目总监说过的一句话医疗场景不是给 Agent 找了很多活干而是把 Agent 能干的活精确地圈出来然后把圈外的活全部挡掉。这套架构拆解下来核心不在模型多强而在边界画得多清楚、证据链多完整、反馈闭环多及时。垂直行业落地的本质大致就是这样——把通才磨成专才再给专才配上严明的纪律。