Глубокое понимание ИИ-агента: принципы проектирования и инженерные практики

Книга посвящена основной формуле Agent = LLM + контекст + инструменты.

Краткий обзор содержания книги (главы 1-10):

1️⃣ Базовые знания об агенте.
Сформулируйте основную формулу: Agent = LLM + Контекст + инструмент и внедрите инженерные разработки - все инженерные возможности, кроме модели, являются реальной конкурентоспособностью.

2️⃣ Разработка контекста.
Контекст определяет верхний предел возможностей агента. Изучите контекстную структуру API для больших моделей, дизайн, удобный для кэширования KV, разработку подсказок, динамические подсказки и навыки агента, метаинформацию в строке состояния и стратегии сжатия контекста.

3️⃣ Пользовательская память и база знаний.
Пусть Агент запоминает пользователей в разных сеансах и получает доступ к внешним знаниям.Она охватывает системы пользовательской памяти, базовые конвейеры RAG, а также организацию знаний и поиск информации (структурированные индексы, карты знаний и т.д.), которые выходят за рамки простого текста.

4️⃣ Инструменты: Инструменты - это руки агента.
Поговорим о классификации инструментов и общих принципах проектирования, протоколе MCP и проблемах выбора инструментов, инструментах восприятия/исполнения/совместной работы и асинхронных агентах, управляемых событиями.

5️⃣ Программист и генерация кода.
Код - это “инструмент, который может создавать новые инструменты” и является мета-способностью обычного агента. Возьмем в качестве примера средство разработки производственного уровня, чтобы продемонстрировать полную реализацию этого самого мощного универсального инструмента.

6️⃣ Оценка агента.
Превратите работу агента в сопоставимый сигнал. От среды оценки, разработки набора данных, системы индексов до статистической значимости, наблюдаемости, отбора на основе оценки, внутренней оценки и моделирования на производственном уровне.

7️⃣ Постмодельное обучение: трехэтапная панорама предварительной подготовки, SFT и RL.
Когда выбирать SFT, когда выбирать RL, RLHF, сравнение алгоритмов, данные и среда, а также передовые исследования, позволяющие моделям научиться вызывать инструменты и повышать эффективность выборки.

8️⃣ Саморазвитие агента.
Вы можете расти, не меняя свой вес. Три парадигмы обучения - от обучения на основе опыта, активного поиска инструментов до “от пользователя инструмента к создателю инструмента“ - позволяют агенту перейти от ”умного“ к ”опытному".

9️⃣ Мультимодальное взаимодействие в режиме реального времени: распространение восприятия и действий с текста на голос, графический интерфейс и физический мир.
Три режима передачи речи (каскадный /сквозной полный режим/полный дуплекс), восприятие и синтез потоковой речи, использование компьютера и управление роботом.

1️⃣0️⃣ Мультиагентное сотрудничество: интеллект группы может быть выше, чем у отдельного человека.
Многоагентная система классификации, когда она действительно лучше, чем один агент, взаимодействие между разделяемыми и не разделяемыми контекстами, закономерности сбоев и появление “сообщества агентов”.

Ну что, вайбкодеры, залетаем на мини-курс от Яндекс по построению безопасных агентов (сертификат прилагается, в том числе на английском языке)

Интенсив будет интересен разработчикам, AI‑ и Dev(Sec)Ops‑инженерам, техлидам и архитекторам, студентам технических вузов и тем, кому важно понимать риски и уметь проектировать надёжные агентные системы

Для практических заданий пригодятся навыки вайб‑кодинга: умение формулировать запросы и запускать получившийся код. Полезно также понимать жизненный цикл разработки

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

⏱ ТОРОПИТЕСЬ
Завтра (а точнее уже сегодня, до 28 июля) последний день, чтобы успеть пройти вводные задания (их 3 штуки, я их честно говоря проходил с нейронкой на пару, нет времени на них). Далее идут лекции, потом сдача финального задания. На выходе получим сертификат о прохождении.

Кому просто посмотреть лекции надо, и сертификат не нужен - можете не дергаться, всё будет общедоступно в ВК и Ютуб.

В прошлый раз ШАД тоже запускал обучение по агентам, все прошло гладко, сертификат выдали. Так что лишним не будет, торопитесь поучаствовать. Построение агентов, а особенно бизнесовых, а тем более безопасных - одна из востребованных тем уже сейчас.

https://shad.yandex.ru/agentsecurityweek

#free

AI разработка web проектов без велосипедов

Делаю AI-агентов и различные веб-проекты, заметил закономерность: модель охотно лепит самописы там, где давно есть готовые популярные решения. Next/React она знает отлично, но как доходит до инфраструктуры вокруг, хочется заругаться (когда ты всё проглядел а оно уже собрано). Прошёлся по стеку своих проектов и собрал список того, что стоит брать сразу, включая пару вещей, которые модели обычно не предлагают сами.

1️⃣ Realtime и стриминг

Socket.IO. Realtime-связь фронта и бекенда: стриминг токенов от LLM, прогресс агента, каналы событий, живые обновления UI. Готовые реконнекты и доставка, не надо писать руками. (даже не пытайтесь в самописы нейронкой, замучаетесь потом ревьюить и править).

Socket.IO-postgres-adapter. Масштабирование Socket.IO между инстансами через Postgres вместо Redis. Если база и так есть, лишний сервис не нужен.

2️⃣ Очереди и фоновые задачи

Pg-boss. Очереди прямо на Postgres: ретраи, cron, dead letter queue, приоритеты. Модели почти никогда сюда не смотрят, рефлекторно предлагают Redis и BullMQ, даже когда база одна и очередь нужна для трёх джобов в сутки.

Inngest / Trigger.dev. Serverless-воркфлоу с шагами и вебхуками для сложных пайплайнов.

Dockerode. Node-обёртка над Docker Remote API: управление контейнерами, образами, стримами прямо из кода вместо шелл-вызовов docker через child_process. Полезно для любых сценариев с программным запуском контейнеров, включая изолированный запуск сгенерированного агентом кода.

3️⃣ Данные и поиск

Prisma ORM. Типобезопасный доступ к БД, миграции, автогенерация типов. Нейронка с ней работает, как боженька. Не приходится лезть в БД а всю схему БД моделька знает из файла схемы, лежащего в проекте, который и является источником истины. Плюс ко всему, призма не даст сломать миграции или как-то криво их применить агенту.

Drizzle. Альтернатива Prisma без отдельного движка, миграции обычным SQL, ближе к базе. Модели реже про неё вспоминают, хотя в проде она встречается не реже. С некоторым допилом поверх можно тоже прийти к единой схеме как и в призме.

Pgvector. Векторы прямо в Postgres. RAG без отдельного сервиса примерно до 10M эмбеддингов. в 90% случаев закрывает все наши векторные хотелки без прибегания к отдельным векторым бд.

Meilisearch / Typesense. Полнотекстовый и векторный поиск с морфологией вместо LIKE и самописных токенизаторов.

4️⃣ Хранилища

Garage вместо MinIO. MinIO больше не безопасный дефолт: в декабре 2025 проект перевели в maintenance mode, в феврале 2026 репозиторий заархивировали с пометкой «no longer maintained». Garage от Deuxfleurs живой, тот же S3-протокол, спроектирован под self-hosted мультинодовый кластер. Модели по инерции всё ещё советуют MinIO, потому что так было в датасетах.

5️⃣ Эмбеддинги

Multilingual-e5-small. Мультиязычные эмбеддинги локально на CPU, компактная модель, не требует GPU. Разумный выбор для недорогого хостинга: BGE-M3 и e5-large точнее на части задач, но для бюджетного CPU-инстанса small-версия достаточна и заметно легче по ресурсам. Без OpenAI и утечек данных. Именно ее во всех проектах и использую.

6️⃣ LLM-инфраструктура

Vercel AI SDK. Стриминг в React/Next из коробки, useChat/useCompletion, 20+ провайдеров через единый интерфейс.

LiteLLM. Единый API к 100+ LLM с фоллбэками и ретраями вместо provider-specific клея на каждый релиз. Важно, что умеет в статистику по токенам и билинг. Перешел на нее с Cli Proxy Api.

Instructor / Outlines. Структурированный вывод по Pydantic/Zod-схемам вместо ручного парсинга JSON через regex.

7️⃣ Агентные фреймворки

Mastra. TS-фреймворк для продакшен-агентов с готовой памятью поверх Postgres. Прямой конкурент LangChain/LangGraph, но нативно на TS, без питонячьей экосистемы.

Eve (пока в бете, но уже интересен) Для личных, семейных, командных агентов. Разделение простое: Mastra под бизнес-задачи, eve под персональные. Не перевариваю всяких гермесов и опен клав, почему, сам не знаю, наверное из за отвращения к перехайпленным решениям.

8️⃣ Авторизация

better-auth. Гибче классического NextAuth, из коробки организации, роли, 2FA.

Парадокс сабагентов, роёв и прочих мультиагентных систем

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

Откуда это вообще пошло. Всё чаще наблюдаю картинку как люди торопятся подключить как можно больше агентов в свой харнесс, при этом даже в один поток еще работу не наладили. Что они ожидают увидеть в таком случае на выходе? Мне не понятно. Думаю, им тоже. Ощущается, что они заражены какими-то постами блогеров или какими-то хайповыми роликами/статьями, воспринимают это как решение большинства проблем, но предметно объяснить какую проблему они этим подходом решают, не могут.

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

Впервые щупать сабагентов я начал на Claude моделях, когда было жесткое ограничение в 200 000 токенов контекста, а модели могли выбирать не самый оптимальный путь мышления перед реализацией задачи. Тогда сабагенты выглядели как инженерный приём, который позволяет:
1️⃣ Экономить контекст. Сабагент получил задачу, выполнил ее, передал результат основному агенту.
2️⃣ Сузить фокус агента на конкретной задаче. Сабагент и агент работают внутри своих окон, каждый может иметь свой системный промпт (я про промпт, описывающий работу сабагента/агента, а не про тот случай, когда сейчас GPT или Claude могут сами спавнить в любой момент себе помощников, которых вы заранее не прописывали).

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

И напомню, что 200к контекста - не совсем те 200к, которые мы можем взять и использовать в полной мере. На старте, пока не появились скиллы и были только MCP, в легкую могло уходить по 30-40к токенов на содержание MCP в контексте, и буфер для сжатия контекста при компакте в районе 40к контекста. Даже на самых оптимизированных конфигах по факту мы имели на старте не 200к, а примерно 140к свободного для работы контекста. Это теперь кажется диким, ведь сейчас на среднем проекте только сбор информации по проекту перед реализацией какой-либо фичи уже может достичь 100к+ контекста.

Далее вендоры стали добавлять собственных системных сабагентов в наши харнессы, там и модель можно использовать попроще и побыстрее, и промпты заранее нужные заготовлены, и обслуживать это не надо. Все работает из коробки. Например, какой-нибудь explore агент для сбора контекста по проекту и последующей передачи его основному агенту, яркий тому пример. И качество компактов сильно подтянули, можно было спокойно переживать 2-4 компакта и все нужные детали всё еще агент учитывал, можно было сильно не переживать, а нужный контекст после компакта добирался. К тому же, у Claude появился 1 миллион контекста, у GPT тоже (но в какой-то момент они свернули не туда, и жестко его порезали). Но этот миллион контекста не работал так надежно, как хотелось бы, часто после 30-40% заполнения уже начинались явные проблемы в работе и потеря фокуса на задаче (сейчас с этим всё гораздо лучше).

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

1️⃣ Основной агент на старте запроса собирает контекст, даже если он это сделал в минимальном размере и поручил основной сбор сабагенту, сабагент заново читает ВЕСЬ контекст, отдает саммари основному агенту. Основной агент, перед тем как начать выполнять задачу, всё равно пойдет читать связанные файлы чтобы посадить новый код в известное ему место, а не по наводке агента по ресерчу. Итого имеем почти двухкратное чтение контекста, а мы еще даже код писать не начали. Время, кстати, тоже теряем. У GPT 5.6 буквально в системном промпте указано, что он должен спавнить сабагента для сбора контекста при любом запросе. Даже когда вы обсудили с ним большую часть реализации, и в целом он сам уже коснулся всех нужных файлов в достаточной степени, чтобы сделать какой-то вывод и распланировать задачу, он все равно будет спавнить агента который опять всё заново будет читать. Это бред. Так быть не должно. Он сам уже все карты на руках имел. Ах да, еще и не забываем что уходит приличное количество токенов на мышление и генерацию промпта от основного агента -> сабагенту, и после отработки сабагента происходит тоже самое в обратную сторону. Экономия, говорите? Ну, нет. Звучит это всё как какой-то заговор на то, чтобы мы больше токенов сжигали. Оптимизация ради оптимизаций порождает отрицательную эффективность.

❓ Что с этим делать? Брать запуск сабагентов под контроль исходя из вашего воркфлоу, а не из-за пожеланий вендоров в системном промпте. Допускаю, что каких-то кейсах запуск агента по ресерчу будет ценным шагом, особенно на новых фреймворках когда надо перелопатить и код в проекте, и документацию, и внешние источники с документацией библиотек. Это скорее крайние случаи в проектах с непопулярным набором фреймворков и библиотек. Иначе у основного агента мозги от кол-ва информации закипят и контекст действительно забьется мусором. Мои советы релевантны скорее для общей массы веб проектов. Конечно же, крайние случаи надо рассматривать индивидуально.

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

❓ Что с этим делать? Отключать на 100%, как мы ранее уже решили, конечно их не будем, но контролировать - обязательно. Для передачи задач и отчетов между агентом и сабагентом нужно заключать в рамки строгого контракта: что, в каком виде и с какой степенью глубины и детальности должно передаваться. Это можно буквально зашить в правилах агента, он будет составлять задачу для сабагента в нужном вам формате и указывать ему формат отчета, по которому он должен будет вернуть результат работы, что значительно повысит качество их взаимодействия и сбережет ваши нервы.

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

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

Что думаете? Может я их "готовить" не могу, и у вас сложилось всё куда удачнее и стабильнее с мультиагентами?