前言

HDC 2026 之后，HarmonyOS 7 的信息量明显变大。

如果你只是快速浏览大会信息，Agent、Skill、AI 开放能力、空间计算、方舟引擎、星盾安全、星河互联这些关键词很容易留下印象。可是回到项目里以后，真正影响开发节奏的，往往不是这些词本身，而是它们会落到哪些工程动作上。

比如，现有 HarmonyOS 6 原生项目是否需要马上迁移到 API 26。
比如，测试版本拿到以后，应该优先体验系统界面，还是优先确认工程环境。
再比如，发布会上出现的新能力，在本地 SDK 中暂时查询不到，这种情况到底应该怎么判断。

这些问题听起来没有那么宏大，但它们会直接影响后续开发节奏。尤其是你手里已经有 HarmonyOS 5 或 HarmonyOS 6 项目时，最怕的情况就是方向还没判断清楚，主流程已经开始大范围重构；或者反过来，因为 Beta 阶段还在变化，所有准备工作都停在那里。

我们先把 HarmonyOS 7 放回真实开发流程里，按照五条主线来理解。

• API 26 Beta
• Skill 能力拆分
• Agent 任务边界
• AI 开放能力
• DevEco 工具链

我的建议是先建立判断框架，再结合手里的项目逐步验证。这样做的好处很明确：你不会因为新版本变化太多而仓促重构，也不会因为测试阶段还在变化就完全停止准备。

---

一、先把 API 26 Beta 当成工程验证基线

HarmonyOS 7 Developer Beta 已经启动，这一轮核心方向包括 Agent 架构、鸿蒙智能体框架 2.0、鸿蒙空间计算、openPangu 2.0，以及方舟引擎、星盾安全、星河互联等底座能力。它们能帮助我们理解系统演进方向，但真正进入项目以后，仍然需要回到 SDK、文档、设备和运行结果中验证。

API 26 Developer Beta1 面向开发调测，报名周期是 2026 年 6 月 12 日到 2026 年 7 月 5 日，推送节奏还会受到设备型号、基线版本、报名状态等因素影响。换句话说，Beta 阶段适合完成环境验证、兼容性检查和问题记录，暂时不适合把测试结果直接套用到正式版本表现。

这里最容易出现的误判，是把几个不同层级的信息混在一起。大会上出现的能力，代表方向已经明确；文档能够查询到，代表具备进一步研究的依据；本地 SDK 能够发现，才适合进入最小工程验证；真机或者云调试能够运行之后，才具备测试结论；真实项目主流程运行通过以后，才适合沉淀为实践结论。

我们可以先把 HarmonyOS 7 相关能力分成五层。

状态	判断依据	当前处理
已发布	HDC、发布稿、开发者网站已经出现	可以作为方向判断
文档可查	Guide、API Reference、Kit 文档能够查询到	可以作为接入依据
SDK 可见	本地 SDK 或 DevEco Studio 中能够发现	可以进入工程验证
Beta 可测	真机或云调试环境能够运行	可以整理测试结论
项目可用	真实项目主流程已经运行通过	可以沉淀实践结论

拿到测试版本以后，第一轮更适合优先确认工程环境。因为后续所有判断都会依赖这个基准。工程环境本身不稳定时，后面遇到异常，很难区分问题来自系统版本、SDK 配置、项目依赖，还是具体能力本身。

第一轮建议记录这些内容。

检查项	记录内容
DevEco Studio	当前使用版本
SDK	是否安装 API 26 对应 SDK
设备	设备型号、系统版本、基线版本
新建项目	是否能够正常创建、编译、运行
存量项目	HarmonyOS 6 工程是否能够编译通过
权限	原有权限声明和授权流程是否正常
API 查询	HarmonyOS 7 新能力是否能够在文档和 SDK 中查询到
日志	编译、运行、真机调试是否存在异常

如果新建项目无法正常运行，后续能力验证会缺少稳定基准。存量项目迁移后出现编译问题时，应该优先区分工程配置、依赖版本、签名配置、权限声明、路由结构和 API 变化。某个 HarmonyOS 7 新能力在本地 SDK 中暂时查询不到，也需要继续检查 API Reference、Kit、权限、AGC 服务、设备基线版本和 HOTA 状态。

远程真机云调试可以作为 Beta 阶段的辅助验证链路，特别是暂时没有合适真机设备的时候。但这里也要留意一个细节，本地真机和远程云调试结果要分开记录。两个环境运行出来的结果都有参考价值，但不适合混成同一个结论。

API 26 Beta 阶段可以先形成一个基本判断。

---

二、Skill 先从页面背后的业务能力拆起

很多项目最开始设计功能时，都会自然地按照页面拆分结构。这个方式非常符合移动应用开发习惯，也方便处理导航、布局、状态和数据展示。一个会议类应用，通常会先拆出会议列表页、会议详情页、新建会议页、待办页和周报页。这样的结构对于用户手动操作很清晰，开发起来也比较直观。

到了 HarmonyOS 7，Skill 相关能力开始进入应用功能被系统级智能入口调用的链路。这个变化会带来一个很现实的问题。页面结构清楚，并不代表系统能够理解这个应用能完成什么。系统更关心的是能力本身，比如能否创建会议、能否生成纪要、能否提取待办、能否生成周报。HarmonyOS 7 新能力清单已经把 Skill、Agent、视觉 AI 等内容放在智能化方向下，并且 Skill 能力会参与开发、调测、审核、上架以及系统级智能入口调用链路。

过去按照页面拆分时，会议类应用可能是这样的结构。

页面	传统职责
会议列表页	展示会议记录
会议详情页	查看会议内容
新建会议页	创建会议
待办页	查看行动项
周报页	整理阶段进展

这种结构适合用户手动操作。进入系统级智能入口之后，应用还需要补充一层能力视角。系统调用需要理解的是应用能够完成哪些动作、需要哪些输入、返回哪些结果、遇到异常时如何反馈。

同样是会议类应用，换成 Skill 视角后，可以先拆成下面这些能力。

应用能力	输入	输出	确认要求
创建会议	标题、时间、参与人	会议记录	可选
生成纪要	会议文本、录音转写文本	纪要草稿	建议确认
提取待办	会议内容	待办列表	建议确认
分配责任人	待办、联系人	更新后的待办	需要确认
生成周报	时间范围、项目	周报草稿	需要确认

这张表的价值，是把页面按钮背后的业务动作抽出来。一个可以被系统理解的能力，需要具备稳定输入、明确输出、状态反馈、异常处理和确认机制。如果生成纪要只编写在页面点击事件里，后续接入系统级智能入口时会很难复用。更稳的结构，是把生成纪要沉淀到独立服务能力中，页面层调用服务能力，后续 Skill 也可以调用同一层能力。

export interface MeetingSummaryInput {
  meetingId: string;
  transcript: string;
}

export interface MeetingSummaryResult {
  summary: string;
  decisions: string[];
  actionItems: string[];
}

export async function generateMeetingSummary(
  input: MeetingSummaryInput
): Promise<MeetingSummaryResult> {
  return {
    summary: '',
    decisions: [],
    actionItems: []
  };
}

这段代码的意义在于，先把会议纪要能力的输入、输出和返回结构固定下来。后续无论接入 Skill、AI 能力，还是继续使用现有页面按钮触发，都可以复用这个服务层边界。

这会影响现有项目的代码结构。

层级	主要职责
页面层	展示、交互、状态反馈
服务层	执行独立能力
数据层	保存状态和结果
校验层	检查输入、权限、边界条件
确认层	拦截高风险动作

当前阶段更适合先完成能力清单整理。可以从 一些高频能力开始，例如创建会议、生成纪要、提取待办。每个能力写清楚输入参数、输出结果、失败情况和确认要求。这个过程即使暂时没有接入 Skill，也能改善项目结构，让业务动作从页面事件里逐步独立出来。

这样的整理还有一个隐藏收益。过去页面复杂之后，很多业务逻辑会散落在点击事件、状态更新和页面跳转里，后续维护成本会逐渐变高。能力颗粒度整理之后，页面仍然负责交互体验，服务能力负责执行逻辑，后面无论接入系统级智能入口，还是继续完成多端适配，都会更容易保持一致性。

三、Agent 接入之前先梳理任务边界

Agent 这个词现在出现频率很高，很多时候会被直接理解成聊天入口。放到应用开发里，这样理解会有些单薄。真正需要提前准备的，通常是任务边界。也就是说，当系统理解到一个用户意图之后，应用能够提供哪些可以被组合的能力，哪些步骤可以自动处理，哪些步骤必须让人确认。

HarmonyOS 7 的 Agent 亲和系统架构已经和端云大模型、Skill、系统级智能入口形成更紧密的关系，鸿蒙智能体框架 2.0 也开始强调系统级 AI 能力和 GUI 操控能力开放。

以会议场景为例，一个完整任务链可能是：

会议录音 → 会议转写 → 生成纪要 → 提取待办 → 分配责任人 → 生成周报 → 归档到项目

传统应用通常把这些动作拆散到多个页面和多个按钮里。进入 Agent 方向后，应用需要提前判断每一步是否能够独立调用，哪些动作可以自动执行，哪些动作需要展示结果后确认，哪些动作必须在执行前进行明确确认。

任务动作可以先分成三类。

动作类型	示例	处理建议
可自动执行	查询、摘要、草稿生成、内容分类	可以减少手动操作
建议确认	生成纪要、提取待办、改写文案	执行前后都要展示结果
必须确认	删除、发布、发送、支付、修改关键数据	不能跳过确认流程

这张表比单纯讨论 Agent 概念更接近工程落地。Agent 越靠近真实执行链路，越需要清晰的确认机制、权限边界、日志记录和失败回退。尤其是删除、发布、发送、支付、修改关键数据这些动作，不能因为智能体接入就降低安全要求。

这里也可以换一个更日常的角度理解。生成一份会议纪要草稿，即使结果不够理想，也可以重新生成或者人工修改；但是把待办分配给某个人、把周报发送出去、删除某条会议记录，这些动作都会产生明确后果。前者适合自动化，后者需要确认机制。这就是 Agent 接入前必须先梳理任务边界的原因。

在暂时没有 Agent 运行结果的阶段，可以先用任务链伪代码固定顺序和确认边界。它不是 HarmonyOS 7 Agent API 的实测结果，也不需要标注为文档可查。它只是项目侧任务编排的说明。

async function runMeetingWorkflow(meetingId: string) {
  const transcript = await transcribeMeeting(meetingId);
  const summary = await generateMeetingSummary({ meetingId, transcript });

  const confirmed = await confirmBeforeAssign(summary.actionItems);
  if (!confirmed) {
    return;
  }

  await assignActionItems(summary.actionItems);
  await archiveMeetingResult(meetingId, summary);
}

这段任务链结构的重点，是把 生成草稿 和 分配待办 分开处理。前者可以更自动化，后者需要确认。我们先把这个边界固定下来，后续接入真实能力时，就不容易把高风险动作混进自动执行流程里。

会议纪要到待办、待办到周报、本地生活查询到预约、图片处理到发布，这些多步骤场景都适合作为 Agent 化之前的分析对象。它们有明确起点，也有明确产出，中间环节还能拆分为多个独立能力，非常适合通过任务链路图进行梳理。

当前阶段适合优先整理任务链路图，把每个节点标注为可自动执行、建议确认、必须确认。等 A2A、Intent、Skill 和系统级智能入口的接入路径更加稳定后，再把链路中的能力逐步接入。

四、AI 开放能力按照业务价值安排接入顺序

AI 开放能力容易让人产生一个冲动，看到能力列表之后，想尽快把应用里的功能都加上智能化入口。但在真实项目里，智能化接入越多，稳定性、权限、性能、交互解释和用户确认这些问题也会随之增加。所以，AI 能力适合按照业务价值排序，而不是按照能力名称排序。

HarmonyOS 7 的智能化方向包含 Skill、Agent 和视觉 AI 能力。视觉 AI 能力面向端侧视觉 AI 处理，覆盖基础能力和场景化控件。

一个功能是否值得接入 AI，可以先围绕三个问题评估。

判断问题	适合接入的表现
用户输入成本是否较高	需要输入长文本、语音、图片或复杂条件
内容整理是否频繁	摘要、分类、提取、改写频繁出现
多步骤是否能够合并	原本需要连续进入多个页面处理

如果一个功能同时满足其中两项，就值得进入验证清单。比如会议纪要生成既涉及长文本处理，也涉及摘要、提取和后续待办整理；待办管理中的责任人识别、截止时间提取，也能减少人工录入成本。相反，如果一个功能通过普通按钮和表单已经足够清楚，增加 AI 入口可能会引入更多不确定性。

涉及支付、账号、隐私、合同、医疗、金融等高风险场景时，智能化体验需要让位给确认流程、权限边界和数据安全。AI 可以辅助整理、识别、推荐和草稿生成，但关键动作仍然需要明确确认。

结合常见应用场景，可以先这样排列优先级。

场景	可能的 AI 使用位置	优先级
会议纪要	摘要、决议、待办提取	高
待办管理	责任人识别、截止时间提取	高
周报生成	从会议和待办汇总阶段进展	高
图片处理	图像增强、内容识别、素材整理	中
本地生活	意图识别、地点匹配、预约信息整理	中
普通设置页	智能化价值不明显	低

这个排序背后有一条很简单的经验。越是输入成本高、整理工作重复、多步骤连接明显的地方，AI 接入的价值越容易体现。越是规则明确、交互简单、结果必须精确的地方，AI 接入越需要谨慎。比如设置页里一个开关状态，用按钮表达就已经足够清楚；会议纪要里几十分钟转写文本需要提取决议和待办，AI 能力就更容易发挥价值。

在 AI 能力尚未完成实测前，可以先整理输入输出样例。这里也不需要写成文档可查，因为它属于项目侧验证样例。真正需要标注验证状态的，是后续接入的具体 HarmonyOS 7 AI 能力。

{
  "input": {
    "meetingText": "今天讨论了版本计划、接口联调和下周发布安排。"
  },
  "expectedOutput": {
    "summary": "本次会议围绕版本计划、接口联调和发布安排展开。",
    "actionItems": [
      "确认接口联调时间",
      "整理下周发布清单"
    ]
  }
}

这类示例的价值，是先明确后续验证目标。真正接入 AI 能力时，就可以对比实际输出和预期输出，继续记录准确性、稳定性、耗时、权限和用户确认结果。

当前阶段最重要的动作，是选择一个高价值场景运行最小验证链路。最小验证链路不需要覆盖完整业务闭环，只需要确认输入来源、能力调用、结果展示、异常处理和用户确认这几个关键位置。这样既能判断能力价值，也能避免过早把不稳定能力放进主流程。

五、DevEco 工具链进入工程闭环以后再谈效率提升

工具链这条线，容易被简单理解成 AI 帮忙生成代码。实际开发里，代码生成只是其中一部分。HarmonyOS 项目经常遇到的问题，会散布在页面结构、工程配置、依赖版本、权限声明、签名配置、设备版本和运行日志里。单独生成一段 ArkTS 代码，并不能解决这些上下文问题。

DevEco Code 面向鸿蒙应用开发，定位为开箱即用 AI Coding 工具，并覆盖需求、设计、开发、验证四个阶段。DevEco CLI 则面向编程 Agent，提供从创建工程、语法检查、编译构建到运行调测的全流程工具，并把鸿蒙开发相关知识资源提供给 Agent 调用。

所以，DevEco Code 这类工具更适合放在工程闭环中使用。它可以参与需求拆分、代码生成、报错解释、构建修复和功能验证，但每个环节的最终结论仍然要回到本地编译、真机运行和日志确认上。

工程环节	AI 工具可以辅助什么	最终确认
需求拆分	拆分页面、组件、服务	是否符合业务流程
代码生成	生成 ArkTS、ArkUI 初稿	API 是否真实可用
报错解释	分析编译错误、运行错误	是否能够复现和修复
构建修复	提供修改建议	本地是否编译通过
功能验证	辅助生成测试思路	真机运行和日志结果

更合理的流程是：

需求拆分 → 代码生成 → 编译构建 → 报错修复 → 真机运行 → 日志确认 → 下一轮调整

这个流程里，AI 工具负责提高定位效率，工程结果仍然以编译、运行、日志、真机体验为准。这样使用工具链，才能减少伪代码、伪 API、伪修复带来的额外成本。

放到会议随记类应用或会后行动台这类项目里，五条主线可以形成一张优先级表。

HarmonyOS 7 主线	项目里的对应动作	当前优先级
API 26 Beta	运行新建项目和存量项目编译	P0
Skill	拆分创建会议、生成纪要、提取待办、生成周报	P1
Agent	整理会议到周报的任务链路	P1
AI 开放能力	优先验证摘要、待办提取、时间识别	P1
DevEco 工具链	用于报错解释、构建修复、代码检查	P1

这张表可以避免两类常见偏差。第一类偏差，是看到 HarmonyOS 7 变化很多，就马上重构所有页面；第二类偏差，是觉得 Beta 阶段还早，所有准备工作都延后。更稳的策略，是先完成不破坏主流程的准备工作。

先记录环境。
先运行工程。
先整理能力表。
先拆分任务链路。
先选择一个小场景验证 AI 能力。
先把 DevEco Code 放进报错修复和构建验证流程。

这些工作不需要一次性完成全部接入，也不会让现有项目失控。等后续文档、SDK、设备版本和正式版本逐步稳定之后，前期沉淀的验证表、能力表、任务链路图和工程闭环记录，都可以继续复用。

---

总结

HarmonyOS 7 当前阶段可以先抓住五条主线。

主线	当前阶段要处理什么
API 26 Beta	建立版本和工程验证记录
Skill	把页面功能整理成能力单元
Agent	先设计任务边界和确认机制
AI 开放能力	只选择高价值业务场景验证
DevEco 工具链	放进构建、报错、验证闭环

优先级可以这样排列。

1. 先验证 API 26 Beta 环境
2. 再检查存量项目是否能够编译运行
3. 继续整理应用能力表
4. 开始拆分任务链路和确认边界
5. 最后选择一个 AI 能力完成最小验证

环境没有运行通过，后面的判断不稳定。能力没有拆分清楚，Skill、Agent 和 AI 能力都很难落到项目里。Beta 阶段最重要的任务，是建立一套可以复查、可以迁移、可以复用的验证方法。