AI এজেন্ট অর্কেস্ট্রেশন: ব্যর্থতা, অনুমোদন এবং রিট্রাই

একই প্রজেক্টে একাধিক এজেন্ট কাজ করছে — শুনতে অত্যন্ত দক্ষ ব্যবস্থা মনে হয়। একটি কাজের পরিকল্পনা করে, আরেকটি ডিজাইন সামলায়, আর তৃতীয়টি কোড লেখে। সবকিছু ঠিকঠাক চলে — যতক্ষণ না আর চলে না। আর ব্যর্থতা আপনি যতটা চান তার চেয়ে অনেক বেশিবার ঘটে।

এই ব্যর্থতা প্রতিরোধ করতে সতর্ক ওয়ার্কফ্লো ইঞ্জিনিয়ারিং প্রয়োজন। তাই চলুন দেখি কোন কারণে অর্কেস্ট্রেটেড ওয়ার্কফ্লো অনির্ভরযোগ্য হয়ে ওঠে, এবং প্রোডাকশনে নির্ভরযোগ্যতার জন্য অর্কেস্ট্রেশনের সেরা পদ্ধতিগুলো জেনে নিই।

AI এজেন্ট অর্কেস্ট্রেশন একটি বহুধাপের কাজ সম্পন্ন করতে একাধিক AI এজেন্ট, মডেল ও টুলের মধ্যে সমন্বয় করে। কিন্তু কোন এজেন্ট আগে চলবে, এটি কী তথ্য পাবে এবং কাজ শেষ হওয়ার পর কী ঘটবে — তা এখনও কাউকে, বা কোনো কিছুকে, ঠিক করতে হয়। এটিই অর্কেস্ট্রেটরের ভূমিকা — ম্যানেজার হিসেবে কাজ করা একটি AI এজেন্ট, অথবা একটি সফটওয়্যার-নিয়ন্ত্রিত এক্সিকিউশন লেয়ার।

সহজ ভাষায়, একটি অর্কেস্ট্রেশন লেয়ার একটি লক্ষ্যকে ছোট ছোট কাজে ভাগ করে, নির্ভরতাগুলো ট্র্যাক করে, সঠিক এজেন্টদের কাছে এক্সিকিউশন অর্পণ করে, শেয়ার করা কনটেক্সট পরিচালনা করে এবং আউটপুটগুলো একত্র করে।

অর্কেস্ট্রেশন এক্সিকিউশন ইঞ্জিনের ডায়াগ্রাম: লক্ষ্য ও পরিকল্পনা, এজেন্টদের কাছে রাউট করা, আলাদা পরিবেশে টুল এক্সিকিউট করা, কাঠামোবদ্ধ ফলাফল, স্থায়ী ওয়ার্কফ্লো স্টেট, এবং একটি যাচাই-ও-সিদ্ধান্ত ধাপ যা পুনরায় চেষ্টা করে, আগের ধাপে ফিরে যায়, বিরতি দেয়, অপেক্ষা করে বা পরবর্তী কাজে এগিয়ে যায়।

চলুন দেখি, কোনো অর্কেস্ট্রেটরকে একটি কাজ দেওয়ার পর কী ঘটে।

Perplexity-র Computer ওয়ার্কশপ থেকে একটি উদাহরণ বিবেচনা করুন: Salesforce, Snowflake, ইমেইল, ক্যালেন্ডার ও সাম্প্রতিক খবরের তথ্য ব্যবহার করে একটি অ্যাকাউন্ট ইন্টেলিজেন্স ড্যাশবোর্ড তৈরি করা।

লক্ষ্য বোঝা এবং কাজের পরিকল্পনা করা। অর্কেস্ট্রেটর অনুরোধ করা ফলাফল দিয়ে শুরু করে এবং সেটিকে সুস্পষ্ট নির্ভরতাসহ বিভিন্ন কাজে ভাগ করে। আমাদের ড্যাশবোর্ডের উদাহরণে, এর মধ্যে রয়েছে বিভিন্ন উৎস থেকে তথ্য সংগ্রহ করা এবং সেটিকে একটি সম্পূর্ণ ডেলিভারেবলে রূপান্তর করা। প্ল্যানার নির্ধারণ করে কোন ধাপগুলো অন্য ধাপের ওপর নির্ভরশীল এবং কোনগুলো স্বাধীনভাবে চলতে পারে।
উপযুক্ত এজেন্টদের কাছে কাজ রাউট করা। অর্কেস্ট্রেটর সেসব কাজ শনাক্ত করে যেগুলোর নির্ভরতা পূরণ হয়েছে, এবং বিশেষায়িত এজেন্ট বা মডেলের কাছে কাজ অর্পণ করে। নির্ভরশীল কাজগুলো তাদের পূর্বশর্ত পূরণের অপেক্ষায় থাকে। Perplexity Computer একাধিক ফ্রন্টিয়ার মডেল ব্যবহার করে এবং ওয়ার্কফ্লোর বিভিন্ন অংশ সেই কাজগুলোর উপযোগী সিস্টেমে রাউট করে। এর ফলে স্বাধীন কাজগুলো সমান্তরালভাবেও চলতে পারে।
নিয়ন্ত্রিত পরিবেশে টুল কল এক্সিকিউট করা। এজেন্টরা ওয়েব সার্চ, API, সংযুক্ত অ্যাপ্লিকেশন, ফাইল অপারেশন বা কোড এক্সিকিউশনের মতো টুলের মাধ্যমে তাদের পরিবেশের সাথে ইন্টারঅ্যাক্ট করে। এক্সিকিউশন লেয়ার এই কাজগুলো চালায় এবং ফলাফল এজেন্টদের কাছে ফেরত পাঠায়।
এজেন্টদের মধ্যে ফলাফল ও কনটেক্সট আদান-প্রদান করা। একটি এজেন্ট তার কাজ শেষ করলে, পরবর্তী ডাউনস্ট্রিম এজেন্টের কাজ চালিয়ে যেতে প্রাসঙ্গিক আউটপুট প্রয়োজন হয়। একটি হ্যান্ডঅফ রেকর্ডে টাস্ক ID, আউটপুট রেফারেন্স, স্কিমা ভার্সন ও উৎস মেটাডেটা থাকতে পারে। অর্কেস্ট্রেটর এই হ্যান্ডঅফগুলো সমন্বয় করে এবং পরবর্তী ধাপগুলোর জন্য প্রয়োজনীয় কনটেক্সট বজায় রাখে। গুরুত্বপূর্ণ বিষয় হলো, এজেন্টদের নিজেদের কনটেক্সট উইন্ডোতে অন্য প্রতিটি এজেন্টের কাজের পুরো ইতিহাস বহন করতে হয় না।
এজেন্ট কনটেক্সট থেকে আলাদাভাবে এক্সিকিউশন স্টেট রেকর্ড করা। এজেন্টরা যখন কাজ শুরু করে, সম্পন্ন করে বা ব্যর্থ হয়, তখন এক্সিকিউশন ইঞ্জিন একটি স্থায়ী ওয়ার্কফ্লো রেকর্ডে কাজের স্ট্যাটাস, এক্সিকিউশনের প্রচেষ্টা, আউটপুট রেফারেন্স ও বাকি কাজ হালনাগাদ করে। এই রেকর্ডের মাধ্যমে অর্কেস্ট্রেটর অগ্রগতি ট্র্যাক করতে পারে এবং কথোপকথনের ইতিহাস থেকে ওয়ার্কফ্লো পুনর্গঠনের জন্য কোনো LLM-এর ওপর নির্ভর না করেই বাধার পর আবার কাজ শুরু করতে পারে।
ফলাফল যাচাই করা এবং এরপর কী হবে তা ঠিক করা। কোনো কাজ ফেরত এলে অর্কেস্ট্রেশন লেয়ার যাচাই করে এর আউটপুট প্রত্যাশিত কন্ট্র্যাক্ট পূরণ করে কি না এবং পরবর্তী কাজের নির্ভরতাগুলো পূরণ হয়েছে কি না। কোনো সমস্যা পাওয়া গেলে, সংশোধনের জন্য ওয়ার্কফ্লো আগের কোনো ধাপে ফিরে যেতে পারে বা বিরতিতে রাখা হতে পারে। অন্যথায়, এটি সম্পন্ন হওয়ার দিকে এগিয়ে যায়।

আপাতদৃষ্টিতে সহজ মনে হওয়া AI এজেন্ট অর্কেস্ট্রেশনের পেছনে অনেক কিছু একসাথে চলে। আপনি এজেন্টদের সমন্বয় কীভাবে সাজান, তা নির্ধারণ করে এক্সিকিউশনের ওপর আপনার কতটা নিয়ন্ত্রণ থাকবে। আর অবশ্যই, এই সমন্বয় বাড়তি ওভারহেড যোগ করে। তাই এটি সবসময় লাভজনক নয়।

মাল্টি-এজেন্ট অর্কেস্ট্রেশন বিবেচনা করুন যখন কাজের বিভিন্ন অংশে আলাদা বিশেষজ্ঞতা প্রয়োজন, স্বাধীন কাজগুলো সমান্তরালভাবে চলতে পারে, অথবা আপনি আগে থেকে পরবর্তী ধাপ নির্ধারণ করতে পারেন না।

তাই, তিনটি পরিস্থিতিতে অর্কেস্ট্রেশন সহায়ক:

কাজগুলোর জন্য ভিন্ন ভিন্ন বিশেষায়ন প্রয়োজন। উদাহরণস্বরূপ, একটি কোডিং প্রজেক্টে আলাদা পরিকল্পনা, ডিজাইন, ডেভেলপমেন্ট ও রিভিউ এজেন্ট থাকলে সুবিধা হতে পারে।
স্বাধীন কাজগুলো সমান্তরালভাবে চলতে পারে। একটি এজেন্টকে দিয়ে সবকিছু ক্রমানুসারে সম্পন্ন করানোর বদলে, একাধিক এজেন্ট একই সময়ে কাজ করে তাদের ফলাফল একটি অর্কেস্ট্রেটরের কাছে ফেরত পাঠাতে পারে।
সমস্যাটি উন্মুক্ত প্রকৃতির। এজেন্টদের হয়তো পূর্বনির্ধারিত ক্রম অনুসরণ না করে বিভিন্ন পদ্ধতি অন্বেষণ, সিদ্ধান্ত গ্রহণ ও পরস্পরের সাথে সহযোগিতা করতে হতে পারে।

এর বাইরে, অর্কেস্ট্রেশন কেবলই একটি ব্যয়বহুল ট্রেন্ড। বেশি এজেন্ট মানে বেশি সমন্বয় এবং সম্ভবত বেশি টোকেন খরচ।

“আমি সাধারণত সবচেয়ে সহজ বিকল্প দিয়ে শুরু করি এবং সেখান থেকে এগোই। যদি আমরা ধাপগুলো জানি এবং সেগুলো পুনরাবৃত্তিযোগ্য হয়, তাহলে সেটি সম্ভবত একটি ওয়ার্কফ্লো। একাধিক এজেন্ট আনার কারণ আমি কেবল তখনই দেখি, যখন তাদের দায়িত্ব, অনুমতি বা ব্যবহারকারী আলাদা,” বলেন Josh Spilker, AirOps-এর সার্চ মার্কেটিং প্রধান।

তখনও, অতিরিক্ত মডেল কল, হ্যান্ডঅফ, লেটেন্সি ও ব্যর্থতার সম্ভাব্য পয়েন্টের সাথে সুবিধাগুলো তুলনা করে দেখুন।

এজেন্টদের সমন্বয় কাঠামোবদ্ধ করার তিনটি প্রচলিত উপায় — কেন্দ্রীভূত, বিকেন্দ্রীভূত ও স্তরভিত্তিক অর্কেস্ট্রেশন। সঠিক আর্কিটেকচার বেছে নেওয়া একটি প্রশ্নের ওপর নির্ভর করে: কাজ কে নিয়ন্ত্রণ করে, এবং এজেন্টরা কীভাবে একে অপরের সাথে সমন্বয় করে?

কেন্দ্রীভূত অর্কেস্ট্রেশনে, একটি অর্কেস্ট্রেটর পুরো প্রক্রিয়া পরিচালনা করে। এটি কাজকে ভাগ করে, বিশেষজ্ঞ এজেন্টদের কাছে কাজ অর্পণ করে, তাদের অগ্রগতি ট্র্যাক করে এবং তাদের ফলাফল একত্র করে।

কেন্দ্রীভূত অর্কেস্ট্রেশনের ডায়াগ্রাম: একটি অর্কেস্ট্রেটর ব্যবহারকারীর অনুরোধ গ্রহণ করে এবং রিসার্চ, অ্যানালাইসিস ও ডিজাইন এজেন্টদের কাছে কাজ অর্পণ করে; প্রতিটি এজেন্ট নিজস্ব টুল ব্যবহার করে, এবং তাদের ফলাফল মিলে একটি চূড়ান্ত ড্যাশবোর্ড তৈরি হয়।

সুবিধা-অসুবিধা: কেন্দ্রীভূত সমন্বয়ের ফলে এক্সিকিউশন ট্র্যাক করা এবং একটি একক নিয়ন্ত্রণ পয়েন্টে সাধারণ নিয়ম প্রয়োগ করা সহজ হয়। তবে অর্কেস্ট্রেটর একটি বটলনেক হয়ে উঠতে পারে, এবং সিস্টেম রিকভারি সমর্থন না করলে এর ব্যর্থতা পুরো ওয়ার্কফ্লো ব্যাহত করতে পারে।

বিকেন্দ্রীভূত অর্কেস্ট্রেশনে, প্রতিটি সিদ্ধান্তের জন্য একজন ম্যানেজারের ওপর নির্ভর না করে এজেন্টরা আরও সরাসরি সমন্বয় করে। তারা বার্তা আদান-প্রদান করতে, শেয়ার করা স্টেট পড়তে এবং স্বাধীনভাবে তাদের পরবর্তী ধাপ নির্ধারণ করতে পারে।

বিকেন্দ্রীভূত অর্কেস্ট্রেশনের ডায়াগ্রাম: রিসার্চ, অ্যানালাইসিস, ডিজাইন ও রিভিউ এজেন্টরা একটি চূড়ান্ত ড্যাশবোর্ড তৈরি করতে একে অপরের সাথে এবং শেয়ার করা স্টেট ও টুলের সাথে সরাসরি যোগাযোগ করে।

সুবিধা-অসুবিধা: এজেন্টরা কোনো কেন্দ্রীয় প্ল্যানারের অপেক্ষা না করেই কাজ করতে পারে, তাই এই পদ্ধতি অনুসন্ধানমূলক কাজ ও স্বাধীন অবদানের জন্য উপযোগী। কিন্তু এজেন্টরা যখন একমত হয় না, শেয়ার করা তথ্য হালনাগাদ করে বা তাদের একটি সামঞ্জস্যপূর্ণ ফলাফলে পৌঁছানোর প্রয়োজন হয়, তখন সমন্বয় কঠিন হয়ে পড়ে।

স্তরভিত্তিক অর্কেস্ট্রেশন ম্যানেজার পদ্ধতিকে একাধিক স্তরে বিস্তৃত করে। একটি শীর্ষ-স্তরের অর্কেস্ট্রেটর অধস্তন অর্কেস্ট্রেটরদের কাছে দায়িত্ব অর্পণ করে, যারা নিজ নিজ বিশেষজ্ঞ এজেন্টের দলগুলোর মধ্যে সমন্বয় করে।

সেলস, ফাইন্যান্স ও লিগ্যাল টিম জড়িত এমন একটি এন্টারপ্রাইজ ওয়ার্কফ্লোর কথা ভাবুন। একটি শীর্ষ-স্তরের অর্কেস্ট্রেটর প্রতিটি কাজের ধারা একটি নির্দিষ্ট ডোমেইনের সমন্বয়কের কাছে অর্পণ করতে পারে। এরপর সেই সমন্বয়কেরা নিজ নিজ বিশেষজ্ঞ এজেন্টদের পরিচালনা করবে এবং একত্রিত ফলাফল জানাবে।

ওয়ার্কফ্লো যখন একটি অর্কেস্ট্রেটরের পক্ষে কার্যকরভাবে পরিচালনা করার জন্য অনেক বেশি বিস্তৃত হয়, তখন এই কাঠামো সহায়ক হতে পারে।

স্তরভিত্তিক অর্কেস্ট্রেশনের ডায়াগ্রাম: একটি শীর্ষ-স্তরের অর্কেস্ট্রেটর সেলস, ফাইন্যান্স ও লিগ্যাল অর্কেস্ট্রেটরদের কাছে কাজ অর্পণ করে, যাদের প্রত্যেকে দুটি বিশেষজ্ঞ এজেন্ট পরিচালনা করে, এবং তাদের কাজ মিলে একটি একত্রিত আউটপুট তৈরি হয়।

সুবিধা-অসুবিধা: স্তরবিন্যাসের মাধ্যমে টিমগুলো সমন্বয়ের দায়িত্ব ভাগ করে নিতে পারে এবং সম্ভাব্যভাবে আলাদা আলাদা শাখার মধ্যেই ব্যর্থতা সামলাতে পারে। তবে এতে অতিরিক্ত হ্যান্ডঅফ, আরও জটিল স্টেট ব্যবস্থাপনা এবং বেশি অপারেশনাল ওভারহেড যুক্ত হয়। স্থানীয় রিকভারিও নির্ভর করে চেকপয়েন্ট ও এক্সিকিউশন স্টেট কীভাবে বাস্তবায়ন করা হয়েছে তার ওপর।

এই আর্কিটেকচারগুলোর তুলনা:

মানদণ্ড	কেন্দ্রীভূত	বিকেন্দ্রীভূত	স্তরভিত্তিক
এক্সিকিউশনের মালিকানা	একটি অর্কেস্ট্রেটর কাজ অর্পণ নিয়ন্ত্রণ করে	এজেন্টরা পিয়ার বা শেয়ার করা স্টেটের মাধ্যমে সমন্বয় করে	দায়িত্ব বিভিন্ন অর্কেস্ট্রেশন স্তরে বণ্টিত থাকে
স্টেটের সামঞ্জস্য	একটি নিয়ন্ত্রণ পয়েন্টের মাধ্যমে সমন্বয় করা সহজ	সুস্পষ্ট সিঙ্ক্রোনাইজেশন ও কনফ্লিক্ট ব্যবস্থাপনা প্রয়োজন	শাখাগুলোর ভেতরে ও শাখাগুলোর মধ্যে সমন্বয় প্রয়োজন
ব্যর্থতা বিচ্ছিন্নকরণ	কেন্দ্রীয় কন্ট্রোলার একটি গুরুত্বপূর্ণ নির্ভরতা হয়ে উঠতে পারে	আলাদা আলাদা এজেন্ট স্বাধীনভাবে ব্যর্থ হতে পারে, তবে শেয়ার করা অবকাঠামো গুরুত্বপূর্ণ থেকে যায়	রিকভারির জন্য ডিজাইন করা হলে ব্যর্থতা শাখার ভেতরেই সীমাবদ্ধ রাখা যেতে পারে
নীতি প্রয়োগ	সাধারণ নিয়ন্ত্রণগুলো কেন্দ্রীয়ভাবে প্রয়োগ করা যায়	সব অংশগ্রহণকারীর মধ্যে নীতিগুলো সামঞ্জস্যপূর্ণভাবে প্রয়োগ করতে হয়	নিয়ন্ত্রণগুলো গ্লোবাল ও ডোমেইন উভয় স্তরে প্রয়োগ করা যায়
পরিচালনাগত জটিলতা	সাধারণত কম	সমন্বয়ের জটিলতা বেশি	একাধিক অর্কেস্ট্রেশন স্তরের কারণে জটিলতা বেশি

আরও একটি পার্থক্য বুঝে রাখা ভালো। আর্কিটেকচার নির্ধারণ করে কে এজেন্টদের সমন্বয় করবে। এক্সিকিউশন প্যাটার্ন নির্ধারণ করে তাদের কাজ কীভাবে এগোবে।

এগুলো হলো তিনটি এক্সিকিউশন প্যাটার্ন:

ধারাবাহিক ওয়ার্কফ্লো: এজেন্টরা একটি পূর্বনির্ধারিত ক্রমে কাজ করে, যেখানে একটি এজেন্টের ফলাফল আরেকটির ইনপুট হয়ে ওঠে।
সমান্তরাল এক্সিকিউশন: স্বাধীন এজেন্টরা একই সময়ে কাজ করে।
হ্যান্ডঅফ-ভিত্তিক এক্সিকিউশন: কাজ এগোনোর সঙ্গে সঙ্গে নিয়ন্ত্রণ বিশেষজ্ঞ এজেন্টদের মধ্যে হাতবদল হয়। পরের ধাপ সামলাতে অন্য কোনো এজেন্ট বেশি উপযুক্ত হলে এটি কাজে আসে, তবে প্রতিটি হ্যান্ডঅফে কাজ চালিয়ে যাওয়ার জন্য প্রয়োজনীয় তথ্য অক্ষুণ্ণ রাখতে হয়।

প্যাটার্নগুলো একটি আরেকটিকে বাদ দেয় না, আর এগুলো অর্কেস্ট্রেশন আর্কিটেকচারের সঙ্গে এক-এক করে মেলেও না। লক্ষ্য হলো এমন সবচেয়ে সরল কাঠামো বেছে নেওয়া, যা আপনার ওয়ার্কফ্লোর নির্ভরতা, সমন্বয়ের প্রয়োজনীয়তা এবং গ্রহণযোগ্য পরিচালনাগত ওভারহেড সমর্থন করে।

অর্কেস্ট্রেশনে যেকোনো কিছুই ভুল হতে পারে, ছোটখাটো অসাবধানতা থেকে শুরু করে জটিল বাধা পর্যন্ত। কখনো কখনো এমনও হয় যে একটি এজেন্ট ঠিকঠাক কাজ করছে বলে মনে হয়, অথচ পুরো ওয়ার্কফ্লো ব্যর্থ হয়। এ নিয়ে কাজ করা পেশাদারদের অভিজ্ঞতার ভিত্তিতে আমরা অনির্ভরযোগ্য অর্কেস্ট্রেটেড ওয়ার্কফ্লোর পেছনের কিছু সাধারণ ভুল সংকলন করেছি — এগুলোর দিকে নজর রাখুন:

তথ্য হারানো এজেন্ট হ্যান্ডঅফ। একটি অর্কেস্ট্রেটর একটি বিশেষজ্ঞ এজেন্টকে সংক্ষিপ্ত পরিকল্পনা পাঠায়, কিন্তু সেই সারাংশে সীমাবদ্ধতা, নির্ভরতা বা বাস্তবায়নের খুঁটিনাটি বাদ পড়ে যায়।
অকাল ফ্যান-ইন এক্সিকিউশন। আপস্ট্রিমের সব কাজ শেষ হওয়ার আগেই একটি ডাউনস্ট্রিম এজেন্ট ফলাফল একত্র করা শুরু করে।
নন-ডিটারমিনিস্টিক শেয়ার্ড-স্টেট আপডেট। সমান্তরাল এজেন্টরা সুনির্দিষ্ট মার্জ সিমান্টিক্স ছাড়াই একই স্টেট কি-তে লেখে। ফ্রেমওয়ার্ক কীভাবে আপডেট সামলায় তার ওপর নির্ভর করে এর ফলে লেখা হারিয়ে যেতে পারে, ডেটা ডুপ্লিকেট হতে পারে, আউটপুট ক্রমের ওপর নির্ভরশীল হয়ে পড়তে পারে, কিংবা পরস্পরবিরোধী পরিবর্তন ঘটতে পারে।
চেকপয়েন্ট ও সাইড-ইফেক্টের অমিল। একটি কাজ বাহ্যিক কোনো অপারেশন সম্পন্ন করে, কিন্তু ওয়ার্কার ব্যর্থ হওয়ার আগে এর সফল এক্সিকিউশন স্থায়ীভাবে রেকর্ড হয় না। পুনরুদ্ধারের সময় অর্কেস্ট্রেটর কাজটিকে অসমাপ্ত দেখে আবার চালায়।
মানব-অনুমোদনের পর পুনরায় শুরুর রেস কন্ডিশন। এক্সিকিউশন থামানো ও আবার চালু করার ফলে নিজস্ব সিঙ্ক্রোনাইজেশন সমস্যা তৈরি হয়।
ডেলিগেশন লুপ ও রিট্রাই অ্যামপ্লিফিকেশন। দায়িত্ব পরস্পরের সঙ্গে মিলে যাওয়া, নির্ভরতা চক্রাকার হওয়া কিংবা সমাপ্তির শর্ত অস্পষ্ট থাকার কারণে এজেন্টরা বারবার একে অপরের কাছে কাজ হস্তান্তর করে।
নির্দেশনা-স্তরের নিয়ন্ত্রণকে এক্সিকিউশন নিরাপত্তা বলে ভুল করা। একটি অর্কেস্ট্রেটর এজেন্টদের নির্দিষ্ট কিছু রিসোর্স অ্যাক্সেস না করতে বা সংবেদনশীল কাজ না করতে বলতে পারে, কিন্তু মডেলের নির্দেশনা অপারেটিং সিস্টেমের অনুমতি, নেটওয়ার্ক বিধিনিষেধ বা অনুমোদনের সীমা প্রয়োগ করে না। Perplexity-এর নিরাপত্তা প্রকৌশল গবেষণা তুলে ধরে, কেন এজেন্টরা কোনো ক্ষতিকর নির্দেশনা ছাড়াই, বৈধ লক্ষ্য অর্জনের চেষ্টায় নিরাপত্তার সীমা অতিক্রম করতে পারে

লক্ষ করুন, এই ব্যর্থতাগুলো কতটা ভিন্ন। শিডিউলারের অকাল ট্রানজিশন বা অস্পষ্ট বাহ্যিক রাইট — উভয়ই ভুল ফলাফল দিতে পারে, কিন্তু এগুলোর উৎপত্তি এক্সিকিউশন লাইফসাইকেলের ভিন্ন ভিন্ন অংশে। এ কারণেই নির্ভরযোগ্য অর্কেস্ট্রেশনের জন্য শুধু প্রম্পট উন্নত করা বা রিট্রাই যোগ করাই যথেষ্ট নয়।

অস্পষ্ট লক্ষ্য এবং কাজ সম্পন্ন হওয়ার সংজ্ঞা পরিষ্কার না থাকলে এজেন্টের তৈরি ফলাফল প্রায়ই হতাশাজনক হয়। এর সমাধান হলো একটি প্রম্পট কন্ট্রাক্ট (একটি এজেন্টের জন্য কাজের পরিধি): এক্সিকিউশন শুরুর আগেই লক্ষ্য, সীমাবদ্ধতা, আউটপুট ফরম্যাট এবং ব্যর্থতার শর্তে একমত হোন।

উদাহরণস্বরূপ, মাঝে মাঝে ব্যর্থ হওয়া একটি ইন্টিগ্রেশন টেস্ট ঠিক করার দায়িত্বে থাকা এজেন্টের জন্য আপনি এভাবে একটি কন্ট্রাক্ট নির্ধারণ করতে পারেন:

লক্ষ্য: চেকআউট API-এর একটি অস্থির ইন্টিগ্রেশন টেস্টের কারণ শনাক্ত করে তা ঠিক করা।
ইনপুট: টেস্টের সোর্স কোড, CI ব্যর্থতার লগ, সাম্প্রতিক কমিট এবং প্রাসঙ্গিক অ্যাপ্লিকেশন কোড।
সীমাবদ্ধতা: টেস্ট নিষ্ক্রিয় করবেন না, অ্যাসারশন শিথিল করবেন না, কিংবা অসম্পর্কিত অ্যাপ্লিকেশন আচরণ পরিবর্তন করবেন না।
প্রত্যাশিত আউটপুট: একটি কোড প্যাচ, মূল কারণের ব্যাখ্যা এবং টেস্ট চালানোর ফলাফল।
গ্রহণযোগ্যতার মানদণ্ড: আগে ব্যর্থ হওয়া টেস্টটি টানা ১০ বার চালানোয় পাস করে এবং প্রাসঙ্গিক রিগ্রেশন স্যুটও পাস করে।
ব্যর্থতার শর্ত: মূল কারণ নির্ণয় করা যায় না, সমাধানটি রিগ্রেশন তৈরি করে, অথবা প্রয়োজনীয় টেস্ট এনভায়রনমেন্ট পাওয়া যায় না।

তবে আরও একটি গুরুত্বপূর্ণ বিষয় আছে: এজেন্টের কখন থামা উচিত?

সন্তোষজনক ফলাফল দিতে পারেনি বলে একটি এজেন্টের অনির্দিষ্টকাল ধরে পুনরাবৃত্তি চালিয়ে যাওয়া উচিত নয়। সফল সমাপ্তি বলতে কী বোঝায়, কখন আংশিক সম্পন্ন কাজ ফেরত দিতে হবে এবং কোনো শর্ত পূরণ করা সম্ভব না হলে কখন থামতে হবে — তা নির্ধারণ করুন। সর্বোচ্চ ডেলিগেশন গভীরতা ও পুনরাবৃত্তির সীমা অথবা এক্সিকিউশন বাজেট নির্ধারণ করুন, যাতে অমীমাংসিত কাজগুলো অন্তহীন লুপে পরিণত না হয়।

আবার আমাদের CI উদাহরণে ফেরা যাক। আপনি নিচের থামার শর্তগুলো নির্ধারণ করতে পারেন:

সফলতা: সমাধানটি টানা ১০ বার টেস্ট রানে এবং প্রাসঙ্গিক রিগ্রেশন স্যুটে পাস করে।
পুনরাবৃত্তির সীমা: এজেন্ট সর্বোচ্চ দুটি সম্ভাব্য সমাধান চেষ্টা করতে পারে।
এক্সিকিউশন বাজেট: সমস্যার সমাধান না হলেও এজেন্টকে ৬০ মিনিট পর থামতে হবে।
ডেলিগেশনের সীমা: এজেন্ট একটি বিশেষজ্ঞ এজেন্টকে কাজ ডেলিগেট করতে পারে, তবে এর বাইরে আর কোনো সাবএজেন্টকে ডেলিগেট করা যাবে না।
আংশিক সমাপ্তি: দুটি চেষ্টাই ব্যর্থ হলে বা সময়সীমা শেষ হলে এজেন্ট তার অনুসন্ধানের ফলাফল, চেষ্টা করা পরিবর্তন এবং টেস্টের ফলাফল ফেরত দেয়।
বাধাগ্রস্ত এক্সিকিউশন: টেস্ট এনভায়রনমেন্ট পাওয়া না গেলে এজেন্ট সফলতা দাবি করার বদলে থেমে যায় এবং বাধাটির কথা জানায়।

কখনো কখনো ডেভেলপাররা একটি অর্কেস্ট্রেটরকে অতিরিক্ত দায়িত্ব দিয়ে ফেলেন, ফলে বিশেষজ্ঞ এজেন্টদের সমন্বয় করার বদলে সেটি নিজেই কোড লেখা, ডিবাগিং বা বিস্তারিত রিভিউ করতে শুরু করে। এতে একটি বটলনেক তৈরি হয়: অর্কেস্ট্রেটর তার কনটেক্সট বাজেট বাস্তবায়নের খুঁটিনাটিতে খরচ করে, ডেলিগেশনে দেরি করে এবং ফলাফলের দায়িত্ব অস্পষ্ট করে তোলে।

তাই অর্কেস্ট্রেটরকে তার নিজের কাজ করতে দিন এবং সুনির্দিষ্ট আর্টিফ্যাক্টের রেফারেন্স দিয়ে হ্যান্ডঅফ নিশ্চিত করুন: মূল কাজ, প্রাসঙ্গিক ইনপুট, আউটপুট আর্টিফ্যাক্ট, এক্সিকিউশনের অবস্থা এবং যেকোনো অমীমাংসিত সমস্যা।

এই উদাহরণটি বিবেচনা করুন: status: completed এজেন্টকে দেওয়া কাজকে বোঝায়, পুরো ওয়ার্কফ্লোকে নয়। যেহেতু টেস্টগুলো এখনো pending, তাই অর্কেস্ট্রেটরের চূড়ান্ত ফলাফল অনুমোদন করা উচিত নয়।

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

একটি এজেন্টের কথোপকথনের ইতিহাস ওয়ার্কফ্লোর অগ্রগতির নির্ভরযোগ্য রেকর্ড নয়। এর কনটেক্সট উইন্ডো ভরে গেলে স্বয়ংক্রিয় কমপ্যাকশন গুরুত্বপূর্ণ খুঁটিনাটি বাদ দিয়ে ফেলতে পারে। আর কোনো ওয়ার্কার ক্র্যাশ করলে, পরবর্তী এজেন্টকে জানতে হবে আসলে কোন ধাপগুলো সম্পন্ন হয়েছে।

উদাহরণস্বরূপ, কোডিং এজেন্ট একটি প্যাচ তৈরি করার পর ক্র্যাশ করলে, পরবর্তী ওয়ার্কারের উচিত সংরক্ষিত আর্টিফ্যাক্টটি নিয়ে রেকর্ড করা ওয়ার্কফ্লো স্টেট থেকে কাজ চালিয়ে যাওয়া। কিন্তু এজেন্টটি যদি একটি বাহ্যিক CI রানও চালু করে থাকে, তাহলে কাজটি পুনরাবৃত্তি করার আগে অর্কেস্ট্রেটরকে সেই রানটি আলাদাভাবে মিলিয়ে দেখতে হবে

তাই এক্সিকিউশন স্টেটকে এজেন্টের কার্যকরী কনটেক্সট থেকে আলাদা রাখুন। কাজের অবস্থা, এক্সিকিউশনের প্রচেষ্টা, সম্পন্ন ধাপ এবং আর্টিফ্যাক্টের রেফারেন্স টেকসই স্টোরেজে সংরক্ষণ করুন। পাশাপাশি, পুরো এক্সিকিউশন ইতিহাস কনটেক্সট উইন্ডোতে ঠেসে না দিয়ে কেবল এজেন্টের বর্তমান কাজের সঙ্গে প্রাসঙ্গিক নির্দেশনা, ইনপুট ও ফলাফল লোড করুন।

ধরুন, আপনার CI এজেন্ট একটি টেস্ট রান চালু করল, কিন্তু API অনুরোধের টাইমআউট হয়ে গেল। টেস্ট রানটি কি শুরুই হয়নি, নাকি CI সার্ভিস সেটিকে কিউতে রেখেছে কিন্তু রেসপন্স হারিয়ে ফেলেছে?

টাইমআউট মানেই যে অপারেশন ব্যর্থ হয়েছে, তা নয়। এ কারণেই পরবর্তী পদক্ষেপ ঠিক করার আগে ত্রুটিগুলোর মধ্যে পার্থক্য করতে হবে:

অস্থায়ী ত্রুটি (429, 503): সীমিত এক্সপোনেনশিয়াল ব্যাকঅফ ও জিটারসহ রিট্রাই করুন, আর দেওয়া থাকলে Retry-After মেনে চলুন।
যাচাইকরণ বা অনুমতি সংক্রান্ত ত্রুটি (400, 403): একই অনুরোধ বারবার না পাঠিয়ে থেমে যান অথবা মূল সমস্যাটি সংশোধন করুন।
অস্পষ্ট ফলাফল (সম্ভাব্য রাইটের পর টাইমআউট): আবার চেষ্টা করার আগে যাচাই করুন অপারেশনটি সফল হয়েছিল কি না।

দ্রষ্টব্য: রিট্রাইযোগ্য ত্রুটিরও সীমা থাকা দরকার। প্রতিটি টুল কলের জন্য টাইমআউট নির্ধারণ করুন, রিট্রাইয়ের সংখ্যা ও মোট রিট্রাই সময় সীমিত করুন, এবং পুরো ওয়ার্কফ্লোর জন্য একটি সময়সীমা প্রয়োগ করুন, যাতে নেস্টেড এজেন্টরা একই অপারেশন বারবার শুরু করতে না পারে। কোনো নির্ভরতা বারবার ব্যর্থ হলে, সাময়িকভাবে অনুরোধ বন্ধ রাখতে একটি সার্কিট ব্রেকার ব্যবহার করুন।

বাহ্যিক সাইড ইফেক্ট আছে এমন অপারেশনের ক্ষেত্রে প্রতিটি লজিক্যাল অ্যাকশনের জন্য একটি স্থির আইডেমপোটেন্সি কি নির্ধারণ করুন এবং রিট্রাইয়ের সময় সেটি পুনরায় ব্যবহার করুন। API যদি সার্ভার-সাইড ডিডুপ্লিকেশন সমর্থন করে, তাহলে এটি কাজটি দুবার না করেই পুনরাবৃত্ত অনুরোধ শনাক্ত করতে পারে। আর যদি সমর্থন না করে, তাহলে একটি কোরিলেশন আইডি বা অন্য কোনো নির্ভরযোগ্য রেফারেন্স ব্যবহার করে বাহ্যিক সিস্টেমে কোয়েরি করুন।

কী ঘটেছে তা নিশ্চিত হতে না পারলে, থামুন এবং বিষয়টি এসকেলেট করুন।

আমাদের CI এজেন্টের রিট্রাই লজিকের একটি উদাহরণ, সিউডোকোডে:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

কোড নোট: উদাহরণটি ধরে নেয় যে CI API অনুরোধ আইডি দিয়ে রান খোঁজা সমর্থন করে। request_id কেবল তখনই ডুপ্লিকেট ঠেকায়, যখন প্রোভাইডার স্পষ্টভাবে আইডেমপোটেন্সির নিশ্চয়তা দেয়। bounded_retry() একটি দৃষ্টান্তমূলক সিউডোকোড। প্রোডাকশনে রিট্রাই সীমিত হওয়া উচিত প্রতিটি অপারেশনের রিট্রাই বাজেট (সর্বোচ্চ চেষ্টা বা অতিবাহিত সময়) এবং পুরো ওয়ার্কফ্লোর সময়সীমা — উভয় দিয়েই।

একাধিক সার্ভিসজুড়ে চলা দীর্ঘ ওয়ার্কফ্লোর ক্ষেত্রে, পরবর্তী ধাপগুলো ব্যর্থ হলে ক্ষতিপূরণমূলক পদক্ষেপ সমন্বয়ের জন্য Saga প্যাটার্ন বিবেচনা করুন। তবে মনে রাখবেন, ক্ষতিপূরণ মানেই সবসময় পুরোপুরি রোলব্যাক নয়। আপনি ডেটাবেস আপডেট ফিরিয়ে নিতে পারেন, কিন্তু পাঠানো ইমেইল ফেরত আনতে পারবেন না।

এখানে দুটি বিষয়ের মধ্যে ভারসাম্য রাখতে হবে: প্রতিটি কাজের জন্য কতটা মডেল সক্ষমতা দরকার এবং একসঙ্গে কতগুলো কাজ চালানো যায়। যেকোনো একটিতে ভুল করলে ঝুঁকি থাকে যে এজেন্টরা শেয়ার করা API কোটার জন্য প্রতিযোগিতা করবে অথবা কেবল ব্যয়বহুল রিজনিং মডেলের ওপর নির্ভর করবে।

মডেল নির্বাচনের ক্ষেত্রে, কাজের জটিলতার সঙ্গে মডেলের সক্ষমতা ও রিজনিংয়ের মাত্রা মিলিয়ে নিন — সহজ, কিন্তু প্রায়ই উপেক্ষিত। মনে রাখবেন, আপনি নিজে রাউটিং নিয়ম কনফিগার করে মডেল মূল্যায়ন করতে পারেন, অথবা এমন একটি অর্কেস্ট্রেশন প্ল্যাটফর্ম ব্যবহার করতে পারেন যা আপনার হয়ে মডেল নির্বাচন সামলায়।

যেমন, Perplexity Computer-এর Effort Mode আপনাকে ম্যানুয়ালি মডেল নির্বাচন না করেই একটি কাজের জন্য কতটা প্রচেষ্টা প্রয়োজন তা বেছে নিতে দেয়। Light, Standard, High বা Ultra বেছে নিন, আর Perplexity স্বয়ংক্রিয়ভাবে অর্কেস্ট্রেটিং মডেল ও তার রিজনিং লেভেল নির্বাচন করবে। এরপর সেই অর্কেস্ট্রেটর সাবটাস্কগুলো সহায়ক এজেন্টদের কাছে ডেলিগেট করে, যারা বিভিন্ন প্রোভাইডারের মডেল ব্যবহার করতে পারে।

Perplexity মান ও খরচের ভিত্তিতে মডেল কনফিগারেশন মূল্যায়ন করে এবং তুলনামূলক ফলাফল দেয় এমন কম ব্যয়বহুল বিকল্পকে অগ্রাধিকার দেয়। আপনি নিজে মডেল ও রিজনিং লেভেল বেছে নিতে চাইলে Custom নিয়ন্ত্রণও ব্যবহার করতে পারেন।

সমান্তরালতার ক্ষেত্রে, সীমা নির্ধারিত হওয়া উচিত আপনার অবকাঠামো ও বাহ্যিক নির্ভরতার ভিত্তিতে। শেয়ার করা API-গুলোর অনুরোধ ও টোকেন রেট লিমিট যাচাই করুন, তারপর ক্রমবর্ধমান কনকারেন্সিতে আপনার ওয়ার্কফ্লোর লোড টেস্ট করুন। লক্ষ করুন, থ্রুপুট বাড়ছে, নাকি অনুরোধগুলো কিউতে জমতে, ধীর হতে বা 429 ত্রুটি ফেরত দিতে শুরু করছে।

রিসোর্সের ব্যবহার অনুমানযোগ্য রাখতে রিসোর্স সীমা ও শিডিউলিং নিয়ন্ত্রণ প্রয়োগ করুন:

কনকারেন্সি ও অনুরোধের হার নিয়ন্ত্রণ করুন: প্রতিটি সার্ভিসে চলমান কলের সংখ্যা সীমিত করুন এবং অতিরিক্ত কাজ কিউতে রাখুন। মনে রাখবেন, শুধু কনকারেন্সির সীমা প্রতি মিনিটে অনুরোধ বা প্রতি মিনিটে টোকেনের সীমা প্রয়োগ করবে না।
টোকেন ও খরচের বাজেট ট্র্যাক করুন: সাবএজেন্টসহ পুরো ওয়ার্কফ্লোজুড়ে ব্যবহারের হিসাব রাখুন, এবং অবশিষ্ট বাজেট অপর্যাপ্ত হলে নতুন কাজ শুরু করা বন্ধ করুন।
এক্সিকিউশনের সময়সীমা প্রয়োগ করুন: কাজ ও ওয়ার্কফ্লোর জন্য সময়সীমা নির্ধারণ করুন, এবং যেখানে সমর্থিত, সেখানে চলমান এজেন্টদের কাছে বাতিলের নির্দেশ পৌঁছে দিন।
নির্ভরতাকে গুরুত্ব দিন: সব এজেন্ট একসঙ্গে চালু না করে, প্রয়োজনীয় ইনপুট পাওয়া গেলে তবেই ডাউনস্ট্রিম কাজগুলো শুরু করুন।

মডেলের নিজের কাজ নিরাপদ কি না, সেই সিদ্ধান্ত কখনো মডেলকে নিতে বলবেন না। বরং এজেন্টদের ন্যূনতম-প্রয়োজনীয় অনুমতি দিন এবং অ্যাপ্লিকেশন কোডে ঝুঁকিভিত্তিক অনুমোদনের নিয়ম প্রয়োগ করুন। এজেন্টরা কোড চালালে, সেই এক্সিকিউশনকে আপনার হোস্ট এনভায়রনমেন্ট থেকে বিচ্ছিন্ন রাখুন এবং ফাইল, নেটওয়ার্ক ও ক্রেডেনশিয়ালে অ্যাক্সেস সীমিত করুন। এজেন্ট ভুল করলে বা অনিরাপদ কোড চালালে এতে ক্ষতির পরিমাণ সীমিত থাকে।

“আমি অতিরিক্ত জটিল মাল্টি-এজেন্ট সিস্টেম নিয়ে সন্দিহান, বিশেষ করে যখন এজেন্টরা একে অপরের কাজ রিভিউ ও অনুমোদন করে। এতে দেখা যেতে পারে, কয়েকটি এজেন্ট আত্মবিশ্বাসের সঙ্গে একই ভুল একে অপরের কাছে পাঠিয়ে দিচ্ছে, অথচ কেউই আসলে সেটি ধরছে না,” সতর্ক করেন স্পিলকার।

অনুমোদন প্রবাহের ডায়াগ্রাম: একটি এজেন্ট প্যারামিটার, টার্গেট রিসোর্স ও স্টেট ভার্সনসহ একটি অপারেশন প্রস্তাব করে; একজন মানুষ সেটি অনুমোদন বা প্রত্যাখ্যান করেন; অনুমোদিত অপারেশনগুলো পুনরায় যাচাই করে সীমিত ফাইল, নেটওয়ার্ক ও ক্রেডেনশিয়াল অ্যাক্সেসসহ একটি বিচ্ছিন্ন এনভায়রনমেন্টে চালানো হয়। প্রত্যাখ্যাত বা মেয়াদোত্তীর্ণ অনুরোধ বন্ধ হয়ে যায়, আর পরিবর্তিত অনুরোধের জন্য নতুন অনুমোদন প্রয়োজন।

যেসব কাজে মানুষের অনুমোদন প্রয়োজন, সেগুলোর ক্ষেত্রে এক্সিকিউশন থামান এবং প্রস্তাবিত অপারেশনটি হুবহু সংরক্ষণ করুন:

অপারেশনটির প্যারামিটার
অপারেশনটির টার্গেট রিসোর্স
অপারেশনটির কমিট বা স্টেট ভার্সন
রিভিউয়ারের সিদ্ধান্ত

এছাড়া, অনুমোদন প্রত্যাখ্যাত হলে, মেয়াদ শেষ হলে বা এসকেলেশনের প্রয়োজন হলে কী হবে তা নির্ধারণ করুন। পুনরায় চালু করা যায় এমন ফ্রেমওয়ার্কের জন্য এটি অপরিহার্য, কারণ বাধাপ্রাপ্ত কোনো নোড পুনরায় চালু করলে সেই নোডের শুরু থেকে কোড আবার এক্সিকিউট হয়। ফলে বাধার আগের যেকোনো সাইড ইফেক্ট আবার ঘটতে পারে।

তাই অনুমোদন প্রত্যাখ্যাত হলে বা মেয়াদ শেষ হলে অনুরোধটি বন্ধ হয়ে যায়। এক্সিকিউশনের আগে টার্গেট কমিট, প্যারামিটার বা অনুমতি পরিবর্তিত হলে, অনুমোদনটি বাতিল করুন এবং নতুন অনুমোদনের অনুরোধ করুন।

স্পিলকার পুরোপুরি স্বায়ত্তশাসিত, এন্ড-টু-এন্ড এজেন্টকেই লক্ষ্য হিসেবে দেখার ধারণাও সমর্থন করেন না। “আমার মতে, ভালো পদ্ধতি হলো স্পষ্ট দায়িত্ব, নির্ধারিত অনুমতি এবং সঠিক জায়গায় মানুষের রিভিউসহ কয়েকটি নির্দিষ্ট কাজে কেন্দ্রীভূত এজেন্ট তৈরি করা। এতে পূর্ণ নিয়ন্ত্রণ না ছেড়েও আপনি কর্মদক্ষতা পাবেন,” উপসংহারে বলেন তিনি।

কখনো কি এমন হয়েছে যে একটি এজেন্ট Success রিপোর্ট করছে, অথচ আসলে সেটি ব্যর্থ হয়েছে? এটা বিরক্তিকর, এমনকি রাগ ধরানোও, আর এর সমাধান দ্রুত হয় না, কারণ এজেন্টের চূড়ান্ত বার্তা আপনাকে অবশ্যই বলে দেবে না কোথায় সমস্যা হয়েছে।

তদন্ত করতে, এক্সিকিউশনের সময় কী ঘটেছে তা ট্রেস করুন এবং ফলাফল স্বাধীনভাবে যাচাই করুন। তাহলে চলুন, সমস্যাটি আলাদা করে শনাক্ত ও সমাধান করতে কিছুটা সময় দেওয়া যাক।

একটি এজেন্টের প্রম্পট ডিবাগ করার আগে পুরো এক্সিকিউশন পথটি ক্যাপচার করুন। আপনার এমন একটি ট্রেস দরকার, যা একই ওয়ার্কফ্লো রানের অধীনে এজেন্ট ইনভোকেশন, টুল কল, ত্রুটি ও রিট্রাইগুলোকে যুক্ত করে।

OpenTelemetry-এর GenAI সিমান্টিক কনভেনশন এই অপারেশনগুলো বর্ণনা করার একটি মানসম্মত উপায় দেয়। উদাহরণস্বরূপ, invoke_workflow ওয়ার্কফ্লো এক্সিকিউশন, invoke_agent একটি এজেন্ট ইনভোকেশন এবং execute_tool একটি টুল কল শনাক্ত করে। প্রতিটি অপারেশন তার সময়, অবস্থা ও প্রাসঙ্গিক মেটাডেটাসহ একটি span হিসেবে রেকর্ড করা যায়।

এই ধাপে আপনি এক্সিকিউশন পথের একটি ট্রেস পাবেন, ফলে কোন জায়গায় এজেন্ট হোঁচট খেয়েছে তা শনাক্ত করতে পারবেন।

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

একটি দৃষ্টান্তমূলক এক্সিকিউশন ট্রেস।

যেখানে সম্ভব, প্রোগ্রাম্যাটিক যাচাই ব্যবহার করুন। JSON স্কিমার বিপরীতে আউটপুট যাচাই করুন, ইউনিট ও ইন্টিগ্রেশন টেস্ট চালান, প্রয়োজনীয় আর্টিফ্যাক্ট আছে কি না দেখুন, এবং কাজগুলো আসলেই সফল হয়েছে কি না তা নিশ্চিত করতে বাহ্যিক সিস্টেমে কোয়েরি করুন।

যেসব আউটপুটের জন্য বিষয়ভিত্তিক বিচার প্রয়োজন — এবং তাই প্রোগ্রাম্যাটিক যাচাইয়ের মাধ্যমে মূল্যায়ন করা যায় না — সেগুলোর জন্য একটি স্বাধীন রিভিউয়ার এজেন্ট যুক্ত করুন। একটি পদ্ধতি হলো ইমপ্লিমেন্টার–রিভিউয়ার–রিজলভার লুপ, যেখানে একটি এজেন্ট একটি আর্টিফ্যাক্ট তৈরি করে, নতুন কনটেক্সটের একটি রিভিউয়ার সমস্যা শনাক্ত করে, এবং যাচাই আবার চালানোর আগে একটি রিজলভার সেগুলোর সমাধান করে।

যেখানে সম্ভব, রিভিউয়ারের ফলাফল আপনাকে তবুও যাচাই করতে হবে, আর বারবার মূল্যায়নের জন্য LLM-ভিত্তিক গ্রেডার ব্যবহার করলে, মানুষের রিভিউ করা উদাহরণের সঙ্গে মিলিয়ে তাদের বিচার ক্যালিব্রেট করুন।

এ পর্যন্ত আপনি এজেন্টগুলো কী এক্সিকিউট করেছে তা ট্রেস করেছেন এবং তাদের আউটপুট সঠিক ছিল কি না যাচাই করেছেন। কিন্তু কোনো ওয়ার্কার যদি কোনো টাস্কের মাঝপথে ক্র্যাশ করে, বা কোনো API একটি রিকোয়েস্ট গ্রহণ করার পর টাইমআউট হয়ে যায়, তখন কী ঘটে? অবাক করার মতো বিষয় হলো, আপনার ওয়ার্কফ্লো স্বাভাবিক অবস্থায় পুরোপুরি ঠিকঠাক কাজ করলেও রিকভারির সময় ব্যর্থ হতে পারে।

এটি পরীক্ষা করতে, একটি টেস্ট এনভায়রনমেন্টে ইচ্ছাকৃতভাবে ত্রুটি তৈরি করুন:

API টাইমআউট সিমুলেট করুন
এক্সটার্নাল রাইট ও চেকপয়েন্টের মাঝখানে ওয়ার্কার ক্র্যাশ করান
ভুল ফরম্যাটের টুল আউটপুট রিটার্ন করুন
অনুমোদনের মেয়াদ শেষ করে দিন

প্রতিটি টেস্টের পর এক্সিকিউশন ট্রেস পরীক্ষা করে দেখুন কোন ধাপগুলো চলেছে, ওয়ার্কফ্লো কোথা থেকে আবার শুরু হয়েছে, এবং কোনো অ্যাকশন পুনরাবৃত্ত হয়েছে বা বাদ পড়েছে কি না। তারপর প্রকৃত ফলাফলগুলো পর্যালোচনা করুন।

ধরুন, আপনার CI এজেন্ট একটি টেস্ট রান শুরু করার জন্য রিকোয়েস্ট পাঠায়, কিন্তু API রেসপন্স টাইমআউট হয়ে যায়। এজেন্টটি আবার চেষ্টা করে, একটি সফল রেসপন্স পায় এবং সফল রিপোর্ট করে। সবকিছু ঠিকঠাকই মনে হয়, যতক্ষণ না আপনি CI সার্ভিস চেক করে দেখেন যে একটির বদলে দুটি টেস্ট রান তৈরি হয়েছে।

এ কারণেই আপনার উচিত ওয়ার্কফ্লোর রেকর্ড করা স্টেট এবং এক্সটার্নাল সিস্টেমগুলোতে হওয়া প্রকৃত পরিবর্তন—দুটিই যাচাই করা। একটি রিকভারি টেস্ট তখনই পাস করা উচিত, যখন ওয়ার্কফ্লো কোনো অনাকাঙ্ক্ষিত সাইড ইফেক্ট ছাড়াই প্রত্যাশিত স্টেটে পৌঁছায়।

যেসব ব্যর্থতা আপনি খুঁজে পান, সেগুলো আপনার রিগ্রেশন টেস্টে যোগ করুন, যাতে ভবিষ্যতের পরিবর্তনগুলো সেগুলো আবার ফিরিয়ে না আনে।

শেষ পর্যন্ত, সফলতা মানে হলো ওয়ার্কফ্লোটি তার প্রয়োজনীয় সব চেক পাস করেছে এবং এর এক্সটার্নাল ফলাফলগুলো যাচাই করা হয়েছে।

বিচ্ছিন্ন এজেন্টগুলো প্রত্যেকে নিজ নিজ টাস্ক সঠিকভাবে সম্পন্ন করতে পারে, কিন্তু একসঙ্গে অসামঞ্জস্যপূর্ণ ফলাফল দিতে পারে। কল্পনা করুন, একটি সেলস এজেন্ট ১০:০০টায় গ্রাহকের শর্তাবলি সংগ্রহ করছে, একটি প্রাইসিং এজেন্ট ১০:০৫-এ হালনাগাদ মূল্য ব্যবহার করে কোটেশন হিসাব করছে, আর একটি লিগ্যাল এজেন্ট ১০:০৭-এ পরিবর্তিত একটি চুক্তি যাচাই করছে। প্রতিটি এজেন্ট ব্যবসার ভিন্ন ভিন্ন স্ন্যাপশট নিয়ে কাজ করে, তাই তাদের আউটপুট একে অপরের সঙ্গে সাংঘর্ষিক হতে পারে।

এন্টারপ্রাইজ স্কেলে সমস্যাটি আরও প্রকট হয়ে ওঠে, কারণ এজেন্টগুলো স্বাধীনভাবে আপডেট হওয়া একাধিক সিস্টেমের সঙ্গে ইন্টারঅ্যাক্ট করে, ভিন্ন ভিন্ন পারমিশন নিয়ে কাজ করে, এবং সবসময় কনটেক্সট বা এক্সিকিউশন স্টেট শেয়ার করে না।

একাধিক স্তরে সীমা নির্ধারণ করুন: সর্বোচ্চ টুল-কল রিট্রাই, সর্বোচ্চ এজেন্ট ইটারেশন, ডেলিগেশনের গভীরতা, এবং পুরো ওয়ার্কফ্লোর জন্য একটি সামগ্রিক ডেডলাইন। রিট্রাই করার আগে ব্যর্থতাগুলো শ্রেণিবদ্ধ করুন। সাময়িক 429 রেসপন্সের ক্ষেত্রে, Retry-After দেওয়া থাকলে তা মেনে চলুন। অন্যথায়, জিটারসহ সীমিত এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করুন।

ভ্যালিডেশন বা পারমিশন ত্রুটির পর অপরিবর্তিত রিকোয়েস্ট রিট্রাই করা বন্ধ করুন। কোনো ডাউনস্ট্রিম সার্ভিস বারবার ব্যর্থ হলে, একটি সার্কিট ব্রেকার এজেন্টগুলোকে অতিরিক্ত লোড তৈরি করা থেকে বিরত রাখতে পারে।

রিকভারি মেকানিজম আপনার রানটাইমের ওপর নির্ভর করে। LangGraph-এ PostgresSaver-এর মতো একটি পারসিস্টেন্ট চেকপয়েন্টার একটি thread_id-এর অধীনে গ্রাফ স্টেট সংরক্ষণ করে, যার ফলে সংরক্ষিত স্টেট থেকে এক্সিকিউশন চালিয়ে যাওয়া যায়। Temporal-এ অন্য একটি ওয়ার্কার কোনো ওয়ার্কফ্লোর ইভেন্ট হিস্ট্রি রিপ্লে করে সেটি পুনর্গঠন করতে পারে। রিপ্লের সময় এটি আগে রেকর্ড করা অ্যাক্টিভিটির ফলাফলগুলো পুনরায় ব্যবহার করে।

ওয়ার্কফ্লো চলমান থাকা অবস্থায় অ্যাপ্লিকেশনটি রিডিপ্লয় করা হলে, সংরক্ষিত স্টেট ও এক্সিকিউশন হিস্ট্রি আর সামঞ্জস্যপূর্ণ নাও থাকতে পারে। Temporal এই সমস্যার সমাধান করে Worker Versioning এবং ওয়ার্কফ্লো প্যাচিংয়ের মাধ্যমে। চেকপয়েন্ট-ভিত্তিক সিস্টেমের ক্ষেত্রে, অসামঞ্জস্যপূর্ণ পরিবর্তন রোলআউট করার আগে স্কিমা মাইগ্রেশনের পরিকল্পনা করুন এবং বিদ্যমান সংরক্ষিত স্টেটগুলোর বিপরীতে রিকভারি টেস্ট করুন।

একই প্রতিনিধিত্বমূলক টাস্কগুলো একাধিকবার চালান এবং pass@k (kটি প্রচেষ্টার মধ্যে অন্তত একটি সফল হয় কি না) ও pass^k (kটি প্রচেষ্টার সবগুলোই সফল হয় কি না)-এর মধ্যে পার্থক্য করুন

একটিমাত্র সামগ্রিক সাফল্যের হারের ওপর নির্ভর না করে টাস্কের ক্যাটাগরি এবং ওয়ার্কফ্লো ভার্সন অনুযায়ী ফলাফল পরিমাপ করুন। প্রথম প্রচেষ্টায় সাফল্য, পুনরাবৃত্ত রানের মধ্যে ধারাবাহিকতা, p95 ল্যাটেন্সি, প্রতিটি সম্পন্ন টাস্কের খরচ, এবং কত অনুপাতে মানুষের হস্তক্ষেপ প্রয়োজন হয় তা ট্র্যাক করুন। সাফল্যের হারের জন্য নমুনার আকার এবং অনিশ্চয়তার ব্যবধান রিপোর্ট করুন।

AI এজেন্ট অর্কেস্ট্রেশন কী?

AI এজেন্ট অর্কেস্ট্রেশন কীভাবে কাজ করে: এক্সিকিউশন ইঞ্জিনের ভেতরে

কখন AI এজেন্ট অর্কেস্ট্রেশন ব্যবহার করবেন?

AI এজেন্ট অর্কেস্ট্রেশনের আর্কিটেকচার এবং সেগুলোর সুবিধা-অসুবিধা

কেন্দ্রীভূত অর্কেস্ট্রেশন

বিকেন্দ্রীভূত অর্কেস্ট্রেশন

স্তরভিত্তিক অর্কেস্ট্রেশন

ধারাবাহিক, সমান্তরাল এবং হ্যান্ডঅফ-ভিত্তিক এক্সিকিউশন

এআই এজেন্ট অর্কেস্ট্রেশনের সাধারণ ব্যর্থতা

প্রোডাকশনে নির্ভরযোগ্যতার জন্য এআই এজেন্ট অর্কেস্ট্রেশনের ৭টি সেরা পদ্ধতি

১. সুস্পষ্ট টাস্ক কন্ট্রাক্ট, গ্রহণযোগ্যতার মানদণ্ড এবং থামার শর্ত নির্ধারণ করুন

২. অর্কেস্ট্রেটরকে হালকা রাখুন এবং কাঠামোবদ্ধ হ্যান্ডঅফ নিশ্চিত করুন

৩. ওয়ার্কফ্লোর স্টেট সংরক্ষণ করুন এবং কনটেক্সটের বৃদ্ধি নিয়ন্ত্রণ করুন

৪. ব্যর্থতা-সচেতন রিট্রাই এবং পুনরুদ্ধারযোগ্য টুল এক্সিকিউশন ডিজাইন করুন

৫. সুস্পষ্ট রিসোর্স বাজেটসহ কাজ রাউট ও সমান্তরাল করুন

৬. অনুমোদন বাধ্যতামূলক করুন এবং এজেন্টের এক্সিকিউশন বিচ্ছিন্ন রাখুন

৭. আউটপুট স্বাধীনভাবে যাচাই করুন এবং পুনরুদ্ধারের আচরণ পরীক্ষা করুন

কী ভুল হয়েছে তা শনাক্ত করতে ওয়ার্কফ্লো ট্রেস করুন

আউটপুট স্বাধীনভাবে পর্যালোচনা করুন

পুনরুদ্ধার পরীক্ষা করতে ইচ্ছাকৃতভাবে ব্যর্থতা তৈরি করুন

AI এজেন্ট অর্কেস্ট্রেশন: সাধারণ জিজ্ঞাসা

এন্টারপ্রাইজ স্কেলে বিচ্ছিন্ন AI এজেন্টগুলো কেন ব্যর্থ হয়?

AI এজেন্টে অসীম রিট্রাই লুপ কীভাবে প্রতিরোধ করবেন?

ক্র্যাশের পর একটি AI এজেন্ট ওয়ার্কফ্লো কীভাবে আবার শুরু করবেন?

AI এজেন্ট অর্কেস্ট্রেশনের নির্ভরযোগ্যতা কীভাবে টেস্ট করবেন?