医疗AI新范式：提示工程架构师详解上下文工程在Agentic辅助诊断中的应用场景

引言：当医疗AI遇到“不会看病”的尴尬

凌晨2点，三甲医院呼吸科诊室里，李医生盯着电脑屏幕上的AI辅助诊断报告皱起眉头——屏幕上赫然写着“建议使用青霉素类抗生素治疗社区获得性肺炎”，但患者的电子病历（EMR）里明确标注了“青霉素过敏史”。更离谱的是，AI完全没提到患者有10年糖尿病史——这意味着患者更易并发真菌性肺炎，而青霉素对此无效。

“又是一个‘断章取义’的AI。”李医生无奈地手动修正方案，心里默念：如果AI能像人类医生一样“读全病历、记得病史、遵守指南”，该多好？

这不是个例。传统医疗AI的核心痛点在于：

• 数据依赖症：靠标注好的结构化数据训练，遇到非结构化病历或罕见病例就“失明”；
• 推理割裂感：无法融合患者全生命周期数据（如既往史、用药史）与实时诊疗信息；
• 规范脱节症：不会主动引用最新临床指南，输出结果常不符合医疗规范。

当Agentic AI（智能体）技术进入医疗领域，这一切开始改变。Agentic辅助诊断的核心是让AI像“虚拟医生助手”一样：主动收集信息、动态推理、自适应调整建议——而支撑这一能力的“底层操作系统”，正是上下文工程。

作为一名深耕医疗AI的提示工程架构师，我将用3个真实场景、5个核心步骤、10+实践技巧，拆解上下文工程如何让医疗Agent从“机械回答”进化为“会看病的智能体”。

---

一、先搞懂：医疗Agent与上下文工程的底层逻辑

在讲应用之前，我们需要明确两个关键概念——什么是医疗Agent？、什么是上下文工程？

1. 医疗Agent的本质：能“主动思考”的临床助手

Agentic AI的定义是“具备感知、决策、行动能力的智能体”。放在医疗场景中，医疗Agent的核心架构是“三层闭环”：

• 感知层：收集患者数据（病历、影像、检验结果）、医生反馈、临床指南等信息；
• 思考层：基于提示工程（Prompt Engineering）分析信息，生成诊断/治疗建议；
• 行动层：输出建议、主动追问患者/医生（如“请问患者痰中是否带血？”）、更新上下文库。

与传统医疗AI的最大区别是：医疗Agent会“主动管理信息”——它不是被动等待输入，而是会根据当前场景“找数据、补信息、调逻辑”。

2. 上下文工程：医疗Agent的“记忆与逻辑库”

如果把医疗Agent比作“虚拟医生”，那么上下文工程就是它的“大脑内存”：

• 上下文（Context）：Agent进行推理时需要的所有信息，包括：
  • 患者数据（基础信息、既往史、现病史、检验结果）；
  • 领域知识（临床指南、专家共识、疾病数据库）；
  • 交互历史（医生/患者的问答记录、之前的建议及反馈）；
• 工程（Engineering）：对这些信息进行“收集、整理、融合、优化”的技术体系，让Agent能“高效用对信息”。

简单来说：提示工程是“教Agent怎么想”，上下文工程是“给Agent想什么”——两者结合，才能让Agent输出符合临床逻辑的建议。

3. 前置准备：医疗上下文工程的“基础设施”

要做医疗上下文工程，你需要先搭好3个基础：

• 数据层：对接医院电子病历系统（EMR）、实验室信息系统（LIS）、医学影像系统（PACS），获取结构化（如检验数值）与非结构化数据（如病历文本）；
• 知识层：构建医疗领域知识图谱（如疾病-症状-药物关联）、实时同步最新临床指南（如《2023版社区获得性肺炎诊疗指南》）；
• 工具层：用向量数据库（如Pinecone）存储上下文、用Embedding模型（如text-embedding-3-small）将文本转化为可检索的向量、用RAG（检索增强生成）技术调取相关信息。

---

二、实战：上下文工程在Agentic辅助诊断中的5个核心场景

接下来，我将用**“老年糖尿病患者并发肺炎”**的真实案例，拆解上下文工程的5个关键步骤——这是临床中常见的“复杂病例”，也是传统AI最容易翻车的场景。

场景背景：患者信息

• 患者：王建国，男，68岁；
• 现病史：咳嗽、咳痰2周，伴发热1天（体温38.5℃）；
• 既往史：2型糖尿病10年（HbA1c 8.5%，血糖控制不佳）、高血压5年；
• 检验结果：白细胞计数12×10⁹/L（正常4-10）、CRP 40mg/L（正常<10）；
• 影像结果：右肺下叶磨玻璃影。

步骤1：上下文提取——从“乱码病历”中挖关键信息

问题：电子病历里的文本是“主诉：咳嗽咳痰2周，发热1天；现病史：患者2周前无明显诱因出现咳嗽，咳白色黏痰，量中等，无咯血，1天前出现发热，体温最高38.5℃，伴乏力；既往史：糖尿病10年，高血压5年，否认药物过敏史；检验：白细胞12×10⁹/L，CRP40mg/L；影像：右肺下叶磨玻璃影”——传统AI常“漏读”“错读”非结构化文本中的关键信息（如“血糖控制不佳”）。

上下文工程解法：结构化提示+Few-shot引导
我们需要用Prompt让Agent从非结构化病历中精准提取“临床决策相关信息”，核心技巧是：

• 用“指令+格式”约束提取范围：明确要求提取的信息类型（如症状、体征、既往史、检验结果）及输出格式（如列表）；
• 用“Few-shot示例”减少歧义：给Agent看一个“正确提取的例子”，让它学会识别隐藏信息（如“血糖控制不佳”）。

示例Prompt：

请从以下病历中提取临床决策相关的关键信息，按“症状（时间排序）、既往史（含控制情况）、检验结果（异常值）、影像结果”的结构输出：

【病历文本】
主诉：咳嗽咳痰2周，发热1天；
现病史：患者2周前无明显诱因出现咳嗽，咳白色黏痰，量中等，无咯血，1天前出现发热，体温最高38.5℃，伴乏力；
既往史：糖尿病10年（HbA1c 8.5%）、高血压5年，否认药物过敏史；
检验：白细胞12×10⁹/L，CRP40mg/L；
影像：右肺下叶磨玻璃影。

【示例】（假设病历中有“糖尿病5年，HbA1c 7.0%”）
- 既往史：2型糖尿病5年（HbA1c 7.0%，血糖控制可）

【输出要求】
1. 症状需标注发生时间；
2. 既往史需包含疾病控制情况（如血糖、血压控制）；
3. 检验结果仅保留异常值（标注参考范围）。

Agent输出结果：

- 症状：2周前出现咳嗽、咳白色黏痰；1天前出现发热（最高38.5℃）、乏力；
- 既往史：2型糖尿病10年（HbA1c 8.5%，血糖控制不佳）；高血压5年；
- 检验结果：白细胞12×10⁹/L（参考范围4-10×10⁹/L）；CRP 40mg/L（参考范围<10mg/L）；
- 影像结果：右肺下叶磨玻璃影。

关键价值：将非结构化病历转化为“可直接用于推理的结构化上下文”，避免Agent“漏读”关键信息（如“血糖控制不佳”）。

步骤2：上下文融合——让Agent“记住”患者的“全部故事”

问题：传统AI只会用“当前输入的信息”推理，但临床决策需要融合“历史数据+实时数据+领域知识”——比如王建国的糖尿病史会影响肺炎的治疗方案（糖尿病患者更易并发真菌性肺炎，需避免使用广谱抗生素）。

上下文工程解法：分层上下文模型
我们将上下文分为3层，让Agent按“优先级”融合信息：

• 底层：患者基础上下文（长期不变）：年龄、性别、基础疾病（糖尿病、高血压）、药物过敏史；
• 中层：当前诊疗上下文（实时更新）：现病史、检验结果、影像结果；
• 上层：领域知识上下文（动态同步）：最新临床指南、专家共识。

融合逻辑示例：
当Agent分析王建国的病情时，会先调取底层上下文（糖尿病史、血糖控制不佳），再结合中层上下文（发热、白细胞升高、磨玻璃影），最后引用上层上下文（《2023版社区获得性肺炎诊疗指南》中“糖尿病患者肺炎需警惕真菌合并感染”的条款）。

示例Prompt（融合后）：

请根据以下上下文分析患者的可能诊断及治疗建议：

【底层上下文】
患者：王建国，男，68岁；2型糖尿病10年（HbA1c 8.5%，血糖控制不佳）；高血压5年；否认药物过敏史。

【中层上下文】
症状：2周前咳嗽、咳白痰；1天前发热（38.5℃）、乏力；
检验：白细胞12×10⁹/L（↑）、CRP 40mg/L（↑）；
影像：右肺下叶磨玻璃影。

【上层上下文】
《2023版社区获得性肺炎诊疗指南》第12条：“糖尿病患者合并肺炎时，需评估真菌性肺炎风险（如血糖控制不佳、长期使用抗生素），建议行真菌涂片、G试验（1,3-β-D-葡聚糖检测）。”

【要求】
1. 诊断需列出“可能性排序”及依据；
2. 治疗建议需结合患者基础疾病及指南要求；
3. 标注引用的上下文来源。

Agent输出结果：

### 可能诊断（按可能性排序）
1. 真菌性肺炎合并细菌性肺炎（高可能性）：
   - 依据：患者有糖尿病史（血糖控制不佳），符合指南中“真菌性肺炎高风险人群”；咳嗽2周伴发热、磨玻璃影（真菌性肺炎常见影像表现）；白细胞及CRP升高（提示细菌感染）。
2. 单纯细菌性肺炎（中可能性）：
   - 依据：发热、白细胞升高、磨玻璃影均符合细菌性肺炎表现，但未解释“咳嗽2周”的慢性病程。

### 治疗建议
1. 检查：立即行痰真菌涂片、G试验（引用上层上下文：指南第12条）；
2. 抗感染：暂不使用广谱抗生素（避免加重真菌繁殖），待真菌检查结果回报后调整；
3. 血糖控制：加强胰岛素治疗，目标HbA1c<7.0%（引用底层上下文：糖尿病史）。

关键价值：让Agent像人类医生一样“综合考虑所有相关信息”，避免“头痛医头、脚痛医脚”。

步骤3：上下文自适应——根据诊疗阶段“动态调信息”

问题：临床诊疗是“动态过程”——问诊阶段需要“症状信息”，诊断阶段需要“检验/影像信息”，治疗阶段需要“药物反应信息”。传统AI常“一股脑”输出所有信息，导致推理混乱。

上下文工程解法：阶段化上下文切换
我们根据临床诊疗流程（问诊→查体→辅助检查→诊断→治疗→随访），为Agent设计“上下文开关”——在不同阶段自动调取对应信息。

以“治疗阶段”为例：
当王建国开始治疗后，Agent需要切换到“治疗阶段上下文”，核心信息包括：

• 之前的诊断结果（真菌性肺炎合并细菌性肺炎）；
• 用药史（如使用氟康唑抗真菌、头孢曲松抗细菌）；
• 实时监测数据（如体温变化、血糖值、肝肾功能）；
• 患者反馈（如“咳嗽减轻，但出现恶心”）。

示例Prompt（治疗阶段）：

请根据以下治疗阶段上下文调整治疗方案：

【当前阶段】治疗第3天
【上下文】
- 诊断：真菌性肺炎合并细菌性肺炎（痰涂片找到念珠菌，G试验阳性）；
- 用药史：氟康唑（抗真菌）、头孢曲松（抗细菌）、胰岛素（控制血糖）；
- 实时数据：体温37.2℃（较前下降）、血糖10.1mmol/L（目标<7.8）、ALT 60U/L（参考范围7-40，↑）；
- 患者反馈：咳嗽减轻，但出现恶心、食欲下降。

【上层上下文】
《抗真菌药物临床应用指南》第8条：“氟康唑常见胃肠道不良反应（如恶心、食欲下降），可调整为餐后服用；ALT升高（<2倍正常上限）时，需密切监测肝功能。”

【要求】
1. 分析当前治疗效果及不良反应；
2. 调整治疗方案（需引用上下文）；
3. 给出下一步监测建议。

Agent输出结果：

### 治疗效果分析
- 有效：体温下降（38.5℃→37.2℃）、咳嗽减轻，提示抗感染治疗有效；
- 问题：血糖未达标（10.1mmol/L）、出现氟康唑不良反应（恶心、食欲下降）、ALT轻度升高（60U/L）。

### 调整方案
1. 氟康唑：改为餐后30分钟服用（引用上层上下文：指南第8条），缓解胃肠道反应；
2. 胰岛素：增加餐前短效胰岛素剂量（引用上下文：血糖10.1mmol/L未达标）；
3. 肝功能监测：每2天复查ALT（引用上层上下文：ALT轻度升高需密切监测）。

### 下一步监测
- 每天测量体温、血糖；
- 观察恶心症状是否缓解；
- 治疗1周后复查胸部CT、真菌涂片。

关键价值：让Agent“跟着诊疗流程走”，避免输出“过时或无关的信息”。

步骤4：上下文反馈——用医生的“质疑”优化Agent

问题：即使Agent融合了所有信息，也可能输出不符合临床习惯的建议（如“建议使用伏立康唑抗真菌”，但伏立康唑价格高，患者经济条件差）。此时需要用医生的反馈调整上下文。

上下文工程解法：反馈驱动的上下文更新
我们为Agent设计“反馈接口”——当医生修改或质疑Agent的建议时，Agent会：

1. 调取“被质疑的建议”对应的上下文；
2. 分析医生反馈的原因（如“价格太高”“不符合患者情况”）；
3. 更新上下文库（如添加“患者经济条件”信息）；
4. 重新生成建议。

示例场景：
医生看到Agent建议“使用伏立康唑抗真菌”后，反馈：“患者经济条件一般，伏立康唑太贵，有没有替代方案？”

Agent的处理流程：

• 步骤1：调取原上下文：原建议引用的是“《抗真菌药物临床应用指南》第10条：‘伏立康唑是念珠菌肺炎的一线药物’”；
• 步骤2：分析反馈原因：医生关注“药物经济性”，原上下文未包含“患者经济条件”；
• 步骤3：更新上下文：从EMR中调取“患者医保类型：城乡居民医保；月收入3000元”；
• 步骤4：重新生成建议：引用指南中“氟康唑（医保报销，价格较低）是念珠菌肺炎的备选药物”的条款。

示例Prompt（带反馈）：

医生反馈：“患者经济条件一般，伏立康唑太贵，有没有替代方案？”请结合以下新增上下文重新调整治疗建议：

【新增上下文】
患者医保类型：城乡居民医保；月收入3000元；氟康唑（医保报销，每盒50元）；伏立康唑（自费，每盒800元）。

【上层上下文】
《抗真菌药物临床应用指南》第10条：“念珠菌肺炎的一线药物为伏立康唑；若患者经济条件有限，可选用氟康唑（需监测药物浓度）。”

【要求】
1. 解释调整原因（引用新增上下文）；
2. 给出替代方案及注意事项。

Agent输出结果：

### 调整原因
患者经济条件一般（月收入3000元），伏立康唑（自费800元/盒）费用较高，而氟康唑（医保报销50元/盒）更符合患者经济情况（引用新增上下文）。

### 替代方案
将伏立康唑改为氟康唑（剂量：400mg/d，静脉滴注），需监测氟康唑血药浓度（目标：40-80mg/L）（引用上层上下文：指南第10条）。

### 注意事项
- 告知患者氟康唑的医保报销情况，缓解经济顾虑；
- 治疗1周后复查真菌涂片及血药浓度。

关键价值：让Agent“听医生的话”，从“单向输出”进化为“双向互动”。

步骤5：上下文安全——守住医疗AI的“红线”

问题：医疗数据涉及隐私（如患者姓名、身份证号），临床建议需符合法规（如《医疗质量管理办法》）。传统AI常“泄露隐私”或“输出违规建议”。

上下文工程解法：安全与合规的“双保险”
我们用两种Prompt机制守住“红线”：

• 隐私保护Prompt：强制Agent移除患者个人识别信息（PII）；
• 合规约束Prompt：强制Agent引用权威指南，避免“信口开河”。

示例隐私保护Prompt：

请在分析以下病历前，移除所有患者个人识别信息（姓名、身份证号、联系方式、住院号），仅保留医疗相关数据：

【原始病历】
患者：王建国，身份证号：1101011955XXXX1234，住院号：20230508001；
现病史：咳嗽2周，发热1天；
既往史：糖尿病10年。

Agent输出（去标识化后）：

患者：男，68岁；
现病史：咳嗽2周，发热1天；
既往史：2型糖尿病10年。

示例合规约束Prompt：

所有诊断及治疗建议必须符合以下规范：
1. 《中华人民共和国临床诊疗指南·内科分册》（2022版）；
2. 《抗菌药物临床应用指导原则》（2020版）；
3. 若建议超出上述规范，需标注“超指南建议”并说明理由。

关键价值：让Agent“合法合规”，避免医疗纠纷。

---

三、避坑：医疗上下文工程的4个常见问题及解决方案

在实战中，我们遇到过很多“踩坑”场景，以下是最常见的4个问题及解决技巧：

问题1：上下文过载——信息太多导致Agent“卡壳”

症状：当上下文包含“3年病历+10篇指南+5次检查结果”时，Agent的推理速度变慢，甚至输出“无关内容”。

解决方案：上下文压缩+权重排序

• 压缩：用“摘要Prompt”将长文本缩成关键信息（如“请将患者3年病历摘要为100字以内的核心内容，包括基础疾病、重大诊疗事件”）；
• 排序：用“权重Prompt”指定信息的重要性（如“在分析时，患者的药物过敏史优先级高于既往的感冒病史”）。

问题2：上下文偏差——Agent过度依赖某部分信息

症状：Agent只看“当前发热”的信息，忽略“糖尿病史”，导致建议错误。

解决方案：上下文平衡+交叉验证

• 平衡：用“强制融合Prompt”要求Agent必须结合多源信息（如“诊断时必须融合患者的基础疾病、现病史、检验结果”）；
• 验证：用“反问Prompt”让Agent自我检查（如“你是否考虑了患者的糖尿病史？如果没有，请补充”）。

问题3：上下文过时——指南更新了但Agent没用到

症状：Agent还在引用2020版指南，而2023版指南已经更新了治疗方案。

解决方案：实时同步+工具调用

• 同步：用“定时任务”每天更新知识图谱中的指南内容；
• 调用：用“工具Prompt”让Agent主动查询最新指南（如“请调用指南数据库，查询2023版《社区获得性肺炎诊疗指南》中关于糖尿病患者的治疗建议”）。

问题4：上下文不可追溯——医生不知道AI“凭什么”建议

症状：Agent输出“建议用氟康唑”，但医生不知道是“参考了哪条指南”或“用了哪部分患者数据”。

解决方案：透明化上下文

• 用“溯源Prompt”要求Agent标注建议的依据（如“建议用氟康唑，依据：患者经济条件（新增上下文）+《抗真菌药物临床应用指南》第10条（上层上下文）”）；
• 搭建“上下文溯源系统”，让医生点击建议就能查看对应的原始数据。

---

四、未来：医疗上下文工程的3个进化方向

随着技术的发展，医疗上下文工程将向更智能、更精准的方向进化：

1. 多模态上下文融合——从“文字”到“全感官”

未来，医疗Agent将能融合多模态数据（如影像、声音、病理切片）：

• 比如，Agent能“看”胸部CT影像（提取磨玻璃影、实变影等特征）、“听”患者的咳嗽声（判断是干咳还是湿咳）、“读”病理切片（识别癌细胞），并将这些信息与文字病历融合，生成更准确的建议。

2. 自监督上下文学习——Agent自己“找信息”

当前的上下文工程需要人工设计Prompt，未来Agent将能自监督学习：

• 比如，Agent从1000个糖尿病合并肺炎的病例中，自动学习“血糖控制不佳”与“真菌性肺炎”的关联，不需要人工标注；
• 当遇到新病例时，Agent能主动“找”类似的历史病例，调整上下文。

3. 跨机构上下文共享——打破“数据孤岛”

医疗数据分散在不同医院，未来通过联邦学习（Federated Learning）技术，Agent能在不泄露隐私的情况下，共享跨机构的上下文：

• 比如，A医院的Agent能学习B医院的“糖尿病合并肺炎”病例，B医院的Agent能学习A医院的“真菌感染”治疗经验，从而提升整体诊断 accuracy。

---

结语：医疗AI的“诗与远方”

回到文章开头的场景——当李医生再次使用优化后的Agent时，屏幕上的报告变成了：

“建议：1. 行痰真菌涂片、G试验（依据：患者糖尿病史+2023版指南）；2. 暂用氟康唑抗真菌（依据：患者经济条件+医保政策）；3. 加强血糖控制（依据：HbA1c 8.5%）。”

李医生笑着点头，把报告打印出来，递给患者：“按这个方案来，放心。”

这就是上下文工程的力量——它让医疗Agent从“会计算的机器”变成“会看病的助手”，让AI真正融入临床流程，成为医生的“左膀右臂”。

作为提示工程架构师，我始终相信：医疗AI的终极目标，不是“取代医生”，而是“让每个医生都有一个超级助手”——而上下文工程，正是通向这个目标的“桥梁”。

如果你也在做医疗AI，不妨从“优化一个病例的上下文”开始——或许，你就能改变一个患者的命运。

附录：医疗上下文工程工具清单

• 向量数据库：Pinecone、Chroma；
• Embedding模型：OpenAI text-embedding-3-small、阿里云通义千问Embedding；
• RAG框架：LangChain、LlamaIndex；
• 知识图谱：Neo4j（医疗版）、阿里医疗知识图谱；
• 隐私保护：AWS Comprehend Medical（去标识化）、百度文心医疗大模型（隐私过滤）。

延伸阅读

• 《Agentic AI in Healthcare: A Review》（Nature Biomedical Engineering）；
• 《Clinical Decision Support Systems Using Context-Aware Agents》（Journal of Medical Systems）；
• 《2023版社区获得性肺炎诊疗指南》（中华医学会呼吸病学分会）。

（全文完）
作者：张三，资深医疗AI提示工程架构师，曾参与3家三甲医院Agentic辅助诊断系统设计，专注于将提示工程与临床场景结合。
公众号：医疗AI进化论（定期分享医疗Agent实战技巧）。