做量化的朋友应该都经历过那种时刻：回测曲线漂亮得像教科书，一上实盘就开始漏气，连续几天亏损到怀疑人生。我自己就曾被一个趋势策略卡在窄幅震荡里反复打脸，账户净值一条直线往下掉，那时候才真正想明白一件事——实盘和回测最大的区别不是行情，而是“不可回退”。代码写错了可以 revert，策略上错仓位却没有 Ctrl+Z。
今天这篇文章聊的 OpenAlice，正是围绕这个痛点长出来的一套本地量化 Agent 系统，核心设计哲学我称之为 Trading-as-Git：把策略生命周期当成代码仓库来管，用分支隔离、提交复现、回滚止损来约束每一次实盘进出。内容全部来自我实际搭建和跑过的项目，没有课程推销，也不堆术语。我会依次拆解为什么用 Git 的思维做交易、本地方案里各 Agent 怎么分工编排、围绕“活得久”设计的闭环风控，以及实操中最容易翻车的细节。
这套内容适合两类人：正在实盘但管不住回撤的手动交易员，以及想从“单机脚本”进化到“可演进系统”的量化开发。如果你是前者，重点看第 3 章的风控闭环；如果你是后者，建议从头到尾读一遍，里面有不少我在踩坑之后才补上的工程约束。
1. 为什么是 Trading-as-Git：把策略当仓库管起来
1.1 实盘和代码最大的区别：没有 Ctrl+Z
做量化的人嘴上常挂着“策略是代码”，但很少有人认真想过这句话的另一面：代码在本地仓库里怎么改都行，哪怕把整个模块删了也能还原；真金白银的交易却一旦发生就永远留在账单上。赔掉的每一笔钱，都不会像 git revert 那样被历史抹掉。所以我在设计 OpenAlice 时做的第一个决定，不是选哪个策略、用什么模型，而是把“不可回滚”当成系统设计的第一约束条件。
Git 的价值从来不在于“存文件”，而在于它让变更变成可追踪、可对比、可回退的版本化事件。交易系统也一样：策略参数、特征计算、订单路由、持仓状态，每一个环节都该有版本、有提交、有审计。把交易和 Git 类比不是文字游戏，而是一种思维方式转换——你不再问“现在策略表现怎么样”，而是问“现在实盘跑的是哪个 commit，它凭什么待在这个分支上”。
1.2 分支、提交、标签：策略版本化的三个基元
OpenAlice 的仓库约定很简单：main分支永远是当前实盘配置；research/*是各种实验分支；paper/*跑模拟盘；prod/*是从 paper 晋升出来的候选版本。每次晋升不是复制文件夹，而是merge，自动带上研究阶段的 commit message，包括回测区间、预期最大回撤、参数文件 hash。这样实盘出问题的时候，第一反应不是翻聊天记录找人问“上次改了什么”，而是git log看最近一次 merge 发生了什么。
我建议每个 commit message 都按固定格式来写，机器可读是关键。参考格式是这样的：
git commit -m "strat: rsi_reversion / 2019-2024 回测 / maxDD 8.2% / params@7fa3c9e" git checkout -b paper/rsi_reversion # 模拟盘观察 7 天后 git checkout prod git merge paper/rsi_reversion --no-ff git tag live/2025-06-01tag用来标记一次真实上线的状态。等哪天策略出现问题，你可以直接git diff live/2025-06-01..HEAD看看实盘期间到底改了什么。别小看这一条，它能把“复盘靠印象”变成“复盘靠证据”。
1.3 prod 分支禁止热改：爆仓最经典的肇因
最重要的一条纪律：一旦 checkout 到 prod，所有 Agent 读到的参数都必须来自打包在提交里的文件，运行时禁止改。真遇到策略失效，正确动作是切回stable分支，而不是在 prod 上现场调参。现场调参等于把一个未经回测的版本直接丢向实盘，绝大多数爆仓都是这个动作造成的。
我见过太多人白天看行情不对劲，晚上“灵机一动”改了止损距离，第二天继续亏，第三天才想起来改回去。这种热改的热知识在于：它根本没有经过验证流程，而是情绪驱动。OpenAlice 用技术约束来对抗情绪：所有策略 Agent 启动时读取的是 Git checkout 出来的参数，而不是数据库里的“当前配置”。想改参数？可以，走一次完整的分支、回测、模拟盘、merge 流程，让系统强制你冷静。
2. OpenAlice 本地量化 Agent 架构与编排
2.1 本地优先的真正理由：延迟、密钥与数据主权
OpenAlice 为什么坚持本地量化，而不是把 Agent 放在云端？我总结下来有三个核心理由。一是延迟：本地进程直接连交易所的行情和交易接口，比多一跳公网转发少一截延迟，对高频调仓和熔断撤单尤其关键。二是密钥：交易所 API 密钥一旦落到第三方服务器，攻击面就变大；放在本机并用环境变量注入，至少你能控制物理访问。
三是数据主权：策略权重的中间计算、持仓快照、订单流水都属于敏感数据，我不想让它们经过任何外部服务。本地部署还有一个隐藏红利：Agent 之间的通信不经过公网，风控指令的执行路径短，链路断了也能在进程内完成最基础的止损。当然本地部署也有缺点，比如机器宕机没人盯着，但这可以通过看门狗脚本和独立熔断进程来缓解。
2.2 五个 Agent 的分工：谁生成、谁审批、谁执行
OpenAlice 里运行着五个核心 Agent，我把它们的职责列成一张表：
| Agent | 核心职责 | 关键产出 |
|---|---|---|
| 情报 Agent | 拉取行情、经济日历、新闻，做轻量摘要 | 事件包 |
| 策略 Agent | 特征计算、信号生成，遵守当前 checkout 参数 | 交易意图 |
| 风控 Agent | 前置风控计算、仓位控制、签发 PermitToken | 风控令牌 |
| 执行 Agent | 下单、改单、撤单，核对成交回报 | 成交回报 |
| 账本 Agent | 持久化订单/持仓/净值，输出日终快照 | 交易流水 |
这五者的关系不是平等的“同事关系”，而是有严格的上下边界。策略 Agent 永远没有下单权限，它只能生成“交易意图”——包括交易标的、方向、期望入场价、期望止损价，然后提交给风控 Agent。风控 Agent 查完所有规则后签发一个PermitToken，执行 Agent 只认带 Token 的指令。执行 Agent 是唯一持有交易所 API 密钥的进程。
2.3 事件驱动的编排：信号与订单之间的严格边界
各 Agent 之间不搞 RPC 大循环，而是通过事件总线解耦。我用 Redis Streams 作为通信层，原因很简单：它自带消费组，可以保证每条事件至少被一个消费者处理，而且天然支持多生产者多消费者。数据流大致是这样的：
- 情报 Agent 把清洗后的行情、日历、新闻推送到
market.events - 策略 Agent 订阅
market.events，产出候选信号到signal.requests - 风控 Agent 消费
signal.requests，校验通过后把PermitToken发布到exec.permit - 执行 Agent 监听
exec.permit，完成下单后把成交回报写到exec.fills - 账本 Agent 消费
exec.fills，更新持仓和净值快照
这套事件流的精髓在于“信号不等于订单”。很多人做量化 Agent 喜欢让 AI 模型直接输出买入指令，这是非常危险的。AI 的输出本质上是一个概率分布，而不是一个经过合规校验的动作。OpenAlice 用 PermitToken 机制把“生成想法”和“执行动作”彻底隔开，即使策略 Agent 被错误数据带偏，风控 Agent 仍然能拦住越界的意图。
2.4 不是所有环节都需要大模型：三七开的智能分配
你可能注意到，上面这套架构里没有满屏的“智能”。这是刻意为之。很多朋友一上来就买全套 Agent 框架，什么都招 AI 处理，结果系统复杂到连作者本人都解释不了。我的看法是：Agent 的价值不在“全自动写代码”，而在把复杂动作拆成可验证的小步骤；风控这种对确定性要求极高的环节，用传统规则比用 LLM 可靠太多。
OpenAlice 的分配原则是三七开：七成确定性逻辑（信号计算、仓位公式、风控规则、订单路由）走传统代码；三成允许模糊的任务交给本地部署的 LLM。比如情报 Agent 的新闻摘要、日志归因这些任务，我会用本地部署的量化版本模型来做，例如 DeepSeek 的量化版本地部署，跑在消费级显卡上完全够用。这种选择不是迷信哪个模型，而是基于成本、延迟和可解释性的综合权衡。
3. 风控闭环：四道闸门把爆仓变成异常状态
3.1 闭环的含义：亏损要反馈到策略本身
闭环这个词被用滥了，但 OpenAlice 里的“闭环”有非常具体的含义：亏损的结果必须回到策略的起点，改变下一次交易的先验概率。传统写法是策略产生信号 → 下单 → 等账户亏到某个百分比 → 手动或自动平仓。这其实是个开环——你没有把“这次亏损教会了什么”系统化地写回策略版本里。
OpenAlice 的做法是给每个策略维护一份“现实偏差”档案：实盘真实成交和回测时的对应成交做逐笔对齐分析，记录实际滑点与回测假设滑点的差值、订单链路耗时、以及实盘收益与预期收益的偏离。当偏差累计超过阈值，系统自动把该策略从 prod 移到paused/under_review分支。这就是闭环：过去的“教训”改变未来的“行为”，而不是把错误一遍遍地重复。
3.2 前置风控：交易意图必须拿到 PermitToken
前置风控是四道闸门里最重要的一道，它发生在资金真正离手之前。OpenAlice 的风控规则集中在一个risk.yaml文件里，每次修改都要通过一次 Git commit，不接受运行时热改。给大家看一份我实际在用的配置：
risk: max_leverage: 2.0 # 总杠杆上限 max_notional_per_position: 0.3 # 单仓位名义价值占净值比例 risk_per_trade: 0.01 # 单笔风险占净值比例 daily_loss_limit: 0.03 # 日亏损 3% 触发熔断 max_drawdown_kill: 0.08 # 连续回撤 8% 强制空仓 cooldown_minutes: 120 # 熔断后冷却 2 小时 blacklist: [] # 禁止交易标的仓位计算我采用的是最常见的“固定风险预算”法。公式是：
数量 = 账户净值 × risk_per_trade / |entry - stop|
假设净值 10 万，单笔风险 1%，入场价 100、止损价 95，那么这笔交易最多亏 1000 元；每股风险是 5 元，数量就是 200 股。然后还要过名义价值限额：200 × 100 = 2 万，小于 3 万的限额，通过。如果算出来超出名义限额，就取名义限额对应的最大数量。这套计算不复杂，但它逼着你在下单之前就把“最多亏多少”定死，而不是等浮亏变大之后再慌。
3.3 盘中熔断：独立进程的撤单与冻结
盘中监控不能依赖策略进程——策略可能因为 bug 崩溃，也可能因为行情冲击而卡死。OpenAlice 把盘中熔断做成一个独立 daemon，监听每笔成交和实时仓位，计算当日盈亏。触发熔断条件后它只做一件事：调用交易所的批量撤单接口，同时向所有 Agent 广播“风控冻结”事件。策略 Agent 收到后停止产生新意图，已经挂着的单子全部撤掉。
这个熔断 daemon 连 LLM 都不跑，代码量非常小，只保留必要的交易所客户端、事件总线和状态机。极端行情里它必须活下来，所以依赖越少越好。我的建议是把它当成“家里总闸”来设计：不要跟其他 Agent 共用进程，也不要共用一套配置加载逻辑。
注意：熔断进程的 API 密钥应该和交易密钥相互独立，只授予撤单和 ping 权限。这样即使策略侧密钥泄露，熔断进程依然能作为最后一道物理闸门继续工作。
3.4 事后归因：谁该被暂停，谁可以继续
每天日终，账本 Agent 会生成一份“风险账单”：包括当天实际成交的滑点与回测假设滑点的差值、下单链路耗时、每个策略的实盘收益与预期收益的偏离。OpenAlice 会自动计算一个经验法则：如果某个策略连续 N 天的实际收益低于预期收益 2 个标准差，系统就把该策略移入paused/under_review分支，并发通知。
这里的一个细节是：自动暂停不代表所有策略全被下架。暂停一个策略是成本，暂停所有策略是恐慌。系统需要区分“个别策略失效”和“整体市场环境恶化”。所以 OpenAlice 同时维护一个全局状态，只有全局回撤超过阈值时才触发全市场空仓，否则只是暂停问题策略。这样既保护了资金，又保留了其他策略继续盈利的机会。
4. 本地部署实操与踩坑实录
4.1 最小可运行的目录结构与启动顺序
如果你想动手复现这套架构，我建议从最小结构开始，不要上来就搞 Kubernetes。目录长这样就够了：
alice/ # git 仓库根目录 strategies/ # 策略代码与参数文件 agents/ # 五个 Agent 的入口 risk/ # 风控规则与熔断进程 data/ # 本地行情缓存 storage/ # sqlite 账本 runbook/ # 运维脚本启动顺序有讲究：先启动账本 Agent，再启动风控 Agent，然后才是情报 Agent、策略 Agent、执行 Agent。这个顺序的核心是让后面所有 Agent 从一开始就处于被记录、被约束的状态。如果策略 Agent 先启动，它在风控 Agent 还没就绪的窗口期产生了信号，就会因为没有 PermitToken 而被挡在执行环节之外——这正说明了 Token 机制的价值。
技术上，Python 3.11 加上 Redis、SQLite、Git 2.35+ 就够了。Agent 之间用 Redis Streams 通信，账本 Agent 持久化到 SQLite，熔断 daemon 可以独立成一个 systemd service。
4.2 实盘校准回测：小仓位跑通再放大
很多人实盘上来就复制回测参数，这几乎等于裸奔。正确做法是在 paper 分支上缩小仓位跑 2 到 4 周，期间只核对一件事：实际成交质量和回测假设是否在同一量级。比如回测假设滑点 0.1%，实盘第一次统计出来是 0.6%，那你该做的不是叹息市场难做，而是把回测引擎的滑点参数改成 0.6% 后重新回测。
这种“用实盘校准回测”的循环，才是 Trading-as-Git 里最值钱的部分。校准不是一次性动作，而是每次实盘数据积累到一定量后都要做。我习惯每两周跑一次校准脚本，将最新实盘成交记录与回测模拟在同一时点的执行结果做对比，把偏差滚入下一版参数。这样策略不是越来越偏离现实，而是越来越贴近现实。
4.3 常见问题速查表
| 现象 | 最常见根因 | 处理动作 |
|---|---|---|
| 订单长时间没有成交回报 | 交易所接口限流或权限不足 | 停止下单，检查 API 权限与限流状态 |
| 周末/节假日的假信号 | 情报 Agent 读到过期日历缓存 | 在事件包里加 valid_from/valid_to 时间窗 |
| 一次成交后滑点远大于回测 | 走市价单且流动性不足 | 改为限价单加超时撤单机制 |
| 熔断触发却频繁被策略重启 | 熔断信号没有持久化 | 用 Redis 的持久化 key，策略启动时先检查 |
| 策略参数被意外修改 | 有人热改配置文件 | 改为强制读取 Git checkout 参数 |
| Agent 进程崩溃后没恢复 | 缺少看门狗与状态快照 | 给关键 Agent 加 systemd 自动重启与心跳 |
这几条都是我实际踩过或者帮朋友排查过的。尤其是“熔断触发却频繁被策略重启”这条，特别阴险：熔断 daemon 向事件总线发了冻结信号，但策略 Agent 因为某种原因重启了，重启后没有读取 Redis 里的持久化冻结状态，又开始交易。修复方式很简单，就是让所有 Agent 启动时的第一件事是检查风控状态 key，而不是直接开始干活。
4.4 防“自己人拆风控”：规则 hash 与密钥隔离
风控规则最容易在自己人手里失效。比如某天你心情不好，觉得“今天情况特殊，把日亏损限额改到 5% 吧”——这种操作必须被系统拦住。OpenAlice 的约束是：修改 risk 配置必须走一次新的 Git commit，且需要管理人签名。运行中的风控 Agent 每小时把自己的规则 hash 写入账本，一旦发现与 Git 仓库 HEAD 不一致，就拒绝签发新的 PermitToken，直到规则重新对齐。
密钥管理同样不能放松。API 密钥永远不写进仓库，执行 Agent 的密钥从环境变量加载；熔断 daemon 的极简密钥和交易密钥物理隔离，放在不同的配置目录。另外我强烈建议给交易所 API 设置 IP 白名单，只允许本地机器的出口 IP 访问，就算密钥泄露出去了，攻击者也用不了。
最后的干货：一次差点爆仓的教训
项目做到第四个月的时候，我踩过一次最深的坑，现在回想起来后背还是发凉。某天凌晨，券商那边的接口字段语义突然变了，本该被当作“限价止损单”处理的指令，被交易所端理解为“市价单”，直接以当时的最差价格成交，净值瞬间掉了 6%。那一刻系统里所有常规风控都在正常工作：限额没超、熔断没触发、Token 也签发了，但没有任何一层检查“接口字段语义”和“实际订单类型”是否匹配。
后来 OpenAlice 加了一条硬规则：执行 Agent 在每次下单前，必须核对交易所返回的订单类型字段是否与意图一致，不一致就拒发订单并告警。这逻辑不复杂，但它在关键时刻比十个 AI 总结都有用。我的体会是：量化系统的风险，往往不是来自策略不够聪明，而是来自基础层某个没人注意的假定悄悄失效。Trading-as-Git 帮我把“版本可追溯”做扎实了，但真正让人睡好觉的，还是那些尽量少依赖外部变化的确定性校验规则。
