Hacker News 当日有一篇“所以你想使用 OpenRouter”，98 points、9 条评论。它提醒开发者，统一模型 API、供应商故障切换和集中计费会改变应用的边界。接入层变薄了，路由、隐私、账单和故障排查的责任会转移到配置上。
它解决了哪件麻烦事
应用通过一个兼容 OpenAI 风格的接口访问多个模型和供应商。更换模型通常只需改变模型标识，服务可以提供 fallback、提供商选择和用量统计。对于需要同时试验多家模型的原型团队，这能减少重复写鉴权、请求格式和计费逻辑的时间。
统一接口不会让模型行为统一。上下文窗口、工具调用、结构化输出、图片能力和速率限制仍会变化。所谓兼容，通常只覆盖请求和响应的共同部分。
最容易踩的三个坑
第一是自动路由不等于最低价格。自动选择可能优先可靠性或能力，实际费用取决于被选中的模型和供应商。需要预算上限时，应明确模型、供应商顺序和 fallback 规则。
第二是把密钥和数据边界想得太简单。请求经过额外服务，团队需要核对保留策略、日志、区域、零数据保留选项和 BYOK 的费用口径。
第三是忽略模型字段差异。生产代码应记录最终响应中的 model、provider、延迟、token 和错误类型，不能只记录“请求成功”。
一套稳妥的接入流程
- 先用一个固定模型完成最小请求，验证鉴权、超时和错误解析。
- 再加入明确的 fallback 列表，给每个模型写能力和价格标签。
- 为敏感请求配置数据保留策略，禁止把密钥、用户隐私和内部提示词写入普通日志。
- 设置余额、速率和单请求 token 上限，并用故障注入测试切换行为。
- 线上持续记录最终路由结果，用真实数据校正成本和质量。
什么时候不该加这一层
如果应用只依赖一家模型，且已有成熟的官方 SDK，额外代理层会增加排障和合规审查成本。强监管场景也许更适合直接使用供应商的区域、合同和审计能力。选择中间层前，先问自己能否接受多一个故障点。
生产监控应该记录什么
至少保留请求用途、模型标识、最终供应商、输入输出 token、延迟、重试次数和错误类别。用户内容需要脱敏，密钥绝不能进入日志。路由策略变更后，重新跑固定评测集，确认结构化输出和工具调用仍符合应用约定。
对于需要稳定结果的任务，可以给模型和供应商做白名单，把自动路由留给探索环境。对于容错优先的任务，再允许 fallback，并明确哪些错误可以切换，哪些错误应该直接返回，避免重复扣费或重复执行有副作用的工具。
FAQ
OpenRouter 会自动选最便宜的模型吗？不能这样假设，必须查看路由配置和实际响应。
它能完全避免供应商宕机吗？不能。它只能在存在可用候选时切换，应用仍需处理超时和部分失败。
个人项目最该做什么？先固定模型和预算，再逐步增加 fallback，别一开始把所有自动选项都打开。