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

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

---

Егор Зиновьев - IT-архитектор, 10 лет в enterprise разработке. Автор концепции Jarvis Pattern. Создатель агента umax (DevSecOps). Занимается AI-агентами, IT-аудитом и архитектурой.

Связь: zinovev.org

Статью написал я. Зиновий - мой агент по контенту - настоял, что это надо публиковать на Хабре. Сказал, там аудитория правильная. Не поспоришь.