企业官网建设流程全解析

AutoGLM 手机 Agent 跑在端侧 AI 芯片上，很多人第一反应是“能跑不就行了”，但真上手做应用适配评估就会发现，这事远不是装个模型、跑个 demo 那么简单。屏幕理解、操作序列生成、跨应用跳转、连续多步执行，每一环都压在芯片的算力、内存带宽、功耗和算子支持上。这篇文章把我这次基于 AutoGLM 手机 Agent 场景做 AI 芯片应用适配评估的思路、指标体系、实操流程和踩过的坑完整梳理一遍，给准备做端侧 Agent 落地或芯片选型的团队做一个参考。

1. 项目背景与评估目标

1.1 AutoGLM 手机 Agent 的核心能力拆解

AutoGLM 不是一个普通的语音助手或单任务自动化脚本，它是一个能“看懂”手机屏幕、能“操作”手机应用的智能体。用户给出一个自然语言指令，比如“帮我把相册里最近三张照片拼成九宫格发到朋友圈”，AutoGLM 需要自己完成相册的打开、图片筛选、拼图工具的调用、文案填写、发布确认这一整条链路。

从技术角度看，这条链路内部包括了三个关键模块。视觉感知模块负责从屏幕截图里解析出 UI 元素、控件位置和操作焦点；决策规划模块把用户指令拆分成一串可执行的操作序列，比如点哪里、滑动多远、输入什么文本；执行控制模块把规划好的操作映射成系统级手势事件，并且在每一步执行后重新截图验证结果。这三个模块如果全部在云端处理，端侧只负责回传截图和接收指令，对芯片的要求不高，但时延高、隐私风险大、断网即失效。而这次评估的核心方向，是把整条链路中的推理部分尽可能放到端侧 AI 芯片上。

1.2 为什么端侧 AI 芯片适配是绕不开的命题

手机 Agent 的体验瓶颈几乎都集中在“每一步操作的等待时间”上。用户发出指令后，Agent 每完成一次“截图—理解—决策—执行”循环，都要产生一次可感知的时延。如果这个循环里的视觉模型和规划模型运行在云端，单次往返的网络开销通常在 300 到 800 毫秒，再加上服务端排队，整个任务可能要几十秒才能完成，用户早就没有耐心了。

端侧推理的优势就在这里。把经过量化的视觉模型和规划模型部署到手机 NPU 上，截图后直接在本地完成 UI 解析和操作生成，单步循环时延可以压缩到 1 到 2 秒以内，而且在飞行模式和弱网环境下依然可用。更实际的意义在于隐私：屏幕截图里经常含有聊天记录、验证码、银行卡号等信息，这些数据不出设备，对用户和厂商都是更稳妥的方案。

1.3 本次评估的目标与边界

我们这次评估不是做一个完整可发布的产品，而是回答三个问题：第一，AutoGLM 的核心推理模型在端侧芯片上能不能跑、能跑到什么精度；第二，在“连续多步操作、长时间运行”的真实场景下，芯片的算力和功耗能不能顶住；第三，如果要做产品化，芯片平台选择上有哪些必须关注的指标。围绕这三个问题，我们搭建了一套评测流程，覆盖单模型基准测试、端到端任务测试、持续压力测试三个层次，最终的结论用于指导后续端侧方案选型和模型裁剪方向。

这个边界很重要，因为很多人一开始就把“芯片适配评估”等同于“跑个 benchmark 看分数”，这是不够的。Agent 场景的特点是每一步推理之间强耦合，前一步的输出会直接影响后一步的输入，芯片不仅要快，还要稳，这个“稳”字恰恰是 benchmark 体现不出来的。

2. 评估框架与核心指标体系

2.1 用“任务完成率”代替单点跑分

做芯片适配评估，传统的做法是先跑通用模型，看算力、看时延、看内存带宽，觉得数据不错就认为适配完成了。但手机 Agent 场景有一个特殊的复杂性：模型推理只是整个链路里的一环，UI 解析的准确率、操作序列生成的合理性和执行环境的稳定性，共同决定了用户最终能不能拿到想要的结果。

所以我们把“端到端任务完成率”设为第一指标。具体做法是准备一组标准任务集，覆盖系统设置、社交应用、购物应用、地图导航等常见场景，每个任务包含 5 到 20 步不等的操作链路。评估时全自动执行，Agent 每一步的操作结果都会被记录下来，完成后由人工复核是否达到目标。这个指标综合反映芯片推理能力和模型效果，比单个模型的精度分更有说服力。

这个设计源于一个很现实的教训：同一颗芯片，跑纯视觉模型的得分可能很高，但一旦进入多步 Agent 场景，每步推理之间的调度开销、NPU 与 CPU 之间的数据搬运延迟、中间内存分配的不确定性，会把理论算力打一个很大的折扣。只有看任务完成率和单步时延，才能反映真实体验。

2.2 芯片关键指标分级拆解

在芯片评估维度上，我把它分成硬性指标和软性指标两类。硬性指标包括整数算力、浮点算力、NPU 算力、内存带宽和功耗上限。软性指标包括框架兼容度、算子覆盖率、量化工具成熟度、动态 shape 支持和多后端调度能力。

这里必须强调内存带宽。Agent 模型虽然经过量化，但视觉编码器处理高分辨率屏幕截图时，中间 Feature Map 的读写量非常惊人。一颗算力很高但带宽不足的芯片，跑小 batch 推理时问题不明显，跑连续截图解析时会出现明显的带宽瓶颈，算力空转，推理速度反而比算力低一档的芯片还慢。

算子覆盖率是另一个关键点。视觉模型里常用的 LayerNorm、GELU、Attention 类算子，在主流端侧 AI 框架里一般有现成实现，但 planning 模型里一些较新的算子或者自定义算子，经常是适配黑洞。覆盖率不足时，部分算子会回退到 CPU 执行，NPU 和 CPU 之间的频繁切换会引入巨大开销。所以在评估指标表里，我们专门加了一项“NPU 算子覆盖率”，要求低于 95% 的芯片平台直接降级评估。

2.3 从“能跑”到“好用”的量化门槛

评估最终要落到一个可以指导决策的结论上，所以我们对指标设置了门槛值。

第一道门槛是模型精度。量化后的模型在标准测试集上的准确率损失不得超过 2 个百分点，超过这个范围就说明芯片的量化工具链或数值精度有问题，需要回去调量化方案。第二道门槛是单步时延。我们设定普通操作单步时延不超过 1500 毫秒，复杂操作不超过 3000 毫秒。超过这个数值，用户的等待焦虑会显著上升。第三道门槛是温度与功耗。连续运行 30 分钟，机身温度不得触发系统级降频，平均功耗要控制在 5 瓦以内。这个标准针对的是长时间使用体验，很多芯片跑单次推理很漂亮，一到持续负载就露馅。

这三个门槛对应的其实是同一个问题：用户感知的“快”是连续几十个操作循环累计出来的，任何一个环节掉链子，整体体验都会崩。所以评估不能只看峰值性能，要把持续性能当作核心评估对象。

3. 端侧推理链路的实现与核心环节拆解

3.1 感知层：从截屏到 UI 结构化描述

手机 Agent 的感知层负责把一张屏幕截图变成机器可理解的结构化信息。

这一步的实现在端侧有一个很现实的工程约束：屏幕截图的原始分辨率通常是 1080×2400 甚至更高，直接送进视觉模型做全分辨率推理，计算量会大到端侧芯片无法承受。我们需要把截图按比例缩放到模型输入尺寸（常见的是 448×448 或 336×336），但缩放不能粗暴，因为 UI 元素里的文字和图标在缩小后可能失去辨识度。我们的做法是两段式感知：先用轻量模型做场景分类和区域提取，确定当前页面属于什么类型的界面；再对关键区域做局部高清裁剪，只对裁剪后的图像块做细粒度文本识别和控件定位。这一步对芯片的并行能力要求很高，因为多个图像块需要同时过模型，好在 NPU 对图像类卷积算子的支持普遍比较成熟，整体耗时可控。

3.2 规划层：操作序列的 token 化生成

AutoGLM 的规划层本质上是把“屏幕上有什么、用户要什么、下一步做什么”编码成一个序列建模问题。模型接收感知层输出的 UI 描述，把屏幕元素映射为可操作的 token，然后输出一段结构化的操作口令，比如点击某个坐标、长按某个控件、输入一段文字。

这部分的推理特点跟感知层完全不一样：它是自回归生成，每一步只产生一个 token，属于典型的低算力、高延迟敏感场景。芯片评估时最容易忽略的也是这一点——卷积类算子的优化经验用不上，注意力算子和逐 token 的解码延迟才是关键。我们在评估中发现，同一颗芯片在感知层的推理速度可能很理想，但到了规划层的自回归解码阶段，如果对 Attention 算子的实现不优化，时延会翻倍甚至更多。这也是为什么评估必须分层、分场景、分模型各自跑。

3.3 执行层：系统手势与操作反馈闭环

执行层严格来说不涉及模型推理，但它的稳定性直接影响芯片评估的准确性。Agent 执行控制模块需要把规划层输出的一系列操作映射成系统 UI 事件，模拟真实用户的点击、滑动和输入。这要求系统授权和无障碍服务配合，同时也要求每一步操作后有可靠的反馈机制来确认操作已经生效。

实际测试中，这个环节暴露过一个很有意思的问题：执行层向系统发送手势事件后，界面变化需要几百毫秒才能稳定，如果模型推理太快，截图上来的时候界面还在动画过渡中，感知层就会拿到一张“半完成”状态的截图，导致后续规划出错。后来我们在推理循环里加入了 300 到 600 毫秒的执行稳定等待窗口，同时让感知层对截图做动态区域比对，避免动画中间态干扰。这个细节也提醒了我们：端到端评测时，芯片推理速度不是越快越好，要与执行环境形成合理的时序配合。

3.4 模型量化与内存带宽优化方案

AutoGLM 涉及的主要模型包括一个视觉编码器和一个规划模型，体量从几亿参数到十几亿参数不等。直接以 FP16 精度运行在端侧芯片上，不仅内存占用高，推理速度也不理想，所以量化是必选项。

我们的量化方案分为两步。第一步是 PTQ（训练后量化），先用代表性校准集统计激活值的分布范围，把权重和激活从 FP16 压到 INT8，观察端到端任务完成率的变化。PTQ 通常能保住大部分精度，但如果某些层对数值变化特别敏感，就需要第二步：对这些敏感层做 QAT（量化感知训练）微调。整个量化过程最麻烦的地方在于不同芯片的量化策略不同，同一套量化后的模型在 A 芯片上表现良好，迁移到 B 芯片可能会因为激活值校准方式不同而出现精度抖动。所以量化参数的超参（比如校准集大小、per-channel 粒度、KL 散度校准还是 min-max 校准）必须针对目标芯片微调，不能一套配置走天下。

内存带宽优化则是部署层面的工作。我们把模型中频繁加载的权重做了内存常驻规划，让注意力层的权重尽量驻留在片上 SRAM 或高速缓存中，减少反复从 DRAM 读取的开销。对于中间激活值，使用算子融合把连续的卷积、归一化、激活合并为一个算子，减少中间结果写回 DRAM 的次数。这两个手段叠加，在实际测试中能带来 30% 以上的端到端性能提升，值得做。

4. 实操评测：芯片适配的完整流程

4.1 评测环境的搭建与准备

评测环境这部分，我踩的比较大的坑是“低估了任务集设计的重要性”。一开始我们直接拿现成的单模型数据集跑精度和时延，结果发现根本没法回答“这个芯片适不适合做手机 Agent”这个问题。后来重新设计了一套任务集，才让评测有了决策价值。

任务集分三层。第一层是原子能力测试，包括 UI 元素识别、文本识别、图标分类等单项能力，每个能力准备了 500 到 1000 张带标注的截图。第二层是短链路任务，比如“打开设置并关闭 Wi-Fi”“把屏幕亮度调到最低”，这些任务只需 2 到 5 步，用于评估基础端到端能力。第三层是长链路任务，比如“在地图里搜一个地点并规划公交路线”“在电商应用里完成搜索、比价、加购”，这些任务需要 10 到 20 步操作，包含跨应用跳转和页面状态变化，能真实考验芯片在复杂推理链路上的持续表现。

评测脚本方面，我们写了一套自动化执行框架，负责向 Agent 下发指令、监听执行状态、周期截图、记录日志。每个任务重复执行 20 次，取成功率和时延分布，而不是单次结果。设备状态也做了控制——每次任务开始前清理后台应用、重置电量到同一水平、关闭非必要系统服务，保证对比的公平性。

4.2 三块关键指标的实测方法

实测过程主要集中在三块。第一块是模型推理时延，这个好办，在模型层面插入计时点，分别统计感知模型和规划模型在 NPU 上的执行时间。需要注意的是，NPU 推理通常有预热过程，首次调用时需要加载权重和构建算子图，所以计时时要跳过预热阶段，统计稳定阶段的数据。

第二块是端到端任务时延，这是用户真实感知的指标。我们在 Agent 执行框架里记录每个操作循环的起止时间，包括截图时间、感知推理时间、规划推理时间、执行等待时间。拆开统计后能清楚看到瓶颈在哪一环。实测下来，感知推理所占比重最大，而规划推理的方差最大，偶尔会出现异常长尾，需要进一步定位是不是 NPU 调度器在动态 shape 场景下的资源分配问题。

第三块是功耗和温度。我们用设备外接的电流计采集整机功耗曲线，同时通过系统接口读取 NPU、CPU 的单独功耗和芯片温度。测试模式是连续 30 分钟执行长链路任务，记录功耗随时间的变化曲线、峰值功耗、平均功耗以及温度触顶的时间点。这块数据对芯片选型非常重要，因为 Agent 的使用场景不是跑一个模型就结束，而是长时间挂在后台做连续任务，散热能力决定了体验上限。

4.3 热设计与持续运行的极限压力测试

持续压力测试是整套评估里最折磨人的环节。手机 Agent 场景下，NPU 和 CPU 往往会交替满载：感知模型跑在 NPU 上，规划模型的某些算子回退到 CPU，执行等待期间又相对空闲。这种交替负载对芯片的电源管理和散热设计非常不友好，容易在多次切换后出现温升累积。

我们遇到的一个典型案例是：某平台在单次推理时温度表现良好，峰值功耗 4 瓦左右，但连续执行 20 分钟长链路任务后，芯片温度爬升到触发系统降频的阈值，推理速度在五分钟内下降了将近一半。关键问题在于降频不是平滑发生的，而是突然掉档，用户会明显感觉到“越用越慢”。这个结果靠单次 benchmark 根本测不出来，必须靠持续压力测试才能暴露。

测出这个问题后，我们对方案做了一些调整。一方面在模型层面把感知模型的输入分辨率做了动态选择，温度高时自动降低分辨率，牺牲部分精度换取速度稳定；另一方面在调度层面限制 NPU 和 CPU 同时高负载的时间，任务之间主动插入微小的空闲窗口，让芯片有时间散热。这些措施不改变模型的最终效果，但能让长期的执行速度保持稳定。

4.4 多场景交叉验证与结论确认

单平台评测完成之后，我们还做了多场景交叉验证。核心思路是验证“芯片适配结论”不是特定测试条件下的偶发结果，而是具有普遍性的技术判断。我们把同一套 AutoGLM 模型分别部署到三款不同定位的芯片平台：一款旗舰级、一款主流级、一款入门级，重复跑完全部任务集。

对比数据非常有意思。旗舰级平台在模型精度和时延上全面领先，但如果只看时延，会发现感知层的优势远大于规划层，说明规划层的解码效率还有优化空间。主流级平台在量化精度上出现了一些问题，某些算子在校准后数值偏差偏大，需要通过混合精度方案修正。入门级平台则整体吃力，尤其是长链路任务的稳定性明显不足，操作越多越容易出错。

这个交叉验证帮我们得出了本次评估的核心结论：AutoGLM 手机 Agent 场景的芯片适配，不能只看单模型性能，必须考虑感知模型、规划模型、系统调度的整体匹配。旗舰级芯片能胜任完整功能，主流级芯片做轻量化裁剪后可以满足基础需求，入门级芯片目前还不适合承担复杂的多步 Agent 任务。

5. 问题排查与适配优化实录

5.1 算子兼容性问题与混合精度方案

算子兼容是我们在适配中被卡得最久的一个问题。AutoGLM 的规划模型里用到了较新的激活函数和注意力变体，在 GPU 上可以直接跑，但在端侧 NPU 上没有对应的底层实现，编译器会把这些算子回退到 CPU 执行。回退的后果就是每一步推理都要经历“NPU→CPU→NPU”的数据搬运，单步时延瞬间增加 3 到 4 倍。

排查过程是这样的：先用性能剖析工具对每个算子的执行时间和设备位置做统计，发现时延异常集中在那几个回退算子上面。然后逐个算子看 NPU 的指令集支持情况，确认哪些有硬件实现，哪些只能通过组合已有算子来模拟。对于可以组合实现的算子，我们在模型编码阶段就做了子图拆分，把一个大算子拆成多个 NPU 原生支持的子算子序列；对于实在无法在 NPU 上高效运行的算子，保留其在 CPU 上的实现，但通过把相关子图整体打包，减少 NPU 和 CPU 间的频繁切换。

最终采用的是一种混合精度方案：视觉模型全 INT8 跑在 NPU 上，规划模型的关键层用 FP16（因为 INT8 量化损失过大），次要层用 INT8，同时把回退算子的数据搬运尽量压缩到同一个 batch 里。这个方案把端到端时延从最初的两秒多压到了 1.4 秒左右，代价是内存占用略增。所以如果你的模型在芯片上出现算子回退，不要一上来就逼芯片硬吃所有算子，先搞清楚哪些算子贡献了 90% 的时延，针对它们做子图优化，收益更直接。

5.2 动态 shape 带来的内存分配与调度抖动

手机 Agent 的场景特殊性在于输入图像的 shape 不是固定的。虽然我们对原始截图做了缩放，但不同应用的 UI 布局差异很大，加上局部裁剪的策略，输入张量的高度和宽度经常在变化。动态 shape 对 NPU 调度器来说是个考验，内存池的预分配策略不好时，频繁重分配会导致明显的抖动。

我们在测试中捕捉到一种“间歇性卡顿”现象：大部分操作时延在 800 毫秒左右，但每隔几个操作会出现一次 2 到 3 秒的超长时延。通过 profiling 发现，问题出在视觉编码器输出的中间特征图尺寸随输入变化，导致 NPU 在每次推理时重新分配内存，而内存分配恰好与系统其他后台任务发生资源竞争。

解决思路是限制输入 shape 的变化范围：把截图缩放的目标尺寸做分档处理，而不是任意缩放，比如 336、448、560 三档，模型对特定档位可以复用分配好的内存池。这样虽然损失了一点点感知精度（因为部分页面被强制缩放到统一尺寸），但时延抖动从 40% 降到了 10% 以内，整体体验提升非常明显。这个取舍我认为值得。

5.3 功耗墙与降频策略的折中处理

降频问题是持续压力测试中发现的最严重问题，也是产品化之前必须解决的一道坎。芯片触发降频后，不仅推理速度下降，模型推理的时延分布也会变宽，极端情况下单步时延能从 1 秒飙到 3 秒，用户会明显感到 Agent“变笨了”。

我们的处理思路分为硬件层面和软件层面。硬件层面，在评测阶段就把散热条件记录下来，后续选型时优先考虑热设计功耗更高的平台，或者建议设备厂商加强散热方案。软件层面，我们引入了一个“任务感知的动态频率调节策略”，在 Agent 感知到当前处于长任务执行状态时，主动把 NPU 的频率设定在一个更保守的档位，宁可单步时延增加 20%，也要避免触发强制降频带来的 100% 性能回退。这个策略的收益是长期的稳定性：用稍微变慢的速度换取全程稳定的执行体验，对用户来说反而更“顺手”。

5.4 常见问题速查表

6. 芯片平台选型对比与适配建议

6.1 按产品定位选择适配深度

做完三款平台的交叉评测，我对“什么样的产品需要什么样的适配深度”有了更清晰的判断。如果你的产品是旗舰手机预装助手，用户对时延和成功率的要求极高，那必须在芯片选型阶段就锁定旗舰平台，并且投入做算子级适配和模型专门调优。如果你的产品是 APP 内嵌的轻量助手，只执行单步或短链路操作，主流级芯片配合轻量化模型就够了，不需要追求极致的算子覆盖和混合精度优化。如果你还在创业阶段，希望以最低成本验证 Agent 场景的可行性，建议先跑云端方案验证产品逻辑，再根据用户反馈决定是否投入端侧芯片适配。

评估数据也给出了一些硬性参考。旗舰平台在端到端任务完成率上能稳定超过 85%，主流平台在模型轻量化后能达到 70% 左右，而入门平台普遍低于 60%，且时延波动明显较大。这个差距不仅是算力问题，更多是工具链成熟度和散热设计的差异。所以如果你的目标用户有大量低端机，纯端侧方案目前还不现实，至少要把一部分推理放在云端做做协同。

6.2 结合业务场景的技术路线建议

从技术演进方向来看，手机 Agent 芯片适配大概率会走向“端云协同”的架构：轻量感知和基础交互在端侧完成，复杂规划任务交给云端大模型处理。这个架构的优势在于，端侧芯片只需要稳定跑好视觉感知这类算子成熟、并行度高的模型，而规划模型这类自回归生成任务可以放在云端的通用计算资源上，避免端侧芯片在自回归解码场景下的低效率问题。

这个路线对芯片厂商也是一个信号：如果未来想服务好手机 Agent 这类场景，不能只在卷积算子上堆算力，还要重视自回归解码相关的算子效能，以及 NPU 与 CPU 之间的数据搬运效率。Agent 场景是少有的“视觉模型 + 语言模型 + 系统调度”紧密结合的应用形态，对芯片的考验是全方位的。

从我的实际体验来说，做这一类评估项目最深的体会是：拿到芯片先别急着跑分，先把你要支持的真实任务链路跑通，再回头看瓶颈在哪个环节。芯片表现好不等于 Agent 表现好，这个幻觉我在项目里踩了好几次，写出来给后面做类似工作的团队做个提醒。另外，任务完成率的评测一定要人工复核结果，不要只看自动化脚本的判断，因为很多任务是“操作完成了但结果错了”，只有人工复核才能发现这层问题。