Groupes de pairs
Un peer group déclare de qui un agent accepte les messages entrants sur un canal, et avec quels autres agents il peut y échanger des messages. C’est la porte d’entrée pour les canaux de discussion et la primitive de routage pour la distribution inter-agents. Dans la configuration, il se trouve à [peer_groups.<name>]. Pour comprendre comment les peer groups s’intègrent dans le câblage d’un agent, consultez Agents.
Les expéditeurs entrants sont filtrés par rapport au peer set résolu pour l’agent lié, constitué à partir de chaque bloc [peer_groups.<name>] auquel l’agent appartient. La correspondance supprime un @ initial et est insensible à la casse par rapport à l’identifiant natif de l’expéditeur du canal. Un ensemble vide refuse tout le monde ; un ensemble contenant "*" accepte n’importe qui ; sinon, seuls les external_peers listés (et les agents pairs) sont acceptés. Ceci est distinct de l’appairage de la passerelle ([gateway] require_pairing), qui authentifie les clients HTTP/WebSocket, et non les expéditeurs des canaux de discussion.
Champs
Un bloc [peer_groups.<name>] contient :
| Champ | Signification |
|---|---|
channel | Un type de canal ("telegram", s’applique à tous les alias de ce type) ou un alias avec notation pointée ("telegram.work", limite la portée à cette seule instance). |
agents | Agents membres par alias. Deux agents ne sont pairs que lorsqu’ils apparaissent tous les deux dans le même groupe ; l’appartenance est mutuelle. |
external_peers | Membres non-agents identifiés par le nom d’utilisateur/ID natif du canal. ["*"] accepte tout le monde ; une valeur vide n’accepte personne. |
ignore | Liste de blocage par groupe ; soustraite de l’ensemble de pairs résolu. |
output_modality | Modalité de réponse préférée pour le groupe : mirror (déterminée par l’entrée, par défaut), voice (toujours répondre et envoyer les messages proactifs sous forme de notes TTS sur les canaux compatibles audio) ou text (toujours en texte). |
admin_for_agent_scope | Lorsque true, les external_peers du groupe sont autorisés à exécuter /model --agent <model> sur l’agent lié. Par défaut false (refus par défaut). Voir Autorisation d’administration de portée agent. |
Résolution
Pour un agent donné, le runtime parcourt chaque groupe dans lequel l’agent apparaît, fait l’union des alias des autres membres (en tant que pairs agents) et des external_peers du groupe sur le canal du groupe, puis soustrait la liste ignore. L’alias propre de l’agent est retiré par précaution afin d’éviter une boucle sur lui-même. Un agent n’appartenant à aucun groupe de pairs fonctionne en solo, sans répartition inter-agents.
L’identifiant d’expéditeur que chaque canal utilise pour la correspondance diffère selon la plateforme (un ID utilisateur Telegram, un @user:server Matrix, un numéro E.164, un UUID, …). Chaque page de canal précise le format d’identifiant attendu.
Exemple
Un groupe de pairs Discord nommé par exemple my_discord_group définit channel = "discord", autorise 111111111111111111 dans external_peers, nomme les agents pairs researcher, summariser, et bloque 222222222222222222 via ignore. Configurez-le via le tableau de bord de la passerelle, zerocode ou zeroclaw config set.
Chaque page de canal affiche le formulaire de directive avec la forme d’identifiant d’expéditeur propre à ce canal.
Autorisation de portée de l’agent administrateur
admin_for_agent_scope = true étend le périmètre de privilèges du groupe : en plus d’être un pair routable, chaque membre de external_peers est autorisé à exécuter /model --agent <model> sur l’agent lié, c.-à-d. basculer le binding de l’agent vers un modèle autre que celui par défaut. L’indicateur est en refus par défaut : tout groupe pour lequel il n’est pas explicitement défini à true refuse la capacité, y compris les groupes avec des external_peers non vides. /model --user <model> (surcharge limitée à la session, sans re-liaison d’agent) n’est pas soumis à cet indicateur et est disponible pour chaque pair accepté.
L’orchestrateur résout l’ensemble des administrateurs autorisés en direct depuis Config::channel_agent_scope_admins, mais la porte de dispatch lit via l’instantané de configuration avec lequel le runtime a été démarré. Les modifications de l’opérateur apportées à admin_for_agent_scope (ou aux external_peers / channel / agents d’un groupe) prennent donc effet au prochain redémarrage du démon, et non sur le processus en cours d’exécution. Basculer le flag sur un démon en cours d’exécution n’autorisera pas, à lui seul, de nouveaux expéditeurs au sein de la session courante.
C’est délibéré : l’autorisation est calculée par rapport à la configuration immuable au démarrage, de sorte qu’un pair qui est ajouté à un groupe d’administration en cours d’exécution ne peut pas escalader au sein de la durée de vie du processus actuel. L’ensemble n’est re-résolu que lors d’un rechargement complet de la configuration, qui est lui-même un chemin de redémarrage. Si une invocation /model --agent signale « not authorized » pour un expéditeur que vous attendiez dans le scope, redémarrez le démon après avoir modifié admin_for_agent_scope et réémettez la commande depuis une session client fraîche avant d’en tirer d’autres conclusions.