OpenClaw on KnightLi Blog

Cómo ve el desarrollo de software con IA Peter Steinberger, creador de OpenClaw: de OpenClaw a la programación en bucle cerrado

Sun, 17 May 2026 20:02:26 +0800

La trayectoria de Peter Steinberger sirve para observar qué está cambiando en el desarrollo de software con IA.

No es un recién llegado que se hizo visible de repente gracias a la IA. Antes de OpenClaw, ya era fundador de PSPDFKit, una empresa dedicada a renderizado PDF, procesamiento de documentos y herramientas para desarrolladores. Este tipo de producto no gana solo con narrativa: debe resolver rendimiento, compatibilidad, diseño de API, clientes empresariales y mantenimiento a largo plazo.

Por eso, cuando Steinberger construyó OpenClaw con herramientas de IA y empezó a hablar de AI Agent, automatización personal y AI coding, lo importante no fue solo que “una persona escribió mucho código”. Lo más interesante es cómo combinó años de experiencia en ingeniería de software con una nueva generación de AI coding agents para reinterpretar el proceso de desarrollo.

AI coding no es un botón mágico

Muchas discusiones sobre AI coding se reducen a dos extremos.

Uno dice que la IA ya puede escribir código y que los programadores pronto no serán necesarios.

El otro dice que el código generado por IA no es fiable y que la ingeniería real debe seguir escribiéndose a mano.

La experiencia de Steinberger apunta a una tercera idea: la IA cambia la unidad de operación del desarrollo de software, pero no elimina el juicio de ingeniería.

Antes, el trabajo del desarrollador giraba alrededor de editar código. Descomponer requisitos, decidir arquitectura, implementar, probar y corregir bugs se organizaba alrededor de cambios manuales.

Cuando entran AI coding agents, el desarrollador empieza a parecerse más a alguien que gestiona un sistema de ejecución:

Explicar el objetivo.
Proporcionar contexto.
Definir límites.
Dejar que el agent modifique código.
Ejecutar pruebas y comprobaciones.
Iterar según los resultados.

Esto no es simplemente entregar el teclado al modelo. Es pasar de “escribir cada línea a mano” a “definir dirección, diseñar feedback y juzgar resultados”.

Por qué no le convence llamarlo vibe coding

Una expresión frecuente alrededor de Steinberger es vibe coding.

El término nació para describir una nueva forma de desarrollo: el desarrollador describe ideas en lenguaje natural, deja que la IA genere mucho código y luego ajusta con resultados de ejecución y feedback.

Pero Steinberger no está del todo de acuerdo con esa etiqueta. En cobertura pública se ha señalado que ve vibe coding como una expresión que puede volverse despectiva, porque sugiere que el desarrollo asistido por IA es solo “generar por intuición” e ignora la habilidad, el juicio y la experiencia detrás.

La crítica tiene sentido.

El AI coding efectivo no consiste en escribir una frase casual y confiar en la salida del modelo. Requiere:

Convertir requisitos vagos en tareas ejecutables.
Detectar si el modelo entendió mal el objetivo.
Diseñar pruebas y criterios de aceptación.
Juzgar si la estructura del código será mantenible.
Saber cuándo dejar de generar y pasar a revisión humana.

En otras palabras, la IA reduce la fricción de escribir código, pero no reduce la responsabilidad de entender el sistema.

La clave es el bucle

Una idea que se asocia con frecuencia a entrevistas y textos de Steinberger es el bucle.

Dejar que la IA genere código es un proceso de bucle abierto.

Dejar que la IA genere código, lo ejecute, lea errores, corrija problemas y vuelva a ejecutar pruebas se acerca más a un bucle cerrado.

La diferencia es importante.

La generación en bucle abierto crea con facilidad software que parece utilizable. La página abre, las funciones parecen existir y hay bastante código. Pero al entrar en escenarios reales aparecen problemas de estado, permisos, manejo de errores, casos límite y despliegue.

El desarrollo en bucle cerrado exige que la salida esté limitada por feedback. El bucle más simple es:

Escribir claramente el objetivo.
Dejar que la IA modifique el código.
Ejecutar automáticamente pruebas, type checks, lint o build.
Devolver los errores a la IA.
Repetir hasta que pase.
Hacer una revisión humana de la ruta crítica.

Ahí es donde el desarrollo de software con IA puede mejorar de verdad la eficiencia. No porque el modelo acierte a la primera, sino porque puede participar rápidamente en el ciclo de generar, validar y reparar.

Cuanta más experiencia, mejor se usa la IA

Uno de los malentendidos más comunes sobre AI coding es que la experiencia deja de importar.

El caso de Steinberger sugiere lo contrario: la experiencia importa más, aunque su función cambia.

Un ingeniero con experiencia juzga mejor:

Qué tareas conviene pasar a un agent.
Qué módulos necesitan pruebas primero.
Qué cambios son demasiado riesgosos para una refactorización amplia con IA.
Qué código generado solo parece razonable.
Qué problemas deberían resolverse con arquitectura y no con más parches.

La IA puede generar muchas soluciones candidatas, pero cuantas más opciones hay, más juicio se necesita. Alguien sin experiencia puede quedar impresionado porque “funciona”. Un ingeniero con experiencia pregunta: ¿se puede mantener? ¿se puede extender? ¿rompe límites de seguridad? ¿se puede depurar si falla?

Por eso los AI coding agents no convierten la ingeniería de software en puro chat. Más bien externalizan una parte del trabajo de ejecución y amplifican la importancia de planificar, revisar, validar y decidir trade-offs.

OpenClaw importa más allá del proyecto

OpenClaw llamó la atención no solo porque es un AI agent open source, ni solo porque creció rápido.

También funciona como señal: los desarrolladores empiezan a querer que la IA no solo responda preguntas, sino que se conecte a herramientas reales y ejecute acciones reales.

Los chatbots tradicionales se quedan dentro de la caja de conversación. Pueden explicar código, escribir borradores y dar consejos, pero muchas veces una persona todavía debe copiar, pegar, abrir software y ejecutar comandos.

La dirección de los agents es conectar modelos con herramientas:

Sistema de archivos.
Navegador.
Terminal.
Email.
Calendario.
Servicios de terceros.
Repositorios de proyecto.

Cuando los modelos pueden usar esas herramientas, cambian los límites del desarrollo de software. La IA deja de ser solo autocompletado de código y participa en lectura de proyectos, descomposición de tareas, edición de archivos, ejecución de pruebas, preparación de PR y automatización de workflows.

Por eso también llamó la atención la incorporación de Steinberger a OpenAI. No representa solo una historia individual de desarrollador, sino una dirección de producto: los agents personales pasarán de demos a la capa de trabajo diaria.

Qué significa para desarrolladores comunes

Para desarrolladores comunes, la experiencia de Steinberger no se puede copiar directamente en todos los casos.

No todo el mundo puede gestionar varios agents a la vez. No todos los proyectos toleran generación intensa con IA. No todos los equipos aceptan el ritmo de “generar primero e iterar rápido”.

Pero hay varias lecciones útiles.

Primero, escribir tareas con claridad.

La IA es sensible a objetivos vagos. Si dices “optimiza esto”, puede cambiar estilo, estructura, funciones y lógica. Si dices “cambia el mensaje de error al fallar el login de inglés a chino sin alterar el flujo de autenticación”, el resultado suele ser más controlable.

Segundo, fijar comandos de validación.

Si un proyecto no tiene pruebas, build ni lint, la IA tiene dificultades para formar un bucle. Incluso comandos básicos como npm test, go test ./..., pytest o hugo son mejores que revisar solo a ojo.

Tercero, controlar el alcance del cambio.

Pedir a la IA que trabaje en un módulo, un bug o una página cada vez suele ser más fiable que pedirle “refactoriza todo el proyecto”.

Cuarto, mantener revisión humana.

En autenticación, pagos, permisos, eliminación de datos, scripts de despliegue, migraciones de base de datos y configuración de seguridad, no bajes el estándar de revisión solo porque el código lo generó IA.

Quinto, revisar prompts y patrones de fallo.

Si la IA malinterpreta a menudo cierto tipo de tarea, escribe esas restricciones en reglas del proyecto, agent instructions o archivos de skill. La capacidad de AI coding no viene solo del modelo, sino también del entorno de trabajo que construyes alrededor.

Hacia dónde va el desarrollo de software con IA

La historia de Steinberger muestra que el desarrollo de software con IA se mueve desde “ayudar a escribir código” hacia “organizar flujos de producción de software”.

Las primeras herramientas de AI coding servían sobre todo para completar funciones, explicar errores y generar plantillas. El cambio actual es que los agents pueden trabajar entre archivos, llamar herramientas, ejecutar comprobaciones y seguir corrigiendo con feedback.

Esto apunta a varias tendencias.

Primero, subirá el techo productivo de los desarrolladores individuales.

Una persona puede avanzar más prototipos, scripts, herramientas internas y productos pequeños. Pero producir más no significa producir mejor automáticamente. Cuanto más rápido se genera, más importante es validar.

Segundo, la estructura del proyecto será más importante.

Cuanto más claro sea el código, más explícitas las pruebas y más completa la documentación, más fácil será que la IA haga cambios correctos. Los proyectos caóticos son difíciles para humanos y para IA.

Tercero, los ingenieros de software se parecerán más a diseñadores de workflows.

En el futuro no importará solo conocer un lenguaje, sino saber organizar requisitos, contexto, herramientas, pruebas, despliegue y permisos en un bucle controlable.

Cuarto, los límites de seguridad serán más sensibles.

Si un agent puede hacer cosas, también puede hacer cosas equivocadas. Si puede leer archivos, ejecutar comandos y acceder a servicios, permisos, auditoría y rollback se vuelven infraestructura básica del entorno de desarrollo con IA.

Resumen

Lo más valioso de la visión de Peter Steinberger sobre desarrollo de software con IA no es “cuánto código generó la IA”, sino la nueva postura de desarrollo que muestra.

Las personas ya no solo escriben línea por línea dentro del editor. Diseñan objetivos, gestionan agents, construyen bucles de feedback, revisan resultados y ajustan el sistema. El código sigue siendo importante, pero ya no es el único centro del trabajo.

Si el desarrollo tradicional enfatizaba “escribir bien el código”, el desarrollo con IA enfatizará cada vez más “hacer que el sistema produzca resultados correctos y verificables de forma continua”.

No se trata solo de bajar la barrera de la ingeniería. Cambia la forma de la capacidad técnica: de implementación manual hacia descomposición de tareas, gestión de contexto, orquestación de herramientas, validación automática y juicio final.

Referencias

Qué es Hermes Agent: resumen, fortalezas, primeros pasos y comparación con OpenClaw

Sun, 12 Apr 2026 14:07:58 +0800

Si has estado siguiendo agentes AI open source recientemente, Hermes Agent es un proyecto al que vale la pena prestar atención. Creado por Nous Research, su atractivo principal no es simplemente ser otro envoltorio de chat, sino intentar reunir memoria a largo plazo, skills reutilizables, archivos de contexto, extensiones MCP, una pasarela de mensajería y sub-agentes paralelos en un único runtime de agentes.

Según el README oficial, Hermes Agent tiene un objetivo muy claro: puede funcionar como un asistente CLI local en tu terminal, o como un asistente personal alojado en la nube y disponible a través de Telegram, Discord, Slack, WhatsApp, Signal y otros canales. Para usuarios que quieren combinar un asistente de programación, un asistente de automatización y un espacio personal de AI en un solo sistema, ese posicionamiento es atractivo.

01 Resumen de Hermes Agent

Hermes Agent es un agente AI open source y auto-mejorable de Nous Research. Soporta varios proveedores de modelos, incluidos Nous Portal, OpenRouter, OpenAI y endpoints personalizados compatibles con OpenAI. También puede ejecutarse en distintos backends como terminal local, Docker, SSH, Daytona y Modal.

Lo que separa a Hermes de muchos chatbots con herramientas es que no se centra solo en llamadas a herramientas dentro de una sesión. Da mucha más importancia a construir capacidades persistentes entre sesiones. La documentación oficial divide esta idea en varias partes:

Memoria persistente: guarda información clave sobre el entorno, el proyecto y las preferencias del usuario mediante MEMORY.md y USER.md.
Sistema de skills: convierte flujos de trabajo exitosos en skills reutilizables que pueden cargarse bajo demanda.
Archivos de contexto: lee automáticamente archivos como AGENTS.md, SOUL.md y .cursorrules para inyectar convenciones del proyecto directamente en la sesión.
Integración MCP: puede conectarse a cualquier servidor compatible con MCP para ampliar capacidades de bases de datos, GitHub, filesystem y scraping.
Pasarela de mensajería: además de la CLI, puede usarse desde Telegram, Discord, Slack, WhatsApp, Signal, Email y otros puntos de entrada.

En una frase, Hermes Agent se siente más como una capa operativa de agentes de propósito general con memoria, skills, extensibilidad y acceso multicanal.

02 Dónde destaca

1. Cubre flujos CLI y flujos de mensajería

Muchos proyectos de agentes se inclinan hacia asistencia de desarrollador en terminal o hacia bots de plataformas de chat. Hermes intenta combinar ambos. Puedes ejecutar hermes directamente en la terminal, o continuar con el mismo asistente por Telegram o Discord después de iniciar la gateway.

El beneficio práctico es que Hermes no se limita a ser útil solo cuando estás frente al ordenador. Si lo despliegas en la nube o en un VPS, puede convertirse en un asistente personal disponible de forma continua.

2. Está diseñado para uso a largo plazo

Hermes hace más que chatear y llamar herramientas. También está construido alrededor de acumulación a largo plazo:

Memoria persistente con límites, en lugar de meter contexto sin fin en cada conversación.
Un sistema de skills que permite guardar y reutilizar flujos exitosos.
Búsqueda en sesiones pasadas para recuperación y recuerdo.
Archivos de contexto de proyecto que reducen la necesidad de repetir el mismo trasfondo.

Esto importa mucho para personas que trabajan repetidamente en los mismos repositorios, flujos y convenciones de equipo. Significa que el agente no solo ayuda una vez; puede familiarizarse gradualmente con tu entorno.

3. El soporte MCP le da gran extensibilidad

La documentación de Hermes soporta explícitamente MCP y describe modos de integración por stdio y HTTP. En la práctica, si un sistema externo ya tiene un servidor MCP, Hermes suele poder conectarse con un coste de integración mucho menor.

Eso es más flexible que escribir un plugin personalizado para cada sistema. Para usuarios que ya tienen herramientas alrededor del ecosistema MCP, Hermes debería ser mucho más fácil de extender.

4. Es amigable para usuarios de OpenClaw

Esta parte es especialmente interesante. El README de Hermes ofrece directamente hermes claw migrate y dice explícitamente que puede importar configuración, memoria, skills, claves API y ajustes de plataformas de mensajería desde OpenClaw.

Eso sugiere que Hermes no intenta ignorar el ecosistema existente y empezar desde cero. Claramente posiciona a algunos usuarios de OpenClaw como audiencia de migración.

03 Cómo empezar rápido

El método de instalación recomendado oficialmente para Hermes Agent es muy directo:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

Según el README oficial, soporta Linux, macOS, WSL2 y Android Termux. Una nota importante es que Windows nativo no está soportado por ahora, así que se recomienda a los usuarios de Windows usar WSL2.

Después de instalar, normalmente conviene refrescar primero la shell:

`1`	`source ~/.bashrc`

Luego puedes iniciarlo directamente:

hermes

Si quieres pasar por un flujo de inicialización más completo paso a paso, el comando más sencillo es:

`1`	`hermes setup`

Según la documentación y el README oficiales, una ruta simple de primera configuración sería:

Ejecuta hermes setup para completar la configuración base.
Usa hermes model para elegir proveedor y modelo.
Usa hermes tools para activar los conjuntos de herramientas que quieras.
Ejecuta hermes para entrar en la CLI interactiva.
Si quieres canales como Telegram o Discord, continúa con hermes gateway.

Si ya usas OpenClaw, también vale la pena previsualizar el comando de migración:

`1`	`hermes claw migrate --dry-run`

Así puedes inspeccionar qué se puede migrar antes de hacer una importación real.

04 Cómo pensarlo frente a OpenClaw

Según la documentación y el README oficiales, Hermes Agent y OpenClaw no son simplemente un caso de uno reemplazando al otro. Sus posicionamientos se solapan, pero sus prioridades son claramente diferentes.

Cómo se siente Hermes Agent

Hermes se siente más como un producto centrado en un núcleo de agente y un sistema de flujos de trabajo. Enfatiza:

experiencia CLI
acumulación de memoria y skills
archivos de contexto de proyecto
extensibilidad MCP
sub-agentes paralelos
cambio de backends de ejecución entre local, contenedor, remoto y serverless

Si tu objetivo principal es que el agente entienda mejor tu proyecto, reutilice capacidades con el tiempo y se conecte de forma más natural a MCP y flujos de desarrollo, Hermes probablemente encaje mejor.

Cómo se siente OpenClaw

OpenClaw se siente más como una plataforma centrada en un asistente personal AI más una pasarela de mensajería. Enfatiza:

integración rica con canales de mensajería
una Gateway siempre en ejecución
una Control UI basada en navegador
emparejamiento de dispositivos, acceso remoto y gestión de estado
superficies más orientadas a asistente, como voz, acceso móvil y Canvas

Si tu objetivo principal es mantener un asistente personal AI disponible de forma fiable en varios canales y dispositivos, con un panel de control para gestionarlo, OpenClaw tiene una sensación de producto más fuerte en esa dirección.

Una regla práctica

Puedes pensar en los dos así:

Hermes Agent: más como un espacio de trabajo de agentes de propósito general que crece con el uso
OpenClaw: más como una plataforma de asistente personal AI multicanal y siempre disponible

La distinción no es absoluta, porque ambos proyectos siguen expandiéndose y Hermes también ofrece una ruta de migración desde OpenClaw. Pero según el material público actual, Hermes destaca más en memoria, skills, contexto, MCP y flujos de desarrollo, mientras OpenClaw parece más maduro en gateway, multicanal, Control UI y acceso a dispositivos.

05 Quién debería probarlo

Hermes Agent merece probarse primero si encajas en alguno de estos perfiles:

Ya dependes mucho de herramientas AI en la terminal y quieres un agente que entienda mejor tu codebase y reglas de proyecto.
Quieres combinar AGENTS.md, skills, memoria y MCP en un solo flujo.
No quieres quedar bloqueado en un único proveedor de modelos y prefieres cambio flexible de proveedores.
Ya usas OpenClaw y quieres explorar una dirección más centrada en flujos de agentes.

Si te importa más el alcance móvil, la integración amplia con plataformas de mensajería, una consola de control en navegador y la sensación de un asistente personal siempre online, OpenClaw sigue teniendo mucho atractivo.

Referencias

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent Docs: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

OpenClaw Dreaming: las máquinas empiezan a soñar mientras los humanos pierden el sueño

Sun, 12 Apr 2026 12:41:34 +0800

La memoria a largo plazo siempre ha sido un punto débil de los modelos grandes. A medida que crece el contexto, la memoria se vuelve más difícil de gestionar. Un agente puede parecer que lo recuerda todo y, aun así, volverse peor al juzgar qué importa y qué debería olvidarse.

El 5 de abril, OpenClaw presentó una función experimental llamada Dreaming. No es solo un nombre llamativo. Es un sistema de gestión de memoria en segundo plano, inspirado en el sueño humano, diseñado para ayudar a los agentes a despertar con una memoria más limpia y útil.

01 Una pipeline basada en sueño para consolidar memoria

Dreaming hace más que indexar datos. Divide el procesamiento de memoria en tres etapas que reflejan distintas funciones del sueño humano.

Light Sleep: el sistema escanea conversaciones recientes y trazas de recuperación, elimina duplicados y construye una lista de candidatos. En esta etapa solo almacena información temporalmente y no modifica el archivo de memoria principal MEMORY.md.

Deep Sleep: el sistema aplica filtros más estrictos para identificar información duradera. Solo avanzan las entradas que superan umbrales de puntuación, número de recuperaciones y diversidad de consultas. Antes de escribir nada, vuelve a revisar los logs más recientes para retirar contenido obsoleto. El resultado final se añade a MEMORY.md, mientras que un resumen de sueño profundo se escribe en DREAMS.md.

REM: después de consolidar la memoria, el sistema busca vínculos ocultos entre trazas de comportamiento recientes. Extrae patrones y resúmenes reflexivos, y luego los guarda en una sección REM dedicada para ayudar al agente a responder con mejor estructura y más contexto.

Dreaming también produce un diario de sueños legible por humanos. Cuando se acumula material suficiente, un sub-agente en segundo plano llama al modelo predeterminado y añade una breve entrada en lenguaje natural a DREAMS.md.

02 Un sistema de puntuación para decidir qué merece quedarse

El punto real de Dreaming no es solo organizar memoria, sino filtrarla. En lugar de conservarlo todo, OpenClaw usa un modelo de puntuación ponderado para decidir qué pertenece al almacenamiento a largo plazo.

Las seis dimensiones son:

Relevancia (30%): qué tan útil es la información cuando se recupera.
Frecuencia (24%): qué tan a menudo aparece el elemento en señales de corto plazo.
Diversidad de consultas (15%): si aparece en diferentes prompts y contextos.
Recencia (15%): si la información sigue siendo fresca y accionable.
Integración (10%): si permanece estable durante varios días.
Riqueza conceptual (6%): qué tan denso y conectado es su grafo conceptual.

En la práctica, esto significa que el sistema intenta conservar información repetida, útil, actual y ampliamente aplicable, mientras deja que el ruido de menor valor se desvanezca.

03 Por qué recuerda al enfoque de “dreaming” de Claude

Algunos desarrolladores han señalado que Dreaming se parece a la lógica de sueño automatizado descrita en materiales filtrados de Claude Code sobre el sistema KAIROS. Los enfoques antiguos que reescribían repetidamente todo MEMORY.md podían volverse desordenados con el tiempo. Al dividir el flujo en sueño ligero, sueño profundo y REM, Dreaming hace que la pipeline sea más explícita: consolidar primero, preservar después y derivar patrones de nivel superior al final.

Otros han destacado el ángulo neurocientífico. Términos como Dreaming, Light Sleep, Deep Sleep y REM no son branding aleatorio. Toman prestados directamente modelos humanos de consolidación de memoria durante el sueño.

OpenClaw ya usa archivos como IDENTITY.md, USER.md y HEARTBEAT.md para preservar identidad, contexto de usuario y continuidad. DREAMS.md completa la pieza que faltaba: decidir qué recuerdos realmente vale la pena conservar.

04 La parte más irónica: las máquinas sueñan y los humanos siguen despiertos

El valor de Dreaming no es que la AI lo recuerde todo. Es que aprende a revisar trazas de corto plazo, extraer patrones y descartar ruido. Un agente fuerte no debería comportarse como un dispositivo de almacenamiento tonto. Debería mejorar con el tiempo al entender preferencias del usuario, objetivos recurrentes y contexto de largo plazo.

Desde una perspectiva de ingeniería, lo más interesante es que el sistema no se presenta como una caja negra mística. Es un proceso backend estructurado con etapas, umbrales, reflexión y reglas de olvido. Eso hace que la memoria de AI se sienta menos como inflación de contexto sin control y más como un sistema diseñado.

Y eso también vuelve irónico todo el asunto. Estamos dedicando un esfuerzo enorme a enseñar a las máquinas a soñar, mientras muchas personas pierden el sueño por ser reemplazadas por esos mismos sistemas cada vez más capaces.

OpenClaw y Agent Harness: por qué parece AGI

Fri, 10 Apr 2026 09:16:17 +0800

Mucha gente, al entrar en contacto por primera vez con OpenClaw, siente que “se parece más a un compañero que hace cosas que a un chatbot”.

Esa sensación no es misteriosa. La clave está en que OpenClaw no es un salto de capacidad de un único modelo, sino un Agent Harness completo.

Conclusión primero

La esencia de OpenClaw puede resumirse así:

El modelo se encarga de entender y decidir
El Harness se encarga de memoria, herramientas, disparadores, ejecución y salida
Ambos colaboran mediante un bucle, generando la experiencia de “acción continua”

Por eso la razón central de que “parezca AGI” no es que el modelo se haya vuelto omnipotente de pronto, sino que la ingeniería del sistema amplifica la ejecutabilidad del modelo.

Qué es Harness

Puedes entender Harness como un “exoesqueleto” puesto sobre el modelo.

Un LLM por sí solo normalmente solo puede dar una respuesta dentro de una solicitud. El Harness completa estas capacidades:

Gestión de sesión y estado: conecta tareas de varias rondas
Mecanismo de memoria: guarda y recupera contexto según necesidad
Sistema de herramientas: llama navegador, terminal, archivos y APIs externas
Mecanismo de disparo: se despierta por temporizador o evento, sin tener que esperar siempre una pregunta humana
Canal de salida: escribe resultados de vuelta al sistema, no solo devuelve un texto

Cuando estas capacidades se integran en un mismo bucle, el modelo pasa de “respondedor” a “ejecutor”.

Por qué OpenClaw parece distinto

El chatbot tradicional es “preguntas una vez, responde una vez”.

OpenClaw se parece más a “observa -> llama herramientas -> mira resultados -> decide de nuevo”. Una vez que el bucle se establece, muestra capacidad de avanzar tareas de forma continua.

Esto también es lo más valioso para aprender de OpenClaw:

Demuestra que la experiencia Agent viene principalmente del diseño de arquitectura
Divide la “autonomía” en módulos que pueden construirse con ingeniería

Valor y límites

La ventaja de OpenClaw es ser general y flexible, pero el coste también es claro:

Cuanto más contexto y definiciones de herramientas haya, mayor será el coste
Cuanto más general sea el sistema, más complejos serán el debugging y la gobernanza

En escenarios de producción, muchos equipos elegirán Agent más pequeños y especializados, no un “agente todopoderoso”.

Cronología completa del bloqueo de OpenClaw por Anthropic

Wed, 08 Apr 2026 19:48:42 +0800

Contexto del evento

El 4 de abril de 2026, Anthropic anunció que dejaría de cubrir herramientas de terceros como OpenClaw mediante suscripciones de Claude.

El impacto directo para los usuarios fue que los flujos de terceros que antes dependían de la ruta de suscripción para acceder a Claude tuvieron que cambiar a otros métodos de acceso o cambiar de modelo.

Cronología (enero a abril de 2026)

Enero de 2026

Según reportes públicos, Anthropic pidió al proyecto entonces llamado Clawdbot que ajustara su nombre, con el argumento de que su pronunciación era cercana a Claude.

En la misma etapa, la comunidad empezó a reportar límites en llamadas de terceros usando credenciales de suscripción.

Febrero de 2026

Las restricciones relacionadas se incorporaron a los términos de servicio, aclarando más el límite entre suscripción y llamadas automatizadas de terceros.

Ese mismo mes, OpenClaw lanzó v4.0 y cambió su arquitectura interna a backends de modelo enchufables. Es decir, el modelo dejó de ser una única entrada fija y pasó a poder alternar entre varios proveedores.

Marzo de 2026

Anthropic lanzó Claude Dispatch y Computer Use, cubriendo capacidades como ejecución de tareas remotas y operación de escritorio.

OpenClaw siguió avanzando en su capa de compatibilidad en actualizaciones posteriores, unificando diferencias entre modelos en autenticación, formato de tool calling y estructura de respuesta para reducir el coste de migración al cambiar de modelo.

Los reportes públicos también mencionaron que el equipo de OpenClaw y Anthropic se comunicaron a finales de marzo, pero la dirección estratégica final no cambió.

4 de abril de 2026

Anthropic ejecutó formalmente el corte de cobertura de suscripción para herramientas de terceros.

Esto marcó que los ajustes estratégicos de los meses anteriores entraron en fase de ejecución.

5 de abril de 2026

OpenClaw lanzó v4.5, con acciones principales como:

Ajustar la prioridad de entradas de modelo en el flujo de onboarding
Integrar rutas alternativas como GPT-5.4
Continuar adaptando flujos de tarea y experiencia interactiva

Por la fecha de lanzamiento, la capacidad de cambio de OpenClaw no fue construida totalmente de emergencia, sino sobre la base de la reforma multi-modelo iniciada desde febrero.

Dos direcciones paralelas durante el proceso

Según la cronología, ambas partes avanzaron en direcciones distintas durante el mismo periodo:

Anthropic: estrechar los límites de suscripción e impulsar la integración de capacidades en productos oficiales
OpenClaw: reforzar la sustituibilidad de modelos y mejorar compatibilidad entre modelos

Estas dos rutas no son contradictorias, pero compiten en la “propiedad de la entrada” y en dónde se acumula el flujo de trabajo del usuario.

Estado actual (hasta abril de 2026)

Con base en la información pública, se pueden confirmar estos hechos:

El corte de cobertura de suscripción ya se ejecutó
OpenClaw completó el cambio principal de rutas de modelo y mantiene iteración de versiones
Que el usuario perciba cambios claros depende de cuánto dependiera su flujo anterior de una sola capacidad de modelo

Puntos de observación posteriores

Lo que más merece seguimiento ahora no es el evento puntual en sí, sino tres cosas:

Si los límites entre suscripciones y llamadas API seguirán refinándose
El rendimiento de largo plazo de Agent multi-modelo en estabilidad, coste y experiencia
Si el flujo de trabajo del usuario terminará acumulándose en la capa de modelo, en la capa de herramienta o en una capa híbrida entre ambas

Conectar OpenClaw con Gemma 4 local: guía completa de configuración

Wed, 08 Apr 2026 18:18:00 +0800

Este artículo muestra cómo conectar OpenClaw a un modelo Gemma 4 local, exponiendo la interfaz mediante Ollama.

Si todavía no completaste el despliegue local, puedes consultar primero:

Cómo ejecutar Gemma 4 en un portátil: guía de despliegue local en 5 minutos

Paso 1: iniciar el servicio API de Ollama

Primero inicia el servicio de Ollama:

`1`	`ollama serve`

Puedes probar rápidamente si la API funciona con el siguiente comando:

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

Si devuelve salida del modelo, significa que la API local ya está disponible.

Paso 2: configurar OpenClaw para acceder a Ollama

La ruta habitual del archivo de configuración de OpenClaw es:

`1`	`~/.openclaw/config.yaml`

Edita config.yaml y añade una entrada de modelo local dentro de models:

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

Paso 3: establecer el modelo predeterminado (opcional)

Si quieres que Gemma 4 sea el modelo predeterminado, añade:

`1`	`default_model: gemma4-local`

Paso 4: reiniciar y verificar OpenClaw

Reinicia OpenClaw:

`1`	`openclaw restart`

Consulta la lista de modelos:

`1`	`openclaw models list`

Inicia una conversación de prueba:

`1`	`openclaw chat --model gemma4-local "你好"`

Si la conversación devuelve respuesta con normalidad, OpenClaw ya se conectó correctamente a Gemma 4 local.

Diagnóstico habitual

connection refused: confirma primero si ollama serve está ejecutándose.
Modelo no encontrado: comprueba que el nombre del modelo coincida con ollama list (por ejemplo gemma4:12b).
Timeout de respuesta: puedes aumentar timeout y probar primero con un modelo más pequeño.