makedream
53:42Vercel
Log in to leave a comment
No posts yet
Les agents autonomes réfléchissent et appellent des outils jusqu'à ce qu'ils atteignent leur objectif. C'est cette structure de boucle qui pose problème. Si l'appel d'un outil spécifique échoue ou si le système tombe dans un état de blocage avec une répétition infinie des invites système (system prompts), des factures API s'élevant à des milliers de dollars peuvent être générées en quelques dizaines de minutes. Selon les données de la plateforme Vercel de 2026, les commits générés par des agents de codage ont représenté plus de la moitié du trafic total de déploiement, et le volume de jetons (tokens) passant par l'AI Gateway a été multiplié par 10 par rapport à l'année précédente. C'est pourquoi une conception capable de bloquer préventivement l'abus de jetons au niveau de la passerelle est nécessaire. Une simple restriction par adresse IP ne suffit pas à détecter les boucles infinies sémantiques au sein de l'agent. Il est nécessaire de construire une couche de filtrage qui calcule en temps réel la similarité cosinus entre deux vecteurs d'invite et en connectant Next.js Edge Middleware et Upstash Redis.
ext{Cosine Similarity} = rac{mathbf{A} cdot mathbf{B}}{|mathbf{A}| |mathbf{B}|}Le système de défense par middleware en temps réel pour bloquer les appels en boucle infinie est mis en œuvre en trois étapes. Tout d'abord, créez un fichier middleware.ts à la racine du projet et utilisez @upstash/ratelimit pour définir un limiteur de débit "sliding window" qui n'autorise qu'un maximum de 5 demandes d'exécution par session en 30 secondes. Ensuite, rédigez une logique qui utilise la fonction embed du SDK AI et le modèle text-embedding-3-small pour extraire en temps réel l'intégration vectorielle de l'invite entrante, et calcule la similarité cosinus avec le vecteur de l'invite précédente stocké dans Upstash Redis. Si la similarité calculée dépasse 0,95, le système juge qu'il s'agit d'un état de boucle infinie, interrompt immédiatement l'appel au backend LLM et configure une instruction conditionnelle pour renvoyer de force agent:response:${sessionId}, qui correspond aux données de réponse réussies précédentes stockées dans Redis. En complétant ces étapes, la consommation anormale de ressources est bloquée en temps réel, ce qui permet de réduire les coûts d'exploitation de l'API LLM jusqu'à 40 %.
Lorsque l'agent traite des scripts générés par l'utilisateur, comme pour la recherche sur le Web ou l'analyse de données, il est exposé à des attaques par injection d'invite (prompt injection). Si un attaquant s'échappe de la sandbox et exécute des commandes shell hôtes, les variables d'environnement contenant les informations d'identification de la base de données brute sont exposées. Pour isoler physiquement la couche de calcul contre les attaques malveillantes, la technologie Vercel Sandbox est introduite, basée sur AWS Firecracker, une microVM légère capable de démarrer en quelques millisecondes. Vercel Sandbox, qui isole les nouvelles instances de runtime Node.js 26 et ajuste automatiquement la RAM à 4 Go avec un ratio de 2 Go par vCPU, prévient le vol d'identifiants et réduit le temps consacré aux audits de sécurité manuels de plus de 5 heures par semaine.
L'environnement d'exécution de code sécurisé et isolé est contrôlé par un exécuteur de sandbox basé sur une liste blanche. Créez un fichier sandbox.config.ts à la racine du projet et définissez l'attribut networkPolicy sur deny-all pour empêcher toute injection d'invite via une évasion externe et toute fuite des variables d'environnement de la base de données. Dans la liste blanche des variables d'environnement à propager en interne, envWhitelist, n'enregistrez que NODE_ENV, TZ et AGENT_RUN_MODE. Ensuite, créez un script sandbox-runner.ts, enregistrez le fichier de code brut reçu de l'extérieur, runner_entry.js, dans le répertoire isolé via la structure sandbox.writeFiles, puis appelez sandbox.runCommand pour exécuter le runtime tout en bloquant l'accès aux informations sensibles de l'hôte. Insérez une instruction conditionnelle dans la boucle for await qui surveille les journaux de sortie de la sandbox par streaming pour suivre la taille totale des octets, et si la somme de stdout et stderr dépasse 50 Ko, exécutez immédiatement sandbox.stop() pour construire une limite d'erreur qui force le nettoyage de la machine virtuelle. L'application de cette procédure d'isolation de sécurité permet de se défendre contre les attaques DoS qui paralysent le système et d'éviter les fuites de ressources et les coûts de calcul inutiles.
Les agents web fonctionnent comme des entreprises à exécution longue, prenant de quelques minutes à quelques heures jusqu'à leur achèvement. En cas d'erreur exceptionnelle telle qu'une déconnexion réseau ou un délai d'attente (timeout), il existe un risque de perdre tous les résultats des étapes de recherche intermédiaires déjà effectuées, entraînant une consommation redondante de jetons et des coûts supplémentaires pour recommencer depuis le début. Pour résoudre le problème de perte d'état distribué, nous introduisons le modèle d'exécution durable fourni par le Vercel Workflows SDK et le framework Eve. En utilisant les directives du compilateur use workflow et use step, même si la durée de vie du conteneur serverless expire, les données de snapshot de l'étape unique finale réussie avant l'échec sont stockées dans la file d'attente des journaux de mémoire persistante, permettant de reprendre l'activité à partir de l'étape où l'échec s'est produit, sans exécution redondante.
Un système de checkpointing durable permettant la récupération après sinistre est construit en implantant un code d'intercepteur de suivi d'état qui appelle des requêtes upsert dans l'infrastructure de stockage connectée à Vercel Connect. Définissez DurableStateContext, la structure d'état clé qui gérera le cycle de vie de la tâche de l'agent, et subdivisez les étapes d'exécution actuelles en Task_Start, API_Called, Data_Parsed et Task_Complete. Rédigez une fonction d'intercepteur upsertCheckpointState qui enregistre immédiatement l'état actuel du contexte à chaque moment de réussite de l'étape dans connectStateStore, un stockage Upstash Redis lié via le mode OIDC sans certificat d'authentification séparé, grâce à Vercel Connect. Enfin, implémentez le gestionnaire executeOrResumeAgent qui traite les demandes de réessai de communication de l'agent pour rechercher l'état final basé sur l'ID de session dans la base de données. Si l'étape de la session en cours n'est pas Task_Complete, créez un flux de contrôle pour restaurer de force le workflow à partir du point de snapshot le plus récent au lieu de réexécuter la tâche depuis le début. L'activation de ce gestionnaire de préservation d'état élimine l'inefficacité de redémarrage complet en cas de timeout serverless ou de défaillance, augmentant ainsi le taux de réussite des tâches de l'agent.
Pour migrer les chemins API monolithiques des services web existants vers une architecture d'agent basée sur le SDK AI sans interrompre l'environnement de production, il est nécessaire de contrôler les indicateurs de fonctionnalité (feature flags) et de mettre en œuvre un routage Edge en temps réel. La migration progressive sans interruption de service s'effectue en conservant l'API de réponse unique qui fonctionnait de manière stable, tout en appliquant progressivement le déploiement Canary vers le nouveau chemin d'infrastructure d'agent conçu. La technologie Vercel Edge Config, qui garantit une lecture CDN Edge à très faible latence, combinée à la couche middleware, permet de contrôler le trafic en toute sécurité en recherchant rapidement les indicateurs de déploiement en temps réel, sans la surcharge liée à l'accès à une base de données distante.
Pour réussir une migration sans interruption de la base de code héritée (legacy), exécutez une procédure de déploiement en production progressive en 3 étapes. Conservez le chemin d'activité hérité existant /api/v1/generate et ouvrez un nouveau point de terminaison de fichier dédié /api/v1/agent/generate où la fonctionnalité d'agent du SDK AI est intégrée. Intégrez dans le middleware.ts de Next.js une logique qui lit l'indicateur de seuil dynamique agent_canary_rate de Vercel Edge Config avec une fonction get, et établissez un environnement Canary où seul 10 % du trafic utilisateur, dont la valeur de hachage de l'identifiant unique du navigateur est attribuée au sous-groupe du seuil défini de 10, est dynamiquement redirigé vers le nouveau point de terminaison du système d'agent via NextResponse.rewrite. Configurez unifiedAgentRequest, un client adaptateur de communication hybride Fetch Wrapper qui gère la séparation en temps réel selon la valeur de l'en-tête Accept, afin que le composant d'interface utilisateur frontend puisse traiter à la fois l'ancienne méthode de résultat JSON à terminaison courte et la nouvelle sortie de jeton SSE en streaming de l'agent asynchrone. L'application de ce framework de migration permet d'achever la refonte complète du système sans interruption, tout en isolant et en contrôlant la charge du système existant et les risques de fonctionnement anormal imprévus dans une zone de trafic inférieure à 10 %.