Bernstein:一个确定性的 Python 协调器,在并行的 git worktree 中运行 44 个 CLI 编码代理,并具备 HMAC 链式审计日志
— 次浏览
Bernstein 是一个 Apache-2.0 许可的 Python 调度器,它分解目标、将 CLI 编码代理(Claude Code、Codex、Gemini CLI,外加 40 多个)生成至隔离的 git worktree 中、针对测试/lint/类型验证每个 diff,并只合并通过者——全部由纯 Python 协调,而非由 LLM,并附带 HMAC-SHA256 审计轨迹。
pipx install bernstein 它是什么
Bernstein 是一个开源(Apache-2.0)的 Python 工具,它协调其他的 CLI 编码代理,而非自己当一个代理。你给它一个目标;一次 LLM 调用将该目标分解成带有专属文件与完成信号的任务,而从那之后调度器就是纯确定性的 Python。它生成代理——Claude Code、OpenAI Codex、GitHub Copilot CLI、Google Gemini CLI、Cursor、Aider、Continue 及其他(截至 v2.7.0 共 44 个适配器,外加一个通用的 --prompt 包装器)——各自进入自己的 git worktree,并行运行它们,然后一个「janitor」阶段在任何成果合并到 main 之前检查具体信号(测试通过、lint 干净、类型正确)。失败的任务会重试或被导向另一个模型。
让它在拥挤的代理框架领域中与众不同的卖点是审计级的确定性:调度决策耗费零 LLM token,每一步都可重放,且每个决策都被写入位于 .sdd/audit/YYYY-MM-DD.jsonl 的 HMAC-SHA256 审计日志。README 着重于合规性、签署的代理卡、逐成品的谱系,以及气隙/本地部署作为差异化要素。
安装与运行
pipx install bernstein # also: pip install bernstein (Python >= 3.12)
cd your-project
bernstein init # creates the .sdd/ workspace
bernstein -g "Add rate limiting" # agents spawn, work in parallel, verify, exit
bernstein live # optional TUI dashboard to watch progress
文档中一个有代表性的运行摘要:
[manager] decomposed into 4 tasks
[agent-1] claude-sonnet: src/auth/middleware.py (done, 2m 14s)
[agent-2] codex: tests/test_auth.py (done, 1m 58s)
[verify] all gates pass. merging to main.
何时使用它
当你有一个跨越多个文件、可并行化的变更,你想要在组合中加入不只一个模型/代理,并且你需要一份可验证的「谁改了什么」记录时(受监管的代码库、前沿部署/气隙工程,或只是不希望 LLM 把 token 烧在协调上的成本敏感团队),就采用 Bernstein。它明确地不适合用来与单一的结对编程伙伴聊天,也不适合非编码的 LLM 工作流程。
| 属性 | 数值 |
|---|---|
| 最新发行版 | v2.7.0 (2026-05-24) |
| 语言/许可 | Python, Apache-2.0 |
| 作者 | Alex Chernysh (sipyourdrink-ltd) |
| 安装 | pipx install bernstein |
| 支持的代理 | 44 个 CLI 适配器 + 通用 —prompt 包装器 |
注意事项
它是一个包装器,而非自给自足的代理:底层的代理 CLI 必须已经安装并在机器上完成验证,且隔离是建立在 git worktree 之上,因此一个非 git 的项目根本无法运行。设计上没有 SaaS 选项——它仅限于本地部署。
从业者注记:杠杆最高的旋钮是任务分解,而非代理选择。因为 Bernstein 确定性地将文件指派给任务,并把每个任务隔离在一个 worktree 中,一个被措辞成让各任务拥有不相交文件的目标会干净且并行地合并;一个迫使两个代理编辑同一模块的目标将会序列化,或产生任何审计日志都无法抚平的合并摩擦。
被考虑不足的角度:大多数「多代理」营销暗示有一个 LLM 在针对协调进行推理,这会增加成本、延迟与不可重现性。Bernstein 的低调赌注恰恰相反——协调应该是无趣的、确定性的代码,而模型唯一的判断调用是那一次的前置分解。那种框架把「多代理」从一个可靠性负债转变成一个可审计的构建步骤,而它是评估任何协调器的一个有用的视角:问问它的调度决策有多少是模型调用、有多少是代码,因为每一个模型在环的决策都是你的运行可能在两次运行之间悄悄分歧的一处。