Envoy AI Gateway v0.7.0：基于主机名的多租户路由及其对 AI 运营团队的影响

2026 年 6 月 6 日发布的 Envoy AI Gateway v0.7.0，跨越了一个对运营共享 AI 基础设施的团队而言至关重要的门槛：它引入了基于主机名的模型目录隔离，使单一网关无需创建多个独立实例，即可为不同租户提供不同的模型集合。这一设计决策，连同 Anthropic 到 Bedrock 的协议转译和早期配额感知路由功能，揭示了工程团队未来将日益需要落地的多租户 AI 路由模式。

发生了什么

Envoy AI Gateway v0.7.0 包含以下面向运营侧的重要变更：

• AIGatewayRoute 的主机名路由：为每条路由分配主机名后，/v1/models 端点将自动仅返回请求租户可见的模型。teamA.ai.example.com 看到其获批的模型集合，teamB.ai.example.com 看到另一套——均来自同一个网关。支持通配符主机名（*.ai.example.com），遵循 Gateway API 的主机名匹配规则。
• Anthropic /v1/messages → AWS Bedrock Converse 协议转译：使用 Anthropic Messages 协议的客户端无需切换 SDK 即可访问 Bedrock 托管的模型。转译覆盖文本、图像、工具调用、thinking block 及流式响应，包括 reasoning_content 字段和需要保留 CoT 内容的多轮工具调用序列。
• 配额感知后端限流（QuotaPolicy）：将 QuotaPolicy 附加到 AIServiceBackend 后，控制器会注入后端限流过滤器。这是配额感知路由的第一步——基于上游提供商配额的每后端请求限流，完整的跨后端配额感知调度将在未来版本中实现。
• MCP tools/list 授权过滤：MCP 路由现在对 tools/list 和 tools/call 应用相同的授权规则，未授权的调用方无法枚举工具名称——既防止了能力泄露，也避免了因 LLM 尝试调用无权执行的工具而产生的无效 token 消耗。
• Azure OpenAI Responses API：/v1/responses 端点现已支持路由到 Azure OpenAI 后端，无需客户端侧修改即可自动转译至 Azure 的 /openai/responses?api-version=... 路径。
• 音频和视频内容类型：聊天补全请求现可包含 audio_url 和 video_url 内容块，为 vLLM（配合 phi-4-mm 和 Qwen 3.5 模型）等兼容后端开放多模态音视频输入通道。

为何值得 AI 工程团队关注

主机名路由特性解决了一个真实的运营痛点：管理共享 AI 基础设施的团队此前面临非此即彼的选择——每个租户独立网关（运维开销高），或单一网关不做目录隔离（所有租户可见所有模型）。v0.7.0 提供了第三条路：单个 Gateway 资源、多个按主机名划分的 AIGatewayRoute，以及对每个租户的 /v1/models 自动作用域限定。

这对平台团队的影响是实质性的。租户模型治理此前在应用层执行——通过应用代码或独立策略层过滤允许调用的模型。基于主机名的路由将执行边界前移至网关本身。将新模型误加到错误路由的团队，会从 /v1/models 收到清晰的 404，而不是部署后才发现的运行时报错。

Anthropic 到 Bedrock 的转译之所以重要，是因为企业团队出于合规考量常常锁定 Bedrock 作为云服务提供商，同时更偏好 Anthropic Messages SDK 的开发者体验。此前，在这两套协议体系之间转换需要定制中间层代码。v0.7.0 将其作为网关原语开箱即用，完整覆盖 thinking block 和多轮推理序列——正是手写转译器通常失败的边缘场景。

路由/运营视角

v0.7.0 有三个设计模式值得作为任何 AI 网关层的设计原则加以提炼：

1. 模型目录作用域属于路由层，而非应用层。 基于主机名的 /v1/models 过滤将治理执行边界移近提供商侧。这与 Gemini API Key 限制在边缘层强制执行的逻辑如出一辙：网关侧的执行比应用层策略更为可靠。

2. 协议转译是路由原语。 v0.7.0 中的 Anthropic→Bedrock 转译加入了已有的 OpenAI→Bedrock 和 Anthropic→OpenAI 两条路径，构成转译矩阵。实际效果是：团队可以在一种客户端 SDK 上标准化，同时路由至异构后端，无需维护各后端专用 SDK。这降低了添加或更换提供商的成本——一个关键的路由可靠性属性。

3. 配额感知是路由策略的下一个前沿。 v0.7.0 中 QuotaPolicy 后端限流注入被明确标记为第一步。完整的配额感知路由——根据剩余提供商配额动态选择后端——需要在请求时感知每个提供商的剩余预算。在 Envoy AI Gateway 上构建业务的运营商现在就应着手设计 QuotaPolicy CRD，而不是等到上游提供商配额开始限流生产流量时再补救。

对于 MCP 部署：授权过滤的 tools/list 是一个有意义的安全边界。向未授权调用方暴露完整工具目录存在信息泄露风险——调用方可以枚举工具名称，并围绕已知工具签名设计提示词注入攻击，即便从未成功调用过任何工具。v0.7.0 的修复直接有效，但在自托管 MCP 部署中容易被忽视。

TheRouter 用户应该关注什么

Envoy AI Gateway v0.7.0 中的模式与 TheRouter 的提供商路由和治理层所应对的核心问题高度吻合：哪些模型对哪些团队可见、如何处理提供商协议异构性，以及如何管理每个后端的配额预算。

评估 AI 路由基础设施的团队应将 v0.7.0 的发布作为一个检查节点，审视自身的模型目录暴露状况：当前路由层是否控制了不同租户或服务账号可以发现哪些模型，还是仅控制了他们可以成功调用哪些模型？这是两个不同的控制维度，对应不同的故障模式。

审阅 /docs/ 中的路由配置，确认当前提供商设置是否已具备每租户模型作用域隔离能力。