Bitfinex借贷自动化机器人：本地运行、API实现利率挂单与续约管理

这次我们来看一个 Bitfinex 借贷自动化项目。它的定位在标题里写得很清楚：运行在 PC 上，而不是服务器上。翻译成大白话就是，不需要为了跑一个利率借贷机器人去单独买 VPS、配置 Docker、维护 systemd，日常使用的 Windows、macOS 或者 Linux 电脑就可以常驻运行，通过 Bitfinex 官方 API 自动完成资金借贷订单的管理。

Bitfinex 的 Lending 本质上是一个 P2P 借贷市场，手里有 USD、USDT、BTC 等资产的人可以把资金借出，赚取借款方支付的利息。问题在于，这个市场是动态变化的：利率波动的窗口很短，订单到期之后需要手动续约，多币种同时管理时，人工操作成本更高。自动化脚本的价值就是把“盯盘、挂单、续约、重新报价”这些重复动作接管过来，并且按照预设的利率区间持续执行。

这个项目有几个核心特点值得先说清楚：

• 本地运行，不需要额外服务器资源。
• 通过 Bitfinex 官方 API 操作，不是网页自动化或者模拟点击。
• 面向利率借贷场景，重点是自动挂单、自动续约、仓位管理。
• 支持多币种、多策略批量任务。
• API 密钥保存在本地，不经过第三方平台代管。

这篇文章会围绕这个项目展开，完整梳理它的适用范围、环境准备、本地部署流程、功能验证方法、API 调用方式、资源占用情况，以及常见报错和排查思路。不管是准备直接部署，还是想参考它的设计思路，这篇文章都可以直接收藏。

1. 核心能力速览

从能力面上看，这个项目不是那种重型的量化交易系统，不需要高频撮合，也不需要复杂的回测框架。它的核心价值是替代手工操作，把借贷订单的维护频率从“每天多次手动点击”变成“后台脚本自动执行”。

如果你已经有 Bitfinex 账户，并且熟悉 API Key 的权限概念，那这个项目的上手门槛不算高。如果你还没有接触过交易所 API，这篇文章也会把最容易出错的权限配置和验证方式拆开讲。

2. 适用场景与使用边界

这个项目适合哪类人？首先是已经持有 Bitfinex 可借资产的用户，比如手上有 USD、USDT、BTC 并且愿意通过借贷市场获取利息。其次是注重密钥安全的人，因为脚本跑在本地，API Key 不需要托管给第三方平台，只要自己不泄露，密钥就只存在于本机配置文件和运行内存中。另外，对自动化交易感兴趣的技术爱好者也可以把它当作一个非常完整的 API 调用案例来学习。

不太适合的场景也要说明白。如果你完全不了解 Bitfinex 的借贷规则、不明白什么是“最低利率”“到期自动续约”，也不清楚借贷订单的资金占用逻辑，建议先把平台规则搞清楚再跑自动化。另外，这个项目不负责预测行情，也不会规避利率下降造成的利息损失，它只负责“按你设定的策略执行”。

这里必须强调使用边界：

1. 借贷有市场风险。利率会波动，可能出现很长一段时间利率低于预期；借出资产期间，市场行情发生极端变化时，也可能影响资金灵活性。
2. 自动化不改变风险。脚本只能提高执行效率，不能消除市场波动和平台规则调整带来的风险。
3. API 密钥安全。密钥一旦泄露，外部调用者可以读取你的账户信息，甚至在权限允许的情况下提交订单。部署时必须把密钥保护好。
4. 合规问题。不同地区对加密货币交易和借贷有不同的监管要求，使用者需要自己判断所在地区的合规边界。
5. 不要用这个项目去尝试任何绕过平台风控、刷单、操纵利率等违规操作。自动化借贷只能在平台规则允许的范围内运行。

一句话总结：这个项目适合“已经想清楚要参与 Bitfinex 借贷、并且希望用技术手段减少手工操作”的用户，不适合把自动化当成无风险赚钱工具的人。

3. 环境准备与前置条件

从项目标题看，它选择在 PC 上运行，而不是部署到服务器，这本身就说明它对运行环境的要求不会太高。但“门槛低”不等于“不用准备”，实际操作前还是要先把环境理清楚。

3.1 操作系统

Windows、macOS、Linux 都可以考虑。重点不是系统类型，而是系统能不能稳定运行 Python 脚本并保持长时间在线。笔记本如果经常休眠，机器人也会跟着休眠，这个要注意。

3.2 Bitfinex 账户与 API Key

这是整个部署里最关键的一步。到 Bitfinex 官网登录账户，进入 API 管理页面，创建一个新的 API Key。创建时有几个权限选项，建议按最小权限原则勾选：

• 读取账户信息（读钱包、读订单）
• 提交订单 / 修改订单

如果项目只做借贷，通常不需要提现权限，也不需要“转账”权限。绝对不要把“提现”权限打开。

另外，Bitfinex 的 API 支持 IP 白名单。如果本机出口 IP 是固定的，可以配置白名单；如果 IP 经常变化，例如家庭宽带重新拨号后会变，开启白名单可能导致脚本突然无法访问 API。这个要根据实际网络环境取舍。

3.3 网络环境

脚本需要持续访问 Bitfinex API，因此要求本机网络稳定。如果网络经常断线，脚本需要具备断线重连机制；如果没有断线重连，至少要让脚本在异常退出后能被 supervisor 或系统任务计划重新拉起。

3.4 Python 运行环境

参考大多数本地自动化脚本的常见实现，通常需要 Python 3.10 及以上，具体版本要看项目 README 或 requirements.txt。安装完成后先确认版本：

python --version pip --version

Python 环境可以使用系统自带版本，也可以使用 Anaconda、Miniconda 管理，但更推荐项目内创建虚拟环境，避免依赖互相污染。

3.5 依赖安装

假设项目已经下载到本地，进入项目目录后创建虚拟环境并安装依赖：

git clone <项目仓库地址> cd <项目目录> python -m venv .venv source .venv/bin/activate # Windows 下激活虚拟环境命令不同： # .venv\Scripts\activate pip install -r requirements.txt

注意：上面的命令是通用模板，实际仓库地址和项目目录名称要以该项目的 README 为准。如果项目使用 Poetry 或 pipenv 管理依赖，安装方式也要相应调整。

3.6 配置文件

这类自动化脚本通常会把 API Key、API Secret、策略参数放在配置文件中。常见做法是放一个.env文件，或者config.yaml/config.json。下面是一个通用的配置模板，需要根据项目实际情况修改：

# .env 示例，不要提交到版本库 BITFINEX_API_KEY=你的APIKey BITFINEX_API_SECRET=你的APISecret

# config.yaml 示例 lending: symbols: - USD - USDT - BTC min_rate: 0.0001 max_rate: 0.001 amount_per_order: 100 renew: true dry_run: true

配置文件的字段名不一定和这个项目完全一致，但它要表达的核心逻辑是共通的：告诉机器人“操作哪些币种、利率范围是多少、单笔委托金额多大、是否自动续约、是否先跑模拟模式”。

4. 安装部署与启动方式

部署思路分成四步：获取代码、配置密钥、启动脚本、确认运行状态。下面按这个顺序展开。

4.1 获取项目代码

从项目发布页或者仓库地址获取代码。如果是发布在 Hacker News 上的 Show HN 项目，作者通常会附带 GitHub 仓库或者 Release 包下载链接。下载后解压到本地目录，比如D:\bitfinex-lending-bot或者~/code/bitfinex-lending。

4.2 配置 API 密钥和策略参数

把 API Key 和 Secret 写入配置文件。这里有两个注意点：

1. 不要把密钥写死到代码里。
2. 不要提交到 Git 仓库。如果项目本身有.gitignore，确认配置文件名是否已被忽略。

4.3 启动脚本

启动方式取决于项目的入口文件。常见入口文件是main.py、run.py、bot.py，也可能项目作者封装了一个启动脚本。通用命令如下：

# 激活虚拟环境之后执行 python main.py # 如果项目支持指定配置文件 python main.py --config config.yaml # 如果项目支持 dry-run 试运行 python main.py --dry-run

启动后，控制台应该会输出日志，例如“API connection established”“Loaded lending strategies”“No active orders, submitting new order”等。如果出现 401、403、签名错误之类的信息，说明 API Key 配置有问题，不要继续放大资金。

4.4 后台运行

要让脚本在 PC 上长时间运行，可以把它放到后台，或者挂到进程守护工具里。

Linux/macOS 上可以用nohup简单挂起：

nohup python main.py > bot.log 2>&1 &

Windows 上可以用任务计划程序，设置开机自动运行，也可以使用 supervisor 这类工具统一管理进程。以下是 Linux 下 systemd 服务文件的通用模板，路径和命令请按实际项目调整：

[Unit] Description=Bitfinex Lending Bot After=network.target [Service] WorkingDirectory=/home/user/bitfinex-lending ExecStart=/home/user/bitfinex-lending/.venv/bin/python main.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

4.5 验证启动状态

启动之后不要马上离开，先观察至少两轮策略循环。确认以下几点：

• API 请求没有报错。
• 日志里能看到币种列表和策略参数。
• 如果开了 dry-run，能看到“模拟提交订单”的日志。
• 如果下了真实订单，去 Bitfinex 平台的订单列表或 Lending 页面确认状态。

确认这些之后，再考虑让脚本常驻。

5. 功能测试与效果验证

很多自动化脚本第一次跑失败，原因不是代码问题，而是测试步骤没做全。这个项目也一样。建议按下面的顺序逐步验证。

5.1 验证 API 连接和账户读取

目的：确认 API Key 和 Secret 能被服务端接受，并且有权限读取账户信息。

如果没有现成的脚本命令，可以用 curl 先做一次只读接口测试。Bitfinex 的 REST API 公开端点可以直接访问，认证端点需要签名。下面是一个公开 ticker 的简单示例：

curl -s "https://api.bitfinex.com/v2/tickers?symbols=tBTCUSD" | head -c 500

如果返回结果是 JSON 数组，说明网络到 Bitfinex API 是通的。账号相关接口需要按 Bitfinex 官方文档生成签名，这里不做展开。

更稳妥的做法是使用项目自带的自检命令。很多这类工具会提供--check或--test参数。如果项目没有，可以在配置好 API Key 后先执行一个只读脚本，请求钱包余额接口，看返回内容是否正确。

判断标准：

• HTTP 状态码 200。
• 返回体包含账户钱包数据，而不是 401/403 错误。
• 余额数据与平台页面显示一致。

5.2 验证利率获取

目的：确认脚本能拿到当前借贷市场利率，并且策略能够基于真实行情计算订单价格。

从项目日志或者调试模式里，应该能看到类似“current rate: 0.00023”或者“best rate: 0.0002”的输出。如果没有日志，可以在项目中增加临时print输出，或者用独立的 API 脚本拉取一次最新行情。

判断标准：

• 拉到的利率不是 0，也不是空值。
• 不同币种的利率存在差异。
• 脚本计算的委托利率在配置文件设定的 min_rate 和 max_rate 范围内。

5.3 dry-run 模拟下单

目的：不真实提交订单，只验证订单参数和账户资金是否满足要求。

python main.py --dry-run

如果 dry-run 模式下日志输出“submit lend order: symbol=USD, amount=100, rate=0.0002”，说明订单参数已经生成正确。此时可以对比平台上的账户可用余额，确认账户真的有钱可以借出。

常见失败原因：

• 配置里的 symbol 写错，例如写了USDT但平台借贷市场里叫UST。
• 账户余额不足。
• 平台限制了该资产的借贷，或者该资产在借贷市场不可用。

5.4 小额真实订单

目的：用最小金额走通真实流程。

建议先用最小可借金额，比如 1 USD 或 1 USDT 做一次真实挂单。观察订单是否出现在 Bitfinex 的 Lending 页面，记录从脚本提交到平台确认的耗时。如果订单成功挂出，再逐步放大金额。

判断标准：

• 平台页面出现活动订单。
• 订单状态为 ACTIVE。
• 脚本日志中订单 ID 和平台订单 ID 对应。

5.5 批量任务测试

多币种配置是这个项目的重要卖点。在配置文件中同时配置 USD、USDT、BTC 三到四种资产，启动后确认每个币种都有独立策略循环。

判断标准：

• 每个 symbol 都有日志输出。
• 每个 symbol 的订单金额、利率来自独立配置。
• 某个 symbol 失败时，不影响其他 symbol 运行。

如果项目没有内置批量任务能力，只能同时运行一个数据的 token 循环，那批量配置的意义就不大，需要看 README 是否支持多进程或多配置实例。这个时候可以尝试同时启动多个配置文件副本，但要注意 API 请求频率是否触发 Bitfinex 限频。

6. 接口 API 与批量任务

这个项目虽然是一个“PC 程序”，但它背后必须依赖 Bitfinex API。理解 API 交互方式，既能帮你判断项目是否可靠，也能在出问题时更快定位。

6.1 Bitfinex API 调用示例

公开市场数据接口可以不带签名访问，例如获取最近成交：

curl -s "https://api.bitfinex.com/v2/tickers?symbols=tBTCUSD"

认证接口需要 API Key、API Secret、签名、时间戳等信息。具体签名逻辑需要看 Bitfinex 官方文档。下面的 Python 示例只展示请求结构，不展开复杂签名细节，实际实现请以官方文档为准：

import hashlib import hmac import time import requests API_KEY = "your_api_key" API_SECRET = "your_api_secret" base_url = "https://api.bitfinex.com" path = "/v2/auth/r/wallets" body = {} nonce = str(int(time.time() * 1000)) raw = f"/api{path}{nonce}{json_body}" signature = hmac.new( API_SECRET.encode(), raw.encode(), hashlib.sha384 ).hexdigest() headers = { "bfx-nonce": nonce, "bfx-apikey": API_KEY, "bfx-signature": signature, "Content-Type": "application/json", } response = requests.post( f"{base_url}{path}", headers=headers, json=body, timeout=30, ) print(response.json())

注意：这段代码只是为了让读者理解请求的组成结构，不是可以直接照抄的完整实现。实际项目里，作者通常已经封装好这些签名逻辑，不需要使用方自己再写一遍。但如果要调试问题，理解这个流程会很有帮助。

6.2 批量任务的实现思路

借贷自动化中的“批量”通常分两层：

第一层是批量管理多个币种。每个币种有独立的最小利率、最大利率、单笔金额和续约策略。实现上可以用一个字典结构保存：

strategies = { "USD": {"min_rate": 0.0001, "max_rate": 0.001, "amount": 500}, "USDT": {"min_rate": 0.0002, "max_rate": 0.002, "amount": 300}, "BTC": {"min_rate": 0.00001, "max_rate": 0.0001, "amount": 0.01}, }

第二层是每个币种内部循环执行。循环里做三件事：

1. 获取当前账户余额和活动订单。
2. 对比配置策略，决定是否撤单、改价、新下订单。
3. 把每轮操作写入日志，避免重复下单。

这个是通用的批量轮询框架。实际项目中，如果作者没有实现完善的批量任务，你可以把每个币种当作一个独立配置实例运行，但要注意多个实例同时跑可能导致重复下单，需要加锁或者限制实例数量。

6.3 失败重试与幂等性

自动化脚本长期运行时最怕“重复执行”。比如订单提交后网络超时，你以为失败了，实际平台已经接受了订单，如果再提交一次就会变成双倍挂单。

合理的处理方式是在日志中记录每个订单的“订单ID + symbol + amount + rate”，每次生成新订单前先查询活动订单，如果同参数订单已经存在，就跳过提交步骤。这样可以降低重复下单的概率。

# 伪代码示例：提交前检查活动订单 active_orders = get_active_lend_orders(symbol) for order in active_orders: if order.amount == target_amount and order.rate == target_rate: print("order already exists, skip") return submit_lend_order(symbol, target_amount, target_rate)

这种幂等设计在批量任务里非常重要。

7. 资源占用与性能观察

项目选择运行在 PC 上，而不是服务器上，这个前提决定了它的资源占用不会很高。但资源占用仍然值得观察，尤其是长时间运行时。

7.1 CPU 占用

借贷自动化的核心操作是轮询 API、比较利率、判断订单状态。这不是计算密集型任务，CPU 占用应该非常低。如果脚本出现 CPU 长时间飙高，大概率是代码里出现了密集的循环或者死循环，也可能是日志打印太频繁导致 IO 压力增大。

观察方式：在 Linux 下使用top或htop，在 Windows 下打开任务管理器，找到对应的 Python 进程，观察 CPU 占用率。正常情况下应该低于 5%。

7.2 内存占用

内存占用取决于项目依赖和日志缓冲策略。纯 API 轮询脚本通常占用很小，几十到几百 MB 都是正常范围。如果进程内存一直在持续增长，说明可能有内存泄漏，需要定时重启实例，或者检查日志对象是否被无限累积。

7.3 网络与 API 频率

这是最需要关注的点。交易所 API 一般都有速率限制。如果轮询间隔太短，比如每秒一次，很容易触发限频，导致 API 返回 429 或 403。保守做法是轮询间隔至少 15 到 30 秒，关键操作如下单、撤单的频率要更低。

判断标准：

• 日志里不出现 Rate Limit 类报错。
• API 返回的 HTTP 状态码全部正常。
• 单日请求量在可控范围内。

7.4 长时间稳定性

PC 和服务器在稳定性上的差异集中在电源、网络、系统休眠三个方面：

• 电源：PC 不能断电，需要搭配 UPS 或者接受断电带来的停机。
• 网络：家庭宽带的公网稳定性通常不如机房，断线后要能自动重连。
• 休眠：笔记本合盖默认会睡眠，机器人会随之暂停。需要修改电源计划，设置为合盖不睡眠。

如果出现“脚本还在跑但好久不下单”的情况，第一件事不是看代码，而是确认系统有没有进入睡眠、网络有没有断线、API Key 是否过期。

8. 常见问题与排查方法

自动化脚本跑起来之后，大概率会遇到下面这些问题。按表格逐个排查，效率会高很多。

排查有一个通用顺序：先看网络，再看认证，再看权限，最后看参数。不要一上来就改代码。绝大多数自动化任务“第一晚上正常、第二天早上报错”都和网络、系统休眠、时间同步有关，而不是策略逻辑问题。

9. 最佳实践与使用建议

把自动化脚本稳定跑起来只是第一步，长期安全运行还需要完善的工程化习惯。下面这些建议值得在部署前就做掉。

9.1 第一次先小参数、dry-run 测试

无论项目作者宣称功能多完善，第一次运行都必须用 dry-run 模式或者最小金额真实测试。先跑通流程，再慢慢放大金额。不要第一天就直接上大额资金。

9.2 API Key 权限最小化

给自动化脚本用的 API Key 只开必要权限。理想情况是：允许读取余额和活动订单，允许提交和取消借贷订单，不开提现权限。如果平台支持子账户，尽量为机器人单独创建一个子账户，与主账户资金隔离。

9.3 不把密钥放到公开仓库

.env、config.yaml、config.json这类文件一旦包含密钥，就必须加入.gitignore。不要因为项目是个人使用就不注意这一点。即使仓库是私有的，也要防止未来误改可见性导致密钥泄露。

9.4 日志要分目录管理

把输入素材、日志、订单记录分开存放。日志建议按日期切分，保留至少 7 天，方便出问题时回溯。订单记录尤其重要，因为借贷订单历史直接对应当前资金状态，如果脚本崩溃，需要靠订单记录来人工确认哪些单已经提交。

bitfinex-lending/ ├── .venv/ ├── src/ ├── config/ │ └── config.yaml ├── logs/ │ └── 2025-01-01.log └── orders/ └── 2025-01-01_orders.json

9.5 添加通知机制

脚本长期运行，不可能每次都在电脑前盯日志。建议在关键动作发生时发送通知，可以是 Telegram Bot、Server 酱、邮件或者企业微信机器人。通知触发条件建议包含：

• 新订单提交成功。
• 订单被外部取消或利率变化。
• 连续多轮 API 请求失败。
• 脚本异常退出。

通知不是必须的，但它能让“PC 本地运行”的可靠性上一个大台阶，毕竟本地 PC 无人值守出问题后，需要及时收到报警。

9.6 策略参数要小步调整

不要频繁大幅修改利率范围。每改一次参数，至少要观察 24 小时，记录实际成交利率和资金利用率，再判断调整是否有效。频繁修改会让订单状态不稳定，而且你自己也分不清收益变化到底来自市场还是策略调整。

9.7 关注平台规则和借贷市场变化

Bitfinex 的借贷规则、可借资产列表、API 权限策略都可能变化。自动化脚本上线后，不代表可以一直不管。每周检查一次平台公告，确保脚本逻辑没有和最新规则脱节。

9.8 合规和数据安全

如果要把这个项目分享给别人，或者做成商业化产品，必须提醒使用者关于 API 密钥安全、平台规则合规、当地监管要求等问题。不要把工具包装成“稳定盈利机器人”，借贷利率本身存在很大波动性，自动化只是提高了执行效率，不改变收益曲线。

10. 总结与下一步

这个项目最值得尝试的点在于：很多类似任务默认要跑到服务器上，但它选择在 PC 本地运行，门槛更低，密钥也不经过第三方。对于已经参与 Bitfinex 借贷、但还靠手工挂单续约的用户来说，它确实能省下不少重复操作。

部署之后，第一个要验证的永远是 API Key 权限。读余额、下单、取消订单这三项跑通，整个流程就顺畅了。最容易被低估的坑是本地 PC 的睡眠策略和网络稳定性，建议部署前先处理这两项。

下一步可以考虑的方向：

• 加通知功能，订单成交或异常时推送到手机。
• 加历史收益统计，用数据库记录每次订单的成交利率和实际收益。
• 加多策略回测，用历史利率数据验证不同利率区间的收益表现。
• 如果项目本身缺少 Web 面板，可以单独开发一个可视化页面，展示当前订单、账户余额、利率曲线。
• 如果资金量变大，再考虑把运行环境迁移到 7x24 的小型服务器，这时候可以沿用同样的代码，只是换一个承载环境。

把 PC 本地自动化跑明白，再把同样的接口逻辑迁移到服务器，是非常顺畅的技术路径。这个项目虽然小，但把 API 调用、策略配置、批量任务、日志排查这些工程细节都串起来了，值得动手试一次。