医疗智能体后端实战：基于Java栈的大模型API封装、限流与结果缓存策略

做医疗AI智能体的后端开发，和做通用聊天机器人完全是两码事。通用场景下模型调用失败，用户刷新重试就行；但在医疗场景里，一次症状识别请求可能直接影响分诊建议，一次病历摘要生成可能被写进电子病历。稳定性、合规性和响应速度，在这个领域不是加分项，而是底线。

这篇文章从Java后端工程视角出发，拆解医疗智能体对接大模型API时的封装设计、限流策略和缓存方案。附可运行的SpringBoot代码骨架。

为什么不能直接调大模型API

很多团队起步阶段的写法是在Service里直接注入一个HTTP客户端，拼好Prompt就发请求。这在Demo阶段没问题，但一上生产就会暴露三个致命问题：

第一，多模型切换困难。 医疗场景往往需要同时对接千问、DeepSeek甚至院内私有化部署的模型。如果调用逻辑散落在各个业务Service里，换模型意味着改遍所有代码。

第二，Prompt与业务逻辑耦合。 症状识别、病历摘要、用药建议的Prompt模板各不一样，如果硬编码在调用处，后续做Prompt版本管理和A/B测试会非常痛苦。

第三，缺乏统一的容错和可观测性。 超时、重试、降级、Token消耗统计，这些如果每个调用点各写一套，既冗余又容易遗漏。

所以第一步要做的，是把大模型调用抽象成一个独立的网关层（LLM Gateway），让业务代码只关心“我要问什么”，不关心“问的是哪个模型、怎么问、失败了怎么办”。

分层架构：Controller → Service → LLM Gateway

推荐的分层设计如下：

• Controller层：接收前端请求，做基础参数校验和权限拦截
• Service层：编排业务逻辑，比如“先查患者历史，再调模型生成建议”
• LLM Gateway层：统一封装模型调用，负责Prompt组装、限流、缓存、降级
• Model Adapter层：对接具体模型厂商（千问、DeepSeek等），处理各家API的协议差异

核心接口设计：

public interface LlmGateway {
LlmResponse chat(LlmRequest request);
Flux<String> streamChat(LlmRequest request);
}

LlmRequest 中携带业务场景标识（如 SYMPTOM_ANALYSIS）、用户输入、上下文等，Gateway内部根据场景选择对应的Prompt模板和模型。

多模型适配：策略模式 + 配置化路由

不同模型厂商的API协议差异很大。千问的DashScope API用 input.messages 传对话，DeepSeek兼容OpenAI的 messages 格式。如果每个模型写一套if-else，维护成本极高。

用策略模式把适配逻辑抽离：

public interface ModelAdapter {
String getModelName();
LlmResponse invoke(LlmRequest request);
Flux<String> stream(LlmRequest request);
}

@Component
public class QwenAdapter implements ModelAdapter {
@Override
public String getModelName() { return "qwen-max"; }

@Override
public LlmResponse invoke(LlmRequest request) {
// 组装千问特定格式的请求体
QwenRequest qwenReq = QwenRequest.builder()
.model("qwen-max")
.input(QwenInput.builder().messages(request.getMessages()).build())
.parameters(QwenParams.builder().resultFormat("message").build())
.build();
// 发送HTTP请求并解析响应
return doInvoke(qwenReq);
}
}

@Component
public class DeepSeekAdapter implements ModelAdapter {
@Override
public String getModelName() { return "deepseek-chat"; }

@Override
public LlmResponse invoke(LlmRequest request) {
// DeepSeek兼容OpenAI格式
OpenAiRequest req = OpenAiRequest.builder()
.model("deepseek-chat")
.messages(request.getMessages())
.build();
return doInvoke(req);
}
}

路由层通过配置决定哪个场景走哪个模型：

llm:
routing:
SYMPTOM_ANALYSIS: qwen–max
MEDICAL_RECORD_SUMMARY: deepseek–chat
DRUG_INTERACTION_CHECK: qwen–plus

@Service
public class LlmGatewayImpl implements LlmGateway {
private final Map<String, ModelAdapter> adapterMap;
private final LlmRoutingProperties routingProperties;

public LlmGatewayImpl(List<ModelAdapter> adapters, LlmRoutingProperties props) {
this.adapterMap = adapters.stream()
.collect(Collectors.toMap(ModelAdapter::getModelName, a -> a));
this.routingProperties = props;
}

@Override
public LlmResponse chat(LlmRequest request) {
String modelName = routingProperties.getRouting()
.get(request.getScene());
ModelAdapter adapter = adapterMap.get(modelName);
if (adapter == null) {
throw new LlmException("未找到模型适配器: " + modelName);
}
return adapter.invoke(request);
}
}

这样新增一个模型只需要实现一个Adapter并注册到Spring容器，路由配置改一行YAML即可。

Prompt模板管理：把“提示词”当配置管

医疗场景的Prompt往往很长，包含角色设定、输出格式约束、安全边界等。硬编码在Java代码里会导致两个问题：一是修改Prompt要重新发版，二是无法做版本回滚和A/B测试。

推荐的做法是把Prompt模板外置到配置中心（Nacos/Apollo）或数据库，用占位符做变量替换：

@Component
public class PromptTemplateManager {
private final PromptTemplateRepository repository;

public String render(String scene, Map<String, Object> variables) {
PromptTemplate template = repository.findActiveByScene(scene);
if (template == null) {
throw new LlmException("未找到场景Prompt模板: " + scene);
}
String content = template.getContent();
for (Map.Entry<String, Object> entry : variables.entrySet()) {
content = content.replace("{{" + entry.getKey() + "}}",
String.valueOf(entry.getValue()));
}
return content;
}
}

症状识别的Prompt模板示例：

你是一名专业的医疗分诊助手。请根据患者描述的症状，给出可能涉及的科室建议和紧急程度评估。

患者主诉：{{symptom}}
患者年龄：{{age}}
既往病史：{{medicalHistory}}

要求：
1. 仅输出结构化的JSON，包含 department、urgency、suggestion 三个字段
2. urgency 取值为 HIGH/MEDIUM/LOW
3. 不做确定性诊断，仅做分诊参考
4. 如果症状描述包含胸痛、呼吸困难等急症关键词，urgency 直接标记为 HIGH

输出：

这里的关键是把安全约束写进Prompt模板本身，而不是依赖调用方每次拼装。模板一旦配置化，合规团队也可以参与审阅，而不只是开发在看。

限流：保护模型服务，也保护自己

大模型API通常有QPS限制，而且医疗系统的调用成本不低。如果前端不做控制，一次批量导入可能瞬间打出几百个请求，既可能被厂商限流封禁，也可能导致账单失控。

限流要分两个维度做：

• 全局维度：限制整个应用对某个模型的调用速率，避免触发厂商的QPS上限
• 用户维度：限制单个医生或单个终端的调用频率，防止滥用

用Redis + Lua脚本实现分布式限流（令牌桶算法）：

@Component
public class RedisRateLimiter {
private final StringRedisTemplate redisTemplate;
private static final String LUA_SCRIPT =
"local key = KEYS[1] " +
"local capacity = tonumber(ARGV[1]) " +
"local rate = tonumber(ARGV[2]) " +
"local now = tonumber(ARGV[3]) " +
"local requested = tonumber(ARGV[4]) " +
"local bucket = redis.call('hmget', key, 'tokens', 'lastTime') " +
"local tokens = tonumber(bucket[1]) or capacity " +
"local lastTime = tonumber(bucket[2]) or now " +
"local delta = math.max(0, now – lastTime) " +
"tokens = math.min(capacity, tokens + delta * rate) " +
"if tokens < requested then return 0 end " +
"tokens = tokens – requested " +
"redis.call('hmset', key, 'tokens', tokens, 'lastTime', now) " +
"redis.call('expire', key, 3600) " +
"return 1";

public boolean tryAcquire(String key, int capacity, double rate, int permits) {
DefaultRedisScript<Long> script = new DefaultRedisScript<>(LUA_SCRIPT, Long.class);
Long result = redisTemplate.execute(script,
Collections.singletonList(key),
String.valueOf(capacity), String.valueOf(rate),
String.valueOf(System.currentTimeMillis() / 1000.0),
String.valueOf(permits));
return result != null && result == 1;
}
}

在Gateway层做调用前拦截：

public LlmResponse chat(LlmRequest request) {
// 全局限流：每个模型独立配置
String globalKey = "llm:rate:global:" + modelName;
if (!rateLimiter.tryAcquire(globalKey, 100, 10.0, 1)) {
throw new LlmRateLimitException("模型调用频率超限，请稍后重试");
}

// 用户维度限流
String userKey = "llm:rate:user:" + request.getUserId();
if (!rateLimiter.tryAcquire(userKey, 20, 2.0, 1)) {
throw new LlmRateLimitException("您的操作过于频繁，请稍后再试");
}

return adapter.invoke(request);
}

限流异常要返回明确的业务提示，而不是直接抛500。医疗场景下，医生需要知道“是系统忙还是自己操作太快”，这影响他后续的行为决策。

结果缓存：医疗场景下的特殊考量

大模型调用又慢又贵，缓存是必选项。但医疗场景的缓存不能简单套用通用方案，有几个特殊点：

第一，缓存键的设计要区分场景。 同样的用户输入，在“症状识别”和“用药咨询”两个场景下应该命中不同的缓存。

第二，缓存内容涉及患者隐私。 缓存Key和Value中不能包含可识别患者身份的明文信息，必须做脱敏处理。

第三，医疗知识的时效性要求缓存有合理的TTL。 用药指南可能更新，缓存不能永久有效。

推荐用Redis做两级缓存，Key的构造规则：

public String buildCacheKey(LlmRequest request) {
// 对用户输入做归一化处理，去除无意义的空格和标点
String normalizedInput = normalize(request.getUserInput());
// 用SHA-256做摘要，避免明文出现在Key中
String inputHash = DigestUtils.sha256Hex(normalizedInput);
// 场景 + 模型 + 输入摘要 + 患者年龄段（脱敏后的粗粒度信息）
return String.format("llm:cache:%s:%s:%s:%s",
request.getScene(),
request.getModelName(),
inputHash,
request.getAgeGroup()); // 如 "30-40" 而非具体年龄
}

缓存查询与写入：

public LlmResponse chat(LlmRequest request) {
String cacheKey = buildCacheKey(request);

// 查缓存
String cached = redisTemplate.opsForValue().get(cacheKey);
if (cached != null) {
log.info("LLM缓存命中, scene={}, key={}", request.getScene(), cacheKey);
return LlmResponse.fromJson(cached);
}

// 缓存未命中，走限流和模型调用
LlmResponse response = doChatWithRateLimit(request);

// 写入缓存，医疗场景TTL建议24小时
if (response.isSuccess()) {
redisTemplate.opsForValue().set(cacheKey, response.toJson(),
Duration.ofHours(24));
}
return response;
}

需要注意，流式响应（streamChat）不适合做全量缓存，因为流式返回的内容是逐Token推送的。但可以对流式请求的“完整结果”做异步落库缓存，供后续相同请求直接返回非流式结果。

降级策略：模型不可用时怎么办

医疗系统7×24小时运行，模型服务随时可能抖动。降级方案要提前设计好：

• 一级降级：主模型超时或返回错误，自动切换到备用模型（如千问切DeepSeek）
• 二级降级：所有模型都不可用，返回预置的规则引擎结果（针对症状识别，可以用关键词匹配兜底）
• 三级降级：明确告知用户“AI服务暂时不可用”，引导至人工通道

public LlmResponse chatWithFallback(LlmRequest request) {
List<String> modelChain = routingProperties.getFallbackChain(request.getScene());

for (String modelName : modelChain) {
try {
ModelAdapter adapter = adapterMap.get(modelName);
return adapter.invoke(request);
} catch (Exception e) {
log.warn("模型 {} 调用失败, 尝试下一个", modelName, e);
}
}

// 所有模型都失败，走规则引擎兜底
return ruleEngineFallback(request);
}

降级链的顺序应该在配置中定义，而不是硬编码。不同场景对模型的偏好不同，比如病历摘要可能优先DeepSeek，症状识别优先千问。

可观测性：没有日志就没有稳定性

医疗系统的每一次模型调用都应该被记录，用于问题排查和成本核算。至少需要记录：

• 请求ID、场景、使用的模型、Prompt模板版本
• 请求耗时、Token消耗（输入/输出）
• 是否命中缓存、是否触发限流、是否走了降级
• 响应状态和错误码

用AOP切面统一埋点：

@Aspect
@Component
public class LlmCallLogAspect {
@Around("@annotation(llmLog)")
public Object logLlmCall(ProceedingJoinPoint pjp, LlmLog llmLog) throws Throwable {
long start = System.currentTimeMillis();
LlmRequest request = (LlmRequest) pjp.getArgs()[0];

try {
Object result = pjp.proceed();
recordMetrics(request, result, System.currentTimeMillis() – start, null);
return result;
} catch (Throwable t) {
recordMetrics(request, null, System.currentTimeMillis() – start, t);
throw t;
}
}
}

这些日志在合规审计时也是必要的证据——每一次AI参与医疗决策的过程都必须可追溯。

写在最后

医疗智能体的后端开发，本质上是在“AI能力的不确定性”和“医疗系统的高可靠性要求”之间架一座桥。模型本身的能力我们控制不了，但封装层、限流层、缓存层和降级层，都是我们可以控制的工程手段。

这套架构的核心思想是：把不确定性关进工程的笼子里。模型可能超时，但系统不能挂；模型可能返回错误，但医生必须得到明确的反馈；模型可能被限流，但业务必须有兜底路径。

如果你的团队正在做医疗AI的后端，建议从Gateway层的抽象开始，先把模型调用统一收口，再逐步补齐限流、缓存和降级。不要一开始就追求大而全，但每一层都要有清晰的边界和可观测性。

医疗场景没有“小故障”，每一次模型调用的稳定性，都关系到临床流程的顺畅和患者数据的安全。