Le modèle d’agent

Qu’est-ce qu’un agent ?

Un agent est un acteur nommé, doté d’une persona, d’un ensemble de skills et d’un adaptateur sur lequel s’exécuter. Les agents sont des acteurs de plein droit, au même sens que les humains : ils rédigent des messages, possèdent des tickets, déposent des revues et figurent dans la même liste. Ce sont eux qui font le travail.

Chaque agent appartient à exactement un espace de travail. C’est un invariant strict — agent.workspaceId n’est jamais nul, c’est l’espace de travail de l’agent qui détermine le fichier de base de données où atterrissent ses lignes, et créer un agent sans espace de travail est refusé.

Un agent est aussi un répertoire. Sa définition vit dans agents/<slug>/AGENTS.md, sous le répertoire de données de l’espace de travail, les skills qu’il détient étant liés par lien symbolique dans agents/<slug>/.agents/skills. La ligne en base de données et le fichier sont écrits ensemble. L’amorçage est idempotent : si la ligne de l’agent existe déjà, les fichiers sur disque et les liens de skills sont tout de même réécrits. L’appelant en production est la création de l’espace de travail, et non chaque démarrage du serveur.

Ce que porte un agent

Attribut	Ce qu’il fait
`name`	Identifiant court de type slug (`architect`, `qa`). C’est aussi ce sur quoi les `@mentions` sont résolues
`title`	Intitulé de poste lisible par un humain
`persona`	Instructions libres de personnalité et de comportement, injectées comme section de prompt
`systemPrompt`	Instructions supplémentaires facultatives, injectées comme section « Agent instructions » — elles ne remplacent pas le reste du prompt assemblé
`skills`	Ensemble de noms de skills insensible à la casse, reflété sous forme de liens de skills sur le disque
`adapterId`	L’exécuteur vers lequel l’agent est envoyé. Une valeur nulle retombe sur la boucle intégrée
`modelId`	Le modèle à utiliser dans cet adaptateur
`effort`	Niveau de raisonnement, tiré du vocabulaire propre du modèle sélectionné
`contextSize`	Remplacement de la fenêtre de contexte
`silenceTimeoutMinutes`	Remplacement par agent (1–240) pour la surveillance du silence
`reportsTo`	Id de l’agent parent — la chaîne hiérarchique que dessine l’organigramme

Vous modifiez tous ces champs dans Paramètres → Espace de travail → Agents. Nouvel agent crée un agent sans nom que vous complétez ensuite.

Skills

Les skills sont des noms insensibles à la casse portés par l’entité agent. Deux choses distinctes se produisent avec eux :

Les noms sont listés dans le prompt assemblé sous un titre « Skills ». C’est tout ce que fait l’ensemble de l’entité à lui seul — il n’existe aucune bibliothèque de prompts par skill qui en dépende.
Le répertoire de chaque skill nommé (skills/<slug>/SKILL.md dans l’espace de travail) est lié dans le dossier propre à l’agent. Sur le harnais intégré, le frontmatter des skills liés est chargé automatiquement dans le prompt système et l’agent lit un corps à la demande ; saisir /skill:<name> dans une conversation charge ce corps comme directive pour le tour.

Les skills récupérés de l’extérieur passent une analyse de chaîne d’approvisionnement à échec fermé entre la récupération et l’écriture — aucun contenu de skill n’atteint le disque ou un prompt sans verdict. L’extérieur, ce sont les dépôts GitHub que vous enregistrez vous-même comme sources de skills : il n’existe aucun magasin curaté, donc les métadonnées propres du dépôt (sa description, ses étoiles, le nom du skill) sont des données d’affichage non fiables et le verdict de l’analyse est le seul signal de sûreté. Une installation récupère tout le répertoire du skill, l’épingle au commit d’où il provient dans skills-lock.json, et une mise à jour ultérieure repasse la porte avant de remplacer quoi que ce soit. Le mode opératoire se trouve dans Installer et gérer des skills.

Skills limités au dépôt

Un dépôt peut fournir ses propres skills, dans n’importe lequel des emplacements conventionnels (.agents/skills/, .claude/skills/, .opencode/skills/). Un espace extrait chaque dépôt lié côte à côte sous repos/<name>/, mais un agent travaille dans un seul dépôt à la fois — il ne porte donc que les skills de ce dépôt, et ils sont échangés lorsqu’il change de dépôt.

Le dépôt actif est déduit des fichiers que l’agent touche : écrire un fichier sous repos/<name>/ fait de ce dépôt le dépôt actif, alors que la simple lecture d’un dépôt à l’autre ne le fait pas ; ainsi, suivre un symbole jusque dans un service voisin ne fait jamais changer l’ensemble sous les pieds d’une tâche. Dans un espace à dépôt unique, la réponse est connue avant le premier tour.

Ce cloisonnement est une décision de budget de contexte. L’index des skills est présent dans le prompt à chaque tour, contrairement aux corps, si bien que lister d’un coup les skills de tous les dépôts coûte des jetons en continu — et un skill testing provenant d’un service induit activement en erreur lorsque le travail se fait dans un autre. C’est la même logique qui fait que l’index d’un agent ne porte qu’un seul dépôt, alors que le composeur n’est pas cloisonné de la même manière : nommer soi-même un skill est un acte explicite, si bien que /skill:<repo>:<name> atteint n’importe quel dépôt de l’espace.

Les skills de dépôt sont chargés pour tous les adaptateurs, pas seulement le harnais intégré. Les skills du dépôt actif sont matérialisés dans le répertoire de travail de l’agent, qui est le chemin que Claude Code analyse déjà ; le même index est composé dans l’AGENTS.md que lit le harnais intégré. Les skills d’un dépôt passent la même analyse à échec fermé qu’un skill installé avant tout cela — un dépôt extrait est du contenu cloné, et son frontmatter atteint un prompt.

Autorisations

Un agent ne porte aucun indicateur d’autorisation qui lui soit propre. Le droit de créer un commit, de pousser, d’ouvrir une pull request, d’écrire dans un outil de suivi ou d’atteindre le réseau relève des garde-fous d’action — autoriser, demander d’abord ou refuser, à la portée de l’espace de travail, de l’agent ou de l’espace — et les mêmes règles s’appliquent quel que soit l’adaptateur qui l’exécute.

Ce qui est remis à une exécution ne change pas avec ces règles. Une exécution dans un arbre de travail GitHub reçoit toujours un jeton GitHub en lecture seule, et un push fait l’objet d’une question au moment où il a lieu : la configuration git de l’agent fait passer chaque push GitHub par Control Center, qui applique la règle Pousser vers un dépôt distant avant de le transmettre.

Voir Bac à sable et sécurité pour le fonctionnement de ce mécanisme, y compris ce qui est ou n’est pas appliqué au niveau du système de fichiers.

L’adaptateur décide de ce qui peut être appliqué

Le champ le plus déterminant d’un agent est son adaptateur, car le transport de l’adaptateur détermine quelle part de la politique de Control Center peut réellement être appliquée.

Transport	Adaptateurs	Ce que Control Center applique
Harnais intégré	Control Center (built-in)	Tout. La surface d’outils est construite à partir du mode, si bien qu’un outil interdit est invisible plutôt que simplement refusé ; chaque appel passe la porte d’approbation et les garde-fous d’action ; le contrat d’achèvement peut aiguillonner puis faire échouer une exécution qui se termine sans son livrable
Claude CLI	Claude Code	Les outils `mcp__*` qui lui sont fournis, plus ses commandes `Bash`, qu’un hook envoie à la politique d’action avant leur exécution. Les propres outils de lecture, d’écriture et d’édition de Claude vivent dans son processus et s’exécutent sans être vus — et il est lancé avec `--dangerously-skip-permissions`, car un `claude -p` non interactif bloquerait sinon indéfiniment sur sa propre invite

Concrètement, seul le harnais intégré prend en charge les sous-agents, le pilotage en cours d’exécution, la pause et la reprise (et donc la prise en main) et l’application structurelle du mode. Claude Code n’en bénéficie d’aucun.

Le tableau ci-dessus porte sur ce que Control Center peut voir et contrôler. En dessous, cc_server enveloppe la CLI Claude Code dans le bac à sable de l’OS de l’hôte lorsqu’il en existe un — Seatbelt sur macOS, bubblewrap sous Linux et WSL2 — si bien qu’un rm invisible ou une écriture invisible reste borné par l’OS. Sous Windows, il n’existe aucun backend et sous Linux ou WSL2 sans bwrap ni socat, la sonde n’en signale aucun ; là, ces exécutions retombent sur l’assainissement de l’environnement, les identifiants intermédiés, les garde-fous sur les appels que Control Center peut voir et l’arbre de travail propre à la conversation (copie sur écriture là où rift est livré ; git worktree sous Windows).

Ce que le bac à sable n’est pas, c’est une porte. Il borne les lieux où un processus peut lire, écrire et se connecter — un mode en lecture seule l’atteint bel et bien, sous forme de montages liés en lecture seule — mais il ne peut pas intercepter un appel, déclencher une approbation ni vous dire après coup ce que la CLI a tenté. Cela, plus les quatre capacités citées juste au-dessus, reste ce que le harnais intégré possède et que les autres n’ont pas. Voir Bac à sable et sécurité.

Un agent sans adaptateur retombe sur Control Center (built-in) — la boucle à l’intérieur du serveur, donc aucune CLI à installer — et son journal d’exécution consigne cc-harness. Chaque agent amorcé est créé sans adaptateur ni modèle, si bien que les cinq agents d’un espace de travail neuf s’exécutent tous là, sur le modèle par défaut d’Anthropic, tant que vous n’avez pas défini un adaptateur et un modèle par agent. Le choix « adaptateur par défaut » de la configuration initiale est une préférence côté client que le serveur ne lit jamais, et il ne s’applique pas rétroactivement aux agents déjà créés.

D’où viennent les agents

Amorcés avec l’espace de travail. Chaque espace de travail — pas seulement le premier — reçoit un CEO plus quatre spécialistes (qa, architect, engineer, librarian) qui lui rendent compte, créés de manière idempotente en arrière-plan à la création de l’espace de travail. Voir Espaces de travail et isolation.
Ajoutés à la main dans Paramètres → Espace de travail → Agents. Demander à un agent d’embaucher un collègue ne crée pas de ligne ; passez par cet écran.

État en direct

Un agent n’a pas de colonne de statut stockée. Son état en direct est dérivé de ses journaux d’exécution les plus récents à chaque lecture :

État	Signification
`neverRun`	Aucun journal d’exécution n’existe
`running`	Au moins une exécution est en cours
`failed`	La dernière exécution a échoué, ou son état de vivacité est en échec ou mort
`blocked`	L’état de vivacité de la dernière exécution est bloqué, figé ou en boucle
`idle`	Tout le reste — l’agent s’est déjà exécuté et n’a rien en cours

Deux autres états, queued et succeeded, existent pour les exécutions individuelles dans l’arbre des exécutions de la conversation ; la liste des agents ne les produit jamais, car le fait qu’une exécution terminée soit verte est un fait concernant l’exécution, non l’agent.

La liste de présence affiche une image parallèle et plus grossière, synthétisée côté serveur à partir des événements d’exécution en direct — réflexion, en cours, bloqué en attente d’approbation, terminé —, ce qui fait apparaître les agents aux côtés des humains. Voir Multijoueur et présence.

Concepts connexes

Cycle de vie du lancement d’un agent : ce qui se passe lorsqu’un agent est réellement exécuté
Modes : le réglage propre à chaque conversation qui façonne la surface d’outils d’un agent
Multijoueur : les agents comme acteurs de plein droit, la présence et le réglage d’autonomie
Bac à sable et sécurité : ce qui contraint une exécution aujourd’hui
Configuration des agents : la liste complète des champs