如果你关注医疗 AI尤其是“以大模型做辅助决策但不敢直接用”的场景这次的项目值得仔细读一读。项目名是DIASENTINEL定位是一套可审计、基于临床指南的糖尿病风险筛查多智能体系统。名字拆开来看很直白DIA 对应 DiabetesSENTINEL 是哨兵合起来就是在基层筛查场景里放一个“守门人”Agent专门做糖尿病风险分层和解释。这套系统最值得关注的点不是哪一个模型更强而是三个关键词的组合Multi-Agent System、Guideline-Grounded、Auditable。意思是说它不指望单个大模型一口给出筛查结论而是用多个 Agent 分工协作并且把风险判断拉回到糖尿病临床指南的规则路径上同时记录下每一步决策的审计轨迹。这对医疗 AI 工程落地来说是一个非常务实的设计方向。因为纯粹靠 LLM 对患者说“你风险偏高”医生和患者都不敢信但如果是“你的 BMI、年龄、空腹血糖分别命中哪几条指南条目系统综合之后为什么给出中危结论”这就变成了可追溯、可复核的辅助工具。这篇文章不做概念复读而是直接拆系统和工程实现我会按核心能力、架构拆解、指南约束的实现方式、审计日志怎么设计、最小可运行 Demo、API 与批量任务、合规边界与排查清单的顺序完整过一遍。适合正在做医疗大模型应用、RAG 问答、多智能体编排或者想把 AI 辅助决策做成“可解释且可控”的工程师。由于项目材料里没有给出完整代码和部署包所有示例都按业界常用实现思路给出真实落地时按实际接口替换即可。1. DIASENTINEL 核心能力速览能力项说明项目定位糖尿病风险筛查辅助系统以临床指南为决策根基系统形态多智能体协作架构Agent 各自负责一个筛查环节核心特点指南约束Guideline-Grounded、可审计Auditable、多角色协作面向任务根据用户提供的健康指标输出风险分层、风险解释、建议动作底层模型依赖不确定需按项目实际版本判断一般可接通用 LLM API 或本地开源模型硬件门槛取决于 LLM 底座和向量检索组件没有材料写明固定显存要求启动方式材料未给出具体脚本本文给出通用部署设计与命令模板是否支持 API作为筛查服务至少应暴露 HTTP API可参考第 6 章改造是否支持批量任务从“筛查系统”定位看是必要能力可用任务队列实现可解释性体现规则命中、Agent 决策、证据引用均可记录并回放适合场景辅助糖尿病早筛、健康管理产品、体检报告解读、科研验证不适合场景未经临床验证与伦理审批的独立诊疗决策从现有信息看这个项目最核心的价值不在某一个 Agent 的聪明程度而在于把“多智能体”从概念变成可审计的工程流程。这一点对医疗场景尤其重要。2. 项目定位糖尿病风险筛查为什么需要多智能体架构如果只是做一次糖尿病风险问答单模型也能完成。输入年龄、BMI、血糖、家族史让 LLM 直接给一个“建议就诊”的回复对话体验很简单。但真实筛查场景不会只问一个问题它要处理的是碎片化输入、指标缺失、判定依据不清、解释不一致等一系列问题。传统评分卡比如 FINDRISC、ADA 风险问卷胜在规则透明缺陷是只能处理固定字段。用户只要少提供一个腰围整条评分路径就卡住了。单 LLM 方案能容忍字段缺失但容易在关键结论上自由发挥甚至引用不存在的指南条款。医生拿到结果后既不知道该信哪一步也没法定位是哪条指标把结论推向高危。多智能体架构正好把问题拆开一个 Agent 负责从原始对话或表单里抽取结构化健康指标。一个 Agent 负责查指南库找出与当前指标相关的筛查条目。一个 Agent 负责任务分解和决策链路构建。一个 Agent 负责把规则命中和推理链转成面向用户的解释。拆开之后每个环节都可以单独测试、单独替换、单独打日志。哪个环节出错就能定位到哪个 Agent这就是 DIASENTINEL 在筛查场景里选多智能体而不是单一模型的原因。同时也解决了“指南约束”问题。中心化 prompt 让单模型“尽量遵守 ADA 指南”模型可能遵守也可能不遵守但把指南条目变成规则查询结果让负责风险分层的 Agent 只能基于检索出的指南条款做判断输出自然被约束在指南边界内。审计则是在每个 Agent 的输入输出之间增加持久化记录做到事后可查、可回放、可复核。3. 系统架构拆解3.1 工作流总览从模式上看DIASENTINEL 这类筛查系统会遵循下面的处理链路接收用户输入文本描述、表单字段或结构化体检数据。数据抽取与清洗抽取出年龄、性别、BMI、血糖、糖化血红蛋白、血压、家族史、妊娠糖尿病史等字段缺失字段单独标记。指南检索与匹配根据已有字段从糖尿病指南知识库中检索与当前人群特征相符的风险因素表和分层规则。风险判断决策 Agent 用“检索到的指南条款 当前指标”做判断输出低危、中危、高危或建议就诊。生成解释解释 Agent 把命中规则转成自然语言说明为什么得出这个结论。审计落库把每一步的输入、输出、中间变量、引用条目标识、置信度写入审计日志。这套链路中第 4 步不是让模型从零“想出一个答案”而是做受限推理。换句话讲指南不是背景知识而是必须遵守的调用上下文。3.2 Agent 角色划分参考Agent 名称职责关键能力Intake Agent从非结构化输入提取健康指标实体抽取、单位换算、字段缺失标记Guideline Agent检索匹配指南条款与评分规则RAG、关键词检索、规则命中Screening Agent按指南做风险分层判断受限推理、调用工具、决策输出Explainer Agent输出自然语言筛查解释可控文本生成、引用编号Auditor Agent汇总审计日志检查决策可溯源性日志记录、规则校验这里要注意Agent 数量不是越多越好。筛查链路相对固定5 个角色已经是比较完整的拆法。若项目资源紧张Explainer 和 Auditor 也可以合并到主流程里但审计记录不能省。3.3 Guideline-Grounded让模型“按指南办事”的实现思路Guideline-Grounded 在工程上通常有两种做法。第一种是硬规则优先。把指南中的评分表转成可执行的规则引擎。比如若空腹血糖大于等于 7.0 mmol/L则直接命中“高血糖”危险因素若年龄大于等于 45 且 BMI 大于等于 23 且缺乏运动则累计风险项。规则引擎适合逻辑非常确定的条目例如诊断阈值。第二种是检索增强生成。指南内容不可能全部转成 if-else尤其是包含大量前置条件和语义描述的场景更适合用向量库召回。先把指南切块并建立索引每次决策前召回相关片段作为上下文约束送入 LLM。实际落地更推荐混合方案能定死的阈值用规则需要综合判断的描述性内容用 RAG。这样既能有确定性又能扩展语义理解。在代码结构上规则部分可以单独放一个模块。比如# guideline_engine.py 示例模板需按实际项目调整 from dataclasses import dataclass dataclass class HealthProfile: age: float | None None bmi: float | None None fasting_glucose: float | None None hba1c: float | None None hypertension: bool False family_history: bool False def evaluate_diabetes_risk(profile: HealthProfile) - dict: hits [] if profile.fasting_glucose is not None: if profile.fasting_glucose 7.0: hits.append(GLU-001: 空腹血糖 7.0 mmol/L达到糖尿病疑似阈值) elif profile.fasting_glucose 5.6: hits.append(GLU-002: 空腹血糖处于空腹血糖受损范围) if profile.bmi is not None and profile.bmi 24: hits.append(BMI-001: BMI 24超重 OR 肥胖为风险因素) if profile.age is not None and profile.age 45: hits.append(AGE-001: 年龄 45风险随年龄上升) return { hits: hits, total_score: len(hits), level: high if any(h.startswith(GLU-001) for h in hits) else moderate }上面这段只是演示规则引擎的代码组织方式。真正的指南条目必须由临床团队给出同时还要区分“诊断阈值”和“筛查风险因素”系统不能越界做诊断。3.4 Auditable审计轨迹怎么设计可审计不是简单加一个 log 文件而是要做到决策链路可回放。每一个 Agent 的输入、输出、采用的规则、引用的指南条目、使用的模型版本、当时的 prompt 版本都应该被记录下来。一份审计记录的 JSON 结构可以这样设计{ screen_id: SCR-20250601-0001, timestamp: 2025-06-01T10:30:00Z, user_profile: { age: 52, bmi: 26.5, fasting_glucose: 6.8 }, evidence: [ {code: GLU-002, source: guideline-v2.1, rule_text: 空腹血糖受损范围} ], agent_trace: [ { agent: guideline_agent, model: llm-v3, prompt_hash: ab12cd34, result: retrieved 3 guideline chunks }, { agent: screening_agent, model: llm-v3, decision: moderate_risk, reason: 血糖偏高并存在年龄风险因素 } ], final_output: { risk_level: 中危, suggestion: 建议进一步做口服葡萄糖耐量试验 } }审计数据要支持两个方向的检索按筛查任务 ID 查完整链路按某条指南规则反查哪些人被这条规则影响。后者在模型迭代和指南更新时尤其重要。如果指南从 2023 版换成 2025 版系统需要能回答“新版指南下多少人的风险分层会发生变化”靠的就是这条可反向查询的审计链。4. 环境准备与本地部署思路从项目形态推断完整系统涉及大模型服务、向量数据库、规则引擎、任务队列和业务 API。由于没有材料提供具体脚本下面给出环境准备建议和部署设计。4.1 基础环境清单部署前先确认这些组件操作系统Linux 优先排查方便Windows 适合本地原型。Python 版本建议按所选 Agent 框架要求安装常见是 3.10 以上。LLM 服务可以接 OpenAI 格式的 API也可以用本地 vLLM、Ollama 等提供兼容接口。向量库用于存放指南知识库切片可选 Chroma、Milvus、pgvector。任务队列批量筛查建议引入 Redis Celery 或类似组件。数据库保存筛查记录和审计日志。4.2 项目目录建议diasentinel/ ├── app/ │ ├── agents/ # 各 Agent 实现 │ ├── core/ # 状态管理与编排 │ ├── guidelines/ # 指南规则和知识库 │ ├── audit/ # 审计日志模块 │ └── api/ # HTTP 接口层 ├── configs/ │ ├── settings.yaml │ └── logging.yaml ├── data/ │ ├── guidelines_raw/ # 原始指南 PDF/文本文档 │ └── audit_store/ # 审计输出 └── scripts/ └── build_guideline_index.py按目录组织的关键点是隔离原始指南、规则引擎、Agent 逻辑、审计存储分开后续单独更新不容易互相影响。4.3 启动流程的一般形态这类系统本地启动通常会经历三个步骤初始化指南知识库对指南文本做切片和向量化。启动 LLM 底座服务确保 Agent 可调用的推理接口可达。启动主服务 API。启动命令可以用容器编排或直接进程管理。这里给一个通用模板# 启动前先确认配置文件路径 python -m app.services.guideline_indexer \ --source ./data/guidelines_raw \ --output ./data/guideline_index python -m app.api.main \ --host 0.0.0.0 \ --port 8000 \ --config ./configs/settings.yaml如果服务之间存在依赖关系更稳妥的方式是写进 docker-compose统一管理数据库、向量库和主服务避免本地端口冲突。5. 最小可运行 Demo 设计与代码示例如果只想验证“多智能体 指南约束 审计”这套思路是否成立可以先不做完整的 Web 页面优先实现命令行版本的筛查链路。下面给出一个最小示例代码是演示用途不是项目原版实现。5.1 定义消息协议Agent 之间的通信最好使用统一消息格式避免每个 Agent 各自定义输入输出。以筛查请求为例# schemas.py 示例模板 from dataclasses import dataclass, field from typing import Any dataclass class ScreeningRequest: user_id: str raw_input: dict profile: dict field(default_factorydict) evidence: list field(default_factorylist) audit_events: list field(default_factorylist) def add_event(self, agent: str, event: dict): self.audit_events.append({ agent: agent, **event })统一协议的好处是审计自然融入数据流。每个 Agent 只要对 ScreeningRequest 做了修改事件就会记录到同一份上下文中最后统一落库。5.2 模拟多智能体协同# pipeline.py 示例模板 from schemas import ScreeningRequest from guideline_engine import evaluate_diabetes_risk def run_intake_agent(req: ScreeningRequest): profile { age: req.raw_input.get(age), bmi: req.raw_input.get(bmi), fasting_glucose: req.raw_input.get(fasting_glucose) } req.profile profile req.add_event(intake_agent, {profile: profile}) def run_screening_agent(req: ScreeningRequest): result evaluate_diabetes_risk(req.profile) req.evidence result[hits] req.add_event(screening_agent, {result: result}) def run_explainer_agent(req: ScreeningRequest): if len(req.evidence) 0: explanation 未发现明显高风险指标建议保持常规体检。 else: explanation 系统发现以下风险因素 .join(req.evidence) req.add_event(explainer_agent, {explanation: explanation}) return explanation def screen(raw_input: dict) - dict: req ScreeningRequest( user_idraw_input.get(user_id, unknown), raw_inputraw_input ) run_intake_agent(req) run_screening_agent(req) explanation run_explainer_agent(req) return { screen_id: req.user_id, evidence: req.evidence, explanation: explanation, audit_events: req.audit_events }这是一个最朴素的实现概念上已经覆盖了多 Agent 拆分、指南规则引用、审计事件采集。真正的项目里intake 可能不是直接取 raw_input 字段而是调用 LLM 做实体抽取screening 也可能先查向量库再交给 LLM 总结。5.3 用真实指南做验证Demo 写完后最应该先验证的不是代码流畅度而是“指南有没有被正确转化为规则”。建议把规则命中结果与医务人员手工判断做对比。选取 50 份脱敏案例让医生标注风险分层再让系统跑一遍计算一致率。这种测试是医疗 AI 项目上线前最不可缺少的环节。6. 接口 API 与批量任务设计一个筛查系统最终要服务上层业务例如体检报告 App、健康管理后台、基层医生工作站因此必须有 API。下面给出接口与批量任务的参考设计。6.1 单例筛查接口对外暴露一个同步接口用于在线筛查比较合理。请求体演示{ user_id: USER-001, raw_input: { age: 52, gender: male, bmi: 26.5, waist_circumference: 90, fasting_glucose: 6.8, hba1c: 6.2, hypertension: true, family_history: false }, enable_audit: true }调用方式curl -X POST http://127.0.0.1:8000/api/v1/screen \ -H Content-Type: application/json \ -d { user_id: USER-001, raw_input: { age: 52, bmi: 26.5, fasting_glucose: 6.8 }, enable_audit: true }返回结构建议包含风险等级、命中的证据列表和解释文本{ screen_id: SCR-20250601-0001, risk_level: moderate, explanation: 空腹血糖偏高并叠加年龄因素建议进一步检查。, evidence: [ {code: GLU-002, text: 空腹血糖处于受损范围}, {code: AGE-001, text: 年龄 45 为风险因素} ] }如果开启审计则额外提供 audit_id便于后续查询完整决策链路。6.2 批量筛查任务的执行方式体检机构处理大批量人群数据时单个同步接口就不够了需要引入异步任务。一个简化流程是调用方上传 CSV 或 JSON 数组。服务端生成任务 ID返回给调用方。后台 Worker 逐条执行筛查 Agent。执行结果写回数据库。调用方用任务 ID 查询进度和结果。批量任务的关键不是并行能力而是失败隔离。假设一万条数据里有 5 条字段异常不能因为这 5 条影响整体任务。给每条数据独立记录状态失败后等待人工修正再重跑。7. 效果验证与合规边界7.1 验证维度对于多智能体筛查系统效果验证要覆盖算法质量、系统稳定性和可解释性。算法质量方面建议对比系统分层与医生基于同一份指南做出的分层统计一致率。更重要的是风险分层不能只求整体准确还要看“漏报”情况。如果一个高危患者被系统分成低危这是比“把低危人群误判为中危”更严重的问题。系统稳定性方面要测试字段缺失时的降级表现。用户没有填空腹血糖时系统是直接报错还是能退化为只基于其他风险因素做判断这在筛查中很常见。可解释性方面要检查审计链路是否完整。每一项输出结论是否都能从审计日志里找到依据。7.2 医疗 AI 合规提醒这类项目无论演示得多好都不能直接把它当作医疗器械或诊断工具使用。在实际落地前需要重点确认这几个边界系统身份只能是“辅助筛查”不能输出确定性诊断结论。涉及真实患者数据必须做匿名化或去标识化处理并遵循本地数据法规。模型训练用到的指南、数据集、案例需要确认版权与授权范围。做临床验证前需要获得相应伦理审批。系统上线后需要持续监控指南版本和模型更新带来的风险分层漂移。无论项目本身是科研原型还是产品把“辅助”两个字守住是医疗 AI 工程化的大前提。7.3 显存与性能观察方法如果后续把 LLM 底座部署在本地需要观察的性能点与通用 LLM 应用一致首 Token 延迟和单次推理总耗时。并发请求下的显存或加速卡占用。指南向量检索耗时应与推理耗时分开统计。批量任务中Agent 调用外部模型接口是否会出现超时。可以先用 1 到 10 条并发请求打开资源监控观察是否存在内存泄漏或连接池耗尽再逐步提高压测规模。材料没有给出固定显存数字因此具体选型需要以本机测试为准。8. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 返回了指南之外的结论Guideline 检索召回不完整或规则未覆盖查看审计日志中 guideline_agent 的命中记录补充指南知识库切片增加规则校验风险分层总比医生保守或激进评分权重配置不当输出审计证据逐条对比医生理由与临床团队校准权重和阈值缺少某个关键指标时系统报错数据抽取 Agent 未做缺失值处理重现该输入看 intake_agent 事件增加 missing_fields 标记和降级逻辑批量任务中途大量失败单条脏数据导致队列中断查看任务日志与错误重试记录每条数据独立任务加入失败隔离审计日志查不到完整链路中间环节未写入统一上下文检查 ScreeningRequest.audit_events 是否逐 Agent 追加统一消息协议审计集中在入口落库指南版本更新后结果冲突旧规则缓存未清理检查证据中 source 字段版本号新增版本号强制刷新指南索引LLM 调用超时模型服务并发能力不足观察模型服务监控和调用耗时增加超时重试限制并发API 返回 500 但日志无记录异常在 Agent 内部被吞掉检查 Agent 是否捕获异常而未输出审计日志统一记录 exception 事件排查时最有效的工具是审计日志。如果每个 Agent 都正确记录输入输出一次异常筛查可以被精确重放。这也是“可审计”带来的工程价值。9. 最佳实践与后续扩展建议把以下实践嵌入项目开发过程。第一先把“最小临床闭环”跑通再扩展功能。所谓最小闭环不是做一个演示面板而是让某个具体人群数据从录入开始能稳定输出与医生判断一致的风险分层。闭环没通之前不要急于加语音、报告生成等外围功能。第二把规则和代码分离。指南条款应该放在配置文件、数据库或专门的知识目录里不要硬编码在 Agent 逻辑里。否则指南更新时必须改代码风险极高。第三为每条输出绑定版本号。建议记录指南版本号、模型版本号和 prompt 版本号。这三点是复现决策结果的前提。第四设计人工复核停靠点。中危和高危结果不要直接自动推送给医生而是进入人工复核队列由医生确认后再写入健康档案。多智能体的定位是辅助不是替代人力。第五对输出文本建立安全提示语模板。即使用户指标很低解释 Agent 也必须在结尾提示“本结果不构成医疗诊断如有不适请就医”。这个模板不应该依赖 LLM 临时发挥应该在最终输出层强制追加。后续扩展方向可以包括把接入指南从糖尿病扩到高血压、慢性肾病等共病场景。增加时间序列趋势判断评估患者历次体检指标变化。接入体检报告结构化解析减少人工录入。增加审计面板让医生能够按用户 ID 或规则编码快速检索历史决策。针对不同地区指南版本提供多租户配置。其中共病筛选是最有延伸价值的方向因为糖尿病患者往往同时存在血压和血脂异常。多智能体架构的优势在这里会被放大新增一个共病 Agent 不会破坏原有筛查链路。10. 总结DIASENTINEL 把一个容易做“虚”的多智能体选题落到了具体且严谨的医学筛查场景里。对于工程师来说它的启发性主要有三点用指南约束代替模型自由发挥用多智能体拆解降低单点判断风险用审计记录让 AI 决策经得起追溯。如果你想动手复现建议从最核心的小闭环开始先整理一份权威糖尿病筛查指南把高风险因素转成规则再用极简的 intake、screening、explainer 三个 Agent 完成一次命令行筛查最后补审计日志并输出 JSON 决策轨迹。这套骨架跑通后再接向量库、批量队列和 Web 界面就不会乱。同时也要记住任何筛查系统都只是辅助工具。真实部署前必须完成数据授权确认、临床对照验证和伦理审查。项目的“可审计”设计本身就是医疗 AI 合规底线的技术保障。