钱拓 Token Hub · 选型对比
New API 还是 Token Hub？
New API 是能力成熟、覆盖广的开源大模型网关与 AI 资产管理系统，适合有工程能力的团队自建。Token Hub 不靠“也能转发模型”取胜，而是面向企业内部生产运行，把员工、部门、Agent、MCP 工具与 Skills 纳入同一套身份、权限、成本、审计和交付责任。两者不是简单的免费版与企业版关系；选型关键是企业愿不愿意长期自维护，以及是否需要组织级治理与结果责任。
| 维度 | New API（开源大模型网关 / AI 资产管理） | Token Hub（企业 AI 运行治理平台） |
|---|---|---|
| 产品路线 | 开源、覆盖广，可自建并按团队需要二次开发 | 面向企业内部组织与生产 Agent 的商业私有化交付 |
| 模型与能力接入 | 支持广泛的模型、协议及 Embedding、语音等多模态接口 | 统一纳管对话模型、Embedding 与 ASR；接入广度是基础能力，不是核心差异 |
| 组织身份 | 密码、OAuth / OIDC、用户角色、分组与 Token 管理 | 企业 IM 手机号验证码（钉钉 / 飞书 / 企微）+ 通讯录同步 + 离职自动回收 |
| 员工与 Agent | 以用户、分组、Token、额度和模型限制为主要管理对象 | 个人 Key 与服务账号分离，负责人可转移；员工离职不影响生产 Agent |
| 成本治理 | 提供额度、余额、倍率、分组、订阅、日志与用量统计 | 按用户、部门、模型、Key 与服务账号归集内部成本并导出 |
| 可用性与路由 | 支持优先级、权重、渠道测试、失败自动禁用、多 Key 轮询与分组容灾 | 支持渠道与路由治理；按成本 / 质量智能择优仍在规划中 |
| MCP / Skills 治理 | 核心文档聚焦模型网关和资产管理；生态应用可另行使用 MCP / Skills | 内置 MCP 工具审核、风险与指纹治理、调用审计，以及 Skills 审核、版本、范围和分发 |
| 安全与审计 | 提供使用日志、Token 限制、IP 白名单等安全管理能力 | 请求、操作、MCP 工具与 Skills 审计；客户端 Key 仅存哈希，供应商 Key 加密落库 |
| 交付责任 | 团队自行承担部署、升级、备份、回滚与故障处置 | 钱拓负责私有化部署、升级与持续支持，系统自检降低日常运维门槛 |
该选 OneAPI / New API
有专门工程团队愿意长期维护，优先追求开源可改、模型与协议覆盖、渠道策略和较低软件成本；或需要充值、订阅、API 分发等运营能力。
该选 Token Hub
AI 已从研发试用走向员工和生产 Agent，需要接企业通讯录、区分个人与服务账号、按部门核算、治理 MCP / Skills、保留审计，并希望有人对私有化交付、升级和运行负责。
对比基于 2026 年 8 月 New API 官方公开文档整理；产品持续迭代，请以最新版本与实际验证为准。
常见问题
New API 已经能用于企业自建，为什么还需要 Token Hub？
New API 已具备多模型、额度与成本、日志、渠道优先级和故障禁用等成熟能力。企业需要 Token Hub 的主要原因不是“多一个转发网关”，而是 AI 已进入员工和生产 Agent：需要接企业通讯录、区分个人 Key 与服务账号、把成本归到部门、审核 MCP / Skills，并明确私有化交付后的长期责任。
已有 New API，迁移到 Token Hub 需要重写应用吗？
通常不以重写应用为目标。对于沿用 OpenAI Chat 或 Anthropic Messages 调用方式的应用，重点是盘点现有 base_url、模型名、渠道和 Key 归属，再完成映射与兼容验证。具体改动量取决于当前使用的协议、扩展参数和自定义逻辑，需要在迁移评估中逐项确认。
迁移期间如何降低生产风险？
先盘点应用、模型、Key 和生产 Agent，再选择小范围流量并行验证；原网关保留为回退路径。协议兼容、权限、服务账号、成本归属和审计通过验收后，再按应用分批切换，并在正式切换前明确回滚窗口和责任人。
Token Hub 是否在所有方面都比 New API 更强？
不是。New API 在开源可改、模型与协议覆盖、渠道策略以及充值订阅等运营能力上很成熟；Token Hub 的重点是企业内部组织治理、员工与 Agent 身份分离、部门成本、MCP / Skills 生产管控和商业交付责任。两者解决的问题边界不同。
什么情况下不建议从 New API 切换？
如果企业有专门工程团队愿意长期维护，优先追求开源可改和较低软件成本，并且暂时不需要企业通讯录、服务账号交接、部门成本、MCP / Skills 治理或商业交付责任，继续使用 New API 往往更合适。