【HarmonyOS 7开发者前瞻】10 HarmonyOS 7 真实项目适配路线图：API 26、AI / Agent 与多端改造优先级

前言

一个已有 HarmonyOS 6 原生项目，到底应该怎样安排 HarmonyOS 7 适配路线。

这类项目通常已经有完整业务结构。比如会议类应用里，可能已经有会议列表、会议详情、新建会议、联系人、待办、项目、设置、本地数据库、页面路由、权限申请和多端适配基础。如果一拿到 API 26 Beta，就直接开始大范围重构，很容易把原本稳定的主流程改乱。

HarmonyOS 7 API 26 Developer Beta1 面向开发调测，适合提前体验 API 26.0.0 Beta1 版本的新能力、新特性，并使用 DevEco Studio 进行应用开发；这个阶段也适合通过邀请测试和远程真机云调试等方式完成应用验证。

我不按单点能力展开，而是用一个会议类项目来拆完整路线。

这里以 会议随记 Pro / 会后行动台 这类应用作为样例。它的核心业务是：记录会议、整理纪要、提取待办、关联联系人、沉淀项目进展，后续还可以扩展到周报生成、跨端同步和 Agent 任务链。

这类项目做 HarmonyOS 7 适配时，可以先把事情分成两类：

类型	代表事项	当前处理
先做	API 26 工程基线、主流程验证、能力拆分、多端布局、工具链闭环	不破坏主流程，先建立适配基础
暂缓	大范围重构、全量 Agent 化、复杂空间化、自动发送/删除/分配、高风险数据修改	等版本、文档、设备和业务链路稳定后再做

整条路线可以概括成一句话：

先保证项目能跑，再整理能力边界；先做最小验证，再逐步接入新能力。

一、先做工程基线

真实项目适配 HarmonyOS 7，第一步应该是工程基线。

所谓工程基线，就是先确认项目在 API 26 环境下能不能打开、编译、安装、启动、运行主流程。这个阶段不适合马上接 Skill、Agent、AI 或空间化能力。因为主流程还没有稳定时，新能力接入只会让问题来源变得更复杂。

以会议类应用为例，第一轮可以先检查这些内容。

检查项	目标	当前优先级
DevEco Studio 和 SDK	确认工具链和 API 26 SDK 状态	P0
项目配置	检查 compile、target、compatible 相关配置	P0
编译构建	确认项目能否完成构建	P0
真机安装	确认 HAP 能否安装到测试设备	P0
应用启动	确认入口页和首页能否加载	P0
主流程运行	确认会议列表、详情、新建、保存、返回刷新	P0

HarmonyOS SDK 的版本信息需要结合 DevEco Studio 查看，官 SDK 内置在 DevEco Studio 中，具体版本可在 DevEco Studio 的相关菜单中查询。

对已有项目来说，适配分支很重要。稳定分支继续保留，API 26 迁移放到独立分支里处理。

main
  └── feature/harmonyos7-api26-adaptation

这个分支命名只是项目侧约定，重点是把 API 26 相关改动隔离出来。后续如果某个配置、依赖或页面改动导致问题，可以和主分支快速对照。

工程基线阶段还需要保存一次迁移前主流程记录。

主流程	迁移前状态	API 26 环境状态	备注
应用启动	正常	待验证	保存日志和截图
首页工作台	正常	待验证	检查首屏加载
会议列表	正常	待验证	检查数据库读取
会议详情	正常	待验证	检查路由参数
新建会议	正常	待验证	检查保存逻辑
待办列表	正常	待验证	检查状态刷新
设置页面	正常	待验证	检查权限和配置

这张表比直接开始改代码更有价值。迁移后出现异常时，可以先判断问题是不是 API 26 环境下新增的。如果迁移前状态没有记录，排查时很容易陷入反复猜测。

P0 只处理工程能不能跑，不处理体验增强和新能力接入。

二、再把业务功能整理成能力清单

工程能跑以后，第二步才是能力整理。

HarmonyOS 7 的新能力页已经把 Skill、Agent 和视觉 AI 放在智能化方向里，同时 Agent 方向强调系统能力和模型能力开放，支持 Agent 能力构建和已有 Agent 的 A2A 接入。

这对会议类项目的影响，在于把页面背后的业务功能整理成能力单元。

会议类项目原本可能是按页面组织的。

页面	当前职责
首页工作台	展示今日会议、待办、快捷入口
会议列表页	展示会议记录
会议详情页	查看转写、纪要、待办、评论
新建会议页	创建会议基础信息
联系人页	管理联系人
待办页	管理行动项
项目页	汇总项目进展
设置页	管理权限、同步、外观和数据

到了能力视角，我们可以整理成另一张表。

能力	输入	输出	是否适合优先适配
创建会议	标题、时间、参与人	会议记录	适合
查询会议	时间、关键词、项目	会议列表	适合
生成纪要	会议文本、转写内容	纪要草稿	适合
提取待办	会议内容	待办草稿	适合
关联联系人	待办、联系人	更新后的行动项	谨慎
生成周报	项目、时间范围、待办状态	周报草稿	适合最小验证
发送周报	周报内容、接收人	对外发送结果	暂缓
删除会议	会议 ID	删除结果	暂缓

这里的关键是区分 生成草稿 和 执行动作。

生成纪要、提取待办、生成周报草稿，都可以先作为低风险能力整理。它们的结果可以展示给用户确认，不直接改变外部状态。

发送周报、删除会议、自动分配责任人，属于高风险动作。它们会影响数据、协作关系或对外输出，第一阶段不适合自动化。

能力清单整理完以后，可以继续沉到服务层。

pages/
  MeetingListPage.ets
  MeetingDetailPage.ets
  MeetingNewPage.ets

services/
  MeetingService.ets
  MeetingSummaryService.ets
  MeetingActionService.ets
  WeeklyReportService.ets

models/
  MeetingModel.ets
  ActionItemModel.ets
  ContactModel.ets
  ProjectModel.ets

这个结构是项目侧组织方式，用来表达页面、服务和模型的分层关系。它的价值在于让页面按钮、Skill 候选入口、Agent 任务链都可以复用同一组服务能力。

能力整理阶段可以先做三件事。

动作	目标
列出页面功能	找到真实高频动作
补齐输入输出	让能力可以被独立调用
标注风险等级	区分自动、建议确认、必须确认

这一阶段暂时不需要追求完整 Skill 接入。先把能力拆出来，后续文档、SDK、设备和审核链路更稳定时，接入成本会明显降低。

三、选择一个最小 AI / Agent 链路验证

能力清单整理以后，第三步是选择一个最小验证链路。

这里最容易出错的地方，是一开始就想做完整 Agent。比如从会议录音到转写，再到纪要、待办、责任人、截止时间、周报、发送、归档，全部交给 Agent 自动处理。这个目标很吸引人，但第一阶段变量太多。

而更稳妥的方式，是先选一条低风险链路。

会议文本 → 生成纪要草稿 → 提取待办草稿 → 用户确认 → 保存草稿

这条链路适合作为第一轮验证，有几个原因。

条件	说明
输入明确	只需要一段会议文本
输出明确	纪要草稿和待办草稿
风险可控	不自动发送，不自动删除，不自动分配
用户价值高	能减少会后整理时间
后续可扩展	可以继续扩展责任人、截止时间和周报

HarmonyOS 7 的智能化方向包含 AI 开放能力、Skill 和 Agent 相关能力。对于项目来说，第一轮更适合验证 输入 → 候选结果 → 用户确认 → 保存结果 这条低风险结构，而不是直接完成高风险自动执行。

这里可以用一个项目侧输入输出样例固定验证目标。

{
  "input": {
    "meetingText": "本次会议确认了版本节奏、接口联调安排和下周发布前的测试计划。"
  },
  "expectedOutput": {
    "summary": "本次会议围绕版本节奏、接口联调和发布测试安排展开。",
    "actionItems": [
      {
        "title": "确认接口联调时间",
        "needConfirm": true
      },
      {
        "title": "整理发布前测试清单",
        "needConfirm": true
      }
    ]
  }
}

这个样例属于项目侧验证样例。它不代表某个 HarmonyOS 7 新 API 的运行结果。它的作用是让后续 AI 能力验证有明确目标：输入是什么、输出应该是什么、哪些结果需要确认。

最小验证链路还应该配一张状态表。

验证项	当前目标	是否进入第一阶段
会议文本输入	能读取现有会议文本	是
纪要草稿生成	能生成摘要和决议	是
待办草稿提取	能生成待办候选项	是
用户确认	保存前展示确认界面	是
草稿保存	只保存确认后的结果	是
自动分配责任人	根据联系人自动分配	否
自动发送周报	对外发送内容	否
自动删除无效记录	修改或删除历史数据	否

第一阶段只做前五项。后面三项暂缓。这样做可以让验证结果更干净，也能避免过早把高风险动作放进自动化链路。

这里还要配合日志记录。

interface TaskExecutionLog {
  taskId: string;
  abilityName: string;
  inputSummary: string;
  status: 'success' | 'failed' | 'cancelled';
  errorMessage?: string;
  createdAt: number;
}

日志结构可以先保持简单。只要能记录任务、能力、输入摘要、执行状态、错误信息和时间，就能支持后续复查。Beta 阶段的问题经常和 SDK、设备、权限、服务条件有关，日志会比临时描述可靠得多。

四、多端和空间化先改核心页面

AI 和 Agent 链路之外，多端适配也要进入路线图。

HarmonyOS 开发者官网的探索页已经把多设备应用开发作为重要方向，覆盖一次开发、多端部署，以及折叠屏、平板、鸿蒙电脑等应用开发实践入口。

对于会议类项目来说，多端适配不应该等到最后才处理。因为会议类应用天然有列表、详情、编辑、待办、项目看板这些页面，大屏和折叠屏展开态会明显影响信息组织方式。

第一阶段可以先改五类页面。

页面	先做什么	暂缓什么
首页工作台	整理信息层级和快捷入口	复杂动效
会议列表详情	做主从结构和选中态	全量重构页面
纪要编辑页	区分原文、草稿、确认内容	复杂视觉包装
待办页面	优化分组和状态展示	自动分配责任人
设置页面	做分类管理和权限入口	过度空间化效果

对于列表详情页，可以先用主从结构处理大屏。

手机：会议列表 → 会议详情
大屏：左侧会议列表 + 右侧会议详情

这类改造对真实项目很有价值。它不依赖某个新 API，也不会打乱业务逻辑，但能让应用在平板、折叠屏和窗口环境里更自然。

编辑页也适合优先处理。会议纪要编辑页可以把内容分成三层。

内容层	页面职责
原始会议文本	作为只读参考
AI 生成草稿	可编辑、可重新生成
用户确认内容	保存到会议记录或项目记录

这三层分清楚以后，后续接入 AI 生成、Skill 调用或 Agent 链路时，用户不会混淆原始内容、生成内容和最终内容。

空间化能力可以先放在第二阶段。HarmonyOS 7 新能力页提到沉浸光感组件和 3DGS 端侧重建等空间化方向，前者强调光学行为、空间属性和交互响应能力，后者更适合空间建模、商品展示和文旅展陈等 3D 内容场景。会议类工具应用第一阶段可以先做层级、分栏、状态和确认，不必强行接入复杂 3D 能力。

页面改造优先级如下。

优先级	页面	原因
P0	首页工作台	应用入口和状态总览
P0	会议列表详情	主流程高频页面
P1	纪要编辑页	AI / Agent 结果确认页
P1	待办页面	会议后续行动承载页
P1	设置页	权限、同步、数据管理入口
P2	低频说明页	使用频率低
P2	复杂空间化页面	需要等业务和能力更稳定

这条路线比较稳。先改核心路径，暂缓全站视觉重构。等核心页面在多端环境里稳定后，再选择适合页面做空间化增强。

五、最后用工具链和优先级表控制节奏

真实项目适配 HarmonyOS 7，最后一定要靠工具链和优先级表收住节奏。

DevEco Studio 覆盖 AI 辅助编程、编译构建、UI 实时预览、代码调试、性能调优、模拟器等能力；DevEco Code 面向 HarmonyOS 开发场景，DevEco CLI 面向编程 Agent，提供工程创建、语法检查、编译构建、运行调测等全流程工具能力。

这意味着，工具链应该进入适配流程，而不是只在写代码时出现。

我们可以把 DevEco Code 和 DevEco CLI 放到这些环节里。

环节	工具链作用	最终确认
编译报错	分析错误原因和修改建议	重新编译
页面改造	辅助拆分组件和状态	真机运行
多端布局	辅助生成断点和布局结构	平板 / 折叠屏验证
AI 链路	辅助整理输入输出和确认流程	最小链路跑通
日志排查	辅助分析运行错误	保存日志和截图
验证清单	生成测试项和回归项	人工执行和确认

工具链进入以后，适配工作可以从单次修改变成闭环。

问题现象 → 上下文收集 → 工具建议 → 最小修改 → 编译运行 → 真机验证 → 记录结论

这条闭环比一次性重构更适合真实项目。每一轮只解决一个问题，修改范围清楚，结果可以复查，回退也更容易。

最后我们可以把所有事项排成一张路线表。

阶段	先做	暂缓
第 1 阶段	API 26 工程基线、编译、安装、启动	新能力接入
第 2 阶段	主流程验证、旧数据读取、权限检查	大范围业务改造
第 3 阶段	页面功能整理为能力清单	全量 Skill 发布链路
第 4 阶段	会议纪要和待办的 AI 最小链路	自动发送、自动删除、自动分配
第 5 阶段	首页、列表详情、编辑页多端适配	全站空间化和复杂 3D 页面
第 6 阶段	DevEco Code / CLI 进入验证闭环	完全自动化工程修改

也可以按照 P0、P1、P2 继续拆。

优先级	事项	判断
P0	编译、安装、启动、主流程	没有这些，适配没有基础
P0	旧数据读取、权限链路	影响真实项目可用性
P1	能力清单、服务层边界	影响 Skill / Agent 后续接入
P1	会议纪要 AI 最小验证	业务价值高，风险可控
P1	多端主页面适配	影响实际体验
P2	完整 Agent 链路	等任务边界和确认流程稳定
P2	复杂空间化效果	等核心页面结构稳定
P2	自动发送、删除、分配	高风险动作，必须谨慎

这张表就是项目适配路线的核心。它能避免两个常见问题：一类是看到 HarmonyOS 7 新能力很多，就立刻全面重构；另一类是因为 Beta 阶段还在变化，就所有准备工作都不做。

更合适的状态，是 P0 立刻做，P1 分阶段做，P2 保持观察。这样既能跟上 HarmonyOS 7 的方向，也不会破坏现有项目稳定性。

总结

一个已有 HarmonyOS 6 原生项目适配 HarmonyOS 7，不需要把所有新能力一次性接完。

应该按照如下路线进行：

步骤	目标
1	先建立 API 26 工程基线
2	再跑通主流程、权限和旧数据
3	继续把页面功能整理成能力清单
4	选择一个 AI / Agent 最小链路验证
5	优先改核心页面的多端布局
6	用 DevEco Code 和 DevEco CLI 进入工程验证闭环
7	把复杂 Agent、复杂空间化和高风险自动化放到后面

对于会议类项目，第一轮可以只做这些事：API 26 分支、编译安装、首页加载、会议列表详情、新建保存、旧数据读取、权限检查、能力清单、纪要草稿和待办草稿最小验证、首页和列表详情多端适配。

暂时不动的内容也要明确：不做全量 Agent 自动执行，不做自动发送周报，不做自动删除会议，不做自动分配责任人，不做全站空间化重构，不在主流程还没稳定时接入太多新能力。

这样安排以后，HarmonyOS 7 适配会更像一条可控路线，而不是一次冒险式重构。先把现有项目稳定跑起来，再把能力边界和验证闭环建立起来，后面的 Skill、Agent、AI 开放能力、多端适配和工具链升级，才有真正落地的基础。