Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id: ADR-011 title: Les agents configurés ont des limites d’exécution explicites sous un seul daemon date: 2026-07-19 status: accepted relates-to:

  • https://github.com/zeroclaw-labs/zeroclaw/issues/5890
  • https://github.com/zeroclaw-labs/zeroclaw/pull/6398
  • ADR-005
  • ADR-010
  • docs/book/src/agents/overview.md
  • docs/book/src/agents/internals.md
  • docs/book/src/channels/peer-groups.md

ADR-011 : Les agents configurés ont des limites d’exécution explicites au sein d’un seul démon

Il s’agit d’un enregistrement rétroactif de l’architecture multi-agent livrée via #6398 dans v0.8.0-beta-1. La date ci-dessus est la date à laquelle cet ADR a été ajouté, et non la date d’implémentation originale.

La RFC acceptée #5890 proposait un modèle plus large d’UX et de configuration multi-agent. Ce document consigne cinq périmètres durables mis en production : des identités nommées, un seul démon superviseur, des relations explicites entre canaux, une mémoire propre à chaque agent, ainsi qu’un périmètre de stratégie d’exécution et d’espace de travail propre à chaque agent. Il ne ratifie pas l’exigence, non livrée, de rejoindre un agent uniquement par alias de la RFC, le schéma memory_namespaces, la taxonomie des bundles, la structure de l’essaim, ni les contrats différés du tableau de bord et de l’observabilité.

Contexte

ZeroClaw centrait à l’origine la configuration et le comportement d’exécution sur un seul agent implicite. Le fonctionnement multi-agent nécessite des identités pouvant coexister sans partager accidentellement l’espace de travail, la mémoire, les permissions ou l’accessibilité des canaux.

L’implémentation V3 a remplacé le singleton implicite par des agents configurés indexés par alias. Chaque agent résout ses propres entrées d’exécution et ses limites de portée, tandis qu’un démon coordonne l’ensemble activé. Des autorisations explicites connectent les agents là où une collaboration est souhaitée.

Décision

Identité et supervision de l’agent

Chaque entrée [agents.<alias>] définit une identité d’agent adressable. L’alias sélectionne l’agent configuré au niveau de la CLI, du canal, du démon et des autres points d’entrée d’exécution. Une installation à agent unique utilise le même modèle avec une seule entrée configurée ; il n’existe pas d’architecture singleton privilégiée distincte.

Chaque agent possède sa propre limite d’espace de travail et sa propre source d’identité. Les fichiers d’identité sont résolus pour cet agent plutôt qu’à partir d’une personnalité unique valable pour toute l’installation.

Un seul processus zeroclaw daemon supervise les agents configurés activés et leurs liaisons de canal. Cela ne signifie pas que chaque agent possède un processus ou une boucle en exécution permanente. Cela signifie que l’opération du daemon démarre et coordonne l’ensemble configuré, sans nécessiter un daemon par identité.

Communication explicite

La règle durable est que les relations de canal autorisées sont explicites. L’implémentation actuelle utilise des liaisons de canal par agent et des groupes de pairs. La co-résidence dans un même daemon ne fait pas des agents des pairs de canal.

La messagerie inter-agents sur un canal requiert actuellement une relation de groupe de pairs partagée sur le canal concerné. Les groupes de pairs constituent des limites mutuelles de routage et d’acceptation entrante ; les agents en dehors de cette relation ne deviennent pas joignables simplement parce qu’ils sont configurés dans la même installation.

Par souci de compatibilité, l’environnement d’exécution attribue de manière déterministe la propriété des canaux lorsqu’aucun agent configuré ne déclare de liaison de canal. Ce mécanisme de repli préserve les installations plus anciennes ; il n’établit pas le partage implicite comme contrat multi-agent.

La délégation et d’autres capacités inter-agents peuvent imposer des contrôles supplémentaires. Cet ADR ne fait pas de l’appartenance à un groupe de pairs un mécanisme d’autorisation universel pour chaque capacité.

Périmètre de l’espace de travail et de la politique d’exécution

Chaque agent activé détermine un profil de risque et un périmètre d’espace de travail. Le périmètre par défaut du système de fichiers est l’espace de travail propre à l’agent. Une entrée d’accès sur l’agent ciblé accorde explicitement à cet agent l’accès à l’espace de travail homologue indiqué.

Le confinement au répertoire de travail peut être désactivé par le profil de risque résolu, notamment en pleine autonomie, ou par le paramètre unrestricted-filesystem de l’agent. Les politiques de chemins interdits et les permissions hôte restantes s’appliquent toujours.

Le partage d’un provider, d’un adaptateur de canal, d’un bundle ou d’une autre configuration référencée ne fusionne pas l’espace de travail des agents ni la portée de la runtime-policy résolue. Cela peut intentionnellement partager la ressource référencée ou les identifiants : les secrets restent à l’échelle de l’installation plutôt que par agent.

Isolation de la mémoire

L’identité d’agent configurée est la portée consommée par le contrat mémoire. Les backends appliquent cette portée via des métadonnées d’agent stockées ou une limite de stockage détenue par l’agent et un adaptateur à portée limitée.

Le rappel inter-agents est additif et explicite. Il nécessite un accès compatible au même backend ; le runtime n’établit pas silencieusement de passerelle entre différents types de backend.

ADR-005 gère le stockage, l’attribution, les listes d’autorisation de rappel, la compatibilité des backends et les contraintes sur les opérations destructives. ADR-010 définit séparément les limites d’autorité entre l’historique de session, la mémoire organisée et l’enrichissement.

Limite d’évolution de schéma

La décision durable est le modèle d’identité nommée et de délimitation explicite ci-dessus. Les références de configuration exactes, les alias de bundles et les champs du système de fichiers peuvent évoluer sans remplacer cet ADR, tant que ces délimitations restent intactes.

Conséquences

Conséquences positives :

  • Les installations mono-agent et multi-agents partagent un seul modèle d’exécution.
  • Les opérateurs peuvent raisonner sur l’espace de travail, la mémoire, la politique d’exécution et l’accessibilité des canaux pour chaque agent nommé.
  • Le partage est visible à travers la configuration plutôt qu’inféré à partir de la co-résidence des processus.
  • La collaboration inter-agents peut être ajoutée de manière sélective sans affaiblir les limites de portée par défaut.

Conséquences négatives :

  • Chaque point d’entrée prenant en charge les agents doit transmettre ou résoudre correctement un alias d’agent.
  • La validation de la configuration doit rejeter les alias orphelins et les autorisations inter-agents incompatibles avant toute utilisation à l’exécution.
  • Les backends et adaptateurs partagés à l’échelle de l’installation nécessitent une attribution et un filtrage par agent plutôt que de s’appuyer sur des processus séparés pour la portée.
  • Les secrets restent globaux à l’installation ; la portée par agent de l’espace de travail et de la politique d’exécution n’implique donc pas l’isolation des identifiants par agent.

Décisions de suivi :

  • Les nouvelles fonctionnalités inter-agents doivent définir leur propre périmètre d’autorisation et d’attribution plutôt que de supposer que l’appartenance à un groupe de pairs ou à un démon est suffisante.
  • Les changements qui affaiblissent l’espace de travail par défaut, le profil de risque ou la portée de la mémoire nécessitent une décision explicite d’architecture et de sécurité.

Références