随着项目代码全量开源至 Gitee、整体功能完成联调验收，为期近三个月的实训开发工作正式步入收尾阶段。从最开始的技术选型、工程搭建，到网络层、状态管理层开发，再到状态机交互、柔性降级等核心业务功能落地，我全程负责项目前端模块的设计与实现。如今回看整个开发过程，我们团队成功将一个简易的大模型问答 Demo，打磨为具备高确定性、强容错能力的医疗类 Web 应用。本篇结合整体项目架构设计思路，从前端视角

随着项目开发推进，前端已完成基础架构搭建、网络层封装、状态管理设计与动态视图渲染，并实现了和后端 Agent 的全流程联调。本篇对当前阶段的开发工作、核心技术问题、解决方案进行复盘，同时梳理后续开发方向，保证项目稳步推进。当前项目前端核心基建已全部完成，与后端 Agent 联调稳定，核心流程运行良好。通过本阶段开发，团队对AI 应用前端架构设计大模型接口联调医疗场景交互规范有了深入理解。后续将聚焦

在完成 Axios 网络层封装并与 FastAPI 后端打通基础联调后，前端面临一个核心问题：大模型 Agent 返回的诊疗数据并非标准化、结构化的固定格式，存在字段缺失、嵌套异常、空值等情况。如果直接在组件中裸写数据解析，会导致页面崩溃、渲染异常，无法满足医疗场景的稳定性要求。本篇将记录我如何使用Pinia完成 AI 半结构化数据的全局状态管理，以及针对大模型输出不确定性做的防御性解析与容错设计

面向全场景用药安全的医师助手 AgentColdX · 山东大学软件学院 2026年春季项目实训前端开发 & 界面设计。

在我们团队的架构方案中，后端核心是一个基于 ReAct 框架的单智能体（Single-Agent），负责从自然语言主诉中提取药物实体，调用本地医药知识图谱（Graph RAG）进行冲突检测，最终输出结构化的决策结果。这套 AI 决策链路的设计已经相当完善。如果 AI 的决策结果无法被医生或患者准确感知，那整套系统的医疗价值就会大打折扣。在普通 Web 应用里，前端的职责通常是"展示后端给的数据"。

在我们团队的架构方案中，后端核心是一个基于 ReAct 框架的单智能体（Single-Agent），负责从自然语言主诉中提取药物实体，调用本地医药知识图谱（Graph RAG）进行冲突检测，最终输出结构化的决策结果。这套 AI 决策链路的设计已经相当完善。如果 AI 的决策结果无法被医生或患者准确感知，那整套系统的医疗价值就会大打折扣。在普通 Web 应用里，前端的职责通常是"展示后端给的数据"。