边缘计算的3个确定性困局：一个开源项目如何用「状态化信号处理」把决策权抢回本地|上下文|代码|信号|决策权|大模型|开源项目|边缘计算

凌晨三点，工厂的传感器突然报警。你的云端模型还在排队等算力，而产线已经停了四分钟——这就是边缘设备最残酷的日常。一个名为 Edge 的开源执行引擎，试图用一套「状态化信号处理」框架，把决策权从云端抢回本地。

它不是又一个边缘推理工具。当前主流方案是输入→模型→输出的单点模式，在受控环境跑得顺，遇到信号中断、延迟波动就抓瞎。这个项目想解决的是：设备怎么在连续变化的信号流里，自己记住上下文、自己决定下一步。

一、核心架构：信号怎么被「消化」

项目的执行流程分了六层，每层都对应一个具体的技术决策。

输入信号（Input Signal）进来后，先做信号分类（Signal Classification）。这一步区分的是信号类型和紧急程度，不是简单打标签，而是决定后续走哪条处理路径。

接着是上下文构建（Context Construction）。这里的关键设计是「本地状态维护」——系统不依赖云端返回历史记录，自己把之前的信号处理结果存在内存里。原文明确说：maintains context locally。

执行层（Execution）跑核心模块，然后是状态更新（State Update），同时处理内存衰减和优先级调整。最后可选的协调层（Optional coordination）负责元数据同步，不是强制环节。

这个流程和云端大模型的批处理逻辑完全不同。它假设网络可能随时断，所以每一步都要能独立闭环。

二、代码结构：四个目录的分工

src/ 下面四个子目录，划清了功能边界。

runtime/ 是执行引擎本体，对应刚才说的六层流程。communication/ 做协调层，但注释写得很克制——coordination layer，没说具体协议。monitoring/ 只负责日志，没提可视化或告警。contracts/ 定义结构化输入，SignalPayload 这类数据类放在这里。

configs/ 里的 config.yaml 控制全局行为。当前版本能调两项：runtime.timeout 和 memory.decay 的强弱系数。这种外置配置的设计，目的是「tuning without modifying core logic」——调参不用改代码。

tests/ 和 docs/ 目前内容有限，符合「early-stage」的定位。

三、确定性执行：为什么用图结构

GraphExecutor 是 runtime 的核心类。从示例代码能看出，信号处理被建模成图遍历：每个节点是处理步骤，边是状态流转。

这种设计的代价是开发复杂度上升，收益是可预测性。原文强调 deterministic execution pipeline，意思是同样输入必定同样输出，不受执行时机影响。对于需要安全认证的工业场景，这是硬需求。

状态更新用了两套衰减系数：weak 0.9 和 strong 0.95。数值越接近1，历史状态保留越久。这个设计暴露了一个产品判断——边缘设备的记忆不能无限累积，必须主动遗忘，否则内存会爆。

四、当前能跑通的四件事

项目文档列了五项「Currently Works」，但仔细看代码和配置，第四项「Config-driven behavior」和第五项「Testable system components」属于工程基础能力，真正体现差异化的前三项是：

确定性执行管道。不是概率模型那种「大概对」，是每一步都可复现。

有状态内存更新。signal 处理完，state 会变，下次处理能读到这个新状态。

基于图的工作流执行。复杂逻辑可以拆成节点，串行或分支都行。

这三项组合起来，解决的是一个具体场景：设备收到一串传感器读数，需要根据历史趋势做判断，而不是只看当前数值。比如振动传感器，单次峰值可能是噪声，持续上升才是真故障。