Обновление MCP 2026-07-28: как stateless-архитектура и долгие задачи поменяли настройку наших ИИ-агентов

Оператор из отдела снабжения написал в чат простой вопрос: «Почему отчёт по остаткам за квартал агент собирает почти до конца рабочего дня, а прогресс мне не показывает — я не понимаю, ушла задача или зависла?» Формулировка обыденная, но за ней — вся боль нашей архитектуры того периода. Мы делали ИИ-агента под сценарии, которые изначально не помещались в модель «вопрос — ответ», и упирались в это каждую неделю. Обновление Model Context Protocol от 28 июля 2026 года стало тем поводом, из-за которого мы, наконец, переделали настройку ИИ-агента честно, а не подпорками.

Синхронный чат, который тянул тяжёлую работу

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

В синхронной схеме это выглядело так: агент вызывает инструмент, инструмент честно молотит, HTTP-соединение висит, клиентский Angular ждёт. Что-то где-то падает по таймауту — а падает всегда, потому что между браузером и MCP-сервером у нас реверс-прокси со своими лимитами. Ответа нет, задача есть, деньги на GigaChat Pro списаны. Мы обкладывали это костылями: свой собственный статус-стор в PostgreSQL, поллинг из фронта, попытки склеить сессию, если пользователь обновил вкладку. Всё это работало, но выглядело как отдельная маленькая ИТ-система вокруг агента, а не как часть агента.

Первый подход: тащить состояние в самом агенте

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

В продакшене всё поплыло. Релиз — воркер перезапустился, сессия потерялась, пользователь получает белый экран. Балансировщик отправил следующий запрос на соседнюю ноду — та про сессию ничего не знает. Автоскейлинг подъезжает, а мы не можем безопасно погасить лишний под, потому что на нём кто-то до сих пор считает свой отчёт. Мы попробовали sticky-сессии, потом Redis для состояния, потом гибрид с PostgreSQL. Каждый шаг убирал одну проблему и добавлял две.

К тому моменту стало ясно: мы боремся не с багами, а с самой моделью — синхронный агент с состоянием в памяти плохо ложится на нагрузки, где задача живёт дольше пода.

Что принёс MCP 2026-07-28

Обновление протокола вышло очень вовремя. Ключевое, что нас зацепило, — переход к stateless-архитектуре, поддержка долгих асинхронных задач и усиленная аутентификация. Формально MCP давно шёл в эту сторону, но именно в июльской спецификации всё собралось в одну согласованную картину: сервер не обязан помнить сессию между вызовами, а длинную работу можно оформить как отдельный ресурс с собственным жизненным циклом.

Для нас это означало три вещи. Во-первых, MCP-серверы теперь можно масштабировать как обычные HTTP-приложения — за балансировщиком, без sticky-сессий, с честным rolling update. Во-вторых, долгие задачи получили нормальный контракт: запустил, получил идентификатор, спрашиваешь статус, забираешь результат — без плясок с висящими соединениями. В-третьих, обновлённая модель авторизации разложила права по местам, куда мы раньше пихали свою обвязку.

Как мы пересобрали настройку ИИ-агента

Мы переписали не всё сразу. Начали с самого больного места — тех самых квартальных отчётов из снабжения. Инструмент, который раньше был обычным вызовом MCP, стал ресурсом типа «долгая задача». Агент теперь не ждёт результат внутри своего цикла рассуждений. Он делает вызов, получает идентификатор задачи, аккуратно сообщает пользователю: «Запустил сводку, обычно занимает несколько часов, пришлю в чат, как будет готово». И идёт заниматься другими запросами.

Настройка ИИ-агента под такую схему потребовала пересмотреть несколько вещей. Мы вынесли всё состояние сессии в PostgreSQL — не как костыль, а как основной источник правды. Промежуточный контекст, история сообщений, ссылки на активные задачи — всё это теперь read-through/write-through через базу, а сам воркер снова стал тонким и заменяемым. Это же убрало старую боль с SIGTERM: под гасится — ничего не теряется, соседний просто подхватывает работу.

Отдельная история — уведомления. Пока задача жила внутри синхронного вызова, пользователь смотрел в спиннер. Теперь агент шлёт в тот же самый чат сообщение, когда фоновая задача завершилась. Технически это web-push плюс запись в базу; UX-ощущение — «агент сам вспомнил и вернулся с ответом». Оператор в снабжении, кажется, первым в компании понял, что это не просто чат, а рабочий инструмент.

Разные типы ИИ-агентов в одной установке

Заодно мы честно признали, что у нас теперь не один агент, а несколько разных типов ИИ-агентов, живущих в одной инфраструктуре. Каждый — под свой класс задач, и настраиваются они по-разному.

Первый — интерактивный чат-агент. Отвечает быстро, ходит в справочники и лёгкие MCP-инструменты, держит диалог с пользователем. Здесь важна отзывчивость: короткие таймауты, стриминг, компактификация контекста.

Второй — фоновый агент-исполнитель. Запускается по команде первого или по событию (пришёл документ, поменялся приказ, наступил месяц). Работает часами, ходит в тяжёлые инструменты, складывает результат в базу и триггерит уведомление. Здесь важна устойчивость: чекпоинты, идемпотентность, повторяемость.

Третий — событийный агент-наблюдатель. Реагирует на изменения в 1С, в CRM, в почте. Обычно короткий по логике, но требовательный к точности классификации: он решает, что за событие произошло и надо ли вообще будить кого-то из остальных. Здесь важна не скорость, а разумная задержка и низкий уровень ложных срабатываний.

Понимание, что перед нами не один агент, а связка, сильно упростило жизнь. Раньше мы пытались одной настройкой ИИ-агента накрыть все три сценария сразу — получалась серединка на половинку. Сейчас у каждого типа свой профиль модели, свои лимиты, свои промпты, свой набор инструментов через MCP.

Что изменилось в работе людей

Разговор об архитектуре быстро становится скучным, если не заканчивать его тем, что почувствовали живые люди. Оператор снабжения перестал жаловаться на висящие отчёты — он теперь запускает сводку, идёт заниматься закупками, а ответ приходит сам, когда готов. Внутренняя команда поддержки перестала разбирать инциденты «а куда делся мой запрос» — сессия хранится в базе, любой воркер её видит. ИИ-агенты и автоматизация фоновых процессов у заказчика перестали конкурировать за одну и ту же архитектуру: интерактив и тяжёлые расчёты живут отдельно, но выглядят для пользователя как один собеседник.

Отдельно порадовал счёт за модель. Раньше при обрыве соединения агент часто повторял часть работы заново — прогресс же нигде не был закреплён. Теперь долгие задачи с чекпоинтами доедают до конца с первого раза, и повторных вызовов GigaChat Pro стало заметно меньше. Порядок величины экономии — ощутимый, точную цифру называть не буду, потому что нагрузка от месяца к месяцу разная, но по ощущениям бухгалтерия перестала спрашивать «а что там опять со счётом».

Что мы забрали для себя как решение

Главный вывод — не технический. Обновление MCP просто дало нам легитимный повод сделать то, что давно назрело: разделить типы агентов и настраивать каждый под свой класс задач. ИИ-агенты как решение для B2B перестают быть «умным чатом» ровно в тот момент, когда впервые сталкиваешься с задачей длиннее одного HTTP-запроса. Дальше выбор простой: строить свой микро-оркестратор сбоку или опереться на инфраструктуру, которая эту задачу уже решила.

Мы выбрали второе и не жалеем. А как у вас устроены долгие задачи в агентах — держите состояние в памяти воркера, тянете свой Redis или уже пробовали новую спецификацию MCP в бою?

Похожие статьи

• Собственный ИИ-агент на сайт вместо чат-бота: как мы разбираем заявки B2B до того, как их увидит менеджер
• Личный ИИ-агент директора: как мы пишем инструкцию, а не очередной промпт
• Собрали ИИ-агента в n8n за вечер, через месяц переписали ядро на Python: где мы провели границу
• Готовые ИИ-агенты появляются каждую неделю: как мы выбираем — взять с полки или собрать под клиента