wormhole

采用判断：如果你正在用 Go 搭建需要同时接入多家大模型的后端，wormhole 值得关注；但目前证据几乎只来自官方 GitHub 仓库页面，热度和可用性样本都很有限，所以更适合当作早期项目观察或自行评估，而不是直接视为成熟标准件。

实际作用上，它不是聊天机器人产品、也不是工作流编排平台，更像 Go 版的多模型接入抽象层/网关 SDK：把 OpenAI、Anthropic、Gemini、Ollama、OpenRouter 放到统一接口下，并突出自适应限流和并发控制。对需要自己写服务、批处理、代理层或内部 AI 能力封装的团队，这类工具的具体产出通常是更统一的调用代码、供应商切换能力和更可控的并发请求管理。

门槛与成本方面，现有证据只能支持“代码开源”与“支持多家提供商”这两个判断；没有看到官方定价页、托管服务收费或 API 加价信息，因此不能推断它本身收费。更合理的保守判断是：SDK 本体大概率按开源方式使用，但真实成本仍主要来自你所连接的模型提供商 API 费用，这里属于保守推断，不是官方价格承诺。此外，它要求使用者具备 Go 开发能力，并自行处理部署、密钥、监控与错误恢复。

适合谁：想在 Go 服务里统一接入多模型、并且愿意读源码做技术验证的开发者。不太适合谁：希望拿来即用的非技术团队，或需要已被大量生产案例验证的企业采购方。社媒共识与讨论质量方面，目前几乎看不到教程、长文评测、实测线程或社区争论；现有 evidenceSources 基本就是仓库自身信息。GitHub 上少量 star 只能算“有人注意到”的热度证明，不能当成“已经很好用”的证明；由于缺少第三方实测，能力、稳定性和维护活跃度都应保守看待。