Trading-as-Git：量化交易防暴仓的OpenAlice风控闭环

如果你也被“回测曲线漂亮得像教科书，实盘账户却在一个月内把半年利润全还回去”这件事折磨过，那这篇文章应该能帮到你。我把自己踩了无数坑之后沉淀下来的量化框架 OpenAlice 完整拆开，讲清楚 Trading-as-Git 这个核心设计怎么落地到本地量化 Agent 上，以及整套风控闭环是如何把“盲目实盘暴仓”这条路一步步堵死的。内容适合那些已经能写策略、会跑回测，但还没建立起一套可靠实盘纪律的个人量化开发者参考——它不是让你发大财的招数，而是让你不在真正上战场之前就死掉的保命设计。

1. 暴仓从来不是运气问题：回测与实盘之间的四道隐形裂缝

先说一个真实场景。我最初做双均线策略的时候，回测年化 40%，最大回撤 8%，曲线出来之后我兴奋得连夜充钱，结果实盘三个月亏了 22%。后来复盘了很久，发现根本原因不是策略不行，而是我从回测到实盘之间存在四条看不见的裂缝。

第一道裂缝是回测引擎和实盘通道根本不是同一套逻辑。我在回测里假设“信号出现后按收盘价附近成交”，但实盘里信号出现到订单进入交易所之间，有行情延迟、有下单延迟、有滑点，还有你的订单可能排在队列后面根本没成交的情况。回测里的手续费模型如果是按“万二点五”单边算的，实盘里频繁交易下来实际成本可能比这个数字高出两三倍。这套差距放到高频里是致命伤，放到日线上也会慢慢吃掉利润。

第二道裂缝藏在数据里。很多人用前复权数据跑回测，前复权会把历史价格统一调整到当前视角，但如果你的策略里写了“突破 N 日新高”之类的逻辑，前复权数据的未来函数问题非常隐蔽——今天的除权会改变历史所有价格，导致历史突破点发生位移。我见过一个策略，换数据复权方式之后收益直接从正变成负。还有停牌日、涨跌停板、交易量异常为零的日子，这些数据不清洗，回测就是在自欺欺人。

第三道裂缝是策略漂移。实盘亏损之后，人天然会去做“微调”：把止损从 5% 放宽到 7%，把均线参数从 20 调整为 25，亏损时加仓摊平成本，盈利时提前止盈落袋。每一次都觉得是小调整，但三次之后策略已经变成另一个东西。当初回测验证过的那个策略早就消失了，你在实盘上用的是一个新的、从未验证过的变体。

第四道裂缝是最要命的：止损在关键时刻总是被人为解除。我复盘过自己所有大亏的交易，几乎每一次都是“再等等，应该会反弹”的念头害的。回测里止损是代码写的，成交就是按价格触发，不掺杂情绪；实盘里止损单挂在那里，你盯着盘口，手一抖就撤掉了。这四个裂缝叠加在一起，就解释了为什么“回测通过”和“实盘暴仓”可以同时发生。

所以我的结论很直接：你缺的不是一个更聪明的策略，而是一套能锁定策略版本、自动执行决策、并且让风控不依赖个人纪律的工程化框架。这也就是 OpenAlice 里 Trading-as-Git 这个概念出现的起点。

2. Trading-as-Git：把交易策略当成一个需要版本管理的软件仓库

2.1 从 Git 仓库到交易系统的概念映射

Git 解决的是软件工程里“代码改来改去、不知道谁改的、出了问题没法回退”的问题。交易策略的开发迭代本质上也是同一个问题：你不断调整参数、修改逻辑、更换数据源，但没有一套机制记录“当前实盘跑的是哪一版策略”“上一版为什么被弃用”“回测数据对应哪个版本的数据集”。

Trading-as-Git 的核心思想很简单：把策略的整个生命周期当成一个 Git 仓库来管理。分支对应环境，commit 对应版本快照，tag 对应发布到实盘的版本，回测报告就是 CI 产物，rollback 就是应急回退操作。我用一张表把这套映射放出来，后面所有设计都围绕这张表展开。

这个映射不是比喻，是直接在工程上强制执行的。在 OpenAlice 里，回测模式可以从任意 commit 启动，但实盘模式如果传入的 tag 不存在，程序会直接拒绝启动。这样至少保证一件事：你在外面跑的钱，永远和当初验证过的那一版代码一致。

2.2 策略签名：代码、参数与数据集三个版本一起锁定

只有代码版本还不够，因为同一个 strategy.py，配上不同参数、不同数据版本，结果完全不一样。所以 OpenAlice 引入了一个“策略签名”的概念，它把三个维度一起哈希锁定：

import hashlib import json def strategy_signature(code_hash: str, params: dict, dataset_version: str) -> str: payload = json.dumps({ "code": code_hash, "params": params, "data": dataset_version, }, sort_keys=True) return hashlib.sha256(payload.encode()).hexdigest() # 每次回测前生成签名 sig = strategy_signature(code_hash, {"fast": 5, "slow": 20}, "20240101_xshg_daily_v3")

这个签名的意义在于，它让你能回答一个平时根本答不上来的问题：当前实盘跑的策略，到底对应哪一次回测？如果实盘策略签名对应的回测报告根本不存在，那就说明这个策略从未被验证过——审计时第一个被拦下来的就是它。

我自己的习惯是每次回测前先 commit，把 run_id 写进 git log，回测报告保存为reports/{run_id}.json，然后把这个 run_id 同时也记录到报告里。这样从任何一次实盘日志，都能反向追溯到：这单买卖是基于哪一版代码、哪一组参数、哪一份数据算出来的。听起来繁琐，但在亏损复盘时，这个追溯链能省掉特别多互相猜疑的时间。

2.3 发布与回滚：git tag 就是实盘启动的唯一凭证

实盘里最容易失控的时刻是“盘中临时改参数”。在 OpenAlice 里这个操作有严格门槛：实盘进程只从 git tag 启动。任何修改都必须先打新 tag，重启进程才生效。这就把“盘中手一抖改了参数”变成了一件有仪式感、有记录、可回滚的事。

实际操作中我一般这样管理发布节奏：

# 1. 在 dev 分支完成参数修改并回测 git checkout dev vim strategies/smacross/params.yaml python main.py --mode backtest --strategy smacross # 2. 回测达标后合并到 master，打 tag git add strategies/ reports/ git commit -m "perf: 双均线增加成交量过滤，回撤从8%降到6%" git push origin master git tag v0.4.2 # 3. 实盘端以 tag 启动 python main.py --mode live --strategy smacross --tag v0.4.2

如果实盘跑了两天发现异常，比如某票流动性急剧下降，或者策略在全新行情下表现诡异，就切回上一个确认正常的 tag：

git checkout v0.4.1 python main.py --mode live --strategy smacross --tag v0.4.1

“回滚”是这个架构里最容易被忽略但最能救命的能力。大多数个人交易者亏大钱，不是因为没有好策略，而是因为陷在一个正在持续亏损的版本里不愿意关停。有了 Git 式的 tag 回滚，回退成了一个没有任何心理负担的标准操作。

3. OpenAlice 本地量化 Agent 的四层骨架：模型、工具、执行与安全边界

3.1 为什么我坚持本地部署，而不是把决策全部交给云端

很多 AI 量化项目会把持仓、订单、策略代码都放到云端模型服务上处理。我这个项目从一开始就坚持本地部署，理由有三个。

第一是隐私和资产安全。策略代码、券商 API key、账户持仓、成交明细，这些一旦经过外部接口，就多一环不可控的暴露面。本地部署之后，数据只在自己机器上流转，攻击面小得多。

第二是延迟与成本。盘中决策对响应时间敏感，本地推理延时常驻在几十毫秒到几百毫秒级别，不用考虑网络抖动；同时也不按 token 计费，策略每天跑多少轮复盘、生成多少条分析日志都不会产生费用焦虑。

第三是可审计性。本地模型的所有输入输出都可以直接落到磁盘，每次决策、每个工具调用参数都能完整记录下来，这对“事后复盘”极其重要。

模型选型上，我在 OpenAlice 里用的是开源量化版本地部署方案，常见的选择包括量化微调版的 DeepSeek 蒸馏模型，或者通义千问系列的小尺寸版本，跑在 Ollama 或 llama.cpp 上。对个人实盘场景来说，14B 以下的小模型在常规 GPU 或 M 系列 Mac 上已经够用，重点不在于模型多聪明，而在于工具边界和风控流程够不够硬。

3.2 Agent 的工具调用：查询归查询，动手归动手

本地 Agent 的骨架分成四层：LLM 调度层、策略回测层、执行层、风控层。LLM 调度层负责把自然语言指令转化为工具调用序列，但它永远不能直接操作资金。这是 OpenAlice 与“让 AI 全自动下单”那类方案最本质的区别。

所有 Agent 可用工具都按“查询类”和“动作类”分开管理：

TOOLS = { "get_market_data": { "type": "query", "args": ["symbol", "timeframe", "limit"], "desc": "获取指定标的历史行情K线", }, "get_position": { "type": "query", "args": [], "desc": "获取当前账户持仓与可用资金", }, "run_backtest": { "type": "query", "args": ["strategy_id", "params_override", "dataset_version"], "desc": "运行回测并返回绩效汇总", }, "place_order": { "type": "action", "args": ["side", "size", "order_type", "price"], "desc": "提交订单到当前 broker", "requires_risk_check": True, "confirm_required": True, }, "stop_all": { "type": "action", "args": [], "desc": "触发全市场熔断，停止全部新开仓", "requires_risk_check": True, }, }

查询类工具可以自由调用，动作类工具必须同时满足两个条件：风控层校验通过、人工或预设策略确认放行。我最开始让 Agent 带“自动下单”能力时，发现 LLM 偶尔会把参数顺序搞反，比如把side="sell"写成side="buy"，一旦直接连着实盘 broker，这种错误就是真金白银。所以后来无论模型多聪明，动作类工具都必须走风控层，且默认要求确认。

3.3 Agent 记忆：把每次决策写成一笔可审计的 commit

Agent 的“记忆”不该是黑盒向量库，而应该是一个可追溯的决策日志。OpenAlice 的做法很简单：每次 Agent 做完一个完整决策（盘前计划、盘中信号、盘后复盘），都自动把决策内容、理由、所用工具、返回结果追加到一个 Markdown 文件里，然后git commit -m "decision: 2025-06-01 午盘 减仓 沪深300ETF"。

这套机制有额外的好处：commit message 本身就是天然的结构化索引，后续可以用git log --grep="减仓"查询所有同类决策的历史。我在跑模拟盘期间积累了几百条 commit，复盘时能把“某类信号出现后的平均决策质量”拉出来看，这是单纯丢给大模型一个记忆库做不到的。

3.4 执行层抽象与数据质量门槛

执行层在 OpenAlice 里通过 broker 抽象来隔离真实资金，共三种实现：BacktestBroker、PaperBroker、LiveBroker。三者的接口完全一致，区别只在于订单到底进入回测引擎、模拟撮合还是真实交易所。Agent 和风控层面对的是同一个接口，所以测试环境验证过的下单流程，切到实盘后不会突然改变行为。

数据层是另一个容易翻车的地方。OpenAlice 在数据进入策略前强制做一轮基础清洗：剔除停牌时段、标记涨跌停状态、对复权因子异常做检测，任何成交量或涨跌幅超出现实合理区间的数据点都会被标记而非直接使用。原因很简单：坏数据不仅会让策略算出错误的信号，还会让风控层做出错误判断——这个后面踩坑部分会详细说。

4. 风控闭环：事前算出能亏多少，事中盯住执行偏差，事后强制复盘

风控闭环是我认为整个 OpenAlice 架构里最核心的部分，也是“本地量化”最大优势的体现——所有风控逻辑都在本地规则引擎里运行，不以模型输出为转移。

4.1 事前风控：用公式把每一笔的下注额度算死

事前风控的目标是：在下单动作发生之前，就把“这次最多亏多少钱”锁死。核心是两条公式。

单笔仓位公式：

单笔仓位 = 账户可用资金 × 单笔风险预算 / (入场价 - 止损价)

举个例子，账户 10 万，单笔风险预算 1%（即单笔最多亏 1000 元），入场价 10 元，止损价 9.8 元（止损距离 2%），那么这笔最多只能买 50000 元市值。如果止损距离是 5%，最多只能买 20000 元市值。这个公式强制你根据止损距离动态调整仓位，而不是凭感觉“买一手”。

总回撤熔断预算：

当日亏损达到账户权益的 3% -> 停止新开仓 总回撤达到账户权益的 8% -> 全部平仓并进入保守模式

OpenAlice 里的risk/rule_engine.py在每笔订单提交前都会读取这两个数字，如果接近阈值就拒绝执行。注意这里的关键点：风控规则是硬编码在独立进程里的，不经过 LLM。哪怕模型认为“现在是千载难逢的抄底机会”，风控层也不会因此改变一分一毫。

4.2 事中风控：盯住滑点、成交回报与下单频率

事前算出仓位还不够，订单执行过程中还有三件事必须实时盯住。

滑点与费用异常：OpenAlice 会按日累计已实现滑点和手续费，如果实际费用超过回测时假设值的 1.5 倍，风控层会对后续订单提高滑点容忍阈值并标记异常。这个监控能让“回测手续费假设过于乐观”的问题在几天内暴露，而不是等到月底账单出来才惊觉利润全被费用吞了。

成交回报偏差：限价单迟迟不成交、部分成交、或者成交价偏离预期超过设定容忍值（我一般设 0.2%），系统会主动撤单并记录异常。这个东西在回测里根本不存在，但它恰恰是实盘最消耗资金的地方——你看到的成交价往往已经不是你信号触发时的价格了。

下单频率节流：每个标的每分钟最多 3 笔订单，全天最多 30 笔，超过就拒绝。这个限制专门用来防 Agent 在交易循环里意外卡死、反复提交订单的情况——AI 系统的 bug 不一定表现为崩溃，可能表现为“非常勤奋地下错单”。

4.3 事后风控：日终对账与策略漂移检测

实盘收盘后，OpenAlice 每天自动做两件事。

日终对账：把本地记录的订单流水与资金账户的成交流水比对，核对数量、价格、费用。任何一笔对不上，直接标记为“审计异常”并暂停次日自动交易。个人交易者最容易忽略的就是对账，总觉得券商流水不会错，但如果是你自己代码里的订单状态和实际成交不一致，这个问题会在策略层面放大。

策略漂移检测：定期用当前策略代码跑一次基线回测，然后把近期实盘决策和回测信号的决策分布做对比。比如回测里某个指标出现后是买入的，但实盘最近十天该指标出现后 Agent 都犹豫没买，或者额外加了其他条件，这就说明策略实际上被改动了。这个检测的价值在于，它能识别“微妙偏离”——不是代码 diff 能捕捉到的那种，而是行为层面的漂移。

4.4 熔断层级：从停止开仓到人工解锁

风控闭环的最后一道闸门是熔断。OpenAlice 的熔断分三级，对应不同动作：

在 OpenAlice 里，熔断解除的唯一方式是人工在配置文件中写入明确的解锁命令，Agent 没有权限自行解除。这一点极其关键——如果让模型能自己“考虑”要不要熔断，那相当于让运动员自己兼任裁判，情绪一上来，什么规则都会失效。

5. 从零跑通这套系统：目录结构、关键配置与验证顺序

5.1 目录结构与启动配置

OpenAlice 的工程结构遵循“策略、数据、报告、Agent、风控、broker”分离的原则，每个模块只干一件事：

openalice/ ├── strategies/ │ └── smacross/ │ ├── strategy.py │ ├── params.yaml │ └── README.md ├── data/ │ ├── raw/ │ └── processed/ ├── reports/ ├── agents/ │ ├── llm_router.py │ ├── tools.py │ ├── memory/ │ └── prompts/ ├── risk/ │ ├── rule_engine.py │ └── circuit_breaker.py ├── brokers/ │ ├── base.py │ ├── backtest_broker.py │ ├── paper_broker.py │ └── live_broker.py ├── configs/ │ └── openalice.yaml └── main.py

configs/openalice.yaml是唯一的运行时配置入口，所有安全边界都在这里明确声明：

mode: paper # backtest | paper | live strategy: id: smacross tag: v0.4.2 # 必须以已存在的 git tag 启动 data: symbols: ["510300.XSHG"] # 宽基ETF，流动性好，不容易触发极端滑点 dataset_version: "20250101_daily_v3" risk: max_position_ratio: 0.2 single_trade_risk: 0.01 max_daily_loss: 0.03 max_drawdown: 0.08 order_rate_limit_per_min: 3 price_slippage_tolerance: 0.002 agent: model: qwen2.5:14b tool_policy: confirm_place_order # 下单必须二次确认 memory: sqlite log_dir: agents/memory/decisions

这套配置我建议按自己的风险承受能力改，但注意一点：三个风控数字（单笔风险、当日亏损、总回撤）应该先想清楚再填，不在盘中改。

5.2 Agent 核心循环与风控网关

Agent 的盘中任务循环大概是这个逻辑：

from risk.rule_engine import RiskRuleEngine class AliceCore: def __init__(self): self.risk = RiskRuleEngine(configs["risk"]) self.broker = create_broker(configs["mode"]) def handle_tool_call(self, tool_name, tool_args): if tool_name in QUERY_TOOLS: return self.run_tool(tool_name, tool_args) if tool_name in ACTION_TOOLS: risk_result = self.risk.check_trade( side=tool_args.get("side"), size=tool_args.get("size"), risk_budget=configs["risk"]["single_trade_risk"] ) if not risk_result.passed: return {"error": "risk_rejected", "detail": risk_result.reason} if configs["agent"]["tool_policy"] == "confirm_place_order": confirm = input(f"确认下单 {tool_args} ? [y/N] ") if confirm.strip().lower() != "y": return {"error": "user_rejected"} return self.broker.submit_order(tool_args) return {"error": "unknown_tool"}

可以看到，风控校验永远是动作类工具的第一道门槛。这个顺序不能反——必须先让风控层确认“允许交易”，再弹人工确认框。如果先让用户确认再查风控，容易出现在盘中最躁动的时候人手一快、确认之后才发现风控就拦在这里，但心里已经“决定要做这笔交易”了，于是顺手改风控参数——这种流程漏洞我用过，后来就砍了。

5.3 从回测到小资金实盘的四级验证路径

一次新策略的完整上线，我喜欢拆成四个阶段，每个阶段都有明确的通过标准：

1. 回测验证阶段：在指定 commit 上跑回测，生成报告并保存 run_id。通过标准不是单纯看收益率，而是看最大回撤、盈亏比、单笔亏损分布是否符合策略逻辑。
2. 模拟盘阶段：切到 paper broker。此时 Agent 每天生成计划、走完风控流程、提交模拟订单，但资金是虚拟的。通过标准是连续运行至少两周，订单流无异常、风控规则被触发过至少一次且行为符合预期。
3. 小资金实盘阶段：投入计划资金的 10%，用流动性最好的宽基 ETF 验证执行链路。此阶段不追求收益，而是确认滑点模型、手续费假设、对账流程和真实行情下的体验。
4. 逐步放量阶段：只有前一个阶段连续 30 个交易日无重大异常，才考虑提升到计划资金的 50%、100%。

这套渐进式路径看起来保守，但恰恰是“告别盲目实盘暴仓”的实质——它把“不知道会发生什么”的未知风险，变成了一步步可控的、可观测的、有数据支撑的决策过程。

6. 实测三个月之后，我改掉了这些设计

这套系统跑模拟盘和小资金实盘大约三个月，中间踩了几个挺有代表性的坑。拿出来讲一下，可能帮你省不少时间。

6.1 Agent 误调用下单工具：环境隔离必须物理级严格

第一次出问题是在模拟盘阶段。Agent 在回测工具里拿到一组信号，然后居然直接调用了place_order，而且我当时偷懒没有开confirm_required，导致一张虚拟订单被提交到了 paper broker。虽然金额是假的，但这个 bug 提醒我一件事：绝不能依赖模型“理解”它在什么环境。后来我把每个工具参数里都加上了env字段，并且风控层校验时强制检查env == configs["mode"]——回测环境下的联调操作永远不可能穿透到实盘 broker。这是纯工程防护，不经过任何模型推理。

6.2 模型复盘时只数盈利单，不数亏损单

我最初给盘后复盘 prompt 写的是“总结今天的交易情况”，结果模型每次复盘都是“今天抓住了 XX 机会，盈利 X 元，市场整体符合预期”这种报喜不报忧的流水账。亏损单被轻描淡写，甚至被解读成“为了控制风险主动放弃”。后来我改了 prompt 结构，强制模型对每一笔亏损单回答三类问题：什么原因导致亏损（信号错误 / 执行偏差 / 数据异常 / 风控未覆盖）；该信号是否遵循了策略签名；下次遇到同类情况应该如何应对。最重要的是，模型产出的复盘结论会作为 commit message 提交到 Git——也就是说，模型的“反思”本身也进入了可审计的决策历史。从那以后复盘质量明显提升，因为我无法接受模型对自己亏损的解释永远是“市场波动”。

6.3 风控进程本身挂了，资金也就裸奔了

有一次风控规则引擎因为一个数据格式异常直接抛异常崩了，Agent 还在继续运行，准备下单时发现自己连不上风控层。默认行为是什么？我最初设计成“连不上就跳过风控直接下单”，理由是怕交易中断。后来想了很久，这个设计完全错误——风控系统是不可用，恰恰是最应该停止交易的时候。现在 OpenAlice 的策略是 fail-safe：风控层挂了，执行层直接拒绝所有新订单并进入只读模式，直到人工修复风控并重启。宁可错过一次交易机会，也绝不在没有风控的情况下裸奔一秒钟。

6.4 坏数据引发的风控误判，比坏数据本身更可怕

数据清洗不够的时候，某个 ETF 在停牌日或除权日出现“零成交、价格跳变”的行情。风控层看到价格异常，直接触发 L2 账户熔断，清掉了所有多头仓位。问题是：那不是真实的市场信号，只是数据质量问题。这个误判让我错过了一整段正常上涨。后来我在数据层和风控层之间增加了一个“数据有效性校验阶段”——成交量必须大于零、涨跌幅必须在合理区间、价格必须连续（允许跳空但需要标记），校验不通过的数据根本不会进入风控引擎。这个改动之后，因为坏数据误熔断的情况再也没出现过。

6.5 回测收益率仍然偏高，但真实滑点比我预想的大

三个月后对比回测和实盘收益差距，发现最大的偏差来源不是信号，而是滑点。ETF 看似流动性很好，但如果你坚持“信号出现后立刻按市价单买入”，在快速波动期实际成交价经常偏离信号价 0.3% 以上。后来我把回测引擎里的成交模型改成“按信号后 N 分钟 VWAP 成交”，并加入按最近 20 日平均买卖价差计算的保守滑点假设，回测数字立刻“难看”了很多，但跟实盘的差距缩小了不少。现在我的原则是：如果你的回测曲线好得让你兴奋，先怀疑哪里已经过度乐观了。

最后再聊两句实操层面的体会

我非常清楚，这套架构从纸面上看挺“重”的，第一次搭完你可能觉得自己不是在做一个策略，而是在维护一个小型软件公司。但我个人的真实体会是，恰恰是这种“重”，才让你在账户波动时能睡得着觉。暴仓这种事，从来不是一次错误决定的瞬间爆发，而是几十次小偏差叠加、没有任何机制在中途拉住你的结果。Trading-as-Git 提供的版本追溯、本地 Agent 提供的自动化执行、风控闭环提供的硬性边界，三件事拼在一起，才终于把“盲目”这两个字从实盘操作中去掉了。

最后分享一个至今保留的习惯：每次 Agent 完成一次完整决策并自动 commit 之后，我会当天补写一段人工的 commit message。它不需要长，一两句话就行，比如“今天按 v0.4.2 的规则执行，没加戏”或者“盘中差点想改止损，忍住了”。几个月之后再回看这条时间线，你会比任何回测曲线都更清楚地看到，自己的交易纪律到底有没有在实盘中兑现。我觉得这就是这套方案最大的价值——它不直接帮你赚钱，但能帮你活到赚钱的那一天。