Transformez l'IA en système d'exécution individuelle, le dernier guide des meilleures pratiques des agents gérés de Claude

Titre original de l'article : Lancement de Claude Managed Agents
Auteur original : Lance Martin
Traduction : Peggy, BlockBeats

Note de l'éditeur: Cet article présente les Managed Agents lancés par Claude. Il fournit une forme logicielle plus proche du futur : les agents intelligents ne sont plus des interfaces qui répondent aux demandes une seule fois mais des systèmes d'exécution qui peuvent être configurés, déployés, planifiés et exécutés sur le long terme.

En découplant complètement "intelligence" (modèle et framework d'exécution), "exécution" (outils et bac à sable) et "processus" (session et journal), Claude Managed Agents transforme l'agent de "logic in code" en une unité d'infrastructure indépendante. Cette conception renforce non seulement la stabilité et la sécurité du système dans les tâches à long terme, mais permet également aux agents de s'étendre continuellement à mesure que les capacités du modèle évoluent, sans être contraints par les cadres existants.

Dans ce cadre, les modes d'utilisation courants ont également changé : de l'exécution déclenchée par un événement et planifiée à l'exécution automatique « à la livraison », et aux tâches complexes s'étalant sur des jours, voire des semaines, les agents acquièrent véritablement la capacité de « travailler en continu ». Cela signifie que la valeur de l’IA ne se reflète plus seulement dans la qualité d’une réponse unique mais dans sa capacité à s’accumuler et à se compliquer au fil du temps.

Si les anciennes API permettaient aux développeurs d'« invoquer l'intelligence », les agents managés tentent maintenant de répondre à une autre question : comment faire de l'intelligence un système qui peut être hébergé, planifié et exécuté en continu. En ce sens, les agents ne sont plus seulement des outils mais plus proches d'une nouvelle primitive informatique.

L'article original est le suivant :

TL;DR

Claude Managed Agents est un framework d'exécution d'agents pré-construit et configurable (harnais d'agents) qui fonctionne sur une infrastructure gérée. Il vous suffit de définir un agent comme un modèle — y compris les outils, les compétences, les dépôts de fichiers/codes, etc. — et le reste du framework d'exécution et de l'infrastructure est fourni par le système. Ce système est conçu pour suivre le rythme de croissance rapide des niveaux d'intelligence de Claude et soutenir les tâches de longue durée.

Liens connexes:

·Claude Blog : Modes d'utilisation et cas clients

·Ingénierie Blog : Conception de Claude Managed Agents

·Documentation : Guide de démarrage, démarrage rapide, CLI et SDK Vue d'ensemble

Claude Managed Agents

Pourquoi Claude Managed Agents est nécessaire

L'API messages de Claude est fondamentalement un point d'entrée pour interagir directement avec le modèle: saisir un message, récupérer un bloc de contenu. Les agents intelligents basés sur l'API messages doivent s'appuyer sur un "cadre d'exécution" pour gérer le routage des invocations d'outils, la gestion du contexte, et plus encore. Cependant, cela pose plusieurs défis:

1. Le framework d'exécution doit suivre l'évolution des capacités de Claude
J'ai récemment écrit un billet de blog sur la façon de construire un agent basé sur les capacités sous-jacentes de Claude API pour gérer l'orchestration d'outils et la gestion de contexte. Cependant, le problème est que le cadre d'exécution de l'agent implique souvent certaines hypothèses sur "ce que Claude ne peut pas faire." Au fur et à mesure que les capacités de Claude grandissent, ces hypothèses deviennent rapidement obsolètes et peuvent même devenir des goulets d'étranglement de performance. Par conséquent, le cadre d'exécution doit être continuellement mis à jour pour suivre le rythme d'évolution de Claude.

2. Les cycles de vie des tâches de Claude s'allongent
La gamme des tâches que Claude peut accomplir augmente de façon exponentielle, dépassant les 10 heures de travail humain dans les tests de référence du METR. Cela impose des exigences plus élevées à l'infrastructure sous-jacente de l'agent : elle doit avoir une sécurité, une stabilité dans les scénarios à long terme (traiter diverses défaillances d'infrastructure) et une évolutivité (par exemple, prendre en charge plusieurs équipes d'agents fonctionnant simultanément).

Pourquoi ces défis comptent

Il est crucial de relever les défis mentionnés ci-dessus, car nous prévoyons que les futures versions de Claude pourront fonctionner en continu sur des périodes de jours, de semaines, voire de mois, en s'attaquant aux problèmes les plus complexes de l'humanité.

Le SDK Claude Agent est le premier pas dans cette direction, en fournissant un framework d'exécution d'agent intelligent polyvalent et facile à utiliser. Pendant ce temps, Claude Managed Agents va plus loin : sur cette base, ils fournissent un framework d'exécution complet + une infrastructure gérée spécialement conçue pour prendre en charge l'exécution sécurisée et fiable des tâches sur de longues périodes.

Pour commencer

Une façon simple de commencer est d'utiliser notre compétence open-source claude-api, qui peut être utilisé prêt à l'emploi dans Claude Code. Il suffit d'installer la dernière version de Claude Code, puis d'exécuter la sous-commande suivante pour terminer la configuration d'initialisation de Claude Managed Agents.

J'ai personnellement une forte préférence pour l'approche "compétences" pour intégrer de nouvelles fonctionnalités, et j'utilise largement cette compétence dans la pratique.

De plus, vous pouvez vous référer à notre documentation pour démarrer rapidement avec le SDK ou la CLI et prototyper vos agents dans la console Claude.

Cas d'utilisation

Vous trouverez de nombreux cas d'utilisation intéressants dans le blog officiel Claude. En combinant ces cas avec ma propre expérience pratique, j'ai observé quelques habitudes d'utilisation courantes:

1. Déclenché par événement
Exécution de tâches par un agent managé déclenché par un service.
Par exemple, lorsqu'un bug est détecté dans le système, un appel automatisé à un agent géré est effectué pour écrire un correctif et soumettre un PR. Aucune intervention humaine n'est nécessaire entre les étapes « problème identifié » et « patch appliqué ».

2. Exécution programmée
Planification des tâches à exécuter par un agent géré.
Par exemple, de nombreuses personnes, dont moi-même, utilisent cette méthode pour générer des briefings quotidiens (comme un résumé des activités sur Platform X ou GitHub, ou le rapport d'étape d'une équipe généré par un agent). Voici un exemple de mon résumé quotidien des activités sur la plateforme X.

3. Feu et oubli
Exécution de tâches par un agent managé déclenché par un humain mais ne nécessitant aucun suivi continu. Par exemple, assigner des tâches à un agent géré via Slack ou Teams, qui termine ensuite la tâche de manière autonome et fournit les résultats (tels que des tableaux, des diapositives ou même des applications).

4. Tâches à long terme
Un travail de longue haleine, que je considère comme l'un des scénarios particulièrement précieux pour les Managed Agents.
J'ai mené quelques expériences basées sur le rapport de recherche automatique d'Andrej Karpathy, explorant différentes façons d'appliquer. Par exemple, j'ai récemment pris la bibliothèque prétexte de _chenglou en entrée et j'ai demandé à un agent managé de chercher comment l'appliquer au contenu de notre blog d'ingénierie.

Concepts de base

Il y a trois concepts fondamentaux à comprendre dans le processus d'intégration:

1. Agent
Configuration contrôlée par version qui définit l'« identité » de l'agent : modèle, invite système, outils, compétences, serveur MCP, etc. Une fois créé, il peut être invoqué à plusieurs reprises via ID.

2. Environnement
Modèle utilisé pour décrire l'environnement sandbox fourni pour l'exécution de l'outil agent (par exemple, type d'exécution, stratégie réseau, configuration du paquet de dépendances, etc.).

3. Séance
Une instance en cours d'exécution d'état lancée sur la base d'un agent et d'un environnement préconfigurés. Il créera un bac à sable flambant neuf à partir du modèle d'environnement, montera les ressources nécessaires à cette exécution (comme les fichiers, les dépôts GitHub) et stockera en toute sécurité les informations d'authentification dans un magasin de clés (comme les informations d'identification MCP).

Vous pouvez le voir de cette façon:

· Agent = La configuration elle-même

· Environnement = Le modèle de bac à sable requis pour le fonctionnement de l'agent

· Session = Un processus d'exécution spécifique

Un Agent peut correspondre à plusieurs Sessions.

Usage

Consultez la documentation pour plus de détails. L'utilisation globale est divisée en deux catégories:

1. SDK (Orienté Code)
Intégrez le SDK à votre application pour piloter des sessions lors de l'exécution. Actuellement, les agents gérés prennent en charge 6 langues: Python, TypeScript, Java, Go, Ruby, PHP.

2. CLI (interface de ligne de commande)
Interagissez avec toutes les ressources de l'API via la ligne de commande, y compris les agents, les environnements, les sessions, les coffres-forts, les compétences, les fichiers, etc. Chaque type de ressource possède des sous-commandes correspondantes.

Pratique courante :
Habituellement, le CLI est utilisé pour la configuration et l'initialisation, tandis que le SDK est utilisé pour la logique d'exécution.
Un modèle d'agent est persistant – vous pouvez créer un modèle (par exemple, définir le modèle, l'invite système, les outils, le serveur MCP, les compétences en YAML), le stocker dans Git et l'appliquer pendant le processus de déploiement via la CLI.

Workflow

J'ai coécrit un billet de blog sur l'ingénierie anthropique avec @mc_anthropic, @gcemaj et @jkeatn, qui fournissait une explication détaillée de la construction de Claude Managed Agents. Une conclusion clé de l'article était que permettre aux agents d'évoluer avec le niveau d'intelligence de Claude est fondamentalement un « problème d'infrastructure », pas seulement un problème de conception de framework d'exécution.

Cela signifie que le véritable défi ne réside pas dans « comment écrire un agent plus intelligent », mais dans la façon de construire un système qui peut fonctionner de manière stable à long terme, être évolutif et évolutif, permettant à l'agent d'entreprendre des tâches de plus en plus complexes et de longue durée.

Sur la base de cette philosophie, nous did-133">n'avons pas conçu de framework d'exécution d'agent fixe (harnais) car nous avions anticipé son évolution continue. Au lieu de cela, nous avons "découplé" plusieurs éléments clés du système:

« Cerveau » (Claude et son environnement d’exécution)

« Mains » (bac à sable et outil réalisant des actions concrètes)

« Session » (enregistre les journaux d’événements d’exécution)

Ces trois éléments ont été conçus comme des interfaces indépendantes avec un minimum d'hypothèses les unes sur les autres. Chaque pièce peut tomber en panne ou être remplacée indépendamment sans affecter le système global.

Dans cet article, nous avons également expliqué comment cette architecture apporte une fiabilité, une sécurité et une flexibilité accrues, tout en laissant place à l'intégration future de nouveaux frameworks d'exécution, bacs à sable ou sessions d'hébergement d'infrastructures.

Conclusion

Je suis très enthousiaste à l'idée de projets explorant l'orchestration multi-agents ou les tâches à long horizon. Une chose qui m'a toujours frustré dans le passé est la façon dont le cadre d'exécution de l'agent peine à suivre l'évolution des capacités du modèle.

L'importance de Claude Managed Agents est qu'il s'occupe du cadre d'exécution et de la couche infrastructure pour vous, vous permettant de vous concentrer sur un niveau supérieur - traitant l'« agent » lui-même comme une nouvelle primitive fondamentale dans l'API Claude, permettant ainsi une exploration et un développement plus poussés en plus.

[Original Post Link]