1. 端侧 Agent 工程化先想清楚边界再谈落地做端侧 Agent 有一个很容易踩的坑一上来就奔着智能去把大模型塞进设备里然后就开始堆功能。结果跑起来之后发现模型在云端表现不错到了端上各种抽风——响应慢、内存爆、上下文乱、工具调用不稳定。然后就开始怀疑是模型的问题其实大概率不是模型的问题是工程化没做到位。我接触端侧 Agent 有三四年的时间了从最早的实验性项目到后来在真实产品里落地最大的感受是端侧 Agent 和云端 Agent 的工程化难度不在一个量级。云端你有一整个机房的资源可以调度端侧只有一块小小的芯片、有限的内存、不可控的网络环境还有用户随时可能锁屏、切后台、杀进程。这一个端字把很多在云端稀松平常的事情变成了挑战。这篇文章是深入理解端侧 Agent系列的一部分主要讲工程化的前半程从整体设计思路、核心模块拆解到实际编码过程中会遇到的问题和解决方案。适合两类人看一类是把 Agent 放到真实设备上、正被性能或稳定性问题折磨的开发者另一类是准备做端侧 Agent 但还没想清楚架构、希望少走弯路的同学。先说结论端侧 Agent 工程化本质上不是把模型跑起来的问题而是把智能体系统在资源受限环境下稳定运行的问题。模型推理只是其中一环更麻烦的是整个系统的编排、上下文管理、工具调用、并发控制和错误恢复。2. 端侧 Agent 的系统架构harness 与 agent 的边界划分2.1 从模型封装到智能体系统的转变很多初学者对 Agent 的理解还停留在调用模型 API的阶段。但真正的 Agent 是一个系统它需要感知环境、做出决策、调用工具、观察结果、迭代执行。这里面每一个环节都需要工程化的支撑。我早期做过一个失败的项目当时把 Agent 简单封装成了模型调用 工具函数的集合看起来架构很清晰模型决定调用哪个工具工具返回结果模型再继续推理。但实际跑起来问题层出不穷。最典型的一个场景用户说了一句带有歧义的话模型需要澄清但我们的架构里没有设计询问用户这个能力于是模型就在那里自说自话最后给出一个完全错误的结果。后来我意识到Agent 不是一个函数它是一个循环。这个循环里有几个关键步骤理解输入、规划行动、调用工具、观察结果、修正计划。这个循环的每一环都有大量的边缘情况需要处理而工程化的核心就是把边缘情况变成确定性逻辑。2.2 harness 与 agent 的核心职责划分关于 harness 和 agent 的区别我见过很多不同的理解。有人觉得 harness 就是工具调用的封装层有人觉得 harness 是 Agent 运行时的代名词。根据我的实践经验比较清晰的定义是Agent是智能决策中枢负责理解任务、拆解步骤、选择策略。它本质上是一个基于大模型的推理循环核心能力是思考。Harness是承载 Agent 运行的环境和框架负责管理上下文窗口、调度工具执行、控制循环迭代、处理错误和中断。它解决的是让 Agent 能稳定跑起来的问题。做一个类比可能更容易理解Agent 像是司机harness 是汽车。司机负责判断路线、决定怎么开汽车负责提供动力、转向、刹车以及保证行驶安全。司机再厉害汽车本身如果刹车不灵、方向盘有虚位也会出事。在实际工程中harness 和 agent 的边界经常被模糊。比如有些框架把上下文管理放进了 agent 里让 agent 自己决定保留哪些历史消息。这在简单场景下没问题但一旦上下文超过模型窗口agent 的决策能力会明显下降因为它自己也不知道该丢哪些信息。正确的做法是把上下文管理从 agent 中剥离出来交给 harness 处理用确定性的策略来管理而不是让模型来做这个决定。2.3 端侧环境对架构的特殊约束端侧和云端最大的区别是资源边界非常硬。云端 CPU 不够可以扩容内存不够可以加节点端侧做不到。所以端侧 Agent 的架构设计从一开始就要考虑资源预算而不是事后优化。我整理过一份端侧 Agent 的资源分配清单大体是这样资源项云端 Agent端侧 Agent端侧约束内存占用可以按需扩展通常控制在几百 MB 内设备其他应用共存需要模型推理可以调用超大模型通常使用 1B-7B 参数模型算力、功耗、发热限制上下文长度128K-200K 无压力需要控制在 4K-8K内存和推理延迟双限制工具调用延迟网络调用可接受本地调用需毫秒级用户体验感知明显并发请求可以横向扩容只能靠编排优化算力有限无法并行这套约束下来端侧 Agent 的架构风格会和云端明显不同。云端 Agent 喜欢有多少工具就用多少工具有多少上下文就装多少上下文端侧 Agent 必须做减法少即是多。我在设计端侧 Agent 架构时会遵循三个核心原则确定性优先于智能性本地优先于网络缓存优先于计算。不确定的逻辑交给模型确定的逻辑交给代码能本地处理的绝不上云能预计算缓存结果的绝不重复推理。3. 核心模块拆解编排、记忆、工具调用三件套3.1 编排引擎Agent 循环的控制中枢编排引擎是整个 Agent 系统的心脏。它负责维护 Agent 的运行循环决定下一步该做什么。一个完整的 Agent 循环包括接收用户输入追加到上下文调用模型进行推理得到响应解析响应判断是最终答案还是工具调用请求如果是工具调用执行工具将结果追加到上下文回到第 2 步继续推理直到得到最终答案或达到最大迭代次数看起来简单实际落地时每个环节都有坑。最大的坑在步骤 3模型返回的工具调用请求是 JSON 格式但这个 JSON 有时候会不合法。模型在生成长文本时偶尔会在 JSON 里加一些额外的逗号、缺一个引号、或者干脆截断了。云端 Agent 遇到这种情况可以直接让模型重新生成端侧 Agent 不行因为重新推理的成本太高了。我在编排引擎里加了一个轻量的 JSON 修复层专门处理模型输出的 JSON 格式问题。比如补全缺失的引号、删除多余逗号、截断补齐等。这些听起来像是不起眼的小功能但实际效果非常明显能把工具调用的成功率从 80% 提升到 95% 以上。另一个关键设计是循环控制的退出条件。云端 Agent 可以把最大迭代次数设置到 20 次甚至更多端侧不行。每次迭代都是时间和电量的消耗用户不会等你的 Agent 思考 20 轮。我通常会把最大迭代次数控制在 5-8 次以内超过次数直接返回当前已获得的最佳结果同时用文本告诉用户由于复杂度限制当前回答可能不是最完整的请尝试更具体的描述。3.2 上下文管理在有限窗口里做出最优取舍上下文管理是端侧 Agent 工程化里最容易被低估的模块。很多人以为上下文管理就是把历史消息拼起来发给模型但实际情况要复杂得多。先说窗口的问题。端侧模型通常只有 4K-8K 的上下文窗口这意味着在单轮对话中你能提供给模型的信息非常有限。一个典型的工具调用过程工具返回的结果可能要几百到上千 token几轮工具调用下来上下文就满了。解决思路是分层的核心指令永远保留历史对话可以压缩工具结果只保留关键部分。我会把上下文分成三层来管理第一层是系统提示词和核心指令这部分是不可压缩的直接固定在上下文的最前面。第二层是最近几轮对话保留完整信息因为这通常是当前任务的焦点。第三层是更早的历史对话和工具调用记录这类信息可以用摘要的方式压缩后保留。摘要压缩是我踩过很多坑之后才做对的事情。早期我用模型来压缩对话用一个小模型对历史信息做总结效果好但消耗大。后来改成了规则 抽取的方式保留用户消息中的关键词和关键实体保留工具调用的参数和结果摘要丢弃推理过程等噪声内容。特别提醒一下不要让 Agent 自己决定保留哪些历史信息。模型倾向于保留所有信息以防万一结果很快就把上下文窗口占满了。上下文裁剪必须是一个确定性的策略由 harness 来控制不交给模型决策。3.3 工具调用的端侧实现从函数注册到结果过滤工具调用模块在云端 Agent 里相对简单——定义函数 schema模型返回函数名和参数系统调用对应的函数。但端侧有一个明显的痛点模型的工具调用格式不稳定。云端用 GPT-4 或 Claude工具的 JSON 输出格式基本不会出错。但端侧模型尤其是小参数模型经常出现格式错误、参数缺失、幻觉函数名等问题。我在早期项目里有差不多五分之一的工具调用是失败的原因全是格式问题而不是模型理解错了。后来我摸索出一套比较完整的做法第一工具注册时要做充分的 schema 定义每个参数都要写清楚类型、范围、默认值并在描述里注明如果该参数不确定可以省略。这样做是为了给模型减负提供尽量多的辅助信息。第二工具调用要做一层参数校验和修复。模型返回的参数可以先走一层规则逻辑检查必填参数是否存在检查参数类型是否匹配检查参数范围是否合法。不合法时优先尝试自动修复比如把字符串转成数字修复不了再返回错误信息让模型重新生成。第三工具结果要做裁剪和提取。工具返回的结果往往包含大量不需要的信息直接塞进上下文会浪费窗口。我会给每个工具定义一个结果过滤器只保留任务相关的字段。比如一个查天气的工具可能接口返回了 30 个字段但模型只需要温度和降水概率两个过滤器直接提取这两个字段返回。3.4 记忆模块短期记忆与长期记忆的互补设计Agent 的记忆系统是智能感的重要来源。没有记忆的 Agent 每次对话都是从零开始用户体验很割裂。有记忆但不会管理的 Agent上下文很快被占满效果反而更差。我通常会把记忆拆成两层短期记忆覆盖当前会话长期记忆跨会话持久化。短期记忆的核心是相关性管理。我维护一个滑动窗口最新的对话永远是最优先保留的。当窗口满了就触发一次记忆整合把旧信息压缩成摘要存到长期记忆里。这个整合过程可以用规则做也可以用一次小模型的推理来做取决于你对实时性的要求。长期记忆的存储有两种选择向量数据库和结构化存储。向量数据库适合做语义检索结构化存储比如 SQLite 或 JSON 文件适合做精确匹配。我个人的建议是能用结构化存储解决的问题就不要上向量数据库原因很简单——端侧资源有限向量索引的内存占用和检索耗时会随着数据量增长而大部分场景实际上只需要简单的键值对查找。举一个实际场景用户经常问上次我说要在周末去爬山帮我看看天气。这种需求需要记住上周末聊过爬山这个话题用结构化存储直接存一个 { 主题爬山时间上周末地点城郊 } 的表就能覆盖不需要向量检索。只有面对帮我找找之前聊过的跟创意相关的所有内容这种模糊需求时向量检索才更有价值。4. 并发与稳定性端侧 Agent 如何扛住压力4.1 端侧 Agent 的并发到底指什么先要澄清一个概念端侧 Agent 的并发和云端 Agent 的并发不是一回事。云端并发是大量用户同时请求你的服务考验的是服务器的负载能力端侧并发是一个用户在同一台设备上可能同时触发多个任务考验的是设备本地资源的调度能力。举个具体例子用户在手机上打开一个 Agent 应用正在和 Agent 对话这时候突然来了一个通知Agent 需要在后台处理通知相关的任务。或者用户在 Agent 应用里运行着一个长任务比如让 Agent 帮忙整理文档同时又发起了另一个对话。这些场景构成了端侧 Agent 的并发压力。端侧算力有限很难做到真正的多任务并行推理。解决办法是任务队列 优先级调度。我把任务分成三类高优先级用户正在交互的任务需要立即响应抢占所有资源中优先级用户期待但可以稍等的任务比如帮我把这些图片分类可以后台执行低优先级系统后台任务比如记忆整理、数据同步只在系统空闲时执行任务队列的调度策略也很简单高优先级任务直接抢占中优先级任务排队轮流执行低优先级任务执行前先检查当前系统的负载如果 CPU 占用超过 60% 就暂停等系统空闲时再恢复。4.2 推理并发与模型调用的串行化处理端侧模型推理目前基本是串行的尤其是在 CPU 或 NPU 上运行小模型时并发推理很难做到。但这不代表没有办法优化。我试过的最有效的方案是推理请求合并。当多个任务同时需要模型推理时不立即执行而是聚合等待一个极小的时间窗通常 100-200 毫秒在这段时间内到达的所有推理请求合并成一次推理。这听起来有点反直觉但实际效果很好模型一次推理的成本远低于多次推理的成本之和而且 100 毫秒的延迟在用户感知上几乎无感。另一个优化点是推理结果缓存。端侧 Agent 经常会遇到相似的请求——用户用不同的措辞问同一个问题或者在不同的对话中触发相同的工具调用。我会对推理请求做语义级别的缓存先计算请求的嵌入向量然后和缓存中的历史请求做相似度匹配相似度超过阈值通常 0.85-0.9就直接返回缓存的结果不调用模型。这个方案踩过一个坑缓存结果如果包含工具调用指令直接返回会导致工具被重复执行或者执行结果和当前状态不匹配。后来我在缓存设计里加了规则含有工具调用的响应不做缓存只缓存纯文本回答的响应。4.3 错误恢复机制Agent 崩溃后怎么办端侧 Agent 的系统崩溃是必然的不是你代码写得好就能避免。用户切换应用、系统杀后台、内存告警、电池低电量各种情况都会导致 Agent 进程被中断。云端 Agent 挂了大不了重试端侧 Agent 挂了你不能要求用户重新把需求说一遍。所以错误恢复机制是端侧 Agent 工程化的必备模块。我的做法是会话持久化 状态重建在 Agent 运行的每个关键步骤结束时把当前状态序列化存储到本地。状态信息包括当前任务描述、执行的步骤清单、每一步的执行结果、上下文压缩摘要、未完成的计划。这样即使 Agent 进程被杀下次启动时也可以从最近的状态点恢复。恢复时的策略是如果恢复点在任务开始前用户输入刚接收还没执行任何步骤直接重新开始如果恢复点在任务执行中部分步骤已完成不从头执行而是基于已完成的结果继续后续步骤如果恢复点在任务结束时结果已经生成直接返回缓存的结果。这个机制有一个值得注意的细节状态恢复后要做一次上下文一致性校验。因为 Agent 可能依赖了真实世界的信息比如读取了某个文件的内容恢复时如果文件已经变了要继续执行就会出错。处理方式是给每个工具调用记录一个输入摘要恢复时比对当前输入是否和摘要一致不一致就要求用户确认或重新执行该步骤。4.4 Agent 安全的端侧实现权限控制与数据最小化端侧 Agent 的安全问题经常被忽略但实际很重要。Agent 在你的设备上运行它能访问你的文件、通讯录、应用数据如果被恶意利用后果比云端泄露更严重。我的安全策略是权限最小化 动态授权。Agent 启动时不持有任何敏感资源的访问权限当它需要访问某个资源时先向用户发出一个授权请求说明访问目的和使用的数据范围。用户授权后权限只在当前任务内有效任务结束后立即收回。工具调用层也需要做安全过滤。我给每个工具定义了安全级别安全级别工具类型授权要求典型例子L0本地无害操作无需授权读取当前时间、处理文本L1本地数据读取用户确认读取相册元数据、读取应用列表L2本地数据修改用户确认 风险提示删除文件、修改系统设置L3网络操作用户确认 域名白名单发微博、购买商品L3 级的工具需要特别注意。Agent 可能会被 prompt injection 攻击——用户在某个网页里藏了一段恶意指令你的 Agent 读取网页内容后被里面的指令诱导执行了不该执行的操作。这是我很早就意识到的问题所以端侧 Agent 执行网络操作前必须有用户的明确确认不能静默操作。5. 实操记录一个端侧 Agent 的工程实现过程5.1 项目背景与基础配置为了不空谈理论我用一个实际项目来展示端侧 Agent 工程化的完整过程。项目背景是做一个移动端助理应用用户可以用自然语言让手机执行一些本地操作查天气、定闹钟、打开应用、发短信等。模型使用的是端侧部署的 3B 参数小模型推理框架用的是本地的 LLM 运行时系统环境是 Android 设备。关键配置参数大致如下模型3B 参数4-bit 量化上下文窗口 8K推理后端本地 NPU 加速支持流式输出设备内存要求Agent 运行时占用控制在 300MB 以内最大迭代轮数6 轮工具数量初始版本注册 12 个工具这个配置比较保守但保证了在老设备上也能流畅运行。如果你的目标设备较新可以适当上调模型参数或上下文窗口。5.2 从零搭建 Agent 运行框架的步骤我逐步讲解搭建过程。这里不是完整的源码而是核心逻辑的骨架和关键决策的解释。第一步定义工具接口和注册机制工具在 Agent 系统里是标准化的接口每个工具需要实现以下内容工具名称唯一标识 工具描述给模型看的说明这个工具能做什么、什么时候用 参数定义JSON Schema 执行函数接收参数返回结果 安全级别对应权限控制 结果过滤器提取返回信息中的关键部分工具注册发生在 Agent 启动时系统会收集所有可用工具的 schema拼接成工具定义文本放入系统提示词中。模型只有在工具定义文本里看到的工具才可能被调用所以工具的描述写得清不清楚直接决定了模型能不能正确选择工具。第二步建立上下文管理模块我实现了一个简单的上下文管理类负责维护完整的对话历史。它对外提供三个操作插入用户输入、插入模型输出、插入工具结果内部负责维护一个循环缓冲区并实时监控 token 占用情况。上下文管理的核心逻辑是水位线机制。定义一个高水位比如 7000 token和一个低水位比如 4000 token。当 token 占用超过高水位时触发压缩流程把最早的历史对话做摘要删掉生存时间最长的工具结果直到降到低水位以下。第三步实现编排引擎编排引擎的代码是 Agent 系统的核心循环。关键逻辑如下def run_agent(user_input): # 1. 追加用户输入到上下文 context.append_user_message(user_input) # 2. 进入 Agent 循环 for iteration in range(max_iterations): # 3. 调用模型推理 response model.generate(context.to_messages()) # 4. 解析响应判断类型 parsed parse_model_response(response) if parsed.is_final_answer(): # 模型给出最终答案直接返回 context.append_assistant_message(parsed.content) return parsed.content elif parsed.is_tool_call(): # 模型请求调用工具 tool_name parsed.tool_name tool_args parsed.tool_args # 5. 验证工具参数执行工具 if not tool_registry.exists(tool_name): context.append_tool_error(f工具 {tool_name} 不存在) continue result execute_tool(tool_name, tool_args) # 6. 结果过滤和裁剪 filtered filter_tool_result(tool_name, result) context.append_tool_result(tool_name, filtered) else: # 解析失败触发错误恢复流程 handle_parse_error(context, response) # 7. 超过最大迭代次数返回当前最佳结果 return 任务执行超过最大步骤数建议简化指令后重试。这段代码看似简单实际有几个关键的工程细节需要注意。第四步加入错误处理与恢复机制在实际运行中model.generate可能会超时execute_tool可能抛异常parse_model_response可能返回空结果。我的处理是每个环节都加 try-catch并且根据错误类型决定是重试、跳过还是终止。比如模型生成超时重试一次工具执行失败把错误信息追加回上下文给模型一个修正机会解析失败且连续发生两次以上终止任务并向用户报告错误。状态恢复的持久化也在这个阶段实现。每次工具调用结束后序列化当前状态到本地。序列化的数据量控制在几 KB 以内读写耗时忽略不计。5.3 工具调用成功率的优化过程我在这个项目的开发过程中最初工具调用的成功率只有 82% 左右经过三轮优化后提升到了 97% 以上。这轮优化过程非常典型我详细说一下每个阶段的改动和效果。第一轮优化增加 JSON 修复层成功率 82% → 88%原始实现是直接把模型的输出交给json.loads解析失败就报错。增加修复层之后做了几件事提取字符串中最外层的大括号或方括号里的内容忽略前后噪声对不完整的字符串尝试补全引号和大括号删除多余的关键字部分模型会输出这里的回复请直接使用 json之类的废话这一轮改完之后格式错误类的失败大幅降低但参数错误类的失败还是很多。第二轮优化加强参数校验与自动修复成功率 88% → 93%这一轮的难点在参数校验。模型的回复里经常会出现参数和 schema 定义不一致的情况比如 schema 里定义的是一个整数类型的时间模型返回了十分钟后schema 里定义了一个必填的location字段模型遗漏了但在描述里提到了。我的做法是工具执行前先做一轮参数清洗针对常见的模型错误模式做专门处理类型转换字符串转数字、字符串转布尔值等根据 schema 的字段类型自动转换枚举归一化模型可能返回同义词比如工具定义接收mobile模型返回了phone通过别名表做映射补全缺失字段某些工具可以在参数缺失时使用默认值在 schema 里注明default: auto的字段缺失时不报错直接使用默认值第三轮优化prompt 层面的工具描述精炼成功率 93% → 97%轮优化没有改代码只改了 prompt。我发现模型调用工具失败很多原因是工具的描述写得太抽象。比如最初某个工具的说明是使用本地应用打开对应链接注意需要防止外部攻击小心点击模型看了之后理解的是这个工具有安全风险可能不能随便用于是就不调用了。我把所有工具描述重写了一遍原则是描述要直接告诉模型这个工具在什么情况下必用应该传哪些参数不要写任何警示性、防御性的废话。改完之后模型工具的调用准确率有了一次明显跃升。5.4 端侧 Agent 的内存与性能实测项目开发完成后我在一台中端 Android 设备上做了详细的性能测试。设备配置8 核 CPU集成 NPU内存 8GB系统实际可用约 4GB系统 Android 14。测试场景是用户连续发出 5 个不同的任务指令每个任务都涉及至少一次工具调用然后检查整体表现指标实测数值备注启动加载时间480ms含模型加载和工具注册首次推理延迟680ms冷启动较慢热启动明显降低平均单轮推理延迟320ms依赖于输入长度和模型量化工具执行平均耗时120ms本地工具不含网络请求对话全流程耗时2.8s含 3 轮推理 2 次工具调用峰值内存占用286MB模型推理时的内存峰值稳态内存占用175MB空闲状态下的常驻内存从数据来看这个配置在多数真实场景下是可以接受的。用户发出一个指令到收到回复大概需要 3 秒左右配合流式输出模型是边生成边输出的体感上不会觉得太慢。内存这块286MB 的峰值占用在移动设备上确实偏高但考虑到是在用户主动使用 Agent 的情况下才会触及这个峰值可以接受。后续我会考虑进一步优化降低模型量化位宽从 4-bit 降到 3-bit 可以再省约 20% 内存但推理质量会轻微下降、对工具结果做更激进的裁剪等。6. 常见问题排查手册踩过的坑和解决方案6.1 工具调用格式频繁出错现象模型有时返回无法解析的工具调用格式。排查思路先区分是格式问题还是内容问题。在日志中记录每一次模型输出的完整原文观察出错的模式。常见的格式错误有JSON 被截断、缺少闭合括号、参数值里出现了未转义的特殊字符、模型把多个工具调用混在一个响应里返回。解决方案优先加 JSON 修复层修复不了就重试用出错信息引导模型重新输出比如追加一句上次的工具调用格式有误请严格按照定义输出重试两次仍然失败时终止调用并返回默认兜底答案。另外在 prompt 层面控制明确告诉模型每次只能调用一个工具多个工具调用必须拆分到不同轮次这能大幅降低格式错误的概率。6.2 上下文窗口被历史工具结果占满现象Agent 运行几轮之后上下文窗口耗尽模型开始失忆——回复的内容和之前的对话逻辑对不上。排查思路检查上下文管理模块的输入输出。在调试模式中打印每次上下文更新后的 token 占用情况找到占用最多的内容类型。根据我排查的经验工具完整返回结果是最主要的内存消耗源。解决方案这需要执行两个方向的优化。第一重写各类工具的结果过滤器让返回内容只保留关键字段第二上下文压缩时优先压缩工具结果毕竟它们往往已经执行完毕不太相关了。如果在压缩后发现 Agent 还是失忆可以尝试把系统提示词里补充你是运行在用户手机上的代理助理请始终基于当前对话最新消息回答如果你没有找到相关信息请直接说明不知道利用宽松约束来提升模型对现有上下文的利用。6.3 Agent 响应太慢用户体验差现象用户发出指令后Agent 偶尔会卡住几秒甚至更久才给出响应。排查思路先把耗时拆解成几个环节模型推理耗时、工具执行耗时、上下文管理耗时、进程切换耗时。分别做埋点统计找到瓶颈。解决方案根据耗时定位结果通常是模型推理耗时占大头。优化手段有调整量化位宽4-bit 效果基本够用、启用 NPU 加速部分设备上相比 CPU 能降低 40% 以上的推理时间、减少上下文占用来降低 attention 计算量、对常见的用户指令做 pattern matching 直接跳过模型推理比如设置一个五分钟后的闹钟这种固定句式不太需要模型推理规则匹配可以直接执行。如果这些手段都用上了还是慢建议降低模型参数规模从 3B 降到 1.5B推理延迟能减半代价是复杂任务的理解能力变差。6.4 Agent 进程被杀后的会话恢复异常现象用户中途切出应用再回来时发现 Agent 完全忘记了之前的任务或者更糟——提醒用户上次任务进行到一半是否继续时用户点继续Agent 执行出错。排查思路检查状态恢复校验逻辑。我遇到过一次这样的问题状态恢复后工具执行继续使用之前的参数但执行环境已经变了。解决方案恢复时的关键校验不能省。每个工具调用的执行结果要带上时间戳和输入摘要恢复时先比较当前的输入参数和摘要是否一致不一致就触发重新执行该步骤。注意恢复状态时不要把用户的对话历史丢掉——短期记忆的恢复优先于长期记忆上次聊了什么远比上个任务做到哪一步更影响用户体验。6.5 不同设备上模型输出质量差异大现象同一套代码同一份模型权重在 A 手机上表现很好在 B 手机上经常出现输出格式错误或语言不流畅。排查思路不同设备的芯片不同算子支持程度不同相同的推理代码可能实际上跑在不同精度的计算上。在 NPU 上某些小算子会被调度到 CPU 执行中间结果精度不同最终输出就会出现细微差异。解决方案对端侧推理做一次算子级验证。在目标设备上跑一遍模型自带的验证用例检查输出是否和参考值一致。如果发现差异过大考虑在同一设备上禁用 NPU 加速改用 CPU 运行推理时间会增加但输出质量更可预期。在很多场景里稳定比快更重要。7. 回到工程化本质端侧 Agent 的下一步怎么走写了这么多都围绕一个核心问题如何把 Agent 从能跑变成好用。端侧环境的资源约束逼着你把工程化做到极致这反而是好事——在云端你可以用堆资源的方式掩盖工程上的粗糙在端侧每一个设计失误都会直接暴露成用户体验问题。根据我个人的实践体会端侧 Agent 工程化的优先级排序应该是稳定性 响应速度 智能程度。这个顺序很重要很多团队做反了。一上来就追求模型的推理能力把一个 7B 模型塞进设备结果经常出 bug用户用两次就卸载了。先把有限的资源投入到稳定性和容错机制上让 Agent 能够稳定地完成简单任务再逐步提升智能程度这个路径更可行。后续这个系列还会继续往下讲。下一部分我会重点分享 Agent 工程化的后半程数据回流与迭代优化、多设备适配实践、以及端侧 Agent 的可观测性设计。如果你正在或准备做端侧 Agent欢迎在评论区交流你们遇到的问题。