Los agentes han transformado la manera en que concebimos el control de versiones, los sistemas de archivos y la persistencia del estado.Los desarrolladores y los agentes están generando más código que nunca —se escribirá más código en los próximos 5 años que en toda la historia de la programación— y esto ha impulsado un cambio de magnitud en la escala de los sistemas necesarios para satisfacer esta demanda. Las plataformas de control de versiones están teniendo dificultades en este punto: fueron diseñadas para satisfacer las necesidades de los humanos, no para afrontar un incremento de 10 veces en el volumen, impulsado por agentes que nunca duermen, pueden trabajar en varios problemas a la vez y nunca se cansan.
Creemos que se necesita una nueva primitiva: un sistema de archivos distribuido y versionado que esté diseñado ante todo para agentes, y que pueda servir a los tipos de aplicaciones que se están creando en la actualidad.
A esto lo llamamos Artifacts: un sistema de archivos con control de versiones integrado con Git. Puedes crear repositorios de forma programática, junto con tus agentes, sandboxes, Workers u otros paradigmas informáticos, y conectarte a ellos desde cualquier cliente Git estándar.
¿Quieres asignar un repositorio a cada sesión para agente?Artifacts puede hacerlo. ¿Cada instancia de sandbox? También Artifacts. ¿Quieres crear 10 000 bifurcaciones a partir de un punto de partida conocido? Adivinaste: Artifacts de nuevo. Artifacts expone una API REST y una API nativa de Workers para crear repositorios, generar credenciales y confirmaciones de cambios para entornos en los que un cliente Git no es la opción adecuada (por ejemplo, en cualquier función sin servidor).
Artifacts está disponible en versión beta privada para cualquier desarrollador del plan pago de Workers, y nuestro objetivo es abrirlo como versión beta pública a principios de mayo.
// Create a repo
const repo = await env.AGENT_REPOS.create(name)
// Pass back the token & remote to your agent
return { repo.remote, repo.token }
# Clone it and use it like any regular git remote
$ git clone https://x:${TOKEN}@123def456abc.artifacts.cloudflare.net/git/repo-13194.git
Eso es todo. Un repositorio vacío, listo para usar, creado al instante, con el que cualquier cliente Git puede operar.
Y si quieres inicializar un repositorio de Artifacts a partir de un repositorio Git existente, para que tu agente pueda trabajar en este de forma independiente y enviar cambios propios, también puedes hacerlo con .import():
interface Env {
ARTIFACTS: Artifacts
}
export default {
async fetch(request: Request, env: Env) {
// Import from GitHub
const { remote, token } = await env.ARTIFACTS.import({
source: {
url: "https://github.com/cloudflare/workers-sdk",
branch: "main",
},
target: {
name: "workers-sdk",
},
})
// Get a handle to the imported repo
const repo = await env.ARTIFACTS.get("workers-sdk")
// Fork to an isolated, read-only copy
const fork = await repo.fork("workers-sdk-review", {
readOnly: true,
})
return Response.json({ remote: fork.remote, token: fork.token })
},
}
Consulta la documentación para empezar, o si quieres entender cómo se utiliza Artifacts, cómo se creó y cómo funciona internamente: sigue leyendo.
¿Por qué Git? ¿Qué es un sistema de archivos versionado?
Los agentes conocen Git. Está profundamente integrado en los datos de entrenamiento de la mayoría de los modelos. Los agentes conocen bien tanto la ruta ideal como los casos límite, y los modelos de código optimizado (y/o arneses) son particularmente eficaces para usar git.
Además, el modelo de datos de Git no solo es útil para el control de versiones, sino también para cualquier escenario en el que necesites hacer un seguimiento de estado, retroceder en el tiempo y mantener grandes volúmenes de datos pequeños. Código, configuración, prompts de sesión e historial del agentes: todos estos son elementos ("objetos") que a menudo quieres almacenar en pequeños fragmentos ("commits") y poder revertir o retroceder ("historial").
Podríamos haber inventado un protocolo completamente nuevo y a medida... pero luego está el problema de la inicialización. Los modelos de IA no lo conocen, así que tienes que distribuir habilidades, o una CLI, o confiar en que los usuarios estén conectados con tu documentación MCP... todo eso agrega fricción.
¿Y si simplemente les damos a los agentes una URL remota de Git por HTTPS, autenticada y segura, para que trabajen como si fuera un repositorio Git?Eso funciona bastante bien. Y para los clientes que no usan Git — como Cloudflare Worker, una función Lambda o una aplicación Node.js, — hemos expuesto una API REST y (próximamente) SDK específicos del idioma. Esos clientes también pueden usar isomorphic-git, pero en muchos casos una API de TypeScript más simple puede reducir la superficie de API necesaria.
No solo para el control de versiones
La API de Git de Artifacts podría hacerte pensar que es solo para el control de versiones, pero en realidad la API y el modelo de datos de Git son una forma eficaz de mantener el estado, permitiendo bifurcar, retroceder en el tiempo y comparar estados para cualquier tipo de datos.
En Cloudflare, utilizamos Artifacts para nuestros agentes internos: se guarda automáticamente el estado actual del sistema de archivos y el historial de la sesión en un repositorio de Artifacts por sesión. Esto nos permite:
Mantener el estado del sandbox sin tener que asignar (ni mantener) almacenamiento en bloques.
Compartir sesiones con otros y permitir que retrocedan en el tiempo tanto en el estado de la sesión (prompt) y como en el estado de los archivos, independientemente de si hubo confirmaciones de cambios en el repositorio "real" (control de versiones).
Y lo mejor: bifurcar una sesión desde cualquier punto, lo que permite a nuestro equipo compartir sesiones con un compañero de trabajo y que este pueda retomarlas desde allí. ¿Estás depurando algo y quieres otra mirada?Envía una URL y haz una bifurcación. ¿Quieres probar una API? Pídele a un compañero de trabajo que la bifurque y continúa desde donde la dejaste.
También hemos hablado con equipos que quieren usar Artifacts en casos en los que el protocolo Git no es un requisito absoluto, pero sí lo son las operaciones semánticas (revertir, clonar, comparar) . ¿Guardas la configuración por cliente como parte de tu producto y quieres tener la posibilidad de revertirla? Artifacts puede ser una buena representación de esto.
Nos entusiasma que los equipos exploren con Artifacts tanto los usos que van más allá de Git como los que se centran directamente en Git.
Artifacts se crea sobre Durable Objects. La capacidad de crear millones (o decenas de millones) de instancias de cómputo con estado y aisladas es parte del funcionamiento actual de Durable Objects, y eso es exactamente lo que necesitábamos para admitir millones de repositorios Git por espacio de nombres.
Major League Baseball (para la distribución de partidos en directo), Confluence Whiteboards y nuestro propio Agents SDK utilizan Durable Objects a nivel interno y a gran escala; por eso estamos construyendo esto sobre una primitiva que ya usamos hace tiempo en producción.
Sin embargo, lo que sí necesitábamos era una implementación de Git que pudiera ejecutarse en Cloudflare Workers. Tenía que ser compacto, lo más completo posible, extensible (notas, LFS) y eficiente. Así que creamos uno en Zig y lo compilamos en Wasm.
¿Por qué usamos Zig? Tres razones:
Todo el motor del protocolo git está escrito íntegramente en Zig (sin libc) y compilado en un binario WASM de aproximadamente 100KB, con margen para optimización.Implementa SHA-1, compresión y descompresión zlib, codificación y decodificación delta, análisis de paquetes y todo el protocolo Git Smart — completamente, desde cero y sin dependencias externas más allá de la biblioteca estándar.
Zig nos brinda control manual sobre la asignación de memoria, lo que es importante en entornos restringidos como Durable Objects. El sistema de compilación de Zig nos permite compartir fácilmente código entre el entorno WASM (producción) y las compilaciones nativas (pruebas contra libgit2 y verificar la corrección).
El módulo WASM se comunica con el host JS mediante una interfaz ligera de devolución de llamadas: 11 funciones importadas por el host para operaciones de almacenamiento (host_get_object, host_put_object, etc.) y una para la transmisión de salida (host_emit_bytes). El componente WASM se puede probar completamente de forma aislada.
A nivel interno, Artifacts también utiliza R2 (para instantáneas) y KV (para el seguimiento de tokens de autenticación):
Cómo funciona Artifacts (Workers, Durable Objects y WebAssembly)
Un Worker actúa como front-end, gestionando la autenticación y la autorización, las métricas clave (errores, latencia) y localizando dinámicamente cada repositorio de Artifacts (Durable Objects).
En concreto:
Los archivos se almacenan en la base de datos SQLite del Durable Object subyacente.
El almacenamiento de Durable Object tiene un tamaño máximo de fila de 2 MB, por lo tanto, los objetos Git grandes se fragmentan y se guardan en varias filas.
Utilizamos la API síncrona de KV (state.storage.kv). que está respaldada por SQLite.
Los Durable Objects tienen un límite de memoria de aproximadamente 128 MB; esto significa que podemos generar decenas de millones de ellos (son rápidos y ligeros), pero debemos trabajar dentro de esas restricciones.
Hacemos un uso intensivo del streaming tanto en las rutas de extracción como de inserción, devolviendo directamente un `ReadableStream<Uint8Array>` creado a partir de los fragmentos de salida sin procesar de WASM.
Evitamos calcular nuestros propios deltas de Git; en su lugar, los deltas sin procesar y los hashes base se conservan junto al objeto resuelto. En una operación de extracción, si el cliente solicitante ya tiene el objeto base, Zig emite el delta en lugar del objeto completo, lo que ahorra ancho de banda y memoria.
Compatibilidad con las versiones v1 y v2 del protocolo Git.
Ofrecemos compatibilidad con capacidades como ls-refs, shallow clones (deepen, deepen-since, deepen-relative) y descarga incremental con negociación have/want.
Tenemos un amplio conjunto de pruebas, que incluye pruebas de conformidad frente a clientes Git y pruebas de verificación contra un servidor libgit2 diseñadas para validar la compatibilidad con el protocolo.
Además, contamos con soporte nativo para git-notes. Artifacts está diseñado con un enfoque centrado en los agentes, y las "notes" permiten que los agentes agreguen anotaciones (metadatos) a los objetos de Git.Esto incluye prompts, atribución de agentes y otros metadatos que se pueden leer/escribir desde el repositorio sin modificar los propios objetos.
¿Grandes repositorios, grandes problemas? Conoce ArtifactFS.
La mayoría de los repositorios no son tan grandes, y Git está diseñado para ser sumamente eficiente en términos de almacenamiento: la mayoría de los repositorios tardan solo unos segundos en clonarse, y ese tiempo está dominado por la configuración de red, la autenticación y la verificación mediante suma de comprobación. En la mayoría de los escenarios con agentes o entornos sandbox, esto resulta práctico: basta con clonar el repositorio al iniciar el sandbox y ponerse a trabajar.
Pero, ¿qué pasa con un repositorio y/o repositorios de varios GB que tienen millones de objetos? ¿Cómo podemos clonar ese repositorio rápidamente, sin impedir que el agente empiece a trabajar durante varios minutos ni agotar recursos de procesamiento?
Un marco web popular (de 2,4 GB y con un largo historial) tarda cerca de 2 minutos en clonarse. Un clon superficial acelera el proceso, pero no lo suficiente como para reducir los segundos a un solo dígito, y no siempre conviene omitir el historial (los agentes suelen necesitarlo).
¿Podemos reducir el tiempo de clonación de repositorios grandes a unos 10‑15 segundos, de modo que el agente pueda empezar a trabajar enseguida? En realidad sí, con algunos trucos.
Como parte del lanzamiento de Artifacts, vamos a ofrecer ArtifactFS de código abierto, un controlador de sistema de archivos diseñado para montar repositorios grandes de Git lo más rápido posible, cargando los contenidos de los archivos en tiempo real en lugar de bloquearse durante el clon inicial. Es ideal para agentes, entornos sandbox, contenedores y otros escenarios en los que la rapidez en el inicio marca la diferencia. Si logras reducir unos 90-100 segundos del tiempo de inicio de cada repositorio grande en tu sandbox, y ejecutas 10 000 de esos trabajos al mes, estarías ahorrando alrededor de 2778 horas de ejecución de sandbox.
Puedes imaginar ArtifactFS como "un clon de Git pero asíncrono":
ArtifactFS ejecuta una clonación sin blobs de un repositorio Git: obtiene la estructura de archivos y las referencias, pero no descarga los contenidos de los archivos.Puede realizar esa tarea durante el arranque del sandbox, lo que permite que el agente empiece a trabajar de inmediato.
En segundo plano comienza a cargar los contenidos de los archivos de manera concurrente, a través de un servicio ligero.
Prioriza los archivos que los agentes suelen necesitar primero: manifiestos de paquetes (package.json, go.mod), archivos de configuración y código. En lo posible, deja en segundo plano los blobs binarios (imágenes, ejecutables y otros archivos no textuales), de modo que los agentes puedan recorrer la estructura de archivos mientras los contenidos se van cargando.
Si un archivo no está completamente cargado cuando el agente intenta leerlo, la lectura se detiene hasta que el contenido esté disponible.
El sistema de archivos no intenta "sincronizar" los archivos de nuevo con el repositorio remoto: con miles o millones de objetos, eso suele ser muy lento, y tratándose de Git, no es necesario. Tu agente solo necesita confirmar y enviar, como lo haría con cualquier repositorio. No hay que aprender nuevas API.
Es importante destacar que ArtifactFS funciona con cualquier control remoto de Git, no solo con nuestros propios Artifacts. Si estás clonando grandes repositorios desde GitHub, GitLab o una infraestructura Git autoalojada, puedes seguir utilizando ArtifactFS.
¿Qué novedades están por llegar?
El lanzamiento de hoy es una versión beta, y ya estamos desarrollando varias funciones que irán llegando en las próximas semanas:
Estamos ampliando las métricas disponibles que ponemos a disposición. Hoy incorporamos métricas sobre operaciones clave por espacio de nombre, repositorio y bytes almacenados por repositorio, para que administrar millones de Artifacts no resulte una tarea pesada.
Compatibilidad con suscripciones a eventos a nivel de repositorio, para poder emitir notificaciones en inserciones, extracciones, clonaciones y bifurcaciones hacia cualquier repositorio dentro de un espacio de nombres. Esto también te permitirá consumir eventos, crear webhooks y aprovecharlos para notificar a los usuarios finales, impulsar eventos del ciclo de evolución dentro de tus productos y/o ejecutar tareas posteriores a una inserción (como procesos de CI/CD).
Los SDK nativos de cliente en TypeScript, Go y Python para interactuar con la API de Artifacts
API de búsqueda a nivel de repositorio y API de búsqueda en todo el espacio de nombres, p. ej., "buscar todos los repositorios con un archivo package.json".
También estamos planificando una API para Workers Builds, que permitirá ejecutar trabajos de CI/CD en cualquier flujo de trabajo impulsado por agentes.
Artifacts aún está en una etapa inicial, pero queremos que nuestro modelo de precios funcione a escala de agentes: debe ser rentable incluso con millones de repositorios, los repositorios sin uso (o con uso mínimo) no deberían representar una carga, y la tarifa debe reflejar la naturaleza altamente exclusiva de los agentes.
Tampoco deberías tener que preocuparte por si un repositorio va a usarse o no, si está activo o inactivo, o si un agente va a reactivarlo. Te cobraremos por el almacenamiento que consumas y por las operaciones realizadas (p. ej., clones, bifurcaciones, pushes y pulls) contra cada repositorio.
| $/unidad | Incluido |
|---|
Operaciones | USD 0,15 por 1000 operaciones | Primeras 10 mil incluidas (por mes) |
Almacenamiento | USD0 50/GB por mes | Primer 1 GB incluido. |
Los repositorios grandes y activos costarán más que los repositorios pequeños o de uso poco frecuente, ya sea que tengas 1000, 100 000 o 10 millones de ellos.
También incorporaremos Artifacts al plan gratuito de Workers (con límites razonables) a medida que avance la versión beta, y compartiremos actualizaciones durante todo el período de prueba en caso de que haya cambios en los precios, antes de facturar.
Artifacts se lanzará en versión beta privada, y esperamos que la versión beta pública esté lista a principios de mayo (de 2026, para ser precisos). Iremos incorporando clientes de forma progresiva durante las próximas semanas, y podrás inscribirte directamente para participar en la versión beta privada.
Mientras tanto, para obtener más información sobre Artifacts, puedes hacer lo siguiente:
Consulta el registro de cambios para seguir la evolución de la versión beta a medida que avanza.