Kafka для разработчиков:
тонкости и нюансы

AI-агенты — самая хайповая концепция, но именно поэтому этим словом
называют все подряд: и простого чат-бота с промптом, и любой скрипт с
 вызовами LLM.

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

Что такое агент и что им не является:

• как мы вообще здесь оказались и почему перестало хватать просто LLM
• агент vs чат-бот vs pipeline vs workflow
• decision framework: когда агент действительно нужен, а когда это оверинжиниринг
• анатомия агентов и agent loop

Паттерны:

• ReAct, Plan→Execute (PlanSolve)
• критерии выбора + антипаттерны

Бонусом:

• кратко пройдемся по внутреннему устройству популярных агентов: Cursor, Claude Code, Deep Research
• разберемся, что у них общего архитектурно

Практика:

• разбираем архитектуру реального агента по слоям
• собираем наивный прототип Projects Health Agent, который постарается навести порядок в вашем GitLab

______________________________


Результат:

• понимаешь, где кончается «чат» и начинается агент
• есть рабочий и простой прототип, который будем прокачивать

«Агент работает, но так себе» — мы не уверены, что задача вообще закончится успехом. В этом уроке строим когнитивный и execution-слой как инженерные компоненты

Когнитивный слой:

• основы инференса LLM как рычаги: на что мы можем влиять
• как выбрать модель под задачу
• context engineering: как не впихивать все, что у вас есть
• structured outputs: заставляем модель ответить так, как нам надо

Execution-слой:

• tools: разбираем из чего они состоят
• проблемы дизайна инструментов: «слишком мало/слишком много»
• коротко про MCP: как стандартизировать доступ к тулзам

Практика:

• подключаем GitLab API как tools
• вводим строгие схемы output + валидацию/repair loop
• делаем стратегию чтения: агент сам решает, какие MR раскрывать глубже

______________________________


Результат:

• предсказуемые структурированные инсайты вместо безумной генерации
• агент умеет выбирать контекст и инструменты, а не пихать все в промпт

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

Память:

• краткосрочная / долгосрочная / эпизодическая
• history management и компактизация: хранить / сжимать / забывать

State engineering & persistence:

• жизненный цикл состояния
• персистентность: падение / рестарт без потери
• параллелизм и консистентность

Идемпотентность и детерминизм:

• повторяемость действий и политики
• идемпотентность операций
• детерминизм, где возможно

Контроль автономности:

• HITL (Human-in-the-Loop): когда действуем сами, а когда спрашиваем
• confidence как уровни автономности
• self-reflection как адаптация

Практика:

• добавляем память и реализуем state-машину
• вводим idempotency keys и учимся не повторяться
• учимся адаптироваться к суровому окружению

______________________________


Результат:

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

Демо прощает все, а прод — нет. В этом уроке делаем агента, которому можно доверять: ошибки, безопасность, наблюдаемость, стоимость, измеримость и обязательные stop conditions

Error handling:

• API 500 / таймауты: retry / backoff / fallback / graceful degradation
• ошибки LLM: отказ, галлюцинации, невалидный output → repair / abort

Guardrails:

• запрет деструктивных действий без подтверждения
• политика алертов и настройка порогов
• работа с prompt injection / adversarial inputs

Stop conditions или когда агент обязан остановиться:

• cost / time / tool control
• mistools и другие ошибки инструментов
• низкая уверенность, отсутствие HITL … и другие

Observability & Evals:

• строим трейсинг и health check
• что такое evals, как их строить и почему в агентах это так важно

Практика:

• добавляем guardrails + запреты + политики алертов
• внедряем stop conditions (бюджеты, circuit breaker, abort правила)
• пишем минимальный eval suite

______________________________


Результат:

• агент безопасно останавливается и сжигает бюджет маленькой страны
• есть наблюдаемость и постоянная оценка качества

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

Когда мультиагентность нужна / когда нет:

• компетенции, параллелизм, сложность решений
• цена координации

Топологии и роутинг:

• supervisor / hierarchical, peer-to-peer
• роутинг: статический / динамический / условный

Multi-agent state:

• shared vs isolated
• конфликтность состояний и findings + dedup / merge-политики

Практика:

• финализируем нашу систему

______________________________


Результат:

• понимаешь, когда мультиагенты оправданы
• умеешь проектировать их координацию и целеполагание

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

Когда мультиагентность нужна / когда нет:

• компетенции, параллелизм, сложность решений
• цена координации

Топологии и роутинг:

• supervisor / hierarchical, peer-to-peer
• роутинг: статический / динамический / условный

Multi-agent state:

• shared vs isolated
• конфликтность состояний и findings + dedup / merge-политики

Практика:

• финализируем нашу систему

______________________________


Результат:

• понимаешь, когда мультиагенты оправданы
• умеешь проектировать их координацию и целеполагание