Más allá de los impresionantes proyectos, la experiencia en Cal Hacks 12.0 también nos dio algo igualmente valioso: comentarios rápidos y sin filtros de desarrolladores que se encuentran con nuestra Stack por primera vez. Los hackathons son pruebas de presión únicas con plazos ajustados, cero familiaridad previa y obstáculos impredecibles (como los famosos cortes de WiFi). Exponen exactamente dónde brilla la experiencia del desarrollador y dónde aún necesita mejoras. Esto importa aún más ahora, ya que los desarrolladores interactúan con el Elastic Stack de nuevas maneras, cada vez más a través de flujos de trabajo impulsados por LLM. En esta entrada del blog, profundizaremos en lo que los participantes construyeron con Agent Builder y lo que aprendimos en el proceso.

Los proyectos ganadores

Primer puesto: AgentOverflow

Stack Overflow reconstruido para la era de los LLM y los agentes.

Lee más sobre AgentOverflow aquí.

AgentOverflow aborda un problema que la mayoría de los desarrolladores de IA enfrentan: los LLMs alucinan, los historiales de chat desaparecen y los desarrolladores pierden tiempo resolviendo los mismos problemas.

AgentOverflow captura, valida y reactiva pares reales problema-solución, para que los desarrolladores puedan romper la espiral de alucinaciones y enviar más rápido.

Cómo funciona:

1. Compartir JSON - el "Esquema de Solución".

Un clic desde un recurso compartido de Claude extraerá, extrae y ensamblará un JSON de Solución de Compartir, que es un formato estructurado que contiene:

• Problema

• Contexto

• Código

• Etiquetas

• Pasos verificados de la solución.

Un validador (LAVA) comprueba y aplica la estructura, el usuario agrega una línea de contexto extra y luego se almacena e indexa dentro de Elasticsearch.

2. Encontrar solución

Cuando te quedes atascado, haz clic en Find Solution y AgentOverflow extraerá tu conversación actual, la usará para crear una consulta y ejecutará una búsqueda híbrida en Elasticsearch para que aparezca:

• Arreglos clasificados y validados por la comunidad

• Los exactos prompts que originalmente resolvieron el problema

Esto permite a los desarrolladores copiar, pegar y desbloquear rápidamente su sesión actual.

3. MCP - inyección de contexto para LLMs

Al conectarse a las soluciones estructuradas almacenadas dentro de Elasticsearch a través de MCP (Model Context Protocol), los LLM reciben un contexto de alta señal (código, registros, configuraciones, correcciones previas) en tiempo de ejecución sin ruido adicional.

AgentOverflow emplea Agent Builder con Elasticsearch como una capa de memoria estructurada que inyecta el contexto relevante en los LLMs. Esto los transforma de chatbots pasivos en solucionadores de problemas conscientes del contexto.

Segundo puesto: MarketMind

Una visión interpretable en tiempo real de la energía del mercado, impulsada por seis Agentes Elásticos.

Lee más sobre MarketMind aquí.

MarketMind consiguió su spot al ofrecer a los traders novatos una plataforma que convierte datos de mercado fragmentados en señales claras y en tiempo real. En lugar de compaginar la acción del precio, los fundamentos, el sentimiento y la volatilidad entre diferentes herramientas, MarketMind consolida toda esta información en una sola plataforma, ayudando a los traders a obtener información útil. Este proyecto también empleó algunos complejos ES|QL consulta al construir sus agentes.

Cómo funciona:

1. Recopilar datos de mercado en tiempo real

MarketMind extrae métricas de precio-acción, fundamentos, sentimiento, volatilidad y riesgo de Yahoo Finance. Estos datos se ingieren y organizan en múltiples índices de Elasticsearch.

2. Seis agentes especializados analizan el mercado

Cada agente, construido con Agent Builder, se centra en una capa diferente del mercado. Leen desde un índice de Elasticsearch, calculan sus propias métricas específicas de dominio y generan una salida JSON estandarizada con puntajes y razonamientos.

3. Agregar señales en un modelo unificado de "energía de mercado"

Las salidas combinadas aparecen como pulsos brillantes alrededor de cada acción, ilustrando si el impulso está creciendo, el riesgo está aumentando o el sentimiento está cambiando.

4. Visualizar percepciones

El frontend se construyó con React y Next.js, usando TypeScript, gráficos basados en física SVG y Chart.js para gráficos en tiempo real con candelabros. Esto convierte el análisis en bruto en feedback accionable en tiempo real.

Otros proyectos interesantes:

Aquí tienes otros candidatos fuertes que usaron Elastic en diferentes partes de su stack:

Encuentra aquí la lista completa de proyectos que se presentaron a nuestra especialidad.

Lo que aprendimos de los desarrolladores

• Agent Builder es fácil de usar:

La mayoría de los equipos nunca usaron Elastic antes y aún así podían crear agentes rápidamente con poco apoyo. Organizamos un taller para quienes necesitaban más orientación, pero la mayoría pudo absorber sus datos y crear un agente para realizar acciones sobre esos datos.

• Los LLMs son excelentes en kNN consultas, pero aún necesitan orientación para generar ES|QL:

Pidiendo a ChatGPT-5 que genere ES|Las consultas QL devolvían información incorrecta, a menudo mezclando ES|QL y SQL. Alimentar al LLM la documentación en un archivo de markdown parecía una solución viable.

• ES| solo para instantáneasFunciones QL filtradas en documentos:

Las próximas funciones de agregación FIRST y LAST pasaron sin querer a nuestro ES|Documentos de QL. Como enviamos esa documentación a ChatGPT, el modelo empleó fielmente estas funciones, aunque aún no estén disponibles en Serverless. Gracias a los comentarios del grupo, ingeniería abrió y fusionó rápidamente una corrección para eliminar las funciones de la documentación publicada (PR #137341).

• Falta orientación específica para Serverless:

Un equipo intentó activar LOOKUP JOIN en un índice que no se creó en modo búsqueda. El mensaje de error les hizo perseguir comandos que no existen en Serverless. Transmitimos esto al equipo de producto, que inmediatamente abrió una corrección para un mensaje específico y accionable para Serverless. A largo plazo, la visión es ocultar por completo la complejidad del reindexado (Número #4838).

• Valor de los eventos presenciales:

Los hackathons online son geniales, pero nada iguala el bucle de retroalimentación rápida que tienes cuando depuras codo a codo con los constructores. Vimos cómo los equipos integraban Agent Builder en diferentes casos de uso, y detectamos la experiencia de los desarrolladores con ES|QL podría mejorar y solucionar los problemas mucho más rápido que intentar hacerlo por canales asincrónicos.

Conclusión

Cal Hacks 12.0 nos ofreció más que un fin de semana de demos chulas; también nos dio una visión de cómo los nuevos desarrolladores interactúan con el Elastic Stack. En tan solo 36 horas, vimos a los equipos adquirir Agent Builder, incorporar datos en Elasticsearch, diseñar sistemas multiagente y probar nuestras funcionalidades de diversas maneras. El evento también nos recordó por qué son importantes los eventos presenciales. Los rápidos bucles de retroalimentación, las conversaciones reales y la depuración práctica nos ayudaron a entender las necesidades actuales de los desarrolladores. Estamos entusiasmados por devolver lo aprendido al equipo de ingeniería. Nos vemos en el próximo hackathon.

En este blog, emplearemos Mastra para construir un agente de conocimiento que recuerda lo que dicen los usuarios y puede recuperar información relevante más adelante, empleando Elasticsearch como backend de memoria y recuperación. Puedes extender fácilmente este mismo concepto a casos de uso reales, piensa en agentes de soporte que puedan recordar conversaciones y resoluciones pasadas, permitiéndoles adaptar las respuestas a usuarios específicos o a soluciones superficiales más rápido basar en contextos previos.

Sigue aquí para ver cómo construirlo paso a paso. Si te pierdes o simplemente quieres ejecutar un ejemplo terminado, echa un vistazo al repositorio aquí.

¿Qué es Mastra?

Mastra es un framework TypeScript de código abierto para construir agentes de IA con partes intercambiables para razonamiento, memoria y herramientas. Su función de recuperación semántica permite a los agentes recordar y recuperar interacciones pasadas almacenando mensajes como incrustaciones en una base de datos vectorial. Esto permite a los agentes mantener el contexto y la continuidad de la conversación a largo plazo. Elasticsearch es un excelente almacén vectorial para habilitar esta función, ya que soporta una búsqueda vectorial densa eficiente. Cuando se activa la recuperación semántica, el agente extrae mensajes pasados relevantes en la ventana de contexto del modelo, permitiendo que el modelo emplee ese contexto recuperado como base para su razonamiento y respuestas.

Lo que necesitas para empezar

• Nodo v18+

• Elasticsearch (versión 8.15 o posterior)

• Clave API de Elasticsearch

• Clave API de OpenAI

Nota: Necesitarás esto porque la demo usa el proveedor OpenAI, pero Mastra soporta otros SDKs de IA y proveedores de modelos comunitarios, así que puedes cambiarlo fácilmente según tu configuración.

Construyendo un proyecto de Mastra

Emplearemos la CLI integrada de Mamra para proporcionar el andamiaje de nuestro proyecto. Ejecuta el comando:

Recibirás un conjunto de indicaciones, que empiezan por:

1. Pon un nombre a tu proyecto.

2. Podemos mantener este valor predeterminado; No dudes en dejar esto en blanco.

3. Para este proyecto, emplearemos un modelo proporcionado por OpenAI.

4. Selecciona la opción "Saltar por ahora" porque almacenaremos todas nuestras variables de entorno en un archivo '.env' que configuraremos en un paso posterior.

5. También podemos saltar esta opción.

Una vez que termines de inicializar, podemos pasar al siguiente paso.

Instalación de dependencias

A continuación, necesitamos instalar algunas dependencias:

• ai - Paquete básico de SDK de IA que proporciona herramientas para gestionar modelos de IA, prompts y flujos de trabajo en JavaScript/TypeScript. Mastra está construido sobre el SDK de IA por Vercel, así que necesitamos esta dependencia para permitir la interacción del modelo con tu agente.

• @ai-sdk/openai - Plugin que conecta el SDK de IA con modelos OpenAI (como GPT-4, GPT-4o, etc.), habilitando llamadas API usando tu clave API OpenAI.

• @elastic/elasticsearch - Cliente oficial de Elasticsearch para Node.js, se emplea para conectarse a tu Elastic Cloud o a un clúster local para operaciones de indexación, búsqueda y vectores.

• dotenv - Carga variables de entorno desde un .env archivar en process.env, permitiendo inyectar de forma segura credenciales como claves API y endpoints Elasticsearch.

Configuración de variables de entorno

Crea un archivo .env en el directorio raíz de tu proyecto si aún no ves uno. Alternativamente, puedes copiar y renombrar el ejemplo .env que proporcioné en el repositorio. En este archivo, podemos agregar las siguientes variables:

Eso concluye la configuración básica. Desde aquí, ya puedes empezar a construir y orquestar agentes. Vamos un paso más allá y agregaremos Elasticsearch como la capa de almacenamiento y búsqueda vectorial.

Agregar Elasticsearch como almacenamiento vectorial

Crea una nueva carpeta llamada stores y dentro, agrega este archivo. Antes de que Mastra y Elastic lanzaran una integración oficial de almacenamiento vectorial de Elasticsearch, Abhi Aiyer(CTO de Mestra) compartió esta clase prototipo temprana llamada ElasticVector. Simplemente, conecta la abstracción de memoria de Mamra con las densas capacidades vectoriales de Elasticsearch, para que los desarrolladores puedan incluir Elasticsearch como base de datos vectorial para sus agentes.

Echemos un vistazo más profundo a las partes importantes de la integración:

Ingestión del cliente Elasticsearch

Esta sección define la clase ElasticVector y configura la conexión cliente de Elasticsearch con soporte tanto para despliegues estándar como serverless.

• ElasticVectorConfig extends ClientOptions: Esto crea una nueva interfaz de configuración que hereda todas las opciones del cliente de Elasticsearch (como node, auth, requestTimeout) y agrega nuestras propiedades personalizadas. Esto significa que los usuarios pueden pasar cualquier configuración válida de Elasticsearch junto con nuestras opciones específicas para serverless.

• extends MastraVector: Esto permite ElasticVector heredar de la clase base de MastraVector de Mastra, que es una interfaz común a la que se ajustan todas las integraciones de almacenamiento vectorial. Esto garantiza que Elasticsearch se comporte como cualquier otro backend de vectores Mastra desde la perspectiva del agente.

• private client: Client: Esta es una propiedad privada que contiene una instancia del cliente JavaScript Elasticsearch. Esto permite que la clase hable directamente con tu grupo.

• isServerless y deploymentChecked: Estas propiedades trabajan juntas para detectar y almacenar en caché si estamos conectados a un despliegue serverless o estándar de Elasticsearch. Esta detección ocurre automáticamente en el primer uso, o puede configurar explícitamente.

• constructor(config: ClientOptions): Este constructor toma un objeto de configuración (que contiene tus credenciales de Elasticsearch y configuraciones opcionales de serverless) y lo emplea para inicializar el cliente en la línea this.client = new Client(config).

• super(): Esto llama constructor base de Mastra, por lo que hereda el registro, los asistentes de validación y otros ganchos internos.

En este punto, Mastra sabe que hay un nuevo almacén vectorial llamado ElasticVector

Detección del tipo de despliegue

Antes de crear índices, el adaptador detecta automáticamente si estás usando Elasticsearch estándar o Elasticsearch Serverless. Esto es importante porque los despliegues serverless no permiten la configuración manual de shards.

Qué pasa:

• Primero comprueba si pusiste explícitamente isServerless en la configuración (se salta la auto-detección).

• Llama a la API info() de Elasticsearch para obtener información del clúster

• Comprueba el build_flavor field (los despliegues serverless devuelven serverless)

• Vuelve a revisar el lema si no hay variedad de build disponible

• Almacena en caché el resultado para evitar llamadas repetidas a la API

• Por defecto se aplica al despliegue estándar si falla la detección

Ejemplo de uso:

Creación del almacén de "memoria" en Elasticsearch

La función siguiente establece un índice Elasticsearch para almacenar incrustaciones. Comprueba si el índice ya existe. Si no, crea uno con el mapeo que aparece abajo y contiene un campo dense_vector para almacenar incrustaciones y métricas de similitud personalizadas.

Algunas cosas a tener en cuenta:

• El parámetro dimension es la longitud de cada vector de incrustación, que depende del modelo de incrustación que estés usando. En nuestro caso, generaremos incrustaciones usando el modelo text-embedding-3-small de OpenAI, que genera vectores de tamaño 1536. Usaremos esto como nuestro valor por defecto.

• La variable similarity empleada en el mapeo a continuación se define a partir de la función auxiliar const similarity = this.mapMetricToSimilarity(metric), que toma el valor del parámetro metric y lo convierte en una palabra clave compatible con Elasticsearch para la métrica de distancia elegida.

  • Por ejemplo: Mastra emplea términos generales para similitud vectorial como cosine, euclidean, y dotproduct. Si pasáramos la métrica euclidean directamente al mapeo de Elasticsearch, generaría un error porque Elasticsearch espera que la palabra clave l2_norm represente la distancia euclidiana.

• Compatibilidad sin servidor: El código omite automáticamente los ajustes de shard y réplica para despliegues sin servidor, ya que estos son gestionados automáticamente por Elasticsearch Serverless.

Almacenar una nueva recordación o nota tras una interacción

Esta función toma nuevas incrustaciones generadas tras cada interacción, junto con los metadatos, y luego las inserta o actualiza en el índice usando la API bulk de Elastic. La API bulk agrupa múltiples operaciones de escritura en una sola solicitud; Esta mejora en nuestro rendimiento de indexación garantiza que las actualizaciones se mantengan eficientes a medida que la memoria de nuestro agente sigue creciendo.

Consulta de vectores similares para la recuperación semántica

Esta función es el núcleo de la característica de recuperación semántica. El agente emplea búsqueda vectorial para encontrar incrustaciones almacenadas similares dentro de nuestro índice.

Bajo el capó:

• Ejecuta una consulta kNN (k-vecinos más cercanos) usando la API knn en Elasticsearch.

• Recupera los vectores top-K similares al vector de consulta de entrada.

• Opcionalmente, aplica filtros de metadatos para reducir resultados (por ejemplo, buscar solo dentro de una categoría o rango de tiempo específico)

• Devuelve resultados estructurados que incluyen el ID del documento, el puntaje de similitud y los metadatos almacenados.

Creación del agente del conocimiento

Ahora que vimos la conexión entre Mastra y Elasticsearch a través de la integración ElasticVector , creemos el propio Knowledge Agent.

Dentro de la carpeta agents, crea un archivo llamado knowledge-agent.ts. Podemos empezar conectando nuestras variables de entorno e inicializando el cliente Elasticsearch.

Aquí, nosotros:

• Usa dotenv para cargar nuestras variables desde nuestro archivo .env .

• Comprueba si las credenciales de Elasticsearch se están inyectando correctamente y podemos establecer una conexión exitosa con el cliente.

• Pasa el endpoint de Elasticsearch y la clave API al constructor ElasticVector para crear una instancia de nuestro almacén vectorial que definimos antes.

• Opcionalmente, especifica isServerless: true si usas Elasticsearch Serverless. Esto omite el paso de detección automática y mejora el tiempo de arranque. Si se omite, el adaptador detectará automáticamente el tipo de despliegue en el primer uso.

A continuación, podemos definir el agente usando la clase Agent de Mastra.

Los campos que podemos definir son:

• name y instructions: Darle una identidad y función primaria.

• model: Estamos usando la gpt-4o de OpenAI a través del paquete @ai-sdk/openai .

• memory:

  • vector: Apunta a nuestra tienda Elasticsearch, así que los embeddings se almacenan y recuperan desde allí.

  • embedder: Qué modelo usar para generar incrustaciones

  • semanticRecall Las opciones deciden cómo funciona la retirada:

    • topK: Cuántos mensajes semánticamente similares recuperar.

    • messageRange: Cuánto de la conversación incluir en cada partido.

    • scope: Define el límite de la memoria.

Casi termino. Solo tenemos que agregar este agente recién creado a nuestra configuración de Mestra. En el archivo llamado index.ts, importa el agente de conocimiento e insértalo en el campo agents .

Los otros campos incluyen:

• storage: Este es el almacén interno de datos de Mamra para historial de ejecuciones, métricas de observabilidad, puntajes y cachés. Para más información sobre el almacenamiento de mastras, visita aquí.

• logger: Mastra emplea Pino, que es un registrador JSON estructurado y ligero. Captura eventos como inicios y atajada de agentes, llamadas y resultados de herramientas, errores y tiempos de respuesta de los LLM.

• observability: Controla el rastreo de IA y la visibilidad de ejecución de los agentes. Sigue lo siguiente:

  • Inicio/final de cada paso de razonamiento.

  • Qué modelo o herramienta se empleó.

  • Entradas y salidas.

  • Puntajes y evaluaciones

Probando al agente con Mastra Studio

¡Felicidades! Si llegaste hasta aquí, estás listo para ejecutar este agente y probar sus capacidades semánticas de recuperación. Por suerte, Mastra ofrece una interfaz de chat integrada para que no tengamos que crear la nuestra.

Para iniciar el servidor de desarrollo de Mestra, abre un terminal y ejecuta el siguiente comando:

Tras el empaquetado y el arranque inicial del servidor, debería proporcionarte una dirección del Playground.

Pega esta dirección en tu navegador y te recibirás con Mastra Studio.

Selecciona la opción de knowledgeAgent y charla sin parar.

Para una prueba rápida y ver si todo está correctamente cableado, dale información como: "El equipo anunció que el rendimiento de ventas en octubre subió un 12%, impulsado principalmente por renovaciones empresariales. El siguiente paso es ampliar su alcance a clientes de gama media." Después, inicia un nuevo chat y haz una pregunta como: "¿En qué segmento de clientes dijimos que debemos centrarnos a continuación?" El agente de conocimiento debería ser capaz de recordar la información que le diste en el primer chat. Deberías ver una respuesta como:

Ver una respuesta así significa que el agente almacenó con éxito nuestro mensaje anterior como incrustaciones en Elasticsearch y lo recuperó después usando búsqueda vectorial.

Inspección del almacenamiento de memoria a largo plazo del agente

Ve a la pestaña memory en la configuración de tu agente en Mastra Studio. Esto te permite ver lo que tu agente aprendió con el tiempo. Cada mensaje, respuesta e interacción que se incrusta y almacena en Elasticsearch pasa a formar parte de esta memoria a largo plazo. Puedes buscar semánticamente en interacciones pasadas para encontrar rápidamente información o contexto recordado que el agente aprendió antes. Este es esencialmente el mismo mecanismo que emplea el agente durante la recuperación semántica, pero aquí puedes inspeccionarlo directamente. En nuestro ejemplo a continuación, buscamos el término "ventas" y recibimos cada interacción que incluyera algo relacionado con las ventas.

Conclusión

Al conectar Mastra y Elasticsearch, podemos dar memoria a nuestros agentes, que es una capa clave en la ingeniería de contexto. Con la memoria semántica, los agentes pueden construir contexto con el tiempo, basando sus respuestas en lo que aprendieron. Eso significa interacciones más precisas, fiables y naturales.

Esta integración temprana es solo el punto de partida. El mismo patrón aquí puede permitir que los agentes de soporte recuerden tiquetes anteriores, bots internos que recuperen la documentación relevante o asistentes de IA que puedan recuperar detalles de los clientes en medio de una conversación. También estamos trabajando en una integración oficial de Mestra, haciendo que esta pareja sea aún más fluida en un futuro próximo.

Estamos deseando ver qué construyes a continuación. Pruébalo, explora Mastra y sus funciones de memoria, y siéntete libre de compartir lo que descubras con la comunidad.

1. Uso de la API _mapping para recuperar información de campos

2. Uso de la API _search para mostrar los valores de los campos

3. Visualización de subcampos

4. _source sintética

5. Campos de tiempo de ejecución

1. Uso de la API _mapping para recuperar información de campo

La API _mapping permite recuperar la definición de mapeo para un índice o varios índices. Esto incluye información sobre los campos, sus tipos de datos y otras propiedades. Para recuperar el mapeo de un índice específico, emplee la siguiente petición:

Por ejemplo, si tienes un índice llamado my_index, puedes recuperar su mapeo con la siguiente petición:

La respuesta incluirá la definición de mapeo para el índice, que contiene información sobre los campos y sus propiedades.

También es posible recuperar el mapeo de un campo específico. Esto puede ser útil si tu mapeo es bastante grande y solo quieres centrarte en un campo específico. Para recuperar el mapeo de un campo específico, emplee la siguiente petición:

También puedes recuperar las asignaciones de varios campos separando sus nombres con comas, como en la siguiente petición:

2. Uso de la API _search para mostrar los valores de los campos

Para mostrar los valores de los campos en un índice de Elasticsearch, puedes usar la API _search . La API _search te ofrece múltiples formas de controlar qué campos se devuelven; Los dos principales son:

1. _source: El campo _source contiene el cuerpo original del documento JSON exactamente como estaba indexado, incluyendo cualquier cambio realizado por las canalizaciones de ingestión o pasos de preprocesamiento. Para mostrar campos específicos del documento fuente, implementa filtrado de fuentes como veremos a continuación.

2. fields: El parámetro fields te permite recuperar campos específicos de tus documentos al realizar una búsqueda, basándote en el mapeo de índice. A diferencia de _source, fields también puede devolver valores de campos almacenados, valores de documentación o campos de ejecución sin referenciar la _source, aunque para campos estándar sin valores de documento ni configuraciones almacenadas, vuelve a _source. Esto puede aportar muchos beneficios como el rendimiento y más, como veremos a continuación.

Uso del campo _source

Por defecto, la API _search devuelve el campo _source , que contiene el documento JSON original que se indexó. Para mostrar campos específicos, puedes agregar filtros en el parámetro _source de la solicitud de búsqueda; Esto se llama filtrado de fuente.

Aquí tienes un ejemplo de una solicitud de búsqueda que devuelve los valores de los campos title y author para documentos en el índice my_index :

En este ejemplo, el parámetro _source especifica los campos que se deben devolver.

Si necesitas aún más control, puedes usar las propiedades de includes y excludes del objeto _source. Por ejemplo, la consulta siguiente devuelve el campo title de nivel superior y todos los subcampos de author excepto author.description.

En este ejemplo, usamos el patrón author.* para recuperar todos los subcampos directos del objeto author . Luego excluimos explícitamente author.description para que solo se devuelvan los otros campos de autor. Ten en cuenta que esto no tiene mejoras de rendimiento ya que aún tiene que cargar y analizar el JSON de origen, pero puede reducir el tamaño de la respuesta enviada por la red.

Uso del parámetro de campos

Puedes usar el parámetro fields para filtrar los campos que aparecen en la respuesta de búsqueda. Emplear fields _source ofrece varios beneficios, entre ellos:

• Mejora de rendimiento: fields puede devolver valores directamente desde campos almacenados o valores de documentos sin tener que cargar toda la _source, haciendo que el tamaño de la carga útil de respuesta sea menor.

• Salida formateada: Para campos estándar, fields puede recurrir a _source para obtener los valores, pero revisa el mapeo del índice para formatear correctamente la salida, como las fechas formateadas, haciéndolas consistentes con lo que se usa para agregaciones y ordenación.

• Acceso a campos de tiempo de ejecución: fields puede devolver campos de tiempo de ejecución, que no existen en el _sourceoriginal.

• Aquí se pueden encontrar más beneficios.

Por ejemplo, para devolver solo los campos title y author en el índice my_index , puedes usar la siguiente solicitud de búsqueda:

En la consulta anterior, ponemos el campo _source en false para no devolver el documento fuente. Esto puede minimizar significativamente el tamaño de la carga útil para la respuesta, pero recuerda que esto solo funciona porque los campos title y author son del tipo keyword campo, que doc_values habilitaron por defecto. Si el campo no tiene doc_values activado y el _source está configurado como falso, Elasticsearch no tendría forma de recuperarlos y se omitiría en la respuesta.

Es importante señalar que la respuesta fields siempre devuelve un array de valores para cada campo, incluso si solo hay un único valor. Esto se debe a que Elasticsearch no tiene un tipo de array dedicado, y cualquier campo puede tener varios valores. Para más información sobre los arrays en Elasticsearch, haz clic aquí.

Otras formas de recuperar campos

Aunque recuperar campos usando _source o fields son los métodos recomendados, existen diferentes métodos disponibles para casos de uso específicos, como:

Campos de valor de documentos: Si quieres evitar _source por completo, puedes buscar usando el parámetro docvalue_fields. Los valores de documentación almacenan los mismos valores de campo que _source pero en una estructura de datos en disco, optimizada para ordenar y agregar.

Como está separado de los valores almacenados con _source, puedes aplicar campos específicos sin cargar toda la _source. Esto es útil si consultas documentos grandes pero solo necesitas unos pocos campos pequeños que soporten valores de documentos. Otro caso de uso para usar docvalue_fields es cuando quieres usar formato personalizado en campos date y numeric , como veremos en el ejemplo más abajo.

Ten en cuenta que esto solo funciona para campos que activas doc_values o para tipos de campos que lo tienen activado por defecto, como keyword, date, tipos numéricos y boolean, no para text o annotated_text.

En este ejemplo, usamos el parámetro docvalue_fields para recuperar los campos title, author, y published sin cargar el documento completo de _source :

Cuando se ejecuta esta consulta, Elasticsearch toma los valores directamente de su almacenamiento columnar en disco en lugar de referenciar el _source de cada documento. El campo published se devuelve con el formato epoch_millis en lugar del formato por defecto, gracias al parámetro format proporcionado en la consulta.

Campos almacenados: Si marcas explícitamente campos específicos como almacenados en el mapeo, puedes usar el parámetro stored_fields para filtrar esos campos. Esto es útil si quieres respuestas ligeras solo con esos campos específicos o para campos que almacenaste deliberadamente para recuperarlos después. Se almacena por separado de _source, por lo que este método también es útil para evitar la necesidad de cargar _source.

Es importante señalar que esta opción está desactivada por defecto y generalmente no se recomienda. Emplea filtrado de fuentes para devolver ciertos subconjuntos del documento fuente original.

En la consulta de ejemplo a continuación, usamos el parámetro stored_fields para recuperar el campo summary , que tiene la configuración de mapeo de índice "store”: true.

Cuando se ejecuta esta consulta, Elasticsearch busca si este campo está marcado con ”store”: true, si no lo encuentra, se saltará el campo por completo.

3. Visualización de subcampos

Si tu índice contiene subcampos, puedes usar la notación de puntos para especificar el camino de campo en el parámetro fields . Ten en cuenta que los subcampos son diferentes del tipo de campo anidado. Por ejemplo, si tienes un subcampo llamado address.city, puedes incluirlo en la respuesta de búsqueda así:

En este ejemplo, la respuesta de búsqueda incluirá los valores de los campos title, author address.city .

4. _source sintético

Si quieres mantener la funcionalidad de usar _source pero también ahorrar espacio en disco, tienes la opción de usar _source sintético en tu mapeo de índice. La_source sintética es una función que permite a Elasticsearch reconstruir el _source a partir de datos existentes como campos almacenados y valores de documentos, incluso cuando _source está desactivado. Esto te permite ahorrar mucho espacio de almacenamiento a cambio de velocidades ligeramente menores en el momento de la consulta, ya que la reconstrucción se realiza sobre la marcha. Activa esta función usando los valores que aparecen a continuación en la configuración de tu índice:

Algunos beneficios de usar _source sintéticos incluyen: visualización completa del documento al usar la API _search , filtrado de código fuente y compatibilidad con otras funciones y herramientas como Kibana que esperan _source estén disponibles, todo ello evitando la necesidad de almacenar el documento completo _source .

5. Campos de tiempo de ejecución

Los campos de ejecución te permiten definir campos guionizados en el momento de la consulta o en tu mapeo de índice bajo un bloque de ejecución. Estos campos nunca se indexan, por lo que agregar un campo en tiempo de ejecución no aumenta el tamaño del índice pero nunca aparecerá en _source. Los campos de ejecución definidos en el mapeo son persistentes y están disponibles para todas las consultas, mientras que los campos de ejecución definidos en el momento de la consulta son temporales y solo están disponibles en esa solicitud de búsqueda.

El principal beneficio de usar campos de tiempo de ejecución es la posibilidad de agregar campos a documentos luego de haberlos ingerido, simplificando así tus decisiones de mapeo. Los campos de ejecución también son ideales para enriquecer tus documentos con valores que no existen en el documento original pero que se generan mediante un script, como formatear una cadena o calcular un puntaje.

También cabe destacar que los campos de ejecución pueden perjudicar el rendimiento, ya que será necesario ejecutar un script para cada documento del conjunto de resultados. Para recuperar un campo de ejecución, también puedes usar el parámetro fields en la API _search .

Conclusión

Mostrar campos de un índice de Elasticsearch puede ir desde simplemente recuperar valores usando el mapeo de índice o el _source, hasta métodos más avanzados usando campos fields, docvalue_fieldso en tiempo de ejecución para mayor control y eficiencia. Comprender los compromisos entre diferentes métodos es clave para optimizar tus experiencias de búsqueda. Ya sea que estés optimizando cargas útiles, enriqueciendo documentos o empleando _source sintéticos para ahorrar espacio, Elasticsearch te ofrece múltiples herramientas y funciones para encontrar los datos que necesitas, de la manera que necesitas. Estas técnicas pueden ayudarte a entender la estructura de tus datos, identificar campos específicos y solucionar problemas.

En esta entrada, exploraremos cómo construir un asistente RAG agente usando Mastra y una aplicación sitio web ligero en JavaScript para interactuar con él. Al conectar este agente con Elasticsearch, le damos acceso a datos estructurados de jugadores y la capacidad de ejecutar agregaciones estadísticas en tiempo real, para ofrecerte recomendaciones basadas en estadísticas de jugadores. Visita el repositorio de GitHub para seguirle; el README proporciona instrucciones sobre cómo clonar y ejecutar la aplicación por tu cuenta.

Así debería ver cuando todo esté montado:

Nota: Esta entrada del blog se basa en "Construcción de agentes de IA con SDK de IA y Elastic". Si eres nuevo en los agentes de IA en general y en qué podrían servir, empieza por ahí.

Visión general de la arquitectura

En el núcleo del sistema se encuentra un gran modelo de lenguaje (LLM), que actúa como motor de razonamiento del agente (el cerebro). Interpreta la entrada del usuario, decide qué herramientas llamar y orquesta los pasos necesarios para generar una respuesta relevante.

El propio agente está estructurado por Mastra, un framework de agentes dentro del ecosistema JavaScript. Mastra envuelve el LLM con infraestructura backend, lo expone como un endpoint API y proporciona una interfaz para definir herramientas, indicaciones del sistema y comportamiento de agentes.

En el frontend, usamos Vite para andamiar rápidamente una aplicación sitio web React que proporciona una interfaz de chat para enviar consultas al agente y recibir sus respuestas.

Por último, tenemos Elasticsearch, que almacena estadísticas de jugadores y datos de emparejamientos que el agente puede consultar y agregar.

Fondo

Vamos a repasar algunos conceptos fundamentales:

¿Qué es el RAG agente?

Los agentes de IA pueden interactuar con otros sistemas, operar de forma independiente y realizar acciones basadas en sus parámetros definidos. El RAG agente combina la autonomía de un agente de IA con los principios de generación aumentada por recuperación, permitiendo a un LLM elegir qué herramientas llamar y qué datos usar como contexto para generar una respuesta. Lee más sobre RAG aquí.

Elegir un framework, ¿por qué ir más allá del SDK de IA?

Hay muchos frameworks de agentes de IA disponibles y probablemente oíste hablar de los más populares como CrewAI, AutoGen y LangGraph. La mayoría de estos frameworks comparten un conjunto común de funcionalidades, incluyendo soporte para diferentes modelos, uso de herramientas y gestión de memoria.

Aquí tienes una hoja comparativa de marcos de Harrison Chase (CEO de LangChain).

Lo que despertó mi interés con Mastra es que es un framework JavaScript-first diseñado para que desarrolladores full-stack integren fácilmente agentes en su ecosistema. El AI-SDK de Vercel también hace la mayoría de esto, pero donde Mastra destaca es cuando tus proyectos incluyen flujos de trabajo de agentes más complejos. Mastra mejora los patrones base establecido por el AI-SDK y en este proyecto los usaremos conjuntamente.

Marcos y consideraciones sobre la elección del modelo

Aunque estos frameworks pueden ayudarte a construir agentes de IA rápidamente, existen algunos inconvenientes a tener en cuenta. Por ejemplo, al usar cualquier otro framework fuera de agentes de IA o cualquier capa de abstracción en general, pierdes un poco de control. Si el LLM no emplea correctamente las herramientas o hace algo que no quieres, la abstracción dificulta la depuración. Aun así, en mi opinión, este equilibrio merece la facilidad y rapidez que obtienes al construir, especialmente porque estos frameworks están ganando impulso y se iteran constantemente.

De nuevo, estos frameworks son independientes de los modelos, lo que significa que puedes conectar y jugar diferentes modelos; recuerda que los modelos varían en los conjuntos de datos con los que fueron capacitados y, a su vez, varían en las respuestas que dan. Algunos modelos ni siquiera soportan la llamada de herramientas. Así que es posible cambiar y probar diferentes modelos para ver cuál te da las mejores respuestas, pero ten en cuenta que probablemente tendrás que reescribir el prompt del sistema para cada uno. Por ejemplo, usando Llama3.3 en comparación con GPT-4o, implica mucho más indicación e instrucciones específicas para obtener la respuesta que buscas.

Baloncesto de fantasía de la NBA

El baloncesto de fantasía consiste en empezar una liga con un grupo de colegas (advertencia, dependiendo de lo competitivo que sea tu grupo, esto podría afectar al estado de tus amistades), normalmente con algo de dinero en juego. Cada uno de vosotros selecciona un equipo de 10 jugadores para competir contra los 10 jugadores de otro amigo alternando semanalmente. Los puntos que contribuyen a tu puntaje global son cómo se desempeña cada uno de tus jugadores contra sus oponentes en una semana determinada.

Si un jugador de tu equipo se lesiona, es suspendido, etc., hay una lista de jugadores agentes libres disponibles para agregar a tu equipo. Aquí es donde ocurre gran parte de la dificultad en los deportes de fantasía, porque solo tienes un número limitado de fichas y todos están constantemente a la caza del mejor jugador.

Aquí es donde nuestro asistente de IA de la NBA brillará, especialmente en situaciones en las que tienes que decidir rápidamente qué jugador elegir. En lugar de tener que buscar manualmente cómo rinde un jugador contra un oponente específico, el asistente puede encontrar esos datos rápidamente y comparar promedios para darte una recomendación informada.

Ahora que ya sabes lo básico sobre el RAG agente y el baloncesto fantasy de la NBA, vamos a verlo en la práctica.

Construcción del proyecto

Si te quedas atascado en algún momento o no quieres montarlo desde cero, por favor consulta el repositorio.

Lo que vamos a cubrir

1. Andamiaje del proyecto:

   1. Backend (Mastra): Usa NPX Create mastra@latest para andamiar el backend y definir la lógica del agente.

   2. Frontend (Vite + React): Usa npm create vite@latest para construir la interfaz de chat del frontend y así interactuar con el agente.

2. Configuración de variables de entorno

   1. Instala dotenv para gestionar las variables del entorno.

   2. Crea un .env archiva y proporciona las variables requeridas.

3. Configuración de Elasticsearch

   1. Crea un clúster de Elasticsearch (ya sea localmente o en la nube).

   2. Instala el cliente oficial de Elasticsearch.

   3. Cerciórate de que las variables del entorno sean accesibles.

   4. Establece conexión con el cliente.

4. Ingiriendo en masa datos de la NBA en Elasticsearch

   1. Crea un índice con los mapeos apropiados para permitir agregaciones.

   2. Ingirir en masa las estadísticas de los jugadores de un archivo CSV en un índice de Elasticsearch.

5. Definir agregaciones de Elasticsearch

   1. Consulta para calcular promedios históricos contra un oponente específico.

   2. Consulta para calcular los promedios de temporada contra un rival específico.

6. Archivo utilitario de comparación de jugadores

   1. Consolida funciones auxiliares y agregaciones de Elasticsearch.

7. Construcción del agente

   1. Agrega la definición del agente y el prompt del sistema.

   2. Instala Zod y define herramientas.

   3. Agregar una configuración de middleware para manejar CORS.

8. Integración del frontend

   1. Usando el useChat de AI-SDK para interactuar con el agente.

   2. Crea la interfaz para mantener conversaciones bien formateadas.

9. Ejecutando la aplicación

   1. Inicia tanto el backend (servidor Mestra) como el frontend (app React).

   2. Ejemplos de consultas y uso.

10. Qué sigue: Hacer que el agente sea más inteligente

    1. Agregar capacidades de búsqueda semántica para permitir recomendaciones más profundas.

    2. Habilitar la consulta dinámica moviendo la lógica de búsqueda al servidor Elasticsearch MCP (Model Context Protocol).

Prerrequisitos

• Node.js y NPM: Tanto el backend como el frontend funcionan en Node. Cerciórate de tener instalados Node 18+ y npm v9+ (que vienen incluidos con Node 18+).

• Clúster de Elasticsearch: Un clúster activo de Elasticsearch, ya sea localmente o en la nube.

• Clave API de OpenAI: Genera una en la página de claves API del portal para desarrolladores de OpenAI.

Estructura del proyecto

Paso 1: Estructurar el proyecto

1. Primero, crea el directorio nba-ai-assistant-js y navega dentro usando:

Backend:

1. Usa la herramienta de creación de Mastra con el comando:

2. Deberías recibir algunos prompts en tu terminal; para el primero, llamaremos al backend del proyecto:

3. A continuación, mantendremos la estructura predeterminada para almacenar los archivos Mastra, así que introduzca src/.

4. Luego, elegiremos OpenAI como nuestro proveedor de LLM por defecto.

5. Finalmente, te pedirá la clave de la API de OpenAI. Por ahora, elegiremos la opción de saltarlo y proporcionarlo más adelante en un archivo .env .

Frontend:

1. Vuelve al directorio raíz y ejecuta la herramienta de creación de Vite usando este comando: npm create vite@latest frontend -- --template react

Esto debería crear una aplicación ligera de React llamada frontend con una plantilla específica para React.

Si todo va bien, dentro de tu directorio de proyecto, deberías estar mirando un directorio backend que contenga el código Mastra y un directorio frontend con tu app React.

Paso 2: Configuración de variables de entorno

1. Para gestionar claves sensibles, usaremos el paquete dotenv para cargar nuestras variables de entorno desde el .env archivo. Navega al directorio del backend e instala dotenv:

2. Mientras está en el directorio backend, se proporciona un archivo example.env con las variables adecuadas para rellenar. Si creas el tuyo propio, cerciórate de incluir las siguientes variables:

Nota: Cerciórate de que este archivo esté excluido de tu control de versiones agregando .env a .gitignore.

Paso 3: Configuración de Elasticsearch

Primero, necesitas un clúster activo de Elasticsearch. Hay dos opciones:

• Opción A: Usar Elasticsearch Cloud

  • Apúntate a Elastic Cloud

  • Crear un nuevo despliegue

  • Obtén la URL de tu endpoint y la clave API (codificada)

• Opción B: Ejecutar Elasticsearch localmente

  • Instala y ejecuta Elasticsearch localmente

  • Usa http://localhost:9200 como punto final

  • Generar una clave API

Instalación del cliente Elasticsearch en el backend:

1. Primero, instala el cliente oficial de Elasticsearch en tu directorio backend:

2. Luego crea una lib de directorios para almacenar funciones reutilizables y navega hacia ella:

3. Dentro, crea un nuevo archivo llamado elasticClient.js. Este archivo inicializará el cliente Elasticsearch y lo expondrá para su uso en todo tu proyecto.

4. Como usamos módulos ECMAScript (ESM), __dirname and __nombre de archivo no están disponibles. Para cerciorarte de que tus variables de entorno se carguen correctamente desde el archivo .env Archivo en la carpeta de backend, agrega esta configuración en la parte superior de tu archivo:

5. Ahora, inicializa el cliente Elasticsearch usando tus variables de entorno y comprueba la conexión:

Ahora, podemos importar esta instancia cliente a cualquier archivo que necesite interactuar con tu clúster de Elasticsearch.

Paso 4: Ingirir en masa datos de la NBA en Elasticsearch

Conjunto de datos:

Para este proyecto, consultaremos los conjuntos de datos disponibles en el directorio de backend/datos del repositorio. Nuestro asistente de la NBA empleará estos datos como base de conocimiento para realizar comparaciones estadísticas y generar recomendaciones.

• sample_player_game_stats.csv - Estadísticas de juego de un jugador (por ejemplo, puntos, rebotes, robos, etc., por partido por jugador a lo largo de toda su carrera en la NBA). Emplearemos este conjunto de datos para realizar agregaciones. (Nota: Estos son datos simulados, pregenerados para fines demo y no provenientes de fuentes oficiales de la NBA.)

• playerAndTeamInfo.js - Sustituye los metadatos de jugadores y equipos que normalmente proporcionaría una llamada a la API para que el agente pueda relacionar los nombres de jugadores y equipos con IDs. Como usamos datos de muestra, no queremos la sobrecarga de buscar desde una API externa, así que codificamos de forma fija algunos valores que el agente puede referenciar.

Implementación:

1. Mientras estés en el directorio backend/lib , crea un archivo llamado playerDataIngestion.js.

2. Configura las importaciones, resuelve la ruta del archivo CSV y configura el análisis sintáctico. De nuevo, como estamos usando ESM, necesitamos reconstruir __dirname para resolver el camino hacia el CSV de muestra. Además, importaremos Node.js módulos incorporados, fs y readline, para analizar el archivo CSV dado línea por línea.

Esto te prepara para leer y analizar eficientemente el CSV cuando lleguemos al paso de la ingestión masiva.

3. Crear un índice con el mapeo adecuado. Aunque Elasticsearch puede inferir automáticamente los tipos de campos con mapeo dinámico, queremos ser explícitos aquí para que cada estadística se trate como un campo numérico. Esto es importante porque usaremos estos campos para agregaciones más adelante. También queremos usar el tipo float para estadísticas como puntos, rebotes, etc., para cerciorarnos de incluir valores decimales. Finalmente, queremos agregar la propiedad de mapeo dynamic: 'strict' para que Elasticsearch no mapee dinámicamente campos no reconocidos. 

4. Agregar la función para ingirte en masa los datos CSV en tu índice de Elasticsearch. Dentro del bloque de código, saltamos la línea de cabecera. Luego, divide cada elemento de línea por una coma y empújalos en el objeto documento. Este paso también los limpia y cerciora que sean del tipo adecuado. A continuación, enviamos los documentos al array bulkBody junto con la información del índice, que servirá como carga útil para la ingestión masiva en Elasticsearch.

5. Luego, podemos usar la API Bulk de Elasticsearch con elasticClient.bulk() para ingirse varios documentos en una sola solicitud. La gestión de errores a continuación está estructurada para darte un recuento de cuántos documentos no se ingirieron y cuántos fueron exitosos.

6. Ejecuta la función main() a continuación para ejecutar secuencialmente las funciones createIndex() y bulkIngestCsv() .

Si ves un registro de consola que indique que la ingesta masiva fue exitosa, realiza una comprobación rápida en tu índice de Elasticsearch para ver si los documentos realmente se ingirieron con éxito.

Paso 5: Definición de agregaciones de Elasticsearch y consolidación

Estas serán las funciones principales que se emplearán cuando definamos las herramientas para el Agente de IA para comparar las estadísticas de los jugadores entre sí.

1. Navega al directorio backend/lib y crea un archivo llamado elasticAggs.js.

2. Agregar la consulta siguiente para calcular los promedios históricos de un jugador frente a un oponente específico. Esta consulta emplea un filtro bool con 2 condiciones: una que coincide con player_id y otra que coincide con la opponent_team_id, para recuperar solo los juegos relevantes. No necesitamos devolver ningún documento, solo nos importan las agregaciones, así que establecemos size:0. Bajo el bloque aggs , ejecutamos múltiples agregaciones métricas en paralelo en campos como points, rebounds, assists, steals, blocks y fg_percentage para calcular sus valores medios. Los LLMs pueden ser impredecibles con los cálculos y esto transfiere ese proceso a Elasticsearch, cerciorando que nuestro asistente de IA de la NBA tenga acceso a datos precisos.

3. Para calcular los promedios de temporada de un jugador frente a un oponente específico, usaremos prácticamente la misma consulta que la histórica. La única diferencia en esta consulta es que el filtro bool tiene una condición adicional para game_date. El game_date del campo tiene que estar dentro del rango de la temporada actual de la NBA. En este caso, el rango está entre 2024-10-01 y 2025-06-30. Esta condición adicional a continuación garantiza que las agregaciones que sigan aislarán solo los partidos de esta temporada.

Paso 6: Utilidad de comparación de jugadores

Para mantener nuestro código modular y mantenible, crearemos un archivo de utilidad que consolide las funciones auxiliares de metadatos y las agregaciones de Elasticsearch. Esto alimentará la herramienta principal que emplea el agente. Más sobre eso más adelante:

1. Crear un nuevo archivo comparePlayers.js en el directorio backend/lib .

2. Agregar la función siguiente para consolidar los asistentes de metadatos y la lógica de agregación de Elasticsearch en una única función que alimente la herramienta principal empleada por el agente.

Paso 7: Construir el agente

Ahora que creaste el frontend y el backend de estructura, absorbiste datos de los partidos de la NBA y establecido una conexión con Elasticsearch, podemos empezar a juntar todas las piezas para construir el agente.

Definición del agente

1. Navega al archivo index.ts dentro del directorio backend/src/mastra/agents y agrega la definición del agente. Puedes especificar campos como:

• Nombre: Dale a tu agente un nombre que se use como referencia cuando te llamen en el frontend.

• Instrucciones/prompt del sistema: Un prompt del sistema proporciona al LLM el contexto inicial y las reglas a seguir durante la interacción. Es similar al prompt que los usuarios envían a través del cuadro de chat, pero este se da antes de cualquier entrada del usuario. De nuevo, esto cambiará según el modelo que elijas.

• Modelo: ¿Qué LLM usar (Mastra soporta OpenAI, Anthropic, modelos locales, etc.).

• Herramientas: Una lista de funciones de la herramienta que el agente puede llamar.

• Memoria: (Opcional) si queremos que el agente recuerde el historial de conversaciones, etc. Para simplificar, podemos empezar sin memoria persistente, aunque Mastra la admite.

Definición de herramientas

1. Navega al archivo index.ts dentro del directorio backend/src/mastra/tools .

2. Instala Zod usando el comando:

3. Agregar definiciones de herramientas. Ten en cuenta que importamos la función dentro del archivo comparePlayers.js como la función principal que el agente usará al llamar a esta herramienta. Usando la función createTool() de Mastra, registraremos nuestro playerComparisonTool. Los campos incluyen:

• id: Esta es una descripción en lenguaje natural para ayudar al agente a entender qué hace la herramienta.

• input schema: Para definir la forma de la entrada de la herramienta, Mastra emplea el esquema Zod , que es una biblioteca de validación de esquema TypeScript. Zod ayuda cerciorar de que el agente reciba entradas estructuradas correctamente y evita que la herramienta se ejecute si la estructura de entrada no coincide.

• description: Esta es una descripción en lenguaje natural para ayudar al agente a entender cuándo llamar y usar la herramienta.

• execute: La lógica que se ejecuta cuando se llama a la herramienta. En nuestro caso, estamos usando una función auxiliar importada para devolver estadísticas de rendimiento.

Adición de middleware para manejar CORS

Agregar middleware en el servidor Mastra para manejar CORS. Dicen que hay tres cosas en la vida que no puedes evitar: la muerte, los impuestos, y para los desarrolladores web es el CORS. En resumen, el Intercambio de Recursos entre Orígenes es una función de seguridad en el navegador que bloquea al frontend para que no haga peticiones a un backend que se ejecuta en otro dominio o puerto. Aunque ejecutamos tanto el backend como el frontend en localhost, usan puertos diferentes, lo que activa la política CORS. Necesitamos agregar el middleware especificado en la documentación de Mastra para que nuestro backend permita esas peticiones desde el frontend.

1. Navega al archivo index.ts dentro del directorio backend/src/mastra y agrega la configuración para CORS:

• origin: ['http://localhost:5173']

  • Permite solicitudes solo desde esta dirección (dirección predeterminada de Vite)

• allowMethods: ["GET", "POST"]

  • Métodos HTTP que están permitidos. La mayoría de las veces, será usando POST.

• allowHeaders: ["Content-Type", "Authorization", "x-mastra-client-type, "x-highlight-request", "traceparent"],

  • Estos deciden qué encabezados personalizados pueden usar en las solicitudes

Paso 8: Integración del frontend

Este componente React proporciona una interfaz de chat sencilla que se conecta al agente Mastra AI usando el gancho useChat() de @ai-sdk/react. También vamos a usar este gancho para mostrar el uso de tokens, llamadas a herramientas y para renderizar la conversación. En el prompt del sistema anterior, también pedimos al agente que genere la respuesta en markdown, así que usaremos react-markdown para formatear correctamente la respuesta.

1. Mientras estés en el directorio frontend, instala el paquete @ai-sdk/react para usar el hook useChat().

2. Mientras estés en el mismo directorio, instala React Markdown para que podamos formatear correctamente la respuesta que genera el agente.

3. Implementar useChat(). Este gancho gestionará la interacción entre tu frontend y el backend de tu agente de IA. Gestiona el estado del mensaje, la entrada del usuario, el estado y te proporciona ganchos de ciclo de vida para fines de observabilidad. Las opciones que descartamos incluyen:

• api: Esto define el punto final de tu Mastra AI Agent. Por defecto se pone en el puerto 4111 y también queremos agregar la ruta que soporta respuestas en streaming.

• onToolCall: Esto se ejecuta cada vez que el agente llama a una herramienta; Lo estamos usando para rastrear qué herramientas está llamando nuestro agente.

• onFinish: Esto se ejecuta después de que el agente complete una respuesta completa. Aunque activamos el streaming, onFinish seguirá ejecutar luego de recibir el mensaje completo y no luego de cada chunk. Aquí, lo estamos usando para rastrear nuestro uso de tokens. Esto puede ser útil para monitorizar los costos de los LLM y optimizarlos.

4. Por último, ve al componente ChatUI.jsx en el directorio frontend/components para crear la interfaz que mantenga nuestra conversación. A continuación, envuelve la respuesta en un componente ReactMarkdown para formatear correctamente la respuesta del agente.

Paso 9: Ejecutar la aplicación

¡Felicidades! Ahora estás listo para ejecutar la aplicación. Sigue estos pasos para empezar tanto el backend como el frontend.

1. En una ventana de terminal, empezando desde el directorio raíz, navega hasta el directorio backend e inicia el servidor Mestra:

2. En otra ventana de terminal, empezando desde el directorio raíz, navega hasta el directorio frontend e inicia la aplicación React:

3. Ve a tu navegador y navega a:

http://localhost:5173

Deberías poder ver la interfaz del chat. Prueba estos ejemplos de prompts:

• "Compara a LeBron James y Stephen Curry"

• "¿A quién debería elegir entre Jayson Tatum y Luka Doncic?"

Qué sigue: Hacer que el agente sea más inteligente

Para que el asistente sea más agenciado y las recomendaciones más perspicaces, agregaré algunas mejoras clave en la próxima iteración.

Búsqueda semántica de noticias de la NBA

Hay un montón de factores que pueden afectar al rendimiento de los jugadores, muchos de los cuales no aparecen en las estadísticas brutas. Cosas como reportes de lesiones, cambios en la alineación o incluso análisis postpartido, solo se pueden encontrar en artículos de prensa. Para captar este contexto adicional, agregaré capacidades de búsqueda semántica para que el agente pueda recuperar artículos relevantes de la NBA e incluir esa narrativa en sus recomendaciones.

Búsqueda dinámica con el servidor MCP de Elasticsearch

MCP (Model Context Protocol) se está convirtiendo rápidamente en el estándar para cómo los agentes se conectan a fuentes de datos. Migraré la lógica de búsqueda al servidor Elasticsearch MCP, que permite al agente construir consultas dinámicamente en lugar de depender de funciones de búsqueda predefinidas que proporcionamos. Esto nos permite emplear más flujos de trabajo en lenguaje natural y reduce la necesidad de escribir manualmente cada consulta de búsqueda. Descubre más sobre el servidor MCP de Elasticsearch y el estado actual del ecosistema aquí.

Estos cambios ya están en marcha, ¡estad atentos!

Conclusión

En este blog, creamos un asistente RAG agente que ofrece recomendaciones personalizadas para tu equipo de baloncesto de fantasía usando JavaScript, Mastra y Elasticsearch. Cubrimos lo siguiente:

• Fundamentos del RAG agente y cómo combinar la autonomía de un agente de IA con las herramientas para usar RAG de forma eficaz puede conducir a agentes más matizados y dinámicos.

• Elasticsearch y cómo sus capacidades de almacenamiento de datos y poderosas agregaciones nativas lo convierten en un gran socio como base de conocimiento para un LLM.

• El framework Mastra y cómo simplifica la construcción de estos agentes para desarrolladores en el ecosistema javaScript.

Tanto si eres un fanático del baloncesto, explorando cómo crear agentes de IA, o ambos como yo, espero que este blog te dio algunos cimientos para empezar. El repositorio completo está disponible en GitHub, siéntete libre de clonar y trastear. ¡Ahora, gana esa liga de fantasía!

¿Qué es el Protocolo de Contexto Modelo (MCP)?

Para aquellos que no están familiarizados, Model Context Protocol es un estándar abierto que ofrece una forma estructurada y bidireccional de conectar modelos de IA en varias fuentes de datos y herramientas, lo que les permite generar respuestas más relevantes e informadas. Se conoce comúnmente como un "puerto USB-C para aplicaciones de IA".

Aquí hay un diagrama arquitectónico que destaca su naturaleza bidireccional:

Este es un cambio significativo para los profesionales de IA, ya que uno de los principales desafíos para escalar las aplicaciones de IA es tener que crear integraciones personalizadas para cada nueva fuente de datos. MCP ofrece una arquitectura sostenible y reutilizable para gestionar y proporcionar contexto a los modelos. Es independiente del modelo, del servidor y de código abierto.

MCP es la última iteración de un linaje de especificaciones de API que buscan estandarizar la integración entre aplicaciones. En el pasado, teníamos OpenAPI para servicios RESTful, GraphQL para consultas de datos y gRPC para comunicación de microservicios. MCP no solo comparte el rigor estructurado de estas especificaciones más antiguas, sino que también lo lleva a un entorno de IA generativa, lo que facilita la conexión de agentes a diferentes sistemas sin conectores personalizados. En muchos sentidos, MCP tiene como objetivo hacer por los agentes de IA lo que HTTP hizo por el sitio web. Al igual que la comunicación estandarizada HTTP entre navegadores y sitios web, MCP busca estandarizar la forma en que los agentes de IA interactúan con el mundo de datos que los rodea.

MCP frente a otros protocolos de agentes

El panorama del protocolo de agentes se está expandiendo rápidamente, con más de una docena de estándares emergentes que compiten para definir cómo interactúan los agentes. Laurie Voss de LlamaIndex describe cómo la mayoría se puede clasificar en 2 tipos: protocolos interagentes que se centran en que los agentes hablen entre sí y protocolos orientados al contexto como MCP que se centran en ofrecer un contexto estructurado a los LLM.

Otros protocolos populares como A2A (Agent to Agent) de Google, ACP (Agent Communication Protocol) de Cisco e IBM y Agora, tienen como objetivo permitir negociaciones de agente a agente, creación de coaliciones e incluso sistemas de identidad descentralizados. MCP adopta un enfoque un poco más pragmático en eso, ya que se centra en cómo los agentes acceden a las herramientas y los datos y no necesariamente en cómo se comunican entre sí (aunque MCP también podría permitir eso en el futuro de diferentes maneras).

Actualmente, lo que distingue a MCP es su tracción e impulso. Al igual que React en los primeros días de los frameworks frontend, MCP comenzó con un problema de nicho y ahora se encuentra como uno de los protocolos de agente más adoptados y extensibles en la práctica.

Resumen de la cumbre: Evolución de las prioridades para MCP

La cumbre contó con presentadores de colaboradores de Anthropic, Okta, OpenAI, AWS, GitHub y muchos otros. Las conversaciones abarcaron desde mejoras en el protocolo central hasta implementaciones en el mundo real y delinearon prioridades inmediatas y a largo plazo. Estas charlas reflejaron un cambio de la experimentación temprana y la simple llamada de herramientas a la construcción de sistemas de IA confiables, escalables y modulares empleando MCP como base.

Varios presentadores se burlaron de un futuro en el que MCP es más que una simple plomería de protocolo, puede convertir en la base de un sitio web nativo de IA. Al igual que JavaScript permitió a los usuarios hacer clic e interactuar con los sitios web, MCP podría permitir que los agentes lleven a cabo esas mismas acciones en nuestro nombre. Por ejemplo, en el comercio electrónico, en lugar de que los usuarios naveguen manualmente a un sitio web para comprar, simplemente podrían decirle a un agente que inicie sesión, encuentre un producto específico, lo agregue a su carrito y pague.

Esto tampoco es pura especulación y exageración; PayPal mostró su nuevo kit de herramientas para agentes y el servidor MCP en la cumbre, lo que permite esta experiencia de comercio agencial exacta. Con MCP proporcionando acceso seguro y confiable a herramientas y fuentes de datos, los agentes no solo leerán el sitio web, sino que podrán actuar en consecuencia. Hoy en día, MCP ya es un estándar poderoso con mucho impulso y, en el futuro, podría convertir en el estándar de interacciones de usuario mejoradas por IA en el sitio web.

Actualizaciones del proyecto MCP: transporte, elicitación y herramientas estructuradas

Jerome Swannack, colaborador principal de MCP, compartió algunas actualizaciones de la especificación del protocolo de los últimos 6 meses. Los principales objetivos de estos cambios son:

1. Para habilitar MCP remoto con la adición de HTTP Streamable

2. Para habilitar modelos de interacción de agentes más completos con la adición de esquemas de salida de herramientas y elicitación

Dado que MCP es de código abierto, los cambios como Streamable HTTP ya están disponibles para que los desarrolladores los implementen. Los esquemas de elicitación y salida de herramientas no se publicaron actualmente; están en la etapa de draft y pueden evolucionar.

HTTP transmitible (lanzado el 26-03-2025): Una actualización técnica impactante fue la introducción de HTTP transmitible como un nuevo mecanismo de transporte. Esto reemplaza los eventos enviados por el servidor (SSE) con un modelo bidireccional más escalable que admite la codificación de transferencia fragmentada y la entrega progresiva de mensajes a través de una sola conexión HTTP. Esto le permite implementar servidores MCP en una infraestructura en la nube como AWS Lambda y admitir restricciones de red empresarial sin conexiones de larga duración ni necesidad de sondeo.

Elicitation (Publicado el 18-06-2025): Elicitation permite a los servidores definir un esquema sobre cómo quieren que se estructure el contexto de un cliente. Esencialmente, el servidor puede describir lo que necesita y el tipo de entrada que espera. Esto tiene algunas participaciones: Para los creadores de servidores, pueden construir interacciones agenciales más complejas. Para los creadores de clientes, pueden implementar interfaces de usuario dinámicas que se adapten a estos esquemas. Sin embargo, la obtención no debe usar para extraer información confidencial o de identificación personal de los usuarios. Los desarrolladores deben seguir las mejores prácticas para cerciorar de que las indicaciones de elicitación permanezcan seguras y apropiadas, especialmente a medida que MCP madura. Esto se relaciona con preocupaciones de seguridad más amplias que discutiremos más adelante en esta publicación.

Esquemas de salida de herramientas (publicado el 18-06-2025): Este concepto permite al cliente y al LLM conocer las formas de salida de la herramienta con anticipación. Los esquemas de salida de herramientas permiten a los desarrolladores describir lo que se espera que devuelva una herramienta. Estos esquemas abordan una de las principales limitaciones de la llamada directa a herramientas, que es el uso ineficiente de la ventana de contexto. La ventana de contexto se considera uno de los recursos más importantes cuando se trabaja con LLM y cuando se llama directamente a una herramienta, devuelve contenido sin procesar que se inserta por completo en el contexto del LLM. Los esquemas de salida de herramientas pueden ayudarlo a hacer un mejor uso de sus tokens y la ventana de contexto al permitir que el servidor MCP proporcione datos estructurados. Aquí hay algunas mejores prácticas sobre herramientas en general.

Juntas, estas nuevas actualizaciones y futuras adiciones ayudarán a MCP a convertir en un protocolo de agente más modular, tipificado y listo para la producción.

Características de potencia infrautilizadas: ejemplificación y raíces

Si bien no es nuevo en la especificación MCP, tanto la ejemplificación como las raíces se destacaron durante el discurso de apertura. Estas dos primitivas actualmente se pasan por alto y no se exploran, pero pueden contribuir significativamente a interacciones más ricas y seguras entre agentes.

Ejemplificación: los servidores pueden aplicar finalizaciones del cliente: el ejemplificación permite a los servidores MCP aplicar finalizaciones del LLM del lado del cliente. Esto se suma a la naturaleza bidireccional del protocolo, donde el servidor no solo responde a las solicitudes; Puede aplicar y pedir al modelo del cliente que genere una respuesta. Esto permite al cliente mantener un control total sobre el costo, la seguridad y el modelo que emplea el servidor MCP. Por lo tanto, en el caso de emplear un servidor MCP externo con un modelo preconfigurado, no necesitará proporcionar sus propias claves API ni configurar su propia subscripción a ese modelo, ya que el servidor puede simplemente aplicar el modelo ya conectado al cliente. Esto permite comportamientos de agente más complejos e interactivos.

Raíces: acceso con ámbito a los recursos: las raíces se diseñaron para proporcionar una forma a los clientes de informar a los servidores sobre los recursos y áreas de trabajo relevantes en los que centrar. Esto es poderoso para establecer el alcance en el que operan los servidores. Es importante tener en cuenta que las raíces son "informativas y no estrictamente aplicables", lo que significa que no definen derechos o licencias para servidores o agentes MCP. En otras palabras, no puede confiar solo en las raíces para evitar que un servidor o agente ejecute ciertas herramientas o realice acciones de escritura. Con roots, las licencias aún deben manejar en el lado del cliente con mecanismos para las aprobaciones de los usuarios. Además, los desarrolladores deben tener en cuenta el uso de servidores diseñados para respetar los límites establecido por las raíces y emplear las mejores prácticas.

Autenticación para agentes: OAuth 2.1 y metadatos protegidos

Esta sección se centra en OAuth 2.1, que es la última iteración de OAuth 2.0 que elimina los flujos inseguros y consolida las prácticas recomendadas.

El soporte de OAuth era un tema muy esperado, especialmente porque la seguridad y la escalabilidad se consideran los principales obstáculos que impiden que MCP se convierta en el estándar para conectar agentes a herramientas. Aaron Parecki (editor de OAuth 2.1 y experto en estándares de identidad en Okta) discutió cómo MCP puede adoptar un flujo de OAuth limpio y escalable que descarga la mayor parte de la complejidad de los desarrolladores de servidores. La especificación oficial de autorización de OAuth 2.1 se publicó recientemente en la última revisión del protocolo el 18-6-2025.

En esta implementación, las responsabilidades de OAuth se pueden dividir entre el cliente MCP y el servidor. La mayor parte del flujo de autenticación es iniciado y manejado por el cliente MCP, solo involucrando al servidor al final para recibir y verificar el token seguro. Esta división ayuda a resolver un problema crítico de escalado de cómo autenticar en muchas herramientas sin necesidad de que los desarrolladores configuren cada conexión y garantiza que los desarrolladores de servidores MCP no tengan que convertir en expertos en OAuth.

Dos aspectos destacados clave de la charla:

1. Metadatos de recursos protegidos: Los servidores MCP pueden publicar un archivo JSON que describe su propósito, puntos finales y métodos de autenticación. Esto permite a los clientes iniciar flujos de OAuth solo con la URL del servidor, lo que simplifica el proceso de conexión. Más información: Arreglemos OAuth en MCP

2. Soporte para IDP y SSO: las compañías pueden integrar proveedores de identidad para gestionar el acceso de forma centralizada. Esta es una victoria tanto para la experiencia del usuario como para la seguridad. Los usuarios no necesitarían hacer clic en 10 pantallas de consentimiento diferentes y los equipos de seguridad pueden observar cada conexión.

Al enviar la lógica de OAuth al cliente y confiar en los metadatos de los servidores, el ecosistema MCP evita un cuello de botella importante. Esto alinea más estrechamente a MCP con la forma en que se protegen las API modernas en los entornos de producción actuales.

Lectura adicional: OAuth 2 simplificado.

Desafíos de seguridad en un ecosistema componible

Los nuevos desarrollos también vienen con nuevas superficies de ataque. Arjun Sambamoorthy de Cisco enumera varias amenazas clave en el panorama de MCP, que incluyen:

Perfiles

Descripción

Remediación y mejores prácticas

Inyección rápida y envenenamiento de herramientas

Una forma de inyectar un mensaje malicioso dentro del contexto del sistema LLM o la descripción de la herramienta, lo que hace que el LLM realice acciones no deseadas como leer archivos o filtrar datos.

Emplee herramientas como MCP Scan para realizar comprobaciones de los metadatos de la herramienta. Valide las descripciones y los parámetros antes de incluirlos en las solicitudes. Por último, considere implementar aprobaciones de usuarios para herramientas de alto riesgo. Para obtener más detalles, consulte la guía de inyección rápida de OWASP en la lista de lectura adicional debajo de la tabla.

Ataques de ejemplificación

En el contexto de MCP, la ejemplificación abre la puerta para que el servidor MCP realice ataques de inyección rápida en el LLM.

Deshabilite la ejemplificación para servidores que no son de confianza y considere la posibilidad de agregar aprobaciones de personas en el bucle para las solicitudes de ejemplificación.

Servidores MCP maliciosos

En las colecciones actuales de servidores MCP, es difícil examinar todos y cada uno de ellos para garantizar la seguridad. Los servidores no autorizados pueden recopilar y exponer silenciosamente sus datos a actores maliciosos.

Conectar únicamente a servidores MCP desde registros confiables o listas internas. Ejecute servidores de terceros en contenedores con sandboxing.

Herramientas de instalación de MCP maliciosas

Los instaladores y scripts de línea de comandos son convenientes para implementar rápidamente servidores o herramientas MCP, pero podría terminar instalando código comprometido y no verificado.

Instale en entornos de espacio aislado y valide las firmas de los paquetes. Nunca actualice automáticamente desde fuentes no verificadas.

Para combatir aún más esto, Arjun sugiere un registro de MCP confiable para manejar todas las verificaciones (un tema que estaba al frente y al centro; para obtener más detalles, consulte los dos elementos principales en la lista de lectura a continuación), así como el uso de esta lista de verificación de seguridad.

Lectura adicional:

• Mejores prácticas oficiales de seguridad de MCP

• Top 10 de aplicaciones de OWASP LLM

• Investigación de amenazas de HiddenLayer

• Escaneo MCP

• Guía de inyección rápida de OWASP

Lo que sigue: Registros, gobernanza y ecosistema

Se está desarrollando un registro centralizado de MCP y fue uno de los temas más discutidos en la cumbre. El ecosistema actual de servidores sufre de fragmentación, baja confianza y capacidad de descubrimiento. Es difícil para los desarrolladores encontrar servidores MCP, verificar lo que hacen e instalarlos de forma segura, especialmente en un ecosistema descentralizado donde los metadatos pueden estar incompletos o falsificados.

Un registro centralizado aborda estos puntos débiles directamente al actuar como una fuente confiable de verdad, mejorando la capacidad de descubrimiento, cerciorando la integridad de los metadatos del servidor y reduciendo el riesgo de instalar herramientas maliciosas.

Los objetivos del registro MCP son:

• Ofrecer una única fuente de verdad para los metadatos del servidor (qué hace un servidor, cómo autenticarlo, instalarlo y llamarlo)

• Deshacer de los registros de terceros incompletos y la fragmentación para que cuando un servidor quiera registrar, no tenga que actualizar todos los demás registros en el Internet.

• Proporcionar un flujo de registro de servidor que incluya una herramienta CLI y un archivo server.json que contenga los metadatos mencionados anteriormente.

La esperanza más amplia es que un registro confiable ayude a escalar el ecosistema de manera segura, permitiendo a los desarrolladores crear y compartir nuevas herramientas con confianza.

La gobernanza fue otro tema prioritario para Anthropic. Dejaron en claro que MCP debe permanecer abierto e impulsado por la comunidad, pero escalar ese modelo de gobernanza aún es un trabajo en progreso. Actualmente están buscando ayuda en ese campo y piden a cualquier persona que tenga experiencia con la gobernanza en protocolos de código abierto que se comunique. Esto lleva al otro tema que quería mencionar. A lo largo del evento, los presentadores enfatizaron que el ecosistema solo puede crecer con las contribuciones de los desarrolladores internos. Es necesario que haya un esfuerzo concentrado para hacer de MCP el nuevo estándar sitio web y destacar de los otros protocolos de agentes populares.

MCP en el mundo real: estudios de casos y demostraciones

Varias organizaciones compartieron cómo MCP ya se está empleando en aplicaciones prácticas:

• PayPal - Servidor MCP para Comercio Agentico: PayPal presentó su nuevo kit de herramientas para agentes y el servidor MCP, que pueden cambiar fundamentalmente la experiencia de compra de un usuario. En lugar de buscar en las redes sociales para encontrar artículos, comparar precios y pagar, los usuarios pueden chatear con un agente que se conecta al servidor MCP de PayPal para manejar todas esas acciones.

• EpicAI.pro - Jarvis: Los desarrollos en MCP nos acercan cada vez más a tener un asistente tipo Jarvis de la vida real. Para aquellos que no están familiarizados con las películas de Iron Man, Jarvis es un asistente de IA que usa lenguaje natural, responde a entradas multimodales, tiene latencia cero al responder, es proactivo en anticipar las necesidades del usuario, gestiona integraciones automáticamente y puede cambiar de contexto entre dispositivos y ubicaciones. Si imaginamos a Jarvis como un asistente robótico físico, MCP le da a Jarvis "manos" o la capacidad de manejar tareas complejas.

• Postman - Generador de servidores MCP: Proporciona una experiencia de carrito de compras para solicitudes de API donde puede elegir diferentes solicitudes de API, ponerlas en una cesta y descargar toda la cesta como un servidor MCP.

• Bloomberg - Bloomberg resolvió un cuello de botella clave en el desarrollo empresarial de GenAI. Con casi 10,000 ingenieros, necesitaban una forma estandarizada de integrar herramientas y agentes en todos los equipos. Con MCP, transformaron sus herramientas internas en componentes modulares y remotos a los que los agentes pueden llamar fácilmente en una interfaz unificada. Esto permitió a sus ingenieros contribuir con herramientas en toda la organización, mientras que los equipos de IA se centraron en crear agentes en lugar de integraciones personalizadas. Bloomberg ahora admite flujos de trabajo de agentes escalables y seguros que desbloquean la interoperabilidad total con el ecosistema MCP. Bloomberg no vinculó ningún recurso público, pero esto es lo que presentaron en público en la cumbre.

• Bloquear- Block emplea MCP para impulsar Goose, un agente interno de IA que permite a los empleados automatizar tareas en ingeniería, ventas, marketing y más. Construyeron más de 60 servidores MCP para herramientas como Git, Snowflake, Jira y Google Workspace para permitir la interacción del lenguaje natural con los sistemas que usan todos los días. Los empleados de Block ahora usan Goose para consultar datos, detectar fraudes, gestionar incidentes, navegar por procesos internos y más, todo sin tener que escribir código. MCP ayudó a Block a escalar la adopción de IA en muchas funciones laborales en solo 2 meses.

• AWS - Servidores MCP de AWS: AWS presentó un divertido servidor MCP con temática de Dungeons and Dragons que simula tirar dados, realiza un seguimiento de las tiradas anteriores y devuelve resultados mediante HTTP transmitible. Este ejemplo ligero destacó lo fácil que es crear e implementar servidores MCP empleando herramientas e infraestructura de AWS como Lambda y Fargate. También presentaron Strands SDK, un conjunto de herramientas de código abierto para crear agentes multimodales que interactúan con los servidores MCP.

Soporte para MCP en Elastic Agent Builder

Puedes empezar a experimentar con MCP hoy mismo usando Elastic Agent Builder, que es la forma más sencilla de construir agentes directamente sobre tus datos. Agent Builder te permite exponer herramientas impulsadas por Elasticsearch a agentes compatibles con MCP y ya incluye algunas herramientas integradas poderosas, entre ellas:

• platform.core.search - Ejecuta búsquedas usando el DSL completo de Elasticsearch Query

• platform.core.list_indices - Lista todos los índices disponibles dentro de Elasticsearch (ayuda a los agentes a descubrir qué datos existen)

• platform.core.get_index_mapping - Recupera mapeos de campos para un índice específico (ayuda a los agentes a entender la forma y los tipos de tus datos)

• platform.core.get_document_by_id - Obtiene un documento específico por ID (para una recuperación precisa)

Solo con estas herramientas, puedes dotar a tu agente de búsqueda y relevancia a nivel empresarial, lo cual es fundamental para construir agentes de IA fiables.

Lo que hace que Agent Builder sea aún más poderoso es la capacidad de definir y exponer tus propias herramientas personalizadas adaptadas a las necesidades de tu aplicación. Esto es especialmente útil para flujos de trabajo con opiniones o repetibles, donde quieres que el agente realice un tipo específico de búsqueda contra un índice concreto sin tener que redescubrir esa lógica cada vez. En lugar de gastar tokens en planeación y razonamiento para llegar a la misma conclusión, puedes codificar esa intención directamente en una herramienta, haciendo que tus agentes sean más rápidos, fiables y rentables.

Dentro de la interfaz de Agent Builder, aquí tienes un ejemplo de definición personalizada de herramienta que emplea ES|QL:

Una vez que definiste tus herramientas personalizadas, puedes exponerlas (además de las herramientas nativas integradas) usando MCP haciendo clic en el desplegable para Manage MCP y copiando la URL del servidor MCP.

Ahora puedes importar este endpoint MCP a cualquier cliente que consuma MCP para conectarlo a Agent Builder y darle acceso a todas las herramientas disponibles. Para más información, lee esta introducción a Agent Builder.

Conclusión

La Cumbre de Desarrollo de MCP dejó en claro que MCP está dando forma a la forma en que estos agentes de IA interactúan entre sí y con el mundo de datos que los rodea. Ya sea que esté conectando un agente a los datos de la compañía o diseñando agentes totalmente autónomos, MCP ofrece una forma estandarizada y componible de integración que se está volviendo rápidamente útil a escala. Desde los protocolos de transporte y los patrones de seguridad hasta los registros y la gobernanza, el ecosistema MCP está madurando rápidamente. MCP seguirá siendo abierto e impulsado por la comunidad, por lo que los desarrolladores de hoy tienen la oportunidad de dar forma a su evolución.