ATRIA: 自适应可追溯心电图报告系统，采用迭代式智能体

# ATRIA：自适应可追溯的迭代式ECG报告生成  
来源：https://arxiv.org/html/2606.24392  
Donggyun Hong、Kyuhwan Lee、Junmyung Kwon 与 Yong-Yeon Jo  

（2018）  

###### 摘要  

现有的心电图报告生成过程高度耦合——解释与报告被端到端地融合在一起，导致错误会逐级传播而缺乏分阶段补救措施；而基于智能体的系统虽然将任务解耦，但依然是单次通过，无法重新审视之前的输出。临床心电图报告则要求迭代展开，需要逐步整合上下文并进行双向编辑。我们提出 **ATRIA**（Adaptive Traceable Reporting with Iterative Agents）——一个多智能体心电图报告系统，它模拟了临床医生的迭代工作流程：将每条报告结论与其支持证据绑定，标记缺乏证据支持的陈述，在会话过程中融入额外上下文，并允许临床医生验证和修改单个发现，而非接受一个不透明的整体输出。由于它的智能体使用已经在临床中使用的心电图分析模型，底层发现具有临床可信性；并且作为一个基于云端的网页服务，ATRIA 可供立即部署。我们通过四个交互案例演示了 ATRIA，并提供实机演示和视频。  

心电图报告、多智能体系统、大型语言模型、临床医生参与循环、迭代式报告生成、基于标注物的推理  

††版权：ACM授权 ††出版年份：2018 ††DOI：XXXXXXX.XXXXXXX ††会议：请从权利确认邮件中输入正确的会议标题；2018年6月03–05日；纽约州伍德斯托克 ††ISBN：978-1-4503-XXXX-X/2018/06 ††CCS：计算方法 → 神经网络 ††CCS：计算方法 → 机器学习方法 ††CCS：应用计算 → 健康护理信息系统 ††CCS：信息系统 → 信息抽取  

## 1. 引言  

心电图预测模型随着深度学习的发展而迅速进步（Hannun 等人，2019 (https://arxiv.org/html/2606.24392#bib.bib1)；Ribeiro 等人，2020 (https://arxiv.org/html/2606.24392#bib.bib2)），最近的研究已将其扩展到基于大型语言模型的报告生成，包括零样本诊断（Yu 等人，2023 (https://arxiv.org/html/2606.24392#bib.bib6), 2025 (https://arxiv.org/html/2606.24392#bib.bib5)）、指令微调（Wan 等人，2024 (https://arxiv.org/html/2606.24392#bib.bib7)）、多模态心电图-语言建模（Lan 等人，2025 (https://arxiv.org/html/2606.24392#bib.bib11)）以及基于检索的推理（Tang 等人，2024 (https://arxiv.org/html/2606.24392#bib.bib9)）。然而，这些流水线通常紧密耦合：心电图的解释与报告生成被融合为一个端到端的步骤，因此错误会传播到最终报告中，而无法在阶段层面进行补救。  

基于智能体的系统已经出现以解耦这一过程，每个智能体专门负责特定心电图解释任务（Chung 等人，2026 (https://arxiv.org/html/2606.24392#bib.bib22)；UC Irvine、ASU 和 CSU 作者，2026 (https://arxiv.org/html/2606.24392#bib.bib27)）。然而，它们仍然聚焦于*单次通过的解释*：每个请求解决一个任务，之前的输出不会被重新审视或优化。而临床心电图报告是逐步展开的，需要逐渐整合上下文并进行双向编辑（Schläpfer 和 Wellens，2017 (https://arxiv.org/html/2606.24392#bib.bib14)；Mason 等人，2007 (https://arxiv.org/html/2606.24392#bib.bib15)）——在会话过程中附加实验室数值、比较既往记录或按需补充证据。因此，我们将设计重点放在使心电图报告在整个工作流程中具备自适应性和可追溯性，以便临床医生可以验证、跟进和修改每个发现，而不是简单接受或拒绝一个不透明的整体输出。  

我们提出 **ATRIA**——*自适应可追溯的迭代式报告生成*——这是一个多智能体系统，它模仿了临床医生迭代的心电图报告工作流程。与单次通过的心电图报告生成器不同，ATRIA 将每条报告结论绑定到其来源证据，验证每条结论是否得到支持，并允许临床医生修改单个结论——将一次性生成转变为可审计的交互式工作流程，其基础是已经在临床使用的心电图模型，这些模型的发现在临床上可信。  

ATRIA 围绕四个特性构建：**阶段级可追溯性**，体现在可检查的阶段输出上；**渐进式上下文整合**，允许在会话过程中接受额外输入（实验室数值、既往记录）；**双向迭代使用**，能够处理后续请求而无需重新执行整个流水线；以及一个**基于云端的、可部署的网页服务**，整合了已在临床使用的心电图模型——而非仅用于研究的原型。我们通过四个源自常规心电图阅读的交互案例来演示 ATRIA。  

我们的贡献如下：  

- 我们提出了 ATRIA，一个多智能体心电图报告系统，模拟临床医生的迭代阅读工作流程。  
- 我们围绕协调的阶段设计 ATRIA，使心电图报告可追溯并可迭代修改。  
- 我们将 ATRIA 实现为基于云端的网页服务，整合了已在临床使用的心电图模型，并通过四个交互案例进行演示；演示视频和实机演示可在 https://atria-ecg-demo.netlify.app/ 获取。  

请参考图注  

图 1. 心电图上传后 ATRIA 聊天界面的截图：编排智能体按阶段分派工作流程，每个智能体步骤在产生标注物时依次流式输出。  

## 2. 系统  

ATRIA 将心电图分析和报告组织成协调的阶段，这些阶段的中间标注物在整个会话期间得以保留，支持迭代优化而非单次通过运行。三个需求将其与单次通过流水线区分开来——**阶段级可追溯性**、**渐进式上下文整合**和**双向迭代使用**——并推动了两个架构决策：阶段级交接，每个阶段输出一个明确、可检查的标注物而不是一个融合的端到端输出；以及一个共享存储，每个智能体都可以读取和写入，使得保留的标注物可以被重新审视、补充或选择性重新推导，而无需重新执行整个流水线。图 2 (https://arxiv.org/html/2606.24392#S2.F2) 展示了整体框架。  

### 2.1. 架构概述  

为了降低临床采用的门槛，ATRIA 通过基于聊天的界面暴露其工作流程——这与常见的大语言模型基于智能体的系统采用相同的交互模型，因此用户通过对话而非专用工具进行交互。所有语言组件运行在 `gpt-5-mini` 上。一个会话对应一次患者就诊，并在初始报告生成后保持打开状态，以便后续请求可以基于相同的保留标注物进行操作。  

工作流程分四步进行：（1）用户提交一份心电图记录，可附带额外上下文，如实验室数值或既往记录。（2）**编排智能体**接管控制；它不执行任何分析或生成，只负责将工作分发给工作智能体。（3）对于初始请求，它按顺序调用工作智能体——分析、报告起草、可选的文献支持、以及审阅——每个智能体将其输出写入共享存储，系统返回一份分节的心电图报告以及支持性标注物，如心电图可视化图片，以及在请求时检索到的证据。（4）对于后续请求——澄清、附加上下文、比较、证据或修改——编排智能体只调度其标注物受影响的智能体，除非底层心电图记录发生变化，否则无需重新执行整个流水线。  

请参考图注  

图 2. ATRIA 的概览。五个智能体在一个共享的标注物存储上进行协调，每个智能体都从中读取和写入，在整个阶段化工作流程中保留中间输出。  

### 2.2. 智能体的角色  

#### 编排智能体  

它仅负责协调工作——维护会话状态、将任务路由到合适的工作智能体，并将后续请求连接到保留的标注物——不执行分析或报告生成。它可以将*多个*分析标注物绑定到同一个会话中——例如，同一患者的两份心电图记录——使得下游的报告和审阅步骤可以跨记录进行推理。工作智能体将它们的中间输出（分析结果、草稿、检索到的参考文献、审阅反馈）写入共享存储，在整个会话期间保持可访问。  

#### 分析智能体  

它接受一份心电图记录以及*可选的病人上下文*（例如，电解质或心脏生物标志物等实验室数值），并生成结构化的发现、测量值和信号级证据。它调用 **AiTiA**，即 MedicalAI 的已在临床中使用的心电图模型套件¹¹¹MedicalAI 有限公司：https://medicalai.com/en/product/，用于左心室收缩（Rhee 等人，2026 (https://arxiv.org/html/2606.24392#bib.bib24)；Jeong 等人，2024 (https://arxiv.org/html/2606.24392#bib.bib26)）和舒张（lim2026ecg_diastolic）功能障碍、主动脉瓣狭窄（kwon2020aortic）以及急性心肌梗死（Lee 等人，2025 (https://arxiv.org/html/2606.24392#bib.bib25)），提取信号级特征（Park 等人，2025 (https://arxiv.org/html/2606.24392#bib.bib19)），并应用基于规则的摘要（ECGwaves (https://arxiv.org/html/2606.24392#bib.bib28)；Life in the Fast Lane (https://arxiv.org/html/2606.24392#bib.bib29)；WikiDoc (https://arxiv.org/html/2606.24392#bib.bib30)）。因此，分析阶段将报告内容锚定在这些生产模型的输出上。提供的实验室数值填入一个单独的清单槽位，由**报告智能体**消费，以便相应的报告部分可以引用这些数值。  

#### 报告智能体  

它消费分析清单并生成一份分节的心电图报告（示例 1 (https://arxiv.org/html/2606.24392#LST1)），涵盖临床印象、特征摘要、人工智能/规则发现、导联观察、建议、注意事项和附件。每个部分都绑定到其来源的上游标注物的子集，从而实现*部分重新起草*：当只有一部分标注物发生变化时——例如，附加上下文或用户移除——仅受影响的部分会被安排重新生成。当多个分析清单绑定到会话时，模板会以比较方式实例化，在一个报告内逐节列出绑定的记录，而不是为每个记录分别生成报告。  

示例 1：临床报告的模板。  
样本链接 (https://atria-ecg-demo.netlify.app/sample_init_result.png)。  
```
## 临床印象
-- 诊断、状况

## 特征摘要
-- 心率、间期、电轴等。

## 发现
-- 人工智能+规则输出

## 导联观察
-- 每个导联的模式

## 建议
-- 后续行动

## 注意事项
-- 薄弱发现

## 附件
-- 心电图图、证据
```

#### 文献智能体  

当报告陈述需要外部支撑或用户请求支持证据时，该智能体被调用。目标陈述要么自动选择（作为跨标注物支持较弱的陈述），要么由用户在后续请求中指向特定陈述；对于每个陈述，它制定查询并从*由医学专家内部策划的心电图特定知识库*（Yu 等人，2025 (https://arxiv.org/html/2606.24392#bib.bib5)）中检索段落。检索到的段落作为文献证据标注物存储，并绑定到原始陈述；该智能体补充但不替代分析阶段。  

#### 审阅智能体  

它对照已累积的完整标注物集检查草稿，检查是否有遗漏发现、引用的证据与报告内容不匹配、以及无支持或矛盾的陈述——这些陈述引用了清单中不存在的发现，或与规则摘要相矛盾。结构化反馈返回给**报告智能体**和**编排智能体**，用于针对性修改，并向用户展示以进行迭代审阅。该智能体也可以在*任何改变标注物的后续请求之后*（例如，上下文增强后的重新起草）被重新调用，以验证更新后的草稿是否与当前标注物集保持一致。  

### 2.3. 实现说明  

ATRIA 实现为基于云端的网页服务。标注物存储按会话键索引，因此一个会话内产生的所有标注物对后续请求仍然可用。每个智能体使用特定阶段的提示和一个通用的 JSON 模式进行标注物交换。心电图输入接受为*商用心电图设备*导出的原始记录文件，涵盖常见的临床心电图格式，如 HL7 aECG、SCP-ECG 和 DICOM-ECG。病人上下文（实验室数值、既往心电图记录）接受为结构化上传或内联聊天附件，并填入相应的清单槽位。  

## 3. 使用案例  

我们通过四个案例来说明 ATRIA 的行为，这些案例共同覆盖了三个设计需求，并展示了不同的后续请求路由路径。每个案例对应临床医生在阅读和完善心电图报告时例行执行的一个步骤——纠正无支持的声明、附加实验室数值、请求支持证据、以及比较既往记录（Schläpfer 和 Wellens，2017 (https://arxiv.org/html/2606.24392#bib.bib14)；Mason 等人，2007 (https://arxiv.org/html/2606.24392#bib.bib15)）——而不是为系统便利而选择的能力。以下列表中的报告和证据摘录经过压缩以节省篇幅；每个示例的实际渲染图以及完整交互可在演示页面和附带的演示视频中获取。  

### 3.1. 案例 1：初始报告的可追溯性验证  

**触发条件**。用户上传一份心电图记录并请求初始报告。  
**行为**。**编排智能体**协调完整的阶段化工作流程；**审阅智能体**将草稿与**分析智能体**的清单进行比较，并标记一个在上游标注物中缺乏对应支持的声明——这是一个在单次通过流水线中会不加标记地到达最终报告的无支持声明。  
**标注物**。一个审阅反馈标注物被添加到会话中，标记那些在上游标注物中缺乏支持的声明，以便在定稿前将其移除或限定（示例 2 (https://arxiv.org/html/2606.24392#LST2)）。  

示例 2：案例 1 —— 审阅智能体对初始草稿的裁决以及被标记为缺乏上游标注物支持的代表性声明。  
样本链接 (https://atria-ecg-demo.netlify.app/sample_review)。  
```
[审阅智能体裁决]
结果：发现无支持的声明（证据缺失）。若干
报告声明未在上游标注物中找到支撑；它们
似乎是外部指南内容，在提供的数据中不存在。

[无支持的声明——证据缺失]
(a) "使用连续高敏肌钙蛋白算法（0/1小时或
0/2小时），由当代ESC和AHA/ACC指南
推荐支持。"
-- 上游标注物中没有任何指南文本或肌钙蛋白数据。

(b) "左心室肥大电压标准（Sokolow-Lyon, Cornell）
敏感性有限；需与超声心动图相关以评估左心室质量。"
-- 规则有lvh_qrsd=1（仅标志）；性能声明和
超声建议不在任何标注物中。

(c) "QTc 444ms 处于临界范围（男性>=450ms，女性>=460ms；
>=500ms 扭转型室速风险较高）。" [部分支持情况]
-- 数字QTc 444ms 在特征摘要中得到支持；性别特异性
临界值和扭转型室速阈值不存在。
```

### 3.2. 案例 2：实验室数值增强的报告（渐进式上下文整合）  

**触发条件**。在生成初始报告后，用户附加实验室数值（例如，血清钾、肌钙蛋白）并要求系统将其纳入解释。  
**行为**。**编排智能体**将该请求路由为患者上下文附件。**分析智能体**被重新调用，使用相同的心电图记录，但提供的实验室数值被填入清单槽位；**报告智能体**仅重新起草受影响的部分（临床印象、建议）。结果