刘浩南 刘浩南-AI实战派 2026年9月13日 07:18
我给 HaoEMR 接入了 14 组AI医助团队、58 个AI子医助。
它们现在可以读取授权范围内的资料，调用真实模型，返回带依据的候选结果。文书类医助还能给出可编辑的段落，由医生决定采用哪些内容。
先看系统入口。
登录后的临床业务门户，选择AI中心可以查看全部AI能力。
EVA 的历史文书任务。医生可以继续查看依据、进入对应病历，或选择候选段落。
9 月 6 日，在独立合成病例环境中，58 个AI子医助逐项完成了真实 DeepSeek 调用；候选转提醒、转任务、领取和确认关闭也逐项验证。10 类文书医助另外验证了段落采用与文书版本保存。
这也是一次以往工作积累后的一次尝试，我拆开讲讲 医疗 Harness ：一次任务怎样拿到正确资料，如何执行，失败后怎么办，以及模型输出最后凭什么能进入病历。不一定对，如果不对请大家批评指正。下面我们对AI医助统一叫EVA。
1、我先给AI医助划了一个工作范围
EVA 的 14 组团队里，有就诊摘要、文书起草、病历质控、结果闭环、诊疗协同，也有心血管、血糖管理、重症和中医等方向。
团队下面再分岗位。文书起草里的门诊记录、首次病程、查房、会诊和出院记录，各自需要的输入与产出不同；诊前摘要和出院摘要，也不会围绕同一个问题整理资料。
团队与子医助的分工。这里的“子医助”是任务角色，共享部分模型与运行机制。
首先，这些子医助并不是同一段 Prompt 换了几个名字。
主医助负责把一次任务组织起来，子医助承担具体步骤，候选结果再汇总返回。当前实现按已发布的组合与阶段选择节点，按确定的顺序执行；目前主要处理文本业务为主，还没有把任意模型动态组队、医学画图、影像病理专属模型之类的能力算进去。
2、一份病例摘要，背后实际发生了什么
医生从工作页面发起任务，系统先确定机构、操作者、患者、就诊、目标文书和资料范围。运行层检查医助版本、模型部署、预算与授权，再把任务交给后台 worker。
worker 读取配置中的节点，通过工具取得业务事实和知识，调用模型，检查返回结构与来源，最后生成待审阅候选。
当前医疗 Harness 的运行关系。
这里有几个明确分工。
运行编排管理任务和状态；工具网关读实际业务对象；模型网关处理供应商请求、返回值、用量和错误；岗位技能给出具体任务要求；验证与业务接口守住结果采用的条件。
DeepSeek harness 给了我开发与运行机制上的参考，我也用它直接参与了项目开发。HaoEMR 的医疗运行层则围绕自己的患者、文书、权限和任务实现。
3、最先要做对的，是“这是哪个患者”
项目开发过程真的出现过这样的问题：选了王某某提问，点结果穿透回业务页，打开的却是张某的病历。
模型回答落到另一个患者身上，整条流程也就错了。
因此，患者上下文不能只是 Prompt 开头的一段姓名和病史。服务端需要核实这次任务的患者、就诊、用途、机构和操作者；租约保存授权范围和有效性，工具读取时继续检查。
我也给无患者任务保留了单独场景。用户只想查一段知识，就不该为了满足必填字段，随便挂在一个患者下面。
进入模型之前，资料还要按任务选择。做本次门诊摘要，并不意味着可以把这个患者所有历史资料和全院配置一股脑塞进去。资料范围越大，越难判断什么是当前任务真正需要的。
4、工具返回的内容，需要能回到原处核对
HaoEMR 的工具会读取病历、诊断、医嘱、结果、生命体征、护理与专科记录，也会读取知识正文、版本和关系。
工具目录管理受控能力及版本。
我要求返回值保留来源类型、标识和版本。这样，模型在候选里引用某条事实时，后面可以核对它来自哪份报告、哪次记录。
“患者有某项风险”来自已保存的诊断、检查结果，还是模型的推测，需要分得开。模型给一个看起来像引用的字符串，不能自动变成系统认可的来源。
知识工具同样如此。检索命中了标题，还需要取得正文；取得正文，还需要知道来源和版本。某份资料在知识库里存在，不等于已经通过审核，也不等于适用于当前患者。
图谱在这里更适合帮助发现关联与定位来源。最终采用内容时，仍然要回到可核对的资料和实际业务事实。
目前把知识中心独立做出来了。它既给医生用，也给AI医助提供资料，但两边都需要遵守同一套版本与审核边界。
5、Skill 要进入请求，才算真的参与了工作
早期测试发现过一个问题：Skill 在目录里了，依赖检查也能通过，但没有产生实际模型请求。
现在，应用维护版本化的岗位技能资源。运行时会加载对应角色的执行步骤，并要求模型交付结构化结果：本次成果、事实依据、缺失资料和风险提示。文书类任务额外返回可编辑段落。
技能目录负责管理与依赖
文书段落只接受明确的字段范围，例如主诉、现病史、评估和计划。缺少资料就列入缺口，不能编一个正常值把表单填满。签名、权限、执行完成之类的声明，不会混进文书段落里。
还有一点：病例和检索资料属于输入，不能反过来改写应用维护的技能规则。输入正文里即使出现“忽略规则”之类的话，也不会因此扩大工具权限或改掉写入条件。
当前仍有不少可以继续改进的地方，比如更细的场景区分、专业知识适用性和异常输入覆盖。但“加载了哪个版本、要求产出什么”已经有实现了。
6、换模型时，业务规则仍然要成立
模型服务管理供应商、接口、凭据引用、部署状态和数据处理边界。一次任务使用哪个部署，也要进入运行记录。
模型服务页面展示实际配置与连接状态。
我把供应商请求细节放进模型网关，岗位定义不需要到处拼 API 请求。这样后面调整模型，至少不用同时改所有业务入口。
不过，统一网关并不能抹平模型差异。结构化输出是否稳定，长结果会不会截断，缺资料时会不会如实返回，都需要重新验证。
运行层还要检查数据处理范围。当前任务是否允许相应的云端处理，所选部署是否仍有效，这些都由系统检查，不能只凭调用成功就算结束。
7、失败要留痕，任务也要能停下来
58 个子医助的第一轮真实运行，成功了 37 个，失败了 21 个。
错误里有来源校验失败、工具失败、返回结构不合要求和输出截断。比如中医工具曾查询一个记录表里并不存在的更新时间字段；初始化环境也漏过专业工具。模型还没开始发挥，工具这一步就已经出了问题。
运行监测显示实际任务、模型与工具调用、耗时和用量。
这其实就是要求 Harness 把过程记下来：子医助开始、工具完成、模型请求、候选生成、失败代码，分别是什么状态。
后台 worker 通过租约领取任务，并在执行检查点续租、检查取消与预算。超过用量或时长限制，不能继续无边界执行。关键步骤失败会影响整个任务；非关键步骤失败，也要在部分结果和缺口里明确表现。
取消同样不是“点一下就假装消失”。外部模型调用可能已经发出，运行层需要在返回后的检查点阻止后续采用，并留下已经发生的调用记录。
目前的代码已有这些运行机制，更复杂的恢复、并发和故障场景仍需要继续覆盖。至少现在排查时可以问得具体：失败在工具、模型、校验，还是业务承接？
8、医生点“采用”，才到了最容易漏做的那一步
文书候选返回以后，医生可以选择段落，带入编辑区继续修改。保存时，系统重新核对患者、就诊、文书和来源版本，并保留候选与文书之间的关系。
如果候选生成后，原文书又被改过，就不能拿旧候选继续覆盖。换了患者，也不能沿用上一次任务的来源。
提醒则走另一条承接流程：候选转提醒，提醒转任务，任务被领取，再由来源业务确认完成。重复提交、跨患者采用和过期来源，都有对应检查。
我希望前端很简单：依据是什么，缺什么，哪些内容可以采用，采用以后去了哪里。
后台可以有编排、租约、模型与工具台账。医生不应该先读懂这些词，才能完成一次复核。
9、下一步，我会怎么判断它有没有用
评测与发布保存规则、版本和状态
先检查工程功能：资料有没有读到，模型有没有实际调用，结果结构是否符合约定，来源能否核对，候选能否进入正确业务。
再检查医学内容：关键事实有没有错，风险有没有漏，知识是否适用，缺资料时是否仍给了确定建议。这里需要明确的病例和专家判定依据。
最后回到医生的工作：一份病历到底少写了多少，候选需要改多少，复核花了多久，最终有没有减少负担。
58 个子医助已经让我有了一套可以开展这些验证的系统。继续增加名字，对我来说没有把现有角色做稳更有吸引力。
这也是我现在对医疗 Harness 最直接的理解：医生交出去一项任务，系统能说清它读了什么、做了什么、哪里没做成，最后由谁决定结果进入业务。
如果你也在做医疗 Agent，欢迎一起交流，我目前也在构思一个万能插件工具的模式，可以兼容各个厂商，信息科能自己维护管理的医疗Agent。
微信扫一扫赞赏作者
收录于刘浩南AI产品