Bernstein

io.github.sipyourdrink-ltd由 GitHub 帳號 sipyourdrink-ltd 發布v3.23.0更新於 Oct 25, 2026

The open-source governance layer for AI agents. Byte-identical run receipts, 40+ adapters, air-gap.

概覽

AI 產生的概覽

Bernstein 是針對 AI 程式代理的在地治理層,透過 MCP 工具建立、領取、完成並監控可稽核的代理執行。

可以做什麼
建立並執行代理工作流程:啟動執行(含空白的管理容器),執行宣告式 YAML 計畫,排程器具決定性且協調環節不含模型。管理任務:建立任務、領取任務、完成任務並輪詢執行狀態。核驗結果:產生簽章的執行回執與重播日誌,並可離線檢查是否遭竄改。治理工作:套用政策即程式碼、角色圍籬、核准閘門、合併閘門,並為每個任務提供隔離的 git worktree。串接代理:透過轉接器或通用提示包裝器驅動 50 多種 CLI 程式代理。
適用情境
當你希望助理在明確政策下並行編排多個 CLI 程式代理,並取得可重現的排程與可離線核驗的執行紀錄時使用。適合需要稽核證據、產物契約或氣隙環境的團隊,而非單純的單一代理助理情境。
執行需求
以在地 stdio 程序在桌面執行;可透過 uv、pipx、pip、brew、dnf、npm 或 Docker 安裝。需已安裝並完成驗證的受支援 CLI 程式代理,可用 bernstein doctor 檢查。清單未宣告環境變數或標頭;稽核回執需透過 BERNSTEIN_AUDIT 主動開啟。
安裝前請注意
處於 beta 階段、由單人維護,次要版本可能改變介面,建議固定版本。它會啟動會修改程式碼與檔案的代理,並可能合併到主分支,安裝前應先審閱政策、角色圍籬與合併閘門。開啟 BERNSTEIN_AUDIT 會寫入 HMAC 鏈式稽核日誌,簽署回執涉及金鑰。worktree 可被關閉,此時任務共用同一份檢出目錄。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Bernstein,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

[Bernstein]
[Bernstein - the open-source governance layer for AI agents]

"To achieve great things, two things are needed: a plan and not quite enough time." - attributed to Leonard Bernstein

the open-source governance layer for AI agents

[CI] [PyPI] [GHCR] [Python 3.12+] [License] [OpenSSF Scorecard] [CodeQL] [Open in Codespaces] [MCP Toplist] [Ask DeepWiki]

website · docs · install · first run · glossary · limitations · name policy · discord · sponsor

简体中文 · 繁體中文 · 日本語 · 한국어 · हिन्दी · বাংলা · Русский · Español · Português · Deutsch · Français · Italiano · Nederlands · Polski · Svenska · Suomi · Українська · Türkçe · العربية · עברית · Bahasa Indonesia · Tiếng Việt · ไทย


Status: beta. Solo-maintained, under active development. The version number counts releases, not maturity - minor versions may change interfaces. Pin the version for anything you depend on; regressions get fixed fast, file them.

Bernstein is the open-source governance layer for AI agents. It runs on policy as code: you write the policy - who may do what, what needs approval, what must be recorded - and Bernstein enforces it and produces the verifiable record. A deterministic scheduler - no model in the coordination loop - runs agents in parallel, gates what they produce, and records every step, so a run can be verified after the fact, offline, from the artifacts alone. CLI coding agents work out of the box (Claude Code, Codex, Gemini CLI, and 50+ more), and the same layer governs any agent workload: the deliverable can be a diff, a research report, a dataset, or an audit evidence pack. Air-gap install profile included. Apache-2.0.

at a glance

Five things set it apart; everything after is detail.

  • No LLM in the coordination loop. Scheduling is plain Python, so a run is reproducible end to end. Replay yesterday's plan and get yesterday's task graph.
  • Hardware key evidence. Offline PIV custody and FIDO2 approval verifiers share the receipt protocol, with pinned trust and explicit time. Token custody does not raise TRACE trust levels. See hardware key evidence.
  • Checkable after the fact. The replay journal records every run, and the always-on lineage spine records every lineage-bearing step; the opt-in HMAC-chained audit log (BERNSTEIN_AUDIT=1) adds receipts you verify offline. Non-determinism surfaces as a hash mismatch at the exact step, not a flaky re-run. Non-code deliverables get the same treatment: a task can declare an artifact contract (report, dataset, action log, ops result) and completes on a signed lineage receipt rather than a git commit.
  • Isolated by construction. Each coding task gets its own git worktree behind merge gates; artifact-mode tasks get a working directory under .sdd/workspaces/. Agents share no mutable workspace by default; the only shared state is the task backlog, which is claimed atomically. Stricter filesystem enforcement is opt-in, from the sandbox backends. Disable worktrees and every task runs in the shared checkout.
  • Broad and local. More than 50 selectable CLI agent adapters plus a generic --prompt wrapper, file-based state, no SaaS hop, no third-party data plane.

The full list is on the capabilities page; the feature matrix is the exhaustive index.

what a run looks like

One YAML file declares the run: phases, roles, dependencies, and the conditions under which a node runs at all. The scheduler executes it as plain Python - nothing in the file is a prompt, and no model decides what happens next. This graph produces an audit evidence pack; the full file ships at .bernstein/workflows/audit-evidence-pack.yaml.

yaml
name: audit-evidence-packversion: "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'"
mermaid
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]

Each node is claimed by an agent whose role the phase allows; role fences and approval gates hold no matter what the agent does inside the task. A coding node completes behind merge gates in its own git worktree. The nodes above complete differently: an artifact contract names the deliverable (report, dataset, scan, action log), and the node finishes on a signed lineage receipt instead of a commit. Same scheduler, same journal, same offline verification - whether the graph ships code, research, an ops change, or a mix of all three. Ready-made graphs for software, research, docs, enterprise, and contributor workflows live in .bernstein/scenarios/.

install in 30 seconds

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

pipx, pip, brew, dnf, npm, and Docker are covered in the install guide; the air-gapped wheelhouse has its own air-gap guide.

[A real bernstein demo run: mock agents fix four seeded bugs, ending on the run's signed receipt verifying offline]

The recording above is a real run, and it ships with its own proof. The cast, the signed run receipt derived from that run's journal, and the public key that pins it all live in docs/assets/demo-run/. Verify the run you just watched, offline:

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

The committed receipt can be re-checked at any time with the command above, and a tampered copy fails the same check. scripts/record_demo.sh regenerates the recording, receipt, and key from a fresh real run; nothing inside the terminal is synthesised.

A run in flight is watchable from either operator surface. Both read the same task API, so neither is a lagging mirror of the other. In bernstein live, the left and right columns scroll independently as whole panes, so widgets below the fold remain reachable in shorter terminals.

prove a run

Determinism here is something you check, not something you take on faith. Run once with audit enabled, then verify what was recorded:

bash
BERNSTEIN_AUDIT=1 bernstein -g "fix the failing test in tests/test_foo.py"bernstein replay list                 # run ids recorded on diskbernstein replay latest --verify      # recompute the journal head, name the first divergent stepbernstein lineage verify <run_id>     # recompute the always-on lineage spinebernstein 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 receiptbernstein verify run <run_id> --signing-key-path key.pem   # sign one portable run receiptbernstein verify receipt .sdd/runs/<run_id>/run-receipt.json  # verify it offline: file only

The journal is written on every run; the lineage spine is always on and gains an entry for each lineage-bearing step, so a short run can finish with a valid, empty spine. bernstein audit verify only has a chain to check when the run was started with BERNSTEIN_AUDIT=1, a compliance preset, or bernstein run --audit. The --audit flag belongs to bernstein run; on the bernstein -g form above, set the environment variable.

One run receipt binds the journal head, the lineage-spine head when the run wrote spine entries, and, opt-in, an audit-chain range, under a single Ed25519-signed subject with the public key embedded. A reviewer holding that file and the operator's public key can confirm the embedded actions and chains were not changed: no HMAC key, no live .sdd/, and exit 2 naming the first divergent step on tamper. That receipt identifies the journal state it embeds; proving that state is the complete finished journal additionally requires an independent head/count seal. With the file alone and no --public-key pin, the check is integrity-only — it proves the receipt is internally consistent, not who signed it, and the verdict says so. Details in deterministic replay.

The same checkability applies to evaluation numbers. bernstein bench run <suite> --reliability k (also spelled bernstein eval --reliability k) runs every task k times under fixed coordination, then reports a pass^k floor (all k attempts must pass) alongside the pass@1 ceiling. That result is sealed in a signed receipt which bernstein bench reliability-verify recomputes offline, so a fabricated floor fails verification. Details: pass^k reliability floor.

how it works

Each goal moves through four stages:

  1. Decompose. The manager breaks your goal into tasks with roles, owned files, and completion signals. One LLM call, then plain Python from there.
  2. Spawn. Agents start in isolated git worktrees, one per coding task; an artifact-mode task gets a plain working directory instead. Main branch stays clean.
  3. Verify. The janitor checks concrete signals: tests pass, files exist, lint clean, types correct.
  4. Merge. Verified work lands in main. Failed tasks get retried or routed to a different model.

Why the scheduler is plain Python, and what that trades away: why deterministic.

everyday commands

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

The full operator surface (PR automation, schedules, chat bridges, the autofix daemon) is in operator commands.

bernstein workflow runs declarative YAML DAGs of agent, command, and loop nodes - with resume support for interrupted runs:

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

Run state checkpoints to .sdd/runs/<run_id>/ on every node. Resume validates the manifest digest at run start, so a spec change is refused rather than silently executing a different manifest. See workflow manifests.

Repository hygiene gates: bernstein readme-l10n verify fails a PR whose translated READMEs drifted from the English source (naming the stale section), bernstein readme-l10n sync rebinds them after an English edit. See readme-l10n.

supported agents

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, and more. The adapter index carries install commands for 30 of them. bernstein integrations list enumerates all 56 wired-in integrations from src/bernstein/adapters/registry.py, the single source of truth for what resolves. 54 of them are selectable agent adapters; the other two rows are the mock test stub and the self-hosted-endpoints endpoint profile. Anything else with a --prompt flag works through the generic wrapper.

Mix agents in the same run: cheap local models for boilerplate, heavier cloud models for architecture. bernstein integrations list --installed shows what is available on your machine.

volunteer compute

A project can mark issues as open to volunteers, and anyone can run one on their own machine without an account or a coordinator. The project declares what a task is allowed to do in a volunteer.json manifest - sandbox backend, network allowlist, wall-clock and memory ceilings - and a donor's own limits can only narrow that, never widen it. The receipt a finished task produces binds the result to the containment decision it ran under, so a maintainer can check months later what the work was actually permitted to touch.

bash
bernstein volunteer verify .bernstein volunteer browse --budget 60

The donor guide covers running a worker and the budget you set, the project guide covers declaring a manifest, and the threat model states what each boundary does and does not protect. The one-command runner is not shipped yet: verify, browse, budget, verify-bundle and hub are the working subcommands today. autopilot is registered but refuses to run until a TaskSource is implemented.

beyond the front page

Everything deep lives on the docs site:

pagewhat it covers
capabilitiesthe full capability list: MCP server mode, signed agent cards, sandbox backends, artifact sinks, regulatory mappings
bernstein_create_taskPOST /api/v1/tasks → bernstein_claim → bernstein_complete
MCP serverlocal stdio server, plus a hosted read-only endpoint at mcp.bernstein.run for receipt verification with no install; questions about this repo can be asked over MCP through DeepWiki
who this is forwhere the value lands, and where Bernstein is the wrong tool
workflowsdeclarative YAML DAGs of agent / command / loop nodes
web UIbrowser dashboard on the same API the TUI uses
cloud executionexperimental: run agents on Cloudflare Workers with R2 workspace sync against your own account. The hosted api.bernstein.run service is not yet available
datasourcesread-only query receipts, plus a query driver that binds each result to the schema snapshot it was derived against
agent catalogspoint roles at agent definitions outside the built-in templates - a generic YAML/SKILL.md directory, or a Claude Code plugin-layout tree
integrationswhat Bernstein bridges to, by the name you call it: SCIM, OIDC, Vault, OPA/Cedar, SPIFFE, OpenTelemetry, MCP, A2A - with what is shipped, what is wired, and what is not planned
securityscorecard, fuzzing, hardening
architecturehow it works under the hood

why the name?

Bernstein is named after Leonard Bernstein, the American conductor and composer. The project orchestrates a crew of CLI coding agents the way Bernstein conducted the New York Philharmonic: every player on cue, the score deterministic, the conductor accountable for the result.

i wrote bernstein because i was paying $400/month in claude bills running three coding agents in parallel and getting nondeterministic merges. Apache 2.0, solo maintained. Live stats: bernstein.run.

mentioned in

Listed in vinta/awesome-python, covered in Augment Code's open-source agent orchestrators roundup, and listed in Python Weekly #742. We also wrote up the approach as the deterministic zero-LLM orchestration pattern in awesome-agentic-patterns.

All coverage: 20+ awesome lists, directories, newsletters, and peer citations

The full tracked list, including every awesome-list entry, catalog listing, prior-art citation, and newsletter mention, lives in docs/mentions.md. Entries are added as they appear; corrections welcome by issue or PR.

Administrative runs

Use bernstein_run(template="administrative", goal="Weekly sprint") to create an empty, audited container without a planner or agent process. Add manual work with bernstein_create_task(title="Review brief", description="...", run_id="admin-...") and poll bernstein_run_status(run_id="admin-..."). Members are claimable through the usual claim API and excluded from automatic orchestration. A nonempty run completes when every member has status done, closed, or cancelled; an empty run stays open. See the operator workflow.

contributing, support, license

PRs welcome; CONTRIBUTING.md has setup and code style. Security reports go through SECURITY.md. If Bernstein saves you time: GitHub Sponsors. Contact: [email protected].

Citation metadata lives in CITATION.cff. License: Apache-2.0; the project name is covered separately in TRADEMARKS.md.


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

來源:README.md,提交 90da568

工具

0
SourceWeft 曾在隔離沙箱中以無憑證方式啟動該軟體包一次,以列出其工具,但未能完成:軟體包安裝失敗。

版本歷史

5
  1. v3.23.0最新Oct 25, 2026
  2. v3.22.0Oct 15, 2026
  3. v3.21.0Oct 5, 2026
  4. v3.20.0Sep 22, 2026
  5. v3.19.2Sep 16, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分