ব্রাউজার র‍্যাপার থেকে সীমাবদ্ধ কম্পিউটার ব্যবহার

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

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

• Anthropic ও OpenAI-এর সাম্প্রতিক সিস্টেমগুলো এমন এজেন্ট দেখিয়েছে, যারা শুধু কাজ করে না; স্টেট নিয়ে যুক্তি করে, ত্রুটি থেকে ঘুরে দাঁড়ায় এবং তাৎক্ষণিকভাবে কাজ-নির্দিষ্ট সমাধান তৈরি করে. এতে ব্রাউজার এজেন্টদের জন্য সাধারণ নির্বাহ পরিবেশে পরিণত হয়, কিন্তু সঙ্গে সঙ্গে একটি নকশাগত প্রশ্ন ওঠে: সেই পরিবেশের কতটা আমরা মডেলের সামনে উন্মুক্ত করব?

• প্রাথমিক সিস্টেমগুলো ব্রাউজারকে নিরাপদ, পূর্বনির্ধারিত অ্যাকশনের একটি স্থির সেটে মুড়ে দিয়ে এর উত্তর দিয়েছিল. এই পোস্টে আমরা দেখাব, সেই পদ্ধতি এখন তার সীমায় পৌঁছে যাচ্ছে.

ব্রাউজার এজেন্ট বানানোর সময় একটি পরিচিত প্রবণতা দেখা যায়: মডেলকে খুব বেশি বিশ্বাস করো না.

তাই আমরা ব্রাউজারকে র‍্যাপ করি. আমরা click, type, scroll, select এবং read_text-এর মতো পূর্বনির্ধারিত টুল উন্মুক্ত করি. আমরা Document Object Model (DOM) সরল করি. আমরা অ্যাকশন স্পেস কমিয়ে আনি. আমাদের নকশা করা বিমূর্ততার মাধ্যমে আচরণকে বোধ্য ও নিয়ন্ত্রণযোগ্য করার চেষ্টা করি.

এটি যুক্তিসঙ্গত সূচনা. তবে ক্রমশ এটি দীর্ঘমেয়াদে ভুল স্থাপত্য হয়ে উঠছে.

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

এই সমঝোতা এখন কম আকর্ষণীয় হয়ে উঠছে.

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

মডেলগুলো সত্যিই খুব ভালো হয়ে গেছে, এবং তাদের আর আপনার বিমূর্ত গার্ডরেলের দরকার নেই—লক্ষ্য অর্জন না হওয়া পর্যন্ত কাজের নকশা, নির্বাহ ও পুনরাবৃত্তির জন্য তাদের সম্পূর্ণ অ্যাকশন স্পেস দরকার.

এই পোস্ট সেই পরিবর্তন নিয়ে—বিমূর্ততা-নির্ভর ব্রাউজার অটোমেশন থেকে সীমাবদ্ধ কম্পিউটার ব্যবহারে যাওয়া, এবং এভাবে সিস্টেম নকশা করলে কী বদলে যায়.

সমস্যা এই নয় যে স্থির অ্যাকশন ইন্টারফেস ধারণাগতভাবে ভুল. সমস্যা হলো ওয়েব তাদের সঙ্গে সহযোগিতা করে না.

আধুনিক ইন্টারফেস React, Vue ও Angular দিয়ে তৈরি; এতে থাকে অ্যাসিঙ্ক্রোনাস স্টেট আপডেট, সিনথেটিক ইভেন্ট সিস্টেম এবং নিজস্ব লাইফসাইকেলসহ ক্রস-অরিজিন iframe-এ থাকা এমবেডেড থার্ড-পার্টি উইজেট. “এই ইনপুটে টাইপ করো” বলা কোনো র‍্যাপার তখনই ঠিক, যখন পেজ আপনার টাইপ করার সংজ্ঞার সঙ্গে একমত হয়. অনেক পেজ একমত হয় না. সরাসরি মান বসালে প্রায়ই ফ্রেমওয়ার্কের পরিবর্তন শনাক্তকরণ সম্পূর্ণ এড়িয়ে যায়. ইনপুটটি পূরণ হয়েছে বলে দেখায়. ভ্যালিডেশন চালুই হয় না. ফর্মটি ভাঙাই থেকে যায়.

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

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

Stripe বা Adyen-এর মাধ্যমে ক্রস-অরিজিন iframe-এর ভেতরে এমবেড করা একটি পেমেন্ট ফর্ম ভাবুন. আপনার র‍্যাপার সরাসরি সেখানে পৌঁছাতে পারে না, কারণ সেটি একটি আলাদা অরিজিনে থাকে. আপনার read_text টুল তার অভ্যন্তরীণ স্টেট দেখতে পারে না. আপনার type টুল তার ইনপুটগুলোকে লক্ষ্য করতে পারে না. র‍্যাপার-ভিত্তিক এজেন্ট এখানে দেয়ালে ঠেকে যায়. বিমূর্ততাটি মূল ডকুমেন্টের জন্য নকশা করা হয়েছিল. আসল কাজটি থাকে এমন জায়গায়, যা বিমূর্ততা দেখতে পারে না.

কম স্পষ্ট ফ্লোগুলোতেও একই ধরনের অমিল দেখা যায়. ফ্রেমওয়ার্ক-নিয়ন্ত্রিত কোনো ড্রপডাউন সরাসরি ক্লিকে একেবারেই সাড়া নাও দিতে পারে, কারণ দৃশ্যমান উপাদানটি প্রকৃত নিয়ন্ত্রণ নয়. অন্তর্নিহিত স্টেট পরিবর্তন ঘটাতে এর জন্য কিবোর্ড ইভেন্টের একটি ধারাবাহিকতা দরকার হতে পারে. বাইরে থেকে UI-টি ক্লিকযোগ্য দেখায়. বিমূর্ততা বলে “ক্লিক”. কিছুই ঘটে না.

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

প্রতিটি ক্ষেত্রেই বিমূর্ততা সেই সংকেতগুলো লুকিয়ে ফেলে, যেগুলো এজেন্টের আসলে দরকার.

নিম্ন স্তরে কাজ করা একটি মডেল—লাইভ DOM পরিদর্শন করা, ফ্রেমের সীমানা নিয়ে যুক্তি করা, নির্দিষ্ট ওই পৃষ্ঠের জন্য ইন্টারঅ্যাকশন ধারাবাহিকতা তৈরি করা—এসব পরিস্থিতি সামলাতে পারে. ব্যাপারটি এমন নয় যে মডেল স্বভাবগতভাবে আরও বুদ্ধিমান. ব্যাপারটি হলো তার কাছে সেই তথ্য আছে, যা সরিয়ে ফেলা হয়েছিল.

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

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

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

ব্রাউজার অটোমেশনের ক্ষেত্রে বাস্তবে এর মানে হলো, সবকিছুকে পূর্বনির্মিত অ্যাকশনের স্থির সেটে মানচিত্রায়িত করার বদলে মডেল সরাসরি লাইভ পেজ স্টেট পরিদর্শন করতে, ফ্রেম অতিক্রম করতে এবং বর্তমান ইন্টারফেসের জন্য নির্দিষ্ট কাস্টম ইন্টারঅ্যাকশন কোড তৈরি করতে পারে.

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

গুরুত্বপূর্ণ হলো, বিমূর্ততার স্তর সরিয়ে দিলেই সিস্টেম কম শৃঙ্খলাপূর্ণ হয় না. এটি শৃঙ্খলার অবস্থান বদলে দেয়.

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

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

এতে সিস্টেম কীভাবে সাধারণীকরণ করে, সেটিও বদলে যায়. র‍্যাপার-ভিত্তিক এজেন্ট আপনার ইতিমধ্যে তৈরি র‍্যাপারগুলোর মতো কাজের ক্ষেত্রে ভালোভাবে সাধারণীকরণ করে. সীমাবদ্ধ রানটাইম এজেন্ট এমন কাজেও সাধারণীকরণ করে যেগুলোর নির্বাহ-ভিত্তি একই, দৃশ্যমান ইন্টারফেস ভিন্ন হলেও.

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

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

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

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

নকশার সময় চারটি বিষয় বিবেচনা করতে হয়:

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

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

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

স্বায়ত্তশাসনের বর্ণালি. সব অ্যাকশন পুরোপুরি স্বয়ংক্রিয় হওয়া উচিত নয়. অনেক প্রোডাকশন পরিবেশে স্বায়ত্তশাসনকে একটি বর্ণালি হিসেবে দেখা জরুরি. সিস্টেম অনুসন্ধান ও নির্বাহের পদ্ধতিতে অত্যন্ত এজেন্টিক হতে পারে, কিন্তু নির্দিষ্ট কিছু শ্রেণির অ্যাকশনের জন্য তবু অনুমোদন চাইতে পারে.

মূল নীতি সহজ: মডেলকে বেশি ক্ষমতা দিলে তাকে ঘিরে থাকা সিস্টেমকেও আরও শক্তিশালী করতে হয়. নীতিহীন স্বায়ত্তশাসন প্রোডাকশনের জন্য প্রস্তুত নয়.

আমরা আর জিজ্ঞেস করিনি: কোন ব্রাউজার অ্যাকশনগুলো উন্মুক্ত করা ঠিক?

আমরা জিজ্ঞেস করতে শুরু করলাম: মডেলকে সম্পূর্ণ অ্যাকশন স্পেস দিতে আমরা কী করতে পারি—এবং সেটিকে নিরাপদ রাখার মতো রানটাইম নীতি কীভাবে তৈরি করব?

এই পুনর্গঠন আপনি কী নিয়ে ভাববেন, তা বদলে দেয়. অ্যাকশন শ্রেণিবিন্যাস ও র‍্যাপারের পূর্ণতা কম গুরুত্বপূর্ণ হয়ে যায়. রানটাইম নীতি, অবজারভেবিলিটি ও ধাপ-স্তরের মূল্যায়ন বেশি গুরুত্বপূর্ণ হয়ে ওঠে. মডেলের সক্ষমতা ও সিস্টেম নকশা একে অন্যের বিকল্প নয়. মডেল উন্নত হলে সিস্টেমের কাজ কম নয়, বরং আরও গুরুত্বপূর্ণ হয়.

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

র‍্যাপার নকশা কম. সিস্টেম ইঞ্জিনিয়ারিং বেশি.

আর আমরা ব্রাউজার এজেন্টে মনোযোগ দিলেও, এটি কম্পিউটার ব্যবহারকে সিস্টেম শৃঙ্খলা হিসেবে ভাবার আরও বিস্তৃত পথে ইঙ্গিত করে.