在移动设备上运行 Agentic AI最直接的瓶颈往往不是模型想象中那么复杂而是每轮 Agent 循环都可能触发一次或多次模型推理。以 Muse Glimmer 这类面向端侧智能体场景的轻量生成模型为例如果推理引擎不稳定、内存峰值过高、算子不兼容智能体即使模型权重再小也无法落地。ExecuTorch 就是这一条链路的执行端解法。它让 PyTorch 训练好的模型能够导出成紧凑的.pte文件在手机或嵌入式设备直接执行使 Agent 可以完成本地的感知、规划和工具调用。1. 先搞清楚 ExecuTorch 在设备端 Agent 里的角色1.1 设备端 Agent 是什么Agentic AI 通常不是一次“问一句答一句”的交互而是一套循环推理系统。系统先接收一个目标然后根据当前环境信息规划步骤必要时调用工具查看结果后继续下一步直到任务完成。可以将它拆成四个环节感知从摄像头、麦克风、传感器或系统状态中读取输入。规划根据目标和已有状态决定下一步动作。工具调用执行搜索、调用系统 API、读写本地文件或触发某个应用动作。反思根据执行结果修正计划决定是继续还是结束。传统做法是把这些过程放到云端大模型里完成。云端有更强算力和更大的模型但代价是网络依赖、隐私上送、单轮延迟和成本控制。所谓设备端 Agent是把至少一部分感知和规划放到手机、汽车座舱、平板或边缘设备上让关键响应在本地完成。如果一次 Agent 会话需要 20 次推理单次推理 200 毫秒、网络 500 毫秒用户体验差异会非常明显。因此设备端 Agent 的项目第一关注点不是“模型能不能跑”而是“在多轮循环下能不能稳定、快速、低内存地连续跑”。1.2 ExecuTorch 解决设备端推理的哪三件事ExecuTorch 是 PyTorch 面向端侧设备推出的可扩展推理执行库官方定位是让 PyTorch 模型能够高效地从训练框架迁移到移动和边缘硬件。具体到 Agentic AI 场景它解决的三个核心问题需要单独理解。第一是导出链路的确定性。PyTorch 模型在 Python 里是动态执行的包含大量控制流和中间对象。要在设备运行必须先把它转换成静态计算图。ExecuTorch 基于 PyTorch 的导出能力将模型从 eager 模式转成可执行程序。这个过程比“拿一个权重文件塞进引擎”更可控因为算子、内存、输入输出边界都会在导出阶段被检查和固化。第二是多硬件后端的适配问题。不同手机上的 CPU、GPU、NPU 能力差异很大。ExecuTorch 通过 delegate 机制把不同的算子分发到不同后端例如 CPU 上的 XNNPACK、部分厂商的 NPU/DSP 加速后端。模型无需为每种硬件各自写一套推理代码而是通过后端配置完成适配。第三是资源占用控制。设备端不像服务器可以随意申请内存。ExecuTorch 会做静态内存规划尽可能复用中间 buffer减少峰值占用。这一点对 Agent 多轮会话特别重要因为每一轮推理都可能分配新的中间结果。用一句话总结ExecuTorch 负责把 PyTorch 生态的天生 Python 动态模型变成一个可被手机原生程序加载的“端侧可执行产物”。1.3 Muse Glimmer 与 ExecuTorch 的分工在项目标题 “Fast, on Device Agentic AI with Muse Glimmer on ExecuTorch” 中Muse Glimmer 是模型角色ExecuTorch 是执行引擎角色。可以将 Muse Glimmer 理解为面向设备端 Agent 场景的一套轻量生成模型权重与方法集合。它不一定只有一个文件可能包含一个负责把图像、文本或传感器状态编码成向量的感知模块一个负责生成下一步决策文案或动作序列的语言/多模态主模型一个负责把模型输出映射成工具调用参数的输出头。ExecuTorch 加载的往往不是整个 Python 对象而是其中某个可执行方法。因此在项目里“把 Muse Glimmer 跑在 ExecuTorch 上”更像是在做模型切分、导出、量化和端侧调度而不是简单地把一个大模型塞进一个运行库里。理解这个分工非常重要。后续所有环境准备、代码导出、性能优化都围绕两条主线展开一条是模型侧的算子兼容和质量保持另一条是 ExecuTorch 侧的导出、编译和运行优化。下面按一条通用端侧 Agent 部署路径展开具体模型结构如果和你的实际仓库不一致需要同步替换模型加载和输入预处理部分。2. 动手前把环境定清楚避免后面全部白跑2.1 硬件选择为什么先用 ARM CPU 起步设备端 Agent 的目标平台通常是手机或嵌入式设备但如果一开始就尝试接厂商 NPU、调试驱动和 kernel 兼容性问题排查范围会非常大。推荐的第一阶段硬件是支持 ARMv8/AArch64 的 Android 设备或 ARM 开发板使用 ExecuTorch 的 CPU/XNNPACK 后端跑通闭环。先跑 CPU 版本不是“性能上可以使用”而是先验证模型能否被导出导出后输出是否与 PyTorch 一致端侧内存是否可控Agent 循环是否稳定哪些算子或者动态逻辑是当前链路不支持的因素。在 CPU 版本稳定后再根据目标设备的实际芯片接入加速路径。表格可以用于初期的平台决策验证阶段最低硬件主要目的不推荐的阶段基准验证x86_64 Linux 或 Mac看模型能否导出、量化精度不做真机验证端侧闭环ARMv8/AArch64 CPU稳定运行 .pte测内存和时延使用厂商私有加速后端加速阶段支持 NPU/DSP 的 Android/iOS 设备接入硬件的独立计算单元跳过 CPU 基线直接调加速器需要特别说明的是不同芯片厂商的加速方案需要独立的 SDK 和驱动版本因此加速阶段要按具体设备和算子分步做不能假设“同一个 .pte 在所有加速器上速度一样”。2.2 软件依赖对齐ExecuTorch 和 PyTorch 的版本是强绑定的。训练环境使用的一个 PyTorch 版本不一定能直接配任意版本的 ExecuTorch 使用。生产项目里强烈建议固定一套版本组合并记录到构建文件里而不是每次安装最新 nightly。常见部署链路会涉及这些软件依赖组件用途注意事项Python模型导出、量化、脚本化验证建议 3.8 到 3.11 范围内以 ExecuTorch 安装要求为准PyTorch模型训练和导出版本必须与 ExecuTorch 对应ExecuTorch模型图转换、量化、后端编译使用稳定 release 而不是临时分支Android NDK / SDK在 Android 设备上运行库要和 ExecuTorch 构建脚本要求的 NDK 版本对齐CMake编译 ExecuTorch runtime 和示例检查安装路径避免系统里存在多个互不兼容版本如果你是从源码编译推荐先执行类似下面的安装流程git clone --recursive https://github.com/pytorch/executorch.git cd executorch git checkout 固定的 release 版本 python -m pip install -e .从源码编译的好处是可以替换或调试算子实现缺点是构建时间较长。如果只需要跑通模型可以直接安装官方发布的 Python 包但一定要确认安装的 ExecuTorch 与项目使用的 PyTorch 版本一致。2.3 环境验证命令安装完成后不要马上进行深度学习模型导出先运行三个基本验证python -c import executorch; print(executorch.__version__) python -c import torch; print(torch.__version__) cmake --version如果 ExecuTorch 和 PyTorch 版本不匹配导出阶段很可能会出现“找不到 export 相关符号”“后端编译库版本不兼容”之类的报错。这类问题看起来是模型问题实际是环境问题。还需要确认目标设备是否能够访问或者并没有依赖云端资源。若设备端 Agent 需要联网只是作为一种可选的工具调用方式那么网络的消失不应导致本地核心规划崩溃。注意接触新的 ExecuTorch 版本时不要只依赖自动安装的依赖版本。建议查看源码目录下的 requirements 或构建说明把 Python、PyTorch、Nightly 版本一同锁定。3. 用代码完成 Muse Glimmer 模型到 ExecuTorch 的导出3.1 准备好模型对象并固定输入导出前第一步是拿到一个已经训练完成的 PyTorch 模型并把它切到 eval 模式。如果 Muse Glimmer 的真实实现里包含 batch normalization 或 dropout缺少 eval 会导致导出的图行为不稳定。下面是一段结构示意代码用于说明导出流程。真实项目里create_muse_glimmer_model需要替换为模型仓库中提供的加载函数。import torch import torch.nn as nn class MuseGlimmerLikePlanner(nn.Module): def __init__(self): super().__init__() self.encode nn.Linear(64, 32) self.head nn.Linear(32, 8) def forward(self, feature, text_ids): x torch.relu(self.encode(feature)) out self.head(x) return out model MuseGlimmerLikePlanner() model.eval() feature_example torch.randn(1, 64) text_ids_example torch.tensor([[1, 2, 3]])这里需要确定两件事第一是输入的真实 shape第二是 dtype。很多设备端模型会因为torch.long输入和float32输入混用导致导出后算子精度出现意外。建议在导出前先固定好输入顺序每个输入的最小和最大 shape输入的 dtype输出是否需要统一为列表或单 Tensor。3.2 导出、to_edge、lowerExecuTorch 的导出链路通常经过几个阶段先用 PyTorch 的export捕获静态图再转到 ExecuTorch 的 edge 中间表示最后编译后端并生成.pte文件。这里的示例代码是 ExecuTorch 常见的结构示意不同版本 API 可能有差异以你锁定的源码样例为准。from executorch import exir from torch.export import export example_inputs (feature_example, text_ids_example) exported_program export(model, example_inputs) edge_program exir.to_edge(exported_program) executorch_program edge_program.to_executorch()如果你用了特定加速后端通常是在to_edge之后执行 lowest 操作把可落地的算子分配到指定 backend。例如edge_program exir.to_edge(exported_program) delegated_program edge_program.to_backend(xnnpack) executorch_program delegated_program.to_executorch()这段代码的关键意义在于导出阶段没有直接使用 model 的forward而是通过静态图和中间表示。若模型里有 Python 的if、动态循环或使用了不支持的数据结构导出就可能报错。很多人第一次导出失败不是 ExecuTorch 本身的问题而是模型里保留了训练阶段的动态逻辑。可以用更简洁的方式把结果写入.ptewith open(muse_glimmer.pte, wb) as f: f.write(executorch_program.buffer)写入后立刻检查文件大小。生产环境会把这个文件作为二进制资产打包进应用而不是在设备侧再执行 Python 导出。3.3 量化与预处理设备端内存通常有限float32 权重会对电池和内存造成压力。ExecuTorch 支持在部署前做量化常见方案包括动态量化和静态量化两种。动态量的量化比较适合文本生成这类带线性层的模型它不需要额外的校准数据集在运行时按实际输入范围动态决定量化参数。静态量的量化更适合卷积这类结构固定、数值分布稳定的算子但它需要先准备一批代表性输入做校准否则很容易出现量化后精度明显下降。下面是一个量化流程的示例思路# 伪代码说明需要在导入 ExecuTorch 量化 API 后准备好一批校准输入 calibration_inputs [feature_example, text_ids_example] quantizer prepare_quantizer(model, modedynamic_int8, inputscalibration_inputs) quantized_model quantizer.quantize()真实项目里量化前还要先跑一遍浮点模型记录每个输入对应的输出作为量化后的对照基线。不要只比较 loss而要比较 Agent 关心的最终动作或工具调用结果是否一致。比如模型输出“调用天气接口参数 cityShanghai”量化后如果变成“调用天气接口参数 cityNone”即使 loss 差值很低也不能接受。3.4 输出 .pte 与模型检查生成.pte后推荐先在桌面环境做一个解包检查确认文件可以被 ExecuTorch 的加载器读出来而不要直接扔进手机。检查项包括文件头是否完整是否包含预期的方法列表输入元数据和输出元数据是否符合要求如果做了量化是否在导出图里已经替换了量化算子如果做了 delegate是否有部分算子回退 CPU回退比例是否可控。这类检查可以使用 ExecuTorch 提供的 Python API 或者直接用简单 Tensor 运行来验证。若模型文件写出来之后无法任意修改需要建立一份清单记录每个.pte文件对应的模型 commit、量化方式、校准数据和导出参数。否则生产阶段一旦模型更新很难定位是“代码问题”还是“模型版本问题”。4. 设备端 Agent 循环要在 ExecuTorch 上跑多次推理4.1 Agent 推理循环的常见形态模型部署完成后最容易忽略的一件事是Agent 不是单次推理接口而是一个长时间运行的循环。一轮典型的端侧 Agent 流程可能包括用户说“帮我订明天下午的会议室”音频或文本被转成向量Agent 决定调用日历工具工具返回空闲会议室列表Agent 再次推理选择会议室并生成确认话术。在这个过程里模型可能被调用 3 到 10 次如果任务更复杂还会超过 10 次。因此性能优化不能只看“单次模型 forward 多快”还要看“一轮 Agent 任务总耗时是多少”。如果每轮都重新加载.pte或重新申请大块内存延迟会成倍放大。正确做法是把模型加载成常驻对象让 Agent 循环复用同一个执行上下文。4.2 用 C 加载 .pte 并执行 forward在手机生产应用中推理侧通常用 C/Java/Kotlin而不是 Python。ExecuTorch 提供 C Module API加载一个.pte文件后可以调用其方法。下面是最小结构的伪代码示意#include executorch/extension/module/module.h #include vector #include string using torch::executor::Module; int main() { Module module(muse_glimmer.pte); auto method module.load_method(forward); std::vectoruint8_t data1 /* 读取输入1 */; std::vectoruint8_t data2 /* 读取输入2 */; // 这里需要把模型输入转成 ExecuTorch 的 Tensor 类型 auto result method-forward(/* input tensors */); return 0; }在真实 Android 工程里代码会放在 JNI 层Java/Kotlin 本地方法将输入字节传给 CC 执行完再把输出向量返回。不要在 Java/Kotlin 层循环调用 C 小函数否则 JNI 调用开销会吃掉大量优化收益。更推荐的结构是Agent 的整体循环也放在 C 层或专门的 native runtime 中Java/Kotlin 只负责 UI 和系统服务调用。这样反复推理时可以持续复用模型对象和内存 buffer。4.3 多入口模型如何处理Agent 模型往往不只是单一 forward 入口。它可能有encode_observation处理视觉或传感器输入plan生成下一步动作reflect根据结果判断是否需要继续。ExecuTorch 支持在一个.pte文件中包含多个 method。处理思路是导出时把每个需要的模块方法都存进同一个程序再在端侧逐个加载。这样能减少文件个数也让模型调用关系保持清晰。如果模型太大把多个入口塞进一个.pte可能造成启动加载时间过长。可以考虑只保留真正需要的入口其余部分拆到辅助模型。拆分后每个.pte更小端侧加载更灵活但需要在 Agent 代码里维护多个执行入口的状态同步。4.4 设备端 token 与缓存管理的取舍生成类模型必须在设备端处理词表映射和上下文缓存。常见误区是把每次生成都当成完全 independent 的请求导致前面生成的 token 历史每次重新处理。可以按是否涉及自回归生成来做如下判断如果模型是单次输出答案或动作缓存问题不严重如果模型是多轮生成且需要保留历史上下文则要考虑 KV Cache 或类似机制的复用如果 Agent 决定调用工具后模型要基于“历史 工具结果”继续生成若缓存策略设计不当每轮都会丢上下文。设备端缓存策略要同时控制长度和内存。建议设置最大轮数和最大历史长度当接近上限时进行摘要压缩而不是直接无限追加 token。注意不要追求在设备端复现完整的大语言模型推理栈。移动设备的 Agentic AI 更适合“把连续对话变成受控流程”在流程节点上调用小模型而不是让模型自由生成一大段文本后再解析。5. 性能指标与调优手段5.1 先建立基准测试没有任何模型调优能在缺少基准的情况下展开。建议在桌面和真机分别建立基线指标测量方式建议关注文件加载时间从Module构造开始到首次可调用用户感知启动速度首次推理耗时冷启动后第一次 forward排除初始化步骤影响稳定推理耗时预热 3 到 5 次后取 P50/P95反映真实稳定性能峰值内存单轮 agent 循环过程中的 RSS / 专用内存记录避免应用被杀功耗相同任务周期下的电量消耗长时间 agent 会话关键指标成功率Agent 最终任务完成占比端侧效果验证最重要记录基线时先不要改任何优化参数。连续跑 50 轮任务把每一轮各阶段耗时打点出来然后画分布图。很多问题只有在多轮分布中才能体现比如第一次很慢、后续变快说明模型加载路径可能包含了重复初始化或者某几次特别慢可能是后台 GC 或系统调度引起。5.2 用 ETDump 与 Trace 定位慢点ExecuTorch 运行时提供了事件跟踪相关能力用来查看每个算子或 delegate 模块的执行时间。使用前要确认目标是 debug 编译因为 release 版本可能裁剪了调试符号。定位慢点一般按以下顺序先确认耗时集中在模型调用还是 Agent 的预处理/后处理如果模型调用耗时很高再看是算子执行慢还是输入拷贝耗时如果输入拷贝耗时很高检查是否在每次调用时都重建 Tensor如果某个算子慢看它是否可以被融合或替换如果在特定 delegate 下慢尝试切回 CPU 后端对比一次确认是硬件加速未生效还是 kernel 未优化。一个常见误判是“NPU 一定比 CPU 快”。实际上某些小型矩阵运算或动态 shape 操作在 NPU 上可能因为数据搬运和算子切分而变慢。因此性能优化必须以实测为准而不是只看理论算力。5.3 量化、委托和内存规整下面是几种常用优化手段及其适用场景优化手段主要作用使用前提风险动态 int8 量化减少权重内存适配线性层模型结构稳定精度可能下降静态 int8 量化更适合卷积和固定 shape 模型需要代表真实场景的校准数据校准数据偏差导致离线精度和真实精度不一致权重预打包将权重转换为后端友好格式使用对应后端导出的.pte与后端绑定Delegate把算子放到专用硬件后端支持列表清晰不支持算子回退 CPU 反而更慢内存 buffer 池复用减少重复申请推理循环可复用需要管理生命周期具体选型时建议性能调查优先于模型结构改动。一个线性层可以动态量化且不影响工具调用那么先做量化若量化后效果大幅下降则需要根据量化敏感层列表做混合量化。这也说明模型在 PyTorch 阶段就应设计成“便于导出和量化”的结构例如避免大量自定义 Python 函数作为前向主体。5.4 模型分段与端侧回退设备端 Agent 的一个实用模式是“分层执行”把高频率、低延迟的简单任务放在本地轻量模型将复杂推理放到更大模型或云端。例如 Muse Glimmer 在本地负责意图判断和结构化动作生成但当输入很复杂或置信度较低时流程可以预定义一个回退策略。回退不一定是每次请求都上传用户数据而可以是在设备端返回“需要更多信息”或者延迟到用户主动选择联网后执行。这个策略应作为系统逻辑明确控制不能让模型自行决定访问任意主机或执行任意命令。6. 常见失败现象和排查路径6.1 导出阶段失败导出阶段最常见的问题是模型包含不受支持的算子或动态控制流。错误表现往往是导出时出现 Warning部分模块被标记为unsupported报错信息中包含 Python 特殊对象.pte生成成功但在端侧加载失败。排查时先用最小模型验证 ExecuTorch 安装是否正常再逐步加入真实模型模块。不要一开始就把整个 Agent 模型塞进导出流程。可以将模型按 submodule 拆分逐一导出定位不兼容算子。可能原因和处理建议可以整理成下面的表格现象常见原因检查方式解决建议报not safe to evaluate模型中存在 Python 控制流打印导出 traceback定位到具体 op将动态控制流移到框架代码或 Agent 循环中报 shape 不匹配输入没有固定 shape查看模型 forward 中 reshape 的位置要么固定输入 shape要么改用动态 shape 支持报量化精度下降量化层选择不当对比量化前后输出使用混合量化敏感层保持高精度.pte后无法运行后端和生成代码不匹配检查.pte导出时是否绑定 delegate使用与目标设备匹配的后端重新导出6.2 加载和推理阶段失败.pte已经制作成功但在 Android/iOS 真机上加载失败常见的三类原因是第一目标 ABI 不一致。ExecuTorch 的 native 库必须针对设备的 arm64 架构构建如果用的是 x86 模拟器库在真机上无法运行。第二模型和 runtime 版本错位。ExecuTorch 的.pte不是纯普通格式导出时使用的新版运行时必须与设备上链接的运行时版本兼容。项目里如果并存多版本库很容易出现“pc 上能跑、手机上报格式错误”。第三模型文件没有正确打包。Android 场景里.pte文件要放到 assets 中并确保不会被压缩读取方式改变。如果文件太大或路径拼错加载时读到的是一段不完整内容问题会表现为随机崩溃或空输出。排查建议是先在终端模拟或最小 C 可执行文件里加载同一个.pte。如果桌面环境能跑再查移动端集成如果桌面环境不能跑问题大概率在模型或导出阶段。6.3 量化后输出不稳定量化后 Agent 的任务成功率下降这类问题比较隐蔽。常见原因不是量化工具失效而是校准数据集和真实场景差异太大。比如校准数据都是英文短句真实场景却是中英文夹杂、带标点和噪声量化模型就会对分布外的样本输出偏移。处理路径如下先收集 100 到 500 条真实设备端输入在浮点模型上推理一次记录结果在量化模型上推理同一批数据对比动作级结果找出任务失败样本判断是哪个模块的偏差导致对偏差大的模块做混合量化或保持浮点。不要只用一个 “accuracy” 数字掩盖问题。Agent 关心的不是平均相似度而是关键字段是否完整。6.4 统一排查顺序当系统表现异常时按下面的顺序排查可以有效避免被表面现象带偏确认模型输入是否正确输入 shape、dtype、归一化方式。确认.pte文件版本是否和 runtime 版本一致。确认运行硬件是否为当前导出目标。确认模型是否首次加载首次耗时和稳定耗时是否分离。确认 Agent 循环中的状态管理是否正确。确认日志里是否有算子回退或 delegate 失败提示。最后再怀疑 ExecuTorch 或模型本身。很多项目在 ExecuTorch 集成期遇到的“推理慢”最后都变成“每次循环都重新加载模型”或者“JNI 层频繁拷贝输入”因此前 5 步排查往往能解决大部分问题。7. 从 Demo 到生产可复用清单与实践建议7.1 生产环境需要关注的差异学习环境和生产环境有一个重要差别学习环境只需要一次模型 forward 能产出结果生产环境还要求整个 Agent 流程可被监控、可回滚、可审计。以 Muse Glimmer 在 ExecuTorch 上的落地为例生产环境至少需要关注这些内容关注点说明模型版本管理.pte文件、Python 导出脚本、模型权重 Source Commit 必须关联配置外置化模型路径、执行轮数上限、工具超时等参数不应硬编码日志脱敏Agent 可能会处理个人输入日志不能直接记录明文设备数据异常处理模型加载失败、单轮超时、输出解析失败都要有兜底话术功耗监控一次本地 Agent 任务消耗的电量需要纳入验收标准A/B 测试模型更新后应有任务成功率对比而不是只看离线指标回滚方案新版.pte在真机崩溃时客户端应能切换回上一个稳定版本另外模型文件一旦与特定后端绑定更换目标设备或后端时不能只替换.pte还要核对导出时使用的后端和算子版本。生产发布流程里要把.pte文件的构建信息写入一个文件头或配套 JSON便于事后核对。7.2 发布前检查清单可以直接把下面这份清单用于一次版本发布前的检查和验收。[ ] 已锁定 ExecuTorch、PyTorch、NDK/SDK 版本并记录到构建配置。[ ] 已完成导出并生成.pte桌面端多次加载运行成功。[ ] 已对比浮点模型和最终量化模型在 100 条以上真实输入上的动作级结果。[ ] 已确认.pte中所有算子被后端支持不支持算子数量可见且可控。[ ] 已使用真机记录首帧加载时间、稳定推理耗时和峰值内存。[ ] 已在 Agent 循环中执行连续 10 到 20 轮任务没有出现内存持续增长。[ ] 已确认输入异常时不会触发模型以外的本地工具调用。[ ] 已验证断网情况下 Agent 核心功能仍可运行或能给出明确提示。[ ] 已准备好模型崩溃后的 fallback 策略。[ ] 已设置日志脱敏不记录未授权的个人隐私内容。这份清单在执行到一定程度后会越来越像一份端侧 Agent 的最低上线标准。每一行都可以继续拆分比如“真机记录峰值内存”要区分 Python demo、JNI 层和最终 app 三种场景因为集成层不同内存差异会很大。7.3 在 ExecuTorch 上继续推进的方向当模型可以在设备端稳定运行后下一步可以按这个顺序推进。首先继续优化单次模型推理性能。到这里再回头检查模型的 Attention 或线性层看有没有因为导出选择而退化成低效 kernel。使用 Profiler 找出前 5 个耗时算子逐个判断是否能融合或委托。其次把 Agent 的状态管理做得更完整。设备端 Agent 不是单纯的模型预测还需要管理任务队列、工具调用超时、上下文长度限制和用户中断。建议把这些逻辑模块与 ExecuTorch 推理解耦形成独立的 runtime。再次扩展多模型组合。Muse Glimmer 可能只是 Agent 的主模型实际场景还需要语音识别、图像理解、本地检索等辅助模型。ExecuTorch 可以同时加载多个.pte但是否把它们放在同一个进程、如何共享内存都需要做压力测试。最后建立一套可回归的评测集。设备端 Agent 的评测不只是跑几个 prompt而应模拟多轮任务。每个用例需要包含输入、可用工具、正确结果和失败时的兜底动作。模型每次更新都在这套评测集上跑一遍才能避免“修了一个 bug引入一个更隐蔽的问题”。设备端 Agent 与云端 Agent 的差异在于每一次推理都有真实的内存、功耗和延迟代价。真正适合 ExecuTorch 的项目往往是模型不必过大、任务边界清晰、强调本地响应和隐私保护的类型。把 ExecuTorch 的导出和运行机制掌握清楚再基于 Muse Glimmer 这类轻量模型构建受控的 Agent 流程这条路会越走越顺。
