Agent Product 101｜07｜Long-Running Tasks：把任务变成可管理对象

Long-Running Tasks 让 Agent 从一次聊天回复升级为可排队、可暂停、可恢复、可通知、可验收的后台工作对象。

核心结论

Long-Running Tasks 的核心不是“让 Agent 跑得更久”，而是把任务变成可管理对象：可以排队、启动、暂停、恢复、取消、通知、审查和验收。

对产品经理来说，这一章的关键收益是：你会把 Agent 的时间维度产品化。很多高价值任务无法在一次回复里完成，例如修复代码、生成应用、整理销售线索、处理工单、准备报告、执行多系统流程。产品必须让用户在离开页面后仍然相信任务在推进，并在关键节点回来做决策。

一次聊天回复只需要回答“现在说什么”；长期任务必须回答更多问题：

产品问题	用户真实关心	PM 要设计的对象
任务是否开始了？	我交代的事有没有进入队列？	job、queue、start 状态
现在做到哪？	还要等多久？卡在哪里？	progress、step、checkpoint
我能打断吗？	发现方向不对能不能停？	pause、cancel、take over
失败了怎么办？	是不是全部白做了？	retry、resume、rollback
什么时候找我？	不要一直打扰，也不要错过关键点	notification、approval gate
怎么验收？	它到底交付了什么？	artifact、review、acceptance

从真实产品看 Long-Running Tasks

Codex cloud task 和 GitHub Copilot coding agent 展示了典型的后台工程任务：用户提交 issue 或需求，Agent 在隔离环境中分析、修改、运行检查，最后输出 branch、diff、draft PR 或 review 结果。这类任务天然跨越数分钟到数小时，产品必须支持排队、进度、失败恢复和审查。

Replit Agent、v0、Lovable 展示了构建类长期任务：从一句产品想法到可预览应用，中间会经历生成、运行、修错、预览、迭代、部署。用户并不想盯着每一步技术细节，但需要在关键节点看到成果并做选择。

Cursor、Claude Code 代表开发者在本地或 IDE 中的长期任务：Agent 可以连续读文件、改代码、跑测试，但开发者需要随时暂停、查看 diff、接管上下文，避免“跑了很久但方向错了”。

Copilot Studio、Agentforce 和 Slack 中的企业 Agent 则提醒我们：长期任务往往涉及多人和多系统。比如处理一个客户升级工单，Agent 可能需要查资料、更新 CRM、通知 Slack、等待经理审批。这里的关键不是模型持续输出，而是流程状态持续可见。

产品模型：长期任务的生命周期

1. 创建：把意图变成任务单

长期任务不能只记录一条 prompt。创建任务时，产品应把目标、范围、输入、权限、预期产物、优先级和通知方式整理成任务单。用户应该能在启动前确认“Agent 理解的任务是否正确”。

2. 排队：管理等待，而不是假装立即开始

当任务需要资源、环境、权限或审批时，排队是正常状态。PM 不应隐藏等待，而应让用户知道排队原因、预计开始时间、优先级和是否可以取消。

3. 执行：展示进度，不展示噪音

长期任务需要进度可见，但不等于把所有日志倾倒给用户。产品应把底层动作归纳成用户能理解的阶段：理解需求、收集材料、生成方案、执行修改、验证结果、等待确认。

4. 阻塞：把“卡住”变成可操作状态

Agent 卡住时，最差体验是沉默或无限转圈。更好的体验是说明阻塞原因：缺少权限、信息不足、工具失败、外部系统不可用、结果不确定，并给出明确选择。

5. 交付：输出可验收产物

长期任务的终点不是“完成了”三个字，而是可验收的 artifact：PR、报告、预览链接、CRM 更新、工单处理结果、审批请求、部署记录。用户要能接受、要求修改或拒绝。

产品判断表：哪些任务适合长期运行？

任务类型	是否适合长期任务	产品建议
简单问答、解释概念	不适合	保持即时对话，不引入任务系统
资料整理、长文总结	轻量长期任务	显示进度和结果，可后台完成
代码修复、测试、PR	非常适合	需要隔离环境、diff、CI、review
应用生成、页面搭建	非常适合	需要 workspace、preview、checkpoint
客服/销售流程处理	非常适合	需要权限、审批、通知、审计
高风险金融/法律动作	谨慎适合	必须加入强审批和人工验收

通知设计：什么时候打扰用户？

长期任务最容易出现两个极端：要么每一步都通知，用户被打扰；要么完全不通知，用户失去信任。PM 可以按“是否需要用户决策”来设计通知。

节点	是否通知	原因
任务已进入队列	轻通知	给用户确定感
正常执行中的每个小步骤	通常不通知	避免噪音
需要新权限或补充信息	必须通知	没有人类输入无法继续
发现高风险动作	必须通知	需要授权或审批
任务失败但可自动重试	可汇总通知	用户只需知道结果和影响
产物可审查	必须通知	进入验收阶段
长时间无进展	应通知	防止用户以为系统失效

反例与误区

误区一：用 loading 动画承载长期任务

加载动画适合秒级等待，不适合分钟级或小时级任务。长期任务需要明确状态、后台运行、通知和恢复入口，而不是一个无限转圈。

误区二：只显示技术日志

技术日志对工程师有用，但对多数 PM、运营、销售、客服用户来说不是进度。产品要把日志翻译成业务阶段和下一步选择。

误区三：任务失败就让用户重来

长期任务最大的价值之一是可恢复。失败后如果只能重新输入需求，用户会认为 Agent 不可靠。至少要保留已完成步骤、输入材料和可复用产物。

误区四：后台执行等于全自动

长期运行不代表用户不参与。好的长期任务会在低风险环节自动推进，在高风险节点主动停下来请用户确认。

设计原则

1. 每个长期任务都要有“任务卡片”

任务卡片应包含目标、状态、进度、最近动作、阻塞原因、下一步和交付物入口。它是用户重回任务的锚点。

2. 进度要面向用户目标，而不是系统步骤

“正在调用工具”不如“正在检查修改是否通过测试”；“处理中”不如“等待你授权访问 CRM”。进度文案应该帮助用户判断是否需要行动。

3. 支持暂停、取消、接管和恢复

长期任务天然存在方向调整。用户应能暂停任务、修改 brief、取消执行、接管当前状态，并在合适时恢复。

4. 把验收设计为任务终点

任务完成后，用户应该看到产物、证据、风险、建议和可选动作：接受、修改、发布、分享、归档。没有验收，长期任务只是后台黑箱。

PM 检查清单

这个任务是否真的需要长期运行，还是即时回复就够？
用户离开页面后，是否能从任务列表或通知回到同一个任务？
任务状态是否包含排队、运行、等待用户、阻塞、失败、完成？
用户能否看到当前进度、最近动作和预计下一步？
哪些节点需要通知，哪些节点应该静默汇总？
失败后是否可以重试、恢复、回滚或接管？
任务产物是否明确、可审查、可验收？
指标是否衡量从创建到验收的完整漏斗，而不只是启动次数？

小结

Long-Running Tasks 的本质是把 Agent 的工作从“回答”变成“任务执行”。PM 要设计的不只是后台能力，而是任务生命周期、用户参与点、失败恢复和交付验收。

下一篇进入 Trust UX：当 Agent 可以长期运行，用户必须随时理解它在做什么、为什么这么做，以及如何控制风险。