ہر چیز ایک فائل ہے: یونکس سے لے کر اے آئی ایجنٹ کے ڈیزائن فلسفے تک

اصل مضمون نگار: ایتھن یی چینگ

cover_image

نصف صدی کی بازگشت

1970 کی دہائی کے اوائل میں بیل لیبز (Bell Labs) میں، یونکس کے بانی کین تھامپسن (Ken Thompson) اور ڈینس رچی (Dennis Ritchie) نے پہلی بار ایک جرات مندانہ اور تقریباً جنونی ڈیزائن اصول پیش کیا: ہر چیز ایک فائل ہے (Everything is a file)۔

پچاس سال سے زیادہ گزرنے کے بعد، آج کل اے آئی ایجنٹ فریم ورک کی بہتات ہے۔ Manus، Claude Code، OpenClaw... یہ مختلف ٹیموں، مختلف ٹیکنالوجی اسٹیکس اور مختلف تجارتی مقاصد سے آتے ہیں، لیکن سب نے متفقہ طور پر ایک ہی انتخاب کیا ہے: فائل سسٹم کو ایجنٹ کے علمی ڈھانچے کے طور پر استعمال کرنا۔

Manus ایجنٹ کو ایک ورچوئل مشین دیتا ہے، اور ٹاسک کی پیداوار فائلوں کی صورت میں ڈسک پر محفوظ ہوتی ہے۔ Claude Code براہ راست صارف کے مقامی فائل سسٹم پر پڑھتا اور لکھتا ہے، اور ایک CLAUDE.md فائل تمام ہدایات اور سیاق و سباق کو محفوظ کرتی ہے۔ OpenClaw جیسے اوپن سورس فریم ورک بھی ٹاسک کی تقسیم اور درمیانی حالت کو ڈائریکٹری ڈھانچے میں منظم کرتے ہیں۔

جب نصف صدی کے فاصلے پر موجود انجینئرز، مکمل طور پر مختلف تکنیکی مسائل کا سامنا کرتے ہیں، تو آزادانہ طور پر ایک ہی حل پر متفق ہو جاتے ہیں - یہ کوئی اتفاق نہیں ہے، یہ ڈیزائن فلسفے کی ہم آہنگی ہے۔

یونکس کا وہ فیصلہ

اس بات کی اہمیت کو سمجھنے کے لیے، پہلے یہ جاننا ضروری ہے کہ یونکس نے کیا کیا۔

یونکس فائل سسٹم کے ڈیزائن کو کمپیوٹر سائنس کی تاریخ کے سب سے بہترین ڈیزائنوں میں سے ایک سمجھا جاتا ہے۔ اس نے ایک انتہائی پیچیدہ مسئلہ حل کیا: مختلف ہارڈ ویئر وسائل اور ڈیٹا وسائل کو ایک متحد اور سادہ انٹرفیس کے ذریعے کیسے منظم کیا جائے۔

1970 کی دہائی سے پہلے، آپریٹنگ سسٹم اس طرح کام کرتے تھے: اگر آپ کو ڈسک پڑھنی ہے، تو ڈسک انٹرفیس کو کال کریں؛ اگر آپ کو ٹیپ پڑھنی ہے، تو ٹیپ انٹرفیس کو کال کریں؛ اگر آپ کو ٹرمینل تک رسائی حاصل کرنی ہے، تو ٹرمینل انٹرفیس کو کال کریں۔ ہر ڈیوائس کا اپنا API ہوتا تھا، اور ہر API کا اپنا معنی ہوتا تھا۔ اگر آپ کے پاس N قسم کے ڈیوائسز اور M قسم کے آپریشنز ہیں، تو سسٹم کی پیچیدگی N × M ہوگی۔

تھامپسن اور رچی نے ایک ایسا کام کیا جو بظاہر سادہ اور احمقانہ تھا:

ہر چیز کو فائل میں تبدیل کر دیں۔ ہر چیز کو چلانے کے لیے open، read، write، close چار افعال استعمال کریں۔

اس کا بنیادی مطلب یہ ہے کہ آپریٹنگ سسٹم میں موجود تمام وسائل - دستاویزات، ڈائریکٹریز، ہارڈ ڈرائیوز، موڈیم، کی بورڈ، پرنٹرز، یہاں تک کہ نیٹ ورک کنکشن اور عمل کی معلومات - کو بائٹس کے سلسلے (Stream of Bytes) کے طور پر خلاصہ کیا جا سکتا ہے۔

اس کا مطلب ہے کہ آپ کو صرف ایک API سیکھنے کی ضرورت ہے - open()، read()، write()، close() - اور آپ کمپیوٹر کے تمام وسائل کو چلا سکتے ہیں۔

اس کے بعد، پیچیدگی N × M سے کم ہو کر 4 × 1 ہو گئی۔ چار افعال، ایک تجرید۔

اس کام کی ذہانت "فائل" کے نام میں نہیں ہے، بلکہ ایک گہری بصیرت میں ہے:

آپ کو یہ جاننے کی ضرورت نہیں ہے کہ فائل ڈسکرپٹر کے پیچھے کیا ہے۔ انٹرفیس ہی معاہدہ ہے۔

ایک fd (فائل ڈسکرپٹر) ایک مبہم ہینڈل ہے۔ آپ اس پر read() کرتے ہیں، اور بائٹس کا سلسلہ نکلتا ہے۔ یہ بائٹس ہارڈ ڈرائیو سیکٹر، نیٹ ورک کارڈ بفر، یا کسی دوسرے عمل کے معیاری آؤٹ پٹ سے آتے ہیں - آپ کو اس کی پرواہ نہیں ہے، اور آپ کو پرواہ نہیں کرنی چاہیے۔

یہ متحد انٹرفیس کی طاقت ہے: یہ لاعلمی کو ایک فائدہ بناتا ہے۔

ایجنٹ کو درپیش ایک ہی سوال

اب اے آئی ایجنٹ کی صورتحال پر واپس آتے ہیں۔

ایک ایجنٹ کو ایک پیچیدہ کام مکمل کرنا ہوتا ہے، اور اسے 1970 کی دہائی کے آپریٹنگ سسٹم جیسی ہی حیران کن مشکل کا سامنا ہے:

مستقل مزاجی کی یادداشت**: LLM کا سیاق و سباق ونڈو غیر مستحکم ہے، اور سوچ کی زنجیر سیشن کے ساتھ ختم ہو جاتی ہے۔ بالکل اسی طرح جیسے عمل سے باہر نکلنے کے بعد میموری کو ری سائیکل کیا جاتا ہے - آپ کو درمیانی حالت کو مستقل کرنے کے لیے ایک جگہ کی ضرورت ہے، ورنہ ہر گفتگو صفر سے شروع ہو گی۔
تدریجی سیاق و سباق: پیچیدہ کام ایک قدم میں مکمل نہیں ہو سکتے۔ ایجنٹ کو استدلال کے متعدد دوروں میں بتدریج سیاق و سباق جمع کرنے کی ضرورت ہے، بالکل اسی طرح جیسے یونکس عمل فائلوں کو پڑھ اور لکھ کر متعدد عملوں کے درمیان حالت کو منتقل کرتا ہے۔ فائل سسٹم قدرتی طور پر اس "تھوڑا لکھیں، تھوڑا پڑھیں، پھر تھوڑا لکھیں" کام کرنے کا طریقہ فراہم کرتا ہے۔
ٹولز اور مہارتوں کا متحد شیڈول: ایجنٹ کو مختلف ٹولز (ٹولز/مہارتیں) جیسے تلاش، کوڈ پر عمل درآمد، اور تصویر کی تخلیق کو کال کرنے کی ضرورت ہے، بالکل اسی طرح جیسے یونکس کو مختلف آلات جیسے ڈسک، نیٹ ورک، اور پرنٹرز کا انتظام کرنا ہوتا ہے۔ آپ کو ایک متحد تجرید کی ضرورت ہے، ورنہ ہر نئے ٹول کو مربوط کرنے کے لیے آپ کو ایک نیا انضمام منطق لکھنا پڑے گا۔
کمپیوٹر کے استعمال کی اجازت کی حدود: جب ایجنٹ کے پاس کمپیوٹر چلانے کی صلاحیت ہوتی ہے، تو "وہ کیا چھو سکتا ہے اور کیا نہیں چھو سکتا" ایک اہم مسئلہ بن جاتا ہے۔ یونکس کا فائل پرمیشن سسٹم (rwx) بالکل تیار سینڈ باکس ماڈل فراہم کرتا ہے - ڈائریکٹری ایک حد ہے، اور اجازت ایک معاہدہ ہے۔

چار ضروریات۔ کیا یہ مانوس لگتا ہے؟

یہ بالکل وہی مسئلہ ہے جس کا سامنا آپریٹنگ سسٹم کو 1970 کی دہائی میں تھا۔

مستقل مزاجی کی یادداشت - فائل سسٹم قدرتی طور پر حل کرتا ہے، لکھنا مستقل ہے۔ تدریجی سیاق و سباق - ڈائریکٹری ڈھانچہ خود ہی بتدریج بنایا گیا ہے، mkdir، touch، append، سیاق و سباق فائل کے ساتھ بڑھتا ہے۔ ٹولز کا متحد شیڈول - یونکس پائپ لائن کا جوہر: ایک عمل کا stdout دوسرے عمل کا stdin ہے، اور درمیانی میڈیم بائٹ اسٹریم ہے۔ ایجنٹ کا ٹول چین بھی ایسا ہی ہے: پچھلے مرحلے کی آؤٹ پٹ فائل اگلے مرحلے کی ان پٹ ہے۔ اجازت کی حدود - فائل سسٹم کی rwx اجازتیں، chroot سینڈ باکس، قدرتی طور پر ایجنٹ کے لیے "قابلیت کا دائرہ" متعین کرتی ہیں۔

لہذا جب ایجنٹ فریم ورک کے ڈیزائنرز کو اس سوال کا سامنا کرنا پڑتا ہے کہ "ایجنٹ کی کام کرنے کی حالت کہاں رکھی جائے"، تو جواب تقریبا پہلے سے طے شدہ ہے: فائل سسٹم میں رکھیں۔ کیونکہ کوئی آسان حل نہیں ہے جو بیک وقت ان چار رکاوٹوں کو پورا کر سکے۔

جب سسٹم کو "بڑی تعداد میں مختلف وسائل کے تعامل کا انتظام" کرنے کی ضرورت ہوتی ہے، تو آپ کے پاس دو راستے ہیں:

راستہ A: ہر وسائل کے لیے ایک وقف شدہ انٹرفیس ڈیزائن کریں۔ N وسائل × M آپریشنز = NM انٹرفیس۔ درست لیکن دھماکہ خیز۔

راستہ B: ایک کافی پتلی تجرید تلاش کریں، تاکہ تمام وسائل ایک ہی لباس پہنیں۔ 4 آپریشنز × 1 تجرید کی پرت۔ کھردرا لیکن قابل جوڑ۔

یونکس نے B کا انتخاب کیا۔ پچاس سال سے زیادہ کے بعد، ایجنٹ فریم ورک نے دوبارہ B کا انتخاب کیا۔

ایک گہری پرت: فائل سوچ کی خارجیت ہے۔

لیکن اگر ہم صرف "تکنیکی حل کے کنورجنس" پر رک جاتے ہیں، تو ہم زیادہ ضروری چیز سے محروم ہو جائیں گے۔

ذرا یاد کریں کہ انسان خود پیچیدہ کاموں کو کیسے سنبھالتے ہیں۔

آپ کو ایک بڑا پروجیکٹ ملتا ہے، پہلی چیز جو آپ کرتے ہیں وہ کام شروع کرنا نہیں ہے، بلکہ: فولڈر بنانا ہے۔ پروجیکٹ روٹ ڈائریکٹری، ذیلی ٹاسک ڈائریکٹری، حوالہ جاتی مواد ڈائریکٹری، آؤٹ پٹ ڈائریکٹری۔ آپ ڈائریکٹری ڈھانچے کا استعمال کرتے ہوئے افراتفری والے کام کو قابل انتظام اکائیوں میں تقسیم کرتے ہیں۔ آپ ہر اکائی کو نام دینے کے لیے فائل نام استعمال کرتے ہیں۔ آپ فائل کے مواد کو سوچ کے عمل اور درمیانی مصنوعات کو ریکارڈ کرنے کے لیے استعمال کرتے ہیں۔

فائل سسٹم صرف ایک اسٹوریج حل نہیں ہے۔ یہ انسانی سوچ کو خارج کرنے کا ایک قدیم ٹول ہے۔

یہ بصیرت بتاتی ہے کہ ایجنٹ فریم ورک فائل سسٹم میں کیوں تبدیل ہوتا ہے: LLM کی "سوچ" کو خارج کرنے کی ضرورت ہے - اس کی سیاق و سباق ونڈو محدود ہے، اور طویل مدتی استدلال کو بیرونی یادداشت پر انحصار کرنا چاہیے۔ اور فائل سسٹم بالکل وہی ہے جو انسانوں نے ایجاد کیا ہے جو سب سے عام "بیرونی یادداشت" فارمیٹ ہے۔

اس نقطہ نظر سے، Claude Code کا CLAUDE.md ایک کنفیگریشن فائل نہیں ہے۔ یہ ایک خارج شدہ علمی معاہدہ ہے - انسان ارادے کو ایک فائل میں لکھتے ہیں، اور ایجنٹ فائل کو ارادے کے طور پر پڑھتا ہے۔ فائل انسانی ذہن اور مصنوعی ذہانت کے درمیان ایک انٹرفیس پرت بن جاتی ہے۔

یہ یونکس پائپ لائن کے فلسفے کے ساتھ حیرت انگیز طور پر مطابقت رکھتا ہے:

Write programs to handle text streams, because that is a universal interface.把"programs"换成"agents"，把"text streams"换成"files"，这句话在 2026 年依然成立。

回到第一性原理

عظیم تجرید پرانی نہیں ہوتی، یہ صرف نئے شعبوں میں نئی مثالیں تلاش کرتی ہے۔

"متحدہ انٹرفیس پیچیدگی کو ختم کرتا ہے" یونکس کی ایجاد نہیں ہے، یہ نظام ڈیزائن کا ایک ابدی قانون ہے۔ یونکس نے اتفاق سے "فائل" کے نام سے اسے نافذ کیا۔ AI ایجنٹ نے اتفاق سے "ورکنگ ڈائریکٹری" کی شکل میں اسے دوبارہ نافذ کیا۔

اگلی نسل کے نظام کو بھی اسی انتخاب کا سامنا کرنا پڑے گا: ہر چیز کے لیے وقف انٹرفیس ڈیزائن کریں، یا ایک پتلی، عام، قابلِ ترتیب تجرید تلاش کریں؟

اگر تاریخ سے کوئی سبق ملتا ہے، تو جواب پہلے ہی /dev/null کے ساتھ لکھا ہوا ہے: