Captain 是 gstack 中的一个技能（slug: captain），也以 /crew 名称调用，定位为“一个控制器、多个 lane”的多智能体协作编排方案。其核心操作模型是：一个负责协调的智能体（Captain 或 controller）与任意数量的工作线程（lane）组成“crew”，每个 lane 有自己的分支和机器，所有 lane 向控制器汇报，控制器再向一个负责人（owner）汇报。该模型旨在让数十个 lane 每天并入同一个基分支而不让基分支变红。
用途与主要能力：
- 控制器统一执行合并，lane 永不自行合并、不启用自动合并，也不使用控制器未驱动的合并队列；lane 的工作以未打戳的 READY 结束。
- READY 块是唯一的合并触发条件。lane 通过 gstack-ship-queue ready 输出 READY 块，包含 PR 编号、完整 40 位 head SHA、STAMP_VERSION、基分支、所需检查状态、PREGATE、付费证据、SHIP_RECEIPT、screen 选择、READY_RECEIPT、flaky 记录及 head 冻结声明等字段；缺失或错误字段会被退回，不进入列车。
- 合并列车：一次全量 gate（full gate）覆盖最多 TRAIN_MAX 个 READY PR；列车按槽位顺序在临时工作树中合并 pin，记录前缀树，运行免费测试，派发 gate，然后逐个合并，每个合并仅在 BASE 与 gate 覆盖的前缀一致（模戳记）时进行。
- 设置参数化：仓库相关配置集中在 crew 规则文件（captain/templates/CREW.md），包括 REPO、BASE、REQUIRED_CHECKS、FULL_GATE_CHECK、TRAIN_MAX/FILL_HOURS、MERGE_METHOD、STAMP_FILES、KNOWN_INFRA_FLAKES、SPEND、CONTROLLER 等参数；仓库的 .gstack/ship-policy.json 携带 train 配置块，供队列工具与规则文件读取同一组名称。
- 负责人决策通过控制器以负责人原话记录，并在被批准的工作开始前记录。付费证据只读取、不重新判定：不改变阈值、试验次数、用例类型或预算来把红变绿。
使用方式： 命令形式为 /captain [setup | ready <pr> | train | digest | approvals | flaky-pass]；/crew 为同一技能。无参数时，读取 crew 规则文件和摘要，然后执行摘要顶部开放项所需操作。 关键命令包括：gstack-ship-queue ready --pr "$PR" --no-screen（或 --screen [--broad]）生成 READY 块；gstack-ship-queue train build --prs "$PINS" --dry-run 预览顺序、前缀、槽位、估算且不产生花费；train build 写入记录、推送列车分支并派发 gate；train status 与 train verdict 获取裁决（GREEN/RED/INCOMPLETE）；verify 在合并前后校验；gh pr merge 配合 --match-head-commit 执行合并；train prune 删除列车分支。每个队列命令以 NEXT: 和 GSTACK_RESULT: 行结束，按 NEXT 指示操作。
适用场景：需要多个编码智能体并行工作、由单一控制器统一合并与协调的工程团队；每日大量 PR 并入同一基分支且要求基分支持续健康的场景；需要记录负责人决策、统一付费评估花费上限、每日修复 flaky 测试而非反复重试的流程。
限制与边界：lane 不得合并、不得启用自动合并，也不得使用控制器未驱动的合并队列；控制器不得向 lane 的分支提交，只能调用槽位由 lane 打戳；列车之外不得合并（单个 PR 使用 --urgent 的一 PR 列车，冻结下的修复使用 train build --repair），列车外每次合并都要付出 backstop gate；READY 后 head 冻结，推送会使 PR 从列车掉出并需要在新 head 上重新 READY（戳记推送除外）；一次戳记提交若改动 STAMP_FILES 之外哪怕一个字节，验证失败并冻结所有人的队列；付费证据不得重新判定。资料未提供具体收费、价格或平台支持范围。