AIRI 接入 BytePlus Coding PlanProvider 配置、验证流程与静态模型清单解析【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airiBytePlus Coding Plan 是 BytePlus 面向编码场景推出的订阅制服务计划在 AIRI 中它以一张独立 Provider 卡片的形式出现与普通的 BytePlus Ark API 配置互不冲突。本文基于 BytePlus Coding Plan 官方文档 展开结合 packages/stage-ui 中 Ark 系列 Provider 的源码实现与测试用例完整讲解凭据准备、界面配置、自动验证、模型选择与故障排查全流程并深入剖析其底层「静态模型列表 模型前缀剥离 OpenAI 兼容客户端」的实现机制帮助你正确、安全地把 BytePlus Coding Plan 接入 AIRI 的 Consciousness意识模块。先厘清关系BytePlus Coding Plan 与普通 BytePlus 是两张不同的卡片在 AIRI 的 Provider 体系里BytePlus 家族有两个独立条目分别对应不同的服务计划BytePlus适用于拥有 Ark API 访问权限的账号走常规的 Ark 兼容 chat 服务BytePlus Coding Plan适用于购买了 BytePlus Coding Plan 订阅的账号使用专用的 Coding Plan API 根地址。原文档的开篇提示点明了选择原则如果你的 BytePlus 账号拥有 Coding Plan就应该使用 Coding Plan 这张卡片而不是普通的 BytePlus 配置以保证请求命中的是与之匹配的服务计划订阅计费与模型配额均由 Coding Plan 统一管理。这一点在源码中得到了直接印证——两张卡片虽然共用同一套 Ark Provider 工厂ark-shared.ts 中的createArkChatProviderDefinition但注册了完全不同的defaultBaseUrl与静态模型列表见 byteplus-coding-plan/index.ts 与 byteplus/index.ts配置项BytePlusBytePlus Coding PlanProvider idbyteplusbyteplus-coding-plan默认 Base URLhttps://ark.ap-southeast.bytepluses.com/api/v3https://ark.ap-southeast.bytepluses.com/api/coding/v3模型前缀byteplus/byteplus-coding-plan/静态模型数5 个带 contextLength6 个无 contextLength是否有 Endpoint ID / 模型输入框无无同样面向中国大陆区域的 Volcengine Coding Plan 也是一张独立卡片其默认 Base URL 为https://ark.cn-beijing.volces.com/api/coding/v3三者共同构成了 AIRI 中「普通 Ark / Coding Plan」的 Provider 矩阵。两张 BytePlus 卡片与 Volcengine Coding Plan 的默认地址与模型清单均由 ark-providers.test.ts 的单元测试锁定防止后续重构导致配置漂移。第一步准备 BytePlus Coding Plan 凭据按照原文档的操作步骤你需要登录 BytePlus ModelArk 控制台区域为arkap-southeast-1的 Application Center / 应用中心获取 Coding Plan 专用的 API key。关键要点该 API key 必须归属于有效的 Coding Plan 订阅普通 Ark API key 无法通过 Coding Plan 卡片的验证获取后妥善保管切勿把 API key 或端点凭据提交进代码仓库、截图展示或分享给任何人——这是原文档明确列出的安全警告也是后续所有 Provider 配置的共同底线。在 AIRI 中API key 在表单里以type: password的字段渲染见下文源码解析输入时默认打码显示。第二步在 AIRI 中完成 Provider 配置配置入口非常直观打开Settings → Providers → Chat → BytePlus Coding Plan在API Key字段填入上一步获取的 Coding Plan API keyBase URL保持默认值https://ark.ap-southeast.bytepluses.com/api/coding/v3除非 BytePlus Coding Plan 官方文档另行给出兼容的 API 根地址注意该表单没有 Endpoint ID 字段也没有模型输入框——模型不在此处手工填写而是来自 AIRI 的静态 Provider 列表详见下一节。源码视角这个表单到底校验了什么BytePlus Coding Plan 的配置表单由 ark-shared.ts 中的 zod schema 定义核心字段只有两个const arkProviderConfigSchema z.object({ apiKey: z.string(API Key), baseUrl: z.string(Base URL), })随后通过createProviderConfig扩展元信息apiKey被标记为password类型并带本地化 label/placeholderbaseUrl则通过.default(defaultBaseUrl)自动填充为编码计划专用的默认地址ark-shared.ts。也就是说即使你只填了 API key、不动 Base URLzod 的 default 机制也会保证请求落到正确的 Coding Plan 端点。源码视角请求是如何发出的createProvider(config)使用xsai-ext/providers/create的createOpenAI(apiKey, baseUrl)构造一个 OpenAI 兼容客户端并包裹了chat()方法ark-shared.tscreateProvider(config) { const provider createOpenAI(config.apiKey ?? , config.baseUrl ?? defaultBaseUrl) const originalChat provider.chat.bind(provider) return { ...provider, chat(model: string, requestOptions?: ChatRequestOptions) { const request originalChat(stripModelPrefix(model, modelPrefix)) if (!requestOptions?.reasoning) return request return { ...request, thinking: { type: requestOptions.reasoning } } }, } }这里有两个值得注意的实现细节模型前缀剥离内部模型 id 统一带byteplus-coding-plan/前缀用于界面与模块层的唯一标识但真正发往 API 时通过stripModelPrefix把前缀去掉只把裸模型名如dola-seed-2.0-pro交给远端——测试用例 ark-providers.test.ts 对此有明确断言推理模式透传Provider 声明了chat.reasoning能力enabled/disabled当请求带有reasoning选项时会翻译为thinking: { type }字段传给模型对应 Coding Plan 中支持思维链的编码模型。静态模型清单6 个可用模型与原文档「模型来自 AIRI 静态 Provider 列表」的说明一致byteplus-coding-plan/index.ts 中硬编码了 6 个模型界面展示名即裸 id内部模型 id说明byteplus-coding-plan/dola-seed-2.0-pro高质量推理/编码模型byteplus-coding-plan/dola-seed-2.0-lite轻量级低延迟模型byteplus-coding-plan/bytedance-seed-code字节系编码模型byteplus-coding-plan/glm-4.7智谱 GLM 系列byteplus-coding-plan/kimi-k2.5月之暗面 Kimi 系列byteplus-coding-plan/gpt-oss-120bOpenAI 开源权重模型这些模型通过extraMethods.listModels暴露ark-shared.ts遍历models数组、拼上modelPrefix生成带前缀的完整 id并携带name、provider等元信息若某个模型配置了contextLength、deprecated或descriptionKey也会一并注入Coding Plan 卡片当前 6 个模型均未声明这些可选字段而普通 BytePlus 卡片的 5 个模型则带contextLength: 256000/200000可对照观察两套清单的差异。正因如此你在配置界面看不到模型输入框只需在验证通过后从模块层挑选模型。第三步验证配置并选择模型原文档给出了两条验证路径Validate configuration自动验证AIRI 在编辑配置时会自动触发校验如果表单中出现Ping API按钮点击即可发起一次真实请求测试确认 API key 与端点可用Select Model →验证通过后点击该按钮会跳转到Settings → Modules → Consciousness从上面静态清单暴露的模型中挑选一个作为意识模块的聊天模型。源码视角验证到底做了什么校验行为由 ark-shared.ts 定义validationRequiredWhen(config) { return !!config.apiKey?.trim() }, validators: { ...createOpenAICompatibleValidators({ checks: [ProviderValidationCheck.Connectivity, ProviderValidationCheck.ModelList, ProviderValidationCheck.ChatCompletions], normalizeModelId: modelId stripModelPrefix(modelId, modelPrefix), }), },validationRequiredWhen只有 API key 非空trim 后才需要校验避免空表单误触发网络请求三阶段检查Connectivity连通性先确认 Base URL 可达→ModelList拉取模型列表确认静态清单可被识别→ChatCompletions发一次最小 chat 补全请求端到端验证凭据与配额normalizeModelId与请求路径一致地剥离模型前缀保证校验请求与真实请求使用同一套 id 规则。对应测试文件 openai-compatible.test.ts 对这套校验器的行为有完整覆盖。这也解释了文档中「验证失败时按顺序排查」的建议为什么有效——三步检查本身就是递进的连接不通先查网络与 Base URL连接通而列表失败再查账号权限最后一步失败才是配额/模型权限问题。第四步故障排查原文档的 Troubleshooting 部分浓缩为两条核心排查路径验证失败检查 API key 是否属于有效的 BytePlus Coding Plan注意不是普通 Ark 订阅并确认 Base URL 是否正确默认值https://ark.ap-southeast.bytepluses.com/api/coding/v3不要误填成普通 BytePlus 的/api/v3模型被拒绝denied静态清单中的模型已经列出并展示但如果实际请求被拒绝需要到 BytePlus 控制台确认当前 Coding Plan 订阅是否授予了该模型的访问权限——清单只代表 AIRI 支持该模型的接入不代表你的订阅一定包含它。再结合源码补充两个常见误区一是混淆了 BytePlus 与 BytePlus Coding Plan 两张卡片Base URL 不同混用必然校验失败二是试图在表单里填 Endpoint ID 或自定义模型名——该卡片刻意不提供这两个字段模型只能从静态列表中选择。附如何从仓库中继续深挖想进一步验证或扩展本文结论可以直接阅读以下源码与测试文件Provider 定义与模型清单packages/stage-ui/src/libs/providers/providers/byteplus-coding-plan/index.tsArk 系列共用实现schema、客户端封装、前缀剥离、校验器packages/stage-ui/src/libs/providers/providers/ark-shared.ts默认地址与模型清单的回归测试packages/stage-ui/src/libs/providers/providers/ark-providers.test.tsProvider 注册表与枚举packages/stage-ui/src/libs/providers/providers/index.ts界面文案本地化en 为例packages/i18n/src/locales/en/settings.yamlbyteplus-coding-plan条目下仅含 title/description无模型子文案与静态清单一致同族对照文档普通 BytePlus 与 Volcengine Coding Plan至此从凭据准备、界面配置、自动验证到模型选择与故障排查你已经完整掌握 BytePlus Coding Plan 在 AIRI 中的接入方法也理解了其背后「共享 Ark 工厂 独立 Base URL 静态模型清单」这一可维护性设计。【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AIRI 接入 BytePlus Coding Plan：Provider 配置、验证流程与静态模型清单解析
AIRI 接入 BytePlus Coding PlanProvider 配置、验证流程与静态模型清单解析【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airiBytePlus Coding Plan 是 BytePlus 面向编码场景推出的订阅制服务计划在 AIRI 中它以一张独立 Provider 卡片的形式出现与普通的 BytePlus Ark API 配置互不冲突。本文基于 BytePlus Coding Plan 官方文档 展开结合 packages/stage-ui 中 Ark 系列 Provider 的源码实现与测试用例完整讲解凭据准备、界面配置、自动验证、模型选择与故障排查全流程并深入剖析其底层「静态模型列表 模型前缀剥离 OpenAI 兼容客户端」的实现机制帮助你正确、安全地把 BytePlus Coding Plan 接入 AIRI 的 Consciousness意识模块。先厘清关系BytePlus Coding Plan 与普通 BytePlus 是两张不同的卡片在 AIRI 的 Provider 体系里BytePlus 家族有两个独立条目分别对应不同的服务计划BytePlus适用于拥有 Ark API 访问权限的账号走常规的 Ark 兼容 chat 服务BytePlus Coding Plan适用于购买了 BytePlus Coding Plan 订阅的账号使用专用的 Coding Plan API 根地址。原文档的开篇提示点明了选择原则如果你的 BytePlus 账号拥有 Coding Plan就应该使用 Coding Plan 这张卡片而不是普通的 BytePlus 配置以保证请求命中的是与之匹配的服务计划订阅计费与模型配额均由 Coding Plan 统一管理。这一点在源码中得到了直接印证——两张卡片虽然共用同一套 Ark Provider 工厂ark-shared.ts 中的createArkChatProviderDefinition但注册了完全不同的defaultBaseUrl与静态模型列表见 byteplus-coding-plan/index.ts 与 byteplus/index.ts配置项BytePlusBytePlus Coding PlanProvider idbyteplusbyteplus-coding-plan默认 Base URLhttps://ark.ap-southeast.bytepluses.com/api/v3https://ark.ap-southeast.bytepluses.com/api/coding/v3模型前缀byteplus/byteplus-coding-plan/静态模型数5 个带 contextLength6 个无 contextLength是否有 Endpoint ID / 模型输入框无无同样面向中国大陆区域的 Volcengine Coding Plan 也是一张独立卡片其默认 Base URL 为https://ark.cn-beijing.volces.com/api/coding/v3三者共同构成了 AIRI 中「普通 Ark / Coding Plan」的 Provider 矩阵。两张 BytePlus 卡片与 Volcengine Coding Plan 的默认地址与模型清单均由 ark-providers.test.ts 的单元测试锁定防止后续重构导致配置漂移。第一步准备 BytePlus Coding Plan 凭据按照原文档的操作步骤你需要登录 BytePlus ModelArk 控制台区域为arkap-southeast-1的 Application Center / 应用中心获取 Coding Plan 专用的 API key。关键要点该 API key 必须归属于有效的 Coding Plan 订阅普通 Ark API key 无法通过 Coding Plan 卡片的验证获取后妥善保管切勿把 API key 或端点凭据提交进代码仓库、截图展示或分享给任何人——这是原文档明确列出的安全警告也是后续所有 Provider 配置的共同底线。在 AIRI 中API key 在表单里以type: password的字段渲染见下文源码解析输入时默认打码显示。第二步在 AIRI 中完成 Provider 配置配置入口非常直观打开Settings → Providers → Chat → BytePlus Coding Plan在API Key字段填入上一步获取的 Coding Plan API keyBase URL保持默认值https://ark.ap-southeast.bytepluses.com/api/coding/v3除非 BytePlus Coding Plan 官方文档另行给出兼容的 API 根地址注意该表单没有 Endpoint ID 字段也没有模型输入框——模型不在此处手工填写而是来自 AIRI 的静态 Provider 列表详见下一节。源码视角这个表单到底校验了什么BytePlus Coding Plan 的配置表单由 ark-shared.ts 中的 zod schema 定义核心字段只有两个const arkProviderConfigSchema z.object({ apiKey: z.string(API Key), baseUrl: z.string(Base URL), })随后通过createProviderConfig扩展元信息apiKey被标记为password类型并带本地化 label/placeholderbaseUrl则通过.default(defaultBaseUrl)自动填充为编码计划专用的默认地址ark-shared.ts。也就是说即使你只填了 API key、不动 Base URLzod 的 default 机制也会保证请求落到正确的 Coding Plan 端点。源码视角请求是如何发出的createProvider(config)使用xsai-ext/providers/create的createOpenAI(apiKey, baseUrl)构造一个 OpenAI 兼容客户端并包裹了chat()方法ark-shared.tscreateProvider(config) { const provider createOpenAI(config.apiKey ?? , config.baseUrl ?? defaultBaseUrl) const originalChat provider.chat.bind(provider) return { ...provider, chat(model: string, requestOptions?: ChatRequestOptions) { const request originalChat(stripModelPrefix(model, modelPrefix)) if (!requestOptions?.reasoning) return request return { ...request, thinking: { type: requestOptions.reasoning } } }, } }这里有两个值得注意的实现细节模型前缀剥离内部模型 id 统一带byteplus-coding-plan/前缀用于界面与模块层的唯一标识但真正发往 API 时通过stripModelPrefix把前缀去掉只把裸模型名如dola-seed-2.0-pro交给远端——测试用例 ark-providers.test.ts 对此有明确断言推理模式透传Provider 声明了chat.reasoning能力enabled/disabled当请求带有reasoning选项时会翻译为thinking: { type }字段传给模型对应 Coding Plan 中支持思维链的编码模型。静态模型清单6 个可用模型与原文档「模型来自 AIRI 静态 Provider 列表」的说明一致byteplus-coding-plan/index.ts 中硬编码了 6 个模型界面展示名即裸 id内部模型 id说明byteplus-coding-plan/dola-seed-2.0-pro高质量推理/编码模型byteplus-coding-plan/dola-seed-2.0-lite轻量级低延迟模型byteplus-coding-plan/bytedance-seed-code字节系编码模型byteplus-coding-plan/glm-4.7智谱 GLM 系列byteplus-coding-plan/kimi-k2.5月之暗面 Kimi 系列byteplus-coding-plan/gpt-oss-120bOpenAI 开源权重模型这些模型通过extraMethods.listModels暴露ark-shared.ts遍历models数组、拼上modelPrefix生成带前缀的完整 id并携带name、provider等元信息若某个模型配置了contextLength、deprecated或descriptionKey也会一并注入Coding Plan 卡片当前 6 个模型均未声明这些可选字段而普通 BytePlus 卡片的 5 个模型则带contextLength: 256000/200000可对照观察两套清单的差异。正因如此你在配置界面看不到模型输入框只需在验证通过后从模块层挑选模型。第三步验证配置并选择模型原文档给出了两条验证路径Validate configuration自动验证AIRI 在编辑配置时会自动触发校验如果表单中出现Ping API按钮点击即可发起一次真实请求测试确认 API key 与端点可用Select Model →验证通过后点击该按钮会跳转到Settings → Modules → Consciousness从上面静态清单暴露的模型中挑选一个作为意识模块的聊天模型。源码视角验证到底做了什么校验行为由 ark-shared.ts 定义validationRequiredWhen(config) { return !!config.apiKey?.trim() }, validators: { ...createOpenAICompatibleValidators({ checks: [ProviderValidationCheck.Connectivity, ProviderValidationCheck.ModelList, ProviderValidationCheck.ChatCompletions], normalizeModelId: modelId stripModelPrefix(modelId, modelPrefix), }), },validationRequiredWhen只有 API key 非空trim 后才需要校验避免空表单误触发网络请求三阶段检查Connectivity连通性先确认 Base URL 可达→ModelList拉取模型列表确认静态清单可被识别→ChatCompletions发一次最小 chat 补全请求端到端验证凭据与配额normalizeModelId与请求路径一致地剥离模型前缀保证校验请求与真实请求使用同一套 id 规则。对应测试文件 openai-compatible.test.ts 对这套校验器的行为有完整覆盖。这也解释了文档中「验证失败时按顺序排查」的建议为什么有效——三步检查本身就是递进的连接不通先查网络与 Base URL连接通而列表失败再查账号权限最后一步失败才是配额/模型权限问题。第四步故障排查原文档的 Troubleshooting 部分浓缩为两条核心排查路径验证失败检查 API key 是否属于有效的 BytePlus Coding Plan注意不是普通 Ark 订阅并确认 Base URL 是否正确默认值https://ark.ap-southeast.bytepluses.com/api/coding/v3不要误填成普通 BytePlus 的/api/v3模型被拒绝denied静态清单中的模型已经列出并展示但如果实际请求被拒绝需要到 BytePlus 控制台确认当前 Coding Plan 订阅是否授予了该模型的访问权限——清单只代表 AIRI 支持该模型的接入不代表你的订阅一定包含它。再结合源码补充两个常见误区一是混淆了 BytePlus 与 BytePlus Coding Plan 两张卡片Base URL 不同混用必然校验失败二是试图在表单里填 Endpoint ID 或自定义模型名——该卡片刻意不提供这两个字段模型只能从静态列表中选择。附如何从仓库中继续深挖想进一步验证或扩展本文结论可以直接阅读以下源码与测试文件Provider 定义与模型清单packages/stage-ui/src/libs/providers/providers/byteplus-coding-plan/index.tsArk 系列共用实现schema、客户端封装、前缀剥离、校验器packages/stage-ui/src/libs/providers/providers/ark-shared.ts默认地址与模型清单的回归测试packages/stage-ui/src/libs/providers/providers/ark-providers.test.tsProvider 注册表与枚举packages/stage-ui/src/libs/providers/providers/index.ts界面文案本地化en 为例packages/i18n/src/locales/en/settings.yamlbyteplus-coding-plan条目下仅含 title/description无模型子文案与静态清单一致同族对照文档普通 BytePlus 与 Volcengine Coding Plan至此从凭据准备、界面配置、自动验证到模型选择与故障排查你已经完整掌握 BytePlus Coding Plan 在 AIRI 中的接入方法也理解了其背后「共享 Ark 工厂 独立 Base URL 静态模型清单」这一可维护性设计。【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考