8.V2执行器与策略编排

Position Executor 仓位管理

Position Executor 是 V2 框架中最核心的执行器，专门负责管理开仓和平仓的完整生命周期。它的设计灵感来自 Martin Prado 在《Advances in Financial Machine Learning》中提出的 Triple Barrier Method，为每个仓位预设三道屏障：止损、止盈和时间限制。

Triple Barrier 机制

三道屏障构成了仓位管理的铁三角。止损屏障防止亏损扩大，止盈屏障锁定利润，时间限制则避免仓位无限期暴露在市场风险中。此外，Position Executor 还支持追踪止损，当价格向有利方向移动时，动态调整止损位置。

class TripleBarrierConf(BaseModel):
    stop_loss: Optional[Decimal] = None
    take_profit: Optional[Decimal] = None
    time_limit: Optional[int] = None
    trailing_stop_activation_price_delta: Optional[Decimal] = None
    trailing_stop_trailing_delta: Optional[Decimal] = None
    open_order_type: OrderType = OrderType.LIMIT
    take_profit_order_type: OrderType = OrderType.MARKET
    stop_loss_order_type: OrderType = OrderType.MARKET
    time_limit_order_type: OrderType = OrderType.MARKET

这段配置定义了三重屏障的所有参数。stop_loss 和 take_profit 使用百分比表示，例如 0.01 代表 1%。time_limit 以秒为单位，2700 表示 45 分钟。追踪止损需要两个参数配合：trailing_stop_activation_price_delta 设置激活阈值，trailing_stop_trailing_delta 设置追踪距离。

现货与合约的差异

Position Executor 在现货和永续合约市场表现出不同的行为特征。在合约市场，它直接管理多空头寸，应用三重屏障逻辑控制仓位风险。在现货市场，它的作用更接近于"挂单管理器"——当限价单成交后，立即为这部分仓位设置止盈止损，类似于 V1 策略中的 Hanging Orders，但控制粒度更精细。

执行流程从策略发出信号开始，Position Executor 接收配置后进入监控循环。每秒它会检查市场价格与三道屏障的关系，一旦触及任一屏障，立即执行对应的平仓操作。追踪止损在价格突破激活阈值后启动，随着盈利扩大不断上移止损位，形成移动保护。

Grid Executor 网格交易

Grid Executor 实现了经典的网格交易策略，在预设价格区间内布置多层买卖订单，像渔网一样捕捉市场的震荡波动。它的核心思想是"低买高卖"，但将人工判断转化为自动化执行。

网格生成逻辑

网格的构建需要四个关键参数：起始价格、结束价格、订单层数和总资金。执行器会自动计算每层的间距，将资金均匀或按比例分配到各个网格节点。

config = GridExecutorConfig(
    connector_name="binance",
    trading_pair="BTC-USDT",
    start_price=Decimal("30000"),
    end_price=Decimal("40000"),
    total_amount_quote=Decimal("1000"),
    min_spread_between_orders=Decimal("0.01"),
    activation_bounds=Decimal("0.02"),
)

这段配置在 30000 到 40000 美元之间建立网格，total_amount_quote 指定了 1000 USDT 的总资金。min_spread_between_orders 确保每层网格至少有 1% 的价差，activation_bounds 设置 2% 的激活边界——只有当价格进入这个范围时，对应的网格订单才会被挂出，避免资金闲置。

状态机管理

每个网格层级都有独立的状态机，包含五种状态：NOT_ACTIVE（未激活）、OPEN_ORDER_PLACED（开仓订单已挂）、OPEN_ORDER_FILLED（开仓订单成交）、CLOSE_ORDER_PLACED（平仓订单已挂）、COMPLETE（完成）。状态机确保网格在成交后能够自动进入下一环节，形成完整的交易闭环。

Grid Executor 同样集成三重屏障系统，但应用方式有所不同。它为整个网格设置全局的止损止盈，当价格突破网格区间时触发。时间限制则防止网格长期运行导致资金效率下降。批量订单处理机制避免对交易所造成冲击，每次只挂出有限数量的订单。

DCA Executor 定投执行

DCA Executor 将传统金融的定投理念引入加密交易，通过定时定额买入或卖出，平滑持仓成本，避免择时风险。它的优势在于纪律性和情绪隔离，特别适合长期建仓或减仓。

核心配置

@dataclass
class DCAExecutorConfig(ExecutorConfig):
    type = "dca_executor"
    exchange: str
    trading_pair: str
    side: TradeType
    leverage: int = 1
    amounts_quote: List[Decimal]
    prices: List[Decimal]
    take_profit: Optional[Decimal] = None
    stop_loss: Optional[Decimal] = None
    trailing_stop: Optional[TrailingStop] = None
    time_limit: Optional[int] = None
    mode: DCAMode = DCAMode.MAKER
    activation_bounds: Optional[List[Decimal]] = None

amounts_quote 和 prices 是两个等长列表，分别指定每期的交易金额和价格。mode 参数决定订单类型，MAKER 模式使用限价单，TAKER 模式使用市价单。activation_bounds 为可选参数，设置价格激活区间，只有当前价格落在区间内才会执行当期定投。

执行逻辑

DCAExecutor 维护一个订单计划，记录每个时间点应该执行的订单。控制任务每秒检查当前时间是否匹配计划中的某个节点，如果匹配且满足余额和激活条件，就调用 create_dca_order 方法下单。订单成交后，执行器会更新状态，进入下一个定投周期。

在合约市场，DCA Executor 可以配合杠杆使用，实现分批建仓。在现货市场，它适合执行大额买入计划，避免一次性投入导致成本过高。追踪止损和止盈设置让定投策略也具备风险管理能力，不至于在趋势反转时坐过山车。

TWAP Executor 时间加权

TWAP Executor 解决大额订单的冲击成本问题。传统上，机构交易者会将大单拆分成小单，在固定时间间隔内逐步执行。TWAP Executor 将这一手动过程完全自动化，确保执行价格接近时间加权均价。

订单计划生成

TWAP 的核心是订单计划，它根据总时长、订单数量和间隔时间，生成一个时间表。每个时间点对应一个待执行的子订单，初始状态为 None，执行后替换为 TrackedOrder 对象。

class TWAPExecutorConfig(ExecutorConfig):
    type = "twap_executor"
    connector_name: str
    trading_pair: str
    side: TradeType
    total_amount_quote: Decimal
    total_duration: float
    order_interval: float
    n_orders: int
    leverage: int = 1
    mode: TWAPMode = TWAPMode.MAKER
    target_execution_price: Optional[Decimal] = None
    activation_bounds: Optional[Decimal] = None

total_duration 设置总执行时长，单位秒。order_interval 是订单间隔，n_orders 是订单数量。执行器会自动计算每个子订单的金额，确保总和等于 total_amount_quote。如果设置 target_execution_price，执行器会监控市场价格，只在接近目标价时下单。

动态调整机制

控制任务每秒评估多个条件：检查是否有订单需要创建、是否有订单需要刷新、是否所有订单已完成、是否有失败订单需要重试。这种动态调整机制让 TWAP 能够适应流动性变化，当市场深度不足时自动暂停，恢复后继续执行。

性能指标计算是 TWAP Executor 的亮点。它实时统计已成交数量、成交均价、累计手续费和净盈亏，让交易者清楚了解执行效果。这对于评估算法执行质量、优化参数至关重要。

XEMM Executor 跨交易所做市

XEMM Executor 实现跨交易所做市策略，在价格较高的交易所挂卖单，在价格较低的交易所挂买单，利用价差获利。它的本质是统计套利，要求两个市场的标的资产具有高度相关性。

套利验证机制

class XEMMExecutorConfig(ExecutorConfig):
    type = "xemm_executor"
    buying_market: ExchangePair
    selling_market: ExchangePair
    order_amount: Decimal
    min_profitability: Decimal
    side: XEMMSide = XEMMSide.MAKER
    leverage: int = 1
    slippage_buffer: Decimal = Decimal("0.001")

执行器启动时会验证两个交易对的代币是否可互换。_are_tokens_interchangeable 方法检查基础资产和报价资产是否相同或属于官方认定的等价代币（如 WETH 和 ETH）。这一步至关重要，避免因为代币不匹配导致对冲失败。

订单管理逻辑

XEMM 同时管理 maker 和 taker 订单。Maker 订单挂在流动性较好的市场，等待成交；taker 订单挂在另一个市场，作为对冲端。控制任务持续更新 maker 订单价格，确保价差始终高于 min_profitability。当 maker 订单成交后，立即在 taker 市场市价平仓，锁定利润。

滑点缓冲 slippage_buffer 是对冲成本的安全垫。实际交易中，taker 订单可能面临滑点，这个缓冲确保扣除滑点后仍有盈利。执行器会实时计算交易成本，包括手续费和滑点，动态调整 maker 报价，保证策略的稳健性。

Arbitrage Executor 套利执行

Arbitrage Executor 是 XEMM 的简化版本，专注于两个市场间的瞬时套利。它的逻辑更直接：发现价差、同时下单、等待成交、计算盈亏。适合价差窗口较短的场景，要求执行速度极快。

工作流程

初始化阶段，ArbitrageExecutor 验证套利有效性，确保交易对可互换。然后创建两个 TrackedOrder 实例，分别追踪买单和卖单。每次控制循环中，它重新计算潜在利润，扣除双边手续费后如果仍高于 min_profitability，就执行交易。

class ArbitrageConfig(ExecutorConfig):
    type = "arbitrage_executor"
    buying_market: ExchangePair
    selling_market: ExchangePair
    order_amount: Decimal
    min_profitability: Decimal
    leverage: int = 1

套利的关键在于速度。Arbitrage Executor 使用市价单或限价单立即成交模式，减少执行时间。它监控订单状态，一旦双边都成交，立即计算实际利润并记录。如果单边成交，会启动超时机制，在一定时间内等待另一边成交，超时则取消订单，避免单边风险。

Executor Orchestrator 编排器

Executor Orchestrator 是 V2 框架的指挥中心，负责协调多个执行器的生命周期。它将 Controller 生成的 ExecutorAction 转化为实际的执行器操作，实现策略的模块化部署。

核心架构

class ExecutorOrchestrator:
    def __init__(self, strategy: StrategyV2Base, executors_update_interval: float = 1.0):
        self.strategy = strategy
        self.executors_update_interval = executors_update_interval
        self.executors: Dict[str, ExecutorBase] = {}
        self.actions_queue: asyncio.Queue = asyncio.Queue()

executors 字典按 controller ID 存储所有活跃执行器，actions_queue 是动作队列，Controller 将 ExecutorAction 推入队列，Orchestrator 异步消费并执行。这种设计解耦了策略决策和订单执行，让 Controller 专注于信号生成，Orchestrator 专注于执行细节。

动作执行系统

编排器支持三种核心动作：CreateExecutorAction、StopExecutorAction、StoreExecutorAction。创建动作会根据配置实例化对应的执行器类型，启动其控制循环。停止动作优雅地关闭执行器，等待当前订单完成后再终止。存储动作将执行器数据持久化，用于后续分析和优化。

性能报告功能是 Orchestrator 的价值体现。它可以按 Controller 汇总盈亏、交易量、胜率等指标，也可以全局统计所有执行器的表现。这些数据为策略优化提供依据，帮助识别哪些参数组合最有效，哪些市场条件最适合策略运行。

与 Controller 的协同

在典型工作流程中，Controller 的 get_executor_actions 方法生成动作列表，脚本调用 executor_orchestrator.execute_actions(actions) 批量执行。Orchestrator 返回执行结果，脚本在 format_status 中展示。这种分层架构让复杂策略的实现变得清晰，每个组件职责单一，易于测试和维护。

Executor Orchestrator 的出现，标志着 Hummingbot 从单一策略脚本迈向了模块化策略系统。开发者可以像搭积木一样组合不同的 Controller 和 Executor，构建出适应各种市场环境的交易机器。这种灵活性正是 V2 框架的核心优势。