VPS-এ নিজের AI agent কীভাবে তৈরি করবেন

একটি AI agent আসলে কী

একটি AI agent হলো language model-কে ঘিরে তৈরি একটি loop। model পরিস্থিতি পড়ে, একটি action নির্বাচন করে, আপনার code সেই action সম্পাদন করে, ফলাফল model-এর কাছে ফেরত যায়, এবং task সম্পন্ন না হওয়া পর্যন্ত loop আবার চলে। মূল ধারণাটি এতটুকুই। একটি সাধারণ chatbot একবার উত্তর দিয়ে থেমে যায়। একটি agent নিজের প্রতিটি turn-এর মধ্যে বাস্তব action সম্পাদন করে goal অর্জন না হওয়া পর্যন্ত কাজ চালিয়ে যায়। এই loop এত ছোট যে এক বিকেলেই নিজে লিখে ফেলা যায়। এখান থেকেই শুরু থেকে agent শেখার ধাপে ধাপে পথ শুরু হয়, এরপর তার ওপর tools, memory এবং safety যোগ করা যায়।

Action-ই গুরুত্বপূর্ণ অংশ। নিজে থেকে একটি language model শুধু text তৈরি করে। এটি file পড়তে, API call করতে বা command চালাতে পারে না। একটি agent model-কে ব্যবহার করার অনুমোদিত tools-এর একটি সেট এবং সেগুলোর জন্য অনুরোধ জানানোর পদ্ধতি দেয়। Model যখন web search করতে বা file লিখতে চায়, তখন সে নিজে কাজটি সম্পাদন করে না। সে একটি structured request তৈরি করে, আপনার code tool চালায়, এবং ফলাফল model পরবর্তী input হিসেবে পড়ে। বিচার-বিবেচনা model দেয়; কাজ সম্পাদনের সক্ষমতা আপনার server দেয়।

প্রতিটি task-এর জন্য agent প্রয়োজন হয় না, এবং default হিসেবে agent বেছে নেওয়া একটি সাধারণ ভুল। ধাপগুলো আগে থেকেই জানা থাকলে একটি সাধারণ script সহজ, দ্রুত এবং বেশি নির্ভরযোগ্য। “প্রতি ঘণ্টায় এই page fetch করে আমাকে price email করো”—এটি একটি scheduled job, agent নয়। পথটি আগে থেকে নির্দিষ্ট না থাকলে এবং model-কে পাওয়া তথ্য দেখে পরবর্তী পদক্ষেপ নির্ধারণ করতে হলে agent তৈরি করুন। Agent-এর খরচ হলো অনির্দেশ্যতা। তাই flexibility থেকে বাস্তব সুবিধা পাওয়া গেলেই এটি ব্যবহার করুন।

Tools: একজন agent কীভাবে কাজ করে

যে কোনো capability-কে tool বলা যায়, যদি আপনি সেটি model-কে এমনভাবে বর্ণনা করেন যে model বুঝতে পারে কখন এটি ব্যবহার করতে হবে। File পড়া, shell command চালানো, database query করা বা message পাঠানো—প্রতিটিই একটি tool। প্রতিটি tool-এর একটি name, সংক্ষিপ্ত description এবং input-এর তালিকা থাকে। Tool আপনি নির্ধারণ করেন; কখন call করতে হবে, তা model সিদ্ধান্ত নেয়। সাধারণত web search যোগ করাই প্রথমে সবচেয়ে উপযোগী। আপনি যদি আগে থেকেই নিজের SearXNG instance চালান, তাহলে commercial search API-এর জন্য অর্থ না দিয়ে এটিকে agent-এর search backend-এ রূপান্তর করতে পারেন।

আপনি যে model-ই ব্যবহার করুন, সর্বত্র একই mechanism কাজ করে। Model একটি structured request ফেরত দেয়। সেখানে একটি tool-এর name থাকে এবং তার input পূরণ করা থাকে। আপনার code সেই request শনাক্ত করে, সংশ্লিষ্ট function চালায় এবং পরের turn-এ ফলাফল পাঠায়। Model ফলাফল পড়ে আরেকটি tool call করে অথবা final answer লিখে। প্রতিটি agent-এর নেপথ্যের plumbing হলো function calling। এটি পরিচালনা করা loop-ও সাধারণ code-এর মাত্র কয়েকটি line।

আপনার control-ও এখানে থাকে। Model কোনো command চালানোর অনুরোধ করতে পারে, কিন্তু আপনার code চালানোর সিদ্ধান্ত না নেওয়া পর্যন্ত কিছুই চলে না। এই ব্যবধানেই dangerous action-এর জন্য approval prompt, কোনো tool কী কী স্পর্শ করতে পারবে তার limit এবং agent যা করেছে তার সম্পূর্ণ log রাখা যায়। আপনি agent-কে যে tool দেন এবং সেগুলোর সামনে যে check বসান, agent-এর নিরাপত্তা ততটাই নির্ভরযোগ্য।

MCP: tools সংযোগের একটি মানসম্মত পদ্ধতি

প্রতিটি service-এর জন্য হাতে নতুন integration লিখতে দ্রুতই বিরক্তিকর হয়ে ওঠে। Model Context Protocol, বা MCP, একটি open standard যা এই সমস্যার সমাধান করে। আপনার files, database এবং issue tracker-এর জন্য আলাদা tool code করার বদলে, আপনি agent-কে এমন একটি MCP server-এর সঙ্গে যুক্ত করেন যা ইতিমধ্যে এগুলোকে tool হিসেবে প্রকাশ করে। Agent একটি protocol-এ যোগাযোগ করে; server বাস্তব system-এর সঙ্গে যোগাযোগের কাজটি করে।

এর সুবিধা হলো পুনর্ব্যবহার। অন্য কেউ আপনার ব্যবহৃত কোনো service-এর জন্য MCP server লিখে থাকলে, নতুন integration code ছাড়াই সেটি আপনার agent-এ ব্যবহার করা যায়। একইভাবে, আপনার লেখা server সেই protocol সমর্থনকারী যেকোনো agent ব্যবহার করতে পারে। কিছু self-hosted app এখন নিজেদের MCP server-ও সরবরাহ করে। যেমন, openGym, একটি workout tracker একটি read-only MCP server প্রকাশ করে। তাই agent আপনার training history সম্পর্কে প্রশ্নের উত্তর দিতে পারে, কিন্তু এর কোনো তথ্য পরিবর্তন করতে পারে না। VPS-এ এটি গুরুত্বপূর্ণ, কারণ agent-এর পাশাপাশি MCP server-গুলোকে আলাদা ছোট service হিসেবে চালানো যায় এবং প্রতিটিকে শুধু প্রয়োজনীয় access দেওয়া যায়। এই server-গুলোর পেছনের system VPS যে network দেখতে পায় না, যেমন বাড়ি বা অফিসের একটি database, সেখানে থাকলে subnet router দিয়ে সেই network-কে আপনার tailnet-এ advertise করা agent-কে public Internet-এ কিছু প্রকাশ না করেই private address-এর মাধ্যমে সেগুলোতে পৌঁছাতে দেয়। VPS-এ MCP server চালানো অংশে setup বর্ণনা করেছি।

মেমরি ও তথ্য পুনরুদ্ধার

একটি language model-এর নিজস্ব কোনো memory থাকে না। প্রতিটি call-এ বর্তমান task সম্পর্কে model-এর জানা সবকিছু আবার দিতে হয়। ছোট কাজের ক্ষেত্রে এটি সমস্যা নয়, কারণ পুরো conversation একটি request-এর মধ্যে থাকে। কতটা রাখা যাবে তা context window-এর ওপর নির্ভর করে। 24 GiB-এর কম GPU memory-যুক্ত server-এ, অথবা GPU না থাকলে, Ollama দিয়ে চালানো self-hosted model সাধারণত ছোট 4k default ব্যবহার করে। এটি নীরবে সবচেয়ে পুরোনো turn বাদ দেয়। তাই agent ভুলে যাচ্ছে বলে দোষ দেওয়ার আগে আপনার loop যে traffic তৈরি করে তার সঙ্গে মিলিয়ে num_ctx সেট করা ভালো। দীর্ঘ কাজের ক্ষেত্রে memory নিজেকেই পরিচালনা করতে হবে। এ জন্য দুটি pattern জানা দরকার।

প্রথমটি হলো scratchpad। Agent-কে এমন একটি file দিন, যা সে পড়তে ও লিখতে পারে। কাজের সময় যা শেখে, তা file-এ লিখে রাখতে তাকে বলুন। পরের turn বা পরের session-এ agent file-টি পড়ে আগের অবস্থান থেকে কাজ চালিয়ে যায়। এটি একটি সাধারণ document হিসেবে memory ব্যবহার করে। এটি কাজ করে, কারণ agent file-টিকে অন্য যেকোনো tool-এর মতোই বিবেচনা করে।

দ্বিতীয়টি হলো retrieval। Agent-এর যখন এমন বিপুল document থেকে তথ্য দরকার হয়, যা একটি request-এ কখনোই fit করবে না, তখন document-গুলো searchable form-এ সংরক্ষণ করুন। প্রয়োজনের সময় শুধু প্রাসঙ্গিক অংশগুলো model-এর view-তে আনুন। এই pattern-কে retrieval-augmented generation বা RAG বলা হয়। Agent একটি প্রশ্ন করে, আপনার code মিল থাকা অল্প কয়েকটি passage খুঁজে বের করে, এবং শুধু সেগুলো model-এ পাঠানো হয়। Store আপনার server-এ থাকে। তাই আপনার private document কখনো server ছেড়ে যায় না।

একাধিক agent, একজন coordinator

অনেক tool-সহ একজন agent অধিকাংশ কাজের জন্য যথেষ্ট। কোনো কাজ বড় হলে বা স্বাভাবিকভাবে কয়েকটি অংশে বিভক্ত হলে ভিন্ন কাঠামো বেশি কার্যকর হতে পারে: এমন একজন coordinator agent, যে বিশেষায়িত sub-agent-দের কাজ দেয়। coordinator লক্ষ্যটিকে কয়েকটি অংশে ভাগ করে, প্রতিটি অংশ সেই ধরনের কাজের জন্য তৈরি একটি sub-agent-কে দেয়, এবং ফলাফলগুলো একত্র করে। Delegation-এর জন্য অংশগুলোর মধ্যে একটি channel দরকার। এর সবচেয়ে সরল রূপটি আপনার server-এই আছে: একই VPS-এ চলা দুটি Claude Code session একে অপরকে message পাঠাতে পারে। নিজের coordination machinery তৈরি করার আগে handoff কীভাবে কাজ করে তা পরীক্ষা করার এটি একটি কম খরচের উপায়।

এর মূল সুবিধা হলো focus। সীমিত দায়িত্ব ও ছোট tool set-সহ একটি sub-agent সবকিছু একসঙ্গে সামলানো সাধারণ-purpose agent-এর তুলনায় ভালো সিদ্ধান্ত নিতে পারে। স্বাধীন অংশগুলো একই সময়ে চলতেও পারে। তবে coordination-এর খরচ বাস্তব। তাই কোনো কাজ স্পষ্টভাবে বেশি agent না চাইলে একজন agent-এই থাকুন। সহজভাবে শুরু করুন, এবং কোনো agent স্পষ্টভাবে অতিরিক্ত চাপের মধ্যে পড়লেই কেবল নতুন agent যোগ করুন।

Self-hosted নাকি hosted: আপনার agent কোন model চালাবে

Agent-এর একমাত্র অংশ হিসেবে model-কে আপনাকেই চালাতে হবে না। এটি কোথায় থাকবে, সেটিই আপনার নেওয়া সবচেয়ে বড় সিদ্ধান্ত। API-এর মাধ্যমে পাওয়া hosted model পরিচালনার কোনো ঝামেলা ছাড়াই শক্তিশালী reasoning দেয়। আপনি text পাঠান, text ফেরত পান। Self-hosted model আপনার নিজের server-এ চলে। এতে আপনার request আপনার নিয়ন্ত্রণাধীন hardware-এ থাকে। প্রতি token-এর fee-এর বদলে server-এর খরচ দিতে হয়। Model provider-এর API চালু থাকা এর ওপরও নির্ভর করতে হয় না। এই নির্ভরতা শুধু API-তে সীমাবদ্ধ নয়: বাংলাদেশ থেকে ChatGPT-এর WhatsApp নম্বরে উত্তর না আসার কারণ দেখলে বোঝা যায়, Meta-র মতো তৃতীয় পক্ষের শর্ত বদলালেও একটি hosted সেবা আপনার নাগালের বাইরে চলে যেতে পারে। বিনিময়টি হলো capability এবং effort। সেরা hosted model-গুলো আপনি নিজে চালাতে পারবেন এমন model-এর চেয়ে এগিয়ে। নিজের model চালাতে হলে সেটি রাখার জন্য পর্যাপ্ত memory দিতে হবে।

শেষের বিষয়টিই বাস্তব সীমাবদ্ধতা। একটি model আপনার server-এর memory-তে fit করতে হবে। GPU ব্যবহার করলে সেটির video memory-তেও fit করতে হবে। Hardware-এর তুলনায় বড় model load হবে না। Self-hosted agent পরিকল্পনা করার আগে আপনি যে model চান, তা আপনার machine-এ fit করে কি না পরীক্ষা করুন:

সংখ্যাগুলো না মিললে আপনার চারটি উপায় আছে: ছোট model বেছে নিন, আরও aggressive quantization ব্যবহার করে model-এর আকার কমান, বেশি memory-যুক্ত server-এ যান বা model-টি একাধিক GPU-তে ভাগ করুন, অথবা reasoning-এর জন্য hosted API ব্যবহার করে শুধু tools এবং data server-এ রাখুন। অনেক self-hosted agent VPS-এ Ollama ব্যবহার করে local model দিয়ে শুরু করে এবং সবচেয়ে কঠিন ধাপগুলোর জন্য hosted API-তে fallback করে।

সার্ভারই সবচেয়ে ঝুঁকিপূর্ণ অংশ

যে agent shell command চালাতে এবং file লিখতে পারে, সেটি শক্তিশালী। আর এ কারণেই এটি ঝুঁকিপূর্ণ। Model-এর বিচারক্ষমতা ভালো হলেও নিখুঁত নয়। ভুল instruction, bug বা ক্ষতিকর input একটি সহায়ক agent-কে এমন agent-এ পরিণত করতে পারে, যা ভুল file মুছে ফেলে বা গোপন তথ্য ফাঁস করে। Security ব্যবস্থা ঐচ্ছিক নয়। Server-এর ক্ষেত্রে এটিই সবচেয়ে গুরুত্বপূর্ণ অংশ।

কয়েকটি অভ্যাসেই বেশিরভাগ সুরক্ষা নিশ্চিত করা যায়। Agent-কে dedicated unprivileged user হিসেবে চালান, কখনো root হিসেবে নয়। এতে কোনো ভুলের ক্ষতির সীমা নির্ধারিত থাকে। একই যুক্তি unprivileged user হিসেবে service চালানো-এর ক্ষেত্রেও প্রযোজ্য। API key-এর মতো secret code-এর বাইরে রাখুন এবং শুধু ওই user যেন সেগুলো পড়তে পারে, তা নিশ্চিত করুন। System-এ পরিবর্তন করে এমন tool-গুলো sandbox করুন, যাতে agent শুধু সত্যিই প্রয়োজনীয় resource-এ পৌঁছাতে পারে। প্রতিটি check নিজে লিখতে না চাইলে ইনস্টল করার মতো DeepSeek Harness plugin একই কাজের ready-made উপাদান দেয়: tool permission rule, prompt injection scanning এবং agent বন্ধ হওয়ার আগে কত খরচ করতে পারবে তার সীমা। বাস্তব self-hosted agent harden করার একটি পূর্ণ উদাহরণের জন্য VPS-এ OpenClaw নিরাপদে চালানো দেখুন। Intelligence-এর জন্য hosted model ব্যবহার করতে চাইলে VPS-এ Claude দিয়ে agent তৈরি করা সহায়ক guide-এ একই ধারণা একটি নির্দিষ্ট model-এর সঙ্গে প্রয়োগ করা হয়েছে।

একটি পূর্ণ উদাহরণ হিসেবে OpenClaw-ধরনের personal agent তৈরি করা এই উপাদানগুলো একসঙ্গে প্রয়োগ করে। আর তৈরি agent চালাতে চাইলে VPS-এ Hermes Agent self-host করা অথবা নিজের server-এ Agent Zero চালানো দিয়ে শুরু করুন। 2026 সালের সেরা self-hosted AI agent-এ আমরা আলোচিত সব ready-made option পাশাপাশি তুলনা করেছি।

FAQ

AI agent এবং chatbot-এর মধ্যে পার্থক্য কী?

একটি chatbot একটি বার্তার উত্তর দিয়ে থেমে যায়। একটি agent একটি loop চালায়: model একটি action নির্ধারণ করে, আপনার code সেটি কার্যকর করে, ফলাফল আবার model-এর কাছে যায়, এবং task সম্পূর্ণ না হওয়া পর্যন্ত এই প্রক্রিয়া চলতে থাকে। পার্থক্য হলো, একটি agent তার প্রতিটি ধাপের মধ্যে বাস্তব action গ্রহণ করে। এটি শুধু text তৈরি না করে file পড়তে, command চালাতে বা service query করতে tool ব্যবহার করে।

VPS-এ AI agent চালাতে কি GPU দরকার?

শুধু model নিজে host করলে GPU দরকার। agent loop, tool এবং memory সাধারণ code; এগুলো GPU ছাড়াই সাধারণ VPS-এ ভালোভাবে চলে। নিজের hardware-এ language model চালাতে চাইলে GPU গুরুত্বপূর্ণ, কারণ model-কে memory-তে fit করতে হয়। API-এর মাধ্যমে hosted model ব্যবহার করলে ভারী computation অন্যত্র হয়, তাই একটি সাধারণ VPS-ই যথেষ্ট।

MCP কী এবং agent তৈরি করতে কি এটি দরকার?

MCP, অর্থাৎ Model Context Protocol, agent-কে tool ও data source-এর সঙ্গে সংযুক্ত করার একটি open standard। এটি কঠোরভাবে প্রয়োজনীয় নয়, কারণ প্রতিটি tool নিজে লিখতে পারেন। MCP এই কাজ কমিয়ে দেয়। এর মাধ্যমে সাধারণ service-এর জন্য বিদ্যমান server পুনরায় ব্যবহার করা যায় এবং নিজের system একবার expose করলে যেকোনো agent সেটি ব্যবহার করতে পারে। Integration-এর সংখ্যা বাড়লে এটি একটি কার্যকর সুবিধায় পরিণত হয়।

AI agent-কে কি আমার server-এ access দেওয়া নিরাপদ?

Containment ব্যবহার করলে এটি নিরাপদ হতে পারে। যে agent command চালায়, তার নিরাপত্তা নির্ভর করে সে যে account-এর অধীনে চলে এবং আপনি যে tool অনুমোদন করেন তার ওপর। agent-কে unprivileged user হিসেবে চালান। এর secrets-এর access সীমিত রাখুন। filesystem-এ কাজ করা tool-গুলো sandbox করুন। Undo করা কঠিন এমন action-এর জন্য approval বাধ্যতামূলক করুন। agent-কে এমন untrusted code হিসেবে বিবেচনা করুন, যা শুধু তুলনামূলকভাবে বুদ্ধিমান। Task-এর জন্য যতটুকু access প্রয়োজন, শুধু ততটুকুই দিন।