在正式开始写代码之前，我们团队花了将近一周时间在争论一个看起来不大的问题：AI模块到底用什么架构？

最终我们选定的方案是：**Multi-Agent（多智能体协同）+ 规则注入 + 证据链追溯**。

这篇博客想完整记录这个决策的推导过程——我们考察了哪些方案、为什么最终选择了多智能体、最终的架构长什么样。纯粹的技术介绍网上很多，我不想重复，只想说清楚“为什么是这个方案而不是别的”。

 一、从问题本身出发

用药安全检查表面上是一个“查询-回答”问题，但细想之后有几个关键约束：

**约束一：答案必须可溯源，不能靠LLM自由发挥。** 布洛芬和华法林能不能一起吃？这个问题的答案是确定的，有明确的药理机制依据。如果LLM答错了，后果不是体验差，而是医疗事故。所以我们不能接受“LLM凭记忆回答”的方案。

**约束二：用药安全涉及多个专业维度，单一视角远远不够。** 一个完整的用药安全审查，需要同时评估：药物之间的相互作用和剂量是否合规、适应证与患者诊断是否匹配、过敏史与交叉过敏风险、库存与可替代品种。这四个维度分属不同的专业知识领域——临床药学、内科诊疗、过敏管理、药房运营——彼此独立又相互影响。任何一个维度的疏漏都可能导致严重后果。

**约束三：信息不完整时系统不能崩，也不能硬性拒绝。** 真实用药场景里，患者经常不知道自己有没有某种过敏史，或者描述不清楚。如果系统遇到信息缺失就直接返回“无法判断”，实用性就大打折扣。

**约束四：不同来源的审查结论可能冲突，需要仲裁机制。** 临床药师认为某药可用，但过敏专员发现交叉过敏风险，这时谁说了算？系统必须有能力汇总各方意见、识别冲突、做出最终裁决。

有了这四个约束，架构选型就有了清晰的评判标准。

 二、我们考察过的方案

### 方案A：直接调用LLM，用Prompt包含知识

最简单的做法：把常见的配伍禁忌规则全部写进System Prompt，然后让LLM根据用户输入直接回答。

**为什么否定：** 这违反了约束一。LLM的参数记忆是概率性的，不是查表。同一个问题问两次可能得到不同答案，而且LLM没有办法“证明”它的答案来自哪条规则。我们做了一个简单测试：把“布洛芬+华法林”这对经典的高风险配伍问题用不同措辞问了几次GPT类模型，结论的严重程度描述差异明显。对医疗场景来说，这是不可接受的。

### 方案B：向量RAG

把医药知识文档切片、向量化，用户提问时先检索最相关的文本片段，再让LLM基于这些片段回答。

**为什么不够用：** 用药安全检查的核心问题是药物之间的关系，而不是关于单一药物的描述。问“布洛芬+华法林是否有冲突”，向量检索可能分别找到“布洛芬的药代动力学”和“华法林的注意事项”两段文字，但这两段文字不一定包含它们之间相互作用的明确表述。更关键的是，用药安全审查远不止药物相互作用这一个维度——适应证匹配、过敏筛查、库存可用性——这些维度之间是**横向并列**的关系，而不是串行的因果关系。

### 方案C：Single-Agent + GraphRAG

这是我们最初倾向的方案：一个Agent通过ReAct工作流调用知识图谱工具。LLM负责理解输入、提取实体，图谱负责事实裁决。

**为什么最终没有选：** Single-Agent的优势在于流程串行、状态简单，但问题恰恰在于——用药安全审查的四个核心维度是**可以并行**的。药物相互作用审查、适应证匹配审查、过敏史审查、库存审查这四件事彼此独立，没有依赖关系。强行塞进一个Agent里串行执行，不仅浪费了并行计算的机会，更关键的是——**单一Agent无法模拟真实临床的多学科会诊（MDT）机制**。

真实的用药安全决策流程是什么样的？不是一个人把四个问题都看了，而是临床药师看相互作用、专科医生看适应证、过敏专员看过敏史、药房库管看库存——各司其职，各自输出专业意见，最后由一个协调者汇总仲裁。Single-Agent架构无法还原这个天然的分工协作模式。

三、最终方案：为什么是Multi-Agent

把上面的分析综合起来，最终方案的设计逻辑如下：

**核心思路是：用多个专业化智能体模拟临床多学科会诊，各智能体独立审查、并行工作，由会诊主席汇总仲裁。**

我们把用药安全审查拆解为**五个专职智能体 + 一个协调智能体**：

**临床药师（clinical_pharmacist）** ——负责药物相互作用审查、剂量合规性、重复用药成分检测。这是药学的核心能力：判断两种药一起吃是否会产生冲突，剂量是否在安全范围内。

**内科主治（internal_medicine）** ——负责适应证与疾病-药物匹配审查。患者的诊断是什么？开的药是否覆盖了这些诊断？是否存在off-label使用风险？

**过敏专员（allergy_specialist）** ——负责过敏史与交叉过敏审查。患者有无已知过敏史？当前处方是否涉及交叉过敏风险？既往ADR记录如何？

**药房库管（pharmacy_inventory）** ——负责库存审查、院内可开品种、缺货替代方案。药开出来了，药房有没有？如果没有，有什么可替代的？

**专科医生（specialist）** ——这是一个动态激活的角色。根据患者的具体情况（妊娠、抗凝、老年等），自动激活相应的专科禁忌审查模块。

**会诊主席（chief_reviewer）** ——负责汇总各专家意见，识别冲突，做出最终仲裁。当临床药师说“可用”但过敏专员说“有交叉过敏风险”时，会诊主席需要根据规则优先级做出裁决。

这套架构的核心价值在于：**每个智能体只做自己最擅长的事**，知识边界清晰，责任可追溯。临床药师不需要懂库存管理，药房库管不需要懂药理学——每个Agent的Prompt里只注入该领域的最新规则和证据。

四、多智能体解决了什么问题

### 并行处理，而非串行等待

四个核心审查维度彼此独立，完全可以并行执行。用户提交处方后，四个智能体同时启动审查，而不是等一个审完再审下一个。这在真实临床场景中意味着**秒级响应**，而不是分钟级等待。

### 专业分工，边界清晰

每个智能体只维护自己领域的知识库和规则。药物相互作用的规则更新了，只需要更新clinical_pharmacist的Prompt和知识库，不影响其他任何模块。过敏指南变了，allergy_specialist单独升级即可。这种**模块化的知识管理**大幅降低了维护成本。

### 模拟真实MDT，决策可解释

会诊主席汇总各专家意见的过程，天然形成了**决策的审计轨迹**：临床药师说了什么、内科主治说了什么、过敏专员发现了什么风险、最终谁的意见被采纳了——整个过程可追溯、可解释。当系统给出“不建议使用”的结论时，我们能明确说出是哪个智能体、基于哪条规则做出的判断。

### 冲突仲裁，而非简单叠加

不同专家的意见可能冲突。会诊主席的角色不是简单地把所有意见罗列出来，而是根据预设的**规则优先级**做出裁决。比如，过敏专员的“禁忌”意见优先级高于临床药师的“可用”意见——因为过敏反应的风险权重高于一般的药物相互作用。这种仲裁逻辑是医疗决策的真实写照。

### 追问生成与保守降级

当某个智能体发现关键信息缺失时（比如患者未提供过敏史），系统不会直接拒绝，而是生成**追问**让用户补充。如果用户无法补充，系统触发**保守降级**——在信息不足的情况下，采用最安全的推荐路径，并生成防御性免责医嘱。这在Single-Agent架构中需要额外的状态管理逻辑，而在Multi-Agent中由coordinator统一调度即可。

五、为什么值得

用药错误是全球第三大死因——每年约有120万人因用药不当死亡。在这个领域，**正确比快重要，可解释比炫酷重要，安全比省事重要**。

Multi-Agent架构让我们能同时做到三件事：**专业的事交给专业的Agent做**（每个Agent只审查自己领域的事情）、**决策过程全程可追溯**（每个Agent的意见都留痕）、**冲突时有仲裁机制**（不会因为单一视角的误判导致严重后果）。

这就是我们选择Multi-Agent的理由。不是因为它更“高级”，而是因为**用药安全这个场景天然需要多专业协作**——Single-Agent做得再好，也只是一个人同时干四个人的活；而Multi-Agent，是四个人各司其职、协同会诊。

这才是临床用药安全该有的样子。