Goose: a nyílt forráskódú agent, amelyet a saját gépeden futtatsz

A goose nyílt forráskódú coding agent, amely a fejlesztő saját gépén fut, nem egy szolgáltató felhőjében. Asztali alkalmazásként macOS, Linux és Windows alá, teljes CLI-ként és beágyazható API-ként is megjelenik, és Rustban írták. A Block 2025 januárjában tette közzé, 2025 decemberében pedig a Linux Foundation Agentic AI Foundation alapítványának adományozta, az Anthropic Model Context Protocoljával és az OpenAI AGENTS.md-jével együtt, tehát a projektet ma már egy alapítvány irányítja, nem a társaság, amely kezdeményezte.

Amit itt nem áru a kiterjesztési modell. A goose a Model Context Protocol szervereken keresztül éri el a külvilágot, és egy munkamenetben használható eszközök az ehhez bekapcsolt kiterjesztések. Ez azt jelenti, hogy az agent képességfelülete konfigurációs döntés, nem a bináris tulajdonsága, ami érdemben más alak, mint egy rögzített beépített eszközkészlettel rendelkező agent.

A dokumentáció elolvasása után a pozíció: ez egy komolyan vett, jól dokumentált agent, amely a kereskedelmi vezetőknek a csiszoltságban és az egyedi feladatin minőségben elmarad, és abban nyer, hogy minden része megvizsgálható, forkolható és továbbterjeszthető, beleértve azt a formátumot is, amelyben a munkafolyamatai megíródnak. A legmeggyőzőbb platformként arról, hogyan szabványosítsuk az agentek viselkedését egy flotta mentén, a legkevésbé meggyőző napi egyedi eszközként, ha amúgy is licencelve van egy kereskedelmi eszköz jobb kiegészítéssel.

Mi a goose

Két felület, egy mag. Az asztali alkalmazás a hozzáférhető felét, a CLI a szkriptelhetőt adja; mindkettő ugyanazt a munkamenet-logikát, ugyanazt a konfigurációs fájlt és ugyanazt a kiterjesztéslistát hajtja. A repository Apache-2.0 licencű, és körülbelül 55 000 csillagot és 6 400 forkot mutat.

• Apache-2.0 licencű, Rustban írt, aláírt kiadási artefaktumokként és egy egysoros telepítő szkriptként a CLI-hez publikálva.
• Több mint 15 LLM szolgáltató, köztük Anthropic, OpenAI, Google, Azure, Bedrock, OpenRouter és Ollama, API-kulccsal vagy meglévő előfizetéssel ACP-n át.
• Több mint 70 kiterjesztés MCP-n keresztül, négy típusban: stdio, builtin, platform és streamable HTTP.
• Négy jogosultsági mód, a teljesen autonómtól a csak chatig, munkamenetenként választható, fölötte granuláris eszközjogosultságokkal.
• Receptek: verziózott YAML-fájlok, amelyek utasításokat, kiterjesztéseket, paramétereket, beállításokat, retry-kat és egy JSON válasz sémát egyetlen átnézhető egységbe zárnak.
• Automatikus tömörítés a kontextusablak 80 százalékánál, eszközkimenetek összefoglalása és egy 1000-es alapértékű kemény fordulókorlát.
• Ütemező, ACP szerver Zedhez hasonló szerkesztőkhöz, beépített review parancs és dokumentált támogatás saját márkázott build szállításához.

Hogyan működik

A hurok a szokásos: küldj kontextust, kapj egy üzenetet, és ha van benne eszközhívás, futtasd le az eszközt, és az eredményt tedd be a következő körbe. Amit a goose a hurok köré épít, az a könyvelés. Tokenelszámolás, tömörítés, fordulókorlát, költségbecslés és egy jogosultsági kapu mind a modell és a fájlrendszer között van, és mindegyik beállítás, nem a binárisban rejtett heurisztika.

A munkamenetek egyetlen folyamatos beszélgetés. A tokenjelző mutatja a kihasznált és az elérhető részt, és amikor eléri a tömörítési küszöböt, a régebbi rész összefoglalódik, miközben a korábbi üzenetek láthatók maradnak a felületen. Ez ésszerű tervezés, és azt jelenti, hogy egy hosszú munkamenet jóval azelőtt veszít pontosságot, hogy elbukna.

# telepítsd a CLI-t (macOS, Linux), majd válassz szolgáltatót
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash
goose configure

# indíts munkamenetet egy repóban, fordulókorláttal
cd ~/code/my-service
goose session --max-turns 25 --with-builtin developer

# felügyelet nélkül: futtasd a receptet, csak a választ írd ki
goose run --recipe release-check.yaml --params env=staging --quiet

# melyik szolgáltató, melyik modell, melyik kiterjesztések
goose info --verbose

A szolgáltatói beállítások egy YAML konfigurációs fájlban vannak, a titkok alapértelmezés szerint a rendszer kulcstárában. A GOOSE_DISABLE_KEYRING környezeti változó fájlos tárolásra kényszerít, amit a dokumentáció a kulcstár nélküli konténerekhez és headless Linuxhoz javasol. Az 1.10.0 verzió óta a munkamenetek egy SQLite adatbázisban vannak egy JSONL fájlgyűjtemény helyett, így a mentés és a migráció adatbázisprobléma.

Kontextus, fordulók és költség

Három beállítás dönti el, meddig fut egy munkamenet és mennyibe kerül, és mindhárom egyszerű konfigurációs kulcs, nem rejtett viselkedés. A dokumentáció még munkatípusonként javasolt értékeket is ad, ami szokatlan és hasznos.

• Az automatikus tömörítési küszöb, alapérték 0.8, vagyis a kontextusablak azon hányada, ahol a régi fordulók összefoglalódnak; 0.0 kikapcsolja.
• A felügyelet nélküli fordulók maximuma, alapérték 1000. A limit elérésére az agent megáll és rákérdez. A dokumentáció 5-től 10-ig javasol felfedező munkához, 100-at vagy többet migrációhoz.
• Az Anthropic prompt cache élettartama, 5 perc alapértékkel vagy 1 óra, hogy a gyorsítótárazott előtag éljen át az üresjárati szakaszokon magasabb cache-írási aránnyal.
• Munkamenetenkénti költségbecslés az OpenRouter katalógusából számolva és lokálisan gyorsítótárazva. A dokumentáció egyértelmű, hogy ez nyilvános árakon alapuló becslés, nem számla.

A kontextuslimitek sorrendben oldódnak fel: explicit felülírás, majd deklarátív szolgáltatókonfiguráció, majd futásidejű felismerés, majd modellmetadátum, végül 128 000 tokenes alapérték. Ez az utolsó visszaesés számít, ha a goose saját modellnevet hordozó gatewayre mutat: a jelző rossz számot mutat, amíg a limitet explicit nem állítod be, ami kis csapda annak, aki proxy mögött futtatja.

Kiterjesztések és receptek

Egy kiterjesztés MCP szerver névvél, parancssal, timeouttal és az opcionális eszközlistával, amelyeket kiadhat. Ez a lista gyakorlatban a legfontosabb beállítás: minden látott eszköz egy döntés, amelyet a modellnek minden fordulóban helyesen kell meghoznia, és a lista szűkítése olcsóbb, mint egy jobb prompt.

version: "1.0.0"
title: "Kiadási kockázat ellenőrzése"
description: "Az ágat hasonlítsd egy bázishoz, és jelentsd a kockázatot"
parameters:
  - key: base
    input_type: string
    requirement: required
    description: "Az ág, amelyhez hasonlítunk"
prompt: |
  Hasonlítsd ezt az ágat a {{ base }} ággal, és foglald
  össze a viselkedési kockázatot szállítási sorrendben.

extensions:
  - type: builtin
    name: developer
    timeout: 300
  - type: stdio
    name: github
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env_keys: [GITHUB_PERSONAL_ACCESS_TOKEN]
    available_tools: [get_file_contents, search_code]

settings:
  goose_provider: anthropic
  temperature: 0.2
  max_turns: 40

retry:
  max_retries: 2
  timeout_seconds: 30
  checks:
    - type: shell
      command: "test -f RISK.md"

Ez a másolni érdemes forma. Egy recept átnézhető YAML egy validáló parancs mellett, így egy ütemezett feladat újrapróbálható addig, amíg valami ellenőrizhetőt nem állít elő, ahelyett hogy vakon indulna újra, és az ellenőrzés elutasít egy olyan sablonváltozót, aminek nincs hozzá tartozó paraméterdefiníciója. A szubreceptek ugyanígy épülnek fel, a szülő recept képezi le az értékeket a gyerekekre, bár a dokumentáció ezt a funkciót még kísérletinek jelöli, és megjegyzi, hogy a szubreceptek elkülönített munkamenetben, közös memória nélkül futnak.

Jogosultságok és autonómia

A jogosultság maga az egész biztonsági történet, és az alapérték a leglazább elérhető beállítás. Négy mód van, és minden munkamenet a sajátját választja.

• Autonóm: jóváhagyás nélkül szerkeszt fájlokat, használ kiterjesztéseket és töröl fájlokat. Ez az alapérték.
• Manuális jóváhagyás: minden eszköz előtt rákérdez, és tiszteletben tartja a granuláris eszközjogosultsági listát.
• Intelligens jóváhagyás: automatikusan átengedi, amit alacsony kockázatúnak ítél, a többit jelzi. A besorolást a modellszolgáltató végzi, tehát javaslat, nem kontroll.
• Csak chat: tiltja a kiterjesztéseket és a fájlmódosítást, elemzéshez, íráshoz és következtetéshez.

Hol csikizik

A hézagok gyakorlatiak, nem architekturálisak. A legtöbb külső kiterjesztés npx-en vagy uvx-en keresztül indul, így az agent hallgatólagosan a Node.js-re vagy egy Python eszközláncra támaszkodik. Olyan fejlesztői szervereket indít, amelyeket senki nem kért, és amelyek sosem lépnek ki, így a munkamenet a tool timeoutjáig függ. A kiterjesztések a futásidőjüket egy mellékelt Hermit másolaton keresztül töltik le, ami elszigetelt hálózaton meghiúsul, ha a shim-eket nem nevezed át. A Windows telepítés fix útvonalon várja a Node.js-t, és a dokumentált orvosság egy szimbolikus link. Az ismert problémák oldala pedig azt javasolja, hogy szüntsd meg a munkamenetet és kezdj újat, ha az agent nem reagál, ami őszinte, de nem megoldás.

Az ügylet a kereskedelmi eszközökkel egyértelmű. A Claude Code jobb napi társ: gyorsabban indul, a modellminőség az, ami miatt maradnak nála, és a jogosultsági modellje a szolgáltatótól jön, nem a modelltől van kikövetkeztetve. Az OpenHands pontosan ott nyer, ahol a goose leggyengébb: sandboxban futtatja az agentmunkát, ahol az eredmény megvizsgálható, egy nehezebb futásidő áráért. A goose azt a két dolgot nyeri, ami egy platformcsapatnak számít: egy licencet, amely engedi a forkolást, és egy deklaratív formátumot receptenkénti engedélylistával, amely egy egész flottán végrehajtható.

A második strukturális hézag a biztonsági mélység. Van promptinjekció-felismerés állítható küszöbbel és egy adversary mód, amely külön felülvizsgáló agentet futtat az eszközhívások fölött, ami érdekes ötlet és önmagában nem kontroll. Az olvasó eszközök alapértelmezés szerint jóváhagyás nélkül futnak, a kiterjesztések pedig a fejlesztő jogosultságaival és hitelesítő adataival.

Vélemény

A goose hihető alapérték annak a csapatnak, amely saját agent stacket akar birtokolni, és rossz helyettesítő egy jól beállított kereskedelmi agenthez egyetlen gépen. A valódi hozzájárulása nem a kódoló hurok, ami áru, hanem az alapítványi licenc, a deklaratív kiterjesztés engedélylista és a géppel ellenőrizhető sikerfeltételekkel bíró receptformátum együttese. Ez az a réteg, amelyet a szervezetek újra és újra rosszul építenek valaki más agentjére.

1. Vedd fel, ha az agentek olyan gépeken kell fussanak, amelyeket nem te felügyelsz, vagy ahol a kód nem hagyhatja el a hálózatot. A bináris és a dokumentáció is csomagolható elszigetelt működésre.
2. Vedd fel az agentek viselkedésének flottaszintű szabványosítására. A receptenkénti kiterjesztés engedélylista és a jogosultsági mód a mechanizmus, a receptfájl pedig a verziózott artefaktum.
3. Vedd fel második véleményként. Ugyanazt a feladatot két agenttel, eltérő eszközökkel futtatni és a diffeket összevetni olcsó, ha mindkettő ingyen fut.
4. Ne vedd fel egy fejlesztő első agentjének. A telepítés egy szkript, az első munkamenethez szolgáltatókulcs kell, így a beállítás annak a terhére esik, akinek a legkevesebb ideje van rá.
5. Ne válts át egy működő kereskedelmi agentet erre. Az egyedi feladatin minőségben a vezetők még mindig előrébb járnak, és a körülöttük lévő ökoszisztéma is mélyebb.

Források

1. goose dokumentáció: gyorsindítás
2. goose dokumentáció: konfigurációs fájlok
3. goose dokumentáció: jogosultsági módok
4. goose dokumentáció: intelligens kontextuskezelés
5. goose dokumentáció: recept referencia
6. goose dokumentáció: CLI parancsok
7. goose dokumentáció: ismert problémák
8. A goose új otthont kapott: az Agentic AI Foundation (2026. április 7.)
9. A goose repository a GitHubon