zeroshot：把执行与验证拆开的 CLI 编码代理编排器

为什么需要一个不信任执行者的验证者

zeroshot 的核心理念写在其 README 开头：“The agent that wrote the code shouldn't be the one that says it works.” 这句话直接点出了当前 AI 编码工具的通病：让同一个模型既写代码又自评，等于让考生自己改卷。zeroshot 把这个过程拆成执行者与验证者两个角色，验证者不共享执行者的会话或推理上下文，必须根据显式的交接产物来复现问题。这种设计针对的是那些希望 AI 生成的代码能直接进入生产环境的工程师，而不是只想快速生成草稿的人。它解决的问题是信任，不是速度。

执行者与验证者的消息总线架构

zeroshot 的底层是一个消息总线，而不是硬编码的流水线。每个工作流都是一个 JSON 文件，存放在 `cluster-templates/base-templates/` 目录下。代理通过订阅和发布主题来协作，图结构就是这些主题连接关系。一个触发条件可以携带 JavaScript 谓词，决定某条消息是否唤醒对应的代理。这意味着您可以定义任意的代理 ID、角色和主题名称。循环是允许的，比如 reject-and-retry 就是一个循环，但 `zeroshot config validate` 会拒绝三个或更多代理组成的环，除非环中有转义逻辑。子集群最多嵌套五层。这种设计让工作流不再是黑盒，您可以直接修改 JSON 来改变验证者的数量或行为。

分类路由：从 TRIVIAL 到 CRITICAL 的代价权衡

在写任何代码之前，一个指挥者（conductor）会对任务进行复杂度评分（TRIVIAL、SIMPLE、STANDARD、CRITICAL）和类型分类（INQUIRY、TASK、DEBUG）。这个评分直接决定使用哪个工作流。规则从上到下匹配，第一条命中即生效。TRIVIAL 任务只使用一个 worker，没有验证者，这意味着执行者与验证者的分离在该路径上不生效。这是 README 中特别指出的一行，也是值得注意的取舍：对于简单任务，zeroshot 放弃了验证环节，以换取速度和成本。而 CRITICAL 任务会启动 planner、worker、meta-coordinator 和四个验证者，分两阶段进行，代价很高。指挥者被指示在犹豫时选择 STANDARD，因为 CRITICAL 会消耗一个高级模型和四个验证者。这种设计承认了验证成本的存在，并试图通过分类来平衡。

安装与首次运行：需要 Node 22 和受支持的代理

安装命令很简单：`npm install -g @the-open-engine/zeroshot`，然后运行 `zeroshot` 进行引导式设置。它要求 Node ≥ 22，并且至少有一个受支持的 provider。支持列表包括 Claude、Codex、Gemini、OpenCode、Pi、OMP、Kiro 和 Copilot，其中模型网关统一通过 Gateway provider 访问。引导设置会自动检测已安装的 provider，选择一个默认值，并为新仓库配置工作树隔离。在 git 仓库中，默认会在单独的工作树中运行，不会修改当前检出，除非您显式使用 `--no-isolation`。首次运行一个任务的命令是 `zeroshot run "Add a --json flag with tests"`，然后可以用 `zeroshot list` 和 `zeroshot logs <id> -f` 从另一个终端观察结果。zeroshot 不存储 provider 密钥，它只是编排这些 CLI，这意味着您需要自行管理各代理的认证。

隔离与交付：工作树、Docker 与标志级联

隔离是 zeroshot 保证安全性的核心手段。引导设置默认将新仓库置于 git 工作树隔离中，这样改动不会影响当前 checkout。交付标志有级联关系：`--ship` 隐含 `--pr`，`--pr` 隐含 `--worktree`。表格中列出了三种模式：git 工作树（`--worktree`）是引导默认；Docker（`--docker`）用于风险更高的工作负载；还有直接修改当前 checkout 的模式，但需要显式使用 `--no-isolation`。这种设计让您可以根据任务的危险程度选择隔离级别。不过，Windows 目前不支持，只有 Linux 和 macOS，这是一个明显的限制。如果您的工作环境是 Windows，那么 zeroshot 当前无法使用。

自定义工作流：JSON 与验证命令

zeroshot 的工作流不是固定的，您可以通过 `zeroshot config list` 查看可用工作流，用 `zeroshot config show full-workflow` 读取一个工作流的定义，用 `zeroshot config validate ./mine.json` 验证自定义工作流，然后用 `zeroshot run 123 --config ./mine.json` 运行它。每个工作流文件都是 JSON，且没有哪个是特权级的。这意味着您可以复制一个现有工作流，修改验证者的数量或触发条件，然后立即使用。但这种灵活性也有代价：您需要理解消息总线的概念，以及如何编写 JavaScript 谓词。对于不熟悉事件驱动架构的开发者，这可能是一个学习曲线。此外，`zeroshot config validate` 对循环的检查（三个或更多代理的环必须有转义逻辑）是一个硬性约束，设计自定义工作流时需要注意。

局限与替代方案：何时不该用 zeroshot

zeroshot 的一个明确局限是 TRIVIAL 任务没有验证者，这意味着简单改动的质量完全依赖单个 worker 的自我判断。另一个局限是它依赖外部编码代理的 CLI，如果这些 CLI 本身不可靠或更新频繁，zeroshot 的编排也可能受影响。此外，它的运行时间可能很长，README 提到一个 90 分钟、5 次迭代才达到批准的例子，这显然不适合快速迭代的场景。替代方案可以是直接使用 Claude Code 或 Codex 的原生功能，它们通常内置了简单的自测循环，但缺少独立的验证者。另一个思路是使用 CI 管道，比如在 GitHub Actions 中运行测试，但这需要您自己编写集成逻辑，而不是像 zeroshot 那样自动生成验证流程。zeroshot 的独特之处在于验证者与执行者的隔离，这是普通 CI 或单代理工具不具备的。

维护成本与许可证

zeroshot 的许可证是 MIT，这意味着您可以自由使用、修改和分发，无需担心商业使用限制，但这不是法律建议。维护方面，项目有活跃的发布记录，最近版本包括 v6.45.0 和 v6.44.0，更新频率较高。每个步骤都写入一个崩溃安全的 SQLite 账本，这有助于在失败后恢复和审计。文档提到 zeroshot-rust 是一个独立的原生产品，有自己的发布和 CLI，但 README 的其余部分描述的是 Node 产品。如果您采用 Node 版本，需要跟踪其发布节奏，因为频繁更新可能带来行为变化。升级成本取决于您是否自定义了工作流，因为自定义 JSON 可能需要适配新版本的变化。总体而言，MIT 许可证和活跃维护是加分项，但您需要准备好应对频繁的版本更新。

编辑结论

zeroshot 适合那些已经在使用 Claude Code、Codex 或 Gemini CLI，并且希望为 AI 生成的改动增加一道独立验证关卡的个人开发者或小团队。它尤其适合标准化程度高、任务边界清晰、且能接受等待验证循环耗时的仓库。如果您的项目需要 Windows 支持，或者您期望一个开箱即用、无需理解工作流 JSON 的工具，那么它目前不是合适的选择。在采用前，请先确认您的 Node 版本 ≥ 22，并检查您所用的编码代理 CLI 是否在官方支持列表中。更重要的是，先用一个简单的 TRIVIAL 任务跑通 `zeroshot run`，再逐步引入需要验证者的 SIMPLE 或 STANDARD 任务，以评估验证环节实际能发现多少问题，而不是假设它总能抓住缺陷。最后，由于 zeroshot 不存储 provider 密钥，您需要自行管理各代理的认证方式，确保在无人值守运行时凭证可用。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes