88:AAIF开源项目Agent Router研究实践-模型流量谁来管？

01、现场：切一个模型，翻出三笔糊涂账

业务方临时要求把某个功能切到另一家模型。改动量看起来只有一行模型名。

真正卡住的是三个问题：Key 在谁手里，账单记在哪个成本中心，限流阈值配在哪。

如果这些答案散落在各业务仓库的 SDK 初始化代码里，切模型就变成一次跨团队考古。

我判断这类问题的根因不是模型不够多，而是流量治理没有独立层。

Agent Router 值得研究的地方，正是它把这一层做成了独立网关。

---

02、拆题：网关该管什么，不该管什么

按官方仓库说明，Agent Router 是面向 AI 与 Agent 流量的开源控制面，由 Envoy 承载。

它前身是 Envoy AI Gateway，代码、维护者、CRD 与 API 组保持不变，CLI 仍是 aigw。

项目定位是给应用团队一个统一的 OpenAI 兼容入口，覆盖托管模型、自托管推理和 MCP Server。

平台团队则把凭证、路由、配额、故障切换和用量归因收拢到一处。

边界同样清楚：它不是 Planner、Agent Runtime，也不是业务工作流引擎。

网关认证不等于业务授权，租户与数据行级权限仍要由身份系统和业务服务校验。

Token 限流控制的是消耗，不代表允许执行某项业务操作。

---

03、原理：控制面配置，数据面转发

控制面由 Kubernetes API Server 接收声明式资源。

AI Gateway Controller 处理 AI 专属资源并配置 External Processor。

Envoy Gateway Controller 负责代理资源编排，通过 xDS 下发配置。

控制面只负责配置，不在每个业务请求里参与模型推理。

数据面里 Envoy Proxy 负责接入与转发，ExtProc 承担 AI 专属请求处理。

Rate Limit Service 依据 Token 用量执行预算限制，三者职责不能混为一谈。

---

04、取舍：与 agentgateway 比职责，不比高低

两者都处在 AI 流量入口这一层，但职责侧重不同。

Agent Router 依托 Envoy 与 Envoy Gateway 生态，控制面走 Kubernetes 声明式资源。

它的强项是把路由、凭证、限流和用量归因放进同一套 CRD 与 xDS 链路。

代价是需要理解 Gateway、Provider、BackendSecurityPolicy 等资源之间的关系。

如果团队已有成熟的 Envoy 运维体系，这条路径的复用价值更高。

如果只需要一个轻量本地代理做开发验证，完整控制面反而是负担。

选择依据应是现有基础设施与治理诉求，而不是功能清单的长短。

---

05、架构：一条请求经过谁

同一条请求可以拆成五段：选模型、认 Provider、转格式、计 Token、必要时重试。

ExtProc 可依据路径、请求头和模型名完成路由选择与模型校验。

它处理 Provider 凭证与请求头，适配 OpenAI、AWS Bedrock 等不同 API 格式。

响应侧由它做归一化，让上游应用看到统一的 OpenAI 兼容形态。

流式与非流式响应中的 Token 用量也由它跟踪，计量结果交给限流决策。

---

06、实战：本地 PoC 与生产部署两条路

本地验证在 Linux 或 macOS 上设置 OPENAI_API_KEY 后运行 aigw run。

默认 OpenAI 兼容服务地址是 localhost:1975/v1，可用 OpenAI SDK 或 curl 验证。

同一命令也可代理 Ollama、vLLM 和 MCP Server，适合先跑通配置再谈上线。

官方 CLI 当前标注支持 Linux 与 macOS，Windows 场景建议用 WSL2 做 PoC。

Kubernetes 路径先安装 AI Gateway CRD，再部署 AI Gateway 与 Envoy Gateway 控制器。

随后配置 Gateway、Provider 和凭证，让请求真正走通数据面。

---

07、复盘：重试不是免费的容灾

Envoy 的重试与回退可能把请求转到另一个 Provider。

但不同 Provider 的认证方式和请求格式可能不同。

ExtProc 需要在上游处理阶段重新完成对应转换与授权，否则重试会直接失败。

是否发生切换取决于路由、重试和后端策略配置，不能写成无需配置的自动容灾。

生产验收我建议逐项过：控制器高可用、xDS 更新是否平滑、密钥如何管理。

还要验收限流预算是否按租户生效、观测指标是否覆盖 Token 与错误码。

升级与回滚路径必须演练，本地单机 CLI 只用于验证配置，不代表生产 HA。

---

08、洞见：治理层才是商业化的落点

多租户数字员工场景里，每个租户的模型配额和账单需要独立归因。

全球 AI 客服的成本中心，要求按部门而不是按进程统计 Token 消耗。

BYOK 意味着客户自带 Key，网关要能隔离凭证而不泄露给业务代码。

部门配额、故障切换和审计留痕，都是同一层治理能力的不同切面。

我的判断是：模型会继续增多，把治理逻辑写进业务代码的代价只会更高。

但也要承认，网关解决的是流量问题，业务决策仍应留在 Agent 与业务服务里。

---

09、小结

Agent Router 的价值不在于多接了几家模型，而在于把路由、凭证、预算和归因抽成一层。

控制面负责声明式配置，数据面由 Envoy、ExtProc 和 Rate Limit Service 分工执行。

重试与故障切换需要显式配置，Token 限流也不等于业务授权。

先本地跑通 aigw run，再按验收清单上 Kubernetes，是更稳妥的路径。

延伸阅读可查 Agent Router 官方文档的 Concepts 与 Architecture 章节，以及 Data Plane 一节。

安装与 CLI 部分对应 Getting Started 和 aigw run 两篇官方指南。

项目仓库 README 说明了更名背景与 CRD 兼容性，适合核对版本差异。