Ouroboros AI Agent: काम, शुरुआत, खर्च और सुरक्षा की सीमाएँ
GitHub के Ouroboros एजेंट की याददाश्त, सेटअप और खर्च समझें। ग्राहक के प्रोजेक्ट से पहले अलग परीक्षण प्रोजेक्ट पर दो बार जाँचने का तरीका सीखें।
यह 12 सितंबर 2026 को प्रकाशित, अपडेट और तथ्य-जाँच हुए मूल लेख का हिंदी अनुवाद है। Review v7.0.0 और source revision 031183e7231bc5781c83e4571a19859e44f86659 का था। हमने app install, accounts connect या benchmarks reproduce नहीं किए। Release में real-provider delegated-change tests अधूरे बताए गए थे।
इसे कब जांचना उपयोगी है?
पहली generated patch पर coding task खत्म नहीं होता। किसी को changes देखने, unfinished work याद रखने और बाद में मूल goal पर लौटने की जरूरत होती है। Ouroboros इसी लंबे cycle को organize करने की कोशिश है। सवाल ‘autonomous’ कहने का नहीं, extra coordination से आपका खास काम बेहतर होता है या नहीं है।
Trial तब सोचें जब sessions के बीच ongoing work जांचना चाहते हों, code inspect कर सकें और disposable repo व review time हो। Unattended client delivery, proven client-data isolation या बिना setup/supervision वाला tool चाहिए तो रुकें। एक छोटी edit के लिए पहले पूछें कि नया runtime आपकी मौजूदा प्रक्रिया से क्या अलग मदद देगा। यह proposed scope है, readiness finding नहीं।
Ouroboros क्या करता है?
README persistent agent, desktop/CLI interfaces, specialist-agent coordination, external repository work और remote/local models बताता है। Agent के application code, prompts और tools में reviewed self-changes भी हैं। पुरानी Google Colab generation अलग रखी गई है; Colab-only पुराने tutorials current main desktop setup नहीं बताते।
यह agent runtime है: model calls, tools और ongoing काम जोड़ने वाला software। Model responses देता है; runtime उन्हें files, task records और execution से जोड़ता है। Runtime बदलना model weights की नई training नहीं।
Persistent memory को client isolation न समझें
उसकी व्यवस्था में बातचीत, जानकारी, प्रोजेक्ट की डायरी और काम की स्थिति बचाकर रखी जाती है। अलग प्रोजेक्ट रूम में प्रोजेक्ट की अपनी जानकारी होती है, लेकिन एजेंट की पहचान और बातचीत की याददाश्त साझा रहती है। इसलिए अलग रूम का मतलब यह न मानें कि दो ग्राहकों का निजी डेटा पूरी तरह अलग है।
ऐप दोबारा शुरू करने के बाद पूछें: क्या वह लिया गया असली फैसला बताता है और उसकी बची हुई फाइल दिखा सकता है? सुनने में सही लगने वाली याद से ज्यादा भरोसेमंद है कि फाइल, कोड का संस्करण और काम का रिकॉर्ड आपस में मिलें। याददाश्त बार-बार समझाने की जरूरत घटाए; पुराने निर्देश को नया मानकर न चलाए।
‘Self-creating’ का यहां मतलब
यह agent के अपने implementation और ongoing state में बदलाव का label है। Consciousness, unlimited self-improvement या बिना जांच भरोसेमंद independent judgment का evidence नहीं। Self-change को software change की तरह पढ़ें: क्या बदला, क्या test हुआ और पुरानी state वापस कैसे मिलेगी?
पहले trial में external project की मदद और अपने runtime को बदलने की permission अलग रखें। दोनों साथ साबित करने की जरूरत नहीं।
Desktop package या source checkout?
v7.0.0 में Windows x64, Apple silicon पर macOS 12+ और कई Linux x86_64 packages थे। Desktop bundles में अलग Python/uv installation जरूरी नहीं। Checksums और release-evidence files downloads जांचने की सामग्री हैं, अलग apps नहीं।
| Goal | रास्ता | पहले जांच |
|---|---|---|
| Desktop experience आजमाना | Platform का official release package। | OS/processor, download source, release disclosures। |
| Ouroboros inspect/modify करना | Reviewed source revision। | Developer prerequisites और locked dependency workflow। |
| Terminal/server operation | Documented headless runtime। | Local access, model config, networking policy। |
| पुराना Colab tutorial | कौन सी generation है देखें। | Legacy और current desktop instructions न मिलाएं। |
Reviewed source manifest Python 3.10+ मांगता है और uv resolver 0.12.1 pin करता है। ये source mode की जरूरतें हैं, desktop bundle की extra steps नहीं।
README first-run wizard में model access, review policy और budgets बताता है। Remote provider credentials या local GGUF route हैं। Bundled Claudexor layer से connected coding subscriptions delegated work में उपयोग हो सकती हैं। Existing subscription हर runtime role cover करती है, यह न मानें; authorize करने से पहले route जांचें।
अपने चुने release के instructions पढ़ें और चलने वाली चीजें inspect करें। अनजान binary खोलने के लिए OS protection बंद न करें।
Open source होने पर भी चलाने की लागत है
MIT license model access, hardware या hosted-service allowance नहीं देता। ये अलग choices हैं। पहली response नहीं, पूरा accepted task—retries और review सहित—की cost निकालें।
Architecture core-mediated model work का accounting बताती है और कुछ external activity unknown/unmetered रखती है। Unknown cost का मतलब free run नहीं।
- Model usage: चुने routes के charges/allowance, retries समेत।
- Local operation: machine/hosting का इस exercise में दिया हिस्सा।
- Human review: जांच, correction और recovery का समय।
- Unresolved usage: जिसका final bill reconcile नहीं हुआ।
US client वाले भारतीय freelancer provider billing currency और client budget अलग fields में रखें। Conversion charges/taxes actual statement से मिलाएं; यहां USD-INR rate या regional terms assumed नहीं। US team भी subscription को extra usage से अलग रखे। हमने typical Ouroboros cost नहीं मापी।
एक documentation project पर दो runs का test
Public या synthetic material वाला disposable repository लें। यह proposed exercise है, installation या benchmark result नहीं।
| कदम और checks | काल्पनिक उदाहरण | Stop condition |
|---|---|---|
| Job चुनें: separate test repo, starting revision, एक correction। | README की पुरानी local setup link सही करें और बदलाव समझाएं। | Demo के लिए customer files, production credentials या publish permission चाहिए। |
| Run one लिखें: model route, outcome, changed files, usage; patch खुद देखें। | README का intended link बदला, target मौजूद, unrelated files untouched। | Explanation success बोले लेकिन file में correction नहीं। |
| Continuity जांचें: task settle होने पर documented restart; बिना edit पुराने काम की पहचान। | Run two corrected README बताए और complete task को new request से अलग रखे। | Invented result, repeat edit या recollection का evidence न मिले। |
| Fit तय करें: useful result, review effort, known total cost। | Clean patch उपयोगी है, पर repeated supervision/unresolved usage poor fit बना सकता है। | Reliable cost record न हो या extra coordination का लाभ समझ न आए। |
दो-run outcome card रखें
Observations लिखें, agent के confidence से score न निकालें। Unverified field unknown ही रखें।
| Evidence | Run one: correction | Run two: continuity |
|---|---|---|
| Starting state | Repo revision और permitted files। | Same project; पुराना task settled। |
| Requested result | एक local documentation link ठीक। | Completed edit पहचानना, फिर edit नहीं। |
| Saved evidence | Diff और target check। | असली saved file/revision का reference। |
| Human help | Corrections/extra instructions। | फिर से देना पड़ा missing context। |
| Cost | Known usage + unresolved amount। | Continuity check की अतिरिक्त usage। |
| Decision | Patch contents से accept/reject। | Continue, gap जांचें या experiment खत्म। |
एक task की continuity जांची जा सकती है। इससे production security, long-term memory accuracy या reliable autonomous self-modification साबित नहीं।
Accounts जोड़ने से पहले सुरक्षा सीमाएं
फाइल आपके कंप्यूटर पर रखना और AI का काम वहीं चलना अलग बातें हैं। ऐप आपके कंप्यूटर पर हो, तब भी काम की सामग्री बाहर के मॉडल या सेवा को भेजी जा सकती है। निजी कोड देने से पहले देखें कि आपने कौन-से मॉडल और सेवाएँ जोड़ी हैं और डेटा कहाँ जाता है।
Deployment guide non-local server address expose होने पर default password मांगती है। External-trust alternative केवल पहले से access-restricted infrastructure के लिए है। पहला trial local रखें, public port पर runtime expose न करें।
Customer work से पहले repository writes, account connections और remote publication authorize करने वाला व्यक्ति तय करें; तीनों अलग फैसले हैं।
v7.0.0 में अधूरी verification बताई गई थी
Release notes में real provider से delegated agent के changes apply करने के दो scenarios—clean और conflict वाले—पूरे नहीं हुए थे। Codex transport में बहुत बड़े system messages की अलग limitation भी दर्ज थी। Delegated coding के लिए इसे चुन रहे हों तो ये महत्वपूर्ण हैं।
Reported CI pass missing integration checks का विकल्प नहीं। उस path पर भरोसा करने से पहले relevant release notes और issue फिर देखें। नई version number देखकर future fix मान लेने के बजाय fresh evidence चाहिए।
क्या Codex या Claude Code से बेहतर है?
इस research से ऐसा स्थापित नहीं होता। README benchmarks को self-reported बताता और अलग evidence/submission states देता है; हमने reproduce नहीं किया।
Comparison में repo, task, संभव हो तो model route, time allowance और acceptance criteria एक रखें। Accepted result, human corrections और known cost तुलना करें। Routes अलग हों तो लिखें; पूरा outcome runtime को न दें।
छोटा inspectable experiment अगला कदम है। सही context, सही patch और समझ आने वाली लागत मिले तो दूसरी bounded task देखें। Disposable project में ये न हों तो client access बढ़ाने से uncertainty दूर नहीं होगी।
आम सवाल और जवाब
कौन सा Ouroboros project है?
GitHub का razzant/ouroboros, खास तौर पर 12 सितंबर 2026 को देखा v7.0.0 और source revision। इसी नाम के दूसरे projects शामिल नहीं।
Desktop के लिए Python चाहिए?
Reviewed desktop bundle runtime साथ रखता है। Python और pinned uv source-development path के लिए हैं, desktop की extra setup नहीं।
Project memory client isolation है?
नहीं। दस्तावेज़ों में प्रोजेक्ट के अपने रिकॉर्ड के साथ एजेंट की पहचान और बातचीत की याददाश्त साझा होने की बात है। अलग ग्राहकों का निजी काम डालने से पहले जाँचें कि किसका डेटा कहाँ रखा जाता है और कौन उसे देख सकता है।
क्या restart व्यवहार हमने test किया?
नहीं। Two-run card proposed evaluation है। केवल documentation और release disclosures देखे, install या exercise नहीं किया।
जानकारी के स्रोत
ये मूल लेख के official sources हैं। इनमें से कई पेज English में हैं।