1. 边缘推理引擎混战中ArmNN凭什么值得源码级关注先交代一下背景。这几年做端侧AI我在嵌入式板子上试过不少推理方案TFLite、ONNX Runtime、NCNN、MNN、OpenVINOx86那边、再就是ARM自家的ArmNN。如果你只在高通或瑞芯微的板子上用厂商SDK可能对ArmNN不太敏感但一旦你接触的是纯ARM公板、Mali GPU、或者要同时照顾CPU和GPU异构调度就会发现ArmNN其实是一个被低估的角色。它最特别的地方在于它不是单纯“翻译模型然后跑算子”而是从模型图到后端算子之间有一套完整的内部分层和调度机制。也就是说它更像一个“编译器运行时”的组合体而不是像TFLite那样偏向解释执行。这个特性决定了它在性能上限、可定制性、源码可控性上都有区别于其他框架的空间。这篇文章不是介绍文档也不是读代码笔记我尽量从源码审计和实践落地的双重视角把ArmNN的架构全貌、推理调用链、构建方式、以及真实板子上的部署经验写清楚。适合这几类读者正在评估ARM设备上边缘推理引擎选型的嵌入式工程师已经用TFLite但遇到Mali GPU利用率上不去想找替代方案的算法工程师准备深度定制推理引擎、想读ArmNN源码但不知道从哪里入手的朋友单纯想了解端侧AI硬件部署到底涉及哪些水位的同学。我默认你了解神经网络的基本算子概念对C和交叉编译有基础认识。不然部分代码走读会费力但整体思路还是能跟上。2. ArmNN源码全貌仓库结构、模块划分与关键抽象一次源码审计第一步一定是摸清仓库结构和模块边界。ArmNN这仓库看起来吓人实际上剥开之后逻辑非常清晰它其实是一个“前端多格式、中端优化器、后端多硬件”的三段式结构。2.1 仓库骨架从目录名就能看出设计意图拿出代码树来看核心就这几块不同版本目录会有小差异但总体稳定。目录职责我的理解src/armnn核心推理引擎Graph、Layer、网络编译、运行时整个框架的心脏值得细读src/backends后端实现Reference、NEON、CL、EthosNPU等真正贴硬件的地方src/armnnTfLiteParserTFLite模型解析器把flatbuffer模型转成ArmNN内部Graphsrc/armnnOnnxParserONNX模型解析器同上处理ONNX格式src/armnnSerializer/src/armnnDeserializerArmNN自有序列化格式适合把编译好的网络存下来加速下次加载tests和unit_tests集成测试与单元测试干活前先看测试怎么调用事半功倍这个划分方式让我第一印象很好它没有把解析器和后端实现混在一起模型格式的差异被限制在最外层核心引擎可以专注于图结构优化和执行调度。如果你要扩展一个新模型格式只需要新写一个Parser把外部格式翻译成ArmNN的Graph就完事。2.2 三层核心抽象Layer、Workload、Backend我阅读下来有3个抽象是理解ArmNN的关键Layer图的节点描述控制流和算子的统一表示。它不关心具体硬件。WorkloadLayer与后端交互的执行单元概念一个Layer经过后端工厂转换成一个或多个Workload。Backend/IBackendInternal硬件能力的统一抽象后端通过它对外暴露支持哪些算子、如何创建Workload、如何分配内存。打个比方Layer就像菜谱上的步骤描述Workload是已经在厨房里备好的半成品Backend就是那个真正的灶台。菜谱写得再好上不了灶台都是白搭灶台再高级菜谱不匹配也炒不出菜。ArmNN花大力气做的就是让这三者灵活匹配。Graph的内部结构由InputSlot和OutputSlot连接每个Layer通过Slot与其他Layer建立张量依赖关系。这也是ArmNN能对整图做内存规划的基础因为所有连接关系都在内存里不是运行时临时拼凑这使得很多编译器优化手段都能在内存规划阶段直接实施。2.3 后端注册机制为什么加一个新后端不算特别难后端不是硬编码在核心代码里的而是通过注册表机制挂接。BackendRegistry维护一个BackendId - 创建函数的映射核心引擎通过BackendId字符串如CpuAcc、GpuAcc、CpuRef查找后端实例。这意味着如果你想接入自研NPU或者第三方加速器理论上只需要在src/backends下新增一个后端目录实现IBackendInternal所要求的接口然后静态注册即可。核心引擎完全不感知你的后端是谁只知道它叫MyNpu。但注意这个接口有两层要求第一层是ILayerSupport用来查询“某算子是否支持”“支持什么数据类型”第二层是IWorkloadFactory用来真正创建执行对象。很多初次接触ArmNN源码的人会忽略第一层直接上手实现WorkloadFactory结果跑到Optimize阶段一脸懵ArmNN根本不让你用不支持的算子。正确顺序一定先实现LayerSupport告诉编译器哪些算子你接得住再谈WorkloadFactory怎么造执行体。3. 源码走读一条推理请求在ArmNN内部的完整旅程审计源码最大的价值是搞清楚“数据进来之后到底经历了什么”。我花了几天时间把主调用路径全部啃了一遍下面这条链路是反复验证过的顺序和关键节点都有据可循。3.1 模型解析从TFLite文件到Graph以TFLite为例入口在armnnTfLiteParser。它读取flatbuffer格式的.tflite文件逐层解析算子转成ArmNN的Layer。这一步不是简单的一对一映射。TFLite的某些复合算子比如FLEX算子或者部分Custom算子解析器会直接拒绝或者标注为不支持。ArmNN的TFLite解析器对标准的卷积、全连接、池化、激活、BatchNorm等都有良好支持但长尾算子覆盖始终是一个实际部署时的不稳定因素。如果模型里有不支持算子解析阶段通常不会直接报错因为ArmNN的解析器策略是“尽量构建不承载处报错”。真正的冲突会在Optimize阶段爆发具体表现就是后端支持检查不过要么抛异常要么走fallback路径。这个设计初看让人困惑其实是合理的因为解析器不应该预判所有后端的能力只有优化器知道最终要用哪些后端跑。3.2 Graph构建Layer与Slot的精细控制用原生API构建网络时代码风格是这样armnn::INetworkPtr network armnn::INetwork::Create(); armnn::IConnectableLayer* input network-AddInputLayer(0); armnn::IConnectableLayer* conv network-AddConvolution2dLayer(convDesc); armnn::IConnectableLayer* output network-AddOutputLayer(0); input-GetOutputSlot(0).Connect(conv-GetInputSlot(0)); conv-GetOutputSlot(0).Connect(output-GetInputSlot(0));每层之间显式通过OutputSlot和InputSlot连接。这种连线的设计保证了图结构是显式的DAG想在图层面做遍历、剪枝、重新排列都很方便。值得留意的是ConstTensorHandle的使用。权重、偏置这些常量在ArmNN里不是塞在Layer内部而是通过OutputSlot连接携带。它们也是图上的“数据流”影响内存规划器对常量内存的处理策略。这一点做过推理引擎的人应该能体会常量张量要不要单独分配内存、能不能驻留在高速缓存对端侧性能的影响非常大。3.3 Optimize阶段后端选择、内存规划与图优化Optimize是ArmNN源码里最值得反复读的函数。它的职责不是改模型而是“基于给定的后端偏好列表把一个不完全确定的网络变成可执行的优化网络”。核心流程可以概括为校验网络结构过滤无效连接逐个Layer调用后端的ILayerSupport确定后端归属根据后端能力做图变换比如算子融合、精度降低、布局转换内存规划统一分配中间张量的内存空间生成IOptimizedNetwork后续可加载执行。这里有一个非常关键的设计后端偏好列表是有顺序的。比如你传{CpuAcc, GpuAcc, CpuRef}ArmNN会优先把Layer放到CpuAccNEON上如果NEON不支持再尝试GpuAccOpenCL还不行就落到CpuRef。这种逐层回退策略比“整图回退”精细得多但也带来一个隐患同一模型里不同Layer可能会落到不同后端后端之间需要额外的张量格式转换转换开销有时会吃掉优化收益。图变换里面有个典型操作是算子融合。ArmNN会将卷积与紧随其后的激活如ReLU融合为一个“带激活的卷积Workload”减少一次中间张量落盘和重新读取。这类融合在源码里随处可见是Mali GPU上提性能的重要来源。3.4 LoadNetwork与内存规划为什么一次加载能省这么多事LoadNetwork做的事本质上就是“为优化后的网络分配真正的工作内存并把所有Workload的创建委托给各后端”。我读过Runtime.cpp里的实现这里最出彩的是内存管理。ArmNN不是在每个Workload执行时临时new一块内存而是在加载阶段就通过PoolManager把中间张量的生命周期排好做了一次统一的内存池分配。整个过程中间张量复用尽量少的物理内存块。这个设计对于边缘硬件极重要。嵌入式板上内存本来就不宽裕一个MobileNet跑FP16都可能吃几百MB如果再每层都动态分配内存碎片和分配耗时都会让人崩溃。ArmNN的内存规划器把这些都编译期加载期解决了执行时每个张量拿到的是一块预分配内存里的偏移地址基本没有运行时分配开销。3.5 EnqueueWorkload与后端执行推理调用时Runtime拿到输入张量拷入内存池中的输入区域然后按拓扑顺序逐个执行Workload。这里有个细节不是简单遍历所有Workload而是依据Graph的拓扑排序执行。Workload之间可能存在依赖ArmNN用一个执行顺序表保证前驱Workload完成后才执行后继。输出张量同样直接写在预分配的内存区域数据拷贝次数被压缩到了最少。NEON后端内部调的是ARM Compute LibraryACL的NEON函数CL后端调的ACL的OpenCL函数。所以源码审计到Workload这一层会看到一个“转发层”ArmNN把已经融合好的算子和张量描述传给ACLACL再做kernel级的调度。跑一次profiling你会发现指令流的实际核心计算全在ACL里ArmNN更像是一个“精明的调度者”。这不算缺点因为ArmNN的价值在于把图层面的优化和内存管理做扎实算子级优化交给ACL是ARM内部的明确分工。4. 源码审计视角下的设计权衡与风险点标题里写了“源码审计”我这里不只是复述源码更想从审计者的角度说说我看见的设计亮点和风险点这些都是实际工程里会踩到的。4.1 静态图架构的收益与代价ArmNN整个设计都是围绕静态图展开的。静态图意味着网络结构在加载时固定执行时不能动态增删层也不能根据输入动态控制分支。收益是可以提前做内存规划、算子融合、后端分配这些是动态图引擎做不好的。代价是对动态shape、循环、控制流支持薄弱。如果你有一个模型包含tf.while_loop或者依赖输入形状的reshapeArmNN的解析器很可能直接拒绝或者跑出错误结果。我的建议是如果模型里动态结构多优先在模型导出阶段就把结构固化。比如把循环展开或者把动态shape改为固定shape。端侧推理本来就适合静态化ArmNN只是把这种倾向推到了极致。4.2 后端回退是好设计但别让它偷偷吃掉性能前面提到逐层回退策略这个设计健壮性很好但有性能陷阱。假设一个模型90%的层都跑在GpuAcc上剩下10%的层因为算子不受支持落到CpuRef上。看起来“能跑”但中间过程需要反复在GPU和CPU之间拷贝张量可能比全CPU还慢。我实际遇到过一个案例一个检测模型因为有自定义NMS节点解析后只有一部分层走了GPU其余全退到CPU单帧推理耗时反而比纯CPU方案多了40%。排查到最后定位原因就是GPU和CPU之间的拷贝开销。源码里有没有提示Optimize返回后你可以拿到每个Layer实际分配的后端ID。审计时建议显式检查这一点别只看最终能不能跑。若发现大量层不在预期后端上就应该回到图优化或者模型切割层面解决。ArmNN也支持手动指定某些层强制用某个后端但在图编译阶段做比较靠谱。4.3 算子覆盖率的量化认知从源码层面统计一下ArmNN算子覆盖情况常见CNN算子很全卷积、池化、全连接、Softmax、Reshape、Concat通通没问题RNN/LSTM相关算子也有但支持的版本和组合比TFLite窄一些较新的Transformer算子如LayerNorm变体覆盖还好但Gelu、Attention组合算子就不一定了。我强烈建议在做选型阶段就把目标模型完整跑一遍ArmNN的ModelOptimizer/TfLiteDelegate自检把不支持算子的清单列出来评估是改模型结构还是换框架。不要到板子上跑起来才发现问题那样工期会非常被动。还有一个常见坑有些算子能解析但精度和原框架不完全一致。这不算bug是不同实现下浮点累加顺序差异。量化模型还好一些FP16模型上偶尔会出现个别输出层偏差需要端到端比对。4.4 并发与多实例执行的风险ArmNN的运行时不是绝对线程安全的。多个线程同时调用同一个Runtime实例的EnqueueWorkload在部分后端上需要外部加锁或者创建多个Runtime实例。我观察到的现象是CL后端在Mali GPU上创建多个实例会导致GPU内存重复分配显存压力很大NEON后端则相对宽松。如果要在边缘设备上跑多路视频分析建议每路一个Runtime实例但要注意共享后端资源的争用。源码里提供了IRuntime::Create的参数选项可以设置EnableGpuProfiling、DynamicBackends等。调试时打开profiling选项能看到详细工作负载耗时生产环境建议关掉profiling本身有额外开销。5. 在真实ARM板上从源码构建ArmNN编译踩坑清单光读源码不落板子等于白读。这一节我把自己在RK3588、树莓派4B等ARM设备上从源码编译ArmNN的实操经历完整呈现踩过的坑、绕过的路都写清楚。5.1 准备工作ACL版本与ArmNN版本必须严格对齐ArmNN依赖ARM Compute Library而且版本敏感度极高。直接用master分支的ArmNN配一个老版本ACL很有可能会在编译时出现一堆链接错误。我建议的做法是选定一个ArmNN发布tag然后找到对应的ACL版本。ArmNN的CMakeLists.txt或build-tool里通常有版本要求编译前先确认。获取代码git clone https://github.com/ARM-software/armnn.git git clone https://github.com/ARM-software/ComputeLibrary.git cd ComputeLibrary git checkout 与ArmNN兼容的ACL版本ACL来自带SCons构建支持NEON和OpenCL两种加速后端。如果板子上有Mali GPU建议两个都编上。5.2 构建ACLNEON与OpenCL一起开一个典型的ACL构建命令是scons archarm64-v8a neon1 opencl1 embed_kernels1 extra_cxx_flags-fPIC build_dirbuild -j4neon1开启CPU端的NEON优化opencl1生成OpenCL的kernel和库embed_kernels1把OpenCL kernel源码编译进二进制避免运行时再去读文件对嵌入式部署很有用extra_cxx_flags-fPIC生成位置无关代码ArmNN链接需要。如果没有Mali GPU或者不想碰OpenCL可以只开neon1。但你要明确后续ArmNN就不会有GPU后端了。这里有一个容易失手的细节embed_kernels1会让ACL的二进制本身变大不少但换来了运行时kernel加载时间的大幅下降。在裸机或极小根文件系统上这个取舍值得做在通用Linux发行版上可以不开让驱动在运行时编译OpenCL kernel。5.3 构建ArmNNCMake参数里的玄机ArmNN本身用CMake构建但参数非常多。我列一份经过验证的最小可用配置mkdir build cd build cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DARMCOMPUTE_ROOT/path/to/ComputeLibrary \ -DARMCOMPUTE_BUILD_DIR/path/to/ComputeLibrary/build \ -DBUILD_TESTS1 \ -DBUILD_TF_LITE_PARSER1 \ -DTF_LITE_SCHEMA_INCLUDE_PATH/path/to/tensorflow/lite/schema \ -DFLATBUFFERS_ROOT/path/to/flatbuffers \ -DPROTOBUF_ROOT/path/to/protobuf make -j4TF_LITE_SCHEMA_INCLUDE_PATH指向TensorFlow Lite的schema目录目的是生成tflite解析需要的数据结构。如果没有TensorFlow源码也可以从tflite的发行包里拿到schema文件。FLATBUFFERS_ROOT和PROTOBUF_ROOT根据你系统里实际安装情况来填。如果你不需要TFLite解析器可以把BUILD_TF_LITE_PARSER关掉那就不用配flatbuffers、protobuf这些依赖。我建议第一次先全部打开把完整能力验证一遍再按需裁剪。5.4 交叉编译还是板载编译很多人会问ArmNN能不能像普通程序一样交叉编译。可以但我不推荐。原因有两点第一ArmNN依赖ACLACL在交叉编译时需要对目标架构做大量指令集检测稍不注意就会编出带错误指令的版本。第二嵌入式板上交叉编译环境通常缺一堆依赖库补起来的时间足够你直接板载编译好几次了。我的经验是如果板子是8核及以上内存不少于4GB直接板载编译。RK3588这种板子编ArmNN大概半小时到一小时完全可接受。只有在对编译时间极端敏感或者板子性能太弱的时候才考虑用aarch64-linux-gnu-gcc交叉编译但需要额外准备sysroot坑会多不少。5.5 编译期容易踩的坑汇总我把自己遇到的高频问题列成一个表方便对照排查。症状原因解决方案链接时报找不到ACL符号ArmNN和ACL版本不匹配严格对齐版本用ArmNN指定tag重建ACLOpenCL kernel编译失败缺少embed_kernels1或驱动问题开embed_kernels重编ACL检查GPU驱动flatbuffers报版本错误本机flatbuffers版本过旧用ArmNN支持的flatbuffers版本或从源码编BUILD_TF_LITE_PARSER1时找不到schema路径填错确认schema目录里有schema.fbs编译极慢且内存不足并行度过高make -j2降低并行度运行时找不到libarmnn.so动态库路径未配置export LD_LIBRARY_PATH包含构建目录还有一个老生常谈但真会出现的坑有人总以为需要ARM自家的armcc编译器才能编ArmNN。根本不是用GCC或者Clang就行。Android NDK里的clang也能编。armcc早就是历史遗留产物了ArmNN完全不用那套工具链。搜“arm compiler 5.06下载”这类词搜出来的老编译器跟ArmNN没有半毛钱关系别浪费时间。6. 端侧AI落地从模型转换到性能调优的实操指南源码看得再多最后还是要落到业务里跑模型。这一节讲端侧AI的完整落地路径包括模型适配、后端选择、量化、性能调优和排错手法。6.1 标准落地流程五步走我自己总结的流程是模型导出把PyTorch/TensorFlow模型转成ONNX或TFLite格式格式适配用ArmNN Parser或Delegate把模型加载进来后端验证用CpuRef参考后端先跑通正确性性能验证切到CpuAcc或GpuAcc对比耗时和精度部署固化序列化优化后的网络集成到业务侧。第3步很多人会跳过去直接上加速后端。我不建议这么做。CpuRef虽然慢但实现最简单干净用它跑出来的结果可以当“标准答案”。如果后面加速后端输出对不上起码能确认是加速后端的数值问题还是模型本身的问题。这个排查思路在实战中救了我好几次。6.2 CPU后端还是GPU后端别凭直觉选ARM板子上的后端选择没有银弹只能实测。我整理了一张经验表场景推荐后端原因小模型、低延迟敏感、功耗敏感CpuAccNEON省电延迟可预期中大规模CNN、Mali GPU性能好GpuAccOpenCL大量并行卷积显著优于CPU快速验证、调试精度CpuRef实现清晰可信度最高混合场景多后端组合优化需要预先排查层回退问题有一个反直觉经验在Mali GPU上小模型不一定比CPU快。原因是OpenCL kernel启动和调度本身有固定开销模型太小的话启动开销占比会非常高。MobileNet这类轻量模型的单帧推理NEON后端和OpenCL后端经常打得有来有回。真正适合GPU的是大模型、高分辨率输入、重卷积结构。另外Mali GPU上FP16经常比FP32有明显加速因为Mali对FP16计算单元的利用率更高。ArmNN的OptimizerOptions里有降低精度选项可以把网络中的FP32计算转为FP16。但注意不是所有算子都支持FP16转化后需要跑一遍精度验证。6.3 量化端侧AI绕不开的一步端侧AI落地量化几乎是必须做的。ArmNN在INT8量化上走的是与TFLite兼容的对称/非对称量化体系权重和激活都支持8bit表示。我实际跑下来的结论INT8推理速度通常比FP32提升1.5到3倍具体取决于算子内存占用降低到原来的1/4左右精度损失在1%到3%之间检测类模型有时需要校准集微调阈值。用TFLite做PTQ训练后量化是最顺的路先量化成INT8的tflite模型再交给ArmNN的TFLite解析器加载。或者直接OnnxRuntime量化后导出。量化最大的坑是“敏感层”。我在一个检测模型里碰到过这样的情况头几层卷积量化后误差还好但最后一个检测头量化后直接把坐标回归搞崩了。排查后发现是检测头的输出范围特殊校准集里覆盖不全。这种问题不改模型结构很难根治建议做混合量化把敏感层保留FP16或FP32其余层走INT8。ArmNN对混合精度的支持比很多框架好因为后端分配是逐Layer的精度差异可以体现在层属性上。6.4 首个推理先做一点预热ArmNN在第一次推理时往往比较慢因为OpenCL后端需要编译kernelNEON后端要初始化线程池。这个是正常现象不是性能问题。我建议集成时做一次“预热推理”用一张全零输入跑一遍让所有后端完成初始化然后才开始真正的业务推理。很多刚接触ArmNN的人第一次看到延迟超高以为哪里写错了实际上是没预热。如果用的是CL后端embed_kernels1能显著缩短预热时间。另外ArmNN也支持把优化后的网络序列化到文件下次直接加载避免重复做图优化对于启动时间敏感的端侧应用非常有用。6.5 实测数据参考我在一块RK3588板子上跑过一个典型分类模型简单分享一组数据供参考不代表所有场景方案单帧耗时备注纯CPUCpuAcc FP32约45ms线程数默认纯CPUCpuAcc INT8约22ms量化收益明显GPUGpuAcc FP16约18msMali G610 GPUGPUGpuAcc INT8约15ms部分算子不支持时反而慢这个表最想说明的是光看方案不看模型任何结论都站不住。但趋势是明确的量化GPU组合在多数重计算场景下是最优解。6.6 端侧AI硬件部署的常见坑最后集中说几个常见坑都是“看起来没问题但总是出问题”的地方。第一内存带宽是隐形瓶颈。ARM板子的算力往往不错但内存带宽有限。计算密集的卷积没问题但大量张量搬运的算子Concat、Reshape、Permute很容易被打到内存瓶颈。优化手段是尽可能在模型结构里减少这种算子或者让ArmNN的布局转换更高效。第二多进程共用GPU设备。如果你同时起多个进程每个进程都创建OpenCL contextMali驱动的上下文切换开销可能大得离谱。我建议在端侧尽量单进程多线程而不是多进程。第三散热功耗。这看起来不是软件问题但实际跑长任务时RK3588这类板子会因过热降频推理延迟忽高忽低。性能验证一定要跑长稳测试不要只跑一次。第四别在一棵树上吊死。ArmNN有它的优势也有它的短板。有的模型在ArmNN上怎么都优化不动换到NCNN或TFLite反而跑得更快。选型时多做横向对比没有谁是万能的。7. 源码审计收尾我读ArmNN源码时的一些思考如果你真的读到这里说明你不是来随便翻翻的。我聊聊对ArmNN源码本身的一些感性认识。ArmNN代码质量在推理引擎这个领域算上乘。它没有那种“为了跑通堆出来的技术债”感相反很多接口设计能看出是为长期演进考虑的。比如IBackendInternal的抽象深度恰到好处接口数量不多但每一层的职责都明确。实现一个新后端时你把ILayerSupport和IWorkloadFactory做好基本就能跑起来这种设计是干净的。代码风格上它偏C11/14有两个特征智能指针用得密集所有权语义清晰模板元编程用得少基本是运行时多态为主的风格。这让我这种半路出家的读者读起来负担小很多。不像某些框架一上来就是模板套模板读得人想摔键盘。更值钱的是它的测试。tests/目录下覆盖了大量算子级别和端到端的测试很多源码中注释不够清晰的边界条件看测试用例能很快理解设计意图。我审计时会先搜一个算子的测试再回头读实现理解速度快很多。如果要说什么不足那就是编译复杂度和文档更新有一定滞后。很多论文式的设计理念在官方博客里讲得漂亮但具体到某个版本的CMake参数还得自己去读CMakeLists.txt。希望后续版本能在构建工具链上更进一步少让工程师在编译上浪费时间。对我来说读ArmNN源码最大的收获还不是学会了怎么用它而是理解了一个推理引擎如何把“图优化”和“硬件适配”这两件事系统性地拆开、再组合起来。这种架构思维放到任何一个端侧AI项目里都是通用的。如果你准备入坑ArmNN我最后的建议是先在这块板子上用TFLite跑通一个Baseline再切到ArmNN对比遇到性能瓶颈不要急着调源码先用profiling确认瓶颈在哪一层如果真走到要改源码那一步优先从后端新增或算子扩展入手核心引擎尽量少动因为核心模块改动影响范围太大维护起来很痛。
