Les agents Amazon Bedrock et le plan de contrôle : une revue de l'architecture

Pour les ingénieurs et les architectes DevOps opérant dans le périmètre AWS, Agents Amazon Bedrock—connu sur le plan architectural sous le nom de Exécution AgentCore—est la méthode standard pour créer des flux de travail agentiques. Il normalise les boucles récursives complexes requises pour les agents, en gérant le raisonnement, la mémoire et l'orchestration des API que les développeurs géraient auparavant manuellement à l'aide de bibliothèques telles que Chaîne Lang.

L'adoption d'un framework d'agents gérés nécessite toutefois souvent un compromis entre la rapidité initiale et le contrôle architectural à long terme. Il associe la logique des applications à la philosophie d'orchestration d'un fournisseur de cloud spécifique. Ce rapport analyse l'architecture technique des agents Amazon Bedrock, évalue les réalités opérationnelles en matière d'observabilité et la compare à une approche de plan de contrôle agnostique utilisant le Plateforme TrueFoundry.

Anatomie de l'environnement d'exécution d'Amazon Bedrock Agent

Les agents Bedrock fonctionnent comme un moteur d'orchestration conçu pour exécuter des tâches en plusieurs étapes. Contrairement à un appel d'API InvokeModel sans état, un agent fonctionne comme une boucle avec état.

Lors de la définition d'un agent dans Bedrock, les développeurs configurent trois primitives distinctes :

1. Le groupe d'action : Un Schéma OpenAPI définir les capacités de l'agent. Ils correspondent généralement à AWS Lambda fonctions, fournissant la couche de calcul pour l'exécution de l'outil.
2. La base de connaissances : Une intégration de magasin vectoriel (généralement Amazon OpenSearch sans serveur) qui fournit des fonctionnalités RAG pour la mise à la terre du modèle.
3. Le modèle d'orchestration : Logique d'ingénierie rapide indiquant au modèle comment interpréter les entrées utilisateur, sélectionner le bon Lambda et analyser la sortie.

La boucle de raisonnement

L'utilité principale est d'automatiser les étapes de raisonnement. Lorsqu'un utilisateur demande à « Vérifier l'inventaire de l'article X et mettre à jour la base de données », le moteur d'exécution décompose cette requête :

• Étape 1 : Détermine que le Lambda CheckInventory est requis.
• Étape 2 : Construit la charge utile.
• Étape 3 : Exécute le Lambda et lit la réponse.
• Étape 4 : Détermine que UpdateDatabase est l'étape logique suivante en fonction de la sortie précédente.

Figure 1 : La boucle d'orchestration récursive gérée par AWS Bedrock Agents.

Compromis opérationnels

Les services gérés accélèrent le déploiement initial, mais les opérations du jour 2 (débogage, mise à l'échelle et migration) révèlent souvent le coût de l'abstraction.

Considérations relatives à l'observabilité

Dans un environnement d'exécution entièrement géré, la boucle d'invite est résumé. Les instructions système et les définitions d'outils sont créées par AWS et envoyées au LLM situé derrière la limite de service.

Si un agent hallucine ou appelle le mauvais outil, le débogage peut s'avérer complexe car la fenêtre de contexte brute et les étapes de raisonnement intermédiaires sont souvent gérées implicitement. Cela peut amener les équipes à se concentrer sur débogage de la sortie finale plutôt que d'inspecter le processus de raisonnement granulaire.

Les architectures utilisant une passerelle IA telle que TrueFoundry garantissent la transparence de la logique d'orchestration. Le « cerveau » de l'agent fonctionne sur votre infrastructure, garantissant que chaque étape d'invite, de jeton et de raisonnement est visible dans les outils de traçage tels que OpenTelemetry ou Arize.

La chaîne d'outils centrée sur AWS

Les agents Bedrock sont optimisés pour l'écosystème AWS. L'appel natif d'un outil implique généralement que l'outil existe en tant que fonction Lambda.

Si une entreprise utilise des outils externes, tels qu'une base de données Snowflake, une API Salesforce ou un service hébergé sur Azure, les développeurs se coordonnent souvent via le wrapper Lambdas dans AWS pour combler le fossé. Cela peut entraîner une latence et des frais de maintenance supplémentaires.

L'industrie est actuellement en train de fusionner autour du Protocole de contexte modèle (MCP), une norme ouverte permettant aux agents de se connecter à des sources de données de manière universelle. TrueFoundry est conçu pour être Natif au MCP, agissant comme un hub neutre où un agent peut se connecter simultanément à un serveur MCP Google Drive, à une base de données Postgres locale et à une fonction AWS Lambda, sans wrappers d'infrastructure personnalisés.

TrueFoundry : l'architecture du plan de contrôle

TrueFoundry propose un Plan de contrôle architecture. Au lieu de regrouper le modèle, l'exécution et les outils dans un seul service cloud vertical, cette approche les dissocie.

Ici, le fournisseur de cloud (AWS, Azure, GCP) fonctionne comme un backend évolutif pour le calcul et les modèles, tandis que la passerelle TrueFoundry reste l'interface gouvernable pour les applications.

Routage et efficacité économique

L'une des caractéristiques déterminantes de Bedrock Agents est la liaison architecturale avec les modèles Bedrock (Titan, Claude, Llama on Bedrock). Les agents complexes exécutent de nombreuses étapes et utilisent un modèle haut de gamme tel que Claude 3,5 Sonnet car chaque étape d'une boucle récursive peut faire grimper les coûts.

TrueFoundry facilite routage sémantique. La passerelle analyse la complexité d'une étape ; si l'agent a simplement besoin d'extraire une date d'une chaîne, la demande est retransmise vers un modèle plus rentable (comme Lama en métal) hébergé sur Instances AWS Spot. Si l'étape nécessite un raisonnement complexe, elle est dirigée vers GPT-4o ou Claude 3.5 Opus.

Figure 2 : La logique de routage de TrueFoundry optimise l'économie de l'unité en faisant correspondre la complexité des tâches au fournisseur le plus rentable.

Comparaison des fonctionnalités : service géré et plan de contrôle

Ce tableau compare les fonctionnalités du service géré AWS par rapport au plan de contrôle TrueFoundry.

L'argument de l'infrastructure hybride

Pour de nombreuses entreprises, l'avenir n'est pas « All-in on AWS » ou « All-in on Azure », mais un état hybride dicté par la gravité des données et les coûts.

AgentCore excelle lorsque l'intégralité du cycle de vie des données, de l'ingestion à l'inférence, se déroule dans AWS. Cependant, à mesure que les flux de travail des agences évoluent, ils ont souvent besoin d'accéder aux données dans Microsoft SharePoint, aux plateformes de données clients sur Google Cloud ou à des entrepôts sur site.

TrueFoundry facilite une modèle de routage inter-cloud. La logique de l'agent réside dans le plan de contrôle, ce qui lui permet d'accéder à des outils sur différents clouds sans avoir à passer par des VPN complexes ou à configurer manuellement des passerelles API. Cela garantit la pérennité de la pile ; si Service Azure OpenAI publie un nouveau modèle qui surpasse Claude, ou si Llama 3 devient viable pour un cas d'utilisation spécifique, le changement du moteur sous-jacent constitue un changement de configuration plutôt qu'une réécriture de code.

Figure 3 : L'architecture de routage TrueFoundry permettant l'accès aux données entre les clouds.

Résumé de la recommandation

Le choix entre le service géré AWS et le plan de contrôle TrueFoundry est en fait un choix entre vitesse d'intégration et optionnalité architecturale.

• Standardisez les agents AWS Bedrock si : Votre équipe d'ingénieurs est petite, la logique des applications est largement composée de fonctions AWS Lambda et il n'est pas nécessaire d'utiliser des modèles extérieurs au portefeuille Bedrock.
• Choisissez TrueFoundry si : Vous créez une plateforme qui doit répondre aux besoins de plusieurs équipes internes ayant des besoins différents. Vous avez besoin d'une gouvernance centralisée pour gérer les budgets et les politiques de sécurité sur AWS et Azure, ou vous avez l'intention de tirer parti de modèles open source sur des instances Spot pour contrôler l'économie unitaire des charges de travail des agents à volume élevé.

‍