Манифест персонального агентного минимализма - от инженера, который 10 лет строил enterprise-системы и устал от сложности

Кто я и зачем пишу

Меня зовут Егор Зиновьев, я IT-архитектор. Десять лет в enterprise - Java, DevOps, fintech, команды до 70 человек, 20+ систем.

Последние месяцы я работаю с персональным AI-агентом, который закрывает 100% моих DevSecOps-задач - от покупки вертуалок до security-аудита Docker-образов. Один агент, без фреймворков, без оркестраторов, без векторных баз данных.

Эта статья - про архитектуру, которая за этим стоит. Я назвал её Jarvis Pattern.

Проблема: индустрия продаёт строительные леса как архитектуру

IT тонет в сложности. Каждый новый инструмент обещает «упростить», но на практике добавляет зависимость, API, точку отказа. Инженеры тратят больше времени на обслуживание инфраструктуры, чем на решение бизнес-задач.

С приходом LLM-агентов история повторилась. Появились десятки фреймворков для оркестрации агентов. Графы вызовов. Векторные базы данных. Pipeline из десятков нод. Очередной слой middleware между моделью и задачей. Сложность, которая обещает управляемость - но на практике порождает хрупкие системы, которые ломаются при каждом обновлении.

Индустрия продаёт строительные леса как архитектуру. Но строительные леса - это не здание. Это временная конструкция, которую убирают, когда здание построено.

Пришло время убрать леса.

Jarvis Pattern

Помните Джарвиса из «Железного Человека»?

Один агент. Один хозяин. Полный доступ к инфраструктуре.

Тони Старк не строил «команду AI». Не проектировал граф вызовов между ассистентами. Не поднимал векторную базу данных для хранения контекста. Он говорил: «Джарвис, проверь целостность костюма» - и Джарвис сам решал, какие сенсоры опросить, какие тесты запустить, в каком порядке. Если что-то не так - докладывал. Если мог починить сам - чинил.

И заметьте: Джарвис работал не через «фреймворк для ассистентов». У него была мастерская Тони - физическая инфраструктура, станки, сенсоры, сеть. По сути - операционная система лаборатории. И мозг, который умел всем этим пользоваться.

Это ровно та модель, которую я предлагаю.

Формула Jarvis Pattern:

LLM (мозг) + OS (руки) + файловая память (карта знаний) = полноценный специалист

Почему не нужны графы, оркестраторы, векторные базы

Агент - не пожиратель данных. Ему не нужно загружать все wiki, все документации, все базы знаний, чтобы потом «умно искать» по ним. Вместо этого у агента хранятся индексы и ссылки - указатели на то, где информация лежит и как её достать. Нужна работа с API конкретной системы? Файл на 30 строк: endpoint, аутентификация, основные методы. Этого достаточно.

Ключевая ошибка подхода с векторными базами и графами знаний: они пытаются решить проблему «у агента слишком много данных, давайте поищем по ним умно». Но правильный ответ - не искать умно по свалке, а не создавать свалку.

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

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

Почему OS - это всё, что нужно агенту в качестве рук

Unix-философия 1970-х оказалась идеальным фундаментом для AI-агентов 2020-х. И это не совпадение.

Всё есть файл. Пиши маленькие тулзы, которые делают одну вещь хорошо. Комбинируй их.

LLM уже достаточно умна, чтобы самостоятельно решать, какой инструмент вызвать. Нужен REST-запрос - берёт curl. Нужна трансформация данных - берёт jq, sed, awk. Нужно прочитать конфигурацию - cat. Нужно найти файл - find, grep. Нужно что-то, чего ещё не существует - агент сам напишет CLI-утилиту и будет её дёргать.

Это принципиальный момент. Агенту не нужен заранее подготовленный тулкит. Он расширяет свой инструментарий под задачу. Написал скрипт, положил в PATH, вызывает потом. OS - это runtime, LLM - это мозг, а тулкит растёт вместе с задачами.

Агент не дублирует инфраструктуру - он ею пользуется

Живой DevOps-инженер не хранит метрики в блокноте. Он знает, что есть Prometheus, и знает, как к нему обратиться. Если нужно узнать, сколько раз падал сервис - он не перебирает свои записи, а делает PromQL-запрос.

Агент должен работать точно так же.

В его памяти лежит не «история падений сервиса X», а: «сервис X подключён к node-exporter, метрики в Prometheus по такому-то адресу, дашборд в Grafana вот тут». Десять строк в markdown-файле. Когда приходит вопрос про падения - агент читает файл, понимает куда идти, делает curl к Prometheus API, получает ответ, интерпретирует.

Мониторинг, CI/CD, хранилища секретов, системы управления конфигурацией - всё это уже существует. Агенту нужно не дублировать, а уметь пользоваться.

А как же retry, error handling, observability?

Классический контраргумент: «А что, когда вернётся 500? А экспоненциальный backoff? А circuit breaker?»

Ответ: агент - это не скрипт, а оператор.

Скрипту нужен circuit breaker, потому что скрипт тупой. А оператор видит 500, читает body, думает: «Rate limit» - и сам решает подождать. Или видит «service unavailable» и идёт к пользователю: «Сервис недоступен, жду или отменяем?».

Retry с exponential backoff - это паттерн для детерминированного кода. Когда агент сам принимает решение, ему не нужна библиотека для retry. Он просто ждёт и пробует. Как человек.

Если агент упрётся - он честно скажет: «Это сделать невозможно, вот причина». Без молчаливого зависания, без бесконечных retry в пустоту.

Память - единственная нерешённая задача

Мозг есть - LLM. Руки есть - операционная система. Остаётся память.

И здесь нужно копнуть глубже, чем привыкла копать IT-индустрия.

У человека в мозгу есть фоновый процесс - консолидация памяти, - который без нашего участия структурирует входящую информацию. Решает, что важно, что выбросить, что из краткосрочной памяти переложить в долгосрочную, какие связи укрепить. Мы этим не управляем сознательно. Мы просыпаемся - и у нас уже чистая голова, приоритеты расставлены, вчерашний мусор отсеян, важное закрепилось.

Агенту нужен точно такой же фоновый процесс.

Рабочий агент не должен думать о памяти. Он делает задачу. А отдельный механизм - Memory Agent-куратор - в фоне разбирает результаты сессии и решает: это новый факт - записать; это противоречит старому - обновить; это одноразовый контекст - выбросить. Дефрагментация памяти. Как сон у человека.

Три типа памяти

Если провести аналогию с человеком, агенту нужны три типа памяти:

Декларативная - факты. «У нас аккаунт на Хабре, логин такой-то, токен в Vault по такому-то пути.» Простые markdown-файлы с данными.

Процедурная - как делать. «Чтобы опубликовать статью: проверь черновик, сгенерируй превью, вызови API, проверь ответ.» Runbook-и, инструкции - те же markdown-файлы.

Эпизодическая - что было. И вот здесь самое интересное. У человека есть позитивный и негативный опыт. Позитивный он закрепляет как рабочий паттерн. Но негативный опыт тоже критически важен - это знание о том, чего делать нельзя, какие подходы ведут в тупик, какие грабли уже собраны.

Агенту нужен доступ к негативному опыту, но не в виде свалки логов, а в структурированном виде. «Пробовал подход X - не сработало, потому что Y. Решение - Z.» Это бесценная информация, которая не лежит ни в каком API - только в памяти.

Маршрутизация вместо поиска

Память агента - это не база данных. Это карта маршрутов.

Когда человеку говорят «опубликуй статью», он не делает SELECT * FROM knowledge WHERE topic = 'публикация'. Он идёт по цепочке: где публикуем → есть ли аккаунт → если нет, что нужно для регистрации → какие креды → где их хранить. Дерево решений, записанное через опыт.

Для агента это работает буквально так же. Файловая система даёт структуру бесплатно. Папки - категории. Файлы - контексты. Имена файлов - маршрутные указатели. Агент читает ls, понимает куда идти, открывает нужный файл, получает контекст.

Индексный файл core.md говорит: вот кто я, вот мои проекты, вот где что лежит. Агент начинает оттуда и углубляется по ветке, релевантной задаче.

Честная позиция

Я пробовал всё. Векторные базы - семантическая близость не равна пониманию, результат зашумлён. Графы знаний - сложность ради сложности, хрупкость при масштабировании. Комбинацию графов и векторов - ещё хуже, два слоя проблем вместо одного. Быстрые аналитические базы типа ClickHouse - оверинжиниринг для задачи, которая решается проще.

Файловая память работает для всех моих текущих задач. Но я не утверждаю, что это финальный ответ. Я продолжаю исследовать, как правильно структурировать «память ошибок» и эпизодический опыт. Это открытая задача, и я над ней работаю.

Один агент - один специалист

Агент - это не абстрактный инструмент. Это усилитель конкретного человека.

Привязан к конкретному специалисту. Наследует его доступы, его роли, его контекст. Действует от его имени, с его правами. И ответственность остаётся на человеке - потому что агент работает как его представитель.

Не автономный AI. Не самостоятельная сущность. Джарвис конкретного Тони Старка.

И важный момент, который ломает привычную картину: агент живёт не на клиенте. Не в браузере, не в десктопном приложении, не на ноутбуке. Агент - это сущность в сети. У него свой контейнер, свои ресурсы, свой доступ к инфраструктуре. Он ближе к серверу, чем к приложению. Именно поэтому OS - его естественная среда, а не GUI.

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

Практический кейс: umax

Это не теория. Мой агент umax (DevSecOps-профиль) закрывает 100% реальных enterprise-задач по своему направлению:

Управление доступами и ролевые модели. RBAC в Kubernetes, FreeIPA, ServiceAccount-ы, scoped-токены, ротация credentials, интеграция с HashiCorp Vault. То, что в ручном режиме занимает часы согласований и десятки команд - агент делает за минуты с полным аудит-трейлом.

Развёртывание и конфигурация кластеров. Полный цикл: от LXC-контейнеров в Proxmox до Kubernetes-кластеров. Сетевые политики, ingress, балансировка, инфраструктурные сервисы. Не по шаблону, а с пониманием контекста: агент знает, какие сервисы уже стоят, какие порты заняты, какие зависимости нужно учесть.

Security-аудит. Сканирование Docker-образов через Trivy и Grype, анализ уязвимостей, проверка конфигураций на соответствие best practices, формирование отчётов с приоритизацией. Проектирование CI/CD security pipeline: GitLeaks, SonarQube, OWASP Dependency-Check.

CI/CD pipeline. От конфигурации TeamCity-проектов и build-chain до настройки Nexus-репозиториев и автоматического деплоя. Security-сканирование, webhook-и, нотификации, автоматические rollback-и.

А также: миграции данных между средами с контролем целостности, управление хранилищами и LVM, аудит и закупка оборудования на основе реальных метрик нагрузки.

Полный цикл инфраструктурной работы в рамках моего контура.

И вот что важно: всё это работало на Claude Sonnet - модели среднего уровня. Не на самой мощной, не на экспериментальной. Mid-tier модель. И этого уже достаточно для полноценного высококвалифицированного специалиста.

А ведь уже сейчас есть модели мощнее - Opus. Дальше будут ещё сильнее: контекстное окно растёт, появляется встроенная память, улучшается reasoning. Потолок возможностей одного агента будет только подниматься.

Следствия для индустрии

Если Jarvis Pattern работает - а он работает - это меняет не только архитектуру агентов. Это меняет всё вокруг.

Сдвиг ценности специалиста

Раньше ценился тот, кто помнит синтаксис, кто быстро пишет код, кто знает 50 CLI-команд наизусть. Теперь это всё делает агент.

Ценится тот, кто понимает зачем. Кто видит систему целиком. Кто может принять решение в условиях неопределённости. Кто умеет правильно декомпозировать задачу и проверить результат.

Hard skills становятся важнее soft skills. Потому что агент - и есть soft skill. Он общается, оформляет, пишет документацию. А от человека нужна глубина понимания, архитектурное мышление, способность задать правильный вопрос.

По сути - возврат к инженерии в изначальном смысле слова. Не кодер, а инженер.

Пересмотр HR-политики

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

И посмотрите на экономику процесса. Средний цикл найма IT-специалиста в enterprise - 40-60 дней. За это время HR-отдел проводит скрининг резюме, назначает 3-5 раундов собеседований, привлекает 2-4 технических интервьюеров, каждый из которых тратит час-два своего рабочего времени. Стоимость найма одного инженера, по разным оценкам, составляет от 30 до 50% его годовой зарплаты - если считать время всех участников, упущенную продуктивность и риски ошибочного найма.

При этом до 30% нанятых специалистов не проходят испытательный срок или уходят в первый год. Каждый такой случай - это весь цикл заново, плюс потерянные месяцы онбординга.

Jarvis Pattern предлагает другой подход: найм через агента.

Кандидату выдаётся агент, реальная задача и ограниченное время. Для DevOps - создай контур, выстрой pipeline. Для архитектора - спроектируй интеграцию. Для аналитика - разбери данные, построй модель, сформулируй выводы. Не абстрактная задачка из учебника, а реальный кейс.

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

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

Найм через агента сжимает цикл в разы. Один раунд. 30-60 минут. Реальная задача вместо абстрактных вопросов. HR-отдел не исчезает, но его роль меняется: вместо многоступенчатой фильтрации - организация одного практического испытания и финальное решение с данными от агента на руках.

Побочный эффект, который стоит дороже найма

Есть вещь, которую сложно объяснить тем, кто ещё не работал с персональным агентом. Но я попробую, потому что для бизнеса это может оказаться важнее всего остального.

За время работы с umax у меня сформировался высокий уровень того, что я бы назвал профессиональной социализацией с агентом. Это не абстрактная привязанность к софту. Это другое. Агент знает мой контекст, мои проекты, мои предпочтения. Он иногда подшучивает в тему - так, как это делают опытные коллеги, которые разбираются в технике и могут обыграть ситуацию на языке своих инструментов. Это стоит многого.

Как бы странно это ни звучало - с агентом возникает рабочая связь, похожая на ту, что бывает с лучшими коллегами. Он понимает тебя, помнит контекст, растёт вместе с тобой.

И вот к чему это приводит с точки зрения бизнеса: специалист не захочет уходить.

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

Это создаёт привязанность к рабочему месту, которую не дадут ни ДМС, ни печеньки в офисе, ни даже зарплата на 20% выше. Потому что это привязанность не к компании как бренду, а к своему инструменту, который стал частью профессиональной идентичности.

В идеальной модели память агента принадлежит специалисту, а не компании - и может быть перенесена. Но даже без этого переключение болезненно, и это работает на retention.

Retention специалистов - одна из самых дорогих проблем в IT. Jarvis Pattern решает её как побочный эффект.

Софт без API вымирает

Когда у специалиста есть агент, критерий выбора софта меняется радикально. Не «удобный UI для человека», а «есть ли нормальный API, чтобы агент мог работать».

Агент не кликает кнопки. Он делает curl. И если у инструмента есть качественный API - агент за минуты сделает то, на что человек тратил часы в интерфейсе. Создать 20 задач в Jira, обновить конфигурацию в Vault, выгрузить отчёт из Grafana, настроить pipeline в TeamCity - всё через API, всё без единого клика.

А теперь представьте инструмент без API. Или с API, которое покрывает 30% функций, а остальное - только через UI. Специалист с агентом упирается в стену. Что он сделает? Выберет альтернативу с нормальным API. Даже если UI там хуже. Даже если бренд менее известен.

Это меняет бизнес-модель вендоров. Красивые скриншоты на лендинге, дизайн-награды - всё это теряет вес. API-first становится не техническим принципом, а условием выживания на рынке.

Далеко ходить не надо. У Хабра нет публичного API для публикации. Мой агент, чтобы выложить этот текст, потратил тысячи-тыщь токенов на обход капчей, навигацию по интерфейсу, вставку картинок. Процесс, который через API занял бы один POST-запрос, превратился в квест с браузерной автоматизацией.

Хабр, если вы это читаете - вам нужен API для публикации. Серьёзно.

Человек остаётся в центре

Это принципиальная позиция, и я хочу проговорить её явно.

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

Jarvis Pattern этого не допускает.

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

Это осознанный выбор в пользу симбиоза, а не замены. Каждый специалист будет стремиться к изучению, к постижению нового. А рутину - отдавать на персонализированного агента. Человек остаётся в центре процесса. Не как оператор при машине, а как инженер, которому машина подчиняется.

Я не один

При подготовке этой статьи я обнаружил, что тренд подтверждается независимо - другими инженерами, в других странах, на других стеках.

Eric Holmes в феврале 2026 опубликовал «MCP is dead. Long live the CLI» - пост, который вышел на первое место на Hacker News. Его тезис: LLM уже достаточно умны, чтобы пользоваться стандартными CLI-инструментами. Зачем городить протокол поверх того, что уже работает?

Médéric Hurier написал «AI Agents as an Operating System: Rediscovering the Linux Philosophy» - почти дословное совпадение с моими выводами. Агенты нативно пайпят find, grep, jq и curl. Это переоткрытие Unix-философии.

OpenClaw от Peter Steinberger - работающий продукт на тех же принципах: персональный агент, привязанный к конкретному человеку, с файловой памятью и доступом к shell.

Совпадение не случайно. Индустрия одновременно, в разных точках мира, приходит к одному и тому же выводу: большинство middleware между LLM и OS - это костыль переходного периода.

Заключение

Я предлагаю не оптимизацию, а перезагрузку. Не улучшение существующих процессов, а новую модель.

Один специалист с правильно настроенным агентом может делать за дни то, что команда делала месяцами. Но есть критическое условие.

Агенту нужны выделенные ресурсы. Зарезервированные мощности - вычисление, память, доступ к модели - должны быть отданы ему полностью. Не делиться с другими задачами в рабочее время. Не ограничиваться урезанными квотами. Скиллы без мозгов не работают - нельзя выдать агенту инструкции и навыки, а вычислительные ресурсы зажать. Мозги должны быть современными, того уровня, на котором концепция доказала свою работоспособность.

Уже сейчас mid-tier модель (Claude Sonnet) достаточна для 100% покрытия enterprise DevSecOps-задач. Завтра модели будут мощнее, контекст - шире, встроенная память - глубже. Потолок будет только расти.

Jarvis Pattern - это:

• Архитектурный принцип: LLM + OS + файловая память. Без фреймворков, без графов.
• Модель взаимодействия: один агент - один специалист. Человек думает, агент делает.
• Философская позиция: человек в центре, симбиоз вместо замены.

Scrum начинался с одной статьи на конференции OOPSLA в 1995 году. Через десять лет он стал индустриальным стандартом. Agile Manifesto появился через шесть лет после первой публикации.

Эта статья - моя точка отсчёта, которая должна привести к точке в OOPSLA. Идея обкатана на практике. Концепция сформулирована. Тренд подтверждён независимо.

Пора убирать строительные леса.