Skip to main content
workspace repository 是连接到一个 Osmosis platform workspace 的 GitHub 仓库。平台会从 Osmosis workspace template 创建它，或连接已有仓库，然后通过 Git Sync 发现 rollouts 和 configs。 您的本地 workspace directory 是该仓库的 clone。

​
CLI Context 的工作方式

默认情况下，当您在 workspace directory 中运行平台命令时，CLI 会：
  1. 找到 Git worktree root。
  2. 读取 origin remote。
  3. 将 GitHub 仓库身份规范化为 owner/repo。
  4. 将该身份发送到平台，让请求限定到匹配的 workspace。
这种 Git-derived scope 仍是默认行为，rollout list、eval run 和 eval upload 等本地 source workflow 仍需要它。Platform-only commands 则可以从任意目录按名称精确选择 workspace：
Root --workspace 无需本地 repository 即可用于完整 benchmark 命令族、platform dataset/model/secret commands，以及 train 的 list、info、logs 和 stop；eval 的 list、info、logs、retry 和 stop。不传入时，这些命令仍使用 Git-derived scope。eval run、eval upload、eval download 和 rollout 命令始终从当前 repository 解析 workspace，因为它们都会读写以 workspace 为相对根的磁盘布局。 eval submit 和 train submit 是 source-backed 例外。可以使用 root --workspace 从任意当前目录调用，但 config 路径必须是绝对路径，并且仍位于其所在 repository 的标准 configs/eval/ 或 configs/training/ 目录下：
CLI 会定位 config 所在的 Osmosis Git workspace，验证所选 platform workspace 连接到同一 repository，并且请求只发送 workspace-name scope。
origin remote 必须指向连接到您平台 workspace 的 GitHub 仓库。如果仓库在 GitHub 上被重命名，请先更新本地 remote，再运行 CLI 命令。

​
常见要求

configs/benchmark/ 是可选目录，仅供 osmosis benchmark submit 使用。osmosis doctor 和 osmosis doctor --fix 都不会要求或创建它。 如果看起来有问题，运行本地健康检查：
修复缺失的 scaffold 目录：

​
仓库所有权

workspace 创建者通常在 onboarding 期间从平台创建仓库。被邀请的成员应 clone 已有 workspace repository，而不是创建单独仓库。 只有 workspace owners 和 admins 可以在平台中管理 GitHub 仓库连接设置。成员如果拥有 GitHub 访问权限，就可以 clone 并使用该仓库。

​
相关命令

​
下一步

结构与配置

了解仓库布局和配置目录。

Git Sync

了解 pushes 如何成为平台 rollouts。
最后修改于 2026年9月1日