А.3 Инструментарий разработчика
Метафора (вводная для всего раздела)
Инструментарий для агентов - это не "выбери один фреймворк и пиши". Это скорее набор свёрл в мастерской: для бетона нужна одна насадка, для дерева - другая, для металла - третья. Универсального инструмента нет. Ваша задача как инженера - знать, какой инструмент под какую задачу, и уметь комбинировать их в production-системе.
А.3.1 Фреймворки: от низкого до высокого уровня
Метафора
Выбор фреймворка - как выбор между языком ассемблера и Python. Ассемблер даёт полный контроль над каждым байтом, но писать на нём долго. Python позволяет сделать то же самое в 10 раз быстрее, но вы полагаетесь на абстракции, которые иногда ведут себя неожиданно.
Спектр контроля vs простоты
Ключевой инсайт, который часто упускают: LangGraph не просто "сложнее" CrewAI. Это принципиально другой уровень абстракции. LangGraph даёт вам граф состояний, где вы сами определяете переходы. CrewAI даёт вам "роли", которые общаются друг с другом, и всё. Если вам нужна детерминированная, предсказуемая система, где агент не может "сойти с рельс" - LangGraph. Если вам нужно быстро проверить гипотезу - CrewAI.
Алгоритм выбора (решающее дерево)
А.3.2 Сравнительная таблица инструментов
Метафора
Инструменты для агентов - как набор свёрл в мастерской. Нельзя просверлить отверстие отвёрткой, но и не нужен перфоратор для дырки в гипсокартоне.
А.3.3 MCP (Model Context Protocol) - важно для 2025+
Метафора
MCP - это USB-C для AI-агентов. До USB-C у каждого устройства был свой разъём: один кабель для принтера, другой для телефона, третий для внешнего диска. USB-C пришёл и сказал: «Один разъём, один кабель, всё работает». MCP делает то же самое для подключения агентов к инструментам.
Архитектура MCP в трёх сущностях
Что даёт MC
· Единый формат описания инструментов (как OpenAPI, но для агентов).
· Клиенты могут обнаруживать инструменты динамически (не нужно хардкодить список)
· Серверы можно писать на любом языке - главное, чтобы говорили по MCP
Когда внедрять MCP
А.3.4 Выполнение кода: песочницы
Метафора
Агент, который пишет код, - как ребёнок, которому дали коробку спичек. Ребёнок может зажечь спичку и полюбоваться пламенем (полезно), а может поджечь шторы (опасно). Песочница - это комната с бетонными стенами и железным полом. Ребёнок может жечь спички сколько угодно - штор в комнате нет.
Проблема
Агент может выполнить rm -rf / или украсть данные.
Решение
Изолированная песочница.
Сравнение песочниц
Ключевой инсайт о песочницах
Правильно настроенный Docker с read-only rootfs, без --privileged, с ограничениями по CPU/памяти - это приемлемый уровень изоляции для большинства сценариев. Если вы работаете в облаке (AWS, GCP) - вы уже доверяете своей облачной инфраструктуре. Docker на вашем сервере не менее безопасен, если вы его правильно настроили. E2B и Modal - это не столько про безопасность, сколько про удобство: вы не настраиваете инфраструктуру сами.
Минимальные требования к песочнице (контрольный список)
· Нет доступа к сети (или только белый список из 2-3 доменов)
· Нет доступа к хостовой файловой системе
· Ограничение по времени выполнения (например, 30 секунд)
· Ограничение по памяти (например, 512MB) и CPU
· Невозможность "вырваться" в хостовую ОС (no container escape)
Мы научились выбирать паттерн, подбирать фреймворк, подключать инструменты через MCP и запускать код в песочнице. Но осталась проблема, которая убивает любого агента в production: память.
Агент без памяти - это человек с амнезией. Он знает, как говорить и пользоваться инструментами, но забывает, что сказал минуту назад и что уже сделал. Без памяти даже самый умный агент зацикливается или начинает каждый раз начинать с нуля.
Память бывает краткосрочная (то, что агент «держит в голове» в рамках диалога) и долгосрочная (факты, которые он может найти в архиве между сессиями). Разберёмся, как их реализовать без взрыва контекста.
А.4 Управление состоянием и памятью
Метафора (вводная)
Агент без памяти - это человек с амнезией. Он знает, как говорить и пользоваться инструментами, но забывает, что сказал минуту назад и что уже сделал. Память для агента - это не "приятная опция", а базовое требование для любой задачи длиннее одного шага.
Краткосрочная память - это история сообщений, которая передаётся в LLM при каждом вызове. Когда она превышает контекстное окно, старые сообщения обрезаются или сжимаются.
Долгосрочная память - это векторная база данных, куда агент сохраняет ключевые выводы после выполнения задачи, а перед началом новой ищет похожие прошлые задачи.
Без краткосрочной агент не ведёт диалог.
Без долгосрочной - не учится на прошлых взаимодействиях. Но и та и другая требуют инженерных решений: как хранить, как искать, когда забывать.
А.4.1 Краткосрочная vs долгосрочная память
Ключевой инсайт
Краткосрочная память - это то, что агент "держит в голове". Долгосрочная - то, что он может "найти в архиве". Без краткосрочной памяти агент не может вести диалог. Без долгосрочной - не учится на прошлых взаимодействиях.
Как работает краткосрочная память
Агент начинает с пустого состояния (или с загруженной предыдущей сессии)
Каждый шаг: добавляет свои рассуждения и действия в историю
История передаётся в LLM при каждом вызове
Когда история превышает контекстное окно - старые сообщения "выпадают" (обрезаются или сжимаются).
Как работает долгосрочная память (через векторную БД)
Агент получает задачу. Ищет в векторной БД похожие прошлые задачи или релевантные факты. Добавляет найденное в краткосрочную память (контекст). После выполнения задачи - сохраняет ключевые выводы обратно в векторную БД.
Долгосрочная память через векторную БД - хорошо. Но есть более лёгкий и прагматичный механизм, который лежит на стыке памяти и оптимизации затрат.
Семантическое кэширование - это когда агент помнит не только точные вопросы, но и похожие.
Если пользователь спросил «погода в Москве», а через минуту другой - «сколько градусов в столице», агент не должен снова вызывать API погоды и тратить токены на LLM. Он просто возвращает ответ из кэша. Экономия денег и времени. Посмотрим, как это устроено.
А.4.2 Семантическое кэширование
Метафора
Семантическое кэширование - это умный блокнот, который помнит не только точные вопросы, но и похожие. Если пользователь спросил "погода в Москве", а через минуту другой пользователь спросил "сколько градусов в столице" - агент не должен снова вызывать API погоды и тратить токены на LLM.
Как это работает
Что даёт семантическое кэширование
· Преимущество
· Пример экономии
· Снижение затрат на LLM
· Повторяющийся запрос - 0 токенов вместо 1000+
· Снижение латентности
· 50ms (поиск в БД) вместо 2-3 секунд (LLM)
· Предсказуемость
· Одинаковые запросы дают одинаковые ответы
Когда включать
· Повторяющиеся запросы от пользователей (например, FAQ в чат-боте)
· RAG с медленным поиском (кэшируем результат поиска + генерацию)
· Дорогие вызовы LLM (например, long-context с 100K токенов)
Теория памятью не ограничивается.
В production нужно принимать конкретные решения: какой размер контекста, когда обрезать, когда сжимать, как часто сохранять в долгосрочную БД, какую стратегию вытеснения использовать.
Собрали контрольный список для инженера: сколько сессий хранить, как часто делать суммаризацию, как бороться с дрейфом личности.
И главный инсайт: память - это не только про «запомнить», но и про «забыть».
А.4.3 Практические рекомендации по памяти для агента
Контрольный список для production
Ключевой инсайт, который часто упускают
Память - это не только про "запомнить". Это ещё и про "забыть". Если агент хранит всю историю всех сессий, контекст раздувается, latency растёт, качество падает. Нужны стратегии обрезания (trimming), сжатия (summarization) и вытеснения (eviction).
У нас есть паттерн, инструменты, память. Агент работает.
Но выдержит ли он реальную нагрузку? Не упадёт ли при первом нестандартном запросе? Не украдут ли через него данные?
И главное - можно ли на этом построить бизнес, не прогорев на токенах через полгода? Надёжность, безопасность и бизнес-модель - это три ножки табурета production-агента. Если хотя бы одна ножка сломана, система падает. Разбираем каждую.
