骁龙峰会的第三天，我坐在媒体间里，感觉今年最热闹的其实不是参数墙，而是“个人AI”这四个字。高通在主题演讲里反复提Agent，整个会场的话题立刻变了：大家不再只问“新一代骁龙芯片NPU多了多少TOPS”，而是问“这模型能不能在手机本地自己调用工具、把事情办了”。这意味着端侧AI终于从“能聊天、能画图”走到了“能干活”的阶段。这篇文章不打算替高通复述发布会，我想结合我自己做端侧推理和Agent开发的经验，拆一拆高通这局Agent到底怎么攒的，以及普通开发者和数码玩家能从这张餐桌上分到什么。
如果你正在做AI应用、Agent产品，或者只是好奇手机里的AI助手下一步会变成什么样，这篇内容应该能省下不少自己摸索的功夫。
1. 个人AI开席，为什么偏偏在骁龙这张桌子上
1.1 端侧大模型的三个前提：带宽、功耗、隐私
“个人AI”这个概念喊了很多年，之前一直没落地，卡住的不是算法，而是硬件。一个大语言模型要能在手机本地流畅跑，首先内存带宽要够。模型每生成一个Token，都要把权重从头到尾读一遍，如果你的内存带宽只有几十GB/s，7B模型出字就会慢到没法用。高通这几代骁龙平台一直在堆LPDDR带宽，本质就是在解决这个“喂数据喂不饱”的问题。
第二是功耗。云端的AI烧的是数据中心的电，端侧AI烧的是手机电池。以前跑个本地大模型掉电极快，机身温度能煎蛋，那就不可能成为日常功能。高通在NPU、CPU、GPU之间做异构调度，目的就是把每一瓦算力用到极致。实测下来，端侧跑一个压缩后的模型，发热和玩中型游戏差不多，这才是能“开席”的前提。
第三也是最关键的：隐私。个人AI如果什么都传到云端，那就不是“个人”了。真正的个人助手要读你的日程、短信、相册、位置，这些敏感数据如果全走服务器，任何厂商都扛不住责任。数据留在本地，模型在本地推理，只在必要时用脱敏的方式调用云服务，这才是“个人AI开席”的完整逻辑。所以端侧大模型不是简单把模型文件塞进手机，它其实是隐私架构上的一次主动选择。
1.2 个人AI不等于云端AI套壳
很多朋友容易把个人AI和“手机里装了一个App连ChatGPT”混为一谈。差别很大。云端AI套壳本质是个客户端，发文字过去，等服务器回话，遇到断网就变智障，而且服务器根本不知道你是谁。个人AI应该是这样一套东西：它在你的设备上有一个轻量的模型常驻，能理解你的上下文，能调用你手机里的工具，能在不把隐私送出去的情况下完成大部分任务。
我用一个通俗类比：云端AI是“你打电话给客服中心”，每次都要重新报工单号。个人AI是“你雇了一个住在家里的助理”，他知道你几点出门、喜欢吃什么、上次聊到哪，很多事不用重复讲。
所以高通的Agent局，并不只是让模型能跑，而是让模型能“住在”设备里。这需要常驻内存管理、低功耗唤醒、工具调用接口一整套配合。如果只是云AI套壳，那么芯片再强也只是个瘦客户端，谈不上“个人”。
1.3 高通这次放出的信号：AI不再是跑分，而是工作流
这次峰会最明显的一个变化，是把AI的讨论从“三大件”跑分挪到了“工作流”。台上演示的Agent，能在一个对话里完成查航班、订餐厅、安排行程的整套动作；操作手机时，Agent能理解当前的屏幕内容，点击对应按钮，像真人一样替你把流程走完。
这背后其实是一个行业转向：大模型参数差不多碰顶了，再往上堆参数，边际收益越来越低，大家开始比“模型能不能干活”。干活就需要工具调用、环境理解、任务规划，而这些能力恰恰需要和本地系统深度绑定。高通做芯片、做系统接口、做模型适配，正好卡在这个环节上。你可以把这次发布会理解成：骁龙不再是“跑分王”，而开始强调“工作流完成率”。
对开发者来说，这意味着以后做AI产品不能只调API，还要认真研究设备端的系统能力。谁先把手机里那些屏幕、通知、传感器、应用接口管好，谁就能把Agent做得真正顺手。
2. 高通攒的Agent局：从芯片到工具链的完整闭环
2.1 底层算力：TOPS只是入场券
先聊算力。很多文章喜欢拿“多少TOPS”说事，但TOPS只是理论峰值。真正决定Agent体验的是NPU在真实负载下的吞吐和时延，以及和CPU、GPU之间的数据搬运效率。高通的Hexagon NPU经过这几代演进，对Transformer类的算子做了专门优化，尤其擅长处理低精度量化模型。我实测过同一份INT4量化模型在几款平台上的表现，新骁龙平台的解码速度明显比上一代更平滑，而不是只在宣传页上好看。
但算力只是入场券。Agent需要长时间运行，它不像单次推理那样跑一个生成任务就结束，而是持续感知环境、维护记忆、执行工具调用。这就要求整个SoC的电源管理和调度策略能跟上。高通强调“always-on AI”，就是在解决这个问题：让一个小模型低功耗地驻留在NPU里，听到唤醒词或被某个事件触发时才拉起来干活。这个能力比单纯堆TOPS难得多。
2.2 模型供给：AI Hub和本地模型库解决“没模型可用”的尴尬
做端侧Agent最头疼的不是芯片，而是模型。很多开源模型是为服务器设计的，动辄几十GB，根本没法往手机里塞。高通做了一件很实际的事：把主流开源模型做了量化、蒸馏、适配之后，整理成可以直接下载的模型包，放在AI Hub这类渠道里。
我在项目里试过用高通适配过的Llama 3、Phi系列模型。体验下来，最大的感受是“省时间”。你不需要自己研究怎么转ONNX、怎么处理动态Shape、怎么调NPU算子，下载下来就能在骁龙设备上跑通。这对中小开发者和个人项目非常友好。
更关键的是，这些模型包里还集成了针对高通的定制算子。模型转换最怕某些算子没有NPU实现，结果只能退回CPU，速度一下就崩了。高通的模型库会标清楚哪些算子已适配、哪些会回落，开发者可以一眼看出性能瓶颈。这比自己去啃文档强多了。
2.3 系统插桩：Agent如何真正操控手机
Agent要“干活”，就不能只躲在对话框里。它需要读屏幕、点按钮、拉通知、查位置、调应用。高通的Agent局里，很重要的一张牌就是系统级的工具调用接口。你可以理解为：他们给Agent提供了“手”和“眼”。
我之前做过一个自动整理会议记录的Agent，难点不在于写Prompt，而在于怎么拿到麦克风录音、怎么读日历、怎么生成纪要后再自动发进便签。这些动作都需要操作系统开放接口。高通现在做的，是在Android系统层把AIDL接口、感知模块、应用交互协议串起来，让Agent能以授权的形式访问系统能力。这很接近“给Agent装了一套API”。
要注意的是，这种能力天然是双刃剑。权限越大，安全问题越严重。我自己的经验是，工具调用接口一定要做成“最小权限”和“人类确认”两个机制。Agent可以建议操作，但关键步骤必须弹窗让用户确认。否则一个Prompt注入就可能把你的相册翻得底朝天，这个后面细说。
2.4 生态协同：手机、PC、汽车、穿戴的一盘棋
单看手机，Agent还只是“个人助理”。高通的野心明显更大：骁龙平台覆盖手机、PC、平板、汽车座舱和智能穿戴，Agent在这个生态里是可以“分身”的。早上你用手表听通知，在车里让车机帮你导航，坐到电脑前让PC帮你整理文件，同一套Agent心智可以无缝迁移。
这个协同靠什么实现？靠一套统一的端侧AI框架和账号体系。模型可以在不同设备间流转，设备本地的记忆库可以同步。比如手机上学到你的通勤习惯，车机就能直接给出更准的预期。这等于把“个人AI”从单点功能变成了跨设备的一张大网。对开发者来说，以后Agent的部署目标不再只是手机，而是一整个异构设备矩阵。
不过跨设备也是目前最不成熟的部分。端侧模型在不同硬件上能力有差异，同步协议也还没有统一标准。所以这块我建议先关注手机和PC的组合，这两者使用率高、交互深，Agent价值最明显。
3. 开发者实战：如何把一个Agent跑在骁龙平台上
3.1 模型选型和轻量化：算好内存与功耗这笔账
真上手做端侧Agent，第一件事不是写代码，而是选模型。你需要在自己能接受的内存、功耗条件下，找到能力够用的模型。
我给出一个实际计算逻辑：假设你选了一个7B模型，用INT4量化，每个参数占0.5字节，那光权重就是约3.5GB。再加上推理过程的KV Cache、临时激活值、系统预留，整机空闲内存至少要有6GB才能跑得舒服。如果你的目标设备是8GB内存的手机，那模型加载后基本不能再开什么大应用。所以很多端侧Agent会选择把常驻模型体积控制在1GB以内，也就是2B-4B级别的量化模型。
选型的时候不要只看模型参数，还要看任务的复杂度。我的习惯是：意图理解和工具调用用一个小模型，比如3B；遇到实在搞不定的复杂逻辑，再通过路由把局部任务丢给云端大模型。这种“端云协同”既保留了端侧的隐私和响应速度，又利用了云端的强推理能力。别指望一个本地小模型事事都干，那不现实。
3.2 推理引擎和API选型：QNN、ONNX还是自研算子
在骁龙平台上跑模型，推理引擎的选型直接影响速度。高通的QNN（Qualcomm Neural Network）是官方路径，对自家NPU支持最到位。如果你手里的模型转换顺利，QNN能把绝大多数关键算子扔到NPU上执行，速度提升非常明显。
但也别迷信官方引擎。之前我在一个项目里把Whisper语音模型转成QNN格式，结果部分算子不兼容，被迫回退到CPU，实时率还不如直接用ONNX Runtime跑。所以我的建议是：先用ONNX Runtime加QNN EP这套组合做快速验证，如果性能不够，再针对具体模型做手工算子替换或模型结构调整。
另外一个容易忽略的坑是Dynamic Shape。端侧Agent的输入长度是不固定的，很多推理引擎在动态Shape下会频繁重新构图，导致严重延迟。解决办法是固定推理长度或做padding，把模型输入Shape固定到某一档位，比如512、1024、2048。虽然会增加一点计算量，但换来的是稳定的延迟，对Agent这种交互式应用来说非常值得。
3.3 Agent逻辑的端侧重构：感知、规划、执行的闭环
一个能落地的端侧Agent，不能只是“模型 + 工具调用”，而是一个完整的循环。我是按感知、规划、执行、记忆四块来拆的。
感知负责把设备上的信号转成模型能理解的文本。屏幕上显示的界面、收到的通知、传感器数据，都要经过一个提取和结构化过程，变成上下文。规划是Agent的核心，根据当前目标和历史记忆，生成下一步动作序列。执行则调用系统接口和应用API完成动作，比如打开应用、点击按钮、发送消息。记忆负责把每次交互的关键信息存到本地，可以是向量数据库，也可以是简单的键值存储，便于下次直接匹配。
这个架构里，最容易出问题的是上下文管理。端侧模型上下文窗口有限，你不能把整段历史都塞进去。我常用的策略是做“摘要 + 关键事件抽取”。对话超过一定长度，就把历史总结成几条状态，再把最近的几轮原始消息保留下来。这样既保住了Agent的“记忆”，又不会把模型窗口撑爆。
3.4 隐私与权限：个人AI的边界怎么划
做个人AI，想清楚边界比想清楚功能更重要。我的原则很简单：能本地不云端，能“脱敏”不“裸奔”，能“确认”不“自动”。Agent在访问相册、通讯录、位置这类敏感信息前，必须经过用户授权，并且每次工具调用都要在界面上展示出来，让用户知道Agent正在干什么。这个不光是合规需求，更是产品信任度的问题。用户敢不敢长期把Agent当私人助理，取决于他有没有掌控感。
实操上，我建议把权限设计成三层：顶层是通用工具，比如查天气、算算术；中间层是设备数据，比如读日历、读通知；底层是隐私敏感数据，比如相册和通讯录。只有核心任务才触达底层，而且必须弹窗重复确认。你甚至可以给Agent设定“禁区”，比如某些App内容永远不允许Agent读取，这样从机制上防住误操作和Prompt注入。
4. 实测体验与避坑指南：我踩过的Agent开发坑
4.1 端侧设备上的实际表现：从加载到连续对话
我拿一块骁龙8系平台开发板做了个简单测试，跑一个3B量级模型，挂上工具调用框架，模拟“帮我查天气并生成行程提醒”的任务。模型冷启动加载花了大概2秒，之后每生成一个字大约需要20-40毫秒，体感上比线上聊天稍慢，但完全可以接受。连续对话到第十轮左右，机身温度从室温升到接近40度，没有明显卡顿，但继续跑下去电源调度会开始限制NPU频率，速度会有所下降。这个表现说明，日常任务级别的端侧Agent已经可用，但如果你要跑更重的模型，还是需要外置散热或选择性能更强的骁龙平台。
我还对比了启用NPU和不启用NPU的差异：纯CPU推理的延迟几乎是NPU的3倍以上，功耗也高不少。所以想让Agent“住”在端侧，确定走NPU路线是非常必要的。不要偷懒直接调CPU，那样体验根本撑不过三句话。
4.2 典型问题排查：模型加载慢、算子转换失败、乱调用工具
踩坑是常态，这里挑几个我遇到过的典型问题。
第一个是模型加载时间太长。原因是每次启动Agent都要把几个GB的权重读进内存，如果是首次冷启动，系统还会做文件缓存预热。我这边用了一个懒加载方案：App启动时不加载模型，用户真正开口或点下按钮时才初始化，把第一次响应的时间摊到用户预期里，体感会好很多。同时，尽量复用进程，不要让重复创建Agent实例。
第二个是QNN算子转换失败。最常见的原因是模型里有某些不标准算子，比如一些新出的Attention变体。我的经验是先看转换日志里列出了哪些“fallback to CPU”，如果关键层都在CPU上跑，那这模型就不适合直接上NPU。这时候要么换一个结构更标准的开源模型，要么自己导出时把特殊算子拆成基础算子组合。
第三个是Agent乱调用工具。有一次它看到用户的日历上有“部门会议”，自作主张把会议内容包括文件名都读了一遍，并生成了一份摘要。虽然技术上没出错，但这不是用户想要的。事后排查，是工具描述里权限写得过于宽泛，模型误以为“查看日历”和“读取所有详情”是合理动作。后来我把工具描述改成“仅返回会议标题和开始时间，不读取内容”，问题就解决了。所以工具描述一定要写得具体，给模型划死边界，不然它会在你意料之外的地方自由发挥。
4.3 几条独家实操心得
如果只让我分享三条心得，我会说这三条。
第一，状态全部外置。不要指望模型自己记得你的业务状态，把用户ID、任务进度、当前上下文用外部存储管理起来。模型只是“大脑”，不是“记忆体”。我每次做Agent都会先设计一个本地状态机，把“Agent现在在哪一步、下一步可能做什么”固定住，再让模型在状态机里选路，而不是自由发挥。
第二，工具描述要像写API文档一样写。模型调用工具靠的是描述文本理解功能，你写得越精确，误用的概率越低。我甚至试过在描述里加入一些“负面提示”，比如“此工具只能用于查询今天天气，禁止读取其他日期数据”，效果很显著。
第三，一定要做“失败回复”。端侧Agent经常因为模型能力不足或接口报错导致任务中断，如果没有任何兜底文案，用户会认为产品坏了。我习惯在工具调用异常时，输出一句“我暂时做不了这件事，要不要我换个方式试试”，然后把现场日志追加进记忆，方便用户重复操作时给Agent更多参考。
这里可以放一个常见问题速查表：
| 问题 | 原因 | 建议 |
|---|---|---|
| 模型加载太慢 | 冷启动读权重、IO未优化 | 懒加载、复用进程、预缓存 |
| NPU速度不升反降 | 算子回退到CPU | 检查转换日志，换合适模型或拆算子 |
| Agent乱读取信息 | 工具权限描述过宽 | 收紧描述、最小授权、加负面提示 |
| 上下文过长丢重点 | 窗口被占满 | 摘要+关键事件抽取，外部存储状态 |
| 连续对话后变慢 | 温控触发降频 | 降低模型负载，增强散热，适当暂停长任务 |
我在实际项目里最深的一个体会是：个人AI这个局，最后拼的不是谁的底座最大、谁的模型最能聊，而是谁能在设备端把“干活”这两个字做扎实。高通这波Agent布局，把芯片、模型、系统接口、开发工具串到了一张桌上，接下来就是开发者们各显神通的时候了。如果你手头有一块骁龙平台的设备，与其继续刷跑分，不如直接从一个小场景开始：让端侧模型读一条通知、回一段话、帮你点一次屏幕。能跑通一个闭环，你就算真正入局了。
