凌晨 1 点 47 分手机连续震动本能反应是出事了。打开仓位页面策略还在源源不断地发出加仓信号可用保证金却已经归零。那一夜我真正理解了什么叫爆仓——不是浮亏而是这行字“由于保证金不足您的仓位已被强制平仓。”正是这次经历逼出了我后来整套系统的设计思路才有了今天要聊的这个 OpenAlice 项目。OpenAlice 是我自己维护的一套本地运行的量化 Agent 框架最核心的设计理念叫 Trading-as-Git以下简称 TaG。一句话解释把策略的开发、回测、试运行到实盘部署完全按软件工程里的 Git 工作流来管理。策略是代码参数是分支回测是测试用例实盘是有风控约束的生产发布而爆仓就是线上事故。这篇内容我会完整拆解这套框架的架构分层、Agent 的核心链路以及风控闭环怎么把“别死”做成一个系统。适合已经能写策略、但苦于不知道怎么从回测走向实盘的人也适合没写过代码、但对量化系统设计思路感兴趣的读者。1. 为什么要用 Git 的思维做交易1.1 回测亮眼、实盘就崩爆仓的四类根源先别急着看架构先理解这个项目为什么存在。我见过的绝大多数爆仓不是市场太无情而是人的流程太脆弱。翻看过去三年的回测和实盘记录崩掉的策略基本逃不出这几类回测时使用了未来数据。比如用当日收盘价来驱动盘中决策或者用了财务数据正式发布之前就已经存在的数值。这类策略曲线画得极其漂亮一到实盘就全面失效。参数严重过拟合。多周期多品种滚动优化把夏普比率从 1.2 一路调到 3.8但做过样本外测试就知道这种“优化”只是在反复记忆历史噪声根本没有预测能力。杠杆过高。回测里用 3 倍杠杆收益翻倍实盘也照做结果遇到一次 5% 的行情回撤就击穿保证金。情绪化干预。策略信号与手动加仓叠加、止损被手动取消、亏损后加大仓位“摊平”这些行为在 Git 仓库里都会留下痕迹——就像 dev 分支没有经过任何 review 就直接 push 到 main然后被当成生产版本发布了。细品就会发现这些问题的本质不是一个“更好的策略”能解决的。它们全都出在流程和状态管理上。我管这个叫“策略上下文不可控”我不知道当前跑的版本是哪一版、参数是哪一批、回测用的数据有没有污染、仓位阈值是被谁改掉的。于是我把做软件工程的那套东西平移了过来。1.2 Trading-as-Git 想解决的三件核心事Trading-as-Git 并不是给策略目录加一个 git init 就算完事。真正的含义是把交易的完整生命周期映射成软件开发生命周期策略即代码每个策略是仓库里的一个模块包含信号生成逻辑、风控参数、执行规则三部分。版本由 commit 唯一标识任何时刻都能回退。回测即测试仓库里每一套策略都要先过回测、再上模拟盘、最后小仓位实盘像 CI/CD 流水线一样分级晋升。发布即部署实盘环境只允许运行经过签名的 release 分支禁止任何未经验证的临时修改直接生效。这三条映射解决了前文说的四类爆仓根源中的三类版本混乱、验证缺失、修改不可控。剩下的一类也就是杠杆和资金管理问题在风控闭环里解决。有人可能会问这套体系是不是应该做成微服务架构或者分布式架构我在早期也这么设计过把数据、策略、执行拆成多个独立服务。后来发现对于单账户、单机运行的本地量化 Agent分布式带来的除了运维复杂度没有任何额外收益。关键不是架构多先进而是流程约束多严格。TaG 的取舍标准只有一个能不能在每个环节留下可审计的痕迹。1.3 为什么是本地 Agent三个关键取舍很多量化框架喜欢把回测、实盘都放在云端或者直接依赖现成的量化平台服务。OpenAlice 在早期也走过这条路后来彻底迁移到本地 Agent 架构原因有三个。第一是数据安全。策略模型、持仓明细、交易日志都是高度敏感的资产放在别人的服务器上我始终不放心。第二是频率问题。本地部署意味着策略信号生成到订单提交之间的网络跳数更少对秒级和分钟级策略来说延迟稳定比绝对值更重要。第三是成本与自由度。本地跑 Agent不需要为了按调用次数付费的接口去改写策略逻辑也不受平台模板的限制想怎么迭代就怎么迭代。代价也很明确运维责任全在自己身上。数据要自己维护故障要自己处理回测环境要自己保证一致性。但对我来说可控性远比便利性重要。本地化是 TaG 能够成立的前提如果环境都不在自己手里那“版本可复现”就是一句空话。2. OpenAlice 的 Agent 架构全景2.1 分层架构全景五个层次各管哪一段OpenAlice 的整体架构按职责分成五层数据层、策略层、执行层、风控层、监控层。用一个后厨的比喻来理解。数据层是采购员负责买来最新鲜的食材也就是行情数据并且洗好切好对应数据清洗和对齐。策略层是厨师长持有菜谱也就是策略代码决定做什么菜对应交易信号的生成。执行层是传菜员把菜准确送到对应餐桌对应把信号变成订单并顺利成交。风控层是食品安全员所有菜上桌前都要过一道检验对应任何信号、任何订单都必须通过风控校验。监控层是店长助手一直盯着整体运营出了问题马上报警对应指标监控、异常告警和熔断日志。这五层各司其职但有一条重要原则层与层之间通过定义良好的接口通信禁止跨层调用。策略层不能直接修改数据层的数据执行层不能跳过风控层直接下单监控层更不能反过来去改策略参数。每层只知道自己上下相邻的两层这种克制让系统在出问题时能快速定位故障边界。2.2 数据引擎本地数据清洗、对齐与防未来数据实盘爆仓案例里数据问题常年排在第一。最常见的就是数据对齐错位用 1 分钟 K 线算出来的信号却拿到了 5 分钟粒度的时间戳上执行又或者 t 时刻生成的信号在 t1 时刻才被真正执行而回测却压根没模拟这个延迟。OpenAlice 的数据引擎对行情数据做了三层处理。第一层叫统一入参。所有外部数据无论来自哪个数据源统一转换成标准事件流对象包含 symbol、timestamp、price、volume、side 等字段并强制按时间戳排序后落库。第二层叫时间对齐。系统里所有策略信号只能消费“截止到指定截止时间”的数据做法是给事件流里的每个 tick 标记一个 watermark任何策略查询只能读取 watermark 之前的记录从机制上杜绝未来数据。第三层叫数据画像。每次回测前数据引擎会对数据集自动生成一份快照包含数据范围、缺口率、异常跳变数量。如果某只股票存在停牌期数据缺失快照里会有明显标注策略作者一眼就能看见。这三层处理完成后数据层才对上层提供查询接口。核心目标是保证任何策略在任何时间点看到的数据都和实盘当时可获知的数据保持一致。这个原则说起来简单实测是最难守的一条。2.3 策略仓库把策略代码当主干分支来管理策略层是 TaG 思想的直接承载体。每个策略是符合约定接口的模块包含三个文件signal.py 负责信号逻辑risk.py 负责策略层面个性化风控参数config.yaml 负责策略参数配置。策略管理完全通过 Git 仓库实现。每个参数修改、每个逻辑调整都是新的 commit分支策略定为main 始终对应当前实盘正在运行的策略集合受分支保护规则限制禁止直接 push。每个策略在独立开发分支上迭代开发完成后发起 merge request在独立环境里走完回测和模拟盘流程后才能合并到 main。参数实验用 tag 标记例如 v0.3.1-param-grid-007确保任何一个回测结果都能追溯到当时的具体参数。这里有个容易被忽略但极其重要的点策略代码要和当时的数据快照、依赖库版本一起打版本。策略版本号必须能还原出完整的运行环境否则半年后想复盘一个问题却发现当时的回测环境早就变了那所有记录都失去意义。OpenAlice 的做法是每次回测时记录一个 manifest 文件包含策略 commit、数据快照 ID、依赖库版本、Python 版本和机器信息。2.4 Agent 执行核心从信号生成到订单落地执行层是 Agent 中最容易被低估的一环。很多人以为策略信号生成了订单就能按回测价格一样成交实际上执行延迟、滑点和部分成交对收益的侵蚀往往超过策略本身 alpha 的贡献。OpenAlice 的执行层做了三件事。第一件是信号缓冲。策略层产出的信号不会直接进入下单流程而是进入一个信号队列等待执行校验。队列里每个信号都携带生成时刻和“最晚有效时间”超过有效时间的信号自动作废避免策略卡顿后延迟信号被错误执行。第二件是订单拆分与调度。对资金量较大或者流动性差的品种直接一整笔订单塞给券商冲击成本会非常明显。执行层按预设拆单算法把大单拆成若干小单再按节奏发送对分钟级策略来说固定间隔拆单是又简单又稳的方案。第三件是状态机管理。每个订单经历 created、validated、submitted、filled、settled 的状态流转任何一环失败都进入异常队列而不是被静默吞掉。后面风控层能不能正常工作依赖的就是这里订单状态的准确性。Agent 安全这部分我也多说一句。本地 Agent 的安全不光是访问控制更要防止 Agent 自身权限失控。所以在执行层任何外部操作指令都要经过独立于策略逻辑的校验模块权限严格最小化。3. 风控闭环怎么落地3.1 事前风控回测防污染与过拟合检测先明确一个观点风控不是从实盘才开始的而是从回测的第一行代码执行起就在起作用。事前风控是 OpenAlice 体系里最花功夫的部分包含四个主要检查项。第一是数据防污染检查。策略在回测时被强制要求通过数据引擎访问数据数据引擎内置 watermark 机制。即便如此每次回测结果还要做一次“未来数据审计”随机抽取多个回测日检查当天的信号是否仅由当天及之前的数据产生。我之前在一个动量策略里就发现过有人在计算 20 日均线时不小心把当日收盘价提前用到盘中信号里那条曲线肉眼看根本看不出来但审计一查就现形。第二是过拟合检测。OpenAlice 要求回测报告输出训练集和样本外 OOS 曲线的对比并计算两者相关性。训练集夏普 3.5、OOS 夏普只有 0.4直接判定不合格。另一个常用手段是参数扫描的“峰面检查”如果最优参数附近一圈的参数表现急剧恶化说明模型对参数高度敏感过拟合概率极大这类策略也无条件拒绝。第三是交易成本模型校验。回测中必须按实盘水平计入手续费、滑点和冲击成本。见过太多策略在零成本条件下年化 80%加上千分之一滑点后直接变成负收益。这不叫策略失效是本来就跑不赢成本。OpenAlice 默认回测配置里滑点按品种分别设置手续费按真实券商标准填写。第四是异常收益审查。策略年化收益超过 100% 且最大回撤小于 5%这本身就是一个危险信号系统直接标记为高风险要求人工复核全部逻辑。你以为你是天才更可能是你的回测有 bug。3.2 事中风控熔断、限额与异常检测的落地事中风控是整个闭环里最刚性的一环。简单说它在实盘执行时独立于策略逻辑运行策略无权关闭风控也无权修改风控参数。OpenAlice 的风控引擎内置几个核心规则。账户级总杠杆限制无论策略信号想加多大仓位账户整体名义市值除以净资产的比例都不能超过设定上限这个上限写死在配置文件里只能通过管理员双人复核后修改。单策略止损熔断为每个策略设置每日最大亏损阈值比如净资产 2%一旦触发风控引擎停止该策略的新增信号执行已持仓部分按预案处理同时通知管理员。敞口异常检测如果某个品种仓位在短时间内从 1% 跳到 15%风控引擎判定为策略逻辑异常或数据异常触发暂停。这种机制专门防两类问题行情数据出现极端跳变以及策略 bug 导致下单数量级错误。命令审批流也是一个核心机制。所有涉及参数修改、仓位上限调整的操作都不能直接执行必须先进入指令队列由管理员确认后才会生效。机器需要防人人也需要防自己的冲动这条规则后来救了我好几次。这里要特别强调一条经验熔断规则宁可配置得保守也不要激进。我最初把单日亏损阈值设成 3%觉得再小就太容易打断策略发挥。后来连续碰到两次回撤 5% 级别的行情一次触发熔断一次没触发对比下来发现被熔断那次事后并不影响策略继续跑没触发那次差点再次击穿保证金。保守止损会带来更多次数的“miss”但换来的是不出大事的确定性。3.3 事后风控归因报告驱动策略迭代如果事前和事中是防守事后风控就是复盘与迭代。很多开源框架的问题是不管事后亏了钱只知道策略失效了但不知道具体为什么。OpenAlice 对每个实盘交易日自动生成一份归因报告重点回答三个问题。第一今天赚或者亏的钱来自哪几个策略每个策略各自的贡献是多少共有的敞口有没有互相抵消第二实盘成交价和回测模拟成交价之间的差距有多大这部分差距是执行问题还是市场行情问题第三哪些信号被风控拦截了拦截得对不对被拦截的信号后续表现如何如果被拦截的信号大多事后证明是亏损的说明风控拦截有效如果拦截后市场大涨就需要人工评估阈值是不是太紧。归因结果会写回策略仓库作为下一次开发分支的依据。这样做的好处是策略迭代永远基于真实数据而非感觉。没有归因的交易记录本质上就是噪音。3.4 串起来看风控闭环的完整链路把事前、事中、事后串起来就是一条完整的闭环链路回测档案生成。包含数据快照、代码版本、参数、绩效报告全部存档。人工评审。通过或者打回评审意见写入仓库。模拟盘跟踪。至少连续 30 个有效交易日收益曲线的最大回撤低于阈值后才能晋级。小仓位实盘验证。默认控制不超过总资金的 5%。逐步加仓。每次加仓都需要重新评审。实盘监控。熔断、限额、异常检测全程运行。每日归因。产出归因报告。复盘结论回到策略开发分支再次进入回测。这个闭环中任何一个环节未完成策略就停留在上一级系统拒绝执行下一级的交易。这种“卡关机制”是防止盲目实盘的核心所在。你可能会问这套流程会不会太慢确实慢但我的切身体会是慢才是安全。实盘爆仓只需要一次而任何一次爆仓背后都必然存在流程被绕过的环节。4. 从零搭建这套系统的实操记录4.1 硬件与软件选型本地部署的基本盘如果你也想按 TaG 思路搭一套本地量化 Agent先别急着抄代码把环境想清楚。硬件方面中低频率策略也就是分钟级、小时级其实不需要很强的机器8 核 CPU、16G 内存的普通 PC 或者小服务器完全够用。如果做 tick 级回测或者多品种并行建议内存升到 32G 以上硬盘用 NVMe SSD数据 IO 在回测里往往是最大瓶颈。软件方面操作系统推荐 Linux我用的是 Ubuntu 22.04 LTS原因无他进程管理方便资源隔离干净定时任务用 systemd 配合就能实现。数据库方面回测数据的轻量存储用 SQLite 或者 DuckDB 就够了真要上生产级数据仓库再用 PostgreSQL。行情数据源、回测执行框架、可视化面板这三块都可以按自己偏好灵活选择重点是统一数据接口避免后期被某个特定平台的格式绑架。4.2 策略接入工作流从开发分支到模拟盘资格假设你已经写好了一个策略模块在 OpenAlice 体系里接入它要经过以下几步。第一步在策略仓库里新建开发分支提交 signal.py 和 config.yaml。config.yaml 里要显式声明策略的参数空间、品种列表、目标仓位区间。第二步注册到数据引擎。在配置中心添加该策略需要的数据集合数据引擎异步把历史数据拉取并落到本地生成数据快照 ID。第三步运行回测。OpenAlice 会使用该快照执行回测自动生成报告包含收益曲线、回撤曲线、交易明细、OOS 对比、成本敏感性分析报告发布到本地网页服务上方便后续查看。第四步提交人工评审。评审记录也要写进仓库包括通过、拒绝或者修改意见。通过后策略才获得“模拟盘资格”。第五步进入模拟盘跟踪。模拟盘环境模拟真实行情撮合、真实手续费与滑点模型但不涉及实际资金。系统要求策略至少连续运行 30 个有效交易日且最大回撤低于设定阈值才能获得“小仓位实盘资格”。这套接入工作流每一步都有对应的命令或脚本触发全部记录在案。任何策略能走到哪一步、为什么走到这一步都可以追踪。4.3 灰度上山模拟盘到小实盘的路径从模拟盘到实盘是从“纸上谈兵”到“真枪实弹”的临界点。我的做法叫“灰度上山”分三步。第一步用最小可用的资金量实盘比如账户总资产的 1% 到 2%并且先只运行一个策略的信号其余资金保持空仓。这一步的唯一目标是验证实盘执行链路是否和模拟环境一致而不是赚钱。第二步观察模拟盘和实盘的偏差。连续跟踪 10 个交易日重点比较买卖点、成交价、滑点损耗、信号执行时延四个指标。如果实盘滑点持续大于模拟盘假设的 2 倍以上就要回过头修正模拟环境的成本模型而不是直接加大仓位。第三步加仓必须分级。从 2% 加到 5% 需要至少 20 个交易日且期间最大回撤控制在阈值以内从 5% 再加需要更多的观察样本。实盘过程中如果触发任何一条熔断规则加仓进度自动暂停并重新评估。这个过程确实繁琐但它是把 TaG 的可控性从概念落到实处的关键。实盘与模拟盘之间永远存在差距灰度策略就是专门用来测量这个差距的。5. 常见问题与排查技巧实录5.1 历史数据对齐错位导致的假信号遇到过最典型的案例策略用某品种的 1 分钟 K 线回测结果年化 40%模拟盘却一直在亏。排查到最后发现这个品种在某个时间段存在一分钟数据整体缺失数据补齐时默认按前值填充导致这段时间的信号被错误计算。解决办法是在数据画像步骤里把缺失率设成硬性指标超过 0.5% 即视为数据集不可用拒绝策略使用。宁可放弃一个品种也不要在一份有残缺的数据上得出结论。5.2 回测曲线和模拟盘曲线对不上怎么办很多人拿到这个结果第一反应是系统有 bug其实大多数情况是“时间语义”不一致。常见原因包括回测按 K 线收盘价成交模拟盘按信号触发的下一根 K 线开盘价成交回测没有计入手续费模拟盘计入了手续费或者回测里的信号时间戳和模拟盘撮合时间戳有偏差。排查时先做差异分解把回测和模拟盘都改成零成本、同一成交规则看纯信号差异再把成本模型逐步加回去看每一层带来的差异量。两两对比后通常很快就能定位到具体环节。5.3 风控熔断频繁误触发怎么办这是很现实的矛盾阈值定得松了怕出事定得紧了又频繁熔断策略根本没机会跑。我的建议是把熔断设计成两级。第一级是“警告降活”。当策略日内亏损到达账户净资产的 1% 时风控不是立刻全停而是把该策略的信号优先级降低把新增仓位的最大手数减半让系统缓一缓继续观察。第二级才是“强制停止”。到达 2% 时立即全停只保留止盈止损和减仓逻辑。这样既给了策略纠错的机会又保住了保命底线。所有阈值应当提前用历史数据做压力测试而不是拍脑袋决定。5.4 实盘跑赢之后更容易踩的隐藏风险还有个特别容易让人飘的场景某个策略回测表现好实盘刚开始也持续盈利。这时候真正该做的不是加仓庆祝而是做三件事。先检查收益来源是否集中在少数几天。如果 80% 的利润来自 5% 的交易天数那它其实很不稳定。其次检查近期市场风格是否正在切换策略适应的环境还有没有在延续。最后看策略在实盘中的滑点损耗是否在预期区间。三项都没问题才轮到考虑加仓而且加仓依旧走分级流程。我自己最惨的一次爆仓恰恰是在连续盈利两周后觉得自己“懂市场了”手动把风控阈值调宽了 50%结果第三周遇到单日急跌全仓被闷在里面。后来我在系统里加了一条硬规则调节阈值必须走审批流且同一调宽操作 30 天内不允许重复。这条规则不是用来挡住市场风险的是挡住那个得意忘形的自己。下面把这几个高频问题整理成一个速查表方便直接对照排查。常见现象最常见原因排查动作回测很好模拟盘一直亏数据缺失被前值填充信号假阳性检查数据画像中的缺失率确认时间戳对齐回测和模拟盘曲线偏差大成交规则、手续费、信号时间语义不一致做差异分解从零成本公共同规则开始逐步对比熔断频繁触发单级阈值太紧改成二级熔断一级降活二级全停回测验证阈值账户盈利后突然大幅回撤手动放宽风控参数、加仓过快走审批流禁止短期二次放宽加仓必须分级我个人在实际操作中的最大体会是做量化最难的任务不是找出一个高收益策略而是让自己的系统长期处于“可控状态”。状态可控意味着每一笔亏损都能归因每一次参数改动都有留痕每一次触发熔断都有记录。爆仓不是一个瞬间而是无数个“跳过流程”的瞬间累积起来的。Trading-as-Git 这类思路能帮你把“跳过流程”这件事变得异常困难这就是它最大的价值。如果你也想动手搭一套类似的本地 Agent别追求一步到位。先从最小的闭环开始一个策略、一份干净的本地数据、一次能跑通全流程的回测、一条实盘时的硬止损线。先保证不被打死再谈怎么活得更好。真等你在凌晨一点被强制平仓短信叫醒的时候再来搭这套系统就真的晚了。
)
