路由层是机制，不是供应商选择

Honest Architect 对 LLM API Gateway Guide: Choose the Right One (2025) 的一次解读，作者 Ofox，2026年3月20日 发表于 ofox.ai。

文章的表层主张是一份购买指南：根据团队规模和优先级，在六个 LLM API 网关（OpenRouter、LiteLLM、Portkey、Ofox、Helicone、Kong AI Gateway）中选一个。Honest Architect 读它比较之下的机制，找到六个。承重的一个是路由层本身：一个网关坐在你的应用与 LLM 供应商之间，给你一个统一接口、自动故障转移与集中化成本控制。Everythink 的 HAI Engine 里的 Theorem 3 主张相同的形式：一个属性恰在其机制已实现并在测量时才被保证。这里属性是「供应商宕机时你的应用继续工作」；机制是「路由层在应用看到错误之前故障转移到另一个供应商」。

在进入机制之前先给一个范围说明：源是一家网关厂商的商业 AI 基础设施购买指南，自然偏向网关模式。下面六个机制形式是 ✅ — 可从文章自身证据中提取。与 Everythink 的跨域平行是 ⚠️ — 结构性的，不是声称我们的民用与防御性预测平台跑在一个多供应商 LLM 网关上。Everythink 的 LLM 供应商配置只兼容 OpenAI（一个协议作为端口，任何兼容供应商作为适配器）— 同一架构形式，范围更窄。

作为 Everythink 产品的商业多供应商 LLM 网关是 🔵 Roadmap — 未营收，不属于当前的民用与防御性平台。

机制 1 — 统一 API 是端口稳定性的机制

文章说网关给你「One interface format for all providers — call GPT, Claude, and Gemini with the same code.」Honest Architect 把这读成一条端口稳定性的主张：你的应用在换供应商后仍存活，由统一接口已实现来保证，不由你的应用认识每个供应商的 SDK 来保证。产生「换模型是改配置，不是改代码」的机制是「网关暴露一个接口并在背后翻译」。统一 API 是机制；供应商的原生 SDK 不是。✅ 生产 — 文章命名了机制（统一 API，所有供应商一个接口）和属性（换模型是一行改动）。

文章诚实地说统一接口的代价：「It's not an abstraction that hides model differences (you still choose which model to call).」端口稳定；背后的选择仍是你的。

与 Everythink 的六边形 trait 端口的跨域平行只是结构性的。Everythink 的 AppState 仓储是 Arc<dyn Trait>，测试可换入 mock — 应用依赖 trait，不依赖具体的 Pg* 适配器。文章的「你的代码依赖网关的一个接口，不依赖三个供应商 SDK」和 Everythink 的「你的 use-case 依赖端口 trait，不依赖具体适配器」共享同一形式：一个稳定端口是可互换性的机制。⚠️ 部分 — 不同领域，同一形式：一个稳定端口是可互换性的机制。

机制 2 — 自动故障转移是可用性的机制

文章说「If Provider A is down, transparently retry with Provider B」以及「If GPT-5.2 is unavailable or rate-limited, the gateway automatically routes to Claude — your app never sees an error.」Honest Architect 把这读成一条可用性主张：运行时间由故障转移已实现并在路由来保证，不由单一供应商可靠来保证。产生「你的应用永远看不到错误」的机制是「网关在浮现失败之前用供应商 B 重试」。自动故障转移是机制；单一可靠供应商不是。✅ 生产 — 文章命名了机制（自动故障转移，透明重试）和属性（应用永远看不到供应商错误）。

文章诚实地承认这不是假设：「In 2025 alone, every major LLM provider experienced at least one significant service disruption.」故障转移存在，因为单一供应商保证不存在。

与 Everythink 的 Oracle 集成的跨域平行只是结构性的。Oracle 把多个 typed Sisters（analyst、contrarian、disruptor、historian、institutionalist）的输出融合进一个归一化集成 — 如果某个 Sister 的草稿弱或缺失，集成仍靠其他 Sister 站住。文章的「供应商 A 宕机 → 供应商 B 接管」和 Oracle 的「一个 Sister 弱 → 集成仍继续融合」共享同一形式：多源故障转移是可用性的机制。⚠️ 部分 — Oracle 服务民用与防御性预测，LLM 网关服务商业 AI 基础设施。不同领域，同一形式：多源故障转移是可用性的机制。

机制 3 — 密钥管理是凭证主权的机制

文章说「One gateway key in your code; provider keys stay in the gateway config.」Honest Architect 把这读成一条凭证主权的主张：供应商凭证永远不到达应用，由密钥管理已集中化来保证，不由应用小心翼翼来保证。产生「应用代码持有一把网关密钥，而非三把供应商密钥」的机制是「供应商密钥住在网关配置里，应用永远看不到它们」。密钥管理是机制；应用级密钥卫生不是。✅ 生产 — 文章命名了机制（代码里一把网关密钥，供应商密钥在网关配置里）和属性（供应商凭证永远不到达应用）。

文章诚实地说明为何这要紧：没有它，「each team member has their own API keys」且「no unified dashboard showing total spend across providers」。凭证蔓延是症状；缺失的密钥管理机制才是原因。

与 Everythink 的 Eye Key 主权的跨域平行只是结构性的。Eye Key 是用户自有的凭证 — 明文从不落盘；只有 HMAC 与指纹进 Postgres，用户密钥是速率限制边界。文章的「供应商密钥留在网关配置里，应用持有一把网关密钥」和 Eye Key 的「明文在内存中显示一次，平台只存 HMAC」共享同一形式：凭证分离是主权的机制。⚠️ 部分 — Eye Key 治理民用与防御性预测的 API 主权，网关密钥管理治理商业 AI 基础设施。不同领域，同一形式：凭证分离是主权的机制。

机制 4 — 成本追踪是支出可观测性的机制

文章说「Without centralized cost tracking, you can't answer basic questions: Which model costs the most per task? Would switching providers save money? Are there runaway processes burning tokens?」并描述成本黑洞：「You discover at month-end that someone left a batch job running against GPT-5 all weekend. Your API bill is 4x what you budgeted.」Honest Architect 把这读成一条支出可观测性主张：支出受控，由成本追踪已实现且可见来保证，不由团队守纪律来保证。产生「你在月底之前抓住失控批处理作业」的机制是「集中化仪表盘实时显示跨供应商总支出」。成本追踪是机制；团队纪律不是。✅ 生产 — 文章命名了机制（集中化成本仪表盘，按模型按任务支出）和属性（失控支出被抓住）。

文章诚实地承认纸面上最便宜的配置（直连，0美元网关成本）藏了真实成本：「factor in engineering time — maintaining three SDKs, building custom fallback logic, debugging three different error formats, and reconciling three separate invoices — and the total cost of ownership shifts heavily toward using a gateway.」要紧的度量是总拥有成本，不是行项 API 成本。

与 Everythink 的带熵戳集成的跨域平行只是结构性的。Oracle 恰在一个地方归一化概率，并在每次合并上以 nats 盖戳熵 — 熵是从归一化中免费来的校准信号，不是一条单独的置信度声明。文章的「集中化仪表盘显示跨供应商支出，而非按供应商发票」和 Oracle 的「熵在每次合并上盖戳，而非单独声称」共享同一形式：一条从核心机制免费来的度量是诚实状态信号。⚠️ 部分 — 不同领域，同一形式：一条免费副产品度量是诚实状态信号。

机制 5 — 模型路由是边界决策的机制

文章说网关提供「Route requests to different models based on cost, latency, or capability」，故障转移配置接受一个 routing 参数（"routing": "cost"）。Honest Architect 把这读成一条边界决策主张：每请求选对模型，由路由规则在网关已实现来保证，不由应用硬编码模型来保证。产生「请求去到最便宜的合格供应商」的机制是「路由规则在派发之前在网关评估成本、延迟或能力」。模型路由是机制；应用里硬编码的模型字符串不是。✅ 生产 — 文章命名了机制（按成本/延迟/能力的路由规则，routing 参数）和属性（每请求模型选择）。

文章诚实地承认路由是策略，不是魔法：决策框架要求团队按定价模型、模型覆盖、SDK 兼容性、可靠性、自托管选项与开发者体验给网关打分。路由规则编码策略；策略不是隐含的。

与 Everythink 的「the space is the router」拓扑的跨域平行只是结构性的。Everythink 的 network → community → room 拓扑在有任何东西响应之前路由一个请求 — 空间是路由器，路由发生在计算的上游。文章的「网关在供应商响应之前路由」和 Everythink 的「拓扑在 agent 响应之前路由」共享同一形式：响应之前路由是边界决策的机制。⚠️ 部分 — 「the space is the router」治理民用与防御性预测拓扑，网关路由治理商业 AI 基础设施。不同领域，同一形式：响应之前路由是边界决策的机制。

机制 6 — 格式翻译是边界解析的机制

文章说某些网关原生支持 SDK 而无需翻译（Ofox：「three protocols natively — OpenAI, Anthropic, and Gemini SDKs all work without translation」），而另一些翻译（LiteLLM：「Anthropic SDK ✅ (translation)」）。Honest Architect 把这读成一条边界解析主张：应用说自己所选 SDK 的格式，由网关在边界翻译来保证，不由应用顺从每个供应商的格式来保证。产生「你的 Anthropic SDK 代码透过网关工作」的机制是「网关解析 Anthropic 格式请求并翻译成供应商的原生格式」。格式翻译是机制；应用侧格式顺从不是。✅ 生产 — 文章命名了机制（原生 SDK 支持无需翻译，或在网关翻译）和属性（应用的 SDK 代码无需修改即工作）。

文章诚实地说出权衡：原生支持意味着「you can use each provider's SDK with its full feature set, all through a single API key」，而翻译意味着你得到统一接口但可能失去供应商特定特性。边界解析；边界保留什么是一个设计选择。

与 Everythink 的运行时 Zod 边界的跨域平行只是结构性的。Everythink 的 wire 类型一次性定义在 @everythink/types 的 Zod 中，响应在网络边界被解析；坏 payload 浮现为 typed ApiError，从不崩溃。文章的「网关在边界解析请求格式，应用不推断」和 Everythink 的「解析器在边界验证 payload，应用不推断」共享同一形式：边界上的显式解析是正确解释的机制。⚠️ 部分 — 不同领域，同一形式：边界上的显式解析是正确解释的机制。

这对范围与限制意味着什么

Ofox 的文章是一家网关厂商的商业 AI 基础设施购买指南。六个机制形式是真实的，可从文章自身证据中提取。与 Everythink 的民用与防御性预测平台的跨域平行是结构性的 — 它们共享机制形式，不共享市场。Honest Architect 把它们标为 ⚠️。

Everythink 自身的 LLM 供应商配置只兼容 OpenAI（async-openai）：一个协议作为端口，任何兼容供应商（OpenAI、vLLM、OpenRouter、Together）作为适配器。这是同一个六边形端口模式应用在更窄的范围 — 一个协议，不是三个。没有直接的 Anthropic SDK 依赖。架构形式成立；实现范围更窄。这是 ⚠️ 部分，不是声称 Everythink 跑那六个网关的比较。

文章不主张的也值得标注。它不主张网关消除供应商宕机 — 它主张故障转移把宕机对应用藏起来。它不主张统一 API 消除模型差异 — 它主张网关翻译格式，而你仍选择模型。它不主张成本追踪减少支出 — 它主张追踪让支出可见。这些范围限制是文章的诚实，本帖保留它们。

关键点

• 你的应用在换供应商后仍存活，由统一接口已实现来保证，不由你的应用认识每个供应商的 SDK 来保证。统一 API 是机制。✅ 生产。
• 运行时间由故障转移已实现并在路由来保证，不由单一供应商可靠来保证。自动故障转移是机制。✅ 生产。
• 供应商凭证永远不到达应用，由密钥管理已集中化来保证，不由应用小心翼翼来保证。密钥管理是机制。✅ 生产。
• 支出受控，由成本追踪已实现且可见来保证，不由团队守纪律来保证。成本追踪是机制。✅ 生产。
• 每请求选对模型，由路由规则在网关已实现来保证，不由应用硬编码模型来保证。模型路由是机制。✅ 生产。
• 应用说自己所选 SDK 的格式，由网关在边界翻译来保证，不由应用顺从每个供应商的格式来保证。格式翻译是机制。✅ 生产。
• 与六边形 trait 端口（稳定端口是可互换性）、Oracle 集成（多源故障转移是可用性）、Eye Key 主权（凭证分离是主权）、带熵戳集成（免费副产品度量是诚实状态信号）、「the space is the router」（响应之前路由是边界决策）和运行时 Zod 边界（边界上显式解析是正确解释）的跨域平行只是结构性的 — 不同市场，同一机制形式。⚠️ 部分。
• Everythink 自身的 LLM 配置只兼容 OpenAI（一个协议作为端口，任何兼容供应商作为适配器）— 同一个六边形端口模式在更窄范围；不是声称跑六个网关的比较。⚠️ 部分。

Sources

• LLM API Gateway Guide: Choose the Right One (2025)，Ofox，2026年3月20日 发表。https://ofox.ai/blog/why-llm-api-gateway-how-to-choose-2026/ （检索于 2026-08-23）。
• Everythink 平台架构：HAI Engine 自 2016 起生产；Theorem 3（一个属性恰在其机制已实现并在测量时才被保证）；「the space is the router」拓扑（network → community → room）；World Monitor（按 geohash 前缀路由地理信号，多源网关带每源自禁，客户端读缓存而非上游）；Oracle 集成归一化，每次合并以 nats 盖戳熵；typed Sisters（analyst、contrarian、disruptor、historian、institutionalist）运行时从 TOML 文件加载；基于 trait 的六边形端口带可互换适配器（AppState 中的 Arc<dyn Trait>）；Zod wire 类型一次性定义在 @everythink/types，在网络边界解析，坏 payload → typed ApiError；Eye Key 主权（HMAC 与指纹登记，明文从不落盘，用户密钥是速率限制边界）；LLM 供应商只兼容 OpenAI，通过 async-openai（一个协议作为端口，任何兼容供应商作为适配器，无直接 Anthropic SDK 依赖）。