Goose (Block): el agente de IA local en tu terminal
Sí: ejecuta goose configure, elige Ollama, deja http://localhost:11434 como dirección predeterminada e indica un modelo de Ollama compatible con la llamada a herramientas. Dos ajustes son importantes en local: aumentar OLLAMA_CONTEXT_LENGTH por encima de los 4096 tokens predeterminados y activar el tool shim (GOOSE_TOOLSHIM=true) si el modelo explica las herramientas en texto en lugar de llamarlas. Goose es ahora un proyecto de la Agentic AI Foundation, ya no solo de Block.
Goose es un agente de IA disponible en línea de comandos y como aplicación de escritorio, inicialmente publicado por Block y luego transferido a la Agentic AI Foundation. Esta guía cubre su configuración con un Ollama local, el tool shim que compensa la falta de soporte nativo para llamadas a herramientas en ciertos modelos, los modos de permisos (autónomo por defecto) y las limitaciones reales de un pequeño modelo local frente a sus extensiones MCP.
#Qué es Goose hoy
Goose se presenta como un agente de IA nativo de código abierto —con aplicación de escritorio, CLI y API— para tareas de programación, flujos de trabajo y otras tareas, escrito en Rust. El repositorio (ahora aaif-goose/goose) cuenta con cerca de 55.000 estrellas a fecha del 28 de septiembre de 2026, con la versión v1.52.0 publicada el 23 de septiembre de 2026.
Un dato que conviene corregir si has leído presentaciones más antiguas: Goose ya no es un proyecto aislado de Block; ahora forma parte de la Agentic AI Foundation (AAIF), acogida por la Linux Foundation. Block sigue siendo quien dio origen al proyecto, pero la gobernanza ha cambiado: un detalle que importa para evaluar la continuidad del proyecto a largo plazo antes de construir un flujo de trabajo sobre él.
Goose funciona con más de 15 proveedores de modelos (Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock, y otros) y se conecta a más de 70 extensiones a través del protocolo abierto MCP (Model Context Protocol).
También existe una interfaz con Ramalama, un motor local que sirve modelos en formato de artefactos OCI en lugar del formato propietario de Ollama. Dado que su API es compatible, Goose puede usarlo directamente a través de su proveedor Ollama, sin código específico — una opción útil en infraestructuras ya construidas alrededor de herramientas de contenedorización estándar (Podman, Docker) en lugar de alrededor de Ollama.
#Conectar Ollama
Agentes que actúan en tu máquina: Cline agéntico, MCP, n8n + Ollama, automatizaciones locales.
- Espacio en línea de por vida
- PDF + archivos
- Actualizaciones de por vida
La configuración se realiza mediante el asistente interactivo goose configure, que pide el proveedor y luego el host. Para Ollama, si no se especifica ningún host, Goose utiliza localhost:11434 por defecto; el prefijo http:// se añade automáticamente si no se especifica el esquema.
Para un Ollama que corre en otra máquina de la red, es necesario definir explícitamente OLLAMA_HOST=http://{hôte}:{port} antes de iniciar la configuración. Para modelos alojados en ollama.com en lugar de localmente, el proveedor a elegir es Ollama Cloud, no Ollama.
#La trampa del contexto de 4096 tokens
El valor predeterminado de Ollama para el tamaño de contexto es de 4096 tokens, y trunca silenciosamente en lugar de devolver un error explícito. En un agente como Goose que carga instrucciones de proyecto (.goosehints), el historial de conversación y las definiciones de extensiones, este límite se alcanza rápidamente.
#Tool shim: corregir las llamadas a herramientas
Algunos modelos no tienen soporte nativo para llamadas a herramientas, o cambian durante la sesión a una salida de texto plano en lugar de una llamada estructurada. El shim de herramientas de Goose detecta estos formatos textuales y los convierte en llamadas a herramientas ejecutables. Esta es una funcionalidad marcada como experimental por el proyecto.
El shim de herramientas se apoya en un modelo intérprete separado del modelo principal de conversación: mistral-nemo por defecto a través de Ollama, que puede sustituirse mediante GOOSE_TOOLSHIM_OLLAMA_MODEL. La documentación cita explícitamente los modelos locales (Ollama, llama.cpp) sin llamadas nativas a herramientas como caso de uso principal, así como los modelos que mezclan etiquetas de razonamiento (« think ») con llamadas a herramientas, una fuente frecuente de errores de análisis sintáctico.
Un modo alternativo utiliza el backend de inferencia local integrado de Goose en lugar de una instancia Ollama separada, mediante GOOSE_TOOLSHIM_BACKEND=local y un nombre de modelo obligatorio (GOOSE_TOOLSHIM_MODEL) — de lo contrario, el arranque falla.
#Modos de permisos: autónomo por defecto
Goose ofrece cuatro modos de permisos: completamente autónomo (modifica y elimina archivos sin confirmación), aprobación manual (pide confirmación para cada herramienta), aprobación inteligente (aprueba automáticamente las acciones de bajo riesgo) y modo de solo conversación (ninguna modificación, ninguna herramienta).
El cambio de modo se realiza en cualquier momento, incluso durante una sesión, mediante /mode auto, /mode smart_approve, /mode approve o /mode chat en CLI, o desde el menú inferior en la aplicación de escritorio.
#Extensiones MCP y allowlist
Goose se conecta a extensiones a través del protocolo MCP y, por defecto, instala cualquier servidor MCP solicitado. Para un contexto profesional, el proyecto ofrece una lista de elementos permitidos: un archivo YAML alojado en una URL, referenciado por la variable GOOSE_ALLOWLIST, que limita las extensiones instalables a una lista explícita de identificadores y comandos.
Sin esta allowlist, técnicamente nada impide que el agente instale un servidor MCP de terceros no verificado si el usuario (o el modelo, en modo autónomo) lo solicita; un punto que conviene considerar junto con la elección del modo de permisos indicada arriba.
La lista de elementos permitidos se despliega como un simple archivo YAML que enumera pares de identificador/comando autorizados, alojado en una URL que Goose vuelve a leer en cada reinicio mediante la variable GOOSE_ALLOWLIST. Es una medida pensada para un despliegue empresarial, donde un administrador quiere restringir las extensiones instalables a una lista validada de antemano en lugar de confiar en el criterio de cada usuario o del modelo en modo autónomo.
- 01Instalar la CLI Goosecurl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash, ou télécharger l'application de bureau depuis la documentation officielle.
- 02Preparar el modelo OllamaVerificar que Ollama esté funcionando en el puerto 11434 y ejecutar un modelo anunciado explícitamente como compatible con tool-calling antes de configurar Goose.
- 03Iniciar goose configureElegir Ollama como proveedor, validar el host propuesto por defecto (localhost:11434) y indicar el nombre exacto del modelo cargado.
- 04Aumentar el contexto si es necesarioSi el agente ignora extensiones o un archivo .goosehints, establecer OLLAMA_CONTEXT_LENGTH en un valor superior a 4096 antes de reiniciar una sesión.
- 05Verificar el modo de permisosAntes de la primera sesión con extensiones sensibles, cambiar explícitamente al modo de aprobación manual o inteligente si no se desea el modo autónomo predeterminado.
#Qué modelo elegir según la memoria disponible
La documentación oficial es categórica sobre un punto que a menudo se minimiza: Goose se apoya en gran medida en las llamadas a herramientas, y un modelo que no las admite solo puede mantener conversaciones sencillas; en ese caso, todas las extensiones de Goose deben desactivarse. Por tanto, la elección del modelo no es solo una cuestión de calidad de respuesta: es una condición binaria que determina si las extensiones MCP pueden funcionar.
| Tamaño del modelo | VRAM aproximada | Uso realista con extensiones |
|---|---|---|
| 7-8B | ≈ 5 GB | Llamadas a herramientas inestables en tareas con varias herramientas encadenadas; probar con GOOSE_TOOLSHIM antes de concluir que el modelo ha fallado |
| 14B | ≈ 9 GB | Caso de uso habitual para una estación de trabajo de desarrollo; verificar la etiqueta tools en ollama.com antes de cargar el modelo |
| 32B | ≈ 19-20 GB | Más fiable en secuencias largas de llamadas a herramientas, a costa de un mayor tiempo de generación en GPU de consumo. |
| 70B | ≈ 40 GB | Reservado para equipos con mucha VRAM o RAM unificada (Mac Studio, estaciones multi-GPU); rara vez resulta adecuado para el uso diario en local |
Estos órdenes de magnitud no sustituyen la comprobación de la etiqueta tools en la ficha del modelo: una variante que no esté anunciada como compatible con tool-calling falla al usar las extensiones, independientemente de su tamaño, tal como especifica la documentación oficial citada anteriormente.
#Checklist de seguridad antes de un despliegue compartido
Tres ajustes, ya documentados por separado en esta guía, forman juntos la base de un despliegue de Goose más seguro que una instalación por defecto en un equipo compartido o un servidor del equipo.
| Punto de control | Ajuste a verificar |
|---|---|
| Modo de permisos | Pasar de un modo completamente autónomo a uno con aprobación manual o inteligente si no se desea eliminar archivos sin confirmación |
| Extensiones instalables | Configurar GOOSE_ALLOWLIST para que apunte a un archivo YAML alojado que restrinja los identificadores y comandos autorizados |
| Capacidad real del modelo | Confirmar la etiqueta tools en ollama.com antes de conectar extensiones; un modelo incompatible exige desactivarlas todas |
| Contexto suficiente | Aumentar OLLAMA_CONTEXT_LENGTH por encima de 4096 para evitar que las propias instrucciones de seguridad se trunquen silenciosamente (.goosehints) |
#Límites de un modelo local para Goose
| Síntoma | Causa probable documentada |
|---|---|
| Extensiones ignoradas, no se siguen las instrucciones de .goosehints | Contexto predeterminado de 4096 tokens demasiado corto: aumentar OLLAMA_CONTEXT_LENGTH |
| Llamadas a herramientas que se detienen durante la sesión | El modelo pasa a generar texto: activar GOOSE_TOOLSHIM |
| Intérprete del tool shim lento | Modelo intérprete demasiado pesado: pasar a un modelo más pequeño mediante GOOSE_TOOLSHIM_OLLAMA_MODEL |
| Razonamiento mezclado con llamadas a herramientas | Etiquetas «think» no deseadas: el tool shim las filtra automáticamente una vez activado |
El modelo nativo DeepSeek-R1 no admite llamadas a herramientas según la documentación oficial, que propone como alternativa una versión comunitaria adaptada para Goose: un ejemplo concreto de la diferencia entre un modelo considerado potente en conversación y su capacidad real para manejar herramientas.
Este desfase entre capacidad de razonamiento y fiabilidad en la ejecución es la limitación estructural que hay que tener en cuenta antes de instalar Goose localmente: un modelo que responde bien a preguntas abiertas no garantiza nada sobre su capacidad para encadenar llamadas a herramientas sin errores de formato. Probar primero una tarea sencilla y verificable —leer un archivo, ejecutar un comando inofensivo— antes de encomendar al agente una tarea de varios pasos sigue siendo la forma más rápida de detectar un modelo inadecuado.
- OpenCode + Ollama: un agente de código en tu terminal
- Cline + Ollama: agente de código 100 % local en VS Code
- MCP: ¿qué es? El Model Context Protocol explicado
- Llamada a herramientas con Ollama: tutorial
- Fuente: README oficial del repositorio Goose
- Fuente: documentación oficial de los proveedores
- Fuente: documentación oficial del tool shim
¿Goose sigue siendo desarrollado por Block?+
¿Por qué Goose ignora mis extensiones o mi archivo .goosehints con Ollama?+
¿Qué hacer si mi modelo local no llama a las herramientas en Goose?+
¿Goose puede eliminar archivos sin pedir confirmación?+
¿Se necesita un GPU potente para ejecutar Goose localmente?+
¿Puede seguir siendo útil con Goose un modelo local sin tool-calling?+
¿Cómo limitar las extensiones MCP que puede instalar Goose?+
¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.