用混元 / TokenHub 作为 Olano 的模型提供方

先说结论：Olano 的具名提供方列表里有通义千问、DeepSeek、Kimi 和十几家海外模型，暂时没有混元。但腾讯云的 TokenHub 提供 OpenAI 兼容的接口，而 Olano 有两条通用的 OpenAI 兼容接入通道：LiteLLM 代理（模型前缀 litellm:，端点由 LITELLM_BASE_URL 指定）和可覆盖端点的 OpenAI 兼容网关提供方。通过其中任何一条，混元今天就能在 Olano 里跑。它和具名提供方的区别是：多一层配置，某些模型特有功能（比如思考模式的参数）能否透传取决于中间那一层。

本页涉及第三方平台的信息，均于 2026 年 9 月 26 日对照各厂商的公开文档核对。厂商的接口、模型名和条款变化很快，落地前请以其当前文档为准。本页描述的 Olano 功能以当前版本为准。

TokenHub 是什么

按腾讯云的公开介绍，TokenHub 把混元和主流第三方模型统一接入，提供新模型的首日可用、统一的协议与密钥管理，以及按成本、性能和能力动态路由。对企业的实际意义是：一个密钥、一份账单，背后可以是混元也可以是别家模型。

它对外提供 OpenAI 兼容接口，这正是 Olano 能接上它的原因。具体端点和模型名请以腾讯云当前文档为准——这类信息变得比文章快。

路径一：LiteLLM 代理

这是最通用、也最成熟的一条路。LiteLLM 是一个开源的模型代理，Olano 把它当作一个提供方（litellm）来用：

1. 运行一个 LiteLLM 代理，在它的配置里把 TokenHub 的 OpenAI 兼容端点和你的密钥登记为上游。
2. 在 Olano 里设置 LITELLM_BASE_URL 指向这个代理。
3. 给智能体填模型字符串 litellm:<模型名>，模型名是你在 LiteLLM 配置里给混元起的别名。

好处是 LiteLLM 本身对几十家上游有适配，混元的参数透传、错误处理、重试都由它负责，Olano 这一侧看到的就是一个标准接口。代价是你多维护一个进程。

路径二：OpenAI 兼容网关提供方

Olano 内置了一个面向 OpenAI 兼容网关的提供方，默认指向某一家网关，但端点可以覆盖——把它指向 TokenHub 的 OpenAI 兼容端点、密钥填 TokenHub 的密钥，理论上就绕过了代理这一层。

说“理论上”是诚实的：这条路径依赖 TokenHub 的接口与 OpenAI 规范的兼容程度，而兼容层之间总有细微差异。它比路径一少一个进程，但少一层适配。对于生产环境，我们的建议是先用路径一跑通，确认模型行为符合预期，再考虑要不要省掉代理。

具名提供方和兼容路径的实际区别

对比一下通义千问的接入就很清楚：千问是一个密钥、一个前缀，DashScope 特有的思考模式等能力由专门的适配处理。混元走兼容路径，意味着：

• 基础能力没有区别。对话、工具调用、多轮上下文、记忆、审批——这些都在 Olano 这一层，跟模型是谁无关。
• 模型特有参数可能需要手动处理。能否透传取决于中间那层。
• 多一处要维护的东西。代理的版本、配置、可用性。
• 换起来同样不丢东西。记忆和对话线程独立于模型，这一点对所有提供方一样。

什么情况下值得走这条路

• 已经在腾讯云体系内，希望模型用量和其他云服务统一计费。
• 团队和客户主要在微信 / 企业微信生态——渠道已经接了企业微信，模型也留在同一体系内有管理上的便利。
• 需要混元和第三方模型统一路由，TokenHub 的动态路由正是为此。

反过来，如果你只是想要一个国产模型、没有腾讯云的既有投入，通义千问的具名接入省事得多。两者也可以并存：负责人用千问、某个岗位用混元，在同一个部署里。

关于“为什么不是具名提供方”

提供方列表是随需求增长的，不是一次定完的。这篇文章存在的意义之一，就是如实描述今天的状态，而不是假装已经有了一个还没有的集成。如果混元成为具名提供方，这一页会更新，日期会改。

各家智能体平台之间的整体定位，包括腾讯云自己的 AgentOps 平台，见悟空、千帆、混元智能体与 Olano：各自适合什么。