如果一个 AI 助手只能回答问题，那么它更像一个聊天工具。但如果用户说“帮我整理明天的会议资料，并生成一份准备清单”，应用就需要完成多个步骤。

这类需求的难点不是生成一段回答，而是如何把任务拆解、执行，并且在某一步失败时能够正确处理。

HarmonyOS 7 的鸿蒙智能体框架 2.0 面向意图理解和任务执行进行了升级，开发者可以通过相应的开放能力接入智能体体系。

我会先从一个简化的会议准备助手开始。

把任务拆成可验证的步骤

假设用户需要整理会议资料。应用可能要读取日历中的会议主题、查询相关文档，再生成准备清单。

这里有一个重要原则：模型负责规划，不代表所有操作都应该由模型直接完成。真正读取日历和文档的动作，仍然要通过经过授权的业务接口执行。

enum TaskStatus {

PENDING,

RUNNING,

SUCCESS,

FAILED

}

interface TaskStep {

id: string;

title: string;

status: TaskStatus;

}

function updateTaskStatus(

steps: TaskStep[],

id: string,

status: TaskStatus

): TaskStep[] {

return steps.map((step: TaskStep) => {

if (step.id === id) {

return {

id: step.id,

title: step.title,

status: status

};

}

return step;

});

}

这个例子只负责更新任务状态，没有实现真正的 Agent 规划或系统能力调用。但它说明了为什么任务状态值得单独管理。

为什么不能只等一个最终答案？

假设第三步读取文档失败了，如果应用只保存最后一段回答，就很难判断前面的步骤是否已经成功完成。

我更倾向于把每一步的输入、输出和执行状态分别记录下来。发生错误时，可以提示用户哪一步没有完成，并根据业务规则决定是否允许重试。

例如，读取资料失败可以重试；但如果某一步涉及发送邮件，就不能在结果不确定时无条件重复执行，否则可能产生重复发送。

异步执行要考虑取消和超时

真实的 AI 任务可能需要调用多个服务，因此应用还需要处理网络中断、任务超时、用户主动取消和页面退出等情况。

界面也应该让用户知道任务进行到了哪一步，而不是一直显示一个转圈动画。

对于涉及敏感资料的任务，还要遵循最小权限原则，只读取完成任务所必需的数据。模型提出的任务计划也不应该自动获得额外权限。

我的开发思路

我会先把每个业务动作设计成一个可独立调用、可单独测试的模块，再接入 Agent 的任务规划与执行流程。

这样做的好处是，即使后续更换模型或调整任务规划策略，原有业务逻辑也不需要全部重写。

在我看来，Agent 真正的价值不在于一次生成多长的回答，而在于能否把复杂需求转化为一系列可验证、可恢复、可追踪的操作。