AI agent-এর ধরন: কোনটি কী কাজে লাগে এবং self-host করা যায়

AI agent-এর ধরন

AI agent-এর ধরন একটি taxonomy থেকে এসেছে: simple reflex, model-based reflex, goal-based, utility-based এবং learning agent। প্রতিটি নাম একটি বিষয় নির্দেশ করে—agent কতটা তথ্য মনে রাখে এবং কাজ করার আগে কতটা ভবিষ্যৎ পরিকল্পনা করে। আরও দুটি শব্দ, multi-agent এবং hierarchical, একক agent কীভাবে সিদ্ধান্ত নেয় তার পরিবর্তে একাধিক agent কীভাবে পরস্পরের সঙ্গে যুক্ত থাকে তা বর্ণনা করে।

এই তালিকা আপনি ব্যবহার করা প্রতিটি model-এর চেয়েও পুরোনো। এটি standard AI textbook থেকে এসেছে। large language model আসার পরও এটি কার্যকর রয়েছে, কারণ এটি এমন একটি প্রশ্ন করে যা আজও আপনার design নির্ধারণ করে: কোনো কিছু কাজ করার আগে তাকে কী জানতে হবে? কোনো agent কোথায় শেষ হয় এবং chat assistant কোথা থেকে শুরু হয়, তা যদি এখনও নির্ধারণ করে থাকেন, আগে AI agent এবং এটি যে LLM-এ চলে তার মধ্যে পার্থক্য পড়ুন। এই পৃষ্ঠা সেই বিষয়ের পরের অংশ থেকে শুরু হয়েছে।

Simple reflex agent: একটি শর্ত, একটি কাজ

Simple reflex agent বর্তমান input-কে একটি action-এর সঙ্গে মিলিয়ে দেয় এবং আগের কোনো তথ্যের memory রাখে না। তাপমাত্রা 25-এর বেশি হলে fan চালু করুন। পুরো প্রক্রিয়াটি এতটুকুই।

আপনি প্রায় নিশ্চিতভাবেই এমন agent চালিয়েছেন। একটি webhook যদি n8n workflow চালু করে, সেই workflow form submission পড়ে database-এ একটি row লেখে, তাহলে সেটি একটি simple reflex agent। মাঝখানে language model বসে ওই row-এর জন্য একটি category বেছে নিলেও agent-এর ধরন বদলায় না। এক ঘণ্টা আগে কী করেছে জিজ্ঞেস করলে agent তা বলতে পারবে না, কারণ কোনো কিছুই সেই উত্তর সংরক্ষণ করেনি।

মানুষ যতটা মনে করে, এই ধরনের agent তার চেয়ে বেশি ক্ষেত্রে সঠিক কাজ করে। এটি চালাতে খরচ কম, এবং এর ব্যর্থতার কারণ সহজে বোঝা যায়: condition মেলেছে, অথবা মেলেনি। কাজটি যদি সত্যিই "X এলে Y করুন" হয়, তাহলে memory ভুল হওয়ার অতিরিক্ত সুযোগ তৈরি করে, কিন্তু কোনো সুবিধা দেয় না। user interface-সহ একটি webhook-triggered n8n agent এই taxonomy-র একই শ্রেণির উদাহরণ।

সঠিক action যদি আগের ঘটনাগুলোর ওপর নির্ভর করে, তখন এটি ব্যর্থ হয়। thread state না থাকা একটি reply bot তৃতীয় message-এ নিজের কথার বিরোধিতা করবে, কারণ প্রথম দুটি message তার input-এর অংশই ছিল না।

ইভেন্টগুলোর মধ্যে state ধরে রাখা: model-based reflex agent

একটি model-based reflex agent তার environment-এর একটি অভ্যন্তরীণ চিত্র ধরে রাখে এবং নতুন input এলে সেই চিত্র আপডেট করে। এখানে "model" বলতে বিশ্বের একটি model বোঝানো হয়েছে, neural network নয়। বর্তমান অর্থটি প্রচলিত হওয়ার প্রায় চল্লিশ বছর আগে থেকেই এই term ব্যবহৃত হচ্ছে, তাই প্রথমবার পড়লে এটি প্রায় সবাইকে বিভ্রান্ত করে।

বিশ মিনিট কোনো motion না থাকলে lights বন্ধ করে দেয়—এমন একটি home automation rule model-based। এটি model-based হওয়াই প্রয়োজন। "এখন কোনো motion নেই" এবং "21:40 থেকে কোনো motion নেই"—একটি simple reflex agent-এর কাছে একই input। তাই শুধু সংরক্ষিত state-ই এই দুটি অবস্থার পার্থক্য জানাতে পারে।

LLM-এর ক্ষেত্রে, এর অর্থ হলো পেছনে একটি memory store থাকা যেকোনো agent: যেমন rolling conversation summary, অথবা একটি সাধারণ markdown file, যা agent প্রতিটি run-এর শুরুতে পড়ে। একটি agent-এর জন্য local memory service এই ধারণাটিকে একটি প্যাকেজে রূপ দেয়। Mechanism অপরিবর্তিত থাকে। যে event এটি তৈরি করেছিল, agent-এর বিশ্বের সেই চিত্র তার পরেও টিকে থাকে।

State-এর মূল্য আছে। পুরোনো বা ভুল fact কোনো fact না থাকার চেয়েও ক্ষতিকর, কারণ agent কোনো সতর্কতা ছাড়াই পূর্ণ আত্মবিশ্বাসে সেটির ভিত্তিতে কাজ করে। আপনি যা সংরক্ষণ করবেন, সেটির expire হওয়ার ব্যবস্থা অথবা পুনরায় যাচাই করার ব্যবস্থা থাকতে হবে। তা না হলে agent March-এ decommission করা একটি server নিয়ে reasoning চালিয়ে যাবে।

যাচাইযোগ্য অবস্থার দিকে পরিকল্পনা: লক্ষ্যভিত্তিক agent

একটি লক্ষ্যভিত্তিক agent একটি target state পায় এবং সেখানে পৌঁছানোর জন্য কাজের একটি ধারাবাহিকতা খোঁজে। কোথায় শেষ করতে হবে, সেখান থেকে এটি উল্টো দিকে কাজ করে। তাই পথটি আগে থেকে লিখে দেওয়া থাকে না।

আপনি নিজে চালাতে পারেন—এমন coding agent এর সবচেয়ে স্পষ্ট উদাহরণ। “ব্যর্থ test-টি সফল করুন” বললে কোনো file বা ধাপ নির্দিষ্ট করা হয় না। agent test পড়ে, একটি plan তৈরি করে, কিছু সম্পাদনা করে, test চালায়, error পড়ে এবং আবার চেষ্টা করে। loop এমন একটি check-এ শেষ হয়, যা agent সত্যিই চালাতে পারে। এ কারণেই এই নির্দেশটি কার্যকর, কিন্তু “এই code উন্নত করুন” কার্যকর নয়। agent যে লক্ষ্য মূল্যায়ন করতে পারে, agent সেই লক্ষ্যে পৌঁছাতে পারে। যে লক্ষ্য মূল্যায়ন করতে পারে না, সেটি bill-সহ একটি অন্তহীন loop-এ পরিণত হয়। নিজের VPS-এ coding agent চালানো এই loop-টিকে এমন জায়গায় চালায়, যেখানে এটি আপনার laptop দখল না করে বারবার কাজ করতে পারে।

এই সারিতেই খরচ জমে। প্রতিটি planning step হলো এখন পর্যন্ত জমা হওয়া history-সহ আরেকটি model call। তাই দশ ধাপের task-এর খরচ এক ধাপের খরচের দশ গুণ নয়; এর চেয়ে বেশি। গুরুত্বপূর্ণ engineering হলো loop-এর গঠন এবং যে condition সেটিকে থামায়। loop engineering-এর বিষয় এটিই।

Utility-ভিত্তিক agent: একাধিক ভালো উত্তরের মধ্যে নির্বাচন

একটি goal binary। Utility একটি score। Utility-ভিত্তিক agent একাধিক গ্রহণযোগ্য outcome-এর মধ্যে আপনার লেখা function অনুযায়ী সর্বোচ্চ score পাওয়া outcome নির্বাচন করে।

কর্মদিবস শুরু হওয়ার আগে uplink সম্পৃক্ত না করে শেষ করতে হবে—এমন একটি backup job হলো utility-র সমস্যা। এখানে একটিমাত্র সঠিক উত্তর নেই; trade-off আছে। কোন request কোন model পরিচালনা করবে তা নির্ধারণ করার সময় price ও answer quality-এর মধ্যে ভারসাম্য বিবেচনা করা একটি router-এর ক্ষেত্রেও একই ধরনের সমস্যা তৈরি করে।

Algorithm কঠিন অংশ নয়। একটি সৎ utility function লেখা কঠিন। শুধু cost-এর ভিত্তিতে score করলে প্রতিটি request-এর জন্য সবচেয়ে সস্তা model নির্বাচন হবে, এমন request-এর ক্ষেত্রেও যার জন্য ব্যয়বহুল model প্রয়োজন ছিল। System ঠিক সেটিই optimise করে যা আপনি measure করেছেন। আর আপনি যা measure করেছেন তা সহজে measure করা যায় বলে বেছে নেওয়া হলে এটি সমস্যা তৈরি করে।

লার্নিং এজেন্ট: অধিকাংশ মানুষ যে ধরনটি নিজেদের আছে বলে ধরে নেন

একটি লার্নিং এজেন্ট অতীতের ফলাফল সম্পর্কে পাওয়া feedback থেকে নিজের আচরণ পরিবর্তন করে। ফলাফল মূল্যায়ন করার জন্য তার একটি উপাদান এবং সেই মূল্যায়নের ভিত্তিতে policy পরিবর্তন করার জন্য আরেকটি উপাদান প্রয়োজন।

খুব কম self-hosted system এই সংজ্ঞা পূরণ করে। গত সপ্তাহে লেখা notes পড়ে এমন কোনো agent হলো memory file-সহ model-based agent। এর weights অপরিবর্তিত থাকে। এর policy-ও অপরিবর্তিত থাকে। Retrieval learning নয়। এই পার্থক্যটি ব্যবহারিক: memory-ভিত্তিক system-এ কোনো ভুল memory সম্পাদনা না করা পর্যন্ত বারবার পুনরাবৃত্তি হবে। কিন্তু learning system-এর ক্ষেত্রে সেই ভুল বন্ধ হওয়ার কথা।

আপনি যদি learning অংশটি চান, প্রথমে evaluation তৈরি করুন। একটি scored test set, সেটির বিরুদ্ধে আপনার পরিবর্তন চালানো, এবং পরিবর্তনটি রাখা বা বাতিল করার সিদ্ধান্ত—এই তিনটি মিলে এমন একটি closed loop তৈরি করে, যেখানে learning component হলেন আপনি। এটি শুনতে যতটা সহজ, বাস্তবে তার চেয়ে ধীর। বর্তমানে self-hosted অংশ দিয়ে কাজ করে এমন একমাত্র সংস্করণ এটিই। একটি eval harness self-host করুন এখান থেকেই শুরু হয়।

মাল্টি-এজেন্ট ও hierarchical system: বিন্যাস, ধরন নয়

এগুলো ষষ্ঠ ও সপ্তম কোনো ধরন নয়। এগুলো agent-গুলো কীভাবে বিন্যস্ত থাকে তা বর্ণনা করে।

একটি multi-agent system shared environment-এর মধ্যে একই সময়ে একাধিক agent চালায়, যেমন একটি queue বা git repository। environment shared হওয়ায় agent-গুলো সেখানে পরস্পরের কাজে বাধা সৃষ্টি করতে পারে। দুটি agent একই file সম্পাদনা করা এর প্রচলিত ব্যর্থতার উদাহরণ। এর সমাধান হলো lock বা work queue। কোনো prompt দিয়ে এই সমস্যা সমাধান করা যায় না।

একটি hierarchical system workers-এর ওপর একটি supervisor রাখে। supervisor একটি task ভাগ করে, অংশগুলো বরাদ্দ করে এবং ফিরে আসা ফলাফল একত্র করে। এটি জনপ্রিয়, কারণ এটি মানুষ যেভাবে কাজ ভাগ করে তার সঙ্গে সামঞ্জস্যপূর্ণ। তবে এটি ব্যয়বহুল, কারণ supervisor যত বেশি report পড়ে, তার context তত বড় হয়। একটি multi-agent harness বাস্তবে wiring কীভাবে করতে হয় তা দেখায়।

বেশিরভাগ সময় কাজ করে এমন চারটির চেয়ে একটি agent ভালো, যা নির্ভরযোগ্যভাবে কাজ করে।

প্রতিটি handoff-এ তথ্য বাদ পড়ার সম্ভাবনা থাকে। একটি loop দিয়ে শুরু করুন। কোন step bottleneck তা নির্দিষ্টভাবে বলতে পারলেই শুধু loop-টি ভাগ করুন।

কেন প্রায় প্রতিটি বাস্তব সিস্টেমই hybrid

আপনি নিজে চালাতে পারেন এমন একটি deployment agent বিবেচনা করুন। একটি webhook এটিকে চালু করে, তাই এটি reflex-ভিত্তিক। এটি বর্তমান release state পড়ে, তাই এটি model-based। চলমান version থেকে target version-এ যাওয়ার ধাপগুলো এটি পরিকল্পনা করে, তাই এটি goal-based। বর্তমান load দেখে এটি একটি rollout window নির্বাচন করে, তাই এটি utility-based। এটি নিজের policy কখনো পরিবর্তন করে না, তাই এটি learning নয়।

একটি সিস্টেম একই সময়ে taxonomy-এর চারটি শ্রেণিতে পড়তে পারে। Finished product-এর label হিসেবে নয়, design checklist হিসেবে taxonomy-এর ব্যবহারিক মূল্য রয়েছে। সিস্টেমটি ভুল আচরণ করলে কোন layer-এ সমস্যা হয়েছে, সেটিই কার্যকর প্রশ্ন। ভুল event-এ চালু হওয়া একটি trigger, পুরোনো হয়ে যাওয়া state, কখনো পূরণ না হওয়া একটি goal check এবং ভুল ফলাফলকে পুরস্কৃত করা একটি score—এগুলো চার ধরনের আলাদা bug, এবং প্রতিটির সমাধানও আলাদা।

কোন কাজের জন্য কোন ধরন উপযুক্ত

• Trigger এবং response নির্দিষ্ট, কোনো history প্রয়োজন নেই: simple reflex।
• সঠিক response আগে কী ঘটেছে তার ওপর নির্ভর করে: model-based reflex।
• শেষ অবস্থা যাচাই করা যায়, কিন্তু সেখানে পৌঁছানোর পথ আগে থেকে জানা নেই: goal-based।
• একাধিক গ্রহণযোগ্য outcome আছে এবং সেগুলোর মধ্যে প্রকৃত trade-off রয়েছে: utility-based।
• সময়ের সঙ্গে result উন্নত করতে হবে: একটি eval loop তৈরি করুন এবং মেনে নিন যে learning component আপনিই।

আপনি কি এই agent-গুলো নিজে host করতে পারবেন, এবং এর খরচ কত?

হ্যাঁ, পারবেন। খরচ দুটি ভাগে বিভক্ত। Orchestration-এর খরচ কম। একটি n8n instance বা Python-এ লেখা agent loop জীবনের বেশিরভাগ সময় network call-এর জন্য অপেক্ষা করে। তাই 2 vCPU এবং 4 GB RAM যথেষ্ট। মূল খরচ হয় model-এর জন্য।

Agent যদি hosted API ব্যবহার করে, server-এর প্রয়োজনীয়তা খুব কম এবং bill token-এর সংখ্যার সঙ্গে বাড়ে। Goal-based agent-এর ক্ষেত্রে আপনি যত বেশি planning step অনুমোদন করবেন, খরচও তত বাড়বে। তাই loop-এর সীমা নির্ধারণ করুন।

আপনি যদি নিজের hardware-এ model চালান, তাহলে আদৌ কী চালাতে পারবেন তা RAM নির্ধারণ করে। নিচের সংখ্যাগুলো August 2026 অনুযায়ী 4-bit quantised weight-এর সাধারণ প্রকাশিত file size। এর পাশে মোট RAM-এর একটি planning figure দেওয়া হয়েছে, কারণ context window এবং runtime-এর জন্য weight-এর অতিরিক্ত memory-ও প্রয়োজন।

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

4-bit quantisation-এ একটি 8B model-এর weight প্রায় 4.9 GB। 10 GB RAM থাকা একটি machine এটি swapping ছাড়াই চালাতে পারে। একই quantisation-এ একটি 70B model-এর weight 43 GB এবং এর জন্য প্রায় 64 GB RAM প্রয়োজন। এই সংখ্যাগুলো কী বাদ দিচ্ছে, তা লক্ষ্য করুন: speed। GPU ছাড়া VPS-এ 4-bit 8B model প্রতি second-এ এক অঙ্কের সংখ্যক token তৈরি করে। রাতভর queue প্রক্রিয়া করা agent-এর জন্য এটি যথেষ্ট, কিন্তু কোনো ব্যক্তি ফলাফলের জন্য অপেক্ষা করলে তা ধীর। Batch কাজের জন্য local inference রাখুন। Interactive অংশের জন্য GPU বা API ব্যবহার করুন। নিজে host করা যায় এমন AI agent-গুলোর সংক্ষিপ্ত তালিকা কোন project-গুলো disk space ব্যবহারের উপযুক্ত তা ব্যাখ্যা করে। আর 2026 সালে agent শেখার পথ কী ক্রমে কী শিখবেন, তা ব্যাখ্যা করে।

ট্যাক্সোনমি যেখানে আর সহায়তা করে না

এতে tool বা permission সম্পর্কে কিছু বলা নেই। পাঠ্যবইয়ের agent-গুলো perceive করে এবং কাজ করে। ওই অধ্যায়ের লেখকেরা production API token হাতে থাকা কোনো agent নিয়ে চিন্তিত ছিলেন না। shell access-সহ একটি goal-based agent এবং শুধু একটি read-only database connection-সহ আরেকটি goal-based agent টেবিলের একই সারিতে থাকে, কিন্তু তাদের ঝুঁকি সম্পূর্ণ আলাদা। কোনো agent কতটা বুদ্ধিমান হওয়া উচিত তা নির্ধারণের আগে সে কোন কোন resource-এ access পাবে তা নির্ধারণ করুন। কোনো credential দেওয়ার আগে AI agent থেকে secret কীভাবে দূরে রাখবেন পড়ুন।

কোনো step ব্যর্থ হলে কী ঘটে, সে বিষয়েও এতে কিছু বলা নেই। বাস্তব agent-গুলো runtime-এর বেশির ভাগ সময় error সামলাতে ব্যয় করে: rate limit, অথবা এমন কোনো tool যা model-এর প্রত্যাশার বাইরে কিছু return করেছে। আপনার system ব্যবহারযোগ্য হবে কি না, তা এই code নির্ধারণ করে। কিন্তু ট্যাক্সোনমির কোনো সারিই এই বিষয়টি বর্ণনা করে না।

FAQ

AI agent-এর পাঁচটি ধরন কী?

Simple reflex, model-based reflex, goal-based, utility-based এবং learning agent। Agent কাজ করার আগে কতটা তথ্য জানে, তার ভিত্তিতে এগুলো সাজানো হয়েছে। Simple reflex agent শুধু বর্তমান input দেখে। Model-based agent তার environment সম্পর্কে state সংরক্ষণ করে। Goal-based agent একটি target state-এর দিকে পরিকল্পনা করে। Utility-based agent একাধিক গ্রহণযোগ্য ফলাফলের score নির্ধারণ করে এবং সর্বোচ্চ score-টি বেছে নেয়। Learning agent feedback থেকে নিজের policy পরিবর্তন করে; বাস্তবে প্রায় কোনো self-hosted setup-ই এটি করে না।

সাধারণ automation-এর জন্য কোন ধরনের AI agent ব্যবহার করা উচিত?

Simple reflex agent। বাস্তবে এর অর্থ হলো এমন একটি webhook বা schedule, যা একটি নির্দিষ্ট sequence চালু করে। সঠিক response যদি শুধু সদ্য আসা input-এর ওপর নির্ভর করে, তাহলে memory failure-এর সম্ভাবনা বাড়ায় কিন্তু কোনো সক্ষমতা যোগ করে না। এমন পর্যায়ে model-based design ব্যবহার করুন, যখন আপনি এমন একটি decision নির্দিষ্টভাবে দেখাতে পারবেন যার জন্য আগে কী ঘটেছে তা জানা প্রয়োজন।

VPS-এ কি নিজের AI agent চালাতে পারি?

হ্যাঁ। Orchestration layer হালকা হওয়ায় 2 vCPU এবং 4 GB RAM-এ একটি workflow engine বা agent loop স্বচ্ছন্দে চালানো যায়। আসল সিদ্ধান্ত হলো model কোথায় চলবে। Hosted API ব্যবহার করলে server ছোট থাকে এবং খরচ tokens-এর ওপর স্থানান্তরিত হয়। Local model-এর জন্য parameter count-এর আনুপাতিক RAM প্রয়োজন। GPU না থাকলে এটি প্রতি সেকেন্ডে single-digit সংখ্যক token তৈরি করে। তাই এটি chat window-এর পরিবর্তে queued batch work-এর জন্য বেশি উপযোগী।

Large language model কি নিজেই একটি AI agent?

না। Model input text-কে output text-এ রূপান্তর করে এবং তারপর থেমে যায়। কোনো wrapper যখন model-কে এমন একটি loop-এর মধ্যে চালায়, যা world-এ action নিতে পারে এবং ফলাফল আবার model-কে দিতে পারে, তখন সেটি agent-এ পরিণত হয়। এর জন্য model যে tools call করতে পারবে এবং loop কখন থামবে তা জানানোর একটি condition প্রয়োজন। Wrapper-ই agent। Model হলো তার ভেতরের একটি component।

আমার কি multi-agent system প্রয়োজন?

সাধারণত নয়। একাধিক tools-সহ একটি single loop অধিকাংশ কাজ সামলাতে পারে এবং debug করাও অনেক সহজ। কোনো task-এর অংশগুলো সত্যিই independent হয়ে একই সময়ে চলতে পারলে, অথবা কোনো অংশের জন্য আলাদা model প্রয়োজন হলে multiple agent উপকারী হতে পারে। এর খরচ হলো coordination: shared state এবং এমন একটি supervisor, যার পড়া প্রতিটি worker report-এর সঙ্গে context বড় হতে থাকে। যে step ধীর, সেটি নির্দিষ্টভাবে দেখাতে পারলেই second agent যোগ করুন।