Jarvis Pattern: почему AI-агенту не нужен фреймворк, а нужна операционная система

Jarvis Pattern: почему AI-агенту не нужен фреймворк, а нужна операционная система

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

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

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

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

Эта статья — про архитектуру, лежащую в основе. Я назвал её Jarvis Pattern.

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

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

С приходом LLM-агентов история повторилась. Появились десятки фреймворков, графы вызовов, векторные базы, pipeline из десятков нод. Это — ещё один слой middleware между моделью и задачей.

Такие системы обещают управляемость, но на практике оказываются хрупкими и ломаются при каждом обновлении.

Индустрия продаёт строительные леса как архитектуру. Но леса — это временная конструкция. Пришло время их убрать.

Jarvis Pattern

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

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

Тони Старк не создавал «команду агентов», не проектировал графы вызовов и не вводил векторные базы. Он говорил: «Джарвис, проверь костюм» — и агент сам решал, какие сенсоры опросить, какие тесты запустить.

Если что-то шло не так — докладывал. Если мог — чинил.

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

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

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

Агенту не нужно поглощать все данные. Вместо этого он хранит индексы и ссылки — указатели на то, где лежит информация и как её получить.

Нужна работа с API? Достаточно файла на 30 строк: endpoint, аутентификация, основные методы.

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

При «загрузим всё» появляются костыли: чанкинг, эмбеддинги, top-k поиск. Это не работает, потому что семантическая близость — не то же самое, что понимание контекста.

Два похожих по эмбеддингам абзаца могут быть из разных контекстов. Результат — мусор.

Решение простое: не загружать всё, а дать карту. При моём масштабе — сотни файлов — этого хватает, чтобы покрыть любого DevOps-инженера.

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

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

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

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

Если нужного инструмента нет — агент сам напишет CLI-утилиту и добавит её в PATH.

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

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

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

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

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

Десять строк в markdown-файле. Когда приходит вопрос — агент читает файл, понимает, куда идти, делает curl к API, получает ответ, интерпретирует.

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

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

Классический контраргумент: «А если вернётся 500? А exponential backoff? А circuit breaker?»

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

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

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

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

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

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

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

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

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

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

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

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

  • Декларативная — факты. «У нас аккаунт на Хабре, логин такой-то, токен в Vault по такому-то пути». Простые markdown-файлы.
  • Процедурная — как делать. «Чтобы опубликовать статью: проверь черновик, сгенерируй превью, вызови API, проверь ответ». Runbook-и, инструкции — те же markdown-файлы.
  • Эпизодическая — что было. Здесь самое интересное. У человека есть позитивный и негативный опыт. Позитивный закрепляется как рабочий паттерн. Негативный — знание о том, чего делать нельзя.

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

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

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

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

Дерево решений, записанное через опыт.

Для агента — то же самое. Файловая система даёт структуру бесплатно. Папки — категории. Файлы — контексты. Имена файлов — маршрутные указатели.

Агент читает 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, анализ уязвимостей, проверка конфигураций, формирование отчётов. Проектирование 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. Потолок возможностей одного агента будет только подниматься.

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

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

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

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

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

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

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

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

Средний цикл найма IT-специалиста — 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 нет? Или покрывает 30% функций, а остальное — только через UI? Специалист с агентом упирается в стену.

Что он сделает? Выберет альтернативу с нормальным API. Даже если UI хуже. Даже если бренд менее известен.

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

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

Процесс, который через API занял бы один POST-запрос, превратился в квест с браузерной автоматизацией.

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

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

Это принципиальная позиция.

Если идти по пути полной автономии 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 появился через шесть лет после первой публикации.

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

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

Читать оригинал