端侧AI Agent开发实战：从token工厂到价值工厂的工程化路径

1. 从跑个Demo到真干活端侧AI卡在哪一环过去两年我接触过不少做智能硬件的团队几乎每家都在PPT里写过AI赋能。但真正把大模型塞进终端、并且让用户愿意天天用的产品屈指可数。大部分项目止步于一个尴尬的阶段演示时惊艳日常使用时鸡肋。用户打开一次问两句天气然后就再也没有然后了。问题出在哪不是模型不够强也不是硬件算力不够。核心矛盾在于——终端上的AI调用是事件驱动的而不是任务驱动的。用户说一句话设备调一次模型返回一个结果流程就结束了。这种模式下AI只是一个高级一点的语音助手它没有记忆、没有上下文、没有持续执行的能力。而真正让AI产生价值的是让它像一个工人一样在终端上持续地、自主地完成一系列任务。这就是智能终端变成token工厂这个说法的底层逻辑。它不是在说终端要生产token而是在说终端应该成为一个持续消耗token、持续产出价值的节点。每一次推理、每一次工具调用、每一次上下文压缩都是在消耗token换结果。当这个循环能够自主运转起来终端才真正从AI玩具变成了AI生产力工具。我见过一个很典型的对比案例。A团队做了一款AI录音笔功能是录音转文字加摘要。用户录完音点一下生成摘要等几秒钟出结果。B团队做的是类似硬件但他们的产品会在录音过程中实时做分段、打标签、识别说话人录完之后自动生成结构化纪要并且根据内容自动创建待办事项、关联日历。两者的硬件成本差不多模型也差不多但B团队的产品日活是A团队的四倍多。差别就在于A是事件驱动B是任务驱动。B的终端在后台持续跑着Agent流程token在持续消耗价值也在持续产出。所以当我们讨论端侧AI的时候真正要解决的问题不是能不能跑模型而是怎么让模型在终端上持续地、可靠地、低成本地跑起来。这涉及到几个层面的工程问题Agent框架怎么在资源受限的终端上编排、token怎么管理才能既够用又不浪费、端侧和云侧怎么分工才能兼顾体验和成本。下面我会结合自己在端侧Agent开发中踩过的坑把这些环节拆开来讲。2. 端侧Agent框架的选型逻辑为什么不能直接搬云端那套2.1 云端Agent框架的假设在终端上全部失效在服务器上跑Agent我们习惯了很多理所当然的事情网络永远在线、内存随便用、CPU核数管够、进程挂了重启就行。但把这些框架直接搬到终端上你会发现每一个假设都不成立。我最早尝试把一个开源的Agent编排框架移植到一款安卓设备上结果光是依赖就装不进去——那个框架依赖了一个完整的Python运行时和一堆科学计算库光安装包就两百多兆。终端设备的存储和内存根本吃不消。后来换了一个轻量级的框架勉强跑起来了但发现它的调度逻辑是轮询式的每隔几秒检查一次有没有新任务。这在服务器上没问题但在终端上轮询意味着CPU永远不能进入深度休眠续航直接崩了。所以端侧Agent框架的第一个选型原则就是事件驱动 按需唤醒。框架本身应该是一个极轻量的调度器平时处于休眠状态只有当特定事件用户输入、传感器触发、定时任务到期发生时才唤醒对应的Agent流程。流程执行完毕后框架要能主动释放资源让系统回到低功耗状态。2.2 端侧Agent的三种典型架构根据我的实践经验端侧Agent的架构大致可以分成三类各有各的适用场景。第一类是纯端侧闭环。所有推理、工具调用、状态管理都在终端上完成。这种架构的优点是隐私好、延迟低、不依赖网络。缺点是能跑的模型规模有限复杂任务搞不定。适合的场景是输入法联想、本地相册整理、离线语音指令。我做过一个本地文档问答的Agent模型用的是量化后的小模型配合本地的向量检索在手机上跑起来响应速度可以做到一秒以内体验相当不错。但一旦用户问的问题需要外部知识或者复杂推理它就歇菜了。第二类是端云协同。终端负责意图识别、简单任务执行和上下文管理复杂推理和知识密集型任务交给云端。这种架构的关键在于任务路由——终端上的Agent要能判断哪些任务自己能搞定哪些需要上云。我见过一个做得比较好的实现终端上跑一个轻量级的分类模型把用户请求分成本地可处理和需要上云两类。本地可处理的直接执行需要上云的把上下文打包发走。这样既保证了简单任务的响应速度又保证了复杂任务的能力上限。第三类是端侧Agent编排 云侧模型服务。终端上的Agent框架负责整个任务的编排和状态管理但具体的推理调用的是云侧的模型API。这种架构下终端更像是一个调度中心它决定什么时候调什么模型、传什么上下文、怎么处理返回结果。这种模式对终端的算力要求最低但对网络稳定性和token成本控制的要求最高。2.3 选型时最容易忽略的指标token消耗效率很多团队在选Agent框架的时候只看功能列表和性能跑分忽略了一个关键指标完成同一个任务不同框架消耗的token量可能差好几倍。我做过一个对比测试让三个不同的Agent框架完成同一个任务帮我查一下明天北京的天气如果下雨就提醒我带伞并且把提醒加到日历里。任务本身不复杂但不同框架的token消耗差异很大。框架A用了大约1200个token框架B用了800个框架C只用了500个。差别主要来自两个方面一是系统提示词的长度二是工具调用结果的压缩策略。框架A的系统提示词写了整整一页把所有的工具描述、输出格式要求、注意事项都塞进去了。框架B精简了一些但每次工具调用返回的结果都原封不动地塞回上下文。框架C做了一件很聪明的事它对工具返回的结果做了摘要压缩只保留关键信息把冗余的JSON结构去掉了。比如天气API返回了一大段JSON框架C只提取了天气状况温度降水概率三个字段其他的全扔了。这个差异在单次任务里可能不明显但如果是每天执行几十次任务的终端设备token成本的差距就会非常可观。所以我在选型时的建议是一定要用真实的任务场景做token消耗的基准测试不要只看框架的文档和宣传。3. Token管理的实战细节从够用到精打细算3.1 端侧token预算的分配策略在终端上做AI应用token预算是一个硬约束。这个约束可能来自几个方面如果是调用云端API约束是成本如果是端侧推理约束是上下文窗口大小和内存。不管是哪种都需要对token的使用做精细化管理。我的做法是把token预算分成四个池子系统提示词池、上下文池、工具调用池、输出池。系统提示词池是固定的用来存放Agent的角色定义和基本规则。上下文池是动态的用来存放对话历史和任务状态。工具调用池用来存放工具描述和调用结果。输出池留给模型的最终回复。这四个池子的比例需要根据任务类型来调整。如果是对话型任务上下文池要大一些因为需要记住多轮对话的内容。如果是工具调用型任务工具调用池要大一些因为工具描述和返回结果可能很占空间。我一般会留出20%的余量防止某个池子突然不够用。有一个很容易踩的坑系统提示词写得太长。我见过一个项目系统提示词写了三千多token把各种边界情况、输出格式、安全规则全塞进去了。结果每次调用光系统提示词就消耗掉一大半预算留给实际任务的空间非常有限。后来我们做了一轮精简把系统提示词压缩到八百token以内把一些不常用的规则改成按需加载——只有当任务类型匹配时才动态注入。这样一改同样的预算能处理的任务量翻了一倍多。3.2 上下文压缩的几种实用手段上下文压缩是端侧Agent必须掌握的核心技能。因为终端的上下文窗口有限如果不做压缩几轮对话下来就满了。我常用的压缩手段有三种。第一种是滑动窗口加摘要。保留最近N轮对话的完整内容更早的对话用模型生成一个摘要。摘要的长度控制在原文的20%左右。这样既能保留关键信息又能大幅节省token。第二种是结构化提取。对于工具调用的返回结果不要原封不动地塞回上下文而是提取关键字段用紧凑的格式重新组织。比如一个搜索API返回了十条结果每条都有标题、链接、摘要、时间戳我可能只保留标题和摘要把链接和时间戳去掉。第三种是状态外置。把一些不常变化的信息比如用户偏好、设备状态存到外部的键值存储里需要的时候再查而不是一直放在上下文里。这三种手段可以组合使用。我在一个智能家居控制的Agent里就同时用了滑动窗口和结构化提取。用户说把客厅的灯调暗一点Agent需要知道当前亮度、用户的历史偏好、房间的灯具列表。这些信息如果全放在上下文里很快就满了。我的做法是当前亮度从设备状态API实时获取用户偏好从本地存储读取灯具列表只在第一次对话时加载。这样上下文里只需要保留对话本身token消耗降低了60%以上。3.3 Token续签与失效处理一个容易被忽视的工程问题在端云协同的架构里token还有一个容易被忽视的含义认证token。终端上的Agent要调用云侧服务就需要携带认证token。这个token有有效期过期了就需要续签。如果续签逻辑没做好Agent在执行任务的过程中突然遇到token失效整个任务就会中断。我踩过这个坑。当时做的是一个定时任务Agent每天早上自动帮用户整理当天的日程并生成摘要。测试的时候一切正常但上线后偶尔会有用户反馈早上没有收到摘要。排查后发现问题出在token续签上Agent在凌晨执行任务时认证token刚好过期了而续签逻辑需要用户交互才能完成结果任务就静默失败了。后来我们的解决方案是在Agent框架里内置一个token生命周期管理器。这个管理器会在token过期前一段时间比如提前十分钟自动触发续签续签过程对Agent流程透明。如果续签失败Agent会记录状态并在下一次有机会时重试而不是直接丢弃任务。同时对于关键任务我们会做任务持久化——把任务状态存到本地即使当前执行失败下次启动时也能恢复。这个经验让我意识到端侧Agent的可靠性不仅仅取决于模型能力还取决于这些周边的工程细节。token管理、网络重试、状态持久化这些看起来不起眼的东西往往决定了用户的实际体验。4. 端侧AI硬件部署的现实约束与应对4.1 算力、内存、功耗的不可能三角做端侧AI硬件绕不开一个不可能三角算力、内存、功耗。你想要更强的算力就得接受更高的功耗和更大的内存占用你想要更长的续航就得在算力和内存上做妥协。我参与过一款带AI功能的可穿戴设备的设计。最初的方案是想在设备上跑一个中等规模的模型支持离线语音助手。但实测发现模型加载后占用了大量内存导致其他功能经常被系统杀掉而且推理时的功耗很高续航从预期的两天缩水到了半天。后来我们调整了方案把模型进一步量化同时把一些不常用的能力移到云端。设备上只保留最核心的唤醒词识别和简单指令解析复杂任务通过蓝牙转发到手机处理。这样续航恢复到了正常水平用户体验也没有明显下降。这个经历给我的教训是端侧AI的硬件部署首先要明确哪些能力必须在端侧哪些可以放到云侧或邻近设备。不是所有AI能力都适合放在终端上。唤醒词识别、隐私敏感的数据处理、需要极低延迟的响应这些适合端侧。知识问答、复杂推理、大规模内容生成这些适合云侧。把合适的能力放在合适的位置比强行把所有东西都塞进终端要明智得多。4.2 模型量化与推理加速的实操经验如果确定要在端侧跑模型量化是必须做的。我试过几种常见的量化方案这里分享一些实测数据。以一款70亿参数的模型为例原始FP16精度下模型大小约14GB在终端上根本跑不起来。经过8-bit量化后大小降到约7GB还是太大。4-bit量化后降到约3.5GB勉强可以在高端手机上运行但推理速度很慢生成一个短句需要好几秒。后来我们换了一个更小的模型30亿参数配合4-bit量化大小降到约1.5GB推理速度提升到可以接受的范围。除了量化推理加速还有几个实用的手段。一是算子融合把多个连续的操作合并成一个减少内存访问次数。二是KV缓存优化对于多轮对话场景缓存之前的键值对避免重复计算。三是动态批处理如果有多个请求同时到达合并成一个批次处理提高硬件利用率。这些手段组合使用可以把端侧推理的延迟降低一半以上。不过要注意量化会带来精度损失。我在一个文本分类任务上测试过4-bit量化后的模型准确率比原始模型下降了大约3个百分点。对于大多数应用场景这个损失是可以接受的但如果是对精度要求很高的任务比如医疗、金融就需要谨慎评估。4.3 端侧存储与状态管理的设计要点端侧Agent需要持久化一些状态对话历史、用户偏好、任务队列、工具调用缓存。这些数据怎么存、存多久、怎么清理都需要仔细设计。我的经验是采用分层存储的策略。最热的数据比如当前对话的上下文放在内存里读写最快。次热的数据比如最近几天的对话历史放在本地数据库里用SQLite或者类似的轻量级方案。冷数据比如几个月前的记录可以压缩后归档或者上传到云端备份。存储空间的管理也很重要。终端设备的存储空间有限不能无限增长。我一般会设置一个上限比如对话历史最多保留最近1000条超过的就自动清理最旧的。同时对于工具调用的缓存设置一个合理的过期时间比如24小时过期后自动删除。这样既能保证常用数据的快速访问又不会把设备存储撑爆。还有一个细节状态的一致性。如果Agent在执行任务的过程中设备突然断电或者应用被杀死状态可能会不一致。我的做法是采用预写日志的方式在执行关键操作之前先把操作意图写到日志里执行完成后再标记为已完成。如果中途崩溃下次启动时可以根据日志恢复或者回滚。这个机制在定时任务和长流程任务里特别重要。5. 让AI被深度使用的产品设计思路5.1 从用户主动调用到Agent主动服务大部分AI产品的交互模式是用户问AI答。这种模式的问题在于它要求用户主动想到要用AI并且知道该怎么问。但真正被深度使用的AI应该是润物细无声的——它在后台持续工作在合适的时机主动提供服务。我观察过一些日活很高的AI功能它们有一个共同点AI的触发不是用户发起的而是场景触发的。比如用户收到一封邮件AI自动提取其中的待办事项并添加到任务列表用户拍了一张名片AI自动识别信息并存入通讯录用户到达一个地点AI自动推送相关的提醒或信息。这些场景下用户不需要打开AIAI就已经在工作了。要实现这种主动服务Agent需要具备几个能力。一是场景感知能够获取设备的状态、用户的位置、当前时间等信息。二是意图预测根据场景判断用户可能需要什么。三是自主执行在不需要用户确认的情况下完成低风险的任务。四是适时反馈在执行完任务后用不打扰的方式告知用户结果。这里的关键是低风险任务的界定。不是所有任务都适合Agent自主执行。发送消息、修改日程、删除文件这些操作最好还是让用户确认一下。而查询信息、整理内容、生成摘要这些只读操作可以放心让Agent自主完成。5.2 反馈闭环让Agent越用越懂用户一个被深度使用的AI一定是越用越懂用户的。这需要建立有效的反馈闭环。我在一个项目中设计了一个简单的反馈机制每次Agent完成任务后会记录用户的反应。如果用户直接使用了Agent生成的结果比如复制了摘要、点击了推荐的链接就视为正反馈。如果用户撤销了操作或者修改了结果就视为负反馈。这些反馈数据被用来调整Agent的行为策略。比如如果用户经常修改Agent生成的日程时间Agent就会在下次生成时更谨慎或者主动询问用户偏好。这个机制不需要复杂的机器学习简单的统计和规则就能见效。关键是要让反馈的收集是隐式的、无感的不要给用户增加额外的操作负担。用户不需要点赞或点踩他们的自然行为就是最好的反馈信号。5.3 避免AI疲劳什么时候该让AI闭嘴做AI产品有一个很容易犯的错误过度推送。Agent觉得某个信息对用户有用就频繁地提醒、推荐、建议。结果用户觉得被打扰干脆把AI功能关掉了。我在设计主动服务的时候会遵循几个原则。一是频率控制同一个类型的主动服务每天最多触发一次。二是优先级过滤只有真正重要的事情才主动推送其他的放到待查看列表里等用户自己来看。三是静默时段在用户休息的时间段比如晚上十点到早上七点除非是紧急事项否则不主动打扰。四是可配置让用户能够控制哪些类型的主动服务是开启的哪些是关闭的。这些原则看起来简单但执行起来需要克制。产品经理总是希望AI能多做一点但有时候少做一点反而能让用户更愿意长期使用。6. 我在端侧Agent开发中踩过的几个真实坑6.1 工具调用的幻觉问题Agent调用工具时最常见的问题是幻觉——模型会编造不存在的工具或者用错误的参数调用工具。在云端这个问题可以通过强大的模型能力和完善的校验机制来缓解。但在端侧模型能力有限校验机制也不能太复杂这个问题就变得很突出。我遇到过一个案例用户让Agent设置一个明天早上八点的闹钟。Agent正确地识别了意图但在调用工具时它编造了一个叫set_alarm的工具而实际上系统提供的工具叫create_reminder。结果调用失败用户没有得到预期的结果。解决这个问题的办法有几个。一是工具描述的清晰化把工具的名称、参数、用途写得非常明确减少模型误解的空间。二是调用前的校验在真正执行工具调用之前先检查工具名称是否存在、参数是否合法。如果校验失败让模型重新生成。三是提供示例在系统提示词里给出几个正确的工具调用示例让模型有样学样。这些手段组合使用后工具调用的成功率从最初的70%左右提升到了95%以上。剩下的5%主要是模型能力本身的限制需要通过模型迭代来解决。6.2 长任务的超时与中断处理端侧Agent执行长任务时很容易遇到超时或中断。比如一个需要调用多个工具、处理大量数据的任务可能跑着跑着就超过了系统允许的执行时间被强制终止。我的处理方案是任务分片 断点续传。把一个长任务拆成多个短步骤每个步骤执行完后保存状态。如果中途被中断下次可以从最后一个成功的步骤继续而不是从头开始。同时对于每个步骤设置合理的超时时间超时后自动重试或者降级处理。这个机制在定时任务和后台任务里特别重要。用户不会一直盯着Agent执行如果任务失败了没有恢复机制用户就会觉得这个AI不靠谱。6.3 多Agent协作时的状态同步在一些复杂的场景里可能需要多个Agent协作完成任务。比如一个Agent负责理解用户意图一个Agent负责调用工具一个Agent负责生成回复。这些Agent之间需要共享状态如果状态同步没做好就会出现各说各话的情况。我的经验是用一个中心化的状态管理器来协调多个Agent。每个Agent在执行前后都从状态管理器读取和写入状态而不是Agent之间直接传递状态。这样可以避免状态不一致的问题也方便调试和追踪。另外Agent之间的通信协议要尽量简单。我一般用JSON格式的消息包含发送者接收者消息类型负载几个字段。消息类型包括请求响应通知错误几种。这种简单的协议足够应对大多数场景而且容易实现和排查问题。7. 端侧AI的未来从token工厂到价值工厂回到标题里的说法——智能终端变成token工厂。这个比喻其实还有一层更深的意思当终端能够持续地、自主地消耗token来完成任务时它就不再是一个被动的工具而是一个主动的生产者。它生产的不是token本身而是token背后代表的价值整理好的信息、自动完成的任务、及时提供的提醒。我个人的判断是未来两年端侧AI的竞争焦点会从能不能跑模型转移到能不能把模型用好。模型能力会逐渐趋同真正的差异化在于Agent的编排能力、token的管理效率、以及产品对用户场景的理解深度。对于正在做端侧AI的团队我的建议是不要追求大而全先找到一个具体的、高频的、用户愿意每天使用的场景把Agent在这个场景里的体验做到极致。一个被深度使用的简单功能比十个浅尝辄止的复杂功能更有价值。最后分享一个我在实践中总结的小技巧在Agent的每个关键决策点加日志。端侧Agent的执行过程往往是个黑盒出了问题很难排查。把每个决策点的输入、输出、耗时都记录下来不仅方便调试还能用来分析用户的使用模式为后续的优化提供依据。这个习惯让我在多个项目里快速定位到了性能瓶颈和逻辑错误省下了大量排查时间。