最近在整理医疗行业 AI Agent 落地方案时一个反复出现的矛盾点让我印象很深模型可以把自然语言指令拆解得很好但真正到生成索赔报文、查询保险资格、提交电子病历相关的交易数据时如果执行层完全不理解医疗电子数据交换的行业标准输出结果往往是“结构漂亮、实际不可用”。这个行业标准就是 X12。它不是 AI 时代的产物却是医疗 AI Agent 从“Demo 级”走向“生产级”时最绕不开的约束条件。本文会从一个 AI Engineer 的视角讲清楚 X12 在医疗 AI Agent 执行层中的作用并带大家动手实现一个带 X12 校验能力的 Agent 执行层。无论你是刚接触 AI Agent 的新手还是正在做医疗信息化集成的后端开发者这篇文章都能提供一套可以直接参考的设计思路与代码样例。1. 医疗 AI Agent 与执行层X12 为什么绕不开1.1 医疗 AI Agent 到底做什么AI Agent 和普通的 LLM 问答最大的区别在于它不只是“说”还会“做”。在医疗场景里这个“做”通常对应着真实的业务动作比如根据患者信息生成一份保险预授权申请。查询某个患者在医保体系内的资格状态。把诊断结果映射成标准诊断编码ICD-10。提交一笔电子化索赔或者核对理赔回执。这些动作背后都对接的是真实存在的医疗信息系统。只要涉及保险公司、医院收费系统、医保清算平台之间的电子化业务往来就几乎绕不开 EDIElectronic Data Interchange体系而美国医疗行业最主流的 EDI 实现就是 X12 标准。1.2 执行层在 AI Agent 架构中的位置我们常说的 AI Agent 完整架构通常包含几个层次交互层接收用户输入包括对话、表单、语音等。规划层由 LLM 理解意图、拆解任务、制定行动计划。工具层封装可供 Agent 调用的工具比如查数据库、调 API、发邮件。执行层真正运行工具、处理数据、产生对外部系统的影响。校验层检查执行结果是否符合预期。很多 AI Agent 项目在初期最重视规划层因为它直接关系到大模型“聪明不聪明”。但进入医疗行业后真正决定系统能不能上线运行的往往是执行层和校验层。道理很简单模型规划得再好如果最终提交出去的报文不符合接收方的格式要求这笔业务就是失败的。这也解释了为什么把 X12 看作是构建可靠执行层的“关键约束”。这里的约束不是贬义词而是指执行层必须严格遵守一套确定的、可验证的规则Agent 的灵活性必须在规则边界之内发挥。1.3 为什么是 X12而不是 JSON 或 XML有人可能会问现在都是 REST API 时代了为什么不直接让 AI Agent 输出 JSON 然后调用接口非要引入 X12原因在于医疗行业的存量系统非常庞大。保险公司、清算所、医院信息系统的核心交易流程仍然是基于 EDI 报文在跑。你可以把 X12 理解成医疗交易领域的“通用语言”无论内部系统用什么技术栈对外交互时大家都说自己这套语言。所以在医疗领域做 AI Agent执行层需要具备两种能力把内部结构化的数据转换成符合 X12 语法规范的报文。把外部返回的 X12 报文解析成内部系统能理解的对象。这两个能力本质上就是开发一个可靠的 EDI 适配层。本文后面会重点实现这一块。2. X12 基础概念从 EDI 报文到医疗事务集2.1 EDI 与 X12 的关系EDI 是一种用于企业之间结构化数据交换的电子化方式核心目标是替代纸质表单、传真、人工录入。X12 是 ANSI 下属的认证标准委员会制定的 EDI 标准广泛用于北美地区的医疗、保险、供应链、金融等行业。在医疗行业X12 报文通常以 ASC X12 的格式传输最常见的是 005010 系列版本。这里的 005010 就是版本号不同版本之间的语法严格程度、事务规则会有差异。AI Agent 在执行层做标准约束时必须明确自己适配的是哪个版本。2.2 X12 报文的基本结构一份完整的 X12 报文由三部分组成交换信封ISA/IEA、功能组信封GS/GE、事务集ST/SE。看一个最简化的结构示意ISA*00* *00* *ZZ*SENDER *ZZ*RECEIVER *230101*1200*^*00501*000000001*0*P*:~ GS*HC*SENDER*RECEIVER*20230101*1200*1*X*005010X222~ ST*837*0001~ ...业务段... SE*12*0001~ GE*1*1~ IEA*1*000000001~解释一下各段的作用ISA 段是交换控制头固定长度 106 个字符包含发送方、接收方、日期时间、控制编号等。这个段的字段位置是固定的所以解析时必须按位置切分不能像 JSON 那样按名字取。GS 段是功能组头说明功能组类型和版本信息。ST 段开启一个具体的事务集比如 837 表示医疗索赔。SE 段结束事务集并带有段计数。GE、IEA 分别结束功能组和交换信封。2.3 医疗场景常见的事务集在医疗领域AI Agent 执行层最常处理的 X12 事务集有几种事务集编号名称典型用途837Health Care Claim提交医疗索赔835Health Care Claim Payment/Advice理赔支付与说明270/271Eligibility Inquiry/Response保险资格查询/响应276/277Claim Status Inquiry/Response索赔状态查询/响应278Health Care Services Review预授权/转诊审核其中 837 和 835 是 AI Agent 最容易碰到的两类。Agent 要“帮用户提交一笔索赔”本质上就是要生成一个 837 事务集要“核对理赔结果”本质上就是解析 835 报文。明白了这些事务集的存在之后你就会理解执行层为什么必须引入约束一个 Agent 如果不知道 837 里 CLM 段应该什么时候出现、NM1 段的限定符应该填什么它生成的报文在接收方看来就是非法数据。3. 执行层设计把标准变成约束而不是阻力3.1 AI Agent 执行层通常包含哪些模块从工程角度看一个面向医疗交易的 Agent 执行层至少包含以下模块数据接入模块接收来自 Agent 规划层的结构化动作指令。映射模块把业务字段映射到 X12 段元素。报文生成模块将映射结果按 X12 语法拼装成报文。校验模块在发送前检查报文是否符合语法和业务规则。传输模块通过 SFTP、HTTPS、AS2 等方式把报文发到接收方。回执处理模块解析接收方返回的 997、999、277 等回执。在实际项目里很多团队会把 3 和 4 合并到同一个服务里。但对于 AI Agent 场景我强烈建议把校验模块独立出来。原因是LLM 生成的内容天然带有不确定性如果校验逻辑散落在各处很难形成有效的安全边界。3.2 为什么“标准”是约束也是保护如果把执行层比作建筑的承重墙X12 标准就是施工规范。规范不会限制你盖出好房子反而能确保房子不会倒。对 AI Agent 来说X12 规则的价值体现在三方面第一减少幻觉造成的错误输出。大模型在生成报文时很可能凭训练记忆“编”出并不符合实际格式要求的字段。如果执行层有强校验这些幻觉输出会在源头被拦截。第二让错误可以被定位。标准化的报文结构意味着每一段、每一个元素都有明确位置。当校验失败时系统可以精确指出“第 3 个 CLM 段缺少医疗记录编号”而不是含糊地提示“报文格式错误”。第三为审计和合规提供基础。医疗数据交换往往涉及合规要求能够保留标准化的报文和校验日志是后续审计的重要依据。3.3 引入 X12 校验网关的架构思路我建议在 Agent 工具调用和外部系统之间插入一层“EDI 校验网关”。执行层的动作指令不再直接生成报文并发送而是先封装成中间结构再经过校验网关。大致调用链如下Agent 规划层 ↓ 工具调用 执行层 ActionExecutor ↓ 生成中间数据 X12TransactionBuilder ↓ 生成 X12 报文 EdiValidationGateway ↓ 校验通过 传输适配器发送到外部系统 ↓ 返回回执 回执解析器这个流程的核心思想是Agent 可以自由地决定“做什么”但执行层必须严格保证“怎么做”。校验网关就是那个把“怎么做”牢牢锁住的角色。4. 实战构建支持 X12 校验的医疗 Agent 执行层下面我们用 Java 写一个简化但可运行的后端示例。为了便于理解我会把重点放在如何解析 X12 段。如何对 837 报文做基本语法校验。如何在校验通过后交给 Agent 执行层继续处理。4.1 项目结构先创建一个 Spring Boot 项目方向如下medical-agent-executor/ ├── pom.xml └── src/main/java/com/example/medagent/ ├── MedicalAgentExecutorApplication.java ├── x12/ │ ├── X12Segment.java │ ├── X12Parser.java │ ├── X12ValidationException.java │ ├── EdiValidationGateway.java │ └── ClaimValidationRule.java ├── agent/ │ ├── AgentTool.java │ └── SubmitClaimTool.java └── model/ └── ClaimRequest.java这里把 X12 相关代码单独放在x12包下方便后续复用和扩展成独立的 EDI 服务。4.2 添加依赖在pom.xml中加入 Spring Boot Web 和参数校验依赖。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version11/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependencies如果你用的是 Spring Boot 3.x只需要把父版本换成对应的 3.x 版本依赖写法不变。4.3 实现 X12 报文解析器X12 报文的解析并没有想象中复杂。核心思路是用段结束符拆出一个个段再用元素分隔符拆出段内元素。系统按照 EDI 标准规定的元字符来进行拆分。// 文件路径src/main/java/com/example/medagent/x12/X12Segment.java package com.example.medagent.x12; import java.util.Arrays; import java.util.List; public class X12Segment { private final String id; private final ListString elements; public X12Segment(String raw) { String[] parts raw.split(\\*, -1); this.id parts[0]; this.elements Arrays.asList(parts); } public String getId() { return id; } public String getElement(int index) { if (index 0 || index elements.size()) { return ; } return elements.get(index); } public int elementCount() { return elements.size() - 1; } Override public String toString() { return String.join(*, elements); } }这里需要注意一个细节split(\\*, -1)末尾的-1不能省略。它保证元素为空时也不会被丢弃。比如CLM*ABC123*250.00***11:B:1*Y*A*Y*Y中连续的分隔符之间有空元素省略-1会导致解析错位。接着实现解析器// 文件路径src/main/java/com/example/medagent/x12/X12Parser.java package com.example.medagent.x12; import java.util.ArrayList; import java.util.List; public class X12Parser { public ListX12Segment parse(String ediContent) { ListX12Segment segments new ArrayList(); // 实际项目中段结束符应从 ISA 段动态识别这里以常见的 ~ 为例 String[] rawSegments ediContent.split(~); for (String raw : rawSegments) { String trimmed raw.trim(); if (trimmed.isEmpty()) { continue; } segments.add(new X12Segment(trimmed)); } return segments; } }在实际生产环境中ISA 段的第 16 个元素就是段结束符第 4 个元素是元素分隔符第 17 个元素是子元素分隔符。更严谨的做法是先提取 ISA 段前 106 个字符从固定位置解析出这些元字符再按元字符拆分后续内容。上面的示例是为了演示主流程所以先固定用*和~。4.4 实现 837 校验规则接下来实现针对 837 事务集的校验规则。这一步是整个执行层的核心。我们需要检查报文中是否存在 ST 段且 ST 段第一个元素必须是 837。报文中是否存在 CLM 段CLM 段至少包含 2 个元素。报文结尾是否包含 SE 段且 SE 段第一个元素与 ST 段事务集编号对应。// 文件路径src/main/java/com/example/medagent/x12/ClaimValidationRule.java package com.example.medagent.x12; import java.util.List; public class ClaimValidationRule { public void validate(ListX12Segment segments) { boolean hasST false; boolean hasCLM false; boolean hasSE false; for (X12Segment segment : segments) { String id segment.getId(); if (ST.equals(id)) { hasST true; if (!837.equals(segment.getElement(1))) { throw new X12ValidationException(ST 段事务集编号不是 837请检查业务类型); } } if (CLM.equals(id)) { hasCLM true; if (segment.elementCount() 2 || segment.getElement(1).isEmpty()) { throw new X12ValidationException(CLM 段缺少必需的索赔编号); } } if (SE.equals(id)) { hasSE true; } } if (!hasST) { throw new X12ValidationException(报文中缺少 ST 段); } if (!hasCLM) { throw new X12ValidationException(837 报文中必须包含至少一个 CLM 段); } if (!hasSE) { throw new X12ValidationException(报文中缺少 SE 段); } } }编写自定义异常// 文件路径src/main/java/com/example/medagent/x12/X12ValidationException.java package com.example.medagent.x12; public class X12ValidationException extends RuntimeException { public X12ValidationException(String message) { super(message); } }4.5 封装校验网关校验网关的作用是把“解析报文”和“校验规则”组合起来对外提供一个统一的入口。有了这一层Agent 工具调用时不需要自己处理 X12 解析细节。// 文件路径src/main/java/com/example/medagent/x12/EdiValidationGateway.java package com.example.medagent.x12; import java.util.List; public class EdiValidationGateway { private final X12Parser parser new X12Parser(); private final ClaimValidationRule claimRule new ClaimValidationRule(); public void validate837(String ediContent) { System.out.println( EdiValidationGateway 开始校验 ); ListX12Segment segments parser.parse(ediContent); claimRule.validate(segments); System.out.println(校验通过共解析到 segments.size() 个段); } }4.6 把校验网关接入 Agent 工具调用这一节演示 Agent 的工具层如何调用校验网关。我们使用一个最简化的案例当大模型决定执行“提交索赔”工具时执行层先完成 X12 报文封装再调用校验网关。先定义一个索赔请求模型// 文件路径src/main/java/com/example/medagent/model/ClaimRequest.java package com.example.medagent.model; public class ClaimRequest { private String claimId; private String patientName; private String diagnosisCode; private String amount; private String providerName; public String getClaimId() { return claimId; } public void setClaimId(String claimId) { this.claimId claimId; } public String getPatientName() { return patientName; } public void setPatientName(String patientName) { this.patientName patientName; } public String getDiagnosisCode() { return diagnosisCode; } public void setDiagnosisCode(String diagnosisCode) { this.diagnosisCode diagnosisCode; } public String getAmount() { return amount; } public void setAmount(String amount) { this.amount amount; } public String getProviderName() { return providerName; } public void setProviderName(String providerName) { this.providerName providerName; } }然后是一个简单的 837 报文构建器// 文件路径src/main/java/com/example/medagent/agent/X12ClaimBuilder.java package com.example.medagent.agent; import com.example.medagent.model.ClaimRequest; public class X12ClaimBuilder { public String build837(ClaimRequest request) { StringBuilder sb new StringBuilder(); sb.append(ISA*00* *00* *ZZ*SENDER *ZZ*RECEIVER *230101*1200*^*00501*000000001*0*P*:); sb.append(~); sb.append(GS*HC*SENDER*RECEIVER*20230101*1200*1*X*005010X222); sb.append(~); sb.append(ST*837*0001); sb.append(~); sb.append(BHT*0019*00*).append(request.getClaimId()).append(*20230101*1200*CH); sb.append(~); sb.append(NM1*41*2*).append(request.getProviderName()).append(*****46*123456789); sb.append(~); sb.append(HL*1**20*1); sb.append(~); sb.append(NM1*85*2*).append(request.getProviderName()).append(*****XX*1234567890); sb.append(~); sb.append(HL*2*1*22*1); sb.append(~); sb.append(NM1*IL*1*DOE*JOHN****MI*123456789); sb.append(~); sb.append(HL*3*2*23*0); sb.append(~); sb.append(NM1*PR*2*INSURANCE_COMPANY*****PI*INS001); sb.append(~); sb.append(CLM*).append(request.getClaimId()).append(*).append(request.getAmount()).append(***11:B:1*Y*A*Y*Y); sb.append(~); sb.append(HI*BK:).append(request.getDiagnosisCode()); sb.append(~); sb.append(SE*13*0001); sb.append(~); sb.append(GE*1*1); sb.append(~); sb.append(IEA*1*000000001); sb.append(~); return sb.toString(); } }然后定义 Agent 工具接口和实现// 文件路径src/main/java/com/example/medagent/agent/AgentTool.java package com.example.medagent.agent; public interface AgentTool { String getName(); String execute(String inputJson); }// 文件路径src/main/java/com/example/medagent/agent/SubmitClaimTool.java package com.example.medagent.agent; import com.example.medagent.model.ClaimRequest; import com.example.medagent.x12.EdiValidationGateway; public class SubmitClaimTool implements AgentTool { private final X12ClaimBuilder claimBuilder new X12ClaimBuilder(); private final EdiValidationGateway validationGateway new EdiValidationGateway(); Override public String getName() { return submit_claim; } Override public String execute(String inputJson) { // 实际项目中这里会把 JSON 反序列化为 ClaimRequest ClaimRequest request parseRequest(inputJson); // Agent 执行层先构建报文 String ediContent claimBuilder.build837(request); // Agent 执行层再做 X12 标准校验 validationGateway.validate837(ediContent); // 校验通过后才允许进入真正的传输环节 return 索赔报文已通过 X12 837 校验可以进入传输队列claimId request.getClaimId(); } private ClaimRequest parseRequest(String inputJson) { // 简化处理实际项目中建议使用 Jackson 或 Gson ClaimRequest request new ClaimRequest(); request.setClaimId(CLAIM001); request.setPatientName(JOHN DOE); request.setDiagnosisCode(I10); request.setAmount(250.00); request.setProviderName(TEST_CLINIC); return request; } }上面的parseRequest简化了 JSON 解析实际项目中请用 Jackson 的ObjectMapper完成。这里为了控制示例长度直接构造对象。下面写一个简单的运行入口// 文件路径src/main/java/com/example/medagent/MedicalAgentExecutorApplication.java package com.example.medagent; import com.example.medagent.agent.SubmitClaimTool; public class MedicalAgentExecutorApplication { public static void main(String[] args) { SubmitClaimTool tool new SubmitClaimTool(); String result tool.execute({}); System.out.println(result); } }4.7 运行与验证直接运行main方法预期控制台输出类似 EdiValidationGateway 开始校验 校验通过共解析到 14 个段 索赔报文已通过 X12 837 校验可以进入传输队列claimIdCLAIM001如果把CLM*这一行的索赔编号去掉例如构造出一个空的 claimId校验网关就会抛出异常Exception in thread main com.example.medagent.x12.X12ValidationException: CLM 段缺少必需的索赔编号这就是执行层约束发挥作用的过程。AI Agent 的规划层可以自由决定要提交哪笔索赔但执行层会确保只有符合 X12 837 规范的报文才能继续往下一环节走。5. 常见问题与排查思路在医疗 AI Agent 执行层开发中比较常见的错误可以分为几类。下面用表格汇总问题现象常见原因解决思路解析后段数量不对没有正确识别段结束符或空行被当作段处理从 ISA 段固定位置提取分隔符跳过空白段CLM 段缺少编号上游数据字段映射错误或 LLM 生成的索赔编号缺失在生成报文前校验业务字段补全必填项前不允许拼接ST 段事务集编号不是 837Agent 选错了工具或业务类型映射错误工具调用参数里强制指定事务集类型校验网关第一层直接拦截发送后收到 997 回执错误报文基本语法通过但业务层校验失败解析 997 中 AK2 和 AK3 段定位具体事务集错误日期格式错误X12 多数日期使用 CCYYMMDD 格式内部接口传成了带横杠的格式在映射层统一做格式转换不要依赖 LLM 自动处理日期再补充两个排查思路第一建议把解析前后的报文打日志。重点观察从 ISA 到 IEA 的完整链路是否齐全。一份 837 报文如果缺少 IEA接收方会认为交换没有正常结束。第二当 Agent 接入多家保险公司时不要假设所有接收方都使用同一版本标准。很多机构使用 004010 或 005010还有少量扩展版本。校验网关里的规则应该是可配置的而不是写死在代码里。6. 医疗 AI Agent 执行层的最佳实践6.1 把标准校验放在模型输出之后这是最重要的一条建议。AI Agent 项目的自然语言处理能力再强执行层也必须保留硬编码的规则校验。模型输出先经过结构化提取再经过 X12 校验网关最后才允许发送。不要把“模型不会出错”当作假设。6.2 明确职责边界Agent 规划层负责拆解意图工具层负责定义可执行的动作执行层负责技术校验传输层负责对接外部系统。每一层只做自己该做的事。如果执行层代码里出现了大量业务意图判断说明边界被破坏了。6.3 日志与审计要留够信息医疗交易对审计要求通常很高。每次 Agent 提交交易时至少记录原始的工具调用参数。生成的 X12 报文全文。校验网关的校验结果。外部系统回执内容。对应的时间戳和会话 ID。注意这里涉及患者信息时在真实环境中必须严格按合规要求做脱敏、权限控制和加密存储。不要在日志里输出完整的敏感个人信息。6.4 设计可配置的规则引擎不同保险公司对 837 报文的业务要求可能有细微差别。例如某些机构要求必填自定义的 REF 段另一些机构则不需要。建议把“必填段”“可选段”“元素格式”等规则抽成配置这样在接入新机构时不需要修改核心代码只需要调整配置。6.5 做好测试数据隔离在开发阶段不要直接连接生产环境的 EDI 网关。建议准备一套测试用的 837、835 报文样例配合本地校验服务做自动化测试。测试样例至少要覆盖正常通过的情况。缺少 CLM 段的情况。ST 段类型错误的情况。SE 段缺失的情况。日期格式错误的情况。6.6 考虑异步化与重试医疗 EDI 交易往往不是瞬时返回结果。Agent 提交 837 后可能需要等待接收方通过 997、277 或 999 回执来确认结果。执行层应该支持异步状态流转而不是同步等待。重试时要注意幂等避免因为网络重发导致同一笔索赔被重复提交。7. 总结从这一套示例能看出来医疗 AI Agent 的落地难点并不全在大模型本身更多在于执行层有没有建立足够的确定性和标准约束。X12 作为医疗行业数据交换的重要标准恰恰为 AI Engineer 提供了这样一套可验证、可审计、可复用的规则边界。本文围绕“医疗 AI Agent 实战”这条主线拆解了 AI Agent 执行层的结构讲清了 X12 报文的基础语法与常见事务集并从零实现了一个包含解析器、校验规则、校验网关和工具调用的最小执行层。代码虽然精简但已经覆盖了医疗交易场景中最核心的“先校验、再发送”思想。如果你正在做一个医疗相关的 AI Agent 项目我建议下一步从三件事开始收集你们业务实际用到的 X12 事务集样例比如 837、835、270/271。把这些样例整理成自动化测试用例固化进 CI/CD 流程。在 Agent 工具调用链中加入校验网关让标准校验成为执行层的默认防线。医疗行业的 AI Agent 越往后做行业标准的重要性会越明显。掌握 X12 约束不仅是为了对接现有系统更是为了在 AI 时代构建真正值得信赖的医疗自动化服务。
医疗AI Agent执行层必备：X12标准校验实战与Java实现
最近在整理医疗行业 AI Agent 落地方案时一个反复出现的矛盾点让我印象很深模型可以把自然语言指令拆解得很好但真正到生成索赔报文、查询保险资格、提交电子病历相关的交易数据时如果执行层完全不理解医疗电子数据交换的行业标准输出结果往往是“结构漂亮、实际不可用”。这个行业标准就是 X12。它不是 AI 时代的产物却是医疗 AI Agent 从“Demo 级”走向“生产级”时最绕不开的约束条件。本文会从一个 AI Engineer 的视角讲清楚 X12 在医疗 AI Agent 执行层中的作用并带大家动手实现一个带 X12 校验能力的 Agent 执行层。无论你是刚接触 AI Agent 的新手还是正在做医疗信息化集成的后端开发者这篇文章都能提供一套可以直接参考的设计思路与代码样例。1. 医疗 AI Agent 与执行层X12 为什么绕不开1.1 医疗 AI Agent 到底做什么AI Agent 和普通的 LLM 问答最大的区别在于它不只是“说”还会“做”。在医疗场景里这个“做”通常对应着真实的业务动作比如根据患者信息生成一份保险预授权申请。查询某个患者在医保体系内的资格状态。把诊断结果映射成标准诊断编码ICD-10。提交一笔电子化索赔或者核对理赔回执。这些动作背后都对接的是真实存在的医疗信息系统。只要涉及保险公司、医院收费系统、医保清算平台之间的电子化业务往来就几乎绕不开 EDIElectronic Data Interchange体系而美国医疗行业最主流的 EDI 实现就是 X12 标准。1.2 执行层在 AI Agent 架构中的位置我们常说的 AI Agent 完整架构通常包含几个层次交互层接收用户输入包括对话、表单、语音等。规划层由 LLM 理解意图、拆解任务、制定行动计划。工具层封装可供 Agent 调用的工具比如查数据库、调 API、发邮件。执行层真正运行工具、处理数据、产生对外部系统的影响。校验层检查执行结果是否符合预期。很多 AI Agent 项目在初期最重视规划层因为它直接关系到大模型“聪明不聪明”。但进入医疗行业后真正决定系统能不能上线运行的往往是执行层和校验层。道理很简单模型规划得再好如果最终提交出去的报文不符合接收方的格式要求这笔业务就是失败的。这也解释了为什么把 X12 看作是构建可靠执行层的“关键约束”。这里的约束不是贬义词而是指执行层必须严格遵守一套确定的、可验证的规则Agent 的灵活性必须在规则边界之内发挥。1.3 为什么是 X12而不是 JSON 或 XML有人可能会问现在都是 REST API 时代了为什么不直接让 AI Agent 输出 JSON 然后调用接口非要引入 X12原因在于医疗行业的存量系统非常庞大。保险公司、清算所、医院信息系统的核心交易流程仍然是基于 EDI 报文在跑。你可以把 X12 理解成医疗交易领域的“通用语言”无论内部系统用什么技术栈对外交互时大家都说自己这套语言。所以在医疗领域做 AI Agent执行层需要具备两种能力把内部结构化的数据转换成符合 X12 语法规范的报文。把外部返回的 X12 报文解析成内部系统能理解的对象。这两个能力本质上就是开发一个可靠的 EDI 适配层。本文后面会重点实现这一块。2. X12 基础概念从 EDI 报文到医疗事务集2.1 EDI 与 X12 的关系EDI 是一种用于企业之间结构化数据交换的电子化方式核心目标是替代纸质表单、传真、人工录入。X12 是 ANSI 下属的认证标准委员会制定的 EDI 标准广泛用于北美地区的医疗、保险、供应链、金融等行业。在医疗行业X12 报文通常以 ASC X12 的格式传输最常见的是 005010 系列版本。这里的 005010 就是版本号不同版本之间的语法严格程度、事务规则会有差异。AI Agent 在执行层做标准约束时必须明确自己适配的是哪个版本。2.2 X12 报文的基本结构一份完整的 X12 报文由三部分组成交换信封ISA/IEA、功能组信封GS/GE、事务集ST/SE。看一个最简化的结构示意ISA*00* *00* *ZZ*SENDER *ZZ*RECEIVER *230101*1200*^*00501*000000001*0*P*:~ GS*HC*SENDER*RECEIVER*20230101*1200*1*X*005010X222~ ST*837*0001~ ...业务段... SE*12*0001~ GE*1*1~ IEA*1*000000001~解释一下各段的作用ISA 段是交换控制头固定长度 106 个字符包含发送方、接收方、日期时间、控制编号等。这个段的字段位置是固定的所以解析时必须按位置切分不能像 JSON 那样按名字取。GS 段是功能组头说明功能组类型和版本信息。ST 段开启一个具体的事务集比如 837 表示医疗索赔。SE 段结束事务集并带有段计数。GE、IEA 分别结束功能组和交换信封。2.3 医疗场景常见的事务集在医疗领域AI Agent 执行层最常处理的 X12 事务集有几种事务集编号名称典型用途837Health Care Claim提交医疗索赔835Health Care Claim Payment/Advice理赔支付与说明270/271Eligibility Inquiry/Response保险资格查询/响应276/277Claim Status Inquiry/Response索赔状态查询/响应278Health Care Services Review预授权/转诊审核其中 837 和 835 是 AI Agent 最容易碰到的两类。Agent 要“帮用户提交一笔索赔”本质上就是要生成一个 837 事务集要“核对理赔结果”本质上就是解析 835 报文。明白了这些事务集的存在之后你就会理解执行层为什么必须引入约束一个 Agent 如果不知道 837 里 CLM 段应该什么时候出现、NM1 段的限定符应该填什么它生成的报文在接收方看来就是非法数据。3. 执行层设计把标准变成约束而不是阻力3.1 AI Agent 执行层通常包含哪些模块从工程角度看一个面向医疗交易的 Agent 执行层至少包含以下模块数据接入模块接收来自 Agent 规划层的结构化动作指令。映射模块把业务字段映射到 X12 段元素。报文生成模块将映射结果按 X12 语法拼装成报文。校验模块在发送前检查报文是否符合语法和业务规则。传输模块通过 SFTP、HTTPS、AS2 等方式把报文发到接收方。回执处理模块解析接收方返回的 997、999、277 等回执。在实际项目里很多团队会把 3 和 4 合并到同一个服务里。但对于 AI Agent 场景我强烈建议把校验模块独立出来。原因是LLM 生成的内容天然带有不确定性如果校验逻辑散落在各处很难形成有效的安全边界。3.2 为什么“标准”是约束也是保护如果把执行层比作建筑的承重墙X12 标准就是施工规范。规范不会限制你盖出好房子反而能确保房子不会倒。对 AI Agent 来说X12 规则的价值体现在三方面第一减少幻觉造成的错误输出。大模型在生成报文时很可能凭训练记忆“编”出并不符合实际格式要求的字段。如果执行层有强校验这些幻觉输出会在源头被拦截。第二让错误可以被定位。标准化的报文结构意味着每一段、每一个元素都有明确位置。当校验失败时系统可以精确指出“第 3 个 CLM 段缺少医疗记录编号”而不是含糊地提示“报文格式错误”。第三为审计和合规提供基础。医疗数据交换往往涉及合规要求能够保留标准化的报文和校验日志是后续审计的重要依据。3.3 引入 X12 校验网关的架构思路我建议在 Agent 工具调用和外部系统之间插入一层“EDI 校验网关”。执行层的动作指令不再直接生成报文并发送而是先封装成中间结构再经过校验网关。大致调用链如下Agent 规划层 ↓ 工具调用 执行层 ActionExecutor ↓ 生成中间数据 X12TransactionBuilder ↓ 生成 X12 报文 EdiValidationGateway ↓ 校验通过 传输适配器发送到外部系统 ↓ 返回回执 回执解析器这个流程的核心思想是Agent 可以自由地决定“做什么”但执行层必须严格保证“怎么做”。校验网关就是那个把“怎么做”牢牢锁住的角色。4. 实战构建支持 X12 校验的医疗 Agent 执行层下面我们用 Java 写一个简化但可运行的后端示例。为了便于理解我会把重点放在如何解析 X12 段。如何对 837 报文做基本语法校验。如何在校验通过后交给 Agent 执行层继续处理。4.1 项目结构先创建一个 Spring Boot 项目方向如下medical-agent-executor/ ├── pom.xml └── src/main/java/com/example/medagent/ ├── MedicalAgentExecutorApplication.java ├── x12/ │ ├── X12Segment.java │ ├── X12Parser.java │ ├── X12ValidationException.java │ ├── EdiValidationGateway.java │ └── ClaimValidationRule.java ├── agent/ │ ├── AgentTool.java │ └── SubmitClaimTool.java └── model/ └── ClaimRequest.java这里把 X12 相关代码单独放在x12包下方便后续复用和扩展成独立的 EDI 服务。4.2 添加依赖在pom.xml中加入 Spring Boot Web 和参数校验依赖。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version11/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependencies如果你用的是 Spring Boot 3.x只需要把父版本换成对应的 3.x 版本依赖写法不变。4.3 实现 X12 报文解析器X12 报文的解析并没有想象中复杂。核心思路是用段结束符拆出一个个段再用元素分隔符拆出段内元素。系统按照 EDI 标准规定的元字符来进行拆分。// 文件路径src/main/java/com/example/medagent/x12/X12Segment.java package com.example.medagent.x12; import java.util.Arrays; import java.util.List; public class X12Segment { private final String id; private final ListString elements; public X12Segment(String raw) { String[] parts raw.split(\\*, -1); this.id parts[0]; this.elements Arrays.asList(parts); } public String getId() { return id; } public String getElement(int index) { if (index 0 || index elements.size()) { return ; } return elements.get(index); } public int elementCount() { return elements.size() - 1; } Override public String toString() { return String.join(*, elements); } }这里需要注意一个细节split(\\*, -1)末尾的-1不能省略。它保证元素为空时也不会被丢弃。比如CLM*ABC123*250.00***11:B:1*Y*A*Y*Y中连续的分隔符之间有空元素省略-1会导致解析错位。接着实现解析器// 文件路径src/main/java/com/example/medagent/x12/X12Parser.java package com.example.medagent.x12; import java.util.ArrayList; import java.util.List; public class X12Parser { public ListX12Segment parse(String ediContent) { ListX12Segment segments new ArrayList(); // 实际项目中段结束符应从 ISA 段动态识别这里以常见的 ~ 为例 String[] rawSegments ediContent.split(~); for (String raw : rawSegments) { String trimmed raw.trim(); if (trimmed.isEmpty()) { continue; } segments.add(new X12Segment(trimmed)); } return segments; } }在实际生产环境中ISA 段的第 16 个元素就是段结束符第 4 个元素是元素分隔符第 17 个元素是子元素分隔符。更严谨的做法是先提取 ISA 段前 106 个字符从固定位置解析出这些元字符再按元字符拆分后续内容。上面的示例是为了演示主流程所以先固定用*和~。4.4 实现 837 校验规则接下来实现针对 837 事务集的校验规则。这一步是整个执行层的核心。我们需要检查报文中是否存在 ST 段且 ST 段第一个元素必须是 837。报文中是否存在 CLM 段CLM 段至少包含 2 个元素。报文结尾是否包含 SE 段且 SE 段第一个元素与 ST 段事务集编号对应。// 文件路径src/main/java/com/example/medagent/x12/ClaimValidationRule.java package com.example.medagent.x12; import java.util.List; public class ClaimValidationRule { public void validate(ListX12Segment segments) { boolean hasST false; boolean hasCLM false; boolean hasSE false; for (X12Segment segment : segments) { String id segment.getId(); if (ST.equals(id)) { hasST true; if (!837.equals(segment.getElement(1))) { throw new X12ValidationException(ST 段事务集编号不是 837请检查业务类型); } } if (CLM.equals(id)) { hasCLM true; if (segment.elementCount() 2 || segment.getElement(1).isEmpty()) { throw new X12ValidationException(CLM 段缺少必需的索赔编号); } } if (SE.equals(id)) { hasSE true; } } if (!hasST) { throw new X12ValidationException(报文中缺少 ST 段); } if (!hasCLM) { throw new X12ValidationException(837 报文中必须包含至少一个 CLM 段); } if (!hasSE) { throw new X12ValidationException(报文中缺少 SE 段); } } }编写自定义异常// 文件路径src/main/java/com/example/medagent/x12/X12ValidationException.java package com.example.medagent.x12; public class X12ValidationException extends RuntimeException { public X12ValidationException(String message) { super(message); } }4.5 封装校验网关校验网关的作用是把“解析报文”和“校验规则”组合起来对外提供一个统一的入口。有了这一层Agent 工具调用时不需要自己处理 X12 解析细节。// 文件路径src/main/java/com/example/medagent/x12/EdiValidationGateway.java package com.example.medagent.x12; import java.util.List; public class EdiValidationGateway { private final X12Parser parser new X12Parser(); private final ClaimValidationRule claimRule new ClaimValidationRule(); public void validate837(String ediContent) { System.out.println( EdiValidationGateway 开始校验 ); ListX12Segment segments parser.parse(ediContent); claimRule.validate(segments); System.out.println(校验通过共解析到 segments.size() 个段); } }4.6 把校验网关接入 Agent 工具调用这一节演示 Agent 的工具层如何调用校验网关。我们使用一个最简化的案例当大模型决定执行“提交索赔”工具时执行层先完成 X12 报文封装再调用校验网关。先定义一个索赔请求模型// 文件路径src/main/java/com/example/medagent/model/ClaimRequest.java package com.example.medagent.model; public class ClaimRequest { private String claimId; private String patientName; private String diagnosisCode; private String amount; private String providerName; public String getClaimId() { return claimId; } public void setClaimId(String claimId) { this.claimId claimId; } public String getPatientName() { return patientName; } public void setPatientName(String patientName) { this.patientName patientName; } public String getDiagnosisCode() { return diagnosisCode; } public void setDiagnosisCode(String diagnosisCode) { this.diagnosisCode diagnosisCode; } public String getAmount() { return amount; } public void setAmount(String amount) { this.amount amount; } public String getProviderName() { return providerName; } public void setProviderName(String providerName) { this.providerName providerName; } }然后是一个简单的 837 报文构建器// 文件路径src/main/java/com/example/medagent/agent/X12ClaimBuilder.java package com.example.medagent.agent; import com.example.medagent.model.ClaimRequest; public class X12ClaimBuilder { public String build837(ClaimRequest request) { StringBuilder sb new StringBuilder(); sb.append(ISA*00* *00* *ZZ*SENDER *ZZ*RECEIVER *230101*1200*^*00501*000000001*0*P*:); sb.append(~); sb.append(GS*HC*SENDER*RECEIVER*20230101*1200*1*X*005010X222); sb.append(~); sb.append(ST*837*0001); sb.append(~); sb.append(BHT*0019*00*).append(request.getClaimId()).append(*20230101*1200*CH); sb.append(~); sb.append(NM1*41*2*).append(request.getProviderName()).append(*****46*123456789); sb.append(~); sb.append(HL*1**20*1); sb.append(~); sb.append(NM1*85*2*).append(request.getProviderName()).append(*****XX*1234567890); sb.append(~); sb.append(HL*2*1*22*1); sb.append(~); sb.append(NM1*IL*1*DOE*JOHN****MI*123456789); sb.append(~); sb.append(HL*3*2*23*0); sb.append(~); sb.append(NM1*PR*2*INSURANCE_COMPANY*****PI*INS001); sb.append(~); sb.append(CLM*).append(request.getClaimId()).append(*).append(request.getAmount()).append(***11:B:1*Y*A*Y*Y); sb.append(~); sb.append(HI*BK:).append(request.getDiagnosisCode()); sb.append(~); sb.append(SE*13*0001); sb.append(~); sb.append(GE*1*1); sb.append(~); sb.append(IEA*1*000000001); sb.append(~); return sb.toString(); } }然后定义 Agent 工具接口和实现// 文件路径src/main/java/com/example/medagent/agent/AgentTool.java package com.example.medagent.agent; public interface AgentTool { String getName(); String execute(String inputJson); }// 文件路径src/main/java/com/example/medagent/agent/SubmitClaimTool.java package com.example.medagent.agent; import com.example.medagent.model.ClaimRequest; import com.example.medagent.x12.EdiValidationGateway; public class SubmitClaimTool implements AgentTool { private final X12ClaimBuilder claimBuilder new X12ClaimBuilder(); private final EdiValidationGateway validationGateway new EdiValidationGateway(); Override public String getName() { return submit_claim; } Override public String execute(String inputJson) { // 实际项目中这里会把 JSON 反序列化为 ClaimRequest ClaimRequest request parseRequest(inputJson); // Agent 执行层先构建报文 String ediContent claimBuilder.build837(request); // Agent 执行层再做 X12 标准校验 validationGateway.validate837(ediContent); // 校验通过后才允许进入真正的传输环节 return 索赔报文已通过 X12 837 校验可以进入传输队列claimId request.getClaimId(); } private ClaimRequest parseRequest(String inputJson) { // 简化处理实际项目中建议使用 Jackson 或 Gson ClaimRequest request new ClaimRequest(); request.setClaimId(CLAIM001); request.setPatientName(JOHN DOE); request.setDiagnosisCode(I10); request.setAmount(250.00); request.setProviderName(TEST_CLINIC); return request; } }上面的parseRequest简化了 JSON 解析实际项目中请用 Jackson 的ObjectMapper完成。这里为了控制示例长度直接构造对象。下面写一个简单的运行入口// 文件路径src/main/java/com/example/medagent/MedicalAgentExecutorApplication.java package com.example.medagent; import com.example.medagent.agent.SubmitClaimTool; public class MedicalAgentExecutorApplication { public static void main(String[] args) { SubmitClaimTool tool new SubmitClaimTool(); String result tool.execute({}); System.out.println(result); } }4.7 运行与验证直接运行main方法预期控制台输出类似 EdiValidationGateway 开始校验 校验通过共解析到 14 个段 索赔报文已通过 X12 837 校验可以进入传输队列claimIdCLAIM001如果把CLM*这一行的索赔编号去掉例如构造出一个空的 claimId校验网关就会抛出异常Exception in thread main com.example.medagent.x12.X12ValidationException: CLM 段缺少必需的索赔编号这就是执行层约束发挥作用的过程。AI Agent 的规划层可以自由决定要提交哪笔索赔但执行层会确保只有符合 X12 837 规范的报文才能继续往下一环节走。5. 常见问题与排查思路在医疗 AI Agent 执行层开发中比较常见的错误可以分为几类。下面用表格汇总问题现象常见原因解决思路解析后段数量不对没有正确识别段结束符或空行被当作段处理从 ISA 段固定位置提取分隔符跳过空白段CLM 段缺少编号上游数据字段映射错误或 LLM 生成的索赔编号缺失在生成报文前校验业务字段补全必填项前不允许拼接ST 段事务集编号不是 837Agent 选错了工具或业务类型映射错误工具调用参数里强制指定事务集类型校验网关第一层直接拦截发送后收到 997 回执错误报文基本语法通过但业务层校验失败解析 997 中 AK2 和 AK3 段定位具体事务集错误日期格式错误X12 多数日期使用 CCYYMMDD 格式内部接口传成了带横杠的格式在映射层统一做格式转换不要依赖 LLM 自动处理日期再补充两个排查思路第一建议把解析前后的报文打日志。重点观察从 ISA 到 IEA 的完整链路是否齐全。一份 837 报文如果缺少 IEA接收方会认为交换没有正常结束。第二当 Agent 接入多家保险公司时不要假设所有接收方都使用同一版本标准。很多机构使用 004010 或 005010还有少量扩展版本。校验网关里的规则应该是可配置的而不是写死在代码里。6. 医疗 AI Agent 执行层的最佳实践6.1 把标准校验放在模型输出之后这是最重要的一条建议。AI Agent 项目的自然语言处理能力再强执行层也必须保留硬编码的规则校验。模型输出先经过结构化提取再经过 X12 校验网关最后才允许发送。不要把“模型不会出错”当作假设。6.2 明确职责边界Agent 规划层负责拆解意图工具层负责定义可执行的动作执行层负责技术校验传输层负责对接外部系统。每一层只做自己该做的事。如果执行层代码里出现了大量业务意图判断说明边界被破坏了。6.3 日志与审计要留够信息医疗交易对审计要求通常很高。每次 Agent 提交交易时至少记录原始的工具调用参数。生成的 X12 报文全文。校验网关的校验结果。外部系统回执内容。对应的时间戳和会话 ID。注意这里涉及患者信息时在真实环境中必须严格按合规要求做脱敏、权限控制和加密存储。不要在日志里输出完整的敏感个人信息。6.4 设计可配置的规则引擎不同保险公司对 837 报文的业务要求可能有细微差别。例如某些机构要求必填自定义的 REF 段另一些机构则不需要。建议把“必填段”“可选段”“元素格式”等规则抽成配置这样在接入新机构时不需要修改核心代码只需要调整配置。6.5 做好测试数据隔离在开发阶段不要直接连接生产环境的 EDI 网关。建议准备一套测试用的 837、835 报文样例配合本地校验服务做自动化测试。测试样例至少要覆盖正常通过的情况。缺少 CLM 段的情况。ST 段类型错误的情况。SE 段缺失的情况。日期格式错误的情况。6.6 考虑异步化与重试医疗 EDI 交易往往不是瞬时返回结果。Agent 提交 837 后可能需要等待接收方通过 997、277 或 999 回执来确认结果。执行层应该支持异步状态流转而不是同步等待。重试时要注意幂等避免因为网络重发导致同一笔索赔被重复提交。7. 总结从这一套示例能看出来医疗 AI Agent 的落地难点并不全在大模型本身更多在于执行层有没有建立足够的确定性和标准约束。X12 作为医疗行业数据交换的重要标准恰恰为 AI Engineer 提供了这样一套可验证、可审计、可复用的规则边界。本文围绕“医疗 AI Agent 实战”这条主线拆解了 AI Agent 执行层的结构讲清了 X12 报文的基础语法与常见事务集并从零实现了一个包含解析器、校验规则、校验网关和工具调用的最小执行层。代码虽然精简但已经覆盖了医疗交易场景中最核心的“先校验、再发送”思想。如果你正在做一个医疗相关的 AI Agent 项目我建议下一步从三件事开始收集你们业务实际用到的 X12 事务集样例比如 837、835、270/271。把这些样例整理成自动化测试用例固化进 CI/CD 流程。在 Agent 工具调用链中加入校验网关让标准校验成为执行层的默认防线。医疗行业的 AI Agent 越往后做行业标准的重要性会越明显。掌握 X12 约束不仅是为了对接现有系统更是为了在 AI 时代构建真正值得信赖的医疗自动化服务。