# /goal a Claude Code-ban: autonóm mód és Agent View 2026-ban
> A Claude Code 2.1.139 /goal parancsa elindítja az autonóm módot: az ügynök addig dolgozik, amíg el nem éri a célt. Bemutatom az Agent View-t, a worktree-ket és 5 példát.
Source: https://ailoot.ai/blog/hu/claude-code-goal-agent-view/
Canonical: https://ailoot.ai/blog/hu/claude-code-goal-agent-view/
Language: hu
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-102
Revision: sha256-5c07d56bc7ebe5f92080f246d0bde7846a9f0e8091c25329b9330cdfa94e414c
Ailoot referencia-dokumentáció: [ailoot.ai/docs/](https://ailoot.ai/docs/).
## Mi az a /goal a Claude Code-ban?
Főbb tanulságok
A `/goal` a Claude Code 2.1.139+ parancsa (2026. május 11-én jelent meg), amellyel elindítható az autonóm mód: megad egy teljesülési feltételt, Claude pedig kódot ír, teszteket futtat, és újabb fordulóval folytatja, amíg el nem éri a célt. Minden forduló után egy kis méretű modell (alapértelmezés szerint Haiku) elolvassa az átiratot, majd „igen/nem” választ ad arra, hogy teljesült-e a feltétel. Normál munkamenetben és headless módban, a `claude -p` paranccsal is aktiválható.
Korábban a Claude Code minden válasz után leállt, és megvárta a következő promptot. Ez rövid feladatoknál működött, hosszabbaknál viszont már nem: egy API-migráció, 12 sikertelen teszt kijavítása vagy egy 800 soros fájl refaktorálása 20–30 iterációt igényelhet, és mindegyik visszahozta Önt a terminálhoz.
A `/goal` egyszerű ötlettel oldja meg ezt a problémát: válassza szét „azt, aki elvégzi a munkát” attól, „aki eldönti, mikor készült el”. A fő ügynök kódot ír. Egy külön értékelő (a gyors Haiku modell) minden forduló után elolvassa a beszélgetést, és egy kérdésre válaszol: „Teljesült a feltétel?” Ha nem, az ügynök megkezdi a következő fordulót. Ha igen, visszakapja az irányítást.
Az Anthropic hivatalos dokumentációja így határozza meg:
A /goal parancs teljesülési feltételt állít be, Claude pedig úgy dolgozik annak elérésén, hogy közben nem vár minden lépésnél újabb promptra. Minden forduló után egy kisméretű, gyors modell ellenőrzi, hogy teljesült-e a feltétel. Ha nem, Claude új fordulót kezd, ahelyett hogy visszaadná Önnek az irányítást. A cél automatikusan törlődik, amint teljesül a feltétel.
— Anthropic Docs, https://code.claude.com/docs/en/goal
Éjszaka több ezer ügynök futtatása telefonról—ez nem marketing, hanem egy Anthropic-mérnök jelenlegi gyakorlata. Ezt a `/goal` és az Agent View kombinációja teszi lehetővé, amelyet ugyanezen a napon, 2026. május 11-én mutattak be.
## Miért van szükség autonóm módra: mi volt előtte és utána, 2026. május 11-én?
Főbb tanulságok
2026. május 11. előtt a Claude Code-nak nem volt beépített autonóm módja. A fejlesztők saját bash-szkripteket írtak cron időzítőkkel, ami pénzügyi katasztrófákhoz vezetett—egy fejlesztő május 22-én egyetlen éjszaka alatt $6,000-t költött, mert a cache TTL-je figyelmeztetés nélkül egy óráról 5 percre változott. A `/goal` magába az eszközbe építette az autonómiát: felügyelői architektúrával, a feltételben megadható fordulólimittel és az ismétlődő munkameneteket leállító értékelőmodellel.
Az „AI éjszakára munkába állítása” gondolata már 2025 őszétől létezett, amikor a Cursor Composer és a Cline auto mode már képes volt a háttérben futni. 2026. május 11. előtt azonban ehhez a Claude Code-ban kézi köztes megoldásra volt szükség: egy cron feladatra, amely N percenként meghívta a `claude -p` parancsot, vagy egy olyan wrapperre, amely figyelte a git állapotát, és elindította a következő promptot.
Ez a barkácsmegközelítés rendszeresen katasztrófákhoz vezetett. 2026. május 22-én egy fejlesztő egy ilyen szkriptet egész éjszakára futni hagyott, majd reggel $6,000-os számlára ébredt. A kiváltó ok az volt, hogy az Anthropic bejelentés nélkül, csendben egy óráról öt percre változtatta a Claude Code cache TTL-jét. A cron 30 percenként hívta meg a szolgáltatást—ezalatt a cache lejárt a futások között. Minden futás nulláról épített fel egy 800,000 tokenes előzményt. Az új adatok cache-be írása jóval többe kerül, mint az aktív cache olvasása.
A fejlesztő nem csinált semmi szokatlant—pontosan úgy használta az eszközt, ahogyan azt az Anthropic bemutatta.
A `/goal` beépített architektúrával oldja meg ezt a problémát:
1. **Felügyelőfolyamat**, amely a terminálon kívül tartja a munkamenetet, és akkor is működik, ha bezárja az ablakot vagy a laptop alvó állapotba kerül.
2. **Haiku értékelő**—egy olcsó modell ellenőrzi az egyes fordulókat; az értékelő tokenjei csak fillérekbe kerülnek.
3. **Szigorú fordulólimit a feltételben**—kifejezetten megadhatja például, hogy `or stop after 20 turns`, így a munkamenet garantáltan leáll.
4. **Worktree-izoláció** a háttérmunkamenetekhez—a változtatások külön ágra kerülnek, és nem érintik a munkapéldányát.
A különbség a „írj saját bash-szkriptet” megközelítéshez képest az, hogy az Anthropic mindezeket a mechanizmusokat az eszköz elsőrangú részeivé tette, nem pedig harmadik féltől származó hackekké.
## A /goal bekapcsolása 3 lépésben
Főbb tanulságok
A legegyszerűbb folyamat: 1) frissítse a Claude Code-ot 2.1.139+ verzióra a `claude update` vagy az `npm i -g @anthropic-ai/claude-code` paranccsal, 2) írja be a `/goal` parancsot és a feltételt közvetlenül a munkamenetbe, 3) kövesse az előrehaladást az élő fedvényen (eltelt idő, fordulók száma, tokenek). A parancs interaktív munkamenetben és headless módban, a `claude -p` paranccsal is működik. A leállításhoz nyomja meg a `Ctrl+C` billentyűkombinációt; a cél megszakításához használja a `/goal clear` parancsot.
**1. lépés. Frissítse a Claude Code-ot 2.1.139-es vagy újabb verzióra.**
Ellenőrizze a verziót:
```bash
claude --version
```
Ha 2.1.139-nél korábbi, frissítse:
```bash
claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest
```
A 2026. május 12. és 19. közötti kiadások fontos hibákat javítottak az első verzióban. A 2.1.140-ben kijavították azt a csendes lefagyást, amelynél a `disableAllHooks` blokkolta az értékelőt. A 2.1.143-ban érkezett a `worktree.bgIsolation: "none"` és a stop hook ciklusok javítása. A 2.1.144-es verzióban (május 19.) hozzáadták a háttérmunkamenetekhez a `--resume`, a szkriptezéshez pedig az agents `--json` lehetőséget. A minimális verzió a 2.1.143.
**2. lépés. Írja be a `/goal` parancsot egy feltétellel.**
Nyisson meg egy normál Claude Code-munkamenetet, és írja be a parancsot:
```
/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns
```
Utána nem kell külön promptot küldenie—a parancs azonnal elindítja az első fordulót. A feltételt oroszul, angolul vagy vegyesen is megadhatja; a modell mindkét nyelvet érti. A hosszkorlát legfeljebb 4,000 karakter.
**3. lépés. Kövesse az előrehaladást az élő fedvényen.**
A `/goal` elindítása után egy élő panel jelenik meg a terminál alján:
```
/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail
```
A panel a következőket mutatja:
- **Fordulók**—az eddig befejezett fordulók száma
- **Eltelt idő**—az indítás óta eltelt idő
- **Tokenek**—az összes felhasznált token (ez a legfontosabb adat a keret figyeléséhez)
- **Legutóbbi**—az értékelő legutóbbi indoka arra, hogy miért mondta: „még nem”
Hasznos trükk: ha az értékelő három fordulón keresztül egymás után ugyanazt az indokot adja, az a ciklus jele. Nyomja meg a `Ctrl+C` billentyűkombinációt, vagy írja be a `/goal clear` parancsot (szinonimák: `stop`, `off`, `reset`, `cancel`), fogalmazza át a feltételt, majd indítsa újra. A közösségi `/goal` útmutatók ezt említik a ciklus fő jelzéseként: „háromszor ugyanaz az indok—ez ciklus, lépj ki.”
## Hogyan írjon jó feltételt: 5 szabály + 5 példa
Főbb tanulságok
A feltétel egy ellenőrizhető kilépési feltétel, nem prompt. A jó feltételnek három eleme van: mérhető végállapot (a tesztek sikeresek, a build zöld), ellenőrzési módszer (`npm test exits 0`), valamint a megszegni tilos korlátozások („ne módosítson fájlokat a /auth könyvtáron kívül”). A rossz feltételek homályosak („legyen szép”), nem ellenőrizhetők („optimalizálja a UX-et”), vagy nincs fordulólimitjük. Egy fejlesztő 14 óra alatt $200-t égetett el egy homályos feltétellel.
Az Anthropic dokumentációja a jó feltétel három szükséges elemét írja le:
Az a feltétel, amely sok fordulón át is egyértelmű marad, általában a következőket tartalmazza: egy mérhető végállapotot—például teszteredményt, build kilépési kódját, fájlszámot vagy üres sort; egyértelmű ellenőrzési módszert—hogyan bizonyítsa be Claude, például `npm test exits 0` vagy tiszta `git status` segítségével; és fontos korlátozásokat—mi nem változhat a folyamat során, például `no other test file is modified`.
— Anthropic Docs, https://code.claude.com/docs/en/goal
Egy kész sablon mindhárom elemet egy sorban tartalmazza:
```/goal [végezze el a munkát] addig, amíg [mérhető végállapot] nem teljesül, [betartandó korlátozások] nélkül```
**Öt szabály, amelyen a legtöbben elcsúsznak:**
**1. szabály. A végállapotot paranccsal lehessen ellenőrizni, ne ízlés alapján.**
Ne azt írja, hogy „legyen szép”, hanem azt, hogy `npm test exits 0`. Ne azt, hogy „javítsa a UX-et”, hanem azt, hogy `Lighthouse Performance score above 90`. Az értékelő csak az átiratot olvassa—nem futtat parancsokat és nem néz képernyőképeket. Ha az eredményt nem lehet szövegben rögzíteni, az értékelő soha nem mond igent.
**2. szabály. A korlátozások legyenek egyértelműek és szűk körűek.**
Korlátozások nélkül Claude úgy is kijavíthatja a teszteket, hogy törli magukat a teszteket, vagy megjegyzésbe teszi a sikertelen állításokat. Adjon meg ilyeneket: `without modifying any file outside /auth`, `without removing existing assertions`, `without bumping major versions of dependencies`.
**3. szabály. Kötelező a szigorú fordulólimit.**
Minden feltételhez adja hozzá a `or stop after N turns` részt. Ez mentőöv a végtelen ciklus ellen. Limit nélkül egy órán át futó ciklus több tokent éget el, mint ugyanazt a feladatot kézzel elvégezni. Számoljon ezzel a keretben.
**4. szabály. A MIT-et írja le, ne csak a HOGYAN-t.**
Ha nem említi a látványt a feltételben, Claude nem fogja elkészíteni. Ha a feltétel csak annyit kíván, hogy „a tesztek sikeresek legyenek”, Claude akár összetett teszteket is megjegyzésbe tehet. Azt írja le, MIT szeretne, ne csak azt, HOGYAN fogja ellenőrizni.
**5. szabály. Kérje meg Claude-ot, hogy mutasson bizonyítékot a chatben.**
Az értékelő nem futtat parancsokat—csak azt olvassa, amit Claude már megmutatott. Ha a feltétel szerint „a `npm test` sikeres”, de Claude nem jelenítette meg a `npm test` kimenetét az átiratban, az értékelő örökké azt fogja mondani, hogy „még nem”. Tegye a feltételhez ezt a kérést: „mutassa meg a `` kimenetét a beszélgetésben”.
**Öt működő példa gyakori feladatokra:**
```
1. API-migráció:
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns
2. Tesztek javítása:
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns
3. Kódminőség (fájlméret):
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns
4. A backlog feldolgozása:
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed
5. Biztonsági audit:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns
```
Szeretne többet tenni a `/goal` futtatásánál, és olyan környezetet kialakítani, amelyben az autonóm mód valóban működik a projektjében? A `/goal` csak az utolsó láncszem. Előtte három pillért kell a helyére tenni: egy AI-klónt (az Ön módszertanát tartalmazó Skills és Subagents), egy [második agyat](https://ailoot.ai/blog/hu/claude-code-second-brain/) (`CLAUDE.md` és egy `plans/` mappa), valamint kontextusmérnökséget (Plan Mode és /compact). Mindhárom összetevőt együtt kell átgondolni—ez a kombináció támogatja a kontextussal végzett munkát.
## 5 példa, amikor a /goal valóban beválik
Főbb tanulságok
A `/goal` jól működik ellenőrizhető végállapotú feladatoknál: API-migráció, sikertelen tesztek javítása, nagy fájlok felbontása, a hibajegy-backlog lezárása és biztonsági audit. Szubjektív feladatoknál, például tervezésnél, UX-csiszolásnál, meglátások keresésénél és kreatív munkánál kevésbé működik jól. Egyszerű ökölszabály: le tudja írni a „kész” állapotot egy `bash` paranccsal? Ha igen, alkalmas rá. Ha nem, térjen vissza a normál munkamenethez vagy a Plan Mode-hoz.
Az Anthropic dokumentációja négy olyan feladattípust sorol fel, amelyekre a `/goal` jól használható:
Használja a goal parancsot jelentős, ellenőrizhető végállapotú munkákhoz: migráljon egy modult új API-ra, amíg minden hívás le nem fordul és a tesztek le nem futnak; valósítson meg egy tervdokumentumot az összes elfogadási feltétel teljesüléséig; bontson fel egy nagy fájlt kisebb, célzott modulokra, amíg mindegyik bele nem fér a méretkorlátba; dolgozza fel a címkézett hibajegyeket, amíg a sor ki nem ürül.
— Anthropic Docs, https://code.claude.com/docs/en/goal
Íme öt kész feltételű példa—vegye át és igazítsa őket a projektjéhez.
**1. példa. Egy modul migrálása új API-ra.**
Helyzet: REST-ről GraphQL-re tér át, vagy a régi `getUser()` függvényt az új `fetchUser()` függvénnyel váltja fel. A feladat mechanikus, de 30–50 fájlt érint.
Feltétel:
```
/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns
```
Miért működik: a végállapot ellenőrizhető a `grep -r getUser src/ | wc -l` paranccsal (az eredménynek 0-nak kell lennie) és a `npm test exits 0` paranccsal. A korlátozás védi a tesztfájlokat.
**2. példa. Sikertelen tesztek javítása.**
Helyzet: egy könyvtár frissítése után 15 teszt elromlott. Tudja, hogy a javítás mechanikus—frissíteni kell a mockokat, és az új formátumhoz igazítani az állításokat. Nem szeretné ezt kézzel elvégezni.
Feltétel:
```
/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns
```
Egy másik példa ugyanerre a feltételre:
```Javítson ki minden sikertelen tesztet, amíg az npm test eredménye 0 nem lesz, és közben ne módosítson semmilyen fájlt az /auth könyvtáron kívül```
**3. példa. Egy mindentudó osztály felbontása.**
Helyzet: egy 1,200 soros fájlban minden benne van—a modell, a szolgáltatás, a segédprogramok és az API-kliens. Az „egy fájl, egy felelősség” elve szerint szeretné felbontani, frissíteni az összes importot, és sikeresen lefuttatni a teszteket.
Feltétel:
```
/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns
```
**4. példa. A hibajegy-backlog lezárása éjszaka.**
Helyzet: van egy nyílt forráskódú tárháza 20 `good-first-issue` címkéjű hibajeggyel. Szeretné, ha Claude éjszaka végigdolgozná őket.
Feltétel:
```
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns
```
A 6-os szám nem véletlen—reális felső határ egyetlen éjszakára Pro előfizetéssel.
**5. példa. Biztonsági audit.**
Helyzet: a `npm audit` 8 magas súlyosságú sebezhetőséget jelez. Szeretné, ha Claude kijavítaná őket a major verziók frissítése nélkül.
Feltétel:
```
/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns
```
**Mit NE tegyen a /goal segítségével:**
| Feladattípus | Miért nem működik |
|----|----|
| „Készítsen gyönyörű UI-t” | Az értékelő csak a szöveget látja, a dizájnt nem |
| „Találjon meglátást az adatokban” | Nincs ellenőrizhető végállapot |
| „Optimalizálja az oldal UX-ét” | Szubjektív ízlés; az ügynök azt optimalizálja, amit mérnek |
| Kutatás / feltárás | Nyitott végű—az értékelő nem tudja, mikor „elég” |
| Éles környezetbe telepítés | A külső mellékhatásokat nem lehet visszavonni |
| Tartalom / marketing készítése | A szöveg minősége nem ellenőrizhető paranccsal |
Croucher határozottan fogalmazza meg az ökölszabályt a gyakorlati útmutatójában: ne használja a `/goal` parancsot olyan feladatokhoz, amelyeknél a „kész” azt jelenti, hogy „jól néz ki”, „jó érzést kelt”, „jól megtervezett” vagy „szórakoztató”. Az értékelő csak az átiratot olvassa—nem futtat eszközöket, és nem tudja megítélni, hogyan működik az eredmény. Ez a szabály kizárja a szubjektív feladatok 80%-át, amelyekben a `/goal` hasznos kimenet nélkül ismételgeti a köröket.
## Amikor a /goal feleslegesen viszi a pénzt: 3 rossz minta
Főbb tanulságok
A `/goal` három gyakori rossz mintája: homályos feltétel fordulólimit nélkül (egy fejlesztő 14 óra alatt $200-t égetett el), rekurzív ciklus elavult cache-sel ($6,000 egy éjszaka alatt a cache TTL változása miatt), valamint kreatív feladat ellenőrizhető végállapot nélkül (grafika nélkül elkészült játék, amelyre az értékelő azt mondja, „kész”, pedig hiányzik a látvány). A védekezés: mindig adjon meg `or stop after N turns` korlátot, határozzon meg mérhető eredményt, és először ellenőrizze, hogy a feladat alkalmas-e autonóm munkára.
**1. rossz minta. Homályos feltétel szigorú fordulólimit nélkül.**
A leggyakoribb hiba az olyan feltétel, mint „javítsa a kódot” / „legyen jó” / „optimalizálja”. Fordulólimit nélkül az ügynök addig fut, amíg el nem fogy a kerete.
A Findskill egy valós esetről számolt be:
Egy fejlesztő arról számolt be, hogy homályos feltételekkel $200-t égetett el egy 14 órás munkamenet során: egy gyenge feltétel, amely miatt az értékelő folyton azt mondja, hogy „még nem”, 50, 100 vagy akár 500 fordulón át is futhat, mielőtt észrevenné.
A homályos feltétel miatt 14 óra alatt elköltött $200 a Max csomag teljes heti kerete. Reggel úgy ébredhet, hogy elfogyott a kerete, és nincs használható eredmény.
Védekezés: minden feltételt zárjon a `or stop after N turns` résszel (15 könnyű feladatokhoz, 50 nehéz feladatokhoz, és éjszakai futtatásnál legfeljebb 100).
**2. rossz minta. Rekurzív ciklus hibás cache-eléssel.**
A 2026. május 22-i történet: $6,000 egy éjszaka alatt, mert az Anthropic csendben egy óráról 5 percre változtatta a cache TTL-jét. A fejlesztő nem közvetlenül a `/goal` parancsot használta, de ugyanaz volt a logika: egy 30 perces cron időzítővel futó autonóm ciklus minden alkalommal nulláról épített fel egy 800,000 tokenes előzményt.
A probléma gyökere az volt, hogy a külső automatizálás nem tudott a szolgáltató belső változásairól. Ugyanez a `/goal` esetén is megtörténhet, ha 8 órán át felügyelet nélkül futtatja: a tokenhasználat nemlineárisan növekszik, és a prompt cache nem úgy működik, ahogy gondolja.
Védekezés:
1. **Ne futtassa a `/goal` parancsot 8+ órán át köztes ellenőrzések nélkül.**
2. **Kapcsolja be a használati korlátokat a Settings → Usage menüben** (új óvintézkedés a $6,000-os incidens után).
3. **Nyissa meg kétszer az éjszaka folyamán a `claude agents` parancsot**—pillantson rá a `Space` billentyűvel, és ellenőrizze, hogy a fordulók száma nem nő-e a vártnál gyorsabban.
4. **Drága modell-láncok (Opus 4.7) esetén** állítson be szigorúbb fordulólimitet—legfeljebb 30-at.
**3. rossz minta. Kreativitás a `/goal` segítségével.**
Croucher a `/goal` paranccsal készített játékot—a feltétel tartalmazta a determinisztikusságot, az invariánsokat és annak ellenőrzését, hogy végigjátszható-e a pálya. A játék elkészült, a tesztek sikeresek voltak, az értékelő pedig azt mondta: „elérve”. A játéknak nem volt látványa—a feltétel nem említette a grafikát.
Ez az általános szabályt mutatja: az értékelő pontosan azt optimalizálja, amit mér. Ha a feltétel nem említi a látványt, nem lesz látvány. Ha csak a teszteket említi, az értékelő akár megjegyzésbe is teheti az állításokat.
Védekezés: ne használja a `/goal` parancsot olyan feladatokra, amelyek ízlésen múlnak (dizájn, szöveg, UX). Térjen vissza a normál munkamenethez vagy a [Plan Mode-hoz](https://ailoot.ai/blog/hu/claude-code-plan-mode/)—ezekben Ön is részt vesz a döntésekben.
## Mi az az Agent View, és hogyan nyissa meg az irányítópultot?
Főbb tanulságok
Az Agent View vizuális irányítópult a háttérben futó Claude Code-munkamenetek kezeléséhez. A terminálban a `claude agents` paranccsal nyitható meg. Minden háttérmunkamenet külön sorban jelenik meg, állapotával együtt (Working, Needs input, Idle, Completed, Failed, Stopped). Akkor hasznos, ha egyszerre 2–5 autonóm feladatot futtat—terminálok közötti váltogatás helyett mindent egy képernyőn láthat. Tartalmaz peek (Space—gyors betekintés csatlakozás nélkül), attach (Enter), detach (balra nyíl) és pin (Ctrl+T) funkciókat.
Ha a `/goal` a „dolgozz, amíg el nem készülsz” parancs, akkor az Agent View az irányítóterem, ahol egyszerre láthatja az összes ilyen munkamenetet. Az Anthropic így írja le:
Az Agent View a claude agents paranccsal nyílik meg—ez egyetlen képernyőn mutatja az összes háttérmunkamenetét: mi dolgozik, mi vár az Ön közreműködésére, és mi készült el. Indítson új munkameneteket, ellenőrizze az állapotukat egy pillantással, az átiratok görgetése nélkül, és csak akkor csatlakozzon, amikor egy munkamenetnek szüksége van Önre.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
**Megnyitó parancs:**
```bash
claude agents
```
Megnyílik egy TUI—szöveges irányítópult a terminálon belül. A munkamenetek listája bal oldalon található, a kiválasztott sor legutóbbi üzenetét mutató peek panel pedig jobb oldalon.
**A munkamenetek hat állapota:**
| Állapot | Jelentés |
|----|----|
| **Working** | Claude aktívan dolgozik—eszközhívásokat végez vagy választ generál |
| **Needs input** | Claude egy konkrét kérdésére adott választ vagy engedélyét várja |
| **Idle** | A munkamenet inaktív, és készen áll a következő promptra |
| **Completed** | A feladat sikeresen befejeződött |
| **Failed** | A munkamenet hibával zárult |
| **Stopped** | A munkamenetet a Ctrl+X vagy a `claude stop` állította le |
**Fő billentyűparancsok:**
```
↑ / ↓ lépkedés a munkamenetek listájában
Space peek panel (megtekintés csatlakozás nélkül)
Enter / → csatlakozás egy munkamenethez (belépés)
← leválás (kilépés a leállítása nélkül)
Ctrl+T rögzítés (védelem az automatikus leállítás ellen)
Ctrl+X munkamenet leállítása; törléshez nyomja meg újra 2 sec-en belül
Ctrl+R átnevezés
Ctrl+S csoportosítás váltása (állapot ↔ könyvtár)
```
**Háttérmunkamenet indítása:**
Interaktív Claude Code-ból:
```
/bg fix the failing test test/auth/login.test.ts
```
Vagy közvetlenül a shellből:
```bash
claude --bg "fix the failing test test/auth/login.test.ts"
```
Vagy névvel (hogy felismerhető címkével jelenjen meg az Agent View-ban):
```bash
claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"
```
A háttérmunkamenet automatikusan megjelenik az Agent View-ban—indítsa el `--bg` kapcsolóval, nyissa meg a `claude agents` parancsot, és látni fogja a listában.
**A fő funkció: a munkamenetek túlélik a laptop alvó állapotba kerülését és az ablak bezárását:**
A munkamenet állapota lemezre kerül, és túléli az automatikus frissítéseket, valamint a felügyelő újraindításait. A munkamenetek akkor is mentésre kerülnek, amikor a gép alvó állapotba kerül. Ébredéskor a folyamataik folytatódnak, a felügyelő pedig újra csatlakozik hozzájuk, ahelyett hogy az alvást tétlenségnek tekintené.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
Ha azonban leállítja a laptopot vagy kézzel újraindítja, a háttérmunkamenetek Failed állapottal véget érnek. Az éjszakai futtatások sok háttérügynökkel csak olyan laptopon működnek, amelyet nem kapcsolnak ki.
## Worktree-k: hogyan különíti el Claude a párhuzamos munkameneteket?
Főbb tanulságok
A worktree a tárház külön másolata a `.claude/worktrees//` könyvtárban, egy külön `worktree-` ágon. Ha a `/bg` parancson vagy az Agent View-on keresztül háttérmunkamenetet indít, Claude a fájlok szerkesztése előtt automatikusan worktree-be helyezi. A párhuzamos munkamenetek ugyanazt a checkoutot olvashatják, de mindegyik a saját példányába ír, így nem írják felül egymás munkáját. Az izoláció kikapcsolható a `.claude/settings.json` fájlban a `worktree.bgIsolation: "none"` beállítással (2.1.143 óta elérhető funkció).
A worktree-k a párhuzamos autonóm munka fő problémáját oldják meg: mi történik, ha két munkamenet egyszerre próbálja szerkeszteni a `src/auth.ts` fájlt? A 2.1.139 előtt az ilyen munkamenetek szó szerint felülírhatták egymás módosításait. Az Agent View-val az Anthropic automatikus izolációt vezetett be:
Az Agent View-ból, a /bg segítségével vagy a claude --bg paranccsal indított háttérmunkamenetek a munkakönyvtárban indulnak. A fájlok szerkesztése előtt Claude egy elszigetelt git worktree-be helyezi át a munkamenetet a .claude/worktrees/ könyvtárban, így a párhuzamos munkamenetek ugyanazt a checkoutot olvassák, de mindegyik a saját példányába ír.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
**Így működik a gyakorlatban:**
```bash
# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"
# File structure after launch:
.claude/worktrees/
├── fix-tests/ # separate repo copy on branch worktree-fix-tests
├── add-oauth/ # separate copy on branch worktree-add-oauth
└── split-userservice/ # separate copy on branch worktree-split-userservice
```
Minden munkamenet a saját példányában dolgozik. A feladat befejezésével egyesítse a szükséges ágakat a main ágba.
**Veszélyes csapda—egy munkamenet törlése a worktree törlését is jelenti.**
Az Anthropic által létrehozott worktree-k az Agent View-ban a munkamenettel együtt törlődnek: egy saját worktree-jében fájlokat módosító munkamenet törlése előtt egyesítse vagy pusholja a változtatásokat.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
Ha leállít egy munkamenetet az Agent View-ban (nyomja meg kétszer a `Ctrl+X` billentyűkombinációt), a worktree eltűnik. Minden nem commitolt változtatás elvész. Mielőtt munkamenetet töröl az Agent View-ban, mindig commitoljon vagy pusholjon.
**Az izoláció kikapcsolása (ritka esetekben):**
Ha olyan tárháza van, ahol a git worktree-k nem működnek (például szimbolikus hivatkozásokat használó beállítás vagy lassan checkoutoló nagy monorepo esetén), kikapcsolhatja az izolációt:
```json
// .claude/settings.json
{
"worktree": {
"bgIsolation": "none"
}
}
```
Ezután a háttérmunkamenetek közvetlenül a munkapéldányában szerkesztenek. Ez a kikapcsolási lehetőség a 2.1.143 verzióban érkezett, a nagy monorepókkal dolgozó csapatok panaszai után.
**A párhuzamosság fogyasztja a keretet:**
A sebességkorlátok itt is érvényesek: a háttérmunkamenetek ugyanúgy használják az előfizetés keretét, mint az interaktív munkamenetek, ezért 10 párhuzamos ügynök körülbelül 10-szer gyorsabban fogyasztja a keretet, mint egyetlen ügynök.
— Anthropic Docs, https://code.claude.com/docs/en/agent-view
Ez azt jelenti, hogy egy Pro csomag ($20/month) 1–2 párhuzamos éjszakai munkamenetre elég, tízre nem. Ha sok ügynököt szeretne párhuzamosan futtatni, Max vagy Enterprise csomagra van szüksége.
## A /goal, a Plan Mode és a subagents kombinálása hosszú feladatokhoz
Főbb tanulságok
A `/goal` önmagában a lánc utolsó eleme. Előtte használja a [Plan Mode-ot](https://ailoot.ai/blog/hu/claude-code-plan-mode/) a `plans/` mappában tárolt, szakaszokra bontott terv elkészítéséhez, a [subagents](https://ailoot.ai/blog/hu/claude-code-alugynokok/) segítségével pedig ossza szét a munkát. A kombináció így működik: 1) a Plan Mode ellenőrizhető jelölőnégyzetekkel ellátott részletes tervet ír, 2) a subagents párhuzamosan dolgozhatnak különböző szakaszokon, saját worktree-ágaikban, 3) a `/goal` addig futtatja a „munka → értékelő → következő forduló” ciklust, amíg minden négyzet be nincs jelölve. A Plan Mode nélkül a `/goal` használhatatlan összetett feladatokhoz.
Gyakori hiba, hogy valaki azonnal beírja: `/goal build a new feature`. Ez nem működik, mert az értékelő nem tudja, hogyan néz ki egy „kész funkció”. Olyan tervre van szükség, amelynek jelölőnégyzeteit az értékelő egyenként ellenőrizheti.
**1. réteg. A Plan Mode szakaszokra bontott tervet ír.**
A [Plan Mode-ban](https://ailoot.ai/blog/hu/claude-code-plan-mode/) kérje meg Claude-ot, hogy készítsen részletes változtatási tervet, 5–7 szakaszra osztva, ellenőrizhető jelölőnégyzetekkel. Mentse `plans/2026-05-24-google-oauth.md` néven. Minden szakaszban 3–7 konkrét műveletet tartalmazó jelölőnégyzet legyen.
**2. réteg. A subagents szakaszonként osztják fel a munkát.**
Ha a terv párhuzamosítható (például a szakaszok függetlenek—backend végpont + frontend űrlap + DB-migráció), minden szakaszhoz indíthat külön háttérmunkamenetet a `claude --bg --name ""` paranccsal. Minden munkamenet saját worktree-t kap.
**3. réteg. A `/goal` addig futtatja a ciklust, amíg a jelölőnégyzetek el nem készülnek.**
```
/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns
```
Minden forduló után az értékelő elolvassa a tervet, ellenőrzi, melyik négyzetek készültek el, és ha maradt még tennivaló, az ügynök folytatja.
**Ez a kombináció három összetevőre épül:**
- kontextusmérnökség: a megfelelő kontextus a `plans/` mappában—az értékelő ezt olvassa
- [második agy](https://ailoot.ai/blog/hu/claude-code-second-brain/): a `plans/` mappa őrzi meg a tervet a munkamenetek között
- AI-klón: a CLAUDE.md tartalmazza az ügynök által követendő szabályokat
CLAUDE.md nélkül a `/goal` az architektúrát megtörő megoldást javasolhat. A `plans/` könyvtárban lévő terv nélkül az értékelő nem tudja, mik a siker feltételei. Subagents nélkül nincsenek párhuzamos szakaszok; minden sorban történik.
## Hogyan hasonlítsa össze a /goal-t Codexszel, Cursorral és más ügynökmódokkal?
Főbb tanulságok
Az számít, hogyan folytatódik a feladat, hol fut, milyen jogosultsággal, és hogyan ellenőrzik a befejezést. Itt nincs forrással alátámasztott, azonos feltételű mérés általános tokenhatékonysági szorzóra vagy más eszköz koherenciavesztésének rögzített lépésszámára. Választás előtt a tényleges modellt, klienst, verziót, végrehajtási módot és feladatot hasonlítsa össze.
A `/goal` minden kör után külön befejezésellenőrzést ad. Más termékek más módokat kínálnak; helyi CLI, hosztolt felhőfeladat és felügyelt szerkesztőmunkamenet nem felcserélhető összevetési egység. Különösen ne írjon le minden Codex CLI-munkát felhőkonténerként, és ne feltételezzen egyetlen ellenőrzőmodellt vagy számlázási módot minden Codex-futáshoz.
Azonos tárolópillanatképet és feladatot használjon azonos elfogadási ellenőrzésekkel. Minden jelöltnél rögzítse:
| Szempont | Mit rögzítsen |
|----|----|
| Végrehajtás | Kliens/verzió és helyi vagy hosztolt futtatás |
| Modell | Pontos modell, effort és kontextuskorlát |
| Folytatás | Mi indít újabb kört és mi állítja le |
| Elkülönítés | Munkapéldány, jogosultságok, titkok és hálózat |
| Eredmény | Elfogadott ellenőrzések, hibák és emberi javítások |
| Felhasználás | Bemenet, cache-read/write, kimenet, idő és tényleges számlázási mód |
Rögzített tokenhasználati szorzóhoz e feltételek és ugyanahhoz a sikeres eredményhez mért mennyiségek kellenek. A benchmarkszázalékhoz verzió, modell, tesztkörnyezet és futásbeállítás kell; a fenti részletek nélküli Terminal-Bench-százalékok nem helyettesítik ezt. A cikk nem ad független eszközközi benchmarkot.
A kívánt munkafolyamat alapján válasszon: felügyelt szerkesztés, körülhatárolt háttérfeladat vagy többkörös munka kifejezett befejezési feltétellel. A telepített termék támogatott módját tesztelje az egész versenytárs autonómiájának kizárása helyett. A jogosultsági jóváhagyást tartsa külön a feladat folytatásától: egy eszközhívás automatikus engedélyezése önmagában nem igazolja a felhasználói cél teljesülését.
**`/goal` vs `/loop`:**
A `/loop` egy másik, ugyanebben a kiadásban megjelent parancs; időközönként (N percenként) indít feladatokat. A `/goal` feltételalapú (addig fut, amíg teljesül a feltétel). Cron jellegű feladatokhoz használja a `/loop` parancsot, konkrét célok eléréséhez pedig a `/goal` parancsot.
Az Anthropic dokumentációjából:
| Megközelítés | A következő forduló ekkor indul | Ekkor áll le |
|----|----|----|
| `/goal` | Az előző forduló befejeződött | A modell megerősíti a feltétel teljesülését |
| `/loop` | Eltelt az időintervallum | Ön leállítja, vagy Claude úgy dönt, hogy elkészült a munka |
| Stop hook | Az előző forduló befejeződött | A szkript vagy a prompt dönt |
## A /goal indítása előtti ellenőrzőlista: 7 pont
Főbb tanulságok
Minden `/goal` futtatás előtt ellenőrizzen 7 dolgot: a Claude Code verziója 2.1.139+, a feltétel ellenőrizhető végállapotot tartalmaz, van szigorú fordulólimit, a korlátozások egyértelműek, minden fontos módosítást commitolt, a használati limitek be vannak kapcsolva a Settings menüben, és az Agent View meg van nyitva a felügyelethez. Egyetlen kihagyott pont is több száz dollárjába és elveszett munkába kerülhet.
Ellenőrzőlista minden `/goal` futtatás előtt:
1. **Claude Code verziója 2.1.139+**—ellenőrizze a `claude --version` paranccsal, és frissítsen, ha régebbi. Az ajánlott minimum a 2.1.143 (2026. május 15.), amely javítja a stop hook ciklusokat.
2. **A feltétel ellenőrizhető végállapotot tartalmaz**—a „javítsa meg” helyett adja meg, hogy `npm test exits 0`. Ha nem tud egy `bash` parancsot kitalálni az eredmény ellenőrzésére, a `/goal` nem való ehhez a feladathoz.
3. **Van szigorú fordulólimit**—minden feltétel tartalmazza ezt: `or stop after N turns`. Könnyű feladatoknál használjon 15-öt, nehézeknél 50-et, éjszakai futtatásnál pedig legfeljebb 100-at.
4. **A korlátozások egyértelműek és szűk körűek**—`without modifying files outside /auth`, `without removing existing assertions`, `without bumping major versions`. Nélkülük Claude úgy is kijavíthatja a teszteket, hogy törli magukat a teszteket.
5. **Minden fontos módosítás commitolva vagy pusholva van**—ha nem worktree-ben dolgozik (például a `worktree.bgIsolation: "none"` beállítást használja), Claude a munkapéldányát szerkeszti. Bármilyen hiba miatt elveszhet a nem mentett munka.
6. **A használati limitek be vannak kapcsolva a Settings → Usage menüben**—ez az új óvintézkedés a $6,000-os incidens után. Állítson be napi, munkamenetenkénti és havi limitet.
7. **Az Agent View `claude agents` külön ablakban meg van nyitva**—hosszú feladatoknál óránként egyszer pillantson rá a Space billentyűvel. Ha a fordulók száma a vártnál gyorsabban nő, vagy az értékelő három fordulón keresztül ugyanazt az indokot ismétli, nyomja meg a `Ctrl+C` billentyűkombinációt, és fogalmazza át a feltételt.
Egy további pont—**soha ne futtassa a `/goal` parancsot `--dangerously-skip-permissions` kapcsolóval más vagy ismeretlen kódján**. Ez a kombináció letilt minden ellenőrzést, és lehetővé teszi az ügynöknek, hogy bármit megtegyen a projektben. Az elemzés szerzője csak olyan új worktree-ben használja, ahol nincs mit elveszíteni.
A `/goal` hatékony funkció, de nem varázslat. Pontosan annyira működik jól, amennyire jól fogalmazza meg a feltételt. Ha szavakkal úgy tudja leírni a „kész” állapotot, hogy azt egy parancs ellenőrizni tudja, a `/goal` elvégzi a többit. Ha nem, térjen vissza a normál munkamenethez vagy a Plan Mode-hoz.
Az Ailootot tovább böngészheti az [ailoot.ai](https://ailoot.ai/) oldalon.
## Kérdések és válaszok: /goal a Claude Code-ban: autonóm mód és Agent View 2026-ban
### Hogyan írjak az értékelő által ellenőrizhető befejezési feltételt?
Egy mérhető eredményt, azt igazoló parancsot vagy bizonyítékot és korlátokat adjon, például állítások megtartását vagy megadott fájlhatókört. Kifejezett leállási korlát is kell, az ügynök pedig mutassa meg a verifikáció kimenetét a beszélgetésben.
### Elég egy rögzített tokenhatékonysági szorzó az ügynök kiválasztásához?
Nem. Azonos feltételű mérés nem támasztja alá. Ugyanazt az elfogadott feladatot hasonlítsa össze, rögzítve modellt, kliensverziót, futtatási módot, gyorsítótár- és tokenhasználatot, időt és emberi javításokat.
## Ailoot · A vállalat és projektportfóliója
Az Ailoot felhalmozott működési tapasztalatra, széles ügyfélkörre, stabil szolgáltatásra és folyamatos KPI-ellenőrzésre épít.
A vállalat és projektportfóliója: ügyfelek milliói; havi értékesítés milliárdos nagyságrendben.
Az Ailoot ezt a működési tapasztalatot használja az ügyfelek termékeiben, ágenseiben, alkalmazásaiban és automatizálásaiban elérhető AI-funkciók API-hozzáféréséhez.