说实话今年骁龙峰会给我的感觉跟往年完全不是一回事。以前是跑分墙前挤满人芯片参数一拍大家热闹一天就散了。这次不一样整个场子都在谈AI、Agent高通的PPT里“骁龙”和“智能体”绑得比什么时候都紧感觉不是在发一款芯片而是在给未来三年的终端AI生态画路线图。作为一个常年跟移动端和嵌入式AI打交道的人我最大的感触是这桌“个人AI”的席面真摆开了而高通想当那个攒局的人。这篇文章我就从这次峰会传递出来的信号出发结合我自己的实践理解聊聊端侧AI Agent到底是怎么一回事为什么非要在手机里跑、硬件底座够不够、Agent在终端上是怎么“活”起来的以及开发者想入局会踩到哪些坎。1. 骁龙峰会变了味从跑分擂台到AI餐桌1.1 今年峰会的三个“反常”信号先说三个让我印象很深的反常点。第一往年发布会第三页一定是CPU性能对比图这次却换成了“NPU每瓦性能提升”的曲线。高通把AI算力效率放在了比峰值频率更靠前的位置这在以前不可想象——以前大家看的是功耗和帧率现在看的是“每瓦特能跑多少Token推理”。这背后其实是整个行业叙事在变移动端不再只是“能玩什么游戏”而是“能跑多大的模型、能多快地响应用户”。第二嘉宾名单里有不少深耕大模型应用层的创业者而不是传统手机厂商的高管。他们聊的不是“我们芯片多强”而是“个人AI”这个概念——每个人都能有自己专属的、随身携带的、越用越懂你的智能体。这类话在云端大模型大会上听多了不稀奇但放在骁龙峰会上意味着终端厂商开始认账光靠云端是不够的。第三高通专门给开发者讲了Agent开发框架和工具链。往年开发者会议基本是“如何调驱动、如何做功耗优化”这次直接教你怎么在骁龙平台上搭Agent、怎么做工具调用、怎么做记忆管理。这说明Agent生态已经进入了“能力基建”阶段不再只是Demo演示。1.2 “个人AI”这个词把行业叙事翻了个页“个人AI”为什么是个翻页式的叙事变化你可以回想一下过去两年大家说的AI默认是云端大模型你打开App输入问题服务器返回答案。这本质上是一个“公共AI”——所有人共享一堆大模型通过提示词做区分。但“个人AI”是完全不同的逻辑它得知道你几点下班、上周末跟谁吃了饭、手机里那些文件哪个是下周要用的、你惯用的口吻是什么。这些信息天然散落在你的手机、手表、车机里而不在云端的某个机房里。所以“个人AI”这个概念天然指向了端侧。这也是为什么这次峰会上高通反复强调“终端AI才是真正的个人AI”。不是说云端没用而是“个人化”这个属性决定了它必须有一部分跑在离你最近、拥有你最多私人数据的设备上。从这个角度看骁龙峰会确实变了味——它不再是手机芯片的发布会而是高通给整个移动生态下的一份“个人AI宣言书”。2. 个人AI为什么必须跑在终端上隐私、时延与算力账2.1 云端大模型解决不了的三件事总有人说手机端跑大模型是“为了跑而跑”云端便宜又强模型还大何苦在终端上折腾这种看法在2023年还算成立放到2025年就不太对了。至少有三件事是云端大模型天然解决不了的。第一是隐私。Agent比聊天机器人可怕得多因为它不仅“理解”你还能“做事”——读取你的日历、整理你的照片、帮你回消息。如果每一次操作都把个人数据传到云端用户心理上那一关过不去法理上更是麻烦。苹果和谷歌这几年反复强调端侧推理的隐私价值不只是在做消费卖点而是在处理一个真实的产品底线问题。第二是时延。你让Agent“帮我把昨天群里的那份文档总结一下然后发邮件给老王”如果这个链路是端侧采集数据—上传云端—云端处理—回传结果—再执行发送每一步都是几百毫秒加起来就是好几秒更别说网络抖动和排队。而端侧Agent完全可以做到本地处理完再决定要不要联网响应几乎是即时的。对于“边走路边跟助手对话”这种高频场景这个差距是体验级别的。第三是成本。Agent和普通聊天不同它的调用频率高很多——每次对话都可能带上下文记忆、需要多轮推理规划Tokens开销是普通问答的几十倍。如果全部跑云端对开发者来说每个活跃用户的推理成本会变成一笔巨款。哪怕大模型API已经降价降了几轮面对动辄百万级日活的应用账单依然烫手。端侧分摊一部分推理压力不是“技术理想”而是“商业算术”里的刚需。2.2 端侧AI的“甜点区间”在哪里当然也不是所有AI任务都必须跑端侧。以我现在的实践来看有一个比较合理的“甜点区间”参数量在7B以下、任务明确的模型摘要、分类、简单问答、意图识别端侧跑完全不吃力需要连续记忆和个性化上下文的Agent场景端侧做“本地记忆轻量推理”最合适需要海量知识或最新信息的任务写长文、复杂推理、实时新闻检索还是交给云端大模型稳妥。这也正好对应了这次峰会上一个很务实的判断端侧不是去替代云端而是跟云端做“混合编排”。离线、隐私、低时延、高频的部分留在本地重计算、深推理、大知识库的部分走云端。Agent要做的是当那个“路由中枢”知道哪个问题该问本地、哪个问题该上云。这个能力本身就是Agent智能化程度的一个体现。2.3 功耗和散热的现实约束聊完“为什么”再泼一盆冷水终端跑AI最痛的现实约束是散热和功耗不是算力。现在旗舰机的NPU跑个小模型瞬时算力足够但连续跑几分钟之后机身温度上去性能就开始回退。厂商在设计端侧Agent的时候最怕的不是“跑不动”而是“跑着跑着就热了、卡了、掉电了”。这也是为什么这次峰会上高通花了大量时间讲“能效”讲“每瓦性能”而不是一味堆峰值TOPS。对开发者来说这意味着你在设计Agent的推理策略时一定要考虑“节能模式”——什么时候调用本地小模型、什么时候唤醒云端大模型、什么时候只做规则匹配不推理这套策略写得聪明与否直接决定用户手机是“凉爽地工作”还是“发烫地死机”。3. 撑起Agent局的硬件底牌NPU、内存带宽与异构调度3.1 高通的AI硬件路线图从Hexagon到一体化AI计算要跑Agent光吹概念不够硬件得顶得上。高通在移动端做AI加速的历史其实很长当年的Hexagon DSP就是专门为低功耗持续处理设计的。这两年高通的思路变化明显不再把NPU当独立部件而是把它和CPU、GPU、内存子系统、传感器中枢做成一个“AI计算整体”。以现役旗舰骁龙8至尊版为例它的NPU支撑了端侧70亿参数模型的流畅运行。而这次峰会上释放的信号是下一代平台的AI底座还会继续加厚不仅仅是表面上的“TOPS数字变大了”更重要的是整套异构调度逻辑更成熟了哪个核跑视觉预处理、哪个核跑Tokenizer、哪个核跑Transformer层有一条完整的流水线在做分工。对做Agent的人来说这意味着你可以把更多模块往端侧卸不再只靠NPU硬扛所有推理。3.2 内存带宽才是端侧Agent的真实瓶颈很多人一谈跑大模型只盯着NPU算力其实大模型推理有个很硬的物理指标——内存带宽。为什么因为Transformer的推理过程是“权重密集”的模型每一层都要反复读取亿级参数算力再多带宽不给够数据搬不动算力只能闲着。这就是所谓的“内存墙”。当前旗舰手机的LPDDR5X带宽大概在100GB/s上下跑7B模型的时候每生成一个Token就要把模型的主要权重过一遍生成速度会被卡得很死。新一代平台升级到LPDDR6之后带宽如果能做到150GB/s以上7B模型的生成速度才会有质变Agent的“多轮对话体验”才能从“勉强能用”变成“日常可用”。这里也引申出一个开发层面的建议选推理模型的时候不要只比“谁准确率高”要比“谁在内存带宽约束下跑得最快”。有些模型在同参数量下对内存访问更友好比如结构更稀疏或者用了高效的注意力机制在端侧跑起来差距能拉到一倍以上。3.3 异构计算CPU/GPU/NPU怎么分活另外一个容易忽略的点是异构调度。现在的高通平台跑Agent不是“一个NPU干所有活”的简单模式。我见过的合理分工大致是这样的CPU负责Agent的逻辑编排、工具调用、状态管理这部分是串行的、充满分支判断的负载NPU反而不擅长GPU适合做并行度高的中间层计算比如大规模特征向量匹配、RAG检索里的向量相似度计算NPU专注做Transformer推理也就是模型本身的前向计算这是它的甜点区传感器中枢/低功耗核负责常驻的音频唤醒、姿态感知、简单意图预筛保证Agent随时在线但又不用满血启动。这样的分工逻辑决定了开发者不能把自己绑死在单一推理引擎上。高通的AI应用框架把这些底层调度封了一层又一层的API目的就是让你不用自己搓汇编能直接管任务级调度。但对开发者来说理解这套分工仍然很有必要——否则你写出来的Agent应用很可能会把一个本来该在传感器中枢做的常驻感知硬塞给NPU跑白白烧掉几倍的功耗。4. Agent在手机里如何“活”起来记忆、规划与工具调用4.1 端侧Agent的参考架构聊完了硬件说说更核心的软件层Agent在手机里到底是怎么“活”起来的。我见过不少团队第一次做端侧Agent习惯把云端Agent的逻辑整个搬下来结果又卡又烫。其实端侧Agent必须做架构上的“瘦身”。一个我目前认为比较合理的参考架构分四层感知层麦克风、屏幕内容、传感器、通知栏数据全部接入做轻量预处理记忆层向量数据库持续写入用户行为摘要和事实参数比如偏好设置并对旧记忆做衰减和归档规划层由端侧轻量模型做主决策决定“这个请求要不要联网、要不要调工具、要不要上云”流程多走ReAct那样简洁的“推理-行动-观察”循环执行层调用系统内的功能发消息、开应用、设提醒、读传感器以及外部的API查天气、订票、查快递。这种分层的好处是每一层都可以独立做功耗优化和降级策略。比如感知层可以用低功耗核心跑规划层只在需要时唤醒大模型执行层把耗时操作做成异步任务。比起云端Agent那种“一有输入就整模型上下文推理”的奢侈状态端侧Agent更像一个有“节能意识”的数字管家。4.2 Agent记忆的三层结构Agent比普通聊天机器人强的地方就是有记忆。而记忆在端侧绝对不能简单理解成“把聊天记录存下来”。我建议把所有记忆按三层拆工作记忆当前对话上下文或者是正在执行的任务状态。这一层占用少、更新快情景记忆最近几天的事件和交互记录比如“昨天下午用户改了两次会议时间”这部分由Agent自动摘要后存入本地向量库语义记忆用户长期偏好和客观事实比如“用户不喜欢喝咖啡只喝茶”“每周三下午有例会”这层是经过沉淀的高置信度信息也是个性化体验的基石。这里必须提一个做端侧Agent特别容易踩的坑记忆不是“越存越多越好”。手机不是云端存储空间和检索速度都有限如果向量库无节制膨胀每次检索都变慢还大量耗电。比较好的做法是定期做记忆“淘汰合并”——把低可信度的过期记忆丢掉把相关的高频记忆合并强化。这个策略跟人脑记忆的规律其实是反着想的人的遗忘不是系统缺陷而是资源管理机制。4.3 函数调用与系统级工具的打通Agent能“做事”靠的是工具调用。在云端环境工具就是API调起来很规整开发者把接口一发就完事。但在端侧工具的形态复杂太多可能是系统级的能力比如发送通知、打开应用、读取剪贴板也可以是应用内API以及跨应用的数据访问比如“把微信里老张发的那张图存到相册并命名为合同”。这也牵扯到Agent技术栈里经常被混淆的一对概念Harness和Agent的区别。Harness是那个“执行壳”它负责维护Agent运行时的循环、会话和工具上下文你可以把它理解成Agent坐的“座舱”而Agent本身更侧重于决策和推理它得靠Harness提供工具握把才能动手操作。开发端侧Agent时最容易出问题的是把Harness做得太重把每个工具都拉起一个完整流程导致响应链路过深、内存暴涨。我的建议是Harness尽量轻工具执行尽量走异步消息队列Agent的决策循环回传一个意图真正动手时再拉起更重的环境。系统级工具的打通同样依赖权限模型。手机上的权限比网页API敏感太多用户对“Agent替你发消息”这件事的容忍度是有限的Agent框架必须在每一次工具调用前做明确的意图确认而不是闷头执行。这个做不好产品上线之后光是隐私投诉就能淹没你。4.4 本地推理与云端大模型的混合编排端侧Agent还有一个核心设计点如何与云端大模型协同。完全离线运行的Agent聪明程度在很长一段时间内都拼不过云端大模型完全依赖云端的Agent又回到了“个人AI公共AI”的悖论。所以最务实的方案是“默认本地按需上云”。我来拆一下这个“按需”的判定逻辑我的经验是分三级简单指令“设个明天早上的闹钟”——本地小模型直接搞定不上云中等复杂度“把最近一周的照片分类整理去掉模糊的”——本地模型先跑主干必要时只把关键帧上传做语义分析高复杂度“写一份竞品分析报告对比我们和对方在功能覆盖上的差距”——整段交给云端大模型本地只负责提供背景记忆数据。这套混合编排策略做得好不好直接决定用户感知到的“聪不聪明”和“省电不稳”然后才是“具体功能好不好用”。你在跟用户炫耀Agent能写PPT之前先要保证它不是每件事都用“杀鸡儆猴”的方式调用云端模型。5. 开发者视角把Agent塞进骁龙平台的实操经验5.1 从模型选型开始谈参数量之前先谈用途每次有朋友问“骁龙平台跑Agent该选多大的模型”我第一反应永远不是报参数量而是反问一句你的Agent核心场景是什么如果是“语音唤醒简单对话”一个1B~3B的端侧小模型就足够了把这个模型做低功耗常驻比塞一个大模型更能提升体验如果要做“多模态输入理解”和“复杂记忆检索”那确实需要7B甚至更大一些的模型但你要接受它只能按需唤醒。用一个具体的比喻来总结我的选型经验如果你做的是一个每天要见十几次面的贴身管家那“在0.3秒内回话”比“用尽毕生所学回话”重要得多如果你做的是一个偶尔才使唤一次的战略顾问那回答质量就更不能妥协。定位决定模型大小模型大小决定硬件策略。5.2 端侧推理框架与量化方案的选型确定模型大小之后第二个坎是推理框架和量化精度。目前主流的做法有两条路一是用高通AI Hub提供的工具链把模型做转换、量化、部署好处是跟自家GPU、NPU适配度最好性能释放充分缺点是绑定在特定平台上迁移成本略高二是用跨平台的开源方案比如llama.cpp或ONNX Runtime Mobile好处是通用性强一张模型能跑遍安卓、Linux、甚至桌面端开发调试和生产运维都顺滑得多。量化上我的实操感受是4bit就是当前端侧的甜点位。2bit或3bit虽然能把模型压得更小但实际推理速度不一定变快因为量化太狠会导致部分层需要额外的反量化计算反而拖慢速度。如果你追求极致响应可以试“混合精度”——前几层用4bit关键的自注意力层保留更高精度这种折中方案在一些慢速手机上效果意外地好。5.3 并发与多Agent单机场景下的调度很多人听到“AI Agent并发”第一反应是上服务器集群做负载均衡。但在端侧并发的含义不太一样——手机没有成千上万的用户请求它面临的是“多个应用同时想用AI”的并发。典型场景你一边开着地图导航一边挂着一个会议转写助手同时后台还有个健康Agent在分析心率。如果这三个Agent各起各的模型实例显存内存带宽瞬间爆炸手机卡成PPT。我的建议是引入一个“端侧推理服务层”类似一个常驻的本地模型网关。所有Agent向这个网关请求推理网关负责排队、优先级调度和合并请求。比如转写助手是持续高优任务导航问答可以降级为“默认离线规则优先”健康分析干脆做成按批隔段时间集中推理一次。这套调度策略做好了就算同时跑三个Agent用户也不会觉得手机变卡——这比单独优化某一个Agent的性能更重要。5.4 我踩过的几个坑最后照例分享几个我在这个方向上踩过的实际坑都是文档上不太会写的经验第一个坑是“NPU常驻”陷阱。刚开始做端侧Agent的时候为了响应快我让NPU常驻等待推理任务结果待机功耗直接干到了500mW以上手机半天就没电。正确做法是让Agent的常驻感知走CPU的低功耗核心一旦检测到明确的交互意图再快速唤醒NPU。从“常驻NPU”改成“按需唤醒NPU”之后待机功耗降到了十分之一以下。第二个坑是“向量库膨胀”失控。早期设计记忆系统我说“所有用户数据都存进向量库”结果跑了一个月记忆库有几十万条向量每次检索都得扫一遍响应时间从200ms涨到1.5秒体验崩盘。后来我把记忆策略改成“摘要优先、过期删除、每周合并”库容控制住了检索速度也回来了。端侧应用内存宝贵记忆不是一个“多多益善”的玩意儿管理策略才是核心。第三个坑是“函数调用陷阱”。我第一版工具调用直接复用云端的HTTP式函数调用逻辑每个工具都做一个网络请求结果发现手机端很多工具根本没有网络延迟倒是“拉起应用-读写数据-返回结果”这个链路慢。系统级工具调用应该走本地AIDL或Binder而不是模仿云端API设计。同样是“打开日历写日程”本地调用比HTTP式调用快了近十倍而且不消耗流量。6. 这一桌席能开多久生态拼图与商业化现实6.1 高通的“攒局”策略芯片、工具链、行业联盟回到这次峰会的主题高通为什么这么高调地攒Agent局表面看是在推新一代芯片实际上是在做一个平台生态的卡位。单纯卖芯片的生意有天花板而Agent生态是未来十年最重要的增量空间谁掌握了终端AI的入口谁就掌握了下一个移动时代的“收租位”。所以高通的策略很清楚芯片硬件底座 开发套件软件工具链 行业联盟跟手机厂、车厂、IoT厂商一起定义参考设计。这不是单点突破的思路而是平台型打法。对开发者来说好消息是你会得到更完整的工具链支持不用自己拼装坏消息是如果你把核心能力绑在单一平台上未来的迁移成本会非常可观。所以我的建议是在技术选型时尽量抽象一层“模型无关、框架无关、尽量跨平台”的Agent中间层。跟随高通的工具链快速落地但核心逻辑不要跟特定平台锁死给自己留条后路。6.2 与竞争对手的差异点高通的Agent局跟别的玩家的打法确实不太一样。苹果更倾向于“系统内置闭门造车”体验极强但开发者空间有限谷歌则是“云端模型Android底层能力”双轮驱动但端侧跟云端的边界相对模糊而高通做的是“顶配硬件基座开放工具链终端生态放飞”它不直接提供用户端应用而是让所有手机厂商和开发者在这个底座上各自出菜。这个站位在我看来是有机会的因为不是所有厂商都愿意被苹果那种封闭生态圈住也不是所有厂商都能接受谷歌的云端依赖。高通的方案把选择权交回给每一家终端厂商和开发者自己只做“水电煤”。这既是一种技术路线也是一种商业姿态。6.3 真正的难题开发者怎么从中赚到钱最后说一个最现实的问题Agent赛道技术热闹但商业化路径还不清晰。目前能看到的方向有几类一是做高阶订阅服务把随身AI助理做成会员制产品二是做垂直场景的Agent比如“医疗记录整理助手”“会议纪要日程规划联动助手”在企业服务里找到付费意愿三是做赋能型平台你自己不直接服务用户而是把Agent能力做成SDK卖给有流量的应用方。我个人的体会是端侧Agent在消费端的付费意愿还处于培育期“好用”到“愿意付钱”之间还有一段很长的用户教育距离。更现实的市场反而不是普通用户而是那些已经有垂直场景流量、需要靠AI提升粘性和转化率的行业应用。谁能在某个细分场景里把Agent做到“离不开、可量化价值、愿意续费”谁就真正撬动了这盘棋。另外Agent的安全问题也会持续是绕不开的课题。端侧Agent拿到了大量权限一旦框架有漏洞被恶意代码诱导去做危险操作比如调用支付接口、发恶意短信后果比“AI胡说八道”严重得多。开发者做Agent的第一职责就是把工具权限卡死把沙箱边界做严。任何试图“先用起来再说安全”的思路都是给自己埋雷。冒着温度边界的风险说了这么多其实我最想表达的一句话是高通的这个局本质上是把过去几年飘在云端大模型概念里的AI以“个人AI”的名义拉回到了用户的掌心里。对开发者来说技术工具的底座已经比两年前成熟太多拼的更多是对场景的理解、对功耗的克制、对安全边界的敬畏。我这一年多踩坑下来的体会是端侧Agent不拼花哨拼“在有限资源里做对的事”。谁先把那个“小事做得极顺手、大事知道该问谁”的数字管家立起来谁就能在下一波终端智能浪潮里站稳脚跟。