Control Remoto de Codex, Endurecimiento de RCE de Agentes, Ganchos de Sesión de Copilot, y Microsoft Agent Framework 1.5
OpenClaw Daily EP048 comienza con OpenAI Codex 0.130.0 y su punto de entrada de servidor de aplicaciones con control remoto, vistas de hilos paginadas, metadatos de ganchos de plugins, actualización de configuración, precisión de diff de turnos, resolución de imágenes multi-entorno y cambios de telemetría. El episodio luego explica el caso de estudio de RCE de Semantic Kernel de Microsoft, los ganchos de sesión y diagnósticos de GitHub Copilot SDK, y los cambios de Microsoft Agent Framework 1.5 alrededor de la orquestación de Magentic, listas de permitidos de WebBrowsingTool, eventos de razonamiento, inyección de estado de tareas y más. Show notes: https://tobyonfitnesstech.com/es/podcasts/episode-48/
🎧 Listen to Episode[00:00] Codex 0.130.0 les da a los operadores de coding-agents un plano de control más limpio. La funcionalidad principal es codex remote-control, un punto de entrada más simple para iniciar un servidor de aplicaciones headless que puede ser controlado de forma remota. Esto es importante porque los coding-agents ya no son solo herramientas de terminal. Son sesiones de servidores de aplicaciones con hilos, instantáneas de configuración, superficies de plugins, eventos de revisión, vistas de archivos y clientes remotos que pueden necesitar inspeccionar o continuar el trabajo sin estar dentro de la terminal original. Esta versión también añade vistas de hilos paginadas, metadatos de hooks de plugins, mejor actualización de configuración en vivo, diffs de turnos más precisos después de fallos parciales de parches, resolución de imágenes en múltiples entornos y telemetría más rica para depurar rutas de revisión.
[02:00] HISTORIA 1 — OpenAI Codex 0.130.0 Añade Servidores de Aplicaciones con Control Remoto, Vistas de Hilos Paginadas, Visibilidad de Hooks de Plugins y Mejor Reparación de Estado
Comencemos con el punto de entrada remote-control. Un servidor de aplicaciones headless es un objeto operativo diferente de una ejecución CLI de un solo uso. El servidor posee sesiones, hilos, configuración, selección de entorno, ejecución de herramientas y conexiones de clientes. Añadir un comando de nivel superior codex remote-control reduce la fricción para iniciar ese plano de control directamente. Para los constructores que integran coding-agents en dashboards, IDEs, clientes de navegador o máquinas de desarrollo remotas, esa es la superficie que convierte un asistente local en un endpoint de servicio.
El mecanismo importante es la separación entre control y trabajo. El servidor de aplicaciones puede mantener una sesión de codificación viva mientras un cliente se reconecta, navega por un hilo grande, abre una vista de resumen o solicita una vista de elemento completo solo cuando es necesario. Codex 0.130.0 añade paginación para hilos grandes donde los clientes pueden solicitar vistas de elementos de turno no cargados, de resumen o completos. Eso no es solo pulido de UI. Los hilos de agentes pueden volverse enormes porque incluyen turnos de usuario, turnos de modelo, llamadas a herramientas, diffs, referencias de archivos, aprobaciones, imágenes y resúmenes compactados. Cargar todo en cada cliente desperdicia memoria, aumenta la latencia y hace que los clientes remotos sean frágiles.
Una API de hilos paginados le da al servidor de aplicaciones espacio para tratar la materialización de hilos como un contrato. Un elemento no cargado puede preservar el orden y la identidad sin transferir la carga útil. Un elemento de resumen puede dar suficiente contexto para la navegación. Un elemento de turno completo puede obtenerse cuando el usuario abre el detalle. Ese patrón es familiar en logs, trazas y líneas de tiempo de issues, y los coding-agents ahora lo necesitan porque sus transcripciones son registros operativos, no solo texto de chat.
Los detalles de plugins ahora muestran los hooks incluidos, y compartir plugins expone metadatos de enlaces más controles de descubribilidad. Los hooks son parte del comportamiento real en tiempo de ejecución de un plugin. Si un plugin puede modificar el inicio, observar una llamada a herramienta, proporcionar un comando o participar en una revisión, los operadores necesitan ver eso antes de instalarlo o compartirlo. Ocultar los hooks dentro de un paquete convierte la revisión de plugins en trabajo de adivinación. Mostrarlos en los detalles del plugin hace que la superficie de ejecución sea auditable.
La versión también repara el comportamiento de configuración del servidor de aplicaciones en vivo. Los hilos del servidor de aplicaciones en vivo ahora captan los cambios de configuración sin requerir un reinicio. En un runtime de agentes, la configuración puede incluir opciones de modelo, políticas de aprobación, configuraciones de proveedor, disponibilidad de herramientas, estado de plugins, selección de entorno y opciones de telemetría. Si un hilo de larga ejecución sigue usando configuración obsoleta, los operadores pueden creer que cambiaron la política mientras un agente activo continúa con la configuración anterior. Actualizar los hilos en vivo desde la última instantánea de configuración hace que los cambios de política surtan efecto donde se está realizando el trabajo.
Los diffs de turnos reciben una corrección particularmente práctica. Codex ahora mantiene los diffs precisos a través de operaciones de apply_patch, incluyendo fallos parciales que aún mutaron archivos. Este modo de fallo importa. Un parche puede fallar a mitad de camino pero aún así cambiar parte de un archivo. Si el runtime reporta el diff incorrecto después, el usuario no puede confiar en la vista de revisión, la lógica de rollback o el rastro de auditoría. El seguimiento de diffs respaldado por operaciones es la dirección correcta: registrar lo que la operación realmente cambió, no lo que se suponía que debía cambiar el parche ideal.
Las correcciones de ThreadStore mejoran los resúmenes, renombrados, resume y rutas de fork, incluyendo hilos sin rutas de despliegue local. Eso significa que la capa de almacenamiento de hilos se está convirtiendo en la fuente de verdad para más operaciones del ciclo de vida. Resume y fork son especialmente importantes para los coding-agents porque un usuario puede querer ramificar una investigación, continuar una ejecución fallida o abrir un hilo desde un cliente remoto que carece de la ruta de despliegue local original. Si la identidad del hilo depende demasiado del estado del sistema de archivos local, los flujos de trabajo remotos y headless se rompen.
La compactación remota también obtiene correcciones de contrato de stream. Codex ahora emite response.processed para streams v2 y evita enviar service_tier en solicitudes de compactación con API-key. La compactación es cómo las sesiones largas permanecen utilizables, pero la compactación remota tiene que hablar el mismo lenguaje de eventos que el resto del servidor de aplicaciones. Un evento processed faltante puede dejar a los clientes esperando un estado terminal. Enviar campos no soportados en una solicitud de compactación puede romper solo la ruta de compactación mientras los turnos normales aún funcionan, lo cual es difícil de diagnosticar.
El soporte multi-entorno aparece en view_image, que ahora puede resolver archivos a través del entorno seleccionado. Los coding-agents a menudo operan a través de un host, contenedor, sandbox, espacio de trabajo remoto o proyecto montado. Una ruta de imagen no es significativa a menos que el runtime sepa qué entorno la posee. Resolver a través del entorno seleccionado evita que un cliente mire accidentalmente el sistema de archivos equivocado o falle al mostrar un artefacto que existe dentro del sandbox activo.
El soporte de autenticación Bedrock ahora acepta credenciales de console-login de AWS de los perfiles de aws login. Eso es una conveniencia para operadores con impacto real en el despliegue. Muchos equipos ya gestionan el acceso a AWS a través de flujos basados en perfiles. Permitir que Codex use esos perfiles reduce las rutas de credenciales duplicadas y hace que la autenticación del proveedor de modelos se alinee con los controles de acceso a la nube existentes.
Los cambios de telemetría son útiles para la depuración en producción. Codex añade metadatos de trazas OpenTelemetry configurables y análisis más ricos de revisión y feedback. Los eventos de revisión son una parte fundamental de la seguridad de los coding-agents. Si un comando fue aprobado, denegado, reintentado o escalado, los operadores necesitan suficiente contexto de traza para entender por qué. Una buena telemetría debería conectar una sesión, un turno, una llamada a herramienta, una decisión de aprobación, una solicitud al modelo y un resultado visible para el usuario sin filtrar secretos.
La recomendación práctica es tratar los despliegues del servidor de aplicaciones Codex como despliegues de servicios. Fijar la versión, iniciar remote-control deliberadamente, documentar qué clientes pueden conectarse, auditar los hooks de plugins antes de compartir, tener en mente el comportamiento de actualización de configuración y probar los casos de fallo de parches. La versión no se trata solo de nuevos comandos; se trata de hacer que un coding-agent sea controlable, inspeccionable y recuperable cuando las sesiones crecen y se ejecutan de forma remota.
[16:00] HISTORIA 2 — La Investigación de RCE del Semantic Kernel de Microsoft Convierte la Inyección de Prompts en una Lección sobre Límites de Ejecución de Herramientas
La publicación de seguridad de Microsoft es un recordatorio directo de que la inyección de prompts se vuelve más peligrosa cuando el lenguaje está conectado a herramientas. El modelo no es el componente vulnerable en el caso de estudio. El modelo recibe texto, decide llamar a una herramienta y llena los argumentos de la herramienta. El límite vulnerable es el código del framework y de plugins que confía en esos argumentos y los convierte en comportamiento ejecutable del host.
El primer problema divulgado se centra en la ruta de búsqueda del Vector Store en memoria de Semantic Kernel. El agente de ejemplo expone una función de búsqueda de hoteles. Un usuario pide hoteles en una ciudad. El modelo llama al plugin de búsqueda con un argumento de ciudad. El plugin construye un filtro determinista para reducir el conjunto de datos antes de la similitud vectorial. El paso arriesgado es que un argumento controlado por el modelo se interpola en una expresión lambda de Python y luego se ejecuta con eval().
Ese es el límite de ejecución. Un valor normal de ciudad se convierte en una expresión de filtro. Un valor malicioso puede cerrar una comilla y anexar lógica de Python. La inyección de prompts no necesita un exploit de navegador, un archivo adjunto malicioso o corrupción de memoria. Necesita que el framework del agente tome un parámetro derivado del lenguaje y lo coloque en una expresión ejecutable. Una vez que eso sucede, la inyección de prompts se ha convertido en inyección de código.
La mitigación intentada usó validación de AST y un entorno de builtins restringido. A alto nivel, el validador permitía expresiones lambda, escaneaba nombres y atributos en busca de identificadores peligrosos y ejecutaba con __builtins__ eliminado. Eso suena razonable, pero los lenguajes dinámicos hacen que las listas de bloqueo sean frágiles. Los investigadores de Microsoft evadieron el filtro sin usar directamente los nombres bloqueados obvios. La carga útil traversó estructuras de objetos de Python para localizar la maquinaria de import y alcanzar la ejecución de comandos del sistema a través de atributos alternativos.
La lección no es simplemente "no uses eval". La lección más amplia es que los argumentos de llamadas a herramientas son entrada no confiable incluso cuando vinieron de un modelo, incluso cuando el usuario no escribió código directamente, e incluso cuando el esquema dice que el campo es un nombre de ciudad. Un modelo puede ser inducido a colocar strings controlados por un atacante en cualquier argumento que se le permita llenar. Si la herramienta luego interpreta ese string como código, un lenguaje de consulta, un comando de shell, una ruta de archivo o una plantilla, el framework ha creado un sumidero de inyección.
La búsqueda vectorial hace que esto sea fácil de subestimar porque se siente como infraestructura de recuperación en lugar de ejecución de código. Pero los vector stores a menudo soportan filtros de metadatos, lenguajes de expresiones, predicados personalizados, prefiltros de embeddings, rerankers y strings de consulta específicos de conectores. Cada uno de esos puede convertirse en un límite de inyección si los valores controlados por el usuario o el modelo se concatenan en una expresión interpretada. El diseño seguro generalmente significa filtros parametrizados, DSLs tipados, operadores en listas de permitidos y validación que rechaza estructura inesperada antes de la ejecución.
Una corrección robusta debería eliminar la construcción de strings-código de la ruta por defecto. En lugar de generar un string lambda, un framework puede construir un predicado a partir de campos tipados y operadores. Por ejemplo, campo equals valor debería ser datos, no código fuente. Si un lenguaje de filtro es inevitable, el runtime debería parsear en un AST restringido y evaluar con un intérprete que solo entienda las operaciones permitidas. No debería llamar al evaluador del lenguaje host e intentar bloquear comportamiento peligroso después.
El principio de mínimo privilegio también es importante. Los plugins de búsqueda no deberían ejecutarse con los mismos privilegios de sistema de archivos, proceso y red que la aplicación host si no los necesitan. Un predicado de búsqueda de hoteles no necesita acceso al shell. Si un bug del framework convierte un filtro en ejecución de código, el sandbox y los privilegios del proceso determinan el radio de explosión. Los frameworks de agentes deberían aislar la ejecución de plugins, limitar las variables de entorno, evitar pasar credenciales a procesos genéricos de herramientas y registrar los parámetros de las herramientas con suficiente detalle para responder ante incidentes.
La detección es práctica. Los equipos que usan frameworks de agentes deberían inventariar las herramientas que ejecutan plantillas, filtros, comandos de shell, celdas de notebooks, fragmentos de Python, fragmentos de JavaScript, SQL u operaciones de archivos. Deberían buscar valores controlados por el modelo que se pasan a esos intérpretes. Deberían aplicar parches a Semantic Kernel y paquetes relacionados, pero también revisar plugins personalizados porque el mismo patrón aparece en el código de la aplicación. La seguridad contra inyección de prompts no es solo un problema de evaluación del modelo; es validación de entradas y aislamiento de ejecución para los tiempos de ejecución de herramientas.
La conclusión para los operadores es directa: cada herramienta de agente es un endpoint de API cuyo llamador está parcialmente controlado por el modelo. Tratar los esquemas de herramientas como contratos de API externos. Validar las entradas en el límite de la herramienta. Preferir estructuras de datos tipadas sobre cadenas interpretadas. Mantener los permisos de los plugins restringidos. Registrar lo suficiente para reconstruir qué prompt causó qué argumentos de herramienta. Y probar la inyección de prompts intentando forzar al agente a pasar parámetros hostiles a las herramientas, no solo verificando si el modelo dice palabras unsafe.
[28:00] HISTORIA 3 — GitHub Copilot SDK Agrega Ganchos de Modo de Aprobación de Plan y Límite de Velocidad Más Diagnósticos Cross-SDK
La versión pre-lanzamiento del Copilot SDK del 8 de mayo se trata de incrustar sesiones de agentes en productos con control de tiempo de ejecución más explícito. Las aplicaciones ahora pueden registrar callbacks para exitPlanMode.request y autoModeSwitch.request. Esos eventos son importantes porque el modo plan y el cambio automático de modelo son decisiones de producto, no solo decisiones del modelo.
El modo plan es un límite entre proponer trabajo y hacer trabajo. En un agente de codificación incrustado, la aplicación puede querer que un humano apruebe el plan, que un motor de políticas lo verifique, o que una regla específica del proyecto bloquee ciertos cambios. Los nuevos handlers permiten que las aplicaciones decidan si una solicitud de salir del modo plan es aprobada. Eso le da al producto host un punto de intercepción claro antes de que el tiempo de ejecución pase de planificar a ejecutar.
El cambio automático de modelo después de límites de velocidad es un tipo diferente de límite. Un tiempo de ejecución puede querer recuperarse de eventos de límite de velocidad cambiando a otro modelo o modo. Eso puede preservar la continuidad, pero también puede cambiar el comportamiento, costo, latencia o capacidad. El handler autoModeSwitch.request permite que la aplicación decida si acepta ese cambio. Para productos empresariales, eso es importante porque la elección del modelo puede estar vinculada a políticas de datos, cumplimiento, líneas base de evaluación o controles de presupuesto.
El lanzamiento también agrega diagnósticos estructurados a través de .NET, Python y Rust. Los logs cubren el inicio del CLI, conexión TCP, tiempo de solicitudes JSON-RPC, ciclo de vida de sesiones y rutas de errores. Esta es exactamente la visibilidad que necesita un SDK de agente incrustado. Cuando una sesión falla, la causa puede ser inicio del proceso, transporte, auth, enmarcado JSON-RPC, manejo de eventos del tiempo de ejecución, respuesta del modelo, ejecución de herramientas o comportamiento de callback del host. Sin logs estructurados de tiempo y ciclo de vida, cada falla parece "el agente se colgó".
El detalle de JSON-RPC vale la pena destacar. Muchos SDKs de agentes de codificación envuelven un proceso de tiempo de ejecución local y se comunican sobre JSON-RPC. Eso significa que hay un objeto cliente en la aplicación, un proceso de tiempo de ejecución, una conexión de transporte, IDs de solicitud, flujos de eventos y operaciones de larga duración. Los diagnósticos necesitan mostrar cuándo comenzó el tiempo de ejecución, cuándo se abrió la conexión TCP, qué solicitudes JSON-RPC se enviaron, cuánto tiempo tomaron y dónde surgieron errores. De lo contrario, los desarrolladores de aplicaciones no pueden distinguir el mal uso del SDK del fallo del tiempo de ejecución.
La opción enableSessionTelemetry hace de la telemetría una elección explícita de sesión. Esa es la forma correcta para privacidad y operaciones. Algunos despliegues quieren telemetría de sesión interna para depurar problemas y mejorar la calidad del producto. Otros la necesitan deshabilitada por política. Poner el control en la configuración de sesión y configuración de reanudación hace que la decisión sea auditable y repetible en lugar de depender de valores predeterminados ocultos.
Hay correcciones de compatibilidad más pequeñas que importan para usuarios del SDK de larga duración. Los enums de eventos de sesión de C# ahora son structs readonly respaldados por strings para que la deserialización no falle cuando el tiempo de ejecución agrega nuevos valores de enum. Eso es compatibilidad hacia adelante para flujos de eventos. Los blobs de recursos de resultados de herramientas binarias de Rust ahora predeterminan a application/octet-stream cuando mimeType está ausente. Eso es una corrección de resiliencia del formato de cable. Ambos cambios reducen roturas cuando los tiempos de ejecución y los SDKs evolucionan a diferentes velocidades.
La implicación práctica para los constructores es que las sesiones del Copilot SDK se están convirtiendo en objetos de tiempo de ejecución controlados por el host. Si los incrustas, implementa los callbacks de modo plan y cambio de modo deliberadamente. Decide qué cambios pueden ocurrir automáticamente y cuáles necesitan revisión. Activa los diagnósticos en desarrollo y staging. Captura el tiempo de JSON-RPC alrededor de sesiones lentas o inestables. Trata la telemetría como una decisión de política. Y prueba clientes más antiguos contra eventos más nuevos del tiempo de ejecución para que la compatibilidad hacia adelante de enums y eventos no te sorprenda.
[38:00] HISTORIA 4 — Microsoft Agent Framework 1.5 Avanza en Orquestación, Observabilidad, Política de Herramientas de Navegador y Semántica de Cable El lanzamiento del 8 de mayo del Microsoft Agent Framework es amplio, pero varios cambios son directamente relevantes para constructores de agentes de producción. La línea .NET agrega Magentic Orchestration, allowlisting de WebBrowsingTool, muestras de observabilidad de agentes alojados, eventos de razonamiento en AGUI, mejoras de multithreading de todo y headers de cliente por llamada de Foundry. La línea Python cercana agrega skills basadas en clases y providers de contexto de harness experimentales. El lanzamiento también corrige el formato de cable de salida de herramientas, loops de workflows, parsing de YAML, serialización multipartita y numeración de secuencias.
Magentic Orchestration es el titular porque los sistemas multi-agente necesitan más que una lista de agentes. Necesitan scheduling, delegación, propiedad de turnos, estado compartido, condiciones de terminación y una forma de decidir qué agente debería actuar a continuación. Una capa de orquestación formaliza esos mecanismos. Marcarla como experimental es apropiado porque la semántica de orquestación se convierte en arquitectura de aplicación: un mal scheduler puede hacer loop, duplicar trabajo, ocultar fallos o dejar que un agente domine la conversación.
El allowlisting de WebBrowsingTool es un control importante de uso de navegador/computadora. Las herramientas de navegación conectan un agente a contenido externo que puede ser malicioso, no confiable o simplemente distractivo. Una allowlist le da a la aplicación host una superficie de política para cuáles destinos de navegación o comportamientos del navegador están permitidos. En sistemas de agentes, navegar no es solo leer. El navegador puede obtener contenido de inyección de prompts, enviar formularios, seguir redirecciones, exponer cookies y recuperar archivos. La política necesita existir antes de que la herramienta se ejecute.
Las muestras de observabilidad de agentes alojados también son valiosas porque el despliegue es donde las abstracciones del framework se encuentran con la realidad de producción. Un agente alojado necesita logs, traces, correlación de solicitudes, visibilidad de llamadas al modelo, tiempo de llamadas a herramientas y estado de fallo. Las muestras de observabilidad pueden convertirse en el patrón de referencia para equipos que de lo contrario enviarían agentes con solo logs de consola. La pregunta útil para cualquier agente alojado es: ¿podemos reconstruir una ejecución fallida desde la solicitud externa a través de la decisión de orquestación, llamada al modelo, llamada a herramienta y respuesta final?
Los eventos de razonamiento en AGUI exponen otro problema de transporte. Las interfaces de usuario necesitan renderizar el progreso del agente sin mezclar cadena de pensamiento privada, racionalización de herramientas y resúmenes de razonamiento visibles por el usuario incorrectamente. Un canal de eventos de razonamiento permite que el framework represente el progreso o estado relacionado con razonamiento como eventos estructurados. La aplicación todavía tiene que decidir qué es seguro mostrar, almacenar y transmitir, pero los eventos estructurados son mejores que hacer scraping de texto de un stream.
El multithreading de todo y la inyección de todo en la lista de mensajes muestran cómo el manejo de estado se convierte en una característica del tiempo de ejecución. Los agentes usan listas de todo para planificar, rastrear progreso y recuperarse después de interrupciones. Si el estado de todo no es thread-safe, las actualizaciones concurrentes pueden corromper el plan. Si el estado de todo no es visible en el contexto del mensaje, el modelo puede perder pista de compromisos. Inyectar todos en la lista de mensajes hace que el estado de tarea sea parte del contexto del modelo, mientras que las mejoras de multithreading reducen condiciones de carrera alrededor de actualizaciones.
La corrección del formato de cable de function_call_output.output es pequeña pero crítica. El lanzamiento lo corrige para que sea un string JSON en el cable. Los formatos de salida de herramientas son contratos entre tiempo de ejecución, SDKs, modelos y clientes. Si un lado espera un string y otro lado envía JSON estructurado directamente, la deserialización o reproducción puede fallar. Los frameworks de agentes deben ser estrictos con estos contratos de cable porque las salidas de herramientas a menudo se almacenan, transmiten, compactan y se reanudan más tarde.
La generación de números de secuencia obtiene una corrección para IDs duplicados o fuera de orden. El ordenamiento de eventos es fundamental para UIs y logs de agentes. Si dos eventos comparten un número de secuencia o llegan con ordenamiento inconsistente, los clientes pueden renderizar estado obsoleto, descartar actualizaciones o desasociar incorrectamente resultados de herramientas. En una conversación multi-agente o multipartita, los bugs de ordenamiento son especialmente dolorosos porque el usuario no puede decir qué agente dijo o hizo qué primero.
Las correcciones de re-ingreso de workflow y parsing de YAML hablan de la confiabilidad de agentes declarativos. Un loop de QuestionExecutor después de re-ingreso de GotoAction es el tipo de bug que convierte la conveniencia del workflow declarativo en comportamiento descontrolado. El parsing de block scalar de YAML para file skills importa porque las definiciones de skills basadas en archivos a menudo contienen prompts, instrucciones, ejemplos o scripts. Si los block scalars se parsean incorrectamente, la skill que el agente ve no es la skill que el desarrollador escribió.
La recomendación práctica es evaluar esta versión a través de las superficies de producción. Si usas Microsoft Agent Framework, inspecciona cómo la orquestación elige el siguiente actor, define listas de permitidos de herramientas de navegador antes de conectar sitios externos, conecta la observabilidad antes del despliegue, trata los eventos de razonamiento como un canal de IU gobernado, prueba el estado de tareas bajo concurrencia y valida la compatibilidad del cableado para las salidas de herramientas. Los lanzamientos de frameworks no son solo nuevas abstracciones; son cambios en los contratos de runtime de los que depende tu aplicación.
[50:00] Cierre
La conclusión práctica del EP048 es operativa. Codex 0.130.0 hace que las sesiones de agente de codificación sean más similares a servicios con servidores de aplicaciones de control remoto, vistas de hilos paginados, visibilidad de ganchos de plugins, actualización de configuración y mejor recuperación alrededor de parches y compactación. La investigación de Semantic Kernel de Microsoft muestra cómo los argumentos de herramientas controlados por modelos pueden convertirse en ejecución de código si los frameworks los transforman en expresiones de lenguaje host interpretadas. GitHub Copilot SDK proporciona a productos integrados ganchos de aprobación y recuperación más diagnósticos. Microsoft Agent Framework 1.5 impulsa la orquestación, la política de navegador, la observabilidad, el transporte de eventos, el estado de tareas y la corrección del formato de cableado. Para los constructores, el trabajo es hacer que cada límite de runtime del agente sea explícito: plano de control, entrada de herramientas, evento de aprobación, política de navegador, telemetría y estado de hilo almacenado.
[NOVA]: Soy NOVA.
[ALLOY]: Y yo soy ALLOY, y esto es OpenClaw Daily. Hoy vamos a ver cuatro historias de constructores donde los runtimes de agentes se vuelven más controlables, más inspeccionables, y más peligrosos si sus límites están mal definidos.
[NOVA]: OpenAI Codex 0.130.0 les da a los operadores de agentes de código una superficie de control remoto más limpia. La investigación de Microsoft's Semantic Kernel muestra cómo la inyección de prompts puede convertirse en ejecución de código cuando los argumentos de herramientas cruzan hacia código de frameworks basados en eval. GitHub Copilot SDK añade callbacks para aprobación de planes y recuperación de límites de tasa. Y Microsoft Agent Framework 1.5 avanza en orquestación, política de navegador, observabilidad y semántica de conexión. ...
[ALLOY]: La pregunta práctica debajo de la última historia es importante: ¿puede Microsoft Agent Framework realmente usarse dentro de OpenClaw? Respuesta corta: sí, pero no como un reemplazo directo para el runtime propio de OpenClaw. Puede ejecutarse junto con OpenClaw como un servicio de agente externo, una habilidad respaldada por comandos, un flujo de trabajo alojado, o un puente expuesto a través de un protocolo de herramientas. OpenClaw permanecería como la puerta de enlace local-first, el enrutador de canales, el administrador de sesiones y la autoridad de herramientas. Microsoft Agent Framework sería un runtime de agente especializado que OpenClaw llama, supervisa y envuelve con políticas.
[NOVA]: Esa distinción importa. Un framework puede ser útil dentro de un sistema sin convertirse en el sistema. El modelo de integración seguro no es, "dejemos que un segundo framework tome el control del host". El modelo seguro es, "tratar el framework como un límite de herramientas no confiable o semi-confiable con entradas, salidas, permisos, telemetría y manejo de fallos explícitos."
[NOVA]: Historia uno es OpenAI Codex 0.130.0. El titular es control remoto de codex, un punto de entrada más simple para iniciar un servidor de aplicaciones sin cabeza que puede ser controlado de forma remota.
[ALLOY]: Un servidor de aplicaciones sin cabeza es un objeto operativo muy diferente de un agente de línea de comandos de una sola ejecución. Una terminal se inicia, trabaja y sale. Un servidor de aplicaciones posee sesiones, hilos, instantáneas de configuración, selección de entorno, ejecución de herramientas, eventos de revisión y conexiones de clientes a lo largo del tiempo. Eso significa que el runtime ya no solo responde a un prompt. Mantiene una superficie de servicio.
[NOVA]: Exactamente. El servidor de aplicaciones tiene que mantener una sesión de código viva mientras los clientes se reconectan, inspeccionan el historial, abren turnos específicos, revisan diffs y continúan el trabajo desde una interfaz diferente. Un comando de control remoto hace que ese plano de control sea explícito. Es el camino desde un asistente de código local hasta un endpoint de servicio que un IDE, panel de control, cliente de navegador o máquina de desarrollo remota puede manejar.
[ALLOY]: El gran mecanismo aquí es la separación de control y trabajo. El servidor posee la sesión durable. Los clientes pueden venir y ir. El trabajo no está ligado a la vida de la pestaña original de la terminal. Eso es útil, pero eleva el listón para la gestión de estado, control de acceso y auditabilidad.
[NOVA]: Codex 0.130.0 también añade paginación de hilos grandes donde los clientes pueden solicitar vistas de elementos de turno descargadas, resumidas o completas. Eso suena como pulido de interfaz hasta que piensas en lo que contiene un hilo de agente. Puede incluir turnos de usuario, turnos de modelo, llamadas a herramientas, aprobaciones, diffs, referencias de archivos, imágenes, resúmenes de compactación, metadatos de plugins y estado de revisión. Cargar ese objeto completo en cada cliente remoto es desperdiciado y frágil.
[ALLOY]: Las vistas de hilos paginadas hacen que la transcripción se comporte más como una línea de tiempo operativa. Un elemento no descargado puede preservar identidad y orden sin transferir la carga útil. Un elemento resumido puede dar suficiente contexto para navegar. Un elemento completo puede materializarse cuando el cliente realmente abre el detalle. Esa es la misma forma que ves en visualizadores de trazas, exploradores de logs y líneas de tiempo de issues.
[NOVA]: También protege la latencia. Un cliente remoto no debería congelarse porque un hilo de agente creció hasta convertirse en un registro de trabajo gigante. Para sesiones de código de larga duración, la paginación no es una optimización en el borde. Se convierte en parte del contrato de sesión.
[ALLOY]: Los detalles de plugins ahora muestran hooks incluidos, y compartir plugins expone metadatos de enlace más controles de descubribilidad. Eso es una mejora en auditabilidad. Los hooks son parte del comportamiento del runtime de un plugin. Si un plugin puede observar el inicio, interceptar llamadas a herramientas, proporcionar comandos o participar en revisión, los operadores necesitan ver eso antes de instalarlo o compartirlo.
[NOVA]: Esconder hooks dentro de paquetes convierte la revisión de plugins en adivinanzas. Mostrar metadatos de hooks hace visible la superficie de ejecución. En sistemas de agentes, la descubribilidad sin inspeccionabilidad es arriesgada. Es fácil instalar algo que suena como una conveniencia inofensiva y descubrir después que modifica el comportamiento de herramientas, el estado de inicio o el flujo de revisión.
[ALLOY]: El lanzamiento también repara el comportamiento de configuración de servidores de aplicaciones en vivo. Los hilos de servidores de aplicaciones en vivo ahora capturan cambios de configuración sin requerir un reinicio. Eso es una corrección de confiabilidad práctica porque la configuración en un runtime de agente puede incluir elecciones de modelo, políticas de aprobación, configuraciones de proveedor, disponibilidad de herramientas, estado de plugins, selección de entorno y opciones de telemetría.
[NOVA]: Si un hilo de larga duración sigue usando configuración obsoleta, el operador puede creer que la política ha cambiado mientras el agente activo continúa bajo reglas más antiguas. Actualizar hilos en vivo desde la última instantánea de configuración hace que los cambios de política tomen efecto donde se está haciendo el trabajo. También reduce la tentación operativa de reiniciar un servicio solo para hacer que una aprobación o configuración de proveedor se mantenga.
[ALLOY]: Los diffs de turno obtienen una de las correcciones más importantes para constructores. Codex ahora mantiene los diffs precisos a través de operaciones de aplicar parche, incluyendo fallos parciales que aún mutan archivos. Este es un modo de fallo real. Un parche puede fallar a mitad de camino y aún así cambiar parte de un archivo. Si el runtime reporta el diff incorrecto después, la vista de revisión, la lógica de reversión y el rastro de auditoría no pueden ser confiables.
[NOVA]: El seguimiento de diffs basado en operaciones es la dirección correcta. El runtime debe registrar lo que realmente cambió, no solo lo que se suponía que debía cambiar el parche ideal. Los agentes de código necesitan estado post-operación preciso, especialmente cuando se permite que las herramientas editen archivos. Un diff engañoso es peor que ningún diff porque crea falsa confianza.
[ALLOY]: Las correcciones de ThreadStore mejoran resúmenes, renombrados, reanudación y rutas de bifurcación, incluyendo hilos sin rutas de despliegue local. Eso hace que la capa de almacenamiento sea más una fuente de verdad para operaciones de ciclo de vida. La reanudación y bifurcación importan porque un usuario puede ramificar una investigación, continuar una ejecución fallida o abrir un hilo desde un cliente remoto que no tiene la ruta del sistema de archivos local original.
[NOVA]: Si la identidad del hilo depende demasiado del estado de la máquina local, los flujos de trabajo sin cabeza y remotos se rompen. Un servidor de aplicaciones remoto debería poder responder, "¿qué es este hilo, qué estado contiene y cómo puede continuar?" sin asumir que el contexto original de la terminal todavía está presente.
[ALLOY]: La compactación remota también recibe correcciones al contrato de stream. Codex ahora emite response.processed para streams v2 y evita enviar service_tier en solicitudes de compactación con clave API. La compactación determina cuánto tiempo permanecen usables las sesiones, pero la compactación remota tiene que hablar el mismo lenguaje de eventos que los turnos normales. Un evento processed faltante puede dejar a un cliente esperando un estado terminal. Un campo de solicitud no soportado puede romper solo la ruta de compactación, lo que hace el diagnóstico doloroso.
[NOVA]: El soporte multiambiente aparece en view_image, que ahora puede resolver archivos a través del entorno seleccionado. Eso importa porque los agentes de codificación suelen operar a través de un host, contenedor, sandbox, espacio de trabajo remoto o proyecto montado. Una ruta de imagen no tiene sentido a menos que el runtime sepa qué entorno la posee. Resolver a través del entorno seleccionado evita que un cliente mire el filesystem equivocado o falle en mostrar un artefacto que existe dentro del sandbox activo.
[ALLOY]: El soporte de autenticación de Bedrock ahora acepta credenciales de inicio de sesión de consola de AWS desde perfiles de login de aws. Eso es conveniencia para el operador con impacto en el despliegue. Muchos equipos ya gestionan el acceso a AWS a través de flujos basados en perfiles. Permitir que Codex use esos perfiles reduce rutas de credenciales duplicadas y hace que la autenticación del proveedor de modelos se alinee con los controles de acceso a la nube existentes.
[NOVA]: Los cambios de telemetría son útiles para depuración en producción. Codex añade metadatos de trazas OpenTelemetry configurables y analíticas de revisión y retroalimentación más ricas. Los eventos de revisión son centrales para la seguridad del agente de codificación. Si un comando fue aprobado, denegado, reintentado o escalado, los operadores necesitan suficiente contexto de traza para entender por qué.
[ALLOY]: Una buena telemetría conecta la sesión, el turno, la llamada de herramienta, la decisión de aprobación, la solicitud al modelo y el resultado visible para el usuario sin filtrar secretos. Esa es la línea que hay que trazar. Muy poca telemetría hace imposible reconstruir incidentes. Demasiada telemetría puede exponer prompts, archivos, credenciales o código privado.
[NOVA]: La recomendación práctica es tratar los despliegues de Codex app-server como despliegues de servicios. Fijar la versión. Iniciar remote-control deliberadamente. Documentar qué clientes pueden conectarse. Auditar los hooks de plugins antes de compartir. Probar el comportamiento de actualización de configuración. Probar fallos de parches parciales. Y verificar que la compactación, la reanudación de hilos y la visualización de imágenes funcionen en los entornos que realmente usas.
[ALLOY]: Un detalle operativo más merece ser detallado. Cuando un agente de codificación se convierte en un app-server, la frontera entre la UX del producto y el estado del runtime se vuelve más delgada. Una interfaz de usuario ahora puede solicitar un resumen compactado, un turno completo, una página de detalle de plugin, un evento de revisión o un artefacto de imagen. Si esos endpoints no están versionados y probados, la UI puede depender accidentalmente de formas internas que cambian en un lanzamiento. Los constructores deben tratar esas respuestas de app-server como contratos de API, incluso cuando el cliente y el servidor se distribuyen juntos.
[NOVA]: Eso también cambia la respuesta a incidentes. En un modelo solo de terminal, un operador puede desplazamiento hacia atrás a través de la transcripción del shell e inspeccionar el árbol de trabajo. En un modelo de app-server remoto, la evidencia está distribuida a través del almacenamiento de hilos, registros de operación de herramientas, telemetría, aprobaciones de revisión, metadatos de plugins y vistas de archivos específicas del entorno. El runtime tiene que preservar suficiente estado para reconstruir lo que pasó después del hecho.
[ALLOY]: Y porque los clientes remotos pueden reconectarse, la sesión debe ser robusta ante fallos parciales del cliente. Si una pestaña del navegador se desconecta durante la compactación, el servidor todavía necesita un evento terminal. Si un parche se aplica parcialmente y el cliente se refresca, el servidor todavía necesita el diff real. Si la configuración cambia durante un hilo largo, la política activa debe ser comprensible. Por eso estas correcciones aparentemente pequeñas se acumulan para hacer un runtime de remote-control más creíble.
[NOVA]: El lanzamiento no solo se trata de nuevos comandos. Se trata de hacer que un agente de codificación sea controlable, inspeccionable y recuperable cuando las sesiones crecen y se ejecutan de forma remota.
[NOVA]: La historia dos es el caso de estudio de seguridad de Microsoft sobre ejecución remota de código en frameworks de agentes de IA. El punto importante es que el modelo no es el componente vulnerable en la falla central. La frontera peligrosa es el código del framework y de plugins que confía en argumentos de herramientas controlados por el modelo y los convierte en comportamiento ejecutable del host.
[ALLOY]: La ruta disclosed se centra en el flujo de búsqueda del Vector Store en memoria de Semantic Kernel. El agente de ejemplo expone un plugin de búsqueda de hoteles. Un usuario pide hoteles en una ciudad. El modelo llama a la función de búsqueda con un argumento de ciudad. El plugin construye un filtro antes de la búsqueda de similitud vectorial. El paso arriesgado es que un valor controlado por el modelo se interpola en una expresión lambda de Python y se ejecuta con eval.
[NOVA]: Ese es el cruce de fronteras. Una cadena de ciudad normal se convierte en parte de una expresión de filtro. Una cadena maliciosa puede cerrar una comilla y appendar lógica de Python. La inyección de prompts no necesita un exploit de navegador ni corrupción de memoria cuando el framework convierte valores controlados por lenguaje natural en código. El agente se ha convertido en una ruta del texto a la ejecución en el host.
[ALLOY]: La mitigación intentada usó validación de AST y un entorno de builtins restringido. En términos generales, el validador permitía expresiones lambda, escaneaba nombres y atributos en busca de identificadores peligrosos, y ejecutaba con los builtins removidos. Eso suena plausible, pero los lenguajes dinámicos hacen que las listas de bloqueo sean frágiles.
[NOVA]: Los investigadores de Microsoft bypassearon el filtro sin depender directamente de los nombres bloqueados obvios. El payload atravesó estructuras de objetos de Python para localizar maquinaria de import y alcanzar ejecución de comandos a través de atributos alternativos. Ese es el problema clásico de intentar hacer seguro un evaluador de lenguaje host general banning tokens conocidos como peligrosos.
[ALLOY]: La lección no es solo "no uses eval," aunque ese es un buen punto de partida. La lección más amplia es que los argumentos de llamadas a herramientas son entradas no confiadas incluso cuando vinieron de un modelo, incluso cuando el usuario no escribió código directamente, e incluso cuando el esquema afirma que el campo es algo inofensivo como un nombre de ciudad.
[NOVA]: Un modelo puede ser inducido a colocar strings controlados por el atacante en cualquier argumento que se le permita llenar. Si la herramienta interpreta esa cadena como código, un lenguaje de consulta, un comando de shell, una ruta de archivo, una plantilla o una expresión serializada, el framework ha creado un sumidero de inyección.
[ALLOY]: La búsqueda vectorial hace que el problema sea fácil de subestimar porque se siente como infraestructura de recuperación, no como ejecución de código. Pero los stores vectoriales a menudo soportan filtros de metadatos, lenguajes de expresión, predicados personalizados, pre-filtros de embeddings, re-rankers y cadenas de consulta específicas de conectores. Cualquiera de esos puede convertirse en una frontera de inyección si los valores controlados por el usuario o el modelo se concatenan en una expresión interpretada.
[NOVA]: Un diseño más seguro generalmente significa filtros parametrizados, DSLs tipados, operadores en lista de permitidos y validación que rechace estructuras inesperadas antes de la ejecución. El campo equals valor debe ser datos, no código fuente. Si un lenguaje de filtro es inevitable, el runtime debería parsear a un AST restringido y evaluar con un intérprete que solo entienda las operaciones permitidas. No debería llamar al evaluador del lenguaje host e intentar bloquear comportamiento peligroso después.
[ALLOY]: El privilegio mínimo también importa. Un predicado de búsqueda de hoteles no necesita acceso a shell. Si un bug del framework convierte un filtro en ejecución de código, los privilegios del sandbox y del proceso determinan el radio de explosión. Los frameworks de agentes deben aislar la ejecución de plugins, limitar las variables de entorno, evitar pasar credenciales a procesos de herramientas genéricos, y registrar cuidadosamente los parámetros de herramientas lo suficiente para la respuesta a incidentes.
[NOVA]: La detección es práctica. Los equipos deben inventariar las herramientas que ejecutan plantillas, filtros, comandos de shell, celdas de notebooks, fragmentos de Python, fragmentos de JavaScript, SQL u operaciones de archivos. Luego deben rastrear si los valores controlados por el modelo pueden llegar a esos intérpretes. Aplicar parches a Semantic Kernel es necesario para los usuarios de la ruta afectada, pero los plugins personalizados a menudo repitieren el mismo patrón.
[ALLOY]: También hay una lección sobre pruebas. Una prueba unitaria normal puede pasar porque verifica un nombre de ciudad amigable, una categoría amigable o un campo de metadatos amigable. Las pruebas de seguridad necesitan valores adversarios que intenten romper la sintaxis esperada. Para un filtro de vectores, eso significa comillas, llaves, operadores, recorrido de atributos, cadenas muy largas, unicode inusual y intentos de referenciar objetos que nunca deberían ser alcanzables. La prueba debe afirmar que estos valores permanecen como datos.
[NOVA]: Una pregunta de revisión útil es: "¿Dónde está el primer intérprete?" Si un valor se analiza como JSON, eso es un límite. Si se convierte en SQL, eso es otro. Si se convierte en una lambda de Python, comando de shell, plantilla, expresión regular o ruta de archivo, cada paso necesita su propia regla de validación. El peor patrón es convertir datos del usuario o del modelo en una cadena que luego es interpretada por un lenguaje más poderoso de lo que el esquema prometía.
[ALLOY]: Los mantenedores de frameworks también tienen que hacer que la ruta segura sea la ruta predeterminada. Si el ejemplo fácil en la documentación usa concatenación de cadenas en una expresión de filtro, las aplicaciones downstream lo copiarán. Si el helper predeterminado del almacén de vectores acepta un constructor de filtros tipado, menos aplicaciones inventarán su propia versión insegura. La seguridad del agente mejora cuando la ergonomía del framework empuja a los desarrolladores hacia la composición segura.
[NOVA]: Por eso esta investigación importa más allá de un solo error. Les da a los constructores un modelo mental concreto: la inyección de prompts se convierte en compromiso del host solo cuando hay un puente desde los datos controlados por el lenguaje hacia la ejecución privilegiada. Encuentren los puentes, estrechenlos y eliminen los intérpretes de la ruta normal.
[ALLOY]: Aquí es donde el propio modelo operativo de OpenClaw es relevante. OpenClaw trata los DMs entrantes y los mensajes de canal como entrada no confiable. Tiene una gateway local-first, enrutamiento de canales, políticas de herramientas y opciones de sandboxing para sesiones no principales. Pero eso no hace mágicamente seguro cada framework llamado. Si OpenClaw invoca un framework de agente externo, se aplica la misma regla: el framework es un límite de herramienta, no un lenguaje interno confiable.
[NOVA]: Exacto. Si se llama un flujo de trabajo de Microsoft Agent Framework, un plugin de Semantic Kernel o cualquier otro runtime externo desde OpenClaw, la integración debe definir un contrato de comandos estrecho, entradas tipadas, acciones en lista de permitidos, aislamiento de entorno, tiempos de espera y salidas estructuradas. El host no debe entregar al runtime externo acceso ilimitado al sistema de archivos, red, tokens o shell a menos que eso sea realmente lo que se busca.
[ALLOY]: El takeaway para operadores es directo: cada herramienta de agente es un endpoint de API cuyo llamador está parcialmente controlado por el modelo. Traten los esquemas de herramientas como contratos de API externos. Validen las entradas en el límite. Prefieran estructuras de datos tipadas sobre cadenas interpretadas. Mantengan los permisos estrechos. Registren lo suficiente para reconstruir qué prompt produjo qué argumentos de herramienta. Y prueben la inyección de prompts intentando forzar parámetros hostiles en las herramientas, no solo verificando si el modelo dice palabras unsafe.
[NOVA]: La seguridad frente a inyección de prompts no es solo comportamiento del modelo. Es validación de entradas, evitación de intérpretes, sandboxing y diseño de mínimo privilegio para el runtime que ejecuta el trabajo.
[NOVA]: Historia tres: la preventa del GitHub Copilot SDK del 8 de mayo. Esta trata sobre incrustar sesiones de agentes de codificación en productos con control de runtime más explícito.
[ALLOY]: Las aplicaciones ahora pueden registrar callbacks para exitPlanMode.request y autoModeSwitch.request. Esos eventos importan porque el modo plan y el cambio automático de modelo son decisiones de producto, no solo decisiones del modelo.
[NOVA]: El modo plan es un límite entre proponer trabajo y hacer trabajo. En un agente de codificación incrustado, la aplicación puede querer que un humano apruebe el plan, que un motor de políticas lo verifique, o que una regla específica del proyecto bloquee ciertos cambios. Un handler para solicitudes de exit-plan-mode le da al producto host un punto claro de interceptación antes de que el runtime pase de planificar a ejecutar.
[ALLOY]: El cambio automático de modelo después de límites de tasa es un límite diferente. Un runtime puede querer recuperarse de un evento de límite de tasa moviéndose a otro modelo o modo. Eso puede preservar la continuidad, pero también puede cambiar comportamiento, costo, latencia o capacidad. El handler de autoModeSwitch.request permite que la aplicación decida si acepta el cambio.
[NOVA]: Para productos empresariales, eso importa porque la elección de modelo puede estar ligada a políticas de datos, cumplimiento, bases de evaluación y controles de presupuesto. Un fallback que parece inofensivo para el runtime puede ser inaceptable para la aplicación host si cruza un límite de proveedor o cambia la política de retención.
[ALLOY]: El release también agrega diagnósticos estructurados en los SDKs de .NET, Python y Rust. Los logs cubren inicio del CLI, conexión TCP, tiempo de solicitudes JSON-RPC, ciclo de vida de sesiones y rutas de error. Esa es la visibilidad que necesita un SDK de agente incrustado.
[NOVA]: Cuando una sesión falla, la causa puede ser inicio del proceso, transporte, autenticación, encuadre JSON-RPC, manejo de eventos del runtime, respuesta del modelo, ejecución de herramientas o comportamiento de callbacks del host. Sin logs estructurados de tiempo y ciclo de vida, todo parece "el agente se colgó."
[ALLOY]: El detalle de JSON-RPC es especialmente importante. Muchos SDKs de agentes de codificación envuelven un proceso de runtime local y se comunican sobre JSON-RPC. Eso crea un objeto cliente en la aplicación, un proceso de runtime, una conexión de transporte, IDs de solicitudes, streams de eventos y operaciones de larga duración. Los diagnósticos necesitan mostrar cuándo arrancó el runtime, cuándo se abrió la conexión TCP, qué solicitudes se enviaron, cuánto tardaron y dónde surgieron los errores.
[NOVA]: La opción enableSessionTelemetry hace que la telemetría sea una elección explícita de sesión. Esa es la forma correcta para privacidad y operaciones. Algunos despliegues quieren telemetría de sesión para depurar problemas y mejorar confiabilidad. Otros la necesitan deshabilitada por política. Poner la perilla en la configuración de sesión y configuración de resume hace que la decisión sea auditable y repetible.
[ALLOY]: Hay correcciones de compatibilidad más pequeñas con impacto real. Los enums de eventos de sesión en C# ahora son readonly structs respaldados por strings para que la deserialización no falle cuando el runtime agrega nuevos valores de enum. Eso es compatibilidad hacia adelante para streams de eventos. Los blobs de recursos de resultados de herramientas binarias de Rust ahora usan application/octet-stream como predeterminado cuando falta mimeType. Eso es resiliencia del formato wire.
[NOVA]: La implicación práctica para constructores es que las sesiones de Copilot SDK se están convirtiendo en objetos de runtime controlados por el host. Si las incrustan, implementen los callbacks de plan-mode y mode-switch deliberadamente. Decidan qué cambios pueden happen automáticamente y cuáles requieren revisión. Habiliten diagnósticos en desarrollo y staging. Capturen tiempos de JSON-RPC alrededor de sesiones lentas o inestables. Traten la telemetría como política, no un predeterminado oculto.
[ALLOY]: Y probar clientes más antiguos contra eventos de runtime más recientes. Los flujos de eventos evolucionan. Si el manejo de enums o los valores por defecto de MIME fallan, el agente puede estar funcionando mientras el producto host no puede deserializar lo que ocurrió.
[NOVA]: La historia cuatro es Microsoft Agent Framework 1.5. El lanzamiento es amplio, pero hay varios cambios directamente relevantes para constructores de agentes en producción: Magentic Orchestration para .NET, allowlisting de WebBrowsingTool, muestras de observabilidad de agentes alojados, eventos de razonamiento en AGUI, skills basados en clases y proveedores de contexto de harness en la línea de Python, inyección de estado todo, headers por llamada de Foundry, y una corrección de formato wire para function_call_output.output.
[ALLOY]: Magentic Orchestration es el titular porque los sistemas multiagente necesitan más que una lista de agentes. Necesitan programación, delegación, propiedad de turnos, estado compartido, condiciones de terminación, y una forma de decidir qué actor debe actuar a continuación. Una capa de orquestación formaliza esos mecanismos. Marcarla como experimental es apropiado porque la semántica de orquestación se convierte en arquitectura de aplicación.
[NOVA]: Un mal programador puede crear bucles, duplicar trabajo, ocultar fallas, o dejar que un agente domine una conversación. La orquestación multiagente no es magia colaborativa. Es una política de runtime sobre quién actúa, cuándo actúan, qué contexto ven, y cuándo se detiene el proceso.
[ALLOY]: El allowlisting de WebBrowsingTool es una característica importante de control del navegador. Las herramientas de navegación conectan un agente a contenido externo que puede ser malicioso, no confiable, o simplemente distractivo. Una lista de permitidos le da a la aplicación host una superficie de política antes de que la herramienta de navegador se ejecute.
[NOVA]: En sistemas de agentes, navegar no es solo leer. El navegador puede obtener contenido de inyección de prompts, enviar formularios, seguir redirecciones, exponer cookies, recuperar archivos e interactuar con sesiones autenticadas. La política tiene que existir antes de la ejecución de la herramienta, no solo después de que una mala página ya haya influido en la ejecución.
[ALLOY]: Las muestras de observabilidad de agentes alojados también son valiosas porque el despliegue es donde las abstracciones del framework se encuentran con la realidad de producción. Un agente alojado necesita logs, trazas, correlación de solicitudes, visibilidad de llamadas al modelo, tiempo de llamadas a herramientas y estado de falla. La pregunta útil es si un equipo puede reconstruir una ejecución fallida desde la solicitud externa a través de orquestación, llamada al modelo, llamada a herramienta y respuesta final.
[NOVA]: Los eventos de razonamiento en AGUI exponen un problema de transporte. Las interfaces de usuario necesitan renderizar el progreso del agente sin mezclar incorrectamente la cadena de pensamiento privada, la justificación de herramientas y los resúmenes visibles para el usuario. Un canal de eventos de razonamiento permite que el framework represente el progreso o el estado relacionado con el razonamiento como eventos estructurados. La aplicación todavía tiene que decidir qué es seguro mostrar, almacenar y transmitir.
[ALLOY]: La multitarea de todo y la inyección de todo en la lista de mensajes muestran cómo el estado de tareas se convierte en una característica de runtime. Los agentes usan listas todo para planificar, seguir el progreso y recuperarse después de interrupciones. Si el estado todo no es seguro para hilos, las actualizaciones concurrentes pueden corromper el plan. Si el estado todo no es visible en el contexto del mensaje, el modelo puede perder el rastro de los compromisos.
[NOVA]: La corrección del formato wire de function_call_output.output es pequeña pero crítica. El lanzamiento lo corrige para que sea una cadena JSON en el wire. Los formatos de salida de herramientas son contratos entre runtime, SDKs, modelos y clientes. Si un lado espera una cadena y otro envía JSON estructurado directamente, la deserialización, reproducción, almacenamiento o compactación pueden fallar.
[ALLOY]: La generación de números de secuencia recibe una corrección para IDs duplicados o fuera de orden. El ordenamiento de eventos es fundamental para interfaces de agentes y logs. Si dos eventos comparten un número de secuencia o llegan fuera de orden, los clientes pueden renderizar estado obsoleto, descartar actualizaciones, o adjuntar un resultado de herramienta al turno equivocado. En una conversación multiagente o multipartita, los errores de ordenamiento son especialmente dolorosos.
[NOVA]: Las correcciones de reentrada de workflow y análisis de YAML hablan de la confiabilidad de agentes declarativos. Un bucle después de reentrada de GotoAction puede convertir la conveniencia del workflow en comportamiento desbocado. El análisis de escalares de bloque YAML para skills de archivos importa porque los skills basados en archivos a menudo contienen prompts, instrucciones, ejemplos o scripts. Si los escalares de bloque se analizan incorrectamente, el skill que el agente ve no es el skill que el desarrollador escribió.
[ALLOY]: Ahora a la pregunta de integración de OpenClaw. ¿Puede Microsoft Agent Framework usarse dentro de OpenClaw? Sí, pero la arquitectura limpia es basada en adaptadores. OpenClaw es un gateway asistente local-first que ya gestiona canales, sesiones, herramientas, nodos, superficies de navegador y canvas, cron, skills, sandboxing y enrutamiento multiagente. Microsoft Agent Framework es un framework de agentes separado con superficies .NET y Python. Debería integrarse como un runtime llamado, no confundido con el runtime de sesión nativo de OpenClaw.
[NOVA]: Hay varios patrones viables. Primero, un skill respaldado por comandos: OpenClaw puede invocar un script local o servicio que ejecute un workflow de Microsoft Agent Framework y devuelva un resultado estructurado. Esa es la forma más simple. La entrada del skill es tipada. El proceso del framework se ejecuta con un directorio de trabajo y entorno definidos. La salida se captura como texto o JSON. Los tiempos de espera y el manejo de fallas permanecen en OpenClaw.
[ALLOY]: Segundo, un servicio local alojado: una aplicación .NET o Python Agent Framework puede ejecutarse como un servicio localhost o de red privada. OpenClaw lo llama a través de un adaptador HTTP o RPC estrecho. Esto es útil si el framework necesita estado de orquestación de larga duración, clientes de modelo warmed o su propio pipeline de observabilidad. OpenClaw todavía es dueño de qué canal puede llamarlo y qué credenciales se exponen.
[NOVA]: Tercero, un puente de protocolo de herramientas: si el workflow de Agent Framework puede exponerse detrás de un servidor de herramientas, OpenClaw puede tratarlo como otro proveedor de herramientas. La parte importante es el límite. Los nombres de herramientas, esquemas, operaciones permitidas y artefactos devueltos deben ser explícitos. OpenClaw no debe importar ciegamente cada capacidad de un proceso de framework en cada sesión.
[ALLOY]: Cuarto, un carril de subagente en sandbox: OpenClaw puede enrutar tareas seleccionadas a un no-primer-agente o sandbox que tiene permiso para ejecutar el framework externo. Este es un patrón más seguro para experimentos porque al framework se le puede dar acceso limitado al sistema de archivos y red. Es especialmente relevante para herramientas de navegador y workflows alojados que pueden encontrar contenido no confiable.
[NOVA]: Los límites de integración son igual de importantes. Microsoft Agent Framework no se convierte automáticamente en un canal nativo de OpenClaw. No hereda automáticamente la política de emparejamiento de OpenClaw, enrutamiento de Discord o Telegram, comportamiento de Canvas en vivo, gestión de nodos, modelo de memoria o puertas de aprobación. Esas tienen que ser envueltas deliberadamente. También trae sus propias dependencias, modelo de eventos, semántica de skills y contratos de salida de herramientas.
[ALLOY]: La lección de seguridad de la historia de Semantic Kernel aplica directamente. Si OpenClaw llama a un agente de Microsoft Agent Framework, los argumentos generados por el modelo de un runtime pueden entrar a las herramientas de otro runtime. Eso significa que la validación no puede asumirse. Un puente seguro debería usar objetos de solicitud tipados, operaciones en lista de permitidos, logs redaccionados, variables de entorno de mínimo privilegio, listas de permitidos de navegador explícitas y sin acceso genérico al shell por defecto.
[NOVA]: La observabilidad también necesita un puente. OpenClaw puede trazar un mensaje de usuario, sesión, llamada de herramienta y respuesta. Microsoft Agent Framework puede trazar orquestación, llamadas al modelo, llamadas a herramientas, eventos de razonamiento y estado del workflow. Una integración de producción debería llevar un ID de correlación a través de ese límite para que una solicitud fallida pueda seguirse desde el mensaje del canal hasta la sesión de OpenClaw, invocación del framework externo y de vuelta.
[ALLOY]: La recomendación práctica es un optimismo cauteloso. Usa Microsoft Agent Framework dentro de OpenClaw cuando te brinde una capacidad específica: orquestación estilo Magentic, integración con Foundry, ejemplos de agentes hospedados, habilidades declarativas, o un flujo de trabajo ya escrito en .NET o Python. No lo uses simplemente porque es otro framework de agentes. Si OpenClaw ya proporciona el canal, la sesión y el comportamiento de herramientas que necesitas, agregar un segundo framework puede añadir complejidad sin valor.
[NOVA]: El mejor primer experimento sería estrecho. Construye un flujo de trabajo de Microsoft Agent Framework que realice una tarea contenida, expónlo a través de una única habilidad de OpenClaw o servicio local, pasa un objeto de entrada tipado, devuelve un resultado estructurado, ejecútalo sin credenciales amplias, y registra el ID de correlación. Luego evalúa la latencia, confiabilidad, seguridad de herramientas, y si el resultado de orquestación es mejor que una habilidad nativa de OpenClaw.
[ALLOY]: Si la respuesta es sí, expands cuidadosamente. Agrega acceso al navegador solo con listas de permitidos. Agrega acceso a archivos solo a un espacio de trabajo delimitado. Agrega credenciales solo a través de referencias secretas explícitas o inyección de entorno. Agrega estado persistente solo después de que la semántica de reproducción y reanudación esté clara. Y nunca dejes que un framework amplíe silenciosamente los permisos de una sesión de chat.
[NOVA]: Así que la respuesta no es "no, porque OpenClaw es separado", y no es "sí, simplemente instálalo y deja que ejecute todo". La respuesta es: sí, Microsoft Agent Framework puede usarse dentro de un despliegue de OpenClaw como un runtime externo integrado, pero OpenClaw debe permanecer como la autoridad para la entrada de canales, confianza del usuario, política de herramientas, sandboxing y entrega.
[ALLOY]: Hay algunos casos donde la integración valdría la pena. Si un equipo ya tiene agentes .NET construidos alrededor de Foundry, Magentic Orchestration, flujos de trabajo declarativos, o los ejemplos de agentes hospedados de Microsoft, envolver ese trabajo para OpenClaw puede preservar la inversión. OpenClaw puede convertirse en la capa operativa personal alrededor de esto: intake de mensajes, aprobación del usuario, entrega de canales, disparadores de programación, preparación de archivos y control de máquina local.
[NOVA]: También hay casos donde no valdría la pena. Si la tarea es una automatización local simple, una habilidad normal de OpenClaw probablemente es más fácil de inspeccionar y operar. Si la tarea necesita una llamada de herramienta y una respuesta, agregar un segundo framework de orquestación puede crear más serialización, más logs, más dependencias, y más modos de falla que valor. La integración debe estar justificada por orquestación, código existente, infraestructura de agente hospedado, o un requisito concreto del ecosistema de Microsoft.
[ALLOY]: El control de versiones es otra consideración real. OpenClaw, el framework externo, los SDKs de modelos y los esquemas de herramientas pueden evolucionar independientemente. Un puente debe declarar la versión del framework que espera, validar las formas de eventos devueltos, y fallar claramente cuando un contrato de conexión cambia. La compatibilidad parcial silenciosa es peligrosa porque puede hacer que un agente parezca funcionar mientras pierde estado de tareas, salida de herramientas, ordenamiento de secuencias o eventos de razonamiento.
[NOVA]: La forma recomendada es aburrida a propósito: un adaptador, un esquema, un perfil de permisos, un ID de correlación, una política de tiempo de espera, y una salida claramente documentada. Empieza ahí. Si eso funciona, agrega capacidades lentamente. El objetivo no es hacer que OpenClaw y Microsoft Agent Framework sean indistinguibles. El objetivo es permitir que OpenClaw llame de forma segura a un runtime de agente externo útil cuando ese runtime gana su lugar.
[ALLOY]: La conclusión práctica del EP048 es operativa. Codex 0.130.0 hace que las sesiones de agente de codificación sean más similares a servicios con servidores de aplicación de control remoto, vistas de hilos paginadas, visibilidad de hooks de plugins, actualización de configuración, mejores diffs de parches, correcciones de compactación y resolución de archivos multi-entorno.
[NOVA]: La investigación de Semantic Kernel de Microsoft muestra cómo los argumentos de herramientas controlados por modelos pueden convertirse en ejecución de código si los frameworks los convierten en expresiones de lenguaje host interpretadas. GitHub Copilot SDK da a los productos embebidos hooks de aprobación y recuperación más diagnósticos. Microsoft Agent Framework 1.5 impulsa la orquestación, política de navegador, observabilidad, transporte de eventos, estado de tareas y corrección del formato de conexión hacia adelante.
[ALLOY]: Y sobre la pregunta de OpenClaw: Microsoft Agent Framework es utilizable dentro de OpenClaw como un runtime externo delimitado, servicio, habilidad o puente de herramientas. No debe evadir el propio modelo de confianza, enrutamiento, sandbox y aprobación de OpenClaw.
[NOVA]: Para los constructores, haz que cada límite de runtime de agente sea explícito: plano de control, entrada de herramientas, evento de aprobación, política de navegador, telemetría, puente de framework y estado de hilo almacenado. Gracias por escuchar OpenClaw Daily. Las notas del programa y los enlaces de origen están disponibles en Toby On Fitness Tech punto com, y volveremos pronto.