高级 📋 6 个步骤 第 619 / 620 篇

用 Cook CLI 把 review / ralph / vN / vs 串成多智能体工作流：评审闸门、并行竞速与任务清单推进实操

cook 是编排 Claude Code、Codex 与 OpenCode 的命令行工具，把一次 Agent 调用写成可组合的操作符。本教程按官方 README 与文档站六步落地：装 CLI 与 skill 并用 cook doctor 验环境、cook init 配置双 Agent 分工、跑通 review 评审闸门、用 xN 与组合顺序叠加轮次、用 v3 与 vs 在隔离 git worktree 里并行竞速并 pick/merge/compare 收口，最后用 ralph 推进任务清单并管住限流与成本。

2026.11.13· 18 分钟阅读· 约 3349 字· 🍳 Cook CLI / 🔀 多智能体编排

一次提示词调用解决不了的任务，通常要拆成「写、审、改、再选」几轮。多数人靠复制粘贴在多个终端之间手动搬，cook 把这套动作写成了一行命令里的可组合操作符：work 是一次 Agent 调用，review 加一道评审闸门，xN 连跑几轮，vN 与 vs 在隔离的 git worktree 里并行试几种做法，ralph 再按任务清单往前推。本教程按官方仓库 README 与文档站，从安装到验收逐层加操作符，每一步都能在终端里跑出结果。

🍳 适合谁：已经装好并登录了 Claude Code、Codex 或 OpenCode，想让多轮评审、并行试跑与任务清单推进变成可复现命令的开发者。前置准备：Node.js 20 或更高、一个已提交过代码的 Git 仓库、至少一个可用的 Agent CLI 登录态；走 Docker 沙箱还需要 Docker daemon。cook 本身不额外要 API Key，但每一轮 Agent 调用都会消耗你已有的订阅额度或模型计费，跑之前先看清下面的成本提示。

先弄清三类原语与组合顺序

官方文档把命令拆成三类 token，理解这个划分是后面所有组合的前提：

类别操作符作用
Work（工作）一段带引号的提示词一次 Agent 调用，是最小单位
Loop（循环）xN / repeat N、review、ralph包裹左侧内容并迭代
Composition（组合）vN / race N、vs、pick / merge / compare并行分支跑完再用解析器收口

规则是从左到右组合，每个操作符包裹它左边的全部内容。所以 cook "work" x3 review 是「连跑三轮之后再进评审循环」，而 cook "work" review x3 是「评审循环整体重复三次」，两者不是一回事。

成本与副作用先说清：vN 与 vs 会在隔离的 git worktree 里同时起多个 Agent，N 越大，并发的模型调用越多、费用越高；review 默认最多迭代 3 轮，写成 review 5 就是 5 轮。官方文档还写明，遇到配额或限流时默认自动等待重试，配置里 maxWaitMinutes 默认 360 分钟，也就是说一条命令可能挂很久。请在自己的仓库与预算内试，别直接对生产分支跑并行竞速。

Step 1：装 CLI 与 Skill，用 cook doctor 验环境

1 两条安装路线按用途二选一

官方给了两种形态：不装 CLI、只把 SKILL.md 放进 Claude Code，让 Agent 自己去编排子 Agent；或装独立 CLI 用于终端与 CI。两条路线的产物不同，选一条走，别混着配。

# 路线 A：只装 Skill，不用 CLI
mkdir -p .claude/skills/cook
curl -fsSL https://raw.githubusercontent.com/rjcorwin/cook/main/no-code/SKILL.md -o .claude/skills/cook/SKILL.md

# 路线 B：装 CLI（终端 / CI 用）
npm install -g @let-it-cook/cli
mkdir -p .claude/skills
cp -r $(npm root -g)/@let-it-cook/cli/skill .claude/skills/cook

# 确认版本与前置
node --version
cook --help

# 检查 Docker、CLI 工具与登录凭据是否就绪
cook doctor

README 写明前置是 Node.js 20 或更高，以及 Claude Code、Codex、OpenCode 三者中至少一个。文档站还补充：OpenCode 只在 Docker 沙箱模式下受支持，默认 agent 沙箱模式下不要选它。

💡 cook doctor 会把 Docker daemon、各 CLI 工具与登录凭据逐项查一遍。先跑它再跑任务，能把「装了但没登录」「Docker 没起」这类问题挡在耗钱的长任务之前。

密钥安全：官方文档的示例配置里出现 "env": ["CLAUDE_CODE_OAUTH_TOKEN"]，意思是把该变量透传进沙箱。这类 OAuth token 等同于账号凭据，别写进提交到仓库的配置，也别贴到日志或群里；用环境变量注入并限制可读范围。从 GitHub 直接 curl 一个 SKILL.md 进项目前，先按团队合规要求审阅内容。

Step 2：cook init 生成配置，指定双 Agent 分工

2 让写作与评审用不同模型

cook init 会在项目根生成 COOK.md（项目说明与提示词模板）、.cook/config.json（默认值与分步骤覆盖）、Dockerfile 与 .cook/logs/。跨模型评审是这套工具的核心用法：让写的和审的不是同一个模型，减少自己给自己放水。

# 在项目根执行，生成配置文件
cook init

# .cook/config.json（官方示例，按你已登录的 CLI 调整）
{
  "agent": "claude",
  "sandbox": "agent",
  "steps": {
    "work":   { "agent": "codex", "model": "gpt-5-codex" },
    "review": { "agent": "claude", "model": "opus" }
  },
  "env": ["CLAUDE_CODE_OAUTH_TOKEN"]
}

# 也可以只在这条命令里临时覆盖
cook "Add dark mode" review --work-agent codex --work-model gpt-5-codex --review-agent claude --review-model opus

# 重新构建 Docker 沙箱镜像（仅 Docker 模式需要）
cook rebuild

配置里的 agent 是全局默认，steps.work 与 steps.review 分别覆盖写与审两步；命令行旗标的优先级用于单次调整。沙箱有 agent（默认，各 Agent 用自带的系统级沙箱，不需要 Docker）与 docker（容器加受限网络）两档。

💡 把 .cook/config.json 提交进仓库，团队就能共用同一套分工；但含凭据的 env 项要拆到本机未跟踪的覆盖文件里。COOK.md 是给 Agent 读的项目说明，写得越具体，评审闸门越容易给出可判定的结论。

Step 3：跑通 review 评审闸门

3 work、review、gate、iterate 四段闭环

review 在 work 之后加一段循环：评审者检查质量，gate 判定 DONE 或 ITERATE；判 ITERATE 就执行修正步骤，再回到评审，直到通过或达到轮次上限。默认最多 3 轮。

# 最简写法：默认提示词，最多 3 轮
cook "Add dark mode" review

# 放宽到 5 轮
cook "Add dark mode" review 5

# 写清楚评审标准与通过条件（位置简写，等价于显式写 review）
cook "Add dark mode" "Review for accessibility" "DONE if WCAG AA, else ITERATE"

# 完整四段：评审提示、闸门条件、修正提示、轮次上限
cook "Add dark mode" "Review for accessibility" "DONE if WCAG AA, else ITERATE" "Fix the issues" 5

# 验收：看 .cook/logs/ 里是否出现多轮 review 与 gate 记录

闸门条件要写成可判定的句子。「DONE if WCAG AA, else ITERATE」能判，「质量要好」判不了。文档站把这条写得很直白：写不出可检查的验收标准，评审循环就容易空转。

别让闸门空转：轮次上限是硬收口，达到上限会强制结束，但每轮都是真实模型调用。先在一条小改动上试通，确认 gate 真的能给出 DONE，再放到大任务上。若评审者始终判 ITERATE，先检查是否标准写得含糊，而不是一味调大轮次；需要立刻失败而非等待时，用 --no-wait 关掉限流等待。

Step 4：xN 连跑，并验证组合顺序

4 顺序不同，结果就不同

xN（长写法 repeat N）把左侧内容顺序跑 N 遍，每一遍都能看到上一遍的输出。把它和 review 叠起来，就是在验证「从左到右包裹」这条规则。

# 连跑三轮
cook "Add dark mode" x3
cook "Add dark mode" repeat 3

# A：三轮写完，再进评审循环
cook "work" x3 review

# B：评审循环整体重复三次
cook "work" review x3

# 组合写法：先连跑三轮再评审，然后并行三支各带评审循环
cook "work" x3 review v3 "most complete"

# 验收：对比 A 与 B 的日志轮次，确认包裹层次不同

官方文档给的三条对照很适合当作回归用例：cook "work" x3 review、cook "work" review x3、cook "work" review v3。跑一遍小任务，把日志里的轮次数对上，就能确认自己没把操作符顺序写反。

💡 建议在项目 README 里记一句「本项目统一用哪种顺序」。同一种任务在不同顺序下成本与产出差别很大，团队口径统一后，日志才有可比性。

Step 5：vN 与 vs 并行竞速，再选结果

5 每支分支跑在自己的 git worktree 里

组合操作符会在隔离的 git worktree 里并行跑多条 cook，再用解析器收口。vN（别名 race N）跑 N 个相同分支，vs 跑两种不同做法，默认解析器是 pick，另有 merge 与 compare。

# 三份相同任务并行，挑代码最少的
cook "Implement dark mode" v3 "least code"
cook "Implement dark mode" race 3 "least code wins"

# 两种方案并行，按安全性挑一个
cook "Auth with JWT" vs "Auth with sessions" pick "best security"

# 每支分支都带自己的评审循环，再挑最干净的结果
cook "Implement dark mode" review v3 "cleanest result"

# 显式指定解析器
cook "Implement dark mode" v3 merge
cook "Implement dark mode" v3 compare "list tradeoffs"

# Docker 模式下的网络白名单（.cook/config.json）
{
  "docker": {
    "network": {
      "mode": "restricted",
      "allowedHosts": ["api.mycompany.com"]
    }
  }
}

文档站说明，Docker 沙箱默认把出网限制到各 Agent 必需的白名单，mode 可设为 restricted（默认）或 unrestricted，allowedHosts 用来追加放行。另一条相关命令是 cook shell --unrestricted，它会放开网络限制，只应在明确需要时使用。

合并与挑选都不是确定性的：pick 由模型按你给的标准判定，不是按测试分数排序；merge 把分支合回来也可能产生冲突。并行分支等于同时起 N 个 Agent，费用与限流概率同步放大。跑之前确认仓库已提交、工作树干净，跑完自己审 diff 并复跑测试，别把竞速结果直接推到主分支。此外，OpenCode 仅在 Docker 沙箱模式下受支持。

Step 6：ralph 推进任务清单，并管住限流与成本

6 外层闸门决定退出还是下一个任务

ralph 包一层外层闸门，让工作提示词自己去读项目状态、找当前任务。它可以和 review 叠起来：内层闸门判 DONE 才把结果交给 ralph，ralph 再判 DONE（全部完成，退出）或 NEXT（推进下一任务并重置迭代计数）。

# 按 plan.md 逐项推进，外层闸门读项目状态
cook "Work on next task in plan.md" review ralph 5 "DONE if all tasks complete, else NEXT"

# 内层评审条件也写清楚
cook "Work on next task in plan.md" review "Code review" "DONE if no High issues, else ITERATE" ralph 5 "DONE if all tasks complete, else NEXT"

# 限流：默认自动等待重试，加 --no-wait 让它立即失败
cook "Build the feature" review --no-wait

# .cook/config.json 里调整等待窗口
{
  "retry": {
    "enabled": true,
    "pollIntervalMinutes": 5,
    "maxWaitMinutes": 60
  }
}

# 复跑前后各看一次日志与用量
cook doctor
git status --short

官方 README 写明限流恢复默认开启：Agent 撞到配额或速率限制时会自动等待重试，TUI 显示倒计时。配置里的 pollIntervalMinutes 默认 5、maxWaitMinutes 默认 360，按自己的预算调小更稳妥。

💡 plan.md 里把每个任务写成可判定的一小步，ralph 的外层闸门才有依据。任务描述含糊时，它容易反复判 NEXT 或提前判 DONE；先拿三五个小任务试跑，比一次塞进整份计划更容易看出问题。

成本与收口：review 轮次、vN 分支数、ralph 任务数三者相乘，就是这条命令可能发起的 Agent 调用规模。官方 README 未写死版本号，包名、旗标与默认值请以你安装当天的 README 与 cook --help 为准。命令结束后检查 git status --short、各 worktree 的残留分支与 .cook/logs/，把没选中的分支清理掉；任何落地改动都要自己审 diff 并复跑测试。

做到哪一步算成功

四条验收都过，才算这条编排链真的跑起来了：① cook doctor 全项就绪，且能说清自己走的是 Skill 路线还是 CLI 路线；② 一次 review 5 在日志里留下多轮评审与 gate 记录，且闸门条件可判定；③ 用 x3 review 与 review x3 各跑一次，日志轮次确实不同，证明组合顺序理解对了；④ 一次 v3 或 vs 在隔离 worktree 里得到多份结果，pick 或 merge 按标准收口，且你已审过 diff、跑过测试并清理了多余分支。做到这些，再把 ralph 接到自己的 plan.md 上。

常见问题速查

你遇到的现象大概率原因与处理
cook doctor 报凭据或工具缺失对应 Agent CLI 没装或没登录；OpenCode 只在 Docker 沙箱模式受支持
命令挂很久不结束默认限流自动等待，maxWaitMinutes 默认 360；调小该值或加 --no-wait
review 一直判 ITERATE闸门条件写得含糊，改成可判定的通过标准，别只调大轮次
x3 review 与 review x3 结果一样检查日志轮次：操作符从左到右包裹，两者层次本就不同
v3 报分支或 worktree 冲突先提交改动、确认工作树干净；并行分支各占独立 worktree 与分支名
pick 选出的结果不理想解析器由模型按标准判定，把挑选标准写具体，或改用 compare 看权衡
Docker 模式里 Agent 连不上外部服务restricted 默认只放行必需主机，用 allowedHosts 追加；别直接放开 unrestricted
ralph 提前退出或反复推进plan.md 任务写成可判定的一小步，并把外层闸门条件写实

交付前自查：本教程命令、操作符与配置字段来自官方仓库 rjcorwin/cook 的 README 与文档站；npm 包版本、支持的 Agent 列表与默认值会变，以你安装当天的 README 与 cook --help 为准。并行竞速与评审循环会产生真实模型费用，跨模型配置要求两个 CLI 都已登录；任何落地改动请自行审 diff、复跑测试后再提交。

📚 更多教程 📰 智能体资讯 🍳 Cook CLI 🔀 多智能体编排 🌳 并行 worktree 🚦 评审闸门
← 返回教程中心

相关教程

更多高级教程 →
高级6 个步骤 用 OMA 在自己机器上跑多智能体团队：runTeam 编排、审批门禁与 verifyRun 离线核验实操 2026.10.27 · 🧩 OMA 高级6 个步骤 照着 Meta 的 Thin Orchestrator 造一个「薄编排器」：状态机路由、专家子智能体与不可变 JSON 交接 2026.10.22 · 🧭 Thin Orchestrator 高级6 个步骤 让 Claude 托管智能体自己写工作流：dynamic workflows 公测实操——开启配置、事件流跟踪与限额治理 2026.10.13 · 🔀 Claude Managed Agents