企业官网建设流程全解析

医疗场景的 AI 落地，和互联网行业完全是两回事。两年前我带队做通用知识库问答系统时，以为把大模型接进去、把知识挂上去就能交付，结果在合作医院的试用现场被问得哑口无言——医生要的不是"能聊"，而是"能辅助做决策"。

后来我们花了大半年时间，把方案推倒重来，做了一套专门面向临床诊断辅助场景的 Agent 系统。这个项目谈不上多前沿，但架构思路和踩坑过程比较有代表性，想着整理出来，给准备做垂直行业 Agent 落地的团队一些参考。

先说清楚这套系统是什么：它不替代医生做诊断，而是在医生输入主诉、病史等关键信息后，由 Agent 完成病历信息结构化提取、疑似方向检索、检查建议生成、鉴别诊断要点提示等辅助工作。整个过程有明确的边界控制，输出必须带证据来源和置信度标识，所有交互留痕可审计。

这套东西适合谁参考？如果你正在做医疗信息化、临床决策支持系统，或者准备把 Agent 架构引入其他强合规、强专业的垂直领域（比如法律、金融风控），这篇拆解会很有价值。我会把整体设计思路、核心模块实现、评测方法、工程落地中的坑，一条一条讲清楚。

1. 为什么医疗场景必须做垂直落地

1.1 通用大模型在医疗场景的失灵现象

先泼一盆冷水：拿通用大模型直接做医疗问答，效果非常不靠谱。我们早期做过一轮实测，用同一个模型问"胸痛伴大汗，可能是什么问题"，它给出的答案确实覆盖了急性心肌梗死、肺栓塞、主动脉夹层等方向，但问题是它把每个方向的紧急程度写得几乎一样，也没有提示"主动脉夹层一旦误判后果极严重"这类临床决策的关键约束。

这个问题不是模型不够聪明，而是通用模型的训练目标决定了它的输出均衡化倾向。在互联网问答场景里，给出全面的、涵盖各种可能性的答案是正确的；但在临床辅助场景里，信息的"决策权重"比"信息覆盖度"重要得多。医生需要知道的是：这个主诉下最需要排除的致命性疾病是什么，什么检查能快速帮助鉴别，哪些信息缺失可能导致误判。

通用模型的另一个问题是知识时效性。医学知识更新很快，诊疗指南每年都有修订，通用模型的知识截断日期决定了它无法感知最新指南。如果让系统直接引用过时的用药建议，在临床应用中是绝对不可接受的。

1.2 医疗场景真实需求的四个维度

垂直落地不是简单地把模型换掉，而是整个系统的交互逻辑、知识组织方式、评价标准都要跟着业务需求走。我在和临床医生反复沟通后，把真实需求拆成了四个维度：

第一，结构化程度。临床工作高度依赖结构化信息。患者说"我胸口疼了两天"，医生需要的是"胸痛、持续时长48小时、疼痛性质待明确"这样的结构化字段，而不是一段自然语言描述。Agent 必须先做信息抽取和结构化，否则下游所有逻辑都无法处理。

第二，决策边界。医生不需要 Agent 告诉他"这是什么病"，而是需要 Agent 提供"这个方向的可能性较大，需要优先排除的疾病有哪几个，建议补充哪些检查"。辅助和决策之间必须有一条清晰的线，系统永远站在辅助位置。

第三，可追溯性。任何一条建议都必须能回溯到具体的知识来源——是哪版指南、哪个共识、哪条文献。没有来源的输出，临床医生不会信任，出了问题也无法追责。

第四，容错偏好。医疗场景的容错是"宁可有假阳性提示，不能漏掉致命性误判"。也就是说，对于急性心梗、主动脉夹层这类高致死率疾病，系统的召回率优先级最高，哪怕多给几条干扰提示，也不能让真正危险的信号被过滤掉。这个偏好会直接影响后面注意力机制的设计和阈值设置。

通用 Agent 架构在互联网场景的假设——海量用户、低交互成本、可接受误差——在医疗场景完全不成立。只有把上面四个维度的需求前置到架构设计里，做出来的系统才能真正进得了科室。

2. 系统总体架构与核心协作流程

2.1 四层架构设计与模块划分

整个系统我们用了四层架构：接入层、编排层、能力层、数据层。每一层的职责都刻意收敛，避免模块间职责交叉导致后续维护失控。

接入层负责统一接诊标准。无论是医生的自然语言输入、护士站的结构化录入，还是后续接入 HIS（医院信息系统），都先转换成统一的中间表示（CMI，Clinical 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 常见问题速查表

我把项目过程中遇到过的高频问题整理成一个速查表，给正在做或者准备做类似系统的团队一个参考：

5.5 冷启动阶段的一个特别提醒

最后单独说一件容易被忽视的事：冷启动阶段不要追求功能完整，先跑通一个最小闭环。

我跟很多团队聊过，大家最容易犯的毛病就是第一版就把所有模块都堆上去，意图识别、多路径推理、复杂知识检索、生成式推荐全部上线，然后发现每个模块都不稳，出了问题根本定位不到是哪个环节。我们的经验是，第一个可交付版本只需要三个能力：一是结构化信息抽取，二是基于检索增强的方向推荐，三是简单的检查建议模板。这三条链路跑通、拿到临床医生的真实反馈之后，再逐步叠加推理引擎、冲突检测、复杂记忆管理这些深度模块。

医疗领域客户对稳定性的要求远高于对功能数量的要求。一个"只有三项能力但每次结果都靠谱且可解释"的系统，远胜于一个"功能很全但经常说些不痛不痒的话"的系统。这个理念贯穿了我们整个开发周期的资源分配。

另外提醒一点，医疗 Agent 的模型行为一致性测试要尽早做。越往后模型版本迭代越频繁，如果没有一个自动化的输出指纹对比机制，上线回归只能靠人工翻案例，根本翻不过来。把行为一致性测试纳入 CI，和代码测试一起跑，是控制长期维护成本最划算的一笔投入。

套用我们项目总监说过的一句话："医疗场景不是给 Agent 找了很多活干，而是把 Agent 能干的活精确地圈出来，然后把圈外的活全部挡掉。"这套架构拆解下来，核心不在模型多强，而在边界画得多清楚、证据链多完整、反馈闭环多及时。垂直行业落地的本质大致就是这样——把通才磨成专才，再给专才配上严明的纪律。