OpenClaw-এর মতো নিজের AI agent কীভাবে বানাবেন

OpenClaw আসলে কী

OpenClaw হলো একটি self-hosted ব্যক্তিগত AI agent। আপনি এটিকে আপনার নিজের সার্ভারে চালান, আপনার ব্যবহৃত চ্যাট অ্যাপগুলোর সাথে সংযুক্ত করেন এবং এটি shell command চালানো, browser নিয়ন্ত্রণ করা, আপনার ফাইল পড়া ও লেখা এবং আপনার পাঠানো বার্তার ভিত্তিতে কাজ করতে সক্ষম। এটি MIT-licensed, local-first এবং 2026 সালের মাঝামাঝি পর্যন্ত GitHub-এ 3,80,000-এর বেশি তারকা পেয়েছে, যা এটিকে প্ল্যাটফর্মটির অন্যতম জনপ্রিয় প্রজেক্টে পরিণত করেছে। এর জটিলতার আড়ালে এটি মূলত কিছু ছোট ছোট অংশের সমন্বয়, যা যৌক্তিকভাবে একে অপরের সাথে যুক্ত। এই পোস্টটি সেই অংশগুলো নিয়ে আলোচনা করবে যাতে আপনি বুঝতে পারেন কীভাবে এই ধরনের টুল তৈরি করা হয় এবং এর ঝুঁকিগুলো কোথায়।

শুরুতেই একটি সতর্কবার্তা, কারণ এটি নিচের প্রতিটি ডিজাইনের সিদ্ধান্তকে প্রভাবিত করে। 2026 সালের মার্চ মাসে OpenClaw-এর রক্ষণাবেক্ষণকারীরা প্রচুর নিরাপত্তা পরামর্শ (security advisories) প্রকাশ করেন: শুধুমাত্র 13 মার্চেই 22টি এবং 16 মার্চ আরও পাঁচটি, যেখানে National Vulnerability Database সেই মাসে 199টি OpenClaw CVE রেকর্ড করেছে। 13 মার্চের ব্যাচে 10-এর মধ্যে 9.9 রেটিংয়ের দুটি গুরুতর ত্রুটি ছিল, যার একটি হলো privilege-escalation বাগ (CVE-2026-32922), যা শুধুমাত্র pairing rights থাকা ডিভাইসকে পূর্ণ admin token তৈরি করার সুযোগ দিত। এই প্রজেক্টটি এমনভাবে ডিজাইন করা হয়েছে যাতে আপনি, অর্থাৎ অপারেটর, এটিকে সুরক্ষিত (harden) করতে পারেন। যে agent যেকোনো command চালাতে পারে, তার নিরাপত্তা নির্ভর করে সেটি যে সার্ভারে চলছে তার নিরাপত্তা এবং আপনি সেখানে কী কী সীমাবদ্ধতা আরোপ করেছেন তার ওপর। পড়ার সময় এই বিষয়টি মনে রাখবেন।

Gateway daemon: একটি প্রসেস, যা ব্যক্তিগত রাখা হয়

এর কেন্দ্রে রয়েছে একটি দীর্ঘস্থায়ী প্রসেস, যাকে সাধারণত gateway বলা হয়। এটি হলো control plane। এটি বার্তা গ্রহণ করে, কী করতে হবে তা নির্ধারণ করে, টুলগুলো চালায় এবং উত্তর পাঠায়। অন্য সবকিছু এর সাথে যুক্ত থাকে।

Gateway সম্পর্কে সবচেয়ে গুরুত্বপূর্ণ তথ্য হলো এটি কোথায় listen করে। সাধারণ host ইনস্টলেশনে OpenClaw এটিকে loopback address, 127.0.0.1-এ bind করে, তাই আপনি যদি নিজে থেকে এটিকে expose না করেন, তবে ইন্টারনেট থেকে এটি অ্যাক্সেস করা সম্ভব নয়। Container image-এর ক্ষেত্রে বিষয়টি ভিন্ন: OpenClaw-এর নিজস্ব নিরাপত্তা নথিতে বলা হয়েছে যে, এগুলো ডিফল্টভাবে exposed অবস্থায় থাকে। তাই আপনি যদি container চালান, তবে authentication চালু রাখুন এবং এর port ইন্টারনেটে প্রকাশ করবেন না। যেকোনো ক্ষেত্রেই, এটিকে ব্যক্তিগত রাখুন। এটিই সেই একমাত্র প্রসেস যা নিয়মিত command চালায়, তাই একটি exposed gateway যে কেউ খুঁজে পেলে আপনার সার্ভারে remote foothold পেয়ে যাবে। যখন আপনার ল্যাপটপ থেকে এটিকে অ্যাক্সেস করার প্রয়োজন হয়, তখন port খোলার পরিবর্তে VPN বা SSH tunnel ব্যবহার করুন। যে port-এ পৌঁছানো যায় না, তা কেউ আক্রমণ করতে পারে না।

চ্যানেল connector: বার্তা গ্রহণ এবং উত্তর পাঠানো

আপনি যে অ্যাপগুলো ইতিমধ্যে ব্যবহার করেন, সেগুলো থেকে যোগাযোগ করা না গেলে personal agent তেমন কার্যকর নয়। চ্যানেল connector-গুলো এই কাজই করে। প্রতিটি connector একটি platform-এর সঙ্গে কাজ করে, যেমন Telegram, WhatsApp, Slack বা Discord। এ জন্য সেটি ওই platform-এর bot API অথবা webhook ব্যবহার করে।

সব connector-এর কাঠামো একই। connector platform-এ একটি bot নিবন্ধন করে। এরপর এটি আপনার পাঠানো বার্তা গ্রহণ করে। এটি platform-কে poll করে বার্তা নিতে পারে, অথবা platform যে webhook পাঠায় তা গ্রহণ করতে পারে। তারপর connector বার্তাটি gateway-তে পাঠায় এবং একই API ব্যবহার করে gateway-এর উত্তর আবার পাঠায়। connector একটি সরল translation layer। এটি “Telegram-এ একটি বার্তা এসেছে” ঘটনাকে “agent-এর জন্য এই text” হিসেবে রূপান্তর করে এবং উত্তর পাওয়ার পর বিপরীত রূপান্তর করে। নিজের connector তৈরি করতে সাধারণত একটি platform-এর bot documentation পড়ে তার message format-কে gateway-এর format-এর সঙ্গে mapping করলেই হয়।

The brain and the tool loop

Gateway-এর ভেতরে এমন একটি অংশ আছে, যা এটিকে chatbot-এর বদলে agent বানায়। এটি একটি loop।

একটি message আসে। Gateway এটি model যে tools ব্যবহার করতে পারবে, সেই tools-এর তালিকাসহ একটি language model-এ পাঠায়। Model message পড়ে সিদ্ধান্ত নেয়: সরাসরি উত্তর দেবে, নাকি কোনো tool call করবে। Model কোনো tool call করলে gateway সেই tool চালায়, ফলাফল সংগ্রহ করে এবং ফলাফলটি model-এ ফেরত পাঠায়। Model ফলাফল দেখে আবার সিদ্ধান্ত নেয়। Model-এর আর কিছু করার না থাকা পর্যন্ত এই প্রক্রিয়া চলতে থাকে। এরপর model একটি final reply তৈরি করে।

এই loop-ই agent-এর মূল ধারণা। Agent chat app-এ চলুক বা terminal-এ, loop একই থাকে। Tools-কে standard উপায়ে এই loop-এর সঙ্গে কীভাবে যুক্ত করতে হয়, তা জানতে Model Context Protocol-এর মাধ্যমে tools যুক্ত করা পরের ভালো পাঠ। Model-এর দিকটি বুঝতে নিজের hardware-এ model চালানো বিষয়টির অন্য অর্ধটি ব্যাখ্যা করে।

টুলসমষ্টিই মূল বিষয় এবং ঝুঁকিও এখানেই

OpenClaw-কে শক্তিশালী করে টুলগুলো। এমন একটি টুল আছে যা shell command চালায়, এমন একটি টুল আছে যা browser নিয়ন্ত্রণ করে, আবার এমন টুলও আছে যা file পড়ে ও লেখে। উপরের loop-কে এগুলোর access দিলে keyboard-এ আপনি যা করতে পারেন, এটি প্রায় সবই করতে পারে। এই বিস্তৃত ক্ষমতাই পুরো product, এবং একই সঙ্গে পুরো ঝুঁকিও।

যে agent chat app থেকে আসা নির্দেশ অনুযায়ী যেকোনো command চালাতে পারে, সেটি একটি বড় attack surface। কোনো খারাপ নির্দেশ, browser tool যে web page-এ যায় সেখানে লুকানো prompt-injection attack, অথবা March 2026-এর flaws-এর মতো কোনো bug, "আমার calendar পড়ো" নির্দেশকে "আমার file মুছে দাও"-তে পরিণত করতে পারে। তাই সীমাবদ্ধতাগুলো ঐচ্ছিক অতিরিক্ত সুবিধা নয়। agent-কে কোনো sudo ছাড়াই একটি dedicated, unprivileged user হিসেবে চালান, যাতে compromise হলে privilege escalation সম্ভব না হয়। বিপজ্জনক tool-গুলোকে approval step-এর আড়ালে রাখুন, যাতে destructive কাজ করার আগে agent অনুমতি চায়। tool execution sandbox করুন, যাতে নিয়ন্ত্রণের বাইরে চলে যাওয়া command সীমাবদ্ধ থাকে। model-এর API key আলাদা করে সুরক্ষিত রাখুন, যাতে key ফাঁস হলে attacker আপনার account-এর access না পায়। একই box-এ থাকা অন্যান্য secret নিয়েও ভাবুন, কারণ Vaultwarden-এর প্রকৃত দুর্বল স্থান হলো তার admin token এবং backup file, encryption নয়; আর shell access-সহ একটি agent উভয়েরই নাগালের মধ্যে থাকে।

shell command চালায় এমন কোনো কিছু Internet-এ প্রকাশ করার আগে মৌলিক বিষয়গুলো পরিকল্পনা করে সম্পন্ন করুন। নিজের box-এর জন্য এখানে একটি checklist তৈরি করুন, তারপর উপর থেকে নিচ পর্যন্ত অনুসরণ করুন:

unprivileged user হিসেবে service চালানোর বিষয়টি unprivileged user হিসেবে service চালানো-তে বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে। প্রকৃত project-এর জন্য সম্পূর্ণ নিরাপদ setup-এর নির্দেশিকা রয়েছে VPS-এ OpenClaw নিরাপদে চালানো-তে।

ফাইল হিসেবে মেমোরি

অধিকাংশ মানুষ আশা করে যে একটি agent-এর মেমোরি কোনো database-এ থাকবে। OpenClaw-এর ক্ষেত্রে তা নয়। এটি মেমোরিকে ডিস্কে সাধারণ Markdown ফাইল হিসেবে সংরক্ষণ করে এবং এই সিদ্ধান্তটি অনুসরণ করার মতো। ফাইলগুলোই হলো তথ্যের মূল উৎস; ডিফল্ট মেমোরি ইঞ্জিন এগুলোর পাশে একটি SQLite search index রাখে এবং সেই index ফাইলগুলো থেকে পুনরায় তৈরি করা সম্ভব।

ফাইলগুলো সহজ। এখানে migrate করার মতো কোনো schema নেই, চালু রাখার মতো কোনো service নেই এবং শেখার মতো কোনো query language নেই। এগুলো পরীক্ষা করা যায়: আপনি ফোল্ডারটি খুলে পড়তে পারেন যে agent আপনার সম্পর্কে ঠিক কী জানে, কোনো ফাইল এডিট করে ভুল তথ্য সংশোধন করতে পারেন অথবা একটি ফাইল মুছে ফেলে মেমোরি ডিলিট করতে পারেন। এগুলো বহনযোগ্যও, কারণ agent-কে নতুন সার্ভারে স্থানান্তর করা মানে কেবল একটি ডিরেক্টরি কপি করা। একজন ব্যবহারকারীর ব্যক্তিগত agent-এর জন্য টেক্সট ফাইলের একটি ফোল্ডারই যথেষ্ট এবং এটি পুরো সিস্টেমকে সহজবোধ্য রাখে।

দক্ষতা: সক্ষমতা যোগ করার একটি পোর্টেবল পদ্ধতি

অন্তর্নির্মিত টুলের বাইরে, OpenClaw একটি পোর্টেবল skill format ব্যবহার করে। এর মাধ্যমে core পরিবর্তন না করেই community-এর পক্ষে এর সক্ষমতা বাড়ানো যায়। একটি skill হলো instructions এবং কখনও কখনও code-এর একটি স্বয়ংসম্পূর্ণ bundle, যা agent-কে নতুন কোনো কাজ শেখায়। কোনো task-এর জন্য প্রয়োজন হলে agent skill লোড করে। Web search সাধারণত মানুষ প্রথমে যে skill যোগ করে। আর সেই skill-কে আপনার নিজের SearXNG instance-এ নির্দেশ করলে আপনার query কোনো commercial search API-এর বাইরে থাকে। একই সঙ্গে skill-এর trust boundary কোথায়, তা স্পষ্ট হয়। কারণ skill যে ফলাফল ফেরত দেয়, সেগুলো কোনো অপরিচিত ব্যক্তির লেখা text।

এই ধরনের format-এর সুবিধা হলো, সক্ষমতাগুলো share করা যায়। কেউ নির্দিষ্ট কাজের জন্য একটি skill লেখে, সেটি publish করে, এবং অন্যরা তা যুক্ত করে। এই সুবিধার ঝুঁকিও আছে। কারণ skill হলো কোনো অপরিচিত ব্যক্তির code, যা আপনার agent দ্বিধা না করেই চালাবে। তাই আপনি নিজে লেখেননি এমন যেকোনো কিছু load করার আগে নিজের host করা একটি security scanner দিয়ে পরীক্ষা করা উপযোগী। আপনি নিজের agent তৈরি করলে শুরুতেই একটি ছোট ও স্পষ্ট extension format নির্ধারণ করুন। এতে পরে প্রতিটি সক্ষমতা core-এর মধ্যে hard-code করতে হবে না।

নিজের মডেল ব্যবহার করুন

OpenClaw মডেল-নিরপেক্ষ। এটি নিজস্ব কোনো language model সরবরাহ করে না। এর পরিবর্তে, আপনি যে মডেল বেছে নেবেন সেটির সঙ্গে এটি সংযুক্ত হয়। সেই মডেল hosted API হতে পারে অথবা আপনি নিজে চালাতে পারেন।

খরচ, গোপনীয়তা এবং নিয়ন্ত্রণের ক্ষেত্রে এই বিভাজন গুরুত্বপূর্ণ। hosted API ব্যবহার করলে কোনো hardware পরিচালনা না করেই সবচেয়ে শক্তিশালী মডেল পাওয়া যায়। তবে token-ভিত্তিক খরচ দিতে হয় এবং আপনার prompt সার্ভারের বাইরে পাঠানো হয়। Ollama-এর মতো কোনো software দিয়ে self-hosted model চালালে প্রতিটি message আপনার নিজের server-এই থাকে। তখন খরচের মধ্যে শুধু hardware ও বিদ্যুৎ থাকে। তবে এর বিনিময়ে ছোট বা ধীরগতির model চালাতে হতে পারে। অনেকে দুটি পদ্ধতি একসঙ্গে ব্যবহার করেন। কোনো agent-কে সম্পূর্ণ private রাখতে চাইলে আপনার VPS-এ model self-host করা এই শেষ ব্যবধানটিও দূর করে। তুলনা করার মতো আরেকটি self-hosted agent হলো Hermes Agent।

একটি তৈরি করবেন কি?

আপনি এগুলো সব নিজেই তৈরি করতে পারেন। উপাদানগুলো অস্বাভাবিক কিছু নয়: একটি daemon, কয়েকটি chat connector, একটি model-and-tools loop, একটি Markdown folder এবং একটি plugin format। এগুলো বোঝা সত্যিই কাজে লাগে। এতে আপনি যে প্রতিটি agent ব্যবহার করবেন, তার কার্যপ্রণালি পরিষ্কার হয় এবং ঝুঁকি ঠিক কোথায় থাকে তা জানা যায়।

তবে অধিকাংশ মানুষের জন্য সৎ উত্তর হলো, এটি নতুন করে বানানোর বদলে আসল সফটওয়্যারটি চালিয়ে harden করা। OpenClaw ইতিমধ্যে connector, loop এবং skill format সমাধান করেছে, এবং এর নিরাপত্তা নিয়ে বাস্তব পর্যালোচনাও হয়েছে। আপনার সময় এমন অংশে ব্যয় করা বেশি কার্যকর, যেটি সঠিকভাবে করা আপনার নিজের দায়িত্ব—নিজের server-এর setup এবং hardening। আপনি যদি আগে শেখার পথ বেছে নিতে চান, তাহলে ধাপে ধাপে ধারণাগুলো আয়ত্ত করা agent-এর source code সরাসরি পড়ার চেয়ে বেশি কার্যকর, কারণ প্রতিটি ধাপ শেষে আপনার হাতে এমন একটি জিনিস থাকে, যা আপনি নিজে তৈরি করেছেন। শেখার জন্য একটি ছোট সংস্করণ তৈরি করুন। ব্যবহারের জন্য আসল সংস্করণটি চালিয়ে নিরাপদ করুন।

সাধারণ ভিত্তিগুলো VPS-এ নিজের AI agent তৈরি করা-এ রয়েছে, আর Claude দিয়ে একটি agent তৈরি করা একই ধারণাগুলো নির্দিষ্ট একটি model-কে brain হিসেবে ব্যবহার করে দেখায়।

FAQ

OpenClaw-এর মতো একটি agent তৈরি করা কি কঠিন?

এর আলাদা অংশগুলো কঠিন নয়। একটি gateway প্রসেস, একটি চ্যাট কানেক্টর, একটি model-and-tools লুপ এবং ফাইলের একটি ফোল্ডার—এগুলো প্রত্যেকেই আলাদাভাবে বেশ সহজ। কঠিন অংশ হলো এটিকে নিরাপদে তৈরি করা। যে agent চ্যাট বার্তা থেকে shell command চালায়, তা একটি বড় ধরনের নিরাপত্তা ঝুঁকি। তাই sandboxing, permissions এবং unprivileged-user সেটআপ সঠিকভাবে করা ফিচারগুলো যুক্ত করার চেয়েও বেশি পরিশ্রমের কাজ।

OpenClaw কেন মেমোরিকে database-এর পরিবর্তে Markdown ফাইল হিসেবে সংরক্ষণ করে?

কারণ একজন ব্যবহারকারীর ব্যক্তিগত agent-এর জন্য ফাইলই যথেষ্ট এবং অনেক বেশি সহজ। এখানে চালানোর মতো কোনো database service নেই, মেমোরি পড়া এবং হাতে সংশোধন করা সহজ, এবং agent-কে অন্য সার্ভারে স্থানান্তর করা মানে কেবল একটি ডিরেক্টরি কপি করা। বড় পরিসরে database-এর প্রয়োজন হয়, এখানে নয়।

ব্যক্তিগত AI agent-এর সবচেয়ে বিপজ্জনক অংশ কোনটি?

যে টুলগুলো এটিকে কাজ করতে দেয়: shell command চালানো, browser নিয়ন্ত্রণ করা এবং ফাইল লেখা। এগুলোই এই agent তৈরির কারণ এবং এগুলোই আপনার ক্ষতি করতে পারে। 2026 সালের মার্চ মাসে OpenClaw-এর নিরাপত্তা পরামর্শের ঢেউ, যেখানে 13 থেকে 16 মার্চের মধ্যে 27টি পরামর্শ প্রকাশিত হয় এবং দুটি 9.9 রেটিংয়ের গুরুতর ত্রুটি ছিল, তা টুল লেয়ারটিকে সতর্কতার সাথে ব্যবহারের সবচেয়ে বড় প্রমাণ: unprivileged user হিসেবে চালান, ধ্বংসাত্মক কাজগুলোকে নিয়ন্ত্রণ করুন এবং execution-কে sandbox করুন।

এটি তৈরি করতে কি আমার নিজের language model প্রয়োজন?

না। OpenClaw-এর মতো agent-গুলো model-agnostic, তাই আপনি আপনার পছন্দের যেকোনো মডেল সংযুক্ত করতে পারেন। এটি শক্তিশালী মডেলের জন্য hosted API হতে পারে, অথবা সম্পূর্ণ গোপনীয়তার জন্য আপনার নিজের চালানো কোনো মডেল হতে পারে। Ollama-এর মাধ্যমে self-hosting করলে প্রতিটি বার্তা আপনার নিজের সার্ভারেই থাকে, তবে এর বিনিময়ে আপনাকে ছোট মডেল ব্যবহার করতে হয়।