还在纠结“该选Python还是Java”的时候医疗AI项目的架构选型往往已经把交付节奏拖慢了一个月。这篇东西的起因是我最近同时接触了两个医疗场景项目——一个用FastAPI LangGraph搭问诊导诊Agent一个用SpringAI做病历结构化与辅助决策服务。两边都跑通了POC过程中踩了不少坑也总结出一套适用性判断方法。如果你正在做医疗AI服务落地或者在两套技术栈之间摇摆这篇文章应该能帮你少走很多弯路。1. 医疗场景下的AI服务到底“难”在哪里1.1 医疗AI项目不像普通Web应用流程编排是核心普通API开发是“请求-处理-返回”三步走但医疗场景的AI服务几乎都是多步骤、带状态、要兜底的。以问诊导诊为例患者进入系统后要经历主诉收集、病史追问、症状初步评估、科室推荐、危重预警等多个环节而且每一步的结果都可能影响后续走向。用传统Web框架硬写这种流程代码会堆成一座屎山每加一个分支就要改一遍主逻辑。这正好是LangGraph这类编排框架的强项。我在这两个项目中体会最深的一点是医疗流程天然适合用“图”来表达节点是“问诊环节”边是“判断条件”状态是“患者信息上下文”。LangGraph把状态机、条件跳转、工具调用都内置了等于把流程设计的复杂度从“代码实现层”降到了“流程设计层”。而SpringAI这边情况不太一样。它在Java生态里解决的是“大模型接入 结构化输出 函数调用”的统一封装问题而不是流程编排。如果你的业务流程相对固定、链路短、但并发和事务要求高比如病历后结构化、检验报告解读SpringAI的稳定性优势就非常明显。1.2 两类技术栈在医疗场景的代表性分工我接触的项目里这两套技术栈一般是这样分工的FastAPI LangGraph负责面向患者的前置交互流程包括预检分诊、智能问诊、报告初步解读。特点是流程长、需要多轮对话、需要动态调整。SpringAI负责后端的结构化处理和高可靠服务如病历自动归档、诊断建议生成、医学知识检索。特点是数据量大、要跟HIS/EMR系统深度集成、对事务和一致性要求极高。这两条线的分工逻辑其实很清晰复杂交互交给Python生态灵活、模型生态强关键数据服务交给Java生态稳定、易集成。但前提是团队能同时驾驭两套技术否则就老老实实选一条路走到底。2. FastAPI LangGraph 医疗Agent实战拆解2.1 为什么是FastAPI而不是Flask或Gradio医疗场景的对外服务接口必须考虑三件事高并发、入参校验、以及异步支持。FastAPI在这三点上几乎是为医疗场景量身定做的。它基于Starlette原生支持async/await配合Uvicorn可以扛住长连接Pydantic模型能做严格的请求体校验——这在医疗场景尤其重要因为一个字段缺失或类型错误可能导致整个问诊流程逻辑跑偏。顺便提一下Gradio网上很多人拿它和FastAPI比。Gradio适合快速做模型演示、内部工具不适合直接暴露成生产API。如果没有API文档、没有鉴权、没有限流医疗系统审核根本过不了。我见过一些项目在POC阶段用Gradio很爽到了集成测试阶段发现完全没法接入HIS只能推倒重来。FastAPI的标准目录结构我也建议直接固定下来前后端联调、运维排障都会省心很多medical_agent/ ├── app/ │ ├── main.py # FastAPI入口挂载路由 │ ├── core/ # 配置、安全、日志 │ ├── models/ # Pydantic模型 │ ├── schemas/ # 请求/响应DTO │ ├── services/ # 业务服务层 │ ├── agents/ # LangGraph工作流 │ ├── tools/ # Agent工具 │ ├── api/ # 路由层 │ └── utils/ # 公共函数 ├── tests/ ├── alembic/ # 数据库迁移 └── pyproject.toml这个结构的核心思想是把Agent逻辑、业务逻辑、接口逻辑彻底分层。LangGraph的工作流只在agents目录里活动不污染上层接口tools里只放具体工具函数如调HIS接口、查知识库供Agent动态调用。2.2 LangGraph工作流定义把医疗问诊画成一张图我实际用LangGraph的StateGraph重写了一个智能预检分诊Agent核心逻辑大概是这样from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class MedicalState(TypedDict): complaint: str patient_info: dict triage_level: str department: str questions_asked: list risk_flag: bool async def collect_complaint(state: MedicalState): # 第一步收集主诉并提取症状关键词 return {complaint: state[complaint]} async def ask_followup(state: MedicalState): # 第二步根据主诉决定是否需要追问如既往病史、过敏史 if needs_more_info(state[complaint]): return {questions_asked: generate_questions(state[complaint])} return state async def assess_risk(state: MedicalState): # 第三步风险初筛若命中危重指征则直接预警 risk evaluate_risk(state[complaint], state[patient_info]) return {risk_flag: risk, triage_level: emergency if risk else routine} async def recommend_department(state: MedicalState): # 第四步基于结构化信息推荐科室 return {department: match_department(state[complaint], state[patient_info])} # 组装图 graph StateGraph(MedicalState) graph.add_node(collect, collect_complaint) graph.add_node(followup, ask_followup) graph.add_node(risk, assess_risk) graph.add_node(recommend, recommend_department) graph.set_entry_point(collect) graph.add_edge(collect, followup) graph.add_conditional_edges(followup, lambda s: risk if not s.get(questions_asked) else collect) graph.add_edge(risk, recommend) graph.add_edge(recommend, END) app graph.compile()这段代码的巧妙之处在于add_conditional_edges——如果患者的回答还需要追问图会绕回collect节点继续循环直到信息充分才进入风险评估。这在传统代码里需要写一堆回调或状态标志而LangGraph用图的结构天然解决了流程变化的可读性极高。2.3 工具调用让Agent真正“下地干活”LangGraph一个重要的设计是Agent可以通过工具调用外部系统。我在项目里注册了三个工具查询科室排班、获取患者历史就诊记录、检索药品说明书。工具定义只需要实现一个函数再用装饰器暴露给模型。from langchain_core.tools import tool tool def get_department_schedule(department: str) - str: 查询某科室未来7天的排班信息 # 这里调用HIS系统接口 return his_client.query_schedule(department) tool def get_patient_history(patient_id: str) - dict: 查询患者最近6个月的就诊记录 return emr_client.get_visits(patient_id)注意工具描述要写得非常具体最好带上“什么时候该调用、参数是什么含义、返回值代表什么”。模型靠描述决定调用哪个工具描述不清晰时模型就会乱调用或干脆不调用。这是我实际调Agent做了几十轮后得到的血泪经验。2.4 异步与超时医疗场景的黄金法则医疗接口最怕的就是卡死。患者在前端等医生回复后端Agent还在调大模型一旦超过5秒用户就流失了。FastAPI的异步能力可以配合LangGraph的arun做并行工具调用但我更想强调的是超时和兜底机制。我在所有Agent入口API上都做了两层防护第一层是接口超时FastAPI里用asyncio.wait_for第二层是LLM调用超时通过LangChain LLM的request_timeout参数。如果两次超时都触发了就走兜底分支——返回固定话术“请稍后人工介入”绝不能让用户无限等待。3. SpringAI在医疗后端的落地姿势3.1 SpringAI解决了Java生态的什么问题Java社区在LLM接入这件事上一直很痛苦。以前要接OpenAI或国产大模型得自己封装HTTP客户端、维护SSE流、再写一堆JSON解析代码。SpringAI的定位就是把这套东西标准化它提供了统一的ChatClient接口适配不同模型厂商还内置了PromptTemplate、结构化输出和函数调用支持。对我手上的病历后结构化项目而言SpringAI最有价值的一点是结构化输出。病历原文是自由文本但HIS系统要求结构化字段主诉、现病史、既往史、过敏史、初步诊断。在SpringAI里写好JavaBean模型输出会自动映射成对象。Data public class MedicalRecordStructured { private String complaint; private String presentIllness; private String pastHistory; private String allergyHistory; private String preliminaryDiagnosis; } RestController public class StructController { Autowired private ChatClient chatClient; PostMapping(/struct/record) public MedicalRecordStructured struct(RequestBody RawRecord raw) { return chatClient.prompt() .user(u - u.text( 请将以下病历文本结构化输出JSON格式 字段包括主诉、现病史、既往史、过敏史、初步诊断。 病历原文{record} ) .param(record, raw.getContent())) .call() .entity(MedicalRecordStructured.class); } }3.2 SpringAI的事务和重试Java的老传统反而是优势医疗后端有个很实际的需求高频写入、不能丢数据、失败必须重试。SpringAI天然继承Spring生态的Transactional、Retryable这些能力。病历结构化结果写库时如果大模型返回格式错了可以先走校验逻辑不通过就不落库保证下游数据质量。我在项目里给结构化服务加了三段式保护先是输出格式校验用Jackson解析字段缺失就抛异常再是业务规则校验比如性别和诊断冲突最后才写数据库。这套流程在现代Java工程里是标配但在Python生态里往往得自己手搓。3.3 SpringAI生态里的函数调用与检索增强医疗场景离不开RAG。医生的诊断建议需要参考最新指南和药品说明SpringAI把向量数据库的接入也做了统一抽象。我用它接入了PGVector构建了一个医学知识库检索通道先向量化检索Top-K文档再塞进Prompt作为上下文最终生成带参考依据的回答。这块的设计要点是检索结果必须带引用来源。SpringAI的Advisor机制可以把检索来源一并返回给前端这样医生能看到AI建议的依据是哪篇指南、哪条说明书。在医疗场景里溯源能力不是加分项是刚需——没有引用来源的AI建议临床上没人敢用。4. 两大技术栈深度对比和选型建议4.1 性能与并发两者差别比想象中小很多人觉得FastAPI性能秒杀Spring Boot但真实压测下来在医疗场景的请求体量下单机几百QPS就够用了两者差距并不明显。FastAPI的异步模型在IO密集型场景有优势Spring Boot在JDK 21的虚拟线程加持下也能轻松扛住高并发。真正的分水岭在于长连接与流式输出。FastAPI对SSEServer-Sent Events的原生支持让流式输出实现非常简洁适合做打字机效果的问诊对话SpringAI虽然也支持流式但配置复杂度和调试成本都更高。反过来如果要做高可靠的数据批量处理Spring Boot的线程池管理和优雅停机机制明显更成熟。4.2 生态与团队选型本质是选“队友”你自己团队可别是“全栈Python”或“全栈Java”这种极端配置。我见过一个医疗项目Java团队硬写LangGraph结果状态管理一塌糊涂也见过Python团队用SpringAI连Maven依赖都搞不明白。选型的真正约束条件是团队在哪个生态里能持续产出高质量代码。如果你是初创团队、要在两周内跑通AI问诊POC无脑上FastAPI LangGraph。模型生态、示例代码、社区教程都是最丰富的踩坑速度最快。如果你是进三甲医院集成要跟HIS、LIS、EMR这些老系统对接SpringBoot的兼容性和企业级中间件生态会让你顺滑很多。4.3 混合架构两端互补的终极形态我最近在推的一个方案是混合架构FastAPI负责AI交互层Spring Boot负责数据服务层中间用消息队列解耦。患者问诊的上下文在FastAPI手里问诊结束后把结构化结果打包发给Spring Boot后者负责写库、同步HIS、触发后续流程。这套架构的关键在于接口契约先行。我在项目里先定义好FastAPI与Spring Boot之间的消息格式用JSON Schema两边各自mock联调最后才打通真实链路。这样可以避免“两边都写完了才发现字段对不上”的经典事故。5. 医疗场景落地的关键注意事项5.1 数据安全与合规白纸黑字写进代码医疗数据的敏感性不用多说但技术实现上经常被忽视。我见过一个项目把患者主诉明文打进了大模型的Prompt这是绝对不行的。正确做法是在传给模型前做脱敏处理替换姓名、身份证号、手机号再在后端做数据映射还原。LangGraph的每个节点传输状态时我都建议加一层脱敏中间件防止数据在某个环节被日志打出来。提示日志里严禁打印患者敏感信息。排查问题时如果确需看上下文用脱敏工具先处理再输出。这是一条红线。5.2 AI输出的医学审核人的介入是安全底线AI在医疗场景只能做辅助不能做决策。我在所有Agent流程里都设计了“人工复核节点”系统生成初步建议后必须经过医生确认或修改才能进入正式医嘱流程。技术上实现就是在LangGraph流程里加一个await human_approval的节点AI产出建议后停住等待医生操作后继续。5.3 可观测性医疗Agent必须有“回放”能力医疗纠纷的风险决定了AI服务必须能“说清楚自己为什么这么回答”。我在FastAPI项目里把LangGraph的完整事件流astream_events录制下来按会话ID存储一旦有疑问就可以回放整个问诊推理过程。SpringAI侧同理每次结构化输出都保存模型返回原文与结构化结果的对照。这些记录既是对患者负责也是对开发者自己的保护。6. 常见问题与排查技巧实录6.1 LangGraph节点状态丢失症状对话轮次一多节点拿到的state缺失了某个字段。 排查方向检查State的TypedDict里是否定义了Annotated[list, operator.add]这类归并操作符。LangGraph的state默认是直接覆盖如果多个节点同时向同一个list字段写值后写会覆盖先写。用operator.add或自定义reduce函数可以改为合并追加。另外节点返回值里如果写了None也会把已有字段清空这点很容易忽略。6.2 FastAPI启动后LangGraph图未初始化症状接口调通但Agent逻辑报“graph not compiled”。 原因很多人把graph.compile()写在了模块导入时但如果中间抛了异常比如LLM API Key没读到图就编译失败且静默吞错。排查方式是启动时打印编译状态并在lifespan里做一次显式初始化。确保编译失败时进程直接启动失败而不是运行到一半才炸。6.3 SpringAI结构化输出偶尔解析失败症状大模型生成的JSON和JavaBean字段不匹配反序列化抛异常。 对策在.entity()之后加一层自定义StructuredOutputConverter对关键字段做容错处理。同时要设置temperature0和固定输出格式的Prompt模板——生成结构化内容时不要温度越稳定越好。反复抽风的话就换一个参数更强的模型。6.4 医疗Agent“幻觉”严重时怎么办这是最难的问题。我目前管用的手段包括第一给模型加系统提示词限定“只基于给定知识库回答不知道就说不知道”第二把知识库检索结果的原文一起传给模型并要求回答中引用片段第三设置关键词过滤器对高风险结论做二次校验。这三个手段叠加能把明显幻觉压到可接受范围。7. 这套方案后续还能怎么扩展项目推进到现在我发现两条值得继续深挖的方向。一条是把LangGraph的图定义和SpringAI的流程配置统一成可视化编排——现在两边各有一套流程描述方式运维和临床同事理解成本太高。另一条是在FastAPI层接入更细粒度的Prompt版本管理每次Prompt调整都记录在案方便回溯效果差异。如果你也在做医疗Agent建议尽早把这套“流程版本化”和“数据血缘追踪”的框架搭起来等到数据量大了再补代价会高得让人不想提。我在实际项目中最大的感受是技术选型没有银弹FastAPI LangGraph的灵活性和SpringAI的稳定性在医疗场景里是互补的。多数团队真正缺的不是框架能力而是对医疗流程的敬畏心——把状态流转、数据脱敏、人工审核这些基础工作做到位比追逐新框架重要得多。