Bernstein Multi Agent Orchestration

---

状态：测试版。 由个人维护，正在积极开发中。版本号表示发布次数，而非成熟度——次要版本可能会更改接口。请固定所依赖的版本；回归问题会迅速修复，提交问题。

Bernstein 是面向 AI Agent 的开源治理层。它以策略即代码的方式运行：你编写策略——规定谁可以做什么、哪些事项需要审批、必须记录什么——Bernstein 会强制执行策略并生成可验证的记录。确定性调度器（协调循环中不使用模型）可并行运行 Agent、审核其产出并记录每一步，因此运行记录事后可仅凭产物离线验证。命令行编码 Agent 开箱即用（Claude Code、Codex、Gemini CLI 等 50 多种），同一治理层也适用于任何 Agent 工作负载：交付物可以是差异、研究报告、数据集或审计证据包。包含隔离网络安装配置。Apache-2.0。

概览

以下五点让它与众不同；后面都是具体细节。

• 协调流程中不使用大模型。 调度逻辑是纯 Python，因此运行过程端到端可复现。重放昨天的计划，就能得到昨天的任务图。
• 硬件密钥凭证。 离线 PIV 保管和 FIDO2 审批验证器共用收据协议，并采用固定的信任锚和明确的时间。令牌保管不会提高 TRACE 信任级别。请参阅硬件密钥凭证。
• 事后可核验。 重放日志会记录每次运行，常驻的溯源主干会记录每个携带溯源信息的步骤；选择启用的 HMAC 链式审计日志（BERNSTEIN_AUDIT=1）则会添加可离线验证的收据。非确定性会在确切步骤上表现为哈希不匹配，而不是时好时坏的重新运行。非代码交付物也同样处理：任务可以声明工件契约（报告、数据集、操作日志、运维结果），并通过签名溯源收据而非 git 提交完成。
• 从设计上实现隔离。 每个编码任务都有自己的 git 工作树，并受到合并门控；工件模式任务则会在 .sdd/workspaces/ 下获得工作目录。默认情况下，Agent 之间不共享可变工作区；唯一共享的状态是以原子方式认领的任务队列。更严格的文件系统强制措施可选择启用，详见沙盒后端。禁用工作树后，每个任务都会在共享检出目录中运行。
• 覆盖面广，完全本地运行。 提供 50 多个可选的 CLI Agent 适配器，以及通用的 --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]

每个节点都由阶段允许其担任相应角色的 Agent 认领；无论 Agent 在任务中做什么，角色限制和审批门控始终有效。编码节点会在自己的 git 工作树中通过合并门控后完成。上述节点的完成方式则有所不同：工件契约会指定交付物（报告、数据集、扫描结果、操作日志），节点通过签名溯源收据而非提交来完成。无论图交付的是代码、研究成果、运维变更，还是三者的组合，使用的都是同一调度器、同一日志和同一离线验证机制。可直接使用的软件、研究、文档、企业和贡献者工作流图位于 .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 有自己的隔离网络安装指南。

上方录制内容来自一次真实运行，并附有相应的证明。演示录像、根据该次运行日志生成的签名运行收据，以及用于固定该收据的公钥，都位于 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 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=1、使用合规预设，或指定 bernstein run --audit，bernstein audit verify 才有链可供检查。--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. 分解。管理器将你的目标拆分为任务，并为其分配角色、负责的文件和完成信号。只调用一次大模型，之后都使用纯 Python。
2. 派生。Agent 在隔离的 git 工作树中启动，每个编码任务对应一个；制品模式任务则会使用普通工作目录。主分支保持干净。
3. 验证。清理器会检查具体信号：测试通过、文件存在、lint 无误、类型正确。
4. 合并。通过验证的工作会合并到主分支。失败的任务会重试，或转交给其他模型。

为什么调度器使用纯 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 自动化、计划任务、聊天桥接、自修复守护进程）请见运维命令。

bernstein workflow 可运行由 Agent、命令和循环节点构成的声明式 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。

支持的 Agent

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 个是可选的 Agent 适配器，另外两项分别是 mock 测试桩和 self-hosted-endpoints 端点配置。其他任何带有 --prompt 标志的工具都可以通过通用封装器运行。

在同一次运行中混用 Agent：用廉价的本地模型处理样板任务，用更强大的云端模型处理架构设计。bernstein integrations list --installed 会显示你计算机上可用的集成。

志愿计算

项目可以将问题标记为向志愿者开放，任何人都可以在自己的计算机上运行任务，无需账号或协调员。项目会在 volunteer.json 清单中声明任务允许执行的操作——沙盒后端、网络允许列表、运行时长和内存上限；捐赠者自己的限制只能进一步收紧这些条件，不能放宽。任务完成后生成的收据会将结果与任务执行时采用的隔离决策绑定起来，以便维护者在数月后核查该工作实际获准访问的内容。

bernstein volunteer verify .
bernstein volunteer browse --budget 60

捐赠者指南介绍了如何运行工作进程以及如何设置预算；项目指南介绍了如何声明清单；威胁模型说明了每项边界能保护和不能保护的内容。目前尚未提供一键运行器：verify、browse、budget、verify-bundle 和 hub 是当前可用的子命令。autopilot 已注册，但在实现 TaskSource 之前不会运行。

首页之外

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

页面	内容
功能	完整的功能列表：MCP 服务模式、签名 Agent 卡片、沙箱后端、产物接收端、监管映射
bernstein_create_task	POST /api/v1/tasks → bernstein_claim → bernstein_complete
MCP 服务	本地 stdio 服务，以及一个托管的只读端点 mcp.bernstein.run，无需安装即可验证收据；可通过 DeepWiki 使用 MCP 提问有关此仓库的问题
适用对象	价值所在，以及 Bernstein 不适用的场景
工作流	声明式 YAML DAG，由 Agent／命令／循环节点组成
Web UI	与 TUI 使用同一 API 的浏览器仪表板
云端执行	实验性功能：在 Cloudflare Workers 上运行 Agent，并通过 R2 工作区同步到你自己的账户。托管的 api.bernstein.run 服务尚不可用
数据源	只读查询收据，以及一种查询驱动程序，可将每项结果绑定到其所依据的架构快照
Agent 目录	将角色指向内置模板之外的 Agent 定义——通用 YAML／SKILL.md 目录，或 Claude Code 插件布局树
集成	Bernstein 对接的对象，按你称呼它的名称列出：SCIM、OIDC、Vault、OPA/Cedar、SPIFFE、OpenTelemetry、MCP、A2A——说明已提供、已接入以及未计划的内容
安全	评分卡、模糊测试、加固
架构	底层工作原理

名称的由来？

Bernstein 以美国指挥家兼作曲家 Leonard Bernstein 命名。这个项目协调一组 CLI 编码 Agent，就像 Bernstein 指挥纽约爱乐乐团：每位乐手按提示演奏，乐谱确定无误，指挥对结果负责。

我编写 bernstein，是因为我每月花 $400 支付 Claude 账单，让三个编码 Agent 并行运行，却得到无法确定结果的合并。Apache 2.0，个人维护。实时统计：bernstein.run。

提及

收录于 vinta/awesome-python，入选 Augment Code 的开源 Agent 编排器综述，并收录于 Python Weekly #742。我们还在 awesome-agentic-patterns 中将这一方法整理为确定性零 LLM 编排模式。

所有报道：20 多个 awesome 列表、目录、通讯和同行引用

完整的跟踪列表包括每一条 awesome 列表收录、目录条目、既有工作的引用和通讯提及，详见 docs/mentions.md。条目会在出现时添加；欢迎通过 issue 或 PR 提交更正。

管理运行

使用 bernstein_run(template="administrative", goal="Weekly sprint") 创建一个空的、经过审计的容器，不启动规划器或 Agent 进程。使用 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 · 任务通知