Claws अब LLM एजेंट्स के ऊपर जोड़ी गई एक नई लेयर है

• LLM के ऊपर एजेंट्स जुड़ने के बाद, उनके ऊपर orchestration·scheduling·context management·tool calling·persistence संभालने वाली Claws लेयर उभरी है
• एजेंट की execution structure को एक स्तर और abstract करके उच्च-स्तरीय automation और configurability हासिल की जाती है
• OpenClaw लगभग 4 लाख lines of code के पैमाने पर बना है, और personal data तथा keys को delegate करने वाली संरचना को लेकर चिंताएँ मौजूद हैं
• exposed instances की रिपोर्ट, RCE vulnerability, supply chain contamination, registry में malicious या corrupted skills जैसे कई security risks सामने आए हैं
• मौजूदा ecosystem लगभग ‘wild west’ जैसा है और security nightmare के करीब का माहौल है

• NanoClaw लगभग 4,000-line core engine के साथ तुलनात्मक रूप से छोटा ढाँचा है
  • कोड इतना छोटा है कि उसे दिमाग में समेटा जा सके, इसलिए management·audit·flexibility के लिहाज़ से फ़ायदेमंद है
• डिफ़ॉल्ट रूप से सभी executions container environment में चलाए जाते हैं
• configuration files की जगह skills के ज़रिये configuration अपनाया गया है
  • /add-telegram कमांड एजेंट को बताता है कि वास्तविक कोड में बदलाव कैसे करने हैं
  • जटिल configuration files और conditional branching structure को कम करने वाला एक नया AI-आधारित approach
• ऐसा repository बनाना जिसे अधिकतम आसानी से fork किया जा सके, और skills द्वारा उसे अलग-अलग configurations में बदलने की meta strategy शानदार है

• nanobot, zeroclaw, ironclaw, picoclaw जैसे कई variant projects सामने आए हैं
• cloud hosting alternatives भी मौजूद हैं, लेकिन local environment experiment और expansion के लिए अधिक अनुकूल है
  • local network-आधारित home automation devices से जुड़ना भी आसान है
• physical devices पर चलने वाले personal digital agent की वैचारिक आकर्षण

• Claws AI stack की नई लेयर के रूप में जगह बना रहा है और एजेंट्स के बाद के चरण की संरचना को परिभाषित कर रहा है
• मेरी ठोस final configuration अभी तय नहीं है, लेकिन एक experimental और scalable structure के रूप में इससे काफ़ी उम्मीदें हैं

[xguru]

NanoClaw – Apple कंटेनर आइसोलेशन environment में चलने वाला 500 लाइनों का TypeScript-आधारित Claude assistant

जब यह सार्वजनिक हुआ था तब 500 लाइनें थीं, लेकिन अब लगता है कि यह 4000 लाइनों का हो गया है ??

[GN⁺]

Hacker News की रायें

• कई टिप्पणियों में व्यक्तिगत हमले पाए गए, इसलिए उन्हें हटा दिया गया
  HN में राय अलग हो सकती है, लेकिन व्यक्तिगत हमला बिल्कुल मना है। क्योंकि यह साइट के उद्देश्य को नुकसान पहुंचाता है
  अगर आपने हाल में guidelines नहीं पढ़ी हैं, तो उन्हें फिर से ज़रूर देखना चाहिए

  • कोई व्यक्तिगत हमला नहीं था, बस उसी फीचर को बार-बार rebranding करने पर नाराज़गी थी। असली innovation नहीं है, इसलिए लोग गुस्सा होते हैं। अगर REST API के शुरुआती दौर में ऐसा हुआ होता, तब भी यही गुस्सा होता

• security के नज़रिए से देखें तो Claw रखना किसी मानव assistant या consultant रखने जैसा है
  जैसे आप अपनी निजी email या bank account की access नहीं देते, वैसे ही अलग email और सीमित corporate card देकर सेटअप करना चाहिए

  • लेकिन politicians या executives के लिए assistants का email या SNS संभालना आम बात है
    bank account न दें, फिर भी accountant या financial advisor को access देना कुछ मामलों में होता है

• जब मैं CLI-आधारित agent tool बना रहा था, तब मैंने एक safety mechanism डाला था
  खतरनाक कामों के लिए, जैसे bulk email भेजना, one-time password (OTP) ज़रूरी हो
  tool agent से कहता है कि user से OTP मांगे, और input के बिना आगे नहीं बढ़ सकता
  मैंने अभी Claw इस्तेमाल नहीं किया है, लेकिन मुझे लगता है कि इस तरह की human-in-the-loop संरचना ज़रूरी है
  इसलिए मैं सारे agent CLI खुद बनाता हूँ ताकि control ज़्यादा रहे

  • आजकल computing कुछ Sim City जैसी हो गई है, जहाँ बस धुंधली-सी योजना बनाओ और उम्मीद करो कि system खुद ठीक से चल जाएगा। लगता है predictable rules की खूबसूरती खो गई है
  • एक और तरीका corporate approval process की नकल करना है। अहम कामों के लिए अलग approver हो, और agent उसे message भेजकर approval ले। यह OTP की जगह approval channel पर भरोसा करने का तरीका है
  • लेकिन सवाल यह है कि “बहुत ज़्यादा लोगों को email नहीं भेजना चाहिए” जैसे नियम को कैसे enforce किया जाए
  • मैं fly.io पर अपना Claw खुद चला रहा हूँ। email, Slack message आदि जैसे जिन कामों में human intervention चाहिए, उन्हें ‘activity’ के रूप में अलग किया जाता है, लिंक बनता है, और मेरी approval के बाद ही वे चलते हैं
  • मैंने internal LLM और external permission orchestration layer वाला एक version बनाया है। मुझे नहीं लगता OTP ज़रूरी है। बाहरी layer मुझे Signal पर notification भेजती है, और मैं हर बार decide करता हूँ कि approve करना है या नहीं

• अगर Claw पहले से मौजूद होता, तो शायद इंटरनेट अलग होता
  साधारण Gopher protocol आधारित menu-structure शायद LLM के लिए ज़्यादा उपयुक्त होती
  आगे अगर user-side agent-केंद्रित interaction बढ़ते हैं, तो शायद चीज़ें उस दिशा में evolve करें

  • ऐसा future हमें खुद बनाना होगा। एक ऐसी दुनिया जहाँ सारी services सिर्फ API के रूप में मौजूद हों, और मेरा agent उन्हें जोड़कर दे
    YouTube, Gmail, HN, bank, power company तक सब कुछ API हो, तो user अपनी पसंद से interface बना सकेगा
    companies इसका विरोध करेंगी क्योंकि उनका monopoly टूटेगा, लेकिन technology कम profitable और ज़्यादा valuable हो जाएगी
  • 1992 के आसपास, IMG tag से पहले के दौर में, मैंने foo-www, foo-http जैसे DNS pairs बनाकर experiment किया था
    जब CGI proposal आया, मैंने सोचा था “इसे कोई इस्तेमाल नहीं करेगा”, लेकिन आखिर सबने वही spec implement किया। उस समय की शुरुआती flexibility खोना अफसोस की बात है
  • MCP पहले से उसी दिशा में जा रहा है। यह ऐसा ढांचा है जहाँ LLM text के ज़रिए services तक पहुँचता है
    मैं Telegram से अपने Mac के OpenClaw instance से बात करता हूँ। यानी मैं पहले ही app UI की जगह एक नया interface इस्तेमाल कर रहा हूँ
    इंसानों के देखने वाले windows के बजाय agent-centric interface बनाना, और सिर्फ verification interface छोड़ना, ज़्यादा तर्कसंगत लगता है
  • technical रूप से हर website API दे सकती है, लेकिन incentive problem की वजह से ज़्यादातर ऐसा नहीं चाहतीं। जैसे Google Search API का मामला
  • शायद Claw पहले से मौजूद हो ही नहीं सकता था। LLM training data WWW के फैलाव की वजह से बना, और वह infrastructure न होता तो large-scale training ही संभव नहीं होती

• Claw की असली बात यह है कि यह user-centric agent है
  लोगों को जिस AI से नफरत है, वह company-controlled AI है। Claw ऐसा कुछ है जो user own करता है, यहाँ तक कि उसे नाम भी देता है
  यह R2D2 जैसे साथी और आपको सामान बेचने की कोशिश करने वाले robot replicant के बीच का फर्क है

  • सहमत। OS vendors जैसे मौजूदा ताकतवर खिलाड़ी इस तरह के user-centric model को कुछ हद तक chaos झेलने के बाद ही अपने products में integrate करने की कोशिश करेंगे
  • लेकिन यह “user” कौन है, इस पर निर्भर करता है। वह जिसने agent शुरू किया, या वह जो उससे interact करता है? दूसरा व्यक्ति victim भी हो सकता है

• मैं सोच रहा था कि “Claw” आखिर है क्या।
  क्या यह ऐसा AI है जिसे email जैसी personal data की access दी जाती है?
  अगर इसे container के अंदर local LLM के साथ चलाएँ, तो क्या यह safe होगा?

  • मेरी नज़र में यह personal digital assistant का नया रूप है।
    • व्यक्ति खुद इस्तेमाल करे
    • code execute कर सकने वाली terminal access
    • chat app integration
    • schedule execution capability
    • email, calendar, file जैसी sensitive data access
      इसे consumer hardware या VPS कहीं भी चलाया जा सकता है। एक नया market खुल रहा है
  • मेरे लिए यह कुछ cron-for-agents जैसा है, जो तय schedule पर चलता है, inbox check करता है, और अपने-आप काम निपटाता है
    यह asynchronous तरीके से मेरी credentials इस्तेमाल करके काम करता है। साधारण है, लेकिन दिलचस्प
  • लेकिन container में चलाने भर से मूल जोखिम खत्म नहीं हो जाता
  • किसी ने व्यंग्य में Claw को बस “AI trend से पीछे नहीं रहना चाहते हुए लापरवाही से खुद को expose कर देने की मानसिक अवस्था” कहा
  • technical रूप से देखें तो Claw एक “queue में agent” है। यानी LLM और tools loop बनाते हैं, और वे loops queue के ज़रिए जुड़े होते हैं

• मेरा summary: OpenClaw का security risk 5/5 है
  पूरी तरह audited NanoClaw भी शायद 4/5 होगा
  human intervention हो तो बेहतर है, लेकिन utility तेज़ी से घट जाती है
  LLM language specs या test-based guardrail generation में अच्छे हैं, लेकिन मेरे हिसाब से stability ज़्यादा महत्वपूर्ण है

• लगता है “Claw” नाम OpenClaw जैसे personal AI agents के लिए एक स्थिर शब्द बन जाएगा

  • terminology के viral spread को देखना दिलचस्प है। बाद में trademark issues पर lawyers का सिरदर्द बढ़ सकता है। WordPress ecosystem के “press” की तरह

• आजकल agent workflow का trend security boundary की गैरमौजूदगी जैसी बुनियादी समस्या को नज़रअंदाज़ करता है
  अगर LLM के पास unrestricted shell access हो और वह untrusted data लाए, तो indirect prompt injection से बचा नहीं जा सकता
  साथ ही अगर बहुत बड़े system prompt और tool schema को context में ठूँस दिया जाए, तो model की बुनियादी reasoning क्षमता घटती है और vulnerability बढ़ती है

  • असल में सबको यह risk पता है, लेकिन convenience इतनी बड़ी है कि लोग इसे स्वीकार कर रहे हैं
  • Information Flow Control आदर्श है, लेकिन integrated channels के protocols बदले बिना इसे लागू करना असंभव है
  • क्या कोई इससे जुड़ी research share कर सकता है?

• GTA VI से पहले ही store-brand Claw आ गया
  खुद बनाकर देखा तो 50 lines of code काफी थीं
  Telegram library की कुछ lines और claude -p prooompt ही काफी है
  ULTRON example code देखा जा सकता है
  बेशक agent को बाहर delegate किया जाता है, लेकिन Bash की 50 lines से भी लगभग perfect result मिल सकता है

  • लेकिन असली Claw की तरह इस्तेमाल करने के लिए cron जोड़ना पड़ेगा