一个 Agent 完成了任务，下一位参与者却仍可能要从头开始。最新文件也许留在某台电脑上，决策埋在一段对话里，Preview 又开在另一个地方。
Agent.Space 为这些工作提供一个可以持续推进的固定位置。它把模型访问与一个云端 Workspace 结合起来，让受支持的 Agent harness 各自在独立 Session 中处理同一组已保存的项目文件。Session、Preview 和明确的团队上下文都留在 Workspace 中。即使更换 Agent，项目也不必重新开始。
Agent 不等于 Workspace
理解 Agent.Space 如何工作，要先把经常被统称为“Agent”的五个层级分开。
这些层级彼此独立。更换模型不会自动改变 harness 的工作方式，也不是每个模型都能与每个 harness 组合。当前支持哪些组合，应以线上 Agent 与模型选择器为准。
如果眼下要决定的是商业访问方式，可以继续看 Share 与 Flex 对比：它会说明不同模型分别使用哪种额度，以及两种余额为什么不会自动互相兜底。
如果需要进一步分清推理层与执行层，可以继续阅读 Agent harness 与模型的区别。
编辑器与 Agent 之间的协议位于这套产品分层之外，不会替代其中任何一层。理解 Agent Client Protocol 的协议边界可以避免把客户端集成误当成模型、Session 或 Workspace 能力。
一个 Turn 可以结束，但对应的 Session 和项目仍然保留。若要从一个 Agent harness 切换到另一个，应在同一 Workspace 中启动新 Session。新 Session 可以检查当前已保存文件和团队主动留下的交接说明，但不会悄悄继承另一个 Session 的对话或隐藏推理。
启动任务后会发生什么
先创建一个 Workspace，并定义一个边界清楚的结果，例如修复已知缺陷、构建一个具体页面、审查一项明确改动，或产出一份具体文档。
首先选择一个可用 Agent 和兼容模型。Agent 在一个 Session 中操作 Workspace 的普通文件树。它的产出可以作为源代码、研究资料、文档或其他文件继续留在项目里，而不是消失在私人聊天记录中。
工作推进时，人员可以检查这些文件，并在 Inspector 或浏览器 Preview 中打开受支持的输出。如果某个 Session 正忙，后续请求会继续显示在 Queue 里；Workspace 中的其他 Session 仍可并行推进。
这里的持久化是指：云端 Runtime 停止后，已经成功保存的项目文件仍会保留。它并不表示每个进程都会永远在后台运行。之后重新打开 Workspace，已保存的项目状态仍在；下一步需要执行什么，再重新启动相应进程。
交接应该延续项目，而不是重建项目
假设一个团队正在准备产品发布。
产品负责人把 launch-brief.md、研究资料和品牌素材加入 Workspace，再启动一个 Codex Session，给出边界明确的要求：根据 Brief 更新发布页，并运行相应检查。
Codex 在共享项目文件树中修改文件。团队一边查看 Brief 与 Preview，一边审阅结果。市场同事留下具体反馈，第二个 Session 再用 Claude Code，依据同一份源材料检查当前实现。
有效的交接并不是声称 Claude Code 能看到 Codex 的私有推理，而是团队主动保留下来的可检查状态：Brief、当前文件、渲染后的 Preview、测试输出、关键决定和未解决风险。下一位参与者可以从证据继续，不用靠记忆重建上下文，也不用来回传压缩包。
工作完成后，团队可以发布一个稳定的网页版本，或按原格式下载产出文件。
为项目带来合适的 Agent
不同任务适合不同的 Agent harness。截至 2026 年 8 月 26 日，Agent.Space 公开列出：
- Codex
- Claude Code
- Grok Build
- OpenCode
- DeepSeek Harness
DeepSeek Harness 当前仍属实验状态；不同 harness 的可用性、兼容模型和支持输入类型可能不同。正式确定工作流前，应检查线上选择器。
每个 Session 都保持清楚的 Agent 边界。一个 Session 可以让 Codex 构建功能，第二个让 Claude Code 审查改动文件，第三个再让 OpenCode 做一次聚焦修复。Agent 会改变，但共享项目状态仍然留在 Workspace 中。
这让 Workspace 成为工作流中稳定的中心。Agent harness 是项目参与者，而不是拥有项目的容器。
并行工作仍然需要主动协调
多开几个 Agent 窗口很容易，真正困难的是协调它们的改动。
Agent.Space 允许同一 Workspace 中的多个 Session 并行运行，并共同面对一份当前文件状态。人员可以在同一个地方看到文件、Session、Queue 和进度，而不用从彼此隔离的工具里收集状态消息。
这个共享中心不会取代项目纪律。Agent.Space 不会为每个 Session 自动创建私有分支，也不会自动合并冲突。团队仍然需要划分所有权、保持任务边界、审查当前文件，并在项目需要历史记录或回滚时使用版本控制。
多 Agent 编程工作流指南会把这些约束进一步整理成一套可执行的所有权、交接、审查与集成顺序。
共享不等于失控
共享 Workspace 需要明确的访问边界。Agent.Space 使用成员角色，区分不同成员可以执行的操作：
- Owner 与 Editor 可以修改共享文件并继续 Agent 工作。
- Viewer 可以检查共享上下文，但不能修改项目。
- Owner 管理邀请链接与 Workspace 所有权。
访问范围仅限 Owner，以及通过 Owner 管理的邀请链接加入的团队成员。Agent.Space 还会把不同项目放进相互独立的 Workspace 环境，不要求团队成员交换上游账号 Credentials，并允许用户导出普通文件和结果。你可以进一步了解产品的安全与成员控制。
如果需要确认 Owner、Editor 与 Viewer 的具体差别，可以查看 Workspace 角色与权限指南。
Agent.Space 增加了什么，哪些仍由上游决定
Agent.Space 是独立产品。它并非 OpenAI、Anthropic、xAI、DeepSeek 或 OpenCode 的官方产品，也不是共享账号或账号转售服务。它与名称相近的原 Google 产品也没有关系；Google Agentspace 与 Agent.Space 对比解释了两者区别，以及 Google Agentspace 后来的去向。
Agent.Space 提供云端项目边界：受支持的 Agent 与模型选择、Workspace 文件、Session、Preview、团队成员和一个可以开始及继续工作的共同位置。上游 Provider 仍然决定模型能力、harness 核心行为、Provider 专属条款，以及只存在于原生界面中的功能。
如果你需要的不是云端 Workspace，而是让本地 Coding Agent 或服务端集成使用模型，可以改看 Agent.Space Developer API 指南这条独立路径。
评估产品时必须保留这条边界。Agent.Space 不会让所有 harness 变得完全相同，不保证任意模型与 harness 组合，也不会复制全部上游 UI 功能。它的价值在于受支持工具周围那个可以持久工作的环境。
谁适合使用 Agent.Space
当 Workspace 能解决真实协调问题时，Agent.Space 最有价值：
- 你希望不同的受支持 Agent harness 操作同一组已保存项目文件。
- 你需要让任务跨多次工作继续，而不用重建项目环境。
- 团队成员需要从明确、可检查的材料审阅或继续工作。
- 你希望分别选择 Agent harness 与兼容模型。
如果你只使用一个 Agent，并且需要其完整原生界面或最新上游功能，官方 harness 可能更简单。如果执行必须留在自己控制的基础设施上，本地方案可能更合适。若某组模型与 harness 不受支持，就需要使用其他受支持路径，例如官方或自托管方案。
从一个真实任务开始
不要一开始就完整迁移项目。先把一个边界明确、可回退的任务放进 Workspace，检查受支持的 Agent 与模型组合是否适合，文件与 Preview 是否容易检查，以及另一个 Session 或团队成员能否从主动保留的状态继续。
这项测试比功能清单更能解释 Agent.Space 如何工作：商业访问为工作提供额度，模型提供能力，Agent harness 组织执行，Session 承载持续任务，Workspace 让项目继续推进。
打开 Agent.Space，加入能定义一个真实项目的文件，再把第一步交给合适的 Agent。任务改变时，保留 Workspace，换一个 Agent。