Agent Router：把模型凭证与配额收进 Envoy 的 AI 网关控制面

它解决的是凭证与配额散落在应用代码里的问题

多模型应用最麻烦的部分通常不是调用本身，而是调用之外的账。每个供应商一套密钥，每个团队各自读取环境变量，限流在应用里硬编码，某个供应商超时后没有统一的重试与切换点，月底想知道哪个业务线烧了多少 token 只能翻日志。Agent Router 把这一层抽出来，README 的定位是给应用团队一个统一的、OpenAI 兼容的 API，覆盖托管供应商、自建推理和 MCP 服务器；平台团队则把凭证、路由、配额、故障转移和用量归属集中在一处，由 Envoy 与 Envoy Gateway 执行。它的口号写得很直白：Agent Router controls, Envoy carries。控制面负责决策，数据面交给已经在大规模生产里跑过的 Envoy。目标读者是有平台工程能力的组织，而不是单个开发者。

控制面与数据面的分工，以及双层网关的取舍

从仓库材料能确认的机制是：Agent Router 以 Kubernetes CRD 的形式描述路由与后端，再由 Envoy Gateway 把这些声明翻译成 Envoy 配置并承载实际流量。README 点名的资源有 AIGatewayRoute、AIServiceBackend、BackendSecurityPolicy，API group 是 aigateway.envoyproxy.io。也就是说，模型后端的地址、认证方式、路由匹配规则都是集群里的对象，改配置走的是 kubectl apply 而不是改应用代码。

README 还描述了一个双层网关模式。Tier One Gateway 是集中入口，负责认证、顶层路由和全局限流；Tier Two Gateway 处理进入自建模型服务集群的流量，提供更细粒度的访问控制，并支持 endpoint picker 来做 LLM 推理优化。这个划分不是装饰：把全局策略和推理集群的就近调度分开，意味着两层可以独立扩缩容，也意味着一次请求要穿过两个 Envoy 实例，链路更长、排障面更大。单集群、单供应商的场景用一层就够，硬套两层只会增加延迟与运维成本。

用 aigw run 在本机起一个兼容端点

README 给出的最短路径是一条命令：OPENAI_API_KEY=sk-your-key aigw run，然后把任意 OpenAI 兼容客户端指向 http://localhost:1975/v1。CLI 名称仍是 aigw，文档里另有 CLI 指南说明安装与供应商自动配置。这条路径不依赖 Kubernetes，适合先验证客户端兼容性再决定是否上集群。

集群部署走 Getting Started 指南，配合 Envoy Gateway。README 没有在正文里展开 Helm 命令与 values 键名，所以具体 chart 名、命名空间之外的参数需要查文档；能确认的是命名空间仍是 envoy-ai-gateway-system，容器镜像仍是 docker.io/envoyproxy/ai-gateway-*。支持的供应商在 README 里以图标表格列出，包括 OpenAI、Azure OpenAI、Google Gemini、Vertex AI、AWS Bedrock、Mistral、Cohere、Groq、Together AI、DeepInfra、DeepSeek、Hunyuan、SambaNova、Grok、Anthropic，以及 Tetrate Agent Router Service。表格只说明支持范围，没有给出各家的功能差异，选型时仍要逐家核对认证方式与流式行为。

重命名之后，哪些东西没有跟着改

Envoy AI Gateway 改名 Agent Router，归入 Agentic AI Foundation，README 明确写了同一份代码、同一批维护者、同样的发布节奏和 Apache 2.0 许可。对已经部署的人来说，关键在于什么没变：CRD 与 API group 不变，CLI 仍是 aigw，命名空间 envoy-ai-gateway-system 不变，容器镜像、Helm chart 和 Go module 路径也不变（docker.io/envoyproxy/ai-gateway-*、github.com/envoyproxy/ai-gateway）。变的是仓库地址迁到 theagentrouter/agent-router，旧链接重定向；站点迁到 theagentrouter.ai，aigateway.envoyproxy.io 的链接逐页重定向。

这种改法对运维友好，但也带来一个容易踩的坑：镜像名、模块路径、API group 都还带着旧名字，搜索引擎和内部文档里两套称呼会长期并存。做依赖审计或写内部规范时，如果只按 agent-router 这个字符串去搜，会漏掉所有实际生效的标识符。

它不是进程内库，也不适合没有集群的场景

最明显的边界是形态。Agent Router 是控制面加数据面，不是可以 import 进应用的 SDK。如果你的部署单元是一个单体服务、没有 Kubernetes，引入它意味着先引入 Envoy Gateway 和一整套 CRD 生命周期管理。这对小团队是净负担。

其次是排障路径。请求经过 Envoy 之后，应用侧看到的错误是网关返回的，模型供应商返回的原始状态码、限流头和重试语义会被中间层改写。README 没有描述错误透传策略或调试接口，所以这部分需要自己在环境里验证。第三是双层模式的成本，前面已经提到，多一跳就多一个故障点和一份容量规划。最后，README 只列出支持的供应商，没有给出各供应商在流式、工具调用、嵌入等能力上的对齐程度。宣称 OpenAI 兼容不等于所有端点都兼容，这一点必须用真实请求打一遍。

与 LiteLLM 这类进程内路由的路径差异

常见的替代方案是 LiteLLM 这类 Python 侧的模型路由库：它在应用进程内把不同供应商的请求翻译成统一格式，部署简单，一个 pip install 就能跑，改动集中在应用代码里。代价是凭证和路由策略随应用走，多语言栈要各自实现一遍，限流和用量统计也分散在各个服务中。

Agent Router 把同一件事放在基础设施层：策略是集群对象，凭证由 BackendSecurityPolicy 一类的资源管理，所有语言的应用只要会说 OpenAI 协议就能接入。区别不在功能清单，而在控制点位置。已经重度使用 Envoy Gateway 的团队迁移成本低，因为多出来的只是几个 CRD 和一条路由；反过来，没有任何 Envoy 经验的团队要先补上 Envoy 的概念模型，这部分学习成本不能忽略。

版本与许可：升级时要盯住什么

仓库的发布记录显示 v1.0.0 与 v1.0.0-rc1 同在 2026 年 6 月 23 日，v1.1.0 在 2026 年 8 月 21 日，最近一次推送在 2026 年 9 月 10 日。README 声称改名后发布节奏不变，但 1.x 系列目前只有两个正式版本，跨版本升级的兼容性承诺还需要从 release notes 里逐条确认，尤其是 CRD schema 的字段变更。

许可为 Apache-2.0，允许商用与修改，附带专利授权条款，通常要求保留版权与许可声明、标注修改过的文件。具体到你的分发方式是否触发额外义务，需要法务判断，这里不做法律意见。可以确定的是，改名没有改变许可，也没有改变你在自己集群里部署这些组件的权利。

编辑结论

已经在跑 Envoy Gateway、并且有平台团队愿意维护 Kubernetes CRD 的组织，适合评估 Agent Router：凭证、路由、限流、故障转移和用量归属都落在同一套声明式资源里，不必在应用侧散落供应商 SDK。只想要一个进程内 SDK、或者没有 Kubernetes 运维能力的小团队不适合，直接调用供应商 API 或使用进程内路由库更省事。上手前先核对三件事：镜像与 Helm chart 是否仍指向 docker.io/envoyproxy/ai-gateway-*，CRD 的 API group 是否仍是 aigateway.envoyproxy.io，以及 aigw run 默认监听的 1975 端口在你的环境里是否可用。这三项确认之后再决定是否把生产流量切过去。

官方来源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. theagentrouter/agent-router on GitHub