Author: Yanhua
انٹونیو گلی گوگل کے انجینئرنگ ڈائریکٹر ہیں۔ انہوں نے ایک 453 صفحات کی کتاب لکھی جس میں AI ایجینٹ ترقی کو 21 ڈیزائن پیٹرنز میں تقسیم کیا گیا ہے۔
لیکن یہ ایک کتاب کا جائزہ نہیں ہے۔ میں نے اس کتاب کو پڑھنے کا اپنا ایک خاص مقصد تھا: میں نے Harness Engineering لکھا، Clawdbot کے تجربات کے بارے میں لکھا، اور "AI ایجینٹس جادو نہیں ہوتے" والے مضمون میں Token خرچ کرنے سے لے کر انہیں حقیقی طور پر استعمال کرنے تک کے ساتھ تبدیلیوں کا ذکر کیا۔ ہر بار لکھنے کے بعد ایک سوال مکمل طور پر واضح نہیں ہوتا: کیا ان چیزوں کے پیچھے ایک دوبارہ استعمال کی جا سکنے والی بنیادی منطق ہے؟
یہ کتاب نے میرے جواب دیے، اور میری توقع سے زیادہ گہرائی سے۔
شاید تم نے جو لکھا ہے وہ اصل میں ایجنٹ نہیں ہے
سب سے زیادہ طاقتور فیصلہ پریلوگ میں چھپا ہوا ہے۔
زیادہ تر لوگ جو "AI" استعمال کرتے ہیں، وہ صرف Level 0 ہیں: بے ٹول، بے یاد، بے عمل LLM۔ آپ اس سے پوچھتے ہیں کہ 2025 کا اکیڈمی ایوارڈ برائے بہترین فلم کون سی ہوگی، تو وہ اندازہ لگاتا ہے۔ کتاب میں اسے بہت واضح طور پر بتایا گیا ہے: Level 0 کی چیزیں Agent نہیں ہوتیں۔
اوپر کی طرف جانا ہی اصل ایجنٹ ہے
لیول 1: ٹول استعمال کرنے والا
ایجینٹ اب اوزار استعمال کرنے لگا ہے: تلاش، API، ڈیٹا بیس۔ لیکن اس کا صرف “انٹرفیس کال کرنا” تک ہی محدود نہیں ہے؛ بلکہ اسے خود فیصلہ کرنا چاہیے کہ کب کال کرنا ہے، کیا کال کرنا ہے، اور نتائج کو کیسے استعمال کرنا ہے۔ کتاب میں ایک بہت واضح مثال دی گئی ہے: صارف پوچھتا ہے “ہالی ووڈ میں حالیہ میں کون سی نئی سیریز آئی ہے؟”، ایجینٹ خود سمجھ جاتا ہے کہ یہ معلومات اس کے تربیتی ڈیٹا میں موجود نہیں ہیں، اس لیے وہ خود تلاش اوزار کو کال کرتا ہے، اور پھر نتائج کو ملا کر پیش کرتا ہے۔ اہم قدم “خود سمجھنا” ہے۔ یہاں کوئی انسان اسے نہیں بتا رہا کہ “تم تلاش کرو”، بلکہ یہ اس کا خود فیصلہ ہے کہ تلاش کرنے کی ضرورت ہے۔ یہ فیصلہ سازی کی صلاحیت، لیول 1 کا بنیادی دروازہ ہے۔
لیول 2: اسٹریٹجک سوچنے والے
دو چیزیں مزید شامل ہو گئیں: منصوبہ بندی اور کنٹیکس انجینئرنگ۔ کتاب میں کنٹیکس انجینئرنگ کو یوں تعریف کیا گیا ہے: معلومات کا اکٹھا کرنا نہیں، بلکہ متعلقہ معلومات کا دقت سے انتخاب، کٹنا اور پیک کرنا۔ مثال بہت اچھی ہے: صارف دو مقامات کے درمیان کافی شاپ تلاش کرنا چاہتا ہے۔ ایجنٹ پہلے نقشہ ٹول کو بلاتا ہے جس سے بہت سارے ڈیٹا حاصل ہوتے ہیں، پھر خود فیصلہ کرتا ہے کہ "اگلے مرحلے میں صرف سڑک کے نام درکار ہیں"، اور نقشہ کے نتائج کو ایک مختصر فہرست میں کاٹ دیتا ہے، جسے مقامی تلاش ٹول کو دیا جاتا ہے۔ ہر مرحلے پر معلومات کے شور کو کم کیا جا رہا ہے۔
کتاب میں ایک جملہ تھا جسے میں نے کئی بار دہرایا: "AI کو اعلیٰ درجہ کی درستگی حاصل کرنے کے لیے، اسے مختصر، مرکوز اور طاقتور متن فراہم کرنا ضروری ہے۔" Context Engineering اسی کام کو کرتا ہے۔
اس سطح تک، ایجینٹ خود کو جانچ سکتا ہے۔ کام ختم ہونے کے بعد خود اس کا جائزہ لیتا ہے، مسائل کو پہچانتا ہے اور خود درست کر لیتا ہے۔ میں بعد میں تفصیل سے بیان کروں گا۔
لیول 3: متعدد ایجنٹس کا تعاون
کتاب کا موقف واضح ہے: ایک سارے کام کرنے والا سپر ایجنٹ بنانے کی بجائے، ایک ٹیم کی طرح ڈالیں — پروجیکٹ مینیجر ایجنٹ + ریسرچ ایجنٹ + ڈیزائنر ایجنٹ + مارکیٹنگ ایجنٹ۔ کتاب میں نئے مصنوعات کے لانچ کا مثال دیا گیا ہے: ایک "پروجیکٹ مینیجر ایجنٹ" مجموعی طور پر منصوبہ بندی کرتا ہے اور "مارکیٹ ریسرچ ایجنٹ"، "پروڈکٹ ڈیزائن ایجنٹ"، "مارکیٹنگ ایجنٹ" کو کام تقسیم کرتا ہے۔ اہم بات مواصلات ہے: ایجنٹس کے درمیان ڈیٹا کس طرح شیئر ہوتا ہے، حالت کس طرح سینکرنائز ہوتی ہے، اور تنازعات کو کس طرح حل کیا جاتا ہے۔ اس حصے میں ستھرے مواصلاتی ٹوپولوجیز کے چھ نمونے دکھائے گئے ہیں، جو سب سے سادہ ایکل ایجنٹ سے لے کر سب سے زیادہ لچکدار مخصوص مخلوط تک ہیں، اور ہر ایک کے لئے مناسب سیناریوز بھی واضح کئے گئے ہیں۔
انچھوں درجات کو دیکھ کر، میں اچانک سمجھ گیا کہ لوگ "میرا ایجینٹ کام نہیں کرتا" کیوں کہتے ہیں۔ ماڈل کا مسئلہ نہیں، مسئلہ یہ ہے کہ آپ اسے ایک چیٹ بوٹ کی طرح استعمال کر رہے ہیں، جبکہ یہ شاید لیول 1 تک نہیں پہنچا۔
کنٹیکس انجینئرنگ: کتاب میں سب سے کم تقریب پائے جانے والے تصور
میں نے ایک کتاب "Harness Engineering" لکھی تھی، جس میں میں نے بتایا کہ ٹریک کی ڈیزائن، انجن کے اسباق سے زیادہ اہم ہے۔ اس کتاب کو پڑھنے کے بعد میں نے سمجھا کہ Context Engineering، prompt لیول پر Harness Engineering کا ایک مترادف ہے۔
سنتی پرامپٹ انجینئرنگ صرف "آپ کیسے پوچھتے ہیں" پر توجہ دیتی ہے۔ کتاب میں کنٹیکس انجینئرنگ "پوچھنے سے پہلے، ایجنٹ کے سامنے کیا رکھا ہوا ہے" پر توجہ دیتی ہے۔ اس میں چار سطحی معلومات شامل ہیں:
پہلا لیول، سسٹم پرامپٹ۔ یہ تعریف کرتا ہے کہ ایجینٹ کون ہے، کون سا انداز ہے، اور کن سرحدوں کے اندر ہے۔ زیادہ تر لوگ صرف اس لیول کو لکھتے ہیں۔
دوسرا لیور، باہری ڈیٹا۔ RAG کے ذریعہ حاصل کیے گئے دستاویزات، ٹول کالز کے جوابات، ریل ٹائم API ڈیٹا۔ یہ وہ جگہ ہے جہاں زیادہ تر لوگ پھنس جاتے ہیں: ڈیٹا فراہم کرنے کا احساس ہوتا ہے، لیکن یہ نہیں جانتے کہ مدل کو بھر دینے کے بجائے اسے کیسے فراہم کیا جائے۔
تیسری سطح، ضمیمہ ڈیٹا۔ صارف کی شناخت، تعامل کی تاریخ، ماحولیاتی حالت۔ وہ چیزیں جو آپ نے صاف طور پر نہیں کہیں لیکن ایجنٹ کو معلوم ہونا چاہئیے۔ مثال کے طور پر، اگر آپ ایجنٹ سے کہتے ہیں "میرے لیے جان کو ای میل بھیج کر کل کے میٹنگ کی تصدیق کرائیں"، تو اسے یہ جانا چاہئیے کہ میری کیلنڈر میں کل کی میٹنگ کیا ہے اور میرا جان سے کیا تعلق ہے۔
چوتھی سطح، فیڈ بیک لوپ۔ ہر آؤٹ پٹ کے بعد، ایجنٹ خودکار طور پر معیار کا جائزہ لیتا ہے اور اگلے کانٹیکسٹ کی حکمت عملی کو تبدیل کرتا ہے۔ کتاب اسے "آٹومیٹڈ کانٹیکسٹ آپٹیمائزیشن" کہتی ہے، جو Google کا Vertex AI Prompt Optimizer کا عملی اطلاق ہے۔
جب میں یہاں تک پڑھ رہا تھا تو میں نے اپنی پہلے لکھی گئی مضمون "AI ایجینٹس جادو نہیں ہوتے" کو یاد کیا، جس میں ایک تجربہ یہ تھا کہ "آپ کے ایجینٹ کو قواعد کی ضرورت ہے، اور بہت زیادہ قواعد۔" اب پیچھے موڑ کر دیکھوں تو، وہ قواعد بنیادی طور پر Context Engineering کا ہاتھ سے بنایا گیا ورژن تھے، جنہیں اس کتاب نے نظام کے ساتھ منظم کر دیا۔
ریفلیکشن: دو ایجینٹس ایک سے حقیقت میں بہتر ہیں
یہ میرے لیے پوری کتاب کا سب سے زیادہ عملی قیمت والی پیٹرن ہے۔
ریفلیکشن کا مرکزی خیال آسان ہے: ایجنٹ کام ختم کرنے کے بعد اپنے کام کا جائزہ لیتا ہے اور اپنی غلطیوں کو خود درست کرتا ہے۔ لیکن اس کا طریقہ کار اہم ہے۔ کتاب میں واضح طور پر کہا گیا ہے: پروڈیوسر اور کرٹک کو دو الگ ایجنٹس استعمال کرنے چاہئیں، جنہیں الگ الگ سسٹم پرامپٹ دیے جائیں۔ ایک ہی پرسونا اپنے ہی کام کا جائزہ لے گا تو ضرور خامیوں کا شکار ہوگا۔ اگر آپ ایک ہی LLM کو پہلے کوڈ لکھنے اور پھر اپنے لکھے ہوئے کوڈ کا جائزہ لینے کو کہیں، تو وہ زیادہ تر اس بات پر متفق ہو جائے گا کہ "بہت اچھا ہے"۔
کتاب میں ایک مکمل کوڈ کا مثال دیا گیا ہے۔
پروڈیوسر کا پرامپٹ ہے: "آپ ایک پائیتھن ڈویلپر ہیں، ایک فیکٹوریل کمپیوٹ کرنے والی فنکشن لکھیں جو بارڈر کنڈیشنز اور ایکسپشنز کو ہینڈل کرے۔"
کریٹک کا پرامپٹ ہے "آپ ایک بہت ہی تفصیلی سینئر انجینئر ہیں، جو کوڈ کو لائن بہ لائن جانچتے ہیں، بگس، اسٹائل، نظرانداز کردہ بارڈر کنڈیشنز، اور بہتری کے مواقع کا جائزہ لیتے ہیں۔ اگر کوڈ مکمل ہو تو
CODE_IS_PERFECTپرنٹ کریں، ورنہ تمام مسائل کی فہرست بنائیں"۔پھر ایک for لوپ ہے: پروڈیوسر کوڈ لکھتا ہے → کریٹک جانچتا ہے → پروڈیوسر تجاویز کے مطابق تبدیلی کرتا ہے → کریٹک دوبارہ جانچتا ہے → جب تک کریٹک کہتا ہے
CODE_IS_PERFECTیا زیادہ سے زیادہ تکرار کی حد پہنچ جائے۔
یہ بہت آسان ہے۔ لیکن کتاب میں ایک ایسی لاپرواہی کی گئی لاگت کا اشارہ کیا گیا ہے: ہر ریفلیکشن سائکل ایک نئی LLM کال ہوتی ہے، جتنا زیادہ تکرار کی جائے، اتنا ہی زیادہ قیمتی ہوتا ہے۔ اور جیسے جیسے مکالمہ کا تاریخی ریکارڈ بڑھتا جاتا ہے، کنٹیکسٹ ونڈو پچھلے ورژن اور تنقیدی تجاویز سے بھر جاتا ہے، جس سے عملی طور پر استعمال کے لیے دستیاب استدلال کی جگہ کم ہوتی جاتی ہے۔ اس لیے ریفلیکشن کا بہترین طریقہ یہ ہے: ایک مناسب حد تک تکرار کا تعین کریں (کتاب میں 3 استعمال کیا گیا ہے)، اور جب کرٹک خوش ہو جائے تو رک جائیں، مثال کے طور پر مکمل کرنے کی کوشش نہ کریں۔
کوڈ لکھنے کے علاوہ بھی اس کا استعمال بہت زیادہ ہے۔ مضمون لکھنا، منصوبہ بندی کرنا، دستاویزات کا خلاصہ نکالنا، منطقی مسائل حل کرنا — Producer-Critic ماڈل ان سب کے لیے استعمال کیا جا سکتا ہے۔ کتاب میں سات استعمال کے مواقع درج ہیں، جن کا بنیادی منطق ایک جیسا ہے: پہلے پیدا کریں، پھر جانچیں، اور پھر درست کریں۔
مُلتی ایجینٹ زیادہ پیچیدہ ہونا ضروری نہیں
اس فصل میں میری سب سے پسندیدہ چیز وہ ستھ کمیونیکیشن ٹاپولوجی گراف ہیں۔ بہت سے لوگ فوراً پیچیدہ چیزوں پر جاتے ہیں، لیکن اصل میں زیادہ تر صورتحال میں تین کافی ہیں:
ایکل ایجنٹ (انفرادی انجام دہی): کام کو آپس میں انحصار نہ رکھنے والے ذیلی مسائل میں تقسیم کیا جا سکتا ہے، جہاں ہر ایجنٹ اپنا کام خود سنبھالتا ہے۔ آسان، آسانی سے برقرار رکھنا۔
پیر ٹو پیر (Peer-to-Peer): ایجینٹس آپس میں ب без مرکزی کنٹرول نوڈ کے براہ راست رابطہ کرتے ہیں۔ غیر مرکزی، خرابی کا تحمل کرتا ہے، ایک ایجینٹ کے بند ہونے سے مجموعی نظام متاثر نہیں ہوتا۔ لیکن تنظیم کا اخراج زیادہ ہوتا ہے اور اس میں انتظام کی کمی ہوتی ہے۔
سپروائزر (مرکزی شیڈولنگ): ایک سپروائزر ایجینٹ کئی ورکر ایجینٹس کو مینج کرتا ہے۔ یہ کام تقسیم کرتا ہے، نتائج جمع کرتا ہے، اور تنازعات حل کرتا ہے۔ یہ سطحی ساخت کے ساتھ اچھی طرح سے مینج کیا جا سکتا ہے۔ لیکن سپروائزر ایک واحد خرابی کا نقطہ اور پرفارمنس کا بند راستہ بھی ہے۔
دوسرے تین (Supervisor-as-Tool، ہائرارکیکل، کسٹم مکس) پہلے تین کے ویریئنٹس اور کمبو ہیں۔ کتاب میں واضح طور پر کہا گیا ہے: آپ کو جو ٹوپولوجی درکار ہے، وہ آپ کے کام کی پیچیدگی پر منحصر ہے۔ جتنا زیادہ آپ کام کو چھوٹے چھوٹے حصوں میں تقسیم کرتے ہیں، اتنی زیادہ کمیونیکیشن کی لاگت ہوتی ہے، اور ایک حد تک پہنچنے پر Supervisor ماڈل حیرت انگیز طور پر ہائرارکیکل ماڈل سے زیادہ موثر ہوتا ہے۔
میرا تجربہ یہ ہے کہ بہت سے لوگ Multi-Agent بناتے وقت 80% وقت مواصلاتی معاہدے پر صرف کر دیتے ہیں، اور ایک زیادہ بنیادی سوال پوچھنا بھول جاتے ہیں: کیا یہ کام حقیقت میں متعدد Agents کی ضرورت رکھتا ہے؟ کتاب میں واضح طور پر لکھا گیا ہے کہ Level 2 کا ایک واحد Agent + Reflection عام طور پر کافی ہوتا ہے۔ Level 3 صرف ان صورتوں کے لیے ہے جہاں ایک واحد Agent حقیقت میں کام نہیں کر پاتا۔
میموری تین طبقاتی ماڈل، میں نے پہلے سے ہی اسے محسوس کیا تھا لیکن نام نہیں دیا تھا
میموری یہ ایپیسڈ میرے لیے سب سے زیادہ مطابقت رکھتی ہے، کیونکہ جب میں نے Obsidian + Claude کے دو مضامین لکھے، تو میں ہمیشہ ایک سوال پر غور کر رہا تھا: ایجینٹ کی یادداشت کو کیسے لیورل کیا جائے؟
کتاب میں جواب دیا گیا ہے:
سیشن (سیشن لییر): موجودہ بات چیت کا سیاق و سباق کا ونڈو، یہ سب سے مختصر یادداشت ہے جو بات چیت ختم ہوتے ہی ختم ہو جاتی ہے۔ لمبے سیاق و سباق والے ماڈل صرف اس ونڈو کو بڑھاتے ہیں، لیکن بنیادی طور پر یہ عارضی رہتی ہے، اور ہر استدلال میں پورے ونڈو کو پروسیس کرنا پڑتا ہے، جس سے اس کا خرچ زیادہ اور سپیدہ ہوتا ہے۔
حالت (حالت لیور): موجودہ کام کے دوران عارضی ڈیٹا۔ مثال کے طور پر، "کون سا کام کیا جا رہا ہے"، "کتنی ترقی ہو چکی ہے"، "درمیان میں کون سے ڈیٹا پیدا ہوئے"۔ سیشن سے لمبا، لیکن کام ختم ہوتے ہی صاف کر دیا جاتا ہے۔ کتاب میں گوگل ADK کے حالت مکانیزم کا مکمل مثال دیا گیا ہے۔
میموری (پرسسٹنٹ لیئر)：سیشن اور ٹاسک کے درمیان لمبی مدتی یادداشت۔ صارف کی ترجیحات، سیکھی گئی تجربات، اہم تاریخی فیصلے، ڈیٹا بیس یا ویکٹر اسٹور میں محفوظ کریں، سیمنٹک ریٹریول کے ساتھ۔ کتاب میں ایک اہم نکتہ بیان کیا گیا ہے: میموری صرف محفوظ کرنا نہیں، بلکہ "کیا محفوظ کرنا ہے، کب محفوظ کرنا ہے، اور کیسے ریٹریو کرنا ہے" کی پوری حکمت عملی کا ڈیزائن کرنا ہے۔ زیادہ محفوظ کرنے سے نوائس زیادہ ہوتا ہے، کم محفوظ کرنے سے کافی نہیں ہوتا۔
میں نے Clawdbot کے بارے میں اپنی پچھلی مضمون میں "حالت فائل" اور "کام کا شعبہ دستاویزات" کا ذکر کیا تھا، جو بنیادی طور پر State لیور اور Memory لیور کو ہاتھوں سے بنانا تھا، اور کتاب نے اس کو فریم ورک کیا ہے۔
پانچ فرضیات، جن میں پانچویں سب سے زیادہ بےحد ہے
کتاب کے آخر میں ایجنٹ کے مستقبل کے بارے میں پانچ فرضیات پیش کی گئی ہیں، جن میں پہلی چار ابھی بھی منطقی تخمینوں کے دائرے میں ہیں: جامع ایجنٹ کوڈ لکھنے سے لے کر منصوبوں کی نگرانی تک، گہری ذاتی تفصیلات کے ساتھ آپ کی ضروریات کا فعال طور پر پتہ لگانا، جسمانی ذہانت اسکرین سے باہر نکل کر فزیکل دنیا میں آ جائے، اور ایجنٹ خود مختار معاشی اکائی بن جائے۔
پانچواں جس نے مجھے حیران کر دیا: ڈیفورم ملٹی-ایجینٹ۔
آپ صرف مقصد کا اعلان کرتے ہیں، جیسے “ایک پریمیم کافی کی ای کامرس کاروبار شروع کریں۔” سسٹم خود فیصلہ کرتا ہے: پہلے “مارکیٹ ریسرچ ایجنٹ” اور “برانڈ ایجنٹ” بنائیں۔ ایک چکر کے بعد ڈیٹا چلائے جانے کے بعد، خود یہ فیصلہ کرتا ہے کہ برانڈ ایجنٹ کی ضرورت نہیں، اسے تین نئے ایجنٹس میں تقسیم کر دیا جاتا ہے: “لوگو ڈیزائن ایجنٹ”، “ویب سائٹ بنانے والا ایجنٹ”، “سلپلائی چین ایجنٹ”۔ اگر ویب سائٹ بنانے والا ایجنٹ بالکل بھیڑ ہو جائے، تو سسٹم خود بخود تین متوازی ایجنٹس بناتا ہے جو مختلف صفحات پر ایک ساتھ کام کرتے ہیں۔ پورے عمل کے دوران، سسٹم مستقل طور پر ہر ایجنٹ کے پرومپٹ کو خودکار طور پر بہتر بناتا رہتا ہے اور ٹیم کی ساخت کو بار بار دوبارہ ترتیب دیتا رہتا ہے۔
کتاب اسے "ہدف-محور، خود-تبدیل ہونے والا متعدد ایجنٹ سسٹم" کہتی ہے۔ یہ صرف آپ کے لکھے گئے منصوبے کو نہیں انجام دے رہا، بلکہ خود منصوبہ بنارہا ہے، اپنا منصوبہ خود تبدیل کررہا ہے، اور اپنی انجام دہی کی ٹیم کو خود دوبارہ تشکیل دے رہا ہے۔
یہ مجھے کارپاثی کے آٹو ریسرچ کو یاد دلاتا ہے: ایک program.md لکھیں، جس میں مقاصد، اشاریے، اور سرحدیں تعریف کی جائیں، اور "شروع" کریں۔ انسان چکر کے باہر ہوتا ہے۔ لیکن یہ کتاب مزید آگے بڑھتی ہے: ایجنٹ ٹیم کو کیسے تشکیل دیا جائے اور کیسے دوبارہ تشکیل دیا جائے، اس کا فیصلہ بھی نظام خود کرتا ہے۔ انسان صرف "کیا چاہتا ہے" اعلان کرتا ہے۔
تین ایسی چیزیں جو آپ فوراً کر سکتے ہیں
اس کتاب کو پڑھنے کے بعد، میرے پاس تین فوری عملی اقدامات ہیں:
سب سے پہلے، اپنے موجودہ ایجینٹ کو ایک مُنتقد شامل کریں۔ چاہے آپ Claude Code، CrewAI یا اپنا خود بنایا ہوا فریم ورک استعمال کر رہے ہوں، اپنے موجودہ ورک فلو کے آخر میں ایک مرحلہ شامل کریں: دوسرے ایجینٹ ( مختلف سسٹم پرومپٹ کے ساتھ) کو پچھلے مرحلے کے آؤٹ پٹ کا جائزہ لینے کے لیے متعین کریں۔ کوڈ جنریشن کے ساتھ کوڈ ریویو، مضمون لکھنے کے ساتھ حقائق کی تصدیق، منصوبہ بندی کے ساتھ عملی صلاحیت کا جائزہ۔ ایک اضافی LLM کال کے ساتھ، معیار میں عام طور پر دگنا اضافہ ہوتا ہے۔ کتاب میں مذکور Producer-Critic ماڈل فوراً استعمال کے لیے تیار ہے۔
دوسرے، صرف پرامپٹ انجینئرنگ کے بجائے کنٹیکس انجینئرنگ شروع کریں۔ اپنے ایجنٹ کو دیے گئے ہدایات کے فائل کو دوبارہ دیکھیں۔ اگر صرف "آپ کو کیا کرنا ہے" کے قوانین ہیں اور "آپ اب کس ماحول کا سامنا کر رہے ہیں" کا کنٹیکس نہیں ہے، تو اسے شامل کریں۔ ایجنٹ کو بتائیں کہ وہ اب کس پروجیکٹ میں ہے، پہلے کیا فیصلے کیے گئے، اور صارف کی ترجیحات کیا ہیں۔ کتاب میں کنٹیکس انجینئرنگ والی ایک چیپٹر اور آپ کا
AGENTS.mdایک ہی بات کے دو اظہار ہیں۔تیسری بات، فوراً Multi-Agent پر نہ جائیں۔ اپنا ایکل Agent Level 2 تک پہنچائیں: ٹولز، ریفلیکشن، اور میموری کے ساتھ۔ کتاب میں بار بار زور دیا گیا ہے کہ Level 2 کا ایکل Agent، Producer-Critic اور Context Engineering کے ساتھ، زیادہ تر عملی مناظر کو کور کر سکتا ہے۔ Level 3 واقعی متعدد شعبوں، متعدد مراحل، اور متوازی تقسیم کی ضرورت والے کاموں کے لیے تیار کیا گیا ہے۔ زیادہ تر لوگوں کا مسئلہ ایجنٹس کی کمی نہیں، بلکہ ایک ایجنٹ بھی اچھی طرح سے سیٹ نہ ہونا ہے۔
یہ کتاب 453 صفحات پر مشتمل ہے، Springer، 2025۔ کوڈ کے مثالیں LangChain/LangGraph، Google ADK، CrewAI، OpenAI API پر مشتمل ہیں۔ تعارف Google Cloud AI کے وائس پریزیڈنٹ نے لکھا ہے، اور ایک Goldman Sachs کے سی آئی او کا تجویزی تعارف بھی ہے، جو حیرت انگیز طور پر اچھا ہے۔
لیکن میں اس کی تجویز اس لیے کرتا ہوں کہ "جامع" نہیں ہے۔ آپ پڑھنے کے بعد ایک بات واضح ہو جائے گی: آپ نے پچھلے چھ ماہ میں Agent پر جو مسائل کھائے، ان کا کوئی ایک نے پہلے ہی نمونہ تیار کر دیا ہے۔ آپ کو Reflection کو دوبارہ دریافت کرنے کی ضرورت نہیں، Memory کو کس طرح لیورلز میں تقسیم کرنا ہے اس کا اندازہ لگانے کی ضرورت نہیں، اور Multi-Agent کے لیے کون سا مواصلاتی ٹاپولوجی استعمال کرنا ہے اسے آزمانے کی ضرورت نہیں۔
کسی نے آپ کے لیے نقشہ بنادیا ہے، باقی صرف چلنا ہے۔
کیا آپ AI ایجینٹ کے ساتھ ترقی کر رہے ہیں؟ آپ کا موجودہ ایجینٹ کس لیول پر ہے؟