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