প্রতিটি এজেন্ট সিস্টেম একই অস্বস্তিকর আপসের (trade-off) সম্মুখীন হয়। আপনি এমন একটি গভীর এবং সুসংগঠিত নলেজ বেস চান যা কোড রিভিউ এবং গিট হিস্ট্রিতে টিকে থাকবে। কিন্তু আপনার রানটাইমকেও দ্রুত এবং ফোকাসড রাখা প্রয়োজন। এই দুটি প্রয়োজন একে অপরের পরিপন্থী। আপনি যত বেশি ইনস্ট্রাকশন সংরক্ষণ করবেন, সেগুলোকে প্রম্পটে ঢেলে দিয়ে সেরাটা আশা করার প্রলোভন তত বেশি বাড়বে। আর সেই আশা করাটা বেশ ব্যয়বহুল।
Agent Project Context ইকোসিস্টেমে, এই উত্তেজনা দুটি স্তরে স্পষ্টভাবে বিভক্ত। APC স্থায়িত্ব (durability) সামলায়। APX গতি (speed) সামলায়। তারা কীভাবে একে অপরের সাথে কাজ করে—এবং কেন APX প্রতিটি স্কিল ডেফিনিশন প্রি-লোড করতে অস্বীকার করে—তা বুঝতে পারলে প্রম্পট ইঞ্জিনিয়ারিং সম্পর্কে বেশিরভাগ অপ্টিমাইজেশন গাইডের চেয়েও বেশি কিছু জানা সম্ভব।
আর্কাইভ এবং ইঞ্জিন
APC-এর কাজ হলো স্থায়িত্ব নিশ্চিত করা। এটি .apc/skills/ এর অধীনে পুনরায় ব্যবহারযোগ্য স্কিল ফাইলগুলোকে সাধারণ মার্কডাউন ডকুমেন্ট হিসেবে সংরক্ষণ করে। যেহেতু এই ফাইলগুলো আপনার রিপোজিটরির ভেতরে থাকে, তাই এগুলো ভার্সন কন্ট্রোলের সাথে সাথে চলে। আপনি একটি ডিপ্লয়মেন্ট প্রসিডিউর পরিবর্তন করে পুল রিকোয়েস্ট পাঠাতে পারেন। আপনি ছয় সপ্তাহ আগের একটি সিকিউরিটি পলিসি রোলব্যাকের ডিফ (diff) দেখতে পারেন। এজেন্ট ঠিক কী কী জানত এবং কখন জানত, তা আপনি অডিট করতে পারেন। যখন কোনো ভুল ডিপ্লয়মেন্ট লাইভ হয়ে যায় বা কোনো কমপ্লায়েন্স অডিটর প্রশ্ন করতে শুরু করেন, তখন এই রিভিউ করার ক্ষমতা অত্যন্ত গুরুত্বপূর্ণ।
অন্যদিকে, APX বর্তমান মুহূর্তের ওপর ভিত্তি করে কাজ করে। এটি আপনার এবং মডেলের মধ্যে প্রকৃত কথোপকথন পরিচালনা করে। এর লক্ষ্য জ্ঞান সংরক্ষণ করা নয়, বরং তা সঠিকভাবে ব্যবহার করা। যখন APX স্কিলগুলোকে স্থায়ী বোঝা (baggage) হিসেবে বিবেচনা করে, তখন পুরো সিস্টেম ধীর হয়ে যায়। কনটেক্সট উইন্ডো পূর্ণ হয়ে যায়। টোকেন খরচ বেড়ে যায়। আরও খারাপ বিষয় হলো, মডেলের মনোযোগ এমন সব ইনস্ট্রাকশনের দিকে বিক্ষিপ্ত হয়ে যায় যেগুলোর সাথে বর্তমান রিকোয়েস্টের কোনো সম্পর্ক নেই।
এই কারণেই স্কিল বডিগুলো অন-ডিমান্ড (প্রয়োজন অনুযায়ী) লোড হয়।
একটি অতিরিক্ত বড় (bloated) প্রম্পটের প্রকৃত খরচ
বেশিরভাগ টিম বোঝে যে টোকেনের জন্য টাকা খরচ হয়। কিন্তু খুব কম টিমই উপলব্ধি করে যে অপ্রাসঙ্গিক টোকেন নির্ভুলতা (accuracy) কমিয়ে দেয়।
যখন APX প্রতিটি টার্নে উপলব্ধ সমস্ত স্কিল ইনজেক্ট করে, তখন প্রম্পটটি নয়েজ বা কোলাহলপূর্ণ হয়ে ওঠে। মডেলটি ডিপ্লয়মেন্ট রানবুক, সিকিউরিটি গাইড, API স্টাইল রেফারেন্স, টেস্টিং চেকলিস্ট এবং অনবোর্ডিং FAQ—সবকিছু একসাথে পায়। এমনকি একটি বড় কনটেক্সট উইন্ডো থাকলেও, মডেলকে যখন সিগন্যাল খোঁজার জন্য প্রথমে নয়েজ বা অপ্রাসঙ্গিক তথ্য থেকে বাছাই করতে হয়, তখন তার রিজনিং বা যুক্তিনির্ভরতার মান কমে যায়। লোকাল টেস্ট সেটআপ সম্পর্কে কোনো প্রশ্নের উত্তর দেওয়ার সময় এটি হয়তো প্রোডাকশন ডিপ্লয়মেন্টের জন্য নির্ধারিত কোনো সিকিউরিটি রিকোয়ারমেন্টের দিকে মনোযোগ দিয়ে ফেলে। এটি হয়তো একটি সাধারণ বাগ ফিক্স করার সময় রিলিজ চেকলিস্ট থেকে কোনো ধাপ হ্যালুসিনেশন হিসেবে যোগ করে দিতে পারে। অপ্রাসঙ্গিক টেক্সটের প্রতিটি অতিরিক্ত প্যারাগ্রাফ হলো একটি সম্ভাব্য বিভ্রান্তি।
এর গণিত খুবই সহজ। বেশিরভাগ টার্নে বেশিরভাগ স্কিলের প্রয়োজন হয় না। আপনি যদি কোনো এরর লগের দ্রুত সমাধানের জন্য জিজ্ঞাসা করেন, তবে আপনার একটি পূর্ণাঙ্গ ডিপ্লয়মেন্ট রানবুক বা সিকিউরিটি হার্ডেনিং গাইডের প্রয়োজন নেই। আপনার প্রয়োজন মডেলটি যেন এররটি দেখতে পায়, আপনার প্রজেক্ট কনভেনশন বুঝতে পারে এবং সঠিক ফাইলটি এডিট করতে পারে। অপ্রাসঙ্গিক স্কিল বডি লোড করা মডেলকে এই কাজে সাহায্য করে না। এটি মডেলকে আপনার আসল সমস্যা নিয়ে কাজ শুরু করার আগেই অপ্রয়োজনীয় ডেটা ফিল্টার করতে বাধ্য করে।
অন-ডিমান্ড লোডিং কীভাবে কাজ করে
এই প্রক্রিয়াটি সহজ কিন্তু সুপরিকল্পিত। APC গ্রাউন্ড ট্রুথ (ground truth) ধরে রাখতে থাকে। আপনার স্কিল ডেফিনিশনগুলো যেখানে থাকার কথা সেখানেই থাকে: .apc/skills/<name>.md-এ।
APX সেই ফাইলগুলোকে অ্যাক্টিভ মেমরিতে মিরর করে না। পরিবর্তে, এটি স্কিল নামগুলোর একটি কম্প্যাক্ট রেজিস্ট্রি তৈরি করে। মডেল এই তালিকাটি দেখতে পায় এবং বুঝতে পারে যে একটি ক্যাটালগ বা তালিকা বিদ্যমান। যদি এর কোনো সক্ষমতা ব্রাউজ বা নিশ্চিত করার প্রয়োজন হয়, তবে এটি একটি list_skills কল করতে পারে। এটি মডেলকে অতিরিক্ত ডেটা ছাড়াই দৃশ্যমানতা প্রদান করে।
যখন কোনো কাজের জন্য স্কিল ফাইলে এনকোড করা সঠিক সিনট্যাক্স, বিস্তারিত ধাপ বা নির্দিষ্ট সীমাবদ্ধতার প্রয়োজন হয়, তখন মডেল load_skill কল করে। ঠিক সেই মুহূর্তে, এবং শুধুমাত্র সেই মুহূর্তেই, APX থেকে APC থেকে সম্পূর্ণ মার্কডাউন বডিটি নিয়ে আসে এবং কনটেক্সটে ইনজেক্ট করে। ইনস্ট্রাকশনটি তাৎক্ষণিকভাবে আসে, তার উদ্দিষ্ট উদ্দেশ্যে একবার ব্যবহৃত হয় এবং সিস্টেম এটিকে বাড়তি বোঝা হিসেবে বহন করা এড়িয়ে চলে।
একটি লাইব্রেরি ইম্পোর্ট করার সাথে আপনার মেইন ফাইলে প্রতিটি ফাংশন ডেফিনিশন পেস্ট করার পার্থক্যের কথা চিন্তা করুন। একটি পদ্ধতি আপনার কোডবেসকে নেভিগেটযোগ্য রাখে। অন্য পদ্ধতিটি এমন একটি বিশৃঙ্খলা তৈরি করে যা কেবল আকস্মিকভাবেই কম্পাইল হয়।
যখন স্কিলগুলোর মধ্যে সংঘর্ষ ঘটে তখন কে জয়ী হয়
APX যখন স্কিল লোড করে, তখন এটি একটি স্পষ্ট অগ্রাধিকারের ক্রম (priority order) প্রয়োগ করে। প্রতিটি এনভায়রনমেন্ট এক নয়, এবং সাধারণ পরামর্শ কখনোই লোকাল নলেজকে ছাপিয়ে যাওয়া উচিত নয়।
প্রজেক্ট স্কিলগুলো (Project skills) সর্বোচ্চ অগ্রাধিকার পায়। এই ফাইলগুলো আপনার বর্তমান রিপোজিটরির .apc/skills/ ডিরেক্টরিতে থাকে। এগুলো আপনার টিমের নির্দিষ্ট নিয়মাবলী (conventions), আপনার কাস্টম র্যাপার (custom wrappers), আপনার লিগ্যাসি নামকরণের মানদণ্ড এবং আপনার বিশেষ টুলচেইনকে ধারণ করে। যদি আপনার প্রজেক্ট ডাটাবেস মাইগ্রেশন হ্যান্ডেল করার নিজস্ব কোনো পদ্ধতি নির্ধারণ করে থাকে, তবে সেই পদ্ধতিই কার্যকর হবে।
এরপর আসে গ্লোবাল স্কিল (Global skills)। এগুলো সংস্থা-ব্যাপী প্যাটার্নগুলোকে কভার করে, যা প্রজেক্ট নিজে কোনো নির্দেশনা না দিলে কার্যকর হয়। এগুলো একটি স্ট্যান্ডার্ড লাইব্রেরি হিসেবে কাজ করে।
বিল্ট-ইন রানটাইম স্কিলগুলো (Built-in runtime skills) সবার নিচে ফলব্যাক (fallback) হিসেবে থাকে। এগুলো সেই সাধারণ সক্ষমতাগুলো পরিচালনা করে যা প্রতিটি এজেন্টের বোঝা উচিত, কিন্তু কোনো নির্দিষ্ট প্রজেক্ট সেগুলো পুনরায় সংজ্ঞায়িত করার প্রয়োজন বোধ করেনি।
এই স্তরভিত্তিক পদ্ধতিটির মানে হলো আপনার রিপোজিটরি তার নিজস্ব আচরণের ওপর নিয়ন্ত্রণ বজায় রাখে। কোনো গ্লোবাল বা বিল্ট-ইন স্কিল ভুলবশত এমন কোনো ওয়ার্কফ্লো হাইজ্যাক করতে পারে না যা আপনার টিম উদ্দেশ্যপ্রণোদিতভাবে কাস্টমাইজ করেছে।
বাস্তবে এটি দেখতে কেমন
একটি সাধারণ রক্ষণাবেক্ষণ কাজের (maintenance task) কথা কল্পনা করুন। একজন সহকর্মী চ্যাটে একটি এরর লগ (error log) পেস্ট করলেন। ট্রেসব্যাক (traceback) একটি ইউটিলিটি মডিউলে একটি সিঙ্গেল নাল রেফারেন্সের (null reference) দিকে নির্দেশ করছে। এর সমাধান সম্ভবত ডিফেন্সিভ কোডিংয়ের মাত্র দুটি লাইন।
অন-ডিমান্ড লোডিং (on-demand loading) ছাড়া কোনো সিস্টেমে, APX তার জানা প্রতিটি স্কিল দিয়ে কনটেক্সটটি পূর্ণ করে ফেলবে। সেই দুটি লাইন দেখার আগে মডেলটিকে এখন চল্লিশ পৃষ্ঠার টেক্সট বিবেচনা করতে হবে। এটি রিলিজ চেকলিস্ট দেখে ভাবছে ভার্সন বাড়ানো উচিত কি না। এটি সিকিউরিটি গাইড দেখে এমন একটি ফাংশনে ইনপুট ভ্যালিডেশনের কথা ভাবছে যার শুধু একটি নাল চেক প্রয়োজন। এটি ডিপ্লয়মেন্ট রানবুক দেখে স্টেজিং এনভায়রনমেন্ট নিয়ে ভাবতে শুরু করে। মডেলটি লক্ষ্যভ্রষ্ট হয়। রেসপন্স পেতে দেরি হয়। টোকেন মিটার দ্রুত ঘুরতে থাকে।
APX-এর অন-ডিমান্ড ডিজাইনের কারণে, মডেলটি শুধুমাত্র নামগুলো দেখতে পায়। এটি জানে যে [release-checklist], [security-guide], [deployment-runbook], এবং [error-handling] বিদ্যমান। এটি প্রথম তিনটি উপেক্ষা করে। যদি আপনার প্রজেক্টের নাল সেফটির (null safety) নিয়মাবলী নির্দিষ্ট হয়, তবে এটি [error-handling] লোড করতে পারে। এটি বাগটি ঠিক করে ফেলে। অপ্রাসঙ্গিক স্কিলগুলো কখনোই কনটেক্সট উইন্ডোতে প্রবেশ করেনি। প্রম্পটটি পরিষ্কার থাকায় মডেলটি ফোকাসড থাকতে পেরেছে।
কাজটি যখন আসলেই জটিল হয়, তখনও একই লজিক কাজ করে। আপনি যদি পরে এজেন্টকে একটি প্রোডাকশন ডিপ্লয়মেন্ট (production deployment) প্রস্তুত করতে বলেন, তবে এটি ডিপ্লয়মেন্ট রানবুক লোড করতে পারে, সিকিউরিটি গাইড দেখে নিতে পারে এবং রিলিজ চেকলিস্ট অনুসরণ করতে পারে ঠিক যখন সেই ধাপগুলো প্রাসঙ্গিক হয়ে ওঠে। জ্ঞানটি সবসময় সেখানেই ছিল। এটি কেবল সঠিক মুহূর্তের জন্য অপেক্ষা করছিল।
আর্কিটেকচার হিসেবে প্রম্পট ডিসিপ্লিন (Prompt Discipline)
APC এবং APX-এর মধ্যকার বিভাজন কেবল একটি ইমপ্লিমেন্টেশন ডিটেইল নয়। এটি প্রম্পট ডিসিপ্লিনের একটি দর্শন। APC জ্ঞানকে চিরস্থায়ীভাবে সংরক্ষণ করে, যা একে রিভিউযোগ্য, ভার্সনযুক্ত এবং নিরাপদ করে তোলে। APX সিদ্ধান্ত নেয় সেই জ্ঞানের কতটুকু অংশ এখনকার সক্রিয় কনটেক্সটে জায়গা পাবে।
একটি সমৃদ্ধ স্কিল ক্যাটালগ হলো একটি সম্পদ। একটি অতিরিক্ত ভারি (bloated) প্রম্পট হলো একটি দায়। লক্ষ্য হলো আপনার কনটেক্সটকে সবসময় সক্রিয় না করেই পোর্টেবল রাখা। আপনার রিপোজিটরিতে আপনার টিমের লেখা প্রতিটি নির্দেশনা থাকা উচিত, কিন্তু এজেন্টকে কেবল সেই নির্দেশনাবলিই পড়া উচিত যা তাৎক্ষণিক কাজে সাহায্য করে।
যদি আপনার সিস্টেম মডেলটিকে প্রতিটি টার্নে প্রতিটি স্কিলের বিস্তারিত তথ্য বহন করতে বাধ্য করে, তবে আপনি কোনো বুদ্ধিমান অ্যাসিস্ট্যান্ট তৈরি করছেন না। আপনি এমন একজন লাইব্রেরিয়ান তৈরি করছেন যিনি প্রতিটি রেফারেন্স ডেস্কের প্রশ্নের জন্য পুরো আর্কাইভ টেনে নিয়ে আসেন। সবকিছু সংরক্ষণ করুন। যা প্রয়োজন কেবল সেটুকুই লোড করুন। এভাবেই আপনি এজেন্টদের দ্রুত, কনটেক্সট পরিষ্কার এবং রিজনিং (reasoning) তীক্ষ্ণ রাখতে পারেন।