你可以通过 OpenCode 官方 Server 接口在云端运行它，也可以把它放进托管 Workspace。托管云端 Workspace 会在 OpenCode 周围增加托管 Runtime、持久项目空间和协作能力；它不会取代 OpenCode harness，也不会把模型访问本身变成 Workspace。
如果你已经确定要选择托管路径，可以直接查看 OpenCode 云端 Workspace 页面，了解 Agent.Space 如何把 harness、模型选择与持久化项目层分开。
这个区别很重要，因为搜索结果里的“OpenCode cloud”可能指完全不同的东西。选择方案前，先确认你需要的是远程访问、模型服务商、持续可用的执行环境，还是由别人负责运营的 Workspace。
本文比较三条实际路径：本地 OpenCode、自托管 OpenCode Server，以及托管的 Agent.Space Workspace。下列 OpenCode 行为均依据 2026 年 8 月 26 日审阅的官方文档。OpenCode 上游支持的能力不会自动成为 Agent.Space 的产品能力，因此托管 Workspace 实际提供什么，应以当前 Agent.Space 产品界面和公开产品资料为准。
“OpenCode cloud”可能指什么
这个说法有歧义。几乎相同的搜索词可能返回四种不同结果：
opencode.com是无关的电信云品牌。 它不是opencode.ai所记录的开源编程 Agent；该域名的搜索结果不描述本文讨论的 OpenCode harness。- OpenCode Zen 与 Go 是模型访问路径。 它们帮助 OpenCode 通过 Provider 调用模型，但不会单独托管仓库、维持开发机器运行或创建共享项目 Workspace。对应层级应参考 OpenCode 的 Provider 文档。
opencode serve会把 OpenCode 暴露为无界面服务。 OpenCode Server 文档描述 HTTP/OpenAPI Server 与 Session API。这是远程访问的重要构件，但运行一条命令不等于运营一个持久生产服务。- 托管 Workspace 会承载 OpenCode 周围的 Runtime。 Workspace 服务商负责算力、项目文件、访问、持久化和协作中的一部分。具体合同取决于服务商，不能把“托管”当作一组通用能力保证。
还有一条默认路径：通过 Terminal、Desktop 或 IDE 在本地运行 OpenCode。它仍然是比较云端方案时最简单的参照点。
OpenCode 官方提供什么
OpenCode 是一个开源 AI 编程 Agent。Harness 协调模型、工具、项目上下文和执行循环。它提供 Terminal、Desktop 和 IDE 入口，并支持多个模型 Provider，而不是把一个模型写死在产品中。
OpenCode 还提供几项与远程运行有关的能力：
- Provider 与模型： 你可以连接受支持的模型 Provider，包括 OpenCode 自己提供的访问路径。Provider 回答“harness 可以调用哪个模型”，不回答“文件与 Runtime 在哪里”。
- Agent 与权限： OpenCode Agent 可以配置模型、Prompt、工具与权限。这些设置会影响 Agent 在具体运行环境中能尝试什么。参见 Agent 文档。
- 无界面 Server：
opencode serve暴露 Server 与 Session API，让远程客户端和集成成为可能，但运营者仍需处理周边部署问题。
这些角色设置与部署路径是两回事：你可以配置 OpenCode Agent 与 Subagent，为它们分配职责明确的 Prompt、工具与权限，但不能把这些角色当成 Hosting 或持久化能力。
如果你还在搭建本地环境，可以先查看如何安装 OpenCode；需要扩展工作方式时，再分别了解 OpenCode Skills 和 OpenCode MCP。这些教程解决的是设置与扩展问题，不替代本文对托管责任的比较。
官方 Server 接口本身并不提供持久存储、备份、身份、团队授权、Secret 管理或升级方面的生产合同。运营者必须在 harness 周围自行提供或核验这些层级。
运行 OpenCode 的三种方式
这三条路径没有一个永远更好。
Runtime 移到云端后，会改变什么
把 OpenCode 从笔记本移走，变化的不只是进程从哪里启动。
Runtime 连续性
本地 Session 依赖本地机器与进程。即便使用远程机器，也只有正确配置 Server 和外围进程管理后，才可能在笔记本合盖后继续可用。托管 Workspace 可以把连续性做成产品能力，但浏览器断开、重启、闲置或触发套餐限制后的具体行为必须核验。
因此，“在云端运行”还不够。你需要询问：浏览器断开、Agent 进程停止和 Workspace 重启后，分别会保留什么？
文件与 Session 状态
OpenCode Session API 与项目文件是两种不同状态。远程 Endpoint 可能暴露一个 Session，但底层文件系统仍是临时的；反过来，持久磁盘也不保证对话或 Agent 状态能从原处精确恢复。
对任何托管路径，都应分别检查：
- Agent 进程结束后，仓库改动是否保存？
- 停止订阅后，文件能否导出？
- 之前的 OpenCode Session 能否恢复，还是每个任务都要重新开始？
- 哪些状态属于 OpenCode，哪些属于托管 Workspace？
Credentials 与模型访问
OpenCode 可以连接多个 Provider，但部署方式决定 Credentials 如何进入环境、谁可以使用它们。自托管团队必须设计 Secret 注入与轮换、日志脱敏和访问控制；使用托管 Workspace 时，应阅读服务商的 Credentials 与模型访问合同，不能假设它一定使用 OpenCode Zen、Go 或个人 API Key。
访问与协作
把 Server 放到互联网上并不会自动产生安全协作。团队仍然需要身份、授权、审计轨迹，以及谁可以运行工具或修改文件的明确规则。托管产品可能在 Workspace 层提供其中一部分；OpenCode Server 本身不应被描述为完整团队平台。
更新与兼容性
自托管让你决定更新时间，也意味着你要负责测试更新。托管 Workspace 可能固定在一个已知版本以保持行为可复现，因此可能落后于最新上游 Release。这是稳定性取舍，不代表任何一条路径天然更优。
Agent.Space 中的持久 OpenCode 工作流
Agent.Space 公开列出 OpenCode 这一可用 Agent harness；Agent.Space Workspace 页面则说明 Session、文件、Preview 与团队上下文如何保留在云端 Workspace 中。由此形成下面的工作流：
- 创建项目 Workspace，而不是配置一个公开 OpenCode Server。
- 选择 OpenCode 作为 harness，再单独选择兼容模型。
- 给 Agent 一个边界明确且包含验证步骤的任务。
- 离开浏览器，之后返回同一个项目 Workspace。
- 回来检查产出文件与 Agent 输出，再继续任务或完成交接。
这描述的是公开的 Workspace 合同，并不表示 OpenCode 自身的上游 Session 状态会在本地、自托管与托管部署中完全一致。应检查部署中实际显示的版本，并把项目持久化、harness Session 状态与进程生命周期分开确认。
模型与 OpenCode 是两项选择
OpenCode 是 harness：它组织上下文、调用工具、应用权限并协调工作循环。模型提供底层生成与推理能力，Provider 则是访问该模型的路径；Workspace 是 harness 与项目运行的环境。
这是四个不同决定：
OpenCode Zen 或 Go 可以简化模型访问，但它们都不是“托管 OpenCode”的另一个名字。同样，把 OpenCode 放进云端 Workspace，也不保证每个模型都能用于每种配置。兼容性仍取决于 harness 版本、Provider、模型能力和 Workspace 集成。
如需进一步理解这套关系，可以阅读 Agent harness 与模型的区别，而无需在本文重复完整模型选型指南。
安全与运营责任
开源让 OpenCode 更容易检查和迁移，却不会自动让某项部署变得私密或安全。运营者仍需决定谁能访问服务、哪些工具可运行、Credentials 存在哪里，以及数据保留多久。
选择路径前，可以使用这张责任清单：
若选择自托管，不要在缺少适合相关数据和工具的认证与网络设计时，把 OpenCode Server 直接暴露在公共互联网。若选择托管 Workspace，也应把同样的问题当作产品要求逐项审查，不能假设服务商一定按你的项目需求处理了它们。
如何选择本地、自托管或托管
如果你想走最短设置路径，设备可以继续作为执行环境，而且个人控制比远程连续性更重要，选择本地 OpenCode。
如果你需要远程或自定义集成，拥有基础设施能力，并愿意自己负责认证、存储、可观察性和升级，选择自托管 OpenCode Server。
如果你想使用托管项目环境、持久访问和协作能力，同时不愿运营完整 Server Stack，选择托管 Workspace。决定前确认真实的 OpenCode 版本、持久化、Resume 行为、Credentials、权限、导出和计费。
核心问题不是“OpenCode 能不能在云端运行”。它可以通过 Server 接口在云端运行。真正有用的问题是：谁来运营 Runtime，并负责它周围的每一层？
你可以先了解 Agent.Space Workspace再选择托管路径，并从一个边界明确的 OpenCode 任务开始，在返回项目后检查已保存文件与验证输出。