০৭ অক্টো, ২০২৫·8 মিনিট
উৎপাদনে ভেঙে না পড়া এজেন্টিক সিস্টেম ডিজাইন করা
কেন অনেক এজেন্টিক সিস্টেম উৎপাদনে ব্যর্থ হয় এবং কীভাবে স্টেট মেশিন, স্পষ্ট টুল চুক্তি, রিট্রাই প্যাটার্ন ও গভীর পর্যবেক্ষণ যোগ করে নির্ভরযোগ্য এজেন্ট ডিজাইন করবেন।
কেন অনেক এজেন্টিক সিস্টেম উৎপাদনে ব্যর্থ হয় এবং কীভাবে স্টেট মেশিন, স্পষ্ট টুল চুক্তি, রিট্রাই প্যাটার্ন ও গভীর পর্যবেক্ষণ যোগ করে নির্ভরযোগ্য এজেন্ট ডিজাইন করবেন।
এজেন্টিক সিস্টেমগুলো সেই অ্যাপ্লিকেশন যেখানে একটি LLM কেবল একটি প্রশ্নের উত্তর দেয় না, বরং পরবর্তী কী করা হবে তা সিদ্ধান্ত নিয়েই থাকে: কোন টুল কল করতে হবে, কোন ডেটা আনতে হবে, কোন ধাপ চালাতে হবে, এবং কখন কাজটি "সম্পন্ন" বলে মনে হবে। এগুলো একটি মডেল, টুলসেট (API, ডাটাবেস, সার্ভিস), পরিকল্পনা/নির্বাহী লুপ, এবং সবকিছুকে একত্রিত করার অবকাঠামো মিলিয়ে গঠিত।
ডেমোতে এটা জাদুর মতো লাগে: একটি এজেন্ট একটি পরিকল্পনা বানায়, কয়েকটি টুল কল করে, এবং নিখুঁত ফল দেয়। সুখী পথটা ছোট, ল্যাটেন্সি কম, এবং সবকিছু একই সময়ে ব্যর্থ হয় না।
বাস্তব ওয়ার্কলোডে একই এজেন্ট এমনভাবে চাপের মধ্যে পড়ে যা ডেমো কখনো দেখেনি:
ফলাফল: ফ্লাকি আচরণ যা পুনরাবৃত্তিযোগ্য নয়, নীরব ডেটা করাপশন, এবং ব্যবহারকারী ফ্লো যা মাঝে মাঝে হ্যাং বা অনন্ত লুপে পড়ে।
ফ্লাকি এজেন্ট কেবল "আনন্দ" নষ্ট করে না। এগুলো:
এই আর্টিকেলটি ইঞ্জিনিয়ারিং প্যাটার্ন নিয়ে, "ভাল প্রম্পট" নয়। আমরা স্টেট মেশিন, স্পষ্ট টুল চুক্তি, রিট্রাই ও ব্যর্থতা-হ্যান্ডলিং কৌশল, মেমোরি ও কনকারেন্সি কন্ট্রোল, এবং এমন পর্যবেক্ষণযোগ্যতা প্যাটার্ন দেখব যা এজেন্টিক সিস্টেমকে লোডে পূর্বানুমানযোগ্য করে—কেবল স্টেজে চমৎকার নয়।
অধিকাংশ এজেন্ট সিস্টেম সিঙ্গেল হ্যাপি-পাথ ডেমোতে ঠিক ই মনে হয়। কিন্তু যখন ট্রাফিক, টুলস ও এজ কেস একসাথে আসে, তখন এগুলো ব্যর্থ হয়।
ভারে-অরক্ষিত অর্কেস্ট্রেশন ধরে নেয় মডেল এক বা দুই কলেই "ঠিক করবে"। বাস্তবে আপনি recurring প্যাটার্ন দেখবেন:
স্পষ্ট স্টেট ও শেষ শর্ত ছাড়া এই আচরণগুলো অনিবার্য।
LLM স্যাম্পলিং, ল্যাটেন্সি ভেরিয়েবিলিটি, এবং টুল টাইমিং লুকানো অ-ডিটারমিনিজম তৈরি করে। একই ইনপুট বিভিন্ন শাখা অতিক্রম করতে পারে, ভিন্ন টুল কল করতে পারে, বা টুল ফলাফল ভিন্নভাবে ব্যাখ্যা করতে পারে।
স্কেলে, টুল সমস্যা প্রাধান্য পায়:
এই প্রত্যেকটি অবস্থা স্পিউরিয়াস লুপ, রিট্রাই, বা ভুল চূড়ান্ত উত্তরে রূপান্তরিত হয়।
10 RPS-এ যা বিরলভাবে ভেঙে, 1,000 RPS-এ সেটি নিয়মিত ভেঙে। কনকারেন্সি প্রকাশ করে:
প্রোডাক্ট টিম সাধারণত ডিটারমিনিস্টিক ওয়ার্কফ্লো, স্পষ্ট SLA এবং অডিটেবিলিটি প্রত্যাশা করে। এজেন্টগুলো, যদি ছেড়ে দেওয়া হয়, তারা দেয় প্রবাবিলিস্টিক, বেস্ট-এফোর্ট আচরণ দুর্বল গ্যারান্টি সহ।
যখন আর্কিটেকচার এই মিসম্যাচ উপেক্ষা করে—এজেন্টকে প্রচলিত সার্ভিসের মতো বিবেচনা করে বরং স্টোকাস্টিক প্ল্যানার হিসেবে নয়—তখন সিস্টেমগুলি সবচেয়ে বেশি প্রয়োজন তখনই অপ্রত্যাশিতভাবে আচরণ করে।
উৎপাদন-রেডি এজেন্ট মানে "বুদ্ধিমান প্রম্পট" নয়, বরং শৃঙ্খলাবদ্ধ সিস্টেম ডিজাইন। একটি ব্যবহারযোগ্য ধারণা হলো: এগুলোকে ছোট, পূর্বানুমানযোগ্য মেশিন হিসেবে ভাবুন যা মাঝে মাঝে একটি LLM কল করে, কখনোই রহস্যময় LLM ব্লব হিসেবে নয় যা মাঝে মাঝে আপনার সিস্টেম স্পর্শ করে।
চারটি বৈশিষ্ট্য সবচেয়ে গুরুত্বপূর্ণ:
এই বৈশিষ্ট্যগুলো প্রম্পট থেকে আসে না; এগুলো আসে কাঠামো থেকে।
অধিকাংশ দল শুরু করে এমন দিয়ে: "while not done, call the model, let it think, maybe call a tool, repeat"। এটি প্রোটোটাইপ করা সহজ কিন্তু চালানো কঠিন।
একটি নিরাপদ প্যাটার্ন হল এজেন্টকে একটি স্পষ্ট ওয়ার্কফ্লো হিসেবে উপস্থাপন করা:
COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE)।এটি এজেন্টকে একটি স্টেট মেশিনে রূপান্তর করে যেখানে প্রতিটি ধাপ পরিদর্শনযোগ্য, টেস্টযোগ্য এবং রেপ্লেয়েবল। ফ্রি-ফর্ম লুপ নমনীয় মনে হলেও, স্পষ্ট ওয়ার্কফ্লো হলো সেই যা ইনসিডেন্টকে ডিবাগযোগ্য ও আচরণকে অডিটেবল করে।
মোনোলিথিক এজেন্টগুলো যেগুলো "সবকিছু করে" আকর্ষণীয়, কিন্তু এগুলো অনাবশ্যকভাবে বিভিন্ন দায়িত্বের মধ্যে টাইট কাপলিং তৈরি করে: পরিকল্পনা, রিট্রিভাল, বিজনেস লজিক, UI অর্কেস্টেশন ইত্যাদি।
তার বদলে ছোট, ভাল-স্কোপড এজেন্ট বা স্কিলগুলো সংগঠিত করুন:
প্রতিটি স্কিলের নিজস্ব স্টেট মেশিন, টুল এবং সেফটি রুল থাকতে পারে। কম্পোজিশন লজিক তখন উচ্চ-স্তরের ওয়ার্কফ্লো হয়ে যায়, একক এজেন্টের ভেতরের ক্রমবর্ধমান প্রম্পট নয়।
এই মডিউল্যারিটি প্রতিটি এজেন্টকে বোঝা সহজ রাখে এবং আপনি একটি ক্ষমতা বাড়লে অন্যগুলোকে স্থিতিশীলতা বিঘ্নিত না করে আপডেট করতে পারবেন।
একটি ব্যবহারযোগ্য মানসিক মডেল হলো এজেন্টকে তিনটি স্তরে ভাগ করে দেখা:
সিদ্ধান্ত নীতি (LLM প্রম্পট + মডেল)
কীভাবে এজেন্ট পরবর্তী কাজ নির্বাচন করে তা ধারণ করে, কঠোর সীমার ভেতরে ব্যাখ্যাত। মডেল, টেম্পারেচার বা প্রম্পট বদলাতে পারবেন সিস্টেম তারের ছাড়াই।
স্টেট মেশিন / ওয়ার্কফ্লো ইঞ্জিন
কোথায় আপনি প্রক্রিয়ায় আছেন, কোন ট্রানজিশন সম্ভব, এবং কিভাবে অগ্রগতি স্থায়ী হবে তা নিয়ন্ত্রণ করে। নীতি একটি পদক্ষেপ প্রস্তাব করে; স্টেট মেশিন সেটি যাচাই করে ও প্রয়োগ করে।
টুলিং লেয়ার
বাস্তবে কি ঘটতে পারে তা বাস্তবায়ন করে: API, ডাটাবেস, কিউ, বাইরের সার্ভিস। টুলগুলো সংকীর্ণ, ভাল-টাইপ করা চুক্তি প্রকাশ করে এবং অনুমোদন, রেট লিমিট, ইনপুট ভ্যালিডেশন প্রয়োগ করে।
এই পৃথকীকরণ লুকানো বিজনেস লজিক প্রম্পটের ভেতরে বা টুল বর্ণনার ভেতরে লুকিয়ে রাখার ফাঁদ থেকে বাঁচায়। LLM হবে একটি সিদ্ধান্ত উপাদান, পরিষ্কার, ডিজিটাল শেলের ভিতরে নয়।
সর্বাধিক নির্ভরযোগ্য এজেন্টিক সিস্টেমগুলো সবচেয়ে চমকপ্রদ ডেমো নয়—এগুলো হলো সেইগুলো যার আচরণ আপনি সাদা বোর্ডে ব্যাখ্যা করতে পারেন।
কয়েকটি কনক্রিট নিয়ম:
ছোট, কম্পোজেবল, ভাল-স্ট্রাকচার্ড এজেন্টের দিকে এই ঝোঁকই সিস্টেমকে বাড়তে দেয় জটিলতায় নিজেই ভেঙে পড়ার বদলে।
অধিকাংশ এজেন্ট ইমপ্লিমেন্টেশন শুরু হয় একটি "চিন্তা কর, কাজ কর, পর্যবেক্ষণ কর" লুপে যেখানে LLM কল থাকে। ডেমোর জন্য এটি ঠিক আছে, কিন্তু এটি দ্রুত অদৃশ্য ও ভঙ্গুর হয়ে পড়ে। একটি ভালো পন্থা হল এজেন্টকে একটি স্পষ্ট স্টেট মেশিন হিসেবে বিবেচনা করা: সীমিত স্টেট সেট এবং ইভেন্ট দ্বারা ট্রিগার হওয়া সুস্পষ্ট ট্রানজিশন।
মডেলকে পরবর্তী সিদ্ধান্ত নিজের ইচ্ছায় নির্ধারণ করতে না দিয়ে, একটি ছোট স্টেট ডায়াগ্রাম সংজ্ঞায়িত করুন:
এই স্টেটগুলোর মধ্যে ট্রানজিশনগুলো টাইপ করা ইভেন্ট দ্বারা ট্রিগার হয় যেমন UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded, বা HumanOverride। প্রতিটি ইভেন্ট ও বর্তমান স্টেট মিলিয়ে পরবর্তী স্টেট ও করণীয় নির্ধারিত হয়।
এটা রিট্রাই ও টাইমআউটকে সরল করে: আপনি প্রতিটি স্টেটে পলিসি সংযুক্ত করবেন (উদা., CALL_TOOL 3 বার এক্সপোনেনশিয়াল ব্যাকঅফ সহ রিট্রাই করতে পারে, PLAN সাধারণত রিট্রাই নাও করা হতে পারে) তা কোডবেস জুড়ে ছড়িয়ে থাকা রিট্রাই লজিকের বদলে।
বর্তমান স্টেট ও ন্যূনতম প্রাসঙ্গিক কনটেক্সট একটি বাহ্যিক স্টোরে (ডাটাবেস, কিউ, বা ওয়ার্কফ্লো ইঞ্জিন) পারসিস্ট করুন। এজেন্ট তখন একটি পিওর ফাংশন হয়ে যায়:
next_state, actions = transition(current_state, event, context)
এটি কী সহজ করে:
স্টেট মেশিন থাকলে এজেন্টের প্রতিটি ধাপ স্পষ্ট: কোন স্টেটে ছিল, কোন ইভেন্ট ঘটলো, কোন ট্রানজিশন fired হলো, এবং কোন সাইড-ইফেক্টসমূহ ঘটলো। এই স্বচ্ছতা ডিবাগিং দ্রুত করে, ইনসিডেন্ট ইনভেস্টিগেশন সহজ করে, এবং কমপ্লায়েন্স রিভিউর জন্য প্রাকৃতিক অডিট ট্রেইল তৈরি করে। লগ ও স্টেট ইতিহাস থেকে প্রমাণ দেখাতে পারবেন যে নির্দিষ্ট ঝুঁকিপূর্ণ অ্যাকশনগুলো কেবল নির্দিষ্ট স্টেট থেকেই ও নির্ধারিত শর্তে নেওয়া হয়।
টুলগুলো তখনই এজেন্টকে আরও পূর্বানুমানযোগ্য করে যখন তারা "প্রম্পটে লুকানো API" না হয়ে ভালভাবে ডিজাইন করা ইন্টারফেস হিসেবে থাকে।
প্রতিটি টুলের কাছে থাকা উচিত:
InvalidInput, NotFound, RateLimited, TransientFailure) স্পষ্ট সেমান্টিকস সহ।এই চুক্তিগুলোকে মডেলের কাছে স্ট্রাকচার্ড ডকুমেন্টেশন হিসেবে দেখান, প্রয়োজনীয় যে একটি বড় পাঠ নয়। এজেন্ট প্ল্যানার জানবে কোন এরর রিট্রায়েবল, কোনটি ব্যবহারকারী হস্তক্ষেপ দরকার, এবং কোনটি ওয়ার্কফ্লো থামাবে।
টুল I/O-কে যেকোনো প্রোডাকশন API-এর মতো হ্যান্ডল করুন:
এতে প্রম্পট সহজ হয়: বিস্তর নির্দেশনার বদলে স্কিমা-চালিত নির্দেশনা ব্যবহার করুন। স্পষ্ট সীমা হ্যালুসিনেটেড আর্গুমেন্ট ও অযৌক্তিক টুল সিকোয়েন্স কমায়।
টুলগুলো হয়তো বিকশিত হবে; এজেন্ট প্রতিবার ভাঙলে চলবে না।
v1, v1.1, v2) এবং এজেন্টকে একটি ভার্সনে পিন করুন।প্ল্যানিং লজিক তখন নিরাপদে বিভিন্ন মচ্যুরিটি স্তরের এজেন্ট ও টুল মিশাতে পারে।
টুল চুক্তি পার্শিয়াল ফেলিউর মনে রেখে ডিজাইন করুন:
এজেন্ট তারপর অভিযোজিত হতে পারে: কম কার্যকারিতায় ফ্লো চালিয়ে যাওয়া, ব্যবহারকারীকে নিশ্চিতকরণ জিজ্ঞাসা করা, বা বিকল্প টুলে স্যুইচ করা।
টুল চুক্তি হলো নিরাপত্তা সীমা এনকোড করার প্রাকৃতিক জায়গা:
confirm: true) চাওয়া।সরভার-সাইড চেকের সঙ্গে এটা মিলিয়ে নিন; কেবল মডেলের আচরণের উপর নির্ভর করবেন না।
যখন টুলগুলো স্পষ্ট, ভ্যালিডেটেড, ভার্সন্ড করা চুক্তি রাখে, প্রম্পট ছোট হয়, অর্কেস্ট্রেশন লজিক সরল হয়, এবং ডিবাগিং অনেক সহজ হয়ে যায়। আপনি কমপ্লেক্সিটি ভাঙে প্রম্পটের ভেতর থেকে নির্ধারিত স্কিমা ও পলিসিতে নিয়ে আসেন, যা হ্যালুসিনেটেড টুল কল ও অপ্রত্যাশিত সাইড-এফেক্ট কমায়।
নির্ভরযোগ্য এজেন্টিক সিস্টেম ধরে নেয় যে সবকিছুই কখনো না কখনো ফেল করবে: মডেল, টুল, নেটওয়ার্ক এমনকি আপনার কোঅরডিনেশন লেয়ারও। লক্ষ্য হল ব্যর্থতাকে এড়ানো নয়, বরং এটাকে সস্তা ও নিরাপদ করা।
আইডেম্পোটেন্সি অর্থ: একই অনুরোধ বারবার করলে বাহ্যিকভাবে একই ফলাফল পাওয়া যায়। LLM এজেন্টরা প্রায়ই পারশিয়াল ফেলিউর বা অস্পষ্ট রেসপন্সের পরে টুল কল পুনরাবৃত্তি করে।
টুলগুলোকে আইডেম্পোটেন্ট করে তুলুন:
request_id অন্তর্ভুক্ত করে। টুলটি এটি স্টোর করে এবং একই ID দেখলে একই ফলাফল রিটার্ন করে।ট্রান্সিয়েন্ট ফেলিউরের (টাইমআউট, রেট লিমিট, 5xx) জন্য কাঠামোভুক্ত রিট্রাই ব্যবহার করুন: এক্সপোনেনশিয়াল ব্যাকঅফ, জিটার এবং কড়া ম্যাক্স অ্যাটেম্পটস। প্রত্যেক প্রচেষ্টা লগ করুন করিলেশন আইডি সহ যাতে এজেন্ট আচরণ ট্রেস করা যায়।
স্থায়ী ফেলিউরের (4xx, ভ্যালিডেশন এরর, ব্যবসায়িক নিয়ম লঙ্ঘন) জন্য রিট্রাই করবেন না। একটি স্ট্রাকচার্ড এরর এজেন্ট পলিসিকে জানানো উচিত যাতে এটি প্ল্যান পরিবর্তন করতে, ব্যবহারকারীকে জিজ্ঞাসা করতে, বা ভিন্ন টুল বেছে নিতে পারে।
এজেন্ট ও টুল লেয়ারে সার্কিট ব্রেকার বাস্তবায়ন করুন: বারবার ব্যর্থতার পরে অস্থায়ীভাবে সেই টুল কল ব্লক করুন এবং দ্রুত ব্যর্থ করুন। এটিকে সুস্পষ্ট ফালব্যাক—ডিগ্রেডেড মোড, ক্যাশড ডেটা, বা বিকল্প টুল—এর সঙ্গে জোড়া লাগান।
এজেন্ট লুপ থেকে ব্লাইন্ড রিট্রাই এড়ান। আইডেম্পোটেন্ট টুল ও স্পষ্ট ব্যর্থতা শ্রেণী ছাড়া, আপনি শুধু সাইড-এফেক্ট, ল্যাটেন্সি ও খরচ বাড়াবেন।
নির্ভরযোগ্য এজেন্ট শুরু হয় পরিষ্কারভাবে চিন্তা করা থেকে: কি স্টেট এবং কোথায় থাকে।
একটি এজেন্টকে এমনভাবে বিবেচনা করুন যেমন একটি সার্ভিস একটি রিকোয়েস্ট হ্যান্ডেল করছে:
মিশ্রিত করলে বিভ্রান্তি ও বাগ হয়—উদা., ক্ষণস্থায়ী টুল ফলাফলগুলো মেমোরিতে রাখলে এজেন্ট ভবিষ্যত কথোপকথনে স্টেলে বা অনুপযুক্ত কনটেক্সট ব্যবহার করতে পারে।
প্রধান তিনটি অপশন:
ভাল নিয়ম: LLM একটি স্পষ্ট স্টেট অবজেক্টের ওপর স্ট্যাটলেস ফাংশন। সেই অবজেক্ট বাহ্যিকভাবে পারসিস্ট করুন এবং প্রম্পটগুলো সেখান থেকেই পুনর্নির্মাণ করুন।
একটি সাধারণ ব্যর্থতা প্যাটার্ন হল কথোপকথনের লগ, ট্রেস বা কাঁচা প্রম্পটকে ডি-ফ্যাক্টো মেমোরি হিসেবে ব্যবহার করা।
সমস্যাগুলো:
এর বদলে সংজ্ঞায়িত করুন স্ট্রাকচার্ড মেমোরি স্কিমা: user_profile, project, task_history ইত্যাদি। লগগুলো স্টেট হতে ডেরাইভ করুন, উল্টোভাবে নয়।
যখন বহু টুল বা এজেন্ট একই এন্টিটি (উদা., CRM রেকর্ড বা টাস্ক স্ট্যাটাস) আপডেট করে, তখন আপনাকে মৌলিক কনসিস্টেন্সি কন্ট্রোল প্রয়োগ করতে হবে:
উচ্চ-মুল্যের অপারেশনের জন্য সিদ্ধান্ত লগ রেকর্ড করুন কথোপকথন লগ থেকে আলাদা: কী পরিবর্তন হয়েছে, কেন, ও কোন ইনপুটের উপর ভিত্তি করে।
ক্র্যাশ, ডেপ্লয় বা রেট লিমিট সহ্য করতে, ওয়ার্কফ্লোগুলো হওয়া উচিত রিসিউমেবল:
এটি টাইম ট্রাভেল ডিবাগিং-ও যোগ্য করে: আপনি নির্দিষ্ট সেই স্টেট পরিদর্শন করে পুনরায় চালাতে পারবেন যা খারাপ সিদ্ধান্তের দিকে নিয়ে গিয়েছিল।
মেমোরি একটি দায়িত্ব যেমনটি একটি সম্পদ। উৎপাদন এজেন্টের জন্য:
মেমোরিকে একটি প্রোডাক্ট সারফেস হিসেবে আচরণ করুন: ডিজাইন করা, ভার্সনকৃত এবং গভর্ন করা — কেবল একটি বাড়তে থাকা টেক্সট ডাম্প নয়।
এজেন্টগুলো সাদা বোর্ডে ধারালোভাবে সিকোয়েন্সিয়াল মনে হলেও বাস্তবে এগুলো বিতরণকৃত সিস্টেমের মতো আচরণ করে। অনেক কনকারেন্ট ব্যবহারকারী, টুল, ও ব্যাকগ্রাউন্ড জব থাকলে আপনি রেস কন্ডিশন, ডুপ্লিকেট কাজ ও অর্ডারিং সমস্যা মিলিয়ে নেবেন।
সাধারণ ফেইলিওর মোড:
আপনি এগুলোকে আইডেম্পোটেন্ট টুল চুক্তি, স্পষ্ট ওয়ার্কফ্লো স্টেট, এবং ডাটা লেয়ারে অপটিমিস্টিক/পেসিমিস্টিক লক দিয়ে মোকাবেলা করবেন।
সিঙ্ক্রোনাস রিকোয়েস্ট–রেসপন্স ফ্লো সহজ কিন্তু ভঙ্গুর: প্রত্যেক নির্ভরশীলতা আপ হতে হবে, রেট সীমার ভিতরে এবং দ্রুত হতে হবে। এজেন্ট যখন বহু টুলে ফ্যান-আউট করে বা প্যারালাল সাব-টাস্ক চালায়, তখন দীর্ঘ চলমান বা সাইড-এফেক্টফুল ধাপগুলোকে কিউ-র পিছনে সরে নিন।
কিউ-ভিত্তিক অর্কেস্ট্রেশন আপনাকে দেয়:
এজেন্টরা সাধারণত তিন ধরনের লিমিটে আঘাত পায়:
আপনি একটি স্পষ্ট রেট-লিমিট লেয়ার লাগাবেন per-user, per-tenant, ও global থ্রোটল সহ। টোকেন বকেট বা লিকি বকেট ব্যবহার করুন নীতি প্রয়োগ করতে, এবং স্পষ্ট এরর টাইপ (RATE_LIMIT_SOFT, RATE_LIMIT_HARD) রিটার্ন করুন যাতে এজেন্ট গ্রেসফুলি ব্যাক-অফ নিতে পারে।
ব্যাকপ্রেশার হচ্ছে কিভাবে সিস্টেম নিজেকে সুরক্ষা করে চাপের মধ্যে। কৌশলগুলো:
কিউ গভীরতা, ওয়ার্কার ইউটিলাইজেশন, মডেল/টুল এরর রেট এবং ল্যাটেন্সি শতাংশের মনিটরিং রাখুন। বাড়তে থাকা কিউ ও বাড়তে থাকা ল্যাটেন্সি বা 429/503 আপনার সতর্ক সংকেত।
যদি আপনি দ্রুত জবাব দিতে না পারেন যে: এটি কী করেছে? এবং এটি কেন করেছে? তাহলে আপনি এজেন্টকে নির্ভরযোগ্য করতে পারবেন না। এজেন্টিক সিস্টেমের পর্যবেক্ষণযোগ্যতা সেই উত্তরগুলোকে সস্তা ও নির্ভুল করে তোলার বিষয়ে।
পর্যবেক্ষণ এমনভাবে ডিজাইন করুন যাতে একটি টাস্কের ট্রেস জুড়ে থাকে:
ট্রেসের ভেতরে স্ট্রাকচার্ড লগ সংযুক্ত করুন গুরুত্বপূর্ণ সিদ্ধান্তের জন্য (রাউটিং পছন্দ, প্ল্যান সংশোধন, গার্ডরেইল ট্রিগার) এবং মেট্রিক্স ভলিউম ও স্বাস্থ্য দেখাতে।
একটি ব্যবহারযোগ্য ট্রেসে সাধারণত থাকে:
প্রম্পট, টুল ইনপুট ও আউটপুট স্ট্রাকচার্ড ফর্মে লগ করুন, কিন্তু আগে একটি রেডাকশন লেয়ার দিয়ে পাঠান:
তিমধ্যন্ত কাঁচা কনটেন্ট নিচু পরিবেশে ফিচার ফ্ল্যাগের পেছনে রাখুন; প্রোডাকশনে ডিফল্ট রেডাক্টেড ভিউ রাখা উচিত।
কমপক্ষে ট্র্যাক করুন:
ইনসিডেন্ট হলে, ভালো ট্রেস ও মেট্রিক আপনাকে বলবে: “এজেন্ট ফ্লাকি” থেকে সঠিক বিবৃতি যেমন: “P95 টাস্ক ToolSelection-এ 2 রিট্রাইয়ের পরে ব্যর্থ হচ্ছে কারণ billing_service-এ নতুন স্কিমা,” যা ডায়াগনসিসকে ঘণ্টা থেকে মিনিটে নামিয়ে আনে এবং কনক্রিট টোনিং লেভার দেয়।
এজেন্ট টেস্ট করা মানে তাদের কল করা টুল এবং সবকিছুকে একসাথে জোড়া ফ্লো—উভয়কেই টেস্ট করা। এটিকে ডিস্ট্রিবিউটেড সিস্টেম টেস্টিং হিসেবে নিন, কেবল প্রম্পট টুইকিং হিসেবে নয়।
টুল বাউন্ডারিতে ইউনিট টেস্ট দিয়ে শুরু করুন:
এই টেস্টগুলো কখনোই LLM-এ নির্ভর করবে না। আপনি সরাসরি টুল কল করে সিনথেটিক ইনপুট দিয়ে ঠিক আউটপুট বা এরর চেক করবেন।
ইন্টিগ্রেশন টেস্টগুলো এজেন্ট ওয়ার্কফ্লো সম্পূর্ণভাবে এক্সারসাইজ করে: LLM + টুল + অর্কেস্ট্রেশন।
এগুলো সিনারিও-ভিত্তিক টেস্ট হিসেবে মডেল করুন:
এই টেস্টগুলো assert করবে স্টেট ট্রানজিশন ও টুল কল—প্রতি টোকেন নয়। যাচাই করুন: কোন টুলগুলো কল হয়েছে, কী আর্গুমেন্টে, কোন অর্ডারে, এবং এজেন্ট কী চূড়ান্ত স্টেট/রেজাল্টে পৌঁছেছে।
টেস্টগুলো রিপিটেবল রাখতে, LLM রেসপন্স ও টুল আউটপুট দুইটাকেই ফিক্সচার করুন:
একটি সাধারণ প্যাটার্ন:
with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
result = run_agent_scenario(input_case)
assert result.state == "COMPLETED"
প্রম্পট বা স্কিমা পরিবর্তন হলে অনিবার্যভাবে একটি রিগ্রেশন রান ট্রিগার করুন:
স্কিমা ইভোলিউশন (ফিল্ড যোগ/টাইটেন টাইপ) এর নিজস্ব রিগ্রেশন কেস থাকা উচিত যাতে পুরোনো চুক্তিতে আশা করা এজেন্ট বা টুল ব্রেক না করে।
নতুন মডেল, পলিসি, বা রাউটিং স্ট্র্যাটেজি সরাসরি প্রোডাকশনে পাঠাবেন না।
এর বদলে:
অফলাইন গেট পাস করলে মাত্র নতুন ভেরিয়ান্ট প্রোডাকশনে ধাপে ধাপে রোল আউট করুন, আদর্শত ফিচার ফ্ল্যাগ ও গ্র্যাজুয়াল রোলআউটসহ।
এজেন্ট লগগুলো প্রায়ই সংবেদনশীল ইউজার ডেটা রাখে। টেস্টিংতে এটি সম্মান করুন:
CI পাইপলাইনে এই নিয়মগুলো কোডিফাই করুন যাতে কোনো টেস্ট আর্টিফ্যাক্ট অ্যানোনিমাইজেশন ছাড়া তৈরি বা সংরক্ষিত না হতে পারে।
উৎপাদনে এজেন্ট পরিচালনা করা স্থির সার্ভিস চালানোর মত; আপনার রোলআউট কৌশল, স্পষ্ট নির্ভরযোগ্যতার লক্ষ্যমাত্রা, এবং নিয়মিত পরিবর্তন নিয়ন্ত্রণ লাগবে।
নতুন এজেন্ট বা আচরণ ধাপে ধাপে চালু করুন:
সবচেয়ে ভালো হলো ফিচার ফ্ল্যাগ ও কনফিগ-চালিত পলিস: রাউটিং নিয়ম, সক্ষম টুল, টেম্পারেচার, সেফটি সেটিংস—সবকিছু কনফিগ দিয়ে ডিপ্লয়যোগ্য ও তাৎক্ষণিকভাবে রিভার্টযোগ্য হওয়া উচিত।
ওভারঅল SLO সংজ্ঞায়িত করুন যা সিস্টেম হেলথ ও ব্যবহারকারী ভ্যালু দুটোই প্রতিফলিত করে:
এগুলোকে অ্যালার্টে বুনুন এবং ইনসিডেন্ট পরিচালনা এমন করুন যেমন অন্য কোনো প্রোডাকশন সার্ভিসের জন্য করতেন: স্পষ্ট অউনারশিপ, ট্রায়েজ রানেরবুক, এবং স্ট্যান্ডার্ড মিটিগেশন স্টেপ (রোলব্যাক ফ্ল্যাগ, ট্র্যাফিক ড্রেন, সেফ-মোড)।
লগ, ট্রেস ও কথোপকথনের ট্রান্সক্রিপ্ট ব্যবহার করে প্রম্পট, টুল ও পলিসি পরিমার্জন করুন। প্রতিটি পরিবর্তনকে ভার্সনকৃত আর্টিফ্যাক্ট হিসেবে বিবেচনা করুন: রিভিউ, অনুমোদন ও রোলব্যাক সক্ষম থাকুক।
নীরব প্রম্পট বা টুল পরিবর্তন এড়ান। নইলে আপনি রিগ্রেশনকে নির্দিষ্ট সম্পাদনার সাথে কোরেলেট করতে পারবেন না এবং ইনসিডেন্ট রেসপন্স অনুমানভিত্তিক হয়ে উঠবে।
উৎপাদন-রেডি এজেন্টিক সিস্টেম স্পষ্ট দায়িত্ব বিভাজন থেকে সুবিধা পায়। লক্ষ্য: এজেন্টকে সিদ্ধান্তে বুদ্ধিমান কিন্তু অবকাঠামোতে নির্বোধ রাখাটা।
1. গেটওয়ে / API এজ
ক্লায়েন্টদের জন্য একক এন্ট্রি পয়েন্ট (অ্যাপ, সার্ভিস, UI)। এখানে পরিচালিত হয়:
2. অর্কেস্ট্রেটর
অর্কেস্ট্রেটর হল "ব্রেনস্টেম", ব্রেইন নয়। এটি কোঅর্ডিনেট করে:
LLM(গুলি) অর্কেস্ট্রেটরের পেছনে থাকে, প্ল্যানার ও নির্দিষ্ট টুলগুলোতে ভাষাগত বোঝাপড়ার জন্য ব্যবহার করা হয়।
3. টুলিং ও স্টোরেজ লেয়ার
বিজনেস লজিক বিদ্যমান মাইক্রোসার্ভিস, কিউ, ও ডেটা সিস্টেমেই থাকে। টুলগুলো পাতলা র্যাপার:
অর্কেস্ট্রেটর কঠোর চুক্তি দিয়ে টুলগুলোকে ইনভোক করে, স্টোরেজ সিস্টেম সোর্স অফ ট্রুথ হিসেবে থাকে।
গেটওয়েতে অথ ও কোটা জোরদার করুন; অর্কেস্ট্রেটরে সেফটি, ডেটা অ্যাক্সেস ও পলিসি প্রয়োগ করুন। সব কল (LLM ও টুল) স্ট্রাকচার্ড টেলিমেট্রি এমিট করবে যা পায়পলাইনে যায়:
সরল আর্কিটেকচার (গেটওয়ে → সিঙ্গেল অর্কেস্ট্রেটর → টুলস) অপারেট করা সহজ; আলাদা প্ল্যানার, পলিসি ইঞ্জিন ও মডেল গেটওয়ে যোগ করলে নমনীয়তা বাড়ে কিন্তু সমন্বয়, ল্যাটেন্সি ও অপারেশনাল জটিলতা বাড়ে।
এখন আপনার কাছে আছে সেই মূল উপাদানগুলো যা এজেন্টকে বাস্তবে পূর্বানুমানযোগ্য করে তোলে: স্পষ্ট স্টেট মেশিন, স্পষ্ট টুল চুক্তি, শৃঙ্খলাবদ্ধ রিট্রাই, এবং গভীর পর্যবেক্ষণযোগ্যতা। শেষ ধাপ হল এই ধারনাগুলোকে আপনার টিমের জন্য নোটিশযোগ্য অনুশীলন হিসেবে রূপান্তর করা।
প্রতিটি এজেন্টকে একটি স্টেটফুল ওয়ার্কফ্লো হিসেবে ভাবুন:
এই উপাদানগুলো মিললে সিস্টেমগুলো gracefully degrade করে ভেঙে পড়ে না।
প্রোটোটাইপ এজেন্ট বাস্তবে পাঠানোর আগে নিশ্চিত করুন:
যদি কোনো আইটেম অনুপস্থিত থাকে, আপনি এখনও প্রোটোটাইপ মোডে আছেন।
একটি টেকসই সেটআপ সাধারণত ভাগ করে:
এতে প্রোডাক্ট টিম দ্রুত বাড়তে পারে যখন প্ল্যাটফর্ম টিম গ্যারান্টি দেয় নির্ভরযোগ্যতা, সিকিউরিটি ও কস্ট কন্ট্রোল।
একবার স্থিতিশীল ভিত্তি পাওয়া গেলে আপনি পরীক্ষা করতে পারেন:
এগুলো ধাপে ধাপে আনা উচিত: ফিচার ফ্ল্যাগের পেছনে নতুন লার্নিং কম্পোনেন্ট রাখুন, অফলাইন ইভ্যালুয়েশন ও শক্ত গার্ডরেইল সহ।
পুরো থিমটা একই: ব্যর্থতার জন্য ডিজাইন করুন, চতুরতার চেয়ে স্পষ্টতাকে অগ্রাধিকার দিন, এবং যেখানে আপনি দেখতে ও রিভার্ট করতে পারেন সেখানেই ইটারেট করুন। এই সীমাবদ্ধতাগুলো থাকলে এজেন্টিক সিস্টেমগুলো স্টার্টআপ-স্টাইল ভয়ানক প্রোটোটাইপ না হয়ে এমন অবকাঠামো হয়ে ওঠে যার ওপর আপনার সংস্থা নির্ভর করতে পারে।
একটি এজেন্টিক সিস্টেম হল এমন একটি অ্যাপ্লিকেশন যেখানে একটি LLM কেবল একটি প্রম্পটের উত্তর দেয় না, বরং পরবর্তী কী করা হবে তা নির্ধারণ করে: কোন টুল কল করা হবে, কোন ডেটা আনা হবে, ওয়ার্কফ্লোতে কোন ধাপ চলবে এবং কখন কাজ শেষ হবে।
সাধারণ চ্যাট সম্পলিশনের সঙ্গে তুলনায়, একটি এজেন্টিক সিস্টেমে থাকে:
উৎপাদনে, LLM হবে একটি বড়, নির্ধারিত শেলের মধ্যে একটি সিদ্ধান্ত গ্রহণকারী উপাদান — পুরো সিস্টেম নয়।
ডেমো সাধারণত একটি সুখী পথ চালায়: একজন ব্যবহারকারী, আদর্শ টুল আচরণ, সময়সীমা নেই, স্কিমা ড্রিফট নেই এবং সংক্ষিপ্ত কথোপকথন। উৎপাদনে এজেন্টরা সম্মুখীন হয়:
স্পষ্ট ওয়ার্কফ্লো, চুক্তি এবং ব্যার্থতা হ্যান্ডলিং ব্যতীত, এগুলো লুপ, স্টল, আংশিক কাজ এবং নীরব ত্রুটি তৈরি করে — যা ডেমোতে দেখা যায় না।
LLM-কে একটি স্পষ্ট কাঠামোর ভিতরে কাজ করান, মুক্ত-রূপ লুপ নয়:
এজেন্টকে একটি ওয়ার্কফ্লো হিসেবে মডেল করুন যেখানে নামকৃত স্টেট এবং টাইপ করা ইভেন্ট আছে, while not done: call LLM এর পরিবর্তে।
সাধারণ স্টেটগুলোর উদাহরণ:
টুলগুলোকে প্রোডাকশনের API হিসেবে ডিজাইন করুন, প্রম্পটের prose-এ লুকানো বিবরণ নয়। প্রত্যেক টুলের জন্য থাকা উচিত:
সবকিছুই অবশেষে ব্যর্থ হবে বলে ভাবুন: মডেল, টুল, নেটওয়ার্ক, কোঅরডিনেশন লেয়ার—সবই। লক্ষ্য হল ব্যর্থতাকে সস্তা ও নিরাপদ করা।
মূল প্যাটার্নগুলো:
request_id পাঠান, অথবা আপসার্ট-স্টাইল অপারেশন ব্যবহার করুন।স্পষ্টভাবে চিন্তা করুন: "কী স্টেট এবং কোথায় থাকে"।
LLM-কে স্ট্যাটলেস একটি ফাংশন হিসাবে আচরণ করান: উপযুক্ত স্টেট লোড করে প্রম্পট তৈরি করুন, মডেল কল করুন, এবং আপডেটেড স্টেট প্যাস্ট করুন। কাঁচা লগ বা কথোপকথন ইতিহাসকে সরাসরি মেমোরি হিসেবে ব্যবহার করবেন না; পরিবর্তে কাঠামোগত রেকর্ড তৈরি করুন ও রিটেনশন নীতি প্রয়োগ করুন।
এজেন্ট সিস্টেমকে লোডে বিতরণকৃত সিস্টেম হিসেবে বিবেচনা করুন — প্রতিটি ফ্লো সিকোয়েন্সিয়াল মনে হলেও কংকরেন্সি, ডুপ্লিকেট ও আউট-অফ-অর্ডার ইফেক্ট দেখা দেয়।
কী করতে হবে:
কিউ গভীরতা, ওয়ার্কার ইউটিলাইজেশন ও হার মনিটর করুন যাতে ওভারলোড আগেই ধরা পড়ে।
প্রতিটি টাস্কের জন্য আপনাকে দ্রুত উত্তর জানতে হবে: "এটা কি করেছে?" এবং "কেন করেছে?"। আসল লক্ষ্য হল সেই উত্তরগুলোকে সস্তা ও সুনির্দিষ্ট করা।
প্রয়োজনীয় উপাদান:
এজেন্টের টুলগুলো ও সেগুলোর স্টিচিং করা ফ্লো—উভয়কেই টেস্ট করুন। এটাকে বিতরণকৃত সিস্টেম টেস্টিং হিসেবে বিবেচনা করুন, কেবল প্রম্পট টিঙ্কারিং নয়।
কী কৌশল:
এজেন্টগুলো পরিচালনা করা স্থির মডেল পাঠানোর চেয়ে বেশি একটি বিতরণকৃত সিস্টেম চালানোর মত। রোলআউট, নির্ভরযোগ্যতার লক্ষ্যমাত্রা এবং পরিবর্তন নিয়ন্ত্রণ লাগে।
গাইডলাইন:
এছাড়া SLO সংজ্ঞায়িত করুন (রিলায়েবিলিটি, ল্যাটেন্সি, কোয়ালিটি) এবং ইনসিডেন্ট-ওয়ার্কফ্লো, রানবুক ও ফিচার ফ্ল্যাগ সহ রোলব্যাক কৌশল নির্দেশ করুন।
এভাবে আপনি ধাপ ধরে আচরণ ব্যাখ্যা, পরীক্ষা ও ডিবাগ করতে পারবেন, অদৃশ্য “এজেন্ট চিন্তা” লুপ অনুসরণ না করে।
PLAN – অনুরোধ ব্যাখ্যা করে ধাপে ভাগ করাCALL_TOOL – নির্দিষ্ট টুল বা ব্যাচ কল করাVERIFY – আউটপুট সহজ ইনভারিয়েন্ট বা সেকেন্ডারি মডেল চেক দিয়ে যাচাই করাRECOVER – রিট্রাই, ফলব্যাক, বা এসকালেশনDONE / FAILED – টার্মিনাল আউটকামইভেন্ট (যেমন ToolCallSucceeded, TimeoutExceeded) ও বর্তমান স্টেট মিলিয়ে পরবর্তী স্টেট নির্ধারণ করে। এতে রিট্রাই, টাইমআউট ও এরর হ্যান্ডলিং স্পষ্ট হয়, প্রম্পট বা গ্লু কোডে লুকানো থাকে না।
InvalidInput, NotFound, RateLimited, TransientFailureকল করার আগে ইনপুট ভ্যালিডেট করুন এবং পরে আউটপুট ভ্যালিডেট করুন। টুল ভ্যার্সনিং করুন এবং এজেন্টকে নির্দিষ্ট ভার্সনে পিন করুন যাতে স্কিমা পরিবর্তন নিঃশব্দে ফ্লো ভঙ্গ না করে।
এই প্যাটার্নগুলো ছাড়া রিট্রাই শুধু সাইড-এফেক্ট, লেটেন্সি ও কস্ট বাড়ায়।
429/503ভাল ট্রেসিং ও মেট্রিক থাকলে ইনসিডেন্ট বিশ্লেষণ "এজেন্ট ফ্লাকি মনে হচ্ছে" থেকে স্পষ্ট বিবৃতিতে পৌঁছায় যেমন: "P95 টাস্ক ToolSelection-এ 2 রিট্রাইয়ের পরে ব্যর্থ হচ্ছে কারণ billing_service-এ নতুন স্কিমা।"
টেস্ট ডেটা অ্যানোনিমাইজ করুন এবং CI-তে এই নিয়মগুলো কোডিফাই করুন।