Warp Agent CLI 改名 Oz：本地还是云端？

Warp 8 月 4 日刚发布独立 Agent CLI，最新版文档已经把命令统一成了 oz，还明确标注 warp-cli 弃用。变化不只是换名字：它现在既能在本地仓库跑 Agent，也能把任务丢到云端环境，还负责 Skill、MCP、Profile 和自动化触发。

换句话说，最早的宣传是“在任何终端里用 Warp Agent”，现在的 Oz 更像 Warp Agent 平台的控制入口。

先说结论

• Warp Agent CLI 最新名称是 Oz CLI，新脚本直接用 oz。
• 需要读本地工作区、边做边看，用 oz agent run。
• 需要后台运行、标准环境或 CI 触发，用 oz agent run-cloud。
• Profile、Skill、MCP 各管一层，别全塞进 prompt。
• Warp 的优势是多 session 和本地/云端衔接；只跑一个本地 Agent 时，Claude Code 或 Codex 更省事。

先把名字理顺

Warp Agent CLI 的产品页仍然提供这条安装命令：

curl -fsSL https://app.warp.dev/download/agent-cli | bash

但最新版 Reference 统一使用 oz。旧的 warp-cli 会自动更新，历史脚本只需要把命令名替换成 oz。macOS 推荐 Homebrew，Linux 提供 apt、yum 和 pacman 包；Windows 暂时通过 Warp 桌面应用获得 Oz，没有单独安装包。

产品页仍使用 Warp Agent CLI 这个名字。来源：Warp Agent CLI。

品牌处于过渡期确实有点乱。实际开发只记一条：自动化以当前文档和 oz 命令为准；写迁移说明时保留 Warp Agent CLI 关键词，方便团队搜到旧资料。

本地和云端不是同一个任务换台机器跑

本地任务这样启动：

oz agent run --cwd ./service \
  --name fix-pagination \
  "Fix the cursor pagination bug and run the focused tests"

它直接操作指定目录，适合排查 bug、实时查看 tool call，或者随时打断 Agent 改方向。

云端任务则用：

oz agent run-cloud \
  --environment "$WARP_ENVIRONMENT_ID" \
  --name fix-pagination \
  "Fix the cursor pagination bug, run tests, and prepare a pull request"

run-cloud 适合 CI、长任务、统一构建环境和关掉电脑后继续跑的工作。

决策点	本地 agent run	云端 agent run-cloud
读取当前工作区	直接读取	只读取传入环境的内容
人工反馈	随时介入	通常异步
环境一致性	取决于开发机	使用固定云端环境
CI 使用	比较别扭	合适
Secret 所在位置	本地凭证	远端环境凭证
最适合	调试、监督式修改	后台任务、自动化

别把云端模式理解成“本地模式加速版”。代码、凭证、构建产物和网络权限都换了位置，安全边界也跟着变了。

Oz 把本地监督式工作与远程异步任务分成两条明确路径。来源：Oz CLI Reference。

Profile、Skill、MCP 别混成一锅

Oz 同时有 --profile、--skill 和 --mcp。它们都能影响 Agent，但职责完全不同：

• Profile：定义模型、行为和权限默认值。
• Skill：保存可复用的任务流程，比如安全审查或发版。
• MCP：给 Agent 接 GitHub、Linear、Sentry 等外部工具。

组合使用的方式如下：

oz agent run \
  --profile "$REVIEW_PROFILE_ID" \
  --skill ./skills/security-review \
  --mcp ./config/github-mcp.json \
  --name auth-review \
  "Review the authentication changes in this branch"

拆开之后才好治理：Skill 跟代码一起 review，MCP 配置可以单独轮换，Profile 能统一收紧团队权限。

不要把带 secret 的 inline MCP JSON 直接敲进 shell history。用引用环境变量的配置文件，或者团队管理的 MCP 条目，并把 token 权限缩到具体仓库和必要动作。

Warp 真正拉开差距的是 session 管理

很多评测只盯着哪个模型代码写得更好。Warp 赌的是另一个问题：同时跑 5 个 Agent 后，怎么知道谁在等审批、谁已失败、谁改了哪些文件？

Warp 能集中展示 session、通知和代码 review，也能把 Claude Code、Codex、Gemini CLI、OpenCode 等外部 Agent 放进同一个工作台。/orchestrate 会拆分子任务并行运行，/plan 则让单个 Agent 先调研再动手。

Warp 明确支持在同一工作台使用 Claude Code、Codex、Gemini CLI 和 OpenCode。来源：Warp Universal Agent Support。

并行不是白给的速度。3 个 Agent 同时改一份 migration，得到的大概率是冲突，不是 3 倍效率。切任务要沿着所有权边界来：实现、测试、文档，或者互不依赖的 package。最后指定一个 Agent 做集成。

Warp/Oz、Claude Code、Codex 怎么选

需求	Warp/Oz	Claude Code	Codex CLI
普通终端可用	支持	支持	支持
一套工具覆盖本地和云端	支持	取决于产品形态	Codex 不同入口可覆盖
可视化多 session 管理	最强项	更偏终端	CLI 与应用入口
内置多 Agent 编排	支持	依工作流而定	支持并行工作流
同一 UI 承载第三方 Agent	支持	不支持	不支持
最少本地概念	较多	简单	简单

瓶颈在多个任务、多个环境和团队协作，选 Warp/Oz。偏爱 Claude 的编码行为，只需要一个终端循环，Claude Code 更直接。已经围绕 OpenAI 工作流搭建，并需要 Codex 的本地或云端入口，就选 Codex。

更完整的横向选择可以看 Claude Code vs Codex vs OpenClaw 和 AI 编程助手对比。

自动化之前先补 4 个护栏

固定云端环境

别让每个任务临时安装一套随机依赖。构建带版本号的环境镜像，在 run 记录里保存环境 ID，升级时明确评审。

读写凭证分开

代码审查只需要读权限，创建 PR 才需要 push。两类 Agent 共用一个大权限 token，会把无害工作流也变成高风险入口。

每个自动任务必须命名

--name 看着可选，出了问题面对 40 个匿名 session 就知道有多重要。名字至少带 workflow、仓库和触发编号。

给多 Agent 设置预算

子任务会成倍消耗模型调用和环境时间。限制最大子 Agent 数、总时长和完成条件。“持续改进代码”不是完成条件。

当 Agent 需要运行不可信代码或调用模型/API 时，可以再接 SandBase 的隔离执行环境。边界要清楚：Oz 负责编排，sandbox 负责限制生成代码能碰什么。

我的判断

Warp Agent CLI 是个很好懂的发布名称，Oz 则更符合它现在的职责：本地 Agent、云端 Agent、集成、MCP、Skill、共享 session 的统一运行入口。

团队同时跑多个 Agent，或者准备把任务从员工电脑迁到云端，这些额外概念有价值。一个人、一个仓库、一个本地 Agent，则可能只是负担。最稳妥的路径是先用 oz agent run；权限重复时加 Profile，流程重复时加 Skill，环境和责任边界准备好之后再上 run-cloud。

FAQ

Warp Agent CLI 停止维护了吗？

没有。当前产品在最新文档中叫 Oz CLI，Warp Agent CLI 仍出现在发布页和历史资料里。

warp-cli 还能用吗？

Warp 已将它标记为 deprecated，并说明会自动更新成 oz。新脚本应直接使用 oz。

Oz 不用云端环境能运行吗？

可以。oz agent run 直接操作本地工作目录，oz agent run-cloud 才是远端路径。

Oz 能连接 MCP Server 吗？

可以。--mcp 可以重复使用，支持团队 MCP UUID、inline JSON 或 JSON 配置文件。

多 Agent 一定更快吗？

不一定。只有子任务相互独立时才容易提速，共享文件、串行依赖和责任不清都会抵消并行收益。