「AI 网关」这个词现在被用得很宽。有人说的是 OneAPI 那种统一模型接入，有人说的是 Higress 加了 AI 插件，有人说的是能管 MCP 工具的东西，还有人指的是一整套 Agent 平台。指代不清就没法讨论选型，所以先把它拆开。
一、AI 网关不是一个组件，是一组能力
按职责划，目前落地的 AI 网关大致包含四类能力，从下往上：
模型接入层。统一多家模型 API，做路由、负载均衡、限流熔断、key 管理、用量与成本归集。这是最成熟的一层，OneAPI、NewAPI、LiteLLM、Bifrost 都在这个位置。
工具接入层。管理外部能力的注册、发现、鉴权和调用转发。包括 MCP server、内部 HTTP/RPC API、搜索、数据库、浏览器。
编排层。任务拆解、多步执行、状态与记忆、工具选择、多 Agent 协同。这层争议最大，下面单独说。
治理与观测层。鉴权、配额、审计 trace、token 成本统计、内容安全与脱敏、缓存。这一层横切其他三层，不是串在链路里的一站。
除此之外还有两个常被单独拎出来命名的东西，其实是上面某层的切面：
- 多模态网关。按输入输出形态抽象，管图片、音频、视频、文档的接入、预处理、编解码和模态路由。它和模型网关是两个维度的切法，模型网关管「接哪个模型」，多模态网关管「接哪种内容」。一张图进来先由它决定走图像理解还是 OCR，再由模型网关路由到具体的 GPT-4o 或 Qwen-VL。
- Prompt 网关。管模板、版本、灰度和实验。规模小的时候它就是个配置中心，不值得单独立一层。
二、模型网关和工具网关的分界
这两层的差别不在协议，在副作用。
模型调用基本是幂等的，同一个 prompt 打两次，最坏是多花一次钱。所以模型网关可以放心做重试、做旁路缓存、做多实例负载均衡，这些都是纯网络层的活。
工具调用不是。「创建工单」「合并 PR」「删除记录」重试两次就是两条工单。
所以工具接入层必须多出几件模型网关不需要的事：
- 幂等键。调用要带业务唯一键，网关侧或工具侧去重。
- 细粒度权限。不是「这个 key 能不能调工具」，而是「这个 Agent 在哪个环境能调哪个工具的哪个操作」。
- 调用前审批。高危操作要能卡住等人确认，而不是直接透传。
- 完整审计。参数、返回、时间戳、发起方，全都要能回放。
这也解释了为什么 Function Call 和「工具调用」不该混着说。Function Call 是模型侧的输出格式，模型不说人话，改成输出一个函数名加参数。而工具调用是能力体系，Function Call 只是它的一种表达形式，MCP tool、HTTP API、搜索、DB query 都在里面。网关要治理的是后者，不是前者。
三、Envoy、Kong、Higress 处在什么位置
它们是流量与治理底座，不是 AI 网关的全部，更不自带编排能力。
它们提供的是四层七层转发、路由、鉴权、限流、熔断、可观测和插件扩展点。往上补 AI 能力的路径也很清楚，Envoy 靠 filter / ext_authz / WASM，Kong 靠 plugin，Higress 直接内置了 AI 插件集。
所以第一层和第四层它们能覆盖大半，第二层能靠插件做到「转发和鉴权」这个程度。第三层基本不在它们的射程内。
四、Agent 网关该合还是该分
这是唯一真正需要判断的问题。我的结论是分层，局部集成。
先说为什么不该合。编排层要管的东西和网关的设计假设是冲突的：
- 状态。网关追求无状态以便水平扩展，编排天生有状态，当前执行到哪一步、上下文是什么、失败过几次。把状态塞进网关，要么绑定实例内存丢掉扩展性，要么外置存储，那时它已经不是网关了。
- 迭代节奏。Agent 逻辑一周改三遍，网关追求稳定可靠、能连续跑几个月不动。放一起就是拿网关的可靠性去赔 Agent 的迭代速度。
- 业务耦合度。模型路由和限流是通用的，换个业务照样能用。任务怎么拆、什么时候要人审批、失败怎么回退，全是业务特有的。通用组件里塞业务逻辑，最后就是一堆 if。
- 长时执行。一次 Agent 任务可能跑几十分钟，中间等审批、等流水线。网关的请求生命周期是秒级到分钟级，模型不匹配。
按请求流向看，重的 Agent 逻辑应该在 AI 网关前面，也就是更靠业务那一侧：
1 | |
分工是，编排服务负责「怎么想、怎么拆、怎么调度」，AI 网关负责「怎么安全、统一、稳定地把调用发出去」。
再说什么情况下该合一部分。有几件事放在网关里明显更合适，因为它们本质是治理而非编排：
- 工具注册表与权限矩阵。这是典型的配置与鉴权，天生属于网关。
- 会话级的成本与配额控制。一次 Agent 任务烧掉多少 token 要能在网关侧封顶。
- 跨 Agent 的统一 trace id。链路追踪必须在入口统一分配，事后拼不出来。
- 工具调用的审批门。策略在网关，决策交给上层，网关只负责卡住。
也就是说，治理下沉到网关，编排留在上层。这条线画得清楚，两边都能各自演进。
五、现成的选择
按上面四层对一遍市面上的东西，会发现没有哪一个是完整的 AI 网关，都是拼出来的：
- 模型接入。
OneAPI、NewAPI、LiteLLM、Bifrost。这层选型最成熟，直接用。 - 流量底座。
Envoy、Kong、Higress。有多租户和企业级流量治理需求时才需要。 - 编排引擎。
LangGraph偏状态机与可恢复执行，AutoGen和CrewAI偏多 Agent 协作，Semantic Kernel偏企业工程栈嵌入。它们都是库，不带界面，也完全不管鉴权配额，只能作为编排层的内核。 - 完整平台。
Multica这类把 Agent 当团队成员的协作工作台，已经带了 runtime 接入、角色权限、执行日志、成本统计和 review gate，是离「Agent 网关」最近的现成品。Dify、Langflow这类偏应用搭建，编排能力有但治理偏弱。
需要注意 Codex、Claude Code、Cursor 这类不在上面任何一层，它们是被网关管理的执行体，不是网关。同理，LangChain 是组件库，Function Call 是协议格式，都不该出现在架构分层图里当一层。
六、给不同规模的建议
个人和小团队。只上模型网关。OneAPI 或 LiteLLM 解决 key 管理和成本可见，编排用现成的 Agent CLI 加脚本。这个阶段建 Agent 网关是纯负担，多租户、配额、权限矩阵一个都用不上。
多人共用、开始要审计。补治理层。重点是统一 trace、按人按项目的成本归集、工具调用的权限矩阵和审批门。这时候可以考虑直接用 Multica 这类平台，比自建快。
要把流程变成系统。这时才需要正式的编排层。判断标准不是「有没有多步任务」，而是「某个环节失败了重来的代价大不大」。发版、提测、流水线轮询这类跑到一半崩掉就要重头来的环节，值得用 LangGraph 之类带 checkpoint 的引擎写成程序。而「这段代码怎么改」这种探索性工作，硬塞进状态机只会更麻烦。
结论
AI 网关 是总入口，模型网关 和 工具网关 是其中最实在的两层，多模态网关 和 Prompt 网关 是切面而非独立层级。
Agent 网关 该分开建，但要把治理能力（工具注册、权限、配额、trace、审批门）下沉进网关，把编排能力（拆解、计划、状态、记忆）留在业务侧。合在一起短期看着省事，代价是用网关的稳定性去换 Agent 的迭代速度，而这两样恰好都是你最需要的东西。