企业官网建设流程全解析

说实话，今年骁龙峰会给我的感觉，跟往年完全不是一回事。以前是跑分墙前挤满人，芯片参数一拍，大家热闹一天就散了。这次不一样，整个场子都在谈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必须做架构上的“瘦身”。

一个我目前认为比较合理的参考架构分四层：

1. 感知层：麦克风、屏幕内容、传感器、通知栏数据，全部接入做轻量预处理；
2. 记忆层：向量数据库持续写入用户行为摘要和事实参数（比如偏好设置），并对旧记忆做衰减和归档；
3. 规划层：由端侧轻量模型做主决策，决定“这个请求要不要联网、要不要调工具、要不要上云”，流程多走ReAct那样简洁的“推理-行动-观察”循环；
4. 执行层：调用系统内的功能（发消息、开应用、设提醒、读传感器），以及外部的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不拼花哨，拼“在有限资源里做对的事”。谁先把那个“小事做得极顺手、大事知道该问谁”的数字管家立起来，谁就能在下一波终端智能浪潮里站稳脚跟。