sipyourdrink-ltd/bernstein

---

状态：beta。 由单人维护，正在积极开发中。版本号计的是发布次数，而非成熟度——次版本（minor）可能改变接口。凡有依赖请锁定版本；回归问题会被尽快修复，欢迎提交。

Bernstein 是面向 AI 智能体的开源治理层。它运行在 policy as code 之上:你编写策略——谁可以做什么、什么需要审批、什么必须被记录——Bernstein 据此执行并生成可验证的记录。确定性调度器 - 协调环路中没有模型 - 并行运行智能体,用门禁把关它们的产出,并记录每一步,因此一次运行可以在事后离线验证,仅凭工件本身。CLI 编码智能体开箱即用(Claude Code、Codex、Gemini CLI 及 50+ 款),同一治理层管辖任何智能体工作负载:交付物可以是 diff、研究报告、数据集,或一份审计证据包。附带 air-gap 安装配置。Apache-2.0。

一览

五点使它与众不同；其余都是细节。

• 协调循环中没有 LLM。 调度是纯 Python，因此运行可以端到端复现。重放昨天的计划，得到昨天的任务图。
• 硬件密钥证据. 离线 PIV 保管证明和 FIDO2 批准验证器共用收据协议，使用固定信任和明确时间。令牌保管不会提升 TRACE 信任级别。 硬件密钥证据.
• 事后可核查。 回放日志记录每一次运行，常驻的血统脊柱记录每个产生血统的步骤；可选的 HMAC 链式审计日志（BERNSTEIN_AUDIT=1）增加了可离线验证的收据。不确定性会在精确步骤处以哈希失配的形式浮出水面，而不是一次偶发的重跑。非代码交付物也享受同样待遇：任务可以声明产物契约（报告、数据集、动作日志、运维结果），并以签署的血统收据而非 git 提交来宣告完成。
• 构造上即隔离。 每个编码任务在合并门禁之后获得自己的 git worktree；产物模式任务在 .sdd/workspaces/ 下获得工作目录。智能体之间默认不共享可变的工作区；唯一共享的状态是任务积压，并以原子方式认领。更严格的文件系统强制是可选的，来自沙箱后端（禁用 worktree 会在共享检出中运行每个任务）。
• 广泛且本地。 53 多个 CLI 智能体适配器，外加通用的 --prompt 包装器、基于文件的状态、无 SaaS 跳转、无第三方数据平面。

完整列表见能力页面；功能矩阵是详尽的索引。

一次运行长什么样

一个 YAML 文件声明整次运行:阶段、角色、依赖,以及节点在什么条件下才会执行。调度器把它当作纯 Python 执行 - 文件里没有任何提示词,也没有模型决定下一步发生什么。这张图生成一份审计证据包;完整文件在 .bernstein/workflows/audit-evidence-pack.yaml。

name: audit-evidence-pack
version: "1.0.0"

phases:
  - name: scope
    allowed_roles: [manager, architect]
  - name: collect
  - name: validate
    allowed_roles: [qa, security]
  - name: deliver
    allowed_roles: [security, manager]

nodes:
  define-control-inventory:
    phase: scope
    role: architect

  collect-audit-logs:
    phase: collect
    role: security
    depends_on: [define-control-inventory]

  # three more evidence streams collect in parallel:
  # collect-sboms-and-attestations, collect-runbooks-and-policies,
  # collect-eval-results

  assemble-pack:
    phase: validate
    role: docs
    depends_on:
      - collect-audit-logs
      - collect-sboms-and-attestations
      - collect-runbooks-and-policies
      - collect-eval-results

  mock-auditor-pass:
    phase: validate
    role: qa
    depends_on: [assemble-pack]

  remediate-findings:
    phase: collect
    role: docs
    depends_on:
      - source: mock-auditor-pass
        condition: "status == 'failed'"
    retry:
      max_attempts: 3
      until: "status == 'done'"

  sign-and-deliver:
    phase: deliver
    role: security
    depends_on:
      - source: mock-auditor-pass
        condition: "status == 'done'"

flowchart LR
    inv[define-control-inventory] --> logs[collect-audit-logs]
    inv --> sbom[collect-sboms-and-attestations]
    inv --> rb[collect-runbooks-and-policies]
    inv --> ev[collect-eval-results]
    logs --> pack[assemble-pack]
    sbom --> pack
    rb --> pack
    ev --> pack
    pack --> gate{mock-auditor-pass}
    gate -->|failed| fix["remediate-findings (retry x3)"]
    gate -->|done| sign[sign-and-deliver]

每个节点由角色被该阶段允许的智能体认领;无论智能体在任务内做什么,角色围栏和审批门禁始终生效。代码节点在自己的 git worktree 里、合并门禁之后完成。上面这些节点的完成方式不同:工件契约指明交付物(报告、数据集、扫描、操作日志),节点以签名的 lineage 回执而非提交收尾。同一个调度器、同一份日志、同样的离线验证 - 无论图里装的是代码、研究、运维变更,还是三者混合。面向软件、研究、文档、企业和贡献者工作流的现成图都在 .bernstein/scenarios/。

30 秒安装

uv tool install bernstein    # or: pipx install bernstein
bernstein init
bernstein doctor             # checks a CLI agent is installed and authenticated
bernstein -g "fix the failing test in tests/test_foo.py"

pipx、pip、brew、dnf、npm 和 Docker 都涵盖在安装指南中；离线 wheelhouse 有单独的 air-gap 指南。

上面的录像是真实运行，并且自带证明：录制文件、从那次运行的日志导出的签署运行收据，以及将其钉死的公钥，一起存放在 docs/assets/demo-run/ 中。离线验证你刚看到的运行：

bernstein verify receipt docs/assets/demo-run/run-receipt.json \
    --public-key docs/assets/demo-run/run-receipt.pub.pem

已保存的回执可随时用上述命令重新验证；被篡改的副本无法通过同样的检查。 scripts/record_demo.sh 从一次全新的真实运行重新生成录制、收据和密钥；终端里没有任何内容是合成的。

运行中的任务可从任一操作界面观看。两者读取同一个任务 API，因此彼此都不是对方的滞后镜像。

bernstein live — 终端仪表盘	bernstein gui serve — 浏览器仪表盘

证明一次运行

这里的确定性是需要你去核查的东西，而不是凭空相信。启用审计运行一次，然后验证记录的内容：

BERNSTEIN_AUDIT=1 bernstein -g "fix the failing test in tests/test_foo.py"
bernstein replay list                 # run ids recorded on disk
bernstein replay latest --verify      # recompute the journal head, name the first divergent step
bernstein lineage verify <run_id>     # recompute the always-on lineage spine
bernstein audit verify                # HMAC chain + Merkle seal (written because audit was enabled)
bernstein audit diagnose <run_id> --signal gate --sign-key KEY
                                      # name the exact step a failure entered the run, as a signed receipt
bernstein verify run <run_id> --signing-key-path key.pem   # sign one portable run receipt
bernstein verify receipt .sdd/runs/<run_id>/run-receipt.json  # verify it offline: file only

日志在每次运行时写入；血统脊柱始终开启，在每个产生血统的步骤上增加一条记录，因此一次很短的运行可能以有效但为空的脊柱结束。bernstein audit verify 只有在运行以 BERNSTEIN_AUDIT=1、合规预设或 bernstein run --audit 启动时才有链可查。--audit 旗标属于 bernstein run；在上面的 bernstein -g 形式中，请设置环境变量。

运行收据在一个 Ed25519 签署主体下绑定日志头部、运行写入脊柱条目时的血统脊柱头部，以及可选的审计链范围，并内嵌公钥。持有该文件与操作者公钥的审查者可以确认其中嵌入的动作与链未被改动：无需 HMAC 密钥，无需活跃的 .sdd/，篡改时以退出码 2 命名第一个分歧步骤。收据标识的是它所嵌入的那一份日志状态；要证明该状态就是完整收尾的日志，还需要一份独立的头部／条数封印。仅凭文件（不钉 --public-key）时，检查只是完整性检查：它证明收据内部自洽，而非谁签署的，结论也会如实说明。详见确定性回放。

同样的可核查性也适用于评估数字。bernstein bench run <suite> --reliability k（也写作 bernstein eval --reliability k）在固定协调下把每个任务运行 k 次，然后报告 pass^k 下限（所有 k 次尝试都必须通过）以及 pass@1 上限。该结果封装在一份签署的收据中，bernstein bench reliability-verify 可离线重算，因此伪造的下限会验证失败。详情：pass^k 可靠性下限。

工作原理

每个目标经历四个阶段：

1. 分解（Decompose）。管理者把你的目标分解为带角色、归属文件和完成信号的任务。一次 LLM 调用，然后全是纯 Python。
2. 孵化（Spawn）。智能体在隔离的 git worktrees 中启动，每个编码任务一个；产物模式任务获得普通工作目录。主分支保持干净。
3. 验证（Verify）。janitor 检查具体信号：测试通过、文件存在、lint 干净、类型正确。
4. 合并（Merge）。验证过的工作落入 main。失败的任务被重试或路由到不同模型。

调度器为什么是纯 Python，以及这换来什么代价：为什么确定性。

日常命令

cd your-project
bernstein init                    # creates .sdd/ workspace, bernstein.yaml + templates/
bernstein -g "Add rate limiting"  # agents spawn, work in parallel, verify, exit
bernstein live                    # watch progress in the TUI dashboard
bernstein run plan.yaml           # multi-stage plan: skip LLM planning, execute directly
bernstein stop                    # graceful shutdown with drain

完整的操作界面（PR 自动化、定时任务、聊天桥接、autofix 守护进程）见操作命令。

bernstein workflow 运行智能体/命令/循环节点的声明式 YAML DAG——支持恢复中断的运行：

bernstein workflow run idea-to-pr -g "Add JWT auth"   # prints run_id
bernstein workflow resume <run_id>                    # picks up at the first non-completed node

每个节点上的运行状态都会作为检查点写入 .sdd/runs/<run_id>/。恢复在运行起始时校验清单摘要，因此规格变更会被拒绝，而不是静默地按另一份清单执行。见工作流清单。

仓库卫生门禁：bernstein readme-l10n verify 会让翻译版 README 偏离英文源的 PR 失败（并指出过期的章节），bernstein readme-l10n sync 在英文修改后重新绑定它们。见 readme-l10n。

支持的智能体

Claude Code、Codex CLI、Gemini CLI、GitHub Copilot CLI、Cursor、Aider、Goose、Muse Code、OpenAI Agents SDK、Amp、Cody、Continue、Devin Terminal、Junie、Kilo、Kiro、AWS Q Developer、Ollama、OpenCode、OpenHands、Open Interpreter、gptme、Plandex、AIChat、Letta Code、Qwen 等等。适配器索引为其中 30 个提供安装命令。bernstein integrations list 从 src/bernstein/adapters/registry.py 中的注册表枚举全部 56 个已接线集成，该文件是"什么能解析"的唯一事实来源。其中 54 个是可选择的智能体适配器，另外两行是 mock 测试桩和 self-hosted-endpoints 端点配置。任何带 --prompt 旗标的其他工具都可以通过通用包装器工作。

在同一运行中混用智能体：用便宜的本地模型处理样板，用更重的云模型处理架构。bernstein integrations list --installed 显示你的机器上可用的内容。

志愿算力

项目可以把 issue 标记为向志愿者开放，任何人都可以在自己的机器上运行其中一个，无需账号，也无需协调者。任务被允许做什么，由项目在 volunteer.json 清单中声明 —— 沙箱后端、允许访问的网络列表、挂钟时间与内存上限 —— 而捐献者自己的限制只能把它收紧，永远不能放宽。已完成任务产生的回执把结果绑定到它运行时所依据的隔离决策上，因此维护者在数月之后仍能核对这项工作当时究竟被允许触碰什么。

bernstein volunteer verify .
bernstein volunteer browse --budget 60

捐献者指南 讲运行 worker 以及你设定的预算，项目指南 讲声明清单，威胁模型 说明每一层边界防护什么、不防护什么。单条命令的运行器尚未发布：目前可用的子命令是 verify、browse、budget、verify-bundle 和 hub。 autopilot 已注册，但在实现 TaskSource 之前会拒绝运行。

首页之外

所有深入内容都在文档站点上：

页面	内容
capabilities	完整能力列表：MCP 服务器模式、签署的智能体卡片、沙箱后端、产物存储、监管映射
bernstein_create_task	POST /api/v1/tasks → bernstein_claim → bernstein_complete
who this is for	价值落在哪里，以及 Bernstein 何时是错误工具
workflows	智能体/命令/循环节点的声明式 YAML DAG
web UI	与 TUI 使用同一 API 的浏览器仪表盘
cloud execution	实验性：在你的账户上通过 R2 workspace 同步在 Cloudflare Workers 上运行智能体。托管的 api.bernstein.run 服务尚不可用
datasources	只读查询收据，外加把每个结果绑定到其推导时所依据的 schema 快照的查询驱动
智能体目录	让角色指向内置模板之外的智能体定义：通用的 YAML/SKILL.md 目录，或 Claude Code 插件布局的目录树
security	scorecard、模糊测试、加固
architecture	底层工作原理

为什么叫这个名字？

Bernstein 得名于美国指挥家、作曲家 Leonard Bernstein。这个项目像 Bernstein 指挥纽约爱乐乐团那样编排一支 CLI 编码智能体队伍：每个乐手准时到位，乐谱确定，指挥对结果负责。

我写 bernstein 是因为我每月为并行运行三个编码智能体支付 400 美元的 claude 账单，却得到不确定性的合并。Apache 2.0，单人维护。实时数据：bernstein.run。

被提及的地方

收录于 vinta/awesome-python，被 Augment Code 的开源智能体编排器综述提及，并收录于 Python Weekly #742。我们也把这一方法写成了 awesome-agentic-patterns 中的确定性零 LLM 编排模式条目。

全部覆盖：20 多个 awesome 列表、目录、通讯和同行引用

完整跟踪列表，包括每一条 awesome-list 条目、目录收录、先前引用和通讯提及，都在 docs/mentions.md 中。条目出现即添加；欢迎通过 issue 或 PR 更正。

管理运行

使用 bernstein_run(template="administrative", goal="Weekly sprint") 创建经过审计的空容器，不启动规划器或代理进程。通过 bernstein_create_task(title="Review brief", description="...", run_id="admin-...") 添加手动任务，并用 bernstein_run_status(run_id="admin-...") 查询状态。成员任务可通过常规认领 API 领取，但不会自动编排。非空运行在所有成员的状态均为 done、closed 或 cancelled 时结束；空运行保持开放。 操作流程.

贡献、支持与许可

欢迎 PR；CONTRIBUTING.md 有环境搭建和代码风格。安全报告通过 SECURITY.md 提交。如果 Bernstein 为你节省了时间：GitHub Sponsors。联系：[email protected]。

引用元数据位于 CITATION.cff。许可：Apache-2.0；项目名在 TRADEMARKS.md 中单独说明。

---

Alex Chernysh · GitHub · X · bernstein.run · task notifications