想进一步了解文中提到的开发工具，欢迎开发者查阅官方教程：快速入门 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 不仅参与把应用写出来，也开始影响系统如何理解和调用应用时，它可能改变的，将是开发者写代码、做应用的底层方式。
以下内容根据采访整理。
HarmonyOS 7 开始围绕 Agent 重新组织
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.AgentExtensionexport 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<agentService.TaskResult> { 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@Componentstruct 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"进入产品逻辑的开始。
InfoQ：在真实项目中，目前最突出的问题是什么？
刘光智： 对中小团队而言，鸿蒙的碎片化适配是目前最棘手的问题。
鸿蒙机型从旗舰到入门覆盖多个价位段，不同设备的屏幕尺寸、芯片、内存和系统 API 版本都不相同。再加上平板、车机、穿戴设备等终端形态不断增加，中小团队通常只有少量测试设备，很难实现完整覆盖。
因此，很多问题并不是在开发阶段被发现，而是在应用上线后才出现在用户设备上，例如安装失败、启动闪退、界面变形，或者某个机型出现卡顿。
这些问题一旦流向用户端，就会造成用户流失和口碑损失。
InfoQ：针对这些问题，目前有哪些应对办法？还有哪些不足？
刘光智： 华为提供了一些针对性工具。例如 EasyGo 平行视界，开发者只需编写一个配置文件，就能让应用在折叠屏和平板上获得横屏大视野体验，适配成本比较低。
多设备 UX 自动检测工具可以识别大图大字、界面截断、内容重叠等典型布局问题，并直接定位到源码中的具体位置。过去，这些工作主要依靠人工在真机上逐一测试，现在开始向自动化和 AI 辅助方向推进。
不过，目前仍有几个比较明显的问题。
第一，DevEco Code 不支持 Linux。编译、构建和调试只能在 Windows 和 macOS 上完成，这对开源社区和服务器端开发不太友好。
第二，它仍然比较依赖 DevEco Studio，纯命令行的使用体验有限。
第三，也是我认为影响最大的一点，通用大模型中的 ArkTS 语料仍然较少。AI 编写 Swift 或 Kotlin 能够做到开箱即用，是因为训练数据比较多；同样的工具用于 ArkTS 时，效果会弱一些，生成的代码大约有 15%到 20%需要人工修正。
Swift 和 Kotlin 已经积累了很多年，ArkTS 的发展时间相对较短。这种差距来自语料积累，很难仅靠工具在短时间内追平。
社区也在进行补位。例如开源项目 harmonyos-ai-skill，将数千行鸿蒙开发知识浓缩成一份 Markdown 文件。完成一次配置后，Claude、Cursor、Copilot 等主流 AI 工具都可以补充鸿蒙知识，在一定程度上弥补语料不足的问题。
鸿蒙与 iOS、Android 的 Agent 路线分野
InfoQ：把鸿蒙与苹果、谷歌放在一起看，您观察到的最大差别是什么？
刘光智： HDC 2026 期间，苹果和谷歌也在各自的开发者大会上介绍 AI 开发工具，但三家的讲述方式不同。
苹果在 WWDC 上，将开发工具 Xcode 与运行时的 Apple Intelligence 作为两个独立叙事。谷歌在 I/O 上拆成四部分，AI 工具、模型、Android Studio 等内容分别开设 Session。
华为则在一场 Keynote 中，将开发态的 DevEco Code、DevEco CLI，与运行态的 HarmonyOS 7、小艺、HMAF 2.0 放在一起，形成“AI 操作系统一体化”的叙事。我刚才提到的 HarmonyOS 7 的六层架构，也正是因为这些能力被放在了同一张架构图中。
我认为，这不只是发布会内容如何编排的问题。如果一家公司将开发工具和系统级 AI 作为两套相互独立的体系推进，通常不会把它们放在同一张架构图中。
华为将这些内容放在同一张图里，因此我更愿意相信，其内部正在把开发态与运行态的 Agent 作为同一套战略推进。
InfoQ：如果进一步比较，三家的具体差异体现在哪些方面？
刘光智： 可以从三个维度来看。
第一个维度是架构哲学。
苹果采取“开放接入”的思路。Xcode 27 通过 mcpbridge 桥接机制，将通用 MCP 协议与苹果内部的 XPC 通信打通，并开放 20 个内置工具，Claude、Codex、Gemini 等第三方 Agent 都可以接入。
谷歌采取“云端一体”的思路。今年 5 月，谷歌停掉原本开源的 Gemini CLI，改为闭源的 Antigravity。由于 Gemini CLI 曾经有很多开发者贡献代码并进行二次开发，这一变化在开发者社区引发了不小的反弹。
华为则是“双轨并行”。一边是自带大脑的 DevEco Code，另一边是只开放能力的 DevEco CLI，同时面向独立开发者、存量团队和大型企业的 CI 体系。
第二个维度是模型策略，也就是 AI 的使用成本。
苹果的 Xcode 本身免费，但接入 Claude、Codex 等第三方模型需要单独付费，Claude Pro 每月从二十多美元起步。
谷歌深度绑定自家的 Gemini，企业版为每名用户每月 45 美元，今年又增加了 100 美元档位的订阅。
华为登录后即可免费使用，内置智谱 GLM-5.1，每分钟可以调用 50 次；同时允许开发者切换 DeepSeek、OpenAI 等兼容模型。
简单概括，苹果让模型在市场中竞争，谷歌通过企业版收费，华为则先让开发者免费进入。鸿蒙现阶段需要吸引更多开发者，优先把生态做起来。
第三个维度是 Skill 生态，即针对特定场景的技能插件。
苹果官方自研了几个 Agent Skill。谷歌采取托管路线，没有明确的本地 Skill 数量，以云端一体化替代；华为提供 70 多个精品 Skill，覆盖多设备开发、问题定位和元服务生成等场景。
一个值得注意的细节是，苹果和华为都采用 SKILL.md 这一开源格式。这意味着“Skill-as-Code”，也就是将技能作为代码编写的思路，已经在三大平台之间形成事实上的行业标准。
InfoQ：除了开发工具，底层操作系统还有哪些差异？
刘光智：
在跨设备互联方面，鸿蒙的分布式软总线把跨设备能力放在操作系统底层，属于原生能力，可以实现跨品牌即插即用。Android 依靠 Wear OS、Android Auto、Matter 等不同协议组合，每个品牌分别实现，体验差异较大。苹果的 Continuity 体验顺滑，但仅在苹果自身生态内互通。
这个差异在代码里也看得到。鸿蒙里跨设备调用一端能力，是系统级的、近乎同步的：
// 跨设备：从手机调用平板上某个能力，系统级软总线帮你完成设备发现与连接import { distributedData } from '@kit.ArkData';// 例如把当前视频流无缝迁移到最近的智慧屏await distributedData.applyDeviceProperty('deviceId', { type: 'video', uri: 'datashare://video/live', positionMs,});而在 Android 上，跨品牌设备协作往往要自己拼接协议、处理每家厂商不同的实现；在 iOS 上，这类能力被 Continuity/Handoff 封装在系统里，但只接受苹果自己的设备。跨端开发方面，ArkUI 是唯一真正跨越多品牌设备的一套代码方案，覆盖手机、平板、PC、车机、手表和大屏；Compose Multiplatform 仍在演进，SwiftUI 很成熟但只能在苹果生态内使用。
因此我的判断很明确：鸿蒙在这些维度上的差异化并非营销话术，而是有底层操作系统基因支撑。
开发态与运行态 Agent 能否真正打通
InfoQ：您怎么看鸿蒙生态目前的情况？
刘光智： 根据调研机构 Counterpoint 今年 5 月的报告，鸿蒙在中国智能手机操作系统市场的份额已经达到 19%，连续七个季度超过 iOS，稳居国内第二。注册开发者超过 1100 万，应用和服务超过 40 万个。
但在这 40 万个应用和服务中，真正完成原生适配的只有 2.3 万个。
之所以强调这个数字，是因为它说明，鸿蒙现在缺的并不是开发者，而是能够把开发者从“能力不足、精力不够”中解放出来的工具。
前面提到的 AI 工具，最终也是为了填补这个适配缺口，让一个人能够承担过去需要几个人完成的工作。
InfoQ：在实际项目中，这些工具带来了怎样的变化？
刘光智： 快手是 HDC 引用的真实生产环境案例。
使用鸿蒙的 AI 工具后，其开发阶段的 AI 代码生成率达到 80%，AI 生成测试用例的直接采纳率为 84%，运维排障中 AI 修复建议的采纳率为 73%，团队综合人效提升 1.7 倍。
过去一名工程师只能交付一个手机端；现在两名工程师在不额外增加鸿蒙人力的情况下，可以同时交付手机、平板和车机三个端。
InfoQ：这个案例中，最值得关注的细节是什么？
刘光智： 快手原本就有一套名为 Kwaipilot 的 AI 编程工具。其内部代码生成率很早就从 1%提升到 30%，部分业务线达到 40%，但团队的需求交付效率基本没有变化。
原因在于，写代码变快并不等于整个交付周期变快。代码编写只是其中一个环节，如果分析、设计、改造和验证依然缓慢，整条链路就不会明显加速。
后来，快手与鸿蒙团队共同采用“Agent Loop 双循环”方案，并开发了面向鸿蒙并发安全改造的专项 Skill——Ark Refiner-Sendable，将分析、定位、改造和验证整个流程自动化。
传统写法里，一个对象跨 Taskpool 或 Worker 传递，经常会因为缺少可序列化标记，在运行时静默出数据竞争。修复后的写法会像这样：
import { TaskPool } from '@kit.ArkTS';// @Sendable 让共享对象可以安全跨 Taskpool 线程传递，避免无意识的 data race@Sendableexport class PlayerState { positionMs: number = 0; volume: number = 0.7; isPlaying: boolean = false;}let state = new PlayerState();let task = new TaskPool.Task(async () => { // 子线程只读共享状态，主线程写，@Sendable 保证一致性 return state.positionMs;});let result = await TaskPool.execute(task);原本两个人需要一周完成的工作，用这个 Skill 半天即可完成，冷启动性能还提升了 16%。
因此，这个案例真正的价值不在于 80%的代码生成率，而在于它证明了针对具体工程问题开发专项 Skill 这条路可以走通，比单纯追求代码生成率更有意义。
当然，这是发布会中的官方案例，确实可能存在选择最佳案例的成分，未必能够代表大多数团队。但它所体现的方法可以复制，这一点具有真实价值。
InfoQ：从开发者的角度看，这条路接下来会怎么走？团队现在可以做什么？
刘光智： 我认为，接下来的操作系统竞争，关键变量不是谁的模型能力更强，而是开发态 Agent 与运行态 Agent 能够协同到什么程度。
让 AI 帮助开发者写出应用并不难，让系统中的 AI 调度不同应用也不难。真正困难的是把两者打通，让 AI 写出的应用能够被 AI 调度的操作系统无缝识别和调用。
如果能够做到这一点，开发方式将发生根本性的变化。从目前来看，鸿蒙正沿着这个方向推进。苹果和谷歌也有相关布局，但华为将开发态与运行态放在同一个框架中推进。
对于开发者，我有三点建议。
第一，尽早明确自己的团队更适合 DevEco Code 还是 DevEco CLI。新项目或需要快速启动的团队可以使用 Code；已有存量系统的团队，可以通过 CLI 把鸿蒙能力接入现有流水线，无需推倒重来。
第二，关注现有的 70 多个 Skill。并发安全改造等鸿蒙特有问题，已经有人完成实践并封装为 Skill，可以直接使用，避免重复投入。
第三，善用 harmonyos-ai-skill 等社区知识包。一次配置，就能让常用 AI 工具补充鸿蒙知识，这是性价比较高的使用方式。
HarmonyOS 7 目前仍不完美，Linux 支持、语料积累和生态成熟度都还有不足。但如果只保留一个判断，那就是：开发态 Agent 和运行态 Agent 的深度呼应，可能是鸿蒙这次真正区别于苹果、谷歌的地方。
