这次我们来看一个偏后端架构的话题Agent 接口的高并发防护。很多人以为 Agent 接口和普通 REST 接口一样加个网关、上个 Nginx 就能扛住流量。但实际上一旦你的 Agent 接口开始承担真实业务问题会很快暴露大模型推理耗时长、工具调用依赖外部服务、多轮会话要保存上下文、用户重试频率高任何一个环节被拖垮整条链路都会雪崩。标题里那句话说得有道理Agent 高并发比普通接口猛多了。这不是说 Agent 接口本身性能更好而是说它对高并发防护的要求远高于普通接口。普通接口扛不住返回 500 顶多是一台机器报错Agent 接口扛不住可能会打垮数据库、拖垮下游工具服务、耗尽连接池最后连带其他业务一起挂掉。这篇文章会围绕四层防护展开缓存、限流、负载均衡、熔断。我会按实际工程落地的顺序给出每层的定位、代码示例、配置方式、验证方法和排查思路。读完你可以直接把这套结构套到自己的 Agent 服务上。1. 核心能力速览先给一张总览表明确四层防护各自解决什么问题。防护层核心作用典型组件/技术针对的高并发问题缓存层命中重复请求减少模型推理和下游调用Redis、本地 Caffeine、多级缓存热点问题重复计算、上下文重复加载限流层控制进入 Agent 服务的流量速率和并发数Sentinel、Resilience4j、Guava RateLimiter突发流量打爆服务线程池负载均衡层把请求分散到多个 Agent 实例Nginx、Spring Cloud LoadBalancer、K8s Service单点压力过大熔断层下游或模型服务异常时快速失败避免长期阻塞Sentinel 熔断规则、自定义 Fallback下游慢调用拖垮整个链路这套四层防护的核心思路是缓存层用来“少算”。限流层用来“挡住”。负载均衡用来“分散”。熔断用来“放弃”。每一层都只解决一个问题但叠加在一起就能显著降低 Agent 服务的雪崩风险。2. 适用场景与使用边界这套方案适合以下场景基于大模型 API 的 Agent 应用后端用户请求量大需要控制成本。Agent 服务需要调用多个外部工具或内部服务存在下游不稳定因素。多人共用的企业级 Agent 平台需要保证多租户隔离和资源公平。准备上线生产环境的 Agent 项目需要压测和容量规划。需要说明的是这四层防护并不能解决所有问题。它们不能提升模型本身的推理能力不能替代业务层的幂等设计也不能帮助无关的重复请求实现“智能化”。如果一个 Agent 接口本身的业务逻辑混乱那么加再多防护也只是把问题推迟。另外一个重要的边界是成本控制。缓存的本质是拿存储换计算对 Agent 场景来说就是用便宜的 Redis 访问替换昂贵的模型推理。但如果你的场景每次请求上下文都完全不同、几乎不可能命中缓存那么缓存层的意义就非常有限。这时候更应该把重心放在限流和熔断上。合规方面如果 Agent 服务会处理用户隐私数据、企业文档或个人敏感信息需要确保缓存中的数据有合理的过期策略和访问控制避免把用户 A 的上下文返回给用户 B。涉及第三方模型 API 时也要确认供应商的数据使用条款不能把敏感数据随意缓存到外部 Redis 或 CDN。3. 环境准备与前置条件本文的示例以 Java Spring Boot Redis Sentinel 为主这也是目前 Agent 后端最常见的技术组合。如果你使用 Python 技术栈思路完全一致把组件替换成 Redis 客户端和对应的限流库即可。推荐环境清单如下依赖项推荐版本/说明JDK17 及以上Spring Boot 3 需要Spring Boot3.x方便集成 Spring Cloud AlibabaRedis6.x 或 7.x用于缓存和分布式限流Sentinel Dashboard1.8.x用于可视化限流和熔断规则配置Nginx1.20用于反向代理和负载均衡Maven/Gradle任一用于构建项目如果只是本地验证不一定要完整部署 Sentinel Dashboard可以先通过代码方式和配置文件定义规则后续上线前再接入控制台。需要预留的磁盘空间取决于模型框架和日志量单纯搭建这套四层架构不算大关键的资源消耗在模型推理服务本身。如果你用的是在线大模型 API那么 Agent 服务只是一个编排层硬件要求不高如果是本地推理那还需要准备 GPU 资源这个不在本文展开。4. 环境准备与前置条件沿用上一部分的技术栈选择。为了让后面每一层都有对应代码可跑我先给出一个最基础的 Agent 接口样例。这个样例故意只做最简单的事接收用户问题调用一个模拟的大模型服务返回答案。先创建一个 Spring Boot 项目依赖包含spring-boot-starter-web、spring-boot-starter-data-redis、spring-cloud-starter-alibaba-sentinel。以下是核心接口代码RestController RequestMapping(/agent) public class AgentController { private static final Logger log LoggerFactory.getLogger(AgentController.class); PostMapping(/chat) public AgentResponse chat(RequestBody AgentRequest request) { // 这里先直接调用一个模拟的 Agent 服务 String answer agentService.chat(request.getUserMessage()); return new AgentResponse(answer); } }AgentService 模拟一次耗时的推理调用Service public class AgentService { public String chat(String userMessage) { // 模拟大模型推理耗时 2-5 秒 try { Thread.sleep(ThreadLocalRandom.current().nextLong(2000, 5000)); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return Agent answer for: userMessage; } }这个版本没有任何防护。压测时你会发现一个实例的线程池很快被打满Tomcat 默认 200 个线程一旦耗尽后续请求全部排队响应时间从 2 秒飙升到 10 秒甚至更长。接下来我们逐层加固。5. 缓存层先把重复请求挡在门外Agent 接口的缓存和普通接口有一个显著区别普通接口缓存的是数据库查询结果Agent 接口缓存的是“模型的答案”或者“中间计算结果”。从实践看Agent 场景适合做缓存的点有三个第一个是固定 Prompt 固定参数的模型结果。很多 Agent 工具节点其实是在调用同一个 Prompt入参变化不大时结果可以直接缓存。例如翻译、摘要、关键词提取这类任务相同的输入在短时间内再次请求的概率非常高。第二个是工具调用结果。Agent 在执行过程中会去查天气、查订单、查文档这些下游服务的响应往往在几分钟内有效缓存可以减少对第三方服务的重复请求既省钱又稳定。第三个是会话上下文快照。多轮对话 Agent 每轮都要把历史消息发给模型如果用户频繁刷新页面或重试可以用 Redis 按会话 ID 缓存上下文减少重复组装。下面是使用 Redis 缓存模型结果的示例Service public class CachedAgentService { private static final String CACHE_KEY_PREFIX agent:answer:; private final StringRedisTemplate redisTemplate; private final AgentService agentService; public CachedAgentService(StringRedisTemplate redisTemplate, AgentService agentService) { this.redisTemplate redisTemplate; this.agentService agentService; } public String chat(String userMessage) { String cacheKey CACHE_KEY_PREFIX DigestUtils.md5DigestAsHex(userMessage.getBytes()); String cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return cached; } String answer agentService.chat(userMessage); redisTemplate.opsForValue().set(cacheKey, answer, Duration.ofMinutes(10)); return answer; } }缓存层引入后还要处理三个经典问题。第一个是缓存穿透。如果用户传入的 key 在缓存和模型层都不存在每次请求都会穿透到模型服务。可以用空值缓存或者用布隆过滤器拦截明显不存在的 key。对 Agent 场景更实际的做法是对非法输入和空输入直接拒绝不在下游做无意义推理。第二个是缓存击穿。某个热点 key 在过期瞬间被大量请求同时访问会同时打到模型服务。解决方案是加互斥锁只让一个请求去重建缓存其他请求短暂等待。public String chatWithLock(String userMessage) { String cacheKey CACHE_KEY_PREFIX DigestUtils.md5DigestAsHex(userMessage.getBytes()); String cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return cached; } // 用 Redis 分布式锁防止缓存击穿 String lockKey lock: cacheKey; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { return cached; } String answer agentService.chat(userMessage); redisTemplate.opsForValue().set(cacheKey, answer, Duration.ofMinutes(10)); return answer; } finally { redisTemplate.delete(lockKey); } } // 没拿到锁的请求短暂等待后重读缓存 try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return redisTemplate.opsForValue().get(cacheKey); }第三个是缓存雪崩。大量 key 在同一时间过期导致请求集中打到下游。解决方式是给过期时间加随机偏移避免同一秒内集体失效。关于缓存一致性Agent 场景通常不追求强一致因为模型结果本身有随机性。如果某个业务要求工具调用结果必须最新比如查实时库存那就不应该缓存或者设置非常短的过期时间如 30 秒。6. 限流层控制进入 Agent 服务的流量缓存解决的是“能省则省”的问题限流解决的是“撑不住时怎么办”的问题。Agent 接口的限流策略和普通接口不太一样。普通接口关注 QPSAgent 接口还要关注并发线程数。因为一个 Agent 请求可能持续 5 秒如果 QPS 限得不高但并发数没限制线程池依然会被耗尽。6.1 按 QPS 限流使用 Sentinel 给/agent/chat接口配置 QPS 限流规则代码如下Configuration public class SentinelConfig { PostConstruct public void initFlowRules() { ListFlowRule rules new ArrayList(); FlowRule rule new FlowRule(); rule.setResource(/agent/chat); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); rule.setCount(20); rules.add(rule); FlowRuleManager.loadRules(rules); } }这个规则的含义是/agent/chat接口每秒最多通过 20 个请求超过部分直接抛出BlockException不会进入业务代码。在大模型服务中20 QPS 已经是不小的压力因为每个请求背后都是一次 3 秒以上的模型调用。按并发线程数算20 QPS * 5 秒耗时 100 个并发线程这已经逼近 Tomcat 默认线程池的一半了。6.2 按并发线程数限流更好的做法是两者结合QPS 限制控制入口流量线程数限制控制资源占用。FlowRule threadRule new FlowRule(); threadRule.setResource(/agent/chat); threadRule.setGrade(RuleConstant.FLOW_GRADE_THREAD); threadRule.setCount(10); rules.add(threadRule);这样即使 QPS 很高同一时刻进入模型调用的线程也不会超过 10 个超出的请求直接快速失败而不是排队等着。6.3 限流降级处理被限流的请求不能直接返回空白页要给出明确提示。用SentinelResource定义 fallbackPostMapping(/chat) SentinelResource(value /agent/chat, blockHandler chatBlockHandler) public AgentResponse chat(RequestBody AgentRequest request) { return new AgentResponse(agentService.chat(request.getUserMessage())); } public AgentResponse chatBlockHandler(AgentRequest request, BlockException e) { log.warn(请求被限流: {}, message{}, request.getUserMessage(), e.getMessage()); return new AgentResponse(系统繁忙请稍后重试); }这里需要说明限流值不是拍脑袋定的要通过压测反推。先跑一个 10 线程的压测观察响应时间和错误率找到拐点再按拐点的 70% 到 80% 设置限流值。关于滑动窗口限流和令牌桶限流的取舍简单说Sentinel 默认的 QPS 统计是基于滑动窗口的能更好应对突发流量令牌桶适合均匀放行但对瞬间突刺的容忍度低。Agent 接口建议用 Sentinel 的滑动窗口模式配合线程数限流效果比单独用令牌桶更稳。如果团队没有引入 Sentinel也可以先用Resilience4j或Guava RateLimiter做单机限流但多实例部署时要注意每个实例是独立计数的同一个用户可能被不同实例各放行一次。要保证全局精确需要把计数放到 Redis。这也就是为什么生产中更推荐 Sentinel 的原因之一。7. 负载均衡层把流量分散到多个实例单个 Agent 服务实例的容量是有限的。限流策略可以防止单台机器被打爆但如果所有流量都打到一台机器上哪怕限流让他不死吞吐量也就那样。负载均衡的作用是把流量分散到多台机器上。常见做法有两种在 Nginx 层做反向代理负载均衡。在微服务注册中心做服务发现和客户端负载均衡。7.1 Nginx 配置对于直接对外提供 HTTP 接口的 Agent 服务Nginx 是最简单的负载均衡方案。upstream agent_backend { server 192.168.1.10:8080 weight3 max_fails3 fail_timeout30s; server 192.168.1.11:8080 weight2 max_fails3 fail_timeout30s; server 192.168.1.12:8080 weight3 max_fails3 fail_timeout30s; keepalive 64; } server { listen 80; server_name agent.example.com; location /agent/ { proxy_pass http://agent_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Request-Id $request_id; proxy_connect_timeout 5s; proxy_read_timeout 60s; } location /actuator/health { proxy_pass http://agent_backend; proxy_connect_timeout 2s; proxy_read_timeout 5s; } }这里有几个针对 Agent 场景的关键配置。proxy_read_timeout需要根据模型最长响应时间设置。如果你的 Agent 服务最慢要 30 秒那超时时间就得大于 30 秒否则 Nginx 会在模型还没返回时提前断开连接。健康检查路径要独立配置短超时。/actuator/health不能跟业务接口共用 60 秒读超时否则服务已经卡死但健康检查还在等待Nginx 会继续把流量打进去。7.2 多实例部署的注意事项Agent 服务多实例部署后要注意三个问题。第一个是本地缓存的数据不一致。如果用了 Caffeine 本地缓存同一个用户的请求在不同实例上会各自缓存一份。轻微的冗余没问题如果业务要求严格一致就得把缓存全部放到 Redis。第二个是会话粘滞问题。多轮会话如果只存在实例本地内存那么负载均衡策略要按用户维度做会话保持比如 Nginx 的ip_hash。但更推荐的做法是把会话上下文放到 Redis让每个实例都是无状态的这样任意实例都能处理任意用户的请求扩缩容也更方便。第三个是线程池隔离。启动多个实例后每个实例有自己的 Tomcat 线程池和模型调用线程池这本身就是一种天然隔离。需要注意总并发不等于单实例并发乘以实例数因为模型服务或下游 API 通常也有自己的配额。从负载均衡的视角看最简单有效的架构是Nginx 承担入口流量分发Spring Boot 实例无状态化Redis 负责共享会话和缓存。这样你可以在高峰期轻松把 Agent 服务从 3 个实例扩到 10 个不需要改动代码。8. 熔断层下游不可用时快速失败熔断是四层防护里最后一道也是最关键的一道。Agent 服务与普通服务相比对下游的依赖更重。一个 Agent 请求可能先调用模型 API再调用搜索服务再调用内部知识库最后再调用一次模型 API。如果其中一个下游服务变慢整个 Agent 请求都会被拖住长时间占用线程。如果下游服务直接挂掉当前请求必然超时失败大量请求还会不断重试加剧下游的压力。熔断的思路是当某个下游或接口的错误率或慢调用比例超过阈值时直接打开断路器后续请求不再真实调用下游而是快速走 fallback。给下游一段时间恢复恢复后再放部分流量试探。8.1 使用 Sentinel 配置熔断规则针对 Agent 服务调用的模型 API可以定义一个熔断规则PostConstruct public void initDegradeRules() { ListDegradeRule rules new ArrayList(); DegradeRule rule new DegradeRule(); rule.setResource(callLLM); rule.setGrade(RuleConstant.DEGRADE_GRADE_RT); rule.setCount(5000); rule.setTimeWindow(10); rules.add(rule); DegradeRuleManager.loadRules(rules); }以上规则含义是callLLM资源的平均响应时间超过 5000 毫秒时触发熔断熔断持续 10 秒10 秒后进入半开状态尝试放行少量请求。在代码中给大模型调用方法加上资源和 fallbackService public class LLMService { SentinelResource(value callLLM, fallback llmFallback) public String call(String prompt) { // 调用大模型 API return restTemplate.postForObject(https://api.model.com/v1/chat, prompt, String.class); } public String llmFallback(String prompt, Throwable throwable) { log.error(LLM 调用失败prompt{}, prompt, throwable); return 模型服务暂时不可用请稍后重试; } }熔断的 fallback 和限流的 blockHandler 有一点区别blockHandler 处理的是流量控制被拦截的情况fallback 处理的是业务异常、超时和熔断的情况。实践中两个都要配。8.2 熔断与限流的配合熔断不能替代限流限流也不能替代熔断。限流是在上游流量过大时进行拦截保护的是 Agent 服务自身。熔断是在下游出现问题时进行拦截保护的是 Agent 服务不被下游拖垮。举例假设模型 API 的响应时间从 2 秒变成 30 秒此时 QPS 并没有上涨限流不会触发但每个请求都会卡 30 秒。线程池很快被堆积的请求占满。熔断的作用就是在平均 RT 超过阈值时快速切断让后续请求立即走 fallback释放线程。熔断和限流都触发时请求进入 fallback 的顺序是先判断限流规则再判断熔断规则。两者都通过才进入真实业务调用。8.3 Agent 调用链路中的超时设置熔断要生效前提是每层调用都有合理的超时时间。常见的错误是只设置了 RestTemplate 的读超时但没有设置连接超时或者没有给整个 Agent 编排流程设置一个总超时。推荐的超时设计如下层级超时时间说明模型 API HTTP 调用10s必须明显大于模型 P99 响应时间工具调用3s工具调用通常比模型调用快很多数据库查询1s数据库不应该成为瓶颈整个 Agent 编排流程20s超过直接终止释放线程Nginx 层30s大于整个编排流程的超时即可每个超时都要配置缺一层就可能导致线程被无谓占用。9. 四层联动一次完整请求的处理链路到现在四层防护都讲完了。我们可以把一次完整的 Agent 请求处理链路串起来看。假设用户通过前端发起聊天请求请求路径如下请求先到达 Nginx 负载均衡层Nginx 根据负载策略把请求转发到某个 Agent 实例。Agent 实例接收请求先经过限流层。如果当前 QPS 或线程数超过阈值直接返回“系统繁忙”。请求通过限流后进入缓存层。如果 Redis 中已有相同问题的答案直接返回不进入模型调用。缓存未命中Agent 服务开始编排先调用大模型 API再调用工具服务最后整理答案。在编排过程中如果大模型 API 的响应时间超过了熔断阈值熔断器打开后续请求直接走 fallback。如果大模型 API 正常但工具服务超时需要由工具调用层的超时配置兜底防止整个流程无限等待。答案生成后写入 Redis 缓存返回给用户。这个过程中每一层都可能失败每一层失败时都应该有对应的降级响应。完整方案下用户感知到的应该是正常时得到答案异常时得到明确提示而不是无限转圈或页面直接 500。四层顺序安排有一个原则越靠近用户入口的防护越应该“简单快速”。Nginx 负责转发和健康检查不负责业务判断限流层只做计数和拦截不进行复杂的逻辑判断缓存层只做存取不编排业务熔断发生在调用下游时是最后一道防线。10. 资源占用与性能观察方法这四层防护在运行中会产生额外的资源开销需要观察以下方面。10.1 线程池状态Agent 服务最需要关注的是 Tomcat 线程池和自定义的异步线程池。线程池指标通常可以通过 Spring Boot Actuator 暴露也可以直接看 JVM 线程快照。关键指标活跃线程数如果长期接近最大值说明请求堆积严重。队列大小线程池队列增长说明处理速度跟不上请求速度。拒绝任务数如果出现任务拒绝说明需要降级限流或扩容。10.2 Redis 连接数与内存缓存层引入 Redis 后要关注 Redis 的connected_clients、used_memory和keyspace_hits/miss比例。命中率是缓存层效果最直接的指标。如果命中率长期低于 30%说明缓存设计可能有问题大部分计算的 key 没有重复访问价值。如果命中率高于 90%也可能说明缓存过期时间设置过长导致数据更新不及时。10.3 Sentinel 控制台指标Sentinel Dashboard 上可以看到每个资源的 QPS、拒绝 QPS、响应时间、异常比例。压测时重点观察“拒绝 QPS”是否在预期范围。如果拒绝率过高说明限流值设置太保守如果拒绝率很低但响应时间持续上升说明限流值设置太激进实际容量已经不够用了。10.4 压测前后对比先把最基础的 Agent 接口直接压测记录最大并发、P95 响应时间、错误率。然后逐层叠加缓存、限流、熔断每次压测记录相同指标。一个可参考的对比表格场景最大并发P95 响应时间错误率观察结论无防护200 线程压测全部超时高线程池被打满加缓存200 线程压测部分接近重复明显下降下降热点请求被缓存挡住加限流设置 QPS 50稳定拦截提示正常超出部分直接 fail-fast加熔断模拟下游 30s 慢调用快速失败错误率降低熔断保护生效这里没有给固定数字因为每台机器的性能和模型调用耗时都不同。你需要在自己的环境里跑出数据找到拐点。11. 常见问题与排查方法在实际落地这四层架构时会遇到不少问题。下面按现象列出排查思路。问题现象可能原因排查方式解决方案高并发下 Tomcat 线程池打满限流未生效或阈值过高查看 Sentinel 监控QPS 和拒绝数调低 QPS 阈值增加线程数限流缓存命中率极低key 设计粒度过细查看 Redis keyspace_hits 和 miss调整缓存 key 粒度加粗结果缓存限流后大量请求返回 500未配置 blockHandler检查异常类型是否为 BlockException为 SentinelResource 添加 blockHandler下游变慢但熔断不触发RT 阈值设置过低请求快速报错而不是慢检查资源平均响应时间和异常比例改用异常比例熔断规则请求通过 Nginx 后服务经常超时proxy_read_timeout 小于实际业务耗时查看 Nginx error.log调大 proxy_read_timeout多个实例限流效果不一致使用了单机限流规则查看 Sentinel 集群流控配置接入 Token Server 或改用 Redis 计数Redis 缓存中有脏数据缓存过期时间过长对比缓存值和源数据更新时间缩短过期时间或主动失效Agent 编排流程卡死工具调用没有设置超时查看堆栈定位阻塞调用给每个下游调用配置独立超时熔断恢复后立即再次熔断半开状态试探流量过大查看熔断日志和流量曲线降低半开最大请求数并发较高时 Sentinel 控制台显示空白Dashboard 与客户端版本不匹配检查版本一致性统一 Spring Cloud Alibaba 版本这套排查思路的核心是先确认是哪一层出了问题再看这一层的指标和日志。不要一上来就改代码先把限流、缓存、熔断分别从链路上拆开验证。12. 最佳实践与使用建议最后给出一些工程落地建议都是实际项目中容易踩坑的地方。第一先小流量测试再全量上线。四层策略全部配好后先只放 5% 的流量观察指标确认无异常再逐步放开。第二规则配置与代码分离。限流阈值、熔断时间窗口这些参数不要硬编码在主流程里放到配置中心或 Sentinel Dashboard方便动态调整。第三每一层都要有日志输出。限流触发日志、缓存命中日志、熔断触发日志、降级返回日志最好都带上请求 ID方便串联排查。第四缓存和限流要区分用户维度。多租户场景下一个用户疯狂调用不应该影响其他用户。可以用 Sentinel 的资源名拼接用户 ID 或租户 ID 来做隔离。String resourceName /agent/chat: request.getUserId();第五所有降级返回信息要保持友好。用户看到“系统繁忙请稍后重试”可以接受但不要返回一长串堆栈异常。第六涉及用户数据和第三方模型服务的场景务必注意授权问题。缓存数据要脱敏用户会话内容要设置合理的有效期不能为了追求缓存命中率把敏感数据长期存在 Redis 里。第七压测是必须的但压测数据不要只看平均值。重点关注 P95、P99 和错误率这三个指标才能反映真实用户体验。13. 总结与下一步这篇文章介绍了 Agent 接口高并发防护的完整四层结构缓存层减少不必要的模型调用限流层控制入口流量负载均衡层分散压力熔断层防止下游故障拖垮整个服务。最值得先做的事情是先给你的 Agent 接口加上缓存和限流因为这两步改动最小、效果最明显。缓存能直接降低模型调用成本限流能保护服务不被打垮。等这两层稳定后再加入熔断和负载均衡。最容易踩的坑有三个一是设置了限流但没有配置 fallback导致大量请求返回 500二是熔断阈值设置不合理要么经常误触要么下游已经慢到不可接受还没有触发三是下游调用没有超时时间导致整个 Agent 编排流程被一个慢请求无限阻塞。如果把前面的示例代码整合到一个 Spring Boot 项目里你可以得到一套最小可用的 Agent 高并发防护骨架。下一步可以按自己的业务场景补充接入真实大模型 API、增加多租户隔离、把规则配置迁移到 Nacos、用压测工具跑出真实的容量拐点。四层防护不是把系统变复杂而是让系统在异常情况下依然能给出明确的、快速的、可预期的响应。这比一个随时可能雪崩的“高性能”接口重要得多。