¿Qué es Google ADK (Agent Development Kit)? Una guía práctica

Google ADK es un framework de código abierto para construir, evaluar y desplegar agentes de IA. Es la base de agentes reales en productos de Google como Agentspace. Si ya ha trabajado con plataformas como el SDK de agentes de OpenAI, ADK resuelve problemas similares, pero con integración directa con Gemini y Vertex AI. En esta guía verá qué es ADK, cómo crear agentes con herramientas, cómo componer sistemas multi-agente y cómo usar Apidog para probar las API que sus agentes terminan llamando.

Prueba Apidog hoy

Qué es Google ADK

ADK significa Agent Development Kit. Google lo presentó en Google Cloud Next en abril de 2025 como un kit de herramientas de código abierto para cubrir el ciclo de vida completo de un agente:

1. Definir el agente.
2. Conectarlo a herramientas.
3. Componer varios agentes.
4. Evaluar su comportamiento.
5. Desplegarlo en producción.

ADK comenzó principalmente como un framework para Python. Google ha añadido Java, con soporte para Go y TypeScript próximamente. El framework también se usa internamente en productos como Agentspace y Customer Engagement Suite, por lo que está orientado a cargas de trabajo reales, no solo a demos.

ADK es agnóstico al modelo, aunque está optimizado para el ecosistema de Google. Funciona especialmente bien con Gemini y con modelos disponibles a través de Vertex AI Model Garden. También se conecta a LiteLLM, lo que permite apuntar agentes a proveedores como Anthropic, Meta, Mistral y otros.

Dónde se sitúa ADK en el ecosistema de Gemini y Vertex AI

Para implementar agentes con ADK conviene separar tres capas:

• Modelo: Gemini u otro proveedor a través de Vertex AI Model Garden o LiteLLM. Esta capa realiza el razonamiento.
• Framework: ADK. Aquí define agentes, herramientas, subagentes y flujos de trabajo.
• Tiempo de ejecución: Vertex AI Agent Engine. Es el host gestionado y escalable para producción. También puede desplegar en Cloud Run o en otro runtime de contenedores.

En la práctica:

• Use ADK para escribir la lógica del agente.
• Use Gemini o Vertex AI Model Garden para elegir el modelo.
• Use Vertex AI Agent Engine si quiere un runtime gestionado.
• Use Cloud Run o contenedores si necesita más portabilidad.

Conceptos clave de ADK

Agentes

La unidad básica en ADK es un agente respaldado por un LLM. En Python, se importa desde google.adk.agents.

La clase principal es LlmAgent, y Agent funciona como alias conveniente. Un agente normalmente necesita:

• name: identificador del agente.
• model: modelo que usará.
• instruction: instrucciones de comportamiento.
• tools: funciones o herramientas que puede invocar.
• sub_agents: agentes secundarios, si aplica.

Ejemplo mínimo:

from google.adk.agents import Agent

def get_exchange_rate(base: str, target: str) -> dict:
    """Devuelve el tipo de cambio entre dos monedas."""
    # Aquí llamarías a tu API real de divisas
    return {
        "base": base,
        "target": target,
        "rate": 1.08
    }

currency_agent = Agent(
    name="currency_exchange_agent",
    model="gemini-2.0-flash",
    instruction="Ayudas a los usuarios a convertir entre monedas. Limítate a los hechos.",
    tools=[get_exchange_rate],
)

Este agente puede razonar sobre una solicitud del usuario y llamar a get_exchange_rate cuando necesite datos externos.

Herramientas

Las herramientas permiten que el agente haga algo más que generar texto. En ADK, una función Python puede convertirse en herramienta.

El modelo usa tres señales para decidir cuándo llamarla:

• Nombre de la función.
• Type hints.
• Docstring.

Por eso la docstring debe describir claramente qué hace la herramienta.

Ejemplo:

def search_order(order_id: str) -> dict:
    """Busca el estado actual de un pedido por su ID."""
    return {
        "order_id": order_id,
        "status": "in_transit",
        "estimated_delivery": "2026-06-30"
    }

Buenas prácticas para herramientas:

• Devuelva JSON estructurado.
• Evite respuestas ambiguas.
• Valide entradas antes de llamar a servicios externos.
• Maneje errores de red, timeouts y respuestas incompletas.
• Documente la función como si fuera un contrato de API.

ADK también incluye herramientas incorporadas como google_search y ejecución de código. Además, es compatible con el Protocolo de Contexto de Modelo, MCP, para conectar servidores de herramientas externos.

También puede envolver librerías de terceros como LangChain o LlamaIndex, o usar otro agente como herramienta.

Sistemas multi-agente

Un solo agente puede cubrir casos simples. Para tareas complejas, ADK permite componer agentes especializados.

Un patrón común es usar:

• Un agente coordinador.
• Varios agentes especialistas.
• Herramientas específicas para cada especialista.

ADK también proporciona agentes de flujo de trabajo para control determinista:

• SequentialAgent: ejecuta subagentes en orden.
• ParallelAgent: ejecuta subagentes al mismo tiempo.
• LoopAgent: repite una operación hasta que se cumple una condición.

Este enfoque es útil cuando quiere combinar razonamiento del LLM con pasos previsibles.

Runners

En producción no suele llamar al agente de forma directa. Un Runner actúa como motor de ejecución de ADK.

El runner se encarga de:

• Gestionar la sesión.
• Procesar eventos.
• Actualizar el estado.
• Invocar el modelo.
• Coordinar llamadas a herramientas.
• Mantener el flujo de ejecución.

Durante el desarrollo puede usar la CLI:

adk run

Esto inicia una sesión interactiva en terminal.

También puede usar:

adk web

Esto abre una interfaz local en el navegador para chatear con el agente e inspeccionar cada paso.

Use adk web cuando necesite depurar:

• Qué herramienta eligió el agente.
• Qué argumentos generó.
• Qué respuesta recibió.
• Cómo usó esa respuesta para continuar.

Evaluación y despliegue

ADK incluye un arnés de evaluación para comparar el comportamiento del agente contra trayectorias y respuestas esperadas.

Esto es importante porque el comportamiento puede cambiar cuando modifica:

• Instrucciones.
• Herramientas.
• Modelos.
• Prompts del sistema.
• Estructura multi-agente.

Para despliegue tiene dos rutas principales:

1. Vertex AI Agent Engine: runtime gestionado y escalable.
2. Contenedores: Cloud Run u otra plataforma compatible.

Si ya opera en Google Cloud, Vertex AI Agent Engine es la ruta natural. Si necesita portabilidad, empaquete el agente como contenedor.

Ejemplo: agente multi-agente para planificar viajes

Este ejemplo muestra una configuración sencilla con un coordinador y dos especialistas.

from google.adk.agents import Agent

def search_flights(origin: str, destination: str, date: str) -> dict:
    """Busca vuelos disponibles para una ruta y fecha."""
    return {
        "origin": origin,
        "destination": destination,
        "date": date,
        "options": [
            {
                "airline": "Example Air",
                "price": 320,
                "departure": "09:00"
            }
        ]
    }

def search_hotels(destination: str, check_in: str, nights: int) -> dict:
    """Busca hoteles disponibles cerca del destino."""
    return {
        "destination": destination,
        "check_in": check_in,
        "nights": nights,
        "options": [
            {
                "name": "Example Hotel",
                "price_per_night": 120
            }
        ]
    }

flights = Agent(
    name="flight_agent",
    model="gemini-2.0-flash",
    instruction="Encuentra opciones de vuelo para la ruta y fechas del usuario.",
    tools=[search_flights],
)

hotels = Agent(
    name="hotel_agent",
    model="gemini-2.0-flash",
    instruction="Encuentra opciones de hotel cerca del destino.",
    tools=[search_hotels],
)

trip_planner = Agent(
    name="trip_planner",
    model="gemini-2.0-flash",
    instruction="Planifica un viaje. Delega la búsqueda de vuelos y hoteles a tus subagentes.",
    sub_agents=[flights, hotels],
)

El agente trip_planner interpreta la solicitud del usuario y delega en flight_agent o hotel_agent según corresponda.

En un proyecto real, las funciones search_flights y search_hotels envolverían llamadas HTTP a APIs externas.

Ejemplo de estructura típica de una herramienta:

import requests

def search_flights(origin: str, destination: str, date: str) -> dict:
    """Busca vuelos disponibles para una ruta y fecha usando una API externa."""
    response = requests.get(
        "https://api.example.com/flights",
        params={
            "origin": origin,
            "destination": destination,
            "date": date,
        },
        timeout=10,
    )

    response.raise_for_status()
    return response.json()

Aquí es donde conviene probar el contrato de la API antes de dejar que el agente dependa de él.

ADK vs SDK de agentes de OpenAI

ADK y el SDK de agentes de OpenAI son frameworks code-first para construir agentes con herramientas, traspasos y trazabilidad. La diferencia principal está en el ecosistema.

	Google ADK	OpenAI Agents SDK
Modelo predeterminado	Gemini en Vertex AI	Modelos de OpenAI
Otros modelos	Vertex AI Model Garden, LiteLLM	LiteLLM y otros
Idiomas	Python, Java, Go, TypeScript	Python, JavaScript/TypeScript
Multi-agente	Subagentes y agentes de flujo secuencial, paralelo y en bucle	Agentes como herramientas y traspasos
Runtime gestionado	Vertex AI Agent Engine	Traiga su propio runtime
Protocolo de herramientas	MCP, herramientas incorporadas, herramientas de función	MCP, herramientas de función

Use ADK si su stack ya vive en Google Cloud o si quiere Gemini y Vertex AI como base. Use el SDK de agentes de OpenAI si su producto ya está centrado en OpenAI.

Como ambos pueden trabajar con MCP, algunos servidores de herramientas pueden compartirse entre ecosistemas.

Cuándo usar ADK

ADK encaja bien cuando:

• Está construyendo sobre Google Cloud.
• Quiere usar Gemini con un runtime gestionado.
• Necesita orquestación multi-agente.
• Quiere flujos secuenciales, paralelos o en bucle.
• Necesita evaluación integrada.
• Quiere mantener la opción de cambiar de modelo con LiteLLM o Vertex AI Model Garden.

Puede omitir ADK si:

• Su caso se resuelve con una sola llamada al modelo.
• Solo necesita una o dos function calls simples.
• No necesita estado, evaluación ni composición multi-agente.
• Su infraestructura ya está firmemente acoplada a otro proveedor.

Un framework de agentes aporta estructura, pero también añade complejidad. Para tareas pequeñas, una integración directa con el modelo puede ser suficiente.

Dónde encaja Apidog: probar y simular las API que llama su agente

ADK orquesta agentes. No valida por sí mismo todas las API externas de las que dependen sus herramientas.

Cada herramienta importante suele llamar a algo externo:

• Un endpoint REST.
• Una API interna.
• Un servicio de pagos.
• Un microservicio.
• Una fuente de datos de terceros.
• Un endpoint de LLM.

Si una API devuelve un campo inesperado o cambia su contrato, el agente puede razonar sobre datos incorrectos. El fallo puede aparecer como una respuesta incoherente, aunque el problema real esté en la capa HTTP.

Apidog encaja en esa capa. No reemplaza a ADK y no es un framework de agentes. Sirve para diseñar, probar, simular y validar las APIs que usan las herramientas del agente.

1. Simule endpoints antes de conectar servicios reales

Durante el desarrollo, puede configurar una API simulada para que su herramienta reciba respuestas controladas.

Ejemplo: si su agente llama a una API de vuelos, puede simular esta respuesta:

{
  "origin": "MAD",
  "destination": "CDG",
  "date": "2026-07-10",
  "options": [
    {
      "airline": "Example Air",
      "price": 320,
      "departure": "09:00"
    }
  ]
}

Esto permite probar el comportamiento del agente sin:

• Consumir tokens innecesarios.
• Golpear límites de velocidad.
• Depender de servicios inestables.
• Usar datos reales en desarrollo.

También puede crear respuestas de error:

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests"
}

Así valida si el agente maneja fallos de forma razonable.

2. Valide la forma de la respuesta

Use aserciones de API para confirmar que cada endpoint devuelve los campos esperados.

Por ejemplo, si su herramienta espera:

{
  "status": "in_transit",
  "estimated_delivery": "2026-06-30"
}

Debe detectar rápido si la API empieza a devolver:

{
  "state": "in_transit",
  "eta": "2026-06-30"
}

Aunque los datos sean equivalentes para un humano, su herramienta puede romperse si esperaba status y estimated_delivery.

3. Separe entornos

Mantenga claves y variables por entorno:

• Desarrollo.
• Staging.
• Producción.

Esto permite ejecutar las mismas pruebas contra diferentes bases de URL, tokens y configuraciones.

Ejemplo conceptual:

DEV_API_BASE_URL=https://mock.example.com
STAGING_API_BASE_URL=https://staging-api.example.com
PROD_API_BASE_URL=https://api.example.com

El objetivo es que el contrato sea estable antes de que el agente dependa de él en producción.

4. Pruebe herramientas como contratos

Una herramienta de ADK no debería ser solo una función auxiliar. Trátela como un contrato entre el agente y el mundo externo.

Checklist práctico:

• ¿La API devuelve siempre JSON válido?
• ¿Los campos requeridos están presentes?
• ¿Los tipos son estables?
• ¿Los errores están documentados?
• ¿La herramienta maneja timeouts?
• ¿La herramienta devuelve una estructura que el agente puede interpretar?
• ¿Hay mocks para casos felices y casos de error?

Si quiere profundizar en este flujo, consulte cómo probar las llamadas a herramientas de un agente de IA antes de que fallen en producción. También puede descargar Apidog y simular un endpoint en pocos minutos.

Preguntas frecuentes

¿Google ADK es gratuito y de código abierto?

Sí. ADK es de código abierto bajo una licencia Apache en GitHub. Puede ejecutarlo localmente sin costo por el framework. Lo que sí paga son los modelos que llama y cualquier runtime gestionado que use, como Vertex AI Agent Engine.

¿ADK solo funciona con Gemini?

No. ADK está optimizado para Gemini y Vertex AI, pero es agnóstico al modelo. A través de Vertex AI Model Garden y LiteLLM puede usar modelos de Anthropic, Meta, Mistral y otros proveedores. Gemini es el camino más integrado, no un requisito absoluto.

¿Qué idiomas soporta ADK?

Python fue el primer lenguaje y sigue siendo el más completo. Google ha añadido Java, con soporte para Go y TypeScript próximamente. Si quiere la mayor cobertura de funciones hoy, Python es la opción más segura.

¿Cómo pruebo las API de las que depende mi agente ADK?

Pruébelas fuera del agente. Primero valide los endpoints, los mocks y las respuestas esperadas. Después conecte esas APIs como herramientas en ADK.

El patrón recomendado es:

1. Diseñar el contrato de la API.
2. Crear mocks.
3. Probar respuestas correctas y errores.
4. Añadir aserciones.
5. Conectar la herramienta al agente.
6. Ejecutar el agente con adk web.
7. Revisar trazas y llamadas a herramientas.

Apidog cubre la parte de mocks, pruebas y aserciones. La guía sobre cómo probar la API de ChatGPT muestra el mismo patrón aplicado a un endpoint de LLM.

Resumen

Google ADK ofrece una forma práctica de construir agentes y sistemas multi-agente con Gemini, Vertex AI y soporte para otros modelos. Empiece con un agente simple, añada herramientas pequeñas y bien documentadas, depure con adk web y escale a subagentes cuando la tarea lo justifique.

La parte crítica es no tratar las herramientas como detalles secundarios. Si una herramienta llama a una API externa, esa API debe probarse, simularse y validarse como cualquier otra dependencia de producción. Esa es la capa donde Apidog ayuda: antes de que el agente razone sobre datos incorrectos, asegure que las APIs devuelven exactamente lo que sus herramientas esperan.