بیشتر نمایشهایی که در آنها ایجنت سرور میخرد، همان لحظهای تمام میشوند که سفارش ثبت میشود. این کمجذابترین لحظه است. سرور هست، ایجنت شناسهای مثل 47HZ7YF در دست دارد، و هیچکس نگفته بعدش چه میشود.
بعدش همهٔ کارهایی است که یک ادمین بدون فکر انجام میدهد: صبر تا SSH واقعاً جواب بدهد، پیدا کردن رمز، متوجه شدن پر شدن دیسک، ریاستارت بعد از بهروزرسانی کرنل، تمدید پیش از تمام شدن ماه، پرسیدن از پشتیبانی وقتی چیزی عجیب است. اگر قرار است ایجنت صاحب زیرساخت باشد، این بخش هم با اوست. در ادامه میبینید این کار با سرور MCP ما چطور پیش میرود. هر قدم را پیش از نوشتن در محیط آزمایشیمان اجرا کردیم.
اگر هنوز کلاینتی وصل نکردهاید، از Claude Code و Codex یا Claude Desktop و Cursor شروع کنید.
دقیقهٔ اول: «active» یعنی «آماده» نیست
order_vps همین که سفارش از موجودی پرداخت شود پاسخ میدهد. سرور در پسزمینه ساخته میشود، معمولاً در حدود یک دقیقه. فراخوانی بعدی ایجنت get_vps_status است و میتواند هر چند بار بخواهد تکرارش کند: این ابزار فقط میخواند.
دو فیلد مهماند. وقتی ماشین ساخته شد، status به active تبدیل میشود. access همهٔ چیزهای لازم برای ورود را دارد: آدرس، پورت و یک دستور SSH آماده. در پلنهای دارای IPv4 اختصاصی پورت ۲۲ است. در پلنهای NAT یک پورت فورواردشدهٔ شخصی است و پاسخ این را صریح میگوید، همراه با هشدار که با فایروالی که فقط پورت بیرونی را باز میکند خودتان را بیرون نگذارید.
بین این دو لحظه شکافی هست که آدمها در آن زمین میخورند. اولین بوت بهروزرسانیهای سیستمعامل را نصب میکند که ممکن است چند دقیقه طول بکشد، و در این مدت SSH ممکن است اتصال را رد کند. ایجنت مؤدب بهجای کوبیدن پورت ۲۲ منتظر access.ssh_ready میماند.
اگر سفارش کلید SSH نداشت، رمز root منتظر است. reveal_password آن را دقیقاً یک بار میدهد و فقط بعد از اینکه بوت VM تمام شد. اگر زود بپرسید password_pending میگیرید و فرصت یکباره هدر نمیرود. این را بعد از آن ساختیم که ایجنتها مدام رمزی را برمیداشتند که VM در حال بوت هنوز اعمالش نکرده بود. ولی راستش: در سفارش یک ssh_key بفرستید و این قدم را کلاً حذف کنید.
روز دوم: زیر نظر داشتن
get_vps_metrics پردازنده، حافظه، شبکه و دیسک را بهصورت سری زمانی برای ساعت، روز، هفته یا ماه گذشته برمیگرداند. ایجنتی که روزی یک بار نگاه کند میتواند الگویی را ببیند که سرورهای کوچک را از پا درمیآورد: حافظه آرامآرام بالا میرود تا OOM killer قربانیای انتخاب کند. از بیرون نمیتواند علت را رفع کند، اما میتواند به شما خبر بدهد یا با SSH وارد شود و نگاه کند.
power_vps کارهای start، stop و reboot را انجام میدهد. نکتهای از تستها: اگر سرور فعال نباشد (هنوز در حال ساخت باشد یا بهخاطر تمدید پرداختنشده معلق شده باشد)، ابزار 409 برمیگرداند و پیشنهاد میکند اول وضعیت را بررسی کنید. ایجنتی که هر پاسخ غیر 200 را «تا ابد دوباره تلاش کن» بداند، اینجا در حلقه گیر میکند. خود خطا میگوید چه باید کرد، چون پیامهای خطای ما به همان اندازه برای ایجنتها نوشته شده که برای انسانها.
set_hostname نام ماشین را از طریق guest agent داخل آن تغییر میدهد، پس در لینوکس بدون ریاستارت اعمال میشود. اگر qemu-guest-agent را حذف کنید، این ابزار کار نمیکند: agent_unavailable برمیگرداند و چیزی را تغییر نمیدهد.
روز سیام: پول
زیرساخت ایجنتها معمولاً همینجا میمیرد. تمدید یک یادآور در تقویم کسی است، آن شخص گرفتار است، سرور معلق میشود.
پیش ما تمدید به حافظهٔ ایجنت بستگی ندارد. هر سرور هر ماه از موجودی پیشپرداخت تمدید میشود و پیش از موعد یادآورها به ایمیل حساب میرسند. ایجنت فقط باید موجودی را بالاتر از کسر بعدی نگه دارد، و get_balance وضعیت را نشان میدهد.
مهلت اضافه وجود ندارد: اگر در پایان دوره موجودی برای تمدید کافی نباشد، سرور معلق میشود و IP اختصاصیاش به استخر برمیگردد.
وقتی موجودی کم است، topup_balance یک لینک پرداخت کریپتو میسازد: USDT، USDC یا ETH روی Base، Ethereum یا Polygon. این اولین جایی است که ایجنت به شما نیاز دارد. صورتحساب را میسازد، اما تا به او کیف پول ندهید نمیتواند تراکنش امضا کند، و ما پیش از چنین کاری خیلی فکر میکنیم. در عمل مردم یک بار برای چند ماه شارژ میکنند و میگذارند ایجنت از همان خرج کند. اگر سفارش یا صورتحسابی بهخاطر کمبود موجودی پرداختنشده ماند، بعد از شارژ شما ایجنت pay_invoice را صدا میزند و از موجودی پرداخت میشود.
یک کمبود صادقانه: ابزارهای MCP سرور را به درخواست چند ماه جلوتر تمدید نمیکنند. تمدید ماهانه خودکار است و پیشپرداخت ۳، ۶ یا ۱۲ ماه از داشبورد یا با یک فراخوانی REST انجام میشود. اگر از اول دورهٔ طولانیتر میخواهید، order_vps هنگام سفارش months (۱ تا ۳۶) میپذیرد.
رشد را get_upgrade_options و change_plan پوشش میدهند. پلن در جا عوض میشود، فایلها و سیستمعامل میمانند، سرور یک بار ریاستارت میشود و اختلاف قیمت برای باقی دوره از موجودی کم میشود. ایجنت باید confirm: true بفرستد — این روش ما برای گفتن «داری پول خرج میکنی، مطمئن باش» است.
وقتی کار خراب میشود
کارهای مخرب عمداً دستوپاگیرند. reinstall_vps و cancel_service فوری هر دو نام دقیق سرور را در confirm میخواهند و توضیحاتشان به ایجنت میگوید اول با یک انسان مشورت کند. این دومین جایی است که ایجنت به شما نیاز دارد، و عمدی است.
لغو امن، end_of_period، سرور را تا پایان زمان پرداختشده نگه میدارد. undo_cancel آن را برمیگرداند و این مهمتر از آن است که فکر میکنید: ایجنتها هم وسط کار به همان اندازهٔ انسانها نظرشان عوض میشود.
وقتی ایجنت گیر میکند، create_ticket تیکتی مرتبط با سرور باز میکند و reply_ticket گفتوگو را ادامه میدهد. آن را یک انسان در سمت ما میخواند، نه چتباتی که به چتبات جواب میدهد.
و وقتی انسانی باید وارد شود، delegate_service او را از طریق ایمیل بهعنوان اپراتور همان یک سرور دعوت میکند. او برق، کنسول، نصب مجدد و hostname را میگیرد. صورتحساب، تمدید و لغو را نمیگیرد و هرگز توکن ایجنت را نمیبیند.
کارهایی که ایجنت هنوز نمیتواند
برای روشن بودن مرزها:
- شارژ موجودی. میتواند صورتحساب شارژ بسازد و صورتحسابها را با
pay_invoiceاز موجودی بپردازد. وارد کردن کریپتو به موجودی کیف پول میخواهد، یعنی معمولاً شما. - کار داخل سیستمعامل با MCP. بستهها، پیکربندی و استقرار از SSH میگذرند. MCP ماشین را از بیرون اداره میکند.
- برداشتن تعلیق بهتنهایی. اگر سرور بهخاطر سوءاستفاده معلق شده باشد، این گفتوگویی با انسان است، و باید همینطور باشد.
هیچکدام از اینها ابزارها را کمفایدهتر نمیکند. فقط یعنی حلقهٔ ایجنت را باید حول آنها طراحی کنید: وضعیت را بپرسد، موجودی را در محدودهٔ درست نگه دارد، با تیکت موضوع را بالا ببرد و برای هر چیزی که داده پاک میکند منتظر شما بماند.
اگر کار ایجنت کوتاهمدت است، شاید یک سرور کامل واحد مناسبی نباشد. VPS یا سندباکس؟ توضیح میدهد کی یک microVM که یک دقیقه زنده است مناسبتر است. وگرنه پلنها اینجا هستند و مرجع MCP همهٔ ابزارها را با پارامترهایشان فهرست میکند.
نظرات
هنوز نظری نیست. اولین نفر باشید.