Bernstein
用确定性调度并行编排 CLI 编码代理，并可离线核验每次运行。
按维度查看评分与理由
证据显示：默认隔离（git worktree）和可选沙箱后端，最小权限原则得到体现；但用户确认机制仅体现在命令执行前，未发现明确的审批流程。数据流透明性通过审计日志和回放日志实现，但未详细说明数据流向。敏感数据处理有密钥库和防泄漏护栏，但未深入验证。依赖安全有Dependabot、pip-audit、CodeQL等，且明确固定了安全相关依赖版本。外部影响通过沙箱和网络隔离控制，但未完全验证。回滚通过git worktree和合并门实现，但未提供回滚命令。来源归属通过签名和审计链实现，但发布者身份未验证。扣分原因：用户确认机制不明确，数据流细节不足，回滚机制未明确。
证据显示：自洽性通过确定性调度和回放机制体现，但未验证实际运行。依赖可用性通过锁文件和依赖固定保证，但未验证所有依赖的可用性。失败消息通过退出码和诊断命令提供，但未验证其准确性。扣分原因：静态审查无法验证实际运行，失败消息的准确性未验证。
证据显示：目标受众明确（开发者、运维），场景覆盖广泛（CLI、GUI、云执行）。能力边界通过功能矩阵和已知限制文档明确。触发精度通过精确的命令和配置体现，但未验证所有触发条件。环境适配通过跨平台支持和多种安装方式体现。扣分原因：触发精度未完全验证，环境适配未覆盖所有平台。
证据显示：信息架构清晰，文档齐全。安装说明详细，支持多种安装方式。命名稳定性通过版本号和API稳定性体现，但未验证。示例和FAQ丰富，已知限制明确。许可证为Apache-2.0，版本变更日志存在但未详细。维护责任通过贡献指南和安全政策明确。扣分原因：命名稳定性未验证，版本变更日志未详细。
证据显示：输出可用性通过可验证的收据和回放日志体现，但未验证实际输出。边际价值通过确定性、审计和隔离等特性体现，但未量化。成本效益通过减少人工干预和错误体现，但未提供具体数据。扣分原因：未验证实际输出，成本效益未量化。
证据显示：声明可追溯性通过文档和代码对应体现，但未验证所有声明。跨来源佐证通过外部提及和引用体现，但未验证。事实与推断分离通过文档区分，但未完全明确。扣分原因：跨来源佐证未验证，事实与推断分离未完全明确。
- 发布者身份未验证，需谨慎对待。
- 静态审查无法验证实际运行，确定性声明需自行验证。
- 用户确认机制不明确，可能自动执行任务。
- 依赖众多，需关注供应链安全。
这个 Agent 能做什么，适合哪些场景？
Bernstein 是面向 Claude Code、Codex CLI、Gemini CLI 等 CLI 编码代理的确定性编排器。它先将目标拆解为任务，随后以普通 Python 调度执行；编码任务各自在独立 Git worktree 中运行，产物型任务则使用独立工作目录。系统通过 lint、类型检查和测试等具体信号验证任务，再将通过验证的代码合并到主分支。每次运行都会写入 lineage spine 与 replay journal；启用 BERNSTEIN_AUDIT=1 时，还会生成可离线验证的 HMAC 审计链与收据。它提供 CLI、TUI 实时视图、Web UI、MCP server mode、YAML 工作流，以及 air-gap 安装配置。
运行 bernstein init 会创建 .sdd/ 工作区和 bernstein.yaml。使用 bernstein -g "..." 时，Bernstein 将目标拆解为带角色、文件归属和完成信号的任务，在每个编码任务的 Git worktree 中调用已配置的 CLI 代理，并以测试、文件存在性、lint 和类型检查作为门禁；验证通过后合并结果。bernstein run plan.yaml 可直接执行声明式多阶段计划，计划可包含 agent、command 与 loop 节点。它将运行记录写入 replay journal 和 lineage spine；bernstein replay latest --verify、bernstein lineage verify <run_id>、bernstein audit verify 可重新核验记录，bernstein verify run 可生成 Ed25519 签名的可携带运行收据，bernstein verify receipt 可仅凭收据文件离线验证。
- 需要让 Codex CLI、Claude Code 或 Gemini CLI 并行修改同一代码库的工程团队，可为每个编码任务分配独立 Git worktree，避免默认共享可变文件状态。
- 需要可复核变更过程的安全、合规或评审团队，可启用 BERNSTEIN_AUDIT=1，并将审计链与签名运行收据交给离线审阅者验证。
- 已有明确任务 DAG、不想在计划阶段调用模型的开发负责人，可用 bernstein run plan.yaml 执行 YAML 多阶段计划。
- 要定位一次自动化任务在哪个验证步骤失败的维护者，可运行 bernstein audit diagnose <run_id> --signal gate --sign-key KEY 生成签名诊断收据。
- 在隔离网络或不使用第三方数据平面的环境中部署编码自动化的团队，可采用其文件式状态和 air-gap 安装配置。
这个 Agent 有哪些优点和局限？
- 协调循环使用普通 Python 而非 LLM；项目将其作为可重放任务图和确定性运行的基础。
- 编码任务默认隔离在每任务一个 Git worktree 中，并通过测试、lint、类型检查等合并门禁验证。
- lineage spine 与 replay journal 始终写入；可选 HMAC 审计链和 Ed25519 签名运行收据支持离线核验。
- 支持 40 多种 CLI 代理适配器、通用 --prompt 包装器，以及本地文件式状态和 air-gap 安装配置。
- 需要 Python 3.12+、Git、Shell 环境，以及另行安装并配置可用的 CLI 编码代理。
- 默认隔离依赖 Git worktree；禁用 worktree 后，所有任务会在共享检出目录运行。
- 任务拆解阶段仍使用一次 LLM 调用；确定性描述适用于之后的协调与重放流程。
- Cloudflare Workers 与 R2 工作区同步属于实验性云执行功能，且托管 api.bernstein.run 服务尚不可用。
如何安装或部署这个 Agent？
运行环境需要 Python 3.12+ 和 Git。安装命令：
pipx install bernstein随后进入目标项目并初始化：
bernstein init还需在机器上安装可用的受支持 CLI 编码代理；README 列举了 Claude Code、Codex CLI、Gemini CLI 等，并提供 bernstein integrations list --installed 查看本机可用集成。README 未给出各代理的认证凭据配置步骤。
如何使用这个 Agent？
在已初始化的项目中执行首个目标：
bernstein -g "fix the failing test in tests/test_foo.py"查看进度可运行 bernstein live。若已有计划文件，运行：
bernstein run plan.yaml要为运行保留可核验审计记录，可执行：
BERNSTEIN_AUDIT=1 bernstein -g "fix the failing test in tests/test_foo.py"之后可用 bernstein replay latest --verify 和 bernstein lineage verify <run_id> 验证记录。