Componentes internos del runtime

Esta página es la contraparte de profundidad arquitectónica del resto de la sección de Agentes: cómo el runtime aplica los permisos por agente, delimita el alcance de la memoria y atribuye los registros. Para configurar y ejecutar agentes, comienza en Agentes; para la referencia de campos a nivel de esquema, consulta Config; para los pasos de configuración en vivo, consulta Configuración multiagente.

Modelo de permisos

El SecurityPolicy efectivo de cada agente se construye con SecurityPolicy::for_agent(config, alias):

1. Parte del perfil de riesgo del agente ([risk_profiles.<profile>]).
2. Establece el límite en el directorio de espacio de trabajo por agente (<install>/agents/<alias>/workspace/).
3. Recorrer [agents.<alias>.workspace.access]:
   • Read → el workspace del proceso hermano queda en la lista de permitidos de solo lectura.
   • Write / ReadWrite → el workspace del proceso hermano queda en la lista de permitidos de lectura-escritura.
4. Si [agents.<alias>.workspace.unrestricted_filesystem] es true, desactive workspace_only.

La lista de permitidos de solo lectura es respetada por file_read (y otras herramientas del lado de lectura); la lista de permitidos de lectura-escritura controla file_write, file_edit, git_operations y las invocaciones de la herramienta de shell que tocan rutas. Los archivos de dispositivo POSIX (/dev/null, /dev/zero, /dev/random, /dev/urandom) siempre son legibles, de modo que los modismos de shell siguen funcionando sin configuración por agente.

Las generaciones de SubAgent aplican la regla de que un proceso hijo no puede escalar más allá de su proceso padre. La lista completa de ejes del validador y el comportamiento de compartición de presupuesto están documentados en Delegation → Permission inheritance.

Modelo de memoria

Cada agente tiene su propia instancia de Arc<dyn Memory>. La factoría (zeroclaw_memory::create_memory_for_agent) realiza el dispatch según el tipo de backend:

• SQLite / Postgres / Lucid: almacén compartido para toda la instalación. La tabla agents asigna alias → UUID, y la tabla memories contiene agent_id que referencia ese UUID. La factoría envuelve el backend interno en AgentScopedMemory, que estampa el UUID del agente vinculado en cada almacenamiento mediante store_with_agent y filtra cada recuperación mediante recall_for_agents con la lista de permitidos resuelta.
• Markdown: directorio por agente. El MarkdownMemory de cada agente escribe en <install>/agents/<alias>/workspace/MEMORY.md y memory/YYYY-MM-DD.md. La recuperación entre agentes se compone mediante AgentScopedMarkdownMemory, que contiene el MarkdownMemory del agente vinculado más un conjunto de pares (alias, MarkdownMemory) y une sus resultados con prefijos de atribución [<alias>] en cada fila.
• Qdrant: colección compartida, indexada por payload. El campo de payload agent_id es la atribución por agente; recall_for_agents sobrecarga la obtención y posfiltra por payload.
• None: stub sin operación. El wrapper sigue existiendo para que la ruta de ejecución sea uniforme.

La memoria entre agentes y entre backends no es compatible: el validador de esquema en la carga de configuración rechaza las entradas read_memory_from que apuntan a un elemento del mismo nivel en un backend diferente.

Ciclo de vida de renombrado y eliminación

Usa los controles de agente del panel del gateway o la CLI dedicada zeroclaw agents para renombrar y eliminar. En la compilación estándar con gateway y agent-runtime habilitados, ambas superficies ejecutan las cascadas de referencias y de estado propio; eliminar directamente o volver a asignar la clave de agents.<alias> en TOML o mediante un configurador genérico no lo hace. Una CLI con funciones reducidas sigue actualizando las referencias de configuración, pero advierte que el estado propio no se propagó en cascada, así que usa una compilación con ambas funciones habilitadas para las operaciones de ciclo de vida.

Ambas operaciones hacen persistente el cambio de configuración antes de ejecutar efectos secundarios sobre el estado propio. Renombrar reescribe primero las referencias de configuración, después mueve el espacio de trabajo predeterminado de cada alias y vuelve a apuntar el estado de memoria, cron, ACP y sesión. Eliminar primero rechaza las referencias duras y las sesiones ACP activas, después elimina la entrada de configuración y las referencias blandas antes de intentar archivar el espacio de trabajo, exportar y limpiar el estado propio y borrar la atribución de sesión.

Los efectos secundarios posteriores a la persistencia son de mejor esfuerzo e informan los fallos detectados, pero los fallos de escritura en el archivo pueden aparecer únicamente en los registros del gateway. Las advertencias de cambio de nombre indican que se debe reintentar el mismo cambio de nombre mediante la API del gateway para converger los residuos que quedaron bajo el alias anterior. Tras la eliminación, verifique el contenido del archivo y los registros antes de depender del archivo para la recuperación. La restauración automatizada no es compatible.

Consulte Configuración de múltiples agentes para conocer los controles actuales, bloqueadores, diseño del archivo y verificaciones del operador.

No compatible actualmente

1. Acceso a memoria entre agentes y backends (p. ej., un agente SQLite leyendo las filas de un agente Postgres).
2. Restauración automatizada desde un archivo de eliminación de agente.
3. Espacios de nombres de secretos por agente: existe un único SecretStore para todo el espacio de trabajo.
4. Extensiones del formato wire de Lucid para el ámbito entre agentes.