सब कुछ एक फ़ाइल है: यूनिक्स से एआई एजेंट के डिज़ाइन दर्शन तक
सब कुछ एक फ़ाइल है: यूनिक्स से एआई एजेंट के डिज़ाइन दर्शन तक\n\nमूल लेखक: एथन येचेंग\n\n
\n\n## आधी सदी से गूंज\n\n1970 के दशक की शुरुआत में बेल लैब्स में, यूनिक्स के जनक केन थॉम्पसन और डेनिस रिची ने पहली बार एक साहसिक और लगभग कट्टरपंथी डिज़ाइन सिद्धांत प्रस्तावित किया: सब कुछ एक फ़ाइल है।\n\nआज, पचास साल बाद, एआई एजेंट फ्रेमवर्क में तेजी आई है। Manus, Claude Code, OpenClaw... वे अलग-अलग टीमों, अलग-अलग तकनीकी स्टैक और अलग-अलग व्यावसायिक लक्ष्यों से आते हैं, लेकिन उन्होंने एक ही विकल्प चुना है: फ़ाइल सिस्टम को एजेंट के संज्ञानात्मक ढांचे के रूप में उपयोग करना।\n\nManus एजेंट को एक वर्चुअल मशीन देता है, और कार्य उत्पाद को फ़ाइल के रूप में डिस्क पर सहेजा जाता है। Claude Code सीधे उपयोगकर्ता के स्थानीय फ़ाइल सिस्टम पर पढ़ता और लिखता है, और सभी निर्देशों और संदर्भों को CLAUDE.md फ़ाइल में रखता है। OpenClaw जैसे ओपन-सोर्स फ्रेमवर्क भी कार्य अपघटन और मध्यवर्ती स्थिति को व्यवस्थित करने के लिए निर्देशिका संरचना का उपयोग करते हैं।\n\nजब आधी सदी के अलग-अलग इंजीनियर, पूरी तरह से अलग तकनीकी समस्याओं का सामना करते हैं, तो स्वतंत्र रूप से एक ही समाधान पर अभिसरण करते हैं - यह कोई संयोग नहीं है, यह डिज़ाइन दर्शन का प्रतिध्वनि है।\n\n## यूनिक्स का वह निर्णय\n\nइस मामले के महत्व को समझने के लिए, हमें पहले यह देखना होगा कि यूनिक्स ने क्या किया।\n\nयूनिक्स फ़ाइल सिस्टम के डिज़ाइन को कंप्यूटर विज्ञान के इतिहास में सबसे सुरुचिपूर्ण डिज़ाइनों में से एक माना जाता है। इसने एक अत्यंत जटिल समस्या को हल किया: विभिन्न प्रकार के हार्डवेयर संसाधनों और डेटा संसाधनों को प्रबंधित करने के लिए एक एकीकृत, सरल इंटरफ़ेस का उपयोग कैसे करें।\n\n1970 के दशक से पहले, ऑपरेटिंग सिस्टम इस तरह काम करते थे: यदि आप डिस्क पढ़ना चाहते हैं, तो डिस्क इंटरफ़ेस को कॉल करें; यदि आप टेप पढ़ना चाहते हैं, तो टेप इंटरफ़ेस को कॉल करें; यदि आप टर्मिनल तक पहुंचना चाहते हैं, तो टर्मिनल इंटरफ़ेस को कॉल करें। प्रत्येक डिवाइस का अपना API होता है, और प्रत्येक API का अपना अर्थ होता है। यदि आपके पास N प्रकार के डिवाइस और M प्रकार के ऑपरेशन हैं, तो सिस्टम की जटिलता N × M है।\n\nथॉम्पसन और रिची ने एक ऐसा काम किया जो देखने में सरल और मूर्खतापूर्ण था:\n\nसब कुछ फ़ाइल में बदल दें। सब कुछ संचालित करने के लिए open, read, write, close चार क्रियाओं का उपयोग करें।\n\nइसका मूल अर्थ है: ऑपरेटिंग सिस्टम में सभी संसाधन - दस्तावेज़, निर्देशिकाएँ, हार्ड ड्राइव, मोडेम, कीबोर्ड, प्रिंटर, और यहां तक कि नेटवर्क कनेक्शन और प्रक्रिया जानकारी - को बाइट्स की एक फ़ाइल स्ट्रीम के रूप में अमूर्त किया जा सकता है।\n\nइसका मतलब है कि आपको केवल एक API सेट सीखना होगा - open(), read(), write(), close() - कंप्यूटर के सभी संसाधनों को संचालित करने के लिए।\n\nतब से, जटिलता N × M से घटकर 4 × 1 हो गई। चार क्रियाएँ, एक अमूर्त परत।\n\nइस मामले की प्रतिभा - स्थायी स्मृति **: LLM का संदर्भ विंडो अस्थिर है, और सत्र के साथ विचार श्रृंखला गायब हो जाती है। यह प्रक्रिया से बाहर निकलने के बाद मेमोरी को रीसायकल करने जैसा है - आपको मध्यवर्ती स्थिति को बनाए रखने के लिए एक जगह की आवश्यकता है, अन्यथा प्रत्येक वार्तालाप शुरू से शुरू होगा।
- ** क्रमिक संदर्भ **: जटिल कार्यों को एक ही चरण में पूरा नहीं किया जा सकता है। एजेंट को कई दौर के तर्क में धीरे-धीरे संदर्भ जमा करने की आवश्यकता होती है, जैसे कि यूनिक्स प्रक्रिया कई निष्पादन के बीच स्थिति को पारित करने के लिए फ़ाइलों को पढ़कर और लिखकर करती है। फ़ाइल सिस्टम स्वाभाविक रूप से इस "थोड़ा लिखें, थोड़ा पढ़ें, फिर थोड़ा लिखें" क्रमिक कार्य मोड प्रदान करता है।
- ** उपकरण और कौशल का एकीकृत शेड्यूलिंग **: एजेंट को खोज, कोड निष्पादन, छवि पीढ़ी और अन्य विषम उपकरणों (Tools/Skills) को कॉल करने की आवश्यकता होती है, जैसे कि यूनिक्स को डिस्क, नेटवर्क, प्रिंटर और अन्य विषम उपकरणों का प्रबंधन करने की आवश्यकता होती है। आपको एक एकीकृत अमूर्तता की आवश्यकता है, अन्यथा प्रत्येक नए उपकरण को कनेक्ट करने के लिए आपको एक नया एकीकरण तर्क लिखना होगा।
- ** कंप्यूटर उपयोग की अनुमति सीमाएँ **: जब एक एजेंट के पास कंप्यूटर को संचालित करने की क्षमता होती है, तो "यह क्या छू सकता है और क्या नहीं छू सकता है" एक जीवन और मृत्यु का मामला बन जाता है। यूनिक्स का फ़ाइल अनुमति प्रणाली (rwx) ठीक एक तैयार सैंडबॉक्स मॉडल प्रदान करता है - निर्देशिका सीमा है, और अनुमति एक अनुबंध है।
चार आवश्यकताएँ। परिचित लगता है?
यह ठीक वही है जो ऑपरेटिंग सिस्टम ने 1970 के दशक में सामना किया था।
स्थायी स्मृति - फ़ाइल सिस्टम स्वाभाविक रूप से हल करता है, लिखना स्थायी है। क्रमिक संदर्भ - निर्देशिका संरचना स्वयं वृद्धिशील रूप से निर्मित होती है, mkdir, touch, append, संदर्भ फ़ाइल के साथ बढ़ता है। उपकरण का एकीकृत शेड्यूलिंग - यूनिक्स पाइप का सार: एक प्रक्रिया का stdout दूसरी प्रक्रिया का stdin है, और मध्यवर्ती माध्यम बाइट स्ट्रीम है। एजेंट का उपकरण श्रृंखला भी ऐसा ही है: पिछले चरण का आउटपुट फ़ाइल अगले चरण का इनपुट है। अनुमति सीमाएँ - फ़ाइल सिस्टम की rwx अनुमति, chroot सैंडबॉक्स, स्वाभाविक रूप से एजेंट के लिए एक "क्षमता सर्कल" को परिभाषित करती है।
इसलिए जब एक एजेंट फ़्रेमवर्क के डिजाइनर को "एजेंट की कार्य स्थिति कहाँ रखें" की समस्या का सामना करना पड़ता है, तो उत्तर लगभग पूर्वनिर्धारित होता है: इसे फ़ाइल सिस्टम में रखें। क्योंकि कोई भी सरल समाधान एक ही समय में इन चार बाधाओं को पूरा नहीं कर सकता है।
जब सिस्टम को "बड़ी संख्या में विषम संसाधनों की बातचीत का प्रबंधन" करने की आवश्यकता होती है, तो आपके पास दो रास्ते हैं:
मार्ग A: प्रत्येक संसाधन के लिए एक समर्पित इंटरफ़ेस डिज़ाइन करें। N संसाधनों × M संचालन = NM इंटरफ़ेस। सटीक लेकिन विस्फोटक।
मार्ग B: एक पर्याप्त पतली अमूर्तता खोजें, ताकि सभी संसाधन एक ही कपड़े पहन सकें। 4 संचालन × 1 अमूर्तता। खुरदरा लेकिन संयोजन योग्य।
यूनिक्स ने B को चुना। पचास से अधिक वर्षों के बाद, एजेंट फ़्रेमवर्क ने फिर से B को चुना।

एक गहरी परत: फ़ाइलें सोच का बाह्यकरण हैं
लेकिन अगर हम केवल "तकनीकी समाधान के अभिसरण" पर रुकते हैं, तो हम अधिक आवश्यक चीज़ों को याद करेंगे।
याद रखें कि मनुष्य स्वयं जटिल कार्यों को कैसे संभालते हैं।
आपको एक बड़ी परियोजना मिलती है, पहली बात जो आप करते हैं वह काम करना शुरू करना नहीं है, बल्कि: फ़ोल्डर बनाना है। परियोजना रूट निर्देशिका, उप-कार्य निर्देशिका, संदर्भ सामग्री निर्देशिका, आउटपुट निर्देशिका। आप अराजक कार्य को प्रबंधनीय इकाइयों में विघटित करने के लिए निर्देशिका संरचना का उपयोग करते हैं। आप प्रत्येक इकाई को नाम देने के लिए फ़ाइल नाम का उपयोग करते हैं। आप फ़ाइल सामग्री का उपयोग विचार प्रक्रिया और मध्यवर्ती उत्पादों को रिकॉर्ड करने के लिए करते हैं।
फ़ाइल सिस्टम केवल एक भंडारण समाधान नहीं है। यह मानव बाह्यकरण सोच के लिए एक मूल उपकरण है।
यह अंतर्दृष्टि बताती है कि एजेंट फ़्रेमवर्क फ़ाइल सिस्टम में क्यों परिवर्तित होता है: LLM की "सोच" को बाह्यकरण की आवश्यकता होती है - इसकी संदर्भ विंडो सीमित है, और लंबी दूरी के तर्क को बाहरी स्मृति पर निर्भर रहना चाहिए। और फ़ाइल सिस्टम ठीक वही है जो मनुष्यों ने सबसे आम "बाहरी स्मृति" प्रारूप का आविष्कार किया है।
इस दृष्टिकोण से, Claude Code का CLAUDE.md एक कॉन्फ़िगरेशन फ़ाइल नहीं है। यह एक बाह्यीकृत संज्ञानात्मक अनुबंध है - मनुष्य इरादे को एक फ़ाइल के रूप में लिखते हैं, और एजेंट फ़ाइल को इरादे के रूप में पढ़ता है। फ़ाइल मानव मन और कृत्रिम बुद्धिमत्ता के बीच एक इंटरफ़ेस परत बन जाती है।
यह यूनिक्स पाइप के दर्शन के साथ आश्चर्यजनक रूप से सुसंगत है:
टेक्स्ट स्ट्रीम को संभालने के लिए प्रोग्राम लिखें, क्योंकि यह एक सार्वभौमिक इंटरफ़ेस है।把"programs"换成"agents",把"text streams"换成"files",这句话在 2026 年依然成立।
पहली सिद्धांतों पर वापस
महान अमूर्तताएँ पुरानी नहीं होतीं, वे केवल नए क्षेत्रों में नए उदाहरण पाती हैं।
"एकीकृत इंटरफ़ेस जटिलता को हल करता है" यूनिक्स का आविष्कार नहीं है, यह सिस्टम डिज़ाइन का शाश्वत नियम है। यूनिक्स ने संयोग से इसे "फ़ाइल" नाम से लागू किया। AI Agent ने संयोग से इसे "कार्यशील निर्देशिका" के रूप में फिर से लागू किया।
अगली पीढ़ी के सिस्टम को भी उसी विकल्प का सामना करना पड़ेगा: प्रत्येक चीज़ के लिए समर्पित इंटरफ़ेस डिज़ाइन करें, या एक पतली, सामान्य, संयोज्य अमूर्तता खोजें?
यदि इतिहास से कोई सबक मिलता है, तो उत्तर पहले से ही /dev/null के बगल में लिखा हुआ है:
Keep it simple. Make it compose. Everything is a file. (इसे सरल रखें। इसे संयोजित करें। सब कुछ एक फ़ाइल है।)





