企业官网建设流程全解析

直接对接多家模型API干了半年之后，我做的第一件事就是在应用和模型之间加了一层网关。不是赶时髦，是疼够了。手里的Key从一把变成三把，每个模型厂商的请求格式都长得不一样，参数名一会儿是max_tokens一会儿是max_new_tokens，limit一会儿是请求次数一会儿是token额度，光是维护这些适配代码就让人崩溃。更别提模型本身还会更新版本、调整价格、偶尔抽风宕机。今天这篇就是把我这半年折腾AI网关的经验彻底摊开来讲——它到底是什么、解决了哪些问题、哪些问题它其实管不了，以及从选型到落地的完整路径，适合正在把多个模型接进生产环境的开发者、技术负责人读。

1. 多模型时代，直接调API的日子是怎么失控的

1.1 你手上不知不觉多出来的那一堆Key

先说一个我自己身上的真实变化。2023年我做的应用只用一家模型，代码里就一个API Key，一个SDK，一份文档，调不通就看那一家文档，问题很清晰。到了2024年，需求变了，用户想要更聪明的推理，想要更快的响应，想要多模态图片理解，甚至部分场景想用本地私有化模型保证数据不出内网。

结果就是：同一个应用里，你得同时接OpenAI的GPT系列、Anthropic的Claude系列、Google的Gemini系列，可能还有国内厂商的模型和本地部署的开源模型。每个厂商给你一把Key，每个Key对应不同的计费口径、不同的速率限制、不同的上下文窗口。

我当时的代码长这样：

async function chat(messages, model) { if (model.startsWith('gpt')) { // OpenAI格式：messages, max_tokens, temperature... } else if (model.startsWith('claude')) { // Anthropic格式：直接把system拆成独立字段，max_tokens是必填... } else if (model.startsWith('gemini')) { // Google格式：contents[{role, parts}], generationConfig... } }

这种代码写起来很快，但后续每个模型厂商更新一次API，我就要跟着改一遍。更麻烦的是SDK版本冲突——同一个Node项目里装三个不同厂商的SDK，底层依赖偶尔打架，升级一个库得连带测试另外两个功能。这种痛苦不是技术难点，是纯纯的维护债。

1.2 各家模型API的"方言"问题

模型API之间的差异，比想象中大得多。普通人以为大家都是"输入文字输出文字"，无非换个地址换个Key。实际用起来，方言问题处处都是：

• 消息结构不同。OpenAI用messages数组统一搞定system和user，Anthropic把system独立成顶层参数，Google Gemini的contents里每个角色字段写法又不一样。
• 参数语义不同。同一个"随机性"控制，OpenAI叫temperature，某些模型叫temperature但支持的取值范围不同，另一些模型干脆只支持top_p，还有的模型同时有top_k。你要让上层应用切换模型，这些参数映射谁来做？
• 返回格式不同。有的返回JSON，有的返回纯文本；工具调用的返回结构各家也完全不同；流式输出的协议格式更是各写各的。
• 错误码含义不同。A厂商的rate_limit_exceeded，B厂商可能叫RESOURCE_EXHAUSTED，C厂商干脆返回429配一段HTML错误页。

这些"方言"问题是典型的中间层可以解决的：网关在上游统一接收一种协议格式，然后在下游为不同厂商做翻译适配。业务代码永远只面对一种请求格式、一种返回格式，模型换了一家，业务代码一行都不用改。

1.3 单一厂商依赖：出了故障就只能干等

还有一件让我坚定要上网关的事——2024年某次大模型服务大面积故障。那天我的应用台里一片飘红，用户端消息发不出去，客服工单炸了。我能做什么？除了等厂商恢复，什么都做不了。因为代码里所有调用都写死了那一个地址、那一把Key，根本没有备用通道。

如果有网关，情况完全不一样。网关层可以配置故障转移策略：主模型超时或者返回5xx的时候，自动把请求切换到备用模型。用户可能感知不到任何变化，顶多觉得响应慢了几百毫秒。这在生产环境是救命级别的能力。

2. AI网关站在中间到底做了什么：五个核心能力逐个拆解

2.1 统一接口层：把N种协议翻译成一种

网关最基础也最重要的能力，就是协议适配。它在业务应用面前伪装成一个标准的模型API服务——业务代码按照一套约定好的格式发请求，网关负责把这份请求翻译成OpenAI的格式发给GPT，翻译成Anthropic的格式发给Claude，翻译成Google的格式发给Gemini。

这个设计借鉴的是企业软件里非常成熟的API网关思想：后端可以有无数个服务，前端统一走一个入口。模型网关不过把"服务"替换成了"模型"。

实践中，很多开源网关直接把OpenAI的API协议当作标准协议，因为它事实上的生态最完善。你的业务代码可以用OpenAI SDK，只改一下baseURL指向网关，就能调通其他模型。这个技巧实测非常方便，基本零学习成本接入。

2.2 智能路由与故障转移：不是所有请求都要走最强模型

多模型时代出现了一个新问题：最强模型往往最贵、最慢，而你的应用里并不是每个请求都需要最强模型。

• 复杂推理/代码生成，走最强模型，质量优先；
• 简单问答/摘要，走中等模型，平衡成本和速度；
• 意图识别/分类，走小模型甚至本地模型，追求低延迟。

网关的路由能力就是做这个事——根据请求的特征（来源、用户、提示词长度、话题分类、自定义标签）分配合适的模型。这不仅是省钱的思路，也是提升用户体验的思路，因为小模型的响应速度肉眼可见地快。

故障转移也是路由的一部分。我在网关里配置了三种粒度的容错规则：

1. 网络层超时——连接超过建连超时时间，直接切换备胎模型；
2. 业务层错误——收到特定错误码，比如限流429、负载过高503，切换模型；
3. 内容层异常——返回为空、前后不一致、触发了拒答，交给下一逻辑。

要注意的是，故障转移不是越灵敏越好。设得太灵敏，上游厂商一秒钟的抖动就会触发大规模切换，反而造成更多不稳定；设得太迟钝，用户早就感知到卡顿了你才切换。我自己的经验是超时时间设在调用方容忍阈值的一半左右，并且切换动作要有次数限制，避免两个模型互相"甩锅"导致请求无限重试。

2.3 成本管控与用量观测：钱花在哪清清楚楚

直接拿各家模型官网的控制台看，你只能看到某一家的消耗。但你的应用同时用了三家，每一家还拆了不同项目、不同模型版本，月底算账的时候根本对不上。尤其当业务量上来之后，一个部门说"我调用了很多次"，另一个部门说"我传的token特别大"，没有一个统一账单，成本优化就无从谈起。

网关天然坐落在所有请求的必经之路上，所以它是做用量统计和成本核算的最佳位置。它能看到每一次请求的模型、token数、延迟、成功/失败状态，然后汇总成统一的观测面板。

我落地的时候重点看了几个指标：

这些数据还有一个额外用途：给老板汇报。之前我说"模型费用涨了"，老板问涨在哪，我答不上来。现在直接截图网关的用量面板，哪个模型涨了多少、哪个业务线贡献了大头，一目了然。

2.4 安全与合规：密钥、审计、内容策略

把密钥直接写在业务代码里，是很多早期项目不自知的隐患。前端代码里嵌Key，更是灾难——抓包就能拿走。网关把密钥统一收编到服务端，业务应用不需要接触任何模型厂商的密钥，它只需要跟网关之间维持一个内部凭据。这样即使应用被拖库、被调试注入，也不会泄露上游模型密钥。

审计日志是合规上很值钱的能力。哪些人/系统、在什么时间、调用了什么模型、传了哪些内容，网关全部记录下来。等以后出了数据泄露问题或者需要配合审计，直接按时间轴拉日志就行，不用去各家后台零散翻找。

除此之外还可以在网关层做内容策略的集中管控。比如某些业务场景不允许输出特定类型的内容，你可以在模型返回后做一道后置内容检查；某些情况下希望给最终回答套一层格式包装，也可以在这里统一做。

2.5 Prompt和模型配置的集中管理

最后一个很多人容易忽略但实际体验极好用的能力：Prompt模板和模型配置的集中管理。

没有网关的时候，Prompt可能散落在各个服务的代码里。今天产品经理说"把这个话术微调一下"，你得发版；明天想换一个模型看效果，你得改代码。有了网关，Prompt模板放到网关配置中心，业务调用时指定模板ID，网关自动填充变量后发给模型。改Prompt不用发版，改模型参数不用发版，甚至可以做A/B对比——同一份Prompt，百分之多少流量走模型A，百分之多少走模型B，效果数据看板上一目了然。

3. 网关不是银弹：边界、误区和场景判断

3.1 网关管不了的事

讲完了网关的能力，必须泼一盆冷水：它管不了所有事。

第一，它管不了模型本身的质量。模型答错了、幻觉了、逻辑崩了，网关不会帮你改答案。它只负责把请求送过去、把响应传回来，智能不智能是模型自己的事。

第二，它管不了网络链路的质量。如果你的应用和目标模型服务之间的国际链路本来就慢，网关只是不背这个锅，也不能变出更好的网络。它能在超时后帮你切换，但切换本身有代价，第一次请求的延迟该多高还是多高。

第三，它管不了业务层面的复杂编排。一个请求需要先检索知识库再拼上下文，或者需要多个模型协同推理，这种编排逻辑应该放在业务代码或独立的Agent框架里，而不是塞进网关。网关是给"单个模型调用"做寻址和调度，不是给你跑业务流程的。

我见过最离谱的用法，是想在网关里塞一套复杂的Agent规划逻辑，结果配置变得巨难维护，出问题都找不到是网关的问题还是业务的问题。这个边界一定要划清楚：网关做通用能力，业务做个性化逻辑。

3.2 什么时候真的不需要网关

也不是所有项目都需要网关，别被"中间层焦虑"带偏。

• 如果你只用一个模型厂商、只有一个Key、用户量不大、也不打算切换厂商——直接调API即可，加一层网关纯属过度设计。
• 如果你的团队只有你一个人写代码，一切配置都了然于心，换模型也就改几行——可以等痛苦出现了再上网关。
• 如果你的需求只是给前端加个AI聊天入口，根本碰不到生产级的要求——先跑通再说。

我的判断方式是：当你的模型调用出现以下任意两条时，就该考虑网关了——多个模型厂商、多个服务/团队调用模型、需要精细的成本核算、需要故障转移、需要集中管控Prompt与密钥。

3.3 部署位置：客户端直连还是网关中继

网关应该放在哪一层？有一种做法是让客户端直接连网关，网关再连模型。这样做的好处是客户端体验可控，坏处是网关直接暴露公网，安全要求更高，而且每次客户端发版都要跟着改。更稳妥的通用做法是：业务后端连网关，客户端只跟业务后端通信。网关作为内部基础设施，不暴露在公网，密钥、审计都在内网完成。

但有一个例外——如果你在做纯客户端应用，比如桌面工具或移动App，并且真的不想维护自己的后端，那么用托管形态的网关服务会合理一些，它自带鉴权和配额控制。但即便如此，我仍然建议至少有一层自己的后端做业务控制，"客户端直连模型网关"只适合Demo和低安全要求的场景。

4. 落地实践：从选型到跑通的完整路径

4.1 先想清楚要解决什么，再谈选型

做技术选型之前，先把你自己的需求列表写下来。我是按照下面这几个问题梳理的：

• 我目前用了几家模型？未来半年想不想再加？
• 我有没有成本核算的刚需？是不是被财务/老板追着问过？
• 我能不能接受依赖一家模型厂商？如果它挂了，业务就停摆吗？
• 我的密钥目前存在哪里？是否已经暴露过？
• 我的团队有多大的运维能力？能伺候多复杂的中间件？

这些问题回答完之后，选型方向基本就定了。如果你们团队后端能力很强，愿意折腾，开源网关自己部署最灵活；如果就想快速用起来，托管网关优先。

4.2 开源网关的选型参考

这个领域目前已经有不少成熟的开源网关项目，我按自己的使用体验做个对比，仅供参考：

我自己的项目最后选了LiteLLM作为主力，原因有三：一是它天然以OpenAI协议作为标准，业务代码改动最小；二是它的配置是纯YAML，版本管理方便；三是它同时也提供代理模式，可以作为一个独立服务部署在K8s里。团队里不是没有人劝我上更重的企业网关，但对我这种两三个人的后端小组来说，LiteLLM的复杂度刚好。

4.3 最小可用方案：用网关统一三家模型

这里给你一个可以直接抄作业的最简落地路径。假设你有一个Node.js后端，现在要统一接入OpenAI、Claude和Gemini。

第一步，部署网关。我用Docker起一个LiteLLM代理：

docker run -d \ --name litellm-proxy \ -p 4000:4000 \ -v $(pwd)/config.yaml:/app/config.yaml \ ghcr.io/berriai/litellm:main-latest \ --config /app/config.yaml

第二步，写网关配置。把三家模型的Key配进来，给每个模型起一个逻辑别名：

model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: sk-xxx - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: sk-ant-xxx - model_name: gemini-1.5-pro litellm_params: model: gemini/gemini-1.5-pro api_key: AIza-xxx router_settings: routing_strategy: usage-based-routing fallbacks: claude-3-5-sonnet: - gpt-4o

第三步，业务代码改用OpenAI SDK但指向网关。核心改动就一个baseURL：

import OpenAI from 'openai'; const client = new OpenAI({ apiKey: '你的网关内部Key', baseURL: 'http://网关地址:4000/v1', }); // 上层想换模型，只改模型名，其他代码不动 const resp = await client.chat.completions.create({ model: 'claude-3-5-sonnet', messages: [{ role: 'user', content: '帮我总结一下这份周报' }], });

第四步，设路由策略。我把简单摘要流量指向gemini，复杂推理指向claude，并把gpt-4o作为全局兜底。跑了一个星期之后，对比之前的账单，成本下降了大约四成——因为大量简单请求不再走最贵的模型了。

4.4 验证与上线

别一上来就切全量流量。我的顺序是先让网关和直连模式并行跑，拿测试流量做对比：

• 先验证单模型调用：同一个问题，直连和走网关的返回内容是否一致（模型相同的前提下应该一致）。
• 再验证流式输出：确认SSE流式返回格式没有被网关破坏。
• 接着验证工具调用：如果业务里有function calling，这个最容易出问题，必须逐个测。
• 最后验证错误码：故意用错误的Key、超限的请求，确认网关的报错对上层业务是友好的。

全部通过之后，把流量按10%灰度切过来，观察延迟、错误率、成本三个指标，稳定24小时后再放大比例。

5. 生产环境里的真实坑：路由、限流和成本失控的复盘

5.1 路由策略写得太粗导致体验劣化

我第一次配路由，就配了"所有请求平均分到三个模型"。结果用户很快就反馈：有的回答特别啰嗦，有的回答又过于简洁。因为我把不同任务混在一起了，有些请求明显需要强推理，被路由到了小模型，回答质量自然崩。

后来改成基于请求分类的路由——业务方在请求里带一个task_type字段，网关根据这个字段决定模型。比如带reasoning标签的走Claude，带summary标签的走Gemini，带chat标签的走GPT。分层清晰之后，质量问题基本消失。

这里提醒一句：路由规则别写得太死。模型能力和价格每季度都在变，半年后你觉得"这个模型最能打"的那个，可能已经被另一个替代。路由配置一定要做成可动态修改的，别编译进代码里。

5.2 限流和熔断参数拍脑袋就完蛋

网关的上游有速率限制，你内部还有各业务线的配额。我第一次设限流阈值，随便填了"每分钟1000次"，结果高峰时段业务方直接报错——我看后台被打爆的其实是某一个重度用户脚本在循环调用，正常业务也被连坐了。

正确的做法分两层：

• 第一层是上游厂商的速率限制，网关要正确读取错误码并做退避重试，而不是无脑重试加重对方压力；
• 第二层是内部业务配额，按业务线、按用户维度分别设限，之间互相隔离。

熔断参数也要谨慎。熔断的本质是"快速失败保护下游"，但如果阈值设得太低，一次小波动就会熔断，然后流量全部压到备胎，备胎也跟着熔断，造成雪崩。我现在的做法是：连续失败率达到30%且最小请求量超过20次，才触发熔断，熔断后30秒半开探测一次。这个参数不一定适合所有人，但方向是对的——把"最小请求量"卡住，避免小样本噪音触发误判。

5.3 成本失控：日志里有真相

还有一次，月底账单突然比上个月翻了三倍。我打开网关的用量数据一看，发现罪魁祸首是一个定时任务，它把一整本几十万字的文档每页单独调了一次模型摘要，而我的路由配置里这个任务走了最贵的模型。这个场景要是没有网关的日志，我可能要去各家后台分别拉数据慢慢对，还不一定对得出来。

从此我把"按业务线成本预算"设成了硬指标：网关里给每个业务线配月度上限，超过就告警，超过80%就通知。省钱这件事，得先看得见钱花在哪。

5.4 缓存带来的意外收益

最后聊一个偏门但很实用的点：模型网关可以做语义缓存。对于重复性很高的业务，比如客服场景里"如何退货""改地址"这类常见问题，如果每次都去找大模型要一遍回答，费用和延迟都是浪费。

我在网关层加了语义缓存：请求先做embedding，与历史问题做相似度匹配，命中就直接返回缓存答案。实测客服场景的缓存命中率能到30%左右，对应节省的成本非常可观。唯一的坑是缓存的内容要带时效性——比如促销规则变了，老答案就不能再用了，所以缓存TTL千万别设成永久。

这半年用下来，我的整体感受是：AI网关不是一个"加了就一定好"的组件，但在你同时面对多个模型、多个业务方、复杂的成本诉求时，它几乎是我能想到的最优解。它不解决模型的智商问题，它解决的是工程问题——让上层业务专心写逻辑，让模型厂商的差异收敛在一个可控的点上。如果你现在也正在被多模型维护、密钥管理、成本对账折磨，从一个小众的网关配置和10%灰度开始，会比想象中快得多。