Si vous avez construit un agent IA en câblant une gigantesque machine à états if/else, vous savez à quelle vitesse cela devient fragile. Strands Agents fait le pari inverse : laisser le modèle faire la planification, et vous fournissez une invite et une liste d'outils. C'est un SDK open source d'AWS, publié en mai 2025 sous la licence Apache 2.0, et il alimente des agents de production au sein d'équipes Amazon comme Amazon Q Developer et AWS Glue.
Ce qu'est réellement Strands Agents
Strands Agents est un SDK pour construire et exécuter des agents IA en quelques lignes de code. Vous donnez à un agent trois choses : un modèle, une invite système et un ensemble d'outils. Le modèle lit l'invite, décide quels outils appeler, les exécute, examine les résultats et continue jusqu'à ce que la tâche soit terminée. Ce cycle est l'essence même du produit.
Il est disponible pour Python et TypeScript. Le nom fait référence aux deux "brins" (strands) qui composent un agent : le modèle et les outils. AWS l'a rendu open source après l'avoir utilisé en interne, donc la conception reflète des besoins de production, pas une démo. Depuis son lancement en prévisualisation, il a dépassé les 150 000 téléchargements sur PyPI et a atteint une version 1.0 qui a ajouté des primitives multi-agents et la prise en charge du protocole Agent-to-Agent (A2A).
Si vous avez lu des informations sur d'autres SDK d'agents, la structure vous semblera familière. Strands se situe dans la même catégorie que LangGraph et Google ADK, mais il s'appuie davantage sur le modèle pour diriger le flux de contrôle au lieu de vous demander de dessiner le graphe vous-même.
La philosophie axée sur le modèle versus l'orchestration codée en dur
La plupart des premiers frameworks d'agents vous demandaient de définir le flux de travail à l'avance. Vous construisiez des nœuds, des arêtes et des conditions, puis vous acheminiez le modèle à travers eux. Cela fonctionne, mais chaque nouvelle capacité signifie plus de graphes à maintenir.
Strands inverse la responsabilité. Les modèles modernes planifient déjà, enchaînent le raisonnement, appellent des outils et réfléchissent aux résultats. Donc, au lieu de coder cette logique à la main, vous décrivez l'objectif et confiez les outils. Le modèle trouve les étapes.
Voici le contraste en termes simples :
| Approche | Vous définissez | Le flux de contrôle réside dans | Coût d'une nouvelle capacité |
|---|---|---|---|
| Orchestration codée en dur | Nœuds, arêtes, conditions, routage | Votre code de graphe | Modifier le graphe, retester les chemins |
| Axée sur le modèle (Strands) | Invite + liste d'outils | La boucle de raisonnement du modèle | Ajouter un outil, mettre à jour l'invite |
Le compromis est réel. Les agents axés sur le modèle sont plus rapides à construire et à adapter, mais vous perdez une certaine dose de déterminisme. Pour les flux de travail qui doivent s'exécuter de la même manière à chaque fois, vous pouvez toujours ajouter de la structure avec des modèles et des hooks multi-agents. Le point n'est pas que les graphes sont mauvais ; c'est que vous y avez recours lorsque vous en avez besoin plutôt que par défaut.
Un agent minimal
Le plus petit programme Strands utile est court. Vous importez la classe Agent, définissez éventuellement un outil avec le décorateur @tool, et appelez l'agent comme une fonction.
from strands import Agent, tool
@tool
def word_count(text: str) -> int:
"""Compte les mots dans un bloc de texte."""
return len(text.split())
agent = Agent(
system_prompt="Vous êtes un assistant de rédaction concis.",
tools=[word_count],
)
response = agent("Combien de mots y a-t-il dans cette phrase ?")
print(response)
Le décorateur @tool transforme une fonction Python ordinaire en quelque chose que le modèle peut appeler. Votre docstring et vos annotations de type deviennent la description de l'outil et le schéma d'entrée, de sorte que le modèle sait quand et comment l'utiliser. Il n'y a pas de registre distinct à maintenir. L'appel à agent(...) exécute la boucle jusqu'à ce que le modèle décide qu'il a terminé.
Outils et fournisseurs de modèles
Les outils sont la manière dont l'agent interagit avec le monde extérieur. Un outil peut être une fonction Python que vous avez écrite, un outil packagé de la communauté, ou un serveur Model Context Protocol (MCP) entier exposé à l'agent.
Côté modèle, Strands est flexible en matière de fournisseurs. Le fournisseur par défaut est Amazon Bedrock, et dès l'installation, un agent utilise un modèle Claude Sonnet dans la région us-west-2 (l'ID exact du modèle par défaut a changé au fil des versions du SDK, donc vérifiez votre version installée plutôt que de le coder en dur). Vous pouvez le diriger ailleurs :
- Tout modèle Amazon Bedrock qui prend en charge l'utilisation d'outils et le streaming
- La famille Claude d'Anthropic via l'API Anthropic
- Les modèles Llama via l'API Llama
- Ollama pour le développement local
- D'autres fournisseurs tels qu'OpenAI via LiteLLM
Changer de fournisseur est un changement d'objet modèle, pas une réécriture. La boucle de l'agent, vos outils et votre invite restent les mêmes. Cela rend pratique le développement avec un modèle Ollama local et le déploiement sur Bedrock.
Support multi-agents et MCP
Un seul agent gère beaucoup de choses, mais les systèmes réels en nécessitent souvent plusieurs. Strands 1.0 a ajouté des primitives pour les applications multi-agents, y compris un modèle "Agent-as-Tool" où un agent appelle un autre agent de la même manière qu'il appelle n'importe quel outil, et une coordination de type "Swarm" pour des groupes d'agents travaillant ensemble sur un problème. Il prend également en charge le protocole A2A, de sorte que les agents Strands peuvent communiquer avec des agents construits sur d'autres frameworks.
Le MCP est une fonctionnalité de premier ordre. Le Model Context Protocol est un standard ouvert pour connecter des modèles à des outils et des sources de données. Avec Strands, vous pouvez vous connecter à des serveurs MCP publiés et utiliser leurs outils directement, ce qui signifie que des milliers d'intégrations existantes deviennent disponibles sans code de "glue" personnalisé. Vous gérez la connexion via un client MCP et passez ses outils à l'agent comme n'importe quelle autre liste d'outils.
Si vous utilisez déjà des serveurs MCP, c'est le moyen le moins cher de donner de nouvelles capacités à un agent. L'inconvénient est que vous dépendez désormais du bon comportement de ces serveurs, ce qui est une raison pour laquelle le test des points d'accès sous-jacents est important.
Déployer un agent Strands
Strands est conçu pour passer de votre ordinateur portable à la production sans changement de framework. Vous testez localement, puis vous déployez vers la cible qui correspond à votre pile :
- Amazon Bedrock AgentCore pour un runtime d'agent géré
- AWS Lambda pour des agents éphémères et pilotés par des événements
- AWS Fargate ou Amazon EKS pour des services conteneurisés et de longue durée
- Du Docker simple partout où vous pouvez exécuter un conteneur
Parce que l'agent est un programme Python ou TypeScript ordinaire, son empaquetage suit les mêmes règles que n'importe quelle application. AWS documente également les hooks d'observabilité, afin que vous puissiez tracer ce que le modèle a décidé et quels outils il a appelés une fois l'agent en ligne.
Où Apidog s'insère
Strands construit l'agent. Il ne construit pas les API que votre agent appelle, et c'est cette lacune qu'il faut prévoir. Chaque agent Strands s'appuie sur deux types de points d'accès HTTP : l'API du fournisseur LLM derrière le modèle, et les API REST ou d'outils derrière vos fonctions @tool et vos serveurs MCP. Si ces points d'accès se comportent mal, l'agent échoue d'une manière qui ressemble à des problèmes de modèle, mais n'en sont pas.
Apidog est l'endroit où vous testez et simulez ces API sous-jacentes avant même que l'agent ne les touche. Voici quelques utilisations concrètes :
- Simuler le modèle ou un point d'accès d'outil pendant que vous itérez sur la boucle, afin de ne pas consommer de jetons ou d'atteindre les limites de débit à chaque exécution. L'article sur la construction d'un harnais de test d'agent IA avec Apidog montre le modèle.
- Affirmer les formes de réponse des outils afin qu'un outil qui renvoie une charge utile mal formée soit détecté lors d'un test, et non en production. Consultez le guide des assertions API pour savoir comment valider les champs, les types et les codes de statut.
- Mettre en place une API factice qui imite les réponses d'un service réel, y compris les cas d'erreur que votre agent doit gérer avec élégance.
- Gérer les clés API par environnement afin que vos agents de développement, de staging et de production s'authentifient auprès des bons backends sans divulguer les informations d'identification dans le code.
Pour être clair, Apidog n'est pas un framework d'agent et n'orchestre rien. Strands reste le cerveau. Apidog est l'établi pour la plomberie en dessous. Vous pouvez télécharger Apidog et câbler des maquettes pour vos points d'accès d'outils en quelques minutes.
Quand utiliser Strands Agents
Optez pour Strands lorsque vous voulez avancer rapidement et faire confiance au modèle pour planifier. Il convient bien si vous êtes sur AWS et utilisez déjà Bedrock, si vous voulez commencer avec un agent et évoluer vers le multi-agent plus tard, ou si vous voulez des outils MCP sans écrire de code d'intégration.
Il convient moins bien lorsque vous avez besoin de flux stricts, auditables et déterministes où chaque branche doit être prédéfinie. Vous pouvez toujours y arriver avec des hooks et une structure multi-agents, mais un framework axé sur les graphes peut être une meilleure correspondance directe. La présentation honnête est que les approches basées sur le modèle et basées sur les graphes résolvent des problèmes différents, et Strands est celle basée sur le modèle.
Questions fréquemment posées
Strands Agents est-il gratuit et open source ?
Oui. Strands Agents est open source sous la licence Apache 2.0, avec le code source sur GitHub. Il n'y a pas de frais de licence pour le SDK. Vous payez pour le modèle et toutes les ressources cloud que vous déployez, comme l'inférence Bedrock ou l'exécution Lambda, mais le framework lui-même ne coûte rien.
Dois-je utiliser Amazon Bedrock avec Strands ?
Non. Bedrock est le fournisseur par défaut, mais Strands prend en charge l'API d'Anthropic, l'API Llama, Ollama pour les exécutions locales et d'autres fournisseurs via LiteLLM. Vous changez l'objet modèle et conservez le reste de votre code. Cela facilite le prototypage local et le passage à un fournisseur géré pour la production.
Quelle est la différence entre Strands et un framework basé sur des graphes ?
Strands est basé sur le modèle : vous fournissez une invite et des outils, et le modèle décide des étapes. Les frameworks basés sur des graphes vous demandent de définir le flux de contrôle sous forme de nœuds et d'arêtes. Strands est plus rapide à construire et à adapter ; les frameworks basés sur des graphes vous offrent une exécution plus rigoureuse et prévisible. De nombreuses équipes utilisent les deux pour différents services.
Comment tester les API dont dépend mon agent Strands ?
Testez-les indépendamment de l'agent, avant et pendant le développement. Simulez les points d'accès LLM et outils, vérifiez la forme de leurs réponses et exécutez ces vérifications en CI. Un outil comme Apidog gère la simulation et les assertions, et la présentation sur le test de l'API ChatGPT avec Apidog couvre l'authentification, le streaming et les tests d'appel d'outils qui se mappent directement aux backends d'agents.
Conclusion
Strands Agents offre une approche épurée de la construction d'agents : définissez un modèle, une invite et des outils, puis laissez le modèle exécuter la boucle. Il s'adapte d'un agent à plusieurs, communique via MCP et A2A, et se déploie sur la pile AWS sans réécriture. Le framework gère le raisonnement. Votre tâche consiste à vous assurer que les API sous-jacentes sont solides, et c'est exactement là qu'Apidog gagne sa place, en simulant et en testant les points d'accès que votre agent appelle afin que les défaillances fassent surface dans vos tests plutôt qu'en production.