Le modèle d’agent

Qu’est-ce qu’un agent ?

Un agent est un acteur nommé doté d’une personnalité, 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 titre que les humains : ils rédigent des messages, possèdent des tickets, laissent des révisions et figurent sur la même liste. Ce sont eux qui font le travail.

Chaque agent appartient à exactement un espace de travail. C’est un invariant absolu — agent.workspaceId n’est jamais nul, c’est l’espace de travail de l’agent lui-même qui détermine dans quel fichier de base de données ses lignes atterrissent, et la création d’un agent sans espace de travail est refusée.

Un agent est aussi un répertoire. Sa définition se trouve dans agents/<slug>/AGENTS.md, sous le répertoire de données de l’espace de travail, et les skills qu’il détient y sont liés symboliquement 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 qu’un agent contient

Attribut	Ce qu’il fait
`name`	Identifiant court de type slug (`architect`, `qa`). Aussi ce sur quoi les `@mentions` se résolvent
`title`	Titre de poste lisible par un humain
`persona`	Personnalité et instructions comportementales en texte libre, injectées comme section du 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é par des liens de skills sur disque
`adapterId`	L’exécuteur vers lequel l’agent est lancé. Null revient à la boucle intégrée
`modelId`	Le modèle à utiliser au sein de cet adaptateur
`effort`	Niveau de raisonnement, tiré du vocabulaire propre au modèle sélectionné
`contextSize`	Remplacement de la taille de la fenêtre de contexte
`silenceTimeoutMinutes`	Remplacement par agent (1–240) du chien de garde d’inactivité
`reportsTo`	Identifiant 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 remplissez ensuite.

Skills

Les skills sont des noms insensibles à la casse sur 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é en soi — il n’existe aucune bibliothèque de prompts par skill qui en dépendrait.
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 ; taper /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 à refus par défaut 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 pas de catalogue organisé, de sorte que les métadonnées du dépôt lui-même (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écurité. 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 le contrôle avant de remplacer quoi que ce soit. La marche à suivre se trouve dans installer et gérer des skills.

Skills à portée de 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 ceux-ci changent lorsqu’il se déplace.

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 qu’une simple lecture d’un dépôt à l’autre ne le fait pas, de sorte que suivre un symbole jusque dans un service voisin ne remplace jamais l’ensemble au beau milieu d’une tâche. Dans un espace à dépôt unique, la réponse est connue avant le premier tour.

Cette délimitation est une décision de budget de contexte. L’index des skills se trouve dans le prompt à chaque tour, tandis que les corps n’y sont pas, de sorte que lister les skills de tous les dépôts à la fois coûte des tokens en continu — et qu’un skill testing provenant d’un service induit activement en erreur quand le travail se fait dans un autre. C’est le même raisonnement qui fait que l’index d’un agent ne porte qu’un dépôt, alors que le composeur n’est pas délimité de cette façon : 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 chaque adaptateur, pas seulement pour le harnais intégré. Les skills du dépôt actif sont matérialisés dans le répertoire de travail de l’agent, soit 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 à refus par défaut qu’un skill installé avant que tout cela ne se produise — 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étermine ce qui peut être appliqué

Le champ le plus déterminant d’un agent est son adaptateur, parce que le transport de l’adaptateur détermine quelle part de la politique de Control Center est réellement applicable.

Transport	Adaptateurs	Ce que Control Center applique
Harnais intégré	Control Center (built-in)	Tout. La surface d’outils est construite à partir du mode, de sorte qu’un outil non autorisé est invisible plutôt que simplement refusé ; chaque appel passe le contrôle d’approbation et les garde-fous d’action ; le contrat d’achèvement peut relancer, puis faire échouer, une exécution qui se termine sans son livrable
CLI Claude	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 outils de lecture, d’écriture et d’édition propres à Claude vivent dans son processus et s’exécutent sans être vus — et il est lancé avec `--dangerously-skip-permissions`, parce que `claude -p` en mode non interactif bloquerait sinon indéfiniment sur son propre prompt

Concrètement, seul le harnais intégré prend en charge les sous-agents, le pilotage en cours d’exécution, la mise en pause et la reprise (et donc la prise de contrôle) ainsi que l’application structurelle des modes. Claude Code n’a rien de tout cela.

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 du système d’exploitation de l’hôte lorsqu’il en existe un — Seatbelt sur macOS, bubblewrap sur Linux et WSL2 — de sorte qu’un rm invisible ou une écriture invisible reste tout de même borné par le système d’exploitation. Sur Windows, il n’y a aucun backend, et sur Linux ou WSL2 sans bwrap et socat, la sonde n’en signale aucun ; là, ces exécutions se rabattent sur l’assainissement de l’environnement, les identifiants délivrés par le courtier, 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 sur Windows).

Ce que le bac à sable n’est pas, c’est un poste de contrôle. Il délimite les endroits 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 ni intercepter un appel, ni déclencher une approbation, ni vous dire après coup ce que la CLI a tenté. Cela, plus les quatre capacités nommé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 revient à 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 : les cinq agents d’un nouvel espace de travail s’exécutent donc tous là, sur le modèle par défaut d’Anthropic, jusqu’à ce que vous définissiez un adaptateur et un modèle pour chaque agent. Le choix d’adaptateur par défaut de l’intégration 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 et quatre spécialistes (qa, architect, engineer, librarian) qui lui rendent compte, créés de façon idempotente en arrière-plan au moment de 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 aucune ligne ; passez par cet écran.

État en direct

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

É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 sa vivacité est en échec ou morte
`blocked`	La vivacité de la dernière exécution est bloquée, stagnante 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 d’exécution d’une conversation ; la liste ne les produit jamais, parce qu’une exécution terminée au vert est un fait qui concerne l’exécution, et 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 — en réflexion, en exécution, bloqué en attente d’approbation, terminé — et c’est ce qui fait apparaître les agents aux côtés des humains. Voir Multijoueur.

Concepts connexes

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