ایجنٹس کے لیے ایک محفوظ ڈیلیوری پائپ لائن بنانا

زیادہ تر ایجنٹ ڈیمو ایک اہم سوال کو نظر انداز کر دیتے ہیں۔ آپ ایک خود مختار (autonomous) سسٹم کو اپنی طرف سے چیزیں بھیجنے کی اجازت کیسے دیتے ہیں بغیر اس کے کہ وہ دو بار بھیج دے یا غیر منظور شدہ کام بھیج دے؟

ڈبل-سینڈ (double-send) کوئی نایاب غلطی نہیں ہے۔ جب کوئی ورکر کام کے دوران رک جاتا ہے، تو یہ ایک سادہ کیو (queue) کا ڈیفالٹ رویہ ہوتا ہے۔ ایک ورکر پیغام بھیجتا ہے اور پھر کامیابی کا ریکارڈ درج کرنے سے پہلے کریش ہو جاتا ہے۔ سسٹم سمجھتا ہے کہ ٹاسک فیل ہو گیا ہے اور ایک نئے ورکر کو دوبارہ کوشش کرنے کا کہتا ہے۔ کسٹمر کو دو ای میلز ملتی ہیں اور آپ کو ایک سپورٹ ٹکٹ ملتا ہے۔

آپ ہر کریش کو نہیں روک سکتے۔ آپ کو ایکشن (action) اور ریکارڈ (record) کے درمیان موجود وقفے میں ہونے والے کریش کے لیے ڈیزائن کرنا چاہیے۔

کسی بھی ایسے ایجنٹ آؤٹ پٹ کے لیے جس کے حقیقی نتائج نکل سکتے ہوں، اس چھ مرحلہ وار پائپ لائن کا استعمال کریں:

• Produce: ایجنٹ مکمل آرٹفیکٹ (artifact) تیار کرتا ہے۔ یہ ابھی کچھ نہیں بھیجتا۔ • Persist: پہلے ارادے (intent) اور آرٹفیکٹ کو پائیدار اسٹوریج (durable storage) میں لکھیں۔ • Score: آؤٹ پٹ کے ساتھ ایک کانفیڈنس اسکور (confidence score) منسلک کریں۔ • Review: کم کانفیڈنس والے آئٹمز کو انسان (human) کے پاس بھیجیں۔ • Approve: ایک 'fail-closed' گیٹ استعمال کریں۔ سسٹم تمام تر بھیجنے کے عمل کو بلاک رکھتا ہے جب تک کہ کوئی انسان واضح طور پر اجازت نہ دے دے۔ • Send and Attest: آئٹم کو ایک لیز (lease) کے تحت بھیجیں، پھر ایک ثبوت کی رسید (evidence receipt) لکھیں۔

ہر مرحلہ ایک الگ پائیدار تبدیلی (durable transition) ہونا چاہیے۔ اسٹیٹ (state) آپ کے ڈیٹا بیس میں ہونی چاہیے، ورکر کی میموری میں نہیں۔

ڈپلیکیٹس سے بچنے کے لیے، رو-لیول لیزنگ (row-level leasing) کا استعمال کریں۔ Postgres میں، SELECT ... FOR UPDATE SKIP LOCKED استعمال کریں۔ یہ اس بات کو یقینی بناتا ہے کہ ایک وقت میں صرف ایک ہی ورکر ایک ٹاسک کا مالک ہو۔

سب سے اہم اصول یہ ہے کہ آپ ایکسپائرڈ لیز (expired leases) کو کیسے ہینڈل کرتے ہیں۔ اگر کوئی ورکر بیرونی پیغام بھیجتے وقت رک جائے، تو اسے خود بخود دوبارہ کوشش (retry) نہ کریں۔ اس کے بجائے، ٹاسک کو انسانی جائزے کے لیے چھوڑ دیں۔ ایک نظر آنے والا رکا ہوا ٹاسک، ایک غیر مرئی ڈبل-سینڈ سے بہتر ہے۔

آپ کو 'fail-closed' اصولوں پر بھی عمل کرنا چاہیے:

  • بھیجنا (Sending) ڈیفالٹ طور پر بند ہوتا ہے۔ تمام آؤٹ باؤنڈ ٹریفک کو فعال کرنے کے لیے ایک سنگل فلیگ (flag) ہونا چاہیے۔
  • شناخت (Identity) کی جانچ کی جاتی ہے۔ سسٹم کو بھیجنے کے لمحے پر بھیجنے والے کے ایڈریس اور ٹرانسپورٹ سیکیورٹی کی تصدیق کرنی چاہیے۔
  • ہر چیز کی رسید ہوتی ہے۔ ایک غیر ریکارڈ شدہ سینڈ (send) ایک ناکامی ہے۔

اسے ان کاموں کے لیے نہ بنائیں جن میں خطرہ کم ہو، جیسے کہ انٹرنل لاگز (internal logs)۔ اسے تب استعمال کریں جب ایک غلطی کی وجہ سے رقم کا نقصان ہو، قانونی مسئلہ پیدا ہو، یا سپورٹ ٹکٹ کی ضرورت پڑے۔

Source: https://dev.to/danmercede/building-a-governed-double-send-safe-delivery-pipeline-for-agent-outputs-80e

Optional learning community: https://t.me/GyaanSetuAi