从“单模型黑箱”到“多智能体博弈”：PediaMind 架构选型与核心优势解析

项目名称PediaMind —— 基于多智能体博弈机制与强化RAG的儿科预诊决策系统日期2026年4月2日一、引言在儿科预诊这一高敏感、高风险的场景中AI系统的输出必须同时满足专业性、可靠性、可解释性三重严苛要求。传统的大模型直接问答方案“输入症状 → 输出建议”虽然实现简单但在实际测试中暴露出幻觉频发、逻辑脆弱、无法自审等致命缺陷。为此我们团队在项目初期经过多轮技术调研与架构推演最终放弃了“单一大模型简单RAG”的常规路线转而构建了一套四层闭环架构其核心是基于LangGraph的多智能体博弈系统。该博客我们会详细说明该架构相较于传统方案的优势并复盘我们的选型思考过程。二、传统项目架构的典型局限在项目启动阶段我们调研了市面上常见的医疗问答类实训项目常见的医疗问答项目无非两种要么直接让大模型硬答要么先查点资料再让模型生成。但问题都差不多第一角色不分。一个模型又得抽信息、又得诊断、还得自我审查任务搅在一起哪个都干不好。第二结果没来源。模型说了啥就是啥。第三模型自己不会主动检查自己的逻辑漏洞。因为这些硬伤我们觉得传统路子用在儿科预诊上风险太大所以才重新设计了多智能体博弈的架构。对于儿科预诊系统这些缺陷是不可接受的——一个错误的用药建议可能带来严重后果。三、PediaMind 四层闭环架构全景我们团队经过仔细商讨以及在ai大模型等的助力下设计如下图所示的整体架构逻辑分层控制层Prompt工程元提示定制 | JSON Schema约束 | 版本管理│逻辑层多智能体博弈分诊Agent → 诊断Agent ⇄ 评审Agent → 方案Agent(最大3轮博弈 熔断机制)│检索层强化RAG迭代检索 | 知识锚定 | 引用标注│数据层知识库默沙东手册(1136条) 儿科学(390MB) ChromaDB(≥400MB)四、我们为什么选择这套架构阶段一需求分析三月初我们先把硬性指标定死了输出必须靠谱结果得有据可查家长和医生能看明白来源工程上要可控API调用次数和Token数不能没上限。就这三条直接把“单模型直接生成”的方案给否了。阶段二技术调研三月中旬我们开始看主流路线。一种是“单模型RAG”比如LangChain的RetrievalQA但问题是它没法自我纠错检索失败就彻底凉了。另一种是多智能体框架我们看了AutoGen、CrewAI、LangGraph。只有LangGraph原生支持状态机、条件路由和Checkpointer最符合我们模拟会诊流程的需求。阶段三架构推演与博弈设计我们拿一个典型错误场景模拟用户说“2个月婴儿发烧38.5度家长自行用了布洛芬混悬液”。传统方案很可能直接说“布洛芬可用按体重算剂量”——这是严重错误。在我们设计的架构里分诊Agent先提取出月龄2等基本信息诊断Agent检索知识库评审Agent标记“年龄禁忌”驳回方案系统触发二次检索找到“6月以下婴儿退热药选择指南”最终方案Agent输出“布洛芬禁用建议立即就医评估”。阶段四工程保障设计三月下旬我们设定了工程边界最大博弈轮次设为3轮避免无限循环、控制成本如果3轮后还冲突就熔断降级输出安全兜底模板用LangGraph的MemorySaver保存每轮中间状态支持断点调试。这些决策保证了系统在真实API调用下足够健壮。五、各层架构优势详解1. 数据层从“零散语料”到“结构化知识锚点”在数据这块传统项目往往随便爬点网上的内容或者只用一本教材当知识库存储也就是原始的文本或者简单的关键词索引。而我们的知识来源上选了《默沙东诊疗手册》的1136条专业数据和《儿科学》这本390MB的权威教材还拿PediaBench当评测基准。2. 逻辑层从“单点盲信”到“多方博弈”这一层是整个系统最核心的改动。传统做法就是一个大模型直接吐答案没人检查也没人辩论。我们改成四个角色协同分诊Agent整理病历诊断Agent查知识库给方案评审Agent专门找茬年龄禁忌、药物冲突等方案Agent汇总输出。每轮评审都会审核诊断结果发现问题就再辩一轮最多三轮。实在吵不清楚就熔断直接建议线下就医不瞎猜。3. 检索层从“一次性RAG”到“迭代强化RAG”很多项目用的RAG就是问之前查一次知识库然后把查到的内容拼进去让模型生成答案后面就不管了。我们对此有了一定创新因为诊断和评审之间可能会来回博弈当评审Agent发现诊断Agent引用的知识依据不充分或者有冲突的时候系统会自动触发第二次、甚至第三次检索。这样让系统的可信度提高不少。4. 控制层从“自由生成”到“结构化约束”传统项目经常只写一个通用的System Prompt所有角色共用一套输出格式也就靠提示词里“请用JSON格式”这种建议性描述模型心情不好就跑偏了。因此为了解决这个问题我们给四个Agent分别写了独立的元提示每个Agent知道自己该干什么,而且用JSON Schema做了强约束。这样一来每个Agent的行为就确定多了。六、总结与展望PediaMind的四层闭环架构本质上是将软件工程中的“模块化、解耦、状态机、熔断”等成熟思想引入到大语言模型应用开发中。相比传统项目它在可靠性、可解释性、可维护性、工程健壮性四个维度均实现了质的提升。当然这套架构也带来了更高的实现复杂度我们需要为每个Agent精心调试提示词需要设计合理的状态转移条件还需要处理多个Agent之间的异步调用。但我们相信这个这个项目会是一大创新。