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

AI एजेंटों के लिए ओपन-सोर्स गवर्नेंस लेयर

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

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

स्थिति: beta। अकेले मेंटेन किया जा रहा है, सक्रिय विकास में। वर्ज़न नंबर रिलीज़ गिनता है, परिपक्वता नहीं — माइनर वर्ज़न में भी इंटरफ़ेस बदल सकते हैं। जिस पर आप निर्भर हैं उसका वर्ज़न पिन कर लें; रिग्रेशन जल्दी ठीक होते हैं, उन्हें दर्ज करें।

Bernstein AI एजेंटों के लिए ओपन-सोर्स गवर्नेंस लेयर है। यह policy as code पर चलता है: आप नीति लिखते हैं - कौन क्या कर सकता है, किसे स्वीकृति चाहिए, क्या दर्ज होना चाहिए - और Bernstein इसे लागू करता है और सत्यापन-योग्य रिकॉर्ड बनाता है। एक डिटर्मिनिस्टिक शेड्यूलर - कोऑर्डिनेशन लूप में कोई मॉडल नहीं - एजेंटों को समानांतर चलाता है, उनके आउटपुट को गेट से जाँचता है और हर कदम रिकॉर्ड करता है, इसलिए रन को बाद में, ऑफ़लाइन, केवल आर्टिफ़ैक्ट्स से सत्यापित किया जा सकता है। CLI कोडिंग एजेंट सीधे काम करते हैं (Claude Code, Codex, Gemini CLI और 40+ अन्य), और यही लेयर किसी भी एजेंट वर्कलोड को गवर्न करती है: डिलिवरेबल एक diff, रिसर्च रिपोर्ट, डेटासेट या ऑडिट एविडेंस पैक हो सकता है। Air-gap इंस्टॉल प्रोफ़ाइल शामिल। Apache-2.0.

चार चीज़ें इसे अलग करती हैं; उसके बाद सब विवरण है।

• कोऑर्डिनेशन लूप में कोई LLM नहीं। शेड्यूलिंग सादा Python है, इसलिए रन शुरू से आख़िर तक दोहराया जा सकता है। कल का प्लान रिप्ले कीजिए, कल वाला ही टास्क ग्राफ़ मिलेगा।
• बाद में जाँचा जा सकता है। रिप्ले जर्नल हर रन दर्ज करता है, और हमेशा चालू रहने वाली लीनिएज स्पाइन हर लीनिएज-वाहक स्टेप दर्ज करती है; ऑप्ट-इन HMAC-चेन ऑडिट लॉग (BERNSTEIN_AUDIT=1) ऐसी रसीदें जोड़ता है जिन्हें आप ऑफ़लाइन सत्यापित कर सकते हैं। नॉन-डिटर्मिनिज़्म ठीक उसी स्टेप पर हैश मिसमैच बनकर सामने आता है, न कि किसी अस्थिर री-रन के रूप में। ग़ैर-कोड डिलिवरेबल के साथ भी यही बर्ताव है: कोई टास्क आर्टिफ़ैक्ट कॉन्ट्रैक्ट (रिपोर्ट, डेटासेट, ऐक्शन लॉग, ऑप्स नतीजा) घोषित कर सकता है और git कमिट के बजाय हस्ताक्षरित लीनिएज रसीद पर पूरा होता है।
• बनावट से ही अलग-थलग। हर कोडिंग टास्क को मर्ज गेट के पीछे अपना git worktree मिलता है; आर्टिफ़ैक्ट-मोड टास्क को .sdd/workspaces/ के नीचे एक वर्किंग डायरेक्टरी मिलती है। डिफ़ॉल्ट रूप से एजेंट कोई बदलने-योग्य वर्कस्पेस साझा नहीं करते; साझा अवस्था सिर्फ़ टास्क बैकलॉग है, जिसे एटॉमिक ढंग से क्लेम किया जाता है। इससे सख़्त फ़ाइल-सिस्टम पाबंदी ऑप्ट-इन है, सैंडबॉक्स बैकएंड से चुनकर। worktree बंद कर दीजिए तो हर टास्क साझा चेकआउट में चलेगा।
• व्यापक और लोकल। 40 से ज़्यादा 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 में merge गेट्स के पीछे पूरा होता है। ऊपर के नोड अलग तरह से पूरे होते हैं: आर्टिफ़ैक्ट कॉन्ट्रैक्ट डिलिवरेबल का नाम तय करता है (रिपोर्ट, डेटासेट, स्कैन, एक्शन लॉग), और नोड कमिट की जगह हस्ताक्षरित lineage रसीद पर बंद होता है। वही शेड्यूलर, वही जर्नल, वही ऑफ़लाइन सत्यापन - ग्राफ़ कोड ले जाए, रिसर्च, ops बदलाव या तीनों का मिश्रण। सॉफ़्टवेयर, रिसर्च, डॉक्स, एंटरप्राइज़ और कंट्रीब्यूटर वर्कफ़्लो के तैयार ग्राफ़ .bernstein/scenarios/ में हैं।

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

main पर हर push पर CI कमिट की गई रसीद दोबारा सत्यापित करता है — और यह भी साबित करता है कि छेड़छाड़ की गई कॉपी फ़ेल होती है — ताकि प्रकाशित सबूत सड़कर सजावटी फ़ाइल न बन जाए। 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@1 की ऊपरी सीमा के साथ-साथ pass^k निचली सीमा (सभी k कोशिशें पास होनी चाहिए) बताता है। वह नतीजा एक हस्ताक्षरित रसीद में सील होता है जिसे bernstein bench reliability-verify ऑफ़लाइन दोबारा गिनता है, इसलिए गढ़ी हुई निचली सीमा सत्यापन में गिर जाती है। विवरण: pass^k विश्वसनीयता की निचली सीमा।

हर लक्ष्य चार चरणों से गुज़रता है:

1. विघटन। मैनेजर आपके लक्ष्य को टास्क में बाँटता है, हर एक के साथ रोल, अपनी फ़ाइलें और पूर्णता-संकेत देता है। एक LLM कॉल, उसके बाद सादा Python।
2. स्पॉन। एजेंट अलग-थलग git worktree में शुरू होते हैं, प्रति कोडिंग टास्क एक; आर्टिफ़ैक्ट-मोड टास्क को इसके बजाय एक सादी वर्किंग डायरेक्टरी मिलती है। main ब्रांच साफ़ रहती है।
3. सत्यापन। जैनिटर ठोस संकेत जाँचता है: टेस्ट पास होते हैं, फ़ाइलें मौजूद हैं, lint साफ़ है, टाइप सही हैं।
4. मर्ज। सत्यापित काम 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 उस PR को फ़ेल करता है जिसके अनूदित README अंग्रेज़ी स्रोत से भटक गए हों (और बासी सेक्शन का नाम बताता है), 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 से जुड़े हुए सभी 54 इंटीग्रेशन गिनाता है — क्या रिज़ॉल्व होता है, इसका यही इकलौता स्रोत है। उनमें 52 चुनने-योग्य एजेंट अडैप्टर हैं; बाक़ी दो पंक्तियाँ mock टेस्ट स्टब और self-hosted-endpoints एंडपॉइंट प्रोफ़ाइल हैं। --prompt फ़्लैग वाली बाक़ी कोई भी चीज़ जेनेरिक रैपर से चलती है।

एक ही रन में एजेंट मिलाइए: बॉयलरप्लेट के लिए सस्ते लोकल मॉडल, आर्किटेक्चर के लिए भारी क्लाउड मॉडल। bernstein integrations list --installed दिखाता है कि आपकी मशीन पर क्या उपलब्ध है।

कोई प्रोजेक्ट अपने issue को स्वयंसेवकों के लिए खुला चिह्नित कर सकता है, और कोई भी उनमें से एक को अपनी ही मशीन पर, बिना खाते और बिना समन्वयक के, चला सकता है। किसी कार्य को क्या करने की अनुमति है, यह प्रोजेक्ट volunteer.json मैनिफ़ेस्ट में घोषित करता है - सैंडबॉक्स बैकएंड, अनुमत नेटवर्क सूची, वॉल-क्लॉक और मेमोरी की ऊपरी सीमाएँ - और दाता की अपनी सीमाएँ इसे केवल संकरा कर सकती हैं, कभी चौड़ा नहीं। पूरा हुआ कार्य जो रसीद बनाता है वह परिणाम को उसी नियंत्रण-निर्णय से बाँध देती है जिसके अधीन वह चला, इसलिए अनुरक्षक महीनों बाद भी जाँच सकता है कि उस काम को वास्तव में किसे छूने की अनुमति थी।

bernstein volunteer verify .
bernstein volunteer browse --budget 60

दाता मार्गदर्शिका वर्कर चलाने और आपके तय किए बजट को कवर करती है, प्रोजेक्ट मार्गदर्शिका मैनिफ़ेस्ट घोषित करना, और ख़तरा मॉडल बताता है कि हर सीमा किससे बचाती है और किससे नहीं। एक ही कमांड वाला रनर अभी जारी नहीं हुआ है: आज verify, browse और hub काम करने वाले सब-कमांड हैं।

गहराई की हर चीज़ डॉक्स साइट पर रहती है:

Bernstein का नाम अमेरिकी कंडक्टर और संगीतकार लियोनार्ड बर्नस्टीन पर रखा गया है। यह प्रोजेक्ट CLI कोडिंग एजेंट्स की टोली को ठीक वैसे संचालित करता है जैसे बर्नस्टीन न्यूयॉर्क फ़िलहार्मोनिक को संचालित करते थे: हर वादक अपने संकेत पर, स्कोर डिटर्मिनिस्टिक, और कंडक्टर नतीजे के लिए जवाबदेह।

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, अकेले मेंटेन किया जाता है। लाइव आँकड़े: bernstein.run।

vinta/awesome-python में सूचीबद्ध, Augment Code के ओपन-सोर्स एजेंट ऑर्केस्ट्रेटर राउंडअप में शामिल, और Python Weekly #742 में सूचीबद्ध। इस तरीक़े को हमने awesome-agentic-patterns में deterministic zero-LLM orchestration पैटर्न के रूप में भी लिखा है।

PR का स्वागत है; सेटअप और कोड स्टाइल CONTRIBUTING.md में हैं। सुरक्षा रिपोर्ट SECURITY.md के रास्ते जाती हैं। अगर Bernstein से आपका समय बचता है: GitHub Sponsors। संपर्क: forte@bernstein.run।

उद्धरण के लिए मेटाडेटा CITATION.cff में है। लाइसेंस: Apache-2.0; प्रोजेक्ट के नाम को अलग से TRADEMARKS.md में देखा गया है।

Alex Chernysh · GitHub · X · bernstein.run