Bernstein
Servidor MCP de orquestación multiagente. Inicia ejecuciones paralelas de agentes, gestiona colas de tareas, rastrea costos y verifica puertas de calidad en más de 20 agentes de codificación CLI.
Documentación
"Para lograr grandes cosas, se necesitan dos cosas: un plan y no tener suficiente tiempo." - atribuido a Leonard Bernstein
orquestación determinista de múltiples agentes CLI
sitio web · documentación · instalación · primera ejecución · glosario · limitaciones · política de nombres · patrocinar
Estado: beta. Mantenido en solitario, en desarrollo activo. El número de versión cuenta lanzamientos, no madurez: las versiones menores pueden cambiar interfaces. Fija la versión para cualquier cosa de la que dependas; las regresiones se corrigen rápido, repórtalas.
Bernstein es un orquestador determinista para agentes CLI de codificación (Claude Code, Codex, Gemini CLI y 40+ más). Los ejecuta en paralelo, controla lo que producen y registra suficiente de la ejecución para que puedas verificarla después. Perfil de instalación air-gap incluido. Apache-2.0.
de un vistazo
Cuatro cosas lo distinguen; todo lo demás es detalle.
- Sin LLM en el bucle de coordinación. La planificación es Python puro, por lo que una ejecución es reproducible de principio a fin. Reproduce el plan de ayer y obtén el grafo de tareas de ayer.
- Verificable después del hecho. El diario de reproducción registra cada ejecución, y la columna vertebral de linaje siempre activa registra cada paso con linaje; el registro de auditoría encadenado con HMAC opcional (
BERNSTEIN_AUDIT=1) añade recibos que verificas sin conexión. El no determinismo se manifiesta como una discrepancia de hash en el paso exacto, no como una re-ejecución inestable. Los entregables que no son código reciben el mismo tratamiento: una tarea puede declarar un contrato de artefacto (informe, conjunto de datos, registro de acciones, resultado de operaciones) y se completa con un recibo de linaje firmado en lugar de un commit de git. - Aislado por construcción. Cada tarea de codificación tiene su propio worktree de git detrás de puertas de fusión; las tareas en modo artefacto obtienen un directorio de trabajo bajo
.sdd/workspaces/. Los agentes no comparten espacio de trabajo mutable por defecto; el único estado compartido es el backlog de tareas, que se reclama atómicamente. El cumplimiento más estricto del sistema de archivos es opcional, desde los backends de sandbox. Desactiva los worktrees y cada tarea se ejecuta en el checkout compartido. - Amplio y local. Más de 40 adaptadores de agentes CLI más un wrapper genérico
--prompt, estado basado en archivos, sin salto a SaaS, sin plano de datos de terceros.
La lista completa está en la página de capacidades; la matriz de características es el índice exhaustivo.
instalar en 30 segundos
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 y Docker están cubiertos en la guía de instalación; el wheelhouse aislado tiene su propia guía de air-gap.
La grabación anterior es una ejecución real, y viene con su propia prueba. El elenco, el recibo de ejecución firmado derivado del diario de esa ejecución y la clave pública que lo fija viven todos en docs/assets/demo-run/. Verifica la ejecución que acabas de ver, sin conexión:
bernstein verify receipt docs/assets/demo-run/run-receipt.json \
--public-key docs/assets/demo-run/run-receipt.pub.pem
CI re-verifica el recibo confirmado en cada push a main — y demuestra que una copia manipulada falla — por lo que la evidencia publicada no puede pudrirse en un archivo decorativo. scripts/record_demo.sh regenera la grabación, el recibo y la clave desde una ejecución real nueva; nada dentro del terminal está sintetizado.
Una ejecución en vuelo es observable desde cualquiera de las dos superficies de operador. Ambas leen la misma API de tareas, por lo que ninguna es un espejo rezagado de la otra.
 |  |
|---|---|
bernstein live — el panel de terminal | bernstein gui serve — el panel de navegador |
probar una ejecución
El determinismo aquí es algo que verificas, no algo que aceptas por fe. Ejecuta una vez con auditoría habilitada, luego verifica lo que se registró:
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
El diario se escribe en cada ejecución; la columna vertebral de linaje está siempre activa y gana una entrada por cada paso con linaje, por lo que una ejecución corta puede terminar con una columna vertebral vacía y válida. bernstein audit verify solo tiene una cadena que verificar cuando la ejecución se inició con BERNSTEIN_AUDIT=1, un preset de cumplimiento o bernstein run --audit. La bandera --audit pertenece a bernstein run; en la forma bernstein -g anterior, establece la variable de entorno.
Un recibo de ejecución vincula la cabeza del diario, la cabeza de la columna vertebral de linaje cuando la ejecución escribió entradas de columna vertebral y, opcionalmente, un rango de cadena de auditoría, bajo un único sujeto firmado con Ed25519 con la clave pública incrustada. Un revisor que tenga ese archivo y la clave pública del operador puede confirmar que las acciones y cadenas incrustadas no fueron cambiadas: sin clave HMAC, sin .sdd/ en vivo, y salida 2 nombrando el primer paso divergente en caso de manipulación. Ese recibo identifica el estado del diario que incrusta; probar que ese estado es el diario completo terminado requiere adicionalmente un sello independiente de cabeza/recuento. Con solo el archivo y sin pin --public-key, la verificación es solo de integridad — prueba que el recibo es internamente consistente, no quién lo firmó, y el veredicto lo dice. Detalles en reproducción determinista.
La misma verificabilidad se aplica a los números de evaluación. bernstein bench run <suite> --reliability k (también escrito bernstein eval --reliability k) ejecuta cada tarea k veces bajo coordinación fija, y luego informa un piso pass^k (todos los k intentos deben pasar) junto con el techo pass@1. Ese resultado se sella en un recibo firmado que bernstein bench reliability-verify recalcula sin conexión, por lo que un piso fabricado falla la verificación. Detalles: piso de fiabilidad pass^k.
cómo funciona
Cada objetivo avanza a través de cuatro etapas:
- Descomponer. El gestor divide tu objetivo en tareas con roles, archivos propietarios y señales de finalización. Una llamada LLM, luego Python puro desde ahí.
- Generar. Los agentes comienzan en worktrees de git aislados, uno por tarea de codificación; una tarea en modo artefacto obtiene un directorio de trabajo simple en su lugar. La rama principal permanece limpia.
- Verificar. El conserje comprueba señales concretas: las pruebas pasan, los archivos existen, el lint está limpio, los tipos son correctos.
- Fusionar. El trabajo verificado llega a main. Las tareas fallidas se reintentan o se enrutan a un modelo diferente.
Por qué el planificador es Python puro, y qué se sacrifica con eso: por qué determinista.
comandos cotidianos
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
La superficie completa del operador (automatización de PR, horarios, puentes de chat, el daemon de autofix) está en comandos de operador.
Puertas de higiene del repositorio: bernstein readme-l10n verify falla un PR cuyos README traducidos se desviaron de la fuente en inglés (nombrando la sección obsoleta), bernstein readme-l10n sync los re-vincula después de una edición en inglés. Ver readme-l10n.
agentes compatibles
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 y más. El índice de adaptadores incluye comandos de instalación para 30 de ellos. bernstein integrations list enumera las 51 integraciones cableadas de src/bernstein/adapters/registry.py, la única fuente de verdad para lo que se resuelve. 49 de ellas son adaptadores de agentes seleccionables; las otras dos filas son el stub de prueba mock y el perfil de endpoint self-hosted-endpoints. Cualquier otra cosa con una bandera --prompt funciona a través del wrapper genérico.
Mezcla agentes en la misma ejecución: modelos locales baratos para código repetitivo, modelos de nube más pesados para arquitectura. bernstein integrations list --installed muestra lo que está disponible en tu máquina.
más allá de la portada
Todo lo profundo vive en el sitio de documentación:
| página | qué cubre |
|---|---|
| capacidades | la lista completa de capacidades: modo servidor MCP, tarjetas de agente firmadas, backends de sandbox, sumideros de artefactos, mapeos regulatorios |
| para quién es esto | dónde aterriza el valor, y dónde Bernstein es la herramienta equivocada |
| flujos de trabajo | DAGs YAML declarativos de nodos de agente / comando / bucle |
| interfaz web | panel de navegador en la misma API que usa la TUI |
| ejecución en la nube | experimental: ejecuta agentes en Cloudflare Workers con sincronización de espacio de trabajo R2 contra tu propia cuenta. El servicio alojado api.bernstein.run aún no está disponible |
| fuentes de datos | recibos de consulta de solo lectura, más un controlador de consulta que vincula cada resultado a la instantánea de esquema contra la que se derivó |
| seguridad | cuadro de mando, fuzzing, endurecimiento |
| arquitectura | cómo funciona bajo el capó |
¿por qué el nombre?
Bernstein lleva el nombre de Leonard Bernstein, el director de orquesta y compositor estadounidense. El proyecto orquesta un equipo de agentes CLI de codificación de la misma manera que Bernstein dirigió la Filarmónica de Nueva York: cada músico a su señal, la partitura determinista, el director responsable del resultado.
escribí bernstein porque estaba pagando $400/mes en facturas de claude ejecutando tres agentes de codificación en paralelo y obteniendo fusiones no deterministas. Apache 2.0, mantenido en solitario. Estadísticas en vivo: bernstein.run.
mencionado en
Listado en vinta/awesome-python, cubierto en el resumen de orquestadores de agentes de código abierto de Augment Code, y listado en Python Weekly #742. También escribimos el enfoque como el patrón de orquestación determinista sin LLM en awesome-agentic-patterns.
Toda la cobertura: más de 20 listas awesome, directorios, boletines y citas de pares
La lista completa rastreada, incluyendo cada entrada de lista awesome, listado de catálogo, cita de arte previo y mención en boletín, vive en docs/mentions.md. Las entradas se añaden a medida que aparecen; las correcciones son bienvenidas por issue o PR.
contribuir, soporte, licencia
Los PR son bienvenidos; CONTRIBUTING.md tiene configuración y estilo de código. Los informes de seguridad van a través de SECURITY.md. Si Bernstein te ahorra tiempo: GitHub Sponsors. Contacto: forte@bernstein.run.
Los metadatos de citación viven en CITATION.cff. Licencia: Apache-2.0; el nombre del proyecto está cubierto por separado en TRADEMARKS.md.
Alex Chernysh · GitHub · X · bernstein.run