所属项目： 面向全场景用药安全的医师助手 Agent
团队： ColdX · 山东大学软件学院 2026年春季项目实训
个人分工： 前端开发 & 界面设计

目录

• • 一、本阶段进展
  • 二、聊天会话状态
  • 三、会诊请求状态
  • 四、本阶段的一个调整
  • 五、AI交互过程
  • 六、本阶段产出
  • 相关链接

一、本阶段进展

接口联调完成初步梳理后，我这一阶段开始处理前端状态管理。本项目前端有两类状态比较典型：一类是智能问答的历史会话，另一类是多智能体会诊的一次性请求结果。

刚开始我想把会诊数据也统一放进全局 Store，但实际推进时发现没有必要。聊天历史需要跨会话、跨刷新保留，所以适合 Pinia；会诊结果主要在当前页面展示，使用 composable 管理请求状态更轻量。

本阶段目标就是把这两类状态边界区分清楚，避免后面页面开发时状态混乱。

---

二、聊天会话状态

智能问答页需要支持多轮对话、新建会话、删除会话、切换历史会话，并且刷新后还要尽量保留记录。因此这部分使用 Pinia 管理。

当前 Store 维护了：

conversations：会话列表
activeId：当前会话 ID
activeConversation：当前会话内容
sortedConversations：按更新时间排序后的会话

我在整理这部分时，把重点放在两个功能上：

• 会话历史通过 localStorage 保存；
• 消息中保留工具调用状态，方便展示 ReAct 过程。

这样聊天页不只是普通对话框，还能体现系统背后的药品查询、相互作用检查和知识图谱检索。

---

三、会诊请求状态

/consult 页面使用 useMultiConsult 管理请求过程。这个 composable 主要维护：

loading：是否正在请求
error：请求失败信息
result：多智能体会诊结果

页面提交时只需要组装 payload，然后调用 run()。请求成功后，结果区根据 result 渲染最终建议、规则证据、专家意见和 Clarify。

这种方式比全局 Store 更适合当前场景，因为一次会诊结果的生命周期主要停留在当前页面。如果需要长期保存，项目通过 Case Log 处理，而不是前端额外存一份。

---

四、本阶段的一个调整

这一阶段我做了一个重要调整：不再追求把所有状态集中到一个 Store，而是按使用场景拆分。

最后形成的状态边界是：

聊天历史：Pinia + localStorage
会诊请求：useMultiConsult
表单输入：页面 ref
结果组件：props 传入
Case 追溯：后端持久化 + Case 页面展示

这样拆分以后，后续写页面时逻辑更清楚。比如 RiskBadge、DebatePanel、ClarifyPanel 这些组件只负责展示，不需要自己关心请求过程。

---

五、AI交互过程

这一阶段我用 AI辅助判断状态归属。提示词大致是：

请检查 frontend/src/stores 和 frontend/src/composables。
结合当前项目页面，帮我判断哪些状态适合 Pinia，哪些适合 composable，哪些应该留在页面内部。
要求基于现有代码给建议，不要重新设计状态管理架构。

AI 帮我把聊天会话和会诊请求分开总结，并指出聊天历史有持久化需求，而会诊请求是页面级异步状态。这个结论和实际开发体验比较一致。

---

六、本阶段产出

本阶段完成了：

• 明确聊天会话使用 Pinia 管理；
• 明确多智能体会诊请求使用 composable 管理；
• 整理表单状态、请求状态、展示组件之间的边界；
• 用 AI辅助确认状态归属；
• 为 /consult 页面结果展示继续开发打好基础。

下一阶段会集中推进 /consult 页面，把多智能体会诊结果按结论、证据、过程和补充说明分层展示出来。

---

相关链接

• 项目地址：https://gitee.com/aemond/innovation-training/tree/master
• 团队博客：https://blog.csdn.net/curufin/category_13140668.html