对于已经有成熟业务后台的应用来说，接入智能体未必需要重建整套系统。更合理的做法，是让 Agent 理解用户需求，再调用已有的业务服务完成查询或操作。

HarmonyOS 7 支持已有 Agent 通过 A2A 等方式接入系统级智能入口。这意味着，开发者需要考虑的不仅是模型能否理解用户，还包括已有业务接口如何被安全、稳定地调用。

我选择一个活动预约服务作为设计案例。用户可以说“帮我找一个周五下午的开发者活动”，系统需要查询活动列表、过滤日期和名额，再让用户选择具体活动。确认后，才进入预约流程。

先明确 Agent 与业务系统的分工

我不会让模型直接决定最终业务状态。Agent 可以负责理解意图、补齐参数和组织任务；活动服务负责查询真实数据、校验预约条件并写入记录。

interface Event {
  id: string;
  title: string;
  startTime: number;
  remainingSeats: number;
}

interface BookingResult {
  success: boolean;
  bookingId?: string;
  message: string;
}

interface BookingService {
  searchEvents(
    startTime: number,
    endTime: number
  ): Promise<Event[]>;

  bookEvent(
    eventId: string,
    requestId: string
  ): Promise<BookingResult>;
}

这是一组应用侧业务接口，不是 HarmonyOS 官方 A2A 协议定义。真正接入时，需要按当前开放平台规范完成 Agent Server 配置、协议适配、鉴权和结果返回。

多步骤任务需要可靠的状态管理

预约不是单次请求。查询到活动之后，用户可能改变时间，也可能在确认前取消。提交过程中还可能发生网络超时，导致客户端不知道服务端究竟有没有完成预约。

因此，我会把任务状态独立管理，至少区分候选结果、等待确认、提交中、成功和失败。提交操作需要幂等机制；如果请求超时，优先查询已有请求的处理结果，而不是立即创建一条新预约。

业务服务还必须在最终提交时重新检查名额和资格，因为前一次查询的结果可能已经过期。模型上下文不能替代数据库中的真实业务状态。

让系统级入口遵守原有安全规则

用户通过系统智能入口发起请求，不意味着可以跳过应用原有的登录和权限控制。预约、取消、支付等会产生实际影响的操作，需要根据风险设置确认环节。

我会重点测试未登录、活动名额不足、重复提交、网络超时和用户中途取消等场景。除了检查对话回复，还会核对服务端记录，确保智能体报告的结果与真实业务状态一致。

这次实践让我意识到，云 A2A 的关键不是让 Agent 能够访问一个接口，而是把已有业务封装成可理解、可校验、可恢复的任务链。只有将智能体的灵活性与业务系统的确定性结合起来，系统级智能入口才能成为可靠的服务入口。