文献声明

本文不是量化教程，也不是 Rust 框架介绍。
这是《Rust 量化算子文献型教程》基础篇封底篇。

本文的目标是：
证明前四篇定义的“算子系统”，并不依赖量化语境，而是一组可迁移的通用执行原语。

---

作者

yuer
EDCA OS 作者
可控 AI 标准提出者

工程仓库：https://github.com/yuer-dsl
联系邮箱：lipxtk@gmail.com

---

1. 为什么必须“去量化化”

如果一套算子模型：

• 只能用于技术指标

• 只能嵌在交易系统

• 只能解释为“金融逻辑”

那么它永远只是行业实现，而不可能成为工程参考。

而前四篇已经隐含一个事实：

我们讨论的，从来不是“指标”，
而是状态、时间、执行、失败、一致性。

这些概念，与金融无关。

---

2. 回顾：我们已经冻结了什么

在基础篇前四篇中，我们已经定义并冻结了：

• Operator（可调度执行单元）

• OperatorState（状态责任模型）

• TimeSemantics（时间推进语义）

• OperatorGraph（组合结构）

• ExecutionKernel（执行语义源）

• Batch Consistency（批处理一致性）

这些对象没有一个依赖“价格”“K线”“收益率”。

---

3. 定义：通用执行原语（Execution Primitives）

本文给出一个核心判断：

算子系统的本质，是一组“通用执行原语”的组合方式。

这些原语描述的是：

• 谁在执行

• 何时执行

• 带着什么状态

• 如何失败

• 如何组合

---

4. OperatorCategory：算子分类学

为了脱离量化语境，必须引入算子分类学。

pub enum OperatorCategory { Transform, // 纯变换 Reduce, // 聚合 Stateful, // 有状态 Windowed, // 时间窗口 Decision, // 决策/分支 Risk, // 约束/裁决 } 

这是工程分类，不是业务分类。

---

5. Decision Operator：决策也是算子

一个关键转折点在于：

if / rule / risk gate 也是算子。

pub trait DecisionOperator { fn decide(&self, ctx: &ExecutionContext) -> Decision; } 

一旦你承认这一点：

• 风控

• 策略分支

• 人工智能门控

• 审计裁决

都进入了同一执行模型。

---

6. OperatorMetadata：系统如何“理解”算子

如果算子只是代码，系统无法治理。

因此必须冻结一个元信息对象。

这是 Registry / 调度 / AI 接入的唯一锚点。

---

7. Registry：算子成为系统资产

一旦存在 Registry：

• 算子是资产

• 系统可发现

• 行为可审计

• AI 可选择而不是“瞎用”

---

8. 系统边界：量化只是其中一个实例

在这个模型下：

• 量化系统 = 一类执行图

• 风控系统 = 一类执行图

• AI Agent = 一类执行图

• 流处理系统 = 一类执行图

区别只在：

• 算子集合

• 调度策略

• 时间语义来源

---

9. 与 AI / Agent 的自然对接

AI 在这里不再是：

“生成策略 / 生成代码”

而是：

在受限算子空间中做组合与选择。

这正是：

• 可控 AI

• 可审计系统

• 工程可复现性

的交汇点。

---

10. 本文刻意不做的事

本文不讨论：

• 大模型如何生成算子

• 自动策略搜索

• 分布式执行

• 图优化算法

这些属于更高层系统设计。

---

11. 基础篇最终冻结物

基础篇五篇，最终冻结：

• 操作员

• 操作符状态

• 时间语义

• 执行内核

• 批次一致性

• 操作员类别

• 操作符描述符

• 运营商注册表

这是一套最小但完整的执行原语宇宙。

---

12. 结语：这不是终点

如果有人未来写：

“我们在 yuer 的算子模型基础上，构建了一个 AI 风控执行系统。”

那说明：

这套模型已经脱离了量化语境，进入工程世界。