В первой статье я рассказал, как поднял Hermes Agent с нуля на своём сервере. Четыре часа на установку, Telegram-бот, Caddy, Firecrawl, gbrain, отдельный профиль copywriter — всё встало.
Что меняется после установки#
Поставить агента — это только начало. Польза появляется, когда он проходит весь цикл: понял задачу, нашёл контекст, изменил файлы, запустил проверки, увидел ошибку, исправил и показал доказательство.
Для бизнеса это ближе к инженерному исполнителю, чем к справочнику. Но такой исполнитель должен работать в рамках: с логами, ограничениями, понятным доступом и обязательной проверкой результата.
Теперь давайте поговорим о том, что происходит после. Потому что настоящая ценность агента проявляется не тогда, когда ты ему говоришь «напиши красиво». А когда даёшь ему чёткую инженерную задачу, доступ к живому контуру, инструменты и жёсткие границы.
Я дал Hermes доступ к приватному GitHub-репозиторию с ops/CI/CD одного клиентского SaaS-проекта. Задача была конкретная: оптимизировать бэкенд под нагрузку, провести нагрузочные тесты через k6, подтвердить p95 и долю ошибок, починить всё, что мешает, и оставить доказательства.
Вот как это выглядело на практике.
Агент — не планировщик, а исполнитель#
Первое, что я заметил: пока у агента нет доступа к реальному серверу и репозиторию, он пишет красивые планы. Как только появляются SSH, gh CLI, compose-файлы и проверки состояния в живом контуре — поведение меняется кардинально.
Hermes начал с того, что принял приглашение в приватный репозиторий через gh CLI, проверил права, склонировал код. Потом сравнил то, что лежит в репозитории, с тем, что реально крутится на сервере: compose, Caddy-конфиг, метки контейнеров, ревизию и точки проверки состояния.
Вывод номер один: без доступа к живому контуру агент будет рассказывать уверенные сказки. С доступом — начинает работать как нормальный инфраструктурный инженер: смотрит реальность, а не только README.
Доступы — это не «дай всё навсегда»#
Очень важный момент, который я теперь записал в gbrain как правило.
Агенту нельзя давать секреты в чат. Ни ключи, ни токены, ни пароли. Нужно давать путь к ключу или ссылку на хранилище, а не сам секрет. В одном моменте агент попросил «сохранить ключик» — я его поправил: «дай путь, а не сам ключ». Это теперь железное правило.
GitHub-доступ, SSH-ключи, токены и серверные учётки — всё выдаётся временно под задачу. После завершения этапа — ротация. Это не паранойя. Это нормальная гигиена после того, как агент интенсивно коммитит, деплоит и смотрит метрики.
Как выглядела реальная работа#
Процесс был такой:
- Агент зашёл в приватный ops-репозиторий.
- Сравнил состояние сервера и кода.
- Начал делать изменения в бэкенде: нашёл место, где tenant context setup происходил по одному запросу, перевёл на batching и кэширование горячих read-path'ов.
- Коммитил, пушил, следил за GitHub Actions.
- После деплоя проверял revision label, health-check, docker stats, pg activity.
- Запускал k6-тесты через публичный Caddy-контур. Важно: не в обход reverse proxy — тест должен идти тем же путём, что и реальный трафик.
- Смотрел k6 summary, Grafana, Influx.
Одним из первых ограничений оказался лимит Caddy на один IP. Один k6-runner выглядел как один клиент — ограничение срабатывало раньше, чем бэкенд показывал свою настоящую ёмкость. Агент это увидел, перекалибровал лимиты под ожидаемую нагрузку и проверил их повторным полным прогоном. Итоговые значения стали постоянной конфигурацией, а не временным обходом для теста.
В итоге API-путь уложился в требуемый p95, а доля ошибок осталась нулевой. Финальные прогоны подтвердили SLO. Сырые k6-отчёты и доказательства остались в приватном ops-репозитории.
Где агент ошибся (и это нормально)#
Была одна серьёзная ошибка.
Агент самостоятельно поднял Grafana + Influx на клиентском сервере, хотя я этого явно не просил. Просто «чтобы было удобно смотреть». Я отреагировал резко: наблюдаемость и демо-инфраструктура по умолчанию живут в лабораторной или собственной среде. Размещать их на клиентском сервере можно только если это заранее явно согласовано с клиентом и входит в согласованный объём работ.
Агент быстро исправился: удалил публичный маршрут и вспомогательные контейнеры с клиентского сервера, запушил исправляющий коммит в ops-репо и записал правило в gbrain.
Вывод номер два: границы полномочий важнее скорости. У меня с клиентом эти границы тоже выставлены: «можно трогать сервер» — не значит «можно разворачивать на нём любую вспомогательную инфраструктуру». По умолчанию графики и сбор метрик для нагрузочных тестов живут в своей среде; клиентский сервер — только если это отдельно согласовано.
Среда выполнения самого агента — тоже инфраструктура#
Ещё один момент, который легко упустить.
Hermes работает в собственной среде выполнения: на сервере агента остаются фоновые процессы, worktrees, логи, туннели, уведомления о завершении команд. Нельзя в процессе работы сломать этот контур.
Долгие задачи — нагрузочные тесты, большие миграции, сканирование — нужно запускать через background=true + notify_on_complete=true. И всегда проверять результат не по чату, а по живым артефактам: health, revision label, метрики, diff после деплоя.
Практический чек-лист: как давать задачу агенту-инженеру#
Если хочешь, чтобы агент реально работал, а не просто красиво планировал, проверь перед стартом:
- Чёткая измеримая цель (SLO, метрики, health, revision).
- Доступ к GitHub-репозиторию (временный WRITE).
- SSH к целевому серверу (с путём к ключу, а не самим ключом).
- Доступ к живому контуру (compose, Caddy, docker stats, health endpoints).
- Отдельный контур для графиков и вспомогательной инфраструктуры нагрузочных тестов; клиентский сервер — только по отдельному согласованию.
- gbrain с правилами и уроками предыдущих этапов.
- Критерии приёмки: что именно считается «сделано».
- План ротации доступов после завершения этапа.
Без этого получается «ещё один умный чат-бот». С этим — инженерный исполнитель, который коммитит, деплоит, тестирует и исправляет ошибки.
Итог#
Hermes Agent не заменил меня как инженера. Он стал хорошим исполнительным инженером, когда я дал ему рамку, критерии успеха, временные полномочия и возможность видеть реальный контур, а не только код из репозитория.
API-путь оптимизирован и подтверждён нагрузочными тестами. Ошибка с клиентской наблюдаемостью исправлена и зафиксирована как урок. Отдельный Pi/printer delivery path остаётся следующей задачей — текущие тесты его не покрывали.
Если вы хотите допустить AI-агента к реальным DevOps-задачам, деплою, тестам или внутренним инструментам, начинать нужно с рамок и проверки, а не с полного доступа. Напишите мне в Telegram или на почту — помогу разобрать, где агент может безопасно ускорить работу, какие права ему давать и как проверять результат до продакшена.
