最近讨论 AI 应用，常常从“接哪个模型”开始。但对产品经理来说，更值得先问的是另一个问题：用户究竟要完成什么任务，系统允许 AI 做到哪一步？

对移动应用而言，Agent 的价值不只是把对话框嵌到页面里，而是理解意图、选择工具、推进业务流程，并在关键节点把控制权交还给用户。本文从产品设计和工程落地视角，拆解鸿蒙智能体与 A2A 接入中的几个关键问题：请求如何拆成可控步骤、A2A 协作如何设定信任边界、会话状态如何设计，以及如何用一条窄链路验证 Agent 的业务价值。

先把请求拆成可控步骤

以“帮我寄出这份快递”的场景为例，Agent 可以先识别用户意图，再询问收件信息是否完整，调用地址簿或运单服务生成草稿，最后展示价格与收件信息，让用户确认后再提交。

这里的关键不是一句提示词，而是一个可控的状态机。查询类动作可以较自动；涉及付款、发送、删除、公开分享等有后果的操作，则应有明确确认。

产品设计上，可以把每个阶段都当成一个可检查节点：用户是否知道系统理解了什么、准备调用什么、正在执行什么、最终提交什么。Agent 不是把流程藏起来，而是把流程推进得更顺，同时把关键决策留给人。

A2A 能互相调用，不代表可以互相信任

A2A 适合把能力拆给不同服务或 Agent，但“能互相调用”不代表“可以互相信任”。每一次委托都要带上任务上下文、必要的权限范围、超时与错误语义。

接收方应知道自己是在查询、准备草稿还是执行不可逆动作；调用方也需要验证返回内容，不能把任意文本都当作可信指令。换句话说，A2A 解决的是协作效率问题，不是信任问题。权限判断必须由系统和业务层共同实施，模型输出不能成为权限判断依据。

产品经理在评审这类方案时，可以重点追问四个问题：

1. 这个 Agent 能调用哪些工具，边界是否写清楚？
2. 哪些动作只是查询，哪些会改变业务状态？
3. 高影响动作是否经过用户确认？
4. 调用失败、超时或返回异常时，用户能否看懂并接管？

会话状态比聊天记录重要

工程上，建议把会话状态拆成：目标、已收集参数、待确认动作、执行中的任务、结果和失败原因。

用户离开页面再回来，不能只恢复一串聊天气泡，却丢失了“订单已经创建但尚未支付”这样的关键状态。网络断开后重试，也要防止同一个操作被重复提交。涉及创建订单、寄件、付款等动作时，应有业务幂等策略，并让用户看得懂当前到底执行到了哪一步。

多轮对话还要处理歧义和上下文污染。比如用户说“换成上次那个地址”，系统应确认“上次”指哪条记录；不能仅凭模型猜测就读取或暴露个人资料。授权应由系统和业务层共同实施，模型输出不能成为权限判断依据。

先做一条窄链路，再谈多 Agent 协作

更稳妥的落地方式，是从一个低风险、高频、结果可验证的任务开始试点。例如“寄快递”的场景，先让 Agent 查询订单状态或整理寄件信息，再逐步开放提交动作。

上线前至少覆盖这些异常场景：

• 参数缺失；
• 网络超时；
• 工具返回异常；
• 用户中途取消；
• 重复点击；
• 会话恢复；
• 权限拒绝；
• 模型理解错误。

指标也要拆开看：任务完成率、用户确认后撤销比例、人工接管率、重复执行率、端到端时延和失败原因分布。只看“回答看起来像不像人”很容易掩盖业务操作的风险。

Agent 的成功标准应该是安全、稳定地完成用户任务，而不是对话轮数越少越好。先把一项任务做可靠，再扩成多 Agent 协作，比一开始就追求全自动更稳妥。

接入鸿蒙智能体能力时，仍要回到基本功

HarmonyOS 的智能体能力继续演进后，应用接入仍要回到这套基本功：清楚定义工具边界、提供可恢复的业务状态、让用户知道系统正在做什么。

可以把它总结为三条产品原则：

1. 能力可调用，但权限要可控：每个工具、每个 Agent 的职责和权限范围要明确。
2. 流程可自动，但后果要确认：查询可自动，付款、发送、删除、公开分享等动作要二次确认。
3. 对话可多轮，但状态要可恢复：用户离开再回来，恢复的是业务状态，不只是聊天记录。

真正需要设计的不是一句提示词，而是从请求进入到结果落地之间的状态机。先把一项任务做可靠，再扩成多 Agent 协作，会比一开始就追求全自动更稳妥。