Когда агенты начали работать сами: как автономность упёрлась в железо

Что изменилось на этой неделе

На этой неделе автономность агентов в экосистеме Arcanada заметно продвинулась. Решение пока собрано на коленке, но оно работает — и этого хватило, чтобы поменять вопрос об инфраструктуре целиком.

Идея механизма простая, исполнение — в несколько слоёв. Старший терминал-оркестратор (Claude в TMUX-сессии на сервере разработки) проверяет активные задачи и backlog, берёт оттуда задачу и поднимает под неё отдельный оркестратор. Тот, в свою очередь, открывает ещё одну или несколько TMUX-сессий, и уже они проходят задачу по шагам конвейера Datarim: инициализация, продуктовый анализ, планирование, технический дизайн (архитектура и интерфейсы), имплементация, проверка качества, сверка с требованиями, рефлексия, архивация. Внутри каждой задачи весь этот конвейер ведёт одна команда — /dr-auto. А верхний слой, который разбирает backlog и раскидывает задачи по сессиям, пока собран вручную — отдельной команды Datarim для такой оркестрации ещё нет, она в разработке. Когда у нижнего терминала возникает вопрос, ответ приходит от старшего оркестратора, а не от человека.

Так на базе Datarim заработала автономность разработки. И вместе с ней всплыли две вещи. Первая приятная: задач за час и за день стало решаться кратно больше — конвейер тащит их от backlog до архива почти без участия человека. Вторая заставила задуматься: нагрузка на инфраструктуру выросла многократно. Каждая итерация, каждый шаг конвейера ощутимо грузит сервер, а шагов теперь идёт в несколько потоков сразу.

Тут возникло подозрение, что вся прежняя планировка инфраструктуры неверна. Думать надо не «как сэкономить на серверах», а «где всё это окажется через три месяца и какая инфраструктура нужна под такой темп». Ни одной коммерческой продажи на текущий момент нет, продукты пока создаются. Но нагрузку создают уже не пользователи, а сами агенты, которые их строят. Значит, об инфраструктуре нужно думать уже сейчас.

Контекст и второй повод: цены и стартовая точка

Инфраструктура к моменту реорганизации — четыре выделенных сервера в Hetzner Robot (Хельсинки) и пятнадцать облачных VM. Суммарные расходы около €332 в месяц, или €3 987 в год.

Вторым поводом пересмотреть железо стало письмо от Hetzner: облачные цены поднимались на 30–37% с 1 апреля 2026 года, следующее повышение намечалось на 15 июня. Причина структурная — дефицит оперативной памяти и NVMe на фоне спроса со стороны AI-индустрии. Письмо не разовое: повышения будут повторяться. При детальном разборе вышло иначе, чем подсказывала интуиция: основная статья расходов — не облачные VM, а выделенные серверы. На них уходила бóльшая часть бюджета — там же был и запас, который стоило пересмотреть в первую очередь.

Момент для реорганизации выбран сознательно — до появления платящих пользователей. Перекладывать серверы, менять архитектуру и переносить данные под живой нагрузкой на порядок сложнее и рискованнее. Пока система маленькая, переезд дешевле и безопаснее.

Что вскрыл аудит серверов

Прежде чем покупать новое, разумно разобраться, что происходит со старым. 3 июня 2026 года агенты провели полное расследование: подключились по API-ключам и SSH ко всем четырём выделенным серверам и сняли замеры. Картина оказалась парадоксальной. Растущую нагрузку создавал в основном сервер разработки, где крутится автономный конвейер. А вот продакшен-машины, наоборот, простаивали.

Три из четырёх серверов (модель AX41-NVMe по €36,70 в месяц каждая) почти не работали. Загрузка процессора держалась на единицах процентов, оперативная память — тоже почти свободна. Серверы ждали не нагрузки, а того, что на них когда-нибудь что-нибудь положат.

Четвёртый сервер, занятый продакшеном, выглядел иначе: диск был почти полон. Первая мысль — данные разрослись. Но это не сходилось: сервисы на этой машине столько данных не порождают. Разобрались — место занимал не результат работы, а Docker build-cache и старые образы, технический мусор, накопившийся при сборках. Дальше просто: docker prune освободил диск, ни один рабочий процесс при этом не пострадал.

Сами базы данных оказались скромными — все вместе уместились бы на одной флешке. Картина аудита: три сервера простаивают, четвёртый был забит кэшем, а реальных данных — мало. Недоиспользование массовое. Удобный момент для реорганизации: расти есть куда, но сначала нужно навести порядок.

Hetzner Server Auction: механизм, ценообразование и скрытые ловушки

Hetzner Server Auction — это рынок «refurbished» серверов: машины, которые вернулись после аренды или были сняты с других задач. Оплата помесячная, без минимального срока, setup — €0. Цена динамическая: снижается по таймеру (поле next_reduce), можно ждать выгодного момента.

Для анализа доступен живой список серверов в формате JSON, который на момент исследования содержал 217 машин. Данные содержат всю необходимую информацию: процессоры, память, диски, наличие контроля памяти (ECC), локацию и текущую цену. Этого хватает, чтобы отобрать подходящие варианты автоматически — не разглядывая веб-страницы вручную.

Но цена в этом списке оказалась ловушкой. Она систематически занижает реальную стоимость. Один и тот же сервер — i9-13900, 3,84 ТБ ECC — в локации FSN1 показывался за €87,70, а в HEL1 за €125,70. При переходе к оформлению заказа цена вырастала. Разница между «витриной» и реальным чеком — до €38 в месяц за идентичное железо, просто из-за локации. Ошибка в выборе точки размещения может стоить сотни евро в год, если довериться только цене из списка.

Ещё одно: фильтр по объёму диска. Если выбираете большие объёмы, обязательно смотрите, какого типа этот диск. Диапазон вроде «3–16 ТБ» вытаскивает в основном машины с обычными жёсткими дисками (HDD) — дешёвыми, но медленными. Для баз данных, где важна скорость доступа, они не годятся: нужны быстрые NVMe-диски, а не терабайты медленного пространства. Большой объём сам по себе ничего не говорит о пригодности — тип диска важнее размера.

Покупка: два сервера i9-9900K, 128 ГБ RAM, 2 ТБ NVMe

После анализа выбор пал на два сервера одинаковой конфигурации: Intel Core i9-9900K, 128 ГБ оперативной памяти, 2 ТБ NVMe-диска.

Первый сервер — приложенческий, в локации HEL1, рядом с продакшеном. Цена около €97 в месяц. Его задача — разгрузить текущую инфраструктуру: принять на себя AI-сервисы (бэкенд совещаний агентов, распознавание речи) и новые модули, которые появятся в ближайшее время.

Второй сервер — для баз данных, в локации FSN1, около €84 в месяц. Под изоляцией хранилищ: Postgres, Mongo, ClickHouse. Изоляция не только логическая, но и физическая — разные продукты разведены по разным серверам, чтобы их данные не пересекались.

Почему выбор пал на 128 ГБ RAM, а не на диске большего объёма, например 3,84 ТБ? Ответ лежит в данных аудита: базы крошечные, им не нужно много места. Им нужна оперативная память — чтобы рабочие наборы данных целиком помещались в RAM, а не упирались в дисковые операции. 128 ГБ — это запас на рост ×2–3 без потери производительности. Диск в 2 ТБ NVMe — быстрый и достаточный для нынешних объёмов.

Экономика: доплата за будущий масштаб, а не экономия

Честный расклад выглядит не как урезание расходов, а как дополнительное вложение.

Гашение семи облачных VM экономит €48,93 в месяц. Но два новых сервера стоят €180,94 в месяц. Чистый прирост — €132 в месяц. Реорганизация не удешевляет инфраструктуру, а удорожает.

Зачем платить больше до первой продажи? Причин две.

Первая — фиксация цены. Выделенные серверы, купленные через аукцион, закрепляют стоимость на момент заказа. Она не растёт вслед за облачными тарифами, а те уже поднялись на 30–37% и поднимутся снова. Через год текущие €464 могут оказаться дешевле облачной альтернативы с новыми наценками.

Вторая — закладка масштаба. Переезд на железо с запасом проходит, пока система маленькая, а сам переезд дешёвый и обратимый. Под нагрузкой с платящими пользователями переносить базы и сервисы кратно сложнее, дороже и рискованнее.

Реорганизация — вложение в архитектуру под рост в два-три раза, а не экономия на текущих расходах.

От «инфраструктуры как кода» к «инфраструктуре как сервису агента»

Этот кейс не просто про замену серверов. Он иллюстрирует сдвиг в том, как современные AI-агенты могут управлять инфраструктурой.

Старая парадигма — «инфраструктура как код» — предполагает декларативное описание ресурсов: человек заранее пишет конфигурацию (например, в Terraform), где перечислено, что создать, а система это исполняет. Агент здесь — исполнитель готового плана.

Новая парадигма — «инфраструктура как сервис агента» — меняет роли. Агент не исполняет чужой план, а сам строит экономически оптимальный план под задачу. Через SSH-доступ и ключи он подключается к живым системам и снимает метрики. В этом кейсе так и вышло: список аукциона на 217 серверов отфильтрован под критерии; расхождение цены витрины с ценой в корзине поймано; разница между обычными и быстрыми дисками учтена; реальные размеры баз замерены, чтобы обосновать выбор памяти вместо лишнего диска; экономика пересчитана. Не исполнение готового плана, а сам план.

Финальное действие контролирует человек. Покупку совершает он — платит своей картой; доступ к секретам тоже остаётся за ним. Агент доводит анализ до точки решения, показывает расклад, аргументирует выбор. Человек подтверждает или отклоняет.

Это и есть новый уровень: IaaS 2.0, где агент не только создаёт и удаляет машины, но и подбирает оптимальное решение по цене под бизнес-задачу. Инфраструктура перестаёт быть кодом и становится сервисом агента.

И здесь история замыкается. Вопрос о новом железе поставила автономность агентов — это их работа нагрузила серверы так, что прежняя архитектура перестала годиться. А подобрал ответ на этот вопрос — тоже агент: снял живые данные, поймал ловушки аукциона, замерил реальные нагрузки, посчитал экономику до точки решения. Агенты, которые строят продукты, упёрлись в железо — и агент же нашёл, какое железо нужно. Человеку осталось подтвердить покупку и держать ключи от секретов. Пока этого достаточно.

Сам бы с удовольствием пользовался сервисом, который вот так подбирает оборудование под конкретную задачу — снимает реальные метрики, считает экономику и доводит до точки решения. Если у вас есть идея, как сделать такой сервис удобным, расскажите — обсудим в Telegram-канале.