使用LangGraph4j/Spring AI构建智能问诊Agent

用LangGraph4j/Spring AI搭一个智能问诊Agent：医疗场景的工程化实操

传统医疗问诊流程，说实话，效率瓶颈挺明显的。

患者自己是很难讲清楚病情的——不是不想，是确实没有医学专业知识，说不到点子上。这就导致就诊前信息准备不充分，医生问诊时间又短，一来一回，诊断效率和治疗效果都受影响。尤其在医疗资源紧张、远程问诊需求激增的后疫情时代，这种低效不单加重了医生的负担，还很容易耽误事。

如果能用AI Agent来做预问诊，把信息先采集好、整理好，情况就会好很多。这不仅能提升就诊效率、降低医疗成本，患者的就医体验也会好一大截。这个方案，算是医疗服务数字化转型里一个很关键的基础设施。今天这篇文章，主要面向做AI工程化的开发者、医疗信息化架构师，还有智能对话系统开发的朋友，会提供一个完整的技术落地思路。

背景：医疗AI的机会和现实

医疗行业眼下正被数字化转型推着走，压力不小。一边是医疗资源分布不均、医生短缺的问题越来越突出；另一边，患者对又快又好的医疗服务需求，水涨船高。好在，大模型技术的成熟，给医疗问诊的智能化打开了新大门。

现在的医疗AI应用，已经不是早年的问答机器人了，复杂多轮对话和诊断辅助都已经能跑起来。尤其是在症状采集、初步分诊、健康管理这些场景里，AI的表现，效率跟准确性都挺能打。而LangGraph4j的MultiAgent架构，天然就很适合模拟真实的医疗场景，比如说分诊、转专科问诊、信息确认这些环节，都能很好地对应起来。

技术选型：为什么是LangGraph4j + Spring AI？

做技术选型的时候，我们做了不少功课。最后敲定LangGraph4j + Spring AI，主要是这么几个理由。

需求拆解

• 多Agent协同
  ：分诊Agent、科室Agent、症状采集Agent，这哥几个需要配合好。

• 状态管理
  ：患者整个就诊的流程和状态变化，得全程追踪。

• 工具集成
  ：医疗知识检索、数据存储、外部API这些工具，要能方便地挂进来。

• 生态匹配
  ：团队熟悉Ja va技术栈，方案得能和现有的Spring Boot系统无缝衔接。

方案对比

技术方案	开发效率	维护成本	性能表现	团队匹配度
LangGraph4j + Spring AI	高	低	优秀	完美匹配
自研MultiAgent框架	低	高	中等	需要投入
Semantic Kernel	中等	中等	良好	技术栈不匹配

决策依据

1. LangGraph4j
   ：它提供了完整的MultiAgent编排能力，状态管理、工具调用的扩展性都很好。

2. Spring AI
   ：LangGraph4j和Spring Boot生态配合得很好，能有效降低学习成本和维护复杂度。

3. 社区活跃
   ：开源项目，社区案例多，文档也还算完善，真遇到问题能找得到答案。

4. 扩展性强
   ：支持自定义Agent和工具，将来加功能也方便。

核心架构：怎么搭起来的？

架构总览

flowchart TDsubgraph 前端层UI[用户界面]MobileApp[移动应用]WebApp[Web应用]endsubgraph 应用层ConsultationService[医疗问诊服务]WorkflowEngine[工作流引擎]ResponseGenerator[响应生成器]endsubgraph 服务层TriageAgent[分诊Agent]DepartmentAgent[科室Agent]SymptomAgent[症状采集Agent]RAGService[RAG知识服务]KnowledgeBase[医疗知识库]DataProtection[数据保护服务]endsubgraph 基础设施层PostgreSQL[PostgreSQL数据库]Redis[Redis缓存]Milvus[Milvus向量数据库]LLM[大语言模型]Monitoring[监控系统]endUI --> ConsultationServiceMobileApp --> ConsultationServiceWebApp --> ConsultationServiceConsultationService --> WorkflowEngineConsultationService --> ResponseGeneratorWorkflowEngine --> TriageAgentWorkflowEngine --> DepartmentAgentWorkflowEngine --> SymptomAgentTriageAgent --> RAGServiceDepartmentAgent --> RAGServiceSymptomAgent --> RAGServiceRAGService --> KnowledgeBaseRAGService --> LLMConsultationService --> DataProtectionDataProtection --> PostgreSQLConsultationService --> PostgreSQLConsultationService --> RedisRAGService --> MilvusConsultationService --> MonitoringWorkflowEngine --> MonitoringRAGService --> Monitoring

分层式的MultiAgent设计

整个系统是围绕LangGraph4j的图结构来设计的，定义了三个核心Agent怎么协作：分诊Agent先做初步评估，科室Agent负责专科问诊，症状采集Agent最后把信息结构化。

```ja va // 代码示例如下，核心逻辑在于通过StateGraph定义工作流 // 1. 创建状态图构建器 // 2. 添加各个Agent节点（分诊、科室问诊、症状采集、紧急路由、最终建议） // 3. 设置入口点（分诊） // 4. 添加条件边（根据分诊结果，判断是紧急转诊、转专科，还是直接给建议） // 5. 添加固定边（定义标准流程顺序） // 6. 设置终点并编译 ```

实现的几个关键点：

1. 用 StateGraph.builder() 定义一个有向无环图，把Agent之间的依赖关系理清楚。
2. 通过 addNode() 注册每个Agent的处理逻辑，职责边界要清晰。
3. addConditionalEdges() 实现智能路由，可以处理复杂的医疗决策逻辑，比如根据病情紧急程度分流。
4. 用 AgentState 对象在节点之间传递状态，保证流程的连续性。
5. 每个节点都有独立的异常处理，不能让一个点崩了影响整个系统。

MultiAgent协作机制

```ja va // 完整的问诊流程，通过Graph.invoke()来执行 // 1. 初始化状态 // 2. 执行图工作流（核心调用） // 3. 保存最终状态（持久化） // 4. 构建并返回问诊结果 // 整个流程是异步的，通过CompletableFuture包装，提高响应能力 ```

医疗知识库与RAG系统

医疗问诊，知识的准确性和时效性就是生命线。我们采用RAG（检索增强生成）架构，把向量检索和大模型生成结合起来，确保给出来的建议是靠谱的。

知识增强生成的医疗应用

```ja va // 核心工作流程 // 1. 检索相关知识：根据用户查询，从知识库中召回相关信息 // 2. 构建增强提示：把检索到的知识作为上下文，和用户问题一起构建Prompt // 3. 生成响应：调用大模型生成回答 // 4. 后处理与验证：对模型输出做校验，确保不出现事实性错误 ```

Prompt会明确要求模型，回答要基于提供的医疗知识，不能给出具体的诊断和处方，如果知识不足要明确说明，涉及紧急情况要建议立即就医。

混合存储架构

医疗数据类型多样：结构化的患者信息、半结构化的对话、向量化的知识。所以我们没有只用一种存储，而是采用了混合策略。

• PostgreSQL
  ：存储核心的结构化业务数据，比如问诊记录、患者基本信息。

• Redis
  ：做缓存，热点数据（比如最近问诊状态）放这里，提高访问速度。

• Milvus
  ：向量数据库，用来存储和管理医疗知识的向量索引，支持高效的相似度检索。

用户交互设计

对话与结构化的平衡

用户体验上，难点在于平衡：既要让AI对话显得自然流畅，又要保证采集到的医疗信息是完整准确的。我们的做法是渐进式交互——先用自然语言聊天式地收集信息，最后通过结构化的表单让患者做一次确认。

```ja va // 系统会根据对话所处的阶段（如症状采集、深度追问、结构化确认）来处理用户输入 // 在症装采集阶段，会从用户输入中提取症状信息，并验证完整性 // 如果信息不够，会生成追问；如果信息完整，则进入下一个环节 ```

智能响应生成

响应生成不是简单地把模型结果抛出去。我们会根据不同的场景，生成不同类型的回答。比如：

• 生成自然流畅的追问问题列表。
• 根据症状和严重程度，生成带有同理心的回应（“听起来您头疼得挺厉害，能具体说说是什么感觉吗？”）。
• 用患者听得懂的语言解释医学状况，避免堆砌术语。

性能优化与监控

响应时间优化

用户等不了太长时间。最简单的办法是上缓存，但缓存也要分层，不然命中了慢存储还是白搭。

我们设计了三层缓存：

• L1（本地缓存）
  ：速度最快，适合高频访问的静态内容或常见问题。

• L2（Redis缓存）
  ：共享缓存，比本地慢一点，但容量更大。

• L3（数据库缓存）
  ：兜底方案。

同时，整个请求处理都是异步的，并通过 completeOnTimeout 设置了3秒的超时兜底，避免用户无限等待。

监控与告警

线上系统，得时刻盯着。

我们用 MeterRegistry 记录几个关键指标：响应时间、请求计数、活跃会话数。一旦发现平均响应时间超过3秒，或者系统健康评分低于0.7，就会触发告警。监控任务每分钟跑一次，确保问题能被及时发现。

实践踩坑与解决方案

纸上谈兵容易，真落地的时候，坑还是不少的。

部署挑战：多服务集成的复杂性

MultiAgent架构跑起来后，我们发现几个问题：

1. 服务发现和注册的配置比想象中复杂。
2. Agent之间通信的网络延迟，会直接影响用户感受。
3. 分布式事务下的数据一致性问题，处理起来有点麻烦。
4. 监控和调试的难度也上了一个台阶。

：用 docker-compose 做服务编排，把主应用、PostgreSQL、Redis、Milvus都定义到一起，加上健康检查和网络配置，确保服务间能顺畅通信。

性能调优：响应时间与准确率的平衡

第一版上线，发现响应时间和准确率往往是对着干的：

• 用大模型，准确率高，但平均响应要5-8秒。
• 用小模型，响应快，但准确率掉到70%左右。
• 加上RAG检索，又多出200-500ms的延迟。

：做自适应模型选择。系统会先分析用户问题的复杂度——简单问题就走小模型，追求速度；中等难度走中等模型；复杂问题才启用大模型，确保准确性。这套动态选择的逻辑，算是比较好地平衡了性能和准确率。

合规处理：医疗数据隐私保护

这是所有医疗系统都绕不开的难点。

1. 数据必须端到端加密。
2. 整个数据访问链路都要有详细审计日志。
3. 数据保留和删除策略必须严格合规。

：我们写了一个专门的 MedicalDataProtection 组件。每次数据访问，都会记录操作人和操作类型。所有敏感数据在落盘时都用AES加密，解密操作同样会记录日志。权限不够？直接抛出异常，拒绝访问。

技术总结与边界

核心结论

通过LangGraph4j和Spring AI这套组合，我们确实把智能问诊这个事儿工程化落地了。几个核心结论：

1. 架构适配
   ：LangGraph4j的图结构，完美映射了医疗问诊的分诊-专科-采集这个流程。

2. 知识增强
   ：RAG技术把向量检索和大模型结合起来，让建议更靠谱。

3. 性能优化
   ：PostgreSQL、Redis、Milvus的混合存储方案，算是各取所长。

4. 体验平衡
   ：渐进式交互（对话式+结构化确认），兼顾了用户习惯和业务准确性。

适用场景 & 不适用场景

• 常见病、慢性病的初步问诊和信息收集。
• 医院预约前，帮患者梳理病情和症状。
• 远程医疗的预诊断和分诊服务。
• 健康管理场景里的症状追踪和风险提醒。

• 紧急情况（心梗、中风、严重外伤等），直接打120。
• 需要影像学检查才能确诊的复杂疾病。
• 处方开具和药物治疗建议。（这个必须让医生来）
• 精神科、急诊科等需要特殊处理的科室。

技术限制

1. 准确率
   ：系统不能替代医生诊断，目前准确率大约在85-90%之间。

2. 性能
   ：复杂查询的响应时间，有可能达到3-5秒。

3. 知识边界
   ：完全依赖训练数据和知识库的质量，超出范围的内容只能“不知道”。

4. 合规
   ：必须满足HIPAA等数据保护法规，这是硬性要求。

后续方向

1. 多模态融合
   ：把语音、图像和文本结合起来，实现更全面的信息采集。

2. 个性化模型
   ：基于患者历史数据，提供定制化的问诊策略。

3. 实时协作
   ：与医生工作站对接，实现AI问诊信息和医生工作流程的打通。

4. 预测分析
   ：基于收集到的症状数据，做疾病的早期风险预测。

总的来说，这个方案为医疗AI应用提供了一个可落地的实现路径。既保证了技术的先进性，也充分考虑了工程实践的复杂性和医疗行业的特殊性。持续迭代优化下去，相信能在医疗数字化转型中发挥更大的价值。