跨国深谈← 返回←给医疗理赔智能体套上 X12 护栏

给医疗理赔智能体套上 X12 护栏

关联

人物 Vasant Kearney

概念 智能体 · X12 · harness · 护栏 · 记忆 · 多模态 · EHR

这一集是一场技术大会演讲，主题是医疗领域的智能体工作流——具体说，是怎么让 AI 智能体安全、可靠地替医疗机构跟保险公司打交道。演讲者一开场就点明目标：把与保险交互的总体成本降下来，同时改善患者体验。他提醒在座的技术人：我们喜欢为技术本身兴奋，但任何方案都必须扎根在这两点之一上，否则就没有意义 。

执行层：模型从“会说”到“会做”

演讲者先快速回顾了 AI 的演进——从神经元、卷积神经网络，到 transformer,再到聊天界面的大语言模型，最后到今天的智能体执行层(Claude Code、Codex 这类工具，以及他所在机构的内部系统)。所谓智能体执行层，就是模型采取行动的能力：查询数据库、探索数据模式、结合数据查代码，甚至进行真正的保险交易、打电话、查看网页门户、对接 EHR(电子健康档案)系统 。

这里有个关键区分：其中一些行动有写入的影响——比如智能体在操作桌面、对接不同的 PMS(诊所管理系统)时，至少会产生用户日志。这是安全设计的起点。

记忆是另一个核心概念。Claude Code 这类工具用本地记忆、直接写桌面，但在企业级医疗场景里不能这么做——他们把记忆放在数据库里，以获得逻辑上的隔离 。

换新模型 ≠ 系统会更好

一个容易踩的坑：当你引入更强、参数更多的新模型时，不能只是替换模型然后假设系统会变好。新模型在某些 eval 上按指标衡量确实更好，但这不等于它在你设计的系统里的所有场景都更好——“所以你真的必须从头重做所有事情”，确保 eval、测试、验证全部就位，才能引入新模型而不弄坏系统 。

支票的教训：细节全在 harness 里

演讲者用兑现支票作类比：手写数字识别早就解决了，但你不能因此就说“可以自动存支票转账了”——真做起来，你得识别支票上的各种字符、确保它与基础设施的其他部分对得上、确保钱进对账户。理赔也一样：从资格认定到让保险公司把钱打进医疗服务提供方的账户，中间是一大堆微小的 AI 步骤，每一步都必须在严格的限制内安全运作 。

他把围绕智能体推理的所有“螺母和螺栓”——记忆、工具、检查、权限、交接、eval——统称为 harness(护栏装置)，在医疗理赔语境下，这个 harness 的核心就是 X12 。

LLM 在约束里反而如鱼得水

X12 是医疗保险行业的电子数据交换标准——一套规则体系，是你和保险公司沟通内容之间的底层契约。演讲者的观察很有意思：就像 COBOL、TypeScript 这些约束严格的语言一样，LLM 在被约束时工作得最好——取值清晰、有限、可预测，而 X12 恰恰就是这种东西 。

理赔流程可能涉及约 50 个步骤，而且很多是多模态的(要处理图像)。这带来两个问题：一是贵、耗时长；二是每一步都是引入错误的机会，错误会沿着系统往下传播。所以有一个“有依据、可以被拒绝”的东西非常重要——有严格的护栏，就能在出现错误时拒绝它 。

反过来，如果把整个系统硬编码、抛弃智能体流程，你的代码会膨胀到无法管理，需要一个庞大的工程团队。所以核心是在“完全自由的智能体推理”和“硬编码”之间找平衡。

他们的做法是引入分层的记忆：伙伴级、组织级和用户级的记忆。比如多站点医疗组织里的人往往日复一日做同样的事，用户提几个词，系统就能推断“他通常做资格验证，通常在这个上下文里做” 。

但持久记忆有个副作用——偏见。也许那个人今天不想做和昨天一模一样的事，而你却引导他去做和昨天一模一样的事。所以必须取得平衡，并确保任何用户都能跳出这个模式 。

神来之笔：打电话也是一笔 X12 交易

理赔生命周期里每一步都有对应的 X12 事务：预约时有资格查询，治疗时涉及保险覆盖的范围，影像资料(有时 X 光片本身就是证据文件)对应 275 事务，提交理赔，最后是付款入账。

演讲者分享了一个他承认“事后回想很显然”的洞见：你打电话给保险公司，归根结底就是一笔 X12 交易。你说“我在问这个病人的资格”——那就是一个 270 资格请求；你查理赔状态——那也有 X12 依据。所以当智能体操作桌面、操作浏览器、对接影像系统时，每一步背后都可以落到一个标准化的 X12 事务上(银行 ACH 不是 X12,但同样是结构化交易)。

这样做还有一个美妙之处：这些事务全部是公开的标准，不是你自己的 schema。如果让智能体自己给你生成一个 schema,你会得到各种乱七八糟的东西；但建立在公开标准上，一个新来的工程师也能立刻看懂整个系统 。

保险公司没有“真值”这回事

这是全场最反直觉的部分。保险公司给你的 X12,不等于就是真的。

保险公司告诉你一件事时，信息可能来自不同团队——他们的网页浏览器、电话系统、X12 层、FHIR 接口，甚至可能是外包给另一家公司做的。所以必须理解：这里没有 ground truth(真值) 。

更糟的是，所有这些系统还可能对错误的信息达成一致：打电话、查网页、查 X12,三个渠道都说“这个病人有覆盖”，你给病人做了治疗，然后理赔被拒——理由是病人在那段时间没有被覆盖 。

他们的应对方式：不管信息是不是以 X12 的形式来的，把所有事务都归结为自己内部的“半正确 X12”——在下游证据证明它不正确之前，先当它是正确的。而任何来自保险公司的信息，任何时候都可能是错的、之后都可能被更新。

演讲者半开玩笑地说：“所以祝你好运吧。”

在整个患者旅程里，这些证据可能就是影像本身——比如一次 CBCT(锥形束 CT)的图像和切片，可能就是保险公司索要的证据。而理赔单的本质是一张收据和合同：你在声明“我做了这项工作”，它被密封发出，现在球在保险公司的场地上——他们该付钱了 。理赔的推进也有明确的节点：999 确认语法无误、状态更新确认收到、没收到就打电话核实、最后是 835 付款收据(EOB)。

完全被 AI 说服，同时对 AI 保持怀疑

收尾时演讲者给了态度层面的忠告。他说自己“完全被 AI 说服了”(fully AI-pilled),但正因为如此，引入大语言模型、小模型时，必须用一种非常怀疑、保守的方式。“这些东西会犯错”——甚至不该说它们犯错，是我们在设计它们时犯了错，我们可能会把它们设置成注定失败 。

最后是成本这条底线：不要用性能过强、价格过贵的模型。如果一个每天要做一千次的常规任务，交付一次的成本变得超级昂贵，那就完全背离了“把总体成本降下来”这个最初的目标 。

本集带走

• 先定目标再动手：医疗智能体的一切设计都要扎根于两件事——降低保险交互成本、改善患者体验，为技术而技术没有意义。
• 用 X12 当智能体的护栏：LLM 在严格约束下表现最好；把打电话、查门户、传影像这些交互统统归结为标准 X12 事务，错误可以被护栏识别并拒绝。
• 用公开标准替代自造 schema:X12 事务定义全是公开的，新工程师和智能体都能立刻理解，不要让智能体自己发明 schema。
• 假设保险公司会给你错的信息：电话、门户、X12 可能互相矛盾，甚至一致地错；维护一份自己内部的“半正确 X12”,等下游证据来推翻它。
• 换新模型必须重做验证：eval 变好不等于你的系统变好，引入新模型前把测试和验证全部重建。
• 持久记忆要留逃生口：用户记忆能提效，但会把人锁死在昨天的习惯里，必须保证用户能随时跳出。
• 既被 AI 说服、又对 AI 怀疑：错误往往是我们自己设计出来的；每天跑一千次的任务尤其要用够用、便宜的小模型，别为常规操作买单贵模型。

但如果你把整个系统硬编码，说我们要抛弃这整个智能体流程，你就限制了自己，或者你的代码会膨胀到完全无法管理。
But if you hard code your whole system, you say we’re going to throw out this whole agentic process, you limit yourself or your code can explode to be just unmanageable.
—— Vasant Kearney · [10:54]