Ⅴ · 数据与交付 — 5.3
优势与代价
两张对称的清单。每条优势标注兑现难度与适用条件——对单账户客户，多账户风控的价值是零。
优势
| 优势 | MT5 现状 | 兑现难度 | 适用条件 | |
|---|---|---|---|---|
| 1 | 多券商 / 多账户 / 多品种统一 | 一终端一账户 | 中 | 客户具备多账户结构 |
| 2 | 研究与生产分离 | 无此概念 | 中 | 客户有持续研究需求 |
| 3 | 独立风控模块 | 需在每个 EA 内自行实现 | 低 · 见效最快 | 多策略 / 多账户客户 |
| 4 | 数据可达性 | 可导出文件；实时状态与标注出不了终端 | 高（C 类） | 有远程、汇总、合规需求 |
| 5 | 开放生态（统计 / 优化 / ML） | 可用但窄：原生 ONNX 推理，缺训练与调参链路 | 中，依赖 6 | 客户具备研究能力 |
| 6 | 参数稳健性方法论 | 仅遗传算法优化 | 中 | 通用 |
| 7 | 全流程可复现 | 依赖文件副本 | 低 | 通用 |
| 8 | 信号可归因 | 投票合成后来源丢失 | 中 | 多信号策略（见 3.3） |
关于第 3 项的边界。“组合级”这个说法只对 LEAN 成立——它有现成的 MaximumDrawdownPercentPortfolio。Nautilus 的 RiskEngine 实测检查项都是逐单级，保证金账户的风控在源码中仍是 TODO。Nautilus 路线下组合级风控需自建。
关于第 5 项。先纠正一个常见误判：MT5 并非不能跑机器学习——它原生支持 ONNX 推理（OnnxCreateFromBuffer / OnnxRun），现有 EA 代码库中已有在用的 ONNX 信号模块。真实差距在训练、特征工程、超参搜索与统计检验这一整条研究链路，不在推理本身。
另：这一项应表述为潜在优势——机器学习在量化中的失败集中于过拟合与特征泄漏，防护依赖第 6 项；第 6 项未建立时第 5 项是负资产。
代价
| 代价 | 类型 | 严重度 | 缓解 | |
|---|---|---|---|---|
| 1 | MT5 桥接耦合 | 架构 | 高 · 最大盲区 | 见 5.2，两条路径均未消除依赖 |
| 2 | 前端 / 图表 / 指标渲染从零 | 工程 | 高 | C 类可跨客户复用 |
| 3 | 研究与生产结果不一致 | 工程 | 中 | 一致性测试（4.1） |
| 4 | 账本对账漂移 | 架构 | 中 | 框架内置对账机制 ✓ |
| 5 | 运维责任转移（7×24 / 断线 / 告警） | 运营 | 中 | LEAN 提供连接状态回调；仍需自建告警 |
| 6 | 框架自身风险与授权 | 工程 / 法务 | 中 | Nautilus API 演进快、文档较薄；LEAN 部署体积 13.1 GB 与隐性约定；CLI 付费 tier 条款待确认 |
| 7 | 交付模式改变（产品 → 项目制 + 运维） | 商业 | 高 | C 类组件复用度决定规模效应 |
| 8 | 技能栈扩张 | 团队 | 中 | Python + 前端 + 数据 + 运维 |
组件分类与可复用性
A 框架内置 · B 框架给骨架 · C 完全从零
| 组件 | 类别 | 跨客户可复用 |
|---|---|---|
| 券商 / 场所连接器 · 执行引擎 · 撮合模拟 · 账户核算 · 风控引擎 · 消息总线 | A | 高 |
| 数据接入与清洗 · 指标计算 · 参数管理 · 回测评估 | B | 中 |
| 策略逻辑 | B | 低 — 逐单定制 |
| 前端 / 图表 / 监控面板 / 多租户 / 部署运维 | C | 高 — 一次建成跨客户复用 |
**C 类决定这门生意有没有规模效应。**A 类是买来的，B 类中的策略逻辑每单重做——只有 C 类是一次投入、多次复用的资产。
这也解释了商业上的定位：引擎能力已被商品化（客户可以直接买现成的本地平台），定制交付卖的是那两成——air-gapped、嵌入客户自有系统、多账户运营、升级节奏自主、不受第三方条款约束。