“我们不是要做一个能替代医生的糖尿病风险筛查系统而是要做一个让医生敢用、能复核、出了争议还能翻回原始依据的系统。”接手项目两个月后团队才真正理解项目标题里那几个词的重量。DIASENTINEL 表面看是一个基于指南的多代理糖尿病风险筛查系统但真正吃功夫的地方不在模型精度而在“可审计”三个字。它意味着系统任何一个判断都不应该是凭空出现的黑盒输出而应是一条可以沿着指南条款、代理分工、输入证据和中间推理链一路回溯的逻辑路径。过去几年我见过太多健康类 AI 项目倒在没有病例愿意点击“采纳”这一步。问题通常不是算法不够聪明而是临床人员根本不知道它为什么给这个分级、为什么没提某个风险因素、为什么和指南某个条目不一致。越自动化越需要一个能讲清楚每一步的“账本”。DIASENTINEL 这类设计之所以值得关注不是因为它把筛查变成了一个 AI 流程而是因为它把 AI 流程变成了一套可以被审计、被复核、被复盘的工作流。这个思路同样适用于体检中心、慢病管理、社区健康档案和任何依赖规则与证据的结构化决策场景。1. 为什么“可审计”和“指南为基”是这类 AI 系统的生死线1.1 黑盒预测在医疗场景里为什么走不通风险筛查不是一个“预测完就结束”的任务。医生的职责不只是告诉你“有风险”还要告诉你风险从哪里来、依据是什么、下一步建议为什么是 A 而不是 B。糖尿病患者筛查更特殊漏掉的可能是无症状人群误报的又会占用随访资源。这时一个只输出“高风险”三个字的模型在临床上几乎没有任何抓手。更实际的问题是责任归属。如果系统给老年人打上“高风险”标签却没有引用指南里基于年龄和体重指数的判断依据医生不会签这个结果。如果系统给某个患者判为“低风险”却忽略了指南中要求核查的家族史条目审计时模型要能说出为什么忽略或者有没有通过其他条件补偿。这个逻辑只有可审计系统才能支撑黑盒输出做不到。所以 DIASENTINEL 里那个“Auditable”不是锦上添花是整个方案能站住脚的前提。它的目标不是做一个聪明的打分器而是做一个“每一步都有据可查”的决策流程。1.2 指南为基意味着把规则当成程序的骨架所谓 Guideline-Grounded本质上是把临床指南里的提醒式条件转成可执行的逻辑节点。比如指南规定“年龄大于等于 40、有糖尿病家族史、BMI 超过正常范围且缺乏运动的高危人群应进入进一步检查路径”系统就需要把这类文本变成可以逐行运行的规则而不是让大模型自由生成判断。这样做有三个明显收益决策可对照。任何一条输出都能对应回指南中的编号或章节。结果可复制。同一份输入在不同批处理时间点跑结论必须稳定。更新可控制。指南修订后只要调整规则层不需要重新训练全部模块。把指南落成代码并不是把医生经验机械压缩而是把原本存在于人脑里的判断流程变成显性配置。这对工程团队来说是件好事因为你可以像做代码评审一样去审查医疗规则。1.3 多代理组合不是炫技是为了贴近协同分工单代理系统也能实现“规则跑一遍再打分”为什么还需要多代理原因是真实筛查流程本身就是分工协作的。一个角色负责收集和校验输入数据。一个角色负责调取适用的指南条目。一个角色负责把患者特征对到条目上得出判断。一个角色负责记录整个过程、生成可读报告。每个角色作为一个代理可以让逻辑边界和工作单元都变得清晰。某个环节出错时不需要回滚整条流水线只需要检查对应代理的输入输出。这种设计与可审计是天然匹配的因为系统多了中间产物每一个代理的决策都被留痕。2. 把 DIASENTINEL 这类系统拆成看得见的结构2.1 代理阵容怎么划分更合理从一个工程蓝图的视角看一个可审计的糖尿病风险筛查多代理系统通常会包含几个基本角色每个角色有明确职责和出口文档。下面是一个通用拆法实际落地时可以按临床场景调整代理名称主要职责可审计输出数据预处理代理清洗输入记录检查缺失字段和取值范围数据质量报告、缺失项标记指南解析代理将选定指南条目转换成可调用规则规则版本号、适用人群条件风险推理代理完成患者特征与规则条件的匹配命中规则列表、风险评级依据报告生成代理产出面向医生或患者的筛查结论可读报告、异议标记、复核字段在这套结构里没有任何一个代理能独立产生最终结论。风险推理代理拿到的规则一定由指南解析代理提供并记录报告生成代理拿到的评级一定由风险推理代理给出。就像公司里的审批流程每一级都要签上自己的名字和依据。2.2 代理之间的信息流为什么不能被大模型串讲代替如果把所有指南和患者数据丢给一个大模型直接输出结论表面上流程更短实际上可审计性会断掉。你拿到的只是语言模型一句“根据指南该患者具有较高风险”但模型究竟是引用哪一条、权重如何计算、为什么没有触发某条排除规则都不可控。代理结构讲究的是把信息流转变成有中间产物的过程数据预处理代理对输入做清洗输出结构化的患者画像。指南解析代理按人群标签筛选指南条目输出当前患者适用的候选规则集。风险推理代理逐条运行候选规则记录命中与未命中原因。报告生成代理把命中原因整理成最终意见并把审计 ID 写入日志。关键一步在于候选规则和命中规则都必须是显式数据而不是隐含在模型权重里。这样设计看着步骤多却为后续调试、追溯和持续优化留足了空间。2.3 最小流程示例从一条记录到一张审计卡下面是一个简化但完整的流程示意图类似伪代码结构用来帮助理解这类系统如何工作输入一条个人健康记录 1. 数据代理 - 检查年龄、性别、BMI、家族史、血糖值等字段 - 输出{age: 45, bmi: 26.8, ...} 2. 指南代理 - 基于记录中的年龄组选择筛查指南 - 输出规则列表 rule_id: [A1, A2, B1, ...] 3. 推理代理 - 遍历规则列表 - 对命中规则输出 hityes命中字段与数值差异 - 对未命中规则输出 hitno 及原因字段 - 输出risk_levelmoderate 4. 报告代理 - 汇总推理结果与关键指标 - 输出可读报告 审计记录实际操作里报告里还会带一个拼接的追踪信息例如audit_trace_abc123医生点开就能看到完整链条。3. 从原型到可用我建议按这个顺序落地3.1 第一步把指南变成可测试的条目而不是急着写代码DIASENTINEL 这类项目的工程起点不是写模型而是把筛选指南做结构化。建议团队先完成两件事把指南文本按“适用人群、触发条件、冲突排除、执行建议”四列拆出来。给每一条规则设计唯一编号并记录规则来源指南版本号。这是后面所有审计的基础。规则没有编号代理之间的日志就会变成一锅粥。更稳妥的做法是先找包含 20 到 30 条规则的指南章节做试点搭好完整流程后再逐步扩展到全部内容。如果一开始就把整本指南塞进来规则冲突和边界问题会淹没你。3.2 第二步选定代理通信和数据交换格式多代理系统最麻烦的不是每个代理的内部算法而是代理之间的数据契约。如果风险推理代理拿不到数据代理输出的标准结构后续规则匹配就是空中楼阁。落地时建议先定义统一的中间数据格式例如 JSON 格式的患者画像和规则判定结果。核心字段建议包含{ patient_id: P001, risk_level: moderate, matched_rules: [ { rule_id: DM-2019-7, matched_condition: age40, actual_value: 45 } ], unmatched_rules: [], audit_trace: 2025-01-15-001 }这样一个结构既能让人读也能让机器读。后续无论换哪个代理实现只要遵循契约整个流程就不会断裂。3.3 第三步单条记录跑通再谈批量先不要立刻做并发和批量筛查。先准备假阳性、假阴性、边界值这样几条典型记录跑通从输入到审计报告的单条链路。我建议的验证顺序是用一条完全符合某条风险规则的记录确认命中正确。用一条“部分符合、部分缺失”的记录确认缺失项能否被完整记录。用一条可能触发规则冲突的记录确认代理之间的冲突裁决策略是否明确。最后再检查整个 trace 日志是否可以被完整复现。如果第一步就跑出与规则不相符的结果通常先查数据代理清洗逻辑再查推理代理的规则匹配语句而不是先质疑模型选型。3.4 第四步让模型返回到它被放置的地方很多团队会在风险推理代理里加入大模型希望它能处理更复杂的语义理解。这本身可以但要给大模型设一个明确的“可输出边界”。大模型更适合做报告润色、非结构化文本抽取、复述指南措辞不适合做规则命中的最终裁决。规则匹配仍然要回到规则引擎或纯代码判断上。这样可以保证核心结论可审计大模型的作用被收敛到文字表达层。4. 可审计不是挂在嘴上要当成系统第一公民来设计4.1 审计日志要记录哪些内容很多项目把日志当成事后加上的补充模块结果上线后才发现很难复盘。DIASENTINEL 这类系统应该把审计日志作为主要输出之一来设计。至少应包含几类信息版本信息指南版本号、规则集版本号、模型版本号。输入信息原始记录的摘要、数据清洗前后对照。规则信息命中了哪些规则哪些条件失败哪些字段缺失。决策信息风险定级结果、影响定级的关键权重或规则、排除理由。产生时间代理执行顺序与时间戳。这些日志不仅要写到文件里还要让医生在前端界面里能直接查看降低复核成本。4.2 最容易踩的三个坑第一个坑是规则版本没固定。今天用 2020 版指南跑的结论明天被系统悄悄加载了新版规则审计时就会对不上。解决方法是把规则版本写进每次筛查的审计 ID 中后端运行时锁死当前版本。第二个坑是中间产物被覆盖。有些团队为了节约存储只保存最终风险等级把中间命中结果删掉。一旦遇到纠纷就没办法解释为什么得到这个结果。正确的做法是至少保存溯源 JSON 和日志文件并按照合规要求设置保留期。第三个坑是代理异常时静默跳过。数据质量代理发现字段缺失时如果直接给空值并继续推理可能得出假阴性。更合理的方式是记录缺失字段并标记“该结论基于不完整输入”把问题推给人工而不是默默吞掉。4.3 排查链路先从日志开始而不是先怀疑模型遇到筛查结论异常或者医生质疑时我建议按下面的顺序排查1. 查看审计 ID 是否完整生成。 2. 检查指南版本与规则编号是否匹配。 3. 检查数据代理输出患者字段是否被错误清洗。 4. 检查规则匹配结果为什么某条规则没有命中是条件阈值还是数据类型问题。 5. 检查最终风险定级逻辑是否存在多重规则叠加导致的冲突。 6. 只有走到最后一步才去怀疑模型推理部分。如果日志里面第 3 步肉眼可见有错误就不要花时间重新训练模型。这个排查顺序可以避免一大半不必要的模型调优。5. 这类系统真正适合什么场景又该警惕什么5.1 适合在过程明确、制度清晰的环境里使用糖尿病风险筛查本身具有几个适合作自动化的特点有公认指南、有结构化指标、有明确的分级建议、流程重复度高。如果单位内部已经有标准筛查路径只是想让系统承担部分初筛和报告生成工作那多代理加审计的模式就非常适合。它尤其适合基层医疗、体检中心和慢病管理项目。因为这些场景里医生不足筛查量大且需要定期复核。可审计系统让上级医疗机构或者质控部门抽查时能快速定位到每一个决策而不需要重读病历。5.2 在开放性问题和缺乏规范的场景要谨慎如果筛查需求还没有统一指南或者风险评估需要结合大量非结构化主观描述那么现在这套基于规则与显式代理的结构就不太合适。盲目套用会创造出大量“为了审计而审计”的数据反而拖慢流程。另外不要把系统输出直接当成临床诊断。风险筛查只是初筛工具不能替代血糖检测和医生面诊。审计日志能记录决策依据却不能消除所有医学不确定性。5.3 想要真正进入生产还需要补齐几块工程拼图DIASENTINEL 这类项目从演示到生产通常还差几块关键拼图权限与脱敏。患者数据访问必须严格按角色控制审计日志本身也可能包含敏感字段。监控与告警。规则实体变动、代理执行异常、输出分布漂移都需要被监测。定期复评。指南版本更新后需要有固定流程重新评估旧记录并通知相关医生。人工复核界面。医生需要能对系统结论提出异议并留下人工修订记录。这些拼图不补齐系统再准确也无法在临床体系里长期运转。回看 DIASENTINEL 这个标题它真正想要解决的事很朴素把 AI 从“一个聪明的答案生成器”变成“一位每一步都能解释的同事”。在这个目标下多代理不是架构上的自我炫耀指南也不是数据库里的死文本审计更不是事后补上的合规负担。它们共同构成了一个医疗 AI 系统能否被信任的最小必要条件。如果你也在做类似的风险筛查、慢病辅助决策或者体检流程自动化不妨先把规则版本、中间产物、审计链路这三件事搭起来再去追求更复杂的模型效果。因为能让系统走远的从来不是某个时刻的准确率而是每一次判断都能被重新翻开、看懂、并经受住追问的能力。