Archivo de la categoría: linux

Cómo instalar OpenClaw en Linux: Tu propio agente de IA en WhatsApp y Telegram

Posted on por
Responder

Si os habéis pasado por aquí últimamente, sabréis que estoy bastante metido en el mundo de los agentes de IA. Primero os enseñé cómo instalar opencode, y ahora os traigo otra joyita que me tiene enganchado: OpenClaw (antes conocido como ClawdBot o MoltBot, por si os suena de algo).

¿Qué es OpenClaw? Pues básicamente es un gateway que te permite tener tu propio asistente de IA conectado a WhatsApp, Telegram, Discord, iMessage y más. Imagina tener a tu disposición un agente que puede limpiar tu bandeja de entrada, enviar correos, gestionar tu calendario o incluso hacer check-in en vuelos, todo desde la app de mensajería que ya usas. Y lo mejor: self-hosted, tus datos en tu máquina, tus reglas.

Requisitos previos

Antes de meternos en harina, aseguraos de tener:

  • Node.js 22 o superior (imprescindible, no valen versiones antiguas)
  • Una API key de algún proveedor de IA (Anthropic recomendado, pero podéis usar otros)
  • Ganas de experimentar (esto no es plug-and-play, pero tampoco es rocket science)

Instalación paso a paso

La instalación es bastante sencilla gracias a npm. Abrimos terminal y ejecutamos:

npm install -g openclaw

Una vez instalado, toca configurar el entorno. OpenClaw guarda todo en ~/.openclaw/, así que vamos a preparar el terreno:

openclaw setup

Esto crea la estructura de carpetas y los archivos de configuración iniciales. Si queréis hacerlo desde el repositorio fuente (para los más aventureros), necesitaréis pnpm y ejecutar pnpm install seguido de pnpm build.

Configuración básica

El archivo de configuración vive en ~/.openclaw/openclaw.json. Aquí podéis ajustar qué canales queréis activar y cómo comportarse el agente. Un ejemplo básico para WhatsApp:

{
  "channels": {
    "whatsapp": {
      "allowFrom": ["+34600123456"],
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}

Con esto, solo vuestro número podrá interactuar con el bot, y en grupos tendrá que mencionaros para responder (útil para no saturar las conversaciones).

Iniciar el Gateway

Ahora viene lo bueno. Arrancamos el gateway con:

openclaw gateway --port 18789 --verbose

Si todo va bien, veréis el mensaje de que el servidor está corriendo. Por defecto, la interfaz de control está disponible en http://127.0.0.1:18789/. Desde ahí podréis gestionar sesiones, ver logs y configurar canales.

Conectar WhatsApp

Esto es lo más chulo. Ejecutad:

openclaw channels login

Os mostrará un código QR que tenéis que escanear con WhatsApp en vuestro móvil (Ajustes ? Dispositivos vinculados ? Vincular dispositivo). Una vez hecho, vuestro número de WhatsApp estará conectado al agente de IA.

Verificar que todo funciona

Para aseguraros de que la instalación está correcta:

openclaw health

Si devuelve OK, estáis listos para empezar a chatear con vuestra IA desde WhatsApp o Telegram.

Algunos trucos que he aprendido

  • Workspace personalizado: Guardad vuestras skills y configuraciones en ~/.openclaw/workspace. Podéis hacer un repo git privado y así tener backups y control de versiones.
  • Heartbeats: OpenClaw tiene un sistema de «heartbeats» que permite al agente hacer comprobaciones periódicas (emails, calendario, etc.) y avisaros proactivamente.
  • Sesiones: Cada conversación es una sesión independiente. Podéis tener diferentes contextos para diferentes tareas.
  • Skills: La comunidad está creando skills para todo (GitHub, Notion, Slack…). Echad un vistazo al repositorio oficial.

Conclusión

OpenClaw es una de esas herramientas que, una vez que las pruebas, te preguntas cómo has vivido sin ellas. Tener un agente de IA verdaderamente personal, que corre en tu máquina y se integra con tus apps de mensajería habituales, es una experiencia que no tiene nada que ver con los asistentes en la nube.

Eso sí, requiere cierto nivel técnico y ganas de trastear. Si os gusta eso de «romper cosas para entenderlas», OpenClaw es vuestro sitio. ¿Ya lo habéis probado? Contadme vuestras experiencias en los comentarios.

Nota: Este post es una guía introductoria. Para configuraciones avanzadas y troubleshooting, consultad la documentación oficial.

Usar una IA local con opencode

Posted on por
Responder

Ya vimos en el anterior post cómo instalar el agente opencode que nos va a permitir utilizar distintos proveedores de IA en nuestros flujos de trabajo (en concreto a mi para programar, pero quien sabe para qué querréis usarlos vosotros), vimos cómo configurarlo con un proveedor externo (por tanto de pago), pero nada nos impide utilizar un proveedor local (si tenéis una tarjeta con GPU solo tenéis que seguir algunos de mis posts al respecto) y ya tendréis un ollama operativo del que tirar. Así que, si cumplís los requisitos vamos a ver cómo configurar nuestra instalación de opencode para dejar de gastar dinero en proveedores externos y usar nuestra propia GPU.

No hay una forma «gráfica» de configurar el modelo, así que vamos con las instrucciones para hacerlo de manera manual:

  1. Crea el archivo opencode.jsonc (en mi caso en ~/.config/opencode ). si habéis seguido la guía de instalación previa os sonará porque es donde hemos metido la configuración mcp
  2. Mete esto (con los cambios que luego veremos):
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3:latest-16k": {
          "reasoning": true
        }
      }
    }
  }
}

En este caso hemos supuesto que tenemos el servidor ollama corriendo en nuestra propia máquina y el modelo que hemos elegido es qwen3… Pero eso tiene cierto truco, si usas el modelo tal cual te lo bajas no va a funcionar porque el contexto en ollama para este modelo es demasiado pequeño, antes tienes que hacer esto:

docker exec -it ollama bash
# ollama run qwen3:latest

>>> /set parameter num_ctx 16384
Set parameter 'num_ctx' to '16384'

>>> /save qwen3:latest-16k
Created new model 'qwen3:8b-16k'

>>> /bye

Si todo ha ido bien, cuando abras opencode en cualquier proyecto ya podrás elegir este modelo:

Y, dependiendo de los recursos de tu máquina podrás disfrutar de todas las ventajas de un modelo local. Eso si, para utilizar las capacidades de opencode aseguraos de que el modelo que estéis usando tenga capacidades para tools y thinking. Podéis verlo, por ejemplo con este modelo de nvidia (si tienes 20Gb de memoria en tu GPU es un buen candidato):

Es posible que, aunque tenga acceso a tools no nos permita ejecutar cosas tan simples como listar un directorio o editar un archivo. Eso es debido a que no está accediendo a las herramientas propias de opencode. He tenido que hacer algunos malabares para hacer funcionar algunos modelos concretos, así que dejo en vuestras manos el poder sacar lo mejor del sistema… Sin tener que pagar a otros proveedores ni enviarles información igual demasiado privada.

IA con OpenCode

Posted on por
2

Como ya vimos en la anterior entrada sobre agentes de IA opensource, hay vida más allá de claude code y gemini-cli (ya veremos cuando tengamos tiempo otros como kilo code) y se nos quedó pendiente instalar y probar otro agente muy conocido opencode.

Vamos a hacer aquí un resumen de la instalación, configuración con un modelo LLM que tengamos y hasta el uso de un MCP local, al igual que hicimos con goose. Luego veremos si son comparables y si lo son a sus homólogos «comerciales»

Instalación

La instalación de opencode es de todo menos dificil, solo tienes que entrar a la página https://opencode.ai/download y ahí tienes todas las opciones disponibles, de hecho, lo más sencillo es ejecutar este script que te indican en la página principal:

curl -fsSL https://opencode.ai/install | bash

Por defecto te va a instalar solo la versión de terminal, pero os recomiendo que vayáis a la página de descargas y os instaléis la versión de escritorio también, que no es que tenga muchas ventajas, pero ya que goose lo usamos en su versión de escritorio así podemos comparar un poco mejor (goose también tiene versión de terminal, pero no la he usado demasiado).

Configuración

Lo primero que tenemos que hacer justo después de arrancar opencode es conmfigurar nuestro LLM (debemos tener alguno disponible, ya sea local o remoto, esto es solo un agente).

Por suerte opencode es bastante amable a la hora de configurar un proveedor, solo tenemos que darle al icono + que vemos a la izquierda y se nos presentará la lista de proveedores soportados:

Y tiene un montón, nosotros, como ya hicimos en el post anterior vamos a conectarnos con glm-4.7 (si, ya han sacado nuevo modelo) y lo haremos usando Z.AI codign plan (podemos usar el que nosotros tengamos, aunque sea solo la capa gratuita)

Y luego cuando abramos un proyecto (un directorio) ya se nos permitirá elegir el modelo:

O, si estamos en el terminal, con la opción /model que nos permitirá elegir de los configurados:

Si os fijáis en la última imagen yo tengo ya configurados dos servidores MCP, vamos a ver cómo lo he hecho (tampoco es tan complicado, pero es más difícil que lo de escoger modelo).

En nuestro caso vamos a tener que editar un archivo, que está en /.config/opencode/opencode.jsonc, al que tendremos que adaptar el código que ya pusimos en el post anterior:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "outline": {
	"type": "local",
	"command": ["docker",
		"run",
		"-i",
		"--rm",
		"--init",
		"-e",
		"DOCKER_CONTAINER=true",
		"-e",
		"OUTLINE_API_KEY",
		"-e",
		"OUTLINE_API_URL",
		"biblioeteca/mcp-outline"
	],
	"environment": {
		"OUTLINE_API_KEY": "ol_api_...",
		"OUTLINE_API_URL": "https://mi-servidor-/api"
	},
	"enabled": true
    },
  }
}

Como véis es muy parecido a lo que poníamos anteriormente, solo aseguraos de que el entorno sea el correcto y luego ya podéis activar los MCP para cualquier proyecto o de manera general.

Para activarlos simplemente pinchar (en la versión de escritorio) en MCP en la parte superior derecha y os aparecerá un desplegable para activar o no los MCP que tengáis configurados:

Y, bueno, con esto ya tenemos otro agente listo para usarse, lo podemos usar en dos modos, modo Plan para que no haga ningún cambio y solo planifique lo que hay que hacer o en modo Build para que haga todos los cambios necesarios.

Me queda mucho por explorar todavía con este agente (y sus plugins, que hay alguno sabroso) pero todavía tengo que ver cómo engancharlo con un ollama local para no tener que usar modelos externos… Eso lo dejo para la próxima.

Conectar claude code con MCPs

Posted on por
1

Como ya contamos en una entrada anterior La IA más barata para generar código, podemos utilizar claude code con otras IAs además de las de Anthropic, y esto es muy bueno porque nos da muchas herramientas de agente inteligente como la nada despreciable posibilidad de conectar con servidores MCP.

Para este ejemplo vamos a utilizar outline, que, para el que no lo conozca, es un excelente editor de documentos al estilo notion y que yo uso, junto con mi equipo, para dejar la documentación de los proyectos y ahora vamos a ver cómo podemos integrar esta documentación con nuestra IA favorita para programar.

Lo primero que tenemos que hacer es conseguir una clave de API en outline. Eso se consigue en la ruta /settings/api-and-apps donde pediremos crear una nueva clave api

Una vez creada más vale que os la copieis rápido porque no vais a poder volver a recuperarla después.

Una vez que tenemos instalado claude code y sus prerequisitos (que podéis ver en la entrada anterior) tendremos en nuestra raíz de usuario un archivo llamado .claude.json que tiene, entre otras cosas, las definiciones de los mcp.

El fragmento que tenemos que añadir es:

       "mcpServers": {
        "outline": {
          "type": "stdio",
          "command": "docker",
          "args": [
            "run",
            "-i",
            "--rm",
            "--init",
            "-e",
            "DOCKER_CONTAINER=true",
            "-e",
            "OUTLINE_API_KEY",
            "-e",
            "OUTLINE_API_URL",
            "biblioeteca/mcp-outline"
          ],
          "env": {
            "OUTLINE_API_KEY": "ol_api_.....",
            "OUTLINE_API_URL": "https://<servidor>/api"
          }
        },

Yo lo he añadido bajo la línea «mcpContextUris»: [] dentro de uno de los proyectos donde lo quiero usar. Evidentemente para usar este mcp necesitas tener docker instalado (doy por hecho que si estás aquí eres de los míos y lo usas diariamente).

Una vez que has grabado el archivo y arrancas claude en el directorio del proyecto en cuestión le puedes preguntar por la lista de mcps:

$ claude mcp list
Checking MCP server health...

outline: docker run -i --rm --init -e DOCKER_CONTAINER=true -e OUTLINE_API_KEY -e OUTLINE_API_URL biblioeteca/mcp-outline - ? Connected

Y ya puedes hacer que la magia surja…

Y darle que si a todos los permisos que pida

Y ya podrías pedirle que te lea documentos como requisitos para programar o que, como en este caso, que nos documente el api que acabamos de construir en el proyecto

¿puedes crear un documento llamado API DocuFactu en esa colección con la documentación sobre el API (solo la parte verifactu) que incluya ejemplos de uso usando una APIKEY?

Y este es el resultado… (solo parte)

Como todo lo que hace la IA luego alguien que sepa tiene que retocarlo y corregirlo (aquí también se puede inventar cosas), pero el caso es que ya tenemos mucho trabajo adelantado.

Hay miles de mcp con los que podemos interactuar por ahí… Solo tienes que buscarlo o, sino, construir el tuyo propio que, igual, lo hacemos aquí cuando tengamos un rato.

La herramienta correcta para gestión de tareas

Posted on por
Responder

Cualquier equipo, se dedique a lo que se dedique, cuando lo componen varias personas hay un momento en que alguien debe pararse y decir, ¿estamos haciendo las cosas bien? ¿en el orden correcto? ¿dedicando el tiempo necesario a cada una? ¿tenemos controlado el trabajo o el trabajo nos controla a nosotros? Lo que antes eran reuniones y encargos sencillos se ha convertido en un sin fin de recordatorios de cosas que no se han hecho, se han hecho sin necesidad o se han hecho demasiado tarde o demasiado pronto. En este punto es cuando la elección de una buena herramienta de gestión de tareas se hace necesaria.

Si esperáis que os diga cual es la correcta para el desarrollo de software, bueno, pues os equivocáis, todavía no he encontrado la que sea perfecta, pero si que puedo ofreceros mi visión sobre lo que necesitaría tener esa herramienta y los intentos de encontrarla que he tenido durante estos casi 30 años en el oficio.

Primero lo primero, cuales son las necesidades que queremos cubrir con esta herramienta:

  • Queremos poder registrar el tiempo dedicado y estimado para cada tarea sin que nos quite tiempo de trabajo efectivo.
  • Necesitamos saber la prioridad de las distintas tareas y poder ordenarlas en el tiempo.
  • Necesitamos saber quien tiene que trabajar en una tarea y qué es lo que tiene que hacer en la misma
  • Necesitamos saber el estado de cada tarea y el grado de avance general de la tarea y del proyecto al que pertenece
  • Es preciso poder descomponer el trabajo en tareas más pequeñas que puedan ser abordadas por una sola persona o, en el caso de requerir múltiples participantes al mismo tiempo que esté controlado el tiempo dedicado por cada persona
  • Queremos que cada proyecto tenga una visión clara de las tareas en curso y las que están en distintos estados del workflow de desarrollo
  • Necesitamos que haya una trazabilidad completa de las tareas desde su creación hasta que esta se termina
  • Es imprescindible disponer de documentación y una forma de asociarla a las tareas, pero de manera más independiente ya que la documentación ha de permanecer más allá de la vida de la tarea
  • Se necesita una manera ágil de comunicación entre los distintos componentes del equipo y, posiblemente, con elementos fuera de los equipos de desarrollo (usuarios, QA, dirección) aunque no es imprescindible que esté ligado al mismo sistema si que se necesita una manera sencilla de referirse a las tareas externamente.
  • Es deseable poder implementar distintos ciclos de vida a distintos tipos de proyectos y no limitarse a uno solo.
  • Si se usa un sistema el directorio de usuarios debe estar en sincronía con el de la empresa y la autenticación deberá ser compatible con la existente.

Evidentemente cada organización, empresa o grupo puede tener más o menos necesidades, pero en la lista anterior creo que he incluido las principales. El objetivo final es saber qué trabajo queda por hacer, qué hacer primero, tener previsiones de cuando estará un cierto trabajo complejo y saber cómo se están aprovechando los recursos. Obviamente cuanto más sencillo sea el sistema y cuanto menos tiempo nos quite de las tareas reales más efectivo será.

Y, para que sirva de referencia os voy a contar mi historia con los distintos sistemas de gestión de tareas que he tenido el «honor» de probar.

En el 97 empecé a trabajar profesionalmente en esto de la informática después de haber terminado la carrera y haber obtenido toda la teoría necesaria sobre gestión de proyectos y haber hecho un curso de CEPADE sobre gestión de proyectos tecnológicos. En la empresa en la que entré se gestionaba todo con Microsoft Project, por suerte generalmente la planificación moría en el momento en que el proyecto empezaba. Lo único que se esperaba respetar eran los plazos y los entregables. El tiempo dedicado no se actualizaba nunca y solo se ampliaban los plazos o, si el cliente se ponía pegigero, se cambiaba el alcance y se eliminaban o añadían tareas sin demasiado control.

Microsoft desarrolló una especie de project on-line para que los usuarios que estuviesen participando en un proyecto pudiesen imputar las horas o indicar cuando se habían acabado las tareas. Ahora mismo no recuerdo el nombre del producto, lo que si recuerdo es que era tan dificil de instalar y hacer funcionar correctamente que lo usamos solo en un proyecto antes del olvidarlo completamente. Project se quedó para el papeleo y marcar las fechas esperadas y controlar, por tanto, el retraso de las tareas y del proyecto en general.

Seguí usando project (sin ningún online y con control mediante arcaicas hojas excel) hasta que evolucioné lo suficiente (y puse mi propia empresa) como para usar Linux como mi máquina principal… Mira por donde ahí no había forma de ejecutar el project y me las vehía y deseaba para generar los gantt de manera medianamente atractiva para presentársela a los clientes (si, ya era para mis propios clientes). Llegados a este punto descubrí una herramienta online que, aunque inicialmente no creada para ello, servía perfectamente para hacer seguimiento del tiempo dedicado a las tareas de un proyecto, se trataba de trac. Tal como contaba en su página (hoy casi abandonada)

Trac es un sistema wiki mejorado y de seguimiento de incidencias para proyectos de desarrollo de software. Trac utiliza un enfoque minimalista para la gestión de proyectos de software basados en la web.

trac era un sistema de tickets, con un wiki para la documentación y conexión con subversion para el control de código. Si a esto le unimos que permitía indicar el número de horas dedicadas a cada incidencia, ya teníamos una primera forma de controlar en tiempo real las tareas. El wiki no era perfecto y la búsqueda también podía mejorarse, pero cumplió muy bien con su cometido durante unos cuantos años. De hecho el problema sobrevino cuando dejaron de mantener el producto y ya teníamos muchos proyectos gestionados con este sistema. Tengo que decir que antes de llegar a trac (que inicialmente se llamó svntrac) estuvimos usando cvstrac y cvs en lugar de subversion… Y si, tuvimos que migrar de cvs a subversion y de eso a git (es lo que tiene llevar más de 20 años produciendo código sin querer perder nada).

El caso es que descubrimos un poco después que había un programa que tenía todo lo que tenía trac (y algunas cosas más) que era completamente software libre y, además, rapidísimo y se llama Redmine. Aunque lleva creado desde 2006 no fue hasta 2018 que decidí implantarlo en mi empresa (y en la de algún cliente posteriormente). Aunque seguía sin ser perfecta nos ofrecía todo lo que necesitábamos para el control de tareas, nos permitía comunicarnos con los clientes via incidencias, llevar un tracking completo de todo en lo que hemos trabajado de cada proyecto, con múltiples proyectos completamente aislados unos de otros y con usuarios igualmente aislados y con roles diferenciados. Todos nuestros proyectos con mantenimiento se iniciaban como proyecto redmine y evolucionaba a proyecto de mantenimiento abierto a que los clientes pudieran dar de alta sus incidencias y hacer seguimiento de la evolución del mismo.

El mayor problema de redmine es que tremendamente poco intuitivo o, dicho en castellano «es feo de cojones». Aunque tiene todo lo que necesitamos para un equipo de desarrollo (aunque feo-feo), es imposible a día de hoy intentar que un cliente entre por el aro de reonocer esto como una aplicación web… Ahora se espera utilizar llamativos tableros kanvan (inutilizables cuando el número de tareas es alto o los equipos grandes) y modificaciones instantaneas via clicks y sin tener que escribir nada, solo pinchar y arrastrar. Me he pasado los últimos años buscando herramientas software libre que me permitiesen tener la misma privacidad y funcionalidad que redmine pero con un aspecto nuevo y renovado. He probado desde Trello hasta monday.com pasando por Jira y Asana (igual Jira no es tampoco demasiado atractivo). Quitando que ninguna de estas herramientas son libres de verdad y varias de ellas o son demasiado completas o carecen de alguna de las características que hemos descrito anteriormente todas ellas son carísimas… Sigo buscando ya que aunque redmine me viene bien para gestionar un equipo de desarrollo se atraganta a otro tipo de perfil menos hecho a lidiar con informes y formularios. ¿Conocéis alguno bueno y, a ser posible, open source o con una versión realmente barata?