Agentes de IA open source: cuál elegir como base
Elegir un agente de IA open source se reduce a cuatro comprobaciones: una licencia que permita tu plan comercial, una arquitectura que puedas leer de verdad, mantenimiento reciente y no unipersonal, y una interfaz de herramientas ampliable sin hacer un fork. Las estrellas no responden a ninguna.
Qué te da realmente un proyecto de agentes
Un framework de agentes empaqueta cuatro cosas: un bucle que decide qué hacer a continuación, una forma de exponer herramientas al modelo, algún tipo de memoria o estado, y gestión de errores para cuando el modelo devuelve un disparate. El bucle es la parte fácil, y por eso existen tantos frameworks. Los meses de trabajo están en la interfaz de herramientas y en la gestión de errores.
Evalúa esas dos. Si ampliar las herramientas obliga a editar el código fuente del propio framework, no has adoptado una dependencia: has adoptado un fork.
Las cuatro comprobaciones que importan
| Comprobación | Qué buscar | Señal de alarma |
|---|---|---|
| Licencia | MIT, Apache-2.0 o BSD si piensas vender | AGPL o licencia propia de tipo «source-available» |
| Arquitectura legible | Puedes seguir una petición de principio a fin en una hora | Capas de abstracción sin ningún ejemplo que las use |
| Mantenimiento | Commits de los últimos 90 días de más de una persona | Un único mantenedor heroico e issues sin respuesta durante meses |
| Extensibilidad | Las herramientas se registran desde fuera del paquete | Añadir una herramienta implica tocar archivos del framework |
Por qué las estrellas engañan
Las estrellas miden el momento en que se descubrió un proyecto, no si hoy es un cimiento sólido. Un repositorio que fue tendencia hace año y medio puede llevar abandonado desde entonces; un proyecto con 400 estrellas y tres mantenedores activos suele ser mejor apuesta que uno con 40.000 y ninguno.
Las estrellas tampoco distinguen entre demostración y producto. Buena parte de los repositorios de agentes más estrellados se construyeron para ilustrar una idea, y sus autores lo dicen en el README si pasas del GIF animado.
Ajustar el proyecto a lo que vas a construir
- Herramienta interna: prioriza legibilidad y autoalojamiento sobre funcionalidades. Tú serás quien lo depure a las seis de la tarde.
- Producto: primero la licencia, después la extensibilidad. Un problema de licencia descubierto tras el lanzamiento sale más caro que cualquier otra cosa de esta lista.
- Prototipo para validar demanda: coge lo que te lleve antes a una demo y asume que lo vas a sustituir.
- Encima de un SaaS existente: mejor un proyecto con una capa de protocolo real como MCP que uno con integraciones cableadas a mano.
Acortar la búsqueda
Hacer estas comprobaciones en serio cuesta cerca de una hora por candidato, y por eso la mayoría las salta y luego lo lamenta. El catálogo de RepoLoot adelanta la parte estructural: qué hace el proyecto, qué problema resuelve, qué puedes construir con él, para quién es y cuánto cuesta implementarlo, con la identidad del repositorio revelada cuando ya has decidido.
Preguntas frecuentes
- ¿Cómo elijo un framework de agentes de IA open source?
- Comprueba cuatro cosas: una licencia compatible con tus planes comerciales, una arquitectura que puedas recorrer de principio a fin en aproximadamente una hora, actividad de mantenimiento en los últimos 90 días por parte de más de una persona, y la posibilidad de registrar herramientas nuevas desde fuera del paquete sin hacer un fork.
- ¿Son las estrellas de GitHub un buen criterio?
- No. Las estrellas registran cuándo se descubrió un proyecto, no si hoy está mantenido y es adecuado. Un proyecto con 400 estrellas y tres mantenedores activos suele ser mejor cimiento que uno con 40.000 y ninguno.
- ¿Qué licencia necesito si voy a vender mi producto?
- MIT, Apache-2.0 o BSD. Trata AGPL y las licencias propias de tipo «source-available» como una decisión que se toma con asesoría legal antes de construir, no después.