এজেন্টের সার্ভার কেনার বেশিরভাগ ডেমো থেমে যায় অর্ডার সম্পন্ন হওয়ার মুহূর্তে। সেটাই সবচেয়ে কম আকর্ষণীয় মুহূর্ত। সার্ভার আছে, এজেন্টের হাতে 47HZ7YF-এর মতো একটা id, আর এরপর কী হবে কেউ বলেনি।
এরপর আসে সেই সব কাজ যা একজন অ্যাডমিন না ভেবেই করেন: SSH সত্যিই সাড়া দেওয়া পর্যন্ত অপেক্ষা, পাসওয়ার্ড খোঁজা, ডিস্ক ভরে যাচ্ছে খেয়াল করা, কার্নেল আপডেটের পর রিবুট, মাস শেষ হওয়ার আগে নবায়ন, কিছু অদ্ভুত লাগলে সাপোর্টকে জিজ্ঞেস করা। এজেন্ট যদি অবকাঠামোর মালিক হয়, তবে এই অংশও তার। আমাদের MCP সার্ভারে এটা কীভাবে হয় নিচে দেখানো হলো। লেখার আগে প্রতিটি ধাপ আমরা পরীক্ষার পরিবেশে চালিয়ে দেখেছি।
এখনও ক্লায়েন্ট যুক্ত না করে থাকলে শুরু করুন Claude Code ও Codex বা Claude Desktop ও Cursor দিয়ে।
প্রথম মিনিট: "active" মানে "প্রস্তুত" নয়
ব্যালান্স থেকে অর্ডারের দাম মেটানো মাত্রই order_vps সাড়া দেয়। সার্ভার তৈরি হয় ব্যাকগ্রাউন্ডে, সাধারণত প্রায় এক মিনিটে। এজেন্টের পরের কল get_vps_status, আর সে এটা যতবার খুশি করতে পারে: টুলটা শুধু পড়ে।
দুটি ফিল্ড গুরুত্বপূর্ণ। মেশিন তৈরি হলে status হয় active। access-এ থাকে লগইনের সবকিছু: হোস্ট, পোর্ট আর তৈরি SSH কমান্ড। নিজস্ব IPv4-এর প্ল্যানে পোর্ট 22। NAT প্ল্যানে এটা ব্যক্তিগত ফরোয়ার্ড করা পোর্ট, আর উত্তরে সেটা স্পষ্ট বলা থাকে, সঙ্গে সতর্কতাও যে শুধু বাইরের পোর্ট খোলা ফায়ারওয়াল দিয়ে নিজেকে আটকে ফেলবেন না।
এই দুই মুহূর্তের মাঝে একটা ফাঁক আছে যেখানে মানুষ হোঁচট খায়। প্রথম বুটে OS আপডেট বসে, যাতে কয়েক মিনিট লাগতে পারে, আর তখন SSH সংযোগ ফিরিয়ে দিতে পারে। ভদ্র এজেন্ট 22 নম্বর পোর্টে বারবার ধাক্কা না দিয়ে access.ssh_ready-এর অপেক্ষা করে।
অর্ডারে SSH কী না থাকলে root পাসওয়ার্ড অপেক্ষা করছে। reveal_password সেটা ঠিক একবার দেয়, আর তাও শুধু VM বুট শেষ হওয়ার পর। বেশি আগে চাইলে পাবেন password_pending, একবারের দেখার সুযোগ খরচ হবে না। আমরা এভাবে বানিয়েছি কারণ এজেন্টরা বারবার এমন পাসওয়ার্ড নিচ্ছিল যা বুট হতে থাকা VM তখনও প্রয়োগ করেনি। তবে সত্যি বলতে: অর্ডারের সঙ্গে ssh_key দিন আর এই ধাপটা পুরোপুরি বাদ দিন।
দ্বিতীয় দিন: নজর রাখা
get_vps_metrics গত এক ঘণ্টা, দিন, সপ্তাহ বা মাসের CPU, মেমরি, নেটওয়ার্ক আর ডিস্কের টাইম সিরিজ দেয়। দিনে একবার দেখা এজেন্ট ছোট সার্ভারকে মেরে ফেলা প্যাটার্নটা ধরতে পারে: মেমরি ধীরে ধীরে বাড়ে যতক্ষণ না OOM killer একটা শিকার বেছে নেয়। বাইরে থেকে সে কারণ সারাতে পারে না, কিন্তু আপনাকে জানাতে পারে বা SSH দিয়ে ঢুকে দেখতে পারে।
power_vps করে start, stop আর reboot। পরীক্ষার একটা খুঁটিনাটি: সার্ভার সক্রিয় না থাকলে (এখনও তৈরি হচ্ছে, বা অপরিশোধিত নবায়নের জন্য স্থগিত), টুলটা আগে স্ট্যাটাস দেখার পরামর্শসহ 409 ফেরত দেয়। যে এজেন্ট 200 ছাড়া সব উত্তরকে "চিরকাল আবার চেষ্টা" ধরে, সে এখানে লুপে আটকে যাবে। ত্রুটি নিজেই বলে দেয় কী করতে হবে, কারণ আমাদের ত্রুটির বার্তা মানুষের মতো এজেন্টদের জন্যও লেখা।
set_hostname মেশিনের ভেতরে চলা গেস্ট এজেন্ট দিয়ে নাম বদলায়, তাই Linux-এ রিবুট ছাড়াই কার্যকর হয়। qemu-guest-agent সরিয়ে দিলে টুলটা কাজ বন্ধ করে: agent_unavailable ফেরত দেয় আর কিছু বদলায় না।
ত্রিশতম দিন: টাকা
এজেন্টের অবকাঠামো সাধারণত এখানেই মরে। নবায়ন কারও ক্যালেন্ডারের রিমাইন্ডার, সে ব্যস্ত, সার্ভার স্থগিত হয়ে যায়।
আমাদের এখানে নবায়ন এজেন্টের স্মৃতির ওপর নির্ভর করে না। প্রতিটি সার্ভার প্রিপেইড ব্যালান্স থেকে প্রতি মাসে নবায়ন হয়, আর তারিখের আগে অ্যাকাউন্টের ইমেলে রিমাইন্ডার যায়। এজেন্টকে শুধু ব্যালান্স পরের কাটার চেয়ে বেশি রাখতে হবে, আর get_balance জানায় অবস্থা কেমন।
কোনো গ্রেস পিরিয়ড নেই: মেয়াদের শেষে ব্যালান্সে নবায়ন না হলে সার্ভার স্থগিত হয় আর তার ডেডিকেটেড IP পুলে ফিরে যায়।
ব্যালান্স কম হলে topup_balance ক্রিপ্টো পেমেন্ট লিংক বানায়: Base, Ethereum বা Polygon-এ USDT, USDC বা ETH। এটাই প্রথম জায়গা যেখানে এজেন্টের আপনাকে দরকার। সে ইনভয়েস বানাতে পারে, কিন্তু আপনি ওয়ালেট না দিলে লেনদেনে সই করতে পারে না, আর সেটা করার আগে আমরা অনেক ভাবতাম। বাস্তবে মানুষ কয়েক মাসের জন্য একবার টপ-আপ করে আর এজেন্টকে সেখান থেকে খরচ করতে দেয়। ব্যালান্স কম থাকায় কোনো অর্ডার বা ইনভয়েস অপরিশোধিত থাকলে, আপনার টপ-আপের পর এজেন্ট pay_invoice ডাকে আর সেটা ব্যালান্স থেকে মেটানো হয়।
একটা সৎ ফাঁক: MCP টুল চাইলে সার্ভারকে কয়েক মাস আগে থেকে নবায়ন করে না। মাসিক নবায়ন স্বয়ংক্রিয়, আর 3, 6 বা 12 মাস আগাম দেওয়া হয় ড্যাশবোর্ডে বা একটি REST কলে। শুরু থেকেই লম্বা মেয়াদ চাইলে order_vps অর্ডারের সময় months (1 থেকে 36) নেয়।
বৃদ্ধি সামলায় get_upgrade_options আর change_plan। প্ল্যান জায়গাতেই বদলায়, ফাইল আর OS থেকে যায়, সার্ভার একবার রিবুট হয়, আর বাকি মেয়াদের দামের পার্থক্য ব্যালান্স থেকে কাটে। এজেন্টকে confirm: true পাঠাতে হয় — এটা আমাদের বলার ধরন, "তুমি টাকা খরচ করছ, নিশ্চিত হও"।
যখন কিছু ভুল হয়
ধ্বংসাত্মক কাজ ইচ্ছে করেই ঝামেলার বানানো। reinstall_vps আর তাৎক্ষণিক cancel_service দুটোই confirm-এ সার্ভারের হুবহু hostname চায়, আর তাদের বিবরণ এজেন্টকে আগে কোনো মানুষকে জিজ্ঞেস করতে বলে। এটা দ্বিতীয় জায়গা যেখানে এজেন্টের আপনাকে দরকার, আর এটা ইচ্ছাকৃত।
নিরাপদ বাতিল, end_of_period, পরিশোধিত সময় শেষ হওয়া পর্যন্ত সার্ভার রাখে। undo_cancel সেটা ফিরিয়ে নেয়, আর এটা যতটা মনে হয় তার চেয়ে গুরুত্বপূর্ণ: এজেন্টরাও কাজের মাঝে মানুষের মতোই মন বদলায়।
এজেন্ট আটকে গেলে create_ticket সার্ভারের সঙ্গে যুক্ত টিকিট খোলে, আর reply_ticket কথোপকথন চালায়। পড়েন আমাদের দিকের একজন মানুষ, চ্যাটবটকে চ্যাটবট উত্তর দিচ্ছে না।
আর যখন মানুষকে হস্তক্ষেপ করতে হয়, delegate_service তাকে ইমেলে শুধু সেই সার্ভারের অপারেটর হিসেবে আমন্ত্রণ জানায়। সে পায় পাওয়ার, কনসোল, আবার ইনস্টল আর hostname। বিলিং, নবায়ন বা বাতিল পায় না, আর এজেন্টের টোকেন কখনো দেখে না।
এজেন্ট এখনও যা পারে না
সীমাগুলো পরিষ্কার থাকুক:
- ব্যালান্স ভরা। সে টপ-আপ ইনভয়েস বানাতে আর
pay_invoiceদিয়ে ব্যালান্স থেকে ইনভয়েস মেটাতে পারে। ব্যালান্সে ক্রিপ্টো আনতে ওয়ালেট লাগে, মানে সাধারণত আপনাকে। - MCP দিয়ে OS-এর ভেতরে কাজ। প্যাকেজ, কনফিগ আর ডিপ্লয় যায় SSH দিয়ে। MCP মেশিনকে বাইরে থেকে চালায়।
- নিজে স্থগিতাদেশ তোলা। অপব্যবহারের জন্য সার্ভার স্থগিত হলে সেটা মানুষের সঙ্গে আলাপের বিষয়, আর তেমনই হওয়া উচিত।
এর কোনোটাই টুলগুলোকে কম কাজের করে না। এর মানে শুধু এজেন্টের লুপ এগুলোকে ঘিরে বানাতে হবে: স্ট্যাটাস দেখা, ব্যালান্স ঠিক সীমায় রাখা, টিকিটে বিষয় এগিয়ে নেওয়া আর ডেটা মোছার মতো যেকোনো কাজের আগে আপনার অপেক্ষা করা।
এজেন্টের কাজ স্বল্পস্থায়ী হলে পুরো সার্ভার হয়তো ঠিক একক নয়। VPS নাকি স্যান্ডবক্স? বলে কখন এক মিনিট বাঁচা microVM ভালো মানায়। নইলে প্ল্যান এখানে, আর MCP রেফারেন্স প্রতিটি টুল প্যারামিটারসহ তালিকা করে।
মন্তব্য
এখনো কোনো মন্তব্য নেই। প্রথম হোন।