01 - 网关是什么：从五行代码长出来的东西
不需要任何前置知识。你只要写过一次"调用大模型 API"的代码就够了。
读完这篇，你会知道：AI 网关解决什么问题、它由哪六件事组成、本专题后面那些术语分别指什么。
讲 AI 网关，最糟糕的开场是"AI 网关是一个统一的 LLM 流量入口，提供路由、限流、可观测能力"。这句话每个字你都认识，但它什么也没告诉你。
所以我们换一种方式：从一段能跑的代码开始，一个需求一个需求地加，看它怎么一步步长成一个网关。
一、第 0 天：五行代码
from openai import OpenAI
client = OpenAI(api_key="sk-xxx")
resp = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "你好"}],
)
print(resp.choices[0].message.content)
跑通了。这时候你不需要网关。任何在这个阶段引入网关的行为都是过度设计。
二、第 30 天：老板说要接 Claude
理由可能是成本，可能是某个任务 Claude 效果更好，也可能只是不想被一家绑死。
问题来了：Anthropic 的接口和 OpenAI 的不一样。 不只是 URL 和密钥不同，请求体的结构就不同 —— OpenAI 把 system 提示放在 messages 数组里，Anthropic 把它放在顶层的 system 字段；返回体的结构也不同。
于是你的代码变成这样：
def chat(provider, messages):
if provider == "openai":
resp = openai_client.chat.completions.create(
model="gpt-4o", messages=messages)
return resp.choices[0].message.content
elif provider == "anthropic":
system = next((m["content"] for m in messages if m["role"] == "system"), None)
rest = [m for m in messages if m["role"] != "system"]
resp = anthropic_client.messages.create(
model="claude-sonnet-4-5", system=system,
messages=rest, max_tokens=4096)
return resp.content[0].text
你刚刚写下了网关的第一个能力：协议转换（protocol translation）。
📖 术语：provider（供应商） 提供模型 API 的一方，比如 OpenAI、Anthropic、AWS Bedrock、阿里云百炼。同一个模型可能有多个 provider —— 比如 Claude 既能从 Anthropic 官方调，也能从 AWS Bedrock 调，两者接口不同、价格不同、限额不同。
三、第 45 天：线上 503 了
某天下午 OpenAI 抖了一下，你的服务跟着挂了 十分钟。
老板：为什么不自动切到 Claude？
def chat(messages):
try:
return call_openai(messages)
except Exception:
log.warning("openai failed, falling back to anthropic")
return call_anthropic(messages)
第二个能力：故障转移（fallback）。
但很快你会发现这个实现太粗糙：
- OpenAI 挂了 10 分钟，这 10 分钟里每个请求都要先失败一次、等超时、再重试 —— 用户感受到的延迟翻倍
- 更好的做法是"记住它挂了，接下来一段时间直接不发给它"，这叫熔断（circuit breaking）；过一会儿再试探性地发一个请求看恢复没有，这叫健康检查（health check）
📖 术语：fallback / 熔断 / 冷却 fallback 是"这次失败了换一个"；熔断是"连续失败达到阈值后，直接停止往这里发请求"；冷却（cooldown） 是熔断后等待多久再试。 本专题 03 - 路由与容错 会看到 Higress 是怎么把这三件事实现在真实代码里的。
四、第 60 天：一个 API Key 不够用了
流量上来了，OpenAI 开始返回 429 Too Many Requests。
你去看文档，发现每个 API Key 有两个限额：
📖 术语：RPM / TPM
- RPM（Requests Per Minute）：每分钟最多发多少个请求
- TPM（Tokens Per Minute）：每分钟最多消耗多少 token（输入 + 输出一起算）
这两个限额是 provider 给你设的硬上限，超了就直接拒绝。绝大多数生产事故是 TPM 打满，因为一个长文档请求就能吃掉几万 token。
于是你申请了 5 个 API Key 轮着用：
keys = ["sk-a", "sk-b", "sk-c", "sk-d", "sk-e"]
i = 0
def next_key():
global i
i = (i + 1) % len(keys)
return keys[i]
轮询（round-robin）能用，但很快就不够了：
- 某个 key 被封了，还在往里发请求
- 5 个 key 的额度不一样，平均分配会让小额度的先满
- 有些请求要 3 万 token，有些只要 200，按请求数轮询会让 TPM 分布极度不均
这时你需要的是：按"哪个后端当下最空"来选，而不是轮着来。
📖 术语：deployment（部署） 这是本专题最重要的一个词。一个 deployment = 一个具体的、可调用的模型端点，由「provider ＋ 模型名 ＋ 密钥 ＋ 地域」共同确定。
举例：下面是同一个模型名
gpt-4o底下挂的四个 deployment：
deployment provider 密钥 地域 TPM A OpenAI 官方 sk-a — 300K B OpenAI 官方 sk-b — 150K C Azure OpenAI key-1 东部 200K D Azure OpenAI key-2 西部 200K 业务代码只说"我要
gpt-4o"，从这四个里挑一个就是网关的工作。这个动作叫路由（routing）。
第三个能力：路由。
五、第 90 天：财务来问账
"上个月模型花了 12 万，哪个团队花的？"
你打开 OpenAI 后台，只有一张总账单。业务代码里所有团队共用同一个 key，分不出来。
正确的做法是：给每个团队发一把不同的密钥，但这些密钥不是 provider 的真密钥，而是你自己发的：
研究团队 → litellm-key-research-xxx → 网关 → 真实 sk-xxx
客服团队 → litellm-key-support-yyy → 网关 → 真实 sk-xxx
📖 术语：虚拟密钥（virtual key) 网关自己签发的、给业务方使用的密钥。它的价值在于：
- 真实的 provider 密钥只存在于网关里，业务方拿不到，泄露了也只影响一个团队
- 每把虚拟密钥可以绑定自己的配额（quota）、预算（budget）、可用模型范围
- 用完了直接吊销，不用动 provider 的密钥
04 - 多租户与配额 会拆 LiteLLM 是怎么实现这套东西的。
第四个能力：多租户与计费归属。
六、第 120 天：合规和安全找上门
- 用户可能把身份证号粘进对话框 → 要在发给外部模型之前脱敏
- 模型可能输出不该输出的内容 → 要在返回给用户之前过滤
- 出了问题要能查：谁、什么时候、调了什么模型、花了多少钱 → 要有审计日志
第五个能力：内容安全与可观测。
📖 术语：guardrail（护栏） 在请求进入模型前、或响应返回用户前插入的检查逻辑。典型的有：敏感词过滤、PII（个人身份信息）脱敏、提示注入检测。 云厂商通常把这一层做成独立产品（阿里云内容安全、AWS Bedrock Guardrails），网关负责把它挂进流量链路。
七、第 150 天：Agent 来了
业务开始做 Agent，需要连一堆外部工具 —— GitHub、内部数据库、公司 API。这些工具通过 MCP 协议接入。
📖 术语：MCP（Model Context Protocol） Anthropic 2024 年底提出、现已成为事实标准的协议，用来让 AI 应用连接外部工具和数据源。一个提供工具的服务叫 MCP Server，使用工具的一方叫 MCP Client。
于是出现了一批全新的问题：
- Agent 要连 5 个 MCP Server，难道要在 Agent 代码里配 5 个地址和 5 套凭证？
- 两个 MCP Server 都有个叫
search的工具，怎么区分？ - 哪些工具允许哪个团队调用？
delete_file这个工具，允许调，但只允许在/tmp下 —— 这条规则写在哪？
第六个能力：MCP 代理与工具级授权。 这是"LLM 网关"和"Agent 网关"的分界线，05 - MCP 网关 专门讲这个。
八、你已经写了一个网关
回头看这六件事：
这就是 AI 网关。 它不是一个突然被发明出来的组件，而是每个把大模型用到一定规模的团队必然会重新造一遍的东西。
现成的方案（LiteLLM、Higress、云厂商的托管产品）的价值在于：上面六件事里的每一件，它们都已经踩过一遍坑了。本专题接下来要做的，就是把这些坑一个个翻出来给你看。
九、什么时候不需要网关
同样重要 —— 下面这些情况，引入网关是净亏损：
| 情况 | 为什么不需要 |
|---|---|
| 只用一个 provider、一个模型 | 六件事一件都不成立 |
| 单人项目 / 内部工具 | 多租户和计费归属没有意义 |
| 延迟极度敏感且请求量小 | 多一跳网络不划算 |
| 团队没人能维护它 | 网关挂了 = 全站 AI 功能挂了，这个单点你得养得起 |
判断标准很简单：上面六件事，你现在真实需要几件？少于三件就先别上。
十、这个专题怎么读
| 你的情况 | 建议路径 |
|---|---|
| 想搞懂网关是怎么实现的 | 按顺序读 02 → 03 → 04 → 05 |
| 要选一个云厂商的托管产品 | 直接跳 06 和 07 |
| 已经在用，想调优 | 03 - 路由与容错 ＋ 08 - 性能与形态代价 |
| 主要做 Agent | 05 - MCP 网关 是重点 |
下一篇 → 02 - 四种形态：网关该做成一个库、一个独立进程、一个 Envoy 扩展，还是一个 Wasm 插件？