AI agents کی اقسام: کون سا agent آپ کے لیے ہے؟

AI agents کی اقسام

AI agents کی اقسام ایک ہی درجہ بندی سے آتی ہیں: simple reflex، model-based reflex، goal-based، utility-based، اور learning agents۔ ہر نام ایک بات بیان کرتا ہے: agent اپنے عمل سے پہلے کتنی معلومات یاد رکھتا ہے اور کتنی دور تک منصوبہ بندی کرتا ہے۔ مزید دو اصطلاحات، multi-agent اور hierarchical، اس بات کی وضاحت کرتی ہیں کہ متعدد agents کو آپس میں کیسے مربوط کیا جاتا ہے، نہ کہ یہ کہ ان میں سے کوئی ایک agent فیصلہ کیسے کرتا ہے۔

یہ فہرست آپ کے استعمال کردہ ہر model سے پرانی ہے۔ یہ معیاری AI textbook سے آئی ہے، اور large language models کے آنے کے بعد بھی برقرار رہی، کیونکہ یہ وہ سوال اٹھاتی ہے جو اب بھی آپ کے design کا فیصلہ کرتا ہے: کسی چیز کو عمل کرنے سے پہلے کیا جاننے کی ضرورت ہے؟ اگر آپ ابھی یہ سمجھنے کی کوشش کر رہے ہیں کہ agent کہاں ختم ہوتا ہے اور chat assistant کہاں سے شروع ہوتا ہے تو پہلے AI agent اور اس کے زیرِ استعمال LLM کے درمیان فرق پڑھیں۔ یہ صفحہ اس نکتے کے بعد شروع ہوتا ہے۔

سادہ reflex agents: ایک شرط، ایک عمل

سادہ reflex agent موجودہ input کو ایک action سے map کرتا ہے اور پہلے کی کسی چیز کی memory نہیں رکھتا۔ اگر temperature 25 سے زیادہ ہو تو fan آن کریں۔ پورا mechanism یہی ہے۔

آپ نے تقریباً یقینی طور پر ایسا agent چلایا ہے۔ ایسا webhook جو n8n workflow کو trigger کرتا ہے، form submission پڑھتا ہے اور database میں ایک row لکھتا ہے، سادہ reflex agent ہے۔ یہ اس وقت بھی سادہ reflex agent رہتا ہے جب درمیان میں language model موجود ہو جو اس row کے لیے category منتخب کرے۔ اگر آپ اس سے پوچھیں کہ اس نے ایک گھنٹہ پہلے کیا کیا تھا تو وہ نہیں بتا سکتا، کیونکہ کسی چیز نے یہ جواب محفوظ نہیں رکھا۔

یہ قسم توقع سے زیادہ مرتبہ درست ثابت ہوتی ہے۔ اسے چلانے کی لاگت کم ہوتی ہے، اور اس کی failure واضح ہوتی ہے: شرط پوری ہوئی یا نہیں ہوئی۔ جب کام واقعی "X آئے تو Y کریں" ہو، تو memory غلطی کے مزید مواقع پیدا کرتی ہے اور کوئی فائدہ نہیں دیتی۔ webhook سے trigger ہونے والا n8n agent taxonomy کی اسی قسم میں آتا ہے، جس کے اوپر user interface موجود ہو۔

یہ اسی وقت ناکام ہو جاتا ہے جب درست action کا انحصار history پر ہو۔ thread state کے بغیر reply bot تیسرے message پر خود سے تضاد کرے گا، کیونکہ پہلے دو messages کبھی اس کے input کا حصہ ہی نہیں تھے۔

ایونٹس کے درمیان state برقرار رکھنا: model-based reflex agents

Model-based reflex agent اپنے ماحول کی اندرونی تصویر رکھتا ہے اور نئی input آنے پر اس تصویر کو update کرتا ہے۔ یہاں "model" سے مراد دنیا کا model ہے، neural network نہیں۔ یہ اصطلاح موجودہ مفہوم سے تقریباً چالیس سال پہلے رائج تھی، اور پہلی بار پڑھنے پر تقریباً ہر شخص کو الجھا دیتی ہے۔

گھر کی automation کا وہ rule جو بیس منٹ تک motion نہ ہونے کے بعد lights بند کر دیتا ہے، model-based ہے۔ ایسا ہونا ضروری ہے۔ "ابھی motion نہیں ہے" اور "21:40 سے motion نہیں ہے" ایک سادہ reflex agent کے لیے ایک ہی input ہیں، اس لیے صرف محفوظ شدہ state ہی دونوں میں فرق بتا سکتی ہے۔

LLM کے تناظر میں یہ کوئی بھی agent ہے جس کے پیچھے memory store موجود ہو: گفتگو کا مسلسل update ہونے والا summary، یا سادہ markdown file جسے agent ہر run کے آغاز میں پڑھتا ہے۔ agent کے لیے local memory service اسی خیال کو packaged شکل میں پیش کرتی ہے۔ mechanism تبدیل نہیں ہوتا۔ agent کی دنیا کے بارے میں تصویر اس event سے زیادہ دیر تک برقرار رہتی ہے جس نے اسے پیدا کیا تھا۔

state کی ایک قیمت ہوتی ہے۔ پرانی ہو چکی fact، کسی fact کے نہ ہونے سے زیادہ نقصان دہ ہے، کیونکہ agent بغیر کسی warning کے پورے اعتماد کے ساتھ اسی پر عمل کرتا ہے۔ جو بھی چیز آپ store کریں، اس کے expire ہونے یا دوبارہ verify ہونے کا کوئی طریقہ ہونا چاہیے، ورنہ agent اس server کے بارے میں reasoning جاری رکھے گا جسے آپ نے March میں decommission کر دیا تھا۔

Goal-based ایجنٹس: ایسی حالت تک منصوبہ بندی جس کی جانچ کی جا سکے

Goal-based agent کو ایک target state دی جاتی ہے، پھر یہ اس تک پہنچنے والے actions کا سلسلہ تلاش کرتا ہے۔ یہ اس مقام سے الٹا کام کرتا ہے جہاں اسے پہنچنا ہو، اس لیے راستہ پہلے سے لکھا ہوا نہیں ہوتا۔

Coding agent اس کی سب سے واضح مثال ہے جسے آپ خود چلا سکتے ہیں۔ "Failing test کو pass کرائیں" میں کسی file یا step کا نام نہیں ہوتا۔ Agent test پڑھتا ہے، plan بناتا ہے، کسی چیز میں ترمیم کرتا ہے، test چلاتا ہے، error پڑھتا ہے، اور دوبارہ کوشش کرتا ہے۔ یہ loop ایسے check پر ختم ہوتا ہے جسے agent واقعی execute کر سکتا ہے؛ اسی لیے یہ ہدایت کام کرتی ہے، جبکہ "اس code کو بہتر بنائیں" کام نہیں کرتی۔ جس goal کا agent جائزہ لے سکتا ہے، agent اس تک پہنچ سکتا ہے۔ جس goal کا agent جائزہ نہیں لے سکتا، وہ bill کے ساتھ ایک نہ ختم ہونے والا loop بن جاتا ہے۔ اپنے VPS پر coding agent چلانا اس loop کو ایسی جگہ چلاتا ہے جہاں یہ آپ کے laptop کو مصروف کیے بغیر بار بار کام کر سکتا ہے۔

لاگت اسی row میں شامل ہوتی ہے۔ ہر planning step ایک اور model call ہوتا ہے جس میں اب تک کی history شامل ہوتی ہے، اس لیے دس steps والا task ایک step کی قیمت کا صرف دس گنا نہیں ہوتا، بلکہ اس سے زیادہ مہنگا ہوتا ہے۔ اصل engineering loop کی ساخت اور اسے روکنے والی condition میں ہوتی ہے، اور یہی loop engineering کا موضوع ہے۔

اچھی کئی جوابات میں سے انتخاب کرنے والے utility-based agents

Goal binary ہوتا ہے۔ Utility ایک score ہوتی ہے۔ utility-based agent کو کئی قابلِ قبول نتائج میں سے انتخاب کرنا ہوتا ہے، اور وہ آپ کے لکھے ہوئے function کے مطابق سب سے زیادہ score والا نتیجہ منتخب کرتا ہے۔

ایسا backup job جسے working day شروع ہونے سے پہلے مکمل ہونا ہو، لیکن uplink پر ضرورت سے زیادہ بوجھ بھی نہ ڈالنا ہو، ایک utility problem ہے۔ اس کا کوئی واحد درست جواب نہیں ہوتا؛ صرف trade-off ہوتا ہے۔ ایسا router بھی اسی نوعیت کا مسئلہ حل کرتا ہے جو price اور answer quality کا موازنہ کرتے ہوئے فیصلہ کرتا ہے کہ ہر request کو کون سا model handle کرے۔

Algorithm مشکل حصہ نہیں ہے۔ مشکل حصہ ایک دیانت دار utility function لکھنا ہے۔ اگر score صرف cost کی بنیاد پر دیں گے تو ہر request کے لیے سب سے سستا model منتخب ہوگا، حتیٰ کہ اس request کے لیے بھی جسے مہنگے model کی ضرورت تھی۔ System بالکل اسی چیز کو optimise کرتا ہے جسے آپ نے measure کیا ہے۔ مسئلہ اس وقت پیدا ہوتا ہے جب measure کی گئی چیز اس لیے منتخب کی گئی ہو کہ اسے measure کرنا آسان تھا۔

Learning agents: وہ قسم جس کے بارے میں زیادہ تر لوگ سمجھتے ہیں کہ ان کے پاس پہلے ہی موجود ہے

Learning agent ماضی کے نتائج سے ملنے والی feedback کی بنیاد پر اپنا رویہ تبدیل کرتا ہے۔ اسے ایک ایسے جزو کی ضرورت ہوتی ہے جو outcome کا جائزہ لے، اور ایک ایسے جزو کی جو اس کے جواب میں policy تبدیل کرے۔

بہت کم self-hosted systems اس معیار پر پورے اترتے ہیں۔ جو agent گزشتہ ہفتے لکھی ہوئی notes پڑھتا ہے، وہ memory file رکھنے والا model-based agent ہے۔ اس کے weights وہی رہتے ہیں۔ اس کی policy بھی وہی رہتی ہے۔ Retrieval، learning نہیں ہے، اور یہ فرق عملی اہمیت رکھتا ہے: memory-based system اس وقت تک غلطی دہراتا رہتا ہے جب تک کوئی memory میں ترمیم نہ کرے، جبکہ learning system سے توقع ہوتی ہے کہ وہ وہ غلطی دوبارہ کرنا بند کر دے۔

اگر آپ learning والا حصہ چاہتے ہیں تو پہلے evaluation بنائیں۔ ایک scored test set، اس کے خلاف اپنی تبدیلی کا run، اور تبدیلی برقرار رکھنے یا مسترد کرنے کا فیصلہ ایک closed loop بناتے ہیں، جس میں learning component آپ خود ہوتے ہیں۔ یہ جتنا آسان سنائی دیتا ہے، اس سے زیادہ سست عمل ہے، اور آج self-hosted components پر کام کرنے والا یہی واحد طریقہ ہے۔ eval harness کی self-hosting کا آغاز یہیں سے ہوتا ہے۔

کثیر ایجنٹ اور درجہ بند نظام: اقسام نہیں بلکہ ترتیبیں

یہ چھٹی اور ساتویں قسم نہیں ہیں۔ یہ صرف بتاتے ہیں کہ ایجنٹس کس طرح ترتیب دیے گئے ہیں۔

کثیر ایجنٹ نظام مشترکہ ماحول، مثلاً queue یا git repository، میں بیک وقت کئی ایجنٹس چلاتا ہے۔ ماحول مشترکہ ہونے کی وجہ سے ایجنٹس اس میں ایک دوسرے سے ٹکراتے ہیں۔ ایک ہی فائل میں دو ایجنٹس کی ترمیم اس خرابی کی عام مثال ہے، اور اس کا حل lock یا work queue ہے۔ کوئی prompt اس مسئلے کو حل نہیں کرتا۔

درجہ بند نظام میں workers کے اوپر ایک supervisor ہوتا ہے۔ supervisor کام کو حصوں میں تقسیم کرتا ہے، یہ حصے workers کو دیتا ہے، اور واپس آنے والے نتائج کو یکجا کرتا ہے۔ یہ طریقہ مقبول ہے کیونکہ یہ لوگوں کے کام تقسیم کرنے کے انداز سے مطابقت رکھتا ہے، لیکن مہنگا ہے کیونکہ supervisor کا context ہر پڑھی گئی report کے ساتھ بڑھتا جاتا ہے۔ کثیر ایجنٹ harness عملی wiring دکھاتا ہے۔

ایک ایسا ایجنٹ جو کام کرتا ہو، ان چار ایجنٹس سے بہتر ہے جو زیادہ تر کام کرتے ہوں۔

ہر handoff میں معلومات ضائع ہونے کا امکان ہوتا ہے۔ ایک loop سے آغاز کریں۔ اسے صرف اس وقت تقسیم کریں جب آپ واضح طور پر بتا سکیں کہ bottleneck کون سا step ہے۔

تقریباً ہر حقیقی نظام hybrid کیوں ہوتا ہے

ایک deployment agent پر غور کریں جسے آپ خود چلا سکتے ہیں۔ ایک webhook اسے شروع کرتا ہے، اس لیے یہ reflex-based ہے۔ یہ موجودہ release state پڑھتا ہے، اس لیے یہ model-based ہے۔ یہ running version سے target version تک کے مراحل کی منصوبہ بندی کرتا ہے، اس لیے یہ goal-based ہے۔ یہ موجودہ load کی بنیاد پر rollout window منتخب کرتا ہے، اس لیے یہ utility-based ہے۔ یہ اپنی policy میں کبھی ترمیم نہیں کرتا، اس لیے یہ learning-based نہیں ہے۔

ایک ہی نظام taxonomy کی چار rows میں بیک وقت آتا ہے۔ Taxonomy کی اصل افادیت مکمل product کے label کے طور پر نہیں، بلکہ design checklist کے طور پر ہے۔ جب نظام غلط برتاؤ کرے تو مفید سوال یہ ہے کہ کون سی layer غلط ہے۔ غلط event پر fire ہونے والا trigger، stale ہو چکی state، ایسا goal check جو کبھی pass نہیں ہو سکتا، اور ایسا score جو غلط outcome کو reward کرتا ہے—یہ چار مختلف bugs ہیں اور ان کے fixes بھی چار مختلف ہیں۔

کون سی قسم کس کام کے لیے موزوں ہے

• trigger اور response دونوں مقرر ہوں، اور سابقہ معلومات درکار نہ ہوں: simple reflex۔
• درست response کا انحصار اس بات پر ہو کہ پہلے کیا ہوا تھا: model-based reflex۔
• آخری حالت کی جانچ ممکن ہو، لیکن راستہ پہلے سے معلوم نہ ہو: goal-based۔
• کئی قابلِ قبول نتائج موجود ہوں اور ان کے درمیان حقیقی trade-off ہو: utility-based۔
• نتائج کو وقت کے ساتھ بہتر بنانا ہو: eval loop بنائیں، اور یہ تسلیم کریں کہ learning component آپ خود ہیں۔

کیا آپ ان ایجنٹس کو خود host کر سکتے ہیں، اور اس کی لاگت کتنی ہے؟

جی ہاں، اور لاگت دو حصوں میں تقسیم ہوتی ہے۔ Orchestration سستی ہوتی ہے۔ n8n instance یا Python میں agent loop اپنی زیادہ تر زندگی network calls کا انتظار کرتے گزارتا ہے، اس لیے 2 vCPU اور 4 GB RAM کافی ہوتے ہیں۔ اصل خرچ model پر آتا ہے۔

اگر agent hosted API کو call کرتا ہے تو server کو تقریباً کسی خاص resource کی ضرورت نہیں ہوتی، اور bill tokens کی تعداد کے ساتھ بڑھتا ہے۔ Goal-based agent کے لیے اس کا مطلب ہے کہ لاگت planning steps کی اجازت دی گئی تعداد کے ساتھ بڑھتی ہے، اس لیے loop کی حد مقرر کریں۔

اگر آپ model اپنے hardware پر چلاتے ہیں تو RAM یہ طے کرتی ہے کہ آپ سرے سے کیا چلا سکتے ہیں۔ ذیل کے اعداد و شمار August 2026 تک 4-bit quantised weights کے عام طور پر شائع شدہ file sizes ہیں۔ ان کے ساتھ total RAM کے لیے planning figure بھی دیا گیا ہے، کیونکہ context window اور runtime دونوں کو weights کے علاوہ اضافی جگہ درکار ہوتی ہے۔

[
  {
    "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 پر 8B model کے weights تقریباً 4.9 GB ہوتے ہیں، اور 10 GB RAM والا box اسے swapping کے بغیر چلا لیتا ہے۔ اسی quantisation پر 70B model کے weights 43 GB ہوتے ہیں، اور اسے تقریباً 64 GB RAM درکار ہوتی ہے۔ غور کریں کہ ان اعداد میں کیا شامل نہیں: speed۔ GPU کے بغیر VPS پر 4-bit کا 8B model فی second چند tokens پیدا کرتا ہے۔ رات بھر queue پر کام کرنے والے agent کے لیے یہ کافی ہے، لیکن کسی ایسے کام کے لیے سست ہے جس کے نتیجے کا انسان انتظار کر رہا ہو۔ Local inference کو batch work تک محدود رکھیں، اور interactive حصوں کے لیے GPU یا API استعمال کریں۔ خود host کیے جانے والے AI agents کی مختصر فہرست میں بتایا گیا ہے کہ کون سے projects disk space کے قابل ہیں، جبکہ 2026 میں agents کے لیے learning path میں بتایا گیا ہے کہ کیا کچھ کس ترتیب سے سیکھنا چاہیے۔

جہاں درجہ بندی مزید مددگار نہیں رہتی

اس میں tools یا permissions کے بارے میں کچھ نہیں بتایا گیا۔ درسی کتاب میں بیان کردہ agents ادراک کرتے اور عمل کرتے ہیں۔ اس باب کو لکھنے والے کسی شخص کو اس بات کی فکر نہیں تھی کہ کسی agent کے پاس production API token ہو سکتا ہے۔ shell access رکھنے والا goal-based agent اور صرف read-only database connection رکھنے والا goal-based agent جدول کی ایک ہی صف میں آتے ہیں، لیکن ان کا خطرہ بالکل مختلف ہوتا ہے۔ پہلے یہ طے کریں کہ agent کو کن چیزوں تک رسائی حاصل ہو سکتی ہے، پھر یہ طے کریں کہ اسے کتنا ذہین ہونا چاہیے۔ کسی credential کے حوالے کرنے سے پہلے AI agent سے secrets کو دور رکھنے کا طریقہ پڑھیں۔

اس میں یہ بھی نہیں بتایا گیا کہ کوئی step ناکام ہونے پر کیا ہوتا ہے۔ حقیقی agents اپنے runtime کا زیادہ تر حصہ errors کو handle کرنے میں صرف کرتے ہیں: مثلاً rate limit کا سامنا کرنا یا کسی tool کا ایسا نتیجہ واپس کرنا جس کی model کو توقع نہ ہو۔ یہی code طے کرتا ہے کہ آپ کا system قابل استعمال ہے یا نہیں، لیکن taxonomy کی کوئی صف اس کی وضاحت نہیں کرتی۔

FAQ

AI agents کی پانچ اقسام کیا ہیں؟

Simple reflex، model-based reflex، goal-based، utility-based، اور learning agents۔ ان کی ترتیب اس بنیاد پر ہے کہ agent کارروائی سے پہلے کتنا جانتا ہے۔ Simple reflex agent صرف موجودہ input دیکھتا ہے۔ Model-based agent اپنے ماحول کی state محفوظ رکھتا ہے۔ Goal-based agent ہدفی state تک پہنچنے کی منصوبہ بندی کرتا ہے۔ Utility-based agent کئی قابلِ قبول نتائج کی درجہ بندی کرتا ہے اور سب سے زیادہ اسکور والا نتیجہ منتخب کرتا ہے۔ Learning agent feedback کی بنیاد پر اپنی policy تبدیل کرتا ہے، جو تقریباً کسی بھی self-hosted setup میں عملاً نہیں ہوتا۔

سادہ automation کے لیے مجھے کس قسم کا AI agent استعمال کرنا چاہیے؟

Simple reflex agent، جس کا عملی مطلب ایک webhook یا schedule ہے جو fixed sequence کو trigger کرتا ہے۔ اگر درست response صرف ابھی موصول ہونے والے input پر منحصر ہے تو memory failure modes بڑھاتی ہے، کوئی نئی capability نہیں دیتی۔ Model-based design اس وقت اختیار کریں جب آپ ایک ایسے فیصلے کی نشاندہی کر سکیں جس کے لیے یہ جاننا ضروری ہو کہ پہلے کیا ہوا تھا۔

کیا میں اپنے AI agents کو VPS پر چلا سکتا ہوں؟

ہاں۔ Orchestration layer ہلکی ہوتی ہے، اس لیے 2 vCPU اور 4 GB RAM والا VPS workflow engine یا agent loop کو آسانی سے چلا سکتا ہے۔ اصل فیصلہ یہ ہے کہ model کہاں چلے گا۔ Hosted API server کو چھوٹا رکھتی ہے اور لاگت tokens میں منتقل کر دیتی ہے۔ Local model کو اس کے parameter count کے تناسب سے RAM درکار ہوتی ہے، اور GPU کے بغیر یہ single-digit tokens per second پیدا کرتا ہے۔ یہ chat window کے بجائے queued batch work کے لیے زیادہ موزوں ہے۔

کیا large language model بذاتِ خود AI agent ہوتا ہے؟

نہیں۔ Model input text کو output text میں تبدیل کرتا ہے اور پھر رک جاتا ہے۔ یہ اس وقت agent بنتا ہے جب کوئی wrapper اسے ایسے loop میں شامل کرے جو دنیا پر کارروائی کر سکے اور نتیجہ دوبارہ loop کو دے سکے۔ اس کے لیے ایسے tools درکار ہوتے ہیں جنہیں یہ call کر سکے، اور ایسی condition بھی جو loop کو بتائے کہ کب رکنا ہے۔ Wrapper ہی agent ہوتا ہے۔ Model اس کے اندر موجود ایک component ہوتا ہے۔

کیا مجھے multi-agent system کی ضرورت ہے؟

عام طور پر نہیں۔ کئی tools کے ساتھ ایک single loop زیادہ تر کام سنبھال لیتا ہے اور اس کی debugging بھی بہت آسان ہوتی ہے۔ Multiple agents اس وقت مفید ہوتے ہیں جب task کے حصے واقعی ایک دوسرے سے independent ہوں اور بیک وقت چل سکتے ہوں، یا جب کسی ایک حصے کے لیے مختلف model درکار ہو۔ اس کی قیمت coordination ہے: shared state، اور ایسا supervisor جس کا context ہر worker report پڑھنے کے ساتھ بڑھتا جاتا ہے۔ دوسرا agent اس وقت شامل کریں جب آپ اس step کی نشاندہی کر سکیں جو سست ہے۔