鸿蒙HMAF 2.0智能体接入与DevEco工具链实践

鸿蒙专家

HarmonyOS 7在HDC 2026亮相已两个月，各方报道大多聚焦性能数据和新增功能，但在资深全栈工程师、鸿蒙生态布道师刘光智看来，这一版本真正的变化是系统底层开始围绕Agent重新组织，而非某个具体功能的增减。下面结合InfoQ对刘光智的采访内容，梳理HarmonyOS 7在智能体框架和AI开发工具链上的实际变化，以及开发者在接入过程中需要关注的问题。

一、HMAF 2.0：系统级智能体框架的六层架构

HarmonyOS 7面向Agent重组后，技术体系分为六层：第一层是小艺，作为系统级智能助手承接用户意图；第二层是HMAF 2.0，即鸿蒙智能体框架，负责任务拆解与多智能体间的沟通协同；第三层是AI底座，包括开源大模型openPangu 2.0与端侧30B模型；第四层是系统保障，涉及方舟引擎、星盾安全与星河互联；第五层是开发者工具DevEco Code与DevEco CLI；第六层是具体场景接入，如空间计算。

对开发者而言，最直接的变化是应用不再只是被动等待用户点开，而是可以把自己注册为可被系统调度的智能体。HDC现场演示中，用户只说了一句“帮我报名马拉松”，小艺就将需求拆成多个子任务，调度运动健康、日程、搜索等子智能体并行推进。落到代码层面，接入HMAF的核心是将意图、参数schema和回调暴露给系统，示意代码如下：

2. import { agentService } from '@kit.AgentKit';
4. @agentService.AgentExtension
5. export default class MarathonAgent extends agentService.AgentExtension {
6.   declareCapabilities(): agentService.Capability[] {
7.     return [{
8.       id: 'sign_up.marathon',
9.       description: '报名某场马拉松赛事',
10.       inputSchema: {
11.         type: 'object',
12.         properties: {
13.           race: { type: 'string', description: '赛事名称' },
14.           date: { type: 'string', description: '比赛日期' },
15.           location: { type: 'string', description: '举办城市' }
16.         },
17.         required: ['race', 'date']
18.       }
19.     }];
20.   }
22.   async onInvoke(task: agentService.TaskInfo): Promise<agentService.TaskResult> {
23.     const { race, date } = task.arguments;
24.     const schedule = await this.invokeSkill('calendar.add_reminder', { race, date });
25.     return { status: 'success', result: schedule };
26.   }
27. }

复制代码

这里的关键在于，系统通过declareCapabilities做意图匹配，通过onInvoke把结构化任务分发下来，多个智能体在后台协作。这不同于传统语音助手的单点问答，而是系统级的任务编排。

openPangu 2.0同步开源，Pro版5050亿参数、Flash版920亿参数，均支持512K上下文。官方称其单卡吞吐率可达主流开源模型的两倍，“昇腾原生”是比参数规模更值得关注的定位。性能方面，HarmonyOS 7调度层引入性能大模型后，系统应用启动速度提升24%，生态应用提升34%，游戏帧率稳定性提升40%。星盾安全架构利用端侧AI秒级识别七大类诈骗套路，已识破347万次潜在骗局，支付宝、抖音等主流应用已接入。

二、DevEco Code与DevEco CLI：双轨工具链的定位与实现

鸿蒙工具链目前采用双轨制。DevEco Code自带Agent能力，类似自动驾驶副驾驶，开发者在给出需求后，它可以自主规划、编写代码、编译调试，遇到报错还能自动修复。DevEco CLI则把工程管理、构建检查、运行调试等原子能力转化为命令，本身不负责决策，方便Claude、Cursor或团队自建Agent直接调用。两者的分工很清晰：DevEco Code适合新团队从零到一快速交付，DevEco CLI适合已有Agent体系的大型团队，将鸿蒙能力接入现有流水线，不需要改变原有开发方式。

DevEco Code的技术底座是华为自研的毕方引擎叠加开源框架OpenCode。毕方对标Claude Agent SDK，负责Agent的思考、规划与工具调用，是整套工具的“大脑”；OpenCode负责终端交互、配置体系以及MCP、Skill、Plugin等开放生态。自研部分保证与DevEco Studio、Hvigor构建、HDC设备调试的深度打通，开源部分则保证支持MCP协议的第三方工具可直接接入，两者互补。

在具体实现上，DevEco Code内部采用Plan Agent与Build Agent双智能体协同。Plan Agent负责理解需求并拆解执行计划，Build Agent负责编码、编译、调试和自动修复。一个典型场景是“一多适配”。传统写法要求开发者自行写条件渲染判断设备类别，而DevEco Code的Plan Agent会在ArkTS组件中自动生成断点分支代码：

2. @Entry
3. @Component
4. struct HomePage {
5.   @State greeting: string = '你好，鸿蒙';
7.   @Builder
8.   GridOfMedia(size: BreakPoint) {
9.     if (size === BreakPoint.MD) {
10.       Row() {
11.         this.Card('左侧')
12.         this.Card('右侧')
13.       }
14.     } else {
15.       Column() {
16.         this.Card('单列')
17.       }
18.     }
19.   }
21.   build() {
22.     Column({ space: 16 }) {
23.       Text(this.greeting).fontSize(28).fontWeight(FontWeight.Bold)
24.       this.GridOfMedia(this.currentPoint())
25.     }
26.     .padding(16)
27.     .width('100%')
28.     .height('100%')
29.   }
30. }

复制代码

真正的差异不在语法而在编排。当需求中带有“手机电视都要能用”这类约束时，Plan Agent会在计划阶段主动插入@Builder断点分支和.distribution跨端能力声明，而不是等开发者事后补写。这是开发态Agent进入产品逻辑的开端。

三、实践中的三个瓶颈

鸿蒙AI工具在真实项目中仍有明显短板。首先是碎片化适配问题。鸿蒙机型从旗舰到入门覆盖多个价位段，屏幕尺寸、芯片、内存和系统API版本各不相同，加上平板、车机、穿戴等终端形态不断增加，中小团队通常只有少量真机，安装失败、启动闪退、界面变形、机型卡顿等问题往往在上线后才暴露在用户设备上。华为提供了EasyGo平行视界，通过一个配置文件即可让应用在折叠屏和平板上获得横屏大视野；多设备UX自动检测工具则能识别大图大字、界面截断、内容重叠等布局问题，并定位到源码位置。这些工具正在把过去依赖人工真机测试的工作推向自动化和AI辅助。

其次是平台支持问题。DevEco Code目前不支持Linux，编译、构建和调试只能在Windows与macOS上完成，对开源社区和服务器端开发不够友好。再次是语料问题。通用大模型中的ArkTS语料远少于Swift和Kotlin，同样工具用于ArkTS时效果偏弱，AI生成的代码大约有15%到20%需要人工修正。Swift和Kotlin积累多年，ArkTS发展时间较短，这种差距很难仅靠工具短时间追平。开源项目harmonyos-ai-skill尝试以一份Markdown知识文件补偿，完成一次配置后，Claude、Cursor、Copilot等主流AI工具均可获得鸿蒙知识补充。

四、快手案例：专项Skill比通用代码生成更有效

快手是HDC引用的一段真实生产环境案例。使用鸿蒙AI工具后，其开发阶段AI代码生成率达80%，AI生成测试用例直接采纳率84%，运维排障中AI修复建议采纳率73%，团队综合人效提升1.7倍。过去一名工程师只能交付一个手机端，现在两名工程师在不额外增加鸿蒙人力的情况下，可同时交付手机、平板和车机三个端。

最值得关注的细节并不是80%的生成率。快手原本有自研AI编程工具Kwaipilot，内部代码生成率早已从1%提升到30%，部分业务线达40%，但需求交付效率几乎没有变化——因为代码编写只是交付链路中的一个环节，分析、设计、改造和验证不加速，整条链路就不会明显提速。后来快手与鸿蒙团队采用“Agent Loop双循环”方案，针对鸿蒙并发安全改造开发了专项Skill：Ark Refiner-Sendable，将分析、定位、改造、验证全流程自动化。传统写法中，对象跨Taskpool或Worker传递时因缺少可序列化标记，常在运行时静默产生数据竞争，改造后的写法如下：

2. import { TaskPool } from '@kit.ArkTS';
4. @Sendable
5. export class PlayerState {
6.   positionMs: number = 0;
7.   volume: number = 0.7;
8.   isPlaying: boolean = false;
9. }
11. let state = new PlayerState();
12. let task = new TaskPool.Task(async () => {
13.   return state.positionMs;
14. });
15. let result = await TaskPool.execute(task);

复制代码

原本两个人一周完成的工作，用这个Skill半天即可完成，冷启动性能还提升了16%。这个案例说明，针对具体工程问题开发专项Skill的路径是可行的，比单纯追求代码生成率更有意义。需要注意，这是发布会中的官方案例，可能选用了最佳实践样本，未必代表大多数团队，但方法本身可以复制。

五、团队下一步怎么选

调研机构Counterpoint今年5月的数据显示，鸿蒙在中国智能手机操作系统市场份额已达19%，连续七个季度超过iOS，注册开发者超1100万，应用和服务超40万，但其中完成原生适配的只有2.3万。适配缺口巨大，AI工具的意义在于填补这个缺口，让一个人承担过去几个人才能完成的工作。

对开发者的建议可以归纳为三点。第一，尽早明确团队适合DevEco Code还是DevEco CLI：新项目或需快速启动的团队选Code，已有存量系统的团队通过CLI把鸿蒙能力接入现有流水线，无需推倒重来。第二，关注现有70多个精品Skill，并发安全改造等鸿蒙特有问题已有人封装为Skill，可直接使用，避免重复投入。第三，使用harmonyos-ai-skill这类社区知识包，一次配置即可让常用AI工具获得鸿蒙知识，性价比很高。

苹果、谷歌与华为在AI开发工具上的路线差异也值得开发者留意。苹果Xcode 27走开放接入路线，通过mcpbridge桥接MCP协议与XPC通信，开放20个内置工具供Claude、Codex、Gemini等第三方Agent接入。谷歌停掉开源Gemini CLI改为闭源Antigravity，由于Gemini CLI曾有大量社区贡献，这一变化引发反弹。华为走双轨并行，DevEco Code登录后免费使用，内置智谱GLM-5.1，每分钟可调用50次，同时允许开发者切换DeepSeek、OpenAI等兼容模型。模型策略的差异背后是生态优先级的不同：鸿蒙现阶段更需要吸引开发者，先做大规模。Skill生态方面，苹果与华为均采用SKILL.md开源格式，“Skill-as-Code”已经在三大平台间形成事实标准。

鸿蒙的Agent路线能否真正区别于苹果和谷歌，最终取决于开发态Agent与运行态Agent能否深度打通：让AI写出的应用，能被AI调度的操作系统无缝识别与调用。目前HarmonyOS 7在Linux支持、语料积累和生态成熟度上仍有不足，但这一方向已经清晰，也是开发者在选型鸿蒙时值得重点评估的部分。

热心网友1

楼主这篇梳理得很扎实，把 HarmonyOS 7 底层“围绕 Agent 重组”这条主线讲清楚了。之前看发布会确实只盯着性能数据，忽略了 HMAF 2.0 对开发模式的改变。 我个人最感兴趣的是 declareCapabilities 这套意图注册机制——应用不再只是被动等用户打开，而是把能力“挂”到系统里让小艺调度，这个思路已经超越传统语音助手范畴了。不过有点担心接入门槛，像 inputSchema 这种结构化定义，对老项目改造工作量会不会很大？DevEco Code 的 Plan/Build 双 Agent 协作看着挺美，但自动生成断点分支那类代码，实际工程里遇到复杂业务状态时，调试成本会不会反而提升？可能还是得等更多实践案例。 另外楼主提到 DevEco CLI 让已有 Agent 体系直接调用，这个对团队吸引力很大，毕竟不用全盘换工具。希望后续能看到更多关于 CLI 原子能力覆盖范围的分享。

热心网友1

读完全文，感觉这才是HarmonyOS 7真正值得关注的部分——不是跑分和功能列表，而是系统从“应用为中心”转向“Agent为中心”的底层重构。HMAF 2.0把应用注册成可被调度的智能体，配合小艺做任务编排，这个思路确实比单纯堆语音助手能力要领先一步。 代码示例很直观，declareCapabilities暴露能力schema，onInvoke接收结构化任务，这种模式对开发者来说学习成本不算高。不过我也在想几个实际问题：比如多个智能体同时声明相似能力时，系统如何做冲突消解？还有权限模型，用户说一句话触发的多智能体协作，是否每一步都需要单独授权？ DevEco Code和DevEco CLI双轨制很有意思。对个人开发者或小团队，Agent化的IDE确实能加快一多适配这类繁琐工作；对已经有成熟CI/CD体系的大厂，CLI方式则更友好，能无缝嵌入现有流水线。毕方引擎加OpenCode的组合，既保证了对鸿蒙特有能力的深度打通，又保留了开放的MCP生态，思路挺务实。 希望后续能看到更多关于HMAF 2.0的实战文章，尤其是多智能体协作的调试技巧和性能瓶颈分析。

热心网友1

楼主的梳理很清晰，尤其把HMAF 2.0的六层架构和DevEco双轨工具链的分工讲得比较透彻。我比较关注的是 `declareCapabilities` 这套意图描述机制——它如何保证第三方应用声明的 schema 不会和小艺自身的意图解析产生冲突？另外，DevEco CLI 既然是把构建、调试变成原子命令，那它在和现有 CI/CD 流水线对接时，对于多设备签名和权限配置这些环节，是否有现成的最佳实践可以分享？期待后续能有更细的落地方案。