Différences avec le service hébergé
Découvrez quelles fonctionnalités seul Claude Managed Agents auto-hébergé possède, lesquelles des fonctionnalités hébergées il ne possède pas, lesquelles se comportent différemment et lesquelles nécessitent d’abord un paramètre du serveur.
Un serveur Claude Managed Agents auto-hébergé possède la même API que le service Managed Agents hébergé d’Anthropic, à l’exception des différences présentées sur cette page. Les tableaux indiquent la marche à suivre pour chaque élément. Consultez-les avant de déplacer une application vers votre serveur. Rien n’est copié depuis le service hébergé, y compris l’historique des sessions. Créez à nouveau vos agents, skills, identifiants de coffre-fort et magasins de mémoire sur votre serveur.
Fonctionnalités que seul votre serveur possède
| Fonctionnalité | Ce qu’elle fait | Comment la configurer |
|---|---|---|
| Un choix de fournisseur d’inférence | Le serveur peut envoyer les appels au modèle vers un fournisseur cloud ou votre propre passerelle de modèles au lieu de l’API Claude. | Fournisseur d’inférence |
| Authentification unique | Les personnes appellent le serveur avec un jeton provenant de votre fournisseur d’identité OpenID Connect. Le serveur attribue à chaque appelant un rôle à partir des groupes présents dans le jeton. La clé API du serveur continue de fonctionner. | Authentification unique |
| Votre propre gestionnaire de secrets | Le serveur peut stocker le secret de chaque nouvel identifiant de coffre-fort dans votre gestionnaire de secrets au lieu de sa propre base de données. | Gestionnaire de secrets |
| Identité de l’agent | Le serveur peut signer un jeton de courte durée et l’envoyer avec les appels d’un agent vers un serveur MCP. Le serveur MCP ou la passerelle vérifie le jeton à l’aide des clés publiques que vous publiez. | Identité de l’agent |
Fonctionnalités non disponibles
| Fonctionnalité | Ce qui se passe | Que faire à la place |
|---|---|---|
| Environnements cloud | Seuls les environnements self_hosted existent. Une requête pour un environnement cloud renvoie une erreur 400. | Déployez des workers auto-hébergés pour chaque environnement. |
| Le reste de l’API Claude, comme l’API Messages et l’API Models | Le serveur ne le sert pas. Les appels du SDK vers /v1/messages et /v1/models renvoient une erreur 404. | Envoyez ces requêtes à l’API Claude ou à votre fournisseur, depuis un client qui ne pointe pas vers votre serveur. |
| Ressources de session de type fichier et l’API Files | Le serveur rejette les ressources file, et /v1/files n’existe pas. Les ressources memory_store fonctionnent. | Placez les fichiers dans le répertoire de travail du worker. Consultez Faire entrer et sortir des données d’une session. Pour montrer une image ou un PDF au modèle, envoyez-le en base64 dans un message. |
Identifiants de coffre-fort mcp_oauth | Le serveur les rejette lorsque vous les créez, car il ne dispose d’aucun flux OAuth pour actualiser un jeton. | Stockez le jeton en tant qu’identifiant static_bearer. Mettez à jour l’identifiant avec un nouveau jeton avant l’expiration de l’ancien. |
Skills prédéfinis docx, pdf, pptx et xlsx | Le serveur rejette un agent qui les déclare. Seuls les skills que vous téléversez existent. | Téléchargez leurs sources depuis le dépôt de skills et téléversez-les en tant que skills personnalisés. |
| Déploiements planifiés et rêves | Le serveur ne dispose d’aucune route pour eux. | Démarrez les sessions depuis votre propre planificateur, tel qu’une tâche cron. Les rêves n’ont pas de remplacement. |
| Webhooks | Le serveur n’envoie aucun webhook, de sorte qu’un worker qui démarre sur un webhook ne démarre jamais. | Suivez une session au moyen de son flux d’événements, ou listez ses événements. Maintenez vos workers en cours d’exécution afin qu’ils puissent interroger le serveur. |
Fonctionnalités qui se comportent différemment
| Fonctionnalité | Ce qui diffère | Que faire |
|---|---|---|
| Claude Console | La Claude Console sur platform.claude.com n’affiche pas ce qui se trouve sur votre serveur. | Utilisez la console de votre serveur. |
| Appels d’outils | Les tours du modèle d’une session s’exécutent même lorsqu’aucun worker n’interroge son environnement. Le premier appel d’outil attend alors, sans erreur, jusqu’à ce qu’un worker l’exécute. | Si une session s’arrête sur un appel d’outil, vérifiez qu’un worker interroge bien son environnement. |
| Magasins de mémoire | L’API est complète. C’est le worker, et non le serveur, qui copie chaque magasin attaché dans la sandbox et qui réécrit les modifications dans le magasin. Consultez Magasins de mémoire dans les sandboxes auto-hébergées. | Exécutez vos workers sur la dernière version de ant, avec un répertoire /mnt/memory accessible en écriture. |
| Téléversements de skills personnalisés | Le serveur ne décompresse pas les archives zip. Le téléversement d’une telle archive renvoie une erreur 400 indiquant SKILL.md not found in uploaded files. | ant apply et l’assistant files_from_dir du SDK Python fonctionnent tels quels. Dans les autres cas, téléversez les fichiers du skill en tant que parties distinctes, et faites commencer le nom de fichier de chaque partie par le dossier du skill, comme dans my-skill/SKILL.md. |
| Orchestration multi-agents | Un agent ne peut déléguer qu’aux sous-agents que vous listez. Les workflows dynamiques, le conseiller et les sous-agents que l’agent définit lui-même ne sont pas disponibles. Le serveur accepte un bloc multiagent uniquement si son type est coordinator. Les exemples d’Orchestration multi-agents définissent type sur multiagent_20261001, ce qui renvoie une erreur 400. Un bloc qui comporte un paramètre advisor renvoie également une erreur 400. | Définissez multiagent sur {"type": "coordinator", "agents": [...]}. Listez de 1 à 20 agents dans agents. Chaque entrée prend l’une des formes d’un agent prédéfini. |
| Ressources de session de type dépôt GitHub | Le serveur rejette les ressources github_repository tant que vous n’avez pas listé leurs hôtes Git dans ses paramètres. Le serveur ne découvre pas les skills situés dans le répertoire .claude/skills d’un dépôt, attachez donc les skills à l’agent. | Consultez Les dépôts Git nécessitent une entrée dans la liste d’autorisation. |
| Serveurs MCP | Le serveur se connecte uniquement aux hôtes MCP que vous listez dans ses paramètres. | Consultez Les serveurs MCP nécessitent une entrée dans la liste d’autorisation. |
| Outils web | Les outils web_search et web_fetch sont désactivés tant que vous ne les avez pas activés dans les paramètres du serveur. | Consultez Les outils web nécessitent un paramètre du serveur. |
Identifiants de coffre-fort environment_variable | Le serveur les rejette tant que vous n’avez pas activé la passerelle de sortie, un proxy entre vos sandboxes et Internet. | Consultez Identifiants de variable d’environnement. Sans la passerelle, fournissez à votre sandbox les identifiants de CLI et d’API dont elle a besoin au moyen de vos propres outils. |
| Résultats d’outils personnalisés | Le serveur envoie au modèle l’intégralité du texte d’un résultat d’outil personnalisé. Si un résultat est trop volumineux pour la « context window » (fenêtre de contexte) du modèle, le serveur répond tout de même avec 200, puis la session se termine avec un session.error. | Raccourcissez les résultats longs dans votre client avant de les envoyer. |
| Résultats d’outils MCP | Le serveur tronque un résultat plus volumineux que son paramètre mcp.max_result_bytes, qui vaut 100 Kio par défaut. Il indique au modèle que le résultat a été tronqué, et le reste est perdu. Le service hébergé tronque également les résultats longs, mais peut enregistrer le résultat complet dans un fichier pour une session dans une sandbox cloud. | Pour modifier la limite, définissez mcp.max_result_bytes dans le fichier de paramètres. |
| Images et documents envoyés par URL | Le serveur accepte un bloc image ou document avec une source url, mais le modèle ne le voit jamais, et aucune erreur n’est renvoyée. Il en va de même pour un bloc image avec une source file. | Envoyez les données en base64, ou en text pour un document. |
Le statut de session rescheduling | Le serveur relance un appel au modèle qui échoue pour une raison passagère et signale chaque tentative sur le flux d’événements, comme le fait le service hébergé. Le statut de la session reste running entre les tentatives, de sorte qu’un filtre statuses[]=rescheduling ne correspond à aucune session. | Consultez les nouvelles tentatives dans le flux d’événements. |
| Métadonnées de session, avec une passerelle de modèles | Si le paramètre inference.credentials.assertion.forward_metadata du serveur liste des clés de métadonnées de session, une mise à jour qui ajoute, supprime ou modifie l’une d’elles renvoie une erreur 400. | Définissez ces clés lorsque vous créez la session. Pour le paramètre, consultez Jetons de passerelle à courte durée de vie. |
Fonctionnalités qui nécessitent un paramètre du serveur
Chacune de ces fonctionnalités est désactivée, ou refuse tous les hôtes, tant que vous n’avez pas modifié le fichier de paramètres du serveur.
Les serveurs MCP nécessitent une entrée dans la liste d’autorisation
Le serveur se connecte uniquement aux serveurs MCP dont vous indiquez les hôtes sous mcp.allowed_hostnames dans son fichier de paramètres :
mcp:
allowed_hostnames:
- mcp.example.comLes hôtes doivent correspondre exactement, sans caractères génériques ni sous-domaines, et la liste est vide par défaut. Tant que l’hôte d’un serveur MCP ne figure pas dans la liste, votre serveur refuse d’enregistrer un agent qui le mentionne.
Un serveur MCP situé dans votre réseau privé ne nécessite aucun tunnel MCP. Indiquez son URL dans la définition de l’agent, comme le décrit Connecteur MCP, et ajoutez son hôte à la liste d’autorisation. Deux règles s’appliquent à l’URL :
- Elle doit utiliser
https, sauf si le serveur MCP se trouve sur l’adresse de bouclage. - Si son hôte est un nom qui se résout uniquement vers des adresses privées ou réservées, votre serveur refuse par défaut de s’y connecter. Choisissez la solution adaptée à votre cas :
| Votre cas | Solution |
|---|---|
L’adresse se trouve dans 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, et vous contrôlez les enregistrements DNS du nom | Conservez le nom, et indiquez-le également sous mcp.private_hostnames dans le fichier de paramètres. |
| Tout autre cas | Utilisez l’adresse IP à la place du nom, dans l’URL et dans la liste d’autorisation. Le certificat du serveur MCP doit mentionner cette adresse. |
Les dépôts Git nécessitent une entrée dans la liste d’autorisation
Sur le service hébergé, les sessions qui utilisent des sandboxes auto-hébergées ne peuvent pas avoir de ressources github_repository. Sur votre serveur, elles le peuvent. Le serveur rejette ces ressources tant que vous n’avez pas listé leurs hôtes Git dans son fichier de paramètres. Les agents ne peuvent effectuer un push que vers les branches que vous listez :
git:
allowed_hostnames:
- github.com
allowed_push_refs:
- refs/heads/agent/Notez ces points :
- URL : L’hôte n’a pas besoin d’être
github.com, mais l’URL doit utiliser HTTPS. - Jeton : Le jeton que votre client envoie n’atteint jamais la sandbox, car le trafic Git passe par votre serveur, qui ajoute le jeton.
- Branches : La liste des branches n’est pas communiquée aux agents, nommez donc une branche dans votre prompt.
- Push forcés : Le serveur ne refuse pas les push forcés, de sorte qu’un agent peut écraser n’importe quelle branche que vous listez. Pour refuser les push forcés, protégez la branche sur votre hôte Git.
Accéder à GitHub présente la requête et la manière d’effectuer la rotation d’un jeton. Si un clonage échoue, la session reçoit un événement session.error qui en indique la cause. Pour vérifier un push, recherchez la branche sur votre hôte Git. Le journal du serveur indique ok même pour un push que votre hôte a refusé.
Les outils web nécessitent un paramètre du serveur
Les outils web_search et web_fetch sont désactivés par défaut. Pour les activer, ajoutez ceci au fichier de paramètres du serveur :
web_tools:
enabled: trueAvec ce seul paramètre, les listes de domaines et la limite de contenu propres à chaque agent s’appliquent, comme sur le service hébergé.
Pour limiter les outils pour tous les agents, définissez web_tools.allowed_domains, web_tools.blocked_domains ou web_tools.max_content_tokens. Chacun de ces paramètres active également les outils. Le serveur refuse d’enregistrer un agent qui demande davantage que ce que ces paramètres autorisent. Par exemple, il refuse un agent qui autorise un domaine en dehors de web_tools.allowed_domains, ou qui définit une limite de contenu plus élevée. Si un tel agent existe déjà, il ne peut pas démarrer de session tant que vous ne l’avez pas mis à jour.
Tant que les outils sont désactivés, ce qui arrive à un agent dépend des entrées web_search et web_fetch de son ensemble d’outils :
| L’ensemble d’outils comporte | Ce qui se passe |
|---|---|
| Aucune entrée pour l’un ou l’autre outil | L’agent s’exécute sans les outils, et aucune erreur ne le signale. |
Une entrée qui ne fait que désactiver son outil, telle que {"name": "web_fetch", "enabled": false} | La même chose. |
| Une entrée qui laisse son outil activé, ou qui définit ses listes de domaines, sa limite de contenu ou sa localisation | Le serveur refuse d’enregistrer l’agent, ou de démarrer une session pour lui. |
Les outils web disponibles dépendent également de votre fournisseur d’inférence.
Différences qui dépendent de votre fournisseur d’inférence
Certaines fonctionnalités ne fonctionnent qu’avec certaines valeurs du paramètre inference.provider du serveur. Le tableau indique ce qui se passe avec les autres valeurs. Certains de ces cas ne renvoient aucune erreur.
Les lignes web_search et web_fetch s’appliquent une fois que vous avez activé les outils web. D’ici là, aucun des deux outils ne fonctionne, quel que soit le fournisseur.
| Fonctionnalité | Fonctionne lorsque inference.provider vaut | Avec les autres valeurs | Que faire |
|---|---|---|---|
Outil web_search | anthropic, vertex, foundry | Le serveur ne propose jamais l’outil au modèle. Les agents sont toujours enregistrés et s’exécutent, et listent toujours l’outil, mais le modèle ne peut pas l’appeler. | Fournissez à l’agent un outil personnalisé ou un serveur MCP qui effectue des recherches. |
Outil web_fetch | anthropic, foundry | Identique à web_search. | Fournissez à l’agent un outil personnalisé ou un serveur MCP qui récupère des pages. |
inference_geo | anthropic | Le serveur refuse d’enregistrer un agent qui le définit. | Retirez inference_geo de l’agent. |
Mode rapide (speed: "fast") | Dépend du fournisseur et du modèle de l’agent | Un agent qui le définit doit réussir deux vérifications. Lorsque vous enregistrez l’agent : Le catalogue de modèles du serveur doit répertorier le modèle de l’agent comme un modèle qui accepte le mode rapide. Sinon, le serveur refuse d’enregistrer l’agent. À chaque tour : Si le fournisseur ne propose pas le mode rapide pour ce modèle ou ce déploiement, le tour se termine par une erreur. | Retirez speed de l’agent. Consultez Modèles qui acceptent le mode rapide. |
Avec anthropic, le serveur demande par défaut le repli côté serveur de l’API Claude. Lorsqu’un classificateur de sécurité refuse une requête, un autre modèle Claude, éventuellement moins performant, peut alors y répondre. Anthropic choisit le modèle, et aucun événement ne signale le changement, mais une lecture de la session indique l’ID de ce modèle. Pour désactiver le repli, définissez inference.model_fallback: false. Avec les autres fournisseurs, une telle requête met fin au tour avec un refus.
La documentation de votre fournisseur indique quels modèles et quelles régions prennent en charge chaque fonctionnalité. Les outils personnalisés, les outils MCP et les outils exécutés par votre worker sont identiques quel que soit le fournisseur.
Modèles qui acceptent le mode rapide
Par défaut, le catalogue de modèles du serveur répertorie quatre modèles comme des modèles qui acceptent le mode rapide : Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8 et Claude Opus 4.6. Sur Claude Opus 4.6, l’API Claude accepte la requête mais l’exécute à la vitesse standard. Ces valeurs de inference.provider constituent des exceptions :
foundry: Le catalogue ne répertorie que Claude Opus 5.5.gatewayavecformat: vertex-raw-predict: Le catalogue ne répertorie aucun modèle.vertex: Le catalogue ne répertorie aucun modèle, et aucun paramètre ne permet de changer cela.
Pour modifier ce que répertorie le catalogue, consultez Entrées de modèle.
Si vous exécutez déjà des sandboxes auto-hébergées
Le logiciel du worker est le même, de sorte que vos workers peuvent se connecter à votre serveur. Exécuter vos propres workers liste les trois valeurs pour le processus qui interroge le serveur, et ce qu’il faut modifier en premier. Un worker qui démarre sur un webhook ne fonctionne pas ici.
Cette page vous a-t-elle été utile ?