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

这次我们来看一个 Bitfinex 借贷自动化项目。它的定位在标题里写得很清楚运行在 PC 上而不是服务器上。翻译成大白话就是不需要为了跑一个利率借贷机器人去单独买 VPS、配置 Docker、维护 systemd日常使用的 Windows、macOS 或者 Linux 电脑就可以常驻运行通过 Bitfinex 官方 API 自动完成资金借贷订单的管理。Bitfinex 的 Lending 本质上是一个 P2P 借贷市场手里有 USD、USDT、BTC 等资产的人可以把资金借出赚取借款方支付的利息。问题在于这个市场是动态变化的利率波动的窗口很短订单到期之后需要手动续约多币种同时管理时人工操作成本更高。自动化脚本的价值就是把“盯盘、挂单、续约、重新报价”这些重复动作接管过来并且按照预设的利率区间持续执行。这个项目有几个核心特点值得先说清楚本地运行不需要额外服务器资源。通过 Bitfinex 官方 API 操作不是网页自动化或者模拟点击。面向利率借贷场景重点是自动挂单、自动续约、仓位管理。支持多币种、多策略批量任务。API 密钥保存在本地不经过第三方平台代管。这篇文章会围绕这个项目展开完整梳理它的适用范围、环境准备、本地部署流程、功能验证方法、API 调用方式、资源占用情况以及常见报错和排查思路。不管是准备直接部署还是想参考它的设计思路这篇文章都可以直接收藏。1. 核心能力速览能力项说明项目类型Bitfinex 利率借贷自动化脚本 / 机器人运行形态本地 PC 常驻任务非服务器部署对接平台Bitfinex通过官方 REST / WebSocket API主要功能自动借贷报价、订单续约、资金分配、多币种管理支持资产Bitfinex Lending 市场支持的可借资产以平台实际列表为准硬件要求普通 PC、笔记本、低功耗小主机均可依赖环境Python 环境及项目依赖包具体版本以 README 为准是否支持 API是依赖 Bitfinex API部分版本可能自带 Web 面板是否支持批量任务支持多币种批量配置具体策略数量以项目实现为准启动方式命令行启动一般不需要图形界面适合场景个人资金借贷管理、小规模费率策略、API 集成学习从能力面上看这个项目不是那种重型的量化交易系统不需要高频撮合也不需要复杂的回测框架。它的核心价值是替代手工操作把借贷订单的维护频率从“每天多次手动点击”变成“后台脚本自动执行”。如果你已经有 Bitfinex 账户并且熟悉 API Key 的权限概念那这个项目的上手门槛不算高。如果你还没有接触过交易所 API这篇文章也会把最容易出错的权限配置和验证方式拆开讲。2. 适用场景与使用边界这个项目适合哪类人首先是已经持有 Bitfinex 可借资产的用户比如手上有 USD、USDT、BTC 并且愿意通过借贷市场获取利息。其次是注重密钥安全的人因为脚本跑在本地API Key 不需要托管给第三方平台只要自己不泄露密钥就只存在于本机配置文件和运行内存中。另外对自动化交易感兴趣的技术爱好者也可以把它当作一个非常完整的 API 调用案例来学习。不太适合的场景也要说明白。如果你完全不了解 Bitfinex 的借贷规则、不明白什么是“最低利率”“到期自动续约”也不清楚借贷订单的资金占用逻辑建议先把平台规则搞清楚再跑自动化。另外这个项目不负责预测行情也不会规避利率下降造成的利息损失它只负责“按你设定的策略执行”。这里必须强调使用边界借贷有市场风险。利率会波动可能出现很长一段时间利率低于预期借出资产期间市场行情发生极端变化时也可能影响资金灵活性。自动化不改变风险。脚本只能提高执行效率不能消除市场波动和平台规则调整带来的风险。API 密钥安全。密钥一旦泄露外部调用者可以读取你的账户信息甚至在权限允许的情况下提交订单。部署时必须把密钥保护好。合规问题。不同地区对加密货币交易和借贷有不同的监管要求使用者需要自己判断所在地区的合规边界。不要用这个项目去尝试任何绕过平台风控、刷单、操纵利率等违规操作。自动化借贷只能在平台规则允许的范围内运行。一句话总结这个项目适合“已经想清楚要参与 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 --versionPython 环境可以使用系统自带版本也可以使用 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 写入配置文件。这里有两个注意点不要把密钥写死到代码里。不要提交到 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 21 Windows 上可以用任务计划程序设置开机自动运行也可以使用 supervisor 这类工具统一管理进程。以下是 Linux 下 systemd 服务文件的通用模板路径和命令请按实际项目调整[Unit] DescriptionBitfinex Lending Bot Afternetwork.target [Service] WorkingDirectory/home/user/bitfinex-lending ExecStart/home/user/bitfinex-lending/.venv/bin/python main.py Restartalways RestartSec10 [Install] WantedBymulti-user.target4.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?symbolstBTCUSD | 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: symbolUSD, amount100, rate0.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?symbolstBTCUSD认证接口需要 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}, headersheaders, jsonbody, timeout30, ) 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}, }第二层是每个币种内部循环执行。循环里做三件事获取当前账户余额和活动订单。对比配置策略决定是否撤单、改价、新下订单。把每轮操作写入日志避免重复下单。这个是通用的批量轮询框架。实际项目中如果作者没有实现完善的批量任务你可以把每个币种当作一个独立配置实例运行但要注意多个实例同时跑可能导致重复下单需要加锁或者限制实例数量。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. 常见问题与排查方法自动化脚本跑起来之后大概率会遇到下面这些问题。按表格逐个排查效率会高很多。问题现象可能原因排查方式解决方案API 返回 401 UnauthorizedAPI Key 或 Secret 不正确检查配置文件和平台 API 页面重新粘贴密钥确认没有多余空格API 返回 403 ForbiddenIP 白名单未包含本机 IP查看平台 API 管理中的 IP 白名单修改白名单或者暂时关闭白名单API 返回 429 Too Many Requests请求频率超过限制查看日志中请求时间间隔增大轮询间隔降低请求频率能读余额但无法下单API Key 缺少下单权限检查 API 权限勾选重新创建 API Key勾选订单权限订单提交返回资金不足账户余额少于订单金额对比平台可用余额和配置文件金额调整 amount 参数或向账户转入资金脚本启动后无日志输出配置错误或入口文件不对检查命令行参数和入口文件查看 README 确认启动命令日志显示订单重复提交缺少幂等检查查看活动订单列表增加提交前检查逻辑脚本运行一段时间后停止网络断开或系统休眠查看进程状态和系统日志调整系统电源计划使用监控进程拉动脚本本地端口被占用项目自带 Web 面板且端口冲突查看端口监听状态修改配置端口例如从 8080 改为 8090时间不同步导致签名错误本机时间偏差过大对比系统时间和标准时间开启系统时间自动同步配置 NTP 服务排查有一个通用顺序先看网络再看认证再看权限最后看参数。不要一上来就改代码。绝大多数自动化任务“第一晚上正常、第二天早上报错”都和网络、系统休眠、时间同步有关而不是策略逻辑问题。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.json9.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 调用、策略配置、批量任务、日志排查这些工程细节都串起来了值得动手试一次。