Un framework d'agent managé échange du contrôle contre de la vitesse, et cet échange en vaut la peine jusqu'au jour où ce n'est plus le cas. Amazon Bedrock Agents exécutera la boucle raisonner-agir pour vous : il planifie, décide quel outil appeler, l'invoque, renvoie le résultat au modèle, et répète jusqu'à ce que la tâche soit terminée. C'est du travail réel que vous n'avez pas à écrire. La question n'est pas de savoir si cela vous fait gagner du temps. C'est de savoir si les parties qu'il vous cache sont des parties que vous pouvez vous permettre de ne plus voir.

La façon honnête de poser le problème est que « construire sa propre boucle » et « utiliser le framework » ne forment pas une échelle de maturité. Ce sont un compromis entre la part de la boucle que vous contrôlez et la part que vous maintenez. Choisissez en fonction du contrôle dont votre application a réellement besoin, pas selon ce qui semble le plus sérieux.

Ce que la boucle managée fait réellement pour vous

La boucle d'agent représente plus de code qu'il n'y paraît. Vous devez maintenir une machine à états de conversation, extraire les demandes d'appel d'outil de la sortie du modèle, les distribuer, gérer les appels mal formés et les timeouts, renvoyer les résultats dans le bon format, décider quand la tâche est terminée, et imposer une condition d'arrêt pour qu'un modèle bloqué ne boucle pas indéfiniment. Bedrock Agents possède tout cela. Vous définissez des outils avec un schéma OpenAPI ou une Lambda, vous attachez une knowledge base pour la récupération, vous définissez des instructions, et le service pilote l'orchestration.

Pour un cas standard, répondre à des questions, appeler quelques outils bien définis, puiser dans une knowledge base, c'est une quantité importante de plomberie non différenciante que vous pouvez éviter. Si votre agent ressemble au cas commun, le framework est franchement le bon choix.

Là où le framework commence à vous posséder

Le coût d'une boucle managée est que la boucle est précisément l'endroit où vivent vos exigences les plus difficiles, et vous ne pouvez pas y accéder.

  • Flux de contrôle personnalisé. Si vous avez besoin d'un branchement conditionnel que le framework ne modélise pas, d'un point d'approbation humaine en cours de tâche, ou de « essayer l'outil A, et seulement en cas d'échec d'un certain type, basculer vers B », vous combattez l'abstraction. La boucle qui vous faisait gagner du travail devient l'obstacle entre vous et le comportement dont vous avez besoin.
  • Contrôle du contexte et des tokens. Vous ne possédez pas entièrement ce qui entre dans chaque appel de modèle. Quand vous devez élaguer l'historique de façon agressive, injecter du contexte récupéré à un point précis, ou gérer un budget de tokens par étape, les choix de la boucle managée sont à subir, pas à modifier.
  • Observabilité du raisonnement. Déboguer pourquoi un agent a choisi un outil signifie voir le prompt exact, la sortie exacte de l'outil, et la décision exacte suivante. Un framework qui cache les étapes intermédiaires transforme un système débogable en devinette.
  • Réglage de la latence et du coût. Router les étapes bon marché vers un petit modèle et les étapes difficiles vers un modèle frontière, mettre agressivement en cache, plafonner la sortie par étape : tout cela vit à l'intérieur de la boucle. Si vous ne pouvez pas toucher la boucle, vous ne pouvez pas les régler.

Le test de la porte de secours

Avant de vous engager avec un framework d'agent, faites un test : trouvez la porte de secours. Pouvez-vous descendre à un niveau plus bas pour la seule étape qui en a besoin, sans abandonner tout le framework ? Une bonne abstraction vous permet de surcharger un seul appel d'outil, d'inspecter le prompt brut, ou d'écrire à la main une étape de la boucle pendant que le framework gère le reste. Une mauvaise abstraction est tout ou rien, si bien que la première exigence qu'elle ne supporte pas force une réécriture complète.

Si la réponse honnête est « pour faire ce dont j'ai besoin, je dois quitter entièrement le framework », alors le framework ne vous fait pas gagner de travail. Il reporte une réécriture au moment le moins pratique. Mieux vaut le savoir le premier jour que pendant l'incident.

Une décision réellement utilisable

  • Utilisez Bedrock Agents quand votre agent suit une forme standard raisonner-agir-récupérer, que vos outils sont bien définis, et que vous préférez livrer plutôt que posséder le code d'orchestration. La plupart des agents métier sont exactement dans ce cas.
  • Construisez votre propre boucle quand le flux de contrôle, la gestion du contexte, le routage de modèle par étape, ou une observabilité profonde sont des exigences centrales plutôt que des agréments. Si la boucle est votre produit, possédez la boucle.
  • Dans tous les cas, gardez les frontières externes. L'autorisation et le moindre privilège n'ont pas leur place à l'intérieur du raisonnement de l'agent, quel que soit celui qui possède la boucle. Policy dans Amazon Bedrock AgentCore, généralement disponible depuis le début de ce mois, évalue chaque appel agent-vers-outil par rapport à des règles extérieures au code de l'agent, ce qui signifie que vous pouvez changer de framework sans réécrire vos garde-fous.

Ce qu'il faut retenir

Bedrock Agents élimine le travail réel et fastidieux d'exécuter une boucle d'agent, et pour le cas commun, c'est le bon compromis. Il commence à vous posséder au moment où votre exigence la plus difficile vit dans la boucle qu'il cache : flux de contrôle personnalisé, contrôle précis du contexte, observabilité profonde, ou réglage par étape. Décidez en cherchant d'abord la porte de secours. Gardez l'autorisation externe pour que le choix du framework reste réversible.

À lire ensuite

Pour le point de vue plateforme et infrastructure sur l'exécution d'agents en production, les notes de terrain cloud sont sur ercan.cloud, et le hub est sur ercanermis.com.