Grupos de pares
Un peer group declara de quién acepta un agente mensajes entrantes en un canal, y con qué otros agentes puede intercambiar mensajes allí. Es la puerta de entrada para los canales de chat y la primitiva de enrutamiento para el despacho entre agentes. En la configuración se encuentra en [peer_groups.<name>]. Para saber cómo encajan los peer groups en el cableado de un agente, consulte Agents.
Los remitentes entrantes se filtran contra el conjunto de pares resuelto para el agente vinculado, extraído de cada bloque [peer_groups.<name>] al que pertenece el agente. La coincidencia elimina el @ inicial y no distingue entre mayúsculas y minúsculas frente al identificador de remitente nativo del canal. Un conjunto vacío deniega a todos; un conjunto que contiene "*" acepta a cualquiera; en caso contrario, solo se aceptan los external_peers listados (y los agentes pares). Esto es independiente del emparejamiento del gateway ([gateway] require_pairing), que autentica clientes HTTP/WebSocket, no remitentes de canales de chat.
Campos
Un bloque [peer_groups.<name>] contiene:
| Campo | Significado |
|---|---|
channel | Un tipo de canal ("telegram", se aplica a todos los alias de ese tipo) o un alias con punto ("telegram.work", se limita a esa única instancia). |
agents | Agentes miembro por alias. Dos agentes son pares solo cuando ambos aparecen en el mismo grupo; la membresía es mutua. |
external_peers | Miembros no agentes según el nombre de usuario/ID nativo del canal. ["*"] acepta a cualquiera; vacío no acepta a nadie. |
ignore | Lista de bloqueo por grupo; se sustrae del conjunto de pares resuelto. |
output_modality | Modalidad de respuesta preferida para el grupo: mirror (basada en la entrada, predeterminada), voice (responder siempre y entregar mensajes proactivos como notas TTS en canales con capacidad de audio) o text (siempre texto). |
admin_for_agent_scope | Cuando es true, los external_peers del grupo están autorizados a emitir /model --agent <model> en el agente vinculado. Valor predeterminado false (denegar por defecto). Véase Autorización del alcance del agente de administración. |
Resolución
Para un agente dado, el runtime recorre cada grupo en el que aparece el agente, une los alias de los demás miembros (como pares del agente) y los external_peers del grupo en el canal del grupo, y luego resta la lista ignore. El alias propio del agente se elimina de forma defensiva para evitar un bucle consigo mismo. Un agente que no pertenece a ningún grupo de pares se ejecuta en solitario sin despacho entre agentes.
El identificador de remitente con el que cada canal realiza la coincidencia difiere según la plataforma (un ID de usuario de Telegram, un @user:server de Matrix, un número E.164, un UUID, …). Cada página de canal indica la forma del identificador que espera.
Ejemplo
Un grupo de pares de Discord llamado p. ej. my_discord_group establece channel = "discord", permite 111111111111111111 en external_peers, nombra a los agentes pares researcher, summariser, y bloquea 222222222222222222 mediante ignore. Configúralo a través del panel de control del gateway, zerocode o zeroclaw config set.
Cada página de canal muestra la forma directiva con la estructura del identificador de remitente de ese canal.
Autorización de ámbito de agente de administrador
admin_for_agent_scope = true amplía el límite de privilegios del grupo: además de ser un peer enrutable, cada miembro de external_peers tiene अनुमति para emitir /model --agent <model> en el agente vinculado, es decir, cambiar el binding del agente a un modelo distinto del predeterminado. La bandera es de denegación por defecto: todo grupo que no la tenga establecida explícitamente en true deniega esta capacidad, incluidos los grupos con external_peers no vacío. /model --user <model> (anulación solo para la sesión, sin rebinding del agente) no está restringido por esta bandera y está disponible para todo peer aceptado.
El orquestador resuelve en vivo el conjunto de administradores autorizados desde Config::channel_agent_scope_admins, pero la puerta de despacho lee a través de la instantánea de configuración con la que se inició el tiempo de ejecución. Por lo tanto, las ediciones del operador en admin_for_agent_scope (o en external_peers / channel / agents de un grupo) surten efecto en el siguiente reinicio del daemon, no en el proceso en ejecución. Cambiar la bandera en un daemon en vivo no autorizará, por sí solo, a ningún nuevo remitente dentro de la sesión actual.
Esto es deliberado: la autorización se calcula contra la configuración inmutable al arrancar, así que un par que se añade a un grupo de administradores a mitad de ejecución no puede escalar privilegios dentro de la vida útil del proceso actual. El conjunto solo se vuelve a resolver en una recarga completa de la configuración, que en sí misma es una ruta de reinicio. Si una invocación de /model --agent informa “not authorized” para un emisor que esperabas que estuviera dentro del ámbito, reinicia el daemon después de editar admin_for_agent_scope y vuelve a emitir el comando desde una nueva sesión de cliente antes de sacar más conclusiones.