Fortgeschritten 12 Min.Agenten

Goose (Block): der lokale KI-Agent in Ihrem terminal

Direkte Antwort

Ja: Führen Sie goose configure aus, wählen Sie Ollama, behalten Sie die Standardadresse http://localhost:11434 bei und geben Sie ein Ollama-Modell an, das Tool-Calling unterstützt. Für den lokalen Betrieb sind zwei Einstellungen wichtig: OLLAMA_CONTEXT_LENGTH über den Standardwert von 4096 Tokens hinaus erhöhen und den Tool-Shim (GOOSE_TOOLSHIM=true) aktivieren, wenn das Modell die Tools in Textform erklärt, statt sie aufzurufen. Goose ist inzwischen ein Projekt der Agentic AI Foundation, nicht mehr nur von Block.

Goose ist ein KI-Agent für die Befehlszeile und als Desktop-Anwendung, der zunächst von Block veröffentlicht und anschließend an die Agentic AI Foundation übergeben wurde. Dieser Leitfaden behandelt die Konfiguration mit einer lokalen Ollama-Instanz, den Tool-Shim, der die fehlende native Unterstützung für Tool-Aufrufe bei manchen Modellen ausgleicht, die Berechtigungsmodi (standardmäßig autonom) und die tatsächlichen Grenzen eines kleinen lokalen Modells im Umgang mit den MCP-Erweiterungen von Goose.

Von Mohamed Meguedmi·Aktualisierung 2026-09-28·Unter Windows, macOS und Linux getestet

#Was ist Goose heute?

Goose präsentiert sich als nativer Open-Source-KI-Agent – als Desktop-Anwendung, CLI und API – für Code, Workflows und darüber hinaus, geschrieben in Rust. Das Repository (inzwischen aaif-goose/goose) zählt zum Stand vom 28. September 2026 fast 55.000 Sterne; die Version v1.52.0 wurde am 23. September 2026 veröffentlicht.

Falls Sie ältere Darstellungen gelesen haben, muss eine Information korrigiert werden: Goose ist kein isoliertes Projekt von Block mehr, sondern gehört inzwischen zur Agentic AI Foundation (AAIF), die bei der Linux Foundation angesiedelt ist. Block bleibt der ursprüngliche Initiator des Projekts, doch die Governance hat sich geändert — ein Detail, das bei der Einschätzung der langfristigen Tragfähigkeit des Projekts zählt, bevor Sie darauf einen Workflow aufbauen.

Goose funktioniert mit über 15 Modellanbietern (Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock und anderen) und verbindet sich über das offene MCP-Protokoll (Model Context Protocol) mit über 70 Erweiterungen.

Es gibt auch eine Anbindung an Ramalama, eine lokale Engine, die Modelle als OCI-Artefakte statt im proprietären Format von Ollama bereitstellt. Da die API kompatibel ist, kann Goose Ramalama direkt über seinen Ollama-Provider nutzen, ohne speziellen Code – eine nützliche Option für Infrastrukturen, die bereits auf Standardwerkzeugen zur Containerisierung wie Podman oder Docker statt auf Ollama aufbauen.

#Ollama verbinden

Das Kit für lokale Agenten

Agenten, die auf Ihrem Rechner handeln: agentisches Cline, MCP, n8n + Ollama und lokale Automatisierungen.

  • Lebenslanger Online-Zugang
  • PDF + Dateien
  • Erstattung binnen 30 Tagen
Das Paket „Lokale Agenten“ →oder alle Pakete lebenslang — 49 € →

Die Konfiguration erfolgt über den interaktiven Assistenten goose configure, der zuerst den Anbieter und dann den Host abfragt. Wenn für Ollama kein Host angegeben wird, verwendet Goose standardmäßig localhost:11434; das Präfix http:// wird automatisch hinzugefügt, wenn kein Schema angegeben ist.

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

Wenn Ollama auf einem anderen Rechner im Netzwerk läuft, muss vor dem Start der Konfiguration ausdrücklich OLLAMA_HOST=http://{hôte}:{port} festgelegt werden. Für Modelle, die auf ollama.com statt lokal gehostet werden, ist Ollama Cloud als Anbieter auszuwählen, nicht Ollama.

i
Empfohlenes Modell zum Einstieg
Die offizielle Dokumentation verwendet qwen2.5 als Beispiel für ein Modell, das vor der Konfiguration von Goose gestartet werden soll. Sie betont dabei, dass das Modell ausdrücklich als mit Tool-Calling kompatibel ausgewiesen sein muss – ein beliebiges allgemeines Chatmodell reicht nicht aus.

#Die Falle beim Kontext mit 4096 Tokens

Der Standardwert von Ollama für das Kontextfenster beträgt 4096 Tokens, und Ollama kürzt den Kontext stillschweigend, statt eine explizite Fehlermeldung zurückzugeben. Bei einem Agenten wie Goose, der Projektanweisungen (.goosehints), den Gesprächsverlauf und Erweiterungsdefinitionen lädt, wird diese Grenze schnell erreicht.

!
Typisches Symptom
Wenn Goose Ihre .goosehints-Dateien ignoriert oder bei aktiven Erweiterungen den Faden zu verlieren scheint, nennt die offizielle Dokumentation zunächst diesen zu kurzen Standardkontext als Ursache. Er sollte über die Umgebungsvariable OLLAMA_CONTEXT_LENGTH vergrößert werden, bevor Sie anderswo nach der Ursache suchen.
Erweitertes Kontextfenster
export OLLAMA_CONTEXT_LENGTH=32768

#Tool shim: Fehlerbehebung beim Aufruf von Tools

Einige Modelle unterstützen Tool-Aufrufe nicht nativ oder wechseln während einer Sitzung zu einer Ausgabe als Klartext statt eines strukturierten Aufrufs. Der Tool-Shim von Goose erkennt diese Textformate und wandelt sie in ausführbare Tool-Aufrufe um. Das Projekt kennzeichnet diese Funktion als experimentell.

Tool-Shim aktivieren
export GOOSE_TOOLSHIM=true
ollama pull mistral-nemo

Der Tool-Shim nutzt ein Interpreter-Modell, das vom Hauptmodell für die Konversation getrennt ist – standardmäßig mistral-nemo über Ollama, austauschbar über GOOSE_TOOLSHIM_OLLAMA_MODEL. Die Dokumentation nennt lokale Modelle (Ollama, llama.cpp) ohne natives Tool-Calling ausdrücklich als Hauptanwendungsfall sowie Modelle, die Reasoning-Tags („think“) mit Tool-Aufrufen vermischen, was häufig zu Parsing-Fehlern führt.

Ein alternativer Modus nutzt das in Goose integrierte lokale Inferenz-Backend anstelle einer separaten Ollama-Instanz, über GOOSE_TOOLSHIM_BACKEND=local und einen zwingend erforderlichen Modellnamen (GOOSE_TOOLSHIM_MODEL) – andernfalls schlägt der Start fehl.

#Berechtigungsmodi: standardmäßig autonom

Goose bietet vier Berechtigungsmodi: vollständig autonom (ändert und löscht Dateien ohne Bestätigung), manuelle Genehmigung (fragt bei jedem Tool nach einer Bestätigung), intelligente Genehmigung (genehmigt automatisch Aktionen mit geringem Risiko) und reiner Gesprächsmodus (keine Änderungen, keine Tools).

!
Der autonome Modus ist ab der Installation aktiv.
Die offizielle Dokumentation stellt es unmissverständlich klar: Der autonome Modus (Autonomous Mode) ist standardmäßig aktiv. Auf einem Rechner, auf dem Goose Zugriff auf Erweiterungen hat, die Dateien löschen oder Befehle ausführen können, ist das ausdrückliche Ändern des Modus vor der ersten Sitzung eine Vorsichtsmaßnahme, die Sie keinesfalls auslassen sollten.

Der Moduswechsel erfolgt jederzeit, auch während einer Sitzung, über /mode auto, /mode smart_approve, /mode approve oder /mode chat in der CLI, oder über das Menü unten in der Desktop-Anwendung.

#MCP-Erweiterungen und Allowlist

Goose verbindet sich über das MCP-Protokoll mit Erweiterungen und installiert standardmäßig jeden angeforderten MCP-Server. Für den beruflichen Einsatz bietet das Projekt eine Allowlist: eine unter einer URL gehostete YAML-Datei, auf die die Variable GOOSE_ALLOWLIST verweist. Diese Datei beschränkt die installierbaren Erweiterungen auf eine explizite Liste von Kennungen und Befehlen.

Ohne diese Allowlist hindert technisch nichts den Agenten daran, einen ungeprüften MCP-Server eines Drittanbieters zu installieren, wenn der Benutzer (oder das Modell im autonomen Modus) dies anfordert – ein Punkt, der zusammen mit der Wahl des oben genannten Berechtigungsmodus berücksichtigt werden sollte.

Die Allowlist wird als einfache YAML-Datei bereitgestellt, die zulässige Paare aus Kennung und Befehl auflistet. Die Datei liegt unter einer URL, von der Goose sie bei jedem Neustart über die Variable GOOSE_ALLOWLIST erneut einliest. Diese Maßnahme ist für den Einsatz in Unternehmen gedacht, in denen ein Administrator die installierbaren Erweiterungen auf eine vorab geprüfte Liste beschränken möchte, statt auf das Urteilsvermögen jedes einzelnen Nutzers oder des Modells im autonomen Modus zu vertrauen.

  1. 01
    Die Goose-CLI installieren
    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
    Das Ollama-Modell vorbereiten
    Prüfen, ob Ollama auf Port 11434 läuft, und ein Modell starten, das ausdrücklich als mit Tool-Calling kompatibel ausgewiesen ist, bevor Goose konfiguriert wird.
  3. 03
    goose configure ausführen
    Ollama als Anbieter auswählen, den standardmäßig vorgeschlagenen Host (localhost:11434) bestätigen und den genauen Namen des geladenen Modells angeben.
  4. 04
    Den Kontext gegebenenfalls erhöhen
    Wenn der Agent Erweiterungen oder eine .goosehints-Datei ignoriert, OLLAMA_CONTEXT_LENGTH auf einen Wert über 4096 setzen, bevor eine Sitzung erneut gestartet wird.
  5. 05
    Berechtigungsmodus prüfen
    Vor der ersten Sitzung mit sensiblen Erweiterungen ausdrücklich in den Modus für manuelle oder intelligente Genehmigung wechseln, falls der standardmäßige autonome Modus nicht gewünscht ist.

#Welches Modell passt zum verfügbaren Speicher?

Die offizielle Dokumentation ist in einem oft heruntergespielten Punkt eindeutig: Goose stützt sich in hohem Maße auf Toolaufrufe, und ein Modell, das diese nicht unterstützt, kann nur einfache Gespräche führen – alle Goose-Erweiterungen müssen dann deaktiviert werden. Die Wahl des Modells ist daher nicht nur eine Frage der Antwortqualität: Sie ist eine Ja-oder-Nein-Bedingung dafür, dass die MCP-Erweiterungen überhaupt funktionieren.

Größenordnung des Speicherbedarfs (Q4, nur Modellgewichte) und realistischer Einsatz mit Goose
ModellgrößeUngefährer VRAM-BedarfRealistische Nutzung mit Erweiterungen
7-8B≈ 5 GBInstabile Tool-Aufrufe bei Aufgaben mit mehreren nacheinander eingesetzten Tools; mit GOOSE_TOOLSHIM testen, bevor Sie auf ein Versagen des Modells schließen
14B≈ 9 GBTypischer Anwendungsfall für einen Entwicklungsrechner; vor dem Laden des Modells das Label tools auf ollama.com überprüfen
32B≈ 19–20 GBZuverlässiger bei langen Abfolgen von Tool-Aufrufen, allerdings mit längeren Generierungszeiten auf Consumer-GPUs
70B≈ 40 GBNur für Systeme mit viel VRAM oder gemeinsam genutztem Arbeitsspeicher (Mac Studio, Multi-GPU-Workstations); für den täglichen lokalen Einsatz selten relevant.

Diese Größenordnungen ersetzen nicht die Prüfung der Kennzeichnung tools in der Modellbeschreibung: Eine Variante, die nicht als mit Tool-Calling kompatibel ausgewiesen ist, scheitert bei den Erweiterungen unabhängig von ihrer Größe – genau wie es die oben zitierte offizielle Dokumentation erläutert.

#Sicherheitscheckliste vor einer Bereitstellung zur gemeinsamen Nutzung

Drei Einstellungen, die bereits separat in diesem Handbuch dokumentiert sind, bilden gemeinsam die Grundlage für einen sichereren Einsatz von Goose im Vergleich zu einer Standardinstallation auf einem geteilten Rechner oder einem Teamserver.

Checkliste, bevor Sie Goose für andere Nutzer oder sensible Erweiterungen öffnen
PrüfpunktZu prüfende Einstellung
BerechtigungsmodusVom vollständig autonomen Modus auf manuelle oder intelligente Genehmigung umstellen, wenn das Löschen von Dateien ohne Bestätigung nicht gewünscht ist
Installierbare ErweiterungenGOOSE_ALLOWLIST auf eine gehostete YAML-Datei setzen, die die zulässigen Kennungen und Befehle einschränkt
Tatsächliche Leistung des ModellsVor dem Anschließen von Erweiterungen prüfen, ob auf ollama.com das Label tools vorhanden ist; bei einem inkompatiblen Modell müssen alle Erweiterungen deaktiviert werden
Ausreichender KontextOLLAMA_CONTEXT_LENGTH auf einen Wert über 4096 erhöhen, um zu verhindern, dass die Sicherheitsanweisungen selbst (.goosehints) unbemerkt abgeschnitten werden
!
Die Allowlist ersetzt nicht die Wahl des Modus
Eine gut konfigurierte Allowlist begrenzt die installierbaren Erweiterungen, verhindert aber nicht, dass ein Agent im autonomen Modus bereits erlaubte Erweiterungen ohne Bestätigung verwendet. Die beiden Einstellungen ergänzen sich; sie ersetzen einander nicht.

#Grenzen eines lokalen Modells für Goose

Was bei einem kleinen lokalen Modell zuerst ausfällt
SymptomDokumentierte wahrscheinliche Ursache
Erweiterungen werden ignoriert, Hinweise aus .goosehints werden nicht befolgtStandardkontext mit 4096 Tokens zu kurz: OLLAMA_CONTEXT_LENGTH erhöhen
Tool-Aufrufe, die während einer Sitzung abbrechenDas Modell wechselt zur Textausgabe: GOOSE_TOOLSHIM aktivieren
Langsamer Interpreter des Tool-ShimsInterpreter-Modell zu ressourcenintensiv: über GOOSE_TOOLSHIM_OLLAMA_MODEL zu einem kleineren Modell wechseln
Mit Tool-Aufrufen vermischte GedankengängeStörende „think“-Tags: Der Tool-Shim filtert sie nach seiner Aktivierung automatisch heraus

DeepSeek-R1 unterstützt in seiner ursprünglichen Version laut der offiziellen Dokumentation keine Tool-Aufrufe. Die Dokumentation schlägt als Alternative eine für Goose angepasste Community-Version vor – ein konkretes Beispiel für den Unterschied zwischen einem Modell, das als leistungsfähig in Gesprächen gilt, und seiner tatsächlichen Fähigkeit, Tools zu steuern.

Diese Diskrepanz zwischen Schlussfolgerungsfähigkeit und zuverlässiger Ausführung ist die strukturelle Grenze, die Sie vor einer lokalen Installation von Goose beachten sollten: Gute Antworten auf offene Fragen garantieren nicht, dass ein Modell mehrere Tool-Aufrufe ohne Formatfehler aneinanderreihen kann. Zunächst eine einfache, überprüfbare Aufgabe zu testen – eine Datei lesen, einen harmlosen Befehl ausführen –, bevor Sie dem Agenten eine mehrstufige Aufgabe anvertrauen, bleibt der schnellste Weg, ein ungeeignetes Modell zu erkennen.

Häufig gestellte Fragen
Wird Goose weiterhin von Block entwickelt?+
Block hat das Projekt ursprünglich ins Leben gerufen, aber Goose gehört inzwischen zur Agentic AI Foundation, die bei der Linux Foundation angesiedelt ist. Das Repository hat zudem die GitHub-Organisation gewechselt, von block/goose zu aaif-goose/goose — eine Änderung der Governance, die Sie kennen sollten, bevor Sie darauf einen Teamworkflow aufbauen, auch wenn Block weiterhin am Projekt beteiligt ist.
Warum ignoriert Goose meine Erweiterungen oder meine Datei .goosehints mit Ollama?+
Die häufigste Ursache ist der Standardkontext von Ollama, der auf 4096 Tokens begrenzt ist und ohne Hinweis abgeschnitten wird, statt eine ausdrückliche Fehlermeldung zurückzugeben. Die offizielle Dokumentation empfiehlt, die Kontextlänge über die Umgebungsvariable OLLAMA_CONTEXT_LENGTH zu erhöhen, beispielsweise auf 32768, bevor Sie nach einer anderen Ursache suchen.
Was tun, wenn mein lokales Modell die Tools in Goose nicht aufruft?+
Den Tool-Shim mit GOOSE_TOOLSHIM=true aktivieren. Diese experimentelle Funktion erkennt Tool-Aufrufe, die von Modellen ohne native Unterstützung als Klartext ausgegeben werden, und wandelt sie mithilfe eines separaten Interpreter-Modells in ausführbare Aufrufe um (standardmäßig mistral-nemo, über GOOSE_TOOLSHIM_OLLAMA_MODEL ersetzbar). Wenn das Modell Reasoning-Tags mit Tool-Aufrufen vermischt, filtert der Tool-Shim nach seiner Aktivierung auch diese Tags automatisch heraus.
Kann Goose Dateien ohne Bestätigung löschen?+
Ja, im Standardmodus: Der vollständig autonome Modus, der laut offizieller Dokumentation bereits ab der Installation aktiv ist, erlaubt Goose, Dateien ohne Zustimmung zu ändern und zu löschen. Der Wechsel in den Modus mit manueller oder intelligenter Zustimmung ändert dieses Verhalten und sollte vor der ersten Sitzung mit sensiblen Erweiterungen erfolgen.
Ist eine leistungsstarke GPU erforderlich, um Goose lokal auszuführen?+
Goose selbst ist ein schlanker, in Rust geschriebener Client; der Großteil der Last hängt vom Modell ab, das Sie über Ollama oder einen anderen lokalen Anbieter wählen. Das Interpreter-Modell des Tool-Shims verursacht zusätzliche Inferenzlast, getrennt vom Konversationsmodell. Wählen Sie dafür ein kleineres Modell, wenn die Antworten langsam werden.
Kann ein lokales Modell ohne Tool-Calling dennoch mit Goose verwendet werden?+
Ja, aber nur zum Chatten: Die offizielle Dokumentation erläutert, dass Goose stark auf Tool-Aufrufe angewiesen ist und ein Modell ohne diese Unterstützung nur einfache Gespräche führen kann. Alle Erweiterungen müssen dann deaktiviert werden. Das Label tools auf ollama.com vor dem Laden eines Modells zu prüfen, verhindert diese Einschränkung.
Wie können die MCP-Erweiterungen, die Goose installieren kann, eingeschränkt werden?+
Die Variable GOOSE_ALLOWLIST auf eine gehostete YAML-Datei setzen, die die Kennungen und Befehle der erlaubten Erweiterungen auflistet; Goose liest sie bei jedem Neustart erneut ein. Diese Maßnahme ist für den Einsatz in Unternehmen gedacht und sollte mit einem nicht autonomen Berechtigungsmodus kombiniert werden, statt sie allein zu verwenden.
Hat Ihnen dieser Guide geholfen?

Haben Sie Feedback, einen Fehler entdeckt oder möchten Sie etwas präzisieren? Geben Sie uns Bescheid – so wird der Guide für alle besser.