Почти всички демота, в които агент купува сървър, свършват в момента на плащането. Това е най-скучният момент. Сървърът го има, агентът държи id като 47HZ7YF и никой не е обяснил какво следва.
Следва всичко, което админът прави, без да се замисля: да изчака SSH наистина да отговори, да намери паролата, да забележи, че дискът се пълни, да рестартира след обновяване на ядрото, да поднови до края на месеца, да пише на поддръжката, когато нещо е странно. Ако на агента се доверява инфраструктура, тази част също е негова. Ето как изглежда това през нашия MCP сървър. Всяка стъпка минахме в тестовата среда, преди да я опишем.
Ако клиентът още не е свързан, започнете с Claude Code и Codex или Claude Desktop и Cursor.
Първата минута: „active“ още не значи „готов“
order_vps отговаря веднага щом поръчката е платена от баланса. Самият сървър се създава на заден план, обикновено за около минута. Следващото извикване на агента е get_vps_status и може да го вика колкото си иска: инструментът само чете.
Важни са две полета. status става active, когато машината е създадена. В access е всичко за вход: адрес, порт и готова SSH команда. При плановете със собствен IPv4 портът е 22. При NAT плановете е личен пренасочен порт и отговорът го казва направо, включително предупреждение да не се заключите с firewall, разрешил само външния порт.
Между тези моменти има празнина, в която се спъват. Първото зареждане инсталира обновления на ОС, това може да отнеме няколко минути и SSH дотогава може да отказва. Внимателният агент чака access.ssh_ready, а не блъска по 22-ри порт.
Ако към поръчката не е подаден 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 дава линк за плащане с крипто: USDT, USDC или ETH в мрежите Base, Ethereum или Polygon. Това е първото място, където агентът има нужда от вас. Сметката ще създаде, но транзакция без портфейл няма да подпише, а да дадем портфейл на агент бихме помислили сто пъти. На практика балансът се зарежда веднъж за няколко месеца, а агентът харчи от него. Ако поръчка или сметка е останала неплатена, защото балансът не е стигнал, след вашето зареждане агентът вика pay_invoice — и тя се плаща от баланса.
Честна празнина: през MCP не може да се поднови сървър няколко месеца напред по желание. Месечното подновяване върви само, а плащането наведнъж за 3, 6 или 12 месеца — през кабинета или една REST заявка. Ако дълъг срок ви трябва от самото начало, order_vps приема months от 1 до 36 още при поръчката.
Растежът се покрива от get_upgrade_options и change_plan. Планът се сменя на място, файловете и ОС остават, сървърът се рестартира веднъж, а разликата за остатъка от периода се взима от баланса. Агентът трябва да подаде confirm: true — така казваме „харчиш пари, бъди сигурен“.
Когато нещо се обърка
Разрушителните действия са нарочно неудобни. reinstall_vps и незабавният cancel_service изискват точното име на сървъра в confirm, а в описанията им на агента е казано първо да попита човек. Това е второто място, където без вас не става, и така е замислено.
Безопасното прекратяване, end_of_period, оставя сървъра до края на платения срок. undo_cancel го отменя и това е по-важно, отколкото изглежда: агентите се отказват по средата на задача не по-рядко от хората.
Ако агентът е заседнал, create_ticket отваря тикет, свързан със сървъра, а reply_ticket продължава кореспонденцията. Чете го човек от наша страна — не е чатбот, който отговаря на чатбот.
А когато трябва да се намеси човек, delegate_service го кани по имейл като оператор на един сървър. Получава захранване, конзола, преинсталиране и име. Плащане, подновяване и прекратяване — не, и токена на агента няма да види.
Какво агентът все още не може
За да няма илюзии:
- Да зарежда баланса. Сметка за зареждане ще създаде, а сметките ще плати от баланса през
pay_invoice. Но да вкара крипто в баланса може само портфейл, тоест обикновено вие. - Да работи в ОС през MCP. Пакетите, конфигурацията и деплоят минават по SSH. MCP управлява машината отвън.
- Сам да вдигне спирането. Ако сървърът е спрян заради злоупотреба, това е разговор с човек и така трябва да бъде.
Полезността на инструментите от това не намалява. Просто цикълът на агента трябва да се изгради около тях: да проверява статуса, да държи баланса в нужните граници, да ескалира с тикет и да ви чака преди всичко, което трие данни.
Ако работата на агента е кратка, цял сървър може да е излишен. В статията VPS или пясъчник — кога е по-добра microVM, която живее минута. В останалите случаи плановете са тук, а справочникът на MCP изброява всички инструменти с параметрите им.
Коментари
Още няма коментари. Бъди първият.