策略

Hummingbot PMM V1（纯做市，由 hummingbot 开发）——忠实移植至 BTCUSDT.BINANCE_SPOT，1 个买入 + 1 个卖出限价档位，位于中间价 ±1%；每 30 秒刷新，成交后延迟 60 秒，库存偏斜 OFF（源代码默认值）

结局: 已放弃

HummingbotPmmV1BtcSpot

结局总结

本假设尝试将 Hummingbot 的 PMM V1 对称限价单做市商移植到 Binance 现货 BTCUSDT。平台改动仅限于强制适配：数量固定为初始权益的 25%，每根 1 分钟K线刷新一次，并检查现货余额。策略始终未能完成编码：迭代 3 次后，运行因“coding_stuck_3_timeouts”而中止。最终未生成回测、优化或分析师结论。

策略报告

假设

忠实移植 Hummingbot 的 PMM V1 控制器（致谢：hummingbot，Apache-2.0）。这是一种可实际交易的策略（对称限价订单做市商），并非辅助工具。源代码默认值：连接器 'binance'（SPOT 连接器）以及 trading_pair 'BTC-USDT'，因此我们使用 BTCUSDT.BINANCE_SPOT（CASH 账户，仅做多库存，每笔成交的做市商手续费为 0.10%）。默认值完全按原文书写：order_amount = 1（基础资产），buy_spreads = [0.01]，sell_spreads = [0.01]（每侧一个层级，层级 ID 为 'buy_0' 和 'sell_0'），order_refresh_time = 30 秒，order_refresh_tolerance_pct = -1（已禁用，因此刷新所有内容），filled_order_delay = 60 秒，inventory_skew_enabled = False，target_base_pct = 0.5，inventory_range_multiplier = 1.0，price_ceiling = -1 且 price_floor = -1（两者均已禁用）。参考价格 = 中间价。在我们的平台上，仅有 K 线数据时，中间价 = 最新 1-MINUTE K 线的收盘价（这是我们拥有多年历史数据的最细粒度 K 线；盘口中间价无法在多年范围内复现）。每笔订单都是普通的 LIMIT 订单（源代码中没有仅挂单选项，因此不添加）。PLATFORM ADAPTATIONS（仅这些，全部为强制项）：（1）规模。1 BTC 达到或超过全部 $100k 的初始资金，因此 order_amount 在开始时被设置为 ONCE：固定基础数量，等于 0.25 × 初始权益 / 首个收盘价（每层约占权益的 25%），之后保持为 FIXED 基础单位，与源代码一致。参数 'order_amount_equity_frac' = 0.25。（2）时钟。30 秒的刷新间隔和 60 秒的成交延迟都短于或等于一根 1m K 线。因此，每根 K 线收盘时都会刷新（取消任何挂单时间超过 30 秒的未成交订单，即每根 K 线刷新一次），而已成交的层级在成交后 60 秒内不能重新报价（会跳过下一根 K 线收盘时的报价）。（3）现货余额。Hummingbot 的现货连接器会拒绝卖出数量超过基础资产余额的订单，以及买入金额超过计价资产余额的订单。因此，仅当持有的基础资产 >= order_amount 时才下达 sell_0 订单（否则该层级在该根 K 线上跳过），并且仅当可用 USDT >= order_amount × 价格 × 1.001 时才下达 buy_0。回测以 100% USDT 开始，因此首次往返交易必须从买入成交开始。源策略没有止损、止盈或按时间退出。不会添加这些机制，因为添加任何一项都会使其不再是忠实移植。

针对第 2 层故障的第 2 次修复。合成测试使用的模拟缓存没有 orders_inflight() 或 account_for_venue() 方法。现在代码使用 getattr 查找这两个方法，并在方法缺失时跳过调用。真实的 NautilusTrader 缓存具有这两个方法，因此回测和模拟交易行为不变。没有更改其他内容。平台适配与之前相同：以K线收盘价代替订单簿中间价，刷新和成交延迟按K线时钟运行，固定基础订单数量根据权益设定，每一侧都受现货余额限制。边际风险在于：价差为 1%，每笔成交支付 0.10% 的挂单手续费，因此只有当 BTC 在约 2% 的区间内来回波动时，策略才会盈利。在单边趋势中，策略会在一侧持有 BTC 或现金。

coding_stuck_3_timeouts

实现

忠实移植 Hummingbot PMM V1（纯做市）至 BTCUSDT 现货市场，使用 1 分钟K线收盘价作为中间价。维持一笔买入限价单 GTC，价格为中间价 × (1 − 1%)；另维持一笔卖出限价单 GTC，价格为中间价 × (1 + 1%)。每根K线都会撤销尚未成交的报价并重新下单，因为 30 秒的刷新间隔短于一根K线。成交后，该侧须等待 60 秒才会再次报价。订单数量为固定基础数量，在启动时设定：以初始权益的 25% 除以首根收盘价。库存偏斜已关闭，价格区间已禁用，与源代码一致。只有可用 USDT 足够时才会下买单，只有持有足够 BTC 时才会下卖单。

迭代历史

验证失败（第 2 层——合成情景）：使用的参数：['buy_spread', 'price_floor', 'sell_spread', 'price_ceiling', 'filled_order_delay', 'order_refresh_time', 'quote_balance_buffer', 'order_amount_equity_frac'] 请检查 __init__ 是否设置了 self.parameters.get() 返回的所有属性。 - steady_uptrend：AttributeError：'_MockCache' 对象没有属性 'orders_inflight'（K线时间戳：1735689660000） - steady_downtrend：AttributeError：'_MockCache' 对象没有属性 'orders_inflight'（K线时间戳：1735689660000） - flat_ranging：AttributeError：'_MockCache' 对象没有属性 'orders_inflight'（K线时间戳：1735689660000） - volatility_spike：AttributeError：'_MockCache' 对象没有属性 'orders_inflight'（K线时间戳：1735689660000） - zero_volume：AttributeError：'_MockCache' 对象没有属性 'orders_inflight'（K线时间戳：1735689660000） - price_gap：AttributeError：'_MockCache' 对象没有属性 'orders_inflight'（K线时间戳：1735689660000）

sandbox_timeout：验证失败（第 3 层——沙盒回测）：冒烟测试在约 20000 根K线的窗口（BTCUSDT.BINANCE_SPOT-1-MINUTE-LAST-EXTERNAL 的 30 天）上超过了 300 秒墙钟时间限制。这几乎总是意味着每根K线的工作量会随历史数据增长，例如反复扫描完整的资金费率/补充序列，或在每根K线上于 calculate_signal()/on_bar() 内重建列表并调用 min()/sorted()。在 __init__ 中预先计算已排序的时间戳数组 ONCE 并使用 bisect，或按时间戳缓存查询结果，使每根K线的开销为 O(log n) 而非 O(n)。

结局总结

订单管理繁重的移植版本（每根K线都撤单并重新报价、等待撤单确认、检查现货余额）复杂到足以导致编码阶段超时，因此今后尝试时应从更简单、更精简的实现开始，以便在编码时限内完成。

运行在编码阶段因“coding_stuck_3_timeouts”而中止，此前已迭代 3 次，因此未进行验证、回测审查、优化、分析师审查或风险审查。

忠实移植 Hummingbot 的 PMM V1 纯做市策略，运行于 BTCUSDT.BINANCE_SPOT 的 1 分钟K线上，在中间价 ±1% 处各挂一笔买入和卖出限价单，每根K线刷新，成交后等待 60 秒再报价；关闭库存偏斜，不设止损、止盈或时间退出。

没有绩效数据：回测报告为空，也不存在优化报告，因此未记录收益、夏普比率或交易笔数。

分析

PMMV1

Stratmill 是研究与模拟交易工具，不提供财务建议，也不是经纪商。回测与模拟结果均为假设性结果。交易存在亏损风险。