糖尿病筛查的可审计多智能体系统：从指南到工程落地

糖尿病风险筛查，在很多人的认知里就是一个“把体检数据扔给模型，输出风险概率”的过程。但在真实医疗场景中，医生做一次筛查，走的是一条非常严谨的决策链：先问年龄、体重、家族史、生活方式，再判断是否需要做实验室检测，最后对照临床指南给出建议。这条链条上的每一步，都要求“有据可依、事后可查”。

这才是医疗 AI 落地时最难的部分。单纯追求“谁的风险高”，深度模型早就做到了；但在医院场景里，医生面对一个 AI 给出的“高风险”结论，必须能追问一句：你为什么这么判？依据的是哪版指南？用了哪些证据？如果患者事后提出异议，这个结论能不能一步步回溯还原？

DIASENTINEL 这类系统的价值，恰好不在“预测更准”，而在于把一个高风险、强监管的筛查过程，组织成一套可审计的、遵循指南的多智能体协作流程。理解它，不只是理解一个新模型，而是理解医疗 AI 从“算法竞赛”走向“工程落地”时需要补上的关键能力。本文会从系统动机、概念拆解、架构设计、最小实现到医疗场景的最佳实践，完整讲透这条技术路线。

1. 核心判断：DIASENTINEL 解决的不是准确率问题，而是“可审计的决策流程”问题

如果只看标题，很多人会把 DIASENTINEL 当作又一个“糖尿病预测 AI”。它确实包含筛查能力，但更重要的是它的定语：Auditable Multi-Agent System（可审计的多智能体系统）和 Guideline-Grounded（基于临床指南）。

这两点指向的是医疗 AI 长期被低估的两个痛点：

第一个痛点：黑盒模型难以进入决策闭环。体检机构、社区医院和内分泌科室需要的不只是一个“风险评分”。如果 AI 系统无法解释它依据哪些危险因素、哪一条指南阈值给出建议，医生就无法在诊疗流程中信任它。一旦出现误判，责任边界也说不清楚。

第二个痛点：指南是活的，系统不能是死的。临床指南会定期更新。糖尿病筛查标准涉及空腹血糖、糖化血红蛋白、口服葡萄糖耐量试验等多项指标，参考阈值、危险因素组合、复查周期都会变化。传统 if-else 专家系统把规则写死在代码里，改一条规则可能破坏另外十条；端到端模型则需要重新收集数据、重新训练。两种方案都很难跟上指南迭代。

DIASENTINEL 的设计路线，是介于“端到端深度学习模型”和“传统专家系统”之间的第三种方案：

• 用大模型处理非结构化信息的理解、抽取和自然语言解释；
• 用结构化流程控制器指挥多个 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 只做一件事，并且输出是结构化、可校验的。只要每个 Agent 的输出稳定，整个流程的可控性就远高于单体大模型套提示词。

3.2 一次筛查任务的执行序列

一个典型的筛查请求，内部大致会经历以下步骤：

1. CollectorAgent 接收患者基本信息，校验必填字段，判断哪些字段缺失。
2. 如果缺少关键危险因素，CollectorAgent 可以触发追问，而不是直接跳过。
3. GuidelineAgent 加载指定版本的指南规则，对患者档案进行风险分层。
4. 存在实验室检查结果时，LabAgent 解析检验指标，并将结构化数值回传给 GuidelineAgent。
5. GuidelineAgent 综合危险因素和检验指标，输出风险分层结论，同时记录命中的指南条款。
6. ExplainAgent 将结论翻译为医生可读、患者可理解的自然语言。
7. AuditAgent 汇总全部中间结果，生成带时间戳和版本号的任务审计报告。

整个过程看起来像一个“工作流加决策引擎”，而不是自由对话。这也是医疗场景多智能体和通用 Agent 产品的本质区别：前者追求可控和可复现，后者追求灵活和创意。

3.3 Agent 编排模式怎么选

实现多智能体系统时，一个核心决策是选择编排模式。这里对比三种常见模式：

对于“基于指南的风险筛查”这样的强流程场景，Pipeline 模式最合适。每步的输入输出边界清晰，每一步产生的审计记录天然有序。如果将来遇到开放性问题，比如患者描述模糊导致需要临时选择检查项目，可以在部分环节引入 Supervisor 模式作为补充。

4. 环境准备与前置条件

这部分开始进入工程实践。我会用一个最小原型演示“指南驱动的风险筛查多智能体”是如何组织和运行的。这个原型不是 DIASENTINEL 本身，而是基于它的设计思想提炼出来的可运行 Demo，目的是把上面讲的架构落地成能看得见的东西。

4.1 环境要求

• 操作系统：Linux、macOS 或 Windows 均可；
• Python：3.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

这个文件定义了两个核心 Agent：CollectorAgent 负责清洗患者输入，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", encoding="utf-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", encoding="utf-8") as f: json.dump(payload, f, ensure_ascii=False, indent=2) 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(f"audit_{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.py

6. 运行结果与效果验证

运行上面的程序，预期输出类似：

筛查结论: prediabetes 命中规则: prediabetes_by_fpg 危险因素数量: 3 建议: 该患者处于糖尿病前期范围，建议生活方式干预并按指南要求复查。

同时，目录下会生成一个名为audit_P2025020001.json的审计报告。打开这个文件，你可以看到完整的两条审计记录：第一条是 CollectorAgent 的输入输出快照，第二条是 GuidelineAgent 的输入快照以及它的风险结论和命中规则。

验证是否成功，可以从三个角度判断：

1. 主流程完成，没有异常抛出。
2. 最终建议和指南规则逻辑一致。示例里患者空腹血糖 6.4，处于 6.1 到 7.0 之间，所以结论是糖尿病前期而不是糖尿病。
3. 审计报告中的输出快照和终端打印结果一致，这说明整个判断链条每一步都能被追溯。

如果运行失败，优先检查 Python 版本、JSON 文件编码，以及是否在项目根目录下执行命令。大部分问题都出在这三个地方。

这个最小原型的价值在于：它用不依赖大模型的方式演示了“流程控制 + 规则推理 + 审计日志”的组合。真实应用中，把 CollectorAgent 替换成大模型调用、把 GuidelineAgent 升级成动态规则引擎，架构骨架依然成立。

7. 常见问题与排查思路

多智能体筛查系统在工程落地时，遇到的问题往往不是“模型不够强”，而是流程和协作上的细节。下面整理了几个高频问题。

一个重要经验：先“审计”后“优化”。排查任何异常时，第一件事不是打开模型调试，而是查看审计日志，把决策链还原出来，找到第一个发生错误偏差的 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 不需要每次都给出最聪明的答案，但必须能解释自己为什么给出这个答案。