内部用户与外部用户
外部用户通过 Agent Pass 使用 Agent，并以信用积分的方式计算使用成本，因此需要明确使用权限和消耗信息。
01 / AI 产品 / ZOOM CHAT
AI Agent for ZOOM Chat
Zoom AI Agent 是一套覆盖 Zoom Meeting、Chat、Mail、Doc、Contact Center 等产品线的 AI 能力体系。我主要负责 Zoom Chat 场景下的产品设计，并梳理 AI Agent 在聊天、会议和团队协作中的具体使用方式。
项目背景与我的角色
在项目初期阶段，公司的产品生态在面临AI带来的巨大转型压力下，提出了All in AI的战略需求：让用户能够在 Zoom 全产品生态 中使用 AI Agent。
面对如此高度浓缩的需求时，作为该产品的产品设计师，我意识到这并不是简单的增加一个功能入口那么简单。我首先根据产品的切入点ZOOM Chat为例，在用户使用AI Agent的场景下，Agent的入口、用户的身份、Agent 的创建者、使用范围、调用位置和执行风险，都会影响最终的产品体验。因此，我围绕“用户如何使用 Agent”作为核心问题，重新拆解整个使用流程。并将其应用到具体的产品方案中
用户使用场景分析
在明确要解决的问题后，我需要明确此次调整面对的用户角色是谁，以及他们有什么使用场景。我首先从用户和 Agent 之间的关系入手，将用户场景分为几类：
自己创建与他人创建
两者在管理权限、使用权限和信息展示上并不相同，用户需要知道 Agent 从哪里来，以及自己可以做什么。
个人使用与多人群组使用
个人调用更关注效率和隐私，群组调用则需要考虑信息是否公开，以及是否会对其他成员造成干扰。
会议场景与聊天场景
用户可能在会议前准备信息、会议中调用 Agent，也可能在 Chat 或 Channel 中围绕同一项任务持续协作。
关键设计问题与方案推导
当明确主要用户以及使用范围后，我将围绕用户如何使用 Agent 的这个具体场景进行完整生命周期的分析，包括用户从初始添加到使用结束整个AI Agent的过程。
用户如何找到合适的 Agent
用户不一定知道有哪些 Agent，也不一定理解每个 Agent 能解决什么问题。因此，我将 Agent 的能力、适用场景、创建者、使用范围、输入方式和示例任务作为重要信息进行整理，并通过 Agent 卡片帮助用户快速判断这个 Agent 是否适合当前任务。
对于他人创建的 Agent，我重点区分了谁创建的、谁可以使用、可以解决什么问题；对于自己创建的 Agent，则增加了管理、配置和后续维护的使用路径。
如何让群组中的用户知道 Agent 的存在
在群聊中，部分用户可能没有使用过当前 Agent，也不了解它的作用。如果直接加入强制性的引导，容易打断正常讨论。因此，我将 Onboarding 放在具体使用场景中：当 Agent 第一次在群组中被调用时，通过提示和卡片说明它的功能、使用方式和可见范围，让用户在真实任务中理解 Agent，而不是先阅读一套与当前工作无关的教程。
对于首次使用的用户，则重点降低第一次操作的理解成本，包括说明 Agent 能做什么、需要提供哪些信息、执行后会产生什么结果，以及是否会消耗信用积分。
如何处理个人调用和群组调用
个人调用和群组调用并不是同一种交互模式。个人使用时，用户更关注快速完成任务以及结果的私密性；群组使用时，则需要明确谁发起了调用、谁能够看到输入和结果，以及 Agent 的回复是否会持续打断对话。
因此，我将调用范围、结果可见性、是否需要提醒群组成员，以及是否需要用户主动确认等内容纳入调用流程中。设计的判断依据主要包括任务的敏感程度、信息的可见范围、调用频率和对群组讨论的影响。
如何让 Agent 产生持续的使用价值
除了帮助用户找到 Agent，我还进一步思考了用户如何理解和复用他人创建的 Agent。为此，我将 Agent 卡片设计成一个能够解释工作方式的载体，除了展示名称和描述，也说明它的输入、处理方式、输出结果和适用场景，帮助用户理解一个 Agent 背后的工作流程。
在此基础上，Agent Market 可以作为 Agent 的发现和共享入口，让不同用户创建的 Agent 被更多人找到和复用。对于个人创建的 Digital Twin，则需要进一步明确它可以代表用户处理哪些基础问题、哪些问题必须交回给本人，以及在什么情况下需要人工介入。
如何降低 Workflow 创建和执行的门槛
对于 Workflow 的创建，我将需求拆分为两种方式：一种是用户通过自然语言描述目标，由系统协助生成流程；另一种是用户基于预设模板快速开始。无论采用哪种方式，用户都需要能够查看和调整具体步骤，而不是直接接受一个无法理解的自动化结果。
在 AI 执行过程中，我也重点考虑了 Human-in-the-loop 的设计。对于信息查询、内容整理等低风险操作，可以减少不必要的确认；对于发送信息、修改数据、改变权限等可能造成影响的操作，则需要在执行前展示具体动作、涉及对象和预期结果，并提供确认、修改或取消的机会。
产品设计过程
我将以一个具体的设计用例来解释产品概念到最终落地的最后思考过程。
案例详情：以“用户如何在 Chat 群组中调用 AI Agent”为例，将整个流程分为三个层级：AI Agent 的唤起、AI Agent 的调用，以及调用后的持续使用来进行分析。
如何唤起AI Agent
首先需要判断用户想要调用的 AI Agent 是否已经安装到当前群组中。
如果 AI Agent 已经安装，用户可以通过 @ 或 / 等方式唤起 Agent，并进一步选择具体的 AI Agent。这里的问题并不只是“如何搜索”，还包括用户能否判断当前 Agent 是否真正适合自己的任务。
因此，在 Agent 的选择过程中，我们需要展示更多能够帮助用户做判断的信息，例如 Agent 的名称、能力描述、创建者、适用场景、使用范围和示例问题。通过这些信息，用户可以区分不同 Agent 的功能，也能够判断它与普通 App 或其他 Agent 之间的差异。
如果用户选择的 AI Agent 尚未安装到当前群组，则需要明确提示当前状态，并提供下一步操作。例如，提示该 Agent 暂不可用于当前群组，或引导 Admin 前往 AI Agent Market 完成安装。这样可以避免用户误以为 Agent 无法使用，也让安装权限和使用权限之间的关系更加清晰。
在这一层级中，我们主要需要回答三个问题：
- 当前群组是否已经安装了这个 Agent；
- 这个 Agent 是否能够解决用户当前的问题；
- 如果 Agent 不可用，用户下一步应该如何处理。
如何调用AI Agent
当用户成功选择 AI Agent 后，接下来需要处理调用范围和信息可见性的问题。
AI Agent 在群组中被调用时，可能会影响其他成员的阅读和交流。如果每一次调用都通知整组用户，或者将完整的 AI 对话直接展示在主聊天区域，就可能对与当前任务无关的成员造成干扰。
因此，我们将调用方式区分为 public 和 private 两种模式：
- 通过 @ 调用时，代表公开调用。群组成员可以看到 Agent 被调用，并根据需要查看相关结果；
- 通过 / 调用时，代表更低干扰的私密调用。调用内容和结果可以只对当前用户可见，必要时再引用到群组的公共区域。
在公开调用中，我们将完整的交互内容放入 Thread，主聊天区域只保留必要的调用信息和结果摘要。这样既能让群组成员知道有人正在使用 AI Agent，又不会让大量过程信息持续打断正常对话。
在私密调用中，则不向整个群组广播用户的提问内容。用户可以先与 Agent 完成个人对话，确认结果有必要与团队共享后，再将相关内容引用到 Public 区域或指定的群组讨论中。
此外，调用后的状态反馈也需要被明确展示。用户发起调用后，系统应及时反馈 Agent 是否已成功唤起、当前是否正在处理，以及最终是否返回结果。对于群组成员来说，他们可以通过这些状态信息判断当前是否有 Agent 参与讨论，而不需要重复发起操作。
调用后如何使用
当用户决定使用 AI Agent 后，实际的使用方式会根据 Agent 的功能而变化。现阶段，我们主要聚焦于用户与 AI Agent 之间的对话式交互。
完整流程包括：
- 用户唤起 AI Agent，并描述需要解决的问题；
- 系统展示 Agent 当前的处理状态，让用户知道请求已经被接收；
- AI Agent 在 Thread 中返回处理结果；
- 用户可以继续在 Thread 中追问、补充信息或调整需求；
- 用户确认结果后，可以将内容引用到 Public 区域或群组讨论中。
我们选择 Thread 作为主要承载空间，是因为它能够保留完整的上下文，同时减少对主聊天内容的干扰。用户可以在同一个 Thread 中持续追问，Agent 也能够基于之前的对话理解后续需求。
在这个过程中，我们重点考虑了两个问题：一是如何让用户知道 AI Agent 当前正在做什么，二是如何让用户对结果的公开范围保持控制。因此，设计上更强调处理状态、结果位置和内容可见性，而不是将所有信息直接展示给群组成员。
最终方案
面对以上三个层级的问题，我们在多轮需求讨论和设计 Review 后，将用户发起调用的入口作为核心交互。
最终方案围绕 @ 和 / 两种方式建立统一的 AI Agent 使用路径，并将 Agent 的发现、安装、调用、对话和内容引用串联起来：
- 用户可以通过 @ 或 / 快速找到并唤起 AI Agent；
- 如果 Agent 尚未安装，系统会提示当前状态，并引导 Admin 前往 AI Agent Market；
- 通过 @ 进行公开调用，通过 / 进行更低干扰的私密调用；
- 对话内容统一在 Thread 中展开，减少对主聊天区域的影响；
- 用户可以在完成个人对话后，将有价值的结果引用到 Public 区域或群组讨论中；
- 通过明确的状态反馈，让用户和群组成员知道 Agent 是否被成功调用以及当前的处理进度。
在这个过程中，我主要负责场景拆解、用户流程设计、调用规则梳理以及交互方案输出，并与 PM 一起明确不同用户身份、使用范围、信息可见性和群组干扰之间的关系。最终，AI Agent 不再只是一个被动等待调用的功能，而是被放入用户真实的聊天和团队协作流程中进行设计。
我的个人贡献
在这个项目中，我负责 Zoom Chat 相关场景的产品和交互设计，并参与了从需求梳理到方案落地的完整过程。我的主要工作包括：
- 将“让用户使用 AI Agent”等抽象需求拆分为用户身份、权限、可见性、调用方式和执行控制等具体问题；
- 梳理 Meeting、Chat、Channel 和个人使用等不同场景下的用户任务与操作流程；
- 设计 Agent 的发现、安装、管理、引用、调用和 Onboarding 流程；
- 建立个人使用与群组使用之间的交互规则，处理信息可见性和群组干扰问题；
- 参与 Agent 卡片、Agent Market、Digital Twin、Workflow 和 Human-in-the-loop 等延展场景的设计思考。
最终产品框架
最终，这个项目形成了一套围绕 Agent 发现、理解、使用和管理的产品框架，不再将 AI Agent 作为单独的功能入口，而是将它放回用户真实的聊天、会议和团队协作流程中进行设计。
