Ⅱ · 框架解剖 — 2.3
LEAN · 引擎装配与运行边界
先分开看配置装配与一次运行，才能理解五类 handler、QCAlgorithm 与外部数据和券商的关系。
这里有两张不同的问题
LEAN Engine 是 C# 编写的算法交易引擎，策略可用 C# 或 Python 编写。LEAN CLI 和 QuantConnect 的云端产品可以调用或承载它，但不是 Engine 的同义词。
读这一章时，先把两个问题分开：
- 装配：回测、纸上或实盘时，数据、成交和结果分别由什么实现接入？
- 运行：当某个时刻的数据抵达后，算法、订单、组合状态和输出如何互相影响？
上一版把这两种关系放在同一张图里，容易把 handler 当成一条从左到右的流水线。它们实际是五个独立的边界角色。
五类 handler 到底各管什么
| handler | 它解决的问题 | 一个具体例子 | 它不负责什么 |
|---|---|---|---|
ISetupHandler |
算法以什么账户、订阅和初始状态启动 | 回测建立初始现金与证券订阅 | 每一根 K 线的计算 |
IDataFeed |
未来哪个时刻有哪些数据可用 | 从本地文件回放，或把实时源整理为框架数据 | 决定买卖信号 |
ITransactionHandler |
订单如何送往成交模型或券商，并把回报带回 | 回测用 fill model，实盘用 brokerage adapter | 制定组合仓位目标 |
IRealtimeHandler |
没有行情时，哪些日历或时钟事件仍需触发 | 日终处理、定时调度 | 拉取行情历史 |
IResultHandler |
日志、统计、图表和结果送往哪里 | 写回测报告或把日志输出到控制台 | 改写订单或策略状态 |
config.json 中的 environment 为这些接口挑选具体实现，所以同一份算法可以在不同环境使用不同数据或执行边界 官方文档。这不意味着只改一个配置就能保证实盘语义相同，券商规则、实时数据质量和延迟仍需要单独验证。
一次运行时，事件怎么走
图中最重要的两个对象是：
Slice：某一时刻能交给算法的已同步数据集合。on_data(slice)不是“单根 K 线回调”的同义词，它可能同时包含多个订阅的数据。QCAlgorithm：策略的入口和状态容器。它读取Slice，访问Securities、Portfolio、Transactions等运行状态，随后提出订单或持仓目标。
订单的结果不是直接修改策略变量。成交、拒绝或取消先形成订单事件，更新订单与组合状态，再经 on_order_event(order_event) 交给策略。这样策略能区分“我发出了请求”和“市场或券商确认了什么”。
Engine 层与 Algorithm Framework 层
Algorithm Framework 的 Universe、Alpha、Portfolio Construction、Risk Management 和 Execution 模型位于 QCAlgorithm 的可选策略组织层。它们不是上图五类 handler 的替代品：前者组织“根据数据想持有什么”，后者处理“数据、时间、成交和结果从哪里来”。
如果一个策略直接在 on_data 中发订单，它仍运行在 LEAN Engine 上，只是没有采用完整的 Algorithm Framework 流水线。下一节会解释时间片与订单事件，3.4 再单独解释其中的风险模型。