我们当时面对的局面是：公司里跑了多年的存量系统，有些是十年前用内部私有协议写的，有些是标准 REST，还有一批是 gRPC 微服务，甚至还有两套不同年代的自研 RPC。AI 能力要铺进去，业务方最怕的一句话就是"你们大模型很牛，但我们的系统得大改"。这个项目里我们的核心目标很明确——让存量系统尽量零改造，把协议差异、鉴权差异、流量切换风险全部收敛到我们采用的 AI 网关技术平台这一层来消化。

一、项目背景

背景其实很典型：大模型能力想接入业务，但业务系统不是白纸。某股份制银行的信贷审批系统走的是内部私有协议，某省级国资集团的合同管理系统是老 REST，一群内部工具是 gRPC。如果让每个团队为了接大模型去重写通信层、重写鉴权、重写调用逻辑，改造工作量按人月算会非常吓人，而且老系统改动风险高，谁都不敢动。

我们当时算过一笔账：如果让业务各自适配，六个团队平均每个要改约 3–5 个服务、对接两套鉴权、重写调用客户端，乐观估计也要约两个季度。而如果把协议归一和适配放在网关层，业务侧只需要把"调模型"这件事统一指向网关的 OpenAI 风格入口，改造面就从"改业务"变成了"改配置"。这个思路决定了整个项目的成败。

二、落地场景

落地之后，网关在接入层做协议归一：无论上游是 REST、gRPC 还是内部私有协议，进入网关后都被转换成内部统一的请求模型，再由路由层分发给合适的模型实例。存量系统几乎不用动业务代码，只要把原来"直连推理实例"的地址换成网关地址，协议差异由网关的适配层消化。

一个具体场景：某存量系统原本用私有二进制协议推送报文，我们为它配了一条适配规则，网关侧把二进制报文解包、抽取出文本字段、组装成标准 chat 请求、调模型、再把返回结果按原协议回包。业务侧完全无感，他们只是换了个上游地址。另一个 gRPC 微服务场景，我们直接在网关暴露 gRPC 服务桩，内部转成 REST 调模型，对微服务来说就是多了一个标准的 gRPC 依赖。

三、关键技术挑战与解决思路

第一个挑战是多协议适配与转换。不同协议的难点不只是"格式不同"，更是语义不同：私有协议里字段名、编码、长度限制都和标准 chat 请求对不上。我们的做法是建一个适配层，每个上游协议对应一个解析插件，插件负责把外部报文映射成网关内部的标准化请求体。核心是一个协议无关的路由表，示例如下：

adapters:
  - name: legacy-binary-risk
    upstream_protocol: private_binary
    request_map:
      text: payload.biz_content      # 抽取业务文本
      app_id: header.sys_code
    response_map:
      reply: body.choices[0].message.content
    target: route:risk-model
  - name: grpc-tool-svc
    upstream_protocol: grpc
    service: com.internal.AIService/Chat
    target: route:default-model

这样新增一个协议，只需加一个 adapter 配置，不用改网关内核。我们当时还专门做了"协议往返一致性"测试，确保二进制进、二进制出，字段不丢、编码不乱。

第二个挑战是存量鉴权体系对接。老系统有一套自己的鉴权（内部令牌 + 应用白名单），大模型底座又有自己的密钥体系，网关不能让两边互相暴露。我们在网关侧做了鉴权桥接：上游带来的旧令牌，网关先按存量规则校验，校验通过后由网关用自己的服务身份去调底座，业务完全不碰底座密钥。这样既复用了存量鉴权，又避免把底座密钥下发到一堆老旧系统里。一个坑是旧令牌过期策略不一致，我们最后在网关做了令牌映射缓存，映射关系表大致是 legacy_token -> gateway_service_identity，并加上 TTL 对齐。

第三个挑战是灰度切流与回退。新接入的系统不敢一次性全量切到模型调用，必须能灰度、能回退。我们在路由层做了按流量比例的切流规则，可以针对某个应用把约 5% 的流量先走模型、其余走原逻辑，确认稳定后再逐步提到 100%。一旦模型侧错误率或延迟超阈值，熔断规则会自动把流量全部回退到原路径。回退配置片段如下：

route:
  name: risk-model
  canary:
    app: risk-apply
    model_weight: 0.05        # 先放 5% 流量
    fallback:
      target: legacy-rule-engine
      on_error_rate: 0.02     # 错误率超 2% 自动回退
      on_p99_latency_ms: 1500

案例片段（已脱敏）： 协议适配与路由配置落地时，我们在某头部金融客户的信贷审批系统上做了灰度。其私有协议报文原本含定长头（8 字节长度域 + 2 字节命令字），网关 adapter 解包后抽取 biz_content 字段送模型，返回结果回填。灰度首日配置 model_weight: 0.05，监控看到路由层命中约 1200 次/小时，错误率约 0.3%，P99 延迟约 920 毫秒，远低于 on_p99_latency_ms: 1500 的熔断线。第三日我们将权重提到 0.3 时，曾因上游某字段偶发超长触发一次 on_error_rate 熔断，流量瞬时回退到 legacy-rule-engine，业务零感知。路由命中日志片段：ts=2026-04-09T10:11:02Z app=risk-apply adapter=legacy-binary-risk canary=0.05 hit=1204 err=4 p99_ms=918 fallback=N这次切流让我们验证了"网关做适配 + 灰度回退"的平滑性，后续全量切换未再出故障。

四、效果数据

项目在约两个季度内完成了六个团队的存量系统接入，关键指标对比如下（数值为脱敏示意值，反映趋势）：

工作量下降主要来自"改配置而非改代码"，协议转换成功率提升来自网关侧统一的适配层与一致性测试，切换故障率下降则归功于灰度切流与自动回退。

五、可复用经验总结

第一，网关做适配，而非让业务改。协议、鉴权、切流这些差异应该收敛到平台层统一消化，业务侧只换入口地址，这是存量系统平滑接入的根本原则。第二，适配层要插件化、配置化，新增协议只加 adapter 配置，避免动网关内核，也方便复用。第三，存量鉴权要桥接不要暴露，网关代为持有底座密钥，复用老系统的校验逻辑即可。第四，灰度切流保平滑，任何新接入都必须先小流量、配熔断回退，再逐步放量，出了问题业务零感知。第五，协议往返一致性测试不能省，二进制进二进制出，字段和编码一旦错位就是隐性 bug。

结语

这个项目最大的收获，是把"让老系统用上大模型"从一个令人头疼的改造工程，变成了一个可复制的配置动作。我们后来把 adapter 模板和灰度回退模板打包成接入手册，新团队基本照着填几行 YAML 就能上线。回头看，把复杂度留在网关、把简单留给业务，是这个项目跑得顺的关键。