🤔 Observability в агентных системах: масштабирование начинается с трейсов

В агентных системах инцидент (нестабильность поведения) – это не дефект кода, а штатная характеристика среды.

➡️Когда логика исполнения выносится в runtime, вопрос «почему это упало?» становится критическим. ➡️Observability (наблюдаемость) здесь перестает быть приятным дополнением – это базовое условие выживания, отделяющее управляемый продукт от непредсказуемого хаоса.

▶️ Проблема causal chain: почему агенты стохастичны
LLM – это системы с высоким уровнем энтропии. В агентной обвязке их риски (hallucinations, context drift) усиливаются за счет вероятностного наслоения:

– Архитектурная сложность: tool calling, итеративное планирование и кросс-агентные зависимости перемножают неопределенность модели на нестабильность среды.
– Инфраструктурный хаос: таймауты внешних API, сайд-эффекты инструментов и изменяемый стейт делают систему невозможной для детерминированного описания.

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

▶️ Почему код больше не источник правды
В классическом софте все линейно: код → поведение, стек-трейс → конкретная причина.

В агентных системах эта связка рвется. Код лишь задает границы маневра, а реальное поведение рождается в runtime – через взаимодействие модели с контекстом и инструментами. Теперь источник правды не main.py, а динамическая история исполнения: входные данные, шаги рассуждений (CoT), вызовы инструментов и мутации стейта.

▶️ Из чего состоит observability агентов (LLMOps stack)
– Distributed Tracing (obs-фундамент): каждый запуск упаковывается в trace_id. Мы используем стандарты вроде OpenTelemetry или готовые решения (LangFuse, LangSmith, Arize Phoenix), чтобы превратить блэк бокс в прозрачную иерархию вызовов.
– Глубокое логирование инструментов: I/O и latency каждого Tool Call. Без этого анализ инцидентов превращается в гадание на кофейной гуще.
– Eval внутри трейса: мониторинг здоровья каждого шага через LLM-as-a-judge. Это позволяет выявлять логические ошибки до того, как они долетят до пользователя, хотя и требует отдельной калибровки судейской модели.

↔️Двухуровневые дашборды
Эффективный мониторинг требует разделения:

– Продуктовый слой: success Rate, CSAT, Efficiency, HITL Rate.
– Технический слой: latency, расход токенов, частота регрессий и ошибок внешних API.

Так за минуты становится понятно: проблема в «галлюцинации» агента или в стабильности внешней инфраструктуры.

🟢Агентные системы без наблюдаемости не поддаются масштабированию. Если вы не можете в любой момент восстановить, почему агент принял конкретное решение – у вас не инженерная система, а неконтролируемый процесс.
🟢Именно observability превращает агентную архитектуру из хрупкого эксперимента в устойчивый продукт, готовый к эксплуатации в продакшене.

#Observability #AgenticAI #LLMOps #AIArchitecture #ProductionAI #MachineLearning

🍎 WebKit → dyld: анатомия системной exploit-chain

➡️Apple выпустила экстренное обновление для закрытия CVE-2026-20700. Это первый критический zero-day года, затрагивающий dyld (Dynamic Link Editor).
➡️Разбираем, почему это технически изящно и крайне опасно для тех, кто работает с чувствительными данными.

⚙️ dyld: точка, где начинается выполнение кода

dyld – это динамический компоновщик. В иерархии macOS и iOS он стоит у основания: когда вы запускаете любое приложение, первым просыпается именно он. Его задача – собрать исполняемый файл и системные библиотеки (.dylib) в единое целое в памяти.

В чем критичность?
dyld обладает огромными привилегиями. Ошибка управления памятью (memory corruption) здесь позволяет атакующему подменить адреса. Система вместо доверенной библиотеки Apple подгружает вредоносный код. Это происходит до того, как сработают основные уровни защиты.

➡️Как это эксплуатируется: логика цепочки
Злоумышленники не используют этот баг сам по себе. Это финальный аккорд в сложной цепочке (Exploit Chain):

– Entry Point: через уязвимости в WebKit (декабрьские CVE-2025-14174 и 43529). Пользователю достаточно просто зайти на подготовленную страницу. Браузер спотыкается, позволяя атакующему записать данные в ограниченную область памяти.

– Escalation: обычного доступа браузера атакующему мало – он заперт внутри процесса Safari. Чтобы получить доступ к сообщениям, камере или паролям, нужно выпрыгнуть в систему.

– The dyld Flip: здесь вступает новый zero-day. Атакующий через поврежденную память заставляет dyld при запуске любого системного процесса подгрузить не родную библиотеку Apple, а вредоносный код.

– Full Control: поскольку dyld доверяет загружаемым модулям, вредоносный код исполняется в контексте более привилегированного процесса.

➡️При чем здесь ИИ?
ИИ все чаще используется в исследовании уязвимостей.

– Автоматизация поиска: AI-агенты и LLM помогают находить аномалии в бинарном коде и нетривиальные паттерны управления памятью быстрее, чем при полностью ручном анализе. Это сокращает время на поиск слабых мест в сложных компонентах вроде WebKit или dyld.
– Ускорение цикла разработки: те же подходы применяются для фаззинга, triage и подготовки исправлений. В результате окно между обнаружением и закрытием уязвимости постепенно сокращается.

В итоге ключевым фактором становится не только глубина уязвимости, но и скорость ее обнаружения и устранения.

🟢

Автоматизация анализа постепенно снижает порог сложности для поиска нетривиальных цепочек эксплуатации

. То, что раньше искали годами вручную, теперь находят алгоритмы.
Цикл жизни багов сокращается, и единственная адекватная реакция – сокращать время до нажатия кнопки «Обновить ПО»

Stay safe. Update mandatory.

#ZeroDay #ExploitChain #dyld

Replication vs Partitioning vs Sharding: три разных ответа на рост данных

Сегодня чуть отойдем от AI, хотя для AI/LLM-систем это тоже основа. Меня часто спрашивают про базы данных, и здесь часто возникает путаница: репликация, партиционирование и шардирование – это не одно и то же «масштабирование базы», а три разных подхода под три разных узких места системы.

TL;DR

➡️Replication (Репликация) – копируем одни и те же данные на несколько узлов.
Нужно для доступности, отказоустойчивости и масштабирования чтений.
➡️Partitioning (Партиционирование) – делим большую таблицу на части внутри одного сервера.
Нужно для ускорения запросов, управления хранением данных и обслуживания.
➡️Sharding (Шардирование) – делим данные и распределяем по разным серверам.
Нужно для горизонтального масштабирования, когда один узел уже физически не справляется.

Важно понимать, что эти подходы не взаимоисключающие. В реальных системах данные часто партиционируются, шардируются по узлам, а каждый шард еще и реплицируется.

1️⃣ Replication: копии ради доступности
Репликация – это один и тот же набор данных в нескольких экземплярах. Обычно есть основной узел (primary), куда идет запись, и реплики, которые получают эти изменения.

Что дает:
🟢устойчивость к сбоям
🟢бóльшую пропускную способность на чтение
🟢возможность быстрого переключения (failover)

Что важно под капотом: появляется

лаг репликации

, т.е. запись уже есть на primary, но реплика может еще отдавать старое состояние;

failover – это не магия

, а выбор нового мастера, риск проблемы split-brain и операционная сложность.

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

2️⃣ Партиционирование: логически делим большую таблицу на части по правилу
Партиционирование – это когда таблица делится на секции (партиции) по правилу: диапазону, хэшу, списку или дате.
Например: логи по месяцам, транзакции по дате, события по ID клиента.

Что дает:
🟢запросы читают не всю таблицу, а только нужную партицию
🟢индексы становятся меньше и дешевле
🟢проще управлять сроком хранения и очисткой
🟢старые данные можно удалять целиком партициями, а не тяжелыми операциями DELETE

Ограничения:
🔴если запросы бьют сразу по всем партициям – выигрыш падает
🔴плохой ключ партиционирования почти убивает идею
🔴джойны и агрегации между партициями остаются дорогими

3️⃣ Шардирование: настоящий горизонтальный рост
Шардирование начинается там, где один сервер уже не вмещает нагрузку физически: по CPU, RAM, IOPS, объему диска или потоку записи. Здесь каждая машина хранит только часть данных. Шард А – одни пользователи, шард B – другие, шард C – третьи.
Что дает:

🟢горизонтальный рост хранилища
🟢распределение нагрузки на запись
🟢выход за пределы архитектуры одного узла

Цена высокая:
🔴нужен ключ шардирования (shard key)
🔴нужна маршрутизация запросов (routing)
🔴возникают «горячие» шарды (перегруженные узлы)
🔴сложнее делать кросс-шардовые запросы
🔴ребалансировка и решардинг становятся отдельными сложными проектами

Главный риск – неудачный ключ шардирования. Если ключ выбран плохо, один шард перегревается, остальные простаивают, а задержки (latency) становятся непредсказуемыми.

🔥 Где чаще всего ошибаются

Самая частая ошибка: «

База тормозит – давайте добавим реплики

»

Это поможет, только если узкое место в чтении. Если проблема в скорости записи, объеме данных, тяжелых процессах очистки, нагрузке на WAL или горячих партициях, смотреть надо уже в другую сторону.
Вторая ошибка – слишком рано шардировать.
Очень часто систему сначала можно отлично вытянуть за счет партиционирования, правильных индексов, политик хранения и read-реплик. Потому что шардирование это не просто фича, а долгосрочное архитектурное обязательство.

🟢

Хорошая архитектура начинается не с вопроса «что из этого круче?», а с вопроса:

во что именно мы уперлись: в чтение, запись, объем диска, задержки, консистентность или эксплуатацию?

#SystemDesign #Databases #HighLoad #DistributedSystems

@mrtnv_prism | @ainative

SreGPT: как Яндекс научил AI-агентов тушить инциденты в проде

Вчера был на AI Dev Day – кейсов было много хороших, но рассказать решил про этот, потому что тема важная и для многих SRE-команд пока неочевидная.

Ребята из Яндекса показали SreGPT – AI Copilot для команд надежности. Не очередной чат-бот поверх документации, а ансамбль специализированных AI-агентов под управлением центрального оркестратора. Контекст: Яндекс Go, около 1000 микросервисов.

➡️Какую проблему решают
1️⃣Снижение MTTR / MTTRC – время до восстановления и до нахождения root cause. Каждая минута инцидента – это деньги, репутация и нервы.
2️⃣Дефицит квалифицированных кадров – людей с нужной экспертизой не хватает, а инцидент не будет ждать, пока вы наймете и онбордите сеньора. AI-агент восполняет этот разрыв, давая дежурному контекст и подсказки, которые раньше были только в голове у конкретного человека.
3️⃣Повышение аптайма до 99,99, сокращение налога на дежурство и высвобождение времени команды на проактивную работу вместо тушения пожаров.

➡️Что умеет SreGPT

Каждый агент отвечает за свой блок процесса, оркестратор координирует их по фазам

Горячая фаза (инцидент прямо сейчас):
– автозаполнение карточки инцидента – агент собирает контекст из алертов, логов и метрик, пока дежурный еще читает первый алерт
– автостатусы – система сама генерирует апдейты для стейкхолдеров, дежурный не отвлекается на "написать в канал что происходит"
– поиск похожих инцидентов – моментальный поиск по истории: было ли такое, что помогло, какой был root cause
– призыв релевантных людей – агент анализирует тип инцидента, затронутые сервисы и историю, и зовет тех, кто реально нужен

Холодная фаза:
– root cause analysis – таймлайн, корреляция событий, гипотезы по первопричине
– подготовка постмортема с ключевыми точками и рекомендациями

➡️Что нужно, чтобы такое построить
SreGPT – это не модель, которую можно просто подключить. Это верхушка айсберга, а под ней - необходимые условия, без которых ничего не взлетит

– Инфраструктура – облако, централизованные логи, алерты, CI/CD. Без единой наблюдаемости агентам не на чем работать.
– Каталоги – сервисов, дежурных, оргструктуры. Агент должен знать, что за сервис, кто за него отвечает и кого звать.
– Knowledge graph / граф зависимостей – без карты связей между сервисами агент не поймёт, что упавший сервис X повалил сервисы Y и Z.
– Аудит всех событий – полная история: деплои, изменения конфигов, алерты, действия людей. Без этого root cause analysis превращается в гадание.
– Инференс – инфраструктура для быстрого вызова моделей, чтобы агенты отвечали за секунды, а не минуты.

Если у вас этого нет – начинать нужно не с AI-агентов, а с фундамента.

➡️Роадмап: от копилота к автопилоту
Самое интересное – куда ребята идут дальше. По сути, это путь от “помогаю человеку” к “делаю сам”:

Q4 2026 – Q1 2027: система сама находит, что сломалось, и определяет корневую причину. Дежурный получает не сырые алерты, а готовый диагноз.
Q4 2027: агент предлагает способы митигации и/или починки корневой причины. Человек выбирает и подтверждает, AI исполняет.
Дальше: полный цикл – находит причину, сам митигирует, сам чинит. Человек подключается только для контроля и нестандартных случаев.

Это классическая эволюция автономности: сначала AI как второй пилот, потом как первый, потом – автопилот с человеком на подстраховке. И у Яндекса уже есть конкретные таймлайны на каждый шаг.

Главное – SRE-процессы одна из самых благодарных зон для AI-агентов: структурированные данные, повторяющиеся паттерны, высокая цена каждой минуты простоя.

Но магия работает только поверх зрелой инфраструктуры

. Сначала – наблюдаемость, каталоги и граф зависимостей. Потом – агенты. А потом – автономия.

#AI #SRE #IncidentManagement #AgenticAI #AIDevDay #Yandex

@mrtnv_prism | @ainative

Rules, Skills, Modes: как команды перестают изобретать промпты

Тема, которая за последние полгода из нишевой стала обязательной: как организовать работу команды с AI-инструментами разработки так, чтобы знания можно было масштабировать на всю команду.

Проблема знакомая: в команде из 10 разработчиков каждый настраивает AI под себя. Один нашел рабочий промпт для код-ревью, другой – для генерации тестов, третий – для миграций. Классический tribal knowledge, только теперь не про код, а про то, как правильно взаимодействовать с AI.

➡️ Что уже есть: три слоя кастомизации

1️⃣ Rules – статичные инструкции, которые AI читает перед каждым ответом. Cursor (.cursor/rules/), Claude Code (CLAUDE. md), Windsurf (.windsurf/rules/) – у всех свой формат, но идея одна: положи файл в репозиторий, закоммить, и вся команда получает одинаковое поведение AI. Это как .eslintrc, только для AI-ассистента. Один настроил – все используют.

2️⃣ Skills – переиспользуемые рабочие процессы. Не просто «веди себя так», а полноценные инструкции с шаблонами, скриптами и примерами. Папка со скиллами, которую AI загружает когда задача подходит. Команда может собрать библиотеку: deploy, review-pr, setup-dev, create-feature – и новый разработчик в первый день работает по тем же стандартам, что и сеньор.

В декабре 2025 Anthropic вывела формат Skills в открытый стандарт (agentskills.io), и его подхватили ключевые игроки: GitHub Copilot, OpenAI Codex, Gemini CLI, Cursor. Тут идея reusable workflow. Написал скилл один раз – перенес без изменения.

Простая аналогия: MCP дает агенту доступ к внешним инструментам и данным. Skills учат агента, что с этими инструментами делать. Уже появились каталоги – можно устанавливать одной командой, можно публиковать свои.

3️⃣ Modes и Subagents – управление автономностью и специализацией.
Modes = сколько агенту разрешено. Например, в Claude Code это permission modes (plan-only / auto-accept edits).
Subagents = кому делегирована подзадача. Отдельный агент со своим контекстом и ограниченной зоной ответственности: один исследует кодовую базу, другой пишет тесты, третий готовит деплой.

➡️ Как это работает на практике в команде

Паттерн простой и уже обкатанный:
– Rules коммитятся в репозиторий проекта – code style, архитектурные решения, запрещенные паттерны
– Skills хранятся рядом с кодом – командные workflows подтягиваются автоматически при клонировании репозитория
– Например, в Claude Team/Enterprise админы уже могут раскатывать skills на всю организацию – пользователь может отключить конкретный скилл, но базовый набор единый.

По сути, это тот же подход, что и с линтерами: один человек настраивает, остальные получают из коробки. Только вместо правил форматирования – правила поведения AI.

➡️ Где чаще всего ошибаются

🔴Первая ошибка – делать один гигантский файл правил на все случаи жизни. Skills специально спроектированы по принципу progressive disclosure: AI читает только название и описание (~100 токенов), и подгружает полные инструкции только когда задача совпала. Несколько фокусных скиллов всегда лучше одного монолитного.
🔴Вторая ошибка – не версионировать. Skills и rules – это код. Они должны жить в git, проходить ревью и эволюционировать вместе с проектом.
🔴Третья – забывать про описание. AI решает, загружать ли скилл, только по полю description. Если оно размытое – скилл никогда не сработает, каким бы хорошим ни было содержимое.

#AI #AIDevTools #AgentSkills #DeveloperExperience #Engineering

@mrtnv_prism | @ainative

Самая сложная машина в мире: как обманули физику, чтобы у нас был современный AI

Мы здесь часто обсуждаем архитектуру AI-агентов, RAG, MCP, графы и тп. Но все это было бы невозможно без физического фундамента. Посмотрел отличный разбор от Veritasium про ASML – единственную компанию в мире, которая продает установки экстремальной ультрафиолетовой литографии (EUV).

TL;DR

➡️Когда старые методы производства чипов начали упираться в физические пределы, эта голландская компания создала устройство нового поколения (High NA) за $400 млн, состоящее из сотен тысяч деталей. Это один из самых сложных коммерческих продуктов за всю историю человечества, который спас закон Мура.

➡️ Как это работает (без сложной физики, но с инженерной магией)

1️⃣ Искусственное солнце в коробке (или 50 000 RPS расплавленным оловом). Чтобы печатать микроскопические транзисторы, нужен свет с экстремально короткой длиной волны (13,5 нм). Как его получить? Машина выстреливает крошечными каплями расплавленного олова. По каждой капле прямо в полете бьют лазером трижды: первый импульс расплющивает каплю в плоский «блинчик», второй снижает ее плотность, а третий, сверхмощный, превращает ее в плазму, которая почти в 40 раз горячее поверхности Солнца. И так 50 000 раз в секунду. Представьте себе систему, которая должна без единого промаха держать такой физический RPS.

2️⃣ Самые гладкие объекты во Вселенной. Этот EUV-свет поглощается абсолютно всем – даже воздухом. Поэтому внутри машины строгий вакуум, а свет фокусируют не линзами, а системой специальных многослойных зеркал. Они отполированы настолько идеально, что если бы самое большое зеркало в системе было размером с Землю, максимальная неровность на нем была бы не толще игральной карты.

3️⃣ Водородное торнадо (Garbage Collection на максималках). Когда вы взрываете олово 50 000 раз в секунду, во все стороны летят микрочастицы, которые могут моментально уничтожить те самые идеальные зеркала. Как решили проблему? Внутри камеры создали направленный поток водорода на скорости более 300 км/ч. Он сдувает оловянный мусор, вступает с ним в реакцию и очищает систему прямо на лету, не перекрывая при этом свет.

4️⃣ Точность на огромной скорости. Современные чипы многослойны. Новейшая машина наносит слои один поверх другого с погрешностью менее 1 нанометра (буквально размер 5 атомов!). При этом платформа с маской чипа носится внутри установки туда-сюда с ускорением больше 20G – это в 5–6 раз больше, чем перегрузки пилота Формулы-1 при жестком торможении. Любое микро-расширение металла от нагрева сломало бы процесс, поэтому сложнейшая система сенсоров и приводов корректирует углы зеркал с точностью до пикорадиан в реальном времени.

➡️ Вместо вывода

Самое крутое в этой истории – масштаб инженерного упорства. Около 30 лет индустрия считала EUV-литографию нерешаемой задачей. Ученых буквально поднимали на смех на конференциях.

🟢Сегодня мы строим платформы, собираем цепочки агентов и обучаем LLM, воспринимая вычислительные мощности как данность. Но вся эта абстракция магии AI существует только потому, что инженеры ASML научились физически синхронизировать лазеры и летящий металл на 50k RPS. Отличное напоминание о том, на каком невероятном железе стоит вся наша индустрия.

#Hardware #SystemArchitecture #ASML #Semiconductors #Engineering

@mrtnv_prism | @ainative

Reverse Proxy vs API Gateway vs Load Balancer: три стража, которых все путают

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

Разберем, кто есть кто :)

TL;DR

➡️Reverse Proxy – прячет инфраструктуру и оптимизирует доставку
➡️Load Balancer – распределяет трафик, чтобы ничего не упало
➡️API Gateway – управляет доступом и бизнес-логикой API

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

1️⃣ Reverse Proxy: телохранитель бэкенда
Принимает запросы от клиентов и пробрасывает их на внутренние серверы. Клиент общается с одним адресом и понятия не имеет, что за ним живут десятки сервисов.

Что дает:
– полную изоляцию внутренней инфраструктуры от внешнего мира
– берет на себя тяжелую работу: TLS-терминацию, сжатие и кеширование
Примеры: NGINX, Envoy, Apache HTTP Server

2️⃣ Load Balancer: диспетчер нагрузки
Задача максимально конкретная: распределить входящий трафик между несколькими инстансами, чтобы ни один не захлебнулся. Это про доступность.

Что дает:
– горизонтальное масштабирование
– отказоустойчивость (мониторит health check серверов и отключает упавшие ноды)
– умную маршрутизацию по алгоритмам (round-robin, least connections, weighted)
Примеры: HAProxy, AWS ALB, Azure Load Balancer

3️⃣ API Gateway: единый вход в ваш API
Здесь начинается бизнес-логика маршрутизации. Это не просто труба для трафика, а полноценный контроллер доступа.

Что дает:
– единую точку входа (аутентификация, авторизация, rate limiting)
– трансформацию запросов на лету
– агрегацию (может собрать ответы от нескольких микросервисов в один)
Примеры: AWS API Gateway, Kong, Apigee

🔥 Где чаще всего ошибаются
Проблема в том, что современные инструменты стирают границы. NGINX умеет балансировать. Kong работает и как gateway, и как прокси. AWS ALB маршрутизирует по хедерам. Из-за этого возникает путаница.

Инструменты действительно могут делать работу друг друга, но ключевое отличие кроется в архитектурной роли:
– Reverse Proxy: «спрячь мою инфраструктуру»
– Load Balancer: «распредели нагрузку, не дай упасть»
– API Gateway: «управляй контрактами и логикой API»

↕️ А что в мире AI?

Кажется, что это все классический бэкенд, но в ML-инфраструктуре работают те же принципы, просто на стероидах. Взять тот же инференс LLM – там базы в духе HAProxy уже не хватает, нужны свои «умные» балансировщики.

Обычный Load Balancer не понимает, сколько токенов в вашем промпте и сколько памяти на GPU этот запрос сожрет. Поэтому для AI пишут специфичные балансиры инференса (например, с учетом KV-cache affinity), которые направляют запрос на ту ноду, где уже лежит нужный контекст для максимальной скорости генерации.

AI Gateway сегодня – это вообще отдельный класс продуктов. Он не только проверяет ключи, но и считает токены, кеширует эмбеддинги и динамически переключает роутинг (например, если тяжелая модель отвалилась по таймауту, прозрачно для юзера идет фоллбэк на более легкую).

🟢

Чем «умнее» становится AI-стек, тем больше он заимствует из классического бэкенда

. Token-aware роутинг - это тот же weighted round-robin, только с учетом контекста. Семантический кеш – это тот же CDN, только ключ не URL, а эмбеддинг. Новые задачи решаются старыми паттернами в новых обертках.

#SystemDesign #Architecture #Backend #Infrastructure #Engineering #AIEngineering

@mrtnv_prism | @ainative

AI Agent vs Agentic AI: и почему это вопрос про архитектурные паттерны, а не про маркетинг

Сейчас каждый второй продукт объявляет себя «agentic». Но за одним и тем же словом скрываются совершенно разные архитектуры – от одного tool call до многоагентной системы с памятью и саморефлексией. Разница не в наличии LLM, а в паттерне исполнения.

TL;DR

➡️AI Agent автономно решает локальную задачу через инструменты («найди отчет, вытащи цифры, посчитай метрику»)
➡️Agentic System планирует, исполняет, проверяет себя и адаптируется под цель
➡️Ключевая разница не в LLM, а в паттерне взаимодействия внутри системы

1️⃣ Паттерны исполнения, которые реально работают

– ReAct (Think → Act → Check → Repeat). Классика. Агент рассуждает, дергает инструмент, смотрит результат, решает следующий шаг. База для большинства single-agent сценариев.
– Plan & Execute. Сначала планировщик строит полный план, потом исполнитель идет по шагам. Лучше ReAct на длинных задачах — меньше дрейфует контекст.
– Hierarchical (супервизор + сабагенты). Супервизор раздает подзадачи специализированным агентам. Нужен, когда задача распадается на независимые куски (research → analysis → writing).
– Author-Critic. Один агент делает, другой критикует и возвращает на доработку. Резко повышает качество на креативных задачах и коде.
– Reflection Loop. Агент сам проверяет свой вывод и исправляет ошибки до того, как отдать результат. Самый дешевый способ поднять accuracy без смены модели.

2️⃣ Уровни зрелости (фреймворк для честной самооценки)

– L0: прямой вызов модели (prompt-response без инструментов)
– L1: ассистирует пошагово (copilot-режим)
– L2: выполняет небольшие задачи сам через tool use
– L3: несколько агентов кооперируются
– L4: самокоррекция через память
– L5: полная автономия и self-improving

Большинство агентных продуктов на рынке – L1–L2. L3+ встречается редко и стоит дорого в эксплуатации.

3️⃣ Что выбирать под задачу

– Разовая/простая задача → function calling, базовые assistant-API, простые графы
– Многошаговая с состоянием → stateful-оркестраторы (LangGraph, CrewAI, AutoGen)
– Постоянная/творческая → полноценная агентная система с памятью и ролями

🔥 Архитектурные антипаттерны

Первая ошибка – путают сложность архитектуры с качеством решения. Задачу, которую закрывает ReAct с двумя инструментами, тащат в CrewAI с пятью ролями. В итоге дороже, медленнее, менее предсказуемо и в три раза сложнее в observability.
Вторая – пропускают Reflection и Author-Critic. Это самые дешевые паттерны по ROI: накидываются поверх существующего агента и заметно поднимают качество без переписывания архитектуры. Но про них вспоминают в последнюю очередь, когда уже пытаются «перейти на модель побольше».

⚙️ Чего стоит L3+ на самом деле

Скачок с L2 на L3+ это не про промпты и не про выбор фреймворка. Это инженерный скачок, и споткнуться там можно на двух вещах, которые редко обсуждают в туториалах по агентам:

🔴 Синхронные цепочки агентов в одном скрипте. Агент 1 ждет Агента 2, тот ждет Агента 3, любой таймаут внешнего API роняет всю цепочку. Под нагрузкой такая система хрупкая по определению. L3+ почти всегда требует асинхронности: очередей задач, брокеров сообщений, воркеров.
🔴 Отсутствие observability под многоагентную систему. Без трейсов, eval и метрик на уровне каждого шага мультиагентная система превращается в черный ящик, в котором нельзя понять, какой именно агент уронил качество.
🟢 Правильный вопрос не «агент у нас или агентная система?», а какой минимальный паттерн закрывает задачу с нужным качеством и готова ли инфраструктура его держать. ReAct + Reflection на асинхронной архитектуре часто бьет иерархию из 4 агентов на синхронном Python-скрипте и по цене, и по стабильности.

#AgenticAI #AIArchitecture #LLMOps #SystemDesign #AIEngineering

@mrtnv_prism | @ainative

MCP vs CLI: половина MCP-серверов написана там, где хватало shell-команды

Часто вижу сравнение «MCP vs Skills», и это сравнение с ошибкой в постановке. Skills – это уровень способностей агента, инструкция «что делать». MCP – это механизм вызова, способ обратиться к внешней системе. Они на разных слоях стека и не конкурируют.
Корректное сравнение на одном слое – MCP vs CLI. Оба отвечают на вопрос «как агент взаимодействует с внешним миром».

TL;DR

➡️Skills – уровень workflow (что делать)
➡️MCP и CLI – механизм интеграции (как взаимодействовать с внешним миром)
➡️Skill внутри использует либо MCP, либо CLI – большинство задач закрывается CLI

1️⃣Где на самом деле проходит граница

Skill – это директория с инструкциями (или Tool / Action в терминологии LangChain, CrewAI, AutoGen, нейминг плавает, суть одна). Сама по себе она ничего не делает: внутри она вызывает инструменты.
– CLI как механизм: скилл запускает git, docker, psql, kubectl через shell в окружении агента. Никакой дополнительной инфры, все, что есть в PATH, доступно.
– MCP как механизм: скилл вызывает MCP-инструмент с типизированными параметрами и схемой. Сервер живет отдельно – со своим рантаймом, секретами, сетью.

Внутри одного Skill вы делаете архитектурный выбор: пойти через CLI или через MCP. И именно здесь чаще всего ошибаются – берут MCP по умолчанию, хотя задача чистая под CLI.

2️⃣ Когда CLI – правильный выбор

– Инструмент уже есть в виде CLI и стабилен (git, docker, kubectl, terraform). Зачем оборачивать в MCP то, что 20 лет работает как CLI?
– Вызовы редкие или разовые. Отдельный сервис под «раз в спринт собрать релиз» – оверкилл по стоимости владения.
– Действие в контексте агента, без разделяемого состояния. Skill с scripts/run. sh, это не кандидат на MCP, это финальная архитектура.
– Креды уже на уровне окружения агента (ENV, kubeconfig). MCP добавил бы второй слой управления секретами там, где первый уже работает.

3️⃣Когда MCP – правильный выбор

– Несколько агентов ходят в одну систему с единым контролем доступа. Один MCP-сервер с Postgres лучше, чем N скиллов с захардкоженным psql.
– Нужна типизация и валидация параметров до вызова. CLI падает на runtime; MCP валидирует по схеме заранее.
– High-frequency сценарий с собственной обсервабилити. Сотни вызовов в день – отдельный сервер с метриками окупается.
– Нужно прятать сложность от агента. Один create_pull_request вместо цепочки git checkout, git commit, gh pr create. И это критично именно для LLM: длинная цепочка CLI-команд резко повышает риск галлюцинаций в аргументах, раздувает контекст и съедает токены на каждом шаге. MCP-контракт снижает когнитивную нагрузку на модель – один типизированный вызов вместо пяти shell-команд с правильным порядком флагов.

Антипаттерны

🔴MCP-сервер git-helper, оборачивающий git checkout, git commit, git push. Это CLI внутри Skill. Заворачивать стабильный 20-летний интерфейс в JSON-RPC, это странно.
🔴MCP-сервер release-builder, дергающий npm, docker, gh через shell внутри сервера. Сетевой хоп до своего сервера, чтобы тот сделал shell-вызов в своем контейнере – который мог быть сделан в контейнере агента.
🔴Обратный антипаттерн: Skill, ходящий в Postgres через psql с захардкоженными кредами. Здесь как раз нужен MCP, типизированный, со схемой, с централизованным управлением доступом.

Что с этим делать

Возьмите список ваших MCP-серверов и для каждого ответьте на один вопрос: что я потеряю, если заменю его на Skill с CLI? Если ответ звучит как «ничего, кроме сервиса, который надо поддерживать», перед вами кандидат на миграцию.

🟢

Skills, MCP и CLI работают на разных слоях.

Skills отвечают за то, что делать, MCP и CLI, за то, чем делать

. В зрелой системе Skills используют оба подхода осознанно: MCP там, где нужен контракт и разделяемый доступ; CLI там, где задачу решает уже существующий стабильный инструмент. Большинство задач пока относится ко второму случаю.

#MCP #AgentSkills #CLI #AIDevTools #AIArchitecture

@mrtnv_prism | @ainative

Иллюзия автономности: почему в бизнес-процессах максимальный ROI приносят агенты, которые ничего за вас не решают

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

Сегодня опираюсь на разбор Anthropic о том, как их finance-команда работает с Claude. Кейс хорош тем, что это не демо и не лендинг, это рутина человека, который закрывает квартальный board deck.

TL;DR

➡️Ценность агента в реальной работе ≠ автономность. Ценность в слое проверки, который не масштабируется руками.
➡️Один агент с reflection-петлей на живой задаче часто полезнее агентной системы.
➡️Кейс работает не из-за модели, а из-за контекста: память, коннекторы к почте/мастер-системам/доке.
➡️Это L1–L2 по шкале зрелости. И именно здесь сейчас лежит почти весь практический ROI.

↗️ Что за задача
Квартальная презентация для CFO и совета директоров. Боль не в том, чтобы посчитать цифры, боль в том, что цифры обновляются до утра отправки, документ собирают несколько человек параллельно, и при каждом обновлении надо заново проверять: коммент на слайде x все еще бьется с цифрой на слайде n? Кто-то не вкинул новую метрику?

Человек физически перечитывает все на каждой итерации. Это и есть та работа, которая съедает время, но не требует когнитивной нагрузки.

↗️ Что реально делает агент
Не «собери мне презу». А: проверь, что каждая цифра и каждое утверждение сходятся к единому источнику правды, и прочитай нарратив глазами члена совета директоров – где он противоречит себе, где предполагает контекст, которого у читателя нет.

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

Формулировка из статьи, которая мне очень зашла: агент держит integrity layer под работой, а время человека уходит на нарратив сверху. Вот это и есть правильная декомпозиция. Не «агент вместо аналитика», а «агент забирает слой сверки, аналитик забирает слой смысла».

↗️ Почему это работает – и почему дело не в модели
Тут легко решить, что магия в модели. Нет. Магия в том, что у агента тот же контекст, что и у человека: локальные файлы, почта, Slack, и ключевое – память проекта. Решение, принятое в длинном кросс-функциональном треде, вытаскивается один раз и лежит наготове к следующему циклу подготовки отчетности. Под разные аудитории, т.е. разные проекты с разной памятью, потому что тон и конвенции месячного ревью и квартального отчета отличаются.

Это прямое подтверждение тезиса, который я повторяю: агент без контекста – это дорогой автокомплит. Ценность дает не вызов модели, а то, что вокруг него.

↗️ Где это на шкале зрелости
Если честно разметить – это L1–L2 по уровням зрелости агентов, про которые я писал раньше. Агент ассистирует и выполняет узкую задачу через инструменты. Никакой иерархии агентов, никакого self-improving. И вот это, по-моему, главный практический вывод.

📌 Почти весь реальный ROI от агентов сегодня лежит на L1–L2 – и это не про один отдел: те же дашборды из промпта без SQL, дайджесты, авто-сверки крутятся на том же скелете. Не в мультиагентных системах, которые дорого эксплуатировать и тяжело наблюдать, а в том, чтобы найти в своей работе слой, который ты держишь руками только потому, что больше некому, и отдать его одному агенту с нормальным контекстом.
📌 Правильный заход к «агентам в работе» – не «какую автономную систему построить», а «какой слой проверки в моей рутине не масштабируется руками». Чаще всего ответ – один агент, нормальный контекст и память между запусками. Этого хватает, чтобы вернуть человеку 10–20 часов в неделю и оставить ему ту работу, ради которой его наняли.

🔗Оригинал разбора Anthropic тут

#AgenticAI #AIArchitecture #AIatWork #LLMOps #Claude

Давно сюда ничего не писал – исправляюсь :)

За последние несколько месяцев я снова успел сходить в горы, вернуться и почти сразу погрузиться в работу!

Мы сильно докрутили AlfaGen Flow и сейчас строим на его базе большой AI-продукт для клиентов Альфа-Банка.
Про продукт отдельно расскажу чуть позже: архитектура агентной системы, контекст, MCP, runtime, observability, ограничения LLM в проде, стоимость и все, что начинает вылезать при переходе от прототипа к большому клиентскому продукту.

Думаю, материала там хватит надолго 😎

А пока расширяю команду AlfaGen Flow и ищу:

➡️ Senior Python Developer
➡️ Senior System Analyst

AlfaGen Flow – платформа для разработки и исполнения AI-агентов и LLM-сценариев.

Под капотом много классического бэка: distributed runtime, очереди, API, интеграции, отказоустойчивость, observability. Поверх этого – LLM, agents, MCP, RAG, память и инструменты.

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

👉 Python

Нужен сильный бэкендер: Python, архитектура, concurrency, performance, базы, очереди, API, production reliability.

👉 System Analysis

Нужен SA, который сам любит разбираться, как все работает: может спроектировать контракт или интеграцию, сходить в архитектуру, руками потыкать LLM/agent stack, при необходимости навайбкодить прототип и проверить гипотезу до того, как она превратится в полноценную разработку.

Если интересно – пишите напрямую

@dmrtnv.

Расскажу, что сейчас строим и какие задачи лежат в родмапе.

Ну и репосты очень приветствуются ❤️

#Hiring #Python #SystemAnalysis #AIEngineering #AgenticAI #LLMOps