Agent Product 101｜06｜Workspace：任务需要一个工作空间

Workspace 是 Agent 产品的任务容器：把目标、上下文、文件、状态、日志、预览、协作和交付物组织成一个可恢复的工作对象。

核心结论

Workspace 是 Agent 产品的任务容器。它不是一个“聊天窗口旁边的文件夹”，而是把用户意图、输入材料、运行状态、权限凭证、工具日志、预览结果、协作记录和最终交付物组织在一起的产品对象。

对产品经理来说，Workspace 的价值是把 Agent 从“一轮对话”升级为“一个可继续、可复盘、可协作、可交付的任务”。如果没有 Workspace，用户只能在聊天记录里猜 Agent 做了什么；有了 Workspace，用户可以看到任务在哪里、做到哪一步、产物是什么、下一步谁来处理。

一个好的 Workspace 至少要回答：

问题	Workspace 中的产品对象	用户收益
任务是什么？	brief、目标、约束、验收标准	不必在长对话里反复解释
Agent 用了什么材料？	文件、链接、数据源、上下文包	知道结果从哪里来
现在做到哪一步？	plan、进度、状态、阻塞原因	可以等待、催办或接管
产物在哪里？	preview、diff、draft、PR、ticket、report	能直接审查和交付
出错怎么办？	checkpoint、日志、回滚、重试入口	失败不是从头再来

从真实产品看 Workspace

v0、Lovable、Replit Agent 展示了 app builder 类产品的 Workspace：用户输入的是产品想法，系统需要把它变成项目、页面、组件、预览、部署和后续修改入口。PM 要关注的不是“生成代码多快”，而是用户能否围绕一个项目持续迭代。

Claude Code、Cursor、Codex 和 GitHub Copilot coding agent 展示了开发者 Workspace：repo、branch、diff、terminal、test、PR、review 共同构成工作空间。Agent 的成果必须进入工程团队已有的协作制度，而不能停留在聊天建议里。

Slack 中的 Agent 说明 Workspace 也可以是 thread、channel 或 workflow run。团队沟通场景里，任务材料、参与者、决策、通知和后续动作都散落在多人上下文里，Agent 需要把它们重新组织成可推进的工作对象。

Agentforce、Copilot Studio 的企业 Agent 则把 Workspace 扩展到业务对象：客户、工单、商机、审批、流程实例、连接器和策略。这里的 Workspace 不一定长得像 IDE，但一定要有状态、权限、记录和交付结果。

产品模型：Workspace 的五个层次

1. Brief：任务说明书

Brief 是 Workspace 的起点。它不只是用户的一句话，而是被产品整理过的任务目标、边界、输入、输出格式、截止时间和验收标准。

Brief 要素	PM 应该追问
目标	用户最终想完成什么业务结果？
范围	哪些对象包含在任务内，哪些明确排除？
输入	Agent 需要哪些文件、链接、数据或账号授权？
约束	风格、品牌、合规、预算、时间、权限限制是什么？
验收	用户如何判断“可以交付”？

2. Context：可管理的上下文

Agent 不应该把所有历史对话和所有文件都塞进上下文。Workspace 需要让上下文可见、可替换、可删除、可补充。PM 应该设计“当前任务正在使用哪些材料”的可视化，而不是只依赖模型自己记住。

3. State：可恢复的状态

Workspace 的核心是状态。一个任务可能处于草稿、运行中、等待授权、等待用户确认、失败、已暂停、已完成等状态。每个状态都应该对应用户能理解的下一步动作。

状态	用户应该看到	可用操作
草稿	Agent 理解的任务和计划	修改 brief、补材料、开始执行
运行中	当前步骤、预计输出、已完成事项	暂停、查看日志、调整优先级
等待授权	需要访问的数据或要执行的动作	授权、拒绝、缩小范围
等待确认	预览、diff、影响范围	批准、修改、要求重做
失败/阻塞	失败原因、已保留的进度	重试、回滚、接管、升级
完成	最终产物、证据、后续建议	验收、发布、分享、归档

4. Artifact：可审查的交付物

Workspace 必须把 Agent 的输出变成明确的 artifact：文档草稿、页面预览、设计方案、代码 diff、PR、工单更新、客户邮件、数据报告。没有 artifact，用户只能评价“回答好不好”；有 artifact，用户才能判断“任务是否完成”。

5. Collaboration：多人协作面

一旦 Agent 进入团队场景，Workspace 就要支持评论、分派、审批、通知、版本和权限。PM 不应只设计单人对话体验，而要考虑谁能进入这个 Workspace、谁能看、谁能改、谁能批准。

产品判断表：什么时候需要 Workspace？

产品场景	是否需要显式 Workspace	原因
单轮问答、解释概念	不一定	输出即结果，状态成本高于收益
写一封短邮件草稿	轻量 Workspace	需要草稿、收件人、发送确认
创建一个 landing page	强 Workspace	有项目、文件、预览、迭代、发布
修复一个 GitHub issue	强 Workspace	有 repo、branch、测试、PR、review
跟进一个销售商机	强 Workspace	有客户对象、沟通记录、审批和 CRM 写入
周期性运营报告	强 Workspace	有数据源、定时任务、版本和分发

反例与误区

误区一：把 Workspace 做成文件管理器

Workspace 不是“把文件放在一起”这么简单。它要表达任务状态、Agent 计划、权限、证据、产物和下一步。只有文件没有状态，用户仍然不知道 Agent 进行到哪。

误区二：把聊天记录当作唯一工作空间

聊天记录适合沟通，但不适合承载复杂任务。用户不应该从几十轮对话里找最新版本、确认点和交付物。Workspace 应该把这些信息结构化呈现。

误区三：每个任务都建一个重型项目

Workspace 也不能过度设计。低风险、短周期任务可以用轻量卡片或临时草稿承载。PM 要根据任务复杂度决定 Workspace 的厚度。

设计原则

1. 先定义任务对象，再定义界面

不要先问“左侧导航放什么”。先问用户交给 Agent 的对象是什么：project、repo、thread、ticket、customer record、workflow run，还是本地 session。对象决定状态和操作。

2. 让 Workspace 成为事实来源

任务目标、使用材料、运行状态、关键决策和交付物都应该在 Workspace 中可见。聊天可以辅助解释，但不能成为唯一事实来源。

3. 把失败路径放进 Workspace

暂停、重试、回滚、接管、补充上下文、重新授权都应是 Workspace 的正常操作，而不是异常提示后的死路。

4. 让 Workspace 对接原有工作流

开发者要 PR 和 CI；销售要 CRM 更新；客服要工单；运营要文档和发布计划。Workspace 的终点应该是用户已有工作流中的交付物。

PM 检查清单

这个 Agent 任务需要持久化吗？用户明天回来能继续吗？
Workspace 的核心对象是什么：项目、仓库、工单、客户、thread 还是流程实例？
用户能否一眼看懂任务目标、状态、阻塞点和下一步？
Workspace 是否展示 Agent 使用的上下文和数据来源？
产物是否脱离聊天记录，成为可审查、可分享、可交付对象？
是否支持版本、预览、diff、回滚或重新生成？
团队成员能否评论、审批、接管或订阅通知？
完成后的 Workspace 如何归档、复用或变成模板？

小结

Workspace 的本质是让 Agent 的工作“有地方发生”。它把对话中的意图变成可持续推进的任务对象，把模型输出变成可审查的交付物，也把失败、协作和恢复纳入产品路径。

下一篇进入 Long-Running Tasks：当 Workspace 承载任务后，Agent 工作就可以从即时回复升级为可排队、可暂停、可恢复的后台任务。