Mécanismes internes du runtime

Cette page est le complément orienté architecture du reste de la section Agents : comment le runtime applique les permissions par agent, délimite la portée de la mémoire et attribue les journaux. Pour configurer et exécuter des agents, commencez par Agents ; pour la référence des champs au niveau du schéma, consultez Config ; pour les étapes de configuration en conditions réelles, consultez Multi-agent setup.

Modèle d’autorisations

Le SecurityPolicy effectif de chaque agent est construit par SecurityPolicy::for_agent(config, alias) :

1. Partez du profil de risque de l’agent ([risk_profiles.<profile>]).
2. Définit la limite sur le répertoire de l’espace de travail propre à chaque agent (<install>/agents/<alias>/workspace/).
3. Parcourir [agents.<alias>.workspace.access] :
   • Read → l’espace de travail du frère ou de la sœur arrive dans la liste d’autorisations en lecture seule.
   • Write / ReadWrite → l’espace de travail du frère est ajouté à la liste d’autorisation en lecture-écriture.
4. Si [agents.<alias>.workspace.unrestricted_filesystem] vaut true, désactivez workspace_only.

La liste d’autorisation en lecture seule est respectée par file_read (et d’autres outils côté lecture) ; la liste d’autorisation en lecture-écriture contrôle file_write, file_edit, git_operations et les invocations de l’outil shell qui touchent aux chemins. Les fichiers de périphérique POSIX (/dev/null, /dev/zero, /dev/random, /dev/urandom) sont toujours lisibles afin que les idiomes shell continuent de fonctionner sans configuration par agent.

Les instances SubAgent créées appliquent la règle selon laquelle un enfant ne peut pas obtenir de privilèges supérieurs à ceux de son parent. La liste complète des axes du validateur et le comportement de partage du budget sont documentés dans Delegation → Permission inheritance.

Modèle de mémoire

Chaque agent possède sa propre instance Arc<dyn Memory>. La fabrique (zeroclaw_memory::create_memory_for_agent) répartit selon le type de backend :

• SQLite / Postgres / Lucid : magasin partagé à l’échelle de l’installation. La table agents associe alias → UUID, et la table memories contient agent_id qui référence cet UUID. La fabrique encapsule le backend interne dans AgentScopedMemory, qui appose l’UUID de l’agent lié sur chaque enregistrement via store_with_agent et filtre chaque rappel via recall_for_agents avec la liste d’autorisation résolue.
• Markdown : répertoire par agent. Le MarkdownMemory de chaque agent écrit dans <install>/agents/<alias>/workspace/MEMORY.md et memory/YYYY-MM-DD.md. Le rappel inter-agents est composé par AgentScopedMarkdownMemory, qui contient le MarkdownMemory de l’agent lié ainsi qu’un ensemble de pairs de paires (alias, MarkdownMemory) et regroupe leurs résultats avec des préfixes d’attribution [<alias>] sur chaque ligne.
• Qdrant : collection partagée, indexée par payload. Le champ de payload agent_id assure l’attribution par agent ; recall_for_agents sur-récupère puis post-filtre selon le payload.
• None : stub no-op. Le wrapper existe toujours afin que le chemin d’exécution soit uniforme.

La mémoire inter-agents multi-backends n’est pas prise en charge : le validateur de schéma au chargement de la configuration rejette les entrées read_memory_from qui pointent vers un homologue sur un backend différent.

Cycle de vie du renommage et de la suppression

Utilisez les contrôles d’agent du tableau de bord de la passerelle ou la CLI dédiée zeroclaw agents pour renommer et supprimer. Dans la version standard avec gateway et agent-runtime activés, les deux interfaces exécutent les cascades de références et d’état possédé ; le fait de supprimer ou de re-clé directement agents.<alias> en TOML ou via un setter de configuration générique ne le fait pas. Une CLI à fonctionnalités réduites met toujours à jour les références de configuration mais avertit que l’état possédé n’a pas été cascadé ; utilisez donc une version avec les deux fonctionnalités activées pour les opérations de cycle de vie.

Les deux opérations rendent la modification de configuration durable avant d’exécuter les effets de bord sur l’état détenu. Le renommage réécrit d’abord les références de configuration, puis déplace l’espace de travail par défaut associé à l’alias et repointe l’état de la mémoire, du cron, d’ACP et des sessions. La suppression refuse d’abord les références strictes et les sessions ACP actives, puis retire l’entrée de configuration et les références souples avant de tenter l’archivage de l’espace de travail, l’export et le nettoyage de l’état détenu, ainsi que l’effacement de l’attribution des sessions.

Les effets de bord post-persistance sont faits au mieux et signalent les échecs détectés, mais les échecs d’écriture de fichiers d’archive peuvent n’apparaître que dans les journaux de la passerelle. Les avertissements de renommage invitent à réessayer le même renommage via l’API de la passerelle pour converger les résidus laissés sous l’ancien alias. Après suppression, vérifiez le contenu de l’archive et les journaux avant de vous appuyer sur l’archive pour la récupération. La restauration automatisée n’est pas prise en charge.

Consultez Configuration multi-agent pas à pas pour les contrôles actuels, les bloqueurs, la disposition des archives et les vérifications de l’opérateur.

Non pris en charge actuellement

1. Accès mémoire inter-agents entre back-ends (par exemple, un agent SQLite lisant les lignes d’un agent Postgres).
2. Restauration automatisée à partir d’une archive de suppression d’agent.
3. Espacement de noms des secrets par agent : il existe un seul SecretStore à l’échelle de l’espace de travail.
4. Extensions du format de communication Lucid pour la définition de portée inter-agents.