前言Agent 这个词现在出现频率很高。我们在聊 HarmonyOS 7 的时候它很容易被直接理解成一个智能助手、一个聊天入口或者一个能够帮用户完成任务的新交互层。这种理解不算错但如果你已经在做 HarmonyOS 应用问题会更具体。现有应用里的功能哪些可以被 Agent 调用。一次用户意图会不会跨过多个页面。哪些动作可以自动执行哪些动作必须确认。如果 Agent 调用失败应用要怎么回退。如果执行结果影响用户数据日志、权限和确认流程怎么保留。这些问题才是接入 Agent 之前最需要先处理的部分。HarmonyOS 7 的智能化方向已经把 Agent、Skill 和 AI 开放能力放到同一条链路里。Agent 系统能力和模型能力开放支持 Agent 能力构建和已有 Agent 的 A2A 接入用来帮助应用 Agent 对接系统级智能入口。所以Agent 接入前的重点可以先落到一个更工程化的问题上你手里的应用是否已经把任务边界设计清楚。我们先不急着讨论完整接入代码也不把 Agent 当成单独的聊天界面来讲。我们先从真实项目出发把一个任务拆开看看哪些步骤适合自动处理哪些步骤需要用户确认哪些能力需要先沉到服务层哪些记录必须保留下来。一、先把 Agent 放回任务链路里理解如果你已经做过一个工具类或者办公类应用就会发现用户想完成的事情通常不会刚好等于某一个按钮。比如会议类应用里用户真正想要的可能不是点击生成纪要按钮而是把一次会议整理成可以继续推进的工作结果。这个结果可能包含会议摘要、决议、待办事项、责任人、截止时间还可能继续生成周报草稿。从页面角度看这些动作会散落在多个页面里。页面页面动作会议详情页查看录音、转写文本、纪要纪要页生成摘要、整理决议待办页提取待办、修改状态联系人页选择责任人周报页汇总项目进展但是从 Agent 角度看它更像一条连续任务链。会议录音 → 会议转写 → 生成纪要 → 提取待办 → 分配责任人 → 生成周报 → 归档项目这条链路里每个节点都要回答几个问题。问题作用这个节点能不能单独执行决定是否适合做成可调用能力这个节点需要什么输入决定参数边界是否清楚这个节点会产生什么结果决定输出是否可保存和复用这个节点失败后怎么处理决定用户体验是否稳定这个节点会不会修改关键数据决定是否必须确认我们在接入 Agent 之前最好先完成这个拆解。这样做的好处是Agent 以后无论从系统级智能入口进入还是从应用内部入口进入调用的都不是一堆散落在页面里的按钮逻辑而是一组边界清楚的业务能力。HarmonyOS 7 已经把 Agent 时代的软件工程创新放到 HDC 2026 的议程中里同时开发文档中也有 Agent Framework Kit、Intents Kit、Core Speech Kit、Core Vision Kit、Natural Language Kit 等 AI 相关能力入口。Agent Framework Kit 用于在应用内拉起智能体组合Intents Kit 则面向 HarmonyOS 级意图体系。但在项目层面第一步仍然不是直接寻找所有 API而是先把应用自己的任务链拆清楚。API 能力只是后面的接入方式任务边界才是应用自己的工程基础。二、再把任务动作分成三类任务链拆出来以后下一步不是马上写代码而是先判断每个动作的风险等级。这个判断非常重要。因为 Agent 的能力越强越不能把所有动作都当成自动化步骤。生成一段草稿、查询一条记录、整理一个摘要失败以后通常还能修正。可是发送消息、删除数据、发布内容、分配责任人、提交订单这些动作一旦执行就会影响真实数据和真实协作关系。我们可以先把任务动作分成三类。动作类型示例处理建议可自动执行查询、摘要、草稿生成、内容分类可以减少手动操作建议确认生成纪要、提取待办、改写文案执行前后都要展示结果必须确认删除、发布、发送、支付、修改关键数据不能跳过确认流程这张表看起来简单但放到项目里很实用。比如会议场景里生成纪要草稿可以相对自动化。即使结果不够理想用户还可以编辑、重新生成或者直接放弃。但是分配责任人就不同了。这个动作会影响团队协作关系如果 Agent 直接把待办分配给某个人就可能造成误会。再比如发送周报它不是一个单纯的内容生成动作而是对外输出动作。生成草稿可以自动化正式发送必须确认。可以把会议任务链继续细化成这样。任务节点动作类型原因读取会议文本可自动执行只读取不修改数据生成纪要草稿可自动执行输出是草稿可以修改提取待办事项建议确认可能识别错误需要用户确认分配责任人必须确认会影响协作关系设置截止时间必须确认会影响任务承诺生成周报草稿建议确认输出需要人工审阅发送周报必须确认属于对外发送动作这里的核心思路是Agent 可以减少操作步骤但不能降低关键动作的确认要求。如果一个应用没有这个分层后面接入 Agent 时就容易把所有动作都放进同一条执行链里。短期看起来更智能长期会带来安全、误操作和责任边界问题。尤其是办公、项目管理、本地生活、金融、医疗、合同这些场景更要提前把确认边界设计清楚。三、把任务节点整理成可调用能力任务类型分清以后接下来要看每个任务节点能不能被整理成可调用能力。这里会回到上一篇提到的 Skill 思路。Agent 不是孤立存在的它需要调用应用里的业务能力。一个能力如果还藏在页面事件里只能通过用户点击按钮触发就很难被 Agent 稳定复用。更好的方式是把业务能力沉到服务层让页面、Skill 候选入口、Agent 任务链都能调用同一套能力。以会议类应用为例任务链可以拆成这些能力。任务节点可调用能力输入输出会议转写获取会议文本会议 ID、音频路径转写文本生成纪要生成会议纪要会议文本摘要、决议、风险提取待办提取行动事项会议文本、纪要待办列表分配责任人更新待办责任人待办 ID、联系人 ID更新后的待办生成周报生成周报草稿时间范围、项目 ID周报草稿归档项目保存会议结果会议 ID、纪要、待办项目记录这张表的重点是把 Agent 任务链和应用服务能力对应起来。我们可以先用项目侧接口草案固定能力边界。这里的代码不代表 HarmonyOS 7 Agent API 实测结果它只是现有项目里可以提前整理的服务层结构。exportinterfaceMeetingWorkflowInput{meetingId:string;}exportinterfaceMeetingWorkflowResult{summary:string;decisions:string[];actionItems:ActionItemDraft[];weeklyReportDraft?:string;}exportinterfaceActionItemDraft{title:string;ownerId?:string;dueTime?:number;needConfirm:boolean;}有了这个结构以后任务链就不会只停留在页面流程里。后续无论通过会议详情页按钮触发还是通过 Agent 调用都可以围绕同一套输入输出继续扩展。再往下可以把每个能力抽到服务层。exportclassMeetingWorkflowService{asyncgenerateWorkflowDraft(input:MeetingWorkflowInput):PromiseMeetingWorkflowResult{consttranscriptawaitthis.loadTranscript(input.meetingId);constsummaryawaitthis.generateSummary(transcript);constactionItemsawaitthis.extractActionItems(transcript);return{summary:summary.summary,decisions:summary.decisions,actionItems};}privateasyncloadTranscript(meetingId:string):Promisestring{return;}privateasyncgenerateSummary(transcript:string){return{summary:,decisions:[]};}privateasyncextractActionItems(transcript:string):PromiseActionItemDraft[]{return[];}}这段代码不解决 Agent 接入本身但它解决了一个更基础的问题任务链需要有稳定的服务层边界。没有这层边界Agent 接入时就容易直接依赖页面状态后续维护会非常麻烦。这里大家可以注意一个细节needConfirm这个字段很重要。它不是为了展示好看而是把任务风险边界放进了数据结构里。待办是否需要确认不应该只由页面临时判断最好在能力输出阶段就给出明确标记。这样后续进入 Agent 调用链时确认逻辑也能继续复用。四、为确认、失败和日志单独设计流程任务链和服务能力整理以后还有一件事经常被忽略异常处理和日志记录。如果你只是做页面按钮失败以后弹一个 Toast用户可能还能理解。但 Agent 调用链路更长失败点也更多。可能是文本为空可能是权限不足可能是服务超时可能是结果不符合预期也可能是用户取消确认。任何一个地方没有处理好最终体验都会变得很模糊。所以在 Agent 接入前确认、失败和日志需要单独设计。可以先把失败情况分成几类。失败类型示例处理方式输入缺失没有会议文本、没有音频提示补充输入或返回原页面权限不足无法访问文件、联系人、通知引导授权或降级处理能力失败生成失败、解析失败、服务超时支持重试或手动编辑用户取消不确认待办、不发送周报保留草稿不继续执行数据冲突待办已修改、会议已删除刷新数据并提示冲突设备限制当前设备不支持某能力记录设备条件提供替代路径再看确认流程。生成候选结果 → 展示结果 → 用户确认 → 执行写入 → 记录日志 → 返回状态这个流程看起来比直接自动执行麻烦但对真实项目更稳。因为很多 Agent 任务并不是单次查询而是会修改用户数据。只要涉及保存、发送、删除、分配、发布就需要把确认流程放在前面。我们可以用一个项目侧确认结构来固定边界。exportinterfaceConfirmableActionT{actionId:string;title:string;payload:T;riskLevel:low|medium|high;confirmRequired:boolean;}exportinterfaceActionExecutionResult{actionId:string;success:boolean;message?:string;}这里的riskLevel和confirmRequired是两个关键字段。它们可以帮助我们把动作风险写进结构里而不是把风险判断散落在页面按钮和弹窗逻辑里。日志记录也要尽早准备。exportinterfaceAgentTaskLog{taskId:string;abilityName:string;inputSummary:string;resultStatus:success|failed|cancelled;errorMessage?:string;createdAt:number;}这个日志结构不一定一开始就很复杂但至少要记录任务 ID、能力名称、输入摘要、执行状态、错误信息和时间。后续排查问题时它会非常有用。尤其在 Beta 阶段如果你要判断某个能力失败是因为接口、权限、设备还是业务数据日志会比口头描述可靠得多。五、用一个最小任务链完成接入前验证前面讲了任务边界、能力拆分、确认流程和日志记录最后还是要回到一个最小验证。Agent 接入前不建议一上来就做完整业务闭环。完整闭环里会有太多变量录音、转写、纪要、待办、联系人、周报、项目归档、权限、同步、通知。任何一个环节出问题排查都会很重。更稳的方式是先选一个最小任务链。对于会议类应用可以先选这条链路。会议文本 → 生成纪要草稿 → 提取待办草稿 → 用户确认 → 保存草稿这条链路有几个好处。第一它有明确输入。只需要一段会议文本。第二它有明确输出。结果是纪要草稿和待办草稿。第三它有确认环节。用户确认后再保存。第四它暂时不涉及发送、删除、支付、外部发布这些高风险动作。可以把验证目标整理成表格。验证项目标输入能接收会议文本纪要生成能返回摘要和决议待办提取能返回待办标题和建议责任人用户确认能展示结果并等待确认保存草稿只保存确认后的结果日志记录能记录成功、失败、取消状态这里可以用输入输出样例先固定验证目标。它不是模型效果证明也不是 HarmonyOS 7 Agent API 实测结果只是最小任务链的项目侧验证样例。{input:{meetingText:本次会议确认了版本节奏接口联调时间以及下周发布前的测试安排。},expectedOutput:{summary:会议围绕版本节奏、接口联调和发布测试安排展开。,actionItems:[{title:确认接口联调时间,needConfirm:true},{title:整理发布前测试清单,needConfirm:true}]}}有了这个最小链路后续就可以逐步替换真实能力。第一步先用手写逻辑或者 mock 数据跑通结构。第二步接入真实 AI 能力生成纪要和待办。第三步补充 Skill 候选入口。第四步再考虑 Agent 任务调用。这样做会慢一点但项目会稳很多。尤其是 Beta 阶段先把任务结构、确认流程和日志记录做清楚比直接追求完整 Agent 效果更可靠。如果放到会议随记类应用或会后行动台里优先级可以这样排。优先级动作原因P0整理任务链路明确 Agent 要调用什么P0拆分服务能力避免业务逻辑绑死页面P1增加确认结构避免高风险动作自动执行P1记录执行日志方便排查和复盘P2接入真实 Agent 能力等文档、SDK 和设备条件更稳定P2扩展多端和系统入口等核心链路稳定后再处理这张表能避免一个常见问题一开始就想做完整 Agent结果任务链、确认流程、服务层、日志都没有准备好。我们先把 P0 和 P1 做扎实后面接入 Agent 会轻松很多。总结Agent 接入前最关键的准备不是马上写完整接入代码而是先把任务边界设计清楚。可以按照五步处理。步骤要做什么1把 Agent 放回真实任务链路里理解2将任务动作分成可自动执行、建议确认、必须确认3把任务节点整理成可调用服务能力4单独设计确认、失败和日志流程5用最小任务链完成接入前验证如果你已经有 HarmonyOS 6 原生项目可以先从现有业务里挑一条任务链。会议类应用可以选会议文本 → 纪要草稿 → 待办草稿 → 用户确认 → 保存草稿。本地生活类应用可以选查询需求 → 推荐结果 → 用户确认 → 创建预约草稿。内容类应用可以选素材输入 → 草稿生成 → 人工确认 → 保存模板。这一步做完以后Agent 接入会更清楚。你不会只盯着聊天入口也不会把高风险动作直接放进自动化流程里。后面无论接入 Skill、Agent Framework Kit、Intents Kit还是继续接 AI 开放能力项目都会有一条更稳定的工程路径。
