核心要点
内存是能力红线:端侧 Agent 要同时驻留本地模型权重、KV cache 与多应用上下文,内存容量直接决定能力档位——12GB 这类门槛是功能划分线,不是营销参数。
芯片选型看三件事:NPU 峰值算力决定突发推理,内存带宽决定解码瓶颈,调度隔离决定 Agent 能否与前台应用共存;常驻感知适合专用低功耗核,突发规划才用主 NPU。
端云卸载是路由问题:低延迟与隐私敏感任务留在端侧,知识密集与长生成任务上云,决策变量是延迟预算、隐私边界、网络状态与单次成本,且必须有云端失效的本地降级路径。
系统集成定义上限:跨应用授权、可审计动作链与敏感操作确认必须在 OS 层内置;OEM 的芯片+商店+助手闭环是架构约束,第三方 Agent 要按权限面收窄的假设做设计。
简要回答
端侧 Agent 的硬件设计从内存门槛开始:跨应用多步任务要求本地模型权重、KV cache 与多应用上下文同时驻留,内存容量直接划出能力档位。在此之上按负载特性决定 NPU 与通用核的分工,按延迟—隐私—成本把任务路由到端侧或云端卸载,最后用系统级权限、审计与降级策略收口。硬件规格表本质是功能清单,这也是 OEM 生态锁定的核心逻辑。
标准回答
一、内存门槛:为什么 RAM 决定 Agent 能力档位
端侧 Agent 的内存占用与单轮对话模型有本质区别。第一,本地模型权重与 KV cache 必须常驻——Agent 是长期运行的后台服务,不能每次调用都重新加载。第二,多应用上下文要同时保持:一个跨应用任务(从消息提取航班信息、写入日历、规划路线)需要读取多个应用的屏幕内容与状态,中间态全部驻留内存。第三,与 OS 和前台应用共存:手机内存优先保障前台体验,Agent 能拿到的是剩余配额。
三层叠加使内存容量成为能力的阶跃函数:低于门槛,Agent 要么整体不可用,要么大幅降级(单应用、短上下文、频繁卸载上云)。Google 把 12GB 划为 Gemini Intelligence 的门槛(Pixel 11 世代,部分上代机型不满足),本质是把内存从硬件参数变成功能开关——硬件规格表直接成为功能清单。
二、芯片选型:NPU 与通用核的分工
端侧 Agent 的计算负载可拆成四类,各适合不同硬件。常驻感知(屏幕理解、唤醒、意图检测):低功耗高频次,适合专用低功耗核而非主 NPU;Tensor G6 宣称浏览器性能 +25%、应用启动 +15%(官方口径,provisional),靠的是芯片级调度优化。突发规划与生成(任务分解、长文本生成):计算密集,需要 NPU 峰值算力,但受散热与降频约束,持续性能比纸面 TOPS 更重要。上下文处理(读取并结构化多应用内容):访存密集,解码阶段瓶颈在内存带宽而非算力。敏感数据处理:应在隔离执行环境(TEE/安全区)内完成,避免明文经过通用核。
选型判据不是「谁的 TOPS 高」,而是三个问题:峰值算力能否持续(散热设计)、内存带宽是否匹配模型尺寸、调度器能否保证 Agent 任务不抢占前台资源。
三、端云卸载:上下文本地与计算上云的决策矩阵
端侧不等于全本地,现实架构是端云混合路由器,决策变量四个:延迟预算(毫秒级意图识别必须本地)、隐私边界(屏幕内容与通信数据优先不出端,减少上传面)、网络状态(弱网与离线场景必须有本地降级能力)、成本(高频小任务端侧零边际成本,低频复杂任务上云比塞更大的端侧模型更划算)。
工程落地还要补两条:一是决策透明,用户能感知哪些数据上了云;二是降级路径,云端失效时本地保留最小可用功能(单应用任务),而不是整体瘫痪。Pixel 11 的路线是本地 Gemini Nano v3 处理轻任务、云端 Gemini 处理重任务(多源交叉,provisional)。
四、权限与隐私边界:系统级集成的信任设计
跨应用 Agent 本质是获得「替用户操作手机」的特权,权限模型必须严于普通应用:最小权限加逐应用授权,Agent 对每个应用的访问应可单独授权与撤销;动作链可审计,每次跨应用操作可回放——哪个意图、读了什么、写了什么;敏感操作确认,支付、发送、删除类不可逆动作需人工确认。
隐私边界与端云决策互相咬合:如果 Agent 必须把屏幕内容上传云端才能理解,隐私承诺即告失效,所以系统级语义理解要尽量在端侧完成——这反过来解释了内存门槛为什么必须抬高:隐私能力是用内存买来的。
五、OEM 生态锁定:业务结构如何塑造架构
端侧 Agent 天然是生态业务:自研芯片控制能力上限与物料成本,自有商店控制应用集成接口与分成,系统助手占据用户入口,三者构成闭环——Google 的 Tensor G6 加 Play 生态加 Gemini Intelligence 就是样板。
架构含义有两层。对平台方:闭环缺任何一环,Agent 架构都建在别人的地基上,OEM 想自研端侧 Agent 要先回答三件套是否齐备。对第三方 Agent:拿不到自研芯片与商店,只能获得 OS 层的次级权限,设计必须假设权限面随时间收窄,核心价值不能构建在脆弱权限上。
常见误区
误区一:把内存门槛当营销参数。12GB 不是规格竞赛,而是 Agent 三层内存占用(模型权重、KV cache、多应用上下文)的真实阶跃函数:低于门槛,功能直接缺失或大幅降级。判断「设备能否跑 Agent」要看内存账本与能力集的对应关系,而不是跑分。
误区二:芯片选型只看 TOPS。解码阶段的瓶颈是内存带宽而非峰值算力,持续性能还受散热约束;TOPS 高但带宽不足或散热差的芯片,Agent 实际体验反而更差。常驻感知类负载还依赖专用低功耗核,不是主 NPU 的活。
误区三:把端侧 Agent 等同于「不上云」。现实架构是端云路由:毫秒级意图识别与隐私数据处理留在端侧,知识密集与长生成任务上云。以「纯本地」为设计目标,要么塞入过大模型导致发热降频,要么为隐私牺牲全部能力,两头皆输。
误区四:把权限模型当应用层问题。跨应用 Agent 持有的是系统级特权,逐应用授权、动作审计、敏感操作确认必须内置在 OS 层,靠单个应用自律等于把钥匙放门口地垫下。隐私承诺还与端云边界咬合:屏幕内容要上云才能理解时,「端侧」就名存实亡。
追问
追问 1:如果让你为下一代手机 Agent 制定内存门槛,你会怎么论证 12GB 这类数字的合理性?
用账本拆解法:先枚举目标能力集的并发组成——模型权重乘以量化位宽、KV cache 乘以平均上下文长度、多应用上下文槽位数、OS 与前台预留——算出 P95 内存峰值,再为后台回收与碎片预留 15-20% 余量,得出门槛数字。然后反向验证:低于门槛的设备要给出明确的降级清单——砍掉哪些功能、保留哪些,而不是模糊的「体验下降」。12GB 这类数字的合理性不在于数值本身,而在于它对应一个明确的能力集(如 40+ 应用多步任务)。如果账本拆不出来、降级清单写不出来,那门槛就只是营销话术而非工程决策,面试里要敢于指出这一点。
追问 2:没有自研芯片和应用商店的第三方 Agent 想做端侧 Agent,架构上的突破口在哪里?
追问 3:OEM 生态锁定对第三方应用开发者意味着什么?应用该如何适配 Agent 时代?
应用的角色从「用户直接使用的产品」变成「Agent 可调用的服务」,要在三层做准备。接口层:向 Agent 暴露结构化能力——意图声明、标准化动作、结果协议,而不是等着被 GUI 模拟操作;被模拟意味着数据流与转化归因都不在自己手里。商业层:当 Agent 代替用户完成下单订票等决策入口,应用的品牌曝光与变现位被前移挤压,需要尽早与平台谈新的分成与展示机制。风险层:依赖单一 OEM 的 Agent 接口是新型平台锁定,跨平台 Agent 协议一旦成熟就是对冲手段。判断标准是核心交易发生在应用内的占比——占比越高,Agent 入口迁移的冲击越大。
🔗 相似问题
同一考点的不同问法,换着练更稳
- 高级AI 工程化
设计一个 AI Gateway:支持多模型路由、降级与成本优化
- 高级AI 工程化
如何设计一个企业级 LLM 问答 / 客服机器人?
- 高级AI 工程化
如何设计一个内容审核(Content Moderation)系统?
- 高级AI 工程化
全双工多模态模型的三条技术路线(SeedRealtime / FLUX 3 / MAI Realtime)有何架构差异,分别解决什么工程问题?
- 高级AI Agent
Agent 接入多渠道(Telegram/飞书/钉钉/Web)时,Channel 抽象层如何设计?
- 高级AI Agent
为什么要把 Context 管理抽象成可插拔的 Context Engine?能支持哪些策略?
延伸学习
按主题分类的相关资源,便于系统复习
