异步任务体验

一句话理解：长任务体验的关键不是让用户盯着看，而是让用户放心离开：任务在后台可靠运行，需要人的时候能及时找到人，用户回来时一眼看懂发生了什么。

Agent 的价值往往恰好在长任务上：全站 SEO 诊断要跑 20 分钟，一批售后工单要处理一上午，Coding Agent 在云端实现一个功能可能要一个小时。如果这些任务要求用户一直开着页面，那用户节省下来的时间，又被“盯着 Agent 干活”消耗掉了。

更麻烦的是，长任务中途经常需要人：审批一个操作、确认一个模糊点、处理一个异常。如果 Agent 在这些时刻只是在页面上默默等待，而用户早已切去开会，任务就会卡住几个小时。这一课讲如何设计异步任务的体验。后台执行、断点续跑等工程机制见 长时间运行的任务 与 任务状态与 Checkpoint，这里聚焦用户侧的体验。

什么时候应该转为异步

不是所有任务都应该异步。一个实用的判断方式是看 预期耗时 与 用户是否需要立即得到结果：

预期耗时（示例区间）	建议形态	例子
几秒	同步，流式输出	查询订单状态
十几秒到两分钟	同步，展示进度，允许用户离开	单个订单的售后诊断
几分钟以上	后台运行，完成或需要人时通知	全站 SEO 诊断、销售周报
周期性或事件触发	常驻任务，只在例外时通知	每天早上自动巡检前一天的超时工单

图 1 把这四档放在一条轴上：

表中的区间是经验示例，要结合你的用户研究调整。关键是：任务开始时就告诉用户预期耗时，并给出“离开也没关系”的明确信号，例如“预计 15–20 分钟，完成后会通知你，你可以关闭此页面”。

任务中心：多个任务的总览

当 Agent 任务在后台运行，用户需要一个地方统一查看所有任务。任务中心的设计要点是 按“需要我做什么”组织，而不是按时间排序（图 2）：

几个细节：

• “需要我处理”置顶，并说明具体需要做什么，而不是只写“等待中”。
• 失败和部分完成归入“需要我处理”，因为它们通常需要用户决定下一步。
• 进行中的任务显示可数的进度，参考 计划与进度。
• 每个任务都能一键进入 对应的执行页，从执行页也能返回任务中心。

通知：该打扰时打扰，不该打扰时安静

通知设计最常见的失败是两个极端：什么都不通知，任务卡住没人知道；什么都通知，用户很快关掉所有通知。按事件类型设计：

事件	是否通知	渠道	通知内容
需要审批或确认	立即	应用推送、企业 IM	要确认什么 + 可直接操作的按钮
任务完成	是	应用内、IM 或邮件	一句话结论 + 产物链接
失败或部分完成	是	与完成相同，标记醒目	做成了什么、没做成什么、建议的下一步
执行中的步骤进展	否	仅在页面内显示	—
审批长时间无人处理	升级	通知备选审批人或主管	已等待多久、影响是什么

可以直接操作的通知 能极大减少审批等待时间。例如在企业 IM 里收到的审批卡片，直接包含通知内容预览和“批准 / 修改 / 拒绝”按钮，用户不必打开 Agent 产品。但高风险操作仍应引导用户进入完整的审批页面，见 审批与接管。

其他注意事项：

• 合并通知。同一个任务短时间内的多个事件合并为一条；批量任务完成时发一条汇总，而不是每个子任务发一条。
• 尊重工作时间。非紧急通知在用户设定的免打扰时段内延后发送。
• 让用户选择通知粒度。有的主管只想知道失败，有的专员想知道每个任务的完成。
• 通知本身也要可追踪。审批通知是否送达、是否被打开，是排查“为什么卡住”的关键信息。

回来之后：一眼看懂发生了什么

用户离开两个小时后回到任务页面，最需要的是一段 离开期间的摘要，而不是一长串执行日志：

你离开期间（14:05–16:10）
  ✓ 已完成 23 个工单的售后诊断
  ✓ 已发送 18 封客户邮件（你在 14:32 通过 IM 批准）
  ⚠ 5 个工单需要你决定是否发起退款                 [去处理]
  ✕ 2 个工单因订单系统故障未能诊断，已安排 17:00 自动重试
  费用：本任务已花费约 ¥12.40，预算 ¥30

这段摘要回答了用户回来时的四个问题：完成了什么、我之前做过什么决定、现在需要我做什么、有没有出问题。

另外两个常见需求：

• 运行中补充要求。 用户在任务执行过程中想到“对了，VIP 客户的通知要加上专属客服电话”。界面应该允许在运行中追加指令，并明确告诉用户这条指令从哪一步开始生效、已经发出的通知是否受影响。
• 中断后恢复。 任务因为系统故障、超时或用户暂停而中断，恢复时应该从中断的位置继续，并告知用户“从第 4 步继续，前 3 步的结果已保留”，而不是从头再来一遍。

图 3 把一个异步任务从发起到用户回来的状态流转串起来：

多任务并行

当用户同时运行多个 Agent 任务，会出现单任务时不存在的问题：

问题	例子	设计对策
资源冲突	两个任务同时要修改同一个工单的状态	检测冲突并提示；对共享资源加锁，后发起的任务等待或询问用户
重复工作	用户不小心为同一批工单发起了两次诊断	发起时检测相似任务，提示“已有进行中的相同任务”
注意力分散	5 个任务同时请求审批	在任务中心聚合审批请求，支持批量处理
成本失控	同时运行大量任务，费用快速累积	显示每个任务与总体的花费，设置用户或团队级预算上限
优先级	紧急异常任务排在批量巡检后面	允许用户调整优先级，紧急任务可以插队

常见误区

• “显示一个加载动画，等它跑完就好。” 超过用户耐心的任务必须支持离开和通知，否则用户会反复刷新或中断重来。
• “通知越多，用户越放心。” 过量通知会让用户关闭通知，真正需要处理的审批也随之被错过。
• “用户回来自己看日志就知道发生了什么。” 日志是给排查问题的人看的，普通用户需要的是离开期间的摘要。
• “任务失败了就让用户重新发起。” 长任务从头重跑既浪费时间又浪费成本，还可能重复执行已经完成的写操作。

设计要点

• 任务开始时告知预期耗时，长任务明确告诉用户可以离开。
• 任务中心按“需要我处理 / 进行中 / 已完成 / 失败”组织，需要处理的置顶。
• 通知只发给需要人的时刻和结果；审批通知可直接操作，长时间无人处理时升级。
• 合并通知，尊重免打扰时段，让用户选择通知粒度。
• 用户回来时提供离开期间摘要：完成了什么、做过什么决定、需要做什么、出了什么问题、花了多少钱。
• 支持运行中追加指令，并说明指令生效的范围。
• 中断后从断点恢复，避免重复执行写操作。
• 多任务场景下处理资源冲突、重复任务、审批聚合、预算与优先级。

练习

为「可执行的售后处理 Agent」设计异步体验（45–60 分钟）。场景：客服主管早上 9 点发起“处理昨天全部 120 个超时工单”的任务，然后去开两个小时的会。

1. 写出任务发起时的确认文案，包含预期耗时和离开提示。
2. 列出执行期间会产生的通知事件，为每个事件决定是否通知、通过什么渠道、通知内容是什么。
3. 写出主管 11 点回来时看到的“离开期间摘要”。
4. 设计一个在 IM 中直接批准客户邮件的消息卡片。

下一步

长任务中，失败几乎不可避免：接口故障、数据缺失、Agent 判断不了。下一课「失败的呈现」讲如何坦诚地报告失败与部分完成，并给出下一步建议。