MedAgentBench — 虚拟 EHR 环境下的医学 LLM 智能体评测基准

INFOBOX — MedAgentBench 一屏速览

维度	内容
本质	医疗 LLM 智能体的交互式评测基准（非静态问答集）——任务 + FHIR 环境 + 评分代码三件套
团队	Stanford University（Stanford ML Group + 临床信息学），8 作者，Andrew Y. Ng / James Zou / Jonathan H. Chen 在列
论文	NEJM AI 2025;2(9):AIdbp2500144（doi:10.1056/AIdbp2500144，2025-08-14）；预印本 arXiv:2501.14654（v1 2025-01-24 / v2 2025-02-12）
任务	300 个医生撰写任务，10 类别（归 7 宽泛类），150 query + 150 action，easy/medium/hard 三档
环境	FHIR-compliant 交互式虚拟 EHR；基于开源 HAPI FHIR JPA + 持久化 H2 数据库
数据	100 例去标识化患者；785,207 条记录（Observation 563,426 / Procedure 124,969 / Condition 74,821 / MedicationRequest 21,991）；近 5 年，截止 2018-11-13
来源	Stanford 临床数据仓库 STARR（患者级时间戳 jitter）
函数	智能体仅暴露 9 个 FHIR 函数（condition/lab/vital/medicationrequest/procedure 的 search+create 与 patient.search）
交互	每轮 3 种动作（GET / POST / finish），最多 8 轮
指标	任务成功率 SR，仅 pass@1；细分 Query SR / Action SR + 三档难度
最好成绩	Claude 3.5 Sonnet v2 = 69.67%（对标 v1 口径 GPT-4o 72%）
关键发现	基准未饱和；类别间差异显著；模型规模≠能力（7B Mistral 4% vs 685B DeepSeek 62.67%）；错误集中在指令遵循与答案格式
获取	代码 MIT（GitHub 公开）｜环境 Docker（jyxsu6/medagentbench）｜refsol.py 走 Box 链接｜研究用途
库内互链	chestagentbench（rid=816）、chimera-agent（rid=933）、medcalc-bench（rid=708）、xmedbench（rid=727）、MultiMedBench（rid=129）

MedAgentBench 是一个"把医学 AI 评测从考场搬进诊室"的基准：它不再问模型"这道题选什么"，而是给模型一个可以读、可以写的虚拟电子病历系统（EHR），丢给它一句"帮这位患者查一下最近的血钾并开一个复测医嘱"，然后数它到底做对了几步。300 个由内科医生亲手写的任务、100 例真实去标识化患者、78 万余条 FHIR 记录、9 个可直接调用的 API——在这套设置下，2025 年初的 12 个最强 LLM 中最好的一个（Claude 3.5 Sonnet v2）也只拿到 69.67 分。这个"没满分"的分数正是它的价值：它告诉整个行业，模型会背医学知识，却还不一定会用医疗系统。

导语读法三则：

1. 只想跑起来：直奔 §6 获取与部署——Docker 拉镜像 + 下载 refsol.py + 配 API key 三步即可复现，注意是研究用途。
2. 关心结果：直奔 §5 评测结果——表 3 全表、Query/Action 反差、难度分层与错误模式四段连读。
3. 做智能体/基准对照：直奔 §8 与 §9——与库内 chestagentbench、chimera-agent 等条目的差异化定位。

---

§0 导读：这个数据集解决什么问题

0.1 一句话定位

MedAgentBench 是医学领域第一个标准化的 LLM 智能体（agent）基准：它提供一个类真实电子病历环境，让大模型像执行任务的助手那样去检索信息、填写记录、下达医嘱，并以"任务是否完成"而非"答案是否匹配"来打分。

0.2 它要解决的三个痛点

痛点一：医疗 AI 基准停在"开卷考试"阶段。 传统医学基准（如 MedQA、MedMCQA）以选择题形式考察医学知识，最强模型早已"超人类"（superhuman performance），基准饱和后无法分辨模型能力高低。而真实临床工作的难点不在"知不知道"，而在"会不会操作"——从系统里检索、跨字段聚合、按规范下医嘱。

痛点二：通用智能体基准不认医疗。 通用 agent 基准（AgentBench、AgentBoard、BFCL、tau-bench）面向网页、工具、API 等场景，无法反映医疗数据的特殊性：多套编码系统（LOINC/CPT/ICD10/NDC/SNOMED）、临床缩写、纵向病历、极高的容错门槛。

痛点三：缺基准就缺信任，缺信任就难落地。 医疗高度受监管，安全是部署前提；没有标准化评测，AI agent 进入临床工作流（术前风险评估、预约调度、合规监测、临床分诊、医保预授权）就缺少可比较的能力证据。

0.3 它给出的解法

MedAgentBench 把"临床工作流"抽象为任务 + 环境 + 动作三要素：

• 任务：300 个医生撰写的、患者特异的临床任务；
• 环境：一个符合 FHIR 标准的交互式虚拟 EHR（现代 EMR 用同一套 API 与通信基础设施），因此可迁移到真实 EMR；
• 动作：智能体每轮只能三选一——GET（读）、POST（写）、finish（交答卷），最多 8 轮。

评测方式严格对齐临床的低容错特性：只跑一次（pass@1），做对记成功，做错记失败，不给你"多试几次碰运气"的机会。

0.4 一句话记住它

MedAgentBench = 医疗版的"智能体驾照考场"：路考（多轮交互）而非笔试（静态问答），一次不过就得重考（pass@1），而且考的是真病历（100 例）。

---

§1 数据集速览：十问十答

#	问题	回答
1	它是什么？	医疗 LLM 智能体评测基准，含 300 任务 + FHIR 环境 + 代码库
2	谁做的？	Stanford University（Stanford ML Group + 临床信息学）；8 作者
3	论文发在哪？	NEJM AI 2025;2(9):AIdbp2500144（正式版）；预印本 arXiv:2501.14654
4	有多少任务？	300 个（150 query + 150 action；10 类别；easy/medium/hard）
5	有多少患者？	100 例去标识化患者，785,207 条记录，近 5 年
6	数据从哪来？	Stanford 临床数据仓库 STARR，患者级时间戳 jitter
7	智能体能调几个函数？	9 个 FHIR 函数；每轮 GET/POST/finish；最多 8 轮
8	怎么打分？	任务成功率 SR，仅 pass@1；细分 Query SR / Action SR
9	最好成绩多少？	Claude 3.5 Sonnet v2 = 69.67%（12 个模型全表见 §5）
10	怎么获取？	代码 MIT（GitHub）；环境 Docker（jyxsu6/medagentbench）；研究用途

1.1 三句话讲清它的独特性

1. 它是"动作基准"不是"知识基准"：考的是规划、工具调用、迭代纠错，而非医学常识记忆。
2. 它是"环境基准"不是"文件基准"：数据不是躺在硬盘上的静态文件，而是一个可以交互的 FHIR 服务器。
3. 它是"未饱和基准"：最好成绩不到七成，给社区留出明确的优化方向，而不是一个已经刷满的榜单。

1.2 谁该关心它

• 医疗 AI 智能体开发者：需要一个可复现、可比较的能力评测场。
• LLM function calling 研究者：9 个函数、8 轮上限，是研究工具调用可靠性的干净设置。
• 临床信息学团队：想评估 agent 迁移进真实 EMR 的可行性与风险。
• 基准方法论研究者：研究"交互式评测 vs 静态评测"的差异与设计取舍。

1.3 谁可能不需要它

• 只想做医学知识问答：用 MedQA/MedMCQA 更直接。
• 需要大规模、多机构、多病种数据：它只有 100 例、单一机构、截止 2018 年。
• 需要外科/操作类任务：它刻意排除了这类干预。

---

§2 数据构成与规格

2.1 规模、来源与机构构成

MedAgentBench 的数据本体是一个虚拟 EHR 环境，其内容源自 Stanford 的去标识化临床数据仓库 STARR（STAnford Research Repository）：

• 患者规模：100 例去标识化真实患者（unique individuals = 100）
• 人口学：平均年龄 58.15 ± 19.82 岁；女性占比 47%
• 总记录数：785,207 条（论文摘要口径为 “over 700,000 data elements”，两者相容——785,207 > 700,000）
• 时间跨度：近 5 年病历，截止日期 2018-11-13
• 隐私处理：时间戳在患者级做 jitter（扰动），以降低时间关联带来的再识别风险

记录类型分解（官方项目页 Table 1）：

记录类型	FHIR 资源	数量
检验结果 + 生命体征	Observation	563,426
医嘱/操作	Procedure	124,969
诊断	Condition	74,821
用药医嘱	MedicationRequest	21,991
合计	—	785,207

（四类之和恰为总数，说明这是完整的记录构成，而非抽样。）

2.2 编码体系与术语标准

数据使用现代临床系统的标准编码，这是它"可直接迁移进真实 EMR"的技术基础：

• NDC（National Drug Code）——药品
• LOINC（Logical Observation Identifiers Names and Codes）——检验与观测
• CPT（Current Procedural Terminology）——操作
• ICD10（International Classification of Diseases, 10th revision）——诊断
• SNOMED（Systematized Nomenclature of Medicine）——临床术语

多编码并存正是医疗数据区别于通用文本的"特殊性"之一，也是考察智能体能否正确理解字段语义的关键。

2.3 环境技术栈：FHIR + HAPI + H2

• FHIR（Fast Healthcare Interoperability Resources）：环境遵循的互操作标准，使用现代 EMR 的标准 API 与通信基础设施。
• HAPI FHIR JPA：实现该环境所用的开源服务器（README/论文口径）。
• 持久化 H2 数据库：服务器配置使用 H2 作持久存储。
• 容器化交付：整套环境打包为 Docker 镜像 jyxsu6/medagentbench:latest，docker run -p 8080:8080 后可通过 http://localhost:8080/ 访问 FHIR server 控制台。

遗留疑点（见 §9）：论文未明确给出 FHIR 的具体版本号（如 R4 / STU3），仅说明"FHIR-compliant"。检索者若需精确版本，应核对 GitHub 配置或 Docker 镜像内的实现。

2.4 数据为何"够真"又"够安全"

MedAgentBench 的巧妙之处在于两头兼顾：

• 够真：源自真实临床数据仓库，记录类型、编码体系、时间纵向结构都来自实际 EMR 生态。
• 够安全：全量去标识化 + 患者级时间戳 jitter，患者身份被剥离，任务在虚拟环境内执行不触碰任何真实系统。

这使它既是"现实主义的"（realistic），又是"可安全试错的"（safe to experiment）。

2.5 与通用医学问答基准的边界

维度	传统医学 QA 基准（MedQA 等）	MedAgentBench
载体	静态题目文本	可交互 FHIR 环境
考察	知识记忆与推理	规划 + 工具调用 + 执行
答案	选项匹配	任务完成判定
交互	单轮	多轮（≤8 轮）
饱和度	已饱和/超人类	未饱和（best 69.67%）

边界声明：MedAgentBench 不是要取代知识型基准，而是补上"agent 能力"这一层——它假定模型已具备基础医学知识，考察的是"知识之上会不会用系统"。

2.6 数据规模在库内同类中的位置

在千方病案医数集收录的医疗智能体/评测基准中，MedAgentBench 的规模特征鲜明：患者数不多（100），但交互深度（多轮工具调用）与环境真实性（FHIR 服务化）是它的差异化核心——它不是"更大的数据集"，而是"更接近部署现场的评测场"。

---

§3 任务体系：300 个任务如何考智能体

3.1 任务的来源与撰写

• 撰写者：2 名内科医生（internal medicine physicians） 亲手编写。
• 性质：患者特异的临床任务（patient-specific clinically-derived tasks）。
• 总数：300 个。
• 设计原则：反映住院与门诊两类设置中"本可由 agent 自动化"的常见场景，刻意排除外科或操作类干预——因为那超出了 LLM agent 的能力边界。

3.2 任务类别：10 具体类 → 7 宽泛类

论文说明 300 个任务"来自 10 个类别（10 categories）"，这 10 个具体类别可归并为 7 个宽泛类别（broad categories）：

7 个宽泛类别（论文表 1 明列）：

1. Patient Information Retrieval（患者信息检索）
2. Lab Result Retrieval（检验结果检索）
3. Patient Data Aggregation（患者数据聚合）
4. Recording Patient Data（记录患者数据）
5. Test Ordering（检验/检查开单）
6. Referral Ordering（转诊开单）
7. Medication Ordering（用药开单）

任务描述中一并提及的功能范围（构成 10 个具体类别的来源）：

patient communication、patient information retrieval、recording patient data、test ordering、documentation、referral ordering、medication ordering、patient data aggregation and analysis 等。

遗留疑点：论文未逐条给出 10 个具体类别的完整权威名称，也未给出每个类别的任务计数。检索者若需精确分类，应参考 GitHub 仓库的任务定义文件。

3.3 两类任务：Query vs Action（各占一半）

论文明确指出：

“Among the 300 tasks in MedAgentBench, half (150) only require information retrieval via GET requests, while the other half require the modification of medical records through POST requests.”

任务类型	数量	动作	语义
Query 任务	150	GET	只读检索（不改动病历）
Action 任务	150	POST	写入/修改病历（如开单）

这一"读写对半"的设计极为关键：它把智能体能力切成"能不能查对"和"能不能写对"两个独立维度，直接暴露模型在写操作上的短板（见 §5.3）。

3.4 三档难度：步数即难度

论文把任务按所需步数分档：

• easy：只需 1 步（如一次 GET 即得答案）
• medium：需 2 步
• hard：需 至少 3 步（多轮规划、聚合或多函数组合）

难度以"步数"而非"知识难度"定义，这与 agent 评测的本质一致——难点在于多步规划与状态维护，而非医学知识。

3.5 智能体可用的 9 个函数

智能体被暴露的 FHIR 函数是精选的 9 个（论文原文逐字）：

condition.search, lab.search, vital.search, vital.create, medicationrequest.search, medicationrequest.create, procedure.search, procedure.create, patient.search

按资源归类：

FHIR 资源	search（读）	create（写）
Condition（诊断）	✔	—
Lab（检验）	✔	—
Vital（生命体征）	✔	✔
MedicationRequest（用药）	✔	✔
Procedure（操作）	✔	✔
Patient（患者）	✔	—

观察：写函数（create）仅覆盖 vital / medicationrequest / procedure 三类，与"写医嘱"的临床动作对应；读函数覆盖全部六类。函数以 JSON schema 定义，由 FHIR API 文档手工翻译而来。

3.6 交互协议：三种动作 + 八轮上限

智能体每轮必须从三种动作中选一种：

• GET：格式 GET url?param_name1=param_value1&param_name2=param_value2...
• POST：格式 POST url + JSON payload
• finish：格式 finish([answer1, answer2, ...])——交答卷，任务结束

硬约束：交互最多 8 轮（maximum of 8 rounds）。这一上限同时考察"效率"（别浪费轮次）与"正确性"（在有限步内完成）。

3.7 评测流程骨架

① 医生任务（自然语言指令 + 患者标识）
        ↓
② agent orchestrator（LLM）解释指令、规划函数调用
        ↓
③ 通过 FHIR server（HAPI FHIR JPA + H2）执行 GET / POST
        ↓
④ 最多 8 轮迭代（读→想→写→再读…）
        ↓
⑤ finish([...]) 提交答案
        ↓
⑥ 与参考解（refsol）比对 → 判定成功/失败（pass@1）

关键节点：判定依赖由 Stanford 经 Box 链接发放的参考解 refsol.py——即"标准答案的实际操作序列/期望终态"。

3.8 任务设计的三条方法论启示

1. 以环境而非题目为载体：任务嵌入可写环境，才能考察"副作用"（是否写错病历）。
2. 以步数定义难度：难度与规划复杂度挂钩，而非知识难度，契合 agent 本质。
3. 读写对半、刻意留白：150/150 的均衡设计与排除外科干预，是为了给出可解释的能力画像，而非堆砌难题。

---

§4 论文、时间线与口径存照

4.1 三条发育线：从预印本到正式发表

MedAgentBench 有明确的版本链，不同阶段的口径存在差异，检索者必须分清：

阶段	载体	时间	关键口径
v1	arXiv:2501.14654v1	2025-01-24	摘要称 100 tasks；best = GPT-4o 72%
v2	arXiv:2501.14654v2	2025-02-12	摘要称 300 tasks；best = Claude 3.5 Sonnet v2 69.67%
正式版	NEJM AI 2025;2(9):AIdbp2500144	2025-08-14	300 tasks；best = Claude 3.5 Sonnet v2 69.67%

本条目以正式版（300 任务 / Claude 3.5 Sonnet v2 69.67%）为准；v1 的 100 任务 / GPT-4o 72% 为早期预印本口径，仅作存照。

4.2 双口径冲突逐条存照

冲突一：任务数（100 vs 300）。

• arXiv 搜索结果所见的 v1 摘要/早期 PDF写 “100 patient-specific clinically-derived tasks”。
• v2 摘要、官方项目页、NEJM AI 正式版一致写 300 tasks。
• 判定：以 300 为准。v1 的 100 是早期版本口径，可能为基准构建早期规模。

冲突二：最佳模型与分数（GPT-4o 72% vs Claude 3.5 Sonnet v2 69.67%）。

• 早期口径：best model GPT-4o，72%。
• v2/正式口径：best model Claude 3.5 Sonnet v2，69.67%。
• 判定：以 Claude 3.5 Sonnet v2 = 69.67% 为准。两者对应不同模型评测轮次（v2 补测了更新模型并对 Claude 给出了更高分）。

冲突三：评测模型数量（11 vs 12）。

• NEJM AI 正文称 “evaluate 12 state-of-the-art LLMs”。
• 表 3 标题却写 “11 state-of-the-art LLMs”。
• 表 3 实际列出 12 行（Claude 3.5 Sonnet v2 … Mistral v0.3 7B）。
• 判定：以表列 12 行为准；“11” 疑为表标题笔误。

冲突四：数据点数（over 700,000 vs 785,207）。

• 论文摘要：over 700,000 data elements。
• 官方项目页 Table 1：785,207 条记录。
• 判定：两者相容（785,207 > 700,000）；正文用精确值 785,207，并注明摘要的约数口径。

4.3 作者与资助

• 作者（8 人）：Yixing Jiang*、Kameron C. Black*（共同一作）、Gloria Geng、Danny Park、James Zou、Andrew Y. Ng、Jonathan H. Chen
• 机构：Stanford University
• 资助：NIH 与 Singapore’s National Science Scholarship（PhD）
• ORCID（7 人公开）：Jiang 0000-0002-3569-014X / Black 0000-0002-3696-4050 / Geng 0009-0005-7869-4000 / Park 0000-0001-6373-005X / Zou 0000-0001-8880-4764 / Ng 0000-0001-5547-3196 / Chen 0000-0002-4387-8740

4.4 学术谱系：站在 AgentBench 肩上

README 明确：该仓库 “built on top of AgentBench”。这意味着 MedAgentBench 复用了 AgentBench 的任务-工作者-控制器（task worker / controller）架构（20 个 task_worker、端口 5000-5015、assigner 分配任务），把通用 agent 评测的工程骨架"嫁接"到医疗场景。这是它工程上能快速落地的重要原因。

论文同时对照了多家通用/医疗 agent 基准，以说明空白：

• 通用 agent：AgentBench、AgentBoard、BFCL、tau-bench
• 医疗相关：AgentClinic、CRAFT-MD
• 知识型（已饱和）：MedQA、MedMCQA

4.5 读数字的四条守则（统计卫生）

1. 看清版本：v1 与 v2/正式版的任务数、最优模型都不同——引用必须标明版本。
2. 区分"摘要约数"与"表格精确值"：700,000+ 是约数，785,207 是精确值，别混用。
3. 注意 pass@1 方差：单次尝试的成功率对随机性敏感，模型排名差异需谨慎解读（论文未给置信区间）。
4. 警惕模型数口径：以表 3 实列 12 行为准，“11” 为标题笔误。

---

§5 评测结果：12 个前沿模型的能力画像

5.1 评测方法学

• 主指标：任务成功率 Success Rate (SR)
• 尝试次数：仅 pass@1——每个任务只给模型一次机会。论文解释此设计"反映临床环境对错误的低容忍度"，逼迫开发者优先追求可靠性而非多次侥幸。
• 细分维度：
  • Query SR（150 个只读任务的子组成功率）
  • Action SR（150 个写操作任务的子组成功率）
  • Easy / Medium / Hard SR（三档难度）
• 任务类型对比：query-based（GET）vs action-based（POST）

5.2 主结果表（表 3，v2 逐字）

模型	Size	Form	Overall SR	Query SR	Action SR
Claude 3.5 Sonnet v2	N/A	API	69.67%	85.33%	54.00%
GPT-4o	N/A	API	64.00%	72.00%	56.00%
DeepSeek-V3	685B	open	62.67%	70.67%	54.67%
Gemini-1.5 Pro	N/A	API	62.00%	52.67%	71.33%
GPT-4o-mini	N/A	API	56.33%	59.33%	53.33%
o3-mini	N/A	API	51.67%	54.67%	48.67%
Qwen2.5	72B	open	51.33%	38.67%	64.00%
Llama 3.3	70B	open	46.33%	50.00%	42.67%
Gemini 2.0 Flash	N/A	API	38.33%	34.00%	42.67%
Gemma2	27B	open	19.33%	38.67%	0.00%
Gemini 2.0 Pro	N/A	API	18.00%	25.33%	10.67%
Mistral v0.3	7B	open	4.00%	8.00%	0.00%

5.3 Query vs Action：写比读难得多

从上表可读出一条清晰规律——多数模型"读"得比"写"好：

• Claude 3.5 Sonnet v2：Query 85.33% vs Action 54.00%（差 31.33 个百分点）
• GPT-4o：Query 72.00% vs Action 56.00%
• GPT-4o-mini：Query 59.33% vs Action 53.33%

例外：Gemini-1.5 Pro 反其道而行——Query 52.67% 却 Action 71.33%，是表里 Action 最高的模型。这说明**"读"与"写"是两种相对独立的能力**，不能用一个总分数概括一个模型的 agent 能力。

临床含义：写操作直接改变病历（开错医嘱、写错生命体征后果严重），而这恰恰是模型最弱的一环——这正是 MedAgentBench 最有价值的警示。

5.4 难度分层：Hard 是真正的天花板（表 4 摘要）

模型	Overall SR	Easy SR	Medium SR	Hard SR
Claude 3.5 Sonnet v2	69.67%	100.00%	81.67%	23.33%
GPT-4o	64.00%	86.67%	70.00%	33.33%
DeepSeek-V3	62.67%	93.33%	68.33%	24.44%
Gemini-1.5 Pro	62.00%	82.22%	45.83%	63.33%
GPT-4o-mini	56.33%	91.11%	55.83%	22.22%
o3-mini	51.67%	67.78%	65.00%	17.78%
Qwen2.5	51.33%	72.22%	44.17%	40.00%
Llama 3.3	46.33%	56.67%	38.33%	46.67%
Gemini 2.0 Flash	38.33%	98.89%	17.50%	5.56%
Gemma2	19.33%	33.33%	23.33%	0.00%
Gemini 2.0 Pro	18.00%	27.78%	14.17%	13.33%
Mistral v0.3	4.00%	13.33%	0.00%	0.00%

读表要点：

• Claude 3.5 Sonnet v2 在 Easy（100%）与 Medium（81.67%）上全面领先，但 Hard 掉到 23.33%——单步/两步任务近乎满分，多步任务却不及三成。
• Gemini-1.5 Pro 的 Hard SR 反常地高达 63.33%（全表最高），却整体只有 62%——说明它的能力分布与主流模型不同。
• Gemini 2.0 Flash 呈现"断崖"：Easy 高达 98.89%，Medium 骤降至 17.50%，Hard 仅 5.56%——典型的"简单题满分、稍微复杂就崩"。
• Mistral v0.3 7B 几乎全线失败（Overall 4%），Small 模型在 agent 任务上仍不可用。

核心结论：Hard（≥3 步）任务是最强模型的真天花板——即使最好的模型也只有约 1/4 的成功率，这是"未饱和"最直接的证据。

5.5 规模不等于能力

表里最反直觉的一行：

• DeepSeek-V3（685B）：Overall 62.67%
• Mistral v0.3（7B）：Overall 4.00%

参数量相差近百倍，能力天壤之别——这本不意外。但更值得注意的是：

• Qwen2.5（72B） 51.33% < Claude 3.5 Sonnet v2（未知规模） 69.67%
• Llama 3.3（70B） 46.33% < 多个更小的 API 模型

结论：agent 能力由训练方法、工具调用对齐、指令遵循质量等综合决定，模型规模不是充分条件。这对"堆参数就能做医疗 agent"的直觉是一记反驳。

5.6 错误模式分析

论文对失败轨迹做了归类，指出两类主要错误模式（逐字引用原文）：

模式一：未严格遵循指令（does not follow the instruction exactly）

“Gemini 2.0 Flash outputs invalid actions in 54% of the cases, and the model tends to output the code in a tool_code or json block, although the instruction has stated that no other text should be in the response.”

即模型收到"只输出动作、不要多余文本"的指令，却仍输出包裹在 tool_code/json 块里的代码 → 动作无效。

模式二：答案格式错误（incorrect answer format）

“the model tends to give the answer in a full sentence, while it is expected to output only a numerical value.”

具体例：期望 [5.4]，模型却输出 ["value": 5.4]（原文如此，疑应为 {"value": 5.4}）——数值本身对了，但因为包了壳而判错。

方法学含义：这两类错误不是"不懂医学"，而是**“不守接口规范”。这意味着：(1) 提升 agent 能力的短期抓手可能在格式约束/输出解析**，而非医学知识；(2) 评测的严格性会把"能力够但格式错"的模型判为失败，这是一种有意的严格（贴合临床对精确性的要求）。

5.7 论文给出的三段成功/失败轨迹（图 2）

论文图 2 展示了三种典型轨迹：

• (a) 成功：检索患者 MRN → 正确调用 FINISH；
• (b) 无效操作：GET 请求格式错误；
• © 答案格式错误：返回文本而非结构化输出。

这三段轨迹为 §5.6 的两类错误提供了可视化证据，也是理解"什么算对、什么算错"的最佳教材。

5.8 与其他基准的饱和度对照

判断一个基准"是否有用"，关键看它是否未饱和。MedAgentBench 的定位正是"从饱和的知识基准中走出来"：

基准	类型	典型最好成绩	是否饱和
MedQA	知识问答	已超人类	饱和
MedMCQA	知识问答	已超人类	饱和
MedAgentBench	agent 交互	69.67%	未饱和

结论：饱和基准无法再区分模型强弱，而未饱和基准（best < 70%）能给社区提供"还有多少路要走"的明确信号——这正是 MedAgentBench 被设计成"交互式、多步、pass@1"的直接目的。

5.9 结果对行业的信号

1. 未饱和 = 有方向：best 69.67%，社区有明确的优化空间，而非一个刷满的死榜。
2. 读写分离暴露真短板：写操作是瓶颈，而它恰是临床风险最高的动作。
3. 多步规划是天花板：Hard 任务 ≈ 23-63%，多步 agent 能力远未成熟。
4. 格式遵循是隐形门槛：大量失败源于接口规范而非知识，提示工程与解析层仍有红利。
5. 规模神话破产：参数量不是 agent 能力的决定因素。

---

§6 获取与部署：怎么把考场搭起来

6.1 三层资产，三种门

MedAgentBench 的获取不是一个"下载按钮"，而是三层资产、三种获取方式：

资产	载体	获取方式	许可
代码库	GitHub stanfordmlgroup/MedAgentBench	公开 clone	MIT License
FHIR 环境 + 数据本体	Docker 镜像 jyxsu6/medagentbench	docker pull 拉取	研究用途（随仓库/镜像）
参考解 refsol.py	Stanford Box 链接	从 Box 下载	随仓库（研究用途）

6.2 许可条款细读

• 代码库：MIT License，Copyright © 2025 Stanford Machine Learning Group。已抓取 LICENSE 原文确认，是最宽松的开源许可（可自由使用、复制、修改、合并、发布、分发、再许可、销售，只需保留版权声明与许可声明）。
• 数据/环境：README 明确 “this code repo is intended for research purpose, and might not be suitable for large-scale production”——即研究用途，不保证生产级可用性。
• 论文本体：NEJM AI 2025;2(9):AIdbp2500144，Copyright © 2025 Massachusetts Medical Society，非开放获取（isAccessibleForFree = false）。
• ⚠️ 许可边界：MIT 覆盖的是代码仓库；数据本体源自 STARR（去标识化真实病历），其再分发受研究用途约束。检索者不应把"代码 MIT"误读为"数据可无条件商用"。

6.3 五步 Quick Start（复现骨架）

Step 1 — 前置准备

git clone <repo> MedAgentBench
cd MedAgentBench
conda create -n medagentbench python=3.9
conda activate medagentbench
pip install -r requirements.txt

确保 Docker 可用：docker ps。

Step 2 — 拉起 FHIR 服务器

docker pull jyxsu6/medagentbench:latest
docker tag jyxsu6/medagentbench:latest medagentbench
docker run -p 8080:8080 medagentbench

控制台显示 “Started Application in XXX seconds” 后，访问 http://localhost:8080/ 应看到 FHIR server 控制台。

Step 3 — 配置智能体

• 在 configs/agents/openai-chat.yaml 填入 OpenAI API key；
• 若用 Gemini/Claude on Vertex AI，运行 gcloud auth print-access-token 取 token；
• 自测：python -m src.client.agent_test；
• 指定模型：python -m src.client.agent_test --config configs/agents/api_agents.yaml --agent gpt-4o-mini。

Step 4 — 启动任务服务

python -m src.start_task -a   # 启动 20 个 task_worker，连到 5000 端口控制器
# 等待约 1 分钟，见到 ".... 200 OK" 后再下一步
python -m src.assigner        # 正式发起任务

假设端口 5000-5015 可用；Mac OS 若 5000 被占用需先释放。

Step 5 — 取结果

outputs/MedAgentBenchv1/gpt-4o-mini/medagentbench-std/overall.json

下载参考解：从 Stanford Box 链接下载 refsol.py，放到 src/server/tasks/medagentbench/refsol.py。

链接：https://stanfordmedicine.box.com/s/fizv0unyjgkb1r3a83rfn5p3dc673uho（带 token 的 Box 分享链接，非永久直链——见 §9 遗留疑点）。

6.4 部署工程细节清单

项	取值
Python	3.9（conda 环境名 medagentbench）
FHIR 端口	8080
任务控制器端口	5000
task_worker 数	20
端口范围假设	5000-5015
输出目录	outputs/MedAgentBenchv1/<model>/medagentbench-std/overall.json
Docker 镜像	jyxsu6/medagentbench:latest
数据库	H2（持久化）

6.5 AI-Ready 评估：这套资产的"可获取性光谱"

按千方病案医数集的 AI-Ready 视角，MedAgentBench 的可获取性呈现开放度递降的梯度：

1. 代码（最开放）：MIT，GitHub 公开，可自由复用。
2. 环境（较开放）：Docker 镜像公开拉取，一键起 FHIR 服务器。
3. 参考解（中等）：经 Stanford Box 分享链接，可访问但非永久直链。
4. 数据本体（受约束）：随仓库/镜像获取，研究用途，README Dataset Summary 节为空（未列明细）。
5. 论文（受限）：NEJM AI 付费墙，非 OA。

评价：代码-环境-数据打包交付是其最强的 AI-Ready 特性——检索者不需要自己拼装数据，一条 docker run 就有一个可交互的医疗 EHR 环境。这是"环境型基准"相对"文件型数据集"的结构性优势。相对不足在于许可表述的模糊地带（代码 MIT 但数据研究用途）与部分资产非永久直链。

6.6 复现的三条实操提醒

1. 端口冲突：8080（FHIR）与 5000-5015（任务）需空闲；Mac 用户尤其注意 5000。
2. API 依赖：评测需真实 LLM API key，成本与限流是复现的现实约束。
3. 版本漂移：模型为 API 服务（如 GPT-4o、Claude 3.5 Sonnet v2），版本更新会导致分数不可复现——引用时必须注明评测时点。

---

§7 生态、影响与定位

7.1 学术谱系：从通用 agent 到医疗 agent

MedAgentBench 的生态位置可概括为"通用 agent 框架 + 医疗场景"的第一次系统性嫁接：

AgentBench（工程骨架：task worker / controller / assigner）
        ↓ 复用
MedAgentBench（医疗场景：FHIR 环境 + 医生任务）
        ↓ 对照
通用 agent 基准：AgentBoard、BFCL、tau-bench
医疗 agent 相关：AgentClinic、CRAFT-MD
知识型（已饱和）：MedQA、MedMCQA

它填补的空白是明确的：在它之前，没有标准化的医疗 LLM agent 基准。

7.2 与前驱基准的差异化

基准	场景	考察	是否交互
MedQA / MedMCQA	医学选择题	知识	否（已饱和）
CRAFT-MD	医患对话	对话推理	半交互
AgentClinic	模拟诊疗	多轮问诊	交互
BFCL	通用函数调用	工具调用	交互
MedAgentBench	EHR 操作	工具调用 + 病历读写	交互（≤8 轮）

差异化核心：MedAgentBench 是唯一把"真实 EHR 读写操作"作为考察对象的基准——它不是"模拟病人聊天"，而是"操作真实结构的病历系统"。

7.3 对行业的三重影响

影响一：给 agent 能力提供了一把标准尺。 在此之前，"医疗 agent 能力强不强"缺乏可比较的量化答案；MedAgentBench 提供了 300 任务 + pass@1 的统一量表。

影响二：把"未饱和"变成社区方向标。 69.67% 的最好成绩公开了"差距有多大"，让优化目标可度量——这正是"benchmark 驱动进步"的经典机制。

影响三：暴露"写操作"这一被忽视的风险点。 Query 与 Action 的分数裂谷，把"模型敢不敢让它真的改病历"从模糊担忧变成量化事实。

7.4 传播与复用

• GitHub 开源 + Docker 一键部署降低了复现门槛，使其易于被后续研究直接采用或扩展。
• MIT 代码许可允许衍生工作（新任务、新函数、新环境）自由构建在其之上。
• NEJM AI 发表赋予其临床信息学领域的权威背书（NEJM AI 是 NEJM 集团旗下 AI 专刊）。

7.5 局限与批评视角

作为客观百科，须列明其局限（详见 §9 与 §11）：

1. 规模小：100 例患者、300 个任务，覆盖有限。
2. 单一机构：全部来自 Stanford 一个系统，跨机构泛化性未验证。
3. 时间陈旧：数据截止 2018-11-13，不含近年临床实践变化。
4. 评测方差：pass@1 单次，无置信区间，模型排名需谨慎。
5. 获取模糊：代码 MIT 与数据研究用途并存，边界需自行判断。
6. 口径不一致：论文自身存在 11/12 模型、100/300 任务的双口径。

7.6 时间线速览

时间	事件
2025-01-24	arXiv v1 发布（100 任务口径，best GPT-4o 72%）
2025-02-12	arXiv v2 发布（300 任务口径，best Claude 3.5 Sonnet v2 69.67%）
2025-08-14	NEJM AI 正式发表（2025;2(9):AIdbp2500144）
2026-10-15	本条目核验时点（未见官方模型榜更新）

7.7 在千方病案医数集生态中的位置

MedAgentBench 属于库内医疗智能体/评测基准族谱，与以下条目构成互链网络（详见 §9）：

• chestagentbench（rid=816）：同为医疗 agent 基准（影像域），最贴近的横向对照；
• chimera-agent（rid=933）：agent 类框架/基准；
• medcalc-bench（rid=708）：医学计算评测基准；
• xmedbench（rid=727）/ MultiMedBench（rid=129）：综合医学评测基准。

---

§8 方法学启示：五条可迁移的经验

8.1 "环境型基准"是 agent 评测的正确形态

静态文件集只能考察"答案对不对"，交互式环境才能考察"过程对不对、副作用有没有"。MedAgentBench 用 FHIR 环境证明：agent 评测的载体必须是环境，而非题目。这一经验可直接迁移到其他领域（法律 agent 用模拟法务系统、金融 agent 用模拟交易系统）。

8.2 pass@1 是贴合高风险场景的评测哲学

医疗错误代价高，因此"一次机会"比"多次尝试的最好结果"更贴近现实。评测的严格度应与部署风险匹配——这是 MedAgentBench 最值得学习的方法论选择之一。

8.3 "读写分离"的维度设计

150 query / 150 action 的对半设计，让"能力画像"而非"单一分数"成为可能。好的基准不只给排名，还告诉你模型强在哪、弱在哪——读写的分数裂谷就是这种信息。

8.4 以步数定义难度

把难度锚定在"需几步"而非"知识多难"，使基准可随模型进步而保持区分度。难度定义要与基准的核心能力对齐——agent 基准的核心是多步规划，难度就该用步数度量。

8.5 "功能最小化"的接口设计

只暴露 9 个函数，是刻意的约束：接口越少，考察越聚焦。多的函数带来"运气性成功"的空间，少的函数让每一次调用都必须正确。这对设计任何 agent 基准都有借鉴意义。

8.6 双向教训：口径不一致的代价

MedAgentBench 论文存在 100/300 任务、11/12 模型的自我口径冲突，给复现与引用带来困扰。教训：基准类论文应维护单一权威数据表（本文的存照清单就是一种补救性实践），否则传播过程中的误引会累积成"数字民俗"。

---

§9 与库内条目的关系

9.1 家族图谱

MedAgentBench 在千方病案医数集生态中属于「医疗智能体与评测基准」家族（医学问答与基准 / 电子健康记录 L1 标签下）。其亲缘关系如下：

库内条目	rid	关系	互链理由
chestagentbench	816	最近邻（横向）	同为医疗 LLM 智能体评测基准；MedAgentBench 面向 EHR/FHIR，chestagentbench 面向胸部 X 光——同域不同模态
chimera-agent	933	同族	agent 类基准/框架
medcalc-bench	708	同族	医学计算评测基准，同属「医学评测基准」域
xmedbench	727	同族	医学综合评测基准
MultiMedBench	129	同族	医学多模态综合评测基准
medreason	（写作目录）	邻近	医学推理基准
medmcqa（MedMCQA）	（库内）	上游对照	MedAgentBench 论文明确对照的饱和知识基准
vqa-med	（库内）	邻近	医学视觉问答基准

9.2 与 chestagentbench（rid=816）的差异化定位

两者最容易混淆，须明确区分：

维度	MedAgentBench	chestagentbench
模态	电子健康档案（结构化文本/编码）	胸部 X 光（影像）
环境	FHIR 交互式服务器	影像 agent 环境
核心动作	GET 读 / POST 写病历	影像检索/判读工具调用
差异本质	考"操作信息系统"	考"操作影像系统"

结论：二者是互补而非重复，互链时应强调"EHR 域 vs 影像域"的分工。

9.3 检索路径建议

• 找医疗 agent 基准：MedAgentBench（本条目）↔ chestagentbench（816）↔ chimera-agent（933）三件套连读。
• 找医学评测基准全景：再叠加 medcalc-bench（708）、xmedbench（727）、MultiMedBench（129）。
• 找医学知识型基准对照：MedMCQA、vqa-med（理解"为什么 agent 基准是下一步"）。
• 找用真实临床数据构建的基准：MedAgentBench（STARR 派生）是库内少见的"真实 EMR 来源型"基准。

9.4 数据血缘与机构关联

• 数据血缘：STARR（Stanford 去标识化临床数据仓库）——库内若有其他 Stanford/STARR 派生数据集，可建立血缘互链。
• 机构：Stanford（Stanford ML Group）——Andrew Y. Ng、James Zou 为库内高频署名学者，可作人物索引。

---

§10 避坑清单：八个已踩过的坑

以下 8 个坑来自本条目核验过程中的实际发现与文献交叉比对。坑 N： 编号制。

坑 1：把 300 任务记成 100 任务。
arXiv v1 摘要写 “100 tasks”，而 v2/官方页/NEJM AI 写 “300 tasks”。若只读了早期预印本，会写出错误规模。对策：以正式版 300 为准，注明 v1 口径。

坑 2：把最好成绩记成 GPT-4o 72%。
早期口径 best = GPT-4o 72%，现行口径 best = Claude 3.5 Sonnet v2 69.67%。两者对应不同评测轮次。对策：引用以 69.67% 为准。

坑 3：把"代码 MIT"误读为"数据可商用"。
GitHub 上的 MIT License 只覆盖代码库；数据本体源自去标识化真实病历（STARR），README 明示研究用途、不保证生产级。对策：区分"代码许可"与"数据用途"。

坑 4：以为数据点数是 785,207 还是 700,000+ 有矛盾。
摘要的 “over 700,000” 是约数，Table 1 的 785,207 是精确值，两者相容（785,207 > 700,000）。对策：正文用精确值并注明约数来源。

坑 5：以为模型数是 11 个。
NEJM AI 表 3 标题写 “11 LLMs”，但正文称 12，且表格实列 12 行。对策：按实列 12 行为准，标注标题存疑。

坑 6：以为 FHIR 有明确的版本号。
论文只说 “FHIR-compliant”，未给出 R4/STU3 等具体版本。检索者若需精确版本须查 GitHub 配置或镜像。对策：不臆造版本号，标为遗留疑点。

坑 7：以为 refsol.py 有永久直链。
参考解经 Stanford Box 带 token 分享链接发放（stanfordmedicine.box.com/s/...），非永久直链，可能失效。对策：注明链接性质，提示可能需查仓库更新。

坑 8：以为 100 例患者数据是"合成"的。
数据源自真实临床数据仓库 STARR 的去标识化派生，不是合成数据（虽在虚拟环境中服务化）。这影响其隐私与伦理评估。对策：明确"真实派生 + 去标识化 + 患者级时间戳 jitter"三重处理。

补坑（第 9 坑，延伸）：把 pass@1 分数当作稳定排名。单次尝试对随机性与 API 版本漂移敏感，且论文未给置信区间。对策：引用时注明评测时点，不把分差 1-2 个百分点解读为显著差异。

---

§11 总结

11.1 三句话总结

1. MedAgentBench 是医学领域第一个标准化的 LLM 智能体基准，用 300 个医生任务 + FHIR 交互环境把医学 AI 评测从"背知识"推向"做操作"。
2. 它的核心价值在未饱和：12 个前沿模型 pass@1 最高仅 69.67%，且"写"远弱于"读"（Action SR 普遍低于 Query SR），多步（Hard）任务是最强模型的天花板。
3. 它以 MIT 代码 + Docker 环境 + 研究用途数据交付，是"环境型基准"的典型样本，可一键复现但受单一机构（Stanford）与陈旧时点（截止 2018）限制。

11.2 适合谁

• 医疗 AI agent 开发者：需要一个贴近部署现场的评测场；
• LLM 工具调用研究者：9 函数 / 8 轮的干净设置适合研究可靠性；
• 临床信息学团队：评估 agent 迁移进真实 EMR 的可行性；
• 基准方法论研究者：研究交互式评测的设计取舍。

11.3 不适合谁

• 需要大规模多机构数据：只有 100 例、单一机构；
• 需要最新临床实践：数据截止 2018；
• 需要外科/操作类任务：刻意排除；
• 需要无条件可商用数据：数据受研究用途约束。

11.4 30 秒决策卡

如果你……	就……
想跑一个医疗 agent 评测	clone + docker run + 配 key，三步起（§6.3）
想知道模型能不能改对病历	别看 Overall，看 Action SR（§5.3）
想找最难的部分	看 Hard SR——最强模型也只有 23.33%（§5.4）
想引用它的成绩	用 Claude 3.5 Sonnet v2 69.67%，注明 pass@1（§5.2）
想找同类基准对照	对照 chestagentbench（816）（§9.2）
想合法使用	代码 MIT，数据研究用途，注意区分（§10 坑 3）

---

FAQ（高频问答 24 问）

A. 基础认知

Q1：MedAgentBench 和 MedQA 有什么区别？
MedQA 是医学选择题基准（考知识），MedAgentBench 是交互式 agent 基准（考操作 EHR 系统）。前者已饱和，后者未饱和（best 69.67%）。

Q2：它是数据集还是基准？
是评测基准（benchmark），由"任务 + FHIR 环境 + 评分代码库"三部分组成，其中含一个 100 例患者的虚拟 EHR 数据集。

Q3：谁做的？
Stanford University，8 作者，含 Andrew Y. Ng、James Zou、Jonathan H. Chen。

Q4：发在哪？
正式版 NEJM AI 2025;2(9):AIdbp2500144；预印本 arXiv:2501.14654。

Q5：为什么叫"虚拟 EHR"？
因为它不是现实医院系统，而是在本地用 HAPI FHIR + H2 搭的一个符合 FHIR 标准的虚拟电子病历环境，可安全试错。

B. 数据与获取

Q6：有多少患者？
100 例去标识化真实患者（源自 STARR）。

Q7：有多少条记录？
785,207 条（Observation 563,426 / Procedure 124,969 / Condition 74,821 / MedicationRequest 21,991）。

Q8：数据是真实的还是合成的？
真实临床数据的去标识化派生（非纯合成），加载进虚拟 FHIR 环境服务化。

Q9：怎么下载？
代码从 GitHub clone，环境用 docker pull jyxsu6/medagentbench:latest，参考解从 Stanford Box 链接下载。

Q10：许可是什么？
代码 MIT；数据研究用途（README 明示不保证生产级）；论文 NEJM AI 版权。

Q11：数据能商用吗？
代码可以（MIT），但数据本体受研究用途约束，商用需自行评估合规——不要把"代码 MIT"外推到数据。

C. 任务与评测

Q12：有多少任务？
300 个（150 query + 150 action），10 类别（归 7 宽泛类），3 难度档。

Q13：智能体能调用几个函数？
9 个 FHIR 函数（condition/lab/vital/medicationrequest/procedure 的 search+create + patient.search）。

Q14：交互上限几轮？
8 轮，每轮只能 GET / POST / finish 三选一。

Q15：怎么算成功？
任务成功率 SR，仅 pass@1（一次机会）；细分 Query SR / Action SR / 三档难度 SR。

Q16：最好成绩多少？
Claude 3.5 Sonnet v2 = 69.67%（Overall）；Query 85.33%，Action 54.00%。

Q17：为什么是 pass@1？
因为临床对错误低容忍，一次机会比多次尝试更贴近现实部署。

Q18：Hard 任务有多难？
最强模型的 Hard SR 也只有 23.33%，全表最高是 Gemini-1.5 Pro 的 63.33%。

D. 复现与工程

Q19：怎么快速跑起来？
① clone + conda env（py3.9）② docker run -p 8080:8080 ③ 配 API key ④ python -m src.start_task -a ⑤ python -m src.assigner。

Q20：需要什么环境？
Python 3.9、Docker；FHIR server 端口 8080，任务控制器 5000-5015，20 个 task_worker。

Q21：结果在哪？
outputs/MedAgentBenchv1/<model>/medagentbench-std/overall.json。

Q22：可以换模型吗？
可以，改 --agent 参数即可（如 --agent gpt-4o-mini）。

Q23：需要联网吗？
需要——评测调用真实 LLM API，需 API key；环境本身本地 Docker 运行。

Q24：基于什么框架？
AgentBench（README 明示 “built on top of AgentBench”），复用其 task worker / controller / assigner 架构。

---

事实清单（硬事实 40 条）

1. 全称：MedAgentBench: A Realistic Virtual EHR Environment to Benchmark Medical LLM Agents
2. 定位：医学领域标准化的 LLM 智能体（agent）评测基准
3. 机构：Stanford University（Stanford ML Group + 临床信息学）
4. 作者 8 人：Yixing Jiang*、Kameron C. Black*（共同一作）、Gloria Geng、Danny Park、James Zou、Andrew Y. Ng、Jonathan H. Chen
5. 资助：NIH 与 Singapore’s National Science Scholarship（PhD）
6. 正式论文：NEJM AI 2025;2(9):AIdbp2500144，2025-08-14，DOI 10.1056/AIdbp2500144
7. 预印本：arXiv:2501.14654（v1 2025-01-24；v2 2025-02-12），DOI 10.48550/arXiv.2501.14654
8. 论文主题分类：cs.LG; cs.AI; cs.MA
9. 任务总数：300 个医生撰写任务
10. 任务类别：10 个具体类别，归 7 个宽泛类别
11. 任务类型：150 query（GET）+ 150 action（POST）
12. 难度分层：easy（1 步）/ medium（2 步）/ hard（≥3 步）
13. 任务撰写者：2 名内科医生
14. 患者数：100 例去标识化患者（unique individuals = 100）
15. 平均年龄：58.15 ± 19.82 岁
16. 女性占比：47%
17. 记录总数：785,207 条
18. Observation 记录：563,426 条
19. Procedure 记录：124,969 条
20. Condition 记录：74,821 条
21. MedicationRequest 记录：21,991 条
22. 时间跨度：近 5 年，截止 2018-11-13
23. 数据来源：Stanford 临床数据仓库 STARR
24. 隐私处理：患者级时间戳 jitter + 去标识化
25. 编码体系：NDC、LOINC、CPT、ICD10、SNOMED
26. 环境标准：FHIR-compliant
27. 环境实现：HAPI FHIR JPA + 持久化 H2 数据库
28. 容器镜像：Docker jyxsu6/medagentbench:latest
29. FHIR server 端口：8080
30. 可用函数：9 个 FHIR 函数（condition.search / lab.search / vital.search / vital.create / medicationrequest.search / medicationrequest.create / procedure.search / procedure.create / patient.search）
31. 交互动作：GET / POST / finish（三选一）
32. 交互上限：最多 8 轮
33. 主指标：任务成功率 SR，仅 pass@1
34. 细分指标：Query SR / Action SR / Easy-Medium-Hard SR
35. 最好成绩：Claude 3.5 Sonnet v2 = 69.67%（Overall）
36. 评测模型数：表 3 实列 12 个（正文/标题 11-12 双口径）
37. 代码许可：MIT License（Copyright © 2025 Stanford Machine Learning Group）
38. 基座框架：AgentBench（README 明示）
39. 参考解：refsol.py，经 Stanford Box 分享链接发放
40. 数据用途：研究用途（README 明示 not suitable for large-scale production）

---

术语表（26 条）

术语	英文/缩写	释义
智能体	Agent	能规划、调用工具、多轮迭代以完成高层任务的 LLM 系统
智能体基准	Agent Benchmark	评测智能体能力的标准化测试集与环境
电子健康档案	EHR (Electronic Health Record)	数字化患者病历系统
电子病历	EMR (Electronic Medical Record)	与 EHR 近义，常指机构内诊疗记录系统
FHIR	Fast Healthcare Interoperability Resources	现代医疗数据互操作标准
HAPI FHIR	HAPI FHIR JPA	开源 FHIR 服务器实现
H2	H2 Database	嵌入式 Java 数据库，本环境用于持久化
函数调用	Function Calling	LLM 输出结构化调用以触发外部函数
工具调用	Tool Use	智能体使用外部工具的统称能力
pass@1	pass@1	单次尝试即成功，不做多次采样
成功率	Success Rate (SR)	完成任务数 / 总任务数
查询任务	Query Task	仅需 GET 读取信息的任务
操作任务	Action Task	需 POST 修改病历的任务
GET	GET	HTTP 读请求，本基准中用于检索
POST	POST	HTTP 写请求，本基准中用于修改
finish	finish([…])	智能体提交答案、结束任务的指令
STARR	STAnford Research Repository	Stanford 去标识化临床数据仓库
去标识化	De-identification	剥离患者身份信息的处理
时间戳扰动	Timestamp Jitter	对时间做随机扰动以降低再识别风险
LOINC	Logical Observation Identifiers Names and Codes	检验与观测编码标准
CPT	Current Procedural Terminology	操作编码标准
ICD10	International Classification of Diseases, 10th revision	疾病诊断编码
NDC	National Drug Code	药品编码
SNOMED	Systematized Nomenclature of Medicine	临床术语标准
未饱和基准	Unsaturated Benchmark	最强模型也未接近满分的基准
参考解	refsol	判定任务成败所依据的标准操作/终态

---

附录

附录 A：条目信息速查卡

项	内容
slug	medagentbench
官方名	MedAgentBench
论文	NEJM AI 2025;2(9):AIdbp2500144 / arXiv:2501.14654
机构	Stanford University
患者	100 例
记录	785,207 条
任务	300 个（150 query + 150 action）
函数	9 个
轮次上限	8
最好成绩	Claude 3.5 Sonnet v2 69.67%
许可	代码 MIT；数据研究用途
仓库	github.com/stanfordmlgroup/MedAgentBench
镜像	jyxsu6/medagentbench:latest

附录 B：DAIMS 评估全表

DAIMS（Data Asset Impact & Maturity Scorecard）从五个维度评估数据资产成熟度，MedAgentBench 评分如下：

维度	权重	得分（1-5）	评分理由
D — Data Quality（数据质量）	25%	4	源自真实临床仓库 STARR，编码体系标准（LOINC/CPT/ICD10/NDC/SNOMED），四类记录齐全且计数自洽；扣分因单机构、样本小、时点旧
A — Accessibility（可获取性）	20%	4	代码 MIT 公开 + Docker 一键部署，环境可复现性极强；扣分因 refsol 非永久直链、数据本体获取不透明（README Dataset Summary 空）
I — Impact（影响力）	20%	4.5	医学首个标准化 agent 基准，NEJM AI 发表，被广泛引用对照；开源+容器化降低采用门槛
M — Maturity（成熟度）	20%	4	任务体系完整（3 难度档 × 读写双类）、评测协议明确（pass@1）、错误分析细致；扣分因口径不一致（11/12、100/300）
S — Sustainability（可持续性）	15%	3.5	Stanford 背书 + MIT 代码利于长期维护；扣分因数据截止 2018、模型 API 版本漂移导致分数难复现、无官方更新机制披露
综合	100%	4.05	强在"环境型基准"的工程交付与影响力，弱在规模、时点与口径一致性

附录 C：主结果完整对照表（表 3 + 表 4 合并）

模型	Overall	Query	Action	Easy	Medium	Hard
Claude 3.5 Sonnet v2	69.67%	85.33%	54.00%	100.00%	81.67%	23.33%
GPT-4o	64.00%	72.00%	56.00%	86.67%	70.00%	33.33%
DeepSeek-V3	62.67%	70.67%	54.67%	93.33%	68.33%	24.44%
Gemini-1.5 Pro	62.00%	52.67%	71.33%	82.22%	45.83%	63.33%
GPT-4o-mini	56.33%	59.33%	53.33%	91.11%	55.83%	22.22%
o3-mini	51.67%	54.67%	48.67%	67.78%	65.00%	17.78%
Qwen2.5 (72B)	51.33%	38.67%	64.00%	72.22%	44.17%	40.00%
Llama 3.3 (70B)	46.33%	50.00%	42.67%	56.67%	38.33%	46.67%
Gemini 2.0 Flash	38.33%	34.00%	42.67%	98.89%	17.50%	5.56%
Gemma2 (27B)	19.33%	38.67%	0.00%	33.33%	23.33%	0.00%
Gemini 2.0 Pro	18.00%	25.33%	10.67%	27.78%	14.17%	13.33%
Mistral v0.3 (7B)	4.00%	8.00%	0.00%	13.33%	0.00%	0.00%

附录 D：9 个 FHIR 函数清单

#	函数	类型	用途
1	condition.search	读	检索诊断
2	lab.search	读	检索检验结果
3	vital.search	读	检索生命体征
4	vital.create	写	记录生命体征
5	medicationrequest.search	读	检索用药医嘱
6	medicationrequest.create	写	下达用药医嘱
7	procedure.search	读	检索操作/医嘱
8	procedure.create	写	下达操作医嘱
9	patient.search	读	检索患者信息

（读 6 个 / 写 3 个；写函数仅覆盖 vital / medicationrequest / procedure。）

附录 E：患者队列特征总表（官方项目页 Table 1）

指标	数值
唯一患者数	100
平均年龄 (± SD)	58.15 ± 19.82
女性占比	47%
记录总数	785,207
Observation 记录	563,426
Procedure 记录	124,969
Condition 记录	74,821
MedicationRequest 记录	21,991

附录 F：Five-step 复现命令骨架

# Step 1 前置
git clone <repo> MedAgentBench && cd MedAgentBench
conda create -n medagentbench python=3.9 && conda activate medagentbench
pip install -r requirements.txt && docker ps

# Step 2 起 FHIR 服务器
docker pull jyxsu6/medagentbench:latest
docker tag jyxsu6/medagentbench:latest medagentbench
docker run -p 8080:8080 medagentbench

# Step 3 配置 agent（填 API key 后自测）
python -m src.client.agent_test --config configs/agents/api_agents.yaml --agent gpt-4o-mini

# Step 4 起任务服务（等约 1 分钟见 200 OK）
python -m src.start_task -a
python -m src.assigner

# Step 5 取结果
cat outputs/MedAgentBenchv1/gpt-4o-mini/medagentbench-std/overall.json

附录 G：任务类型与难度矩阵

维度	取值	数量/说明
请求类型	Query (GET)	150
请求类型	Action (POST)	150
难度	Easy（1 步）	未逐档公开计数
难度	Medium（2 步）	未逐档公开计数
难度	Hard（≥3 步）	未逐档公开计数
类别	10 具体类	归 7 宽泛类

附录 H：双口径冲突存照表

字段	口径 A	口径 B	采信
任务数	v1：100	v2/官方/NEJM：300	300
最佳模型	早期：GPT-4o 72%	v2/NEJM：Claude 3.5 Sonnet v2 69.67%	Claude 3.5 Sonnet v2 69.67%
模型数	正文：12	表标题：11	12（表实列）
数据点数	摘要：over 700,000	Table 1：785,207	785,207（精确）+ 约数并存

附录 I：与库内同类基准对照

条目	rid	域	模态
MedAgentBench	本条目	EHR/agent	结构化文本
chestagentbench	816	影像 agent	胸部 X 光
chimera-agent	933	agent 框架	多模态
medcalc-bench	708	医学计算	文本
xmedbench	727	综合评测	多模态
MultiMedBench	129	综合评测	多模态

附录 J：DAIMS 评分雷达（文字版）

数据质量 D  ████████░░  4.0
可获取性 A  ████████░░  4.0
影响力   I  █████████░  4.5
成熟度   M  ████████░░  4.0
可持续性 S  ███████░░░  3.5
────────────────────────
综合        ████████░░  4.05

附录 K：错误模式速查

模式	表现	典型案例
未严格遵循指令	输出包裹在 tool_code/json 块中	Gemini 2.0 Flash 54% 无效动作
答案格式错误	输出整句而非纯数值	期望 [5.4]，输出带壳结构

附录 L：口径不一致风险提示（论文自省）

• 任务数：v1(100) vs v2(300)——引用必须标版本。
• 模型数：11 vs 12——按表实列 12。
• 最优模型：GPT-4o 72% vs Claude 3.5 Sonnet v2 69.67%——按后者。
• 建议：任何引用 MedAgentBench 的成绩，均应注明论文版本与评测时点。

附录 M：STARR 血缘声明

MedAgentBench 数据本体源自 STARR（STAnford Research Repository）——Stanford 的去标识化临床数据仓库。凡引用本条目数据时应同时声明该血缘：“数据为 STARR 派生的去标识化患者档案（患者级时间戳 jitter），经 FHIR 服务化用于 agent 评测。”

附录 N：检索决策树

你要找的是？
├─ 医疗 LLM 智能体能力评测 → MedAgentBench（本条目）
│    ├─ 更关注影像 agent → chestagentbench (rid=816)
│    └─ 想要 agent 框架 → chimera-agent (rid=933)
├─ 医学知识型基准（对照） → MedMCQA / vqa-med
├─ 综合医学评测基准 → xmedbench (727) / MultiMedBench (129)
└─ 医学计算基准 → medcalc-bench (708)

附录 O：坑点档案（与 §10 对照）

坑号	一句话	定位
坑 1	300 ≠ 100 任务	§4.2
坑 2	best 是 69.67% 非 72%	§4.2
坑 3	代码 MIT ≠ 数据可商用	§6.2
坑 4	700,000+ 与 785,207 相容	§4.2
坑 5	模型数是 12 非 11	§4.2
坑 6	FHIR 无明确版本号	§2.3
坑 7	refsol 非永久直链	§6.3
坑 8	数据是真实派生非合成	§2.1
坑 9	pass@1 不宜读作稳定排名	§4.5

附录 P：引用规范建议

引用 MedAgentBench 成绩时建议格式：

“MedAgentBench（NEJM AI 2025;2(9):AIdbp2500144；arXiv:2501.14654v2）上，<模型名> 取得 Overall SR <x>%（pass@1，评测时点 <yyyy-mm>）。”

必含三要素：论文版本、pass@1 指标、评测时点——缺一不可，以避免版本漂移与口径误引。

---

建议互链点（供主会话回填）

• chestagentbench（rid=816）——最近邻横向对照（EHR agent vs 影像 agent），优先互链
• chimera-agent（rid=933）——agent 类基准/框架
• medcalc-bench（rid=708）——医学评测基准
• xmedbench（rid=727）——综合医学评测基准
• MultiMedBench（rid=129）——多模态综合评测基准
• medreason（写作目录）——医学推理基准

说明：以上 rid 为写作时点 DB 实测值（SELECT ... WHERE status=1 AND del_sign=0）；入库后请以主会话实测在架 rid 为准回填 relatedLink（R018 教训）。

---

数据来源与存照

1. 官方项目页：https://stanfordmlgroup.github.io/projects/medagentbench/ （300 任务 / 100 患者 / 785,207 记录 / Table 1 队列特征）
2. 论文正式版：NEJM AI 2025;2(9):AIdbp2500144，DOI 10.1056/AIdbp2500144（2025-08-14；best Claude 3.5 Sonnet v2 69.67%）
3. 预印本：arXiv:2501.14654（v1 2025-01-24 / v2 2025-02-12；DOI 10.48550/arXiv.2501.14654；表 3/表 4 结果、9 函数、8 轮、错误模式）
4. GitHub 仓库：https://github.com/stanfordmlgroup/MedAgentBench （MIT License、Quick Start、Docker 镜像 jyxsu6/medagentbench、refsol Box 链接、AgentBench 基座）
5. arXiv HTML v2：https://arxiv.org/html/2501.14654v2 （逐类/逐模型细节、HAPI FHIR JPA + H2）

抓取时点：2026-10-15

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• synsum — 共享标签：电子健康记录 / 医学问答与基准 / 临床电子病历 / 评测基准 / 医疗NLP
• ehr-notes-qa-llms — 共享标签：电子健康记录 / 医学问答与基准 / 临床电子病历 / 评测基准 / 医疗NLP
• cliniq — 共享标签：电子健康记录 / 医学问答与基准 / 临床电子病历 / 医疗NLP
• medsecid — 共享标签：电子健康记录 / 临床电子病历 / 评测基准 / 医疗NLP
• labelled-notes-hospital-course — 共享标签：电子健康记录 / 临床电子病历 / 评测基准 / 医疗NLP
• persona-patientsim — 共享标签：医学问答与基准 / 临床电子病历 / 评测基准 / 医疗NLP
• sdoh-adverse-pregnancy — 共享标签：电子健康记录 / 临床电子病历 / 评测基准 / 医疗NLP
• mediqa — 共享标签：电子健康记录 / 临床电子病历 / 评测基准 / 医疗NLP
• archehr-qa-bionlp-task-2025 — 共享标签：电子健康记录 / 医学问答与基准 / 临床电子病历 / 医疗NLP
• ehr-reasoncon — 共享标签：电子健康记录 / 医学问答与基准 / 临床电子病历 / 医疗NLP

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。