HDC 2026 开完之后，群里问得最多的一个问题就是：A2A 到底是什么？跟我们之前写的 Agent Framework Kit 有什么关系？

说实话，我一开始也有点懵。毕竟文章 67 里刚写完 FunctionComponent 的接入方式——传个 agentId、放个按钮就完事了，那 A2A 又是什么新东西？

后来花了一周把 HDC 的技术文档和演示案例都翻了一遍，才算理清楚。这篇就把我的理解写出来，顺便把几个容易混淆的概念捋一遍。

A2A 不是新功能，而是新架构

先纠正一个常见的误解：很多人觉得 A2A 是 HarmonyOS 7 新增的一个 API。

不对。A2A（Agent to Agent）在 HarmonyOS 6 里就有了——超过 80 款头部应用已经接入了 A2A 协议，小艺可以作为主 Agent 调度第三方子 Agent 完成任务。比如对着小艺说"帮我用深圳航空选个靠窗座位"，小艺就会拉起深航的智能体"深航飞飞"来执行值机。

HarmonyOS 7 做的不是"发明 A2A"，而是把整个操作系统的底层架构从"App 亲和"推向了"Agent 亲和"。具体体现在三件事：

1. HMAF 2.0 框架发布，围绕 Agent、Skill、元服务、意图框架、MCP 构建了一套完整的开发路径
2. 系统能力全面 Skill 化——200 多个系统级能力被封装成 Skill，从日程、人脉到运动健康全都能被 Agent 调用
3. A2A 协议升级支持端侧直连——以前 Agent 之间的协作需要走云端，现在可以在设备本地完成

第三点是最值得关注的，因为它直接改变了接入方式。

端侧直连和云侧接入有什么区别

HarmonyOS 6 的 A2A 模式是这样的：

用户说话 → 小艺理解意图 → 小艺通过云端找到目标 Agent → 目标 Agent 执行 → 结果返回给小艺

整个链路要经过云端中转。对于大部分场景够用了，但如果涉及实时性要求高的任务（比如视频播放控制、传感器数据联动），延迟就比较明显了。

HarmonyOS 7 新增了端侧直连：

用户说话 → 小艺理解意图 → 小艺直接在设备上找到目标 Agent → 目标 Agent 在本地执行 → 结果实时返回

不经过云端，全在设备上完成。据 HDC 演示，腾讯视频已经通过端侧直连实现了小艺直接控制视频播放、搜索、暂停等操作，响应速度明显提升。

对开发者来说，这意味着两件事：

• 你的 Agent 需要能同时在云端和端侧被调用
• 端侧 Agent 的执行环境跟云端不一样，需要考虑设备资源限制

端侧 Skill：跟着 App 一起发布的新形态

这是 HarmonyOS 7 最值得关注的变化之一。

以前 Agent 的能力都是在云端定义的——你在小艺开放平台创建智能体、配置角色指令、绑定插件，所有逻辑都跑在云上。用户调用的时候，小艺通过网络跟你的云端 Agent 通信。

HMAF 2.0 引入了 Ark Agent Framework，支持端侧 Skill 和云端 Skill 两种形态：

• 云端 Skill：跟之前一样，在小艺开放平台配置，跑在你的服务器上
• 端侧 Skill：跟着你的 App 一起发布和上架，代码跑在用户设备上

端侧 Skill 的好处很直接：

1. 不需要你自己搭后端服务器，省了服务器成本
2. 响应快，不用走网络
3. 可以直接调用 App 本地的数据和能力（比如本地数据库、文件系统、传感器）
4. 离线也能用

一个实际案例：《时光旅记》的开发者在 HDC 上分享，他通过 Agent Framework Kit 接入小艺智能体，实现了旅行照片地点历史故事自动回顾。这个功能的 Skill 就是端侧的——用户拍的照片存在本地，历史故事的生成和展示也在本地完成，不需要把照片上传到云端。

据他分享，整个接入过程只花了 10 分钟。

三种接入路径怎么选

HMAF 2.0 给开发者提供了三条路径接入小艺的 Agent 生态，适用于不同的场景和团队情况：

路径一：云侧 A2A（适合已有后端服务的团队）

如果你的应用已经有后端 API，最快的接入方式还是云侧 A2A。流程跟 HarmonyOS 6 基本一致：

1. 在小艺开放平台创建智能体，选择 A2A 模式
2. 配置你的云端 Agent 通信协议
3. 定义端 A2A 协议的消息指令（请求/响应 Schema）
4. 绑定 Intents Kit 意图，让小艺能找到你

这条路适合电商、社交、金融这些本身就重度依赖后端的应用。你的 Agent 本质上就是对你已有 API 的一层封装。

路径二：端侧 Skill（适合轻应用和工具型 App）

如果你的应用比较轻量，或者核心数据都在本地（比如记账、笔记、健身记录），端侧 Skill 是更好的选择。

开发流程：

1. 在 DevEco Studio 中创建 Skill 模块（Ark Agent Framework）
2. 定义 Skill 的能力描述（告诉小艺"我能做什么"）
3. 实现 Skill 的执行逻辑（ArkTS 代码，跑在设备上）
4. 发布 App 时 Skill 随 App 一起上架

端侧 Skill 的核心代码结构大致是这样：

// Skill 的能力描述——小艺通过这个理解你的 Skill 能做什么
const skillDescriptor = {
  name: 'localNoteSearch',
  description: '在本地笔记中搜索关键词，返回匹配的笔记列表',
  parameters: {
    keyword: { type: 'string', description: '搜索关键词', required: true },
    limit: { type: 'number', description: '返回结果数量上限', default: 10 }
  }
}

// Skill 的执行逻辑
async function executeSkill(params: Record<string, Object>): Promise<SkillResult> {
  const keyword = params['keyword'] as string
  const limit = (params['limit'] as number) ?? 10

  // 直接操作本地数据库
  const results = await localDb.searchNotes(keyword, limit)

  return {
    success: true,
    data: results
  }
}

注意几个关键点：

• description 写得越清晰，小艺的意图匹配越准确
• 端侧 Skill 跑在用户设备上，不要做太重的计算
• 可以直接调用 App 本地数据，这是相比云侧 Skill 的最大优势

路径三：MCP 接入（适合工具链和外部服务集成）

MCP（Model Context Protocol）是去年开始流行的一种标准化协议，HarmonyOS 7 也支持了。它的定位是让你已有的外部工具和服务能被 Agent 直接调用。

适合场景：你的团队已经在用一些第三方工具（比如 CRM、项目管理、监控告警），想把这些能力接入小艺的 Agent 生态。

MCP 的好处是协议标准化程度高，对接成本低。但坏处是灵活性不如 A2A 和端侧 Skill，复杂的多轮交互场景不太好处理。

A2UI：让 Agent 的输出不再只有文字

这是 HDC 2026 上另一个容易被忽略但很有价值的更新。

A2UI 协议解决的是一个实际痛点：Agent 执行完任务后，返回的结果通常是一段文字。但对于购物订单、日程安排、航班信息这些结构化数据，纯文字展示体验很差。

A2UI 的思路是把 Agent 的输出封装成 UI 组件。小艺开放平台基于鸿蒙 A2UI 协议，实现了低门槛的 UI 对接，设备端直接渲染 Agent 返回的结构化界面。

比如用户对小艺说"帮我查一下明天北京到上海的高铁"，Agent 返回的不是一段文字描述，而是一个可交互的列车列表卡片——用户可以直接点击选择、查看座位、跳转购票。

对开发者来说，A2UI 意味着你需要为你的 Skill 定义一套 UI Schema，描述返回结果的展示形式。这部分工作量不大，但对用户体验提升明显。

Intents Kit 的角色变了

在 HarmonyOS 6 里，Intents Kit 主要是给 App 注册"我能做什么"的声明入口。用户通过系统入口或者小艺触发意图，App 响应处理。

在 HarmonyOS 7 里，Intents Kit 的角色升级了——它成了 A2A 协议的核心调度器。当小艺接收到用户指令后，先通过 Intents Kit 理解意图，然后在系统级别找到匹配的 Agent 或 Skill，完成精准分发。

据 HDC 公布的数据，小艺目前已经覆盖了 2100 多个系统级 Skill，精选 500 多个，以及 2000 多个设备形态模板。这些 Skill 的分发全靠 Intents Kit 的意图理解能力。

这对开发者的影响是：你的 Skill 描述和意图注册越精准，被小艺分发到的概率就越高。这有点像 SEO——你的"关键词"写得越准确，流量越大。

实际接入时的几个坑

虽然 HarmonyOS 7 目前还是 Beta 阶段，但基于 HDC 放出的文档和社区里早期尝鲜的开发者反馈，有几个点需要提前注意。

坑 1：端侧 Skill 和云端 Skill 的命名冲突

Ark Agent Framework 里，端侧 Skill 和云端 Skill 的 name 不能重复。如果你在云侧定义了一个叫 searchNote 的 Skill，端侧又定义了一个同名的，系统会优先调用端侧的，而且不会给你任何警告。

建议在命名时加上前缀区分，比如 local_searchNote 和 cloud_searchNote。

坑 2：端侧 Skill 的执行超时

端侧 Skill 跑在用户设备上，系统对执行时间有严格限制（目前社区反馈是 3 秒左右）。如果你的 Skill 需要做复杂的数据处理或者网络请求，很容易超时。

解决方法：

• 数据处理尽量异步化，先返回"处理中"状态，后续通过回调更新结果
• 避免在 Skill 执行逻辑里做同步网络请求
• 如果确实需要长时间操作，考虑拆成多个 Skill 串联

坑 3：A2UI Schema 的版本兼容

A2UI 协议目前还在快速迭代，HDC 放出的版本和最终稳定版可能会有差异。如果你的 Skill 返回的 UI Schema 字段在旧版系统上不存在，渲染会静默失败——不会报错，但用户看到的是空白卡片。

建议在 Schema 里做好 fallback，确保即使 A2UI 渲染失败，至少有文字兜底。

坑 4：意图匹配的"模糊地带"

Intents Kit 的意图理解能力虽然很强，但对于模糊指令的匹配还是会有偏差。比如用户说"帮我记一下明天下午开会"，小艺可能把"开会"匹配到日历 Skill 而不是你的笔记 Skill。

这个问题没有太好的技术手段解决，目前社区的做法是在 Skill description 里尽可能多地覆盖用户可能的表述方式，相当于做"语义 SEO"。

三种路径怎么选？一张表总结

从 HarmonyOS 6 迁移到 HarmonyOS 7 的注意事项

如果你之前在 HarmonyOS 6 上已经接入了 Agent Framework Kit（比如用了 FunctionComponent），迁移到 HarmonyOS 7 不需要推翻重来。FunctionComponent 组件依然可用，你的 App 还是可以通过按钮拉起小艺智能体。

HMAF 2.0 是增量升级，不是替代。新的 A2A 端侧直连和端侧 Skill 是额外能力，你可以根据需要选择性接入。

不过有一点需要注意：HarmonyOS 7 的 API 26 SDK 里，Agent Framework Kit 的部分接口有调整。如果你之前用的是 @kit.AgentFrameworkKit 里的底层 API（不是 FunctionComponent），建议检查一下 API 变更日志。FunctionComponent 的用法没有变化，这点可以放心。

我的判断

Agent 亲和架构是鸿蒙从"应用操作系统"走向"智能体操作系统"的关键一步。对开发者来说，短期看端侧 Skill 是最容易出成果的方向——不需要后端，ArkTS 直接写，跟 App 一起发布，上手快。

中长期看，A2A 端侧直连才是真正的杀手锏。当越来越多的应用完成 Agent 化改造，Agent 之间的本地协作会产生很多现在想象不到的新场景。就像当年智能手机刚出来的时候，没人能想到移动支付会彻底改变生活一样。

不过现阶段鸿蒙 7 还是 Beta，API 可能还会有调整。建议大家先把端侧 Skill 的文档和示例跑通，等正式版发布后再做生产环境部署。