Los agentes de IA han evolucionado significativamente más allá del chat. Escribir código, conservar el estado del sistema de archivos, ejecutar comandos de shell y administrar estados en todo el sistema de archivos son algunos ejemplos de cosas que pueden hacer. A medida que los asistentes de codificación agentes y los flujos de trabajo de desarrollo han madurado, el sistema de archivos se ha convertido en la principal memoria de trabajo de los agentes, ampliando sus capacidades más allá de la ventana contextual. Este cambio crea dos desafíos con los que se enfrenta todo equipo que crea agentes de producción:
El sistema de archivos es efímero. Cuando la sesión de su agente se detiene, todo lo que creó, como las dependencias instaladas, el código generado o el historial de git local, desaparece. Cuando su flujo de trabajo necesita una operación determinista como npm test o git push, se ve obligado a enrutarlo a través del modelo de lenguaje grande (LLM) o crear herramientas personalizadas fuera del tiempo de ejecución. Ninguna opción es buena.
Amazon Bedrock AgentCore Runtime ahora aborda ambos desafíos con dos capacidades: almacenamiento de sesión administrado para el estado persistente del sistema de archivos del agente (vista previa pública) y comando de ejecución (InvokeAgentRuntimeCommand) para ejecutar comandos de shell directamente dentro de la microVM asociada con cada sesión de agente activo. Cada uno de ellos es útil por sí solo. Juntos, desbloquean flujos de trabajo que antes no eran posibles.
En esta publicación, explicamos cómo utilizar el almacenamiento de sesión administrado para conservar el estado del sistema de archivos de su agente y cómo ejecutar comandos de shell directamente en el entorno de su agente.
Dentro de una sesión de AgentCore Runtime
AgentCore Runtime ejecuta cada sesión en una microVM dedicada con recursos aislados, incluido su propio kernel, memoria y sistema de archivos. Esta arquitectura proporciona límites de seguridad sólidos, pero también significa que cada sesión se inicia en un sistema de archivos limpio. Cuando la microVM finaliza, ya sea mediante una parada explícita o un tiempo de inactividad, todo lo que creó el agente desaparece.
Piense en lo que eso significa en la práctica. Su agente de codificación dedica veinte minutos a desarrollar un proyecto: configurar estructuras de directorios, instalar dependencias, generar código repetitivo, configurar herramientas de compilación. Te alejas para almorzar y cuando regresas e invocas la misma sesión, el agente comienza desde cero. Cada paquete reinstalado, cada archivo regenerado. Se queman veinte minutos de cálculo antes de que el agente pueda volver a realizar un trabajo útil. Esta limitación se puede abordar escribiendo una lógica de punto de control para cargar archivos en Amazon Simple Storage Service (Amazon S3) antes de detener una sesión y descargarlos al reanudar o para mantener activas las sesiones para evitar perder el estado. Esta solución alternativa puede funcionar, pero no aborda las limitaciones a nivel del sistema de archivos y se está agregando complejidad al código del agente.
La misma fricción existe para las operaciones deterministas. Cuando el agente finaliza una solución y necesita ejecutar pruebas, enrutar el comando a través del LLM como una llamada de herramienta agrega costo de token, latencia y no determinismo a una operación predecible. Otra opción es crear una lógica de orquestación separada fuera del tiempo de ejecución, lo que requiere que usted se conecte al sistema de archivos del agente, lo que agrega complejidad.
Almacenamiento de sesión administrado (vista previa pública): estado que sobrevive
El primer desafío, los sistemas de archivos efímeros, se aborda mediante el almacenamiento de sesiones administrado. Le proporciona a su agente un directorio persistente que sobrevive a los ciclos de parada/reanudación. La persistencia está integrada en el tiempo de ejecución y se configura en la creación del agente; todo lo escrito en ese directorio sobrevive incluso cuando se reemplaza el entorno informático.
Configurar el almacenamiento persistente
Para configurar el almacenamiento persistente, haga lo siguiente:
Agregue sessionStorage a la configuración del sistema de archivos del tiempo de ejecución de su agente:
O usando AWS SDK para Python (Boto3):
Nota: AgentCore utiliza dos clientes de servicio Boto3. El cliente del plano de control (bedrock-agentcore-control) maneja operaciones del ciclo de vida del tiempo de ejecución como CreateAgentRuntime, GetAgentRuntime y DeleteAgentRuntime. El cliente del plano de datos (bedrock-agentcore) maneja operaciones de sesión como InvokeAgentRuntime e InvokeAgentRuntimeCommand. La ruta de montaje debe comenzar con /mnt seguido de un nombre de carpeta (por ejemplo, /mnt/workspace o /mnt/data). Después de la configuración, cualquier archivo que su agente escriba en esta ruta se conserva automáticamente en el almacenamiento administrado.
La experiencia de detener/reanudar
Invocas a tu agente y le pides que configure un proyecto:
El agente descarga el código, instala los paquetes y genera la configuración en la microVM dedicada a esa sesión. Luego, detiene la sesión o se activa el tiempo de espera de inactividad y la microVM finaliza.
Regresas e invocas con el mismo runtime-session-id:
Un nuevo entorno informático (microVM) se activa y monta el mismo almacenamiento. El agente ve /mnt/workspace exactamente como lo dejó, incluidos los archivos fuente, node_modules, artefactos de compilación y el historial de .git. El agente retoma el proceso a mitad del pensamiento, sin necesidad de reinstalar y volver a generar.
Desde la perspectiva del agente, no está sucediendo nada especial. Lee y escribe archivos en un directorio como lo haría normalmente. No es necesario cambiar el código de su agente: no hay API especiales, ni lógica de guardado/restauración, ni serialización. Escriba un archivo en /mnt/workspace, detenga la sesión, reanúdela y el archivo estará allí.
El entorno informático de la sesión (microVM) de ayer desapareció, pero el sistema de archivos sobrevivió.
Controlar cuánto tiempo duran los datos
De forma predeterminada, los datos de almacenamiento de la sesión se conservan durante 14 días de tiempo de inactividad. Si la sesión no se reanuda dentro de esta ventana, los datos se limpian. Cuando el punto final del agente se actualiza a una versión diferente y se invoca el mismo runtime-session-id, los datos de la sesión se actualizan. Esto le da al directorio montado un contexto limpio para la nueva versión.
Un flujo de trabajo de desarrollo de varios días
Veamos cómo se ve esto en la práctica. Día 1: invocas a tu agente de codificación y le pides que descargue una base de código, inspeccione los archivos y configure el entorno de desarrollo:
El agente descarga el repositorio en /mnt/workspace, lo extrae e informa:
Cierras tu computadora portátil y te vas a casa. Día 2: invocas con el mismo ID de sesión:
El agente ve el proyecto exactamente como lo dejó. Modifica main.py directamente. Sin volver a descargar ni volver a extraer. Cuando le pide al agente que enumere los archivos, todo está ahí, incluido el main.py modificado con la nueva función hello_world. El entorno informático (microVM) de ayer ya se finalizó, pero el trabajo persiste.
Eso soluciona el primer desafío, pero ahora su agente ha escrito un código nuevo y necesita verificar que funcione. Aquí es donde entra en juego la segunda capacidad.
Ejecutar comando de shell: operaciones deterministas, directamente en el entorno del agente
InvokeAgentRuntimeCommand aborda el segundo desafío, ejecutar operaciones deterministas sin enrutarlas a través del LLM. Puede ejecutar comandos de shell directamente dentro de una sesión de AgentCore Runtime en ejecución y transmitir la salida a través de HTTP/2.
La idea clave es que los agentes y los comandos de shell son buenos en cosas diferentes:
Use el comando de ejecución Use el agente La operación tiene un comando conocido (npm test, git push) La operación requiere razonamiento (“analizar este código y corregir el error”) Quiere una ejecución determinista: el mismo comando, el mismo resultado Quiere que el LLM decida qué hacer Necesita transmitir la salida de un proceso de larga duración Necesita que el agente use herramientas en un bucle La operación es una puerta de validación en su flujo de trabajo La operación es el trabajo creativo o analítico Está iniciando el entorno antes de que comience el agente Está preguntando al agente para trabajar en una tarea
Cuando su agente termine de escribir código y necesite ejecutar pruebas, no debería necesitar el LLM para eso. La prueba npm es la prueba npm. El comando es conocido, el comportamiento debe ser determinista y lo que desea es el resultado sin procesar, no la interpretación del LLM.
Ejecutando un comando
Ejecute un comando utilizando AWS SDK para Python (Boto3):
La respuesta transmite tres tipos de eventos en tiempo real:
Evento Cuándo Contiene contentStart Primer fragmento Confirma el comando iniciado contentDelta Durante la ejecución salida stdout y/o stderr contentStop Último fragmento código de salida y estado (COMPLETED o TIMED_OUT)
Como la salida se transmite a medida que se produce, puede detectar una falla en los primeros segundos y reaccionar de inmediato, en lugar de esperar a que se ejecute por completo.
Contenedor, mismo sistema de archivos
Este es el detalle crítico: los comandos se ejecutan en el mismo contenedor, sistema de archivos y entorno que su agente, no en un sidecar o en un proceso separado que habla a través de un socket. Un archivo que el agente escribió en /mnt/workspace/fix.py es inmediatamente visible para un comando que ejecuta cat /mnt/workspace/fix.py. No hay ningún paso de sincronización, ni transferencia de archivos, ni ningún volumen compartido que configurar.
AgentCore Runtime microVM no incluye herramientas de desarrollador de forma predeterminada. Esto también significa que cualquier herramienta de la que dependan sus comandos, git, npm o lenguajes de ejecución, debe agregarse en la imagen de su contenedor o instalarse dinámicamente en tiempo de ejecución.
Opciones de diseño que dan forma a cómo lo usas
Ejecución de un solo disparo. Cada comando genera un nuevo proceso bash, se ejecuta hasta su finalización (o se agota el tiempo de espera) y regresa. No hay sesión de shell persistente entre comandos. Esto coincide con la forma en que los marcos de agentes utilizan la ejecución de comandos, elaboran un comando, lo ejecutan, leen el resultado y deciden qué hacer a continuación. Sin bloqueo. La ejecución de comandos no bloquea las invocaciones de agentes. Puede invocar al agente y ejecutar comandos simultáneamente en la misma sesión. Sin estado entre comandos. Cada comando comienza de nuevo, no hay historial de shell y las variables de entorno de comandos anteriores no se transfieren. Si necesita el estado, codifíquelo en el comando: cd /workspace && export NODE_ENV=test && npm test.
Lo que la gente está construyendo con él
Automatización de pruebas: después de que el agente escriba el código, ejecute npm test o pytest como comando. Transmita la salida y envíe fallas específicas al agente para su iteración. Flujos de trabajo de Git: la bifurcación, el compromiso y el envío son deterministas. Ejecútelos como comandos, manteniendo la lógica de control de versiones fuera del LLM. Arranque del entorno: clonar repositorios, instalar paquetes y configurar herramientas de compilación antes de que se inicie el agente. Esto será más rápido y confiable que los comandos directos. Generar canalizaciones: cualquier cosa con un comando conocido que deba ejecutarse exactamente como se especifica, por ejemplo: cargo build –release, mvn package, go build. Puertas de validación: ejecute linters, verificadores de tipos y escáneres de seguridad como puerta después de que el agente escriba el código, pero antes de confirmarlo. Depuración: inspeccione el entorno de ejecución: verifique los paquetes instalados, el uso del disco y los procesos en ejecución. Estos serán útiles para comprender las fallas de los agentes.
Mejor juntos: el sistema de archivos es el contexto compartido
El almacenamiento de sesiones administrado (en versión preliminar pública) aborda el desafío del sistema de archivos efímero. El comando de ejecución aborda el desafío de las operaciones deterministas. Cada uno es valioso por sí solo, pero son más poderosos cuando se combinan porque comparten el mismo sistema de archivos que une todo el flujo de trabajo.
Cuando el tiempo de ejecución de su agente tiene configurado el almacenamiento de sesión administrado en /mnt/workspace, todo opera en el mismo directorio persistente:
InvokeAgentRuntime escribe código, genera artefactos y administra archivos en /mnt/workspace. InvokeAgentRuntimeCommand ejecuta pruebas, operaciones de git y compila lecturas y escrituras en el mismo /mnt/espacio de trabajo. Detener la sesión. Compute (microVM) se detiene. /mnt/workspace persiste. Reanudar al día siguiente. La nueva computación monta el mismo almacenamiento. Tanto el agente como el comando de ejecución ven los mismos archivos.
El sistema de archivos se convierte en el contexto compartido que conecta el razonamiento de los agentes, las operaciones deterministas y el tiempo. Así es como se ve en el código:
El agente escribe el código mientras la plataforma ejecuta los comandos. Cada uno hace aquello para lo que está diseñado. Debido a que /mnt/workspace está respaldado por un almacenamiento de sesión administrado, puede detener esta sesión, regresar al día siguiente y todo el espacio de trabajo seguirá ahí, listo para que el agente continúe con la iteración.
Este es el patrón: el agente razona, ejecuta el comando y el sistema de archivos persistente recuerda. Las tres capacidades forman un bucle que no se rompe cuando cierras tu computadora portátil.
Empezando
Ambas capacidades ahora están disponibles. A continuación te explicamos cómo empezar a utilizarlos:
Almacenamiento de sesión administrado (vista previa pública): agregue configuraciones del sistema de archivos con sessionStorage al llamar a CreateAgentRuntime. Especifique una ruta de montaje que comience con /mnt. Todo lo que su agente escribe en esa ruta persiste durante los ciclos de parada/reanudación. Los datos máximos permitidos son 1 GB por sesión.
Ejecutar comando: llame a InvokeAgentRuntimeCommand con una cadena de comando y un tiempo de espera en cualquier sesión activa. El comando se ejecuta en el mismo contenedor que su agente, con acceso al mismo sistema de archivos.
Para comenzar con tutoriales y código de muestra:
Comenzó con dos desafíos: agentes que pierden su trabajo cuando se detienen las sesiones y operaciones deterministas que debían enrutarse a través del LLM o construirse fuera del tiempo de ejecución. El almacenamiento de sesiones administradas y el comando de ejecución abordan ambos desafíos. El sistema de archivos compartido entre ellos crea un ciclo de desarrollo donde el agente razona, ejecuta comandos y el trabajo persiste entre sesiones. Pruebe las nuevas capacidades de Amazon Bedrock AgentCore y cuéntenos qué crea.
Acerca de los autores
Rui Cardoso
Rui Cardoso es arquitecto de soluciones socio senior en Amazon Web Services (AWS). Se centra en AI/ML e IoT. Trabaja con socios de AWS y los apoya en el desarrollo de soluciones en AWS. Cuando no está trabajando, le gusta andar en bicicleta, hacer senderismo y aprender cosas nuevas.
Kosti Vasilakakis
Kosti Vasilakakis es PM principal en AWS en el equipo de Agentic AI, donde ha dirigido el diseño y desarrollo de varios servicios Bedrock AgentCore desde cero, incluidos Runtime, Browser, Code Interpreter e Identity. Anteriormente trabajó en Amazon SageMaker desde sus inicios, lanzando capacidades de IA/ML que ahora utilizan miles de empresas en todo el mundo. Al principio de su carrera, Kosti fue científico de datos. Fuera del trabajo, crea automatizaciones de productividad personal, juega tenis y disfruta de la vida con su esposa e hijos.
Vignesh Somasundaram
Vignesh Somasundaram es ingeniero de desarrollo de software fundador en AWS y forma parte del equipo de Amazon Bedrock AgentCore, donde crea infraestructura de inteligencia artificial para implementar agentes a escala. Con una maestría en Ciencias de la Computación de la Universidad Purdue y una licenciatura de la Universidad Anna, le apasiona construir sistemas distribuidos a gran escala y abordar desafíos arquitectónicos. Cuando no está en el trabajo, lo encontrarás al aire libre jugando cricket, bádminton o explorando la naturaleza.
Adarsh Srikanth
Adarsh Srikanth es ingeniero de desarrollo de software fundador de Amazon Bedrock AgentCore, donde diseña y desarrolla plataformas que potencian los servicios de agentes de IA. Obtuvo su maestría en ciencias de la computación de la Universidad del Sur de California y tiene tres años de experiencia profesional en ingeniería de software. Fuera del trabajo, Adarsh disfruta explorar parques nacionales, hacer senderismo y practicar deportes de raqueta.
Abhimanyu Siwach
Abhimanyu Siwach es ingeniero de desarrollo de software fundador de Amazon Bedrock AgentCore, donde dirige la arquitectura y la dirección técnica de la plataforma que permite a los clientes implementar y administrar agentes de IA a escala. Tiene una licenciatura en Ciencias de la Computación de BITS Pilani. Con más de ocho años en Amazon abarcando equipos que incluyen Last Mile, Advertising y AWS, aporta una amplia experiencia en la creación de sistemas distribuidos a gran escala. Fuera del trabajo, a Abhimanyu le gusta viajar, crear aplicaciones basadas en inteligencia artificial y explorar nuevas tecnologías.