Apache Burr: भरोसेमंद AI एजेंट और एप्लिकेशन बनाना

 (burr.apache.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apache Burr एक framework है जो simple chatbot से लेकर complex multi-agent system तक decision-making AI applications को Python में बनाने के लिए उपयोग होता है
  • एप्लिकेशन को actions और transitions के set के रूप में define किया जाता है, और DSL या YAML के बिना Python functions और decorators से लिखा जाता है
  • Burr UI execution के हर step पर monitoring·debugging·tracing देता है, और state changes को real time में देखा जा सकता है
  • state को disk, database, या custom backend में save किया जा सकता है, interruption point से resume किया जा सकता है, और human input wait व parallel execution भी support होते हैं
  • यह OpenAI, Anthropic, LangChain, FastAPI, PostgreSQL जैसे existing tools के साथ integrate होता है, और lock-in या wrapper के बिना इस्तेमाल किया जा सकता है

भरोसेमंद AI एजेंट और एप्लिकेशन बनाना

  • Apache Burr decision-making applications के development को आसान बनाने वाला Apache Incubating Project है
  • इसका दायरा simple chatbot से complex multi-agent systems तक फैला हुआ है
  • इसका implementation pure Python में है, और यह “no magic” approach को आगे रखता है
  • public metrics के रूप में GitHub Stars 1,641, PyPI Downloads 379k+, Discord Members 457+ दिखाए गए हैं

सरल और शक्तिशाली Python API

  • Burr chatbot से multi-agent system तक बनाने के लिए composable interface देता है
  • example code में burr.core के action, State, ApplicationBuilder का उपयोग करके chat action define किया गया है
  • @action(reads=["messages"], writes=["messages"]) पढ़ी जाने वाली state और लिखी जाने वाली state को specify करता है
  • ApplicationBuilder() action, transition, initial state, और local tracker को set करने के बाद application build करता है
  • execution example app.run(halt_after=["chat"], inputs={"llm_client": client}) के रूप में LLM client को input के तौर पर pass करता है

AI एप्लिकेशन बनाने के लिए ज़रूरी तत्व

  • Simple Python API एप्लिकेशन को actions और transitions के set के रूप में define करता है, और DSL या YAML के बिना सिर्फ Python functions और decorators का उपयोग करता है
  • Built-in Observability Burr UI के जरिए application के हर step को real time में monitor, debug, और trace करने की सुविधा देता है
  • Persistence & State Management state को disk, database, या custom backend में अपने-आप save करता है और interruption point से resume करने देता है
  • Human-in-the-Loop किसी भी step पर execution रोककर human input का इंतज़ार कर सकता है, इसलिए यह approval workflow और interactive agents के लिए उपयुक्त है
  • Branching & Parallelism parallel action execution, fan out / fan in, complex DAG construction, और sub-application composition को support करता है
  • Testing & Replay past runs को replay करने, individual action unit test करने, और state transitions को verify करने के जरिए AI systems पर भरोसा बढ़ाता है

मौजूदा stack के साथ integration

  • Burr पहले से इस्तेमाल हो रहे tools और frameworks के साथ integrate होता है, और lock-in या wrapper की ज़रूरत नहीं होती
  • LLM integration में OpenAI, Anthropic, Instructor दिखाए गए हैं
  • framework integration में LangChain, Hamilton, Haystack दिखाए गए हैं
  • UI और serving integration में Streamlit और FastAPI दिखाए गए हैं
  • validation और storage integration में Pydantic और PostgreSQL दिखाए गए हैं
  • integrations की पूरी list दस्तावेज़ में देखी जा सकती है

डेवलपर्स और टीमों का उपयोग अनुभव

  • Peanut Robotics की प्रतिक्रिया के अनुसार कई LLM frameworks का मूल्यांकन करने के बाद Burr का state management AI decision-making आधारित robotics deployment के लिए एक मजबूत समाधान साबित हुआ
  • Watto.ai की प्रतिक्रिया के अनुसार modular AI applications बनाना आसान है, और UI debugging को आसान बनाता है
  • Paxton AI की प्रतिक्रिया इस बात पर ज़ोर देती है कि सिर्फ AI होने की वजह से अजीब और कठिन concepts का उपयोग नहीं किया जाता
  • Provectus की प्रतिक्रिया के अनुसार state snapshots बनाना, debugging, replay, और evaluation cases तैयार करना Burr के state management से आसान हुआ
  • CognitiveGraphs की प्रतिक्रिया के अनुसार LangChain, CrewAi, AutoGen, Agency Swarm जैसे कई agentic LLM platforms की तुलना में Burr complex behavior design के लिए अधिक robust framework देता है
  • TaskHuman की प्रतिक्रिया के अनुसार LangChain से Burr पर आने के बाद कुछ ही घंटों में काम शुरू हो गया, और पूरी codebase को Burr पर migrate कर दिया गया

कम्युनिटी और प्रोजेक्ट की स्थिति

  • कम्युनिटी मदद माँगने, प्रोजेक्ट साझा करने, और Burr के future contribution के लिए एक जगह के रूप में बनी है
  • भागीदारी के रास्ते Discord, GitHub, Twitter / X के रूप में दिए गए हैं
  • प्रोजेक्ट resources में docs, examples, YouTube, roadmap, और changelog के लिंक शामिल हैं
  • Apache Burr Apache Software Foundation में incubation के तहत चल रहा प्रोजेक्ट है, और इसे Apache Incubator sponsor करता है
  • incubation status ज़रूरी नहीं कि code की completeness या stability को दिखाए, लेकिन यह बताता है कि इसे अभी ASF की पूरी मंज़ूरी नहीं मिली है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News टिप्पणियाँ

  • एजेंट framework को लेकर अभी फैसला सुरक्षित है, और इसकी उपयोगिता एजेंट की प्रकृति पर निर्भर करती है। उदाहरण के लिए, 3 सेकंड के भीतर पर्याप्त अच्छा जवाब देना हो या एक ही समस्या को 3 घंटे तक हल करना हो, दोनों अलग बातें हैं
    आखिरकार एजेंट को context बनाना, LLM call करना, मांगे गए tool calls चलाना, अंतिम model output को parse करना, और frontend को लौटाना—इन तक समेटा जा सकता है। memory या async tool calls जैसी extensions हैं, लेकिन पारंपरिक software engineering नज़रिए से यह इतना जटिल नहीं है
    हर कोई अपना agent framework बनाना चाहता है, लेकिन अगर किसी खास agent को बनाना हो, तो उस agent के लिए लिखा गया 1:1 code कहीं ज्यादा आसान होता है और maintenance भी बेहतर रहती है। framework की abstractions अक्सर core logic को छिपा देती हैं और काम में बाधा बनती हैं, और अंत में framework ने जो abstraction चुनी है उसी के हिसाब से ढलना पड़ता है, जिससे असली लक्ष्य से भटकाव हो सकता है

    • मेरा मानना है कि agent-style systems का सार agent इस्तेमाल करने में नहीं, बल्कि केवल तब इस्तेमाल करने में है जब सचमुच ज़रूरत हो। एक काम करने वाले system में multi-step flow को व्यक्त करने के लिए pipeline/recipe, कई agent worker pools में model और human-in-the-loop चरणों को भरोसेमंद ढंग से चलाने वाली operations व्यवस्था, जितना हो सके उतना काम code से कराने वाले thick skills का management/deployment/security/permissions, और सही session में सही context डालने वाली context management चाहिए
      इसके अलावा tickets, dependencies, progress, और अटके हुए tickets को फिर से शुरू करने वाला project management, conversation history storage और memory, dreaming, cumulative learning जैसी क्षमताएँ, cost और usage देखने की observability, prompt evaluation और auto-tuning, model provider बदलना और model version pinning, तथा असली sessions चलाने के लिए sandbox भी चाहिए
      यह सब कुछ एक ही vendor से लेना ज़रूरी नहीं है, लेकिन ज़्यादातर मामलों में किसी एक model provider में फँसना नहीं चाहिए, और अपना context तथा cumulative learning सीधे अपने नियंत्रण में होना चाहिए
    • ज़्यादातर agent frameworks में सबसे गंभीर समस्या core logic को छिपाना है। असली language model को क्या भेजा जा रहा है और वहाँ से क्या वापस आ रहा है, यह साफ़ दिखना चाहिए
      agent-style application की हर चीज़ आखिरकार token sequence या provider call के रूप में ही साकार होती है, इसलिए app की लगभग हर layer में यह रूप स्पष्ट होना चाहिए
    • दर्जनों frontend frameworks को लेकर भी मेरा ऐसा ही विचार रहा है। ये ऐसे लगते हैं जैसे भविष्य में शायद मिलने वाले, लेकिन शायद कभी न आने वाले फ़ायदे के लिए भारी abstraction और complexity लाद दी गई हो
      फिर भी लोगों को करने के लिए काम या खेलने के लिए मज़ेदार खिलौने चाहिए, और “अगले व्यक्ति” को आम तौर पर इतना महत्वपूर्ण नहीं माना जाता, इसलिए paid playtime के नतीजे किसी और पर थोप देने में उन्हें कोई समस्या नहीं लगती
    • किसी खास agent के लिए 1:1 code लिखने वाले तरीके से मैं कुछ हद तक सहमत हूँ। लेकिन जब किसी नए agent में नई techniques या approaches बनती हैं, तब पुराने agents को कैसे update किया जाए और क्या उन्हें update करना भी चाहिए—यह maintenance के लिहाज़ से चिंता का विषय रहता है
      उदाहरण के लिए, लगता है Apache Burr pluggable vector RAG system को support करता है या आगे करेगा, लेकिन ज़रूरत ऐसी व्यवस्था की है जो documents को context में जोड़े, उन्हें updated system prompt के हिस्से के रूप में बनाए रखे, और उस प्रक्रिया में बहुत ही specific tuning डाले। यह मौजूदा RAG concept का customized इस्तेमाल है, इसलिए किसी खास framework के साथ अच्छी तरह फिट नहीं बैठता
      मेरे use case में custom implementation सही है, लेकिन पुराने agents को refresh करने के लिए engineering choices का सवाल फिर भी बना रहता है
    • framework का फ़ायदा असल में agent लिखना आसान बनाने में नहीं, बल्कि tools और observability जैसी चीज़ों में है। LangChain पर आलोचना करने के लिए बहुत कुछ है, लेकिन उसने यह बात शुरुआत में ही बहुत साफ़ दिखा दी थी
      chatbot को scratch से खुद बनाना आसान हो सकता है, या शायद उससे भी आसान, लेकिन जब observability या tracing जोड़नी हो तो कहानी बदल जाती है। अगर सिर्फ एक environment variable जोड़कर UI में लगभग बिना अतिरिक्त काम के सारी tracing देखी जा सके, तो self-built solution के लिए प्रतिस्पर्धा करना मुश्किल हो जाता है

  • जिज्ञासा है कि क्या यह पेज https://vorpus.github.io/performativeUI/ से बनाया गया है
    यह AI-generated landing page के लगभग हर संभव cliché पर खरा उतरता है। या फिर क्या यह जानबूझकर किया गया व्यंग्य है

  • मैं इस framework को personal projects और काम के projects दोनों में पसंद से इस्तेमाल करता हूँ। AI models के लिए भरोसेमंद stateful workflows और free observability मिलना मुझे अच्छा लगा
    मैंने Burr state machine को MCP पर mount करने वाले tools को जोड़ा है, और agent को follow करने के लिए rails देते हुए भी MCP tools state machine navigation तक सीमित रहते हैं, चाहे state machine कितनी भी complex हो: https://github.com/msradam/theodosia
    अभी मैं skills को state machine में बदलने पर काम कर रहा हूँ। कई लोकप्रिय skills पहले से ही उन चरणों के रूप में लिखे गए हैं जिन्हें AI model follow कर सकता है, इसलिए लगता है कि Burr की explicit capabilities का इस्तेमाल करके उन्हें और reliable बनाया जा सकता है

  • https://strandsagents.com/ की तुलना में यह कैसा है, यह जानना चाहता हूँ। मुझे इस क्षेत्र के tools में दिलचस्पी है और अभी किसी खास tool से बँधा नहीं हूँ, लेकिन Bedrock + Serverless on Agent Core एक “आसान guided path” जैसा लगता है। हालांकि platform lock-in पसंद नहीं है

    • दूसरों का अनुभव भी जानना चाहूँगा। मैं इस stack को आज़मा रहा हूँ, लेकिन अभी भी संदेह है कि क्या Strands, Agent Core के साथ कोई खास गुप्त लाभ देता है
      अभी तक तो ऐसा महसूस नहीं हुआ, और कभी-कभी तो दोनों एक-दूसरे से टकराते हुए भी लगते हैं

  • यहाँ builder pattern और decorator दिख रहे हैं। Python में भी decorators होते हैं, लेकिन मेरा मानना है कि उन्हें functions या methods पर लागू होने वाले “filters” की तरह इस्तेमाल करना सबसे सही है। जैसे: इस function को cache करो, इस function के output को हमेशा serialize करो, या इस function को agent-style execution engine के tool के रूप में तैयार करो
    मेरा नहीं मानना कि इन्हें registration या flow control के लिए इस्तेमाल करना चाहिए। आप असहमत हो सकते हैं, लेकिन किसी न किसी को यह कहना था। FastAPI ने modern decorator usage को बहुत ज़्यादा गलत दिशा में खींच दिया है
    builder pattern, Rust में named keyword arguments न होने की वजह से बनी एक परंपरा के ज़्यादा करीब है, और Python functions पहले से ही named contract expose करते हैं। configuration parameters को chain किए गए method calls के जरिए क्रम से पास करने की लगभग कोई वजह नहीं है
    अगर constructor या factory में अभी मौजूद न होने वाली state जोड़नी है, तो वह builder pattern नहीं बल्कि registration है। builder pattern को स्वीकार करने लायक जगह शायद query builder जैसी चीज़ें हैं। वहाँ concepts को बार-बार परतों में जोड़ा जाता है, और method names तथा keyword arguments जैसे metadata slots वास्तव में उपयोगी होते हैं। keyword arguments की जगह single parameter लेने वाले methods का इस्तेमाल करना मुझे गलत लगता है

    • यहाँ decorator खास तौर पर functions पर metadata जोड़कर उन्हें reusable components बनाते हैं, और builder workflow बनाता है। Hamilton में सब कुछ शुद्ध declarative composition है, इसलिए सब decorators से संभाला जाता है, लेकिन reusability दरअसल अलग मुद्दा है
    • builder pattern सिर्फ Rust में ही इस्तेमाल नहीं होता, लेकिन Python में इसका इस्तेमाल बदसूरत लगता है — इस बात से मैं सहमत हूँ

  • यह काफ़ी भोला-भाला version लगता है कि reliable AI agent आखिर होता क्या है
    reliability का मतलब है “क्या यह सौंपा गया काम पूरा कर सकता है”, इसका state machine से कोई खास संबंध नहीं है

  • Burr का नाम पहली बार सुन रहा हूँ, सोच रहा हूँ कि इसे Apache में incubation क्यों मिला

    • ऐसा न होने की कोई वजह नहीं है। ASF का नए free open source projects को incubate करने का लंबा इतिहास रहा है
      उनमें से कुछ graduate होकर ऐसे नाम बन जाते हैं जिन्हें हर कोई जानता है, और कुछ असफल होकर attic में चले जाते हैं। ASF organizational support देता है और आम तौर पर अच्छे समुदाय विकसित करने में मदद करता है
    • क्योंकि मैंने ही इसे submit किया था। Apache process सीखने और साथ में दूसरे काम करने की वजह से यह धीमी प्रक्रिया थी, लेकिन अब इसमें कुछ momentum आ गया है और हम अधिक नियमित releases शुरू कर रहे हैं

  • यह पेज Claude Code से बनाई गई किसी disposable बेकार चीज़ जैसा दिखता है, और JavaScript के बिना चलाने की कोशिश भी नहीं करता। कम से कम brand consistency तो है

  • नाम की स्पष्ट वजह तो नहीं मिली, लेकिन जिज्ञासु लोगों के लिए यहाँ Hamilton example है: https://github.com/apache/burr/tree/main/examples/multi-agen...

    • Burr का नाम अमेरिका के founding fathers में से एक, तीसरे उपराष्ट्रपति, और Alexander Hamilton के हत्यारे तथा राजनीतिक प्रतिद्वंद्वी Aaron Burr के नाम पर रखा गया है
      Hamilton से इसका संबंध यह है कि DAGWorks ने Hamilton library के बाद इसे अपनी दूसरी open source library के रूप में जारी किया। यह नाम इस कल्पना से आया कि अगर Burr और Hamilton ने तालमेल बिठाया होता और मतभेदों से ऊपर उठकर बेहतर संघ बनाया होता, तो क्या होता
      मूल रूप से Burr को Hamilton DAG executions के बीच state संभालने के लिए बनाया गया था। DAG में cycle नहीं होते। बाद में एहसास हुआ कि इसका उपयोग-क्षेत्र इससे कहीं व्यापक है, इसलिए इसे और व्यापक रूप से जारी किया गया
      https://pypi.org/project/burr/

  • सोच रहा हूँ कि coding agents के लिए कोई orchestration tool या platform ऐसा है जिसकी आप सिफारिश करें। मैं कई machines पर codex या claude agents को चलाना, manage करना और monitor करना चाहता हूँ
    अगर संभव हो तो self-hosted हो या open source हो, तो अच्छा रहेगा। पता है कि claude code के अंदर ऐसी कई क्षमताएँ हैं, लेकिन वह claude-specific है

    • docs देखने पर लगता है कि Burr में इसे शुरू करने के लिए agent cookbook है, और यह multi-machine workflows भी संभाल सकता है। सोच रहा हूँ कि शायद आप यही ढूँढ़ रहे थे
      skills वगैरह के साथ इसे कैसे integrate किया जाता है, यह पूरी तरह स्पष्ट नहीं है, लेकिन देखने में लगता है कि यह काम कर सकता है
      https://burr.apache.org/docs/examples/agents/