AgenticOps, часть №3 - платформа

Общие принципы
● агенты общаются с платформой через CLI + SKILL.md
● CLI-команды - плоские и максимально простые
● топология ресурсов приложения инкапсулирована в платформе
● даём агенту высокоуровневые инструменты, но стараемся избегать дырявых абстракций
● у агента могут быть как платформенные тулы, так и специфичные для его локального контекста
● почти всё типизировано, компилируется и тестируется (TypeScript + Deno) - детерминизм!

Части платформы

Адаптеры к базовым компонентам
TypeScript-обёртки вокруг API/CLI тех компонентов, которые были перечислены в посте №2 - отсюда и происходит требование к каждому компоненту иметь такие интерфейсы.

К примеру, для redis-cli, RabbitMQ HTTP API, для pg_dump - для всех них созданы обёртки в едином стиле.
Адаптеры знают, как общаться с компонентами инфраструктуры, ловят ошибки и работают с секретами.

И только адаптеры делают сырые вызовы к инфраструктурным компонентам и что-то от них парсят.

Дескриптор приложения
У платформы есть машиночитаемое описание приложения: дескриптор со списком ресурсов, и она знает, где что хостится, какие базовые компоненты нужны приложению и какие возможности они предоставляют.

Это позволяет агенту, к примеру, при дебаге не искать самому, где какой сервер, как к нему подключиться, а где у нас вообще логи, а что это за формат, а почему их тут 10 гигов, ааа..., а вместо этого:
● вызвать CLI-команду вида "дай логи с вот такими фильтрами"
● команда под капотом идёт к платформе
● платформа уже знает все места с логами для этого приложения
● платформа через адаптеры базовых компонентов сходит либо в файлы, либо в Loki, либо ещё куда, чтобы собрать логи
● логи агрегируются, чистятся и возвращаются агенту с пейджингом, удобным форматированием и указанием источника

Оркестрация
Тут живут и исполняются типовые сценарии и их шаблоны, такие как deploy, verify, diagnose и т.п.

К примеру, примерно так устроен шаблон для deploy:
● получаем сведения о конкретном приложении из дескриптора
● определяем, какие компоненты участвуют в deploy для этого приложения
● проверяем, живы ли они все
● получаем тег и/или версию из гита в качестве deploy tag
● проверяем, готов ли у нас билд и артефакты с нужным тегом, чтобы было из чего деплоить
● запускаем конкретный workflow деплоя (который определен в самом приложении, тут мы его деталей не должны знать)
● мониторим, как идёт, периодически рапортуем прогресс для агента-деплоера
● проверяем теги/версии на задеплоенных частях системы
● возвращаем итоговый отчёт агенту

Лирическое отступление
Казалось бы, можно просто обписать базовые компоненты адаптерами и накинуть сверху CLI + скиллы для агента.
И это вполне рабочий подход, когда приложений мало, их Ops не требует унификации и некоторое дублирование допустимо.
Но в моём случае (да и вообще в случае принятия платформенного подхода) - это именно то, от чего и хочется уйти :)

Преимущества тут такие:
● повторяемые процессы (или их части) отдаём платформе, чтобы агент делал меньше шагов, "ручных" действий и не загрязнял контекст лишними деталями
● можно менять топологию, расположение, и даже иногда сами базовые компоненты чисто на уровне самой платформы без необходимости менять инструкции для агентов-разработчиков
● безопасность - можно настроить набор тулов для конкретного агента, и ограничить его работу только с ресурсами, которые принадлежат его приложению - это тоже форсится платформой

CLI + SKILL.md для агентов
Агент пользуется плоским набором CLI-команд, главные из которых описаны в скилле.

Но при старте CLI сам делает discovery тех команд, которые доступны агенту.
Есть команды, специфичные для конкретного приложения, которые подгружаются динамически + платформа может включать/выключать некоторые команды.

Команды есть сценарные: deploy, verify, diagnose, а есть и для отдельных инструментов, типа redis flush namespace, s3 list.
Для каждой команды CLI может выдать хелп, который агент на ходу может изучить, а в некоторых ещё и follow up commands возвращает, давая подсказки, что ещё можно попробовать.

#ai #agentic_ops #devops