Агентская инфраструктура и новый бэкэнд

Мы часто говорили об агентных фреймворках. LangGraph, CrewAI, AutoGen, различные SDK, цикл, вызов инструментов, память, планировщик, критик, супервизор. Все полезные слова, ради бога. Но чем больше я смотрю на реально используемые агенты, тем больше мне кажется, что самое интересное переместилось ниже уровня фреймворка.

Вопрос уже не просто в том: какую библиотеку мне использовать, чтобы заставить думать пошаговую модель?

Реальный вопрос заключается в следующем: где будет жить этот агент, когда он перестанет быть демо?

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

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

Потому что сейчас об этом много говорят

В 2023 и 2024 годах разговор был очень сосредоточен на моделях. Какой LLM? Сколько контекста? Сколько это стоит? Насколько он хорош в программировании?

В 2025 и 2026 годах разговор сместился. Модели достаточно хороши, чтобы выполнять реальную работу, но именно поэтому становятся видны скучные детали: время выполнения, безопасность, соединители, идентичность, наблюдаемость, выполнение кода, развертывание, откат.

Это естественный переход от магии к инженерии.

Когда агенту просто нужно сгенерировать ответ, достаточно чата. Когда вам нужно открыть запрос на включение, запросить базу данных, вызвать CRM, начать работу, перемещаться по сайту, прочитать Slack, скомпилировать код и обновить документ, вам нужна операционная система.

Не в буквальном смысле. В организационном смысле.

Первая часть: среда выполнения, в которой агент может работать долго

Агент часто работает поэтапно. Посмотрите на состояние, выберите действие, используйте инструмент, наблюдайте за результатом, обновите план, повторите.

Если этот цикл существует внутри одного HTTP-запроса, у вас сразу возникает проблема. Некоторые действия выполняются медленно. Некоторые ждут вмешательства человека. Некоторые терпят неудачу, и их нужно попробовать еще раз. Некоторые должны пережить развертывание или тайм-аут.

Именно здесь в игру вступают устойчивые рабочие процессы, очереди, фоны заданий и конечные автоматы. Они не гламурны, но они представляют собой разницу между агентом, который на демо-версии кажется умным, и тем, кого можно оставить работать, пока вы идете за кофе.

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

• где мне сохранить состояние между одним шагом и другим?
• что произойдет, если процесс завершится на полпути?
• могу ли я сделать паузу и попросить одобрения?
• могу ли я переиграть пробежку, чтобы понять, почему он сделал такой выбор?
• могу ли я ограничить продолжительность, память, инструменты и стоимость?

Vercel активно продвигается в этом направлении, предлагая AI SDK, функции, рабочие процессы и инструменты для создания агентов в веб-приложениях. Но дело не только в Верселе. Дело в том, что агенту нужен оперативный дом, а не отдельная конечная точка.

##Вторая часть: песочница, ведь агент должен иметь возможность испачкаться, не сломавшись

Как только агент пишет код или выполняет команды, необходима песочница.

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

Агентская песочница должна иметь некоторые свойства:

• изолированная файловая система;
• Ограничения по процессору, памяти и времени;
• управляемая сеть;
• секреты монтируются только при необходимости;
• полные журналы;
• возможность экспорта артефактов;
• чистый сброс между запусками, если это необходимо.

Vercel Sandbox идет именно в этом направлении: изолированные среды для запуска кода, установки зависимостей, работы с файлами и создания артефактов без запуска всего в основной среде выполнения приложения.

Эта вещь важнее, чем кажется. Многие агентные прототипы переходят непосредственно из модели в реальную систему. Модель может вызвать инструмент. Инструменты могут делать многое. Все это кажется элегантным до первой неправильной команды, первой зависимости, установленной не в том месте, и первого токена, попадающего в журнал.

Песочница — это взрослый способ сказать: давай, но здесь.

Третья часть: MCP и проблема с разъемом

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

Без стандарта каждая интеграция представляет собой маленький остров. Коннектор для GitHub сделан так, один для Slack — другой, один для баз данных с разной семантикой, один для автоматизации браузера, который выглядит ни на что.

MCP предлагает общий язык между клиентом и сервером: инструменты, ресурсы, подсказки, авторизация, транспорт, обнаружение. Он не решает волшебным образом проблемы управления и безопасности, но дает грамматику.

И грамматика имеет значение. Когда агент может подключиться ко многим инструментам, вопрос не просто в том, «сможет ли он это сделать?». Проблема в том, «понимает ли он, что он может сделать, в каких пределах, от имени кого и какой след оставить?».

Для меня MCP — это не шумиха, потому что он «вызывает инструменты». Мы уже это сделали. Это хайп, потому что он смещает центр тяжести с единой интеграции на оперативный каталог инструментов.

В хорошей агентной архитектуре MCP становится своего рода патч-панелью:

• GitHub для кода и проблем;
• Slack для разговорного контекста;
• Linear или Jira для плановых работ;
• доступная только для чтения база данных для аналитики;
• браузер или парсер, контролируемый для внешних сайтов;
• хранение документов;
• изолированные среды выполнения;
• внутренние системы подвергаются строгим разрешениям.

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

Четвертая часть: личность и разрешения

Это та область, на которую многие демо-версии закрывают глаза.

Агент действует от чьего-либо имени. Поэтому должно быть ясно, кто является субъектом действия.

Используются ли права пользователя? Из сервисного аккаунта? Из рабочего места? У вас есть временный или постоянный доступ? Вы можете прочитать все или только некоторые ресурсы? Можешь написать? Можете ли вы отменить? Может ли он писать реальным людям?

Если вы плохо ответите на эти вопросы, рано или поздно у вас появится помощник с ключами от дома и без памяти о том, кто ему их дал.

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

Это означает OAuth, область действия токена, управление секретами, журнал аудита, политику инструментов, список разрешений, этап утверждения. Не очень романтическая вещь. Необходимые вещи.

##Пятый кусок: память и контекст, но без накопления мусора

Агентам нужна память, но память опасна, когда становится чердаком.

Существует как минимум три типа памяти:

• запустить память: что произошло в этом исполнении;
• память проекта: условности, решения, ограничения;
• личная или командная память: предпочтения, тон, ритуалы, процессы.

Поместить все в командную строку — это ярлык. Это работает до тех пор, пока не перестанет работать. О полезной памяти нужно заботиться: индексировать, обновлять, просрочивать, проверять, делать доступной для цитирования.

Агент, который плохо помнит, хуже агента, который не помнит. Потому что он говорит уверенно.

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

Шестая часть: наблюдаемость, оценка и воспроизведение

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

Вы хотите увидеть маршрут. Какой контекст он получил? Какие инструменты были доступны? Какой инструмент вы выбрали? С какими аргументами? Какой ответ вы получили? Сколько это стоило? Где оно застряло? Одобрил ли человек что-нибудь? Является ли ошибка модели, инструмента, подсказки, данных или разрешения?

Здесь агенты больше похожи на распределенные системы, чем на чат-ботов.

Вам нужны читаемые трассировки, а не просто текстовые журналы. Вам нужно иметь возможность воспроизвести пробежку. Необходимо сравнить две версии одного и того же агента на известных задачах. Нам нужно измерить регрессию: он не только «отвечает лучше», но и «закрывает нужный тикет, не затрагивая нежелательные файлы».

Агентские оценки сложнее текстовых, поскольку они включают в себя действия. Недостаточно сравнить ожидаемую строку. Вы должны учитывать последовательность действий, побочные эффекты, качество артефакта, время, стоимость, количество человеческих вмешательств.

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

Часть седьмая: человеческие интерфейсы

Агенту не обязательно просто жить в чате.

Некоторым агентам нужна доска. Другие страница со статусом и журналом. Другие кнопки «одобрить». Больше встроенных комментариев. Still others of a CLI.

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

Достойная агентская инфраструктура включает в себя поверхности управления:

• current status;
• редактируемый план;
• произведенные артефакты;
• разница;
• запросы на одобрение;
• хронология;
• кнопка остановки;
• кнопка повтора;
• видимые разрешения.

Это кажется тривиальным, но это не так. Разница между «жутким ИИ» и «надежным помощником» зачастую заключается лишь в том, что последний показывает вам, где у него руки.

Ментальный стек

Если бы я нарисовал это сегодня, минимальный стек агентов был бы таким:

1. Модель: рассуждения, генерация, вызов инструментов, при необходимости мультимодальная.
2. Оркестрация: цикл, шаг, планировщик, политика, участие человека в цикле.
3. Надежная среда выполнения: рабочий процесс, очередь, повтор, пауза, возобновление.
4. Песочница: выполнение кода, изолированная файловая система, ограничения, артефакты.
5. Уровень инструментов: MCP, внутренний API, браузер, база данных, репозиторий.
6. Уровень идентификации: OAuth, область действия, секрет, аудит, политика.
7. Уровень памяти: контекст проекта, извлечение, инструкции, срок действия.
8. Наблюдаемость: отслеживание, воспроизведение, оценка, метрики стоимости и качества.
9. Поверхность продукта: чат, когда достаточно, информационная панель, когда это необходимо, просмотр, когда это важно.

Агентская структура в основном охватывает пункт 2 и часть пункта 1. Остальное — настоящая работа.

Что бы я сделал на практике

Если бы команда сказала мне: «Нам нужны агенты в производстве», я бы не стал начинать с десяти агентов.

Я бы начал с небольшого, повторяющегося и наблюдаемого рабочего процесса. Например: открывать запросы на обслуживание, обновлять документацию по закрытым проблемам, готовить еженедельный обзор, сортировать повторяющиеся ошибки, создавать тесты для затронутых файлов.

Тогда я бы установил очень четкие ограничения:

• никакой записи без веток или песочницы;
• никаких секретов в подсказке;
• инструменты в белом списке;
• человеческое одобрение внешних действий;
• обязательная регистрация и трассировка;
• бюджет на прогон;
• выход всегда доступен для проверки.

Только тогда я бы расширился.

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

Мое чтение

Агентская инфраструктура в лучшем смысле скучна.

Это не та часть, которая заставляет вас аплодировать в демо. Это та часть, которая позволяет вам использовать демо-версию в понедельник утром с реальными людьми, реальными данными и реальными последствиями.

Будущее агентов не будет решаться только тем, у кого лучший образец для подражания. Это будет решать тот, кто построит лучшее место, где он сможет работать: изолированный, когда он экспериментирует, подключенный, когда это необходимо, всегда наблюдаемый, уполномоченный критериями и достаточно скромный, чтобы остановиться, когда он не знает.

Именно здесь агенты перестают быть игрушкой и становятся инфраструктурой.

Источники

• [Vercel: Как создавать агенты ИИ с помощью Vercel и AI SDK] (https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
• Документы Vercel: Песочница
• Документация Vercel: Работа с песочницей
• Документы Vercel: MCP
• Протокол контекста модели: спецификация
• OpenAI: Новые инструменты для создания агентов
• Блог Cloudflare: Агенты в Cloudflare