为什么还要再做一个 Python 量化终端
国内期货量化工具大致分为三派。第一派是自研语言派（如文华、开拓者、金字塔等），生态成熟、教程丰富，但语言封闭，无法直接复用 pandas、sklearn 等现代数据科学生态，策略资产的可移植性受限。第二派是纯后端 SDK 派（如天勤量化），轻量、可编程性强，适合服务器部署，但缺少前端可视化交互，策略运行状态"看不见"，对入门者和需要直观复盘的用户不够友好。第三派是行情终端外挂脚本，灵活但稳定性与风控能力最弱。
期魔方（四川赤壁量化科技有限公司出品）选择的是第四条路：以 Python 为唯一开发语言，同时保留完整的行情图表、策略编辑器、回测面板与实盘任务管理，把"写代码"和"看盘面"重新放回到同一个进程里。这种设计取舍的价值在于降低上下文切换成本——开发者不需要在 IDE、行情软件和交易终端之间来回跳转，信号、图表、日志与持仓处于同一时间轴上。
分层架构：数据层 → 引擎层 → 策略层 → 交互层 → 执行层
从外部观察其行为，可以把期魔方抽象为五层：
数据层：负责 K 线、Tick、合约信息、库存仓单现货等衍生数据的拉取、缓存与对齐。官方披露支持超过 15 年历史数据，这是做长周期验证与截面分析的基础。
引擎层：事件循环 + 回测引擎 + 订单撮合模拟器。回测引擎据称采用自研架构，性能较同类产品有数量级提升（官方口径为十倍以上），这对多品种、多年份的参数扫描至关重要。
策略层：用户编写的 on_init / on_tick / on_bar / on_order / on_trade / on_error / on_stop 回调集合，运行在内置的 Python 环境中。
交互层：超级图表（支持 Python 自定义指标绘制）、回测报告、任务面板、运行日志与消息预警。
执行层：CTP 接口封装、委托状态机、失败补单、止损止盈、隔夜自动登录维护，以及 MT4 TO CTP 桥接。
这五层的关键在于策略层与执行层之间隔着一个确定的订单状态机。策略只表达意图（开多 1 手），由执行层负责重试、撤单重报与状态同步。这一设计决定了策略代码可以保持纯粹，不必被网络抖动污染。
事件驱动模型的契约与时序
期魔方采用事件驱动而非轮询，这意味着开发者需要理解三个时序约束：
（1）on_bar 在 K 线闭合时触发
一根 15 分钟 K 线的 on_bar 回调发生在该周期结束的时刻，此时 get_kline 拿到的最后一根 bar 是已闭合的确定值。很多新手把"当前未闭合 K 线"当成已确认信号，造成回测完美、实盘失效——这不是平台 bug，而是时序理解错误。
（2）回调是串行单线程的
同一策略实例不会并发执行 on_bar，因此策略内部的状态变量不需要加锁。但这也意味着：不要在 on_bar 里做耗时操作（如全量重训模型、大规模 IO），否则会阻塞后续 Tick 与风控逻辑。正确做法是把重计算放到独立线程或定时任务中，主回调只读取结果。
（3）on_order / on_trade 是异步回报
发出委托不等于成交。策略若依赖"已成交才进行下一步"的逻辑，必须在 on_trade 中推进状态机，而不能在下单语句之后立即假设仓位已变化。
Python 环境：零配置背后的工程考量
平台内置 Python 12.9 并预装 pandas、numpy、ta_lib、sklearn 等库。从工程角度看，这一设计的收益很明确：消除环境差异导致的"在我机器上能跑"问题，让策略在不同机器、不同用户之间具备可复现性；代价则是版本自由度受限（例如无法随意升级某个依赖）。因此建议：把策略写成不依赖特定小版本的代码，避免使用实验性 API；若需第三方库，先确认平台是否支持安装或已有等价实现。
另一个容易踩坑的点是策略对象的生命周期。ContextInfo 贯穿策略全程，其自定义属性是唯一可靠的跨回调状态存储位置。函数局部变量会在每次回调结束后丢失，全局变量在多策略实例运行时可能互相污染。规范做法是全部挂在 ContextInfo 上，并在 on_init 中赋予初始值。
数据层的两个隐形难点
跨周期跨品种对齐
期魔方允许在螺纹钢的 15 分钟策略里取铁矿石的 1 小时数据和热卷的日线数据。但这三类数据的 bar 闭合时刻不同，直接使用 [-1] 索引会引入"用到未来数据"的偏差。稳健写法是先判断辅助序列长度是否充足，再按"上一根已闭合"的偏移取值，必要时做前向填充。
主力连续合约的拼接
长期回测必然涉及换月。主力连续序列在换月日存在价差跳空，若不做处理，均值回归类策略会被虚假的跳空收益误导。平台提供基础行情数据，但换月规则、复权方式需要在策略层面显式处理，或在回测设置中确认是否启用复权。这是任何回测系统都无法替你自动做对的环节。
可观测性：被低估的能力
期魔方把每一笔委托和成交标注在 K 线上，并生成逐笔运行日志。从运维角度看，这相当于给策略配备了 trace。当实盘表现偏离回测时，排查顺序应当是：先看标注点位是否与信号逻辑一致（判断是逻辑 bug 还是执行损耗），再看日志中的委托回报与滑点（判断是流动性问题还是接口问题），最后才怀疑模型本身。多数"策略失效"最终都落在第一层。
边界与不适用场景
客观地说，期魔方的定位是 CTA／套利／多因子类的中低频量化终端。它的优势在于一体化与可视化，而不在于极低延迟。对于微秒级的高频做市、需要 GPU 集群的深度模型训练、或者跨资产（股票、期权希腊值对冲）的统一风控，它更适合作为执行端与研究端的衔接层，而非唯一基础设施。选工具的本质是匹配场景，而非追求功能最全。
期魔方的架构价值可以用一句话概括：用 Python 生态的开放性，换取终端产品的完整性，同时通过事件驱动契约与订单状态机守住确定性。理解这三件事，比记住任何一组 API 都重要。
