Sebastian Gomez

Oct 16, 2025

Updated: Jun 25, 2026

De desarrollo a producción: streaming, memoria, evaluación, despliegue, seguridad y observabilidad

Notebook de la lección: Lesson_6.ipynb

En esta lección cerramos el círculo: llevamos tu sistema (multi)agente del entorno local a producción. Nos apoyamos en el transcript del curso y contrastamos cada pilar con la documentación local de ADK para darte un camino concreto y seguro.

Este es el panorama general que vamos a recorrer juntos:

• Live bidirectional streaming (voz y video) con Runner.run_live() y colas de eventos.
• Memoria persistente con Vertex AI Memory Bank (--memory_service_uri).
• Evaluación de agentes: trayectorias y respuestas finales (adk eval, evaluadores).
• Despliegue: Vertex AI Agent Engine y alternativas (Cloud Run, GKE).
• Seguridad y guardrails: autenticación, callbacks y plugins, Model Armor, redacción de PII, código en sandbox.
• Observabilidad: logging, métricas y Cloud Trace con OpenTelemetry.

6.1 Live bidirectional streaming

ADK separa la lógica del agente del transporte en vivo mediante dos primitivas (docs: get-started/streaming/ y streaming/custom-streaming*.md):

• live_request_queue: envía entrada al agente (texto, audio en tiempo real, señales de actividad).
• live_events: stream de eventos del agente (respuestas, turnos, interrupciones, tool outputs).

Veamos el patrón básico (extracto; ver ejemplos en adk-docs/examples/python/snippets/streaming/adk-streaming):

from google.adk.runners import InMemoryRunner
from google.adk.agents import LiveRequestQueue
from google.adk.agents.run_config import RunConfig
from google.genai import types

# 1) Runner y sesión
runner = InMemoryRunner(app_name="My Streaming App", agent=root_agent)
session = await runner.session_service.create_session(
    app_name=runner.app_name, user_id="user123"
)

# 2) Configurar modalidad de respuesta (AUDIO o TEXT)
run_config = RunConfig(
    response_modalities=["AUDIO"],
    session_resumption=types.SessionResumptionConfig(),
)

# 3) Wiring live
live_request_queue = LiveRequestQueue()
live_events = runner.run_live(
    session=session,
    live_request_queue=live_request_queue,
    run_config=run_config,
)

# 4) Cliente hacia agente
live_request_queue.send_content(
    content=types.Content(role="user", parts=[types.Part(text="Hola")])
)
# Para audio PCM:
# live_request_queue.send_realtime(
#     types.Blob(data=pcm_bytes, mime_type="audio/pcm;rate=16000")
# )

# 5) Agente hacia cliente (SSE/WS)
async for event in live_events:
    if event.turn_complete or event.interrupted:
        # avisar cambio de turno o estado
        ...
    elif event.content and event.content.parts:
        part = event.content.parts[0]
        if getattr(part, "inline_data", None) and part.inline_data.mime_type.startswith("audio/pcm"):
            # enviar audio (base64) al cliente
            ...
        elif getattr(part, "text", None):
            # enviar texto incremental o final al cliente
            ...

El import from google.adk.agents import LiveRequestQueue debe confirmarse contra la versión instalada de google-adk. En algunas versiones la clase se expone vía google.adk.agents.live_request_queue. Verifica el path exacto y fija la versión del paquete que apuntan estos snippets.

Modelos: para streaming de voz y video usa un modelo con soporte de Gemini Live API (docs: get-started/streaming/quickstart-streaming.md). Un punto de partida razonable hoy es gemini-2.0-flash-live-preview, pero ten en cuenta el siguiente aviso.

Los nombres de modelos Live rotan con frecuencia. Confirma el ID del modelo Live recomendado en la documentación oficial antes de fijarlo en producción; no lo tomes de este post como definitivo.

ADK Web ya usa WebSockets y oculta gran parte de la complejidad. En producción, integra tu propio cliente (FastAPI con WebSocket o SSE) y orquesta live_request_queue y live_events a mano.

6.2 Memoria persistente con Vertex AI Memory Bank

Conecta memoria de largo plazo para personalización entre sesiones (docs: sessions/memory.md).

Para arrancar el servidor de ADK con memoria gestionada desde la CLI, pasa el --memory_service_uri:

adk web \
  --memory_service_uri="agentengine://<AGENT_ENGINE_ID>" \
  path/to/your/agent

O configura VertexAiMemoryBankService vía SDK si construyes un runner propio.

La diferencia clave es la siguiente: session.state es volátil y de corto plazo, mientras que Memory Bank es persistente, con extracción y resumen vía LLM y búsqueda semántica.

Vertex AI Memory Bank estaba en transición preview a GA a finales de 2025. Confirma su estado GA a junio de 2026 y que el esquema de URI agentengine:// sigue vigente sin cambios.

6.3 Evalúa tu agente: calidad por encima de exactitud

La evaluación de agentes apunta a calidad y trayectoria, no solo a un "pass/fail" determinista (docs: evaluate/index.md).

¿Qué evaluar?

• Trayectoria y uso de herramientas (orden, precisión, recall, exact match, single tool checks).
• Respuesta final (match con una referencia; por ejemplo, ROUGE).

Formas de evaluar:

• UI en ADK Web (captura sesiones y las convierte a un evalset).
• Programática con AgentEvaluator (Python) o con pytest.
• CLI: adk eval sobre uno o más evalsets.

Veamos el ejemplo de CLI (evalset completo y evals específicos):

# Evalset completo
adk eval \
  path/to/agent \
  path/to/my_evalset.evalset.json

# Solo evals específicos (separados por coma)
adk eval \
  path/to/agent \
  path/to/my_evalset.evalset.json:eval_1,eval_2

Históricamente adk eval corría en local y no siempre requería --project ni --region. Reejecuta adk eval --help contra tu versión actual de la CLI y corrige el set de flags (el ejemplo de arriba toma la forma local sin proyecto ni región).

6.4 Despliegue a escala

Tenemos tres rutas principales (docs: deploy/agent-engine.md, deploy/cloud-run.md, deploy/gke.md):

Vertex AI Agent Engine. Integración estrecha con ADK; gestiona sesiones, escalado, seguridad y memoria. Es la opción recomendada para empezar:

adk deploy agent_engine \
  --project="$GOOGLE_CLOUD_PROJECT" \
  --region="$GOOGLE_CLOUD_LOCATION" \
  --staging_bucket="gs://<YOUR_STAGING_BUCKET>" \
  --trace_to_cloud \
  path/to/your/agent

Cloud Run. Conteneriza el servicio de tu agente y lo despliega serverless:

adk deploy cloud_run \
  --project="$GOOGLE_CLOUD_PROJECT" \
  --region="$GOOGLE_CLOUD_LOCATION" \
  --service_name="my-agent-service" \
  path/to/your/agent

GKE. Control completo con Kubernetes; usa adk deploy gke o tus propios manifiestos.

Algunos consejos:

• Usa --trace_to_cloud para enviar trazas a Cloud Trace en despliegues gestionados.
• Si usas memoria persistente gestionada, pasa --agent_engine_id o --memory_service_uri según corresponda.

Confirma los nombres de subcomando de adk deploy (agent_engine, cloud_run, gke) y los flags exactos contra adk deploy --help en tu versión instalada antes de automatizarlos en CI/CD.

6.5 Seguridad y guardrails

La seguridad es defensa en profundidad (docs: safety/index.md).

Autenticación y autorización.

• Agent auth (service accounts) cuando todos comparten privilegios.
• User auth (OAuth) para permisos por usuario; registra la atribución de acciones.

Guardrails con callbacks y plugins.

• Callbacks por agente, herramienta o modelo para filtrar y transformar entradas y salidas.
• Plugins globales (recomendado en producción) con precedencia y retorno anticipado si devuelven un valor.
• Ejemplos de plugins de la documentación: "Gemini as a Judge", "Model Armor", "PII Redaction".

Filtrado de contenido y sanitización.

• Combinación de filtros nativos del modelo (Gemini Safety) más tus propias políticas.
• Sanitiza inputs para mitigar prompt injection (indirecta y directa).

Ejecución de código en sandbox.

• Usa ejecutores seguros (por ejemplo, Built in Code Execution, GKE Code Executor con gVisor) o Vertex Code Interpreter.

Red y perímetros.

• VPC SC, mínimos privilegios, sin redes abiertas en los ejecutores de código.

Tip: Para políticas reutilizables, define Plugins y ajústalos con métricas y telemetría. Recuerda que los plugins se ejecutan antes que los callbacks de nivel agente y pueden detener la cadena si devuelven algo distinto a None.

6.6 Observabilidad y trazabilidad

Vamos a monitorear, depurar y optimizar con logging y OpenTelemetry (docs: observability/logging.md, observability/cloud-trace.md).

Logging.

• Controla la verbosidad desde la CLI: --log_level DEBUG|INFO|... en adk web, adk api_server y adk deploy *.
• En desarrollo, habilita DEBUG y revisa los prompts y las llamadas a herramientas.

Cloud Trace (GCP).

• En despliegues gestionados añade --trace_to_cloud.
• O integra exportadores de OpenTelemetry (Cloud Trace Span Exporter) en runtimes personalizados.

Integraciones de terceros.

• Weave (W&B), Arize AX, Phoenix y AgentOps, soportadas y documentadas.

6.7 Checklist de producción

• Modelos: elegidos por latencia y capacidades (Live API para voz y video).
• Memoria: --memory_service_uri=agentengine://<id> si corresponde.
• Guardrails: Plugins más callbacks; políticas documentadas; sanitización de I/O; redacción de PII.
• Evaluación: evalsets, criterios y umbrales claros; adk eval en CI/CD.
• Observabilidad: --log_level, --trace_to_cloud, exportadores OTel, dashboards configurados.
• Despliegue: Agent Engine (recomendado) o Cloud Run/GKE con seguridad de red.

Ejercicios propuestos

1. Toma uno de los agentes de las lecciones anteriores y ponlo a hablar en vivo: cablea live_request_queue y live_events con un cliente WebSocket o SSE propio, primero en modalidad TEXT y luego en AUDIO.
2. Conecta Vertex AI Memory Bank arrancando adk web con --memory_service_uri y comprueba que el agente recuerda datos entre sesiones distintas.
3. Crea un evalset pequeño, ejecútalo con adk eval y define un umbral mínimo de calidad; luego integra ese comando en un paso de CI/CD.
4. Despliega tu agente a Cloud Run o Agent Engine con --trace_to_cloud y revisa las trazas resultantes en Cloud Trace.

Resumen en 3 puntos

1. El streaming en vivo en ADK se construye sobre dos primitivas, live_request_queue y live_events, que separan la lógica del agente del transporte; en producción orquestas tú el cliente.
2. La ruta a producción combina memoria persistente (Memory Bank), evaluación con adk eval, despliegue gestionado (Agent Engine, Cloud Run o GKE) y guardrails de defensa en profundidad.
3. La observabilidad con logging y OpenTelemetry, más una checklist clara, es lo que hace que todo lo anterior sea sostenible una vez que el agente está vivo.

Recursos

• Streaming Quickstart: https://google.github.io/adk docs/get started/streaming/quickstart streaming/
• Memoria: https://google.github.io/adk docs/sessions/memory/
• Evaluación: https://google.github.io/adk docs/evaluate/
• Despliegue: Agent Engine, Cloud Run, GKE
• Seguridad: https://google.github.io/adk docs/safety/
• Observabilidad: logging, Cloud Trace

Los paths profundos de la documentación de ADK (por ejemplo quickstart-streaming/) y la URL del curso de DeepLearning.AI pueden haber cambiado o redireccionado. Conviene revisarlos antes de publicar.

Lección anterior: Respuestas estructuradas con esquemas y validación

Siguiente: Conclusión de la serie

Con esto cerramos el recorrido de desarrollo a producción. Espero que esta lección te sea de utilidad y la puedas aplicar al agente que tengas en mente. Déjame un comentario si te sirvió o si tienes alguna duda, y si te gustó, compártelo usando los links a las redes sociales aquí abajo. Nos vemos en la conclusión de la serie.

Este contenido se basa en el curso "Building Live Voice Agents with Google's ADK!" de DeepLearning.AI (enlace al curso). Este blog busca acercar material de ADK al español.

Sebastián Gómez