如果你同时在用 OpenAI、Anthropic、Gemini、Groq 等多个模型 API，大概率经历过这种痛苦：每个供应商的 SDK 不一样，认证方式不一样，请求格式不一样，错误处理也不一样。你的代码里散落着各种 if provider == "anthropic" 的分支，每次新增一个模型都要改一堆胶水代码。
GoModel 就是来解决这个问题的。
一个网关，统一所有模型 API
GoModel 是一个用 Go 写的开源 AI 网关，刚在 Hacker News 上获得了不少关注。它的核心思路很简单：提供一个 OpenAI 兼容的统一 API，背后自动路由到 OpenAI、Anthropic、Google Gemini、xAI、Groq、OpenRouter、Azure OpenAI、Oracle、Ollama 等 10+ 个供应商。
启动方式极简 — 一个 Docker 命令，传入你有的 API Key，就能跑起来：
docker run --rm -p 8080:8080 \\
-e OPENAI_API_KEY="sk-xxx" \\
-e ANTHROPIC_API_KEY="sk-ant-xxx" \\
-e GEMINI_API_KEY="xxx" \\
enterpilot/gomodel
然后所有请求都走 localhost:8080/v1/chat/completions，通过 model 字段自动路由到对应供应商。对调用方来说，只需要对接一套 OpenAI 格式的 API。
为什么值得关注
市面上做 AI 网关的项目不少，但 GoModel 有几个点让我觉得值得一看：
第一，Go 写的。 这不是废话 — AI 基础设施领域大量项目用 Python 写，在高并发场景下性能堪忧。Go 天生适合做网关这种 I/O 密集型服务，goroutine 的并发模型处理大量并行 API 请求比 Python 的 asyncio 优雅得多。
第二，功能覆盖比较全。 不只是 chat completions，还支持 OpenAI 的 Responses API、Embeddings、Files、Batches，甚至有 Passthrough 模式可以直接透传供应商特有的 API。这意味着你不会因为用了网关就丢失某些供应商的独有功能。
第三，零配置自动发现。 你传了哪些 API Key，它就自动启用哪些供应商。不需要写配置文件，不需要声明路由规则。这个设计哲学很对 — 基础设施应该是“能用就用”，而不是“先配半天”。
适合什么场景
说实话，如果你只用一个模型供应商，GoModel 对你没什么用。它的价值在于多模型场景：
- 开发团队内部：统一 API 入口，开发者不需要关心底层用的是哪个模型
- 成本优化：简单任务路由到便宜的模型，复杂任务才用贵的
- 容灾切换：某个供应商挂了，可以快速切到备选
- 合规需求：所有 AI 请求经过统一网关，方便审计和监控
自带 Prometheus 指标和 PostgreSQL 日志存储，运维友好度不错。
冷静看几个问题
当然，开源项目要看清楚再用：
- 项目还很年轻，star 数刚起来，生产环境使用需要谨慎评估稳定性
- 没有内置的负载均衡和限流（至少文档里没看到），高流量场景可能需要前面再加一层
- 模型名称映射依赖供应商的命名规范，跨供应商的模型等价映射（比如 GPT-4o 和 Claude Sonnet 4 之间的选择）需要自己处理
这类项目的核心风险是：供应商 API 变更的速度很快，网关能不能跟上？一个人或小团队维护的开源项目，长期维护能力是最大的不确定性。
写在最后
AI 基础设施正在从“直连模型 API”走向“通过中间层管理模型”。这个趋势很明确 — 当你用的模型从 1 个变成 5 个、10 个，中间层就不是可选项，而是必需品。
GoModel 代表了一种思路：用一个轻量的网关层抹平供应商差异，让上层应用只关心“我要什么能力”，而不是“我要调谁的 API”。像 OfoxAI（ofox.ai）这样的多模型聚合平台在产品层面做的也是类似的事 — 一个入口接入 Claude、GPT、Gemini 等主流模型，把供应商切换的成本降到最低。
不管是自建网关还是用现成的聚合平台，多模型策略已经不是“要不要做”的问题，而是“怎么做”的问题了。
