AI医疗分诊与健康咨询助手agent开发——（0）项目背景与概要

一、我为什么要做这个项目

说起来这个想法不是突然冒出来的，是几条线慢慢汇到一起的。

第一条线：工作里的"缺憾"。

我目前在做互联网医院的项目，上线之后发现一个很明显的问题------我们的挂号流程是"直筒式"的：选医院，然后医院各科室列表摆在这儿，你自己选，自己挂。系统不会问你哪里不舒服，也不会帮你判断该挂哪个科。结果就是，患者挂错科的情况时有发生。每次看到客服反馈过来的这类工单，我心里就想：这个环节，明显是能用技术优化的。

但公司有公司的排期和优先级，这个功能一直没排上去，所以有些遗憾！！。

第二条线：自己小时候的记忆。

小时候生病去医院，站在门诊大厅那个巨大的科室指示牌前面，完全不知道该往哪走。爸妈也不懂，就问护士该挂哪一个，但因为自己描述不清晰，护士追问比较少，导致运气不好还容易挂错，来回折腾。那种"着急又迷茫"的感觉，记到现在。结果这么多年过去了，我带我家人去医院，发现这个场景几乎没变------科室名字越来越多，普通人反而越来越懵。

第三条线：技术上的好奇心。

最近Agent这个概念确实火，各种框架、各种教程铺天盖地。我个人做应用开发比较多，对这种"让AI不只是回答问题，而是能自己做判断、做调度"的东西挺感兴趣的。再加上Vibe Coding的风也吹过来了，用AI辅助写代码的效率提升肉眼可见。

结论

这三条线叠在一起，我就想：我本身就是做互联网医院的，业务场景我熟；Agent技术我想学，正好缺一个有深度的练手项目；导诊分诊这个功能，恰好是那种"看着简单，做好了很难"的问题------它要理解自然语言、要多轮追问、要结合医学知识做判断，天然就是Agent的好靶子。

所以这个项目对我来说，是一石三鸟：解决一个真实痛点，学一门新技术，顺便把Vibe Coding的开发方式跑通一遍。

定位说清楚：这是一个学习型项目 ，不是要替代真实的医疗系统。只做医疗分诊与健康咨询 ，所有输出都会带免责声明，不碰诊断、不碰处方、不碰治疗方案，这些红线从第一天就立在这儿。

二、为什么不直接用现成的

说实话，市面上已经有不少AI问诊产品了。但我做这个项目的目的不是做一个产品，而是学Agent技术。

Agent这个词听起来高大上，但其实就是：让AI不只是回答一个问题，而是能根据情况做判断、做调度、做协作。比如用户说"我头疼"，一个简单的AI只会说"建议就医"，但一个Agent系统会追问"头疼多久了？有没有伴随恶心呕吐？"，然后根据回答决定下一步做什么。

这种多步骤、有状态、有编排的AI应用，才是我想学的东西。

项目定位

学习型AI Agent项目 。只做医疗分诊与健康咨询 ，所有输出都会带免责声明，绝不碰诊断、处方、治疗方案这些红线。

红线划清楚

可以做	不做
症状收集与整理	疾病诊断
科室推荐	处方开具
紧急程度提示	治疗方案
健康科普	药物剂量建议
就诊前准备提醒	急救指导
结构化报告生成	医学影像专业判读

所有输出必须包含免责声明，这一点没有商量余地。

三、这个项目最终要做成什么样

先看一个完整的用户交互场景：

用户：我最近一直咳嗽，有点低烧

助手：咳嗽大概持续多久了？是干咳还是有痰？低烧大概多少度？

用户：大概三天了，有痰，黄色的，体温37.8

助手：有没有胸闷或者呼吸困难的情况？最近接触过感冒的人吗？

用户：没有胸闷，同事有几个感冒的

助手：根据您描述的症状，初步判断情况如下：

推荐科室：呼吸内科

紧急程度：普通（建议3天内就诊）

就诊前准备：可记录体温变化，注意痰的颜色变化

免责声明：以上建议仅供参考，不构成医疗诊断，请以医生诊断为准。

这就是最终效果------用户输入症状，系统急症拦截（如果有急症会立刻提醒），AI多轮追问补全信息，Agent编排分诊，最后输出一份结构化报告。

核心功能

症状输入与多轮追问
急症拦截（胸痛、呼吸困难等立刻提醒就医）
科室推荐与紧急程度评估
知识库辅助（常见症状对应的科室、健康科普）
结构化分诊报告
多模态支持（后期加入，比如拍皮疹照片辅助描述）

四、技术选型为什么这么选

技术栈目前打算这么做，后续根据实际情况进行调整（有些技术栈的选择可能会变哦！！）：

技术	选了什么	为什么	没选什么
后端语言	Java 21	我的主力语言，生态成熟，想看看Java做Agent到底行不行	Python------AI生态确实最好，但我想验证Java这条路线
后端框架	Spring Boot 3.4+	企业级标配，Web服务、REST API、SSE流式输出开箱即用	---
AI框架	Spring AI Alibaba + Spring AI	Alibaba版提供Agent Graph编排和Tool Calling，原生版负责Ollama集成、RAG和Embedding，两者配合覆盖完整链路	LangChain4j------功能更全，但跟Spring生态贴合度不如Spring AI
微服务治理	Spring Cloud Gateway + Nacos 2.3+ + Sentinel	Gateway做路由鉴权限流，Nacos一肩挑注册中心和配置中心（支持热更新），Sentinel兜底限流熔断。虽然是学习项目，但提前把这套搭好，后面扩服务不慌	无------单体也能跑，但既然技术栈里有Spring Cloud，不如一步到位
前端	Vue 3 + Element Plus + Vite + Pinia + Axios	Vue轻量上手快，Element Plus的对话、表单、卡片组件正好够用，Vite开发热更新快，Pinia管会话状态，Axios做请求拦截。全是我熟的技术栈，不踩坑	React------也能做，但我Vue更熟，学习项目没必要两边都踩坑
数据库 & 向量检索	PostgreSQL 16 + pgvector 0.7+	一个库同时搞定关系数据、向量检索和全文检索，少引入一个中间件，部署维护都省事	Milvus------纯向量数据库性能更强，但这个项目的检索规模用不上，杀鸡不用牛刀
缓存	Redis 7	会话状态存储、RAG结果缓存、限流计数，标配没得选	无------会话必须有地方存，这个省不了
本地大模型	Ollama 0.4+ / Qwen2.5 14b / Llama3.2-Vision 11b / nomic-embed-text	Qwen2.5做中文对话和分诊推理，14b参数量在本地跑效果和速度能兼顾；Llama3.2-Vision处理舌苔、皮肤等图像分析；nomic-embed-text负责文本向量化进RAG。全跑在Ollama上，开发阶段零成本	直接调云端API------开发期每调一次都花钱，本地模型随便折腾；代码里会做模型适配层，不写死，后面换云端API也方便
监控 & 可观测性	Prometheus + Grafana + SkyWalking 9.7+	Prometheus采集指标，Grafana出仪表盘，SkyWalking做分布式调用链追踪。三件套配齐，出了问题能快速定位	ELK------日志方案，前期先不上，等真正需要再加
开发调试工具	Spring AI Alibaba Studio + Spring AI Alibaba Admin	Studio能可视化Agent的推理过程，Admin做Agent评估和执行追踪。调试Agent的时候，能看清楚每一步在干什么，比看日志高效得多	无------这是Spring AI Alibaba生态自带的，不用白不用
反向代理	Nginx	SSL终止、静态资源托管、请求缓冲，前端和后端都挂它后面	---
部署	Docker + Docker Compose	一台机器全拉起来，开发阶段够用，compose文件一写，环境一致性有保障	K8s------学习项目搞K8s运维成本太高，完全没必要
构建工具	Maven + JDK 21	标配，没什么好说的	Gradle------也能用，但Maven我更熟

说几个背后的关键考量：

为什么AI框架用Spring AI Alibaba而不是纯Spring AI？ 纯Spring AI的抽象层做得很好，Ollama集成、RAG、Embedding这些基础能力它都有。但到了Agent编排这一步，它原生的能力还不够------我需要StateGraph做流程编排、需要Tool Calling做工具调用、需要QC Agent做质控回环，这些Spring AI Alibaba都提供了现成的实现。两个搭配用，各取所长。

为什么选Ollama本地模型？ 开发阶段我不想每次调API都花钱，Ollama拉个qwen2.5或者llama3就能跑，零成本。而且代码里我会做模型适配层，不写死具体模型，后面换云端API也很方便。

为什么模型选Qwen2.5 14b？ 分诊场景对中文理解要求高，Qwen2.5在中文医疗语料上的表现比同参数量的其他模型要好。14b是本地能跑的甜点参数量------再大显存扛不住，再小推理效果打折扣。后面如果需要更强的模型，切到云端API就行，代码里不会写死。

为什么监控三件套全上？ 学习项目嘛，该有的都得有。Agent调用链路本身就长------从用户输入到IntakeAgent、SymptomExtractAgent、TriageDecisionAgent......中间还有质控回环，出了问题不知道卡在哪一步，排查起来很痛苦。SkyWalking能帮我看清楚整条链路每一跳花了多少时间、哪里报了错。Prometheus + Grafana则帮我盯着系统的整体健康状态。

为什么没上ELK？ 前期日志量不大，SkyWalking + 应用日志够用了。等后面真到了需要全文检索日志的阶段再加，不提前过度设计。

五、10个阶段怎么拆的

为什么不一次做完

Agent项目最怕的就是链路太长。你想一口气把8个Agent、RAG、多模态全做完，结果第一个Agent的输出格式不对，后面的全卡住了。

所以我选择小步快跑------每个阶段做完，能启动、能演示、能验证，再进入下一阶段。这三个条件缺一不可：

能启动：项目能跑起来，不报错
能演示：有可见的交互效果，不是只有日志
能验证：核心逻辑有测试覆盖，不是"看起来能跑"

10个阶段一览

阶段	内容	核心验收标准
1	后端骨架与基础对话	能调AI，能返回一句话
2	前端对话页与流式输出	打字机效果，能连续对话
3	结构化分诊与安全规则	AI返回固定JSON格式，急症关键词能拦截
4	多轮追问与会话状态	信息不足时追问，信息够了就出结果
5	三Agent编排	IntakeAgent/TriageAgent/ReportAgent各司其职
6	知识库与基础RAG	pgvector向量检索，回答能引用知识库内容
7	八Agent与质控回环	8个Agent各司其职，StateGraph编排，QC Agent能拦截不合格输出
8	多模态图像辅助	Vision模型接入，图像安全预检
9	认证、权限与隐私安全	JWT认证，敏感数据加密
10	生产化部署、监控与评估	Docker Compose一键部署，Prometheus监控

每个阶段我都会写清楚做了什么、踩了什么坑、怎么验证的。不会跳步，也不会含糊。

六、8个Agent是怎么回事

用医院分诊台来类比

你去医院看病的流程大概是这样的：

前台：问你哪里不舒服，登记基本信息 → IntakeAgent
护士：把你的症状整理成标准说法 → SymptomExtractAgent
追问：信息不够就再问你几句 → ClarificationAgent
查资料：翻翻手册看看类似情况 → KnowledgeRetrievalAgent
分诊：综合判断你应该去哪个科 → TriageDecisionAgent
质控：有人检查分诊结果靠不靠谱 → QCAgent
出报告：把结果整理成你能看懂的报告 → ReportAgent
后续建议：告诉你就诊前要准备什么 → FollowUpAgent

还有一个VisionAgent，负责处理图片输入（比如皮疹照片），前期先空实现，后面再加。

为什么需要这么多Agent

一个Service也能干这些事，为什么要拆这么多Agent？

因为职责拆分之后，每个Agent可以独立迭代和测试。比如TriageAgent的分诊逻辑改了，不会影响IntakeAgent的问诊流程。QCAgent的审查规则加了一条，不需要动ReportAgent的代码。

如果全写在一个Service里，改一个地方牵一发动全身，到最后谁都不敢改了。

Agent编排流程（简化版）

TypeScript 复制代码

用户输入
  │
  ▼
IntakeAgent（预问诊）
  │
  ▼
SymptomExtractAgent（症状标准化）
  │
  ├── 信息不足？──→ ClarificationAgent（追问）──→ 回到SymptomExtractAgent
  │
  ▼
KnowledgeRetrievalAgent（知识检索）
  │
  ▼
TriageDecisionAgent（分诊决策）
  │
  ▼
QCAgent（质控审查）
  │
  ├── 不通过？──→ 回到TriageDecisionAgent（重新决策）
  │
  ▼
ReportAgent + FollowUpAgent（报告 + 建议）
  │
  ▼
输出给用户

注意那个质控回环------QCAgent觉得结果不靠谱，会打回去让TriageDecisionAgent重新来。这就是Agent编排比简单调用链强的地方：有反馈，有纠错。

七、系列文章计划

整个系列一共9篇，从第0篇到第8篇：

篇数	文件	覆盖内容
第0篇	我要做一个AI医疗分诊与健康咨询助手	项目启动说明
第1篇	从零搭建SpringBoot与AI对话系统	阶段1-2
第2篇	让AI输出可控_结构化分诊与安全规则	阶段3-4
第3篇	三Agent编排：从单Service到职责拆分	阶段5
第4篇	RAG知识库实战	阶段6
第5篇	八Agent与质控回环	阶段7
第6篇	多模态图像辅助	阶段8
第7篇	认证权限与隐私安全	阶段9
第8篇	生产化部署与评估	阶段10

第0篇就是你现在看到的这篇，纯规划，不写代码。

从第1篇开始，每篇都会有代码和验证步骤。最终的项目完成代码我会公开到我的gitee与github上供大家一块学习，共勉！！

最后说两句

这个项目对我来说，既是一个学习计划，也是一个验证------验证Java生态做Agent应用到底行不行

现在AI发展太快了，技术迭代也太快了。所以获取知识的方式有所改变，通过Vibe Coding的形式，边学边做。我想把这个过程完整地记录下来，给同样想用Java做Agent的人一个参考。

下一篇开始动手写代码（当然是AI辅助编程了，提效这方面没得说！！），从搭建Spring Boot项目骨架、接入Ollama、实现第一个AI对话接口开始。

走着（学不完、根本学不完......）。

补充

感谢关注本系列，下一篇预告：从零搭建SpringBoot与AI对话系统

ps:其实我已经做到阶段5了，然后才想到，不如写文章记录下来吧，反正好久没写文章了，边学、边做、边记录、边分享....

大概效果如图（哈哈哈哈，UI做的有点潦草，后续再做优化吧）：

（1）分诊

（2）普通聊天