我一直觉得医疗场景是 Agent 最不该急着落地、但一旦落地价值最实的行业。原因不复杂医生每天要处理的信息量早已超出人脑能高效消化的范围而诊断推理链条又长又严谨恰好是 LLM 这类系统相对擅长辅助的领域。但这里有一个前提——它只能做辅助不能做替代。这篇内容我基于实际参与过的医疗场景 Agent 诊断辅助系统架构设计把核心思路、模块划分、落地过程中踩过的坑和排查方法完整拆一遍适合正在做垂直行业 AI 落地的架构师、算法工程师也适合医疗信息化方向的产品和技术负责人参考。1. 医疗场景到底需要什么样的诊断辅助系统1.1 先给系统划定边界辅助工具不是自动驾驶医疗场景最大的特点我说直白一点容错率极低责任链条非常清晰数据敏感度又高。这和电商推荐、内容生成完全不是一个量级的约束。所以做医疗 Agent第一原则不是功能多强、覆盖面多广而是边界是否清晰、输出是否可控、决策是否可追溯。我们在最开始设计时也有过一段弯路。当时团队里有人提了一个很吸引人的想法做一个输入症状、直接输出诊断结果的问答系统听起来很酷但很快就发现这条路走不通。原因其实不复杂——真实临床场景下患者不会照着教科书描述症状主诉经常是模糊的、混杂的、非典型的。假设一个患者说“最近总是头晕站起来眼前发黑血压好像有点高”这个描述里既没有明确的持续时间也没有既往病史更没有检验指标如果系统直接给出一个自以为是的“最可能诊断”医生根本没法用也不愿意信。所以后来我们给这个系统定下了非常明确的身份它不是一个能独立下诊断的“自动驾驶系统”而是给医生提供结构化信息整理、鉴别诊断参考、证据链归纳的“辅助驾驶工具”。系统可以主动帮医生梳理病情线索、提出排查方向、给出检查建议但最终诊断结论必须由医生确认系统内不设“最终诊断”按钮。这个定位一开始可能让人觉得保守但后来整个项目的落地推进全靠这个边界守得稳。1.2 诊断辅助的三个核心能力拆解把边界划清楚之后接下来要回答的是这个系统到底要具备什么核心能力才能让医生觉得有用而不是又一个添乱的“AI玩具”我拆下来核心能力集中在三块第一块是临床逻辑深度。医疗诊断不是一个简单的症状到疾病的映射关系。同样一个“胸痛”可能是心肌梗死也可能是肋间神经痛还可能是反流性食管炎。系统需要理解的不只是症状本身还要结合病程演变、既往史、用药史、检验指标动态变化构建一个有时间轴的临床逻辑链。比如一个患者的肌钙蛋白在几个小时内持续升高同时伴有典型胸痛和心电图改变这个信息组合的权重远大于患者随口说的一句“胸口不舒服”。第二块是证据链构建。医生在临床决策时最反感的就是“黑盒给结论”。所以系统的每一个判断都必须能追到依据——是哪条指南、哪个检验指标变化、哪段既往病史支撑了这个考虑方向。换句话说系统给医生的不应该是一句“可能是冠心病”而应该是“根据患者胸痛性质、肌钙蛋白动态升高、既往高血压病史结合某版指南建议优先排查急性冠脉综合征建议完善心电图和心梗三项”。第三块是多源信息整合。一份病历里面有医生书写的非结构化文本有检验检查的结构化数值有影像报告的结论描述还有历史住院记录的时序数据。这些来源的信息常常不在同一个系统里医生需要自己来回切换、人工拼接。Agent 系统最有价值的地方之一就是能把来自不同数据源的信息拉到同一个上下文里按时间轴和临床维度重组变成一个医生可以直接审阅的结构化视图。打个比方大家就明白了。这套系统做的事情有点像给医生配了一个能力很强的住院总助手——他提前把病人资料全部翻过一遍整理出一个按时间线排好的摘要把关键异常指标用红黄绿标出来然后给出“可以考虑排查什么、为什么、下一步建议做什么”。这个助手不会直接拍着胸脯说“病人就是某某病”但他能极大节省医生整理信息的时间减少遗漏。2. 系统架构的核心设计思路2.1 总体分层从数据接入到临床应用的解耦设计整体架构上我们分了五层每一层职责单一可以独立升级改造。这也是后期维护时痛苦最少的选择。最底下是数据接入层。医疗场景的数据源非常分散EMR电子病历、LIS检验系统、RIS影像系统、超声报告、病理报告各有各的接口规范和数据库。这一层要做的事情就是把不同格式的数据统一成一套内部标准结构比如把“肌钙蛋白I 0.05ng/mL”这种可能在不同系统里字段名完全不同的数据全部规范化成统一指标名、统一单位、统一参考范围。别小看这一层的工程量医疗数据标准化是整个项目里最琐碎但最关键的底座。上面一层是知识层。包含医学知识图谱、临床指南库、药品说明书库、既往脱敏病历库。知识层的定位不是简单存文件而是把这些知识结构化让上层 Agent 可以按需精准取用。例如知识图谱中记录“胸痛”这个症状与几十种疾病之间的关联关系、每种关联的权重、对应的支持证据来源。指南库则按疾病领域拆分每条指南片段带标签和版本号方便后续溯源。再往上是Agent编排层这是整个系统的核心中枢。它接收来自医生工作站的结构化输入把任务拆解成多个子任务分发给不同的 Agent统一管理上下文状态和任务流转最后汇总各 Agent 的输出做一致性校验。这里类似一个项目总监的角色不亲自写代码但知道什么时候把任务派给谁也知道怎么把各部分产出拼成完整的交付物。上面两层靠近用户应用层和展示层。应用层对接具体场景比如门诊医生工作站插件、病房会诊辅助界面、病历质控后台。展示层解决“怎么让医生舒服地看”的问题设计原则是关键信息醒目参考内容弱化所有 AI 生成内容都可编辑可留痕。2.2 为什么选择多 Agent 编排而不是单一大模型对话这是架构设计里被问得最多的问题也是我们最开始反复权衡的决策点。最初我们确实做过一个原型把全部能力塞进一个大模型的 system prompt 里通过多轮会话完成从主诉收集到鉴别诊断到检查建议的全流程。当时觉得这样最简单上下文不用切来切去而且大模型本身具备很强的对话连贯性。但实际跑起来之后问题暴露得很明显。第一上下文窗口再大也是有限的当患者信息很多时最早的关键信息会被逐渐“挤丢”。第二职责不分所有的指令混在一个超级提示词里互相干扰。例如让同一个模型既做严谨的事实抽取又做发散性的鉴别诊断推理还要兼顾病历写作风格模型很难在一条回复里同时把三件事都做到位。第三是维护成本高临床反馈经常是“主诉抽取还好但鉴别诊断那块建议质量下降了”如果是单一大模型我们根本没法只优化某一个特定环节因为参数是全局共享的。多 Agent 架构天然解决了这些问题。我们把临床任务拆成几个明确分工的角色主诉解析 Agent负责把患者零散的语言描述转成结构化病史元素。鉴别诊断推理 Agent基于结构化病史和多源指标生成候选诊断列表并给出鉴别分析。检查建议 Agent根据候选诊断和临床指南推荐下一步排查手段。病历文书 Agent把会话过程自动组织成符合规范的门诊病历或出院小结草稿。风险预警 Agent负责识别危险信号触发转人工或紧急提示。每个 Agent 有独立的提示模板、独立的工具集、独立的评价数据。这让系统可以像一支各有专长的医疗团队一样协作。某个环节出了问题我们只需要针对那个 Agent 单独调整和测评不会牵一发动全身。实测下来多 Agent 方案在信息完整度、单模块优化空间和故障隔离范围上都全面优于单一大模型。编排层还有一个职责我想单独强调上下文管理。各 Agent 之间不是简单的互相独立它们共享一个统一的“案例上下文容器”里面包含患者的结构化信息摘要、时间轴、当前已采集的证据列表、已生成的部分报告。每个 Agent 只读取与自身任务相关的字段避免了职责交叉同时又能保证所有 Agent 基于同一份患者信息推理不会各说各话。3. 关键模块拆解与实操要点3.1 患者主诉解析 Agent从自然语言到结构化病史这是整个系统最前置也最容易翻车的环节。为什么这么说因为后面所有推理的质量都取决于这一层结构化的信息是否完整、准确。就像医生问诊问得越清楚诊断越有把握系统解析得越准鉴别诊断 Agent 的可信度才越高。真实场景中的患者描述是什么样的呢举个例子“大夫我最近总觉得心慌有时候一阵阵的干活儿一累就明显晚上睡不着觉之前查过心电图说有点问题但是我那会儿没当回事。”这段描述里信息是碎片化的夹杂了诱因、情绪状态、既往模糊的检查结果还有患者的主观态度。主诉解析 Agent 要做的是从这段话里抽取以下结构化元素主诉心悸待明确性质、持续时间病程近期诱发因素劳累时加重伴随症状眠差待确认与心悸是否相关既往相关检查心电图异常史时间不详待采集信息心悸发作时的性质、有无胸痛、有无晕厥、家族史、近期用药这背后我们走的是“规则抽取优先、模型理解兜底”的混合策略。先跑一套基于医学词典和正则表达式的实体识别把化验指标、症状词、药物名、时间单位抓出来然后在此基础上用 LLM 做语义级的要素补全和逻辑组织。如果把所有解析任务全交给 LLM 裸跑很容易出现输出结构不稳定或漏字段的问题。这里有个实操细节供参考Agent 的输出必须是有固定 Schema 的 JSON而不是自由文本。每个字段附带结构化记录的置信度和来源片段例如“心悸来源原文‘总觉得心慌’置信度 0.95”。这样即使用户看到输出有疑问也能直接追溯到原始描述而不是对着一个黑盒结构干瞪眼。注意最忌讳的就是让主诉解析 Agent 自行脑补患者没提过的信息。假设患者没说胸痛系统绝对不能为了“让逻辑更完整”而加上“无胸痛”这个阴性症状因为患者可能是没说也可能是问诊阶段还没问到。Agent 只能对显式信息做结构化对未提及信息标记为“待确认”。3.2 鉴别诊断推理 Agent如何生成可解释的候选排序鉴别诊断是整个系统的核心模块也是最难做好的模块。我先把我们最终落地的三段式思路讲清楚。第一跳候选召回。系统拿到结构化病史后先通过医学知识图谱做疾病召回。比如患者有“心悸”“劳累诱发”“心电图异常史”图谱就会沿着症状节点关联出心律失常、冠心病、甲状腺功能亢进、焦虑障碍、贫血等候选疾病。这一步的核心目标是“不遗漏”宁可多召回一些概率很低的病也不能漏掉高风险的病。我们比较关注 Top20 召回率要求常见病基本都能覆盖到这是后面排序的前提。第二跳规则与统计排序。这一步用可解释的权重规则对候选疾病做初排序。排序因子包括患者年龄性别的基础流行病学概率、症状匹配度、危险信号权重、既往病史关联度。为什么不用 LLM 直接排序因为 LLM 排序的结果难以解释而且很容易被训练语料里的“常见病偏差”所影响。用显式规则做排序每一个权重调整都有迹可循也方便临床医生理解和参与调整。第三跳LLM 生成鉴别分析。排序完成后LLM 拿到 Top N 候选疾病和对应的证据列表用自然语言生成鉴别分析文本。这段文本不是凭空写的而是严格围绕给定的证据列表来组织。例如“患者中年男性劳累后心悸心电图提示异常结合高血压病史首先考虑心律失常可能。冠心病需排除建议完善动态心电图和心脏超声。甲亢可引起心悸建议检测甲状腺功能。”三段式最大的好处是每一跳都负责一个明确且可控的任务模型只负责最终的语言组织和表达而关键的事实判断工作由图谱和规则来完成。这样既保证了可解释性也极大地降低了模型幻觉对最终结果的影响。在这个模块里还要特别提一个设计——危险信号分级。我们要求鉴别诊断 Agent 输出候选列表时每个诊断必须配一个信号等级等级含义系统行为红色需立即排除的高危诊断如急性心梗、主动脉夹层显著标注建议医生优先关注黄色常见或需重点排查的诊断常规显示进入鉴别分析绿色低概率但不典型的可能折叠展示防止误伤注意力这个分级机制既防止了系统漏掉高危信号也避免了所有可能性平铺在界面上、医生什么都看不清的问题。3.3 医学知识检索设计RAG 不是万能的现在大家做垂直领域应用基本言必称 RAG。但我可以负责任地说医疗场景直接拿通用 RAG 方案效果大概率会让人失望。我们最开始尝试过把指南 PDF 直接切片做向量化再用相似度检索召回。测试下来有三个特别典型的问题。第一PDF 解析质量极差指南里大量内容在表格里切片后表格结构全丢检索命中的文本往往不完整。第二语义相似度检索在医学语境下很容易召回“语义像但内容不对”的片段。比如查询“胸痛伴随呼吸困难”检索结果可能返回“胸痛患者的呼吸困难评估”这类相关描述但也可能返回“心源性呼吸困难鉴别”这种关联太泛的内容。第三检索返回的文本片段零散Agent 很难从中组织出结构化的诊断逻辑结果质量自然不稳定。后来我们换成了**“先图谱定位、再文本取证”两阶段检索方案**。第一阶段系统根据结构化症状和指标在知识图谱中定位到对应的疾病节点和相关关系。例如症状“心悸”节点关联到“心律失常”“甲亢”“贫血”等疾病节点同时连接着“动态心电图”“甲状腺功能检查”等诊疗节点。第二阶段针对图谱定位出的关键节点去指南库中精准提取对应的原文片段作为证据附件这时提取的文本就不是泛泛相似了而是有明确目的、按图索骥式的取证。这个方案的直接效果是检索相关性显著提升而且每一段检索文本都有对应的图谱路径方便最终生成时做引用溯源。如果你也在做医疗类的 Agent我强烈建议把知识图谱前置而不是一上来就做纯向量库。实操心得医疗知识图谱的构建初期不需要追求大而全。先把一个科室、一种疾病领域的核心关系建模清楚比做一张“全科图谱”但每个节点都缺斤短两要实用得多。我们是从心血管领域起步的关系只覆盖症状、疾病、检验、药物、检查五类节点和十几条关系边但每一条关系都经过临床顾问逐条审核可信度非常高。3.4 病历文书生成与辅助记录医生日常最耗时的工作往往不是诊断推理本身而是写病历。一份规范的门诊病历要写清楚主诉、现病史、既往史、体格检查、辅助检查、初步诊断和处理意见还要符合医疗机构内部的文书规范。这也是 Agent 最能直接产生效率价值的地方。病历文书 Agent 的逻辑是在整段诊疗会话过程中持续记录将主诉解析 Agent 的结构化结果、鉴别诊断 Agent 的分析结论、医生手动录入的补充信息一并汇总按院内病历模板自动生成草稿。它的输出不是“文本框填空”而是按章节结构生成的完整文本医生在界面里直接审阅、修改、确认。这里有一个很重要的设计约束所有检查结果和数值指标的引用必须原文摘录不允许 LLM 转述。实践中我们发现如果让模型用自己的话描述检验数值很容易在生产报告中引入细微偏差。比如患者肌钙蛋白数值“0.05ng/mL”模型可能会在生成时表述为“轻度升高”但如果这个数值其实处在临界区间“轻度”这个形容词就可能误导。因此我们做了硬性约束指标值必须是结构化数据源的原文模型能写的只是描述性语境不能改动数值本身。另一个约束是模板字段的可追溯性。病历文书 Agent 在生成每个段落时都会附带内容来源标记。比如“现病史”段落引用的是主诉解析 Agent 的结构化字段“初步诊断”段落引用的是鉴别诊断 Agent 的候选列表和医生的确认结果。这样做的好处是一旦出现病历质量争议可以快速定位每一个字段是从哪一步来的而不是面对一个大模型生成的文本无从追查。这块上线后收到的反馈相当正面。医生普遍反映整理信息的时间明显减少以前一份门诊病历要写几分钟现在主要是审改 AI 草稿几十秒就能完成。4. 落地过程中的典型问题与排查实录4.1 幻觉问题多策略约束生成幻觉在医疗场景不是“效果不好”的问题而是“可能误导诊疗方向”的问题。我们在真实测试中的一次失误值得拿出来复盘。当时在脱敏演示环境里系统接诊了一个“心悸伴晕厥”的案例。鉴别诊断 Agent 生成的文本里把“低钾血症”列入了重点排查建议理由是“低钾血症可导致心律失常甚至晕厥”。从医学逻辑上讲这句话本身没有错低钾血症确实是心悸和晕厥的诱因之一。但问题在于——这位患者的血钾是正常值 4.2mmol/L系统因为知识图谱里“晕厥-低钾”这条关系被触碰到了生成了这个排查建议却没有严格对照当前患者的结构化化验数据。这是一个典型的“知识关系正确但个体不适用”的幻觉案例。这次事件之后我们建立了一套多策略约束机制第一强制证据绑定。鉴别诊断 Agent 生成的每一个候选疾病必须在知识图谱和当前患者的化验指标之间有明确的关联路径并且关联所使用的证据必须来自患者数据不允许来自模型记忆。如果一个诊断建议找不到患者数据支撑就会被自动剔除。第二结构化数值闭环。患者的所有检验指标在推理链路里不是作为一段文本上下文存在的而是作为结构化数据对象Agent 只能通过工具调用去查询“当前患者血钾是多少”查询返回的结果才是它可用的证据。这从机制上切断了模型凭记忆“编造”检验值的路径。第三事实类输出锁定。对主诉、现病史、诊断、检查建议这类事实性极强的输出我们把模型温度调到极低同时限制模型只能使用给定工具结果不能自由发挥。经验是医疗场景事实类任务宁可让模型说“信息不足”而拒绝作答也比给它一个看似合理实则存疑的回答更安全。4.2 置信度与拒答机制不硬答同样是一种能力医疗 Agent 最危险的其实不是答错而是“不知道自己不知道”还硬答。所以我们在系统架构里单独设计了置信度评估和拒答机制。每个 Agent 在输出关键结论时都需要附带一个内部一致性评分。评分逻辑并不是模型给自己打一个“感觉分数”而是基于实际证据覆盖度计算患者的症状元素被候选诊断解释了多少、医生的关键未回答信息是否影响当前判断、被触发的鉴别关系是否有足够的化验指标支持。当这些证据覆盖度低于某个阈值时系统不会强行生成诊断建议而是转入追问流程或转人工。我做了一张规则表可以比较直观地表达这个机制触发条件系统行为证据覆盖充分候选诊断清晰输出建议并附证据链关键信息缺失如缺少持续时间、既往史触发追问补齐信息后再推理存在红色危险信号且信息不足无