一、 破局：为什么“套壳大模型”在医疗场景行不通？

随着大语言模型（LLM）的爆发，将自然语言处理应用于医疗辅助（如电子病历生成、用药问答）似乎成为了技术圈的显学。然而，在着手设计我们的《面向全场景用药安全的大模型 Agent 决策引擎》初期，我首先否决了“直接将患者主诉丢给大模型并要求其输出用药建议”的常规方案。

在医疗尤其是全场景用药（处方药、OTC、保健品混用）领域，存在一个致命的矛盾：大模型的概率生成本质与医疗决策所需的绝对确定性之间的冲突。

如果仅仅使用 Prompt Engineering（提示词工程），系统会面临三大痛点：

1. 致命幻觉（Hallucination）：模型可能会根据训练数据的统计概率，凭空捏造不存在的药理反应。

2. 知识滞后与黑盒：大模型无法实时动态更新具体的药品配伍禁忌，且推理过程无法溯源。

3. 缺乏状态感知：真实的临床环境中，患者信息往往缺失（如未知过敏史）。传统大模型倾向于强行作答，缺乏主动追问和防御性降级的能力。

因此，作为架构师，我决定引入 Graph RAG（知识图谱检索增强） 与 ReAct（Reason + Act）工作流，从底层重构系统的决策链路。

二、 核心架构演进：为大模型装上“刹车”与“指南针”

为了解决上述痛点，我将系统架构设计为解耦的四层模型，核心逻辑在于**“让大模型只做它擅长的意图理解，把确定性的逻辑运算交给传统代码与图谱”**。

1. 确定性底座：基于本地轻量图谱的 Graph RAG

我们摒弃了单纯的向量检索（Vector Search），而是选择在后端（FastAPI）构建一个轻量级的医药冲突知识图谱。

• 节点（Node）：药物实体（如布洛芬、泰诺）、患者状态（如孕妇、胃溃疡史）、食物（如西柚汁）。

• 边（Edge）：冲突规则与严重等级（如 [布洛芬] -[增加胃出血风险 (High)]-> [胃溃疡史]）。

通过这种方式，我们可以利用时间复杂度为 $O(V+E)$ 的路径遍历算法，实现对用药冲突的 100% 准确命中，为系统装上了绝对安全的“刹车”。

2. 调度大脑：基于 ReAct 范式的单智能体（Single-Agent）

考虑到多智能体（Multi-Agent）在 Web 场景下的高延迟与死锁风险，我们采用了高内聚的单智能体架构，并为其注入 ReAct 思维模式：

• Reason（思考）：解析自然语言，结构化提取【患者标签】与【药物清单】。

• Act（行动）：自主决策触发 Tool Calling（工具调用），将提取的实体作为参数，调用后端的图谱查询微服务。

• Observe（观察/整合）：接收后端返回的确定性冲突规则，或 needs_clarification（信息缺失）状态码，以此决定是直接输出结果，还是向前端下发追问指令。

三、 系统层级划分与技术选型

为了支撑这套 Agent 工作流，我确立了以下前后端分离的技术基建规范：

• 表现层（Frontend）：采用 Vue3 (Composition API) + Vite + Pinia。前端不仅负责 UI 渲染，更重要的是承载复杂的状态机流转。当接收到 Agent 判定信息缺失的信号时，前端需动态渲染“防御性降级 (Fallback)”UI（如醒目的免责声明时间轴），保障极端场景下的系统鲁棒性。

• 调度层（AI Middleware）：利用 LangChain 框架，封装国产优质大模型（如 GLM-4），统一管理 Tool 的 Schema 契约定义。

• 服务层（Backend）：采用 Python + FastAPI。其原生的 asyncio 异步特性，能有效缓解大模型长轮询带来的 I/O 阻塞，支撑系统的并发响应。

四、 结语与下一步计划

通过引入 Graph RAG 与 ReAct 架构，我们不仅剥离了大模型的幻觉风险，更建立了一套具备“追问”与“容错”能力的智能医疗防线。这标志着我们的项目从一个简单的“对话框”，正式迈向了高可用的“医疗 SaaS 决策引擎”。

目前的底层架构蓝图已经落定。在下一篇文章中，我将详细梳理前后端双线并行的接口契约（API Schema），并记录大模型 Tool Calling 数据格式在跨域传输中遇到的坑与解决方案。