在应用中加入聊天窗口并不难，难的是让智能体真正完成业务任务。

我在设计应用智能化能力时，越来越关注一个问题：智能体应该负责理解和组织任务，还是直接接管所有业务逻辑？如果所有功能都交给模型临场生成，不仅难以控制结果，也很难保证业务规则始终一致。

HarmonyOS 7 开放了 Agent 能力构建和已有 Agent 的 A2A 接入方向，目标之一是让应用智能体更好地进入系统级智能服务体系。

<Cite refs={["turn427496search0","turn427496search5"]}/>

这次我以一个旅行规划服务为例。用户提出“帮我整理一份周末两日游计划”，智能体需要理解目的地、出行日期和偏好，再调用应用已有的景点查询、路线整理等业务能力。这里最重要的不是让模型一次性生成一大段文字，而是把任务拆成可验证的步骤。

我采用的基本思路是：智能体负责意图理解和任务规划，业务服务负责数据查询与规则校验，最终结果由应用统一组织和展示。

interface TravelRequest {
  destination: string;
  days: number;
  preferences: string[];
}
 
interface TravelPlan {
  title: string;
  items: string[];
}
 
interface TravelService {
  buildPlan(
    request: TravelRequest
  ): Promise<TravelPlan>;
}
 
async function handleTravelIntent(
  request: TravelRequest,
  service: TravelService
): Promise<TravelPlan> {
  if (!request.destination.trim()) {
    throw new Error('需要先确定目的地');
  }
 
  if (request.days < 1 || request.days > 7) {
    throw new Error('行程天数超出支持范围');
  }
 
  return await service.buildPlan(request);
}

这段 ArkTS 展示的是业务服务的调用边界，并不是 HarmonyOS 7 Agent 或 A2A 的官方调用 API。实际接入时，Agent 的描述、能力暴露、通信协议及系统侧对接方式，都需要依据官方开发文档配置。

我认为，Agent 接入的第一步应该是定义职责边界。模型可以理解“轻松一点”“适合带孩子”等自然语言偏好，但不能凭空编造实时营业时间、票价或交通信息。涉及外部数据时，必须调用可靠的数据服务，并标明数据的有效范围。

第二步是设计任务状态。一个多步骤任务可能经历参数收集、数据查询、计划生成和用户确认。如果中间一步失败，应用应该能够解释失败原因，并允许重试，而不是只返回“处理失败”。对于需要付费、下单或修改用户数据的操作，还应该保留明确的确认环节。

第三步是考虑 A2A 协作。如果应用已有自己的 Agent，可以根据业务需要探索与其他 Agent 的协作。但跨 Agent 通信不意味着可以无限制传递上下文。传递的数据应当尽量精简，明确输入输出格式，并避免把不必要的用户信息交给其他服务。

在测试阶段，我会准备正常请求、信息缺失、工具调用失败、返回数据不完整以及重复执行等用例。尤其要验证同一任务重试时是否可能产生重复订单或重复记录。

这次实践让我更清楚地认识到，智能体的价值不只是“会回答问题”，而是能够在受控的业务边界内组织多个能力，帮助用户完成任务。模型负责理解和规划，应用负责规则、数据与执行，二者之间的接口越明确，整个系统就越容易维护和验证。