- Framework Python de código abierto con dependencias mínimas: solo la librería cliente de OpenAI. Sin overhead de abstracciones complejas.
- Su primitiva central es el handoff: cualquier agente puede transferir el control a otro especialista devolviendo un objeto Agent desde una función.
- Compatible con cualquier API OpenAI-compatible: modelos locales con Ollama, LM Studio, o cualquier servicio que exponga el endpoint
/v1/chat/completions. - Las variables de contexto son un diccionario Python simple que viaja entre agentes sin necesidad de configuración adicional.
- Diseñado con propósito educativo: la base de código completa es lo suficientemente pequeña para leerla en una tarde y entender cómo funcionan los sistemas multi-agente.
¿Qué es OpenSwarm y de dónde viene?
OpenSwarm es una implementación de código abierto del paradigma de enjambre para sistemas multi-agente. Su origen está en el experimento Swarm que OpenAI publicó como proyecto educativo: una abstracción deliberadamente simple para demostrar cómo varios agentes pueden coordinarse transfiriéndose el control entre sí sin un orquestador central. OpenSwarm toma esa idea, la hace completamente independiente de OpenAI como empresa y la extiende con soporte para cualquier API compatible.
La filosofía de diseño es la opuesta a la de frameworks como LangChain o CrewAI. Donde estos ofrecen cientos de abstracciones, integraciones y configuraciones, OpenSwarm ofrece tres conceptos: agentes, handoffs y variables de contexto. Eso es todo. El objetivo no es ser el framework de producción más completo, sino el más fácil de entender para alguien que quiere aprender cómo funcionan los sistemas multi-agente desde dentro.
En la práctica, OpenSwarm es la herramienta correcta cuando tienes un caso de uso que se describe naturalmente como una red de especialistas que se pasan la conversación entre sí: un agente de triaje que redirige al cliente al departamento adecuado, un asistente que escala a un supervisor cuando no puede resolver algo, o un pipeline de análisis donde cada paso es un agente con un enfoque diferente. Para explorar el ecosistema completo de opciones, consulta la sección de comparativas.
Conceptos clave: agentes, handoffs y variables de contexto
OpenSwarm reduce la orquestación multi-agente a tres primitivas. Entender estas tres piezas es suficiente para construir sistemas complejos de delegación dinámica.
name (identificador legible), instructions (el system prompt
que define el comportamiento y la especialización) y functions (la lista
de herramientas y funciones de handoff disponibles). No hay roles, backstories ni
configuraciones YAML: la instrucción del agente es texto libre. El modelo LLM se
configura a nivel de cliente, no de agente.
Agent en lugar de un
string. Cuando el LLM decide invocar esa función, OpenSwarm interpreta el resultado
como una orden de transferencia: detiene el bucle del agente actual, activa el agente
devuelto y reinicia la ejecución desde el mismo historial de conversación. El agente
receptor tiene acceso completo a todo lo hablado hasta ese momento y a las variables
de contexto acumuladas.
context_variables)
que se pasa a cada llamada del cliente y que cualquier función puede leer y modificar.
Son el mecanismo para compartir estado entre agentes sin usar el historial de
mensajes: datos del usuario, resultados de consultas, preferencias detectadas, flags
de sesión. Los cambios que una función hace al diccionario persisten para el resto
de la sesión.
OpenSwarm ejecuta un bucle agéntico simple hasta que el agente activo devuelve una respuesta de texto sin invocar más funciones:
- El cliente llama a
swarm.run(agent, messages, context_variables). - El agente activo recibe el historial completo y genera una respuesta con posibles tool calls.
- Si una tool call devuelve un objeto Agent, OpenSwarm activa ese agente como el nuevo agente activo.
- Si una tool call devuelve un string o Result, el resultado se añade al historial y el ciclo continúa con el mismo agente.
- Cuando el agente activo responde con texto sin invocar funciones, el bucle termina y se devuelve la
Responsefinal.
¿Cómo instalar OpenSwarm y configurarlo?
OpenSwarm requiere Python 3.10 o superior. Su única dependencia directa es la librería oficial de OpenAI, que proporciona el cliente HTTP y el manejo de tool calls. La instalación es directa desde PyPI o desde el repositorio de GitHub para obtener la versión más reciente:
# Desde PyPI
pip install openswarm
# Desde el repositorio (version de desarrollo)
pip install git+https://github.com/openswarm/openswarm.git
# Verificar la instalacion
python -c "from swarm import Swarm, Agent; print('OpenSwarm listo')"
Configuración del cliente y del modelo
El cliente de OpenSwarm envuelve al cliente de OpenAI, por lo que acepta los mismos parámetros de configuración. Para usar modelos locales con Ollama, basta con apuntar la URL base al servidor local:
from swarm import Swarm, Agent
from openai import OpenAI
# --- Usando la API de OpenAI ---
# OPENAI_API_KEY debe estar en el entorno o pasarse explicitamente
cliente_openai = Swarm() # Usa OpenAI por defecto
# --- Usando Ollama (modelos locales, sin coste de API) ---
cliente_ollama = Swarm(
client=OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # Ollama no valida la clave, pero el campo es obligatorio
)
)
# --- Primer agente: el mas simple posible ---
agente_saludo = Agent(
name="Asistente",
instructions="Eres un asistente util. Responde siempre en espanol y de forma concisa.",
)
# --- Ejecutar una conversacion de una vuelta ---
respuesta = cliente_ollama.run(
agent=agente_saludo,
messages=[{"role": "user", "content": "Hola, explica que es un agente IA en dos frases."}],
model_override="llama3.1:8b", # Modelo de Ollama a usar
)
print(respuesta.messages[-1]["content"])
# El campo messages contiene todo el historial, incluyendo la respuesta del agente
La clase Result para handoffs con contexto
Además de devolver un agente directamente, las funciones pueden devolver un objeto
Result que combina el agente destino con un valor de retorno visible en
el historial y actualizaciones al diccionario de contexto:
from swarm import Swarm, Agent, Result
agente_ventas = Agent(
name="Equipo de ventas",
instructions="Eres un especialista en ventas. Ayuda al cliente a encontrar el producto adecuado.",
)
agente_soporte = Agent(
name="Soporte tecnico",
instructions="Eres un tecnico de soporte. Resuelve incidencias tecnicas con paciencia y precision.",
)
def transferir_a_ventas(context_variables: dict) -> Result:
"""Transfiere la conversacion al equipo de ventas cuando el usuario quiere comprar."""
return Result(
value="Conectando con el equipo de ventas...",
agent=agente_ventas,
context_variables={"departamento": "ventas", **context_variables},
)
def transferir_a_soporte(context_variables: dict) -> Result:
"""Transfiere la conversacion al soporte tecnico cuando hay un problema con un producto."""
return Result(
value="Conectando con soporte tecnico...",
agent=agente_soporte,
context_variables={"departamento": "soporte", **context_variables},
)
agente_triaje = Agent(
name="Recepcionista",
instructions=(
"Eres la recepcion de una tienda online. Tu trabajo es determinar la necesidad "
"del usuario y dirigirlo al departamento correcto. "
"Si el usuario quiere comprar o consultar precios, usa transferir_a_ventas. "
"Si el usuario tiene un problema tecnico o quiere devolver un producto, usa transferir_a_soporte. "
"Si la intencion no esta clara, pide mas informacion antes de transferir."
),
functions=[transferir_a_ventas, transferir_a_soporte],
)
cliente = Swarm()
respuesta = cliente.run(
agent=agente_triaje,
messages=[{"role": "user", "content": "Tengo un problema con mi pedido, el articulo llego roto."}],
)
# El agente activo al final sera agente_soporte, no agente_triaje
print(f"Agente final: {respuesta.agent.name}")
print(respuesta.messages[-1]["content"])
Patrones de handoff: triage, especialista y escalado
La mayoría de los sistemas construidos con OpenSwarm siguen uno de estos tres patrones o una combinación de ellos. Reconocerlos acelera el diseño de nuevas arquitecturas.
Patrón de triage
Un agente receptor analiza la intención del usuario y lo redirige al especialista adecuado. El agente de triage no resuelve ningún problema por sí mismo: su única función es clasificar y transferir. Es el patrón más común en bots de atención al cliente: un agente inicial que detecta si la solicitud es de ventas, soporte, facturación o información general y activa el agente correspondiente.
La clave para implementarlo bien es que las instrucciones del agente de triage sean muy específicas sobre los criterios de clasificación, y que cada función de handoff tenga un docstring claro que el LLM pueda usar para decidir cuándo invocarla.
Patrón de especialistas en cadena
Varios agentes especialistas se pasan la conversación en secuencia, cada uno añadiendo su capa de procesamiento. El primero recopila información, el segundo la analiza, el tercero redacta la respuesta. Este patrón es similar al proceso secuencial de CrewAI pero implementado como handoffs en lugar de tareas predefinidas: el flujo lo decide el propio LLM en tiempo de ejecución, no el código del desarrollador.
Es más flexible que el proceso secuencial de CrewAI (el agente puede decidir saltar un paso si no es necesario) pero también menos predecible, lo que lo hace más apropiado para prototipos que para producción.
Patrón de escalado jerárquico
Los agentes de primera línea resuelven solicitudes simples y escalan las complejas a agentes con mayor capacidad o acceso a más herramientas. El escalado puede ser unidireccional (el agente junior siempre transfiere al senior) o bidireccional (el senior puede devolver el control al junior una vez resuelta la parte compleja).
El escalado bidireccional requiere cuidado para evitar bucles de transferencia infinitos. La práctica recomendada es usar las variables de contexto para registrar cuántas transferencias se han producido y limitar el escalado si se supera un umbral.
Bot de atención al cliente con handoff completo
El siguiente ejemplo implementa un sistema de atención al cliente con tres agentes: un recepcionista que clasifica, un especialista en ventas y un técnico de soporte. Incluye variables de contexto y manejo del historial multi-vuelta.
"""
Bot de atencion al cliente con OpenSwarm.
Tres agentes: triaje, ventas y soporte tecnico.
Compatible con Ollama (local) y la API de OpenAI.
"""
from swarm import Swarm, Agent, Result
from openai import OpenAI
# ─── CONFIGURACION DEL CLIENTE ───────────────────────────────────────────────
# Para Ollama: sustituye por tu servidor local si es distinto
cliente = Swarm(
client=OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama",
)
)
MODELO = "llama3.1:8b"
# ─── AGENTES ESPECIALISTAS ───────────────────────────────────────────────────
agente_ventas = Agent(
name="Especialista en ventas",
instructions="""
Eres el especialista en ventas de TiendaDemo, una tienda online de electronica.
Tu objetivo es ayudar al cliente a encontrar el producto que mejor se adapta
a sus necesidades y presupuesto. Sé amable, proporciona especificaciones tecnicas
cuando se pidan y sugiere alternativas si el producto solicitado no esta disponible.
Si el cliente tiene un problema con un pedido ya realizado, transfierelo a soporte.
""",
functions=[], # Se rellenara tras definir transferir_a_soporte
)
agente_soporte = Agent(
name="Tecnico de soporte",
instructions="""
Eres el tecnico de soporte de TiendaDemo. Tu trabajo es resolver incidencias
con pedidos, devoluciones, productos defectuosos y problemas de envio.
Sé empatico con el cliente, documenta el problema con precision y proporciona
un numero de ticket de soporte al final de cada interaccion. Si el cliente
quiere hacer una compra nueva, transfierelo al equipo de ventas.
""",
functions=[], # Se rellenara tras definir transferir_a_ventas
)
# ─── FUNCIONES DE HANDOFF ─────────────────────────────────────────────────────
def transferir_a_ventas(context_variables: dict) -> Result:
"""
Transfiere al cliente al equipo de ventas.
Usa esta funcion cuando el usuario quiere comprar, consultar precios
o conocer disponibilidad de productos.
"""
nombre = context_variables.get("nombre_cliente", "el cliente")
return Result(
value=f"Transfiriendo a {nombre} al equipo de ventas. Un momento.",
agent=agente_ventas,
context_variables={**context_variables, "ultimo_departamento": "ventas"},
)
def transferir_a_soporte(context_variables: dict) -> Result:
"""
Transfiere al cliente al soporte tecnico.
Usa esta funcion cuando el usuario tiene un problema con un pedido,
quiere hacer una devolucion o reporta un producto defectuoso.
"""
nombre = context_variables.get("nombre_cliente", "el cliente")
return Result(
value=f"Transfiriendo a {nombre} al soporte tecnico. Un momento.",
agent=agente_soporte,
context_variables={**context_variables, "ultimo_departamento": "soporte"},
)
# Asignar las funciones de transferencia cruzada
agente_ventas.functions = [transferir_a_soporte]
agente_soporte.functions = [transferir_a_ventas]
# ─── AGENTE DE TRIAJE ─────────────────────────────────────────────────────────
def registrar_nombre(nombre: str, context_variables: dict) -> Result:
"""
Registra el nombre del cliente para personalizar la conversacion.
Usa esta funcion cuando el cliente se presente o diga su nombre.
"""
return Result(
value=f"Encantado, {nombre}. En que puedo ayudarte hoy?",
context_variables={**context_variables, "nombre_cliente": nombre},
)
agente_triaje = Agent(
name="Recepcion",
instructions="""
Eres la recepcion virtual de TiendaDemo. Bienvenida al cliente, identifica
su necesidad y dirigelo al departamento correcto.
Reglas de triaje:
- Si el cliente quiere comprar, consultar precios o disponibilidad → transferir_a_ventas
- Si hay un problema con pedido, devolucion o producto defectuoso → transferir_a_soporte
- Si el cliente se presenta con su nombre → registrar_nombre
- Si la intencion no esta clara → pide mas informacion antes de transferir
Siempre saluda al cliente al inicio si no lo has hecho aun.
""",
functions=[registrar_nombre, transferir_a_ventas, transferir_a_soporte],
)
# ─── BUCLE DE CONVERSACION MULTI-VUELTA ──────────────────────────────────────
def main():
historial = []
agente_activo = agente_triaje
contexto = {}
print("=== Bot de atencion al cliente (OpenSwarm) ===")
print("Escribe 'salir' para terminar la conversacion.\n")
while True:
entrada = input("Usuario: ").strip()
if entrada.lower() in ("salir", "exit", "quit"):
print("Hasta pronto.")
break
historial.append({"role": "user", "content": entrada})
respuesta = cliente.run(
agent=agente_activo,
messages=historial,
context_variables=contexto,
model_override=MODELO,
)
# Actualizar estado para la siguiente vuelta
agente_activo = respuesta.agent
historial = respuesta.messages
contexto = respuesta.context_variables
# Mostrar el ultimo mensaje del agente
ultimo_mensaje = next(
(m for m in reversed(respuesta.messages) if m["role"] == "assistant"),
None,
)
if ultimo_mensaje:
print(f"\n{agente_activo.name}: {ultimo_mensaje['content']}\n")
if __name__ == "__main__":
main()
Para ejecutarlo con Ollama local, asegúrate de tener el modelo descargado:
ollama pull llama3.1:8b. Luego ejecuta python atencion_cliente.py.
Para usar la API de OpenAI, sustituye la configuración del cliente por
Swarm() y elimina el model_override (usará GPT-5 por defecto).
El repositorio oficial de
OpenSwarm en GitHub
incluye ejemplos adicionales de weather bot, airline service y soporte de reservas.
OpenSwarm vs CrewAI vs LangChain vs Pydantic AI
Cuatro frameworks con filosofías distintas. La tabla resume los criterios más relevantes para elegir el correcto según el caso de uso.
| Criterio | OpenSwarm | CrewAI | LangChain | Pydantic AI |
|---|---|---|---|---|
| Curva de aprendizaje | Muy baja — 3 conceptos | Baja — API intuitiva | Alta — centenares de abstracciones | Media — requiere conocer Pydantic |
| Paradigma principal | Handoff dinámico entre agentes | Equipos con roles definidos | Cadenas y grafos de razonamiento | Agentes con salida tipada y validada |
| Dependencias | Solo openai | crewai + litellm + pydantic | langchain-core + decenas de extras | pydantic + openai o anthropic |
| Compatibilidad LLM | Cualquier API OpenAI-compatible | Cualquier proveedor via LiteLLM | Cualquier proveedor via LangChain | OpenAI, Anthropic, Gemini, Ollama |
| Herramientas integradas | Ninguna — todo manual | Ecosistema crewai-tools amplio | Más de 600 integraciones | Manual con decoradores |
| Validación de salida | No — texto libre | Básica via expected_output | Via output parsers | Nativa con modelos Pydantic |
| Observabilidad | Logs básicos en modo debug | CrewAI+ para trazas completas | LangSmith (plataforma propia) | Logfire (plataforma de Pydantic) |
| Proposito principal | Aprendizaje y prototipado rápido | Producción con equipos de agentes | Producción con flujos complejos | Producción con tipos de datos estrictos |
| GitHub stars (mayo 2026) | ~7k | ~25k | ~95k | ~8k |
¿Cuándo usar OpenSwarm y cuándo no?
OpenSwarm no es el framework correcto para todos los casos. Identificar sus límites es tan importante como conocer sus fortalezas.
- Estás aprendiendo cómo funcionan los sistemas multi-agente y quieres entender los mecanismos internos sin capas de abstracción.
- Necesitas prototipar rápidamente un sistema de handoffs para validar el concepto antes de invertir tiempo en un framework más completo.
- Tu caso de uso es un bot de routing: detectar la intención y transferir a distintos especialistas es exactamente para lo que OpenSwarm está diseñado.
- Quieres zero dependencias extra: si ya usas el cliente de OpenAI, añadir OpenSwarm no modifica tu entorno.
- Necesitas compatibilidad con modelos locales vía Ollama sin configuración adicional.
- Necesitas herramientas integradas como búsqueda web, lectura de PDFs o consultas a bases de datos: CrewAI con crewai-tools será más productivo.
- El proyecto requiere validación estricta de entradas y salidas de agentes: Pydantic AI ofrece garantías de tipos que OpenSwarm no proporciona.
- Necesitas observabilidad en producción: sin trazas, métricas de coste ni dashboards, depurar problemas en sistemas complejos es difícil.
- El flujo es no lineal con ciclos y bifurcaciones complejas: LangGraph está construido específicamente para grafos de estado que OpenSwarm no puede modelar.
- El proyecto tiene un equipo y requisitos de mantenimiento a largo plazo: la falta de ecosistema de OpenSwarm aumenta la deuda técnica con el tiempo.
| Ventaja | Limitación |
|---|---|
| Base de código mínima, fácil de leer y entender al completo | Sin herramientas integradas: cada tool hay que implementarla manualmente |
| Instalación en segundos, sin conflictos de dependencias | Sin observabilidad ni trazas de ejecución integradas |
| Handoffs nativos sin configuración: la primitiva más natural para routing | Sin persistencia de memoria entre sesiones distintas |
| Compatible con cualquier API OpenAI-compatible, incluido Ollama | Sin soporte oficial para Anthropic Claude o Google Gemini de forma directa |
| Ideal para enseñar y demostrar patrones multi-agente en talleres | Ecosistema de comunidad pequeño en comparación con LangChain o CrewAI |
| Paralelismo de agentes posible con asyncio sin modificar el framework | Sin gestión automática de errores ni reintentos entre agentes |
Preguntas frecuentes sobre OpenSwarm
¿Qué es OpenSwarm y en qué se diferencia de otros frameworks?
OpenSwarm es un framework Python de código abierto para construir sistemas multi-agente basado en el paradigma de enjambre. Su característica principal es el handoff: un agente puede transferir dinámicamente el control a otro agente especializado según el contexto de la conversación, sin necesitar un orquestador central. A diferencia de CrewAI, donde los roles y el flujo se definen de antemano, en OpenSwarm el LLM decide en tiempo de ejecución a quién pasar el control. Esto lo hace más flexible pero también menos predecible, lo que lo convierte en una herramienta mejor para prototipos que para producción a gran escala.
¿OpenSwarm es gratuito?
Sí, OpenSwarm es completamente gratuito y de código abierto. No tiene versión enterprise ni costes de licencia. El único coste asociado es el del proveedor LLM: si usas Ollama con modelos locales, el coste es cero. Si usas la API de OpenAI, Anthropic u otros, pagas por los tokens consumidos por tus agentes. La propia base de código de OpenSwarm no añade ningún coste.
¿Con qué modelos LLM es compatible OpenSwarm?
OpenSwarm funciona con cualquier API compatible con el formato de OpenAI. Esto incluye:
OpenAI (GPT-5, GPT-4.1 nano, o3-mini), modelos locales a través de
Ollama (Llama 3.1, Mistral, Qwen 2.5, Gemma),
LM Studio, y cualquier servicio que exponga el endpoint /v1/chat/completions
con el formato de mensajes de OpenAI. Para usar Anthropic Claude de forma directa se
necesita un proxy intermedio, aunque la mayoría de desarrolladores que prefieren Claude
optan por usar OpenSwarm con un provider compatible o migran a CrewAI que soporta
Anthropic de forma nativa.
¿Qué es un handoff en OpenSwarm?
Un handoff es la transferencia de control de un agente a otro dentro del mismo sistema. Cuando el agente activo determina que una solicitud supera su especialización, invoca una función especial que devuelve el agente destino. OpenSwarm interrumpe el bucle del agente actual y reinicia la ejecución desde el agente receptor, pasando todo el historial de conversación y las variables de contexto acumuladas. El agente receptor no sabe que hubo un handoff previo (a menos que el historial lo indique): recibe la conversación completa como si hubiera estado presente desde el principio.
¿OpenSwarm es adecuado para producción?
OpenSwarm está pensado para aprender patrones multi-agente y prototipar rápidamente. Para cargas de producción con requisitos de observabilidad, gestión de errores robusta y escalado, frameworks como CrewAI, LangChain o Pydantic AI ofrecen ecosistemas más maduros. Dicho esto, OpenSwarm puede usarse en producción para sistemas sencillos de routing donde la simplicidad es una ventaja: menos dependencias significa menos vectores de fallo. La recomendación práctica es: prototipa con OpenSwarm, valida el concepto, y si el sistema crece en complejidad, migra a un framework con más soporte operacional.
¿Cómo se comparan las variables de contexto de OpenSwarm con la memoria de CrewAI?
Las variables de contexto de OpenSwarm son un diccionario Python simple que se pasa
entre agentes durante la sesión. Son eficaces pero no persisten entre sesiones distintas:
cada nueva llamada a swarm.run() parte de un diccionario limpio a menos que
tu código lo gestione explícitamente. La memoria de CrewAI es una abstracción más
sofisticada con tres capas: memoria de corto plazo (dentro de la ejecución), memoria
de largo plazo (persistente entre ejecuciones vía base de datos) y memoria de entidad
(sobre objetos específicos como clientes o productos). Para prototipos, el diccionario
de contexto de OpenSwarm es más que suficiente; para sistemas con memoria real entre
sesiones, usa CrewAI o implementa tu propia capa de persistencia.
¿Listo para un framework multi-agente de producción?
Si OpenSwarm te ha ayudado a entender los handoffs y quieres llevar tus agentes a producción con roles estructurados, herramientas integradas y observabilidad, CrewAI es el siguiente paso natural.
Ver guía completa de CrewAICrea tu primer agente de IA, paso a paso
Descarga la guía en PDF: 12 secciones, ejemplos reales y datos de 2026. Gratis.
Usamos analítica propia y anónima para mejorar la web. No usamos cookies de seguimiento ni vendemos tus datos. Más información en la política de cookies.