05 / AI 产品 / MOBILE

ZOOM AI Agent for mobile

这个项目是 Zoom Chat AI Agent 的移动端延伸，主要目标是让用户在移动设备上也能够使用 Zoom AI Agent，完成信息查询、内容处理和沟通协作等任务。

项目背景

ZOOM AI Agent for Mobile 是 Fusion Agent 从桌面端向移动端延伸的项目。项目的目标不是将桌面端界面简单缩小，而是在移动端支持 AI Agent 的核心使用能力，让用户能够在 Chat Channel 中完成 Agent 的发现、调用、对话和结果分享。

项目启动时，Zoom Chat 正在进行 Slack 风格的信息架构重构，原本位于 Chat 中的 Agent 入口将面临位置变化。同时，移动端的屏幕空间、交互方式和开发资源也受到限制，因此项目并没有一次性实现完整的桌面端能力，而是先以“最小功能对等”为目标，优先解决移动端最常用、最基础的 Agent 使用场景。

我的角色

我参与了 Fusion Agent 移动端的产品和交互设计，主要负责跨端信息架构、Agent 调用流程、移动端使用规则以及相关边界场景的梳理。

参与定义 Mobile 端的功能范围和优先级；
设计 @agent 和 /agent 的调用方式；
梳理 Agent、App、Contact 和 Channel 之间的展示关系；
设计 Add Agent to Channel、Agent Profile 和 Agent Tag 等相关流程；
参与 Human-in-the-loop、Streaming Card 和错误反馈的移动端适配；
对比 Desktop 与 Mobile 的交互差异，明确哪些内容需要保持一致，哪些内容需要针对移动端重新设计；
与 PM、Desktop、Mobile、SDK 和协议团队进行多轮 Review，确认设计方案的实现条件和边界。

需求分析

“让用户在移动端使用 AI Agent”本身是一个比较宽泛的目标。为了将它转化为可以落地的设计方案，我先从用户任务出发，将问题拆成四个部分。

用户如何找到自己需要的 Agent；
Agent 是否已经加入当前 Channel，以及用户是否有权限添加；
用户如何区分公开调用和私密调用；
Agent 返回结果后，用户如何继续追问、确认和分享。

同时，我根据用户任务频率、信息可见范围、操作风险、移动端空间和开发成本，将功能拆分为不同优先级：

P0： @agent、/agent、Markdown 消息、Human-in-the-loop 和 Card Streaming；
P1： Agent Tag、Profile Card、Add Agent to Channel；
P2： Task Run Result 和 History 等更完整的管理能力。

这种拆分帮助项目在时间和资源有限的情况下，先保证 Agent 在移动端能够被找到、被调用并正常返回结果，而不是试图一次性复制桌面端的全部功能。

Level 1：AI Agent 的发现与唤起

用户首先需要知道当前可以使用哪些 Agent，以及当前 Agent 是否已经加入所在的 Channel。

在移动端，如果将 Contacts、Apps 和 AI Agents 完全拆成独立入口，会增加用户的寻找成本；但如果完全混排，又可能让用户难以区分“联系人”和“可执行任务的 Agent”。

在 MVP 方案中，我们将 App 和 Agent 放在同一个选择入口中，并通过 Agent 的头像标识、标签和 Profile 信息帮助用户进行区分。对于尚未加入当前 Channel 的 Agent，如果当前用户拥有添加权限，则在列表中展示添加入口；如果没有权限，则不展示 Add 按钮，避免用户执行后才发现无法完成操作。

这个方案解决了两个问题：

用户可以在已有的 App 入口中找到 Agent，不需要重新学习一套移动端导航；
添加权限被直接反映在界面中，减少无效操作和权限错误。

同时，我也参与梳理了 Agent 选择列表的展示逻辑，包括分类、排序、展开数量和 Agent 详情信息。设计时重点考虑移动端有限的屏幕空间，避免在用户输入过程中叠加过多提示和 Banner。

Level 2：公开调用与私密调用

Agent 被调用后，另一个关键问题是：这次调用是否应该被整个群组看到。

在群组中，用户可能只是想私下询问 Agent，也可能希望让整个 Channel 参与讨论。如果所有调用都直接展示给群组成员，容易造成信息干扰；如果所有调用都默认为私密，又会削弱 Agent 在团队协作中的价值。

因此，我们将两种调用方式进行区分：

使用 @ 调用 Agent，代表公开调用，相关消息和结果可以进入群组协作流程；
使用 / 调用 Agent，代表私密调用，消息和回复默认只对当前用户可见；
用户可以在确认结果后，将私密对话中的内容引用或转发到 Public 区域、Channel 或 Thread 中。

为了让用户理解两种方式的区别，设计中需要在输入提示和调用反馈中明确说明：使用 / 可以保持消息和回复私密；如果希望让群组成员看到，则使用 @。调用完成后，界面还需要反馈 Agent 是否已经成功唤起、当前是否正在处理，以及是否返回了结果。

对于失败情况，Mobile 端优先展示接口返回的错误信息；当接口没有返回具体内容时，则使用统一的错误提示，避免用户点击后没有任何反馈。

Level 3：结果展示与持续对话

目前移动端主要聚焦于对话式 Agent 体验，完整流程包括唤起、处理、返回结果、继续追问和协作分享。

用户唤起 Agent 并描述问题；
Agent 展示正在处理或生成中的状态；
Agent 在 Thread 中返回结果；
用户继续追问、补充信息或调整任务；
用户确认结果后，将内容分享至 Channel 或其他协作场景。

Thread 被作为主要的结果承载空间，是因为它可以保留对话上下文，同时减少 Agent 回复对主聊天内容的干扰。移动端的 Thread 流程以 Desktop 结构为基础，但在信息密度和操作方式上进行了适配。

在设计过程中，我们重点处理了移动端常见的问题：

避免多层气泡嵌套造成信息难以阅读；
减少非必要的边框和视觉层级；
对输入框提示和推荐内容进行取舍，避免占用主要操作空间；
确保 Markdown 和 Streaming Card 在移动端能够正常展示；
支持将 Agent 结果转发到 Thread 或 Channel，保证用户能够继续协作。

Human-in-the-loop

部分 Agent 在执行任务前需要用户确认，例如调用工具、访问数据或执行可能影响系统状态的操作。

这个流程在桌面端可以展示较多的权限和配置选项，但移动端没有足够空间承载复杂的权限管理。因此，移动端将 Human-in-the-loop 简化为当次任务决策，只保留 Allow 和 Deny 两个主要操作。像 Always Allow 这类长期权限设置，则不在移动端处理，而是引导用户前往桌面端进行管理。

在确认卡片中，移动端主要展示两类信息：

Agent 即将执行什么操作；
这项操作可能影响什么内容。

这种处理将“当次确认”和“长期权限配置”分开，既保留了必要的安全控制，也避免移动端出现过于复杂的设置流程。

跨端一致性与移动端适配

整个项目中，我将跨端一致性拆成两部分：需要保持一致的内容，以及需要根据移动端重新设计的内容。

需要保持一致的内容： Agent 的基本概念和命名；@ 与 / 的调用规则；Agent 的运行状态和结果状态；权限和可见性逻辑；Thread 中的上下文关系；Agent 结果的分享和引用方式。

需要根据移动端调整的内容： Agent 的入口和列表展示方式；信息层级和内容密度；操作按钮数量；Card 和 Markdown 的展示结构；错误提示和状态反馈；权限管理和复杂配置的位置。

设计判断主要基于四个因素：用户是否能快速完成任务、信息是否应该被其他成员看到、操作是否存在风险，以及当前移动端和 SDK 是否具备实现条件。

项目结果

项目最终以 Mobile 端的核心 Agent 使用能力为第一阶段目标，优先支持 Agent 的发现、调用、结果处理和协作分享。

在 Chat Channel 中通过 @ 或 / 调用 Agent；
查看和添加当前 Channel 中可用的 Agent；
接收 Agent 的流式消息、Markdown 和交互卡片；
在 Thread 中继续对话；
完成 Human-in-the-loop 确认；
将 Agent 结果分享至 Channel 或其他协作场景。

Agent 详情页、完整 Marketplace、Agent 创建、Task History 等能力则作为后续阶段继续推进。

这个项目的核心并不是把桌面端页面迁移到手机上，而是在移动端的空间、性能、权限和技术限制下，重新确定 Agent 的入口、调用方式、信息可见性和结果处理流程。我的主要贡献，是将“移动端支持 AI Agent”这一抽象目标，转化为一套包含优先级、交互规则、跨端约束和异常处理的可执行方案。