从“单模型黑箱”到“多智能体博弈”：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之间的异步调用。但我们相信这个这个项目会是一大创新。