如果你带过一个量化策略上实盘大概率经历过这种场面回测曲线漂亮得像教科书真实账户一开连续止损、滑点吃满、心态炸裂最后不甘心又手动加仓一夜回到解放前。“暴仓”听起来是行情问题但拆开看绝大多数是工程问题——状态不可追溯、参数不可回滚、风控不可强制。我最近把一个本地量化 Agent 项目 OpenAlice 重新拉了一遍核心思路只有一句话把交易系统当成 Git 仓库来管理。也就是标题里说的 Trading-as-Git。这篇文章我会完整拆解它的架构设计、风控闭环是怎么落地的以及我在实操中踩过的坑。适合正在写策略但不敢上实盘的人也适合做 Agent 开发但对交易领域不熟的技术人。没有玄学指标只有工程约束。1. 为什么“能赚钱的策略”一上实盘就暴仓1.1 三起暴仓事故本质都是“状态失控”先说三个我很早就见过的真实事故不是编的都是我身边朋友的账户。第一个事故是马丁策略。逻辑很简单亏了加倍仓位赢回一次就回本。回测时资金曲线涨得飞快参数怎么调都好看。但行情一旦出现连续反向账户会以指数级亏损速度冲向零。他当时没有任何最大仓位约束也没有单日亏损熔断等反应过来保证金已经不够了。这本质上是“仓位状态失控”。第二个事故是参数回归。某策略在沪深300上做回测把均线周期从20调到18夏普从1.2变成2.1他觉得很爽直接拿去实盘。结果那两周刚好是样本内的特殊行情上线后策略持续亏损他却不记得之前那版参数是什么、为什么当时选20。因为参数没有版本管理改完就回不去了。这是典型的“回滚能力缺失”。第三个事故有点反直觉策略本身没大问题但 Agent 进程半夜崩溃重启重启后状态丢了重复下了两笔同样的订单仓位翻倍后又赶上跳空直接击穿止损线。这是“执行状态不一致”。你会发现三起事故没有一个是因为策略数学期望为负而是因为系统对状态的管理完全是裸奔的——没有快照、没有审计、没有熔断、没有回滚。暴仓不是赌错了而是失控了。1.2 交易系统是不可回溯的状态机把交易系统抽象一下它本质上是一个状态机输入是行情内部状态是账户权益、持仓、订单状态、策略自身的记忆变量输出是下单动作。状态机最怕两件事状态丢失和状态回滚不了。普通软件工程怎么应对这种问题用 Git。代码改动被记录成 commit想回到三天前的版本一条命令搞定出了 bug 可以 diff 出来看是谁在哪个时间点改了哪一行。交易系统比代码更需要这种能力因为交易涉及到真金白银而且市场是时间不可逆的。但大多数人做量化只把 Git 用在了管代码上没有把 Git 用在全生命周期上。策略代码有版本但参数配置、风控规则、订单流水、账户快照、每次调参的理由全都没有被纳入版本管理。一旦出问题你根本不知道当前实盘跑的是哪一套逻辑也不知道该回滚到哪里。1.3 Git 思维能带来什么Trading-as-Git 就是把这些状态全部版本化。具体展开是这几层策略代码和配置文件进 Git分支隔离开发和实盘版本每一次回测结果、每一笔实盘订单、每一个账户快照都形成不可变记录主分支保护实盘只能用经过验证的 tag 部署触发风控时先自动止血再把状态回滚到上一个 stable commit。这样做的收益不只是“能回滚”而是让交易过程变得可审计、可复现。任何一个时刻你都能回答三个问题现在跑的是什么版本的策略它的风控参数是什么上一次仓位调整是什么时候。这听起来很基础但 80% 的个人量化交易者做不到。2. OpenAlice 架构拆解本地量化 Agent 怎么设计2.1 模块划分与职责OpenAlice 是我本地跑的一个开源思路结构上刻意保持精简没有上重型 Agent 框架。原因是风控路径必须完全可控、可审计框架越重黑盒越多越难排查问题。它的目录结构大致是openalice/ ├── core/ │ ├── agent.py # 主循环编排 │ ├── risk_engine.py # 风控引擎 │ ├── executor.py # 订单执行与幂等保护 │ ├── snapshot.py # 状态快照 │ └── journal.py # 行为日志与审计 ├── strategies/ │ ├── ma_cross.py │ └── momentum.py ├── configs/ │ └── risk.yaml ├── data/ # 行情缓存不入 Git ├── backtests/ # 回测产物 └── live/ # 实盘运行日志与快照core/agent.py 是大脑负责按心跳节奏跑主循环risk_engine.py 是闸门任何信号和订单都必须过它executor.py 负责对接券商接口同时保证同样的订单指令不会被重复执行snapshot.py 定时把账户状态、持仓、策略内部变量写到磁盘journal.py 则负责把所有决策记录成可审计的事件流。为什么要把风控做在 Agent 内部而不是依赖交易所的风控因为本机 Agent 是最后一道自主防线。交易所的强平是你爆仓之后才发生的本地风控是在爆仓之前拦截的。两者不是替代关系是前后关系。2.2 Agent 主循环调研、决策、执行、记录OpenAlice 的主循环设计得比较朴素每一轮做四件事取行情、跑策略、过风控、执行并记录。核心伪代码是这样while not shutdown: tick feed.next() if not risk_engine.can_trade(): journal.append(risk block, reasoncooldown or panic) continue signal strategy.evaluate(tick) if signal is None: continue order risk_engine.pre_check(signal) if not order.approved: journal.append(order rejected, order) continue executor.submit(order) journal.append(order submitted, order, context...) snapshot.persist() commit_if_epoch_reached()你可能会注意到我没有把“调研”作为一个独立步骤放进去而是拆成了信号生成和风险预检。这是故意的。Agent 框架里很多教程会把“规划-执行-反思”拆得很开但在交易场景里决策路径必须尽量短任何多余的推理都有可能错过止损时机。关于 Agent 框架和编排的边界我多说一句OpenAlice 不需要复杂的工具调用链也不需要大模型来生成交易信号。行动路径里如果夹了一层不可解释的 AI 推理风控就没法做形式化验证。所以我把 Agent 定义为“自主执行引擎”它按照固定规则循环而不是一个通用对话 Agent。2.3 本地运行还是云端运行OpenAlice 选择完全本地运行我用一张表说清楚这个取舍维度本地 Agent云端信号端订单延迟低直连交易所网关高多一跳网络数据主权全在自己机器可能被第三方看到成本只有电费和机器钱按量计费长期不便宜故障点断电、断网、磁盘坏服务商宕机、带宽受限可审计性所有文件可查黑盒日志难取证我见过很多方案是云端生成信号、本地执行这其实也没问题。关键是要明确“决策在哪里做、风控在哪里做、记录在哪里存”。OpenAlice 的做法是全部集中在本地云端最多做行情数据源的拉取。这样即使云端挂了本地还能按最后一份快照继续运行或者安全关机。3. 风控闭环把“不暴仓”变成工程约束3.1 闭环四步准入、监控、熔断、复盘风控闭环的四个阶段刚好可以和 Git 操作一一对应阶段做的事情对应的 Git 流程准入策略上线前通过回测校验pre-push 钩子自动回测监控盘中实时检查仓位和亏损进程内风险引擎逐笔检查熔断突破阈值立即止损并暂停回滚到上一个 stable tag复盘分析原因并沉淀规则写复盘报告并提交到仓库如果只看前三个你只能解决“当场不爆”但解决不了“下次还会不会再爆”。复盘那一步才是闭环的闭合点。熔断不是结束熔断之后的 diff 才是真正有价值的东西当天的行情切片是什么、策略为什么错了、是参数问题还是逻辑问题、需要改哪一行代码。这些问题没有记录就是一笔糊涂账。3.2 风控参数怎么定从拍脑袋到可推导OpenAlice 的风险配置放在 configs/risk.yaml 里示例risk: max_position_ratio: 0.8 # 总仓位占账户比例上限 max_daily_loss_ratio: 0.02 # 单日亏损上限触发熔断 max_drawdown_ratio: 0.10 # 历史回撤上限 cooldown_seconds: 300 # 熔断之后禁止交易时间 max_consecutive_losses: 3 # 连续止损次数上限 circuit_breaker: enabled: true equity_drop_ratio: 0.05 # 权益瞬时回撤阈值 pause_after_trigger: true这些数字不是随便填的背后要有计算过程。比如单日亏损上限假设账户 10 万你按照“每天最多亏总资金的 2%”来定那就是 2000 元。这个数值要小于你心理能承受的最大亏损否则真到阈值时你会犹豫、会关掉程序、会手动乱来。仓位计算的逻辑遵循固定分数风险管理账户权益 E单笔风险率 r单笔风险预算 E × r设入场价 P止损比例为 s合约乘数为 M止损距离 P × s × M可开仓手数 单笔风险预算 / 止损距离。举个例子账户 10 万r0.5%单笔风险预算 500 元。若某合约价格 100、止损 1.5%、乘数 10则每手止损金额是 15 元500 / 15 ≈ 33 手。风控引擎会计算这个手数是否超过 max_position_ratio超了就拒绝。这套逻辑不保证你单笔不亏但保证你不会因为一笔交易伤筋动骨。3.3 熔断之后怎么办熔断触发的一瞬间OpenAlice 会执行一系列动作停止新开仓、平掉止损线之外的持仓、打一条 panic 级别的日志、生成一份现场快照然后把运行版本指向上一个 stable tag。这个“回滚到上一个 stable commit”的动作很重要但它不是自动切回去继续跑。切回去只是把程序状态恢复到确定位置交易要不要继续必须由人来决定。我的习惯是熔断后至少冷静一个交易日把当天的行情数据、订单日志、策略参数全部导出来跑一遍离线回测确认是行情问题还是策略失效再决定要不要以更小的仓位恢复运行。4. 实操本地跑通 OpenAlice 最小闭环4.1 初始化环境与 Git 仓库先准备环境Python 3.11 或以上Git还有你自己的行情数据源。把项目克隆下来后第一件事就是初始化 Git 仓库并建立分支约定。我用这样的分支模型git init git checkout -b develop git checkout -b main git push origin main约定是main 分支是实盘生产版本不允许直接提交develop 是策略开发分支feature/xxx 是单个策略或风控改动分支。实盘部署时只允许从 main 分支的稳定 tag 启动。这套约定一开始看起来繁琐但等你线上出问题再想恢复版本就知道有多值钱了。打开编辑器的第一步是配置 .gitignore把 data/ 和 live/ 目录排除掉原因后面专门讲。4.2 提交门禁与策略示例在 OpenAlice 里策略上线前必须过“提交门禁”。我会在 .git/hooks/pre-push 里放一段脚本大意是检查当前策略的最近一次回测结果是否符合风控要求不符合就拒绝 push。脚本大致是#!/bin/bash echo Running validation pipeline... python -m openalice.cli run_backtest \ --strategy $STRATEGY_NAME \ --config configs/risk.yaml if [ $? -ne 0 ]; then echo Backtest validation failed, push aborted. exit 1 fi echo Validation passed.一个最简单的双均线策略代码长这样import pandas as pd def strategy(data: pd.DataFrame, fast: int 10, slow: int 30): data data.copy() data[fast_ma] data[close].rolling(fast).mean() data[slow_ma] data[close].rolling(slow).mean() data[signal] 0 data.loc[data[fast_ma] data[slow_ma], signal] 1 data.loc[data[fast_ma] data[slow_ma], signal] -1 return data这里是很多新手第一次踩坑的地方如果你在“当前这根K线”里同时用它自己的收盘价计算均线并产生信号然后立刻以收盘价成交那就犯了未来函数错误。因为信号是在这根K线收盘之后才知道的实盘中你根本不可能在收盘那一刻成交。OpenAlice 的规则是信号统一滞后一根K线执行回测和实盘执行逻辑完全一致。4.3 从上到下的实盘检查清单跑通回测之后我不建议直接拿真金白银上。我的流程是模拟盘跑两周用小资金实盘跑一个月再逐步放大。实盘启动前过一遍这张清单风控配置文件是否正确加载熔断阈值是否生效订单接口是否走测试环境交易品种和手续费是否配置正确日志系统是否正常journal 每条记录是否落盘进程守护是否启动Agent 崩溃后能否自动重启并恢复快照仓位计算模块跑一遍单元测试确认手数不超过上限。千万别嫌麻烦。我见过太多人跳过了模拟盘结果第一天上实盘就连续触发止损然后暴躁地关闭风控手动一顿乱操作把最后一层保护也拆掉了。4.4 运行中改参数的标准动作实盘运行中你可能想调整某个参数。标准动作不是直接改 live 配置而是在 feature/xxx 分支上修改参数用历史数据重新回测确认风控指标达标合并到 develop跑样本外数据检验确认没问题再合并到 main重新打 tag手动重启 Agent让它加载新 tag。这套流程看起来很重但它的作用是多了一道“冷静期”。很多参数调整是一时冲动等你做完回测和检查冲动基本也消退了。Git 分支的另一个好处是如果新参数上线后亏了你可以立刻切回上一个 tag而不是翻聊天记录找“当时的参数”。5. 我踩过的坑常见问题与排查实录5.1 回测漂亮实盘翻车这个问题的原因集中在三类未来函数、过拟合、成本低估。未来函数前面已经说过了典型特征就是回测曲线异常平滑每笔交易的胜率高得离谱。排查手段是把策略里每一处用到“当前K线收盘价”的地方都检查一遍确认信号是否滞后执行。另一个排查技巧是随机打乱信号顺序做“蒙特卡洛置换检验”如果去掉局部时序后收益依然很高说明回测结果不是来自真实的行情结构而是来自某个计算误区。过拟合则表现为参数稍微一动收益就大幅下降。我用的是样本外验证加滚动窗口回测把数据切成三段前两段训练参数第三段只看不做如果第三段表现不行就说明参数是在背答案。最后是成本包括手续费、滑点和冲击成本。很多人回测里手续费设得很低实盘却发现每次成交价都比你的触发价差了几个 tick长期下来就是巨大损耗。我的习惯是回测时故意把成本乘 1.5如果这样还能赚钱实盘才值得考虑。5.2 Agent 崩溃与重复下单本地 Agent 最常见的坑就是进程挂掉后状态错乱。之前说的半夜重复下单根因是重启后内存里“上一笔订单已提交”的标记丢了Agent 以为刚才那笔没发出去于是又发了一遍。解决方法是两层第一层是幂等每个订单指令生成唯一的 order_id比如 f{日期}-{策略名}-{序号}执行器记录所有已提交的 order_id重复指令直接拒绝第二层是状态快照加 WAL 语义agent 每完成一个周期就把以下内容写到磁盘当前仓位、账户权益、最新订单状态、策略内部计数器。重启时先读快照再读日志重新放一遍未完成订单的“最终状态”而不是重新下单。我用 SQLite 存快照和 journal事务保证一致性。SQLite 对本地单进程来说绰绰有余没必要上更重的数据库。5.3 Git 仓库膨胀与数据管理Trading-as-Git 不等于把什么都塞进 Git。行情数据和回测产物是二进制大文件硬塞进 Git 会让仓库迅速膨胀到几十个 GBclone 都 clone 不动。我的规则是代码、配置、回测报告、复盘记录进 Git行情数据放 data/用单独的数据目录管理回测中间产物放 artifacts/只保留摘要和结论live 快照放 live/定期归档到本地冷存储。.gitignore 里把这几项排除掉。如果你确实需要保存某一段行情数据用于复盘按日期打成压缩包存到单独目录不要直接 commit 到仓库里。这样仓库始终保持轻盈恢复分支时也快。5.4 时钟漂移与行情抖动还有一个小坑本地机器的时钟如果偏了几秒在普通应用里无所谓但在策略里会导致信号时间戳和行情时间戳对不上。比如你的策略判断“9点35分出现金叉”程序记录的是9点35分零2秒回测时用的又是另一个时间口径就对不上了。OpenAlice 的处理办法是所有逻辑判断统一使用行情源自带的撮合时间戳而不是本机当前时间数据的区间切分、指标计算完全基于时间戳无状态进行。机器时钟仍然要做 NTP 同步但业务逻辑不能依赖本机时钟。这样做之后即使某天行情抖动造成迟到的tick系统也不会产生混乱。我个人在实际操作中的体会是交易最大的敌人不是市场是自己对失控的无知。OpenAlice 的 Trading-as-Git 并没有发明什么神技它只是把软件工程里最成熟的那套状态管理手段原封不动地搬到了交易系统里。如果你正准备把自己的策略推上实盘我的建议是先别急着优化策略指标先把熔断、快照、回滚这三件事做扎实哪怕用一个最简单的均线策略都行。最后再分享一个小技巧把风控规则写成单元测试每次改完代码先跑一遍测试比任何嘴上说要控制风险都管用。系统不会说谎它只会诚实地执行你写下的规则。
