Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id: ADR-011 title: Los agentes configurados tienen límites de ejecución explícitos bajo un único 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: Los Agentes Configurados Tienen Límites de Ejecución Explícitos Bajo un Solo Daemon

Este es un registro retroactivo de la arquitectura multi-agente implementada a través de #6398 en v0.8.0-beta-1. La fecha anterior es la fecha en que se añadió este ADR, no la fecha de implementación original.

El RFC aceptado #5890 propuso un modelo de configuración y de experiencia de usuario multiagente más amplio. Este registro captura cinco límites duraderos que se publicaron: identidades con nombre, un único daemon supervisor, relaciones de canal explícitas, memoria de alcance por agente, y política de tiempo de ejecución y alcance de espacio de trabajo por agente. No ratifica el requisito no publicado del RFC de unión únicamente por alias, el esquema memory_namespaces, la taxonomía de paquetes, la forma del enjambre, ni los contratos diferidos de panel y observabilidad.

Contexto

ZeroClaw originalmente centraba la configuración y el comportamiento en tiempo de ejecución en un único agente implícito. La operación multiagente requiere identidades que puedan coexistir sin compartir espacio de trabajo, memoria, permisos o accesibilidad de canal de forma accidental.

La implementación V3 reemplazó el singleton implícito con agentes configurados identificados por alias. Cada agente resuelve sus propias entradas de tiempo de ejecución y límites de ámbito, mientras que un daemon coordina el conjunto habilitado. Las concesiones explícitas conectan los agentes donde se pretende la colaboración.

Decisión

Identidad y supervisión de agentes

Cada entrada [agents.<alias>] define una identidad de agente direccionable. El alias selecciona el agente configurado en los puntos de entrada de CLI, canal, daemon y otros puntos de entrada en tiempo de ejecución. Una instalación de un solo agente utiliza el mismo modelo con una entrada configurada; no existe una arquitectura singleton privilegiada separada.

Cada agente tiene su propio límite del espacio de trabajo y su propia fuente de identidad. Los archivos de identidad se resuelven para ese agente, en lugar de a partir de una única personalidad para toda la instalación.

Un proceso zeroclaw daemon supervisa los agentes configurados habilitados y sus enlaces de canal. Esto no significa que cada agente posea un proceso o bucle en ejecución continua. Significa que la operación del daemon inicia y coordina el conjunto configurado en lugar de requerir un daemon por identidad.

Comunicación explícita

La regla duradera es que las relaciones de canal autorizadas son explícitas. La implementación actual utiliza enlaces de canal por agente y grupos de pares. La corresidencia en un mismo daemon no convierte a los agentes en pares de canal.

La mensajería entre agentes en canales actualmente requiere una relación de grupo de pares compartida en el canal correspondiente. Los grupos de pares son límites mutuos de enrutamiento y aceptación entrante; los agentes fuera de esa relación no se vuelven accesibles simplemente porque estén configurados en la misma instalación.

Por compatibilidad, el tiempo de ejecución asigna determinísticamente la propiedad de los canales cuando ningún agente configurado declara ninguna vinculación de canales. Esta alternativa mantiene la compatibilidad con instalaciones anteriores; no establece el uso compartido implícito como contrato multiagente.

La delegación y otras capacidades entre agentes pueden imponer puertas adicionales. Este ADR no convierte la membresía en el grupo de pares en un mecanismo de autorización universal para todas las capacidades.

Ámbito del espacio de trabajo y la política de tiempo de ejecución

Cada agente habilitado resuelve un perfil de riesgo y un límite de espacio de trabajo. El límite del sistema de archivos predeterminado es el propio espacio de trabajo del agente. Una entrada de acceso en el agente direccionado concede explícitamente a ese agente acceso al espacio de trabajo hermano indicado.

La jaula de solo-espacio de trabajo puede deshabilitarse mediante el perfil de riesgo resuelto, incluyendo plena autonomía, o mediante la configuración unrestricted-filesystem del agente. La política de rutas prohibidas y los permisos del host restantes siguen aplicándose.

Compartir un proveedor, adaptador de canal, bundle u otra configuración referenciada no fusiona el workspace de los agentes ni el ámbito de runtime-policy resuelto. Puede compartir intencionadamente el recurso o las credenciales referenciadas: los secrets permanecen a nivel de toda la instalación en lugar de por agente.

Aislamiento de memoria

La identidad de agente configurada es el ámbito consumido por el contrato de memoria. Los backends aplican ese ámbito mediante los metadatos de agente almacenados o un límite de almacenamiento propiedad del agente y un adaptador con ámbito.

La recuperación entre agentes es aditiva y explícita. Requiere acceso compatible al mismo backend; el runtime no conecta silenciosamente distintos tipos de backend.

ADR-005 gestiona el almacenamiento, la atribución, las listas de permitidos de recuperación, la compatibilidad de backends y las restricciones de operaciones destructivas. ADR-010 asigna por separado la autoridad entre el historial de sesión, la memoria curada y el enriquecimiento.

Límite de evolución del esquema

La decisión perdurable es el modelo de identidad nombrada y límites explícitos descrito arriba. Las referencias exactas de configuración, los alias de paquete y los campos del sistema de archivos pueden evolucionar sin reemplazar este ADR mientras esos límites permanezcan intactos.

Consecuencias

Consecuencias positivas:

  • Las instalaciones de un solo agente y de múltiples agentes comparten un único modelo de ejecución.
  • Los operadores pueden razonar sobre el espacio de trabajo, la memoria, la política de tiempo de ejecución y la accesibilidad de canales por cada agente con nombre.
  • El intercambio es visible a través de la configuración en lugar de inferirse de la co-residencia de procesos.
  • La colaboración entre agentes puede añadirse de forma selectiva sin debilitar los límites de ámbito predeterminados.

Consecuencias negativas:

  • Cada punto de entrada compatible con agentes debe transportar o resolver correctamente un alias de agente.
  • La validación de configuración debe rechazar los alias pendientes y las concesiones entre agentes incompatibles antes del uso en tiempo de ejecución.
  • Los backends y adaptadores compartidos a nivel de instalación necesitan atribución y filtrado por agente en lugar de depender de procesos separados para el alcance.
  • Los secretos siguen siendo válidos para toda la instalación, por lo que el ámbito de espacio de trabajo y política de ejecución por agente no implica un aislamiento de credenciales por agente.

Decisiones de seguimiento:

  • Las nuevas capacidades entre agentes deben definir sus propios límites de autorización y atribución, en lugar de asumir que la pertenencia a un grupo de pares o a un daemon es suficiente.
  • Los cambios que debilitan el espacio de trabajo predeterminado, el perfil de riesgo o el alcance de la memoria requieren una decisión explícita de arquitectura y seguridad.

Referencias