makedream
53:42Vercel
Log in to leave a comment
No posts yet
Автономные агенты думают и вызывают инструменты до тех пор, пока не достигнут цели. Проблема заключается именно в этой циклической структуре. Если вызов определенного инструмента завершается с ошибкой или системный промпт попадает в состояние «зацикливания», в течение десятков минут могут возникнуть расходы на API, исчисляемые тысячами долларов. Согласно данным платформы Vercel за 2026 год, коммиты, созданные AI-агентами, составили более половины всего трафика развертываний, а объем токенов, проходящих через AI Gateway, вырос в 10 раз по сравнению с предыдущим годом. Именно поэтому необходима архитектура, превентивно блокирующая злоупотребление токенами на уровне шлюза. Простых ограничений по IP-адресу недостаточно для обнаружения семантических бесконечных циклов внутри агента. Необходимо создать фильтрующий слой, который связывает Next.js Edge Middleware с Upstash Redis для вычисления косинусного сходства между двумя векторами промптов и в реальном времени.
ext{Cosine Similarity} = rac{mathbf{A} cdot mathbf{B}}{|mathbf{A}| |mathbf{B}|}Система защиты на уровне промежуточного ПО (middleware) для блокировки бесконечных циклов реализуется в три этапа. В корне проекта создается файл middleware.ts, где с помощью @upstash/ratelimit определяется ограничитель частоты (rate limiter) типа «скользящее окно», разрешающий не более 5 запросов на выполнение на одну сессию в течение 30 секунд. Затем вызывается функция embed из AI SDK и модель text-embedding-3-small для извлечения векторных эмбеддингов входящих промптов в реальном времени, после чего реализуется логика вычисления косинусного сходства с вектором предыдущего промпта, хранящимся в Upstash Redis. Если вычисленное сходство превышает 0.95, это классифицируется как состояние бесконечного цикла, вызов бэкенда LLM немедленно прерывается, а через условную конструкцию принудительно возвращаются данные последнего успешного ответа agent:response:${sessionId}, хранящиеся в Redis. Выполнение этих шагов позволяет блокировать ненормальное потребление ресурсов в реальном времени, сокращая операционные расходы на API LLM до 40%.
Когда агент обрабатывает сценарии, созданные пользователем (например, веб-исследования или анализ данных), он подвергается атакам типа «инъекция промпта» (prompt injection). Если злоумышленник выйдет из «песочницы» (sandbox) и запустит команды оболочки хоста, произойдет утечка переменных окружения с учетными данными базы данных. Для физической изоляции вычислительного слоя от вредоносных атак внедряется технология Vercel Sandbox — микро-ВМ на базе AWS Firecracker, отличающаяся легкостью и производительностью загрузки за миллисекунды. Vercel Sandbox, изолирующая новые экземпляры среды выполнения Node.js 26 и автоматически масштабирующая оперативную память из расчета 2 ГБ на 2 vCPU (всего до 4 ГБ), предотвращает кражу учетных данных, что экономит более 5 часов ручного аудита безопасности в неделю.
Изолированная безопасная среда выполнения кода контролируется с помощью песочницы на основе белого списка. В корне проекта создается файл sandbox.config.ts, где для свойства networkPolicy задается значение deny-all, что на корню пресекает инъекции промптов через внешний взлом и утечку переменных окружения базы данных. В список envWhitelist, содержащий переменные окружения, допустимые для передачи внутрь, добавляются только NODE_ENV, TZ и AGENT_RUN_MODE. Далее создается скрипт sandbox-runner.ts, который записывает необработанный файл кода runner_entry.js, полученный извне, в изолированную директорию через sandbox.writeFiles, а затем вызывает sandbox.runCommand для запуска среды выполнения с блокировкой доступа к конфиденциальной информации хоста. Внутри цикла for await, отслеживающего выходные логи песочницы в режиме потоковой передачи, вставляется условие для отслеживания совокупного размера байтов; при превышении суммы stdout и stderr значения 50 КБ немедленно выполняется sandbox.stop(), создавая границу ошибок для принудительной очистки виртуальной машины. Применение этой процедуры изоляции защищает от DoS-атак, вызывающих паралич системы, и предотвращает утечку ресурсов и ненужные вычислительные затраты.
Веб-агенты работают как долгосрочные бизнес-процессы, выполнение которых занимает от нескольких минут до нескольких часов. В случае возникновения исключительных ошибок, таких как разрыв сети или тайм-аут, существует риск потери всех результатов промежуточных этапов поиска, что вынуждает тратить токены заново и несет дополнительные расходы на повторное выполнение. Для решения проблемы потери распределенного состояния внедряются паттерны долговечного выполнения, предоставляемые Vercel Workflows SDK и фреймворком Eve. Использование директив компилятора use workflow и use step гарантирует, что даже если время жизни серверного контейнера истечет, данные снимка последнего успешно выполненного шага перед сбоем будут сохранены в очереди журналов энергонезависимой памяти, что позволяет возобновить бизнес-процесс с момента сбоя без повторного выполнения.
Система долговечного чекпоинтинга с возможностью восстановления после сбоев строится путем внедрения кода перехватчика (interceptor) отслеживания состояния, который выполняет upsert-запросы к инфраструктуре хранилища, связанной с Vercel Connect. Определяется DurableStateContext — ключевая структура состояния для управления жизненным циклом задачи агента, с детализацией этапов: Task_Start, API_Called, Data_Parsed, Task_Complete. Через Vercel Connect пишется функция-перехватчик upsertCheckpointState, которая немедленно записывает текущее состояние контекста в хранилище Upstash Redis (connectStateStore), привязанное через OIDC без отдельных сертификатов аутентификации, в момент успеха на каждом этапе. Наконец, реализуется обработчик executeOrResumeAgent, который обрабатывает повторные запросы связи агента, извлекая конечное состояние на основе ID сессии из базы данных; если этап сессии не является Task_Complete, создается поток управления, который принудительно восстанавливает рабочий процесс с последней сохраненной точки, вместо перезапуска задачи с самого начала. Запуск этого обработчика сохранения состояния устраняет неэффективность перезапуска при тайм-аутах serverless-функций или сбоях, повышая процент успешного выполнения задач агентом.
Для миграции монолитных API-путей существующего веб-сервиса на архитектуру агентов на базе AI SDK без остановки производственной среды необходимы управление функциональными флагами и маршрутизация на границе (edge routing) в реальном времени. Поэтапная миграция без остановки обслуживания осуществляется путем постепенного применения Canary-развертывания к новому пути инфраструктуры агента, при сохранении стабильно работающего исходного API с одиночным ответом. Объединение технологии Vercel Edge Config, обеспечивающей чтение CDN edge с ультранизкой задержкой, со слоем middleware позволяет безопасно контролировать трафик путем быстрого поиска флагов развертывания в реальном времени без накладных расходов на удаленный доступ к БД.
Для достижения миграции устаревшей кодовой базы без простоев выполняется трехэтапная процедура постепенного развертывания в продакшене. Сохраняется существующий рабочий путь legacy /api/v1/generate, и открывается новый выделенный файл-эндпоинт /api/v1/agent/generate, в который интегрируются функции агента AI SDK. В middleware.ts Next.js встраивается логика считывания динамического порогового показателя agent_canary_rate из Vercel Edge Config с помощью функции get. Устанавливается Canary-среда, где только 10% трафика пользователей, чье хеш-значение уникального ID браузера попадает в подгруппу ниже порогового значения 10, динамически перенаправляются на эндпоинт новой агентской системы через NextResponse.rewrite. Для обработки как старого типа JSON-ответов с кратким сроком жизни, так и нового вывода SSE-потока токенов асинхронного агента внутри компонентов фронтенд-интерфейса, настраивается клиент unifiedAgentRequest — гибридный адаптер связи Fetch Wrapper, который в реальном времени переключает обработку в зависимости от значения заголовка Accept. Применение этой архитектуры миграции позволяет завершить переработку всей системы без простоев, изолируя риски нагрузки на существующую систему и непредвиденных сбоев в пределах менее 10% трафика.