盯盤盯到凌晨三點(diǎn)手動加倉加成了滿倉結(jié)果一根大陰線打穿止損賬戶直接回到解放前——這種經(jīng)歷做量化的人多少都沾點(diǎn)。尤其是剛開始把策略跑在實(shí)盤上的那段時間單子滿天飛、參數(shù)亂調(diào)、回撤失控最大的問題根本不是策略不賺錢而是整個交易過程完全沒有“可回滾”的余地。我后來把整套系統(tǒng)推倒重做核心思路就是一句話把量化交易當(dāng)成寫代碼用 Git 的那套版本管理邏輯來管交易狀態(tài)。這就是 OpenAlice 這個本地量化 Agent 架構(gòu)的由來你可以叫它 Trading-as-Git。這篇文章不是給你講什么高大上的分布式微服務(wù)而是扎扎實(shí)實(shí)拆開一套可以跑在你自己電腦上的量化 Agent從架構(gòu)設(shè)計、模塊劃分到風(fēng)控閉環(huán)怎么閉環(huán)每一步都帶著實(shí)操細(xì)節(jié)和踩坑記錄。適合兩類人看一類是已經(jīng)寫過策略、但每次實(shí)盤都心驚肉跳的量化新手另一類是正在設(shè)計自己的交易系統(tǒng)、想知道除了“止損止盈”之外風(fēng)控還能怎么落地的開發(fā)者。1. 整體設(shè)計與思路拆解為什么交易系統(tǒng)要學(xué) Git1.1 盲目實(shí)盤的問題本質(zhì)狀態(tài)不可回退大多數(shù)個人量化的實(shí)盤路徑是這樣的寫一個策略腳本回測看著不錯直接丟到實(shí)盤跑。跑幾天發(fā)現(xiàn)參數(shù)不行改參數(shù)改完繼續(xù)跑。某天行情劇烈波動策略連續(xù)止損凈值大幅回撤你想停下來但手里還有持倉想恢復(fù)之前的某個穩(wěn)健狀態(tài)卻發(fā)現(xiàn)早就不知道怎么回去了。這里面最要命的是交易系統(tǒng)的狀態(tài)是單向演進(jìn)的。你的倉位、訂單、資金曲線、參數(shù)配置全都擠在一個數(shù)據(jù)庫里改亂了就是亂了沒有任何機(jī)制告訴你“上一次正常運(yùn)轉(zhuǎn)時的完整狀態(tài)是什么”。Git 解決了代碼的這個問題——每次提交都是一個可恢復(fù)的完整快照套用到交易系統(tǒng)上就是讓每一次持倉變化、每一次參數(shù)調(diào)整、每一次風(fēng)控觸發(fā)都變成一次可審計、可回滾的“提交”。我第一次意識到這個需求是因?yàn)橛幸淮尾呗詤?shù)被誤改導(dǎo)致下單數(shù)量直接翻了十倍要不是券商端有最大手?jǐn)?shù)限制那一單就能把我半年利潤吐回去。事故之后我去查日志發(fā)現(xiàn)連誰改的、什么時候改的、改之前是什么值都查不到。那一刻我就明白了交易系統(tǒng)的第一剛需不是更多的策略而是狀態(tài)管理。1.2 Trading-as-Git 的核心映射把版本管理哲學(xué)搬進(jìn)量化系統(tǒng)Trading-as-Git 不是一個具體的軟件而是一套設(shè)計原則。我把 Git 的幾個核心概念直接映射到了交易系統(tǒng)的模塊上整套架構(gòu)就是圍繞這張映射表展開的Git 概念交易系統(tǒng)對應(yīng)具體作用commit提交狀態(tài)快照每次持倉變化、參數(shù)變更、風(fēng)控動作都生成快照記錄完整的賬戶狀態(tài)branch分支策略變體隔離不同參數(shù)組合、不同策略版本并行運(yùn)行互不干擾統(tǒng)一在回測框架內(nèi)驗(yàn)證revert回滾狀態(tài)恢復(fù)系統(tǒng)檢測到異常時將持倉、掛單、參數(shù)恢復(fù)到上一個健康快照rebase變基參數(shù)校準(zhǔn)用最新市場數(shù)據(jù)重新校準(zhǔn)策略因子生成新的基準(zhǔn)狀態(tài)hooks鉤子風(fēng)控觸發(fā)器在指定事件點(diǎn)如下單前、持倉更新后強(qiáng)制執(zhí)行風(fēng)控邏輯.gitignore隱私隔離API 密鑰、私密配置、敏感日志不與策略代碼混淆存放為什么這個映射能成立因?yàn)榻灰紫到y(tǒng)和代碼項(xiàng)目的本質(zhì)是一樣的都是狀態(tài)機(jī) 時間序列。代碼項(xiàng)目有源碼、依賴、構(gòu)建產(chǎn)物交易系統(tǒng)有策略代碼、參數(shù)配置、倉位狀態(tài)代碼需要分支來實(shí)驗(yàn)新功能交易需要分支來實(shí)驗(yàn)新參數(shù)代碼出 bug 要回滾交易出亂子也要回滾。想通了這一層架構(gòu)設(shè)計就有了主心骨。1.3 本地部署而非云端的決策邏輯OpenAlice 選擇“本地量化 Agent”而不是 SaaS 服務(wù)這個決定當(dāng)時在公司內(nèi)部爭論最多。我只說三個原因。第一是延遲敏感。實(shí)盤下單的鏈路是行情 → 信號 → 風(fēng)控 → 訂單 → 券商每增加一次網(wǎng)絡(luò)跳轉(zhuǎn)就增加幾十毫秒延遲。策略跑在本地行情數(shù)據(jù)從本地內(nèi)存直接讀取信號到下單控制在 10ms 以內(nèi)一旦上云網(wǎng)絡(luò)抖動、隊列堆積、服務(wù)間通信都會在關(guān)鍵節(jié)點(diǎn)上添亂。第二是數(shù)據(jù)隱私。策略源碼和倉位信息是量化團(tuán)隊的核心資產(chǎn)本地部署意味著核心代碼不出本機(jī)API 密鑰也只存在環(huán)境變量里。第三是成本。一臺帶 GPU 的本地工作站跑中低頻策略完全夠用省掉了云服務(wù)器和數(shù)據(jù)庫的月租。代價是運(yùn)維自己扛但這套架構(gòu)設(shè)計得足夠簡單本地跑完全沒壓力。2. 核心模塊解析本地量化 Agent 的五層架構(gòu)2.1 事件驅(qū)動內(nèi)核一切皆消息OpenAlice 的底層是一個事件驅(qū)動內(nèi)核所有模塊之間不直接調(diào)用而是通過事件總線通信。我把系統(tǒng)內(nèi)的事件分成了四類市場事件tick、bar、公告、資金費(fèi)率變動統(tǒng)一封裝成帶時間戳的 MarketEvent策略事件信號產(chǎn)生、策略狀態(tài)變化、參數(shù)更新對應(yīng) SignalEvent訂單事件下單指令、訂單回報、成交回報、撤單回報對應(yīng) OrderEvent 和 FillEvent風(fēng)控事件風(fēng)控檢查通過/拒絕、熔斷觸發(fā)、快照生成對應(yīng) RiskEvent引入事件驅(qū)動而不是模塊間函數(shù)直調(diào)最大的好處是解耦。策略模塊不需要知道風(fēng)控模塊內(nèi)部怎么實(shí)現(xiàn)它只要往事件總線上發(fā)一個 SignalEvent風(fēng)控模塊監(jiān)聽到之后做檢查檢查通過再轉(zhuǎn)成 OrderEvent整個過程模塊之間零直接依賴。想替換掉某個模塊只要保證事件接口不變內(nèi)部隨便重寫。事件總線的實(shí)現(xiàn)我用的是 Python 的asyncio 自定義消息隊列沒有引入 Kafka 這種重依賴。核心代碼如下import asyncio from collections import defaultdict from typing import Callable, Any class EventBus: def __init__(self): self._subscribers defaultdict(list) self._queue asyncio.Queue() self._running False def subscribe(self, event_type: str, handler: Callable): self._subscribers[event_type].append(handler) async def publish(self, event_type: str, data: Any): await self._queue.put((event_type, data)) async def _dispatch(self): while self._running: event_type, data await self._queue.get() for handler in self._subscribers.get(event_type, []): asyncio.create_task(handler(data)) def start(self): self._running True asyncio.get_event_loop().create_task(self._dispatch())這個簡化版事件總線在單機(jī)場景下完全夠用。關(guān)鍵點(diǎn)在最后一行——用asyncio.create_task處理每個事件保證風(fēng)控模塊的檢查邏輯不會阻塞后續(xù)事件的處理。如果風(fēng)控檢查本身跑得慢后續(xù)訂單事件就會排隊這在實(shí)盤里是災(zāi)難性的延遲所以風(fēng)控模塊我單獨(dú)開了線程池不讓它在事件循環(huán)里跑。2.2 快照與回滾機(jī)制系統(tǒng)的“后悔藥”Trading-as-Git 的核心實(shí)現(xiàn)是快照子系統(tǒng)。每次系統(tǒng)發(fā)生重要狀態(tài)變更比如持倉變化、參數(shù)調(diào)整、風(fēng)控觸發(fā)都會生成一個完整快照寫入本地 Git 倉庫?？煺諆?nèi)容分為兩層第一層是狀態(tài)層記錄賬戶權(quán)益、持倉列表、掛單列表、策略參數(shù)、當(dāng)前系統(tǒng)版本號。第二層是事件層記錄從上一個快照到現(xiàn)在發(fā)生的所有 MarketEvent、OrderEvent、RiskEvent用于事后審計和回放。快照生成不是想象中那么簡單。最開始我把所有數(shù)據(jù)一股腦序列化結(jié)果發(fā)現(xiàn)快照文件大到幾百 MB生成一次要好幾秒。后來才意識到關(guān)鍵在于“只存差異”。Git 的每次提交也不是把全量文件復(fù)制一遍而是記錄變更集。我的快照設(shè)計也是同樣的思路class StateSnapshot: def __init__(self, version: str, parent: str | None, state_diff: dict, event_batch: list): self.version version # 快照 ID如 snap_20250317_143005 self.parent parent # 上一個快照的 ID形成鏈 self.state_diff state_diff # 狀態(tài)變更集而非全量狀態(tài) self.event_batch event_batch # 該時段內(nèi)的事件列表 self.timestamp time.time()舉例說明回滾場景。假設(shè)你跑著策略 A某天發(fā)布了一個新版本改動了均線周期參數(shù)和倉位管理規(guī)則快照 V10 記錄了改動前的狀態(tài)。運(yùn)行三個小時后策略開始異常頻繁開倉賬戶浮虧快速擴(kuò)大。系統(tǒng)檢測到異常后執(zhí)行回滾指令把當(dāng)前狀態(tài)重置為 V10先是撤銷當(dāng)前所有未成交掛單然后按 V10 的持倉列表強(qiáng)制平掉多出來的倉位或者反向開倉對沖最后把策略參數(shù)恢復(fù)到 V10 記錄的值。整個回滾過程也會作為一個新快照記錄下來方便后續(xù)復(fù)盤。這里有個實(shí)操細(xì)節(jié)你需要注意價格已經(jīng)變化了按舊持倉恢復(fù)不等于沒有損失。回滾的目的是止損和恢復(fù)可控狀態(tài)不是為了不留痕跡。所以我在回滾邏輯里加了一個“安全墊”參數(shù)默認(rèn) 2%意思是回滾時允許獲得略高于原持倉數(shù)量的價格容忍度防止在流動性和滑點(diǎn)劇烈的情況下強(qiáng)行全部平倉。這個參數(shù)在真實(shí)交易里極其重要。2.3 任務(wù)隊列與本地 Agent 的任務(wù)編排量化 Agent 不只是跑策略它要定時拉取數(shù)據(jù)、定期重算指標(biāo)、盤后生成報告、異常時觸發(fā)告警。這些雜活如果全塞在事件循環(huán)里就會阻塞核心交易邏輯。我實(shí)際的做法是把任務(wù)分成三類用三個隊列隔離隊列類型任務(wù)內(nèi)容優(yōu)先級調(diào)度方式實(shí)時隊列策略信號處理、訂單狀態(tài)更新、風(fēng)控檢查最高事件驅(qū)動即時消費(fèi)常規(guī)隊列行情采集、指標(biāo)計算、日志歸檔中固定間隔輪詢低頻隊列回測任務(wù)、參數(shù)優(yōu)化、報告生成低空閑時執(zhí)行支持暫停常規(guī)隊列里最容易踩的坑是數(shù)據(jù)抓取任務(wù)和策略任務(wù)爭搶 CPU。比如整點(diǎn)拉取日線數(shù)據(jù)的時候剛好碰到策略在計算開倉信號單核機(jī)器上兩者互相卡頓信號延遲發(fā)出錯過最佳開倉點(diǎn)位。解決思路是在任務(wù)隊列層做資源隔離——把行情采集和指標(biāo)計算放進(jìn)一個單獨(dú)的進(jìn)程通過 IPC 和主進(jìn)程通信而不是在同一個進(jìn)程里跑線程。一開始為了方便用線程后來被延遲問題折磨了一周換成多進(jìn)程之后世界清凈了。Agent 的調(diào)度邏輯遵循一個簡單的規(guī)則不要讓任何非交易任務(wù)阻塞交易任務(wù)。比如回測任務(wù)再耗時也不能占用事件循環(huán)。因此所有非實(shí)時任務(wù)統(tǒng)一通過concurrent.futures.ProcessPoolExecutor丟到子進(jìn)程執(zhí)行父進(jìn)程只負(fù)責(zé)收集結(jié)果。這個設(shè)計讓本地量化的“并發(fā)”問題變成了一個“調(diào)度”問題——你不需要關(guān)心線程安全只要做好隊列優(yōu)先級和進(jìn)程隔離。3. 風(fēng)控閉環(huán)實(shí)現(xiàn)從信號到清算每一環(huán)都被攔截3.1 三層風(fēng)控體系預(yù)交易、實(shí)時、事后風(fēng)控閉環(huán)不是單一的風(fēng)控模塊而是貫穿交易全鏈路的三層攔截體系。我把它拆成了 Pre-trade、Real-time、Post-trade 三層每一層管的事情完全不同。Pre-trade預(yù)交易風(fēng)控發(fā)生在信號被接受、但下單指令尚未發(fā)出之前。這一層檢查的是“這筆單子值不值得下”包括標(biāo)的是否在允許交易名單內(nèi)排除 ST、停牌、流動性極差的單筆投入的名義本金是否超過賬戶凈值的設(shè)定比例比如 5%當(dāng)前持倉數(shù)是否超過上限比如單標(biāo)的最大 3 個倉位、總持倉不超過 20 個策略是否處于“撲街狀態(tài)”近 20 筆交易勝率低于閾值時強(qiáng)制降頻Real-time實(shí)時風(fēng)控發(fā)生在持倉已經(jīng)存在的過程中。這一層盯著賬戶的整體風(fēng)險和瞬時異常核心邏輯是熔斷器。我設(shè)計了三個熔斷閾值單筆熔斷單個倉位浮虧超過初始保證金的 15%觸發(fā)強(qiáng)制止損組合熔斷賬戶日內(nèi)虧損達(dá)到初始權(quán)益的 3%停止開新倉極端熔斷市場波動率指數(shù)如 BTC 的 DVOL 或股票的 VIX超過閾值全部倉位降杠桿或清倉Post-trade事后風(fēng)控發(fā)生在收盤后或運(yùn)行結(jié)束后主要做審計和回放檢查今天的每一筆成交是否經(jīng)過風(fēng)控通道、訂單執(zhí)行是否有明顯滑點(diǎn)、策略表現(xiàn)是否符合預(yù)期。事后風(fēng)控更像是一個“監(jiān)視器”它不直接干預(yù)交易但它的發(fā)現(xiàn)會影響第二天的預(yù)交易參數(shù)——這就是閉環(huán)的含義。3.2 止損、熔斷與 Git 式回滾的聯(lián)動我把三層風(fēng)控和 Trading-as-Git 的快照機(jī)制綁在一起形成了一個自動化的異常響應(yīng)循環(huán)。流程是這樣的實(shí)時風(fēng)控檢測到賬戶日內(nèi)虧損達(dá)到 2%接近熔斷閾值系統(tǒng)自動生成一個“危險快照”標(biāo)記當(dāng)前持倉和參數(shù)狀態(tài)觸發(fā)熔斷后所有策略模塊暫停產(chǎn)生新 SignalEvent系統(tǒng)進(jìn)入“觀察模式”只處理平倉事件不處理開倉事件如果虧損繼續(xù)擴(kuò)大到 3%進(jìn)入“安全回滾”模式按最近一個健康快照恢復(fù)持倉盤后由人工決定是回滾到更早的快照還是維持“觀察模式”等待市場恢復(fù)這個流程里最關(guān)鍵的是第 5 步。很多人理解的止損是“虧到閾值就平倉”但實(shí)際執(zhí)行中最大的問題不是平不掉而是平倉之后下一個策略又自動開倉了。防復(fù)發(fā)比止損本身更重要。所以每次熔斷觸發(fā)之后系統(tǒng)必須把策略模塊的狀態(tài)機(jī)置為“鎖死”只有人工解鎖或第二天的定時任務(wù)才能恢復(fù)。熔斷器的實(shí)現(xiàn)我采用了狀態(tài)機(jī)模式class CircuitBreaker: def __init__(self, daily_loss_limit0.03, single_loss_limit0.15): self.state CLOSED # CLOSED: 正常; OPEN: 熔斷; HALF_OPEN: 試探恢復(fù) self.daily_loss_limit daily_loss_limit self.single_loss_limit single_loss_limit self.daily_start_equity None self.peak_equity None def check(self, current_equity, positions): if self.state OPEN: return REJECT # 日內(nèi)虧損檢查 daily_loss (self.daily_start_equity - current_equity) / self.daily_start_equity if daily_loss self.daily_loss_limit: self.state OPEN return TRIGGER_DAILY_LIMIT # 單筆持倉浮虧檢查 for pos in positions: if pos.unrealized_pnl / pos.initial_margin -self.single_loss_limit: self.state OPEN return TRIGGER_SINGLE_LIMIT return PASS注意我用了daily_start_equity而不是“當(dāng)前權(quán)益回撤”作為分母。為什么因?yàn)槿諆?nèi)虧損 3% 的基準(zhǔn)應(yīng)該是今天開始時的權(quán)益而不是昨天收盤時的總資產(chǎn)。如果你用回撤drawdown的概念系統(tǒng)可能會在連續(xù)虧損多日之后因?yàn)椤翱偦爻芬汛蟆倍`判但當(dāng)日其實(shí)是盈利的。用日內(nèi)基準(zhǔn)更直接也更符合交易員盯盤的習(xí)慣。3.3 訂單路由與執(zhí)行質(zhì)量監(jiān)控信號從策略產(chǎn)生到最終成交中間涉及訂單路由。這一塊新手經(jīng)常忽略但實(shí)盤里滑點(diǎn)、拒單、超時全部發(fā)生在這里。我在訂單模塊設(shè)計了一個“雙重路由”策略主路由是券商原生 API直接走 TCP 連接延遲最低備路由是 HTTP 接口用于主路由異常時的兜底。當(dāng)訂單發(fā)出后系統(tǒng)啟動一個 5 秒監(jiān)聽窗口如果 5 秒內(nèi)沒有成交回報且訂單狀態(tài)不是 PARTIALLY_FILLED就自動撤單并嘗試備路由。這個“超時撤單”邏輯必須放在風(fēng)控層因?yàn)槌穯伪旧硪彩且环N風(fēng)控操作——寧可錯過這筆交易也不讓它變成一筆失控的裸單。執(zhí)行質(zhì)量的監(jiān)控指標(biāo)我日常盯三組滑點(diǎn)率成交價與信號發(fā)出時標(biāo)記價格的偏差、拒單率券商拒絕訂單的比例、下單延遲從 SignalEvent 到 OrderEvent 的毫秒數(shù)。這三組指標(biāo)每天盤后匯總?cè)绻骋惶斓幕c(diǎn)率中位數(shù)超過 0.1%我就知道是策略觸發(fā)太頻繁還是市場流動性變差了進(jìn)而決定是否調(diào)整訂單拆分邏輯。滑點(diǎn)問題有一個本地量化容易被忽略的細(xì)節(jié)回測時假設(shè)成交價 信號價實(shí)盤卻可能差出好幾個 tick。所以我在回測模塊中強(qiáng)制加入了“滑點(diǎn)模型”默認(rèn)雙邊各 0.05% 的滑點(diǎn)這個參數(shù)雖然是估計值但遠(yuǎn)比用 0 滑點(diǎn)自欺欺人強(qiáng)得多。參數(shù)設(shè)定參考了真實(shí)交易的教訓(xùn)——曾經(jīng)有個策略回測年化 80%實(shí)盤三個月只有 35%差距基本就來自滑點(diǎn)和手續(xù)費(fèi)。4. 實(shí)操過程從零搭建一套可復(fù)現(xiàn)的本地量化 Agent4.1 環(huán)境準(zhǔn)備與技術(shù)選型在動手寫代碼之前先確認(rèn)硬件和系統(tǒng)環(huán)境。我的參考配置如下你不需要完全一致但建議不要低于這個水平組件推薦配置說明CPU8 核 16 線程以上多進(jìn)程跑回測和任務(wù)隊列時核心數(shù)越多越好內(nèi)存32GB行情數(shù)據(jù)和策略緩存非常吃內(nèi)存存儲NVMe SSD 1TB快照和日志頻繁寫入機(jī)械硬盤扛不住OSUbuntu 22.04 LTSPython 生態(tài)在 Linux 上問題最少Python3.10用了asyncio和類型注解的新特性技術(shù)棧我選的是Python SQLite Redis Git全部本地部署零云依賴。Python 做策略開發(fā)效率第一SQLite 存交易記錄和快照索引單文件備份方便Redis 做內(nèi)存緩存和任務(wù)隊列主要為了跨進(jìn)程通信Git 就是字面意義上的 Git——每個快照提交到一個真實(shí)的 Git 倉庫這樣每次回滾在 Git 日志里都有記錄你想回到三天前的任意狀態(tài)git checkout就能拿回來。有人說 SQLite 并發(fā)不行但在本地單進(jìn)程寫多進(jìn)程讀的場景下完全夠用。真正要注意的是把 SQLite 放在內(nèi)存映射模式下打開 WAL 日志模式避免寫鎖阻塞讀操作PRAGMA journal_modeWAL; PRAGMA synchronousNORMAL; PRAGMA busy_timeout5000; PRAGMA cache_size-64000;這三行配置能讓 SQLite 在本地性能接近內(nèi)存數(shù)據(jù)庫而代價不過是多了幾個 wal 文件。我見過不少人一開始就用 PostgreSQL 或 MySQL結(jié)果運(yùn)維成本直線上升實(shí)際吞吐量需求只有每秒幾十次寫入——?dú)㈦u用牛刀。4.2 Agent 核心模塊的代碼骨架下面給出 OpenAlice 的核心啟動文件的簡化骨架這個骨架概括了整個 Agent 的模塊結(jié)構(gòu)和事件流的啟動方式# agent.py - OpenAlice 本地量化 Agent 入口 import asyncio from core.event_bus import EventBus from core.snapshot import SnapshotManager from core.circuit_breaker import CircuitBreaker from engines.market_data import MarketDataEngine from engines.strategy import StrategyEngine from engines.order import OrderEngine from risk.pre_trade import PreTradeRisk from risk.realtime import RealTimeRisk class OpenAliceAgent: def __init__(self, config): self.config config self.event_bus EventBus() self.circuit_breaker CircuitBreaker( daily_loss_limitconfig.daily_loss_limit, single_loss_limitconfig.single_loss_limit) self.snapshot_mgr SnapshotManager(config.snapshot_dir) self.market_data MarketDataEngine(config, self.event_bus) self.strategy StrategyEngine(config, self.event_bus) self.order OrderEngine(config, self.event_bus) self.pre_trade_risk PreTradeRisk(config, self.event_bus) self.realtime_risk RealTimeRisk(config, self.event_bus, self.circuit_breaker) def _register_event_handlers(self): # 策略信號先過預(yù)交易風(fēng)控 self.event_bus.subscribe(SIGNAL, self.pre_trade_risk.check_signal) # 預(yù)交易通過后轉(zhuǎn)為訂單指令 self.event_bus.subscribe(RISK_PASS, self.order.create_order) # 訂單回報后更新實(shí)時風(fēng)控狀態(tài) self.event_bus.subscribe(FILL, self.realtime_risk.on_fill) self.event_bus.subscribe(FILL, self.snapshot_mgr.on_state_change) # 熔斷觸發(fā)后全局停止新信號 self.event_bus.subscribe(CIRCUIT_OPEN, self.strategy.pause_trading) async def run(self): self._register_event_handlers() self.event_bus.start() await self.market_data.start() await self.strategy.start() await self.order.start() # 主循環(huán)保持存活 while True: await asyncio.sleep(1)這套啟動邏輯看起來簡單但它是整個系統(tǒng)穩(wěn)定運(yùn)行的基礎(chǔ)。信號流的路徑是SIGNAL → 預(yù)交易風(fēng)控 → RISK_PASS → 訂單模塊 → 券商 → FILL → 實(shí)時風(fēng)控 快照管理器。每一環(huán)都是松耦合的單獨(dú)拉出來改都不影響其他部分。4.3 參數(shù)配置與券商的模擬盤對接在跑真實(shí)盤之前強(qiáng)制要求先用模擬盤跑滿兩周。這不是慫而是給系統(tǒng)一個“安全測試期”。我自己的參數(shù)配置如下# config.yaml risk: daily_loss_limit: 0.03 # 日內(nèi)虧損 3% 熔斷 single_loss_limit: 0.15 # 單筆浮虧 15% 止損 max_position_count: 20 # 最大持倉數(shù)量 max_single_position_value: 0.05 # 單標(biāo)的倉位占總權(quán)益 5% circuit_cooldown_minutes: 30 # 熔斷冷卻時間 snapshot: dir: ./snapshots interval_seconds: 300 # 每 5 分鐘自動生成快照 keep_days: 30 execution: max_order_retry: 2 order_timeout_seconds: 5 slippage_bps: 5 # 滑點(diǎn)容忍度5 個基點(diǎn) market: symbols: [BTC-USDT, ETH-USDT, SOL-USDT] data_dir: ./data跟券商模擬盤對接時務(wù)必要驗(yàn)證三件事。第一訂單狀態(tài)的推送是否可靠。很多券商的 WebSocket 看似實(shí)時推送但斷線重連之后可能漏報成交如果你的系統(tǒng)沒做狀態(tài)同步就會以為單子還掛著但其實(shí)已經(jīng)成交了。第二下單接口的冪等性。網(wǎng)絡(luò)重試時同一個訂單號可能被重復(fù)提交必須在本地做訂單 ID 去重。第三模擬盤和實(shí)盤的行為差異。模擬盤的成交速度通常比實(shí)盤慢流動性深度也完全不是一回事所以模擬盤上跑通的參數(shù)只能作為實(shí)盤的初始參考實(shí)盤前半年要持續(xù)微調(diào)。4.4 實(shí)測運(yùn)行一次完整的信號到回滾演練理論說再多不如一次完整的演練。我記錄的這套流程是在模擬盤環(huán)境跑通的目的是驗(yàn)證“信號產(chǎn)生 → 風(fēng)控檢查 → 成交 → 異常觸發(fā) → 自動回滾”全鏈路。上午 10:00策略引擎檢測到 BTC 的 1 小時均線金叉信號向事件總線發(fā)出SIGNAL事件。預(yù)交易風(fēng)控模塊收到后做檢查當(dāng)前 BTC 未持倉、單筆名義價值未超限、日內(nèi)虧損未超閾值三項(xiàng)都通過于是產(chǎn)生RISK_PASS事件。訂單模塊收到后按參數(shù)要求以當(dāng)前市價對手價買入 0.5 BTC下單指令發(fā)送到模擬券商。10:00:03成交回報返回成交價 68420比信號產(chǎn)生時的標(biāo)記價高 5 個基點(diǎn)滑點(diǎn)在容忍范圍內(nèi)。實(shí)時風(fēng)控模塊更新賬戶狀態(tài)快照管理器生成一條新快照snap_20250317_100003parent 指向上一個狀態(tài)。下午 14:30市場突然跳水BTC 15 分鐘內(nèi)下跌 3%。實(shí)時風(fēng)控模塊檢測到 BTC 持倉浮虧達(dá)到 12%還在單筆止損線內(nèi)但賬戶日內(nèi)虧損已經(jīng)累計到 2.8%逼近 3% 的組合熔斷線。14:32日內(nèi)虧損達(dá)到 3.05%熔斷器狀態(tài)從CLOSED翻轉(zhuǎn)為OPEN系統(tǒng)發(fā)出CIRCUIT_OPEN事件。策略引擎收到后立即暫停信號產(chǎn)生訂單模塊撤銷所有未成交掛單。系統(tǒng)進(jìn)入“觀察模式”只允許平倉操作。14:35人工介入審查確認(rèn)本輪異常不是策略本身的問題而是行情劇烈波動。人工選擇回滾到snap_20250317_100003即上午建倉前的狀態(tài)之前一個快照snap_20250317_093000執(zhí)行回滾?；貪L邏輯將當(dāng)前 BTC 持倉全部市價平倉同時將策略參數(shù)和狀態(tài)恢復(fù)到快照記錄的值。14:36平倉成交成交價 66410實(shí)際虧損約 2.9%。系統(tǒng)生成一條新的快照snap_20250317_143602_rollback標(biāo)記為回滾操作。整個流程從異常觸發(fā)到完成回滾用了不到 4 分鐘。如果沒有這套自動化機(jī)制等人工反應(yīng)過來去查賬戶、去撤單、去手動平倉至少要多等 10 分鐘虧損可能擴(kuò)大一倍以上。這就是 Trading-as-Git 在實(shí)盤里真正的價值它不是讓你的策略賺錢而是讓你在策略出錯的時候用最小的代價恢復(fù)到可控狀態(tài)。5. 常見問題與排查技巧實(shí)錄5.1 快照生成頻繁導(dǎo)致磁盤爆滿怎么辦運(yùn)行一個月之后我遇到了最實(shí)際的問題快照目錄占了幾百 GB。原因是每 5 分鐘生成一個差異快照差異再小也有事件列表要存一天 288 個快照一個月就是 8640 個。解決方案是引入“快照合并”機(jī)制每天收盤后把當(dāng)天所有差異快照合并成當(dāng)日全量快照只保留最近 7 天的全量快照和一份完整的事件索引。這樣既能保證快速回滾到“任意時刻”的需求先定位到天級快照再應(yīng)用當(dāng)天差異快照又把磁盤占用量降到原來的 20%。具體實(shí)現(xiàn)的時候要注意快照合并的原子性。合并過程如果中途崩潰快照倉庫會處于不一致狀態(tài)。我的做法是先寫入臨時文件全部合并完成后用os.replace原子替換。這個細(xì)節(jié)在 Linux 上很好用Windows 上則要小心文件被占用的問題。5.2 事件總線背壓行情劇烈波動時事件堆積某次模擬盤測試遇到極端行情一分鐘內(nèi)產(chǎn)生了幾千個 tick 事件事件總線隊列瞬間堆積到幾萬條待處理事件系統(tǒng)延遲從正常的 5ms 飆升到 3 秒。這個問題直接導(dǎo)致策略信號延遲訂單錯過最佳價格。定位思路是通過監(jiān)控日志發(fā)現(xiàn)_queue.qsize()快速上升確認(rèn)是事件消費(fèi)速度跟不上生產(chǎn)速度。排查后發(fā)現(xiàn)瓶頸不在事件分發(fā)而在行情引擎的廣播效率——每個 tick 都會被廣播給所有訂閱者而訂閱者里有幾個做指標(biāo)計算的函數(shù)非常耗時它們拖慢了整個分發(fā)循環(huán)。修復(fù)辦法有兩個一是把耗時計算函數(shù)改成異步模式不阻塞主分發(fā)循環(huán)二是給 tick 事件增加“節(jié)流”配置當(dāng)行情劇烈波動時同一毫秒內(nèi)的 tick 只保留最后一幀。這兩個改動加起來事件隊列的堆積問題徹底解決。實(shí)測中“節(jié)流 異步”方案在單核機(jī)器上能把 1000 tick/s 的吞吐壓到 2ms 延遲對個人量化來說綽綽有余。5.3 回滾時持倉對不上快照狀態(tài)與真實(shí)賬戶不一致回滾機(jī)制上線初期我踩過一個大坑快照里記錄的持倉數(shù)量和真實(shí)券商賬戶對不上。查了半天發(fā)現(xiàn)是部分成交導(dǎo)致的。策略下了 10 手單實(shí)際只成交了 6 手快照生成時正確記錄了 6 手但回滾邏輯判斷“當(dāng)前持倉 10 手”于是多平了 4 手反而制造了額外的空頭敞口。教訓(xùn)是快照里不僅要記錄持倉數(shù)量還要把待成交訂單也納入快照范圍?；貪L邏輯因此改寫為快照對比步驟 1. 對比當(dāng)前持倉與快照持倉 → 多出的部分平倉缺少的部分補(bǔ)回 2. 對比當(dāng)前待成交訂單與快照待成交訂單 → 撤銷所有非快照訂單 3. 對比當(dāng)前策略參數(shù)與快照策略參數(shù) → 恢復(fù)到快照版本這個“三步對比法”徹底解決了部分成交導(dǎo)致的持倉錯位問題?，F(xiàn)在回滾邏輯運(yùn)行之前還要拉取一次券商的持倉快照做交叉驗(yàn)證確認(rèn)真實(shí)持倉和本地記錄一致才執(zhí)行后續(xù)操作。5.4 回測與實(shí)盤差異大到離譜是怎么回事“回測收益 80%實(shí)盤只有 20%”這是我收到過最多的問題。大多數(shù)情況下不是策略代碼寫錯了而是回測環(huán)境過度理想化。我總結(jié)了三個最常見的原因按影響大小排序第一是手續(xù)費(fèi)與滑點(diǎn)被忽略。很多初學(xué)者在回測框架里用 0 手續(xù)費(fèi)這放大了高頻交易策略的收益但實(shí)盤里手續(xù)費(fèi)和滑點(diǎn)直接吃掉利潤。建議在回測里加入不低于真實(shí)費(fèi)率的手續(xù)費(fèi)和雙邊 5 個基點(diǎn)的滑點(diǎn)。第二是沒有模擬撮合排隊?；販y時用了“信號產(chǎn)生即成交”的假設(shè)但實(shí)際買入時你的訂單可能排在隊列后面價格已經(jīng)被頂上去。解決方法是引入“部分成交 排隊延遲”模型模擬限價單被部分成交的情況。第三是數(shù)據(jù)前視偏差。用了未來數(shù)據(jù)比如用當(dāng)天收盤后的數(shù)據(jù)來計算當(dāng)天的信號這在技術(shù)指標(biāo)上很容易犯。OpenAlice 在回測引擎里強(qiáng)制開啟了“滑點(diǎn)模型”和“手續(xù)費(fèi)模型”并且默認(rèn)不允許關(guān)閉。這個看似“不近人情”的設(shè)計實(shí)際上幫團(tuán)隊過濾了至少一半以上的“紙面盈利策略”。5.5 實(shí)盤期間策略崩潰的自動恢復(fù)流程本地量化最容易崩的就是策略進(jìn)程本身。我遇到過策略代碼因?yàn)槟掣惓?K 線比如成交量數(shù)據(jù)為 0拋出異常進(jìn)程直接掛掉的情況。如果此時市場還在交易你的持倉就成了“沒人管”的狀態(tài)。解決思路是引入進(jìn)程守護(hù) 狀態(tài)恢復(fù)兩層機(jī)制。第一層用 systemd 或 supervisor 監(jiān)控策略進(jìn)程檢測到退出自動重啟第二層在重啟時加載最近的快照對比券商真實(shí)持倉和本地記錄。如果不一致先暫停策略向操作者發(fā)送告警等待人工確認(rèn)——絕不讓重啟后的策略立刻接入實(shí)時行情繼續(xù)跑。因?yàn)槟悴恢辣罎⑶鞍l(fā)生了什么貿(mào)然恢復(fù)操作可能造成二次傷害。這個“重啟后不自動恢復(fù)交易”的設(shè)計是我從一次極端行情中吸取的教訓(xùn)。當(dāng)時進(jìn)程崩潰后自動重啟策略立刻重新開倉結(jié)果市場已經(jīng)反轉(zhuǎn)新開的倉位直接吃滿止損比崩潰前虧得更多。從那以后**“恢復(fù)”永遠(yuǎn)先于“交易”**成為本地量化的一條鐵律。6. 這個架構(gòu)還能怎么擴(kuò)展最后分享幾個我在 OpenAlice 基礎(chǔ)上驗(yàn)證過、但還沒有完全落地的擴(kuò)展方向。如果你自己也在折騰交易系統(tǒng)這幾個點(diǎn)值得留個心。一個是多策略分支并行驗(yàn)證。Git 的 branch 天然適合做策略分組——每個策略變體跑一個獨(dú)立分支共用同一套市場數(shù)據(jù)和風(fēng)控框架。當(dāng)前只做了同一策略的不同參數(shù)版本并行下一步打算把完全不同的策略趨勢跟蹤、套利、網(wǎng)格也納入分支管理每個分支有自己的狀態(tài)快照和回滾記錄主分支只合入經(jīng)過驗(yàn)證的策略版本。另一個是風(fēng)控規(guī)則的動態(tài)熱更新。目前風(fēng)控參數(shù)配置在 yaml 文件里修改后要重啟系統(tǒng)才能生效。但實(shí)際上很多參數(shù)比如單筆止損比例完全可以在盤中進(jìn)行調(diào)整——市場波動率變化時止損比例應(yīng)該隨之變動而不是固定死在一個值上。把風(fēng)控參數(shù)做成由事件觸發(fā)的動態(tài)規(guī)則就能避免“行情變快、止損跟不上”的尷尬。還有一個方向是把回測引擎和實(shí)盤引擎統(tǒng)一成同一套代碼。現(xiàn)在很多人回測用一套代碼實(shí)盤用另一套結(jié)果兩邊的行為差異成了“薛定諤的貓”——你不知道實(shí)盤里的策略行為和回測時的策略行為是不是同一個東西。如果內(nèi)核統(tǒng)一回測和實(shí)盤共享同一套信號計算模塊差異只會出現(xiàn)在撮合環(huán)境回測用歷史數(shù)據(jù)撮合實(shí)盤用真實(shí)行情撮合問題定位就簡單得多。我個人在實(shí)際運(yùn)行這套架構(gòu)半年之后的體會是它并不能讓你抓到更多的大漲但它能讓你在大跌的時候睡得著覺。量化交易的盈虧曲線本質(zhì)上是策略期望和風(fēng)控成本的加總而大多數(shù)個人量化者虧損的根源不是策略沒有期望而是風(fēng)控成本高到把策略的期望全部吃穿。Trading-as-Git 提供的不是“圣杯”而是一條“安全帶”——系上它你至少能在系統(tǒng)出錯的時候活著回來把賬戶交到下一個干凈的快照手里。