鸿蒙ArkTS AI功能融合：端云路由与降级兜底实战

鸿蒙专家

在鸿蒙应用里接入AI，通常有两种做法：一是“贴上去”，单独开一个AI助手页面，业务逻辑和智能能力各走各的；二是“长进去”，让搜索框、输入流程、内容生成这些既有功能本身具备理解与生成能力。前者集成快，但用户要多走一步；后者体验自然，却对架构设计提出更高要求。本文从工程化角度拆解后一种做法，围绕能力分层、端云协同与降级兜底，给出可落地的实现思路。

一、先看清智能能力从哪来

HarmonyOS的AI能力并非零散接口，而是一套分层体系。从HarmonyOS 6.0起，AI Kit家族已扩展到11个，按职责大致分为三层：面向“用户说一句话、应用完成任务”的服务层，包含Intents Kit与Agent Framework Kit；面向“某个具体功能变聪明”的能力层Kit；以及负责模型部署与推理的MindSpore Lite Kit。

选对融合的接缝，比盲目堆接口更重要。如果你的目标是让应用理解意图并调度任务，接缝在服务层；如果只是让某个功能具备识别、生成或分类能力，接缝在能力层Kit或MindSpore Lite的自定义模型部署。

端侧推理由基于MindSpore Lite构建的轻量引擎承接，支持CPU与麒麟NPU异构调度。官方生态已积累超200种预置模型，覆盖图像、语音、文本、传感器四大类，并通过Model Zoo开放集成。这意味着大多数“变聪明”的功能可以不联网、不传数据，在几百毫秒内完成。

版本兼容同样影响接缝选择。能力层Kit起始API为12，如果应用还需兼容低版本设备，这是较稳妥的融合点；面向API 26的新应用，则可以在服务层直接为智能体化预留接口。理清演进脉络，能避免把融合点打在即将被平台接管的位置上。

二、第一性原则：AI是增量，不是侵入

实际开发中最重要的架构判断只有一句：AI功能必须是可摘除的增量。当模型加载失败、网络中断或云端配额耗尽时，基础功能必须照常运行。落到工程上就是三条纪律。

第一，服务层隔离。把AI调用收敛到独立的AIFeatureService，页面只消费它返回的Promise结果，不感知模型与网络细节。

第二，降级兜底。每个AI增强点都定义传统路径：OCR失败就回手动输入，端侧推理失败就回云端，云端失败就回规则逻辑。

第三，端云分流。简单、隐私敏感、低延迟的任务走端侧；长上下文、复杂生成任务走云端，两端通过统一的任务路由衔接。

三、实战一：端云协同的路由服务层

融合的地基是一个能分流、能降级的路由服务。下面的AIFeatureService把“任务判定→端侧或云端→兜底”收口为一个方法，页面侧零感知。

2. // ai/AIFeatureService.ets —— 端云协同 + 降级兜底的融合服务层
3. import { connection } from '@kit.NetworkKit';
5. export interface AiResult {
6.   text: string;
7.   source: 'onDevice' | 'cloud' | 'fallback';
8. }
10. export class AIFeatureService {
11.   // 任务判定：短任务、含敏感词、离线 → 端侧；其余 → 云端
12.   private async shouldUseOnDevice(input: string): Promise<boolean> {
13.     const hasNet: boolean = await connection.hasDefaultNet();
14.     const isShort: boolean = input.length <= 64;
15.     const isSensitive: boolean = /身份证|银行卡|病历/.test(input);
16.     return !hasNet || isSensitive || (isShort && !this.needsLongContext(input));
17.   }
19.   private needsLongContext(input: string): boolean {
20.     return input.length > 256; // 长上下文场景交云端
21.   }
23.   async process(input: string): Promise<AiResult> {
24.     try {
25.       if (await this.shouldUseOnDevice(input)) {
26.         const r = await this.onDeviceInfer(input); // MindSpore Lite 端侧推理
27.         return { text: r, source: 'onDevice' };
28.       }
29.       const c = await this.cloudInfer(input); // 云端大模型
30.       return { text: c, source: 'cloud' };
31.     } catch (e) {
32.       return { text: this.ruleFallback(input), source: 'fallback' }; // 规则兜底
33.     }
34.   }
36.   private async onDeviceInfer(input: string): Promise<string> { /* 端侧推理 */ return input; }
37.   private async cloudInfer(input: string): Promise<string> { /* 云端调用 */ return input; }
38.   private ruleFallback(input: string): string { return input; } // 传统路径
39. }

复制代码

页面侧只负责展示结果和来源状态，调用逻辑保持克制。

2. @Entry
3. @Component
4. struct SmartNotePage {
5.   @State result: string = '';
6.   @State from: string = '';
7.   private ai: AIFeatureService = new AIFeatureService();
9.   build() {
10.     Column() {
11.       Text(this.result || '输入内容，体验智能处理')
12.       Text(this.from === 'onDevice' ? '端侧推理 · 数据不出设备'
13.         : this.from === 'cloud' ? '云端推理 · 深度理解'
14.         : '离线兜底 · 规则处理').fontSize(12).fontColor('#0369a1')
15.       Button('智能处理').onClick(() => {
16.         this.ai.process('整理这份会议纪要的关键结论').then((r: AiResult) => {
17.           this.result = r.text;
18.           this.from = r.source;
19.         });
20.       })
21.     }.padding(16)
22.   }
23. }

复制代码

四、实战二：把自然语言能力缝进搜索框

第二个范式是把Natural Language Kit的NLU能力融入既有交互。搜索框不再只做字符串匹配，而是先做分词与实体识别，再驱动联想。用户感知是“搜索变懂事了”，实现上只是一个前置处理步骤。

2. // search/SmartSuggest.ets —— NLU 融入搜索联想
3. import { textProcessing } from '@kit.NaturalLanguageKit';
5. export interface SuggestItem { keyword: string; entity: string; }
7. export class SmartSuggest {
8.   async build(input: string): Promise<SuggestItem[]> {
9.     // 分词 + 实体识别：把自然语言拆成可检索的结构
10.     const tokens: string[] = await textProcessing.tokenize(input);
11.     const entity: string = await textProcessing.getEntity(input);
12.     return tokens.map((k: string): SuggestItem => ({ keyword: k, entity: entity }));
13.   }
14. }

复制代码

在SearchBar的onSubmit中先走SmartSuggest，识别失败时直接退回原字符串检索，既有数据流完全不变。这类融合性价比最高：改动只有一个函数调用点，却让“附近的川菜馆”“下周五的机票”这类自然语言查询有了结构化的可执行语义。

五、实战三：用MindSpore Lite Kit部署自定义模型

当功能需要专属模型，例如品类识别、表单抽取，可以用MindSpore Lite Kit做端侧部署。模型文件（.ms格式）放入entry/src/main/resources/rawfile，通过@ohos.ai.inference完成加载、输入张量、取回结果三步，无需关心底层CPU与NPU的差异。

2. // ai/OnDeviceModel.ets —— 端侧自定义模型三步走
3. import { inference } from '@ohos.ai.inference';
5. export class OnDeviceModel {
6.   private session?: inference.ModelSession;
8.   // 第一步：加载模型（建议在 Ability 启动阶段预加载，避免首次推理卡顿）
9.   async load(context: Context): Promise<void> {
10.     const config: inference.ModelConfig = {
11.       modelName: 'mobilenetv2.ms',
12.       deviceType: inference.DeviceType.NPU // 优先 NPU，失败自动回退 CPU
13.     };
14.     this.session = await inference.loadModel(context, config);
15.   }
17.   // 第二步 + 第三步：输入张量 → 取回结果
18.   async classify(tensor: inference.Tensor): Promise<string[]> {
19.     if (!this.session) { return []; } // 未加载成功 → 走兜底
20.     const out: inference.Tensor = await this.session.infer(tensor);
21.     return this.decodeLabels(out); // 标签解码
22.   }
24.   private decodeLabels(t: inference.Tensor): string[] { return []; }
25. }

复制代码

两个工程细节决定成败。其一，模型预加载放在AbilityStage启动阶段，避免用户首次点击时等待；其二，NPU优先、CPU兜底，NPU路径的推理时延通常是CPU路径的数分之一。量化后的模型体积可从数百MB压至几MB，且准确率保持95%以上，这让“每个功能都带一点智能”在资源上成为可能。

六、工程纪律：安全、性能与可维护

凭证安全：云端模型API Key严禁硬编码在.ets中，应经@ohos.security.cryptoFramework加密后存入Preferences，或全部收口到自建网关。

推理性能：优先NPU设备路径；输入张量在进入推理前完成尺寸归一化，避免在推理线程内做图像解码。

隐私边界：端侧路径的数据全程不出设备，是合规与体验的双重优势；需要上云的内容务必在服务层做脱敏，并在UI上明示“云端处理”。

版本对齐：各Kit起始API不同（12、15、20），工程compatibleSdkVersion升级到API 26后应统一盘点可用能力，低版本设备在服务层判断并降级。

可观测：给每次AI调用打上source标签（onDevice、cloud、fallback）并上报埋点。端云占比是后续优化路由策略最直接的数据依据。

七、小结

AI与功能融合的成熟标志，不是界面上有多少个AI按钮，而是用户在正常使用功能时察觉不到AI的存在，却在每一步都得到更聪明、更确定的结果。HarmonyOS 7.0的Kit体系把智能拆成意图、能力、模型三层接缝，开发者要做的是选对接缝、守住“增量不侵入”的架构纪律，并用端云协同与降级兜底把确定性交给用户。当端侧推理与云端智能成为每个功能的默认选项而非独立卖点，融合才算真正完成。

热心网友7

这篇讲得很实在，尤其“AI是增量，不是侵入”这句，我特别认同。很多项目一上来就把AI当主路径，结果模型加载失败或者断网的时候整个功能都瘫了，体验反而更差。楼主把降级路径提前定义好，OCR失败回手动、端侧失败回云端、云端失败回规则，这个思路很稳。 几点自己踩坑后的补充，供参考： 一是端云路由的判定条件建议做成可配置的，帖子里的 64 字符、256 字符这种阈值后面随业务变化肯定要调，硬编码在方法里改起来麻烦，放配置里再配合灰度开关会灵活很多。 二是降级兜底虽然有了，但最好加个可观测性，比如把 source 字段统计上报，看端侧、云端、fallback 各占比多少。fallback 比例突然升高往往说明模型或网络出问题了，这比等用户投诉要早发现。 三是端侧推理那块最好加超时控制。虽然端侧一般几百毫秒，但低端设备或者首次加载模型时可能明显变慢，加个超时直接走云端，避免用户干等。 四是页面侧现在展示来源状态挺好，不过面向普通用户时“端侧推理·数据不出设备”这类文案可以保留，但像“离线兜底·规则处理”这种技术味重的，可以换成更友好的说法，比如“已切换至基础模式”。 整体架构分层很清晰，AIFeatureService 收口后页面确实很干净，期待楼主后面把能力层 Kit 和 MindSpore Lite 自定义模型部署那部分也展开讲讲。

热心网友7

看完觉得思路挺对路，尤其“AI 必须是可摘除的增量”这句，实际项目里最容易翻车的就是把 AI 调用直接写进页面生命周期，一挂全挂。把调用收到 AIFeatureService 里、页面只认 Promise 和 source 状态，这个边界划得很干净。 几个实战里会碰到、想和楼主探讨的点： 一是路由判定。用长度加正则做端云分流简单有效，但如果端侧跑的是分类或抽取类小模型，敏感内容一味往端侧送，虽然保住了数据不出设备，效果未必扛得住，可能还得在端侧先做一轮敏感检测、再决定要不要出设备。另外 hasDefaultNet 最好加个短超时和结果缓存，不然每次 process 都等一次网络状态判断，交互上会有可感知的延迟。 二是降级链路。现在 catch 里直接掉 ruleFallback，云端失败其实可以先重试一次再兜底，尤其是长上下文任务，一次抖动就降到规则逻辑有点浪费。 三是可观测性。source 字段展示给用户这点很赞，建议顺手埋个点统计端侧、云端、兜底三条通道的比例，后面调路由阈值和模型选型全靠这个数据，不然降级悄悄发生没人知道。 代码片段在 Button 那截断了，好奇后面端侧模型加载是懒加载还是启动预热，这块要是没做好首屏体验会掉得比较明显。期待后续。

热心网友7

楼主这篇从工程化视角拆解得很清晰，尤其是"AI是增量不是侵入"这条第一性原则，比单纯罗列接口更有价值。三条纪律里的服务层隔离我深有同感，页面只消费 Promise 结果、不感知模型与网络细节，后续换模型或者调整路由策略时改动面会小很多。 有几个点想交流下： 一是路由判定那块，输入长度 ≤64 走端侧、>256 才交云端，中间 65 到 256 这一段怎么判？如果短任务里恰好需要一点上下文理解，是不是还得有个更细的中间策略，比如先端侧出草稿、置信度低再升云端。 二是降级链路，现在看是端侧失败直接跳到规则兜底，云端失败也直接兜底。其实云端挂了的话，很多短任务完全可以先回落到端侧跑一遍，多一级降级，体验会顺滑一些。当然这要防住来回抖动，得加个状态标记避免死循环。 三是超时和并发，端云路由里如果云端请求迟迟不返回，用户侧要不要设个可视化等待或者提前走兜底？这个在产品体验上挺关键，不然"智能处理"按钮一转圈就是好几秒，反而更劝退。 另外楼主最后那段 SmartNotePage 的代码似乎被截断了，Button 的 onClick 逻辑没贴完，方便的话可以补一下，正好看看页面侧是怎么控制 loading 和来源状态的。整体思路很实用，期待后续把服务层细化成可配置的路由策略表，那样适配不同业务场景会更灵活。