Корпоративный ИИ-агент — это не языковая модель с длинным промптом. Это замкнутый цикл: модель получает цель, выбирает действие, вызывает внешний инструмент, читает результат и решает, каким будет следующий шаг — пока цель не достигнута, пока агент не застрял или пока не исчерпан бюджет шагов. Под капотом всего четыре компонента: модель, инструменты, память и контроль. В опросе McKinsey за ноябрь 2025 года (1993 респондента примерно из 105 стран) около 62% организаций экспериментировали с агентами, но лишь около 23% вывели их на масштаб, а Gartner прогнозирует, что более 40% проектов агентного ИИ будут закрыты до конца 2027 года. Этот разрыв почти никогда не связан с моделью.
Что на самом деле отличает агента от чат-бота
Разница не в качестве ответа. Она в том, кто определяет порядок операций. В чат-боте решает человек: он спрашивает, получает текст и сам решает, что с ним делать. В классической автоматизации решает разработчик заранее: процесс описан блок-схемой, и каждая ветвь определена на этапе разработки. У агента это решение переносится на время выполнения — модель сама выбирает, какой инструмент вызвать, в каком порядке и когда остановиться.
Это единственное различие, которое имеет значение, и оно же источник всех рисков. Как только порядок операций перестаёт быть зафиксированным заранее, систему нельзя тестировать так, как тестируют обычное программное обеспечение, и нельзя рассчитывать, что вчерашний удачный прогон сегодня пойдёт тем же путём.
| Свойство | Чат-бот | Классическая автоматизация | Агент |
|---|---|---|---|
| Кто задаёт порядок операций | Пользователь | Разработчик, на этапе разработки | Модель, во время выполнения |
| Доступ к системам | Обычно отсутствует | Фиксированный и заранее заданный | Динамический, через слой инструментов |
| Поведение при сбое | Возвращает неверный ответ | Останавливается и сообщает об ошибке | Продолжает работу и усугубляет ошибку |
| Что проверяют перед запуском | Качество формулировок | Известные сценарии | Распределение результатов по прогонам |
Ключевая мысль: сломавшаяся автоматизация останавливается. Сломавшийся агент продолжает работать. Именно поэтому контроль — это компонент системы, а не то, что добавляют в конце.
Цикл выполнения: планировать, действовать, наблюдать
Независимо от поставщика, языка и фреймворка любой агент выполняет один и тот же цикл. Модель получает цель и текущее состояние мира, вырабатывает решение о следующем шаге, отправляет вызов внешнему инструменту, получает результат — и снова запускает себя, уже с этим результатом в контексте. Цикл завершается, когда модель объявляет о завершении, когда инструмент возвращает блокирующую ошибку или когда внешний механизм прерывает работу.
Важное слово здесь — наблюдать. Агент не знает о мире ничего, кроме того, что инструменты возвращают ему текстом. Если CRM вернула пустое поле, то для агента у клиента действительно нет телефона. Поэтому качество наблюдения — инженерная переменная первого порядка, а не технический нюанс.
| Этап цикла | Что происходит на самом деле | Типичный режим отказа |
|---|---|---|
| Приём цели | Цель становится начальным контекстом рядом с системными инструкциями | Размытая цель, дающая разный путь в каждом прогоне |
| Планирование шага | Модель выбирает инструмент и его аргументы | Верный инструмент, неверный аргумент — самый частый сбой |
| Выполнение | Слой инструментов выполняет вызов к реальной системе | Слишком широкое разрешение, допускающее разрушительное действие |
| Наблюдение | Результат возвращается в контекст | Длинный ответ, вытесняющий ранее полученную критичную информацию |
| Решение | Продолжить или остановиться | Бесконечный цикл, выжигающий бюджет до потолка |
Четыре компонента, из которых собран любой агент
Разберите агента на части — и получите четыре компонента. Три из них не модель, и именно там сосредоточена большая часть инженерной работы и почти все сбои.
| Компонент | Его задача | Что ломается, когда он слабый |
|---|---|---|
| Модель | Вырабатывает решение о следующем шаге | Изящные формулировки при ошибочных рассуждениях; обновление модели не чинит остальные компоненты |
| Инструменты | Единственный интерфейс агента с реальностью | Неточное описание инструмента ведёт к неправильному использованию даже с отличной моделью |
| Память и контекст | То, что агент знает в момент принятия решения | Вытесненная критичная информация или загрязнённый контекст, уводящий агента не туда |
| Контроль | Ограничения, разрешения, бюджет шагов и точки утверждения | Нет способа остановить ошибку до того, как она затронет клиента или систему |
В проектах, которые мы видим, первая реакция на неполадку почти всегда — сменить модель. В большинстве случаев проблема не в этом. Точные описания инструментов, структурированный вывод вместо свободного текста и внятное условие остановки повышают долю успешных прогонов сильнее, чем любое обновление модели.
Слой инструментов: что на самом деле изменил MCP
Ещё недавно каждое соединение между моделью и корпоративной системой писали с нуля: отдельная интеграция под каждую пару «модель — система». Model Context Protocol заменил это единым слоем — сервером, который объявляет инструменты, и клиентом, который их вызывает.
Стабильная редакция спецификации от 28 июля 2026 года — самая крупная ревизия протокола с момента его запуска. Сессии на уровне протокола и заголовок Mcp-Session-Id убраны из транспорта Streamable HTTP; рукопожатие initialize упразднено; списки инструментов, ресурсов и промптов перестали различаться от соединения к соединению, что делает их кешируемыми. Вместе с этим появились запросы с несколькими обменами, маршрутизация по заголовкам, формальный механизм расширений и усиленная авторизация. Сервер, которому нужно состояние между вызовами, теперь получает его через явный дескриптор, выданный сервером и передаваемый как обычный аргумент инструмента.
Почему это важно тем, кто не пишет код: протокол без состояния можно развернуть за обычным балансировщиком нагрузки, масштабировать горизонтально и наблюдать штатными средствами. Иначе говоря, слой инструментов перестал быть исследовательским проектом и стал инфраструктурой, которую можно бюджетировать, эксплуатировать и аудировать. Если вы планируете держать этот слой на собственной инфраструктуре, полная модель затрат — в нашем руководстве по запуску агентов на своём оборудовании.
Контекст — это бюджет, а не склад
Самая частая ошибка проектирования — относиться к окну контекста как к хранилищу. Это не хранилище. Это бюджет, расходуемый на каждом шаге, и вы платите за него заново при каждом вызове. Агент, проходящий двадцать шагов, оплачивает собственную историю двадцать раз.
Отсюда следуют три проектных решения. Возвращать из инструментов компактный структурированный вывод, а не целые документы. Сжимать историю в сводку состояния после фиксированного числа шагов. Извлекать корпоративные знания во время выполнения вместо предзагрузки. Финансовая сторона этих решений разобрана в нашем руководстве по снижению стоимости инференса.
Где это ломается на практике
Три причины объясняют большую часть сбоев, с которыми мы сталкиваемся.
Накапливающиеся ошибки. В цикле ошибка на третьем шаге не остаётся на третьем шаге. Она попадает в контекст и оттуда питает все последующие решения. Поэтому видимый сбой проявляется далеко от места, где он возник, и отладка агента требует разбора полного прогона, а не одного ответа.
Оптимистичное измерение. Привычная метрика успеха спрашивает, справился ли агент один раз в благоприятных условиях. В продакшене важна стабильность: одна и та же задача, сто прогонов, сколько завершились корректно. Разрыв между этими двумя числами — это разрыв между эффектной демонстрацией и системой, на которую можно положиться. Как его закрыть, разобрано в нашем руководстве по оценке агентов.
Agent washing. По оценке Gartner, из тысяч поставщиков, продающих агентные возможности, лишь около 130 предлагают настоящий продукт; остальные переименовывают существующих ассистентов, RPA и чат-ботов. Вопрос, который быстрее всего отсеивает лишнее на встрече с продавцом: какие инструменты этот агент умеет вызывать и кто решает, когда он их вызывает.
В той же записке Gartner есть и другая сторона истории: к 2028 году примерно 15% повседневных рабочих решений будут приниматься автономно, а 33% корпоративных приложений будут включать агентные возможности — против менее чем 1% в 2024 году. Направление ясно; ломаются сроки и ожидания.
Чек-лист перед первым агентом
- Определите задачу, которая завершается. Задачу с однозначным условием завершения, а не открытую зону ответственности.
- Посчитайте инструменты. Если у первого агента больше десяти инструментов, вы, скорее всего, описали должность, а не задачу.
- Пишите описания инструментов как контракты. Что на входе, что на выходе, что происходит при сбое и когда инструмент применять нельзя.
- Задайте бюджет шагов и бюджет токенов. Жёсткий потолок, останавливающий цикл даже тогда, когда модель уверена, что идёт верным путём.
- Отметьте необратимые действия. Отправка письма, списание средств, удаление, изменение статуса, видимого клиенту — всему этому нужна точка человеческого утверждения.
- Определите разрешения до того, как напишете промпт. Ущерб ограничивает модель разрешений, а не формулировка инструкций. Подробный разбор — в нашем руководстве о границах агента.
- Записывайте каждый прогон. Без полного журнала вызовов и результатов нет ни отладки, ни улучшения.
Если вы предпочитаете начать со структурированной оценки готовности, начните с наших направлений экспертизы. Если вы уже знаете, что хотите запустить, свяжитесь с нами по поводу этапа внедрения.
Частые вопросы
Чем ИИ-агент отличается от обычной автоматизации?
В автоматизации порядок операций задан заранее разработчиком. У агента модель выбирает действия во время выполнения, исходя из цели и того, что она наблюдает. Поэтому автоматизацию тестируют по известным сценариям, а агента — по распределению результатов на повторяющихся прогонах.
Нужна ли особенно сильная модель, чтобы построить агента?
В большинстве случаев нет. Доля успешных прогонов определяется качеством описаний инструментов, управлением контекстом и условиями остановки в большей степени, чем выбором модели. Более сильная модель какое-то время маскирует проблемы проектирования, но и делает каждый шаг цикла дороже.
Что такое MCP и почему о нём все говорят?
Model Context Protocol — это единый протокол подключения моделей к инструментам и источникам данных. Стабильная редакция от 28 июля 2026 года сделала его протоколом без состояния: сессий на уровне протокола больше нет, списки инструментов кешируются, авторизация усилена. На практике это позволяет разворачивать слой инструментов как обычную инфраструктуру, а не как разовый проект.
Сколько времени занимает вывод первого агента в продакшен?
Одна задача с тремя-пятью инструментами и точкой человеческого утверждения обычно доходит до продакшена за четыре-восемь недель. Большая часть этого времени уходит не на построение цикла, а на чистую интеграцию с системами, проектирование разрешений и сборку набора тестов.
Какой признак говорит, что агент не подходит для задачи?
Если процесс можно описать полной блок-схемой без неоднозначных решений, агент не нужен — автоматизация будет дешевле, быстрее и проверяемее. Агент окупается тогда, когда пространство возможностей слишком широко, чтобы описать его заранее.