ByteDance libera DeerFlow 2.0, un agente con su propio ordenador y licencia MIT

ByteDance libera DeerFlow 2.0, un agente con su propio ordenador y licencia MIT
Fuente: github.com

ByteDance ha reescrito DeerFlow de cero y lo ha publicado bajo licencia MIT. La versión 2.0 deja de ser un framework de investigación y pasa a ser un runtime de agentes completo: cada agente arranca con su propio ordenador aislado, memoria que sobrevive entre sesiones y capacidad de delegar en subagentes. El repositorio marca 79.100 estrellas y 10.800 forks.

Puntos clave

  • Licencia MIT, uso comercial incluido, sin restricciones de las que llevan letra pequeña.
  • Sandbox por agente en local, Docker o Kubernetes, con sistema de ficheros propio en `/mnt/user-data/` (uploads, workspace y outputs).
  • Memoria persistente con DeerMem: perfiles y preferencias que aguantan entre sesiones.
  • Skills declaradas en Markdown con carga progresiva según el contexto de la tarea.
  • Se conecta a servidores MCP, funciones Python y herramientas internas de búsqueda web, ficheros y bash.

Qué cambia respecto a la versión anterior

DeerFlow 1.x era una herramienta de investigación profunda: le dabas una pregunta, hacía búsquedas y te devolvía un informe. Útil y estrecho.

La 2.0 cambia la unidad de trabajo. Ahora el agente tiene un entorno de ejecución propio donde puede escribir ficheros, ejecutar código y ordenar su trabajo. Eso convierte tareas que antes eran imposibles en tareas normales: descargar tres exports de tu ERP, cruzarlos con un script, generar un Excel y dejarlo en una carpeta de salida.

El detalle del aislamiento importa. Cada agente corre en su contenedor, así que un script que se va de madre no toca nada de tu máquina. Puedes montarlo en local para probar y en Kubernetes para producción sin cambiar el código.

Las skills en Markdown

Este es el patrón que más me interesa del diseño, porque es el mismo que uso yo a diario. Una skill es un fichero Markdown que describe qué hace, cuándo se usa y qué pasos sigue. El agente carga solo las que hacen falta para la tarea que tiene delante, en lugar de arrastrar todo el manual en cada petición.

Eso es lo que abarata el asunto de verdad. Si tienes 40 procedimientos documentados y el modelo tiene que leerlos todos cada vez, cada llamada cuesta un dineral y el modelo se pierde. Con carga progresiva lee el índice, decide cuál necesita y abre solo ese.

Llevo meses trabajando así en Barner y DigitalBrain, con skills en ficheros de texto que se invocan a demanda o por tarea programada. Es el motivo por el que no tengo agentes construidos en el sentido en el que se vende la palabra: las skills bien escritas dan casi toda la funcionalidad y son mucho más fáciles de depurar cuando algo falla.

Sobre qué está construido

DeerFlow 2.0 se apoya en LangGraph y LangChain, con una Gateway API unificada que expone el runtime. En desarrollo corre con un solo worker; en producción, con varios y Redis coordinando.

La configuración admite modelos de varios proveedores: OpenAI, Anthropic, Google, DeepSeek y QwQ a través de OpenRouter. La documentación recomienda Doubao-Seed-2.0-Code (el modelo de código de la propia ByteDance) y DeepSeek v3.2, que precisamente acaba de sacar una versión Flash que supera a su modelo grande en las nueve pruebas de agente que publicó la compañía.

Por qué importa

Que una empresa como ByteDance suelte esto con licencia MIT tiene una lectura comercial clara: quiere que su modelo de código sea el que se ejecute dentro. Es la jugada de siempre, regalar la infraestructura para vender el cómputo.

Para una empresa mediana la pregunta práctica es otra: ¿me sirve montar esto o me monto lo mío? Mi respuesta después de construir bastantes automatizaciones es que depende de si necesitas el sandbox. Si tus procesos son llamadas a APIs y transformaciones de datos, un script bien hecho con un modelo detrás te sobra y lo depuras en cinco minutos. Si necesitas que el agente ejecute código que no has escrito tú, con ficheros que no controlas, el aislamiento deja de ser un lujo.

Y hay un aviso que doy siempre: antes de montar el agente, coloca bien los datos. Un runtime excelente sobre datos sucios da resultados sucios más rápido. En Barner etiquetamos todo el catálogo en Odoo antes de meter nada de IA encima. Ese trabajo aburrido es el que decide si lo demás funciona.


Relacionado