মানুষ ও এজেন্টদের জন্য শেয়ার করা ওয়ার্কস্পেস তৈরি

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

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

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

বড় করুন

আর্কিটেকচার

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

আমাদের আর্কিটেকচার পুরো প্রক্রিয়াটি ক্লাউডে চালায় এবং কোডিংয়ের বাইরেও সব ধরনের নলেজ ওয়ার্ক সমর্থন করে। প্রতিটি Computer প্রজেক্টের পেছনে রয়েছে একটি Git রিপোজিটরি, যা ৫টি কম্পোনেন্টের মাধ্যমে সার্ভ করা হয়:

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

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

এরপর আমরা একে একে প্রতিটি কম্পোনেন্ট ব্যাখ্যা করব।

বড় করুন

CLI: স্যান্ডবক্সে লোকাল ফাইল নিয়ে কাজ

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

এজেন্টরা সাধারণত প্রজেক্ট ফাইলের খুব সামান্য অংশ নিয়েই কাজ করে, তাই শুরুতেই পুরো রিপোজিটরি ম্যাটেরিয়ালাইজ করার প্রয়োজন নেই। সে কারণে CLI লেজি পদ্ধতিতে, অর্থাৎ প্রয়োজন অনুযায়ী, ম্যাটেরিয়ালাইজ করে: Git Large File Storage (LFS)-এর মাধ্যমে সংরক্ষিত বড় ও বাইনারি ফাইলগুলো ছোট পয়েন্টার ফাইল হিসেবে আসে, যেগুলোতে অবজেক্টের প্রকৃত আকার লেখা থাকে; ফলে এজেন্ট নাম ও আকার দেখে ঠিক করতে পারে ডাউনলোড করা সার্থক হবে কি না। PDF-এর মতো ডকুমেন্টের ক্ষেত্রে এজেন্ট প্রথমে পার্স করা টেক্সট পড়ে এবং কেবল প্রয়োজন হলেই সোর্স ফাইল ডাউনলোড করে।

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

বড় করুন

কন্ট্রোল প্লেন: রিপোজিটরি খুঁজে বের করা ও অ্যাক্সেস প্রদান

কন্ট্রোল প্লেন খুঁজে বের করে প্রতিটি রিপোজিটরি কোথায় সংরক্ষিত আছে এবং সেটিতে অ্যাক্সেস প্রদান করে। কোনো রিপোজিটরি তৈরি হলে কন্ট্রোল প্লেন সেটিকে একটি স্টোরেজ সেলে বরাদ্দ করে—স্টোরেজ সেল হলো স্টোরেজের একটি বিচ্ছিন্ন একক, যার নিজস্ব Git সার্ভিস রেপ্লিকা রয়েছে। কোনো এজেন্ট একটি প্রজেক্টে কাজ শুরু করলে CLI কন্ট্রোল প্লেনের কাছে জানতে চায় রিপোজিটরিটি কোথায় সংরক্ষিত আছে। কন্ট্রোল প্লেন অবস্থান এবং Git সার্ভিসের জন্য অস্থায়ী ক্রেডেনশিয়াল ফেরত দেয়। কন্ট্রোল প্লেন কখনোই রিপোজিটরির ডেটা পড়ে না বা লেখে না। রিপোজিটরিতে কী প্রবেশ করবে, তা ঠিক করে Git সার্ভিস।

Git সার্ভিস: ডেটা স্থানান্তর ও আপডেট সমন্বয়

Git সার্ভিস Git অপারেশন সম্পাদন করে এবং স্যান্ডবক্স ও স্টোরেজের মধ্যে রিপোজিটরির কনটেন্ট ও সংস্করণ ইতিহাস স্থানান্তর করে। এটি Git-এর নিজস্ব সার্ভিং কমান্ডগুলোর ওপর একটি পাতলা র‍্যাপার। এটি ক্লায়েন্টকে রিপোজিটরির হেড কোথায় তা জানানোর জন্য ref ডিসকভারি, ক্লোন ও ফেচ করার জন্য upload-pack, এবং নতুন অবজেক্ট ও রিপোজিটরির হেড এগিয়ে নেওয়ার অনুরোধ গ্রহণের জন্য receive-pack সমর্থন করে। এটি Git LFS API-ও সার্ভ করে: বড় ও বাইনারি ফাইলের জন্য এটি স্বল্পমেয়াদি লিংক দেয়, যাতে স্যান্ডবক্সগুলো সরাসরি S3-এ ওই ফাইলগুলো আপলোড এবং S3 থেকে ডাউনলোড করতে পারে।

আমরা শুরু করেছিলাম একটি তৈরি (অফ-দ্য-শেলফ) ফোর্জ সার্ভার দিয়ে, যাতে কেবল আমাদের প্রয়োজনীয় Git অপারেশনগুলোর ওপর কেন্দ্রীভূত নিজস্ব হালকা ফোর্জ তৈরির পাশাপাশি সমান্তরালভাবে এজেন্ট ও ব্যবহারকারী ইন্টারফেসের প্রোটোটাইপ করতে পারি।

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

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

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

বড় করুন

একটি সাধারণ সিঙ্ক্রোনাইজেশন ধাপ একযোগে লিখতে থাকা একাধিক রাইটারকে নিয়ন্ত্রণ করে। এটি সর্বশেষ গৃহীত কমিট, অর্থাৎ হেড, ট্র্যাক করে। কোনো সাবমিশন পেলে এটি কেবল তখনই সেটি গ্রহণ করে, যদি সাবমিটটি ওই হেডের ওপর ভিত্তি করে তৈরি হয়ে থাকে। তা না হলে এটি একটি কাঠামোবদ্ধ স্টেল-বেস রেসপন্স পাঠায়; তখন হেরে যাওয়া পক্ষকে নতুন হেডের ওপর তার পরিবর্তন রিপ্লে করে আবার সাবমিট করতে হয়। এই ডিজাইন নিশ্চিত করে যে একযোগে কাজ করা এজেন্টরা নীরবে একে অপরের কাজ ওভাররাইট করে না, আর তাতে উল্লেখযোগ্যভাবে গতিও কমে না। আমাদের প্রোডাকশন ওয়ার্কফ্লোতে ২%-এরও কম সাবমিট স্টেল হিসেবে প্রত্যাখ্যাত হয়। সামগ্রিকভাবে, সাবমিটের মিডিয়ান লেটেন্সি ১.৭ সেকেন্ডের কম এবং p99 লেটেন্সি ৮ সেকেন্ডের কম।

বড় করুন

Git সার্ভিস প্রতিটি গৃহীত পরিবর্তনও রেকর্ড করে। প্রতিটি গৃহীত রাইটের জন্য এটি একটি আউটবক্সে একটি এন্ট্রি যোগ করে—আউটবক্স হলো একটি লগ, যেখানে রিপোজিটরি, নতুন কমিট, পরিবর্তনকারী ব্যবহারকারী এবং পরিবর্তিত পাথগুলোর তালিকা থাকে। পার্সারের মতো ডাউনস্ট্রিম সার্ভিসগুলো নতুন কাজ খুঁজে পেতে এই লগ পড়ে।

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

স্টোরেজ: কাজকে টেকসই রাখা

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

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

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

বড় করুন

ডাউনস্ট্রিম প্রসেসিং: এজেন্টদের জন্য ডকুমেন্ট পাঠযোগ্য করা

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

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

এজেন্টরা কীভাবে ওয়ার্কস্পেস ব্যবহার করে

স্যান্ডবক্সে লোড করা রিপোজিটরি সংস্করণটি এজেন্টরা স্ট্যান্ডার্ড ফাইলসিস্টেম টুল দিয়ে খুঁজে দেখে। “আগে সার্চ, পরে পড়া”-র মতো নির্দিষ্ট কোনো পাইপলাইন অনুসরণ করার বদলে তারা ফোল্ডারের তালিকা দেখে, grep দিয়ে ফাইলের কনটেন্টে সার্চ করে, প্রাসঙ্গিক অংশ পড়ে এবং যা পায় তার ভিত্তিতে ঠিক করে এরপর কোথায় দেখবে।

Computer-এর মতোই, Search তার স্ট্যান্ডার্ড ফাইল টুলের মাধ্যমে একই পদ্ধতি ব্যবহার করে। একটি আলাদা এক্সপ্লোরেশন এজেন্ট আরও সীমিত বাজেটের মধ্যে প্রজেক্টে সার্চ করে এবং প্রাসঙ্গিক ফাইল পাথ ও সহায়ক উদ্ধৃতাংশ ফেরত দেয়। এরপর উত্তর দেওয়ার মডেলটি নির্বাচিত ফাইলগুলো পড়ে উত্তর তৈরি করে। বিদ্যমান প্রজেক্ট স্যান্ডবক্স পুনর্ব্যবহার করলে সেটআপের সময় কমে: একটি ওয়ার্ম চেকআউটে যুক্ত হতে প্রায় ২.৯ সেকেন্ড লাগে, যেখানে কোল্ড স্টার্টে লাগে প্রায় ৮ সেকেন্ড।

বড় করুন

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

একই কর্পাসের ওপর ১৫০টি একক-ডকুমেন্ট আর্থিক প্রশ্নে আমরা এই পদ্ধতিকে একটি ইনডেক্সভিত্তিক সিমান্টিক সার্চের সঙ্গে বেঞ্চমার্ক করেছি। সঠিক ডকুমেন্ট খুঁজে বের করায় এক্সপ্লোরেশন এজেন্টের স্কোর ছিল ০.৮৬৭ এবং সঠিক উত্তর দেওয়ায় ০.৬২৭, যেখানে সিমান্টিক সার্চের স্কোর ছিল যথাক্রমে প্রায় ০.৩৯ ও ০.৩৭—অর্থাৎ উত্তরে প্রায় ১.৭ গুণ এবং রিট্রিভালে প্রায় ২ গুণ ভালো, আর লেটেন্সি প্রায় ২৫% কম। এক্সপ্লোরেশন এজেন্ট মূলত বের করা টেক্সট নিয়েই কাজ করে এবং মূল PDF খুব কমই ডাউনলোড করে।

বড় করুন

একটি শেয়ার করা অবকাঠামো

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

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

উপসংহার

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

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

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

উদ্ধৃতি

@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}