第二階段：核心組件深度解讀
模組 08：執行引擎 — 訂單的一生從你下達指令到收到成交回報的完整旅程
一、執行引擎的角色
執行引擎是訂單管理的中央控制塔。它不直接和交易所通訊，而是透過 ExecutionClient 適配器來操作。
flowchart LR
subgraph input["📝 命令輸入"]
direction TB
submit["SubmitOrder"]
cancel["CancelOrder"]
modify["ModifyOrder"]
end
ee["⚙️ ExecutionEngine<br/>執行引擎中心"]
subgraph output["⚡ 事件輸出"]
direction TB
accepted["OrderAccepted"]
filled["OrderFilled"]
rejected["OrderRejected"]
end
subgraph adapt["🔌 適配器與交易所"]
direction TB
binance["Binance Client"]
ib["IB Client"]
sim["Simulator"]
end
input ==> ee
ee ==> adapt
adapt ==> ee
ee ==> output
style ee fill:#0f1419,stroke:#4fc3f7,stroke-width:2px
style input fill:#0f1419,stroke:#ab47bc,stroke-width:1px
style output fill:#0f1419,stroke:#ef5350,stroke-width:1px
圖 1：執行引擎接收命令、路由到交易所、回報事件
二、訂單的完整生命週期
sequenceDiagram
participant S as 🎯 策略
participant RE as 🛡️ RiskEngine
participant EE as ⚙️ ExecutionEngine
participant EC as 🔌 ExecutionClient
participant EX as 🏦 交易所
participant Cache as 💾 Cache
participant Port as 💰 Portfolio
S->>RE: SubmitOrder(市價買入 1 BTC)
Note over RE: 風控檢查通過 ✅
RE->>EE: 轉發命令
EE->>EE: 生成 OrderSubmitted 事件
EE->>Cache: 更新狀態 → SUBMITTED
EE->>EC: 路由到 Binance 適配器
EC->>EX: REST API 下單
EX-->>EC: 訂單接受確認
EC->>EE: OrderAccepted 事件
EE->>Cache: 更新狀態 → ACCEPTED
EX-->>EC: 成交回報
EC->>EE: OrderFilled 事件
EE->>Cache: 更新狀態 → FILLED
EE->>Port: 更新持倉和盈虧
EE->>S: 通知成交（透過 MessageBus）
圖 2：訂單從策略到交易所再回到策略的完整流程
三、訂單命令 API
以下是你在策略中最常使用的訂單操作：
# 市價訂單 — 立即執行
order = self.order_factory.market(
instrument_id=btc_usdt_id,
order_side=OrderSide.BUY,
quantity=Quantity.from_str("0.01"),
)
self.submit_order(order)
# 限價訂單 — 指定價格
order = self.order_factory.limit(
instrument_id=btc_usdt_id,
order_side=OrderSide.BUY,
quantity=Quantity.from_str("0.01"),
price=Price.from_str("48000.00"),
time_in_force=TimeInForce.GTC,
)
self.submit_order(order)
# 止損訂單 — 防止虧損擴大
order = self.order_factory.stop_market(
instrument_id=btc_usdt_id,
order_side=OrderSide.SELL,
quantity=Quantity.from_str("0.01"),
trigger_price=Price.from_str("45000.00"),
)
self.submit_order(order)
# 取消訂單
self.cancel_order(order)
# 修改訂單（改價或改量）
self.modify_order(order, price=Price.from_str("47500.00"))
# 全部取消
self.cancel_all_orders(instrument_id=btc_usdt_id)四、條件單組合 (Contingency Orders)
NautilusTrader 支援三種訂單組合策略：
🔗
OTO — One Triggers Other
訂單 A 成交後，自動觸發訂單 B。
例子：買入後自動掛止損
⚖️
OCO — One Cancels Other
訂單 A 或 B 任一成交，自動取消另一個。
例子：止盈和止損只觸發一個
🎯
OUO — One Updates Other
訂單 A 部分成交時，自動更新訂單 B 的數量。
例子：保持止損數量和持倉一致
五、模擬交易所 (SimulatedExchange)
在回測和沙箱模式中，ExecutionClient 連接的是模擬交易所而非真實交易所：
| 特性 | 模擬交易所 | 真實交易所 |
|---|---|---|
| 撮合引擎 | 內建撮合邏輯 | 交易所的撮合引擎 |
| 延遲模擬 | 可配置固定延遲 | 真實網絡延遲 |
| 手續費 | 按配置計算 | 交易所實際收取 |
| 滑點 | 可配置滑點模型 | 真實市場滑點 |
| 部分成交 | 基於訂單簿深度模擬 | 真實市場深度 |
六、互動練習
🧠 練習：設計訂單組合
你想在 50,000 買入 BTC，同時設置止損在 48,000、止盈在 55,000（只觸發一個就取消另一個）。你需要用哪些訂單和什麼組合方式？
步驟：
- 掛一個限價買入單 @ 50,000（主訂單）
- 設置 OTO 條件：主訂單成交後觸發以下兩個子訂單
- 子訂單 A：止損賣出 @ 48,000（
StopMarketOrder） - 子訂單 B：止盈賣出 @ 55,000（
LimitOrder） - 子訂單 A 和 B 之間設置 OCO：任一成交就取消另一個
💡 這就是經典的「進場 + 止損止盈」三合一訂單組合，也叫 Bracket Order（括號訂單）。
七、本模組重點回顧
📋 關鍵點
- 執行引擎管理所有訂單的生命週期，不直接連接交易所
- 命令 → 路由 → 事件：策略發送命令，引擎路由到適配器，適配器回報事件
- 條件單：OTO（觸發）、OCO（取消）、OUO（更新）三種組合
- 模擬交易所：回測中完全模擬真實交易所行為
- 訂單工廠：使用
self.order_factory創建訂單