সব কিছুই একটি ফাইল: ইউনিক্স থেকে এআই এজেন্টের ডিজাইন দর্শন
সবকিছুই একটি ফাইল: ইউনিক্স থেকে এআই এজেন্টের ডিজাইন দর্শন\n\nমূল লেখক ইথান ইয়েচেং\n\n
\n\n## অর্ধ শতাব্দীর প্রতিধ্বনি\n\n১৯৭০-এর দশকের শুরুতে বেল ল্যাবসে (Bell Labs), ইউনিক্সের জনক কেন থম্পসন (Ken Thompson) এবং ডেনিস রিচি (Dennis Ritchie) প্রথম একটি সাহসী ডিজাইন নীতি প্রস্তাব করেন: Everything is a file - সবকিছুই একটি ফাইল।\n\nপঞ্চাশ বছরেরও বেশি সময় পর, এআই এজেন্ট ফ্রেমওয়ার্কের ব্যাপক প্রসার ঘটেছে। Manus, Claude Code, OpenClaw... এগুলি বিভিন্ন দল, বিভিন্ন প্রযুক্তি স্ট্যাক এবং বিভিন্ন বাণিজ্যিক লক্ষ্য থেকে এসেছে, কিন্তু তারা সবাই একই পছন্দ করেছে: ফাইল সিস্টেমকে এজেন্টের জ্ঞানীয় কাঠামো হিসাবে ব্যবহার করা।\n\nManus একটি এজেন্টকে ভার্চুয়াল মেশিন দেয়, যেখানে টাস্কের আউটপুট ফাইল হিসাবে জমা হয়। Claude Code সরাসরি ব্যবহারকারীর স্থানীয় ফাইল সিস্টেমে পড়ে এবং লেখে, এবং একটি CLAUDE.md ফাইল সমস্ত নির্দেশাবলী এবং প্রসঙ্গ বহন করে। OpenClaw এর মতো ওপেন সোর্স ফ্রেমওয়ার্কগুলিও ডিরেক্টরি কাঠামোতে টাস্ক বিভাজন এবং মধ্যবর্তী অবস্থাগুলি সংগঠিত করে।\n\nযখন অর্ধ শতাব্দী ধরে প্রকৌশলীরা সম্পূর্ণ ভিন্ন প্রযুক্তিগত সমস্যার মুখোমুখি হন, তখন তারা স্বাধীনভাবে একই সমাধানে পৌঁছে যান - এটি কোনও কাকতালীয় ঘটনা নয়, এটি ডিজাইন দর্শনের প্রতিধ্বনি।\n\n## ইউনিক্সের সেই সিদ্ধান্ত\n\nএই সিদ্ধান্তের গুরুত্ব বুঝতে হলে, প্রথমে জানতে হবে ইউনিক্স কী করেছিল।\n\nইউনিক্স ফাইল সিস্টেমের ডিজাইন কম্পিউটার বিজ্ঞান ইতিহাসের সবচেয়ে মার্জিত ডিজাইনগুলির মধ্যে একটি হিসাবে স্বীকৃত। এটি একটি অত্যন্ত জটিল সমস্যার সমাধান করেছে: কীভাবে একটি অভিন্ন এবং সরল ইন্টারফেস ব্যবহার করে বিভিন্ন হার্ডওয়্যার এবং ডেটা রিসোর্স পরিচালনা করা যায়।\n\n১৯৭০-এর দশকের আগে, অপারেটিং সিস্টেম এভাবে কাজ করত: আপনি যদি ডিস্ক পড়তে চান তবে ডিস্ক ইন্টারফেস কল করুন; আপনি যদি টেপ পড়তে চান তবে টেপ ইন্টারফেস কল করুন; আপনি যদি টার্মিনাল অ্যাক্সেস করতে চান তবে টার্মিনাল ইন্টারফেস কল করুন। প্রতিটি ডিভাইসের নিজস্ব API ছিল, এবং প্রতিটি API-এর নিজস্ব অর্থ ছিল। আপনার যদি N সংখ্যক ডিভাইস এবং M সংখ্যক অপারেশন থাকে তবে সিস্টেমের জটিলতা হবে N × M।\n\nথম্পসন এবং রিচি একটি আপাতদৃষ্টিতে সরল কাজ করেছেন:\n\nসবকিছুকে ফাইলে পরিণত করুন। open, read, write, close এই চারটি ক্রিয়া দিয়ে সবকিছু পরিচালনা করুন।\n\nএর মূল অর্থ হল: অপারেটিং সিস্টেমের সমস্ত রিসোর্স - ডকুমেন্ট, ডিরেক্টরি, হার্ড ড্রাইভ, মডেম, কীবোর্ড, প্রিন্টার, এমনকি নেটওয়ার্ক সংযোগ এবং প্রক্রিয়া সম্পর্কিত তথ্য - একটি ফাইল স্ট্রীম (Stream of Bytes) হিসাবে বিমূর্ত করা যেতে পারে।\n\nএর মানে হল, আপনাকে কেবল একটি API শিখতে হবে - open(), read(), write(), close() - এবং আপনি কম্পিউটারের সমস্ত রিসোর্স পরিচালনা করতে পারবেন।\n\nএরপর থেকে, জটিলতা N × M থেকে ৪ × ১ এ নেমে আসে। চারটি ক্রিয়া, একটি বিমূর্ত স্তর।\n\nএই কাজের প্রতিভা - স্থায়ী মেমরি**: এলএলএম-এর কনটেক্সট উইন্ডো উদ্বায়ী, চিন্তার চেইন সেশনের সাথে শেষ হয়ে যায়। অনেকটা প্রসেস শেষ হওয়ার পরে মেমরি রিসাইকেল করার মতো—আপনার এমন একটি জায়গার দরকার যেখানে অন্তর্বর্তী অবস্থা স্থায়ীভাবে সংরক্ষণ করা যায়, অন্যথায় প্রতিটি কথোপকথন স্ক্র্যাচ থেকে শুরু হবে।
- ক্রমবর্ধমান কনটেক্সট: জটিল কাজ একবারে সম্পন্ন করা যায় না। এজেন্টকে একাধিক রাউন্ডের যুক্তিতে ধীরে ধীরে কনটেক্সট তৈরি করতে হয়, অনেকটা ইউনিক্স প্রসেস ফাইল পড়া এবং লেখার মাধ্যমে একাধিক এক্সিকিউশনের মধ্যে স্টেট পাস করার মতো। ফাইলসিস্টেম স্বাভাবিকভাবেই এই "একটু লেখা, একটু পড়া, আবার একটু লেখা"-এর ক্রমবর্ধমান কাজের মডেল সরবরাহ করে।
- সরঞ্জাম এবং দক্ষতার ইউনিফাইড শিডিউলিং: এজেন্টকে বিভিন্ন সরঞ্জাম (Tools/Skills) যেমন অনুসন্ধান, কোড এক্সিকিউশন, ছবি তৈরি ইত্যাদি কল করতে হয়, অনেকটা ইউনিক্স ডিস্ক, নেটওয়ার্ক, প্রিন্টার ইত্যাদি বিভিন্ন ডিভাইস পরিচালনা করার মতো। আপনার একটি ইউনিফাইড অ্যাবস্ট্রাকশন লেয়ার দরকার, অন্যথায় প্রতিটি নতুন সরঞ্জাম যুক্ত করার জন্য একটি নতুন ইন্টিগ্রেশন লজিক লিখতে হবে।
- কম্পিউটার ব্যবহারের অনুমতির সীমা: যখন কোনও এজেন্টের কম্পিউটার চালানোর ক্ষমতা থাকে, তখন "এটি কী স্পর্শ করতে পারবে, কী পারবে না" একটি গুরুত্বপূর্ণ বিষয় হয়ে দাঁড়ায়। ইউনিক্সের ফাইল পারমিশন সিস্টেম (rwx) একটি রেডি-মেড স্যান্ডবক্স মডেল সরবরাহ করে—ডিরেক্টরি হল সীমানা, অনুমতি হল চুক্তি।
চারটি প্রয়োজনীয়তা। পরিচিত লাগছে, তাই না?
এগুলোই হল সেই সমস্যা যা ১৯৭০-এর দশকে অপারেটিং সিস্টেম মোকাবিলা করেছিল।
স্থায়ী মেমরি—ফাইলসিস্টেম স্বাভাবিকভাবেই সমাধান করে, লেখা মানেই স্থায়ী। ক্রমবর্ধমান কনটেক্সট—ডিরেক্টরি স্ট্রাকচার নিজেই ক্রমবর্ধমানভাবে তৈরি হয়, mkdir, touch, append, কনটেক্সট ফাইলের সাথে বৃদ্ধি পায়। সরঞ্জামগুলির ইউনিফাইড শিডিউলিং—ইউনিক্স পাইপের সারমর্ম: একটি প্রসেসের stdout হল অন্য প্রসেসের stdin, মধ্যবর্তী মাধ্যম হল বাইট স্ট্রিম। এজেন্টের সরঞ্জাম চেইনও একই রকম: আগের ধাপের আউটপুট ফাইল হল পরবর্তী ধাপের ইনপুট। অনুমতির সীমা—ফাইলসিস্টেমের rwx অনুমতি, chroot স্যান্ডবক্স, স্বাভাবিকভাবেই এজেন্টের জন্য একটি "ক্ষমতার পরিধি" নির্ধারণ করে।
সুতরাং যখন কোনও এজেন্ট ফ্রেমওয়ার্কের ডিজাইনার "এজেন্টের কাজের অবস্থা কোথায় রাখা উচিত" এই প্রশ্নের মুখোমুখি হন, তখন উত্তরটি প্রায় পূর্বনির্ধারিত: ফাইলসিস্টেমে। কারণ এই চারটি সীমাবদ্ধতা একসাথে পূরণ করার জন্য এর চেয়ে সহজ কোনও সমাধান নেই।
যখন কোনও সিস্টেমকে "বিপুল সংখ্যক ভিন্নধর্মী রিসোর্সের মিথস্ক্রিয়া পরিচালনা" করতে হয়, তখন আপনার কাছে দুটি পথ রয়েছে:
রুট A: প্রতিটি রিসোর্সের জন্য ডেডিকেটেড ইন্টারফেস ডিজাইন করুন। N সংখ্যক রিসোর্স × M সংখ্যক অপারেশন = NM সংখ্যক ইন্টারফেস। নির্ভুল কিন্তু বিস্ফোরক।
রুট B: একটি যথেষ্ট পাতলা অ্যাবস্ট্রাকশন লেয়ার খুঁজুন, যাতে সমস্ত রিসোর্স একই পোশাক পরতে পারে। ৪টি অপারেশন × ১টি অ্যাবস্ট্রাকশন লেয়ার। মোটামুটি কিন্তু একত্রিত করা যায়।
ইউনিক্স B বেছে নিয়েছে। পঞ্চাশ বছরেরও বেশি সময় পরে, এজেন্ট ফ্রেমওয়ার্ক আবার B বেছে নিয়েছে।

আরও গভীরে: ফাইল হল চিন্তার বহিঃপ্রকাশ
তবে যদি আমরা কেবল "টেকনিক্যাল সমাধানের অভিসারে" থেমে যাই, তবে আমরা আরও মৌলিক কিছু মিস করব।
একবার ভাবুন মানুষ কীভাবে জটিল কাজগুলি পরিচালনা করে।
আপনি যখন একটি বড় প্রকল্প পান, তখন প্রথম কাজটি হল কাজ শুরু করা নয়, বরং: ফোল্ডার তৈরি করা। প্রকল্পের রুট ডিরেক্টরি, সাবটাস্ক ডিরেক্টরি, রেফারেন্স ম্যাটেরিয়াল ডিরেক্টরি, আউটপুট ডিরেক্টরি। আপনি ডিরেক্টরি স্ট্রাকচার ব্যবহার করে বিশৃঙ্খল কাজটিকে পরিচালনাযোগ্য ইউনিটে বিভক্ত করেন। আপনি প্রতিটি ইউনিটের নামকরণ করেন ফাইলের নাম দিয়ে। আপনি ফাইলের বিষয়বস্তু ব্যবহার করে চিন্তার প্রক্রিয়া এবং অন্তর্বর্তী পণ্যগুলি রেকর্ড করেন।
ফাইলসিস্টেম কেবল স্টোরেজ সমাধান নয়। এটি মানুষের চিন্তাভাবনাকে বহিঃপ্রকাশ করার আদিম সরঞ্জাম।
এই অন্তর্দৃষ্টিটি ব্যাখ্যা করে কেন এজেন্ট ফ্রেমওয়ার্ক ফাইলসিস্টেমে একত্রিত হয়: এলএলএম-এর "চিন্তা" কে বহিঃপ্রকাশ করতে হয়—এর কনটেক্সট উইন্ডো সীমিত, দীর্ঘমেয়াদী যুক্তির জন্য বাহ্যিক স্মৃতির উপর নির্ভর করতে হয়। এবং ফাইলসিস্টেম হল মানুষের উদ্ভাবিত সবচেয়ে সাধারণ "বাহ্যিক মেমরি" ফর্ম্যাট।
এই দৃষ্টিকোণ থেকে, ক্লড কোডের CLAUDE.md একটি কনফিগারেশন ফাইল নয়। এটি একটি বহিঃপ্রকাশিত জ্ঞানীয় চুক্তি—মানুষ তাদের উদ্দেশ্য ফাইলে লেখে, এজেন্ট ফাইলটি পড়ে উদ্দেশ্য হিসেবে। ফাইলটি মানব মন এবং কৃত্রিম বুদ্ধিমত্তার মধ্যে একটি ইন্টারফেস স্তর হয়ে ওঠে।
এটি ইউনিক্স পাইপের দর্শনের সাথে আশ্চর্যজনকভাবে সঙ্গতিপূর্ণ:
Write programs to handle text streams, because that is a universal interface.把"programs"换成"agents",把"text streams"换成"files",这句话在 2026 年依然成立। ( "programs" কে "agents" দিয়ে এবং "text streams" কে "files" দিয়ে প্রতিস্থাপন করুন, এই উক্তিটি ২০২৬ সালেও সত্য থাকবে।)
回到第一性原理 (প্রথম নীতিতে ফিরে যান)
伟大的抽象不会过时,它只会在新领域找到新的实例। (মহৎ বিমূর্ততা পুরনো হয় না, এটি কেবল নতুন ক্ষেত্রে নতুন উদাহরণ খুঁজে পায়।)
"统一接口消解复杂性"不是 Unix 的发明,它是系统设计的永恒定律। ( "ইউনিফাইড ইন্টারফেস জটিলতা দূর করে" এটা ইউনিক্সের আবিষ্কার নয়, এটি সিস্টেম ডিজাইনের শাশ্বত নিয়ম। ) Unix 碰巧用"文件"这个名字实现了它। (ইউনিক্স ঘটনাক্রমে "ফাইল" এই নামের মাধ্যমে এটি বাস্তবায়ন করেছে।) AI Agent 碰巧用"工作目录"这个形式再次实现了它। (এআই এজেন্ট ঘটনাক্রমে "ওয়ার্কিং ডিরেক্টরি" এই ফর্মের মাধ্যমে পুনরায় এটি বাস্তবায়ন করেছে।)
下一代系统也会再次面对同一个选择:给每种东西设计专用接口,还是找到一层薄薄的、通用的、可组合的抽象? (পরবর্তী প্রজন্মের সিস্টেমকেও আবার একই পছন্দের মুখোমুখি হতে হবে: প্রতিটি জিনিসের জন্য ডেডিকেটেড ইন্টারফেস ডিজাইন করা, নাকি একটি পাতলা, সার্বজনীন, সংযোজনযোগ্য বিমূর্ততা খুঁজে বের করা?)
如果历史有什么教训的话,答案早就写在 /dev/null 旁边了: (ইতিহাসের যদি কোনো শিক্ষা থাকে, তবে উত্তরটি /dev/null এর পাশেই লেখা আছে:)
Keep it simple. Make it compose. Everything is a file.





