当 Agentic AI 开始从云端走向手机、车机、智能硬件时最核心的矛盾不是“模型会不会选工具”而是“延迟和隐私能不能接受”。ExecuTorch 作为 PyTorch 官方的端侧推理运行时承担的是把模型搬到设备上的最后一段路而像 Muse Glimmer 这样主打低延迟、轻量化的模型设计又给 Agent 循环提供了可以放在本地执行的“大脑”。本文将围绕 ExecuTorch 上的端侧 Agentic AI 实战展开先讲清楚方案的基本概念再给出从模型导出、量化、运行时集成到工具调用闭环的完整示例。如果你是刚接触 ExecuTorch 的开发者或者已经完成了云端大模型调用、但一直想尝试让 Agent 真正运行在用户设备上的工程人员这篇文章可以帮你少走很多弯路。我们会在行文中使用 Muse Glimmer 作为示例模型名但我们不会把重点放在某一款模型的具体参数上。ExecuTorch 的导出与部署链路是通用的只要最终你拿到的是一个可以通过结构化输出完成意图识别、工具选择的模型都可以参考这套流程。下面的内容包含可复制的 Python 导出脚本、端侧 Agent 循环伪代码、Android 集成注意事项以及一份高频问题排查表。建议收藏后对照实践而不是只当作概念文章阅读。理解 ExecuTorch 的运行机制才是掌握端侧 Agentic AI 的关键。1. 为什么要做 on-device Agentic AI1.1 Agentic AI 与传统 AI 助手的区别传统 AI 助手的典型工作方式是“用户提问、模型回答”它更像一个增强版的搜索框或聊天机器人。而 Agentic AI 的核心特征是模型能够根据当前对话目标自主决定下一步动作是继续追问用户、调用本地工具还是直接生成结果。比如用户说“帮我查一下明天下午有没有空会议室并预定一间”云端版本需要把会议系统、日历系统等多个 API 全部接入再交给云端大模型做函数调用端侧版本则直接在手机本地扫描日历、请求会议室服务权限模型只在本地完成语义理解和决策数据不需要上传。这种能力并不等于让模型在所有问题上都做得更聪明而是让模型的行为模式从“一次性回复”变成“目标导向的循环”。Agentic AI 在端侧运行时会频繁用到两个基础能力一个是意图识别另一个是结构化输出。意图识别决定下一步该触发哪个工具结构化输出则保证模型返回内容能被代码严格解析例如输出{tool: query_calendar, params: {date: 2025-06-10}}。所以端侧 Agent 真正要解决的是延迟、稳定性和资源占用之间的平衡。1.2 为什么必须把 Agent 放到设备端过去几年很多团队习惯把所有智能能力都放到云端因为大模型推理需要的显存和算力远超普通手机。但真实场景中存在三个无法回避的问题第一是延迟云端往返会造成几百毫秒甚至数秒的等待而很多 Agent 场景需要的交互响应是 100ms 级别第二是隐私日历、通讯录、位置、健康数据等一旦发送到云端合规成本和数据泄露风险都会明显上升第三是可用性在弱网、飞行模式或者地下车库环境下离线 Agent 能力往往才是用户体验的底线。端侧推理借助芯片厂商的 NPU、DSP 以及量化压缩技术目前已经可以在手机上流畅运行数十亿参数的小模型。与其把用户每句话都交给云端处理不如将高频、敏感、延迟敏感的操作留在本地只把真正需要通用知识库的任务抛给云端。这也是“on-device Agentic AI”价值最直接的体现用户数据和工具调用命令不出设备Agent 依然可以完成日历查询、消息发送、快捷指令编排等具体任务。1.3 ExecuTorch 与 Muse Glimmer 在方案中的分工ExecuTorch 是 PyTorch 为移动端、嵌入式设备和桌面端提供的一个可扩展推理运行时。它没有采用“套壳浏览器”或“单独训练模型”的方式而是尽量复用 PyTorch 生态你先在服务器或本地训练好模型再把 PyTorch 模型导出成 ExecuTorch 的.pte格式最后把.pte文件和 ExecuTorch runtime 集成到 App 中。这样的好处是模型训练、调优、评估仍然沿用已有工具链只在最终部署环节引入新的运行时。Muse Glimmer 这类端侧模型的价值在于把 Agent 能力压缩到设备可接受的范围内。它不是替代 ExecuTorch 的推理框架而更像一个经过剪枝、量化或蒸馏后的模型实例。在本文中我们会把muse_glimmer.pte当作我们导出后的产物名称来使用。模型和运行时两者是分工关系模型负责接收 token、输出结构化的 Agent 动作ExecuTorch 负责在设备上高效执行模型推理二者共同组成一条可落地的端侧 Agentic AI 链路。2. 整体架构与运行流程2.1 端侧 Agent 的闭环结构一个完整的端侧 Agent 闭环通常由四部分构成用户输入、Agent 策略模型、工具执行器、环境反馈。用户输入并不一定是纯文本也可以来自语音识别结果或系统事件。Agent 策略模型负责把输入转化为动作意图例如“打开勿扰模式”“查询明天的日程”“给某位联系人发送消息”。工具执行器是模型与系统能力之间的桥梁每个工具对应一段可被代码调用的函数。环境反馈则把工具执行结果写回上下文让模型继续决定是否还需要下一步操作。在云端 Agent 中模型可能会根据反馈多次调用在线 API在端侧 Agent 中我们通常希望循环尽量短。最常用的策略是先让模型对用户意图做一次结构化预判如果置信度不够再追加一句澄清式问答。下面是一个简化的流程列表获取用户输入把对话内容整理成模型可接受的 token。模型运行一次推理输出结构化动作包括工具名、参数和可选内容。代码解析结构化动作决定调用本地工具还是直接回复。工具执行后把结果拼接到下一轮上下文中。当模型输出代表“任务完成”的标记或达到最大轮数时结束循环。这个闭环并不强调模型能写多复杂的代码而是强调代码侧的调度能力要足够可靠。模型每一步只需要做“下一步该做什么”的判断真正执行动作的永远是本地原生函数。2.2 ExecuTorch 的模型编译与加载流程ExecuTorch 的工作可以粗略切成两个阶段导出阶段和运行阶段。导出阶段通常发生在开发者电脑上你需要通过 PyTorch 的torch.export得到中间表示再经过to_edge做图优化和适配最后调用to_executorch生成.pte文件。在这个阶段也可以插入量化、算子替换、内存规划等优化步骤使模型更适配移动端 NPU 或 CPU。运行阶段发生在设备上。App 正式打包时会包含ExecuTorch runtime 动态库与模型算子对应的 kernels.pte模型文件Agent 调度代码Kotlin、Swift 或 C。运行时加载.pte文件后并不负责 Agent 策略它只负责“喂入输入张量、执行模型、返回输出张量”。所以端侧 Agent 的工程难点往往不是模型训练而是如何设计一个稳定、低延迟、可观测的调度层。从架构上看模型是决策引擎工具是执行器Agent 策略代码是决策引擎与执行器之间的胶水层。2.3 什么时候适合上 ExecuTorch什么时候不适合并不是所有 Agentic AI 都必须跑到设备端。如果任务高度依赖实时更新的网络知识库或者需要综合调用几十个云端服务当前更适合保留云端 Agent。如果任务需要毫秒级本地响应或者处理的数据高度敏感则适合上 ExecuTorch。项目启动前建议先做一次“端云拆分”把高频、低语义复杂度、隐私敏感的动作放到端侧把知识覆盖广、需要海量上下文的任务放到云端。同时也要评估模型体积与设备算力。一个 7B 模型经过 4bit 量化后仍然有 4GB 左右大小对多数手机有压力而 Muse Glimmer 这样的轻量模型目标应用场景通常是 1.5B 至 3B 参数范围。如果你手里的模型根本无法在目标设备上跑到可接受延迟那么再精美的框架也无法救回来。ExecuTorch 的价值在于让模型“跑得动”但它不能凭空抹掉算法的资源开销。3. 环境准备与版本说明3.1 开发环境概览本文示例以 Python 环境完成模型导出以 Android 工程演示运行时集成。系统环境需要满足以下条件Linux 或 macOS 比较推荐Windows 也可以完成部分 Python 侧流程但 Android 交叉编译会遇到更多坑Python 使用 3.9 或更高版本PyTorch 版本必须与 ExecuTorch 有对应关系建议使用官方文档中指定的组合。由于 ExecuTorch 迭代速度较快不同版本之间 API 可能有变化所有代码示例都会标注“以你的实际版本为准”。你需要准备下面几类工具Android Studio 或 Android NDK用于编译集成端Python 环境建议使用虚拟环境venv一个已经通过 PyTorch 保存的模型权重比如pytorch_model.ptCMake、Ninja 等构建工具如果你需要在本地跑 ExecuTorch 测试用例一台 Android 真机或模拟器真机更接近弱网、低内存的真实场景。版本细节这里不写成确定数字因为 ExecuTorch 每个 release 的依赖经常变化。最稳妥的方法是把 ExecuTorch clone 到本地后直接使用文档要求的分支而不是凭记忆安装最新版。3.2 准备 ExecuTorch 依赖你可以用 Git 拉取 ExecuTorch 主库并进入对应目录安装 Python 依赖。官方仓库通常会提供requirements.txt或脚本下面的命令只作参考git clone --depth 1 https://github.com/pytorch/executorch.git cd executorch python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt在执行这组命令之前建议先确认你的 PyTorch 版本。如果 PyTorch 版本比 ExecuTorch 对应版本新很多导出时容易出现算子不兼容问题。一个常见的做法是先安装 ExecuTorch 文档要求的最低 PyTorch 版本再在虚拟环境中运行模型导出。不要图省事事直接在全局环境安装避免污染未来项目。3.3 演示项目目录本文中的示例会按照下面的目录结构组织方便你理解每个文件的作用on_device_agent_demo/ ├── export_model.py # 导出executorch模型 ├── agent_loop.py # 端侧agent闭环演示 ├── mobilenet_agent.pte # 导出的模型产物 ├── android/ │ ├── app/src/main/cpp/ # JNI executorch runtime代码 │ └── app/src/main/java/ # Android层调用 └── tools/ └── local_tools.py # 工具注册示例这个目录不是固定标准只是为了让我们后面的代码讲解有明确的归属。实际项目中你完全可以把模型导出放到独立的模型仓库把 runtime 集成放到移动端仓库二者之间只通过.pte文件交付。4. 将模型导出为 ExecuTorch 格式4.1 从 PyTorch 模型完成一次最小导出ExecuTorch 模型导出流程的第一个核心是torch.export。我们需要一个已经训练好的模型并准备好样例输入这样才能把动态模型结构固化成一整套可执行图表。下面是一个最小导出示例# export_model.py import torch from executorch.exir import to_edge from executorch.exir import ExecutorchProgramManager class MuseGlimmerLite(torch.nn.Module): def __init__(self): super().__init__() self.fc1 torch.nn.Linear(128, 256) self.fc2 torch.nn.Linear(256, 4) self.act torch.nn.ReLU() def forward(self, x): x self.act(self.fc1(x)) return self.fc2(x) model MuseGlimmerLite() model.eval() example_input torch.randn(1, 128) exported_program torch.export.export(model, (example_input,)) edge_program to_edge(exported_program) executorch_program edge_program.to_executorch() with open(muse_glimmer.pte, wb) as f: f.write(executorch_program.buffer) print(export finish: muse_glimmer.pte)说明一下为什么示例模型这么简单。ExecuTorch 导出链路同样适用于 Transformer 类结构但 Agent 模型导出时往往包含 tokenizer、embedding、attention mask 等复杂输入。最小示例的价值是先把流程跑通确认 ExecuTorch 安装成功然后再替换成真实模型。如果你导出一个大模型example_input通常是input_ids张量形状类似(batch_size, sequence_length)并且可能还需要传入past_key_values等缓存参数。4.2 量化与内存优化模型导出后体积往往仍然偏大。端侧执行真正的资源瓶颈首先是模型体积其次是运行时峰值内存。ExecuTorch 支持多种量化方式常见思路是把权重从fp32压缩到int8或int4。以线性层量化为例如果目标 CPU 上不支持 int8 矩阵乘加速量化反而可能变慢所以必须针对目标硬件做 benchmark。下面给出一个带量化逻辑的导出片段。由于不同版本 API 差异较大这里的写法更多是示意你需要查阅对应版本的 ExecuTorch 量化文档# export_quantized.py 片段使用示意API from executorch.backends.x86.partitioner import X86Partitioner from executorch.exir.backend.compile_spec_schema import CompileSpec # 请以你的实际SDK文档为准为了避免把不存在的 API 写得太详细建议采用更稳妥的做法先检查 ExecuTorch 仓库里的examples目录找到官方量化脚本沿用其中已验证的封装函数。不要从网上复制一个无人维护的旧脚本直接上生产ExecuTorch 的 API 演进非常快。4.3 导出后的检查与验证导出.pte后至少要做三种检查。第一种是文件大小检查判断是否超过端侧安装包可接受范围。第二种是端到端一致性检查用同一个输入分别在 PyTorch 浮点模型和 ExecuTorch 导出模型上跑对比输出差异量化模型允许轻微误差但误差不可太大。第三种是算子覆盖检查如果执行时出现 “operator not supported”说明模型里包含 ExecuTorch runtime 尚未支持的算子。ls -lh muse_glimmer.pte如果你使用的是文本模型还需要检查 tokenizer 文件是否缺失。因为.pte文件通常只保存模型权重和计算图不保存词表与 tokenizer 配置部署时必须把 tokenizer 单独打包进 App。这个细节很容易被忽略也是最常见的端侧 Agent 启动崩溃原因之一。5. 编写端侧 Agent 推理与工具调用闭环5.1 结构化输出与意图识别Agent 模型完成推理后得到的结果通常不能直接用于工具调用。我们需要定义一套稳定的协议例如 JSON 格式的结构化输出。一个安全的策略是把输出限定在几个固定字段tool表示工具名params表示工具参数done表示是否已经完成。下面的代码是一个简单但完整的意图解析函数# agent_loop.py 片段 import json def parse_model_output(raw_text: str) - dict: text raw_text.strip().strip(json).strip().strip() try: return json.loads(text) except json.JSONDecodeError: return {tool: fallback, params: {message: raw_text}, done: True}这里的fallback工具可以避免模型输出非法 JSON 时程序直接崩溃。真实项目中还需要处理模型在 token 中间被截断的情况比如只输出半个 JSON 对象。你可以先用正则或循环补全括号但更稳妥的做法是让模型在生成结束前输出一个特殊结束符代码检测到结束符后再进入解析流程。5.2 工具注册与本地调用端侧 Agent 的工具数量不需要特别多但每个工具都需要有明确的 schema。我们用 Python 演示一套工具注册机制在实际 Android 项目中会用 Kotlin 或 C 实现同等逻辑TOOL_REGISTRY {} def register_tool(name): def wrapper(func): TOOL_REGISTRY[name] func return func return wrapper register_tool(open_flashlight) def open_flashlight(params): # 在实际App中调用硬件能力这里是模拟 return {status: success, result: flashlight opened} register_tool(query_calendar) def query_calendar(params): date params.get(date, today) return {status: success, result: fcalendar info for {date}}工具函数返回的结果必须能自动转换为字符串或结构化数据因为下次模型推理时需要把这些结果重新拼进上下文中。为了安全工具执行前应校验参数类型避免模型把一个字符串参数传给了要求整数参数的函数。5.3 完整的 Agent 循环下面是一个最小的模拟循环。它假设模型已经被封装成run_pte_inference函数输入是上下文字符串输出是原始文本。代码的核心价值不是最终可上生产而是展示一个可运行的 Agent 闭环骨架def run_pte_inference(context: str) - str: # 实际的 ExecuTorch 推理需要把文本转成 token_ids # 这里用 mock 代替帮助你先把循环逻辑跑通。 return json.dumps({tool: query_calendar, params: {date: tomorrow}, done: True}) def agent_execute(user_input: str, max_steps: int 3): context fuser: {user_input}\n step 0 while step max_steps: step 1 model_output run_pte_inference(context) action parse_model_output(model_output) if action[done]: return {response: action[params].get(message, done)} tool_name action[tool] tool_func TOOL_REGISTRY.get(tool_name) if tool_func is None: context assistant: unknown tool, please retry\n continue observation tool_func(action[params]) context fobservation: {observation}\n context assistant: continue\n return {response: reach max steps} if __name__ __main__: result agent_execute(帮我看看明天的日程) print(result)这段代码中工具调用结果被追加到context下一次推理就可以参考最新 observation 决定是否执行更多步骤。实际 Agent 模型往往需要从输入文本到张量的转换所以你的run_pte_inference内部至少要做四件事分词、padding、调用 ExecuTorch runtime、解码输出 token。为了方便调试可以把每一步context打印出来这会非常直观地展示模型决策链路。6. 移动端部署 ExecuTorch以 Android 为例6.1 将 ExecuTorch runtime 接入 AndroidExecuTorch 在 Android 端的集成主要有两种方式第一种是使用官方预编译 AAR第二种是通过 CMake 自行编译适合需要自定义算子或特定后端时使用。无论哪种方式都需要把.pte模型文件放入 Android 工程 assets 目录并在启动时复制到可读路径或直接通过 AssetManager 加载。通常而言C 层负责 ExecuTorch runtime 的初始化JNI 层向上暴露 Java/Kotlin 可调用的接口。下面是一个典型的 CMake 集成片段cmake_minimum_required(VERSION 3.18) project(executorch_agent) set(CMAKE_CXX_STANDARD 17) add_library(executorch_agent SHARED native_lib.cpp ) target_link_libraries(executorch_agent executorch extension_module extension_aten_util )这里的executorch、extension_module等目标名取决于你的 ExecuTorch 构建配置。如果直接使用预编译 AARCMake 文件中只需要链接官方提供的库和自己实现的 JNI 代码即可。6.2 JNI 调用与内存管理当 Android 端加载.pte文件后程序会得到一个Module对象。初始化需要指定执行后端、线程数和是否启用内存规划。JNI 方法通常分为两步先加载模型再执行推理。加载阶段完成后模型会持有较大的权重内存因此 App 应当在 Agent 页面打开时初始化在页面销毁时释放而不是每次请求都重新加载。下面是一段示意性的 JNI 头文件真正的实现可能因为 ExecuTorch 版本不同而有差异// native_lib.h 示意 extern C JNIEXPORT jlong JNICALL Java_com_example_agent_MuseGlimmerEngine_loadModel(JNIEnv *env, jobject, jstring path); extern C JNIEXPORT jstring JNICALL Java_com_example_agent_MuseGlimmerEngine_predict(JNIEnv *env, jobject, jlong handle, jstring input);如果你的 Agent 模型是增量式文本生成单次预测会返回多个 token。更好的做法是暴露一个流式回调Kotlin 层收到新的 token 后一边更新 UI 一边判断是否到达结束符。内存管理上需要特别注意long handle对应的 native 对象如果不主动释放一定会造成内存泄漏。6.3 性能调优与弱网体验移动端 Agent 通常会同时使用 CPU、NPU 和内存资源。如果模型与 NPU 兼容优先选择 NPU 后端但在开发阶段CPU 后端能更好地验证功能一致性。启动推理前可以通过 ExecuTorch 配置设置线程数不同线程数对延迟影响很大通常建议跑一组基准测试线程 1、2、4 分别测试找到吞吐量与功耗的平衡点。弱网环境下端侧 Agent 最好的体验不是完全不出网而是“本地快速处理网络只在必要时使用”。例如查询本地天气缓存可以直接由本地工具完成更新在线日历再触发网络请求。如果网络请求失败Agent 可以选择回退到内置默认结果而不是让用户一直等待转圈。整个过程需要做到交互界面反馈与后台推理异步解耦避免 UI 线程阻塞。7. 常见问题与排查思路ExecuTorch 部署链路比较长这里把高频问题整理成一张表方便你直接定位。如果你遇到的报错不在表内建议先搜索 ExecuTorch 官方 GitHub issues关键词不要只写报错原文要带上 ExecuTorch 版本、目标后端和模型类型。问题现象常见原因解决思路导出时报torch._dynamo相关错误PyTorch 与 ExecuTorch 版本不匹配切换到官方文档要求的版本组合再试加载.pte时报 operator not supported模型包含 runtime 不支持的算子或自定义算子查看日志定位算子替换等价结构或注册自定义 kernel端上与 PC 导出结果不一致量化误差、后端算子实现差异先跑 fp32 CPU 对比再排查量化后差异模型文件太大无法打包权重未量化、tokenizer 等文件重复放入 assets使用 int8/int4 量化检查 assets 目录重复文件推理延迟过高未开启并行、后端选择错误、模型输入太长基准测试 CPU/NPU 后端限制最大 token 长度工具调用频繁失败结构化输出不稳定、模型生成 JSON 被截断在 Agent 循环里增加重试与 fallback 工具App 闪退但没有明显 Java 异常native 层没有释放模型或输入输出内存管理错误检查 JNI 层日志确认释放逻辑与线程安全模型加载正常但输出乱码tokenizer 词表不匹配比对导出侧与部署侧 tokenizer 文件版本这里最容易被忽略的是“输出乱码”。很多开发者在 PC 上用项目自带的 tokenizer 测试一切正常但打包到 Android 时只拷贝了模型文件忘记拷贝词表最终模型输出的 token id 被错误解释成乱码。遇到这类问题按从上到下的顺序检查先确认 tokenizer 与模型匹配再确认输入文本被正确编码最后检查解码逻辑。8. 最佳实践与工程建议做端侧 Agentic AI 时开发者容易把注意力全部放到模型的“聪明程度”而忽略了工程可维护性。实际上生产环境更看重的是稳定、可控、可观测。下面几条建议来自大量端侧部署项目的共同经验你在实践中可以直接套用。第一Agent 循环必须有最大轮数限制和超时机制。模型在端侧运行虽然比网络请求快但同样有卡死风险。如果 Agent 连续执行了 5 步仍未完成任务代码要主动终止并提示用户。超时时间建议做成配置项必要时按设备性能自动调整。第二工具注册表要和模型输出协议保持同一份代码。你可以用 JSON Schema 描述工具参数让代码在调用工具前自动做校验。不要把工具名直接拼接进系统命令避免 Agent 决策结果被注入式利用。例如如果某个工具接收路径参数必须严格校验路径是否在应用沙箱目录内不能信任模型端到端生成的任何文件名。第三日志与追踪是端侧 Agent 的生命线。你需要记录模型输入、输出、工具调用结果、耗时、峰值内存并且能按会话 ID 聚合。为了防止隐私泄露日志中不要记录完整的用户输入可以只记录脱敏后的摘要。线上排查 Agent 问题时如果缺少这些日志几乎无法定位是模型选错工具还是工具执行模块出现异常。第四发布前一定要做设备矩阵测试。不同厂商的 NPU 驱动、内存大小、SoC 调度策略差异很大。ExecuTorch 在 A 手机上运行良好不代表在 B 手机上也能达到相同延迟。建议在 CI 中接入真机性能测试把“模型加载耗时、单次推理耗时、首 token 延迟、峰值内存、崩溃率”五项指标作为发布门禁。第五模型小版本更新时不要只替换.pte要有一套独立的模型评估集。你可以提前准备 100 条与 Agent 相关的用户请求每次更新模型后离线跑一遍工具调用命中率和参数解析准确率。端侧模型迭代必须比云端模型更谨慎因为一旦新模型在部分设备上表现退化用户很难像卸载云端应用一样快速回滚。9. 总结与后续学习路线回到我们开头提出的问题端侧 Agentic AI 能否做到既快又能真正处理任务从 ExecuTorch 的模型导出、量化、运行时集成到 Muse Glimmer 这类轻量模型的 Agent 闭环答案已经比较明确可以在设备端实现一个延迟可接受、隐私边界清晰、工具调用可控的 Agent 子系统。ExecuTorch 负责解决“模型怎么高效跑起来”Agent 调度代码负责解决“模型决策怎么变成真实动作”两者缺一不可。如果你是初学者建议先不要追求完整的大模型端侧迁移。可以先按本文提供的最小示例把一个普通 PyTorch 小模型导出成.pte在 Python 环境里跑通一遍推理再试着把这个模型接到简单的工具调用循环上。当你理解了.pte文件、to_edge 和运行时加载这三件事后再开始挑战 Android 或 iOS 集成会顺手很多。如果你想深入下一步可以重点学习三个方向一是 ExecuTorch 的量化工具与后端抽象了解不同算子在不同硬件上的执行差异二是 Agent 模型的提示词设计与结构化输出训练让模型从模型层面就减少 JSON 解析失败的风险三是端侧模型与云端服务的混合调度真正实现“隐私敏感的本地处理、知识密集的云端处理”。端侧 Agentic AI 不是要替代云端大模型而是在大模型落地的最后一段路上把用户最关心的延迟和隐私留给设备本身。建议你现在就打开 ExecuTorch 官方仓库跑一次官方 demo然后再回来调整本文的示例代码。只要模型能够导出成.pte剩下的端侧运行和 Agent 循环本质上都是工程问题完全可以通过调试和迭代解决。希望这篇文章能成为你快速入门的起点。如果发现 ExecuTorch 版本更新导致 API 变化欢迎在评论区补充说明大家一起维护一份最新可用的端侧 Agent 部署清单。
