EQVPS

用 API 和 MCP 自动化你的 VPS 分销生意

2026年9月5日 · 1 分钟阅读 · EQVPS Team

靠手工运行的分销生意很快撞上天花板:每一笔下单、每一次暂停、每一次续费都是一个人在面板里点击,而你的时间随客户数增长。越过这道天花板的办法是把运营当作代码来跑——而 EQVPS 通过 REST API 和一个 MCP 端点同时暴露分销一侧,于是你可以脚本化它,或把它交给一个 AI 代理。

一个令牌,30 个分销工具

你在 Partners 后台获取一个分销令牌rk_…),并作为 Authorization: Bearer rk_… 发送。该令牌按角色过滤:它在同一个 MCP 端点上开放 30 个 reseller_* 工具,覆盖完整的客户生命周期:

下单一台服务器不再是一次面板操作,而成为一次经过鉴权的调用。

API 或 MCP —— 同样的能力,两扇门

它们不是相互竞争的选项;它们是通往同一组工具的两个入口:

多数分销商两者都用:一个通过 REST 部署的计费 webhook,加上一个通过 MCP 处理更棘手判断的代理。

护城河:一个运营整个生意的代理

这就是它不再像其他任何分销方案的地方。因为分销工具在 MCP 上,一个用你的 rk_ 令牌鉴权的 AI 代理可以直接运营这门生意——在客户付款时下单 VM、读取状态、在欠费时暂停、在结清时恢复——无需人在环中。同一个代理能购买并运行自己服务器的平台,让代理能替你的客户运营一个机群。你设定策略;代理执行它。这就是作为具体范式的由 AI 运营的主机生意

一个最小流程

// 用你的分销令牌为每次调用鉴权
// Authorization: Bearer rk_...

reseller_order_for_client({ client_id, product: "small", os_id: 1 })  // 以你的品牌部署
// → service_id、ip、访问方式 —— 作为你自己的交付给客户
reseller_suspend_client({ service_id })       // 欠费时
reseller_unsuspend_client({ service_id })      // 结清时

四次调用,替代了以往每客户、每事件都要来一次的面板操作。

诚实的边界

下一步去哪

完整参考——鉴权、reseller_* 工具、os_id 处理与状态——见分销 API / MCP 文档。刚接触生意一侧?从如何开启 VPS 分销生意开始。批发一侧是白标分销方案

常见问题

作为分销商,我如何自动化部署?

你在 Partners 后台获取一个分销令牌(rk_…),并用它调用同一个 MCP 端点(或 REST API)。该令牌按角色过滤:它开放 30 个 reseller_* 工具,覆盖完整的客户生命周期——创建套餐、添加客户、为其下单 VM、读取状态、暂停、恢复、续费、取消。为客户下单一台服务器,从一次面板操作变成一次经过鉴权的调用。

这里 API 和 MCP 有什么区别?

同样的能力,两扇门。REST API 是你从自己的后端或计费系统里脚本化调用的。MCP 端点把同样的 reseller_* 工具暴露给 AI 代理或支持 MCP 的客户端,于是模型可以直接操作它们。你可以用其一或两者——一个通过 REST 部署的计费 webhook,加上一个通过 MCP 处理其余部分的代理。

AI 代理真的能跑下单和暂停吗?

能——这正是 MCP 面存在的意义。因为分销工具暴露给了 MCP,一个用你的 rk_ 令牌鉴权的代理可以在客户付款时下单 VM、读取其状态、在欠费时暂停、在结清时恢复,全程无需人点击面板。你设定策略;代理执行它。

我的分销访问如何鉴权与限定范围?

用一个分销令牌(rk_…),作为 Authorization: Bearer rk_… 发送。它按角色只过滤到 reseller_* 工具,所以它操作的是你的客户和你的套餐,而非整个平台。像对待任何凭据一样保密该令牌;它是你整个客户机群的钥匙。

我必须一次性自动化一切吗?

不必。先从面板部署开始,随着增长把最高频的动作移到 API——通常先是付款即下单和欠费即暂停。要点在于:一旦这两项自动化,运营投入就不再随客户数增长,而这正是让庞大的分销账目盈利的关键。

← 返回博客查看套餐与价格 →

评论

暂无评论。来做第一个吧。

发表评论

评论在显示前会经过审核。