一套系统，两种运行方式：xairouter.com + xaicontrol.com 的组合玩法

Posted March 9, 2026 by XAI 技术团队 ‐ 15 min read

如果把 AI 接入看作一套基础设施，那么 xairouter.com 解决的是“马上能用”，xaicontrol.com 解决的是“资源归你、规则归你、分发也归你”。两者不是两套互不相关的产品，而是同一套系统的两种运行方式。

对很多团队来说，最容易困惑的并不是接口本身，而是这几个域名之间的关系：xairouter.com、xaicontrol.com、admin.xaicontrol.com、manage.xaicontrol.com 分别做什么？主账户和子账户又如何配合？这篇文章把这件事一次讲清楚，并给出最快可落地的使用路径。

先说结论：
• 想在线注册后立刻调用统一 AI API，可以先用 xairouter.com
• 想纳管自己手里的 OpenAI、Anthropic、Gemini、DeepSeek 等第三方官方 API Key，并把资源分发给团队或客户，直接用 xaicontrol.com
• 想既保留统一接口，又保留资源所有权与治理权，就用 xairouter.com + xaicontrol.com 的组合方式

先把几个站点说清楚

你可以把这套系统理解为“文档入口 + 配置入口 + 管理入口 + 统一 API 入口”四个层面：

入口	角色	作用
`xairouter.com`	在线即用模式	面向开发者与团队的统一 AI API Router，强调注册即用、统一采购、统一接入
`xaicontrol.com`	BYOK 模式	面向团队与企业的多租户 BYOK AI API Router，强调自有第三方 Key 的治理、分发与审计
`admin.xaicontrol.com` / `a.xaicontrol.com`	配置管理	同一个站点，仅主账户可进入，用来录入第三方 Provider Key 和配置路由规则
`manage.xaicontrol.com` / `m.xaicontrol.com`	用户管理	同一个站点，主账户和子账户都可进入，用来查看用量、账单、日志，并做子账户管理

如果你使用的是 XAI Router 的在线即用模式，对应的用户入口是 m.xairouter.com；如果你使用的是 XAI Control 的 BYOK 模式，对应的配置与管理入口则是 a.xaicontrol.com / m.xaicontrol.com。

再往下看，真正给业务系统调用的是统一 API：

https://api.xairouter.com：对应 XAI Router 的在线即用模式
https://api.xaicontrol.com：对应 XAI Control 的 BYOK 自主管理模式

也就是说，前台看到的是几个站点，后台真正对接业务时，核心仍然是一个统一的 API Router。

这套关系最简单的理解方式

如果你希望先快速建立清晰的心智模型，可以先按下面这个最实用的版本理解：

在 xaicontrol.com 自主注册得到的账号，就是一级主账户
一级主账户最大的特点，是可以登录 Admin
主账户在 Admin 中录入自己手里的第三方 AI API Key
主账户在 Manage 中创建子账户、分配额度、限制模型与访问范围
子账户只需要登录 Manage，通常不需要也没有权限进入 Admin
业务系统和团队成员最终都通过统一 Base URL 调用模型，而不是直接拿原始 Provider Key 去调用官方接口

从使用体验上看，这就像把“原始资源”和“使用权限”拆开了：

第三方官方 AI API Key
        ↓
主账户在 Admin 录入与配置
        ↓
主账户在 Manage 创建子账户并分发额度/权限
        ↓
子账户拿到自己的 XAI API Key
        ↓
应用、成员、项目统一调用 api.xaicontrol.com

这正是 xaicontrol.com 的核心价值：你的第三方 Key 不再四处散落，而是被变成一套可治理、可分发、可审计的团队 AI 资源系统。

从 API 角度看这套系统

如果你更关心技术边界，而不是页面名称，那么这套系统可以直接拆成三类接口：

1. Admin API：管资源与规则

主账户进入 Admin 后，实际对应的是一组 Owner 级接口：

/x-keys：管理上游 Provider Key
/x-conf：查看和批量更新主账户级配置
/x-config：读写配置项
/x-info：查看某个用户的详细信息

这些接口对应的能力包括：

录入 OpenAI、Anthropic、Gemini、DeepSeek 等第三方官方 Key
配置 LevelMapper、ModelMapper、Resources、ModelLimits
管理模型分组、主备切换、白名单与定价策略

2. Manage API：管账户、额度和分发

Manage 对应的是日常运营侧接口：

/x-users：创建、更新、删除子账户
/x-dna：查看后代账户树
/x-bill：查看后代账单
/dashboard/*：查看状态、账单、日志、新闻、模型清单
/x-self：轮换当前账户 API Key

这部分决定的不是“模型怎么路由”，而是“谁能用、能用多少、能看到什么”。

3. Proxy API：真正对外提供模型服务

最终业务系统接的，是统一推理入口：

/v1/chat/completions
/v1/responses
/v1/messages
/v1/models

这也是为什么从业务代码角度看，整套系统非常克制：应用往往只需要改 Base URL 和 API Key，不需要改调用范式。

玩法 A：xairouter.com + xaicontrol.com 组合使用

这是最适合团队、渠道和 SaaS 场景的一种方式。

它的核心思路不是“两个站都要重度使用”，而是让两者各自承担最合适的角色：

xairouter.com 负责统一产品入口、文档、模型目录、协议说明和快速接入认知
xaicontrol.com 负责自有第三方 AI 资源的接入、治理、分发和审计

换句话说，xairouter.com 让团队更容易理解和对接统一 API，xaicontrol.com 让团队真正掌握资源所有权与配置权。

这种组合特别适合以下几类团队：

已经打算长期使用统一 AI API，但不希望把核心资源交给平台代管
需要把 OpenAI、Anthropic、Gemini、DeepSeek 等多家资源统一收口
需要把 AI 能力按部门、项目、客户、环境分发出去
希望研发团队只面向一套兼容接口开发，而把成本、限额、权限、路由策略留给平台侧治理

一个很常见的实际落地方式是：

研发团队先按 xairouter.com 的文档和示例，把接入标准统一下来
运维或负责人在 xaicontrol.com 开一个主账户
在 Admin 中录入自己的第三方 Provider Key，并配置路由规则
在 Manage 中为团队成员、项目或客户创建子账户
所有人继续按统一接口接入，只是实际 Base URL 使用 api.xaicontrol.com

这样做的好处是，前端接入方式几乎不变，后端资源治理却已经完全掌握在自己手里。

玩法 B：完全只用 xaicontrol.com

如果你的目标非常明确，就是“把我自己的第三方 AI API Key 纳入统一管理，然后分发给团队或客户使用”，那么其实完全可以直接从 xaicontrol.com 开始，不必绕路。

这也是 xaicontrol.com 最纯粹、最有力量的用法。

你可以把它理解成一套专门面向 BYOK 的 AI 资源操作系统：

资源来源是你自己的第三方官方 Key
路由、白名单、限速、计量、账单、日志由系统统一处理
下游成员或下游客户不接触原始 Provider Key，只拿自己的 XAI API Key

这一模式下，主账户和子账户的职责会非常清楚：

主账户负责录入第三方 Key、定义策略、管理资源池
子账户负责消费被授权的能力
主账户可以在 Manage 中持续做额度调整、账号增删、权限收缩与用量观察

如果你是下面这些角色，这往往是最直接的选择：

企业内部 AI 平台负责人
需要给客户分发 AI 额度的 SaaS 团队
希望把多个 Provider 统一封装成企业内部标准接口的技术团队
想做项目级、部门级、环境级 AI 资源隔离的开发者

五分钟把 xaicontrol.com 跑起来

下面是一条最短路径，足够让大多数用户真正开始用起来。

第一步：注册主账户

访问 xaicontrol.com 注册。凡是在这里自主注册得到的账号，都可以视为一级主账户。

主账户注册完成后，你会得到自己的 XAI API Key，同时具备进入 Admin 与 Manage 的资格。

第二步：进入 Admin 录入第三方 Provider Key

https://admin.xaicontrol.com
或 https://a.xaicontrol.com

这两个地址是同一个站点。

在这里录入你自己的第三方官方资源，例如：

OpenAI
Anthropic
Gemini
DeepSeek
其他兼容的 Provider

录入之后，你就拥有了自己的私有资源池。

第三步：配置路由与治理规则

仍然在 Admin 中，设置主账户级的规则，例如：

LevelMapper：不同模型走哪个资源池
ModelMapper：把调用模型名映射到实际模型
Resources：限制允许访问的 API 路径
ModelLimits：限制贵模型的速率和用量

这一步的本质，是把“原始密钥”变成“可治理的服务”。

第四步：进入 Manage 创建子账户

https://manage.xaicontrol.com
或 https://m.xaicontrol.com

这两个地址也是同一个站点。

在 Manage 中你可以：

创建子账户
给子账户分配额度
设置模型白名单、IP 白名单、资源白名单
调整速率限制与账单策略
查看日志、用量和后代账单

对于大多数团队来说，到这一步为止，AI 资源已经能真正按组织结构下发了。

第五步：把统一 API Key 分发给成员或系统

这里最重要的一点是：

你分发出去的，不是 OpenAI 或 Anthropic 的原始密钥，而是 XAI 系统分配出来的账户密钥。

因此：

原始 Provider Key 不出主账户治理范围
下游成员只拿到自己可控的访问凭证
额度、权限、模型范围和日志可以独立统计

第六步：把业务接到统一 Base URL

当资源和账户都准备好以后，业务系统只需要面向统一接口调用即可：

export XAI_API_KEY="sk-xxxx"

curl https://api.xaicontrol.com/v1/chat/completions \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.3-codex",
    "messages": [
      {
        "role": "user",
        "content": "你好，请介绍一下你自己。"
      }
    ]
  }'

如果你已经按 OpenAI 兼容方式写过代码，那么迁移成本通常只有一件事：替换 Base URL 与 API Key。

例如在 JavaScript 中：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.XAI_API_KEY,
  baseURL: "https://api.xaicontrol.com/v1",
});

const resp = await client.chat.completions.create({
  model: "gpt-5.3-codex",
  messages: [{ role: "user", content: "hello" }],
});

如果你使用的是 xairouter.com 的在线即用模式，那么同样的代码结构只需要把 Base URL 换成 https://api.xairouter.com/v1。

为什么这套方式更适合团队

很多团队真正缺的不是“再多一个模型入口”，而是一套稳定的资源治理方式。

xaicontrol.com 的价值，恰好就在这里：

密钥不外发：第三方官方 Key 集中托管在主账户治理范围内
权限可继承也可收缩：子账户只能在父账户允许的范围内继续使用
成本更可控：额度、限速、模型范围和账单都能按账户拆开
审计更清楚：谁在什么时间用掉了多少资源，可以回溯
业务接入更统一：研发只面向统一 API，管理侧单独演进

对个人开发者而言，这意味着你终于不用在多家平台的后台之间来回切换。

对团队负责人而言，这意味着你终于可以把 AI 资源像云主机、数据库、对象存储一样进行治理。

对 SaaS 或渠道业务而言，这意味着你不仅能自己使用 AI，还能把 AI 能力变成一套可分发、可计费、可运营的服务。

最后的建议

如果你现在还在验证需求、想尽快跑通统一 AI API，对 xairouter.com 的在线即用模式就足够友好。

如果你已经明确要长期使用自己的第三方 AI API Key，并希望把资源掌握在自己手里，那就直接从 xaicontrol.com 开始。

而当你的目标是“统一接口 + 自有资源 + 团队分发 + 成本治理”同时成立时，xairouter.com + xaicontrol.com 就是最自然的组合方式。

这不是把事情变复杂，而是把本来就存在的复杂性，收拢成一套清晰、稳定、可扩展的系统。