我一直认为，应用接入智能体之后，最值得关注的变化不是多了一个聊天入口，而是用户能否用自然语言直接完成原本需要多次点击的业务操作。

HarmonyOS 7 面向开发者开放 Agent 能力构建和已有 Agent 的 A2A 接入能力，使应用智能体有机会进入系统级智能服务体系。对于已经拥有云端业务服务和 Agent Server 的应用来说，云 A2A 是值得评估的接入方向。

这次我以一个活动管理应用为例，尝试设计从用户表达意图到查询活动、筛选结果、确认报名的完整流程。✍️

一、不要只提供一个聊天接口

如果 Agent Server 只接收一段文本，然后返回一段自然语言，用户仍然需要回到应用中完成报名。这种方案可以展示对话能力，却没有真正打通业务链路。

我会先把活动服务拆分为明确的业务操作，例如查询活动、检查报名条件、创建报名记录和查询报名状态。Agent 负责理解用户需求并组织调用，业务服务负责执行操作和验证规则。

下面是服务层的接口设计示例：

interface EventInfo {
 id: string;
 title: string;
 availableSeats: number;
}
interface RegistrationResult {
 success: boolean;
 registrationId?: string;
 message: string;
}
interface EventService {
 searchEvents(
 keyword: string
 ): Promise<EventInfo[]>;
 register(
 eventId: string,
 idempotencyKey: string
 ): Promise<RegistrationResult>;
}

这段 TypeScript 风格接口用于说明服务边界，不是 HarmonyOS 官方 Agent API，也不是完整的 A2A 协议实现。实际接入需要依据小艺开放平台的当前规范完成 Agent Server、鉴权、协议交互和平台配置。

二、让任务执行具备可恢复性

用户说“帮我报名下周的开发者活动”，系统需要先确定具体活动。如果存在多个候选项，就应该返回可供用户选择的结果，而不是让模型自行猜测。

当用户确认后，Agent 再调用报名服务。服务端需要重新检查名额、报名资格和当前活动状态，不能仅依赖前一步查询结果。因为从查询到提交之间，名额可能已经发生变化。

对于创建报名记录这样的操作，我会使用幂等机制，避免网络超时或重复调用导致同一个用户重复报名。幂等键应由可靠的业务请求逻辑生成，并在服务端持久化处理；不能简单地用每次随机生成的新值替代。

任务状态也需要独立管理，例如“等待用户选择”“等待确认”“提交中”“报名成功”和“报名失败”。发生异常时，系统应能查询真实业务状态，而不是仅根据模型上下文推断任务是否成功。👈

三、把安全控制放在模型之外

自然语言存在歧义。用户说“帮我报上”，不一定意味着他已经确认了具体活动和相关条款。因此，提交、付款、取消等具有实际影响的操作，应根据业务风险设置确认机制。

身份认证、访问控制和权限检查也必须由业务服务落实。模型可以提出调用建议，却不应该成为最终的权限判断者。

完成平台接入后，我会使用真实设备和测试账号覆盖以下场景：正常报名、活动不存在、名额已满、用户未登录、重复提交、请求超时以及用户中途取消。除了检查回复内容，还要确认业务数据库中的记录与界面展示一致。

这次实践让我认识到，云 A2A 的工程难点不只是协议打通，更在于让 Agent 成为一个可靠的业务执行者。只有将意图理解、业务调用、用户确认和异常恢复设计成完整链路，应用才能真正从“能回答”走向“能办事”。😁