HarmonyOS 7 将智能体推向应用设计前台，但“能对话”与“能完成任务”之间隔着产品责任。本文提出最小原型验证法，从工具契约、失败场景到产品指标，教你避开 Demo 陷阱，让智能体真正承担任务。

HarmonyOS 7 把“智能体”推到了应用产品设计的前台。对开发团队来说，最有吸引力的想象不是多一个聊天窗口，而是用户说出目标，系统理解意图，调用应用或服务能力，把原本需要多次点击的任务完成。

但“能对话”和“能完成任务”之间，隔着一整套产品责任：信息不完整时谁来追问，涉及权限和费用时谁来确认，执行到一半失败后如何恢复，多个智能体或服务协作时怎样传递上下文，最终结果由谁展示和承担。

所以，第一次探索鸿蒙智能体，不应该以“做出一个很聪明的 Demo”为目标，而应该用一个最小原型验证：某个多步骤任务是否适合交给智能体，以及用户是否仍然能够理解、控制并纠正它。

一、先把三个名字分开

当前官方资料中，有几个相近但不等同的概念。

华为将面向鸿蒙生态的整体框架称为鸿蒙智能体框架，英文为 Harmony Agent Framework，简称 HMAF。官方介绍强调，它定义鸿蒙系统、应用或元服务与智能体之间的交互协同范式。

小艺开放平台则提供智能体开发与分发相关工具。华为官方“天工计划”页面列出的智能体编排方式包括 LLM、Workflow 和 A2A，并将开发、多端调试、部署上架纳入工具链范围。

Agent Framework Kit 是 HarmonyOS SDK 中的一个 Kit。官方文档对它的描述是：

在应用内拉起智能体组合的服务，让用户可以在适当场景下通过 UI 控件能力主动拉起智能体。

它不是“所有智能体能力”的同义词，也不能仅凭名字推断它负责智能体规划、工具调用和跨智能体协商的全部过程。

二、不是所有多步骤任务都适合智能体

最适合做首个原型的，不是步骤最多、想象空间最大的任务，而是边界最清楚的任务。

可以假设一个“安排一次线下服务”的场景：用户提出时间与地点偏好，系统查询可选项，用户选择，确认必要信息，最后提交预约。这个场景只用于建立评估框架，不代表已经完成接入或测试。

它是否适合智能体，要看四个条件。

第一，目标能否清楚表达。用户说“帮我安排一下”可能缺少时间、地点和服务类型，智能体必须知道何时追问，而不是自行补全关键条件。

第二，步骤是否可以被结构化。查询、选择、确认、提交分别需要什么输入，返回什么结果，失败怎样表示，必须可以写成稳定的能力契约。只有人能看懂的页面流程，不会自动变成可靠的智能体工具。

第三，风险是否可控。涉及付款、个人敏感信息、不可撤销操作或专业判断时，不能把流畅度放在知情和确认之前。风险越高，越需要明确确认点、权限边界和人工接管。

第四，结果是否可验证。预约成功应该有可查询的记录和明确状态，而不是智能体说一句“已经为你处理好了”。没有外部可验证结果的任务，很难判断智能体究竟完成了什么。

三、把原型写成一个可证伪的假设

“验证智能体能力”太宽，最后往往只剩演示。更好的原型假设可以写成：在用户给出不完整目标的情况下，智能体能够补齐必要信息，在最终提交前获得明确确认，并在任一步骤失败时保留已确认内容，让用户可以继续或转回普通页面完成。

这句话里包含四个可被推翻的判断：能否识别缺失信息，能否正确追问，能否在高风险动作前停下来，能否从失败中恢复。

原型范围也应该随之收缩。只选择一个任务、一组有限意图、少量明确工具和一种结果卡片。不要同时加入跨设备、多模态、主动推荐和多个智能体协作，否则一旦失败，团队无法判断是意图识别、工具契约、权限、界面还是协作协议出了问题。

最小不是功能少，而是变量少。每一次原型都应该只让一个关键假设暴露出来。

四、能力接入之前，先把工具契约写清楚

智能体能够调用应用能力，并不意味着可以直接复用所有内部接口。面向智能体的工具需要更清楚的边界。

输入字段要区分必填、可选和默认值，不能让模型猜测业务关键参数；枚举和范围要明确，避免自然语言被错误映射；返回结果要包含业务状态和可供用户理解的信息，不能只给一个模糊的成功布尔值；错误要区分可重试、需要补充信息、需要用户处理和不可继续。

更重要的是副作用。查询可选时间通常是只读动作，真正提交预约则会改变外部状态。两者不应拥有相同的调用门槛。对有副作用的动作，应展示将要发生什么，让用户确认关键参数，并为重复调用设置业务防护。

A2A 也不能被理解成“让两个智能体自己商量就行”。华为官方资料确认小艺开放平台提供 A2A 模式，官方文档目录还提供“端 A2A 协议技术规范”和应用内 Agent 接入资料；具体消息规范、身份、权限和可用范围应以当前接入文档为准。产品层仍要决定哪些信息可以传递、传给谁、用户如何知情，以及协作失败后由哪个参与方负责收口。

五、最小原型至少要跑六类失败场景

一次顺利完成不能证明产品成立。真正有价值的测试从故意破坏流程开始。

第一类是不完整表达。用户不给时间、地点或对象，观察智能体是否只追问必要信息，还是擅自假设。

第二类是歧义。用户给出两个可能解释的说法，观察系统是否暴露选项并让用户确认。

第三类是权限拒绝。用户不愿提供位置、联系人或其他信息时，任务能否通过手动输入继续，而不是直接终止。

第四类是工具失败。查询超时、服务不可用或返回空结果时，智能体是否准确说明现状，保留已填写信息，并给出可执行的下一步。

第五类是中途改意。用户在最终确认前修改时间或对象，系统能否只重算受影响步骤，而不是沿用过期结果。

第六类是重复与越权。用户连续确认、恢复会话或用含糊表达要求执行高风险动作时，系统能否避免重复提交，并拒绝超出授权范围的操作。

这些场景的评估不能只看模型回答是否自然。还要看真实业务状态、调用记录、确认界面和最终结果是否一致。语言很顺但状态错了，比直接失败更危险。

六、产品指标不要从“聊了多少轮”开始

智能体产品很容易用对话轮数、回答长度和主观“聪明程度”衡量体验。但对任务型智能体，核心指标应该围绕任务责任。

可以先记录：必要信息是否完整、工具选择是否正确、高风险动作是否经过确认、最终状态是否可验证、失败后是否可恢复、用户是否能够转回普通路径。具体目标值必须来自真实测试，不能在原型开始前编一个漂亮比例。

对话轮数只能作为诊断信息。轮数少可能代表路径高效，也可能代表系统跳过确认；轮数多可能是啰嗦，也可能是任务本身存在必要追问。最终判断仍然是：用户是否在知情、可控的前提下完成目标。

隐私和安全也不能等到上架前补。原型阶段就要记录每个工具需要的数据、处理目的、最小范围、保存位置和共享对象。智能体能够串联更多能力，意味着一处含糊授权可能被放大成跨步骤的数据流动。系统越主动，责任边界越要显式。

七、什么时候应该暂缓产品化

MVP的结论不一定是继续。

如果任务的关键条件总需要人类专业判断，工具接口无法稳定表达业务状态，失败后没有可靠补救，用户无法理解智能体将要执行什么，或者普通页面只需两步而对话反而增加负担，那么暂缓智能体化是合理结果。

智能体不是新入口的必选项，而是一种重新组织任务的方式。它最有价值的地方，是把原本分散、重复、需要跨服务协调的步骤压缩成一个可控过程；它最危险的地方，是让用户在没有看见中间步骤时误以为系统已经正确完成。

因此，HarmonyOS 7 的智能体探索不该从宏大的“应用会不会消失”开始，而应该从一个很小的问题开始：哪一个任务值得被重新组织？系统要拿到哪些能力？在哪些节点必须把控制权交还用户？

当这三个问题被最小原型真实回答，智能体才从展示能力变成产品能力。否则，再自然的对话也只是一个无法承担结果的界面。