当操作系统开始“理解意图”：鸿蒙 AI 如何改变开发者的工作方式

想进一步了解文中提到的开发工具，欢迎开发者查阅官方教程： 快速入门 DevEco CLI ，让 AI Agent 更懂 HarmonyOS 应用开发，更有牛人带你 玩转 HarmonyOS AI Coding 提效工具 DevEco Code 和 DevEco CLI。

距离 HarmonyOS 7 开发者 Beta 在 HDC 2026 亮相，已经过去两个月。一个系统版本的分量，往往要在发布之后才逐渐显现：性能数据和功能清单容易被迅速看见，架构选择、工具边界及其对生态的影响，则需要放到更具体的开发语境中审视。

围绕 HarmonyOS 7 的新特性与 AI Agent 能力、开发工具的实际体验与局限、鸿蒙与 iOS 和 Android 的技术路线差异，以及生态发展和开发者的下一步选择，InfoQ 与 资深全栈工程师、架构师、鸿蒙生态布道师刘光智 展开了这次对话。

在刘光智看来，衡量 Agent 的价值，既不能只看系统增加了多少功能，也不能只看 AI 生成了多少代码。更关键的是，研发流程能否形成闭环，开发态 Agent 与运行态 Agent 能否真正打通。

当 AI 不仅参与把应用写出来，也开始影响系统如何理解和调用应用时，它可能改变的，将是开发者写代码、做应用的底层方式。

InfoQ：站在开发者的角度看，HarmonyOS 7 这一版最大的变化是什么？

刘光智： 市面上很多报道都在讨论 HarmonyOS 7 的性能提升、速度变化和新增功能。这些内容都很重要，但我更想强调另一件事：HarmonyOS 7 最大的变化，不是某一个具体功能，而是整个系统底层开始围绕 Agent 重新组织。

过去的操作系统，本质上是一个安装和运行应用的地方。用户想完成一件事，需要先确定应该使用哪个应用，再打开应用，一步步完成操作。

HarmonyOS 7 想做的是把这个过程反过来。用户只需要说出自己的意图，系统再判断应该调用哪些能力，并将这些能力组织起来，帮助用户完成任务。

InfoQ：你刚才提到的这个转变，要真正落地，核心是什么？

刘光智： 核心是升级到 2.0 版本的鸿蒙智能体框架，也就是 HMAF 2.0。

第一层是小艺。它是系统级智能助手，也是用户进入这套体系的入口。用户可以直接向它表达需求。

第二层是 HMAF 2.0。它负责任务拆解，把用户的一句话拆成多个步骤，同时管理多个智能体之间的沟通与配合。

第三层是 AI 底座，包括开源大模型 openPangu 2.0 和端侧 30B 模型。

第四层是系统层面的保障，包括方舟引擎、星盾安全和星河互联。

第五层是开发者工具，包括 DevEco Code 和 DevEco CLI。

这六层呈现了 HarmonyOS 7 围绕 Agent 建立的整体技术体系。开发者端最直接的变化，是应用不再只是被动等待用户点开，而是可以把自己暴露成一个"可被系统调度"的智能体。大会现场有一个非常直观的演示——用户只说了一句"帮我报名马拉松"，小艺就把需求拆成多个子任务，调度"运动健康""日程""搜索"等不同子智能体，让它们互相沟通、并行推进。

落到代码层面，一个应用如何把自己交给系统调度，本质上就是一件事：用 HMAF 的能力注册一个可被识别的智能体，把意图、参数和回调暴露出去。下面是一个简化的示意，一个马拉松报名相关的能力如何接入 HMAF：

// 接入 HMAF：注册一个"赛事报名"能力，让系统级智能体（小艺）能调度到它 import { agentService } from '@kit.AgentKit' ; @agentService .AgentExtension export default class MarathonAgent extends agentService . AgentExtension { // 声明该智能体支持的能力与参数 schema，供系统做意图匹配 declareCapabilities(): agentService.Capability[] { return [{ id : 'sign_up.marathon' , description: '报名某场马拉松赛事' , inputSchema: { type : 'object' , properties: { race: { type : 'string' , description: '赛事名称' }, date : { type : 'string' , description: '比赛日期' }, location: { type : 'string' , description: '举办城市' } }, required: [ 'race' , 'date' ] } }]; } // 系统把拆解后的子任务分发进来，这里拿到的是结构化参数，而不是一句自然语言 async onInvoke(task: agentService.TaskInfo): Promise { const { race, date } = task.arguments; // 这里可以调用健康数据、支付、日程等多个 skill 协同 const schedule = await this .invokeSkill( 'calendar.add_reminder' , { race, date }); return { status: 'success' , result: schedule }; } } 复制代码

这跟"一个语音助手调用一个 API"不是同一层面的复杂度。过去是你问我答、单点调用；现在用户只要表达意图，系统通过 declareCapabilities 做意图匹配，通过 onInvoke 把结构化任务分发下来，背后是多个智能体在协作。

InfoQ：除了 Agent 能力，这一版还有哪些技术变化值得关注？

刘光智： openPangu 2.0 这次也开源了。Pro 版有 5050 亿参数，Flash 版有 920 亿参数，两个版本都支持 512K 超长上下文。

不过，我认为重点不只是参数规模，而是“昇腾原生”。按照官方说法，openPangu 2.0 的单卡吞吐率可以达到主流开源模型的两倍。相比单纯比较参数量，这个定位更值得关注。

在性能方面，HarmonyOS 7 的调度层首次引入“性能大模型”。系统应用启动速度提升 24%，生态应用启动速度提升 34%，游戏帧率稳定性提升 40%；年度负载增长则控制在 10%以内，低于行业平均水平。

安全方面，星盾安全架构使用端侧 AI 防范诈骗，可以秒级识别七大类诈骗套路。目前已经帮助用户识破 347 万次潜在骗局，支付宝、抖音等主流应用也已经接入。

InfoQ：从开发者实际使用的角度看，这次工具链有哪些变化？

刘光智： 我把这次鸿蒙的开发工具路线称为“双轨制”。

一条是 DevEco Code。它“自带大脑”，类似自动驾驶中的副驾驶。开发者给出需求后，它可以自主规划、编写代码、编译调试，遇到报错还能够自动修复。

另一条是 DevEco CLI。它本身不负责决策，而是负责开放能力，把工程管理、构建检查、运行调试等鸿蒙原子能力转化为命令。无论使用 Claude、Cursor，还是团队自己搭建的 Agent，都可以接入并调用这些能力。

两条路线覆盖不同的人群。DevEco Code 适合新团队和新项目，用于从零到一快速交付；DevEco CLI 适合已经拥有 Agent 体系的大型团队。这些团队不需要改变原有的开发方式，只需将鸿蒙能力接入现有体系。

InfoQ：如果进一步看工具内部，它的技术实现和工作方式是怎样的？

刘光智： DevEco Code 由华为自研的毕方引擎和开源框架 OpenCode 叠加构成。

毕方所处的位置对标 Claude Agent SDK，负责 Agent 如何思考、规划和调用工具，可以理解为整套工具的“大脑”。

OpenCode 负责终端交互、配置体系，以及 MCP、Skill、Plugin 等开放生态，可以理解为工具的“骨架和接口”。

之所以同时使用两者，我的理解是，自研部分能够与鸿蒙工具链进行更深入的打通和优化，包括 DevEco Studio、Hvigor 构建和 HDC 设备调试；保留开源部分，则能够利用开源生态，任何支持 MCP 协议的第三方工具都可以直接接入。

自研保证鸿蒙原生优化，开源保证生态兼容，两者缺一不可。

DevEco Code 内部采用两个智能体协同的架构。Plan Agent 负责理解需求，并将其拆分成执行计划； Build Agent 负责执行，包括编写代码、编译和调试，出现错误后还会自动修复。

而且它不只工作在命令行，还会直接改写工程里的资源与页面。拿"一多适配"做个例子，传统做法是开发者自己写条件渲染判断设备类别，DevEco Code 的 Plan Agent 会在你的 ArkTS 组件里自动生成这样一段代码：

/ / ArkTS 声明式 UI： @Entry 标记入口组件， @State 管理状态 @Entry @Component struct HomePage { @State greeting: string = '你好，鸿蒙' ; // 一多适配：根据屏幕宽度自动切换横竖屏布局，DK 会帮你在计划阶段就补齐这段 @Builder GridOfMedia ( size: BreakPoint ) { if (size === BreakPoint.MD) { // 中屏：卡片一行两个 Row ( ) { this .Card( '左侧' ); this .Card( '右侧' ) } } else { // 小屏/大屏：走各自布局 Column ( ) { this .Card( '单列' ) } } } build ( ) { Column ( { space: 16 } ) { Text( this .greeting).fontSize( 28 ).fontWeight(FontWeight.Bold) this .GridOfMedia( this .currentPoint()) // 依据媒体查询取断点 } .padding(16) .width( '100%' ) .height( '100%' ) } } 复制代码

真正的差异不在语法，而在编排：当用户的需求带上了"手机电视都要能用"这类约束时，Plan Agent 会在计划里主动插入 @Builder 按断点分支、以及 .distribution 这类跨端能力声明，而不是等开发者事后补。这就是"开发态 Agent"进入产品逻辑的开始。