PhysicianBench：在真实电子病历环境中评估大语言模型智能体 PhysicianBench: Evaluating LLM Agents in Real-World EHR Environments
首个基于真实电子病历与医生验证的长程临床智能体基准，揭示当前LLM在自主临床任务上最高仅46%成功率。
前置知识
大语言模型智能体（LLM Agent）
指在通用大语言模型基础上，通过工具调用、规划与多轮决策循环，自主完成多步骤任务的系统。智能体能在每一步根据当前观察选择下一步动作（通常是调用一个工具），并依据环境反馈调整策略。
PhysicianBench评估的对象正是LLM智能体而非单纯的问答模型，必须理解智能体的工具调用循环才能把握基准的设计逻辑。
电子病历（EHR）与FHIR标准
电子病历是医院中存储患者人口学、诊断、检验、用药、影像报告等结构化与半结构化数据的系统。FHIR（Fast Healthcare Interoperability Resources）是HL7制定的医疗数据交换标准，被Epic、Cerner等主流厂商采用，定义了Patient、Condition、Observation、MedicationRequest、ServiceRequest等资源类型。
本文的EHR环境完全基于FHIR R4实现，智能体必须通过FHIR API读写资源，任务的真实感正是来自这一生产级标准。
部分可观测马尔可夫决策过程（POMDP）
POMDP是序贯决策的数学框架，定义为 $(\mathcal{S}, \mathcal{A}, \mathcal{T}, \mathcal{O}, \Omega, I, C)$，其中智能体不能直接观测完整状态，只能依据不完整的观察与历史选择动作。
作者将每个临床任务形式化为POMDP，状态空间是完整EHR内容，观测空间是FHIR返回的JSON束，这一致性地建模了医生在真实系统中需要主动查询信息的工作方式。
电子会诊（e-Consult）
电子会诊是初级保健医生通过EHR异步向亚专科医生提交临床问题、附上完整病历，由亚专科医生返回书面评估、建议检查或转诊的工作模式。它体现了跨专科、跨时间的复杂临床推理流程。
PhysicianBench的100个任务全部来源于真实e-consult案例，这是它能捕捉长程临床工作流的关键。
Pass@1、Pass@3与Pass^3
Pass@1是单次尝试的任务完成率，反映实际部署性能；Pass@3使用无偏估计 $\text{pass@}k = 1 - \binom{n-c}{k}/\binom{n}{k}$ 衡量三次尝试中至少一次成功的概率；Pass^3是三次全部成功的概率，衡量一致性与可靠性。
三者从不同维度刻画智能体能力——最强模型GPT-5.5的Pass@1为46.3%，Pass^3仅28.0%，说明其表现具有显著随机性，这是临床部署中难以接受的。
研究动机
现有医疗AI基准存在三大根本缺陷。第一，MedQA、PubMedQA、MedMCQA等传统基准仅考察静态知识回忆，AgentClinic虽然引入了交互，但仍是诊断导向且不涉及真实EHR系统；MedAgentBench和FHIR-AgentBench虽然提供FHIR环境，但任务多是单步原子操作（取一个化验值或下一个医嘱），无法反映真实临床工作流。第二，HealthBench、MedHELM等基准只评估模型回复文本，不要求智能体在EHR中实际执行动作并验证环境状态变化，因此无法衡量"动作可执行性"。第三，多数基准的任务来自考试题或合成患者，缺乏真实临床案例的复杂共病模式和数据噪声，例如AgentEHR虽然做了长程推理，但未使用标准FHIR接口、也没有结构化动作执行。
本文的目标是本文旨在构建一个满足三项同时成立的医疗智能体基准：（1）长程多步任务，涵盖从信息检索、跨异构数据推理、临床动作执行到文档输出的完整临床工作流；（2）真实EHR环境，通过FHIR R4标准API与HAPI FHIR JPA服务器交互，并对动作产生的EHR状态变化进行可执行验证；（3）基于真实电子会诊案例并经独立医师小组多轮审核的临床保真度。基准由100个长程任务（平均27次工具调用）、670个细粒度检查点、14种FHIR工具组成，跨21个临床亚专科、4大类工作流（诊断解读、用药处方、治疗规划、检查与风险分层）。
与已有工作不同的是，PhysicianBench的独特切入角度是"真实环境+真实案例+可验证执行"的三位一体。它不是把已有基准的某一项维度推到极致，而是首次在医疗领域把长程任务、FHIR可执行性、临床医生独立审核三件事同时做齐。更关键的是其评测粒度不是简单的最终答案对错，而是把每个任务分解成6-7个临床有意义的检查点（数据检索→临床推理→动作执行→文档输出），并按能力类别归因失败原因，从而能精确定位"临床推理是主要瓶颈"这一关键发现——50.4%的失败集中在临床推理，而非工具使用或文档格式。
核心方法
PhysicianBench的方法思路可以理解为"真实环境+任务设计+评测协议"三部分。直觉上，它要回答的核心问题是：一个LLM智能体在真实医院的电子病历系统中，能像住院医师一样独立完成多步临床工作吗？技术路线上，作者首先将每个临床任务形式化为POMDP：状态是完整EHR内容、动作是14个结构化工具调用、观察是FHIR返回的JSON束；然后基于真实e-consult案例构建100个任务并经过11位临床医生多轮迭代审核；最后开发了一套基于检查点的评测体系——把任务拆成670个临床意义明确的子步骤（检查点），用代码评分器、混合评分器、LLM评判器三种机制分别评估智能体在EHR中是否真的写入了正确的资源、是否给出了正确的临床推理、是否产出了合规的文档。每个任务在独立的Docker容器中运行HAPI FHIR JPA服务器，确保可重复性。
PhysicianBench的核心创新在于把"任务分解为可验证的临床检查点"和"对EHR真实状态进行执行验证"。与MedAgentBench等已有基准只评估"动作意图"（如智能体是否说要开某药）不同，PhysicianBench要求智能体在FHIR服务器上真正创建MedicationRequest、ServiceRequest等资源，并通过查询post-execution状态来验证。第二个创新是引入了临床推理检查点（4个子类型：计算临床评分、解释合成数据、做出临床判断、应用临床标准），用混合评分器把FHIR数据计算出的客观真值与LLM从智能体自由文本中提取的答案对比，从而把主观的临床推理变成可量化指标。第三个创新是错误归因：失败检查点按数据检索/临床推理/动作执行/文档输出四个能力类别分布，这种结构化诊断让研究者能精确定位瓶颈。
方法步骤详情
任务构建包含四个步骤。第一步是任务源头筛选：从STARR（Stanford Research Repository）去标识化EHR数据库中筛选185个真实e-consult案例，要求每个案例至少涉及两个推理步骤且需要跨多个EHR数据源。第二步是患者数据扰动：结构化字段（化验值、生命体征）在临床合理范围内加均匀噪声；类别字段（诊断、用药）通过随机删除部分条目并插入临床合理但任务无关的值来防止智能体通过记录结构直接猜出目标条件；自由文本笔记使用Stanford SecureGPT改写以去除PHI并保留临床含义。第三步是任务实例化：每个任务包含（a）自然语言指令（角色、患者ID、日期、步骤、交付物）、（b）FHIR编码的患者记录（使用LOINC、SNOMED等标准术语）、（c）评估测试套件（检查点定义与评分逻辑）、（d）参考解法与审查清单。第四步是三轮医师审核：阶段1由领域专家按5个维度（指令清晰性、临床准确性、完整性、患者安全、EHR一致性）做结构化审查；阶段2由LLM智能体解析审查反馈生成结构化diff（带来源审查项、影响位置、修改前后文本、修改理由）；阶段3由医生在diff界面逐条批准或拒绝，被拒条目触发下一轮修订循环直至全部通过。评测时，每个任务在独立Docker容器中预加载患者数据运行HAPI FHIR JPA服务器，使用统一的OpenAI兼容函数调用接口，最多100步工具调用，启用推理强度为高、温度为默认值，运行3次独立试验以计算pass@1、pass@3、pass^3。
技术新颖性
本文的技术新颖性体现在评测协议设计上。第一个新颖之处是"检查点—评分器"两级分类体系：670个检查点按4类能力（数据检索/临床推理/动作执行/文档输出）做归因，按3种评分器（纯代码验证FHIR状态、混合验证计算真值+LLM提取、纯LLM评判带pass/partial/fail三档rubric）做执行，三者正交组合形成细粒度诊断能力。第二个新颖之处是FHIR原生执行验证：与EHRAgent用SQL翻译、FHIR-AgentBench只做检索评估不同，PhysicianBench要求智能体用标准FHIR POST接口真实创建MedicationRequest、ServiceRequest、Appointment、Communication等资源，评分器用FHIR GET接口读取任务时间戳之后的资源来验证——这等同于在沙箱中复现了真实EHR的下单流程。第三个新颖之处是端到端智能体框架的最小化设计：仅300行Python代码封装OpenAI兼容聊天补全API，避免使用LangChain、OpenAI Agents SDK等三方框架以保证不同模型的性能差异归因于模型本身而非脚手架；并集成了4种鲁棒性机制（工具错误处理、过长输出截断带恢复提示、循环检测、推理强度透传）以保证评测稳定。
实验结果
在12个模型上评测（10个闭源+2个开源）后出现三个核心发现。第一个发现是"巨大能力鸿沟"：GPT-5.5以46.3% pass@1领跑，比第二名Claude Opus 4.6（31.7%）高出14.6个百分点；最强开源模型DeepSeek V4-Pro为18.7%，已超过多个闭源模型（MiMo-v2.5-Pro 16.7%、Qwen3.6-Plus 13.7%、MiniMax M2.7 8.7%、Gemini Pro 3.1 6.0%、Grok-4.20 5.3%）；所有模型均显著低于可用阈值。第二个发现是"可靠性差"：即使最强的GPT-5.5，其Pass^3（三次独立运行全部成功）也仅28.0%，意味着近半数任务的成功完成是随机的；Claude Opus 4.6与4.7的Pass^3同为18.0%，弱模型如Grok-4.20、MiniMax M2.7低至1.0%——临床部署绝对无法接受这种不稳定性。第三个发现是"失败集中在临床推理"：所有模型的失败检查点中临床推理平均占50.4%，数据检索12.4%、动作执行18.8%、文档输出18.4%；GPT-5.5的推理失败占比最低（42.5%），其优势体现为更全面的rubric覆盖——对GPT-5.5 vs Claude Opus 4.6的细粒度根因分析显示，推理失败多为"不完整推理"（41%）和"差一点/细节遗漏"（33%），而非"错误结论"（仅0%），GPT-5.5在每个子组的绝对失败数都低于Claude Opus 4.6；GPT-5.5的领先本质上是行为一致性而非临床知识差距。专科分布上，GPT-5.5在内分泌（59.0%）、胃肠肝病（57.1%）、心血管（55.6%）最强，Claude家族在肾/泌尿（33.3%）领先；任务类型分布上，GPT-5.5在"检查与风险分层"上达54.9%，比Claude Opus 4.6的38.2%高出17个百分点。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 整体任务完成（100任务平均） | Pass@1 (%) | 46.3 (GPT-5.5), 31.7 (Claude Opus 4.6), 18.7 (DeepSeek V4-Pro) | MedAgentBench: 300个FHIR任务，单步原子操作为主，最高~73%但局限于检索/下单孤立步骤 | 首次报告长程组合任务的端到端成功率：GPT-5.5在跨21个专科的100个复合工作流上达到46.3%，揭示真实场景下能力远低于先前单步基准的表象 |
| Pass^3 可靠性（三次独立运行全部成功） | Pass^3 (%) | 28.0 (GPT-5.5), 18.0 (Claude Opus 4.6/4.7), 1.0 (Grok-4.20/MiniMax M2.7) | 传统单次pass@1评测无法捕捉的随机性维度 | Pass^3与Pass@1之间有显著落差：GPT-5.5的46.3%→28.0% (-18.3点)，弱模型近乎降至0，证明当前智能体的成功是偶然而非能力 |
| 按专科 - 内分泌 | Pass@1 (%) | 59.0 (GPT-5.5), 35.9 (Claude Opus 4.6) | 心血管: 55.6 vs 27.8；胃肠肝病: 57.1 vs 35.7；精神神经成瘾: 33.3 vs 27.1 | GPT-5.5在7/8专科组中领先，仅在肾/泌尿以29.2% vs Claude 33.3%落后 |
| 按任务类型 - 治疗规划 | Pass@1 (%) | 40.7 (GPT-5.5), 21.0 (Claude Opus 4.6), 23.5 (GPT-5.4) | 诊断解读: GPT-5.5 46.2% / Claude Opus 4.6 43.6%；检查与风险分层: 54.9% / 38.2% | 治疗规划是公认最难类型——开放性多步决策；GPT-5.5相对Claude Opus 4.6的领先在治疗规划上达19.7个百分点，是其最大优势所在 |
| 失败归因 - 临床推理失败占比 | % of failed checkpoints | 42.5 (GPT-5.5), 50.4 (Claude Opus 4.6), 58.3 (DeepSeek V4-Pro), 54.4 (Grok-4.20) | 数据检索12.4%、动作执行18.8%、文档输出18.4%（全体平均） | GPT-5.5把临床推理失败占比压到最低，体现其优势更多源自行为一致性而非临床知识 |
局限与改进
作者明确指出的局限包括：基准仅覆盖e-consult风格的EHR中介任务，未触及住院、出院摘要、用药管理等工作流；评测的是自主执行而非医生-AI协作下的交互；缺乏多模态输入（影像、心电图波形）和外部知识库（PubMed、RxNorm）。作者独立观察到的局限还包括：100个任务的规模相对有限，且高度依赖单一机构（Stanford Health Care）的患者群体，泛化性需要跨机构验证；患者数据虽经扰动但仍保留STARR的共病模式分布，跨人群适用性未测；GPT-5.5的绝对成功率为46.3%但pass^3仅28%，这意味着任何依赖其可靠性的临床场景（如自动开药）都不安全；评测仅评估智能体在EHR中动作的最终状态，不评估动作之间的中间决策是否合理——例如附录G的失败轨迹显示Claude Opus 4.6把继发性肾上腺功能不全误判为原发性Addison病，导致开错了氟氢可的松；评分器中的LLM-judge虽然有结构化rubric，但本质仍依赖大模型判断，存在评分方差；最大100步的工具调用限制可能截断需要更细致探查的复杂任务。
独立分析的弱点
基于独立分析，我观察到以下弱点并提出改进方向。第一，任务类型分布偏检查与风险分层（34%），治疗规划虽最难但样本仅27例，未来应扩充到200-300任务以获得更稳定的专科×任务类型交叉分析。第二，670个检查点的评分中，LLM-judge占比不低，存在评分方差（同一轨迹多次评估可能给出不同结果），未来可采用多模型投票或训练专用reward model来降低方差。第三，14个工具的接口设计偏向生产FHIR的read/write，对临床决策支持类工具（如计算CHA2DS2-VASc的工具型API）缺位，智能体被迫用文本推理完成多步计算——改进方向是引入专用计算工具，把医生常用的临床计算器封装为确定性FHIR端点。第四，基准未测量智能体的"反悔能力"——当智能体发现错误时能否回滚已写入的FHIR资源，这是真实临床安全的关键。第五，评测的是开卷场景（智能体可以反复查询EHR），但没有测量闭卷场景（仅给定一次完整记录后作答），后者更接近考试场景而前者更接近真实工作。第六，附录G展示的失败轨迹显示Claude Opus 4.6把继发性肾上腺功能不全误判为原发性，这是一个有真实伤害的错误，基准应增设"安全关键检查点"——若该检查点失败则任务直接判零分，无论其他步骤如何。
未来方向
作者明确提出的未来方向有三个：（i）扩展到出院摘要、住院用药管理等住院场景；（ii）从自主执行扩展到与模拟医生/患者的协作交互与共同决策；（iii）引入多模态输入（影像、波形）和外部知识库。基于研究结果，我建议补充几个方向：第一，建立"临床安全红线"任务集，专门覆盖常见高风险错误（药物过敏、剂量过大、禁忌症遗漏），用作安全子基准；第二，把pass^3作为基准的官方排名指标而非仅做参考，因为临床部署关心的是可靠性而非峰值性能；第三，引入"工具失败注入"鲁棒性测试——故意让FHIR接口返回超时或部分错误，评估智能体的恢复能力；第四，构建"反事实轨迹"评测：给定部分正确的轨迹，让智能体识别并修正错误，这更接近真实医生工作；第五，将评分器中的LLM-judge部分替换为基于临床指南的形式化验证器（如CDC疫苗指南的决策表），进一步提升评分客观性。
复现评估
PhysicianBench的可复现性较高。代码与数据完全开源：基准网站healthrex.github.io/PhysicianBench托管了完整环境、智能体框架与评测harness；任务实例以自包含Docker镜像形式分发，每个任务预装HAPI FHIR JPA服务器和持久化H2数据库，消除了运行时数据摄入的不确定性。算力需求适中：单任务用HAPI FHIR JPA运行在Docker中，12个模型×100任务×3轮=3600次试验，每轮推理时间取决于模型（GPT-5.5平均41.9步/任务、Claude Opus 4.7仅16.2步），整体可在几天内完成。复现难度中等偏低：环境配置只需Docker，无需GPU（HAPI FHIR JPA是Java应用，依赖CPU），评分器基于标准FHIR API无需定制；唯一挑战是商业模型API的可访问性和成本（12个模型中10个是闭源API），开源模型DeepSeek V4-Pro和Kimi-K2.6可本地部署但需要显著GPU资源。需要注意的潜在风险是LLM-judge评分器的版本依赖——如果使用不同版本的judge模型，分数可能有差异，作者建议锁定评审模型版本。
论文图表
