糖尿病风险筛查在很多人的认知里就是一个“把体检数据扔给模型输出风险概率”的过程。但在真实医疗场景中医生做一次筛查走的是一条非常严谨的决策链先问年龄、体重、家族史、生活方式再判断是否需要做实验室检测最后对照临床指南给出建议。这条链条上的每一步都要求“有据可依、事后可查”。这才是医疗 AI 落地时最难的部分。单纯追求“谁的风险高”深度模型早就做到了但在医院场景里医生面对一个 AI 给出的“高风险”结论必须能追问一句你为什么这么判依据的是哪版指南用了哪些证据如果患者事后提出异议这个结论能不能一步步回溯还原DIASENTINEL 这类系统的价值恰好不在“预测更准”而在于把一个高风险、强监管的筛查过程组织成一套可审计的、遵循指南的多智能体协作流程。理解它不只是理解一个新模型而是理解医疗 AI 从“算法竞赛”走向“工程落地”时需要补上的关键能力。本文会从系统动机、概念拆解、架构设计、最小实现到医疗场景的最佳实践完整讲透这条技术路线。1. 核心判断DIASENTINEL 解决的不是准确率问题而是“可审计的决策流程”问题如果只看标题很多人会把 DIASENTINEL 当作又一个“糖尿病预测 AI”。它确实包含筛查能力但更重要的是它的定语Auditable Multi-Agent System可审计的多智能体系统和 Guideline-Grounded基于临床指南。这两点指向的是医疗 AI 长期被低估的两个痛点第一个痛点黑盒模型难以进入决策闭环。体检机构、社区医院和内分泌科室需要的不只是一个“风险评分”。如果 AI 系统无法解释它依据哪些危险因素、哪一条指南阈值给出建议医生就无法在诊疗流程中信任它。一旦出现误判责任边界也说不清楚。第二个痛点指南是活的系统不能是死的。临床指南会定期更新。糖尿病筛查标准涉及空腹血糖、糖化血红蛋白、口服葡萄糖耐量试验等多项指标参考阈值、危险因素组合、复查周期都会变化。传统 if-else 专家系统把规则写死在代码里改一条规则可能破坏另外十条端到端模型则需要重新收集数据、重新训练。两种方案都很难跟上指南迭代。DIASENTINEL 的设计路线是介于“端到端深度学习模型”和“传统专家系统”之间的第三种方案用大模型处理非结构化信息的理解、抽取和自然语言解释用结构化流程控制器指挥多个 Agent 按临床指南协作每个环节的输出都写入审计日志保证整条决策链可追溯、可复现。一句话概括它真正改变的是把“人看的指南”变成“机器可执行、可审计的流程”。方案可解释性指南更新成本复杂判断能力审计追溯端到端深度模型低基本黑盒高需要重新训练强但不可控难无法还原推理链条传统专家系统高规则透明中高规则容易互相冲突弱遇到开放文本无能为力部分可追溯但维护成本高多智能体指南系统高Agent 分工明确低更新指南数据或规则配置强可结合大模型理解能力强每一步落日志所以如果你正在做医疗 AI、健康管理平台或者准备用多智能体框架构建强监管场景的应用DIASENTINEL 的思路值得仔细消化。2. 基础概念Multi-Agent System、Guideline-Grounded 与 Auditable在继续深入之前先把三个核心概念讲清楚。这不是术语堆砌因为后面所有架构和代码都建立在这三个词之上。2.1 Multi-Agent System多智能体系统多智能体系统并不是“多个 AI 接口轮流调用”那么简单。它强调的是一种组织方式一个复杂任务被拆分成多个角色每个角色拥有独立的上下文、目标和输出格式通过明确的协作协议完成整体任务。通俗解释这就像一个三甲医院的筛查门诊不是一位医生从头做到尾而是分诊护士先登记基本信息内分泌科医生负责分析风险检验科负责出化验结果最后再由医生结合报告给出建议。每个人只做自己最擅长的事每个环节都能问责。在软件架构里这意味着你要定义角色、通信方式、任务编排和失败处理而不是写一个巨大的 prompt 让大模型自由发挥。2.2 Guideline-Grounded基于指南Guideline-Grounded 的意思是系统的推理边界不是模型“自由发挥”出来的而是被临床指南约束住的。糖尿病风险筛查中医生的判断依据通常来自类似 ADA美国糖尿病协会指南或中国 2 型糖尿病防治指南。这些指南定义了哪些是高风险人群年龄、体重、家族史、高血压等什么条件下需要进行血糖检测不同检测指标达到什么阈值对应正常、糖尿病前期还是糖尿病。Guideline-Grounded 系统会把上述逻辑建模成可加载的规则、决策表和解释依据。大模型不是决策者而是“指南的执行助手”。这样做有一个关键工程收益指南更新时不需要改动核心推理代码只需要替换规则配置并进行回归验证。2.3 Auditable可审计可审计意味着系统执行的每一个关键决策都能被记录下来并回答以下问题这个结论是什么时候生成的它依据了哪些输入数据它命中了哪一条指南规则负责这个判断的 Agent 是哪一版本有没有中间环节改写或丢弃过信息在金融、医疗这类强监管领域可审计不是加分项而是基本要求。没有审计日志的 AI 系统相当于一个拒绝写病历的医生——也许诊断是对的但没有人敢让他独立接诊。3. 系统架构拆解多智能体如何协作完成筛查从系统名称和医疗筛查的实际流程来看DIASENTINEL 这类系统的角色分工可以这样理解它把一次“筛查服务”组织成一条流水线多个 Agent 分别承担采集、分析、裁决、解释和审计任务。下面是一种典型的分层拆解方式具有普遍参考价值。3.1 Agent 角色与职责Agent 角色核心职责关键输入关键输出CollectorAgent信息采集收集并结构化患者基础信息患者填写的问卷、电子病历文本结构化患者档案GuidelineAgent指南推理按临床指南规则计算风险分层结构化患者档案、指南规则库风险分层结果与命中规则LabAgent检验解读读取实验室指标并解析血糖、血脂、肾功能等检验结果标准化的检验结论ExplainAgent解释生成生成面向医生/患者的分层解释风险分层结果、命中规则自然语言筛查建议AuditAgent审计追踪记录整个决策链所有 Agent 的关键输入输出审计日志、可回放的决策轨迹这里的核心设计理念是“职责单一”每一个 Agent 只做一件事并且输出是结构化、可校验的。只要每个 Agent 的输出稳定整个流程的可控性就远高于单体大模型套提示词。3.2 一次筛查任务的执行序列一个典型的筛查请求内部大致会经历以下步骤CollectorAgent 接收患者基本信息校验必填字段判断哪些字段缺失。如果缺少关键危险因素CollectorAgent 可以触发追问而不是直接跳过。GuidelineAgent 加载指定版本的指南规则对患者档案进行风险分层。存在实验室检查结果时LabAgent 解析检验指标并将结构化数值回传给 GuidelineAgent。GuidelineAgent 综合危险因素和检验指标输出风险分层结论同时记录命中的指南条款。ExplainAgent 将结论翻译为医生可读、患者可理解的自然语言。AuditAgent 汇总全部中间结果生成带时间戳和版本号的任务审计报告。整个过程看起来像一个“工作流加决策引擎”而不是自由对话。这也是医疗场景多智能体和通用 Agent 产品的本质区别前者追求可控和可复现后者追求灵活和创意。3.3 Agent 编排模式怎么选实现多智能体系统时一个核心决策是选择编排模式。这里对比三种常见模式编排模式工作方式优点缺点适用场景Pipeline 流水线Agent 1 → Agent 2 → Agent 3顺序执行简单直观调试容易无法回退前一步错误会传导结构化筛查流程适合 DIASENTINEL 主流程Supervisor 监督者一个协调 Agent 动态调度其他 Agent灵活能处理分支任务协调逻辑复杂需要较强模型能力需要动态决策的复杂场景Blackboard 黑板多个 Agent 读写共享内存区协同求解适合信息不完整的复杂问题并发控制难审计顺序难追踪研究型系统工程落地成本高对于“基于指南的风险筛查”这样的强流程场景Pipeline 模式最合适。每步的输入输出边界清晰每一步产生的审计记录天然有序。如果将来遇到开放性问题比如患者描述模糊导致需要临时选择检查项目可以在部分环节引入 Supervisor 模式作为补充。4. 环境准备与前置条件这部分开始进入工程实践。我会用一个最小原型演示“指南驱动的风险筛查多智能体”是如何组织和运行的。这个原型不是 DIASENTINEL 本身而是基于它的设计思想提炼出来的可运行 Demo目的是把上面讲的架构落地成能看得见的东西。4.1 环境要求操作系统Linux、macOS 或 Windows 均可Python3.9 及以上版本依赖包仅使用 Python 标准库无需安装第三方框架设计说明为了让代码可离线运行指南推理部分使用基于 JSON 决策表的规则不调用大模型 API。真实项目中把 Agent 内部实现替换成 LLM 调用即可。4.2 项目目录结构diagent_screener/ ├── guidelines.json # 指南规则库 ├── agents.py # Agent 角色定义 ├── audit.py # 审计日志模块 └── demo_run.py # 主流程演示这种安排和 DIASENTINEL 的模块化思想一致指南规则、Agent 代码、审计模块彼此独立任意一个模块的修改都不应该牵动另外两个。如果你的团队正在设计真实系统建议进一步拆分成独立服务每个 Agent 对应一个可独立部署的子服务并对外提供统一协议接口。5. 完整示例代码实现下面从一个最小原型出发逐步实现“数据采集 Agent → 指南推理 Agent → 审计日志”的完整闭环。5.1 指南规则文件 guidelines.json这个文件对应临床指南中的关键筛查规则。为了清晰演示我把“危险因素命中的风险分层”简化为以下规则如果患者存在过度危险因素或者已表现出血糖异常指标系统标记为高风险并提示进一步检查。真实指南会更复杂但数据结构和加载逻辑是一致的。{ guideline: diabetes_screening_demo_v1, published_date: 2025-01-01, dangerous_factors: [ {key: age_over_45, weight: 1}, {key: bmi_over_28, weight: 1}, {key: family_history, weight: 1}, {key: hypertension, weight: 1}, {key: sedentary, weight: 1} ], lab_thresholds: { fasting_glucose_mmol_l: { normal_upper: 6.1, prediabetes_upper: 7.0 }, hba1c_percent: { normal_upper: 5.7, prediabetes_upper: 6.5 } }, risk_rules: [ { name: high_risk_by_lifestyle, description: 命中 3 项及以上危险因素建议进一步实验室检查, condition: {type: dangerous_factor_count, min: 3}, result: high_risk }, { name: prediabetes_by_fpg, description: 空腹血糖处于糖尿病前期范围, condition: {type: lab_between, lab_key: fasting_glucose_mmol_l, low: 6.1, high: 7.0}, result: prediabetes }, { name: diabetes_by_hba1c, description: 糖化血红蛋白达到糖尿病参考标准需转诊确认, condition: {type: lab_ge, lab_key: hba1c_percent, value: 6.5}, result: diabetes_suspect } ] }关于索引场景的提示单纯保存一个 JSON 文件还不够建议把规则版本号作为主键并把“本次筛查使用的是哪一版指南”写入审计日志。这是医疗场景必须形成的习惯因为患者可能几个月后复查而那时指南规则可能已经更新系统必须能还原当时的判断依据。5.2 Agent 角色定义 agents.py这个文件定义了两个核心 AgentCollectorAgent 负责清洗患者输入GuidelineAgent 负责加载规则并施判断。结构上刻意保持简洁方便看出设计骨架。import json class BaseAgent: def __init__(self, name: str): self.name name def run(self, *args, **kwargs): raise NotImplementedError class CollectorAgent(BaseAgent): 数据采集与标准化 Agent把不规则的输入映射成规则引擎可用的结构。 def __init__(self): super().__init__(CollectorAgent) def run(self, raw_profile: dict) - dict: clean_profile { age_over_45: bool(raw_profile.get(age_over_45, False)), bmi_over_28: bool(raw_profile.get(bmi_over_28, False)), family_history: bool(raw_profile.get(family_history, False)), hypertension: bool(raw_profile.get(hypertension, False)), sedentary: bool(raw_profile.get(sedentary, False)), fasting_glucose_mmol_l: raw_profile.get(fasting_glucose_mmol_l), hba1c_percent: raw_profile.get(hba1c_percent), } return clean_profile class GuidelineAgent(BaseAgent): 指南推理 Agent不依赖大模型按 JSON 决策表执行规则。 def __init__(self, guideline_path: str): super().__init__(GuidelineAgent) with open(guideline_path, r, encodingutf-8) as f: self.guideline json.load(f) def _dangerous_factor_count(self, profile: dict) - int: count 0 for factor in self.guideline[dangerous_factors]: key factor[key] if profile.get(key): count 1 return count def _lab_check(self, profile: dict) - list: hits [] thresholds self.guideline[lab_thresholds] fpg profile.get(fasting_glucose_mmol_l) if fpg is not None: if fpg thresholds[fasting_glucose_mmol_l][prediabetes_upper]: hits.append(lab_high_fpg) elif fpg thresholds[fasting_glucose_mmol_l][normal_upper]: hits.append(lab_prediabetes_fpg) hba1c profile.get(hba1c_percent) if hba1c is not None and hba1c thresholds[hba1c_percent][prediabetes_upper]: hits.append(lab_high_hba1c) return hits def run(self, clean_profile: dict) - dict: factor_count self._dangerous_factor_count(clean_profile) lab_hits self._lab_check(clean_profile) result regular_check matched_rules [] for rule in self.guideline[risk_rules]: cond rule[condition] if cond[type] dangerous_factor_count: if factor_count cond[min]: result rule[result] matched_rules.append(rule[name]) elif cond[type] lab_between: val clean_profile.get(cond[lab_key]) if val is not None and cond[low] val cond[high]: result rule[result] matched_rules.append(rule[name]) elif cond[type] lab_ge: val clean_profile.get(cond[lab_key]) if val is not None and val cond[value]: result rule[result] matched_rules.append(rule[name]) return { agent: self.name, guideline_version: self.guideline.get(guideline), result: result, matched_rules: matched_rules, dangerous_factor_count: factor_count, lab_hits: lab_hits, }代码里的关键设计是CollectorAgent 只负责把输入变成干净的数据结构GuidelineAgent 只负责判断并返回命中的规则和结论。两者之间用“结构化字典”通信谁都不需要理解对方的提示词逻辑。这种解耦在真实项目里非常重要因为指南更新只影响 GuidelineAgent 加载的 JSON 内容输入字段变化只影响 CollectorAgent。5.3 审计日志模块 audit.py审计模块是 DIASENTINEL 这类系统最容易被忽略的部分。我在这里设计了一个简化版本每一条审计记录都带上 Agent 名称、时间、输入快照、输出快照和指南版本。import json import time import uuid class AuditLogger: 审计追踪器记录每个 Agent 的关键输入输出形成可回放决策链。 def __init__(self, patient_id: str): self.patient_id patient_id self.records [] self.started_at time.strftime(%Y-%m-%d %H:%M:%S) def log(self, agent: str, input_snapshot: dict, output_snapshot: dict): record { record_id: uuid.uuid4().hex[:12], patient_id: self.patient_id, timestamp: time.strftime(%Y-%m-%d %H:%M:%S), agent: agent, input_snapshot: input_snapshot, output_snapshot: output_snapshot, } self.records.append(record) return record def export(self, path: str): payload { patient_id: self.patient_id, started_at: self.started_at, total_records: len(self.records), records: self.records, } with open(path, w, encodingutf-8) as f: json.dump(payload, f, ensure_asciiFalse, indent2) print(f[audit] 已生成审计报告: {path})在真实医疗场景中审计日志还应该增加两个能力防篡改存储和敏感字段脱敏。前者可以借助消息摘要链实现后者则要求在记录原始输入之前就完成隐私字段的替换。5.4 主流程 demo_run.py主流程把上面的模块串联起来模拟一次完整的筛查请求。import copy from agents import CollectorAgent, GuidelineAgent from audit import AuditLogger def main(): # 模拟一个患者画像字段可能不够规范 raw_profile { age_over_45: True, bmi_over_28: True, family_history: False, hypertension: True, sedentary: True, fasting_glucose_mmol_l: 6.4, hba1c_percent: None, } patient_id P2025020001 audit_logger AuditLogger(patient_id) collector CollectorAgent() clean_profile collector.run(raw_profile) audit_logger.log(collector.name, copy.deepcopy(raw_profile), copy.deepcopy(clean_profile)) guideline_agent GuidelineAgent(guidelines.json) result guideline_agent.run(clean_profile) audit_logger.log(guideline_agent.name, copy.deepcopy(clean_profile), copy.deepcopy(result)) audit_logger.export(faudit_{patient_id}.json) print(筛查结论:, result[result]) print(命中规则:, , .join(result[matched_rules]) if result[matched_rules] else 无) print(危险因素数量:, result[dangerous_factor_count]) if result[result] diabetes_suspect: print(建议: 该患者检验指标已达到糖尿病参考范围请临床医生复诊确认不可直接作为诊断依据。) elif result[result] prediabetes: print(建议: 该患者处于糖尿病前期范围建议生活方式干预并按指南要求复查。) elif result[result] high_risk: print(建议: 该患者存在多个危险因素建议进一步进行实验室血糖检查。) else: print(建议: 按指南保持常规年度筛查。) if __name__ __main__: main()执行方式cd diagent_screener python demo_run.py6. 运行结果与效果验证运行上面的程序预期输出类似筛查结论: prediabetes 命中规则: prediabetes_by_fpg 危险因素数量: 3 建议: 该患者处于糖尿病前期范围建议生活方式干预并按指南要求复查。同时目录下会生成一个名为audit_P2025020001.json的审计报告。打开这个文件你可以看到完整的两条审计记录第一条是 CollectorAgent 的输入输出快照第二条是 GuidelineAgent 的输入快照以及它的风险结论和命中规则。验证是否成功可以从三个角度判断主流程完成没有异常抛出。最终建议和指南规则逻辑一致。示例里患者空腹血糖 6.4处于 6.1 到 7.0 之间所以结论是糖尿病前期而不是糖尿病。审计报告中的输出快照和终端打印结果一致这说明整个判断链条每一步都能被追溯。如果运行失败优先检查 Python 版本、JSON 文件编码以及是否在项目根目录下执行命令。大部分问题都出在这三个地方。这个最小原型的价值在于它用不依赖大模型的方式演示了“流程控制 规则推理 审计日志”的组合。真实应用中把 CollectorAgent 替换成大模型调用、把 GuidelineAgent 升级成动态规则引擎架构骨架依然成立。7. 常见问题与排查思路多智能体筛查系统在工程落地时遇到的问题往往不是“模型不够强”而是流程和协作上的细节。下面整理了几个高频问题。问题现象可能原因排查方式解决方案筛查结论和指南预期不符指南 JSON 规则冲突或阈值设置错误查看审计日志中 GuidelineAgent 命中的规则用规则单测覆盖每条阈值边界避免规则重叠部分患者在采集阶段被拒筛CollectorAgent 对缺失字段处理过严检查日志中输入快照和缺失校验逻辑区分“必填字段”和“可选字段”缺失时走追问流程审计报告缺少中间环节开发时只为部分 Agent 接入了日志审查主流程中每个 Agent 是否都调用 AuditLogger.log建立强制审计约定Agent 不落日志就不允许返回结果指南更新后旧患者记录无法复现审计日志未记录指南版本号检查历史记录里的 guideline_version 字段把指南版本作为规则加载时的必填字段写入每条输出Agent 化后接口不稳定各 Agent 依赖不同的自然语言输出检查各 Agent 间通信协议中间数据统一走 JSON SchemaLLM 输出先做结构化抽取引入大模型后延迟明显多个环节都调用大模型分段统计每个 Agent 的耗时能用规则判断的先走规则只有开放信息理解才调用大模型一个重要经验先“审计”后“优化”。排查任何异常时第一件事不是打开模型调试而是查看审计日志把决策链还原出来找到第一个发生错误偏差的 Agent。只要系统每个环节都留痕问题定位通常非常快。8. 医疗场景多智能体系统的工程最佳实践从 DIASENTINEL 的设计思路延伸到真实项目以下几条工程经验值得直接复用。8.1 能规则化就规则化LLM 只处理它擅长的事筛查流程里“危险因素计数”“血糖阈值判断”“按照哪条指南进入下一环节”都属于逻辑确定的部分应该用决策表或规则引擎实现。大模型的价值集中在两处理解患者的自由文本描述以及生成医生和患者都能读懂的解释。这个原则能同时改善三个指标延迟、成本和稳定性。规则模块毫秒级返回可控且便宜大模型环节数量越少整个决策链的不可控因子就越少。8.2 审计日志从第一天就要做不要等上线前补在医疗场景中审计日志不是辅助排查的工具而是系统核心能力。设计时应该做到三件事每个 Agent 的输出必须包含“它依据了什么输入”每次规则命中必须记录指南版本每次诊断决策必须区分“机器建议”和“医生确认”两个层级。没有审计能力之前系统不允许接收真实患者数据这一点应该写进开发规范。8.3 结论与责任边界必须明确任何筛查系统的输出都只是“筛查建议”不能替代临床诊断。建议在最前端明确标注系统的使用边界例如“本结果基于临床指南自动生成仅供医生参考不构成最终诊断。”这既是合规要求也是对患者负责。8.4 引入版本化指南管理指南规则库应该像代码一样做版本管理。推荐做法是指南文件包含唯一版本号每个筛查结论携带版本号每次规则变更走代码评审和回归测试历史版本只追加不删除保证过去的结果可以被复现。与其说这是技术问题不如说这是流程纪律问题。糖尿病指南几年更新一次如果没有版本纪律三年后你根本无法回答“去年那个结论是哪版规则算出来的”。8.5 对多智能体系统做“决策一致性”测试传统 AI 测试只关注准确率医疗多智能体系统还要关注一致性同样的输入在不同时间、不同版本下是否给出同样决策。建议建立决策回归集每组输入同时记录预期结论和命中规则。任何指南更新或 Agent 替换都必须保证历史决策回归集中没有意外翻转。8.6 数据隐私与最小权限患者数据属于高度敏感信息。设计上应遵循最小权限原则每个 Agent 只获得完成任务所需的数据。比如 ExplainAgent 生成解释时可能根本不需要患者的身份证号或联系方式那这些字段就不应该出现在它的输入里。审计日志中存储的内容也应该做脱敏处理避免因日志泄露引发二次风险。9. 结语与后续方向DIASENTINEL 的系统思路清楚勾勒出医疗 AI 产品的一个正确方向与其训练一个能回答所有问题的巨型模型不如把决策流程拆成可协同、可追溯的多个智能体让医学指南成为系统推理的边界让审计日志成为系统可信度的证据。如果你正在做医疗 AI下一步可以从三个方向实践第一个方向是实现一个最小筛查 Agent。不用一上来就做完整系统先模拟一个科室的筛查流程想清楚采集、判断、解释、落日志四个环节分别由谁负责。第二个方向是为你的业务场景设计一份“指南规则库”。把领域里专家的判断标准梳理成 JSON 决策表这是后续所有自动化能力的基础。第三个方向是把多智能体的评测体系建立起来。分类模型看 AUC多智能体系统要看流程正确率、指南遵循率、审计完整率和端到端延迟。没有这个评测框架系统改到后期会陷入“感觉能用但不敢上线”的状态。多智能体不是银弹但它确实为医疗这类高风险场景提供了一条兼顾能力、可控性和可解释性的技术路径。理解 DIASENTINEL不如说是在理解一种新的设计态度AI 不需要每次都给出最聪明的答案但必须能解释自己为什么给出这个答案。
糖尿病风险筛查在很多人的认知里就是一个“把体检数据扔给模型输出风险概率”的过程。但在真实医疗场景中医生做一次筛查走的是一条非常严谨的决策链先问年龄、体重、家族史、生活方式再判断是否需要做实验室检测最后对照临床指南给出建议。这条链条上的每一步都要求“有据可依、事后可查”。这才是医疗 AI 落地时最难的部分。单纯追求“谁的风险高”深度模型早就做到了但在医院场景里医生面对一个 AI 给出的“高风险”结论必须能追问一句你为什么这么判依据的是哪版指南用了哪些证据如果患者事后提出异议这个结论能不能一步步回溯还原DIASENTINEL 这类系统的价值恰好不在“预测更准”而在于把一个高风险、强监管的筛查过程组织成一套可审计的、遵循指南的多智能体协作流程。理解它不只是理解一个新模型而是理解医疗 AI 从“算法竞赛”走向“工程落地”时需要补上的关键能力。本文会从系统动机、概念拆解、架构设计、最小实现到医疗场景的最佳实践完整讲透这条技术路线。1. 核心判断DIASENTINEL 解决的不是准确率问题而是“可审计的决策流程”问题如果只看标题很多人会把 DIASENTINEL 当作又一个“糖尿病预测 AI”。它确实包含筛查能力但更重要的是它的定语Auditable Multi-Agent System可审计的多智能体系统和 Guideline-Grounded基于临床指南。这两点指向的是医疗 AI 长期被低估的两个痛点第一个痛点黑盒模型难以进入决策闭环。体检机构、社区医院和内分泌科室需要的不只是一个“风险评分”。如果 AI 系统无法解释它依据哪些危险因素、哪一条指南阈值给出建议医生就无法在诊疗流程中信任它。一旦出现误判责任边界也说不清楚。第二个痛点指南是活的系统不能是死的。临床指南会定期更新。糖尿病筛查标准涉及空腹血糖、糖化血红蛋白、口服葡萄糖耐量试验等多项指标参考阈值、危险因素组合、复查周期都会变化。传统 if-else 专家系统把规则写死在代码里改一条规则可能破坏另外十条端到端模型则需要重新收集数据、重新训练。两种方案都很难跟上指南迭代。DIASENTINEL 的设计路线是介于“端到端深度学习模型”和“传统专家系统”之间的第三种方案用大模型处理非结构化信息的理解、抽取和自然语言解释用结构化流程控制器指挥多个 Agent 按临床指南协作每个环节的输出都写入审计日志保证整条决策链可追溯、可复现。一句话概括它真正改变的是把“人看的指南”变成“机器可执行、可审计的流程”。方案可解释性指南更新成本复杂判断能力审计追溯端到端深度模型低基本黑盒高需要重新训练强但不可控难无法还原推理链条传统专家系统高规则透明中高规则容易互相冲突弱遇到开放文本无能为力部分可追溯但维护成本高多智能体指南系统高Agent 分工明确低更新指南数据或规则配置强可结合大模型理解能力强每一步落日志所以如果你正在做医疗 AI、健康管理平台或者准备用多智能体框架构建强监管场景的应用DIASENTINEL 的思路值得仔细消化。2. 基础概念Multi-Agent System、Guideline-Grounded 与 Auditable在继续深入之前先把三个核心概念讲清楚。这不是术语堆砌因为后面所有架构和代码都建立在这三个词之上。2.1 Multi-Agent System多智能体系统多智能体系统并不是“多个 AI 接口轮流调用”那么简单。它强调的是一种组织方式一个复杂任务被拆分成多个角色每个角色拥有独立的上下文、目标和输出格式通过明确的协作协议完成整体任务。通俗解释这就像一个三甲医院的筛查门诊不是一位医生从头做到尾而是分诊护士先登记基本信息内分泌科医生负责分析风险检验科负责出化验结果最后再由医生结合报告给出建议。每个人只做自己最擅长的事每个环节都能问责。在软件架构里这意味着你要定义角色、通信方式、任务编排和失败处理而不是写一个巨大的 prompt 让大模型自由发挥。2.2 Guideline-Grounded基于指南Guideline-Grounded 的意思是系统的推理边界不是模型“自由发挥”出来的而是被临床指南约束住的。糖尿病风险筛查中医生的判断依据通常来自类似 ADA美国糖尿病协会指南或中国 2 型糖尿病防治指南。这些指南定义了哪些是高风险人群年龄、体重、家族史、高血压等什么条件下需要进行血糖检测不同检测指标达到什么阈值对应正常、糖尿病前期还是糖尿病。Guideline-Grounded 系统会把上述逻辑建模成可加载的规则、决策表和解释依据。大模型不是决策者而是“指南的执行助手”。这样做有一个关键工程收益指南更新时不需要改动核心推理代码只需要替换规则配置并进行回归验证。2.3 Auditable可审计可审计意味着系统执行的每一个关键决策都能被记录下来并回答以下问题这个结论是什么时候生成的它依据了哪些输入数据它命中了哪一条指南规则负责这个判断的 Agent 是哪一版本有没有中间环节改写或丢弃过信息在金融、医疗这类强监管领域可审计不是加分项而是基本要求。没有审计日志的 AI 系统相当于一个拒绝写病历的医生——也许诊断是对的但没有人敢让他独立接诊。3. 系统架构拆解多智能体如何协作完成筛查从系统名称和医疗筛查的实际流程来看DIASENTINEL 这类系统的角色分工可以这样理解它把一次“筛查服务”组织成一条流水线多个 Agent 分别承担采集、分析、裁决、解释和审计任务。下面是一种典型的分层拆解方式具有普遍参考价值。3.1 Agent 角色与职责Agent 角色核心职责关键输入关键输出CollectorAgent信息采集收集并结构化患者基础信息患者填写的问卷、电子病历文本结构化患者档案GuidelineAgent指南推理按临床指南规则计算风险分层结构化患者档案、指南规则库风险分层结果与命中规则LabAgent检验解读读取实验室指标并解析血糖、血脂、肾功能等检验结果标准化的检验结论ExplainAgent解释生成生成面向医生/患者的分层解释风险分层结果、命中规则自然语言筛查建议AuditAgent审计追踪记录整个决策链所有 Agent 的关键输入输出审计日志、可回放的决策轨迹这里的核心设计理念是“职责单一”每一个 Agent 只做一件事并且输出是结构化、可校验的。只要每个 Agent 的输出稳定整个流程的可控性就远高于单体大模型套提示词。3.2 一次筛查任务的执行序列一个典型的筛查请求内部大致会经历以下步骤CollectorAgent 接收患者基本信息校验必填字段判断哪些字段缺失。如果缺少关键危险因素CollectorAgent 可以触发追问而不是直接跳过。GuidelineAgent 加载指定版本的指南规则对患者档案进行风险分层。存在实验室检查结果时LabAgent 解析检验指标并将结构化数值回传给 GuidelineAgent。GuidelineAgent 综合危险因素和检验指标输出风险分层结论同时记录命中的指南条款。ExplainAgent 将结论翻译为医生可读、患者可理解的自然语言。AuditAgent 汇总全部中间结果生成带时间戳和版本号的任务审计报告。整个过程看起来像一个“工作流加决策引擎”而不是自由对话。这也是医疗场景多智能体和通用 Agent 产品的本质区别前者追求可控和可复现后者追求灵活和创意。3.3 Agent 编排模式怎么选实现多智能体系统时一个核心决策是选择编排模式。这里对比三种常见模式编排模式工作方式优点缺点适用场景Pipeline 流水线Agent 1 → Agent 2 → Agent 3顺序执行简单直观调试容易无法回退前一步错误会传导结构化筛查流程适合 DIASENTINEL 主流程Supervisor 监督者一个协调 Agent 动态调度其他 Agent灵活能处理分支任务协调逻辑复杂需要较强模型能力需要动态决策的复杂场景Blackboard 黑板多个 Agent 读写共享内存区协同求解适合信息不完整的复杂问题并发控制难审计顺序难追踪研究型系统工程落地成本高对于“基于指南的风险筛查”这样的强流程场景Pipeline 模式最合适。每步的输入输出边界清晰每一步产生的审计记录天然有序。如果将来遇到开放性问题比如患者描述模糊导致需要临时选择检查项目可以在部分环节引入 Supervisor 模式作为补充。4. 环境准备与前置条件这部分开始进入工程实践。我会用一个最小原型演示“指南驱动的风险筛查多智能体”是如何组织和运行的。这个原型不是 DIASENTINEL 本身而是基于它的设计思想提炼出来的可运行 Demo目的是把上面讲的架构落地成能看得见的东西。4.1 环境要求操作系统Linux、macOS 或 Windows 均可Python3.9 及以上版本依赖包仅使用 Python 标准库无需安装第三方框架设计说明为了让代码可离线运行指南推理部分使用基于 JSON 决策表的规则不调用大模型 API。真实项目中把 Agent 内部实现替换成 LLM 调用即可。4.2 项目目录结构diagent_screener/ ├── guidelines.json # 指南规则库 ├── agents.py # Agent 角色定义 ├── audit.py # 审计日志模块 └── demo_run.py # 主流程演示这种安排和 DIASENTINEL 的模块化思想一致指南规则、Agent 代码、审计模块彼此独立任意一个模块的修改都不应该牵动另外两个。如果你的团队正在设计真实系统建议进一步拆分成独立服务每个 Agent 对应一个可独立部署的子服务并对外提供统一协议接口。5. 完整示例代码实现下面从一个最小原型出发逐步实现“数据采集 Agent → 指南推理 Agent → 审计日志”的完整闭环。5.1 指南规则文件 guidelines.json这个文件对应临床指南中的关键筛查规则。为了清晰演示我把“危险因素命中的风险分层”简化为以下规则如果患者存在过度危险因素或者已表现出血糖异常指标系统标记为高风险并提示进一步检查。真实指南会更复杂但数据结构和加载逻辑是一致的。{ guideline: diabetes_screening_demo_v1, published_date: 2025-01-01, dangerous_factors: [ {key: age_over_45, weight: 1}, {key: bmi_over_28, weight: 1}, {key: family_history, weight: 1}, {key: hypertension, weight: 1}, {key: sedentary, weight: 1} ], lab_thresholds: { fasting_glucose_mmol_l: { normal_upper: 6.1, prediabetes_upper: 7.0 }, hba1c_percent: { normal_upper: 5.7, prediabetes_upper: 6.5 } }, risk_rules: [ { name: high_risk_by_lifestyle, description: 命中 3 项及以上危险因素建议进一步实验室检查, condition: {type: dangerous_factor_count, min: 3}, result: high_risk }, { name: prediabetes_by_fpg, description: 空腹血糖处于糖尿病前期范围, condition: {type: lab_between, lab_key: fasting_glucose_mmol_l, low: 6.1, high: 7.0}, result: prediabetes }, { name: diabetes_by_hba1c, description: 糖化血红蛋白达到糖尿病参考标准需转诊确认, condition: {type: lab_ge, lab_key: hba1c_percent, value: 6.5}, result: diabetes_suspect } ] }关于索引场景的提示单纯保存一个 JSON 文件还不够建议把规则版本号作为主键并把“本次筛查使用的是哪一版指南”写入审计日志。这是医疗场景必须形成的习惯因为患者可能几个月后复查而那时指南规则可能已经更新系统必须能还原当时的判断依据。5.2 Agent 角色定义 agents.py这个文件定义了两个核心 AgentCollectorAgent 负责清洗患者输入GuidelineAgent 负责加载规则并施判断。结构上刻意保持简洁方便看出设计骨架。import json class BaseAgent: def __init__(self, name: str): self.name name def run(self, *args, **kwargs): raise NotImplementedError class CollectorAgent(BaseAgent): 数据采集与标准化 Agent把不规则的输入映射成规则引擎可用的结构。 def __init__(self): super().__init__(CollectorAgent) def run(self, raw_profile: dict) - dict: clean_profile { age_over_45: bool(raw_profile.get(age_over_45, False)), bmi_over_28: bool(raw_profile.get(bmi_over_28, False)), family_history: bool(raw_profile.get(family_history, False)), hypertension: bool(raw_profile.get(hypertension, False)), sedentary: bool(raw_profile.get(sedentary, False)), fasting_glucose_mmol_l: raw_profile.get(fasting_glucose_mmol_l), hba1c_percent: raw_profile.get(hba1c_percent), } return clean_profile class GuidelineAgent(BaseAgent): 指南推理 Agent不依赖大模型按 JSON 决策表执行规则。 def __init__(self, guideline_path: str): super().__init__(GuidelineAgent) with open(guideline_path, r, encodingutf-8) as f: self.guideline json.load(f) def _dangerous_factor_count(self, profile: dict) - int: count 0 for factor in self.guideline[dangerous_factors]: key factor[key] if profile.get(key): count 1 return count def _lab_check(self, profile: dict) - list: hits [] thresholds self.guideline[lab_thresholds] fpg profile.get(fasting_glucose_mmol_l) if fpg is not None: if fpg thresholds[fasting_glucose_mmol_l][prediabetes_upper]: hits.append(lab_high_fpg) elif fpg thresholds[fasting_glucose_mmol_l][normal_upper]: hits.append(lab_prediabetes_fpg) hba1c profile.get(hba1c_percent) if hba1c is not None and hba1c thresholds[hba1c_percent][prediabetes_upper]: hits.append(lab_high_hba1c) return hits def run(self, clean_profile: dict) - dict: factor_count self._dangerous_factor_count(clean_profile) lab_hits self._lab_check(clean_profile) result regular_check matched_rules [] for rule in self.guideline[risk_rules]: cond rule[condition] if cond[type] dangerous_factor_count: if factor_count cond[min]: result rule[result] matched_rules.append(rule[name]) elif cond[type] lab_between: val clean_profile.get(cond[lab_key]) if val is not None and cond[low] val cond[high]: result rule[result] matched_rules.append(rule[name]) elif cond[type] lab_ge: val clean_profile.get(cond[lab_key]) if val is not None and val cond[value]: result rule[result] matched_rules.append(rule[name]) return { agent: self.name, guideline_version: self.guideline.get(guideline), result: result, matched_rules: matched_rules, dangerous_factor_count: factor_count, lab_hits: lab_hits, }代码里的关键设计是CollectorAgent 只负责把输入变成干净的数据结构GuidelineAgent 只负责判断并返回命中的规则和结论。两者之间用“结构化字典”通信谁都不需要理解对方的提示词逻辑。这种解耦在真实项目里非常重要因为指南更新只影响 GuidelineAgent 加载的 JSON 内容输入字段变化只影响 CollectorAgent。5.3 审计日志模块 audit.py审计模块是 DIASENTINEL 这类系统最容易被忽略的部分。我在这里设计了一个简化版本每一条审计记录都带上 Agent 名称、时间、输入快照、输出快照和指南版本。import json import time import uuid class AuditLogger: 审计追踪器记录每个 Agent 的关键输入输出形成可回放决策链。 def __init__(self, patient_id: str): self.patient_id patient_id self.records [] self.started_at time.strftime(%Y-%m-%d %H:%M:%S) def log(self, agent: str, input_snapshot: dict, output_snapshot: dict): record { record_id: uuid.uuid4().hex[:12], patient_id: self.patient_id, timestamp: time.strftime(%Y-%m-%d %H:%M:%S), agent: agent, input_snapshot: input_snapshot, output_snapshot: output_snapshot, } self.records.append(record) return record def export(self, path: str): payload { patient_id: self.patient_id, started_at: self.started_at, total_records: len(self.records), records: self.records, } with open(path, w, encodingutf-8) as f: json.dump(payload, f, ensure_asciiFalse, indent2) print(f[audit] 已生成审计报告: {path})在真实医疗场景中审计日志还应该增加两个能力防篡改存储和敏感字段脱敏。前者可以借助消息摘要链实现后者则要求在记录原始输入之前就完成隐私字段的替换。5.4 主流程 demo_run.py主流程把上面的模块串联起来模拟一次完整的筛查请求。import copy from agents import CollectorAgent, GuidelineAgent from audit import AuditLogger def main(): # 模拟一个患者画像字段可能不够规范 raw_profile { age_over_45: True, bmi_over_28: True, family_history: False, hypertension: True, sedentary: True, fasting_glucose_mmol_l: 6.4, hba1c_percent: None, } patient_id P2025020001 audit_logger AuditLogger(patient_id) collector CollectorAgent() clean_profile collector.run(raw_profile) audit_logger.log(collector.name, copy.deepcopy(raw_profile), copy.deepcopy(clean_profile)) guideline_agent GuidelineAgent(guidelines.json) result guideline_agent.run(clean_profile) audit_logger.log(guideline_agent.name, copy.deepcopy(clean_profile), copy.deepcopy(result)) audit_logger.export(faudit_{patient_id}.json) print(筛查结论:, result[result]) print(命中规则:, , .join(result[matched_rules]) if result[matched_rules] else 无) print(危险因素数量:, result[dangerous_factor_count]) if result[result] diabetes_suspect: print(建议: 该患者检验指标已达到糖尿病参考范围请临床医生复诊确认不可直接作为诊断依据。) elif result[result] prediabetes: print(建议: 该患者处于糖尿病前期范围建议生活方式干预并按指南要求复查。) elif result[result] high_risk: print(建议: 该患者存在多个危险因素建议进一步进行实验室血糖检查。) else: print(建议: 按指南保持常规年度筛查。) if __name__ __main__: main()执行方式cd diagent_screener python demo_run.py6. 运行结果与效果验证运行上面的程序预期输出类似筛查结论: prediabetes 命中规则: prediabetes_by_fpg 危险因素数量: 3 建议: 该患者处于糖尿病前期范围建议生活方式干预并按指南要求复查。同时目录下会生成一个名为audit_P2025020001.json的审计报告。打开这个文件你可以看到完整的两条审计记录第一条是 CollectorAgent 的输入输出快照第二条是 GuidelineAgent 的输入快照以及它的风险结论和命中规则。验证是否成功可以从三个角度判断主流程完成没有异常抛出。最终建议和指南规则逻辑一致。示例里患者空腹血糖 6.4处于 6.1 到 7.0 之间所以结论是糖尿病前期而不是糖尿病。审计报告中的输出快照和终端打印结果一致这说明整个判断链条每一步都能被追溯。如果运行失败优先检查 Python 版本、JSON 文件编码以及是否在项目根目录下执行命令。大部分问题都出在这三个地方。这个最小原型的价值在于它用不依赖大模型的方式演示了“流程控制 规则推理 审计日志”的组合。真实应用中把 CollectorAgent 替换成大模型调用、把 GuidelineAgent 升级成动态规则引擎架构骨架依然成立。7. 常见问题与排查思路多智能体筛查系统在工程落地时遇到的问题往往不是“模型不够强”而是流程和协作上的细节。下面整理了几个高频问题。问题现象可能原因排查方式解决方案筛查结论和指南预期不符指南 JSON 规则冲突或阈值设置错误查看审计日志中 GuidelineAgent 命中的规则用规则单测覆盖每条阈值边界避免规则重叠部分患者在采集阶段被拒筛CollectorAgent 对缺失字段处理过严检查日志中输入快照和缺失校验逻辑区分“必填字段”和“可选字段”缺失时走追问流程审计报告缺少中间环节开发时只为部分 Agent 接入了日志审查主流程中每个 Agent 是否都调用 AuditLogger.log建立强制审计约定Agent 不落日志就不允许返回结果指南更新后旧患者记录无法复现审计日志未记录指南版本号检查历史记录里的 guideline_version 字段把指南版本作为规则加载时的必填字段写入每条输出Agent 化后接口不稳定各 Agent 依赖不同的自然语言输出检查各 Agent 间通信协议中间数据统一走 JSON SchemaLLM 输出先做结构化抽取引入大模型后延迟明显多个环节都调用大模型分段统计每个 Agent 的耗时能用规则判断的先走规则只有开放信息理解才调用大模型一个重要经验先“审计”后“优化”。排查任何异常时第一件事不是打开模型调试而是查看审计日志把决策链还原出来找到第一个发生错误偏差的 Agent。只要系统每个环节都留痕问题定位通常非常快。8. 医疗场景多智能体系统的工程最佳实践从 DIASENTINEL 的设计思路延伸到真实项目以下几条工程经验值得直接复用。8.1 能规则化就规则化LLM 只处理它擅长的事筛查流程里“危险因素计数”“血糖阈值判断”“按照哪条指南进入下一环节”都属于逻辑确定的部分应该用决策表或规则引擎实现。大模型的价值集中在两处理解患者的自由文本描述以及生成医生和患者都能读懂的解释。这个原则能同时改善三个指标延迟、成本和稳定性。规则模块毫秒级返回可控且便宜大模型环节数量越少整个决策链的不可控因子就越少。8.2 审计日志从第一天就要做不要等上线前补在医疗场景中审计日志不是辅助排查的工具而是系统核心能力。设计时应该做到三件事每个 Agent 的输出必须包含“它依据了什么输入”每次规则命中必须记录指南版本每次诊断决策必须区分“机器建议”和“医生确认”两个层级。没有审计能力之前系统不允许接收真实患者数据这一点应该写进开发规范。8.3 结论与责任边界必须明确任何筛查系统的输出都只是“筛查建议”不能替代临床诊断。建议在最前端明确标注系统的使用边界例如“本结果基于临床指南自动生成仅供医生参考不构成最终诊断。”这既是合规要求也是对患者负责。8.4 引入版本化指南管理指南规则库应该像代码一样做版本管理。推荐做法是指南文件包含唯一版本号每个筛查结论携带版本号每次规则变更走代码评审和回归测试历史版本只追加不删除保证过去的结果可以被复现。与其说这是技术问题不如说这是流程纪律问题。糖尿病指南几年更新一次如果没有版本纪律三年后你根本无法回答“去年那个结论是哪版规则算出来的”。8.5 对多智能体系统做“决策一致性”测试传统 AI 测试只关注准确率医疗多智能体系统还要关注一致性同样的输入在不同时间、不同版本下是否给出同样决策。建议建立决策回归集每组输入同时记录预期结论和命中规则。任何指南更新或 Agent 替换都必须保证历史决策回归集中没有意外翻转。8.6 数据隐私与最小权限患者数据属于高度敏感信息。设计上应遵循最小权限原则每个 Agent 只获得完成任务所需的数据。比如 ExplainAgent 生成解释时可能根本不需要患者的身份证号或联系方式那这些字段就不应该出现在它的输入里。审计日志中存储的内容也应该做脱敏处理避免因日志泄露引发二次风险。9. 结语与后续方向DIASENTINEL 的系统思路清楚勾勒出医疗 AI 产品的一个正确方向与其训练一个能回答所有问题的巨型模型不如把决策流程拆成可协同、可追溯的多个智能体让医学指南成为系统推理的边界让审计日志成为系统可信度的证据。如果你正在做医疗 AI下一步可以从三个方向实践第一个方向是实现一个最小筛查 Agent。不用一上来就做完整系统先模拟一个科室的筛查流程想清楚采集、判断、解释、落日志四个环节分别由谁负责。第二个方向是为你的业务场景设计一份“指南规则库”。把领域里专家的判断标准梳理成 JSON 决策表这是后续所有自动化能力的基础。第三个方向是把多智能体的评测体系建立起来。分类模型看 AUC多智能体系统要看流程正确率、指南遵循率、审计完整率和端到端延迟。没有这个评测框架系统改到后期会陷入“感觉能用但不敢上线”的状态。多智能体不是银弹但它确实为医疗这类高风险场景提供了一条兼顾能力、可控性和可解释性的技术路径。理解 DIASENTINEL不如说是在理解一种新的设计态度AI 不需要每次都给出最聪明的答案但必须能解释自己为什么给出这个答案。
