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.
Everything in this series was building to this. You can prove a model works
(part 1), make its output machine-reliable
(part 2), generate real test data
(part 3), and observe production
(part 4). Now we spend all four skills at once on
the pattern behind almost every serious LLM product: RAG — retrieval-augmented generation.
We'll build a docs assistant: a containerized HTTP service that answers customer questions
from WEC's own documentation. Not a notebook — a service, Docker-first, the shape you'd actually
deploy. And because this series doesn't do happy-path demos: along the way our RAG hallucinates a
GPU price, we root-cause it to our own scraper, fix it, and pin the fix with a regression
test. Every command, number, and error below is from a real run.
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, 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 la misma 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 las fallas 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.