Goose, otwarty agent AI działający lokalnie

Goose to agent AI, który uruchamiasz na własnej maszynie i który sam wykonuje zadania: czyta pliki, uruchamia polecenia, wprowadza zmiany i sprawdza wynik. Napisany w Rust, wydawany na licencji Apache 2.0, dostępny jako aplikacja z interfejsem graficznym i jako narzędzie wiersza poleceń. Kluczowa cecha odróżniająca go od konkurencji: model podłączasz dowolny, łącznie z uruchomionym lokalnie.

Nowy właściciel projektu

Zacznę od zmiany, która dezaktualizuje większość starszych materiałów o tym narzędziu, w tym wcześniejszą wersję tego tekstu. Goose powstał w firmie Block, znanej z Square i Cash App, ale nie należy już do niej.

W grudniu 2025 roku Linux Foundation ogłosiła powstanie Agentic AI Foundation, a projekt goose trafił do niej razem z protokołem Model Context Protocol od Anthropica i standardem AGENTS.md od OpenAI. Przeprowadzka repozytorium nastąpiła w kwietniu 2026 roku: adres block/goose przekierowuje dziś na aaif-goose/goose, a dokumentacja przeniosła się na osobną domenę.

Praktyczne znaczenie tej zmiany jest większe, niż wygląda. Projekt przestał być narzędziem jednej firmy, a zaczął być projektem fundacyjnym z opisanym modelem zarządzania. Dla zespołu rozważającego wdrożenie oznacza to mniejsze ryzyko, że rozwój zatrzyma się przy zmianie priorytetów u jednego sponsora. Skala jest przy tym poważna: ponad 52 tysiące gwiazdek na GitHubie i wydania w rytmie mniej więcej tygodniowym, ostatnie oznaczone 1.45.0 z 29 lipca 2026 roku.

To nie jest wyłącznie narzędzie do kodu

Opis, który krąży w sieci, sprowadza goose do agenta programistycznego, i jest to zawężenie samego projektu. Dokumentacja mówi wprost o agencie ogólnego przeznaczenia, przydatnym też do researchu, pisania, automatyzacji i analizy danych.

Różnica jest realna, bo wynika z architektury. Agent nie ma wbudowanej wiedzy o repozytoriach ani specjalnego traktowania kodu. Ma zestaw narzędzi, które może wywołać, a te narzędzia dokładasz sam przez rozszerzenia zgodne z protokołem MCP. Jeśli podłączysz mu dostęp do arkuszy i skrzynki pocztowej, będzie agentem biurowym równie naturalnie jak programistycznym.

To pociąga za sobą konsekwencję, którą warto rozumieć przed pierwszym uruchomieniem. Narzędzie tej klasy jest tak dobre, jak zestaw narzędzi, który mu dasz, i tak bezpieczne, jak uprawnienia, które przy tym nadasz. Agent z dostępem do powłoki systemowej może zrobić na Twojej maszynie wszystko to, co Ty.

Dowolny model, w tym własny

To jest cecha, dla której ludzie wybierają goose zamiast rozwiązań związanych z jednym dostawcą. Konfigurujesz, z jakim modelem agent rozmawia, i lista obejmuje zarówno usługi komercyjne, jak i modele uruchomione lokalnie przez Ollamę.

Wynikają z tego trzy rzeczy. Pierwsza to koszt: przy zadaniach powtarzalnych i prostych możesz zejść na model tańszy, a mocny zostawić do trudnych. Druga to poufność: kod, który nie może opuścić firmy, obsłużysz modelem lokalnym, płacąc za to niższą jakością wyników. Trzecia to odporność na zmiany cennika u jednego dostawcy, bo przejście na inny model jest zmianą wpisu w konfiguracji, a nie przepisaniem procesu pracy.

Uczciwie trzeba dodać, że modele lokalne przy zadaniach agentowych wypadają wyraźnie słabiej niż wiodące modele komercyjne. Agent musi utrzymać plan przez wiele kroków, poprawnie wywołać narzędzia i zauważyć własny błąd, a to są dokładnie te zdolności, na których mniejsze modele tracą najwięcej. Traktuj wariant lokalny jako odpowiedź na wymóg poufności, nie jako sposób na oszczędzanie.

Dlaczego Goose?

Problem z typowymi asystentami AI

Większość narzędzi AI do kodu jest:

Reaktywna - czeka na polecenia, nie przejmuje inicjatywy
Fragmentaryczna - pomaga przy wycinkach kodu, nie przy całych projektach
Wymagająca nadzoru - każdy krok potrzebuje zatwierdzenia
Pozbawiona kontekstu - nie pamięta wcześniejszych decyzji
Odizolowana - nie wpina się w narzędzia programisty

Rozwiązanie Goose

Code

TEXT

┌─────────────────────────────────────────────────────────────┐
│                    GOOSE WORKFLOW                            │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐  │
│   │ ANALYZE │ -> │  PLAN   │ -> │  CODE   │ -> │  TEST   │  │
│   └─────────┘    └─────────┘    └─────────┘    └─────────┘  │
│        │                                             │       │
│        │              ┌─────────┐                    │       │
│        └──────────────│  DEBUG  │<───────────────────┘       │
│                       └─────────┘                            │
│                            │                                 │
│                       ┌─────────┐                            │
│                       │ DEPLOY  │                            │
│                       └─────────┘                            │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Kluczowe zalety

Pełna autonomia - Goose sam planuje i wykonuje
Multi-LLM - Optymalizuj koszty i wydajność między modelami
MCP servers - Rozszerzaj możliwości przez integracje
Open-source - Pełna kontrola nad kodem
Desktop + CLI - Wybierz preferowany interfejs
Rust core - Szybki i bezpieczny

Instalacja

Desktop App (macOS/Windows/Linux)

Code

Bash

# macOS (Homebrew)
brew install --cask block-goose

# Lub pobierz z releases
# https://github.com/aaif-goose/goose/releases

CLI

Code

Bash

# macOS/Linux
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# Albo przez Homebrew
brew install block-goose-cli

# Weryfikacja
goose --version

Konfiguracja modelu

Code

Bash

# Ustaw klucz API
export ANTHROPIC_API_KEY=your_key
# lub
export OPENAI_API_KEY=your_key

# Kreator wyboru dostawcy, modelu i rozszerzeń
goose configure

# Bieżąca konfiguracja i ścieżki do plików
goose info -v

Plik konfiguracyjny

~/.config/goose/config.yaml

YAML

# ~/.config/goose/config.yaml
active_provider: anthropic
providers:
  anthropic:
    enabled: true
    model: claude-sonnet-4-5-20250929
    configured: true

GOOSE_MODE: "smart_approve"
GOOSE_MAX_TURNS: 1000

extensions:
  developer:
    bundled: true
    enabled: true
    name: developer
    timeout: 300
    type: builtin

Podstawowe użycie

Uruchomienie interaktywne

Code

Bash

# Start sesji w bieżącym katalogu
goose session

# Goose przeanalizuje projekt i zapyta o zadanie
Goose: I've analyzed your project. It's a Next.js app with TypeScript.
         What would you like me to do?

> Add a dark mode toggle to the navbar

Jednorazowe zadanie

Code

Bash

# Wykonaj zadanie bez trybu interaktywnego
goose run -t "Create a REST API with Express and MongoDB"

# Z plikiem instrukcji
goose run -i tasks.md

Przykładowe zadania

Code

Bash

# Stworzenie projektu od zera
goose run -t "Create a React + Vite + TypeScript todo app with Zustand state management"

# Refaktoring
goose run -t "Refactor the auth module to use JWT instead of sessions"

# Debugging
goose run -t "The tests in src/api are failing. Find and fix the issues"

# Migracja
goose run -t "Migrate this project from JavaScript to TypeScript"

# Code review
goose run -t "Review the PR changes and suggest improvements"

Autonomiczny workflow

Faza 1: Analiza

Code

TEXT

Goose: Analyzing your request...

Task: Create a REST API with Express and MongoDB
Requirements identified:
- Express.js server setup
- MongoDB connection and models
- CRUD endpoints
- Error handling
- Environment configuration
- Basic authentication

Faza 2: Planowanie

Code

TEXT

Goose: Here's my implementation plan:

1. Initialize Node.js project with TypeScript
2. Set up Express server with middleware
3. Configure MongoDB with Mongoose
4. Create User model with validation
5. Implement auth endpoints (register, login)
6. Add CRUD endpoints for resources
7. Write tests with Jest
8. Add Docker configuration

Proceed? [Y/n]

Faza 3: Implementacja

Code

TEXT

Goose: Starting implementation...

[1/8] Initializing project...
      [ok] Created package.json
      [ok] Installed dependencies
      [ok] Set up TypeScript config

[2/8] Setting up Express...
      [ok] Created src/index.ts
      [ok] Added middleware (cors, helmet, morgan)
      [ok] Configured error handling

[3/8] Configuring MongoDB...
      [ok] Created database connection
      [ok] Added connection retry logic
      [ok] Created .env.example

... continuing autonomously ...

Faza 4: Testowanie

Code

TEXT

Goose: Running tests...

PASS  src/__tests__/auth.test.ts
  [ok] should register a new user (45 ms)
  [ok] should login with valid credentials (23 ms)
  [ok] should reject invalid credentials (12 ms)

PASS  src/__tests__/users.test.ts
  [ok] should create a user (34 ms)
  [ok] should get all users (21 ms)
  ...

Test Suites: 4 passed, 4 total
Tests:       18 passed, 18 total

Faza 5: Debugging (jeśli potrzebne)

Code

TEXT

Goose: Found an issue in user validation...

Error: ValidationError: User validation failed
Location: src/models/User.ts:23

Fixing...
[ok] Updated email regex pattern
[ok] Added proper error messages
[ok] Retesting...

All tests passing now.

Konfiguracja wielu modeli

Goose pozwala rozdzielić model planujący od wykonawczego, a przy pojedynczym uruchomieniu nadpisać jedno i drugie:

~/.config/goose/config.yaml

YAML

# ~/.config/goose/config.yaml
active_provider: anthropic
providers:
  anthropic:
    enabled: true
    model: claude-sonnet-4-5-20250929
    configured: true

# Osobny model dla trybu planowania (/plan)
GOOSE_PLANNER_PROVIDER: "openai"
GOOSE_PLANNER_MODEL: "gpt-4.1"

Code

Bash

# Nadpisanie dostawcy i modelu dla jednego uruchomienia
goose run --provider ollama --model llama3.2 -t "Podsumuj zmiany w tym katalogu"

Integracja z MCP

Goose integruje się z MCP (Model Context Protocol) servers:

Wbudowane serwery

~/.config/goose/config.yaml

YAML

# ~/.config/goose/config.yaml
extensions:
  developer:
    bundled: true
    enabled: true
    name: developer
    timeout: 300
    type: builtin
  memory:
    bundled: true
    enabled: true
    name: memory
    timeout: 300
    type: builtin

Własny serwer MCP

Code

Bash

# Dodanie rozszerzenia w kreatorze: Add Extension
goose configure

# Podłączenie rozszerzenia tylko na czas jednej sesji
goose session --with-extension "uvx mcp-server-fetch"

# Włączenie rozszerzeń wbudowanych na czas sesji
goose session --with-builtin "developer,computercontroller"

Przypadki użycia

Prototypowanie

Code

Bash

goose run -t "Create a full-stack prototype for a booking system with:
- Next.js frontend
- Supabase backend
- Calendar component
- Payment integration mockup"

# Goose w ~30 minut stworzy działający prototyp

Legacy code migration

Code

Bash

goose run -t "Migrate this Express.js API to NestJS:
- Keep the same endpoints
- Use TypeORM instead of Mongoose
- Add Swagger documentation"

Bug fixing

Code

Bash

goose run -t "Users report that file upload fails for images > 5MB.
Find the issue and fix it, then add appropriate tests."

Code review assistant

Code

Bash

goose run -t "Review PR #42 and:
- Check for security issues
- Identify performance problems
- Suggest improvements
- Create a summary"

Documentation generation

Code

Bash

goose run -t "Generate comprehensive documentation for this project:
- API documentation with examples
- Architecture overview
- Setup guide
- Contributing guidelines"

Goose vs alternatywy

Cecha	Goose	Claude Code	Aider	Cursor
Licencja	Apache 2.0	zamknięta	Apache 2.0	zamknięta
Interfejs graficzny	tak	nie, terminal i edytor	nie	tak, edytor
Wiersz poleceń	tak	tak	tak	ograniczony
Wybór dostawcy modelu	dowolny, w tym lokalny	modele Anthropic	dowolny	wbudowany
Rozszerzenia MCP	tak	tak	brak	tak
Rozliczenie	koszt wywołań API	abonament albo API	koszt wywołań API	abonament

Bezpieczeństwo

Approval mode

~/.config/goose/config.yaml

YAML

# ~/.config/goose/config.yaml
# auto, approve, chat albo smart_approve
GOOSE_MODE: "approve"

# Wykrywanie instrukcji wstrzykniętych w czytane treści
SECURITY_PROMPT_ENABLED: true
SECURITY_PROMPT_THRESHOLD: 0.8

Uprawnienia narzędzi

Code

Bash

# Poziomy uprawnień dla poszczególnych narzędzi, zapisywane w permission.yaml
goose configure

# Ograniczenie instalowanych rozszerzeń do zatwierdzonej listy
export GOOSE_ALLOWLIST=https://example.com/goose-allowlist.yaml

Audit log

Code

Bash

# Lista zapisanych sesji
goose session list

# Eksport przebiegu do analizy
goose session export -n moja-sesja --format json > audit.json

# Ścieżki do konfiguracji, sesji i logów
goose info -v

Rozwiązywanie problemów

Goose utknął w pętli

Code

Bash

# Ogranicz liczbę tur i powtórzeń tego samego narzędzia
goose run --max-turns 10 --max-tool-repetitions 3 -t "Task..."

# Lub na stałe w ~/.config/goose/config.yaml
# GOOSE_MAX_TURNS: 20

Za duże koszty API

Code

Bash

# Pokazuj szacowany koszt tokenów w wierszu poleceń
export GOOSE_CLI_SHOW_COST=true

# Automatyczne zwijanie kontekstu po przekroczeniu progu zapełnienia
export GOOSE_AUTO_COMPACT_THRESHOLD=0.6

# Ręczne zwinięcie rozmowy w trakcie sesji: polecenie /compact

Problemy z MCP

Code

Bash

# Włączanie i wyłączanie rozszerzeń
goose configure

# Raport diagnostyczny sesji do zgłoszenia błędu
goose session diagnostics -o diagnostyka.json

# Pełne odpowiedzi narzędzi w konsoli
goose session --debug

Rozszerzenia MCP i co z nich naprawdę wynika

Protokół MCP jest tu warstwą, przez którą agent dostaje dostęp do czegokolwiek poza własnym rozumowaniem. Bez rozszerzeń potrafi rozmawiać, z rozszerzeniami potrafi działać, i to one decydują o tym, do czego to narzędzie się w Twoim przypadku nadaje.

Podstawowy zestaw obejmuje operacje na plikach i uruchamianie poleceń, czyli minimum potrzebne do pracy z repozytorium. Reszta to katalog gotowych serwerów, od dostępu do repozytoriów i systemów zgłoszeń, przez bazy danych, po przeglądarkę i usługi zewnętrzne. Więcej o samym protokole i o tym, jak pisać własne serwery, znajdziesz przy okazji zestawu narzędzi MCP. Z gotowych rozszerzeń najczęściej dokłada się serwer MCP GitHuba, bo domyka największą lukę: agent widzi pliki, ale bez niego nie widzi zgłoszeń, propozycji zmian ani wyników potoku budowania. Ma wariant zdalny bez instalacji i lokalny z własnym tokenem, przydatny przy instalacji GitHuba we własnej infrastrukturze.

Warto jednak podejść do tego z umiarem, bo tu działa mechanizm odwrotny do intuicji. Każde podłączone rozszerzenie dokłada opisy swoich narzędzi do kontekstu wysyłanego przy każdym kroku. Dwadzieścia rozszerzeń oznacza kilkadziesiąt opisów narzędzi w każdym wywołaniu, co podnosi koszt i, co gorsza, pogarsza trafność wyboru. Model mający do dyspozycji pięć narzędzi wybiera właściwe niemal zawsze, model mający ich sześćdziesiąt zaczyna się mylić.

Praktyczna zasada brzmi więc: podłączaj to, czego zadanie faktycznie wymaga, i wyłączaj resztę. Osobne profile konfiguracji dla różnych rodzajów pracy sprawdzają się tu lepiej niż jeden zestaw obejmujący wszystko. Do przeglądania repozytorium wystarczą pliki i polecenia, do zadania obejmującego zgłoszenia i wdrożenie dokładasz to, co potrzebne, i wracasz do zestawu podstawowego, kiedy skończysz.

Ile to realnie kosztuje

Samo narzędzie jest darmowe, więc cały rachunek to wywołania modelu. Ta pozornie prosta odpowiedź kryje pułapkę, którą warto zrozumieć przed pierwszym dłuższym zadaniem.

Agent nie wykonuje jednego wywołania na polecenie. Wykonuje ich tyle, ile potrzebuje kroków, a przy każdym kroku wysyła narastającą historię rozmowy: treść plików, wyniki poleceń, wcześniejsze próby. Zadanie rozwiązane w piętnastu krokach potrafi zużyć więcej tokenów wejściowych niż dwadzieścia zwykłych rozmów z modelem, bo kontekst rośnie z każdym obrotem pętli.

Wynika z tego kilka praktycznych zasad. Zadania formułuj wąsko, bo agent zapuszczony na cały projekt spali budżet na czytaniu plików, które go nie dotyczą. Pracuj w katalogu ograniczonym do właściwego fragmentu repozytorium, a nie w korzeniu monorepo. Przerywaj sesję, która krąży wokół tego samego błędu, bo każdy kolejny obrót kosztuje więcej niż poprzedni i rzadko przynosi przełom.

Warto też policzyć jedno zadanie, zanim uznasz to za stały element pracy zespołu. Uruchom typowe polecenie, sprawdź zużycie tokenów po stronie dostawcy i pomnóż przez spodziewaną liczbę takich zadań dziennie i przez liczbę osób. Ta liczba mówi więcej niż jakiekolwiek zestawienie cenników.

Bezpieczeństwo, czyli o czym trzeba pomyśleć wcześniej

Agent wykonujący polecenia na Twojej maszynie to inne ryzyko niż asystent podpowiadający kod, i warto nazwać je wprost, zamiast poprzestać na wyliczance funkcji.

Podstawowa zasada brzmi: agent działa z Twoimi uprawnieniami. Jeśli Ty możesz usunąć katalog, przesłać plik albo wypchnąć zmiany do repozytorium, on też może. Tryb zatwierdzania operacji istnieje właśnie po to, żeby wstawić człowieka przed czynności nieodwracalne, i wyłączanie go dla wygody to decyzja, którą trzeba podejmować świadomie.

Drugie ryzyko dotyczy treści, które agent czyta. Plik z repozytorium, strona pobrana z sieci albo opis zgłoszenia mogą zawierać instrukcje skierowane do modelu, a agent nie ma wbudowanego sposobu, żeby odróżnić polecenie od użytkownika od polecenia znalezionego w danych. To nie jest teoria, tylko znana klasa ataku na systemy tej klasy. Wniosek praktyczny: uruchamiaj agenta na repozytoriach, którym ufasz, i traktuj jego kontakt z zewnętrzną treścią jak kontakt z danymi niezaufanymi.

Trzecia sprawa to sekrety. Agent czytający pliki projektu przeczyta też plik ze zmiennymi środowiskowymi, a jego treść trafi do kontekstu wysyłanego do dostawcy modelu. Jeśli pracujesz na repozytorium z kluczami produkcyjnymi, wyłącz te pliki z zakresu albo pracuj na modelu lokalnym.

Typowe błędy

Pierwszy to zbyt szerokie polecenie. Zdanie w rodzaju „popraw wydajność aplikacji" daje agentowi zbyt dużo swobody i kończy się zmianami w kilkunastu plikach, których nikt nie chce przeglądać. Im węższe zadanie, tym większa szansa na wynik nadający się do przyjęcia.

Drugi to praca bez systemu kontroli wersji albo na brudnym drzewie roboczym. Agent zmienia pliki na miejscu, więc bez czystego punktu odniesienia nie odróżnisz jego zmian od własnych. Zaczynaj sesję od czystego stanu, żeby móc jednym poleceniem cofnąć wszystko.

Trzeci to przyjmowanie zmian bez czytania. Agent potrafi napisać kod, który się kompiluje, przechodzi testy i robi coś innego, niż zamierzałeś. Przegląd zmian jest tu tym samym, czym przegląd cudzego kodu, i pomijanie go zamienia oszczędność czasu w dług.

Czwarty to podłączanie rozszerzeń bez sprawdzenia, co robią. Każde rozszerzenie MCP dokłada agentowi możliwości, a niektóre dają dostęp do usług zewnętrznych z Twoimi poświadczeniami. Warto potraktować je jak zależności w projekcie, czyli sprawdzić źródło przed instalacją.

Piąty to oczekiwanie, że agent poradzi sobie z zadaniem, którego sam nie umiesz zdefiniować. Jeśli nie potrafisz opisać, jak wygląda dobry wynik, nie będziesz w stanie ocenić tego, co dostaniesz, ani poprawić kierunku w połowie drogi. Najlepiej sprawdza się tu prosty test przed uruchomieniem sesji: napisz jednym zdaniem, po czym poznasz, że zadanie zostało wykonane dobrze. Jeśli to zdanie nie chce się napisać, agent też sobie nie poradzi, a problem leży w zadaniu, a nie w narzędziu.

FAQ

Czy Goose jest darmowy?

Samo narzędzie tak, na licencji Apache 2.0. Płacisz wyłącznie za wywołania modelu u wybranego dostawcy, a przy modelu uruchomionym lokalnie nie płacisz nic poza prądem i sprzętem.

Czy Goose nadal należy do Block?

Nie. Projekt powstał w Block, ale został przekazany Agentic AI Foundation przy Linux Foundation, a repozytorium przeniesiono do organizacji aaif-goose. Stary adres przekierowuje na nowy.

Jakie modele obsługuje?

Zarówno usługi komercyjne, jak i modele uruchomione lokalnie. Wybór konfigurujesz i możesz go zmienić bez zmiany sposobu pracy, co odróżnia to narzędzie od rozwiązań związanych z jednym dostawcą.

Czy da się pracować bez dostępu do sieci?

Tak, z modelem lokalnym. Licz się jednak z wyraźnie gorszymi wynikami przy zadaniach wieloetapowych, bo utrzymanie planu przez wiele kroków to zdolność, na której mniejsze modele tracą najbardziej.

Czym różni się od Claude Code?

Głównie otwartością i swobodą wyboru modelu. Goose jest na licencji Apache 2.0, ma interfejs graficzny obok wiersza poleceń i rozmawia z dowolnym dostawcą. Claude Code jest rozwiązaniem zamkniętym, związanym z modelami jednego producenta, za to głębiej dopracowanym pod pracę z kodem.

Kod źródłowy i wydania znajdziesz w repozytorium projektu, a informacje o przejściu pod skrzydła fundacji w komunikacie Linux Foundation.