Введение
Если попросить чат-бота найти отель в Лондоне, он выдаст список названий и предоставит вам разбираться дальше. Если попросить агента — он проверит доступность, сравнит цены на разных сайтах, забронирует номер и пришлёт подтверждение на почту. Этот разрыв между «сообщить информацию» и «сделать что-то за вас» — вся суть агентного ИИ, и именно поэтому термин превратился из исследовательской сноски в пункт почти каждой инженерной дорожной карты на 2026 год.
Сложность не в идее. Идея понятна всем. Сложность в том, что «агентный ИИ» сейчас заменяет пять или шесть отдельных инженерных концепций, которые смешиваются в маркетинговых презентациях, и если их не разделять, на выходе получается агент, не способный запомнить разговор, не умеющий обращаться к нужным инструментам или прекрасно работающий на демо и рассыпающийся при реальной нагрузке. Примерно 88% создаваемых сегодня ИИ-агентов так и не добираются до продакшена, и значительная часть этих провалов никак не связана с базовой моделью. Всё упирается в то, разобралась ли инженерная команда в этих пяти концепциях до начала разработки.
В этой статье разбираются пять идей, на которых реально держатся агентные системы: как агенты выходят за свои пределы для использования инструментов, как они вообще что-либо запоминают, как принимают решение о следующем шаге, как несколько агентов работают в команде, не мешая друг другу, и как кто-либо понимает, работает ли вся эта конструкция вообще. По ходу текста даны ссылки на ресурсы и фреймворки, чтобы можно было углубиться в тот аспект, который важнее всего для вашей задачи.
1. Использование инструментов и Model Context Protocol
Большая языковая модель (LLM) сама по себе способна только генерировать текст. В момент, когда требуется обратиться к базе данных, вызвать API, прочитать файл или отправить письмо, нужен мост между рассуждениями модели и внешним миром. Этот мост и называют «использованием инструментов», и годами его построение означало написание кастомной интеграции для каждой отдельной комбинации модели и сервиса. Десять ИИ-приложений и сотня инструментов раньше означали что-то около тысячи хрупких, одноразовых интеграций.
Anthropic представила Model Context Protocol (MCP) в ноябре 2024 года именно для решения этой проблемы, и кривую внедрения с тех пор сложно переоценить. К марту 2026 года официальные SDK набирали 97 миллионов ежемесячных загрузок — рост примерно со 100 000 в первый месяц после запуска; скачок, которого npm-пакет React достиг за три года, а MCP — примерно за шестнадцать месяцев. В декабре 2025 года Anthropic передала MCP недавно созданному Agentic AI Foundation под эгидой Linux Foundation, а OpenAI и Block присоединились как сооснователи; AWS, Google, Microsoft, Cloudflare и Bloomberg вошли как поддерживающие участники — это тот самый шаг, который превращает протокол вендора в общую инфраструктуру, которую никто не сможет тихо вывести из эксплуатации.
Однако для инженера важны не цифры загрузок. Важно то, что протокол реально стандартизирует: модель может запросить у любого MCP-совместимого сервера информацию о его возможностях, а затем вызывать его инструменты по одному и тому же JSON-RPC шаблону каждый раз, независимо от того, кто создал сервер. Клиент обнаруживает доступные инструменты через манифест возможностей сервера и вызывает их стандартными запросами — это означает, что вы перестаёте перестраивать одну и ту же обвязку для каждой новой интеграции. Если вы подключаете агента к Slack, Notion, GitHub или базе данных, есть реальный шанс, что кто-то уже собрал и опубликовал MCP-сервер для этого. Официальный реестр MCP и community-каталоги вроде PulseMCP — хорошие отправные точки перед тем, как писать кастомную интеграцию с нуля.
Честная оговорка, которую стоит знать: MCP не бесплатен. Он добавляет ощутимые накладные расходы по токенам по сравнению с прямым вызовом API, и для высоконагруженных пайплайнов, где каждый токен на счету, многие команды в 2026 году по-прежнему выбирают легковесные CLI-вызовы или прямые запросы. MCP оправдывает себя, когда нужно корректно обработать OAuth, когда вы обслуживаете нескольких арендаторов с жёсткими границами данных или когда не-инженеры в вашей команде должны подключать агента к инструменту без самостоятельного написания SDK-интеграции.
2. Память и контекстная инженерия
Каждый вызов LLM по умолчанию не имеет состояния. Модель понятия не имеет, что происходило пять минут назад, если только вы снова не поместите это перед ней. Для одиночного обмена вопросом-ответом это нормально. Для агента, обслуживающего клиента на протяжении нескольких сессий, выполняющего многодневную исследовательскую задачу или управляющего проектом неделями напролёт, модель, забывающая всё между вызовами, практически бесполезна — какой бы умной она ни была в моменте.
Именно здесь память перестала быть запоздалой мыслью и стала отдельной дисциплиной. Три года назад память агента означала запихивание истории разговора в контекстное окно с надеждой, что модель уследит за всем. Серьёзные системы так больше не строят. Память теперь рассматривается как самостоятельный архитектурный компонент, отдельный от контекстного окна, со своими бенчмарками и измеримым разрывом между подходами, которые реально работают, и теми, что нет.
Механика довольно проста, если разложить её по полочкам. Во время разговора слой памяти извлекает факты, которые стоит сохранить, и помещает их в векторную базу данных с тегами пользователя, сессии и агента. Когда начинается новая сессия, система извлекает релевантное через смесь семантического сходства, совпадения ключевых слов и сопоставления сущностей, а затем незаметно внедряет только этот срез в контекст модели перед тем, как она ответит. Агент выглядит так, будто помнит вас. На деле же перед каждым ответом происходит целевой шаг извлечения.
Инструменты вроде Mem0, Zep (построенный на темпоральном графе знаний под названием Graphiti) и Letta стали стандартными отправными точками вместо того, чтобы команды собирали всё с нуля. Разница между ними главным образом в том, какой тип памяти нужен. Mem0 — более простой и широкий вариант для быстрой персонализации. Zep заметно лучше справляется с темпоральными рассуждениями — запросами типа «как изменилось поведение этого клиента после обновления цен» — потому что отслеживает факты с окном валидности (начало и конец), а не просто хранит самую свежую или наиболее похожую запись.
Термин, который теперь звучит рядом с памятью — «контекстная инженерия», и стоит понимать, почему это словосочетание вытеснило «промт-инженерию» во многих обсуждениях. Качество контекста, а не его объём стало реальным ограничивающим фактором для LLM-агентов. Большинство команд даже близко не подходят к использованию полного контекстного окна своих моделей; настоящая задача — выборка, сжатие и структурирование той информации, которая действительно влияет на решения модели, а не просто сваливание всего подряд. Большее контекстное окно не исправляет неряшливую стратегию извлечения. Оно лишь даёт неряшливости больше пространства спрятаться.
3. Циклы планирования и рассуждений
Чат-бот отвечает один раз и останавливается. Агент должен решить, что делать дальше; сделать это; посмотреть на результат; и решить снова — иногда десятки раз подряд — без того чтобы человек подсказывал ему на каждом шагу. Этот цикл является реальным механическим различием между «ИИ который говорит» и «ИИ который работает», и почти каждый агентный фреймворк сегодня представляет собой вариацию одной и той же базовой схемы.
У этой схемы есть название и конкретное происхождение. В конце 2022 года исследователи из Google и Princeton опубликовали ReAct: Synergizing Reasoning and Acting in Language Models, предложив чередование шагов рассуждения с действиями вместо того чтобы рассматривать их как отдельные задачи. Структура проста: модель генерирует мысль (thought), предпринимает действие (action), наблюдает результат (observation) и производит следующую мысль на основе только что увиденного. На бенчмарках по ответам на вопросы и интерактивному принятию решений этот подход значительно превосходил чистое имитационное обучение и чистое обучение с подкреплением при всего одном-двух примерах для работы.
С 2022 года изменился не сам базовый цикл; изменилось количество структуры вокруг него. Цепочка рассуждений (Chain-of-thought), рассуждения в стиле ReAct, и few-shot prompting раньше были всем арсеналом. К 2026 году это эволюционировало в то что называют контекстной инженерией — проектирование всей информационной среды вокруг модели а не только промта запускающего цикл. Современные агентные фреймворки добавляют логику повторных попыток самокоррекцию при неудачном вызове инструмента и явную декомпозицию задач чтобы расплывчатая цель вроде «исследуй этот рынок и обобщи конкурентный ландшафт» разбивалась на шаги которые модель может реально верифицировать по одному.
Именно здесь проблемы надёжности обычно всплывают первыми. Цикл рассуждений без контроля может быстро сжигать токены застревать на повторении одного неудачного действия или вовсе уходить от первоначальной цели. Данные продакшен-трейсов показывают что значительная доля отказов LLM-вызовов в агентных системах вызвана превышением лимитов скорости именно во время таких повторяющихся зацикленных вызовов — полезное напоминание о том что цикл планирования это не только концепция рассуждений но и то что нужно бюджетировать и мониторить как любой другой элемент инфраструктуры.
4. Оркестрация множества агентов
У одиночного агента с одним контекстным окном есть потолок. Дайте ему целую кодовую базу длинный исследовательский бриф и набор бизнес-правил одновременно — где-то внутри он начнёт терять детали особенно те что запрятаны поглубже во всём этом контексте. Стандартным решением к 2026 году стало не увеличение модели а разделение работы между несколькими агентами у каждого свой фокусированный контекст координируемые чем-то стоящим над ними.
Схему обычно описывают как оркестратор и суб-агенты: один оркестрирующий агент координирует специализированных суб-агентов каждого со своим выделенным контекстом параллельно вместо того чтобы один агент пытался удержать всё у себя в голове одновременно. И это не теоретическое улучшение. Fountain платформа найма использовала многоагентную оркестрацию чтобы добиться на 50% более быстрого скрининга кандидатов и на 40% более быстрого онбординга сократив время закрытия вакансии у одного клиента с недель до менее чем 72 часов.
Если выбирать как строить это самостоятельно ландшафт фреймворков устоялся в несколько чётких направлений а не десятки конкурирующих вариантов. LangGraph обладает самым крутым порогом входа среди основных вариантов но даёт наибольший контроль и наиболее зрелую готовность к продакшену со встроенными чекпоинтами (checkpointing) и явным управлением состоянием. CrewAI легче всего освоить он структурирует многоагентную работу вокруг ролей и задач будучи наиболее интуитивным выбором когда работа естественно разделяется по специализированным ролям. AutoGen лидирует в исследовательских и академических кругах благодаря гибким conversational паттернам между агентами хотя продакшен-внедрение отстаёт от двух других. Ни один из них не является универсально «лучшим». Правильный выбор зависит от того нужен ли вашей команде тонкий контроль или быстрый путь до прототипа.
Вторая половина этой концепции — дать агентам построенным на разных фреймворках вообще возможность общаться друг с другом это отдельная проблема от предоставления одному агенту доступа к инструментам. Google представила протокол Agent2Agent (A2A) в апреле 2025 года специально для этого сейчас он находится под Linux Foundation как опенсорсный проект. Если MCP стандартизирует как агент общается с инструментами то A2A стандартизирует как агенты общаются друг с другом позволяя им обнаруживать возможности друг друга и сотрудничать над задачей без раскрытия внутренней памяти или логики друг другу. Два протокола спроектированы дополнять друг друга а не конкурировать видеть оба названными в архитектуре системы становится нормальным ожиданием к середине 2026 года.
5. Оценка наблюдаемость и защитные ограждения
Это та концепция которая определяет попадёт ли всё вышеперечисленное вообще в релиз и именно её инженеры склонны недофинансировать потому что это наименее захватывающая часть сборки. Цифры объясняют почему она не может оставаться запоздалой мыслью: примерно 88% ИИ-агентов проваливаются не дойдя до продакшена, но те что доходят возвращают в среднем 171% ROI. Это немаленький разрыв это разница между проектом который тихо кладут на полку и тем который становится реальным конкурентным преимуществом; закрывается же этот разрыв главным образом инженерной дисциплиной а не лучшей моделью.
Как эта дисциплина выглядит на практике? Начинается всё с трейсинга (tracing) — возможности увидеть что именно делал агент на каждом шагу какой инструмент вызывал что наблюдал где ошибся. LangSmith, работающий в паре с LangGraph стал распространённым выбором для такого фреймворк-агностичного трейсинга и систематической отладки в продакшене аналогичные инструменты существуют и для других основных фреймворков. Без этого отладка агента некорректно отработавшего в продакшене сводится к гаданию потому что у вас нет записи рассуждений которые его туда привели.
Оценка (evaluation) — это вторая половина она отличается от трейсинга. Трейсинг говорит вам что произошло оценка говорит было ли это действительно хорошо. Более новые инструменты Microsoft в этой области например включают рубричный оценщик автоматически генерирующий критерии оценки исходя из конкретного контекста агента затем оценивающий его производительность по взвешенным измерениям давая более нюансированный взгляд на качество чем простой зачёт или незачёт. Индустрия также начала стандартизировать где именно в жизненном цикле агента размещать проверки безопасности один из возникающих подходов определяет пять контрольных точек валидации во время работы агента охватывающих вход собственные рассуждения модели внутреннее состояние выполнение инструментов и финальный выход выражаемых как портативная версионируемая политика а не разрозненный кастомный код.
Ничто из этого не заменяет человеческое суждение оно лишь указывает куда его направить.Gartner прогнозирует что более 40% проектов агентного ИИ будут отменены к концу 2027 года, основными драйверами называют рост затрат неясную бизнес-ценность и недостаточный контроль рисков; каждый из этих режимов отказа — это то что оценка и наблюдаемость созданы ловить заранее прежде чем они превратятся в отменённый проект а не исправимый баг.
Заключение
Ни одна из этих пяти концепций хорошо не работает сама по себе. Агент с отличным доступом к инструментам но без памяти забывает каждый урок который только что усвоил. Агент с надёжным циклом рассуждений но без оркестрации упирается в потолок как только задача становится слишком большой для одного контекстного окна. Агент делающий всё вышеперечисленное но без слоя оценки представляет собой чёрный ящик который вы надеетесь будет вести себя хорошо в продакшене. Инженеры получающие реальную отдачу от агентного ИИ в 2026 году — это не те кто выбрал самый яркий фреймворк а те кто понял как использование инструментов память планирование оркестрация и оценка складываются вместе как единая система и строили соответственно.
Если начинать с нуля вам не нужно осваивать все пять до написания первой строки кода выберите одну хорошо ограниченную задачу подключите одного агента через MCP для доступа к инструментам добавьте базовый слой памяти посмотрите как он рассуждает через несколько реальных прогонов и тянитесь к многоагентной оркестрации только когда один агент действительно перестанет справляться с масштабом задачи оценка должна присутствовать с первого дня а не прикручиваться после того как что-то сломалось именно такой порядок больше чем любой конкретный выбор фреймворка отделяет агентов попадающих в продакшен от тех 88% которые туда не попадают.