Agents

Les agents sont la vedette d’un déploiement ZeroClaw. Tout le reste de ce livre, les fournisseurs, les canaux, les profils de sécurité, les compétences, la mémoire, existe pour qu’un agent puisse l’utiliser. Cette section est la vitrine ; le reste de la documentation constitue le générique.

Multi-agent. ZeroClaw exécute plusieurs agents à partir d’une seule installation. Chaque agent possède son propre ensemble de références (profil de risque, fournisseur de modèle, canaux), son propre répertoire d’espace de travail et son propre backend de mémoire. Un agent peut générer un SubAgent éphémère qui hérite de l’identité et de la politique de sécurité de son parent, et les agents peuvent communiquer entre eux lorsqu’ils partagent un peer group. Dans la configuration, chaque agent est un bloc [agents.<alias>]. Voir Agents → Runtime internals.

Un agent est une jointure

Un agent n’est pas un programme que vous installez. C’est une ligne nommée, [agents.<alias>], qui joint deux moitiés :

• Références de configuration (le côté relationnel) : des pointeurs vers des éléments configurés ailleurs, un fournisseur de modèle, un profil de risque, un profil d’exécution, des canaux, des bundles de compétences / connaissances / MCP, des tâches cron. Chacun est un alias en notation pointée. L’agent ne possède aucun de ces éléments ; il pointe vers eux, et de nombreux agents peuvent pointer vers le même élément ou diverger librement.
• Composants Filesystem (le volet stocké sur disque) : un répertoire d’espace de travail par agent, un backend de mémoire et une source d’identité (personnalité). C’est là que le graphe relationnel rejoint une arborescence de répertoires concrète.

  Config references (relational)              Filesystem (on-disk)
  ──────────────────────────────             ──────────────────────
  - model provider                           - workspace/
  - risk profile                             - memory store
  - runtime profile          agents.<alias>  - identity / personality
  - channels             ──▶  (the join)  ◀──
  - peer groups
  - skill / knowledge / MCP bundles
  - cron jobs

L’agent pointe vers les références à gauche, sans en posséder aucune : plusieurs agents peuvent en partager une ou diverger librement. Il possède la moitié du système de fichiers à droite.

Chaque référence est un lien vers sa propre section, les crédits : les fournisseurs de modèles se trouvent dans Model Providers, les profils dans Security & Autonomy, les canaux dans Channels, les groupes de pairs dans Peer Groups, les bundles dans Tools.

Multi-agent dès le départ

Il n’existe pas d’agent privilégié, « l’agent ». Le runtime maintient une map d’agents indexée par alias ; une installation mono-agent n’est qu’une map de taille un. Vous ne commencez pas avec un bot pour en greffer d’autres plus tard, vous ajoutez des agents et câblez chacun d’eux, et ils coexistent dès la première ligne de configuration.

Parce que chaque agent joint ses propres références et son propre système de fichiers, les agents peuvent partager certains axes et diverger sur d’autres de manière indépendante. Deux agents peuvent partager un même fournisseur de modèle mais s’exécuter sous des profils de risque différents, répondre sur des canaux différents et conserver une mémoire entièrement séparée.

Les agents communiquent entre eux de deux façons, chacune contrôlée séparément : ils peuvent envoyer des messages sur un canal où ils partagent un groupe de pairs, et ils peuvent déléguer une tâche à un autre uniquement lorsque le profil de risque de l’appelant autorise la délégation et que la cible fait partie de l’ensemble accessible par l’appelant (un pair du même profil, ou une entrée inter-profils explicite dans la liste delegates de l’appelant ; voir Exécuter des agents).

                    agents.researcher          agents.support
                    ─────────────────          ──────────────
  model provider     openrouter.prod ◀───────── openrouter.prod   (same one)
  risk profile       hardened                   permissive        (diverge)
  channel            discord.main               slack.helpdesk    (diverge)
  peers              └──────▶ peer group on discord.main ◀───────┘

Deux agents partagent un même fournisseur de modèle, s’exécutent sous des profils de risque différents, répondent sur des canaux différents et ne se rencontrent que là où ils partagent un groupe de pairs.

Un SubAgent est l’exception éphémère à la coexistence : un agent peut générer un SubAgent éphémère qui hérite de l’identité et de la politique de sécurité du parent pour une tâche unique. Voir Delegation & SubAgents.

Où aller ensuite

• Anatomie d’un agent : chaque champ de [agents.<alias>], et ce que chaque référence désigne.
• Composants Filesystem : l’espace de travail, la mémoire et l’identité qui résident sur disque pour chaque agent.
• Exécution des agents : adressage des agents, coexistence et comment un agent apparaît dans les volets Code et Chat de zerocode.

Pour les détails internes du runtime, le modèle de permissions, le modèle de mémoire et la boucle de l’agent, consultez Détails internes du runtime.