Java构建AI路由网关：大模型多接入统一管理实战

1. 从"接大模型"到"管大模型"：我们为什么要自己造一个AI路由网关

先说个背景。2024年下半年开始，我们团队的产品从传统CRUD向AI能力转型，接了多家大模型的API——当时是典型的"看到一家接一家"，ChatGPT、Claude、国产几家的模型全都在代码里硬编码。刚开始觉得挺爽，哪家效果好、哪家便宜就切哪家，一条配置改一下SDK就行。但等业务量上来，问题全浮出来了：每个模型厂商的鉴权方式不同、限流阈值不同、返回格式不同，SDK版本互不兼容，有的走HTTP轮询、有的走WebSocket；一线的研发同学每个人都在重复封装HTTP客户端、重试逻辑、Token计数和费用统计。更致命的是——业务的AI需求开始涉及多个模型配合调用，一个Agent任务要依次经过"意图识别→工具调用→结果生成"，这意味着同一个任务可能要在多个厂商的多个模型之间动态切换。

那时候我就意识到了一个问题：我们缺的不是"某个大模型的SDK"，而是一个统一的大模型接入层，一个"AI路由网关"。类比一下：在没有网关之前，每台业务服务器都要自己连数据库，改数据库地址要通知所有应用重启；有了数据库中间层之后，连接管理和读写分离都在这一层解决。AI路由网关就是大模型世界的中间层——所有上游业务只对接它，它负责把请求路由到正确的模型、正确的厂商、正确的基础设施。

说白了，这个网关要解决的事情有四个：

• 统一入口：业务方只面向一个接口，不关心背后是哪个大模型厂商。
• 智能路由：根据业务类型、Token成本、响应速度要求、模型可用性，动态路由；
• 优雅降级：主模型挂了自动切换备用模型，不影响线上业务；
• 成本可观测：每个请求消耗多少Token、多少钱、响应延迟多少，看得清清楚楚。

这篇文章就把我们团队从零建设这套系统的完整思路写下来，包括架构设计、Java核心实现细节、踩过的坑，以及我作为Java开发者的所有工程化思考。如果你也在做Java侧的AI工程化，或者正在被"多模型接入"折磨，这篇文章应该能给你一个相对完整的参考。

2. 整体架构：AI路由网关的模块划分与请求流转链路

2.1 先想清楚"网关管什么，不管什么"

在动笔写代码之前，我们反复讨论过一句话：**网关应该只做路由，不做业务。**这一点看似简单，执行起来极其容易走偏。

很多团队做AI网关，做着做着就变成了"AI服务编排平台"——把Prompt模板、知识库检索、工具调用全塞进网关。这种做法的好处是业务方接入成本极低，但代价是网关变成了一个随时爆炸的巨石，任何Prompt改动都要网关发版。我们最终定下来的边界是：

• 网关负责：接收请求、解析路由标识、匹配路由策略、调用目标模型、处理流式响应、收集指标、处理失败重试与降级；
• 网关不负责：业务上下文构建、Prompt模板管理、Agent工具链的编排（这些放在上层独立的Agent服务里）。

这个边界的好处很快就体现出来了。业务方负责思考"我用什么Prompt、要调用什么工具"，网关只负责高效、稳定、省钱地把请求送到正确的模型，两者通过一套标准协议协作，互不干扰。

2.2 网关整体模块划分

整个项目基于Java 17 + Spring Boot 3.x构建，核心模块分为以下几块：

2.3 一次完整请求的流转链路

请求的流转是整个系统的心脏。我直接用文字把这个链路捋一遍。

业务服务通过HTTP POST调用网关的/v1/route/chat接口，请求体带有routeTag（路由标签）和messages（对话消息），例如：

json复制{
  "routeTag": "customer_service_vip",
  "messages": [
    {"role": "user", "content": "我的订单什么时候发货？"}
  ],
  "stream": true
}

网关的接入层拿到这个请求后，第一件事是解析出routeTag，然后到路由表中查到对应的路由规则。路由规则决定了：目标模型是哪一个（比如是GPT-4o还是Claude Sonnet）、使用哪个Provider Adapter调用、超时时间多长、每秒最多允许多少并发、失败后降级到哪个备用模型。

接着，网关会把请求转换成目标模型厂商的原生格式。这个过程是Adapter模式的核心逻辑，在后续的第4部分我会详细介绍。

目标模型返回后（可能是实时SSE流式返回，也可能是完整JSON一次性返回），网关统一转换为自研的ChatResponse结构，再以SSE流式推送给业务方。这里有个关键设计：业务方感受到的永远是同一套返回结构，不管背后是OpenAI格式、Claude格式还是国产模型的格式。

整条链路的设计目标很简单——把复杂留在网关内部，把简单留给上游业务。业务方对接网关只需要一天，后续任何模型变更都不需要业务方改代码。

3. 路由表的建模方式：从"硬编码切换"到"可配置策略"

3.1 路由表的数据结构设计

AI路由网关的核心是路由表。这张表本质上回答一个问题：一个请求来了，我应该派给谁？

我们的路由表不是简单的"一个模型配一个Key"，而是分成了三层模型：

第一层：路由目标（Route Target）
路由目标代表一组可用的模型端点。每个路由目标包含：厂商类型、模型名称、API Key引用、Base URL、权重。

第二层：路由策略（Route Policy）
路由策略是一组规则集合，包含：可能的路由目标列表、选择模式（权重/优先/fallback）、超时配置、限流配置、降级配置。

第三层：路由标签（Route Tag）
路由标签是暴露给业务方的唯一标识。业务方调用时只传routeTag，网关根据路由标签查到对应策略，再根据策略实时决定目标模型。

这三层的关系我用代码来表达会更直观。

3.2 路由策略的核心Java实现

java复制public class RoutePolicy {
    private String policyName;
    private RouteStrategy strategy; // WEIGHTED, PRIORITY, FALLBACK
    private List<RouteTarget> targets;
    private Duration timeout;
    private int maxConcurrency;
    private String fallbackPolicy;
}

public class RouteTarget {
    private String targetId;
    private ProviderType providerType; // OPENAI, ANTHROPIC, ZHIPU, DASHSCOPE...
    private String modelName;
    private String apiKeyRef; // 引用密钥管理中心的Key ID
    private int weight; // 权重路由下的权重值
    private int priority; // 优先路由下的优先级，越小越优先
    private boolean enabled;
    private CircuitBreakerState cbState; // 熔断器状态
}

路由策略的选择过程我们写成了一个单独的RouterContext组件，这个组件维护了当前所有可用策略的快照，每个请求进来后按以下顺序决策：

text复制1. 根据routeTag查RoutePolicy；
2. 检查该策略下是否有可用目标（target.enabled == true && 熔断器闭合）；
3. 按策略模式选择目标：
   - WEIGHTED模式：按权重随机选择一个可用目标；
   - PRIORITY模式：优先选priority最小且可用的目标；
   - FALLBACK模式：主目标不可用时降级到备用目标；
4. 如果所有目标都不可用，进入降级逻辑（返回模型繁忙错误或调用降级模型）；
5. 如果降级也没有，返回503状态码 + 可读错误信息。

这里有一个很值得说的点：权重路由和优先级的差别，以及为什么我们最后两者都要支持。

权重路由适合的场景是成本优化。比如我们同时接了一个高精度高价模型和一个低精度低价模型，想让90%的简单请求走低价模型、10%的复杂请求走高价模型，用权重路由最合适。

优先级路由适合的场景是可靠性保障。比如某一个模型是主用模型，只有在主用模型故障时才切换到备用模型，这时候用优先级路由——主用模型的priority是1，备用模型是2，只要主用模型不熔断，请求永远走它。

这两者不能互相替代，所以必须都支持。最终我们通过在RoutePolicy里加了一个strategy字段来区分，每个策略模式对应一个独立的TargetSelector实现类，用策略模式解决。

3.3 动态刷新的关键机制

网关的配置必须能动态更新，否则每次调整路由权重都要重启服务，那就不是"网关"了，是个"静态路由表"。

我们用Nacos做配置中心，配置数据结构是JSON格式，变更后通过Nacos的监听器推送到各网关实例。监听器的实现方式如下：

java复制@Component
public class RouteConfigListener implements ApplicationRunner {
    
    private final NacosConfigManager nacosConfigManager;
    private final RouterContext routerContext;
    
    @Override
    public void run(ApplicationArguments args) {
        String dataId = "ai-gateway-routes.json";
        nacosConfigManager.getConfigService().addListener(dataId, new AbstractListener() {
            @Override
            public void receiveConfigInfo(String configInfo) {
                List<RoutePolicy> policies = JSON.parseArray(configInfo, RoutePolicy.class);
                routerContext.refreshPolicies(policies);
            }
        });
    }
}

这里踩过一个坑：RouterContext里保存的路由表是HashMap，多线程环境下一边读一边写，并发修改会导致读取到不完整的数据。一开始我们偷懒加了synchronized，结果在高峰期网关吞吐直接掉了30%，因为所有请求都在等一把全局锁。后来换成了CopyOnWriteArrayList加AtomicReference的方案——保存的是不可变快照，每次刷新创建新快照并原子替换，读请求完全无锁。这算得上是我们这个项目第一个有代表性的性能优化点。

4. 多模型接入的最佳实践：Adapter模式如何屏蔽API差异

4.1 为什么开源SDK不适合直接作为网关底座

刚开始我们确实考虑过直接用各家官方SDK，或者用LangChain4j这类集成框架。但试了一个星期后放弃了这个路线，原因很现实：

• 各家SDK的依赖版本冲突严重。OpenAI的SDK基于WebFlux，国产模型的SDK有的还基于OkHttp 3，在同一个Spring Boot应用里并存时，类冲突和信息不一致的问题处理起来极费精力。
• SDK本身迭代很快，且不完全可控。厂商改协议、改参数，我们只能等SDK更新，但网关这种基础组件不能跟着第三方SDK的节奏走。
• 无法做统一的流式处理。不同SDK对SSE的封装方式不一样，有的返回Flux<String>，有的基于回调，统一在网关层做流量控制和指标采集非常别扭。

所以我们最终决定：网关不依赖任何模型厂商的SDK，全部通过HTTP直连厂商API，用Adapter模式自行封装协议。

4.2 Provider Adapter的分层设计

我把Provider Adapter设计成三层：

java复制public interface ChatProvider {
    ChatResponse chat(ChatRequest request);
    Flux<ChatChunk> chatStream(ChatRequest request);
    ProviderType providerType();
}

这是最顶层的统一接口，业务方和网关核心链路只依赖这个接口。往下分两层：

• OpenAiChatProvider、ClaudeChatProvider、ZhipuChatProvider等具体实现类，每个类负责某一类厂商的真实协议交互；
• 每个实现类内部再拆出RequestConverter和ResponseParser，把内部统一的ChatRequest/ChatResponse与厂商的私有格式互转。

4.3 关键细节：流式响应处理的统一

流式是所有模型接入中最麻烦的环节，因为各家推送流式内容的方式不一样。

OpenAI系的接口是基于SSE的data:前缀推送；Claude的流式是event: message_start、event: content_block_delta事件流；国产的一些模型则直接在data字段里带整个增量JSON。如果每次都在上层业务里去解析这些差异，业务方的接入成本会高到爆炸。

网关的处理方式是这样的：

java复制public Flux<ChatChunk> chatStream(ChatRequest request) {
    return webClient.post()
            .uri(providerEndpoint)
            .bodyValue(converter.toProviderRequest(request))
            .accept(MediaType.TEXT_EVENT_STREAM)
            .retrieve()
            .bodyToFlux(String.class)
            .mapNotNull(this::parseSseEvent)
            .map(chunk -> converter.toUnifiedChunk(chunk));
}

parseSseEvent负责把厂商的原始流按规则拆成事件，toUnifiedChunk负责把厂商的增量数据转成统一的ChatChunk结构（包含content、toolCalls、finishReason等通用字段）。对于不标准的厂商，我们在Adapter层加了一个缓冲累积器，把碎片化的JSON片段攒成完整JSON后再解析。

这块我特别想提醒的一点是：**流式响应的超时控制比普通HTTP请求严格得多。**一个正常的SSE连接可能持续几十秒甚至几分钟，中间任何一段时间没有数据推送（比如模型在思考），就可能被网关或上游误判为超时。我们的方案是把流式超时分成首包超时（默认10秒内必须收到第一个数据包）和空闲超时（两个数据包之间最多间隔60秒），这两个参数都支持按路由策略单独配置。

5. 稳定性为王：熔断、隔离、限流和重试的Java实现细节

5.1 动态熔断器：不搞固定阈值，用滑动窗口

大模型API的故障模式非常具有"特色"——不是那种彻底的挂掉，而是间歇性的：先开始高延迟，然后逐步出现超时，再出现5xx错误，最后才完全不可用。按传统固定阈值熔断（比如错误率超过50%就熔断10秒），会导致大量请求在这种"半死状态"中痛苦挣扎。

我们参考了Resilience4j的思路，但做了两个调整：一是把熔断状态检查从每次请求前改成每个请求在路由阶段实时结算；二是引入了慢调用比例作为熔断指标。

java复制public class DynamicCircuitBreaker {
    
    private final SlidingWindowCounter counter;
    private final int failureRateThreshold = 50; // %
    private final int slowCallRateThreshold = 60; // %
    private final Duration slowCallDurationThreshold = Duration.ofSeconds(15);
    
    public synchronized void recordResult(Duration elapsed, boolean success) {
        counter.record(success, elapsed);
        if (getFailureRate() >= failureRateThreshold 
            || getSlowCallRate() >= slowCallRateThreshold) {
            state = State.OPEN;
            halfOpenTimer = now + Duration.ofSeconds(30);
        }
    }
    
    public boolean isAvailable() {
        if (state == State.CLOSED) return true;
        if (state == State.OPEN && now > halfOpenTimer) {
            state = State.HALF_OPEN; // 放一个试探请求
            return true;
        }
        return false;
    }
}

熔断状态变化会影响路由决策：一旦某个目标进入OPEN状态，这个目标会被路由表排除，请求自动转向其他备用目标。这个"排除"是动态的，完全不需要人工介入。

5.2 信号量隔离：比线程池隔离更适合网关场景

网关的外部依赖是HTTP调用，这种调用是IO密集型的，用线程池隔离会浪费大量线程资源在线程等待上，而且线程池的阻塞队列会让请求排队时间不可控。我们用的是信号量隔离：

java复制private final Semaphore semaphore = new Semaphore(config.getMaxConcurrency());

public void executeWithSemaphore(Runnable task) {
    if (semaphore.tryAcquire()) {
        try {
            task.run();
        } finally {
            semaphore.release();
        }
    } else {
        throw new TooManyRequestsException("No available semaphore permit");
    }
}

信号量隔离的好处是超出的请求立即返回失败，不会排队堆积，这对HTTP调用来说是最合理的行为——与其让请求在队列里等，不如让调用方立即感知到压力并作出降级响应。

5.3 限流策略：按"路由标签"维度限，而不是按"IP"维度限

一般的网关限流都做在IP维度或用户维度，但AI网关的核心指标是Token消耗速率和QPS，所以我们在路由策略维度做了两级限流：

• 第一级：全局QPS限流，针对每一个RouteTarget设置每秒最大请求数；
• 第二级：Token消耗速率限流，针对各模型厂商的 tokens-per-minute (TPM) 限制做平滑限制。

第二级特别重要。很多Java团队做AI网关时忽略了这个——只做了QPS限流，结果某个厂商的TPM限额被打满，返回429限流错误，业务方看到的是随机的报错。我们实现了一个基于令牌桶的Token速率限制器，每次请求前根据请求的预估Token数检查桶里是否有足够的配额，不够就直接拦截并让请求降级到备用模型，而不是先去请求厂商再挨一个429。

这里预估Token数的方法也简单说一下：我们不搞复杂的tokenizer，直接用 字符数 / 3 做粗估（中英文混合场景大概一个token对应2-4个字符），对大多数场景的误差在可接受范围。精确计费在响应完成后根据厂商返回的usage字段重新核算。

5.4 重试的幂等策略与"重试风暴"防范

模型调用失败后要不要重试，是个两难问题。重试太多，在厂商故障时会造成重试风暴，让原本就负担过重的模型服务雪上加霜；完全不重试，又会导致个别瞬时故障直接暴露给用户。

我们总结了一套适合AI网关场景的重试策略：

重试时还有个要点：请求体里带requestId作为幂等键，防止重试时厂商端重复扣费。这在多次重试时尤其重要，毕竟模型计费是按Token算的，一次请求扣两次费是纯粹的损失。

6. 可观测性与成本审计：Token计费系统的工程化设计

6.1 Metrics的埋点维度

网关的Metrics直接决定了线上问题排查效率和成本控制能力。我们从一开始就定了埋点维度，按标签组合来聚合：

text复制route_tag（路由标签）
provider_type（厂商类型）
model_name（具体模型）
target_id（路由目标ID）
status（成功/失败/降级/熔断）
error_type（超时/限流/服务端异常/网络错误）

埋点数据通过Micrometer发送到Prometheus，Grafana做好可视化面板。这里我要专门提一下我们踩过的坑：一开始把所有标签全部放进同一个Metrics名里，结果基数爆炸，Prometheus存储告警。后来拆成两个Metrics维度：一个ai_gateway_request_total带routeTag+status，一个ai_gateway_provider_metric_total带providerType+modelName+status。这样既保证了排障维度，又控制了基数。

6.2 Token费用计算的实现思路

Token计费在AI网关里属于"必须做且必须准确"的功能。我们的实现思路分三个环节：

请求预估计费（请求刚进来时）：根据输入字符预估Input Token数和预估费用，记入当日预算池；
响应实际计费（响应完成后）：根据厂商返回的usage字段实际扣减预算；
每日账单复核（异步任务）：基于全量请求明细表，精确计算每个部门、每个业务线、每个路由标签的日消耗和费用。

计费模块的数据结构：

java复制public class UsageRecord {
    private String requestId;
    private String routeTag;
    private String providerType;
    private String modelName;
    private int promptTokens;
    private int completionTokens;
    private int totalTokens;
    private BigDecimal cost;
    private String currency;
    private Instant startTime;
    private Instant endTime;
    private Duration latency;
}

费用计算规则放配置文件，类似price-config.json，每家的计价规则不一样，有些按百万Token定阶梯价，有些按时间段浮动。我们把计价器抽成了PricingCalculator策略接口，不同厂商价格策略不同，但对外暴露统一的计算方法。

6.3 分布式追踪：从业务请求到模型调用的完整链路

AI网关的另一个工程化硬性要求是：**当用户反馈"AI回答很慢"，我们必须能快速判断慢在哪。**为此，我们在网关中引入了基于Micrometer Tracing + Zipkin的分布式追踪方案。

每个进入网关的请求都会生成一个traceId并透传到模型厂商侧（放在请求头的X-Request-Id字段）。整个链路的关键节点都埋了Span：

• 网关接收请求（包含路由策略匹配时间）；
• 调用目标模型（包含网络耗时、等待TTFB时间、流式总时长）；
• 返回响应给业务方（包含下游消费耗时）。

线上排障时，通过Zipkin按traceId搜索，就能看到"业务调用网关耗时2s，网关路由耗时5ms，模型调用耗时1.8s，其中首包返回1.2s，流式传输600ms"。有了这种粒度，用户投诉时不再靠猜，一切都可定位。

7. 压测结果与性能调优：4个真正起作用的JVM参数与代码优化

7.1 压测场景与吞吐量数据

压测配置：4核8G的两台网关实例，接一个模拟的OpenAI接口（延迟150ms，返回2000个字符）。压测工具用wrk，从另一台机器发起。

压测结果（开启流式）：

这个数据验证了网关本身的性能不是瓶颈——瓶颈完全在模型API的延迟上。网关的存在给业务方带来的额外延迟约5-10ms，在可接受范围。

7.2 真正起作用的4个JVM参数

bash复制-Xms4g -Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=50
-XX:+UseStringDeduplication

这里重点说UseStringDeduplication——这个参数在AI网关场景特别有用，因为路由表、模型名、错误信息这些字符串在整个JVM堆里大量重复，开启字符串去重后，GC压力明显下降，我们在压测中看到GC暂停时间从120ms降到了50ms以内。

另外，**网络层调优比JVM调优更立竿见影。**我们把Tomcat的acceptCount从默认100调到500，maxThreads从200调到400，并将ConnectionTimeout从20秒降到5秒。而真正质变的是引入响应式WebFlux来承接SSE流式转发——不使用异步架构的话，流式响应会长期占用Tomcat线程，200个并发流式请求就能打满默认线程池。这是Java开发者在做AI类网关时必须想清楚的架构决策。

7.3 代码层面的三个性能优化

第一是避免访问日志打全量请求体。很多团队为了排查问题，会把请求消息体打到日志里。大模型的请求体动辄几千字，高并发下磁盘日志能撑爆。我们的方案是只记录消息前200字符和Token预估数，完整请求体存到对象存储，按requestId可追溯。

第二是JSON序列化全部用Jackson的DataFormat + 预编译。我们实际压测中发现，每次请求做两三次全量Jackson序列化和反序列化，在600QPS下就会占掉大约120ms的CPU时间。后来把请求和响应的DTO都改成手动预编译的ObjectMapper配置，开了DeserializationFeature.USE_JAVA_ARRAY_FOR_JSON_ARRAY，性能提升约15%。

第三是自研了HTTP连接池复用。Spring的WebClient默认连接池配置非常保守，我们手动调高了maxConnections和pendingAcquireTimeout，并且对每个Provider维护独立连接池——这样某个厂商的地址变更或协议异常不会污染全局连接池。

8. 避坑总结：AI路由网关开发中最容易翻车的5个细节

代码层面该讲的都讲得差不多了，最后把这几个月踩得最深的几个坑单独拉出来说一遍。

8.1 流式响应返回后Connection: keep-alive处理

SSE流式响应用的MediaType是text/event-stream，但很多Java开发者会踩这个坑：响应头里没有显式声明Cache-Control: no-cache和X-Accel-Buffering: no，导致某些Nginx层或浏览器层把流式响应缓存住，用户看到的就是"回答一个字一个字地蹦出来"或者"回答全被打断"。处理方式是网关返回流式响应时，强制统一设置这两个Header。

8.2 Token计费必须考虑缓存命中和工具调用的重复Token

如果上层业务有Prompt缓存，那么同一个请求可能会命中缓存，此时实际只会产生输出Token费用，不产生输入Token费用。计算费用必须基于厂商返回的usage字段而非预估费用。另外Agent场景的多轮工具调用，同一段上下文会被重复计费多次，这一点也要在计费明细中体现出来——我们一开始没做区分，财务对账时对不上，后来加了billingType字段（NEW_INPUT / CACHED_INPUT / OUTPUT）才解决问题。

8.3 不能忽略的DNS缓存问题

调用厂商API时，DNS解析结果是会缓存的。在Java中默认的JVM DNS缓存是30秒，但一旦厂商CDN切换IP，网关拿到旧IP连接会持续失败。我们把网络层切到HTTPClient的自定义DNS解析策略，把缓存时间设为5秒。这个坑在厂商故障切换时特别致命——厂商那边已经切到备用节点了，我们这边还死死连着一个超时的IP。

8.4 配置热更新的一致性

前面说到了用Nacos做动态配置，但有一个隐患：多实例部署时，配置下发到各实例存在秒级的时间窗口，导致同一时刻不同实例路由策略不同。在流量高峰期，这会造成部分请求走新策略、部分请求走旧策略。我们的解法是给发布操作加了一个version字段，网关在请求开始和请求结束两个阶段检查版本号一致性，如果不一致则放弃响应结果，让调用方重试。这个机制虽然简单，但能保证事务的一致性。

8.5 不要忽略上游业务方的超时设置

最后这个坑是和我们对接的兄弟团队踩的。他们业务服务的HTTP Client设置了3秒超时，但网关调用大模型进行流式生成，一个普通问题的首包返回可能就需要3秒以上。结果就是业务方不断主动断开连接，网关这边还在继续消耗模型额度生成回答。后续我们在网关接入文档里强烈建议：调用AI网关时，超时必须分为"连接超时"（建议3-5秒）和"读取超时"（建议60秒以上），并且对接时要在黑洞流量上线前先用小流量验证超时设置是否合理。

9. 从网关到AI基础设施的延伸思考

网关上线至今运行了4个月，最高日处理请求量约50万次，成功率保持在99.5%以上。这个系统帮我们解决的不仅是"多模型切换"的问题，更重要的是建立了一套可度量的模型接入规范：任何新模型接入，只要写一个新的Provider Adapter，配置好路由策略，当天就能全量上线，完全不需要业务方参与。

这段经验带给我的思考是：**Java在AI工程化领域不是配角。**大模型应用层的"工程难点"恰恰不是算法调参，而是稳定性的保障、成本的控制、协议的统一、容灾与降级的机制——这些全都属于Java后端工程师最擅长解决的问题。AI路由网关只是一个起点，接下来我们正在规划的是统一的工具调用网关（Tool Gateway）和多模型协同调度器（Agent Orchestrator），方向依然是"把复杂留给基础设施，把简单留给业务"。

如果这篇文章让你对Java做AI基础设施产生了兴趣，我的建议是不要从开源框架开始，而是先用Spring Boot自研一个小型网关，跑通一个透明转发的过程，再逐步加路由、加熔断、加计费。等亲自踩过一遍之后，你就知道哪些地方该框架化，哪些地方必须自己掌控。AI开发的核心不是调用大模型的能力，而是工程化地管理大模型的能力——这句话，我越来越确信。