দীর্ঘ-মেয়াদী এজেন্ট টাস্ক ও নিরাপত্তা
এই পাঠে যা শিখবেন
- সিঙ্গল-টার্ন প্রম্পট থেকে দীর্ঘ-মেয়াদী স্বায়ত্তশাসিত এজেন্টে যাওয়ার সময় কী নতুন সমস্যা তৈরি হয়
- একাধিক context window জুড়ে অগ্রগতি ট্র্যাক করার তিনটি বাস্তব পদ্ধতি
- ঠিক কোন ধরনের পদক্ষেপ "হার্ড-টু-রিভার্স" হিসেবে গণ্য হয়
- autonomy ও safety-র মধ্যে ভারসাম্য রাখার একটি বাস্তবিক প্রম্পট প্যাটার্ন
১ · সিঙ্গল-টার্ন থেকে দীর্ঘ-মেয়াদী এজেন্টে যাওয়া
আগের পাঠে (টুল ইউজ প্রম্পটিং) আমরা দেখেছি কীভাবে একটা এজেন্টকে টুল কল করে সরাসরি কাজ করতে বলা যায়। কিন্তু একটা একক প্রশ্ন-উত্তরের এজেন্ট, আর একটা এমন এজেন্ট যাকে ঘণ্টার পর ঘণ্টা ধরে — এমনকি একাধিক দিন ধরে — স্বাধীনভাবে একটা বড় টাস্ক সম্পন্ন করতে হয়, এই দুইয়ের মধ্যে ফারাক বিশাল। একে বলা যায় দীর্ঘ-মেয়াদী এজেন্ট টাস্ক (Long-horizon Agent Task)Long-horizon Agent Taskএমন একটা কাজ যা একটা মাত্র প্রম্পট-উত্তরে শেষ হয় না, বরং বহু ধাপ, বহু টুল কল, এবং প্রায়ই একাধিক আলাদা সেশন বা context window জুড়ে চলে — যেমন একটা সম্পূর্ণ কোডবেস রিফ্যাক্টর করা বা একটা বহু-পর্যায়ের গবেষণা প্রকল্প। — এখানে দুটো নতুন সমস্যা সামনে আসে যা ছোট প্রম্পটে দেখা যায় না — সীমিত context window-এর মধ্যে দীর্ঘ কাজের অগ্রগতি কীভাবে ধরে রাখা যায়, আর এজেন্ট যখন নিজের সিদ্ধান্তে একের পর এক পদক্ষেপ নিচ্ছে, তখন কীভাবে নিশ্চিত করা যায় যে সে কোনো অপরিবর্তনীয় ভুল করবে না।
২ · টোকেন বাজেট ও অগ্রগতি ট্র্যাক করা
পাঠ ০১ থেকে আমরা জানি — context window-এর একটা নির্দিষ্ট সীমা আছে। একটা দীর্ঘ-মেয়াদী টাস্কে এজেন্ট প্রায়ই এই সীমার কাছে পৌঁছে যায়, বা এমনকি একাধিক আলাদা কথোপকথন/সেশনে (একাধিক আলাদা context window জুড়ে) কাজ চালিয়ে যেতে হয় — যেমন একটা সেশন শেষ হয়ে যায়, কিন্তু কাজ অসম্পূর্ণ থাকে, আর পরের সেশনে আবার শুরু করতে হয়। এই পরিস্থিতিতে এজেন্টের নিজের অগ্রগতি মনে রাখার কোনো স্বাভাবিক উপায় নেই — যদি না প্রম্পট বা ওয়ার্কফ্লো তাকে স্পষ্টভাবে তা করতে বলে।
এই সমস্যার তিনটি ব্যবহারিক সমাধান আছে, এবং এগুলো একে অপরের বিকল্প নয় — বরং একসাথে ব্যবহার করা যায়।
যে কাজগুলো সম্পন্ন হয়েছে, যেগুলো বাকি আছে, এবং প্রতিটির অবস্থা — এসব একটা JSON ফাইলে রেকর্ড রাখা। এজেন্টকে নির্দেশ দেওয়া যায় প্রতিটি বড় ধাপ শেষে এই ফাইল আপডেট করতে, এবং নতুন সেশন শুরুর আগে প্রথমে এই ফাইল পড়তে — এতে টেস্ট-কেস বা সাব-টাস্কের অবস্থা (pass/fail/pending) মেশিন-পাঠযোগ্য ফরম্যাটে থাকে।
একটা সাধারণ টেক্সট ফাইলে মুক্ত-ফর্মে অগ্রগতির নোট রাখা — কী করা হলো, কেন একটা নির্দিষ্ট সিদ্ধান্ত নেওয়া হলো, কোথায় আটকে গিয়েছিল। এটা JSON-এর মতো কঠোরভাবে গঠিত নয়, কিন্তু এমন সূক্ষ্ম প্রেক্ষাপট ধরে রাখতে পারে যা একটা কঠোর স্কিমায় ফিট হয় না — যেমন "কেন" এই পথটা বেছে নেওয়া হলো, অন্য পথটা নয়।
কোডিং টাস্কে, প্রতিটা স্থিতিশীল মাইলফলকে একটা কমিট তৈরি করা নিজেই একটা অগ্রগতি-ট্র্যাকিং ব্যবস্থা — কমিট হিস্ট্রি নিজেই বলে দেয় এখন পর্যন্ত কী কী সম্পন্ন হয়েছে, এবং কোনো ধাপ ভুল হয়ে গেলে নির্দিষ্ট একটা পূর্ববর্তী অবস্থায় ফিরে যাওয়া সহজ হয়।
progress.json-এ কোন টেস্ট পাস করেছে তা রাখে (স্ট্রাকচার্ড স্টেট), আর একটা
notes.md-এ কেন একটা নির্দিষ্ট আর্কিটেকচার সিদ্ধান্ত নেওয়া হলো তা লেখে (আনস্ট্রাকচার্ড নোট)। সিস্টেম
প্রম্পটে এই তিনটা ফাইল আপডেট করার নির্দেশনা স্পষ্টভাবে থাকা উচিত — "প্রতিটি ধাপ শেষে অগ্রগতি স্পষ্টভাবে রেকর্ড
করুন" বলাটাই যথেষ্ট নয়, ঠিক কোথায় ও কীভাবে রেকর্ড করতে হবে তা বলা দরকার।
৩ · Autonomy ও Safety-র মধ্যে ভারসাম্য
যত বেশি স্বায়ত্তশাসন একটা এজেন্টকে দেওয়া হয়, তত বেশি ঝুঁকি থাকে যে সে এমন একটা পদক্ষেপ নেবে যা সহজে ফেরানো যায় না। নির্দেশনা ছাড়া, একটা এজেন্ট নিজের বিচারে এমন পদক্ষেপও নিতে পারে যা মানুষ কখনো বিনা অনুমতিতে নিত না — কারণ তার কাছে "এই পদক্ষেপটা বিশেষভাবে ঝুঁকিপূর্ণ" এই বোঝাপড়া স্বতঃস্ফূর্তভাবে থাকে না, যদি না প্রম্পটে সেটা স্পষ্ট করা হয়।
rm -rf চালানো, git push --force,
git reset --hard, ইতিমধ্যে পাবলিশ করা কমিট amend করা, কোড পুশ করা, PR-এ মন্তব্য করা, বার্তা পাঠানো,
অথবা শেয়ার্ড ইনফ্রাস্ট্রাকচার পরিবর্তন করা।
লক্ষ্য করুন — এই তালিকার প্রতিটা আইটেমের একটা সাধারণ বৈশিষ্ট্য আছে — এগুলো এমন পদক্ষেপ যা একবার সম্পন্ন হয়ে গেলে ফিরিয়ে আনা কঠিন বা অসম্ভব, অথবা এমন সিস্টেমকে প্রভাবিত করে যা শুধু একজন ব্যবহারকারীর নিয়ন্ত্রণে নেই (যেমন একটা শেয়ার্ড রিপোজিটরি বা প্রোডাকশন ডেটাবেস)। এই দুটো বৈশিষ্ট্য — reversibility (ফেরানো যায় কি না) আর impact (কতজনকে বা কতটা প্রভাবিত করে) — মিলেই ঠিক করে একটা পদক্ষেপ কতটা সতর্কতা দাবি করে।
Consider the reversibility and potential impact of your actions before
taking them. For actions that are hard to reverse, affect shared
systems, or could be destructive — such as deleting files or branches,
dropping database tables, running rm -rf, force-pushing, resetting
history with git reset --hard, amending already-published commits,
pushing code, commenting on a pull request, sending messages, or
modifying shared infrastructure — stop and ask the user for
confirmation before proceeding, describing exactly what you intend
to do and why.এই প্যাটার্নের গঠনটা লক্ষ্য করুন — এটা প্রতিটা সম্ভাব্য বিপজ্জনক কাজের একটা নির্দিষ্ট তালিকা দেয়নি বলে ক্ষান্ত হয়নি, বরং একটা নীতি দিয়েছে (reversibility ও impact বিবেচনা করা) এবং তারপর সেই নীতির বাস্তব উদাহরণ দিয়েছে। এতে এজেন্ট এমন পরিস্থিতিতেও সঠিক সিদ্ধান্ত নিতে পারে যা তালিকায় সরাসরি উল্লেখ নেই, কারণ সে নীতিটা বুঝেছে, শুধু একটা তালিকা মুখস্থ করেনি।
দীর্ঘ-মেয়াদী এজেন্ট প্রম্পটিং মানে শুধু "কী করতে হবে" বলা নয় — এর সাথে যোগ হয় "কীভাবে অগ্রগতি মনে রাখতে হবে" এবং "কখন থেমে অনুমতি চাইতে হবে"। যত বেশি একটা এজেন্ট স্বাধীনভাবে কাজ করে, তত বেশি গুরুত্বপূর্ণ হয়ে ওঠে এই দুটো প্রশ্নের স্পষ্ট, প্রম্পটে-লিখিত উত্তর — কারণ মডেল নিজে থেকে এই সীমারেখা অনুমান করতে পারে না।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটা কোডিং এজেন্ট একটা বড় রিফ্যাক্টর টাস্কের মাঝপথে সেশন হারিয়ে ফেলল, এবং নতুন সেশনে আবার শুরু থেকে কাজ শুরু করল, আগের অগ্রগতি সম্পূর্ণ উপেক্ষা করে। এটা কেন হলো, এবং কীভাবে প্রতিরোধ করা যেত?
সম্ভবত আগের সেশনে কোনো স্ট্রাকচার্ড বা আনস্ট্রাকচার্ড অগ্রগতি-রেকর্ড রাখা হয়নি, অথবা নতুন সেশন শুরু হওয়ার সময় এজেন্টকে সেই রেকর্ড প্রথমে পড়ার নির্দেশ দেওয়া হয়নি। এজেন্টের কাছে আগের সেশনের কোনো স্মৃতি স্বতঃস্ফূর্তভাবে থাকে না — যদি সেটা ফাইলে লেখা না থাকে এবং স্পষ্টভাবে পড়তে না বলা হয়, তাহলে সে ধরে নেবে কাজ শুরু থেকেই করতে হবে।
প্রতিরোধ — সিস্টেম প্রম্পটে নির্দেশ দিন প্রতিটি সেশনের শুরুতে প্রথমে progress.json বা অনুরূপ
স্টেট ফাইল পড়তে, এবং প্রতিটি বড় ধাপ শেষে সেটা আপডেট করতে। git কমিট হিস্ট্রিও একটা বাড়তি চেকপয়েন্ট হিসেবে
কাজ করত।
প্র ০২ একটা এজেন্টকে বলা হয়েছিল "ডেটাবেস অপ্টিমাইজ করো", আর সে নিজের বিচারে একটা পুরনো টেবিল drop করে ফেলল কারণ মনে হয়েছিল এটা অপ্রয়োজনীয়। এই ঘটনায় কোন নীতি লঙ্ঘিত হয়েছে?
এখানে reversibility ও impact বিবেচনা করা হয়নি — একটা টেবিল drop করা একটা হার্ড-টু-রিভার্স, সম্ভাব্য ধ্বংসাত্মক পদক্ষেপ, এবং এটা এমন একটা সিস্টেমকে প্রভাবিত করে যা একা এজেন্টের সিদ্ধান্তে ছেড়ে দেওয়া উচিত নয়। "অপ্টিমাইজ করো" নির্দেশটা এই ধরনের ধ্বংসাত্মক পদক্ষেপের জন্য স্পষ্ট অনুমতি ছিল না।
সমাধান — সিস্টেম প্রম্পটে একটা নিরাপত্তা-প্যাটার্ন থাকা উচিত ছিল যা এজেন্টকে টেবিল drop করার মতো পদক্ষেপের আগে থামতে এবং ব্যবহারকারীর কাছে নিশ্চিতকরণ চাইতে বলে, ঠিক কী করতে চলেছে এবং কেন তা ব্যাখ্যা করে।
প্র ০৩ একটা এজেন্ট প্রতিটা ছোট পদক্ষেপের আগেই থেমে অনুমতি চাইছে — এমনকি একটা ভ্যারিয়েবলের নাম বদলানোর মতো নিরীহ কাজেও। এটা কীভাবে আগের পাঠের (টুল ইউজ প্রম্পটিং) সাথে সম্পর্কিত, এবং কীভাবে ঠিক করবেন?
এটা অতিরিক্ত রক্ষণশীল আচরণ — সম্ভবত সিস্টেম প্রম্পটে নিরাপত্তা-নির্দেশনা এত ব্যাপকভাবে লেখা হয়েছে যে এজেন্ট সব পদক্ষেপকেই "ঝুঁকিপূর্ণ" হিসেবে গণ্য করছে, এমনকি সহজে ফেরানো যায় এমন ছোট পরিবর্তনও।
সমাধান — আগের পাঠে আলোচিত <default_to_action> ব্লকের সাথে এই নিরাপত্তা-প্যাটার্ন একসাথে
ব্যবহার করুন, স্পষ্ট করে বলুন যে শুধু হার্ড-টু-রিভার্স বা ধ্বংসাত্মক পদক্ষেপের আগেই থামতে হবে — সাধারণ,
সহজে-ফেরানো-যায় এমন পদক্ষেপে (যেমন ভ্যারিয়েবলের নাম বদলানো) সরাসরি এগিয়ে যাওয়া উচিত।
অনুশীলন
-
ডিজাইন করুন: একটা এজেন্ট যাকে তিন দিন ধরে একটা বড় ডেটা-মাইগ্রেশন প্রকল্পে কাজ করতে হবে, একাধিক
আলাদা সেশনে। এই এজেন্টের জন্য একটা অগ্রগতি-ট্র্যাকিং কৌশল প্রস্তাব করুন যাতে তিনটা পদ্ধতিই ব্যবহৃত হয়।
একটা সম্ভাব্য কৌশল —
migration_state.json-এ কোন টেবিল/রেকর্ড মাইগ্রেট হয়েছে তার স্ট্রাকচার্ড তালিকা রাখা;migration_notes.md-এ কোন এজ-কেস বা অপ্রত্যাশিত সমস্যা পাওয়া গেছে তার আনস্ট্রাকচার্ড বর্ণনা রাখা; এবং প্রতিটা সফল ব্যাচ মাইগ্রেশনের পর একটা git কমিট (যদি কোড/স্ক্রিপ্ট ভার্সন-নিয়ন্ত্রিত হয়) বা অনুরূপ চেকপয়েন্ট তৈরি করা, যাতে যেকোনো ধাপে সমস্যা দেখা দিলে নির্দিষ্ট একটা অবস্থায় ফিরে যাওয়া যায়। -
শনাক্ত করুন: নিচের কাজগুলোর মধ্যে কোনগুলো এই পাঠে আলোচিত "হার্ড-টু-রিভার্স" তালিকায় পড়ে —
(ক) একটা টেস্ট ফাইল লেখা, (খ) production ব্রাঞ্চে force-push করা, (গ) একটা লোকাল ভ্যারিয়েবলের মান প্রিন্ট করা,
(ঘ) একজন গ্রাহককে সরাসরি ইমেইল পাঠানো।
(খ) force-push এবং (ঘ) গ্রাহককে ইমেইল পাঠানো — দুটোই এই পাঠের তালিকায় স্পষ্টভাবে উল্লেখিত (force-push, এবং বার্তা/মেসেজ পাঠানো)। (ক) ও (গ) সাধারণত নিরাপদ, সহজে-ফেরানো-যায় এমন পদক্ষেপ — এগুলোর জন্য অনুমতি চাওয়া অপ্রয়োজনীয় বাধা তৈরি করবে।
-
রিরাইট করুন: "Be careful with dangerous actions" — এই দুর্বল, অস্পষ্ট নিরাপত্তা-নির্দেশনাটাকে এই
পাঠের প্যাটার্ন অনুসরণ করে একটা স্পষ্ট, কার্যকর নির্দেশনায় রূপান্তর করুন।
মূল সমস্যা — "dangerous" শব্দটা সংজ্ঞায়িত করা হয়নি, তাই এজেন্ট নিজের মতো ব্যাখ্যা করবে। রিরাইট এই পাঠের টেমপ্লেট অনুসরণ করবে — reversibility ও impact বিবেচনা করতে বলা, তারপর নির্দিষ্ট উদাহরণের তালিকা (ফাইল/ব্রাঞ্চ ডিলিট, DB টেবিল drop, rm -rf, force-push, git reset --hard, published কমিট amend, কোড পুশ, PR মন্তব্য, বার্তা পাঠানো, শেয়ার্ড ইনফ্রাস্ট্রাকচার পরিবর্তন) দেওয়া, এবং এসবের আগে ব্যবহারকারীর নিশ্চিতকরণ চাওয়ার স্পষ্ট নির্দেশ দেওয়া।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ — প্রম্পট ইঞ্জিনিয়ারিং বনাম কনটেক্সট ইঞ্জিনিয়ারিং পাঠ ২৩ ২০২৬ সালের একটা গুরুত্বপূর্ণ ধারণা — কোথায় প্রম্পট শেষ হয় আর সিস্টেম-ডিজাইন শুরু হয়।
- সব AI Courses দেখুন ABCL TECH AI Foundations, Python for AI, Machine Learning, Deep Learning, NLP ও LLM, Prompt Engineering — সব এক জায়গায়।
- AI সংবাদ ও সাম্প্রতিক ঘটনাবলি Blog ABCL TECH-এর বাংলা AI সংবাদ — Claude, GPT, Gemini-এর নতুন মডেল ও আপডেট নিয়ে।