Avanzado 12 minAgentes

Goose (Block): el agente de IA local en tu terminal

Respuesta directa

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.

Por Mohamed Meguedmi·Actualización 2026-09-28·Probado en Windows, macOS y Linux

#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

El kit Agentes Locales

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.

Terminal
ollama run qwen2.5
# dans un second terminal
goose configure

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.

i
Modelo recomendado para empezar
La documentación oficial utiliza qwen2.5 como ejemplo de modelo que hay que ejecutar antes de configurar Goose, e insiste en que debe estar anunciado como compatible con llamadas a herramientas: no sirve cualquier modelo de chat generalista.

#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.

!
Síntoma típico
Si Goose ignora tus archivos .goosehints o parece perder el hilo con extensiones activas, la documentación oficial señala como primera causa ese contexto predeterminado demasiado corto: hay que aumentar su longitud mediante la variable de entorno OLLAMA_CONTEXT_LENGTH antes de buscar otras causas.
Contexto ampliado
export OLLAMA_CONTEXT_LENGTH=32768

#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.

Activar el tool shim
export GOOSE_TOOLSHIM=true
ollama pull mistral-nemo

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 modo autónomo está activo desde la instalación
La documentación oficial lo especifica sin rodeos: el modo autónomo (Autonomous Mode) está activado por defecto. En un equipo donde Goose tenga acceso a extensiones capaces de eliminar archivos o ejecutar comandos, cambiar explícitamente de modo antes de la primera sesión es una precaución que no se debe omitir.

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.

  1. 01
    Instalar la CLI Goose
    curl -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.
  2. 02
    Preparar el modelo Ollama
    Verificar que Ollama esté funcionando en el puerto 11434 y ejecutar un modelo anunciado explícitamente como compatible con tool-calling antes de configurar Goose.
  3. 03
    Iniciar goose configure
    Elegir Ollama como proveedor, validar el host propuesto por defecto (localhost:11434) y indicar el nombre exacto del modelo cargado.
  4. 04
    Aumentar el contexto si es necesario
    Si el agente ignora extensiones o un archivo .goosehints, establecer OLLAMA_CONTEXT_LENGTH en un valor superior a 4096 antes de reiniciar una sesión.
  5. 05
    Verificar el modo de permisos
    Antes 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.

Orden de magnitud de la memoria (Q4, solo los pesos) y uso realista con Goose
Tamaño del modeloVRAM aproximadaUso realista con extensiones
7-8B≈ 5 GBLlamadas a herramientas inestables en tareas con varias herramientas encadenadas; probar con GOOSE_TOOLSHIM antes de concluir que el modelo ha fallado
14B≈ 9 GBCaso 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 GBMás fiable en secuencias largas de llamadas a herramientas, a costa de un mayor tiempo de generación en GPU de consumo.
70B≈ 40 GBReservado 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.

Lista de comprobación antes de dar acceso a Goose a otros usuarios o a extensiones sensibles
Punto de controlAjuste a verificar
Modo de permisosPasar de un modo completamente autónomo a uno con aprobación manual o inteligente si no se desea eliminar archivos sin confirmación
Extensiones instalablesConfigurar GOOSE_ALLOWLIST para que apunte a un archivo YAML alojado que restrinja los identificadores y comandos autorizados
Capacidad real del modeloConfirmar la etiqueta tools en ollama.com antes de conectar extensiones; un modelo incompatible exige desactivarlas todas
Contexto suficienteAumentar OLLAMA_CONTEXT_LENGTH por encima de 4096 para evitar que las propias instrucciones de seguridad se trunquen silenciosamente (.goosehints)
!
La allowlist no reemplaza la elección del modo
Una allowlist bien configurada limita las extensiones instalables, pero no impide que un agente en modo autónomo use sin confirmación las extensiones ya autorizadas. Ambos ajustes se complementan, no se sustituyen el uno por el otro.

#Límites de un modelo local para Goose

Lo que falla primero con un pequeño modelo local
SíntomaCausa probable documentada
Extensiones ignoradas, no se siguen las instrucciones de .goosehintsContexto predeterminado de 4096 tokens demasiado corto: aumentar OLLAMA_CONTEXT_LENGTH
Llamadas a herramientas que se detienen durante la sesiónEl modelo pasa a generar texto: activar GOOSE_TOOLSHIM
Intérprete del tool shim lentoModelo intérprete demasiado pesado: pasar a un modelo más pequeño mediante GOOSE_TOOLSHIM_OLLAMA_MODEL
Razonamiento mezclado con llamadas a herramientasEtiquetas «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.

Preguntas frecuentes
¿Goose sigue siendo desarrollado por Block?+
Block inició el proyecto, pero Goose ahora forma parte de la Agentic AI Foundation, acogida por la Linux Foundation. De hecho, el repositorio ha cambiado de organización en GitHub, de block/goose a aaif-goose/goose: un cambio de gobernanza que conviene conocer antes de crear un flujo de trabajo de equipo basado en Goose, aunque Block siga implicado en el proyecto.
¿Por qué Goose ignora mis extensiones o mi archivo .goosehints con Ollama?+
La causa más frecuente es el contexto predeterminado de Ollama, limitado a 4096 tokens y truncado silenciosamente en lugar de devolver un error explícito. La documentación oficial recomienda aumentarlo mediante la variable de entorno OLLAMA_CONTEXT_LENGTH, por ejemplo a 32768, antes de buscar otra causa.
¿Qué hacer si mi modelo local no llama a las herramientas en Goose?+
Habilitar el tool shim con GOOSE_TOOLSHIM=true. Esta funcionalidad experimental detecta llamadas a herramientas escritas en texto plano por modelos sin soporte nativo y las convierte en llamadas ejecutables, a través de un modelo intérprete separado (mistral-nemo por defecto, reemplazable mediante GOOSE_TOOLSHIM_OLLAMA_MODEL). Si el modelo mezcla etiquetas de razonamiento con llamadas a herramientas, el tool shim también filtra esas etiquetas automáticamente una vez activado.
¿Goose puede eliminar archivos sin pedir confirmación?+
Sí, por defecto: el modo completamente autónomo, activo desde la instalación según la documentación oficial, permite a Goose modificar y eliminar archivos sin aprobación. Cambiar a modo de aprobación manual o inteligente modifica este comportamiento, algo que hay que hacer antes de la primera sesión con extensiones sensibles.
¿Se necesita un GPU potente para ejecutar Goose localmente?+
Goose en sí mismo es un cliente ligero escrito en Rust; la mayor parte de la carga depende del modelo elegido mediante Ollama u otro proveedor local. El modelo que actúa como intérprete del tool shim añade una carga de inferencia adicional, separada de la del modelo de conversación; elige un modelo intérprete más pequeño si las respuestas se vuelven lentas.
¿Puede seguir siendo útil con Goose un modelo local sin tool-calling?+
Sí, pero únicamente para conversar: la documentación oficial especifica que Goose depende en gran medida de las llamadas a herramientas y que un modelo que no las admite solo puede mantener conversaciones sencillas; en ese caso, todas las extensiones deben estar desactivadas. Comprobar la etiqueta tools en ollama.com antes de cargar un modelo evita esta limitación.
¿Cómo limitar las extensiones MCP que puede instalar Goose?+
Configurar la variable GOOSE_ALLOWLIST para que apunte a un archivo YAML alojado que enumere los identificadores y comandos de las extensiones autorizadas; Goose lo vuelve a leer en cada reinicio. Es una medida pensada para un despliegue empresarial, que debe combinarse con un modo de permisos no autónomo en lugar de utilizarse por sí sola.

¿Esta guía te ha ayudado?

¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.