阅读时间 … 分钟

Bitget 交易策略的 AI 原生运行时

在 Cursor、Claude Code 或任何 AI IDE 中编写策略。从 GitHub 部署到托管云端运行时，享有原生 MCP 控制、日志和区域选择支持。

由 TradingHost 工程团队撰写

第 01 部分 · 一览

一览

交易平台
Bitget
平台类型
加密货币交易所（以跟单交易为主导）
资产类别
加密货币（现货、USDT-M 和 coin-M 永续合约、杠杆交易、跟单交易）
支持的产品
现货、USDT-M 永续合约、coin-M 永续合约、USDC-M 永续合约、逐仓和全仓杠杆、基于永续合约的跟单交易。支持通过生产环境 API 进行模拟交易。
运行环境模式
容器化策略运行时
部署源
GitHub
编程语言
任何可在容器中运行的语言
常用集成
原生 Bitget V2 REST 和 WebSocket、CCXT、Hummingbot、自定义连接器
AI 工作流集成
适用于 Cursor、Claude Code、GitHub Copilot 和 CLI 智能体的 MCP 控制面板
TradingHost 角色
运行时、部署、日志、健康检查、区域选择、MCP 控制
Bitget 角色
交易所账户、API 访问、市场接入、执行场所
关联关系
TradingHost 是独立平台，与 Bitget 无任何隶属关系。

第 02 部分 · Bitget 平台功能

Bitget 平台功能

Bitget 通过 REST 和 WebSocket API 提供现货、USDT-M、coin-M 和 USDC-M 永续合约、全仓和逐仓杠杆，以及基于永续合约的跟单交易。策略通过向 V2 API 发送带有 HMAC-SHA256 签名的三标头请求进行身份验证。具体端点可能会随时间变化，但整体架构是稳定的；具体的频率限制权重、手续费等级和交易对列表请参考 Bitget 官方文档。

市场与策略模式

  • USDT-M 永续合约策略
  • Coin-M 和 USDC-M 永续合约策略
  • 跟单交易主账户与跟随账户资金流
  • 永续合约资金费率与基差交易
  • 现货与杠杆策略（全仓或逐仓）
  • 基于子账户隔离的多策略部署
  • WebSocket 私有频道的订单与持仓数据流
  • 在生产环境 API 上通过模拟交易验证的部署

API 接口

产品范围
现货、USDT-M 永续合约、coin-M 永续合约、USDC-M 永续合约、逐仓和全仓杠杆，以及跟单交易的主/从账户层级。模拟交易提供相同的 V2 接口，无需真实资金即可在生产环境 API 上进行验证。
连接方式
使用 REST 进行下单和账户查询。WebSocket 公共频道用于获取行情数据和订单簿更新。WebSocket 私有频道用于接收账户、余额、持仓和订单事件。Bitget V2 是当前最新的 API 版本；虽然旧版 V1 端点仍有文档记录，但新集成应以 V2 为准。
身份验证
每个策略都需要 API key、secret 和 passphrase。私有请求需携带三个标头：ACCESS-KEY、ACCESS-TIMESTAMP 和 ACCESS-SIGN。签名为 timestamp + method + requestPath + body 的 base64 编码 HMAC-SHA256 值。Bitget 会拒绝时间戳偏差超过 30 秒的请求。

具体细节请参考 Bitget

具体端点、频率限制权重、交易对列表、手续费等级和版本历史请参阅 Bitget 官方文档。请以官方文档为准。

第 03 部分 · 用 AI 构建

用 AI 构建您的 Bitget 策略

选择一种集成方式，Fork 一个 TradingHost 框架模板，然后在 AI IDE 中编写您的策略。Cursor、Claude Code、GitHub Copilot 以及基于 CLI 的 AI Agent 均可无缝接入相同的 GitHub 原生部署循环。

  • 原生 Bitget V2 API

    直接控制 Bitget 特有的行为、跟单交易层级和订单执行逻辑。

  • CCXT

    跨 Bitget 和其他加密货币交易所的通用接口。

    开始使用 CCXT

  • Hummingbot

    基于 Hummingbot 策略结构和配置模型的框架化部署。

    开始使用 Hummingbot

  • 自定义连接器

    您自研的交易引擎或专有的 Bitget 集成方案。

框架对 Bitget 产品的支持情况

各框架的支持范围有所不同。CCXT 支持 Bitget 现货和永续合约；Hummingbot 除了现货外，还提供专用的 bitget_perpetual 连接器。目前跟单交易层级只能通过原生 API 处理，尚无框架将其抽象为一等公民。原生 Bitget V2 支持 Bitget 提供的所有功能，包括跟单交易。

框架现货永续杠杆跟单
Native Bitget V2已支持已支持已支持已支持
CCXT已支持已支持部分支持未记录支持
Hummingbot已支持已支持未记录支持未记录支持
Freqtrade未记录支持未记录支持未记录支持未记录支持

✓ 表示官方框架文档确认支持。“no” 表示官方文档未明确说明支持。

TradingHost 不强求特定的框架，它只负责运行您的项目。

使用 AI 编写

上述框架模板与 AI IDE 是绝佳的搭配。TradingHost 的 MCP 控制面实现了闭环：AI 工具可以与您一同检查部署、查看日志并管理运行环境，但绝不会介入交易执行路径。

Section 04 · 在 TradingHost 上运行

在 TradingHost 上运行您的代码

Bitget 提供交易所和 API 访问。TradingHost 则提供生产环境，用于运行您连接到 Bitget 的策略。

无需在笔记本电脑、台式机、通用 VPS 或手动配置的服务器上运行策略代码，您只需从 GitHub 部署到由 TradingHost 托管的容器运行环境中。

您

  • 您的代码库包含您的代码。
  • 您的部署定义了其运行方式。
  • 您的策略连接到 Bitget。

TradingHost

  • 保持运行环境持续在线。
  • 呈现日志和健康状况检查。
  • 区域选择。
  • 受控的部署环境。

部署流程

  1. 步骤 01

    连接 GitHub

    授权 TradingHost 访问您的 GitHub 帐户。

  2. 步骤 02

    关联代码库或从框架开始

    将 TradingHost 指向您现有的策略仓库，或者 fork 一个 TradingHost 框架运行时（CCXT 或 Hummingbot）作为可运行的基础模板。

  3. 步骤 03

    部署至 TradingHost 容器

    选择一个区域（EU 或 US-East），提供策略所需的环境变量（Bitget API key、secret 和 passphrase 等），然后直接部署。TradingHost 会从您的代码仓库构建容器，并在托管的 Kubernetes 基础设施上运行您的策略。您无需在本地安装 Docker。

  4. 步骤 04

    监控日志与健康状况

    通过 TradingHost 控制面板实时查看日志、健康状况和运行状态。该界面同样支持在任何 AI IDE 中通过 MCP 进行访问，方便 Cursor、Claude Code 或 CLI 智能体与您协同读取部署状态并管理运行环境。

  5. 步骤 05

    更新与重新部署

    将代码更改推送到 GitHub 的主分支（main branch），TradingHost 便会自动重新部署。

部署

Section 05 · 运维说明

Bitget 运维说明

这些是在容器化云端运行时中实际运行 Bitget 策略时容易踩到的坑，无论是 Bitget 文档还是框架的 README 中都不会提及。以下所有内容均引用或改编自 Bitget 官方文档；部署相关的指南则源自我们在 TradingHost 上运行这些策略的实际经验。

  1. 01 · 三标头认证

    必须提供 ACCESS-KEY、ACCESS-TIMESTAMP 和 ACCESS-SIGN

    Bitget V2 私有请求携带三个标头：ACCESS-KEY（您的 API key）、ACCESS-TIMESTAMP（当前 Unix 毫秒时间戳）和 ACCESS-SIGN（使用您的 secret key 对 timestamp + method + requestPath + body 进行 HMAC-SHA256 签名并经过 base64 编码的值）。此外，每个签名请求还需要第四个标头 ACCESS-PASSPHRASE。策略如果遗漏这四个标头中的任何一个，都会返回 error 40009 签名无效错误。Passphrase 是在创建密钥时设置的，后续无法检索；如果丢失，唯一的解决办法是重新生成新密钥。

    来源Bitget API signature reference

  2. 02 · 30 秒时间窗口

    ACCESS-TIMESTAMP 超出 30 秒有效窗口将被拒绝

    Bitget 会拒绝任何 ACCESS-TIMESTAMP 与 Bitget 服务器时间相差超过 30 秒的签名请求。如果容器的时钟偏差大于 30 秒，无论签名是否有效，服务器端都会拒绝该签名请求。TradingHost 运行环境采用 NTP 同步，因此 30 秒的容差非常充裕。但如果容器发生时钟偏差（例如在长时间的网络分区之后），则需要先同步时钟，然后才能成功对请求进行签名。

    来源Bitget API signature reference

  3. 03 · V1 到 V2

    V2 是当前的 API 版本；V1 接口虽仍保留在文档中，但不应作为新集成的目标

    Bitget 发布了 V2 API，将现货、USDT-M、coin-M 和跟单交易接口整合在统一的签名方案和基础路径下。虽然 V1 接口仍保留在文档中以兼容旧系统，但更新日志已开始针对 V2 跟踪弃用情况。新策略应直接对接 V2 接口，以免集成代码一上线就面临弃用倒计时。建议在客户端中固定 API 版本，这样未来的 V3 切换将是一次明确的迁移，而不是无声的系统崩溃。

    来源Bitget V2 release notes

  4. 04 · 跟单交易层级

    主账户与跟单子账户继承 stpGroupId；策略需要明确自身运行在主端还是跟单端

    Bitget 的跟单交易持仓会在交易员（主）账户与其跟单者之间继承 stpGroupId。在主账户中运行的策略一旦开仓，就会触发所有关联跟单账户的跟单交易，具体权重取决于跟单者的配置。不希望被跟单的策略必须在非交易员账户上运行，或者在持仓层级明确选择退出。配置错误的主账户波及范围极广，因此采用子账户隔离和单 Key 权限范围限制是正确的风险控制模式。

    来源Bitget API introduction

  5. 05 · 密钥权限范围限制

    每个策略使用独立的专属密钥，切勿跨策略共享主密钥

    Bitget API 密钥支持细粒度的权限范围限制（只读、现货交易、期货交易、提币）。策略绝不需要提币权限；请将具有提币权限的密钥隔离在容器运行环境之外，作为独立的手工管理凭据。为每个策略配置仅包含其所需权限的专属密钥，可以在密钥泄露时控制波及范围。此外，Bitget 还支持为每个密钥设置 IP 白名单；在确定了所选区域的运行环境出口 IP 范围且保持稳定后，请务必进行绑定。

    来源Bitget API introduction

  6. 06 · 模拟交易隔离

    模拟交易共享 V2 接口，但使用独立的密钥和资金账户

    Bitget 的模拟交易与生产环境共享 V2 接口；请求格式完全一致，但密钥集、资金账户和持仓与生产环境完全隔离。一种常见的隐蔽错误是在将通过模拟验证的代码部署到生产环境时忘记更换密钥集，反之亦然。请将模拟环境和生产环境的敏感信息保存在独立的 TradingHost Secrets 条目中，切勿跨环境混用。

    来源Bitget API introduction

Section 06 · 适用场景

适用场景

TradingHost Bitget 运行环境最适合用于：

  • 在 AI IDE（Cursor、Claude Code）中构建策略的开发者
  • 系统化加密货币交易员
  • 量化开发者
  • CCXT 和 Hummingbot 用户
  • 正在从 VPS 托管转向容器化部署的团队

连接 GitHub 并创建首个策略完全免费。

Section 08 · 常见问题

常见问题

没有。TradingHost 是独立的平台，与 Bitget 无任何隶属或合作关系。

不会。您的策略代码会根据您自己的逻辑、账户权限和集成方式连接到 Bitget 并发送指令。TradingHost 仅提供运行该代码的托管环境。

不提供。Bitget API 访问权限由 Bitget 官方提供。您需要自行负责您的 Bitget 账户、API 权限、凭据以及对 Bitget 服务条款的合规性。

不是。TradingHost 是运行您策略代码的云端运行环境。我们不提供交易信号、AI 预测模型或预建的机器人。使用 TradingHost，您需要自己编写或生成策略（通常使用 Cursor 或 Claude Code），将其作为您自己的代码保存在 GitHub 中，然后使用 TradingHost 在生产环境中运行它。3Commas、Cryptohopper 及类似产品提供的是策略逻辑本身，而 TradingHost 则是运行您自己的策略。

AWS 和 DigitalOcean 提供的是原始算力。您需要自己处理操作系统更新、容器编排、日志传输、密钥轮换、区域容灾和可用性监控。而 TradingHost 为您提供专为交易策略打造的托管运行环境：开箱即用的 GitHub 原生部署、源自 AI IDE 的 MCP 驱动控制、以及日志和健康状况监控界面。如果您想自己运维基础设施，AWS 是可行的；如果您希望将运行环境作为托管服务来使用，TradingHost 是更快捷的途径。

可以。TradingHost 支持运行 Python 策略；您可以选择与您的技术栈匹配的框架运行环境，或者直接部署您自己的代码仓库。

可以。TradingHost 支持任何可以在容器内运行的语言。

可以。CCXT 通过统一的 `bitget` 类提供 Bitget 现货和永续合约接口。由于跟单交易接口并非 CCXT 的原生基础组件，因此跟单交易流程需要直接调用原生的 Bitget V2 API。具体配置方法请参阅 CCXT 框架运行环境文档。

TradingHost 在运行环境层层面对交易平台是中立的：任何能够通过 Bitget 身份验证的代码都可以在容器内运行，包括托管在 Bitget 跟单交易主账户上的策略。在设计时您需要考虑到，该策略开启的任何持仓都会触发所有关联跟单账户的跟单交易，具体权重取决于他们的配置。请将符合跟单条件的策略运行在与非公开策略隔离的独立子账户上，并为每个策略隔离 API 密钥，以控制波及范围。

可以，只要您的项目是这样设计的。您可以在同一个运行环境中运行多个策略进程或服务，也可以将它们拆分到不同的运行环境中，以实现隔离和清晰的运维管理。多策略模式的具体说明请参阅 TradingHost 运行环境页面。

最快的方法是 Fork 一个 TradingHost 框架运行环境：选择 CCXT 或 Hummingbot 即可获得开箱即用的项目。或者，您也可以直接连接自己的 GitHub 策略仓库。关联 GitHub 仓库和创建策略是免费的；运行环境方案详见价格页面。

保存在由您通过 GitHub 控制的敏感信息（Secrets）工作流中。TradingHost 在运行时通过 GitHub 仓库 Secrets、环境 Secrets 或您自己认可的密钥管理流程读取它们。TradingHost 不需要托管您的 API 密钥、私钥和密码（passphrase）。完整处理模式请参阅平台 Secrets 说明。

不需要。策略绝不应该需要提币权限。请使用受限的权限范围（只读、现货交易、期货交易），并在适用时启用 IP 白名单。

可以。TradingHost 支持针对 AI IDE 的基于 MCP 的控制，包括 Cursor、Claude Code、GitHub Copilot 以及基于 CLI 的 AI 智能体。AI 工具可以检查部署、查看日志、重启策略并管理运行环境工作流。需要注意的是，MCP 是控制和可观测性界面，而非交易执行路径。完整架构请参阅 MCP 控制界面说明。

两者皆可。MCP 控制界面在基于 CLI 的智能体（Claude Code CLI、自定义 MCP 客户端、脚本化 MCP 调用）和 IDE 内部同样表现出色。此外，GitHub 原生部署循环在不使用任何 AI 工具的情况下也能正常工作：只需向您的 main 分支进行常规的 git push 即可触发重新部署。

运行环境会检测到崩溃，并展示相关的日志和健康状况信息。在支持的情况下，受影响的策略可以重新启动，而不会干扰在同一个容器中运行的其他策略。您的策略代码仍需自行负责安全错误处理、防重复下单保护和风险控制。日志和健康状况界面详见可观测性说明。

Bitget 40009 错误意味着您的策略发送的签名与预期的 HMAC-SHA256（由 timestamp + method + requestPath + body 拼接并使用您的 secret 签名）不匹配。常见原因包括：缺失或错误的 ACCESS-PASSPHRASE 请求头、ACCESS-TIMESTAMP 超出了 30 秒的有效时间窗口、使用了错误的 secret（测试网密钥与生产网密钥混淆），或者对错误的规范请求体进行了签名（例如多余的空格、键值对顺序重排）。建议锁定经过实战检验的 SDK，或对照 Bitget 签名参考文档对签名路径进行单元测试。完整指南请参阅上方的“运行注意事项”部分。

TradingHost 在 EU 和 US-East 区域运行。请选择最靠近您策略所依赖的撮合引擎的区域。请参阅区域页面以获取路由和物理距离详情。

不支持。TradingHost 专注于生产环境的运行和部署。回测应当在您的研究技术栈、开发框架或 AlgoBuilder 中进行。