专为 bitFlyer 交易策略打造的 AI 原生运行环境
在 Cursor、Claude Code 或任何 AI IDE 中编写策略。从 GitHub 部署到托管云端运行环境，并享有原生级别的 MCP 控制、日志和区域选择支持。
第 01 部分 · 一览
一览
- 交易平台
- bitFlyer
- 平台类型
- 加密货币交易所（持日本、美国、欧盟牌照）
- 资产类别
- 加密货币（现货、日本 Crypto CFD）
- 支持的产品
- BTC、ETH 及 JPY 交易对的现货交易。仅限日本：Crypto CFD 产品 FX_BTC_JPY（前身为 Lightning FX）。产品可用性因司法管辖区而异；美国和欧盟账户仅能看到日本 product_code 列表的子集。
- 运行环境模式
- 容器化策略运行环境
- 部署源
- GitHub
- 编程语言
- 任何可在容器中运行的语言
- 常用集成
- 原生 bitFlyer Lightning API（REST 和 WebSocket）、CCXT、自定义连接器
- AI 工作流集成
- 适用于 Cursor、Claude Code、GitHub Copilot 及 CLI 智能体的 MCP 控制面板
- TradingHost 角色
- 运行环境、部署、日志、健康检查、区域选择、MCP 控制
- bitFlyer 角色
- 交易所账户、API 访问、市场准入、执行场所
- 关联关系
- TradingHost 保持独立，与 bitFlyer 无任何隶属关系。
第 02 部分 · bitFlyer 平台功能
bitFlyer 平台功能
bitFlyer 在三个司法管辖区（日本、美国、欧盟）提供 BTC、ETH 等交易对的现货交易，以及仅限日本的 Crypto CFD 产品（FX_BTC_JPY）。所有管辖区共享同一个 Lightning API 终端节点 api.bitflyer.com，但其 product_code 映射和产品可用性有所不同。策略通过带有 HMAC-SHA256 签名的三标头（three-header）请求进行身份验证。具体终端节点细节可能会随时间变化。整体架构是稳定的；具体的频率限制权重、手续费等级和产品列表请以 bitFlyer 的官方文档为准。
市场与策略模式
- 日元（JPY）计价的现货策略（BTC_JPY、ETH_JPY）
- 美元计价的现货策略（美国账户）
- 欧元计价的现货策略（欧盟账户）
- 通过 FX_BTC_JPY 运行的日本 Crypto CFD 策略
- 日本 Crypto CFD 的资金费率套利交易
- 在同一账户框架下进行跨司法管辖区的价格套利
- WebSocket 实时市场数据订阅
- 子账户隔离的多策略部署
API 接口
- 产品范围
- BTC、ETH 及其他已上线交易对的现货交易。仅限日本：以 JPY 结算的 Crypto CFD（FX_BTC_JPY，前身为 Lightning FX）。产品可用性受司法管辖区限制；相同的 Lightning API 终端节点服务于所有三个管辖区，但 product_code 映射因账户而异。
- 连接方式
- REST 接口位于 https://api.bitflyer.com/v1/，用于下单、获取市场数据和查询账户。WebSocket 接口通过 lightning.bitflyer.com 终端节点上的 JSON-RPC 2.0 运行，用于获取实时市场数据和私有频道。公共 WebSocket 频道无需身份验证，私有频道则需要。
- 身份验证
- 每个策略需配置 API 密钥（Key）和私钥（Secret）。私有 REST 请求须携带 ACCESS-KEY、ACCESS-TIMESTAMP 和 ACCESS-SIGN 标头。签名为对 时间戳 + HTTP 方法 + 路径 + 请求体 进行 HMAC-SHA256 计算后输出的十六进制字符串。权限按密钥范围划分（读取、交易、提现）。策略绝不需要提现权限。
具体细节请参考 bitFlyer
具体终端节点、频率限制权重、product_code 列表、手续费等级和版本历史均记录在 bitFlyer 的官方文档中。请以此作为权威参考。
第 03 部分 · 用 AI 构建
用 AI 构建您的 bitFlyer 策略
选择一种集成方式，Fork 一个 TradingHost 框架模板，然后在 AI IDE 中编写您的策略。Cursor、Claude Code、GitHub Copilot 以及基于 CLI 的 AI Agent 均可无缝接入相同的 GitHub 原生部署循环。
原生 bitFlyer Lightning API
直接控制 bitFlyer 的特定行为、product_code 映射和订单执行逻辑。
自定义连接器
您自研的内部交易引擎或专有的 bitFlyer 集成方案。
框架对 bitFlyer 产品的支持情况
相比于第一梯队（Tier-1）的交易场所，各大框架对 bitFlyer 的支持较弱。CCXT 通过统一的 bitflyer 类提供 bitFlyer 现货接口，但日本 Crypto CFD 产品并非 CCXT 的原生一等公民（first-class primitive）。Hummingbot 和 Freqtrade 的官方支持交易所列表中均未列出 bitFlyer。通过原生 bitFlyer Lightning API，则可以访问 bitFlyer 在各个司法管辖区提供的所有功能。
✓ 表示官方框架文档确认支持。“no” 表示官方文档未明确说明支持。
TradingHost 不强求特定的框架，它只负责运行您的项目。
使用 AI 编写
上述框架模板与 AI IDE 是绝佳的搭配。TradingHost 的 MCP 控制面实现了闭环：AI 工具可以与您一同检查部署、查看日志并管理运行环境，但绝不会介入交易执行路径。
Section 04 · 在 TradingHost 上运行
在 TradingHost 上运行您的代码
bitFlyer 提供交易所和 API 访问。TradingHost 则提供生产环境，用于运行您连接到 bitFlyer 的策略。
无需在笔记本电脑、台式机、通用 VPS 或手动配置的服务器上运行策略代码，您只需从 GitHub 部署到由 TradingHost 托管的容器运行环境中。
您
- 您的代码库包含您的代码。
- 您的部署定义了其运行方式。
- 您的策略连接到 bitFlyer。
TradingHost
- 保持运行环境持续在线。
- 呈现日志和健康状况检查。
- 区域选择。
- 受控的部署环境。
部署流程
- 步骤 01
连接 GitHub
授权 TradingHost 访问您的 GitHub 帐户。
- 步骤 02
关联代码库或从框架开始
将 TradingHost 指向您现有的策略仓库，或者派生（fork）一个 TradingHost 框架运行环境（CCXT）作为可运行的基础模板。
- 步骤 03
部署至 TradingHost 容器
选择一个区域（EU 或 US-East），提供您策略所需的环境变量（bitFlyer API 密钥和密钥、特定司法管辖区的 product_code 等），然后进行部署。TradingHost 会根据您的代码仓库构建容器，并在托管的 Kubernetes 基础设施上运行您的策略。无需在本地安装 Docker。
- 步骤 04
监控日志与健康状况
通过 TradingHost 控制面板实时查看日志、健康状况和运行状态。该界面同样支持在任何 AI IDE 中通过 MCP 进行访问，方便 Cursor、Claude Code 或 CLI 智能体与您协同读取部署状态并管理运行环境。
- 步骤 05
更新与重新部署
将代码更改推送到 GitHub 的主分支（main branch），TradingHost 便会自动重新部署。
Section 05 · 运维说明
bitFlyer 运维说明
这些是在容器化云端运行环境中实际运行 bitFlyer 策略时可能遇到的隐患，它们既不在 bitFlyer 的文档里，也不在框架的 README 中。以下所有陈述均引用或改写自 bitFlyer 的官方文档；部署方面的指南则源自我们在 TradingHost 上运行这些策略的实际经验。
01 · 共享终端节点
日本、美国和欧盟管辖区共享 api.bitflyer.com，但 product_code 映射不同
bitFlyer 的所有三个司法管辖区（日本、美国、欧盟）均使用相同的 Lightning API 终端节点 https://api.bitflyer.com/v1/。其区别在于 product_code 参数：日本账户可以看到包含 FX_BTC_JPY (Crypto CFD) 在内的完整列表；美国账户只能看到美国持牌子集；欧盟账户只能看到欧盟持牌子集。如果策略针对非日本账户硬编码了仅限日本的 product_code，在提交订单时会返回“产品不可用”错误。请将 product_code 列表作为基于账户管辖区的配置项进行绑定，而不是在代码中写死为常量。
02 · Crypto CFD 更名
FX_BTC_JPY 为当前产品代码；旧版“FX BTC/JPY” Lightning FX 已于 2024 年 3 月停用
bitFlyer 自 2024 年 3 月起将其保证金交易产品 Lightning FX 更名为 Crypto CFD，并将产品代码统一为 FX_BTC_JPY。旧版的 Lightning FX 接口已被弃用；在过渡期内，签名和请求头保持了向后兼容，但目前仍指向旧代码路径的集成会返回产品不可用（product-unavailable）错误。2024 年之前的策略必须迁移到 Crypto CFD 框架下的 FX_BTC_JPY product_code。
03 · 三层频率限制
私有接口每 IP 每 5 分钟 500 次请求；小于 0.1 BTC 的下单每分钟设有限额；每 5 分钟最多 300 次下单/撤单操作
bitFlyer 设有几种不同的频率限制上限：每 IP 结合 API 密钥每 5 分钟 500 次私有请求，小于 0.1 BTC 的订单每分钟限制 100 次下单，以及每 5 分钟 300 次下单/撤单操作。触发小额订单上限的策略通常很快也会触发 5 分钟窗口限制。请根据这些限制的较低者重新调整下单节奏，并使用 WebSocket 获取状态更新，而不是频繁轮询 REST 接口。bitFlyer 文档指出，这些限制“可能会根据系统负载进行更改”，且不保证提前通知。
04 · 三重请求头认证
必须提供 ACCESS-KEY、ACCESS-TIMESTAMP 和 ACCESS-SIGN
bitFlyer 的私有 REST 请求包含三个请求头：ACCESS-KEY（您的 API 密钥）、ACCESS-TIMESTAMP（Unix 时间戳）和 ACCESS-SIGN（时间戳 + HTTP 方法 + 路径 + 请求体的 HMAC-SHA256 签名，使用您的密钥签名，输出为十六进制）。缺少这三者中任何一个的策略都会返回签名错误响应。规范的请求体必须与发送的内容完全一致，包括空格；在签名之前，请使用固定的键顺序对 JSON 进行序列化。
05 · WebSocket 协议
基于 lightning.bitflyer.com 的 JSON-RPC 2.0；私有频道需要单条消息认证，而非连接级认证
bitFlyer Lightning WebSocket 是基于 lightning.bitflyer.com 接口的 JSON-RPC 2.0。公共频道（executions、board、ticker）无需认证。私有频道（子订单、父订单、您账户上的成交记录）需要在连接后发送一条认证消息，将 ACCESS-KEY、ACCESS-TIMESTAMP 和 ACCESS-SIGN 作为 JSON-RPC 参数的一部分。仅在 HTTPS 握手时进行认证而未在 JSON-RPC 请求体中认证的策略，其私有订阅会被静默丢弃。
06 · 密钥权限范围
每个策略使用一个专属权限密钥，切勿在多个策略间共享一个主密钥
bitFlyer API 密钥具有逐项权限范围（读取、交易、提现）。策略绝不需要提现权限；请将具有提现权限的密钥隔离在容器运行环境之外的独立手动管理凭据中。每个策略仅配置其所需的权限，可在密钥泄露时控制波及范围。平台支持 IP 白名单；请将其绑定到您所在地区稳定的运行环境出口 IP 范围内。
Section 06 · 适用场景
适用场景
TradingHost bitFlyer 运行环境最适合用于：
- 在 AI IDE（Cursor、Claude Code）中构建策略的开发者
- 系统化加密货币交易员
- 量化开发者
- 日本、美国和欧盟的 bitFlyer 账户持有人
- CCXT 用户
- 从 VPS 托管转向容器化部署的团队
连接 GitHub 并创建首个策略完全免费。
Section 08 · 常见问题
常见问题
没有。TradingHost 是独立的，与 bitFlyer 没有任何隶属关系。
不会。您的策略代码会根据您自己的逻辑、账户权限和集成方式连接到 bitFlyer 并发送指令。TradingHost 仅提供运行该代码的托管环境。
不提供。bitFlyer API 访问权限由 bitFlyer 提供。您需要自行负责您的 bitFlyer 账户、API 权限、凭据以及对 bitFlyer 条款的合规性。
不是。TradingHost 是运行您策略代码的云端运行环境。我们不提供交易信号、AI 预测模型或预建的机器人。使用 TradingHost，您需要自己编写或生成策略（通常使用 Cursor 或 Claude Code），将其作为您自己的代码保存在 GitHub 中，并使用 TradingHost 在生产环境中运行它。3Commas、Cryptohopper 及类似产品拥有策略逻辑；而 TradingHost 则是运行您自己的策略。
AWS 和 DigitalOcean 为您提供的是基础计算资源。您需要自己处理操作系统更新、容器编排、日志传输、密钥轮换、区域容灾和在线率监控。而 TradingHost 为您提供专为交易策略打造的托管运行环境：开箱即用的 GitHub 原生部署、来自 AI IDE 的 MCP 驱动控制、日志和健康状况监控界面。如果您想自己运营基础设施，AWS 是可行的。如果您希望将运行环境作为一项托管服务，TradingHost 是更快捷的途径。
可以。TradingHost 支持运行 Python 策略；选择与您的技术栈匹配的框架运行环境，或者直接部署您自己的代码仓库。
可以。TradingHost 支持任何可以在容器内运行的语言。
可以。CCXT 通过统一的 `bitflyer` 类提供 bitFlyer 接口，涵盖日本、美国和欧盟管辖区的现货交易。日本的 Crypto CFD 产品（FX_BTC_JPY）并不是 CCXT 原生支持的对象；对于该保证金产品，请直接对接原生的 bitFlyer Lightning API。有关完整的配置说明，请参阅 CCXT 框架运行环境页面。
不可以。日本的 Crypto CFD 产品（FX_BTC_JPY，前身为 Lightning FX）已获得 bitFlyer 日本的许可，且仅对获得日本许可的用户开放。美国和欧盟的 bitFlyer 账户会看到不同的 product_code 映射，无论策略逻辑如何，都无法通过 API 交易 FX_BTC_JPY。需要该产品的策略必须在获得日本许可的 bitFlyer 账户上运行，且运行环境的出口 IP 应与该账户管辖区保持一致。
可以，只要您的项目是这样设计的。您可以在一个运行环境中运行多个策略进程或服务，也可以将它们拆分到不同的运行环境中，以实现隔离和运行清晰度。有关多策略模型的详细信息，请参阅 TradingHost 运行环境页面。
最快的方法是 Fork 一个 TradingHost 框架运行环境：例如用于开箱即用现货项目的 CCXT。或者，如果您针对日本 Crypto CFD 使用原生的 Lightning API，可以直接连接您自己的 GitHub 策略仓库。关联 GitHub 仓库和创建策略是免费的；运行环境方案已列在价格页面上。
保存在您通过 GitHub 控制的机密（Secrets）工作流中。TradingHost 在运行时通过 GitHub 仓库机密、环境机密或您自己批准的机密管理流程来读取它们。TradingHost 不需要托管您的 API 密钥和密钥。有关完整的处理模型，请参阅平台机密说明。
不需要。策略绝不需要提现权限。请使用限定范围的权限（读取、交易），并在适当情况下使用 IP 白名单。
可以。TradingHost 支持针对 AI IDE（包括 Cursor、Claude Code、GitHub Copilot 和基于 CLI 的 AI 智能体）的基于 MCP 的控制。AI 工具可以检查部署、查看日志、重启策略并管理运行环境工作流。MCP 仅作为控制和可观测性界面，绝非交易执行路径。有关完整信息，请参阅 MCP 控制界面说明。
两者皆可。MCP 控制界面在基于 CLI 的智能体（Claude Code CLI、自定义 MCP 客户端、脚本化 MCP 调用）和 IDE 内部同样表现出色。此外，GitHub 原生部署循环在没有任何 AI 工具的情况下也能正常工作：向您的 main 分支进行常规的 git push 即可触发重新部署。
运行时会检测到崩溃并提供相关的日志和健康状态信息。在支持的情况下，受影响的策略可以重新启动，而不会干扰同一容器中运行的其他策略。您的策略代码仍需负责安全错误处理、防重复下单以及风险控制。请参阅可观测性部分以了解日志和健康状态接口。
bitFlyer 的 product_code 映射受到司法管辖区限制。同一个 Lightning API 端点虽然同时服务日本、美国和欧盟用户，但每个司法管辖区可见的可用产品子集不同。无论 API 密钥权限如何，美国或欧盟账户请求 FX_BTC_JPY（仅限日本的 Crypto CFD 产品）都会返回 product-not-available 错误。自 2024 年 3 月更名以来，2024 年之前针对 "Lightning FX" 的策略也必须迁移到 FX_BTC_JPY。请将 product_code 列表固定为以账户司法管辖区为键的配置。请参阅上方的“操作说明”部分以获取完整指南。
TradingHost 在 EU 和 US-East 区域运行。请选择最靠近您策略所依赖的撮合引擎的区域。有关路由和物理距离的详情，请参阅区域页面。
不支持。TradingHost 专注于生产环境的运行时和部署。回测应当在您的研究技术栈、框架或 AlgoBuilder 中进行。