做一个鸿蒙应用，想让自己的服务被用户"一句话叫出来"，第一反应往往是自己在应用里写一套对话逻辑：自己接大模型、自己做意图识别、自己管上下文。做完就发现，成本全花在了跟业务无关的地方，而且用户根本不会为了你这个功能专门打开应用——它拿不到系统级的入口。

为了解决这个问题，HarmonyOS 7 把小艺开放平台整套开放了出来：应用只需要按两种模式之一接入，Agent（智能体）与 Skill（技能）就能被小艺统一调度与分发。华为终端小艺产品总监在 2026 年 9 月 18 日的 HDD·HarmonyOS 创新论坛上海站上，用三十分钟把这两条路讲清楚了。

本文基于该场分享的现场录音与课件照片整理，按"系统演进 → 小艺作为系统智能体能提供什么 → 开发者的两条接入路径 → 怎么选"的顺序梳理，所有数据与案例均出自现场分享。

一、系统的三次演进：从智能控件到智能体亲和架构

现场把鸿蒙智能这几年的路线梳理得很清楚，一句话可以概括为：AI 从被应用调用的"控件"，变成了调度应用的"系统智能体"。

阶段	形态	特征
两年前	智能化控件	开发者用系统的 AI 控件完成某个具体智能功能
去年	鸿蒙智能体框架 HMAF	提出智能体框架，系统侧开始统一抽象
今年（HarmonyOS 7）	智能体亲和架构	系统级智能体小艺被单独拎出来，控件全面 AI 化

这个演进的关键动作，是把系统级智能体小艺独立出来。它的意义不在于小艺本身变强，而在于小艺下面那一层公共能力被抽出来了，可以供所有开发者复用。

现场对智能体的定义也很朴素：用户用自然语言给一个任务，中间有规划、工具调用、执行框架，底下还有一套记忆结构。这四件事在业界已经是共识。

二、小艺能提供的三样东西：懂你、能干、能记

1. 数据与记忆：200+ 系统级数据

小艺的第一层价值来自数据。现场给的说法是"小艺更懂你：丰富的长期记忆与上下文理解，200+ 系统级数据"。这句话落到具体场景是这样的：

• 早上问"我上周睡眠状态怎么样"，小艺能取到手表侧的数据；
• 问"下周有什么会议安排"，小艺能取日程；
• 桌面卡片可以让用户自定义，比如"创建异地关怀卡片，显示北京的温度与过敏指数，还能一键打电话"。

底层是四层记忆架构加长期记忆与上下文理解。对开发者的含义是：这些上下文你不用自己采集，接入之后就有。

2. 交互入口：收、推、问，加上输入法

小艺容易被觉得"杂"，现场用四个字收了口：收、推、问，再加输入法。

• 收：用户下拉，主动来找；
• 推：桌面卡片、AI Bar 推荐，主动递到面前；
• 问：语音唤醒、长按电源键、双指按压等直接问；
• 输入法：一个常被忽略但量级很大的入口。

现场同时给了一组数字：小艺家族日活 1.8 亿、每天 30 亿次唤醒，并且反复强调"这可能还偏保守"。这些入口加上数据，才构成后面那段话的前提——从 To C 的体验，回到 To B 的能力开放。

三、开发者只有两条路：应用 Agent 化，或者把能力 Skill 化

现场把开发者能做的事分成两大类，并且说得很直白：以前讲第一版材料还要解释这两个概念，现在基本不用解释了。

路径一：应用 Agent 化——把已有的智能体接进来

适用于"我已经有一个应用或智能体，怎么低成本接到鸿蒙生态里"。现场列了三种典型做法。

① 云侧 A2A。 京东这类原本就很成熟的智能体可以直接接入。开发者在小艺开放平台上按兼容协议配账号、配调用方式、配认证方式，套用小艺智能体的模板，把现有能力接进来即可。

② 端侧 A2A。 面向"数据必须留在应用里"的场景，银行是最典型的例子。现场举的是招商银行：用户在小艺里说"用招行预约最近的网点"，端侧 A2A 让覆盖 1000+ 意图的能力被调起，而隐私数据不出端。共享信息的边界很清晰——小艺是"意图分发者与执行监督者"，业务方是"领域专家与具体执行者"。

③ Agent UI Extension。 如果现有界面本身已经满足交易与数据规范，可以直接把鸿蒙应用内通过 UIExtension 实现的界面迁移进小艺对话，省掉重做界面的工作量。现场的原话是：小艺对话界面能不能像 Web 时代的浏览器一样，界面由开发者定义并直接嵌入？ 答案是能。

路径二：Skill 化——把经验沉淀成一件小事

另一条路是"万物皆可 Skill"。现场特意补了一句更重要的：门槛低不等于好做，优质 Skill 的门槛依然很高，但适用范围非常宽。

小艺开放平台提供的是一站式服务：开发 → 在线调测与真机调测 → 分发（小艺 Skill 市场）→ 管理（更新、下架、质量评测、安全检测）→ 上架。

几个值得记的点：

• VibeCoding 开发 Skill：用自然语言描述想法，平台自动生成，再做鸿蒙规范检查，微调后即可上架；也支持把已有 API、MCP 快速开发为 Skill。
• 端侧 Skill 随应用打包发布：如果你不想单独来平台注册，可以在开发应用时把 Skill 按标准格式打进包里（my-skill 目录下含 scripts、references、assets、skill.md、module.json），应用上架时自动注册到 Skill 市场。这条对已有鸿蒙应用的团队最省事。
• 发布面不止小艺主对话：还有小艺 Pro；关注最近新闻的会发现小艺 Work 也在内测，同一个能力可以一键发布多端。
• 分发与商业化：Agent Store、SkillHub、华为应用内支付、A2UI 生成式 UI 都由平台侧统一提供。

组合编排才是真正的差异化

现场给了一个非常有代表性的例子，用户说：

"我下午有一个和开发者的线下会议，需要提前 20 分钟左右到达现场，请根据实时路况帮我提前定好出发提醒的闹钟，并预约打车。"

拆开看是三段：日历 Skill 拿到会议时间 → 高德 Skill 查路况与打车 → 闹钟 Skill 设提醒。系统 Skill 与生态 Skill 串起来，才完成这件事。

这里有一条对开发者很实用的建议：不要把一个大而全的能力做成一个 Skill，优先拆成原子化的小能力。现场举的是东方财富妙想，它把查股票信息、基础行情等原子能力分别开放成 Skill，一共 8 个左右——粒度越细，描述反而越清晰，越容易被正确的场景命中。

现场也给了一个参考量级：去年一年，小艺上已上架 3000+ 个智能体。

四、怎么选：三句话的判断表

你的情况	建议路径
已有成熟智能体，希望快速接入	云侧 A2A，平台配好账号/调用/认证即可
数据敏感、必须留在自有应用内	端侧 A2A（如银行、政务类场景）
现有界面已合规，不想重做 UI	Agent UI Extension，界面直接迁移
想沉淀经验、做轻量能力	Skill 化，优先拆原子能力
已有鸿蒙应用、不想额外注册	端侧 Skill 随包发布，上架自动注册

总结

这场分享最值得带走的不是某个 API，而是边界划分：

1. 系统负责入口与调度——收推问加输入法，开发者不用自己造入口；
2. 开发者负责专业执行——业务逻辑与数据留在自己手里，尤其是端侧 A2A 这种"数据不出端"的模式；
3. 能拆就拆成 Skill——原子能力比大而全的能力更容易被正确调用；
4. 组合编排是差异化的来源——系统 Skill 与生态 Skill 串起来，才能做出别人抄不走的体验。

如果你的鸿蒙应用已经有明确的服务场景，现在需要判断的就是一件事：它是一个"智能体"，还是一组"技能"？

关于我

13 年 IT 全栈，.NET、Python、Office 自动化（VSTO/VBA/Python）都做，也做 AI 应用实操（智能体开发），主业是帮企业和团队把重复劳动自动化——报表一键生成、数据对接、文档批量处理、工具定制。

本科物理化学、硕士计算机化学，在一线实验室待过 13 年（9 年制药 + 4 年第三方检测），现在主要服务药企、检测机构和实验室：SOP、合规、样本流、仪器数据接口这些词不用你解释。

这几年做得比较多的是这几类：Office 自动化（VSTO/VBA/Python）工具定制、数据对接与 LIMS 咨询、技术陪跑。

不是外包码农，是听得懂业务的自己人。有同类场景的朋友欢迎评论区聊聊，先聊清楚再动手不迟。