来源：GitHub (★789)
URL: https://github.com/sipyourdrink-ltd/bernstein
精读日期：2026-08-06
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • Bernstein 是一个确定性编排器（deterministic orchestrator），支持 Claude Code、Codex、Gemini CLI 等 40+ 种 CLI 编码代理，调度层使用纯 Python，无 LLM 参与协调循环。
  • 核心卖点：每次运行可端到端复现——重放昨天的计划即可得到昨天的任务图，非确定性会以哈希不匹配的形式在精确步骤暴露，而非表现为随机性 flaky 重跑。
  • 每个编码任务运行在独立 git worktree 中，位于 lint/type/test 合并门禁之后；artifact 模式任务（报告、数据集、操作日志等）以签名 lineage 收据（signed lineage receipt）而非 commit 完成，使用独立工作目录。
  • 可审计性：始终开启的 lineage 主干和重放日志（replay journal），外加可选 HMAC 链式审计日志，收据可离线验证，无需重跑任务。
  • 默认隔离下代理间无共享可变状态；文件系统级强制隔离为可选，禁用 worktree 时所有任务在共享 checkout 中运行。
  • 项目由单人维护，Apache-2.0 许可，作者因每月 $400 Claude 账单和三个并行代理的非确定性合并问题而发起该项目，GitHub 星标 789。

二、方法/架构拆解

  • 调度架构：纯 Python 调度器，无 LLM 在协调循环中——一次 LLM 调用将目标分解为带角色、属主文件和完成信号的任务，之后全部由 Python 执行；支持多阶段计划（跳过 LLM 规划直接执行）和并行代理生命周期（spawn → 并行工作 → 验证 → 退出）。
  • 隔离机制：每个编码任务一个 git worktree，主分支保持干净；artifact 模式任务使用独立工作目录；janitor 检查具体信号（测试通过、文件存在、lint 干净、类型正确），验证通过的工作合并到 main，失败任务重试或路由到不同模型。
  • 审计链实现：运行收据（run receipt）将日志头、lineage 主干头（可选加审计链范围）绑定在一个 Ed25519 签名主体下，公钥内嵌；验证者持文件和操作者公钥即可确认记录动作与实际执行一致，无需 HMAC 密钥或实时服务；无公钥 pin 时仅做完整性检查（内部一致性，不验证签名者身份）。
  • 评估基准：bernstein bench run <suite> --reliability k 在固定协调下运行 k 次并报告结果，可离线重算验证——伪造的基准下限无法通过验证。
  • 部署与生态：支持 pip、uv、brew、dnf、npm、Docker 及气隙 wheelhouse 安装；registry 枚举全部 48 个内置适配器，支持混合代理（本地廉价模型处理样板代码，云端重型模型处理架构）；含 MCP server 模式、签名代理卡、沙箱后端、artifact 接收器、监管映射；实验性支持 Cloudflare Workers + R2 workspace 同步。
  • 操作面：完整操作员接口（PR 自动化、调度、聊天桥接、autofix 守护进程）在独立模块中；浏览器仪表盘与 TUI 共用同一 API；查询驱动将每个结果绑定到其推导所依据的 schema 快照。

三、值得注意的局限/争议

作者承认的局限：

  • 纯 Python 调度器有明确权衡：放弃 LLM 在协调中的灵活性，换取确定性；不支持动态规划调整。
  • 文件系统强制隔离是可选而非默认，禁用 worktree 时所有任务共享 checkout，可能引入状态污染。
  • 审计链仅在启用 audit 模式时生成，未启用时无链可查。

AI 判断的局限/争议：

  • 确定性编排的适用边界有限：对需要探索性、开放式推理的任务（如架构设计），纯 Python 调度可能过于刚性，作者也承认"where Bernstein is the wrong tool"。
  • 单点依赖：项目为单人维护，长期可持续性和社区响应速度存疑，企业采用需评估维护风险。
  • 审计链的"离线验证"依赖操作者公钥的信任分发，公钥管理本身可能成为攻击面；无 pin 时仅完整性检查，安全性降级。
  • 48 个适配器的兼容性维护成本高，新 CLI 代理版本更新可能导致适配器失效，需持续跟进。

四、与 RRLab 研究的关联

  • Harness 工程：Bernstein 的纯 Python 调度 + git worktree 隔离 + 门禁合并模式，可直接借鉴到 RRLab 的 agent harness 设计中，实现多代理并行执行的可复现性和状态隔离，减少非确定性合并问题。
  • 多模型协同：混合代理策略（本地廉价模型 + 云端重型模型按任务类型分配）与 RRLab 的多模型协同研究方向高度契合，其"一次 LLM 调用分解任务，之后纯 Python 执行"的模式可作为协同编排的参考实现。
  • 模型评测：bernstein bench 的固定协调 + 离线可重算验证机制，为 RRLab 的评测基准提供了防伪造、可审计的评测框架设计思路，尤其适合需要高可信度的基准测试场景。
  • Agent 落地：artifact 模式（非代码交付物以签名收据完成）和 HMAC 审计链，为 RRLab 在 Agent 落地中的合规、审计需求提供了可操作的模式，适合金融、医疗等强监管场景。
  • AI 原生产品：其"确定性编排 + 可验证审计"的定位，可作为 RRLab 构建 AI 原生开发工具链的差异化卖点，解决企业对 AI 代理输出可信度的核心顾虑。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://github.com/sipyourdrink-ltd/bernstein