"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"