端侧 LLM 部署这事如果说上一篇文章讨论的是 Agent 的架构和意图那今天要聊的就是这个脑子到底怎么落到一块板子上、一台手机上、一个摄像头后面。做端侧 Agent 的人应该都有同感云端大模型接口封装得再好真到产品化阶段延迟、隐私、流量成本、甚至断网场景每一项都在逼你把模型往设备端推。而端侧 LLM 部署恰恰是这条路上最硬的那块骨头——它不是在服务器上装个模型跑个测试而是要在算力、内存、功耗三重约束下让模型稳定、持续、可靠地提供服务。这篇文章我准备把从模型选型、框架选择、量化到实际对接 Agent 的完整链路讲透适合两类人看一类是正在做端侧 Agent 产品、需要把 LLM 真正部署到设备上的开发者另一类是刚接触大模型部署、想了解端侧和云端到底差在哪的后端工程师。文章里没有那种下一步、再下一步的空洞教程全是我实际踩过坑之后的复盘和可以直接抄作业的方案。1. 端侧部署先想清楚模型、硬件与场景三方匹配很多人在端侧部署上翻车不是因为技术不够而是第一步就没想明白。拿到一个 7B 模型就往设备上塞结果推理速度慢到没法用或者内存直接爆掉然后开始怀疑自己代码写得有问题。实际上问题往往出在需求和硬件根本没有对齐。1.1 端侧 Agent 对 LLM 的真实诉求端侧 Agent 跟普通的端侧 AI 应用不一样它对 LLM 有一组独特的需求我列一下我在产品里实际感受到的低延迟Agent 要跟用户交互用户说一句话Agent 得在可感知的范围内给出响应。云端 300ms 的 API 延迟可以接受但端侧如果跑到 5 秒以上用户会直接认为设备卡了。具体指标要看场景语音交互的 Agent 要求更高文本类的 Agent 相对宽裕一些。流式输出Agent 的思考过程如果能让用户看到体验会好很多。端侧模型因为速度本身不快如果还要等整段输出完再说交互会非常难受所以流式几乎是必需能力。可控性端侧 Agent 往往要执行操作比如控制设备、读取传感器、调用工具所以模型得能按结构化格式输出也就是要有基本的功能调用能力。长会话保持Agent 和用户的对话通常不是一问一答就结束而是要持续几轮、几十轮。这意味着上下文窗口不能太小同时 KV Cache 的开销必须要有预期。有朋友会问那到底多大模型才够用这个问题没有标准答案但我可以给你一个可参照的结论做简单工具调用和意图识别1B~3B 的量化模型就能跑做通用对话和复杂任务规划7B~8B 是体验底线14B 以上在高端手机上勉强能跑在嵌入式设备上基本不现实。这个判断不是我拍脑袋而是经过多个平台实测之后的经验。1.2 主流端侧硬件的算力边界当前端侧推理的主力平台我分成三档来说手机 SoC 阵营高通骁龙 8 系列、联发科天玑 9000 系列、苹果 A 系列和 M 系列这几类都有独立的 NPU 或加强的 GPU内存普遍 8GB~16GB理论算力跨度从 20 TOPS 到 60 TOPS 以上。这类平台适合跑到 7B 量级的量化模型苹果 M 系列甚至可以跑 14B 甚至更大。嵌入式 AI 板卡阵营典型代表是瑞芯微 RK35888 TOPS NPU、Jetson Orin 系列最高 275 TOPS、树莓派加 AI 加速模块等。这些平台内存小但胜在功耗可控、接口丰富适合做固定位置的 Agent 设备比如桌面助手、机器人的大脑。其中 Jetson Orin 因为显存可以和内存统一寻址跑 7B 模型做 Agent 是目前嵌入式里最舒服的方案。RK3588 的 NPU 对 LLM 支持的算子还有一些限制我后面会专门讲。MCU 或者低功耗 SoC 阵营能跑 0.5B~1B 的模型就已经是极限适合做唤醒词、简单意图识别这类轻 Agent。这类平台跑不了通用对话别硬上。这里有个核心认知要建立端侧部署不是选最强的而是选瓶颈最小的。算力再强内存不够一样白搭内存够大算力不够推理慢到怀疑人生。所以要三方匹配模型大小、硬件算力、场景需求缺一个环节不对整个产品都立不住。1.3 模型选型从 0.5B 到 14B 的分级思路模型选型我建议按任务复杂度 × 设备等级来分不要一味看参数数量。下面是我实际使用过的几个模型和它们在端侧的表现整理成一个表格供参考模型参数量推荐设备实际效果我踩过的坑Qwen2.5-0.5B / 1.5B0.5B~1.5BMCU、低端手机意图识别勉强通用对话不顶用对话稍微拐个弯就答非所问Qwen2.5-3B / Phi-3-mini3B~3.8BRK3588、中端手机简单 Agent 工具调用勉强可用上下文一长就失忆需要做压缩Qwen2.5-7B / Llama-3-8B7B~8B骁龙 8 Gen 2、Jetson Orin、Apple Silicon通用 Agent 的入门线Function Calling 可用内存占用大KV Cache 要精打细算Qwen2.5-14B14BApple Silicon、大内存旗舰体验接近云端小模型功耗发热明显长时间运行会降频我做 Agent 项目时最低敢用的线是 3B但如果是用户直接对话的产品我建议至少 7B 量化。有人说 3B 够用那是任务太简单Agent 一旦涉及多步推理、记忆、工具调用小模型立刻露馅这不是调 prompt 能解决的是模型本身的容量天花板。2. 部署框架选型llama.cpp、MLC-LLM、Ollama 到底怎么选很多人以为端侧部署就是下载一个 Ollama跑一条命令实际上工程化落地时你要考虑的东西比这多得多。Ollama 只是最上层的一个封装它底层用的还是 llama.cpp 这类推理引擎而不同推理引擎在端侧的表现差异巨大。2.1 三大主流框架的能力边界对比llama.cpp目前端侧部署事实上的标准。纯 C/C 实现依赖少对 CPU 的优化做到了极致支持 AVX/NEON 等指令集加速量化方案 GGUF 格式的生态非常成熟。它的核心优势是在哪儿都能跑树莓派能跑、x86 边缘网关能跑、安卓手机配合 Termux 也能跑。劣势是 GPU/NPU 加速需要自己折腾默认主要走 CPU。MLC-LLM基于 TVM 编译器生态主打一次编写、多端部署对手机 GPUOpenCL/Metal和部分 NPU 做了统一抽象。我在骁龙平台上测试过GPU 加速效果比 llama.cpp 纯 CPU 快不少但环境配置复杂遇到算子不兼容时报错会非常抽象。Ollama严格说它不是一个推理引擎而是一个模型服务 管理工具。它是把 llama.cpp 包了一层提供 HTTP API、模型管理、多模型并发等能力特别适合快速验证想法。但端侧产品化时我一般不直接用 Ollama因为它的进程管理和资源占用控制不够细定制空间小。不过 Ollama 在 x86 小主机和开发板上的部署速度确实快做原型很香。如果你有印象的话AMD 的 ROCm 生态也有自己的推理路径NVIDIA 的 Jetson 平台则是以 TensorRT-LLM 和 PyTorch/ExecuTorch 为主。所以框架选型本质上是在生态成熟度加速性能定制灵活性三个维度上权衡。我的建议是快速验证、原型演示直接上 Ollama别犹豫。产品化落地、CPU 推理为主llama.cpp自己编译控制一切。手机 GPU 加速、追求极致性能MLC-LLM 或 ExecuTorch但要接受折腾。Jetson 平台TensorRT-LLM 优先配合 PyTorch 生态做 Agent 编排。2.2 移动端与嵌入式平台的差异化选型手机和平板这类移动端跟 RK3588 这类嵌入式板卡在框架选择上差异非常大。手机端不要直接上 Ollama因为它主要面向桌面和服务器环境安卓上要跑也是通过 Termux 套一层性能和稳定性都不理想。正确做法是在安卓端用 ExecuTorch 或 MLC-LLM 的 Android SDK通过 JNI 层把推理引擎嵌入到 App 进程里模型文件放在 assets 或下载目录走 app 的生命周期管理。嵌入式板卡反而是 Ollama 的舒适区。RK3588 和 Jetson 系列跑的都是 Linux 系统Ollama 可以直接 systemd 管理GPU 或 NPU 驱动装好之后模型加载和服务化一条龙。尤其是 Jetson Orin 上Ollama 配合 CUDA 后端跑 Qwen2.5-7B Q4 量化能到每秒 15~30 个 token 的生成速度这对一个端侧 Agent 的大脑来说已经够用了。RK3588 的 NPU 就得另说它的 RKNN 工具链对 LLM 支持度还在完善很多情况下反而不如直接用 CPU 跑 llama.cppNPU 的算子转换时间可能比 CPU 推理时间还长。2.3 框架之外还要解决的运行时问题说实话框架只是端侧部署的第一步。实际产品上线前这些问题你都得自己处理模型热加载与卸载端侧内存宝贵你不能让一个 7B 模型常驻内存占掉 6GB否则其他进程没法活。需要做模型按需加载、空闲自动卸载的机制。接口统一Agent 框架调用的是 OpenAI 风格的/chat/completions接口但 llama.cpp 和 MLC-LLM 原生接口都不完全兼容 OpenAI 格式中间要加一层适配服务。模型文件管理GGUF 文件动辄几个 GB升级、回滚、完整性校验都要有方案。并发控制端侧设备通常一次只能跑一路推理多用户接入时要排队这个后面专门讲。这些都不是框架帮你解决的得自己在工程层做设计。3. 量化与内存把模型塞进有限显存的关键一仗端侧部署的物理瓶颈基本就是内存和算力而内存问题是数学上可以预判的。我见过太多人一上来就下原版 FP16 模型然后内存爆了才开始研究量化。早知道这些公式根本不用走弯路。3.1 内存需求的估算方法一个模型的内存占用主要由三块构成模型权重、KV Cache、运行时开销。模型权重的计算公式很简单参数量 × 每个参数的字节数。以 7B 模型为例FP16每参数 2 字节7B × 2 ≈ 14GBINT8每参数 1 字节7B × 1 ≈ 7GBINT4每参数 0.5 字节7B × 0.5 ≈ 3.5GBKV Cache 的估算稍微复杂一点2K 和 V × 层数 × 隐藏维度 × 上下文长度 × 字节数。不同模型的隐藏维度差异很大Qwen2.5-7B 是 3584Llama-3-8B 是 4096。以 Qwen2.5-7B 为例上下文 8192、FP16 时KV Cache 大约 2 × 28 × 3584 × 8192 × 2 ≈ 3.2GB。如果你开 32K 上下文这块直接翻四倍。这就是为什么长上下文在端侧那么奢侈。运行时开销包括激活值、临时缓冲区、推理中间结果等一般额外预留 20%~30%。所以一个实际的生产经验是7B 模型 Q4 量化想要 8K 上下文稳定运行设备可用内存最好在 6GB~8GB 以上。14B 模型 Q4 量化需要 12GB 以上可用内存。低于这个数不是不能跑而是会频繁触发内存回收或直接被杀进程。3.2 常见量化方案及精度影响量化方案几大主流选择各有各的应用场景量化格式精度模型体积7B推荐场景风险点Q8_0接近无损约 7GB对精度敏感、内存充裕体积大端侧不常用Q6_K高精度约 5.5GB通用端侧、效果优先内存压力中等Q5_K_M较高精度约 5GB平衡之选无明显短板Q4_K_M可接受精度约 4.4GB端侧主力方案复杂推理偶尔输出颠三倒四Q3_K_M精度明显下降约 3.7GB内存受限时的妥协逻辑推理能力显著变弱IQ2_XXS极限压缩约 2.5GB演示、极端内存受限基本不能用于 Agent这里我想多说一句很多论文宣称 INT4 量化精度损失可以忽略那是拿评测集测出来的均值结论实际做 Agent 时你会遇到评测集测不出来的问题——模型生成 JSON 时偶尔多一个字段、工具调用参数偶尔串位、长上下文的注意力偶尔崩掉。这些在平均指标上看不出来但对产品体验是致命的。所以我的建议是Agent 场景至少用 Q5_K_M 起步Q4_K_M 是底线不要因为省几十 MB 内存去用 Q3 以下。3.3 实测数据不同精度下的内存与速度对照我在 Jetson Orin Nano 8GB 上做过一组实测模型是 Qwen2.5-7B-Instruct数据如下量化等级模型加载内存速度token/s首 token 延迟Q8_0约 7.5GB6~82.5sQ6_K约 6GB8~101.8sQ5_K_M约 5.2GB9~121.5sQ4_K_M约 4.6GB11~151.2s需要说明的是Orin Nano 的 GPU 是 Ampere 架构llama.cpp 的 CUDA 后端能比较好的发挥。如果是纯 CPU 跑7B Q4 的速度可能只有每秒 2~4 个 token体验会大打折扣。所以在嵌入式平台上能不能用上 GPU 加速往往比选什么量化格式更影响体验。另一个容易被忽略的点是不同的 GGUF 量化版本之间也存在差异。比如 Q4_K_M 比 Q4_0 更精细同体积下质量更好K-quants 方案专门优化了重要张量的精度分配所以在模型文件大小差不多的情况下优先选带 K 的版本。4. 实操实录Ollama llama.cpp 部署一个端侧 Agent 底座前面理论讲了不少这部分我给一份可以直接落地的实操方案。我用的是组合拳Jetson Orin Ollama 一个轻量适配层对接 Agent 框架。4.1 环境准备与启动模型首先安装 Ollama。在 Jetson 系列上Ollama 官方安装脚本会尝试探测 CUDA你只要保证 JetPack 系统里已经装好了 NVIDIA 驱动和 CUDA 运行时就行。# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 启动服务 systemctl start ollama systemctl status ollama然后拉取量化后的模型。以 Qwen2.5-7B-Instruct 为例Ollama 默认会拉取 Q4_K_M 版本也可以显式指定ollama pull qwen2.5:7b-instruct-q5_K_M ollama run qwen2.5:7b-instruct-q5_K_M这里的坑在于默认拉取的模型版本可能不是你想要的那个。Ollama 有两个 tag 体系一个是官方默认的比如qwen2.5:7b另一个是社区上传的带完整量化标识的版本。我的经验是生产环境要用带.gguf标识的球队格式或者直接从 Hugging Face 下载 GGUF 文件然后创建自定义 Modelfile。这样可以完全锁定文件版本和量化参数不会因为上游更新导致行为漂移。如果你用的是 llama.cpp 而不是 Ollama那编译和启动方式是这样的git clone https://github.com/ggml-org/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_CUDAON make -j$(nproc) # 启动 server 模式 ./bin/llama-server -m /path/to/qwen2.5-7b-instruct-q5_K_M.gguf \ --host 0.0.0.0 --port 8080 \ -ngl 99 \ -c 8192 \ --jinja-ngl 99是让模型尽可能多地放 GPU--jinja是启用模型的模板语法。这个参数对工具调用能否正确生效非常关键。4.2 OpenAI 兼容接口与 Agent 框架对接不管用 Ollama 还是 llama.cpp server最终都要让 Agent 框架以 OpenAI SDK 的方式访问模型。Ollama 的接口不完全是 OpenAI 风格需要设置环境变量让它启用兼容模式export OLLAMA_HOST0.0.0.0:11434 # 新版 Ollama 直接支持 /v1/chat/completions curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct-q5_K_M, messages: [{role: user, content: 你好}] }Agent 框架对接时只需要把 base_url 指向 Ollama 或 llama.cpp server 即可from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8080/v1, # llama.cpp 或 Ollama api_keynone ) response client.chat.completions.create( modelqwen2.5:7b-instruct-q5_K_M, messages[{role: user, content: 帮我查一下今天的天气并设置提醒}], tools[{ type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string} }, required: [city] } } }], streamTrue )这里要注意llama.cpp 的 server 需要开启--jinja并且模型本身支持 chat template 才会正确处理 tools 字段。如果模型没有正确的 tool-use prompt 模板tools 会被忽略模型还是会按照普通对话的方式回复。实测中Qwen2.5 系列对 tools 的支持是开箱即用的Llama-3 需要确认模板版本老版本模型往往不支持。4.3 流式输出与并发控制的细节流式输出对端侧 Agent 不是锦上添花而是必不可少。因为端侧 LLM 推理速度本来就慢如果用户要等 5 秒才看到第一个文字基本等于不可用。流式输出能把首 token 的时间压缩到 1~2 秒内用户心理感受完全不同。实现流式输出时OpenAI SDK 直接传streamTrue即可但真正做产品时有两个细节第一个细节是 SSE 与端侧设备的网络栈兼容性。很多嵌入式设备的 HTTP 客户端对 SSE 支持不完善连接容易被网关断开需要设置合理的 keep-alive 参数或者自己解析 chunk 而不是依赖封装的 SDK。第二个细节是取消生成的机制。用户可能在 Agent 生成到一半时打断比如说别说了直接执行如果你的端侧推理服务不支持立即停止生成模型还会继续算好几百个 token既浪费算力又导致后续指令延迟。Ollama 的 API 支持中断llama.cpp 需要自己实现 slot 的释放逻辑。我在做产品时专门加了一个打断控制器一旦检测到用户新意图立即释放推理槽位。并发方面端侧设备和服务器不一样不要指望多路并发。7B Q5 模型在 Jetson Orin 上占掉大半内存后多路推理会导致每路都变慢总吞吐反而下降。我的处理方式是单路推理 请求排队。实际用消息队列把请求串行化一次只处理一个会话其他请求排队等待。这个方案在大多数端侧 Agent 场景下已经够用——毕竟端侧服务的就是一两个用户不像云端要扛几千路并发。4.4 Function Calling 在端侧模型上的现实表现做 Agent 的人绕不开 Function Calling。端侧模型的工具调用能力确实比云端小模型弱但量化后还能不能保住这个能力取决于两个因素一是模型的原始能力二是量化的精度等级。实测下来Qwen2.5-7B 在 Q5_K_M 量化下工具调用的格式正确率还能维持在 90% 以上降到 Q4_K_M 时格式正确率会掉到 80%~85%降到 Q3 以下直接不建议做工具调用因为经常会输出半截 JSON 或者漏掉参数。Llama-3-8B 的情况类似但它的 JSON 风格输出整体比 Qwen 要弱一些做工具调用时需要更强的提示词约束。还有个实际经验是端侧模型做 Function Calling最好把工具的数量控制在 5 个以内每个工具的 description 写清楚但不要啰嗦。工具太多会让小模型的注意力涣散选择工具时出错率显著上升。我在项目里试过给模型塞 10 个工具结果它经常选错工具或者把参数填错位置。把工具精简到 4 个之后准确率回到可接受水平。另外提一嘴llm 的知识库检索问题。热词里提到的 RAG 和 GraphRAG 也是端侧 Agent 常见配套。端侧做 RAG 不能原样搬云端方案因为 embedding 模型也要在端侧跑向量库也不能太重。推荐用embedding小模型0.5B 级别加 SQLite-Vec 这类轻量方案把文本向量化后存在本地满足检索需求即可。不要为了追求效果好就上重型向量数据库端侧吃不动。5. 端侧部署的常见问题与排查记录这部分我尽量把平时最容易踩的坑整理出来每条都是真实项目中遇到过的不是编出来的。5.1 启动失败与依赖缺失典型症状llama-server启动后提示 CUDA 相关错误或者 Ollama 显示 GPU 不可用。排查思路先确认驱动和 CUDA 版本再确认 llama.cpp 编译时是否真的启用了 CUDA。nvidia-smi # 检查驱动和 GPU 是否可见 ollama ps # 查看模型实际运行在 CPU 还是 GPU有一个很隐蔽的坑Jetson 的 JetPack 版本和 CUDA 版本是绑定的如果你从官网下载的 llama.cpp 预编译包带着桌面版 CUDA 依赖在 Jetson 上会直接起不来。解决办法是必须用 JetPack 自带的 CUDA 工具链自己编译别偷懒用预编译包。另外在 RK3588 上经常遇到的问题是NPU 驱动没装好但 CPU 推理正常你以为是 NPU 在跑实际上一直是 CPU 在干活。用top看 CPU 占用率如果接近 100%基本可以断定 NPU 没有参与计算。5.2 推理速度异常的排查思路速度慢的排查优先级我建议这样排先看模型是否真用上了 GPUollama ps或者 llama.cpp 的启动日志里是否有 CUDA offload 到 GPU 的打印。如果 GPU 显存不够部分层跑在 CPU速度会断崖式下降。看内存是否触发了 swap嵌入式设备经常启用 swap但 swap 上跑 LLM 推理速度会慢 10 倍以上。要观察free -h和swapon的输出如果 swap 使用率一直在涨说明物理内存不足需要降量化等级或减小上下文长度。看是否被降频Jetson 的 GPU 有功率墙长时间满负荷跑会触发降频。用tegrastats查看如果 GPU 频率掉到一半以下说明散热或供电出了问题。看数据和代码优化选项llama.cpp 编译时是否加了-O3、-marchnative是否开了GGML_CUDA这些对性能影响很大。默认没编译优化的 llama.cpp 跑起来速度差 20% 起步。5.3 输出质量崩坏的量化背锅现场有段时间我们的 Agent 总是突然答非所问排查了提示词模板、对话历史、上下文截断逻辑最后发现是模型加载的量化版本变了——之前一直用的 Q5_K_M某次自动更新之后变成 Q3_K_M参数文件大小一下子小了几百 MB但界面上没有明显提示所以一直没发现。这件事给我提了个醒端侧模型的版本管理必须严格模型的加载路径和量化标识要打进日志里每次启动都打印一行方便日后排查。另外模型文件的哈希值要校验下载中断导致文件损坏时加载过程可能不报错但推理结果会胡言乱语。GGUF 文件如果没有正确下载完整llama.cpp 启动时可能只报一个警告后面输出全是乱的。另一个常见问题是上下文对话轮次过多时Agent 开始丢失指令。这通常是 KV Cache 溢出后的静默截断导致的。我建议在应用层主动做对话历史裁剪把超过 N 轮的早期对话压缩成摘要而不是任由模型填充 KV Cache 后被截断。这和云端上的上下文管理类似但端侧因为缓存更小更依赖上层的主动管理。5.4 热管理、省电与长时间运行稳定性端侧设备不是数据中心服务器散热和功耗是实打实的问题。Jetson Orin Nano 满负荷跑 7B 模型功耗能到 15W~20W如果设备是在一个密闭外壳里半小时后就会触发降频。实测一个案例刚开始跑 Agent 时首 token 延迟 1.2 秒运行 20 分钟后变成 2.8 秒这就是降频导致的散热片一加回去马上恢复。省电策略上我的做法是把推理服务拆成热态和冷态。热态是模型常驻内存、等待请求适合交互频次高的场景冷态是模型空闲超时自动卸载需要时重新加载适合交互频次低的场景。模型重新加载虽然要花几秒但平均功耗能降一半以上。还有一个很容易忽略的问题长时间运行的日志膨胀。llama.cpp 的日志如果开了 debug 级别几天下来能吃掉几百 MB 存储这对嵌入式设备是致命的。生产环境务必把日志级别调到 warn 以上并配置日志轮转。6. 浅谈端侧 Agent 的未来模型占用与云端协同端侧 LLM 部署并不是孤立的它最终要为 Agent 服务的完整链路提供支撑。有一个观点我想分享一下端侧 Agent 的产品形态大概率不是一切都跑在端上而是端侧为主、云端为辅的混合架构。6.1 三层模型的端云协同结构根据我的实践端侧 Agent 至少有三种任务粒度需要不同规模的模型处理端侧常驻小模型0.5B~1.5B负责意图粗分类、语音唤醒、敏感信息过滤、简单指令执行。这个模型始终在内存里毫秒级响应。端侧按需中模型3B~7B负责通用对话、Agent 规划、工具调用。有任务时加载空闲时卸载。云端大模型量级更大负责复杂推理、长文档处理、跨设备协同等端侧搞不定的任务仅在端侧模型判定自己能力不足时才调用或主动选择。这套结构的好处是可以做到绝大多数请求在端侧闭环隐私数据不出设备无网环境也能提供服务。成本上也非常划算一个 7B 模型的端侧推理相比按 token 计费的云 API长期跑下来省钱得多而且一旦模型在本地响应速度快一个量级。6.2 端侧 Agent 的记忆与状态管理回到热词里的那张图——LLM 的 token 三个点key 我是谁、query 我在找什么、value 我能提供什么。这个概念在端侧 Agent 里同样适用端侧模型本身没有持续记忆Agent 的记忆要靠外部状态管理来做。我的做法是维护一个本地记忆库按三类组织key自述信息记录设备 ID、用户偏好、环境配置query意图查询记录当前任务的上下文、目标value执行结果记录工具调用的返回值、对话摘要。每次 Agent 会话开始时从记忆中构建 system prompt 的身份块让模型知道我是谁会话中把 query 转化成工具调用的参数语义会话结束后把结果写回 value。这套机制让 3B 的小模型也能表现出我记得你的效果实际上模型本身没有任何记忆能力是外层状态管理补上的。6.3 关于 Agent 开发的几点建议热词里有吴恩达 Agent 教程也有Agent 框架与编排说明大家都在往这个方向探索但端侧 Agent 的开发和云端 Agent 开发很不一样这里给几条建议第一端侧 Agent 的功能范围要做减法人。设备端的 Agent 不需要什么都会只要把几个核心场景做到极致体验就好。贪多嚼不烂端侧尤其如此。第二要让 Agent 的能力边界变得可见。如果用户的请求超出了端侧模型的能力范围要明确告诉用户这个操作需要联网才能完成或者这个功能当前设备不支持而不是让模型硬答。硬答的结果一定是我前面提到的一本正经胡说八道这在 Agent 场景下比在对话场景下危害大得多——它会直接驱动设备执行错误动作。第三端侧 Agent 必须留好人工兜底通道。任何自动化 Agent最终必须有用户可以一键手动接管或取消操作的路径。这在功能安全上不是可选项而是必须项。我在做设备控制类 Agent 时所有危险操作都会二次确认在 model 层做不了就在应用层做。写在最后按惯例不写总结了分享两个我最近在实际操作中的感受。第一个是做端侧 LLM 部署别神话量化、也别小看量化的影响。它确实是端侧落地的唯一解但唯一解不等于免费午餐。每一步精度的下降最后都会以你看不到的方式反映在 Agent 的行为上。如果你负责的产品稳定性要求很高那么量化上线前做一轮专门的工具调用压力测试非常值得成本不高收益很大。第二个是端侧 LLM 部署的调试最大的敌人是环境不透明。同样的模型文件在 A 设备上跑得好好的到 B 设备上就疯狂输出乱码查来查去发现是 B 设备的非统一内存架构 低配 GPU 导致部分层没有 offload。所以在每一台设备上第一步永远是打印模型跑在哪、内存用了多少、量化是什么版本这三条信息比什么优化技巧都重要。这套流程走完端侧 Agent 的底座基本上就稳了。剩下的事情——Agent 的规划、记忆、工具链编排——都是在这个底座之上的锦上添花。底座不稳上面再漂亮也白搭。