什么是 Rust 语境下的“量化算子”——一个工程对象的最小定义

文献声明

本文不是 Rust 教程，也不是量化策略教程。

本文记录的是：在 Rust 语境下，量化算子应如何被工程化与定义。

文中所有代码仅作为工程定义的参考实现存在，其目的在于验证模型是否成立，而非作为教学成果本身。

作者

yuer

EDCA OS 作者

可控 AI 标准提出者

工程仓库：https://github.com/yuer-dsl

联系邮箱：lipxtk@gmail.com

1. 问题从哪里来

在大多数实现中，技术指标通常被建模为"函数"：

输入一个数组
输出一个数组或一个数值

这种方式在早期是可行的，但在以下工程场景中会系统性失效：

指标需要维护跨调用状态（如 rolling / EMA）
指标需要对时间顺序敏感
指标需要在逐条与批量计算中保持一致语义
指标需要被组合、调度、复用

函数模型无法表达这些约束。

在 Rust 中，这个问题被进一步放大：

所有权与生命周期迫使我们必须明确"谁持有状态"
隐式共享状态几乎不可接受
高性能要求需要清晰的执行边界

继续把指标当函数，本质上是一种语义缺失。

2. 核心定义：什么是算子（Operator）

在本文中，算子（Operator） 被定义为：

一个在明确执行语义下，对输入数据进行处理的可调度执行单元。

刻意不使用"函数"一词，是因为函数模型无法覆盖算子的工程责任。

一个算子必须满足：

拥有明确的输入与输出语义
在一次"执行"中被调用，而非任意时间
对自身状态拥有明确责任边界
能够失败，并以结构化方式暴露失败

一个算子永远不负责：

决策（是否交易）
调度（何时执行）
资源管理（线程、内存池）
系统级错误恢复

3. 执行（Execution）的最小语义

执行（Execution） 指的是：

在给定输入与执行上下文下，对算子进行的一次不可分割的调用。

关键点是：

执行是语义单位，而不是函数调用次数
同一个算子可以被多次执行
执行之间的关系，本文不讨论

4. 失败不是 panic

算子失败不是 panic，而是：

一次可观察、可传播的执行结果。

最小约束是：

失败必须显式表达
失败不等同于系统崩溃
是否中断系统，由外部决定

5. 最小参考实现（v0.1）

下面的代码不是"教程示例"，而是用于验证上述定义在 Rust 中可以成立。

复制代码

pub trait Operator<Input, Output> {
    type Error;

    fn execute(&mut self, input: Input) -> Result<Output, Self::Error>;
}

说明：

&mut self 明确算子可能持有状态
不引入时间、不引入批处理、不涉及调度
这是一个刻意"过小"的接口

一个最小无状态算子示例：

复制代码

pub struct Sum;

impl Operator<&[f64], f64> for Sum {
    type Error = ();

    fn execute(&mut self, input: &[f64]) -> Result<f64, Self::Error> {
        Ok(input.iter().sum())
    }
}

它的意义不在功能，而在于：

算子 ≠ 函数调用。