鸿蒙应用开发外包：系统智能体能力回收后，自建与外购怎么划界

某制造企业的鸿蒙端巡检 App，把「语音下发工单」直接挂在系统助手入口上，验收单里写的只有一句“支持语音创建工单”。系统侧一次能力调整之后，这个入口在新批次设备上不再下发，整个语音工单模块要重做，工期、演示脚本和验收口径全部重谈。

这不是个例，而是鸿蒙端做 AI 功能时必须提前回答的一个问题：哪些能力属于你，哪些只是系统暂时借给你的。

一次「不再支持」，为什么会让整块功能返工

据 IT 之家 10 月 3 日的报道，「小艺帮帮忙」智能体能力在鸿蒙 7.0 阶段做了调整，后续新增设备将不再支持。在厂商口径里这只是一句功能说明，但对把它写进合同的乙方来说，它等于一次单方面的能力回收——没有提前量，也没有谈判空间。

更早的一个可查证例子是系统级通话能力。QQ 鸿蒙版 9 月 24 日开启的尝鲜版把系统级通话提醒暂时收回，9 月 28 日的正式版又让它回归。同一条能力在两周内经历了上线、下线、再上线。产品若只挂一条实现路径，就只能跟着对方的节奏走。

功能下发本身也是分批的：9 月 24 日起的首批升级只覆盖较新的几个系列，9 月 27 日才轮到更早的 Mate 60、Pura 70 等机型，走的是 SP6 子版本。装不装得上、什么时候装得上，由机型和批次决定，不由你的 App 决定。相关批次信息可查 IT 之家的鸿蒙频道标签页。

鸿蒙端 AI 能力的三条路线

路线一：直接调用系统助手能力

把功能挂到助手的入口、意图或卡片上，开发量最小，演示效果最好。代价是这套能力的生命周期由系统版本决定：什么时候开放、给哪些设备、是否二次授权，你都不可控。它适合演示和内部提效工具，不适合写进对外承诺的服务等级协议。

路线二：系统能力 + 自研编排

助手只承担“耳朵和嘴”——负责唤起、语音、卡片展示；业务判断、数据调用与状态机放在端内或服务端。能力被回收时，需要替换的是入口层，而不是业务层。这是多数企业项目里更稳妥的位置，也是我们在鸿蒙端 AI 应用工程化里反复强调的分层。

路线三：端内完全自研

意图识别、工具调用、语音链路全部自己搭。可控性最高，替换成本也最高：模型体积、端侧算力、账号权限、数据回流都要重新设计。只有当业务数据不能出端，或同类能力长期覆盖不到你的场景时，才值得投入。

三条路线怎么选：替换成本、适配窗口与数据边界

路线	能力被调整时的替换成本	适配窗口	数据边界	适合场景
直接调用设备助手	高，整块功能重做	完全跟随系统批次	数据经过系统链路	演示、内部提效
设备能力 + 自研编排	中，只替换入口层	与版本对齐，业务层独立	端内可控，敏感字段不出端	对外产品、有 SLA 承诺
端内完全自研	低（不依赖系统），但初始投入最高	自主	全部留在端内	数据敏感、长尾场景

把这张表当成立项会上的第一页：先确认业务能不能接受“入口随系统波动”，再决定预算往哪投。凡是写进对外 SLA 的功能，都不应该只存在于第一列。

做鸿蒙应用开发外包，合同里要写进的四条

1. 能力被回收时的替代方案。写清触发条件（官方公告、设备批次变化）、替代路径（降级到端内链路还是切换供应商能力）与交付时限。没有这一条，回收就等于变更单。
2. 版本发布节奏对齐。约定 Beta、正式版、SP 子版本三类节奏里，哪一类需要回归测试、由谁承担回归成本。
3. 接口兼容与行为等价测试。同一个意图在不同版本、不同机型上的返回结果要能对比，并保留可复现的用例集，而不是靠人工点两下。
4. 退出成本与代码归属。编排逻辑、提示词、规则库的仓库地址与交接文档要在合同里具名，约定迁移周期。这条最常被漏，也最贵。

一个常见返工场景

脱敏复述：某行业客户把「扫码后语音播报 + 自动填单」绑在系统助手上，一期顺利验收。两个月后系统侧调整，新批次设备不再下发该入口，二期已排期的四个功能全部阻塞。重谈的结果是：原合同没写替代方案，新增工作量按变更处理，工期顺延 3 周，验收标准改成“以端内自研链路为准”。返工的成本，全程由乙方承担。

交付前的五条验收清单

1. 能力依赖清单。逐个标注哪些功能依赖设备助手、哪些是自研，形成可核对的表格。
2. 降级演练。人为关闭系统能力，验证核心业务流程仍可走完。
3. 版本矩阵回归。至少覆盖目标机型的两个 SP 子版本，加上你承诺的最低支持版本。
4. 数据边界确认。列出会经过系统链路的数据字段，与内部合规口径逐项对齐。
5. 归属与迁移。编排逻辑、提示词与规则库的仓库地址、交接文档齐备，交接人签字。

常见问题

系统助手能力被调整，是 bug 还是正常节奏？

正常节奏。系统厂商会按机型、批次和版本来分层下发能力，灰度、调整、回收都属于发布策略的一部分。把它当成不可变的接口来依赖，才是设计问题。

现在开始做鸿蒙端 AI，是不是应该完全自研？

不一定。先问两个问题：你的核心数据能不能出端？系统能力在你目标机型上的覆盖期是否长于产品生命周期？两个答案都是“是/长”，用系统能力加自研编排更划算；否则再考虑全自研。

外包合同里最容易被忽略的一条是什么？

替代方案。多数合同只写“功能验收”，没写“能力消失时怎么办”。把替代路径和时间写进附件，比多压 5% 报价更有价值。立项阶段的机型与版本约束，可参考企业级 AI 应用的技术决策。

端和云怎么分工？

敏感字段、身份与状态机留在端内；重推理和需要跨设备共享的部分放服务端；编排层在端内自持，随版本独立演进。

适配新版本要多久？

取决于入口层与业务层的耦合度。分层做好的项目，一次版本适配通常在数个工作日量级；把功能直接绑在助手入口上的项目，往往要按整模块重估。

把系统能力当入口层，而不是地基

我们在鸿蒙端交付时的默认约定是：系统助手、系统卡片、系统意图一律当成可插拔的入口层，业务编排与规则库一律自研并留在自有仓库。这样系统侧调整时，改动范围被限制在接口适配，而不是整块功能重写。与之配套的沉浸光感等新约束，可参考鸿蒙开发适配要点。

如果你正在评估鸿蒙端 AI 功能的工期与报价，可以先把“能力依赖清单”填出来——这一步通常能暴露出一半以上的隐藏风险。需要参考同类交付的边界划分方式，可以查看我们的鸿蒙端交付案例，里面有按机型与版本分级的能力依赖模板与验收脚本。

参考来源

本文涉及的系统能力调整、机型批次与版本信息，来自 IT 之家鸿蒙频道与AI 频道的公开报道；敏感数据治理部分参考了 InfoQ 的技术实践文章。为避免重复，以上原文地址已在上文以超链接形式给出，此处不再重复列出。