企业官网建设流程全解析

OpenClaw 接入 Together AI 实战指南：API Key 认证、模型选择与视频生成配置

【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 🦞项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw

本篇指南以 OpenClaw 内置的togetherprovider 为核心，讲解如何通过 API Key 完成认证、如何选择与切换内置的 Llama / Kimi / DeepSeek / GLM 模型，以及如何把 Together 配置为默认的视频生成服务。读完本文，你将掌握openclaw onboard交互式与非交互式两种接入流程、模型 ref 的书写规则、Gateway 守护进程环境变量注入要点，以及视频生成工具的参数约束与底层调用机制。

一、Provider 概览：OpenAI 兼容的统一入口

Together AI 通过一套统一的 API 提供 Llama、DeepSeek、Kimi 等主流开源模型的托管服务。OpenClaw 将其打包为名为together的内置 provider，其核心属性如下：

| 属性 | 值 | | ---- | -- | | Provider |together| | 认证方式 |TOGETHER_API_KEY| | API 协议 | OpenAI 兼容（openai-completions） | | Base URL |https://api.together.xyz/v1|

从源码实现看，provider 清单定义中明确声明了api: "openai-completions"与baseUrl: "https://api.together.xyz/v1"，入口文件 通过defineSingleProviderPluginEntry注册 provider，并配置了liveModelDiscovery: true与discoveryMode: "strict"，即模型目录支持动态发现且采用严格校验模式。

此外，Together 插件默认启用（enabledByDefault: true）且不在启动时激活（activation.onStartup: false），并在providerRequest中声明了family: "together"，因此只要配置好 API Key，即可在会话中直接使用该 provider。

二、Getting Started：从申请 Key 到设置默认模型

1. 获取 API Key

前往 Together AI 控制台的 API Keys 页面创建一个密钥。该密钥将作为 OpenClaw 访问 Together 服务的唯一凭证。

2. 运行认证引导

OpenClaw 提供了开箱即用的认证引导命令：

openclaw onboard --auth-choice together-api-key

--auth-choice together-api-key对应 插件清单 中注册的providerAuthChoices条目：其cliFlag为--together-api-key，optionKey为togetherApiKey，并启用了appGuidedSecret（应用引导式密钥录入）。引导完成后，OpenClaw 会把模型目录、默认模型与别名写入配置。

3. 设置默认模型

在 OpenClaw 配置文件中，通过agents.defaults.model.primary指定默认模型。模型 ref 的格式为together/<model-id>：

{ agents: { defaults: { model: { primary: "together/moonshotai/Kimi-K2.6", }, }, }, }

非交互式（自动化）接入示例

在 CI、脚本或容器环境中，可以使用完全非交互的引导命令，直接以命令行参数注入密钥：

openclaw onboard --non-interactive --accept-risk --skip-health \ --mode local \ --auth-choice together-api-key \ --together-api-key "$TOGETHER_API_KEY"

各参数作用如下：

• --non-interactive：跳过所有交互提示；
• --accept-risk：接受引导过程中的风险确认；
• --skip-health：跳过健康检查；
• --mode local：以本地模式初始化；
• --auth-choice together-api-key：选择 Together AI API Key 认证方式；
• --together-api-key "$TOGETHER_API_KEY"：直接提供密钥（与插件清单中的cliFlag一致）。

注意：引导过程会把 Together 推荐的聊天模型together/moonshotai/Kimi-K2.6设为默认模型。

三、内置模型目录：四种模型的完整规格与成本

Together provider 自带模型目录，成本单位为「每百万 tokens 美元」。以下数据与 插件清单模型目录 中的定义一致：

从源码看模型目录的结构

models.ts 从插件清单读取模型目录并通过buildManifestModelProviderConfig构建TOGETHER_MODEL_CATALOG，同时为每个模型统一标记api: "openai-completions"，确保它们走 OpenAI 兼容的补全接口。

值得注意的细节：

• 默认模型 Kimi K2.6 FP4 是唯一支持text与image两种输入类型的模型，并声明了reasoning: true；
• DeepSeek V4 Pro 与 GLM 5.2 都在compat.codeMode中标为capable，表示具备代码模式能力；
• 清单中还包含缓存读取（cacheRead）成本，例如 Kimi K2.6 的cacheRead: 0.2、Llama 3.3 的cacheRead: 1.04，便于更精确地评估长上下文会话的开销。

默认模型与别名的落地逻辑

onboard.ts 通过readManifestProviderDefaultModelRef从清单推导默认模型 ref，得到TOGETHER_DEFAULT_MODEL_REF = "together/moonshotai/Kimi-K2.6"，并注册了别名"Together AI"。对应的 单元测试 验证了三点：应用后的模型目录与清单一致、默认模型主值为together/moonshotai/Kimi-K2.6、agents.defaults.models中为该模型注册了alias: "Together AI"。

四、视频生成：把 Together 配置为默认视频提供方

Together 插件除了聊天补全，还通过共享的video_generate工具注册了视频生成能力（见 video-generation-provider.ts 与插件清单的contracts.videoGenerationProviders）。核心属性如下：

| 属性 | 值 | | ---- | -- | | 默认视频模型 |Wan-AI/Wan2.2-T2V-A14B| | 其他可用模型 |Wan-AI/Wan2.2-I2V-A14B、minimax/hailuo-02、kwaivgI/kling-2.1-master| | 模式 | 文生视频；仅Wan-AI/Wan2.2-I2V-A14B支持图生视频（单张参考图） | | 时长 | 1–10 秒 | | 支持的参数 |size（解析为<宽>x<高>）；aspectRatio/resolution不会被读取 |

配置为默认视频 provider

{ agents: { defaults: { mediaModels: { video: { primary: "together/Wan-AI/Wan2.2-T2V-A14B", }, }, }, }, }

底层实现要点

从源码可以确认以下机制：

• 请求地址：视频请求使用独立的https://api.together.xyz/v2端点（TOGETHER_VIDEO_BASE_URL）。如果用户在models.providers.together.baseUrl中配置了自定义地址且与聊天补全地址不同，则优先使用自定义地址；
• 异步任务轮询：提交任务后，如果状态不是completed，会以 5 秒间隔轮询GET {baseUrl}/videos/{videoId}，最多尝试 120 次，默认超时 120 秒；
• 时长解析：durationSeconds会被四舍五入并限制在 1–10 秒范围内（超出范围返回undefined，即不传该参数）；
• 尺寸解析：size仅接受^\d+x\d+$格式（如1280x720），解析后映射为请求体中的width与height；
• 图生视频约束：只有当模型为Wan-AI/Wan2.2-I2V-A14B时才允许携带参考图（至多 1 张），参考图可以是 URL 或本地 buffer（转换为 data URL 上传）；其余模型传入参考图会直接报错；
• 能力声明：capabilities中generate.maxVideos: 1、imageToVideo.enabled: true、videoToVideo.enabled: false，即单次最多生成 1 条视频、不支持视频到视频；
• 结果下载：完成后从响应中提取video_url，按配置的最大字节数限制下载为本地资产，并返回videoId、status、videoUrl等元数据。

关于共享工具的参数、provider 选择与故障转移行为，参见 视频生成工具文档。

五、环境变量：守护进程场景下的密钥注入

如果 Gateway 以守护进程方式运行（launchd / systemd），请务必确保TOGETHER_API_KEY对该进程可见，例如写入~/.openclaw/.env或通过env.shellEnv配置注入。

⚠️ 仅设置在交互式 shell 中的密钥对守护进程管理的 Gateway 是不可见的。请使用~/.openclaw/.env或env.shellEnv配置来保证密钥的持久可用。

六、故障排查

• 验证密钥是否生效：执行openclaw models list --provider together，如果能列出模型，说明密钥与连接正常；
• 模型不出现：确认 API Key 被设置在了 Gateway 进程实际运行的正确环境中（尤其是守护进程场景，参见上一节）；
• 模型 ref 书写：统一使用together/<model-id>形式，例如together/moonshotai/Kimi-K2.6。

另外，入口文件 还实现了故障原因分类：当错误信息匹配concurrency limit ... breached/reached时，会把失败归类为rate_limit，从而触发 OpenClaw 的限流重试与故障转移逻辑。

七、更多参考

• Model providers 概念文档：provider 规则、模型 ref 与故障转移行为；
• Video generation 工具文档：共享视频生成工具参数与 provider 选择机制；
• 配置参考：包含 provider 设置的完整配置 schema；
• CLI 引导命令文档：openclaw onboard的全部参数说明；
• CLI 模型命令文档：openclaw models list的使用方式。

【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 🦞项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw