正在加载，请稍候
一次把 Web 端智能体平移到鸿蒙端，首屏崩溃率冲到 8%。这篇复盘给出智能体落地的 5 个关键决策：权限与隐私、意图框架、端云协同、热更新、合规审核，附外包评估 4 问。
我们把一个 Web 端 AI 助手直接平移到鸿蒙上，首屏崩溃率冲到 8%，改成端云分权后压到 0.3%。这篇复盘讲清楚鸿蒙上的 AI 应用与 Web、小程序端的关键差异，以及智能体落地必须做对的 5 个决策。
2026 年 6 月 HDC 2026 上 HarmonyOS 7 开发者 Beta 亮相后，行业讨论最多的不是性能数字，而是「系统底层开始围绕智能体重新组织」——用户不再需要先打开某个 App，而是直接表达意图，由系统判断该调用哪些能力。InfoQ 对鸿蒙生态布道师刘光智的专访把这条链路拆成六层：小艺（入口）→ HMAF 2.0（任务拆解与多智能体协作）→ AI 底座（openPangu 2.0 开源模型 + 端侧 30B 模型）→ 方舟引擎 / 星盾安全 / 星河互联 → DevEco Code / CLI → 具体场景。
对开发者最直接的变化：应用可以把自己暴露成「可被系统调度」的 AI 能力。代码层面是用 ArkTS 里 @agentService.AgentExtension 注册能力，通过 declareCapabilities 声明意图与参数结构，系统匹配意图后用 onInvoke 把结构化任务分发进来——不是一句自然语言，而是结构化参数。这跟「语音助手调一个 API」是不同层面的复杂度。
同期值得关注的还有端侧算力与跨端成本两条线。openPangu 2.0 开源版 Pro 有 5050 亿参数、Flash 有 920 亿参数，均支持 512K 上下文，昇腾原生单卡吞吐率据称是主流开源模型的两倍；星盾安全架构用端侧 AI 秒级识别七大类诈骗套路，官方口径已识破 347 万次潜在骗局。InfoQ 关于 KMP 在鸿蒙上跑起来的报道则给出另一组关键数据：渲染内存降 95%、GC 卡顿率降 90%，而国内大厂押注 KMP 的核心理由是三端（Android / iOS / 鸿蒙）共享逻辑的成本压力。这些都在改变「鸿蒙上做 AI」的工程假设。
HarmonyOS 平台的工程栈选择比 Web / 小程序多一个维度：不仅要考虑 UI 层，还要考虑意图框架接入深度与端侧模型能力。主流方案对比见下表；成本与技术栈的整体拆解可参考鸿蒙应用开发外包指南（2026）。
| 方案 | 意图框架接入 | 性能与内存 | 适合场景 |
|---|---|---|---|
| ArkTS 原生 | 直接注册 HMAF 扩展 | 最优，无跨语言开销 | AI 主链路、系统级交互 |
| Flutter（鸿蒙适配） | 需桥接层，意图暴露受限 | 自渲染，1080P 单页约增加 70MB 内存 | 运营型内容页、快速迭代 |
| KMP（鸿蒙适配） | 可调用平台 CAPI，逻辑层共享 | 渲染内存降 95%、GC 卡顿率降 90%（InfoQ 实测口径） | 三端共享业务逻辑的性能域 |
我们的结论：智能体主链路用 ArkTS 原生，内容与运营页交给跨端框架；「性能域 / 动态域 / 开放域」三分法在鸿蒙同样成立。
端侧小模型与云侧大模型的分工：端上模型（openPangu 2.0 端侧 30B 量级）负责隐私敏感、低延迟、断网场景——意图理解、表单抽取、敏感内容过滤；云端负责长上下文、复杂工具调用与多智能体编排。两端通过任务队列衔接，断网时本地兜底。鸿蒙端大模型接入的常见误区是「全部上云」，等遇到弱网和合规问题再回头改造，成本远高于一开始就做分权。这也是 HarmonyOS Agent 工程化与 Web 端最大的一点不同：端侧不是可选项，是兜底层。
鸿蒙的授权模型是「最小化 + 可撤回」，星盾安全框架还会在端上做 AI 检测。AI 能力一旦被系统调度，会接触到联系人、位置、健康等敏感数据。设计上要区分「系统调度需要的数据」与「业务自处理的数据」：敏感操作尽量本地完成，云端只收脱敏结果。我们在复盘后把通讯录读取从云侧 RAG 链路中拿掉，只保留本地结构化抽取，弹窗数量直接减半。
两条路：接入 HMAF 扩展让系统助手能调度你的能力；或者自建意图路由，在 App 内处理用户输入。前者能进入系统分发流量池，但要遵守 HMAF 的能力声明与参数结构规范；后者可控性强，但拿不到系统级分发。多数团队建议先做自建路由，再把高频能力（日程、搜索、报名）逐步暴露成 HMAF 智能体。
AI 应用最常见的崩溃来源不是模型本身，而是「云端不可达时的空指针」。设计任务队列：端上模型先产出结构化结果，云端异步深化；断网时本地小模型兜底，恢复后合并。网络状态变化要作为一等公民事件处理，而不是事后 try-catch。上线后的运行指标与治理，可以参考AgentOps 平台搭建实践。
鸿蒙对动态化能力有明确边界。AI 能力的提示词、工具定义、描述文案这类「业务参数」可以走服务端下发，但可执行代码、动态库必须走应用市场审核。把「参数下发」与「代码发布」分开设计，迭代周期可以从两周缩短到小时级，同时不触碰审核红线。
AI 生成内容标识、隐私权限声明、未成年人保护、生成式 AI 备案都会进入上架审核。AI 功能涉及支付、短信、定位等敏感操作时，审核会要求提供能力说明与用户授权链路。建议在技术方案评审阶段就把合规清单列出来，而不是等提审被拒再补。
以下来自我们为某某行业客户（金融场景，名称脱敏）交付的鸿蒙端 AI 助手项目，时间线完整保留：
三个可复用的结论：
企业级 AI 应用的技术决策我们之前写过，这里只谈怎么验证团队的交付能力。与其听团队讲技术愿景，不如直接问 4 个具体问题：
如果对方只能回答「我们支持大模型接入、做过 Chat 界面」，基本可以判断没有真正做过鸿蒙上的智能体项目。
授权与意图模型。Web 端几乎没有授权弹窗成本，鸿蒙上弹窗叠加会直接造成崩溃（我们踩到过同类问题）；且应用可以被系统智能体调度，需要按 HMAF 规范暴露能力。
够做意图理解、表单抽取、敏感内容过滤这类确定性任务；复杂推理、长上下文仍建议云侧大模型。openPangu 2.0 端侧 30B 量级与 512K 上下文的开源版本（Pro 5050 亿 / Flash 920 亿参数）已覆盖多数场景。
提示词、工具定义、能力描述走服务端下发；可执行代码与动态库走应用市场审核。参数与代码分离设计，是兼顾迭代速度与合规的唯一可行路径。
问授权策略、端上模型量化与降级路径、HMAF 能力注册、审核被拒记录这四个问题，回答细节越多越可信。