在 Coding Agent Workspace 中，Preview、发布和导出解决的是三个不同问题。
- 工作仍在修改时，用 Preview 检查结果。
- 需要稳定网页地址与可管理 Release 时，发布受支持的网站。
- 产物应以原文件格式离开 Workspace 时，下载或导出普通文件。
应该选哪一种，取决于你想验证什么。Preview 回答“当前效果是否符合预期”；已发布站点回答“这个固定网址现在应该指向哪个 Web Release”；下载文件则回答“我们究竟要交付哪份产物”。这三者都不能单独证明工作已经正确、安全或达到生产标准。
Preview、发布与导出快速对比
三条路径可以组合使用。团队可以先审查源码与 Preview，再发布批准后的 Web Release，同时下载交接所需的文件。
如果你还在比较其他 Agent Builder，可以另行查看 Grok Build 的网页与移动端发布流程；它的发布、导出与设备入口遵循另一套产品合同。
工作仍在变化时，先用 Preview
Agent.Space 可以在 Workspace Inspector 中打开受支持文件，也可以在浏览器 Preview 中渲染受支持的产出。这会缩短 Agent 改动与人工 Review 之间的反馈环路：检查文件、查看渲染结果、给出具体修改要求，再检查下一版。
Preview 适合：
- 检查布局、文案、导航或某个视觉状态；
- 把渲染结果与 Task Brief 对照；
- 在创建稳定 Release 前定位具体问题；
- 让团队成员无需在本地重建环境，就能检查当前工作；
- 验证开发服务是否能按预期启动并响应。
Preview 仍然有边界。有些格式无法在浏览器安全渲染；渲染后的文件也可能缺少依赖后端、Credentials 或其他外部服务的行为。Runtime Preview 通常是临时的；根据具体交付路径，它的公开路由与创建它的 Workspace 进程也可能有不同生命周期。
最重要的是：Preview 是 Review 证据，不是源码检查、测试、访问控制和发布决策的替代品。
需要稳定 Web Release 时再发布
对于受支持的网页产出，Agent.Space Web Delivery 可以创建永久 Site。Site 保持一个固定网址，并指向不可变 Release。发布后续版本可以更新该 Site；Release 历史也可以提供回滚目标。
这些场景适合发布：
- Reviewer 需要一个不依赖当前 Workspace Session 的网址；
- 已批准的静态或受支持网页结果需要持续可访问；
- 团队需要明确区分当前 Release 与旧版本；
- 更新出现问题后，需要恢复到之前的 Release。
固定网址只是交付能力，不是对“生产可用”的完整保证。发布前仍要检查真实部署输入、源目录、命令、Health Check、前端路由、资源文件，以及结果依赖的外部服务。一个页面能够显示，不代表表单、认证、Secret 与后端能力都正确。
发布也不应该成为第一次 Review。先检查源码和 Preview，再决定是否扩大可访问范围。如果新版本发布失败，现有稳定站点仍应作为当前事实源，而不能把失败尝试当成已上线 Release。
文件本身就是交付物时，选择下载或导出
有些产出不应该变成网站。报告、源文件、表格、图片、演示文稿或配置文件，可能需要在另一个工具中 Review、进入代码仓库、遵循单独的留存规则，或交付给 Workspace 之外的人。
这时应下载对应的普通文件。下载会保留这份产物的文件形态，但不会打包 Runtime、复现所有依赖，也不会把文件变成在线服务。
交付前：
- 用接收方真正会使用的工具打开下载文件；
- 确认名称、格式和内容与已经 Review 的 Workspace 版本一致；
- 删除不应离开 Workspace 的 Secret、临时数据或私人说明；
- 如果产物依赖其他文件，把必要的支持文件一起纳入交付；
- 记录它来自哪个 Revision 或 Session。
对于代码项目，版本控制通常比反复下载互不关联的副本更适合保存历史。导出仍适合交付某个具体产物，或让接收方获得普通文件。
一套实用的 Review 流程
网页或文件型 Agent 任务，可以按以下顺序检查。
1. 回到任务边界
重新查看 Acceptance Criteria，确认 Agent 被要求修改什么、明确不能修改什么。即使 Preview 很精致，如果做错了范围，结果仍然不合格。
2. 检查已保存文件
阅读改动后的源码，而不是只看 Agent 总结。检查无关变更、占位数据、缺少的异常状态、Secret，以及没有写进项目的隐含前提。
3. 打开适合的 Preview
文件本身使用 File Preview；交互式网页行为使用浏览器或 Runtime Preview。检查当前任务真正关心的状态、视口、路由和失败情况。
4. 运行对应验证
使用项目真实的检查：测试、Type Check、Lint、Build、可访问性检查、内容 QA 或其他领域门槛，并记录没有运行的部分。
5. 选择交付路径
- 工作还需要迭代，就继续使用 Preview。
- 目标是稳定网址，而且产出属于受支持网页，就发布一个 Release。
- 产物要进入另一个系统或交给其他人，就下载普通文件。
6. 留下交接记录
写清被 Review 的产物、验证结果、正式或临时链接、已知限制与回滚方式。Coding Agent 团队交接指南提供了更完整的责任转移检查清单。
常见错误
把 Preview 当成正式部署
临时 Preview 用于检查，可能到期或被撤销。如果结果需要稳定保留，就不能只把它放在临时链接里。
不看源码就直接发布
网页看起来正确时，仍可能包含无关改动、不安全配置、可访问性问题或损坏状态。视觉 Review 只是其中一层。
默认所有产出都能 Preview
浏览器对不同文件类型与内容的渲染支持并不相同。如果 Inspector 无法安全渲染，就下载文件，并使用合适、可信的工具检查。
只下载一个文件，却漏掉依赖
HTML 可能引用资源文件，代码可能依赖 Package 与配置，报告也可能引用支持数据。导出前先定义真实交付物的完整边界。
把稳定网址称为“已经生产可用”
已发布 Site 具备稳定交付方式与 Release 历史，但生产可用性仍取决于应用安全、可靠性、数据、合规、监控和外部集成。
让交付动作回答正确的 Review 问题
Agent.Space 如何工作一文介绍了项目文件、Session 与 Review 上下文如何留在同一个 Workspace。产出路径仍要清楚选择：
- 用 Preview 评估进行中的工作；
- 用发布把批准后的受支持 Web Release 放到固定网址；
- 用下载把普通文件交给下一个负责人或工具。
如果这是第一次使用，可以先看第一个 Agent.Space 项目教程，再决定交付方式。随后进入 Agent.Space Workspace，把一个有边界的产出从源码检查到渲染结果，再根据下一位接收者真正需要的内容选择 Preview、发布或导出。