21 publicaciones etiquetados con "ai"

++

La Parte 3 le dio a un agente cinco herramientas por MCP — un calendario, una lista de clientes, facturas y un reembolso — y puso a un humano delante del reembolso. Terminó admitiendo lo evidente: un solo agente tenía las cinco. Nada impedía que el modelo echara mano de issue_refund cuando se le había pedido reservar una cita. La pausa humana era lo único que se interponía, y una pausa solo se dispara si el modelo llega a llamar la herramienta.

Esta parte quita la herramienta en su lugar. El de agenda recibe tres y el de facturación tres, compartiendo una. Pídele al de agenda que reembolse una factura y no puede — no porque se le haya dicho que no, no porque una política lo bloquee, sino porque issue_refund nunca estuvo en la lista que se le dio.

Luego el supervisor de la Parte 2 vuelve encima, y sale a la luz la propiedad interesante: el enrutado decide quién trabaja, el alcance decide qué es posible. Un reembolso mal enrutado sigue sin poder reembolsar.

++

La Parte 1 le dio a un agente un estado que sobrevive a un reinicio, y una pausa donde un humano aprueba antes de que continúe. La Parte 2 puso un supervisor delante de un agente de agenda y uno de facturación, y repartió el trabajo entre ellos.

Ninguno de esos agentes agendó ni facturó nada. Lo comentaron. Cada herramienta que tenían era una función que tú escribiste en el mismo proceso, y las interesantes — buscar un cliente, ocupar un hueco, mover dinero — no existían.

Esta parte construye la caja de herramientas que esos dos roles necesitan, por MCP: un calendario, una lista de clientes, facturas y un reembolso. Para reducir piezas móviles apuntamos un agente a las cinco herramientas en lugar de reconstruir el supervisor de la Parte 2 — el agente las descubre en tiempo de ejecución en vez de estar cableado a ellas, las encadena para responder una pregunta, y escribe filas que puedes ir a comprobar en la base de datos después. Luego el reembolso lo detiene en seco y hace que un humano teclee el importe.

Repartir estas herramientas de vuelta entre el agente de agenda y el de facturación — de modo que el de agenda no pueda ver issue_refund en absoluto — es el siguiente paso natural, y la última sección explica cómo.

En julio la especificación de MCP eliminó las sesiones por completo. El día que ejecutamos esto, LangChain publicó el soporte para esa revisión en el paquete principal. Así que esta es una primera ejecución contra un protocolo de cinco semanas y un cliente del mismo día — que es justo por lo que tres cosas de aquí no están todavía en la documentación de nadie.

++

Tienes dos agentes. Uno reserva citas. Otro gestiona facturación.

Llega un ticket que necesita los dos: cambia la fecha de mi instalación, y mi factura parece incorrecta. Así que lo envías a los dos.

El primero reserva el martes. El segundo ve que la cuenta está en mora y la congela. Los dos terminan casi en el mismo momento, y los dos guardan lo que decidieron.

Solo se guarda uno de ellos. ¿Cuál? El que terminó primero — que depende de lo lenta que estuviera una llamada de API ese día. Así que reservas una cita en una cuenta congelada, o congelas una cuenta a la que acabas de prometerle un ingeniero. Después parece que se tomó una única decisión limpia.

La Parte 1 construyó un agente que ejecuta sus pasos en un orden fijo. Este post tiene varios: un supervisor que elige quién trabaja en qué, un agente que pasa el trabajo a otro a mitad de camino, y dos agentes puestos en el camino del otro a propósito — para descubrir qué hace LangGraph cuando no están de acuerdo.

++

Tu agente lleva cuarenta segundos trabajando en la petición de un cliente. Ha leído el ticket, ha consultado la cuenta y ha revisado los calendarios de tres ingenieros. Está a punto de reservar la cita.

Entonces el proceso muere. Un despliegue que sale, el host que se queda sin memoria, alguien que reinicia el contenedor — da igual cuál de ellos.

El agente no continúa donde lo dejó, porque no hay nada desde donde continuar. Todo lo que aprendió vivía en variables dentro de un proceso que ya no existe. El cliente sigue esperando. Ejecútalo de nuevo y pagas todo ese trabajo por segunda vez. Y la parte que más debería preocuparte: nadie puede decir si la cita se reservó en el último segundo antes de morir.

Un agente es un modelo dentro de un bucle. Como script de Python normal, ese bucle es exactamente igual de frágil que el proceso que lo contiene.

Aquí construimos uno que guarda su estado en Postgres después de cada paso, para que una caída no cueste nada.

+

En Parte 1 alojaste Hermes con memoria persistente. Esta parte lo conecta al mismo bot de Telegram de la serie OpenClaw — el chat que tus usuarios ya conocen sigue funcionando exactamente como antes, solo que con un agente diferente respondiendo detrás. No hay un nuevo bot que anunciar, ni un canal al que migrar a la gente.

+

Supón que has construido un chatbot de soporte o un asistente RAG en WEC. Es sólido en tus documentos y en lo que el modelo ya sabe, pero pregúntale algo actual ("¿cuál es la última versión de X?", precios de hoy, un cambio reciente) y o bien adivina o te dice que su conocimiento está desactualizado. Para cualquier cosa que necesite estar al día, eso es una verdadera brecha.

WEC Inference ahora tiene una herramienta de búsqueda web integrada. Agrégala a una llamada normal /v1/chat/completions y el modelo puede buscar cosas en la web en vivo: la búsqueda se realiza en la propia infraestructura de WiLine (SearXNG), por lo que nada se envía a un proveedor de búsqueda de terceros. Vamos a probarlo.

Un agente que llama a herramientas hace dos cosas muy diferentes: razona ("Debería buscar en la documentación") y actúa (realmente llama a la herramienta). Cuando algo sale mal, la primera pregunta siempre es qué capa falló — ¿pensó mal o se rompió la acción? Un registro plano no puede responder eso. Un trazado puede.

En este tutorial, construirás un pequeño agente que llama a herramientas en WEC Inference, lo instrumentarás con Langfuse para que cada paso de razonamiento y cada llamada a la herramienta se conviertan en un nodo inspeccionable, y luego depurarás dos fallos reales del árbol de trazado — incluyendo el peor tipo: una respuesta incorrecta y confiada que nunca lanza un error. Cada comando, error y captura de pantalla a continuación proviene de una ejecución real.

++

La mayoría de las guías de "autoalbergar un asistente de IA para WhatsApp" se detienen en "el contenedor se inició". Esta va hasta el final: despliegas una puerta de enlace de WhatsApp programable real (API de Evolution), luego escribes el puente tú mismo — las ~50 líneas que convierten un mensaje entrante en una respuesta de LLM y la envían de vuelta. Ese puente (webhook → modelo → respuesta) es el patrón reutilizable detrás de cada integración de chat-AI: SMS, Slack, Telegram, voz — cambia el canal, la forma es idéntica.

Y porque esto es una construcción real, encontramos — y solucionamos — cada detalle: una imagen que movió a los editores, un bucle de versión de Baileys, un bucle de respuesta infinito, spam en grupos de chat, la nueva dirección LID de WhatsApp, y una genuina pared de entrega que la mayoría de los tutoriales pretenden que no existe. Cada comando, error y salida a continuación es de una ejecución real.

+

Telegram (Parte 3) le dio a tu agente un bot. WhatsApp le da una línea telefónica — la aplicación que ~3 mil millones de personas ya usan, accesible sin fricción. Una advertencia que vale la pena entender desde el principio: WhatsApp no tiene cuenta de bot, así que OpenClaw se vincula a un número real como un dispositivo compañero (como WhatsApp Web) y el agente actúa como esa cuenta. Cada comando y error a continuación proviene de una ejecución real.

++

Nuestro análisis de economía de tokens de GPT-5.6 terminó con un desafío: las promesas de referencia son una hipótesis, no una razón — ejecuta la evaluación en tu carga de trabajo antes de que creas en un reclamo de "menos tokens por tarea". Este tutorial es nosotros siguiendo nuestro propio consejo.

Tomamos el asistente de documentos RAG de parte 5, lo envolvemos en una suite de regresión DeepEval — en contenedor, juzgada por gemma4 en la API de Inferencia WEC, sin dependencia de OpenAI — y luego usamos esa suite para responder a una pregunta genuinamente abierta: ¿deberíamos cambiar el modelo de generación del servicio? Qwen2.5-3B-Instruct (actual) vs gemma4 (candidato), tasa de aprobación y tokens por tarea, medidos cara a cara.

Spoiler: la evaluación nos salvó de una migración innecesaria. Y en el camino encontramos cuatro fallos reales de producción: un espiral mortal por disco lleno, una condición de carrera en el arranque, una trampa de variable de Docker Compose que evaluó silenciosamente el modelo incorrecto, y la solución que hace que esa clase de error sea imposible. Cada comando, número y error a continuación proviene de una ejecución real.

++

Todo en esta serie apuntaba a esto. Sabes demostrar que un modelo funciona (parte 1), hacer su salida fiable para máquinas (parte 2), generar datos de prueba reales (parte 3) y observar producción (parte 4). Ahora gastamos las cuatro habilidades a la vez en el patrón que está detrás de casi todo producto LLM serio: RAG — generación aumentada por recuperación.

Vamos a construir un asistente de documentación: un servicio HTTP en contenedor que responde preguntas de clientes desde la propia documentación de WEC. No un notebook — un servicio, Docker primero, con la forma que realmente desplegarías. Y como esta serie no hace demos del camino felíz: por el camino nuestro RAG alucina un precio de GPU, encontramos la causa en nuestro propio scraper, la arreglamos y fijamos el arreglo con un test de regresión. Cada comando, número y error de abajo viene de una ejecución real.

Un cliente dice que tu bot de soporte les prometió una política de reembolso que no existe. Tu función hizo dos llamadas LLM: clasificar y luego responder. ¿Cuál de ellas la inventó? Si no puedes responder eso, tu aplicación es una caja negra — y esta guía soluciona exactamente eso.

Ahora puedes probar que un modelo funciona (parte 1), hacer que su salida sea confiable para máquinas (parte 2), y generar un conjunto de pruebas real para verificarlo (parte 3). Pero todo eso se ejecuta fuera de línea, en CI, con entradas que elegiste. La producción no juega de esa manera.

Esta guía cierra la brecha. Autoalojaremos Langfuse — la alternativa de código abierto y autoalojable a LangSmith — rastrearemos cada llamada real, evaluaremos automáticamente el tráfico en vivo con un juez LLM, profundizaremos en el paso exacto que falla y retroalimentaremos los fallos para que tu conjunto de datos de la parte 3 se vuelva más fuerte. La evaluación fuera de línea te dice que funcionó en tu conjunto de pruebas; esto te dice que funciona en el mundo real.

++

Tu evaluación pasa el 100% — de los dos casos de prueba que escribiste a mano. Los usuarios reales no expresarán las cosas como tú lo hiciste.

En parte 1 y parte 2 construimos un arnés de evaluación real — afirmaciones, validación de esquema, una matriz de modelos. Pero dos casos no pueden decirte si tu aplicación funciona; solo pueden decirte que no se bloqueó con dos entradas.

Esta guía soluciona eso. La habilidad es producir un conjunto de datos en el que realmente puedas confiar: usamos la API de Inferencia de WEC para generar tickets etiquetados, luego validarlos y curarlos — porque las etiquetas generadas no son automáticamente correctas, y tratarlas como verdad solo mueve el error. El resultado es datos de prueba reales a gran escala. Cuando finalmente lo ejecutes a través del arnés de la parte 2, la cobertura revela las fallas — malas clasificaciones genuinas y etiquetas debatibles — que dos casos seleccionados a mano ocultan.

++

"Devuelve solo JSON" es una de las instrucciones más comunes en aplicaciones LLM en producción — y una de las menos fiables. Los modelos envuelven JSON en cercas de markdown, añaden una frase amigable, o (si son modelos de razonamiento) narran todo su proceso de pensamiento alrededor de ello. Cualquiera de esos casos rompe un estricto JSON.parse, y tu pipeline se cae.

En esta guía construimos una evaluación de Promptfoo que hace que los modelos de API de Inferencia WEC clasifiquen tickets de soporte en JSON validado por esquema, luego lo endurecemos contra el desorden del mundo real — y lo usamos para elegir un modelo en el que realmente puedes confiar. Esta es la parte 2 de la serie de evaluaciones (consulta parte 1 para la configuración inicial). Todo aquí se ejecutó en vivo contra https://inference.wiline.com.

+

No enviarías código sin pruebas — pero la mayoría de los equipos envían funciones LLM con "se ve bien para mí." Evaluaciones (evals) solucionan eso: defines casos de prueba y criterios de aprobación/fallo, luego mides tu modelo objetivamente — detectando regresiones, comparando modelos y bloqueando despliegues.

En esta guía construirás un verdadero arnés de evaluación con Promptfoo apuntando a la API de Inferencia WEC — el mismo punto final compatible con OpenAI que llamas desde tus aplicaciones. Todo aquí se ejecutó en vivo contra https://inference.wiline.com; las salidas son reales.

+

A través de Partes 1–4 implementaste OpenClaw, lo aseguraste con HTTPS, añadiste Telegram y lo hiciste privado a través de una malla NetBird — todo apuntando a OpenAI. Esta parte intercambia el modelo por debajo: apunta el mismo agente a Modelos WEC — la inferencia compatible con OpenAI de WiLine — y ejecútalo en un modelo de peso abierto, Llama 3.1 8B Instruct. Misma caja, sin reconstrucción — solo un cambio de base-URL, clave y modelo a través de la CLI de OpenClaw.

+

Hermes Agent es el agente de IA de código abierto (MIT) de Nous Research — "el agente que crece contigo." Su característica destacada es memoria persistente: aprende sobre tus proyectos y no olvida entre reinicios. Esta guía lo despliega en la misma Instancia WEC que ya usas para OpenClaw, lo apunta a un modelo y prueba que la memoria sobrevive a un reinicio completo.

+

En Artículo 2 colocamos Caddy frente a OpenClaw para HTTPS, y en Artículo 3 agregamos un canal de Telegram. La puerta de enlace funciona — pero Caddy sigue escuchando en 0.0.0.0, accesible por cualquier cosa que pueda enrutar hacia la caja. Este es el proyecto final de la serie: unimos el servidor y tu laptop a una malla NetBird, redirigimos openclaw.local a la IP de la malla y cerramos los puertos públicos. La misma URL https://openclaw.local/chat sigue funcionando — pero solo para tus dispositivos. Cada comando y error a continuación proviene de la ejecución real.

+

Has desplegado OpenClaw y lo has asegurado detrás de HTTPS. Ahora hazlo utilizable — habla con tu agente desde tu teléfono a través de Telegram. Creamos un bot, lo conectamos, limpiamos la puerta de emparejamiento de OpenClaw y obtenemos una respuesta real. Cada comando y detalle a continuación proviene de una ejecución real.

+

En Artículo 1 hicimos funcionar OpenClaw — pero solo a través de HTTP sin cifrar, con un workaround allowInsecureAuth. Aquí colocamos Caddy frente a él como un proxy inverso: verdadero HTTPS, autenticación emparejada por dispositivo, y los puertos del gateway cerrados para que el proxy sea la única forma de acceso. Cada comando y error a continuación proviene de la implementación real.

++

Tu asistente de IA no tiene que vivir en la nube de otra persona.

Despliega un agente de IA OpenClaw autoalojado en una instancia WEC con Docker Compose — desde iniciar la VM hasta un agente que realmente responde, usando tu propia clave de API de modelo. Cada comando, versión y error a continuación fue capturado de un despliegue real en una instancia WEC.