Composants Filesystem

La moitié relationnelle d’un agent pointe vers la configuration ; la moitié sur disque réside sous la racine d’installation. L’organisation est structurée par portée, et non en une arborescence unique et plate : l’état à l’échelle de l’instance, les ressources partagées entre agents et les données privées par agent disposent chacun de leur propre répertoire de premier niveau.

<install>/
├── data/                         — instance-wide state (not per-agent)
│   ├── sessions/                 — chat session stores
│   │   └── sessions.db, acp-sessions.db
│   ├── state/                    — runtime state
│   │   └── costs.jsonl, runtime-trace.jsonl
│   ├── devices.db                — paired-device metadata
│   └── memory/                   — shared instance memory
│       └── brain.db, audit.db, response_cache.db,
│           MEMORY_SNAPSHOT.md, archive/
├── shared/                       — resources agents draw on in common
│   └── skills/<bundle>/          — skill bundles
│       └── SKILL.md, scripts/, references/, assets/
└── agents/                       — per-agent private data
    └── <alias>/
        └── workspace/            — the agent's jailed filesystem sandbox
            └── memory/
                └── brain.db

Les trois racines correspondent à trois portées :

• **data/** contient l’état propre à l’installation dans son ensemble, et non à un agent en particulier : les sessions de chat sessions/, l’état d’exécution state/ (suivi des coûts et assimilés), les métadonnées des appareils appairés dans devices.db, et la mémoire partagée de l’instance sous data/memory/. Les jetons bearer de la passerelle valides restent un état de configuration ; devices.db rend les appareils appairés visibles et gérables.
• shared/ contient les ressources que les agents utilisent en commun, notamment les ensembles de compétences sous shared/skills/<bundle>/.
• agents/<alias>/ contient tout ce qui est privé à un agent. Par défaut, l’espace de travail d’un agent est <install>/agents/<alias>/workspace/, et tout ce que l’agent lit ou écrit reste à l’intérieur de celui-ci. La source d’identité de l’agent est résolue relativement à cet espace de travail. Les agents sont cloisonnés dans leur propre espace de travail, sauf si vous accordez explicitement un accès inter-agents.

Espace de travail

L’espace de travail est le bac à sable du système de fichiers de l’agent. Les champs ci-dessous sont générés à partir du schéma :

zeroclaw config set agents.<alias>.workspace.access <value>

export ZEROCLAW_agents__<alias>__workspace__access=

zeroclaw config set agents.<alias>.workspace.path <value>

export ZEROCLAW_agents__<alias>__workspace__path=

zeroclaw config set agents.<alias>.workspace.read_memory_from <value>

export ZEROCLAW_agents__<alias>__workspace__read_memory_from=

zeroclaw config set agents.<alias>.workspace.unrestricted_filesystem <value>

export ZEROCLAW_agents__<alias>__workspace__unrestricted_filesystem=

Deux points méritent d’être soulignés :

• access est une liste d’autorisation entrante pour le partage de système de fichiers entre agents. Vide signifie cloisonné (espace de travail propre uniquement) ; une entrée accorde à un agent frère nommé un mode de lecture ou d’écriture dans l’espace de travail de cet agent.
• unrestricted_filesystem est la porte de sortie : lorsque défini à true, l’agent peut accéder à tout ce que le système de fichiers de l’hôte autorise. Il est désactivé par défaut et son activation est auditable.

Mémoire

Chaque agent conserve son propre stockage de mémoire dans son espace de travail (agents/<alias>/workspace/memory/), distinct de la mémoire d’instance partagée dans data/memory/. Le backend est sélectionné par agent :

zeroclaw config set agents.<alias>.memory.backend <value>

export ZEROCLAW_agents__<alias>__memory__backend=

Le backend est SQLite par défaut pour un nouvel agent. Une fois que l’agent a écrit des données sur disque, cette valeur est verrouillée : vous ne pouvez pas remplacer silencieusement un backend sous une mémoire existante. Le partage de mémoire entre agents est optionnel et s’active via la liste d’autorisation read_memory_from de l’espace de travail. Les entrées héritées sous forme de chaînes accordent toutes les catégories. Les entrées structurées peuvent restreindre un agent voisin à des noms de catégories exacts, sur les backends qui conservent les catégories par ligne. La mémoire Markdown rejette les autorisations restreintes, car ses fichiers ne portent pas cette attribution. Pour le modèle de mémoire lui-même, voir Fonctionnement interne du runtime. Pour une carte transversale de l’état du système, voir État et persistance du runtime.

Identité

L’identité d’un agent (sa personnalité) est définie individuellement pour chaque agent :

zeroclaw config set agents.<alias>.identity.aieos_inline <value>

export ZEROCLAW_agents__<alias>__identity__aieos_inline=

zeroclaw config set agents.<alias>.identity.aieos_path <value>

export ZEROCLAW_agents__<alias>__identity__aieos_path=

zeroclaw config set agents.<alias>.identity.format <value>

export ZEROCLAW_agents__<alias>__identity__format=

Le format sélectionne la manière dont l’identité est chargée. La valeur par défaut lit les fichiers de personnalité du projet ; l’alternative charge une définition JSON AIEOS, soit depuis un chemin relatif à l’espace de travail, soit en ligne.