Как один AI-агент закрывает работу целого отдела — без фреймворков и векторных баз

Большинство AI-проектов превращаются в слоёный пирог из зависимостей. Агентские фреймворки, графы вызовов, хранилища эмбеддингов, оркестраторы. Каждый новый слой обещает решить проблему предыдущего и добавляет свою. Но есть подход, который выкидывает всё лишнее и строит агента из трёх базовых элементов.

Откуда растут ноги

В enterprise-разработке есть закономерность: чем сложнее обвязка вокруг инструмента, тем больше времени уходит на поддержку самой обвязки, а не на полезную работу. Фреймворки для AI-агентов попали в ту же ловушку. LangChain, CrewAI, AutoGen — каждый тянет за собой десятки абстракций, которые ломаются при обновлении и усложняют отладку.

Автор этого подхода пошёл другим путём. Вместо того чтобы наращивать слои, убрал всё до костей. Получившийся подход получил название паттерн Джарвис — по аналогии с ассистентом из «Железного Человека». Старк не собирал совещание из десяти AI. Он говорил одному помощнику «разберись» — и тот разбирался.

Три кирпича, из которых собран агент

Идея укладывается в одно предложение. Берём языковую модель, даём ей терминал и организуем файловое хранилище знаний.

Модель отвечает за мышление: анализирует задачу, выбирает способ решения, интерпретирует результаты.

Терминал даёт возможность действовать: запускать команды, обращаться к сервисам, писать и выполнять код. Файловая память хранит контекст: что за проект, какие сервисы развёрнуты, что пробовали раньше и чем закончилось.

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

Терминал как универсальный набор инструментов

Здесь срабатывает неочевидная вещь: принципы Unix, заложенные полвека назад, идеально ложатся на работу с языковыми моделями.

Философия простая: атомарные программы, каждая заточена под одну операцию, связываются между собой текстовыми потоками. Языковая модель работает с текстом по определению, поэтому вписывается в эту схему органично. Отправить запрос к серверу — curl. Разобрать структурированный ответ — jq. Найти нужную строку в конфиге — grep. Когда подходящей программы нет, агент пишет свою и сохраняет для повторного использования.

Самое интересное здесь: инструментарий не ограничен заданным набором. Встретил незнакомый сервис — сделал скрипт-обёртку за минуту. Обнаружил рутинную операцию — превратил в однострочник. Со временем агент обрастает собственной коллекцией утилит, которая отражает именно те задачи, с которыми сталкивается конкретная команда.

Зачем файлы, когда есть векторные базы

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

Альтернатива банальнее и надёжнее. Директории играют роль рубрик. Названия документов служат навигацией. В корне лежит карта: что где искать. Агент открывает карту, идёт по нужной ветке и достаёт именно тот файл, который относится к задаче. Принцип тот же, что у опытного сотрудника: он не перечитывает всю wiki, а знает, где лежит нужный раздел.

Сейчас система покрывает несколько сотен документов по всей инфраструктуре, и узких мест пока не видно. Когда объём вырастет на порядок, вероятно, придётся добавить что-то сверху, но пока запас есть.

Память агента устроена как человеческая

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

Фактическая — конкретные данные. Адреса серверов, пути к секретам в хранилище, параметры подключения. Файлы с ключевой информацией, к которым агент обращается при необходимости.

Инструкционная — последовательности действий. Как развернуть новый сервис: проверить конфигурацию, собрать контейнер, прогнать проверки, выкатить. Runbook-и и чеклисты.

Опытная — история проб и ошибок. «Пытался настроить через подход X, упёрся в ограничение Y, обошёл через Z.» Этот тип памяти самый ценный, потому что такой информации нет ни в документации, ни в API.

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

Какие задачи это закрывает прямо сейчас

Это не лабораторный эксперимент. Агент, построенный по этому паттерну, каждый день работает в боевом окружении:

• Контроль доступов: настройка RBAC-политик в кластерах Kubernetes, работа с секретами через HashiCorp Vault, автоматическая смена ключей и токенов. Задачи, на которые инженер тратит полдня, закрываются за считанные минуты.
• Подъём инфраструктуры: запуск контейнерных сред в Proxmox, конфигурация Kubernetes-кластеров с нуля. Правила сетевого взаимодействия, входящий трафик, распределение нагрузки — агент учитывает текущее состояние окружения и существующие связи между компонентами.
• Проверка безопасности: анализ контейнерных образов инструментами вроде Trivy и Grype, ревизия конфигурационных файлов, генерация структурированных отчётов с ранжированием найденных проблем по критичности.
• Сборка и доставка кода: выстраивание цепочек сборки, подключение репозиториев, организация автоматического выкатывания с встроенными проверками на уязвимости.

Примечательно, что всё перечисленное работает на модели среднего ценового сегмента. Claude Sonnet, не флагманский Opus. С учётом того, что каждое следующее поколение языковых моделей приходит заметно сильнее предыдущего, потенциал агента на такой архитектуре будет расти сам по себе.

Что меняется в индустрии

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

Переоценка навыков. Помнить наизусть пятьдесят команд kubectl перестаёт быть конкурентным преимуществом. Агент справится с этим быстрее. Растёт спрос на тех, кто понимает зачем: видит систему целиком, умеет декомпозировать проблему и оценить результат. Инженерия возвращается к первоначальному смыслу.

Софт без программного интерфейса теряет рынок. С появлением агента подход к выбору инструментов переворачивается. Вопрос не «насколько удобен UI», а «смогу ли я это заскриптовать». Завести пачку задач в трекере, обновить настройки на десяти серверах, собрать сводку за квартал — через API это секунды. Продукт, в котором всё только мышкой, вылетает из обоймы.

Текучка снижается сама собой. Неожиданный бонус для работодателя. Полгода рядом с агентом — и в его памяти лежит карта всех проектов, типичных граблей, успешных решений. Это персональная база знаний, привязанная к рабочему месту. Уволиться означает бросить всё и собирать заново. Такой якорь работает надёжнее, чем корпоративы и ДМС.

Не только одна команда пришла к таким выводам

Похожие мысли всплывают в индустрии параллельно. Публикация Холмса про смерть MCP и возврат к CLI-инструментам взлетела на первую страницу Hacker News. Его аргумент прост: зачем городить специальные протоколы, если модель и так справляется со стандартными утилитами. Юрье из европейского сообщества выпустил материал с тезисом «агент — это операционная система», развив ту же логику независимо. Люди из разных компаний и стран, без координации между собой, формулируют общий вывод: абстракции поверх ОС — артефакт ранней стадии, а не долгосрочное решение.

Применимость выходит далеко за пределы DevOps

Паттерн проверен на DevSecOps-задачах, но сфера применения шире:

• DevOps / SRE — наблюдение за системами, выкатка релизов, конфигурация серверной части, реагирование на сбои
• Системный администратор — обслуживание серверного парка, резервное копирование, накатывание патчей, поиск неисправностей
• Security-инженер — ревизия настроек безопасности, поиск уязвимых мест, регулярная замена секретов
• Data-инженер — построение конвейеров обработки данных, перенос между хранилищами, контроль целостности
• Технический писатель — автоматическое создание документации на основе кода, актуализация операционных инструкций
• Контент-менеджер — размещение материалов, работа с поисковой оптимизацией, распространение по площадкам, сбор статистики
• Бизнес-аналитик — формализация требований, работа с показателями эффективности, создание презентаций для руководства, описание процессов
• Системный аналитик — проработка схем интеграции, документирование программных интерфейсов, исследование потоков данных, написание технических заданий

Привязки к одному вендору нет. Подход проверен с продуктами Anthropic и OpenAI, вдобавок z. ai демонстрирует обнадёживающие показатели. Единственное техническое условие: поддержка вызова инструментов и контекстное окно, достаточное для полноценной рабочей сессии.

Запускается двумя способами:

Локально — открыл терминал, запустил на своей машине, ведёшь диалог напрямую. Настройка минимальна, всё под контролем.

Удалённо — агент живёт на отдельном сервере и доступен через Telegram-бота или REST-эндпоинт. Функционирует круглосуточно: реагирует на алерты, мониторит входящие, контролирует пайплайны. По сути, это напарник, который никогда не уходит офлайн.

Агент усиливает, а не заменяет

Никаких иллюзий про самостоятельный разум, работающий без людей. Последнее слово, зона ответственности, стратегия — всё остаётся за человеком. Агент забирает исполнительскую часть: рутинные операции, сбор информации, механическую работу.

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