Antecedentes y definición del problema
"A Programming Paradigm for Spatiotemporal Composability" está co-firmado por Yifan Shi, Wei Zhang (Universidad de Pekín) y Tianyi Cui (DeepSeek-AI, es decir, el autor del framework Koishi, Shigma). Es un artículo de teoría de lenguajes de programación y sistemas en tiempo de ejecución, no un artículo sobre entrenamiento o capacidades de modelos.
Agent = Model + Harness
[Conclusión original del artículo §1.2.2] El artículo toma el Agent Runtime como uno de sus ejemplos motivadores: los agentes de IA modernos dependen de runtime agent harnesses, sistemas que ensamblan conjuntos de herramientas, entornos de ejecución, sandboxes de permisos, estado de sesión, memoria de contexto, flujos de trabajo de sub-agentes y UI; "es posible que los harnesses futuros generen y desplieguen modificaciones a sus propios componentes mientras siguen sirviendo solicitudes".
Esta definición coincide exactamente con la descripción oficial de DeepSeek sobre Harness: Agent = Model + Harness. El Model se encarga del razonamiento y la toma de decisiones; el Harness ofrece Tools / Skills / Sessions / Sandboxes / Storage / Loops / Sub-agent scheduling / UI mediante plugins. DeepSeek Harness convierte todos estos dominios de capacidad en plugins de Cordis.
¿Por qué un Agente de larga duración y auto-modificable necesita cargar, descargar y reemplazar componentes dinámicamente? Porque el rasgo definitorio de un Agente auto-evolutivo es "modificarse a sí mismo mientras se ejecuta": actualizar una herramienta, reemplazar un Skill, ajustar el entorno de un sub-Agente. Si cada modificación obliga a reiniciar toda la sesión, se pierden contexto y estado intermedio; si no se reinicia, los efectos secundarios del componente antiguo (conexiones abiertas, callbacks registrados, estado retenido) se convierten en basura colgada que contamina la ejecución subsiguiente. Los mecanismos tradicionales no responden a "cómo reemplazar limpiamente un componente que aún está en uso".
Por qué los sistemas de plugins, DI y HMR tradicionales no bastan
El artículo §1.2.1 toma VSCode como ejemplo canónico:
- Temporal limitation: el extension host de VSCode no ofrece mecanismo para descargar el código de una extensión concreta en tiempo de ejecución; deshabilitar o desinstalar una extensión exige reiniciar todo el host. 87 de las 100 extensiones más populares contienen código ejecutable y todas requieren reinicio. El hook
deactivatesolo se usa como callback de salida elegante al cierre del proceso, y separa el effect disposal del effect creation (enactivate), violando la locality of concern. - Spatial limitation:
extensionDependenciescasi no se usa (solo 7 de las 100 principales lo declaran); no hay contrato estructural entre extensiones, ygetExtension(...).exportsdevuelve un valor de tipoany.
[Inferencia basada en el artículo] La DI tradicional (p. ej. Spring, Angular) solo inyecta dependencias en la inicialización; cuando un provider se reemplaza o elimina en tiempo de ejecución, los dependent existentes no se desactivan ni se reinicializan. El useEffect de React empareja effect con cleanup, pero los hooks no pueden llamarse dentro de condiciones/bucles/funciones anidadas, el cuerpo del effect no admite funciones async ni iteradores, y no se puede componer un inverse compuesto a partir de efectos existentes. El HMR (webpack, Vite) migra estado hacia adelante mediante import.meta.hot, dependiendo de que los desarrolladores escriban a mano las funciones de migración. La memoria transaccional por software (STM) y RAII limitan la reversal a un ámbito estático fijo. OSGi Declarative Services reacciona a la disponibilidad del servicio, pero el callback de deactivation se escribe a mano y es sincrónico.
[Conclusión original del artículo §1.2.3] Los sistemas operativos ofrecen temporal composability a granularity de proceso; los orquestadores de contenedores ofrecen spatial composability a granularity de servicio, pero son sustitutos de grano grueso: cada reinicio descarta todo el estado local del proceso (cachés, conexiones, cómputos parciales), y la reconstrucción lleva de segundos a minutos; la orquestación a nivel de contenedor no puede expresar dependencias entre componentes que comparten un mismo espacio de direcciones. El artículo demanda una abstracción de composición al mismo grano que los propios componentes.
Dos dimensiones ortogonales
[Conclusión original del artículo §1.1] El artículo identifica dos dimensiones ortogonales de la composición dinámica:
- Temporal composability (dimensión temporal): cuando se elimina un componente, toda modificación que haya hecho al entorno compartido debe revertirse completa y seguramente. Esto exige rastrear cada asignación de recurso, registro de evento y cambio de estado que el componente ejecutó, y garantizar su recuperación ordenada.
- Spatial composability (dimensión espacial): los componentes deben poder declarar, descubrir y resolver dependencias entre sí de forma estructural y verificable. Esto exige gestionar la topología de dependencias y coordinar los ciclos de vida de los componentes cuando cambian las dependencias.
[Conclusión original del artículo §2.3] Effect describe "cómo un cómputo modifica el entorno", y Coeffect describe "cómo un cómputo depende del entorno" — las dos direcciones son complementarias, no las confunda. En el escenario estático, temporal se reduce al ámbito léxico (RAII, bracket pattern) y spatial a la resolución de importación de módulos; en el escenario dinámico, ambos resultan notablemente más difíciles.
La solución del artículo: elevar el effect/coeffect clásico del análisis estático en tiempo de compilación a mecanismos en tiempo de ejecución — Revertible Effects (cada transformación de contexto lleva un inverse, rastreado en tiempo de ejecución) resuelve temporal; Reactive Coeffects (los componentes declaran especificaciones de coeffect; el contexto les notifica según la especificación cuando cambia) resuelve spatial. Ambos se unifican en un único tipo de contexto, constituyen el concepto de componente, y dan lugar a un cálculo de composición dinámica con propiedades metateóricas probadas.
Mapa de conceptos centrales
| Concepto | Significado | Fuente |
|---|---|---|
| Revertible Effect | Cada transformación de contexto lleva un inverse, rastreado en tiempo de ejecución | §3.1, Def 8 |
| Reactive Coeffect | Los componentes declaran especificaciones de coeffect; el contexto notifica según la especificación al cambiar | §3.2.2, Def 26 |
| Unified Context Γ∞ | Un único tipo de contexto que lleva recursivamente (estado, acumulador, tabla de coeffect) | §3.3.1, Def 32 |
| Component ℭΓ | Triple (spec de dependencia d, provisión p, función witness de effect e) | §4.1, Def 43 |
| Fiber | Una instanciación de un componente, que porta el estado del ciclo de vida | §4.1, Def 44 |
| Committed View ω | La resolución de dependencias actualmente comprometida (mapeo de nombres de fiber) | §4.1, Def 44 |
| Target View | El estado de resolución de dependencias en el que el fiber debería estar | §4.2, Def 46 |
| Isolation Realm | La misma key se resuelve a instancias distintas en contextos distintos | §3.2.3, Def 28 |
| Interception | No reemplazar la dependencia, solo modificar cómo se usa | §3.2.3, Def 30 |
Los capítulos siguientes siguen esta línea: Effects cubre cómo se revierte temporal; Coeffects cubre cómo responde spatial; Ciclo de vida cubre cómo ambos se coordinan sobre una instancia de componente; Teoremas cubre qué garantiza este mecanismo; DeepSeek Harness cubre cómo aterriza en un Agent Runtime real; Límites cubre qué no garantiza.