Claude Code-alügynökök: felépítés, öt szerepkör és vezénylés

Mi az alügynök a Claude Code-ban, és miért nem „csak egy újabb Skill”?#

A Claude Code dokumentációja így határozza meg:

Vállalkozók számára érthető megfogalmazásban: képzelj el egy ingatlanirodát. Van egy igazgató, egy marketinges, egy ügyvéd és néhány értékesítési vezető. Ha egyetlen alkalmazott váltogat ezek között a szerepek között, az nem csapat, hanem egy túlterhelt ember. Akkor alakul ki csapat, ha mindenkinek saját kontextusa és felelősségi köre van, az igazgató pedig csak kiosztja a feladatokat és összefogja az eredményeket.

A Claude Code alügynökei ugyanígy működnek. A fő beszélgetés az igazgató. Az alügynök olyan szakértő, akinek szűk körű feladata, saját kontextusa és eszközkészlete van. Ha egy feladat megfelel a szakértő leírásának, az igazgató delegálja neki – anélkül, hogy belemerülne a részletekbe.

5 cél, amelyre az Anthropic az alügynököket tervezte

Az Anthropic dokumentációja pontosan öt okot sorol fel arra, hogy saját alügynököt hozz létre:

A listából a nem programozók számára a költségszabályozás a leggyakorlatiasabb szempont. Egy összetett kutatási feladatot elküldhetsz az olcsó Haiku modellnek, miközben a fő beszélgetést Sonnettel vagy Opusszal folytatod. A tokenmegtakarítás egyenesen arányos.

Ellenőrizd a telepített verzió beágyazási támogatását

Az útmutató sablonjaiban egy fő munkamenet közvetlenül delegál a dolgozóknak. A régebbi dokumentáció „az alügynökök nem indíthatnak másik alügynököt” mondatát ne kezeld időtlen szabályként: a beágyazás a telepített verziótól és engedélyezett eszközöktől függ. A külön beágyazottalügynök-útmutató verzióhoz kötött receptet tárgyal. Mélyebb delegálás tervezése előtt a saját telepítéseden igazold a támogatást.

Miben különbözik az alügynök a Skillektől, a Slash Commandoktól és a Hookoktól?#

A Skillsről szóló korábbi útmutató elmagyarázza, hogy a Claude Code-ban a skillek és a slash commandok lényegében egyetlen formátumba olvadtak össze. Az alügynök azonban másfajta entitás – nem egyszerűen „egy nagyobb skill”.

A négy mechanizmus összefoglaló táblázata:

Egy angol nyelvű útmutatóban jól hangzik így: a Skillek receptek; az alügynökök specializált kollégák.

Egyszerűen: a skillek olyanok, mint a receptek; az alügynökök pedig olyanok, mint a specializált kollégák.

A gyakorlatban így működik: a Skillek automatikusan aktiválódnak, ha a leírásuk illik a feladatra, az alügynököket viszont kifejezetten hívják meg – vagy a fő beszélgetés dönt úgy, hogy delegál, vagy te hívod meg az alügynököt név szerint.

Döntési fa: „Melyiket válasszam?”

Ha arra gondolsz, hogy „Szeretném, ha Claude megcsinálná X-et”, válaszolj erre a négy kérdésre:

1. Olyan tudásról van szó, amelynek mindig elérhetőnek kell lennie? Például: „a felhasználó által választott nyelvre lokalizálunk” vagy „nem használunk em dash jeleket”. Tedd a CLAUDE.md fájlba.
2. Olyan aktiválható módszertanról van szó, amelyet most manuálisan végzel? Például: „Minden hétfőn értékesítési jelentést írok.” Készíts belőle Skillt.
3. Olyan feladatról van szó, amely elhasználja a fő beszélgetés kontextusát, vagy párhuzamosan is futtatható? Például: „alapos kutatás 30 forrás alapján” vagy „biztonsági audit, miközben egy új funkciót írok”. Készíts belőle alügynököt.
4. Automatikus választ szeretnél egy Claude Code-eseményre? Például: „minden Edit után futtasd a lintert”. Írj egy Hookot.

A vállalkozók feladatainak 90%-a az első két kategóriába esik. Az alügynökök haladó szintű eszközök: akkor jönnek jól, amikor az „egyszerre egy feladat” módról áttérsz a vezénylésre.

Hol találhatók az alügynökök, és melyik élvez elsőbbséget?#

Az alügynökhierarchia öt szintből áll, a legmagasabbtól a legalacsonyabb prioritásig rendezve:

A prioritási logika megegyezik a Skillek és a CLAUDE.md esetében alkalmazottal: a szervezet felülírja a CLI-t, a CLI a projektet, a projekt a személyes beállítást, a személyes beállítás pedig a plugint.

Tudnivalók a betöltésről

Az alügynökök a Claude Code-munkamenet indításakor töltődnek be. Ha manuálisan szerkesztesz egy ügynökfájlt a lemezen, a módosítások csak a munkamenet újraindítása után lépnek életbe. Az interaktív /agents felületen végzett szerkesztések azonnal érvénybe lépnek.

Hatókörönként egy alügynök egy fájlt jelent. Ha a .claude/agents/ mappa tartalmaz egy code-reviewer.md fájlt, és van mellette egy másik code-reviewer.md is (például egy régi biztonsági másolatból), a Claude Code csendben figyelmen kívül hagyja az egyiket. Értesítés nem jelenik meg.

A pluginokhoz tartozó alügynökök külön esetet jelentenek. Biztonsági korlátozások vonatkoznak rájuk: a hooks, mcpServers és permissionMode mezőket nem támogatják. Ez megakadályozza, hogy egy harmadik féltől származó plugin engedélyt kapjon tetszőleges kód futtatására a gépeden.

Az alügynökfájl felépítése: frontmatter és törzs#

Példa a hivatalos dokumentációból a minimális változatra – mindössze 9 sor:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

Ennyi elég. Ha egy felhasználó azt írja a fő beszélgetésben, hogy „nézd át a PR-emet”, Claude a „reviewer / code / quality” kifejezéseket a leírással egyezteti, és delegálja a feladatot az alügynöknek. Az alügynök elolvassa a diffet, megjegyzéseket készít, majd összefoglalót küld vissza a fő beszélgetésnek. A fő beszélgetést nem zsúfolják tele a naplók és a köztes elemzések.

A teljes frontmatter-séma

A model: haiku mező testesíti meg a listában említett „költségszabályozást”. Ha van egy kutatási ügynököd, amely 50 oldalnyi dokumentációt olvas, futtasd Haikuval, így az Opushoz képest 5–7-szeres megtakarítást érhetsz el.

Az isolation: worktree mező egy fontos problémát kezel: egy alügynök potenciálisan veszélyes módosításokat végez (refaktorálás, migráció), te viszont nem szeretnéd, hogy a munkapéldányodhoz nyúljon. Állítsd be az isolation: worktree értéket, és a Claude Code ideiglenes git-másolatot készít a projektből; az alügynök ott dolgozik, majd egy diffet ad vissza ellenőrzésre.

A fájl törzse a rendszerprompt

A frontmatter után hagyományos Markdown következik – ez az alügynök rendszerpromptja. Nincs szükség különleges szerkezetre, de ez a minta bevált:

1. Ki vagy te – egy mondat: „te kódellenőr vagy”, „te biztonsági auditor vagy”, „te dokumentációkarbantartó vagy”.
2. Mikor hívnak meg, és mit teszel először – az első 2–3 művelet a feladat kézhezvétele után.
3. Ellenőrzési vagy lépéslista – 5–10 pont, amelyet az alügynök követ.
4. Mit adsz vissza – a végső jelentés formátuma. Ez döntő fontosságú: ha nem adsz meg formátumot, az alügynök strukturált összefoglaló helyett „esszét” készít.
5. Mit NEM teszel – kifejezett korlátozások. E szakasz nélkül az alügynök rögtönözni kezd.

A fájl törzse legfeljebb 200–500 sor legyen. Ha hosszabb, helyezd át a terjedelmes hivatkozásokat külön, közeli fájlokba, és hivatkozz rájuk a promptban.

Hogyan írj olyan leírást, amely alapján Claude biztosan meghívja az alügynököt?#

Gyakori probléma, hogy valaki beállít egy alügynököt kódellenőrzéshez, de Claude mindent maga végez el, anélkül, hogy az ügynököt használná. Ennek rendszerint egyetlen oka van: a leírás például így szól: „Helper for code review.” Claude nem érti, mikor kell aktiválnia.

A hatékony leírás képlete (3 rész)

1. rész – mit csinál. Egy mondat az eredményről, nem a folyamatról. Ne azt írd, hogy „kódot elemez”, hanem azt, hogy „sebezhetőségeket keres a kódban, és súlyosságot, valamint javítási javaslatot tartalmazó listát ad vissza”.

2. rész – mikor aktiválódjon. 3–5 idézőjelbe tett kifejezés úgy, ahogy a felhasználók ténylegesen kérni szokták. Ne találgasd – nézd meg a beszélgetési előzményeket és a valós megfogalmazásokat.

3. rész – mikor NE aktiválódjon. 1–2 kifejezés a hasonló feladatokról, amelyekre ennek az alügynöknek nem kell reagálnia. E szakasz nélkül két hasonló ügynök folyamatosan összeakad.

A varázskifejezés: „Use Proactively”

Az Anthropic hivatalos dokumentációja közvetlen ajánlást tesz:

Más szóval, ha a leírásból hiányoznak az egyértelmű jelzések, Claude alapértelmezés szerint nem szívesen hívja meg az alügynököt. Add hozzá a „use proactively” vagy a „use immediately after writing code” kifejezést, és az aktiválás jelentősen gyakoribbá válik.

Így néz ki egy jó leírás

description: |
  Expert code review specialist. Proactively reviews code for quality,
  security, and maintainability. Use immediately after writing or
  modifying code. Returns prioritized list of issues with severity
  and fix recommendations.
  Do not invoke for documentation changes, README edits, or commit
  message rewrites - these are handled by doc-maintainer.

Mi működik ebben:

• A „reviews” + „returns” igék konkrét eredményt határoznak meg, nem folyamatot.
• A „Proactively” és az „immediately after” kifejezések egyértelmű aktiválási feltételek.
• A „Do not invoke for...” kizárja az ütközést egy hasonló alügynökkel.
• A description angol nyelve megszokott. Claude angolul jobban illeszti hozzá a feladatokat.

5 használatra kész alügynökszerep, amely 10 perc alatt bevethető#

Az alábbi szerepek mindegyike egyetlen fájl, .claude/agents/<name>.md. A fájl létrehozása után indítsd újra a Claude Code-ot, nyisd meg az /agents felületet, és ellenőrizd, hogy az új ügynök megjelenik-e a listában. Ezután az @agent-name használatával hívhatod meg.

1. code-reviewer – kódellenőrzés minden módosítás után

Ez az Anthropic dokumentációjának hivatalos példája, munkafolyamatra szabva:

---
name: code-reviewer
description: |
  Expert code review specialist. Proactively reviews code for quality,
  security, and maintainability. Use immediately after writing or
  modifying code.
tools: Read, Grep, Glob
model: inherit
color: blue
---

You are a senior code reviewer ensuring high standards of code quality.

When invoked:
1. Read the diff and changed-file list supplied by the main session. If missing, ask the main session to provide them.
2. Use Read, Grep, and Glob to inspect the relevant files.
3. Return findings without changing files or running shell commands.

Review checklist:
- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Test coverage adequate
- Performance considerations addressed

Provide feedback organized by priority:
- Critical issues (must fix before merge)
- Warnings (should fix)
- Suggestions (consider improving)

Format: for each issue - file:line + 1 sentence why it's a problem + concrete fix.

A kulcs a tools: Read, Grep, Glob: az ellenőr fájlolvasó és kereső eszközöket kap, Bash-, Write- és Edit-hozzáférés nélkül. A diffet a fő munkamenet készíti elő és adja át. A puszta utasítás, hogy csak git diff fusson, nem korlátoz egy teljesen megadott Bash eszközt.

2. security-auditor – sebezhetőségek és kiszivárgások felderítése

Ez a szerep az opus modellt használja alaposabb gondolkodáshoz, ugyanazzal a Read, Grep és Glob eszközkorláttal. A tartós memória kimarad ebből a csak olvasó sablonból, mert az ügynökmemória bekapcsolása memóriaírási képességet is ad:

---
name: security-auditor
description: |
  Security audit specialist. Use proactively to find OWASP Top 10
  vulnerabilities, exposed secrets, injection risks, broken auth.
  Run before any deploy or merge to main.
tools: Read, Grep, Glob
model: opus
color: red
---

You are a security auditor. Find exploitable vulnerabilities, not style issues.

Audit checklist:
- SQL / NoSQL injection
- XSS (stored, reflected, DOM-based)
- CSRF / SSRF risks
- Hardcoded secrets (API keys, tokens, passwords)
- Broken auth / session management
- Insecure deserialization
- Missing input validation
- Path traversal
- Open redirects
- Insecure direct object references (IDOR)

For each finding:
- Severity: Critical / High / Medium / Low
- File:line
- Attack scenario in 1–2 sentences
- Fix recommendation with code example

Skip linter or style noise. Report only exploitable issues.

Eszközhasználat szempontjából ez csak olvasható szerep, model: opus beállítással az összetett ellenőrzésekhez, például a sebezhetőségek láncolatához.

3. research-agent – alapos kutatás 8+ forrásból

Ezt a mintát maga az Anthropic ismerteti a többügynökös kutatási rendszeréről szóló cikkében. A kulcs a kifejezett kimeneti formátum és a nyers eredmények kiírásának tiltása:

---
name: research-agent
description: |
  Deep web research specialist. Use proactively for fact-finding,
  competitive analysis, gathering external documentation, comparing
  approaches across multiple sources.
tools: WebFetch, WebSearch, Read, Write
model: sonnet
maxTurns: 30
color: purple
---

You are a research analyst. Goal: synthesized brief, not raw search dumps.

Process:
1. Decompose the question into 3–5 sub-queries
2. WebSearch each sub-query, fetch top 3–5 sources per query
3. Cross-verify claims across at least 2 independent sources
4. Reject SEO-farm and aggregator content; prefer primary sources
5. Quote verbatim with URL attribution for any specific claim
6. Return: TL;DR (3 bullets) + Findings + Sources (8+ domains minimum)

Anti-patterns to avoid:
- Don't cite a fact from a single source
- Don't paraphrase quotes as if they were verbatim
- Don't return raw search result dumps to the parent
- Don't include filler intro / outro ("Hope this helps")

A maxTurns: 30 védelemként szolgál, hogy a kutatás ne fajuljon végtelen iterációvá. Az Anthropic ezt az értéket a többügynökös rendszeréről szóló cikkében közli:

A kilencven százalékos különbség a kutatási benchmarkfeladatokra vonatkozik. A gyakorlatban az üzleti feladatoknál a növekedés kisebb, de az általános mérték hasonló.

4. doc-maintainer – a dokumentáció és a kód szinkronban tartása

Ez a szerep model: haiku modellt használ – tipikus példa a „költségszabályozásra”. A dokumentációhoz nincs szükség Opusra; Haiku harmadakkora költségért elvégzi a munkát:

---
name: doc-maintainer
description: |
  Documentation sync specialist. Use after merging features to update
  README, API docs, CHANGELOG. Reads recent commits, identifies
  undocumented changes, updates docs proactively.
tools: Read, Write, Edit, Glob, Grep, Bash
model: haiku
memory: project
color: green
---

You maintain documentation in sync with code.

When invoked:
1. Run `git log --since="last release"` to see recent changes
2. Read README.md, docs/, CHANGELOG.md
3. Identify gaps: new features without docs, removed APIs still
   documented, version mismatches

Output:
- Updated files (use Edit, not Write - preserve existing structure)
- CHANGELOG.md entry in Keep-A-Changelog format
- List of changes you made (actual diff summary, not paraphrase)

Style rules:
- Active voice, present tense
- Code examples must be copy-pasteable
- No marketing language ("powerful", "robust", "seamless")
- No filler ("This guide will help you...")

5. refactor-agent – biztonságos refaktorálás worktree-n keresztül

Ez a szerep az isolation: worktree beállítást használja – az alügynök a repository külön példányában dolgozik, és csak akkor olvasztod össze a változtatásait, ha jóváhagyod:

---
name: refactor-agent
description: |
  Safe refactor specialist. Use for renames, extracts, inlines that
  shouldn't touch your working copy until reviewed. Runs in a
  temporary git worktree.
tools: Read, Edit, Write, Bash, Grep, Glob
model: sonnet
isolation: worktree
permissionMode: acceptEdits
color: yellow
---

You refactor code without changing behavior.

Strict rules:
1. Tests must pass BEFORE and AFTER the refactor.
   If pre-refactor tests fail, STOP and report.
2. One atomic refactor per commit (extract, rename, inline).
3. Never change public APIs without explicit instruction.
4. Never modify tests unless they test the refactored implementation
   directly.

Process:
- Run test suite -> baseline
- Make atomic refactor
- Run test suite -> verify
- Commit with conventional message: refactor(scope): what

Return: summary of changes + worktree path so user can diff and merge.

Ezzel a szereppel megszűnik a legfájdalmasabb refaktorálási probléma: „Elrontottam valamit, és nem tudom visszacsinálni”. Az eredeti példány érintetlen marad, az alügynök pedig elszigetelt worktree-ben dolgozik.

Nemcsak a használatra kész alügynököket szeretnéd másolni, hanem olyan kombinációt összeállítani, amely stabil eszközzé teszi Claude-ot? Az alügynökök az AI-klónod részei: így adhatsz Claude-nak olyan specializált csapatot, amely a te logikád szerint dolgozik. A módszertan három pillére: AI-klón (Skills + Subagents) + Second Brain + Context Engineering. Ez a kombináció találgató asszisztensből olyan eszközzé alakítja Claude-ot, amely a te logikád szerint gondolkodik.

5 alügynök párhuzamos indítása: vezénylő + végrehajtók#

A párhuzamos vezénylés olyan, mint „a karmester és a zenekar”. A karmester kezében van a terv, nem ő írja a kottát, és ellenőrzi, hogyan játszanak a zenészek. Ha valaki rossz hangot játszik, a karmester arra kéri, hogy játssza újra, nem pedig megpróbálja helyette befejezni a művet.

A vállalkozóknak közelebb álló hasonlat egy marketingügynökség, amely egy új ügyfél stratégiáját készíti elő. Az egyik elemző SWOT-elemzést készít, egy másik versenytárselemzést végez, egy harmadik közönségprofilt állít össze, egy vezető elemző kiszűri a költségkeretbe nem illő hipotéziseket, a projektmenedzser pedig összeállítja a végső prezentációt. A Claude Code-ban ez a munkafolyamat egyetlen mondattal indul – és a kritikus már a folyamat része, nem utólag érkezik.

Minimális vezénylőprompt

A fő beszélgetésben egy mondat is elég:

Launch five subagents in parallel: three research-agents on different sources
(Anthropic docs, GitHub repos, AI bloggers), one critic-agent to filter out
weak conclusions, and one summary-agent for the final document.

Context: I am writing a guide about X. Target length: 2,000 words with sources.
Before starting, each one reads CLAUDE.md.

Claude ezután delegálja a munkát az öt ügynöknek. Mindegyik a saját kontextusában dolgozik: a kutatóügynökök a nekik kijelölt forrásokat használják, a kritikus szűr, az összefoglaló ügynök pedig összeállítja a dokumentumot. Csak a végső összefoglalók kerülnek vissza a fő beszélgetésbe.

Mikor éri meg a párhuzamosítás?

Nem minden esetben. A párhuzamos végrehajtás csak akkor indokolt, ha:

1. A feladatok függetlenek. Ha a research-agent #2 a research-agent #1 eredményére vár, nincs párhuzamosság – lényegében egymás után dolgoznak.
2. A feladatok hosszú ideig tartanak. A „záró szóközök eltávolításának” párhuzamosítása értelmetlen; az alügynökök indításának költsége felemészti a nyereséget.
3. Megfelelő keretekkel rendelkezel. Erről részletesebben az alábbi külön szakasz szól – a párhuzamos alügynökök gyorsan fogyasztják a tokeneket.

Az Anthropic Multi-Agent v2 rendszere: a következő lépés

2026 májusában az Anthropic kiadta a Multi-Agent Orchestration v2-t, amely három fontos szempontban különbözik a párhuzamos alügynökök indításának klasszikus megközelítésétől. Erről bővebben a következő szakaszban.

Újdonságok a Multi-Agent v2-ben: Orchestration, Outcomes, Dreaming#

Multi-Agent Orchestration: megosztott fájlrendszer + munkafolyamat közbeni bejelentkezések

Az Anthropic így írja le ezt a funkciót:

A klasszikus alügynökökhöz képest a fő különbség a megosztott fájlrendszer. Korábban minden alügynök teljes elszigeteltségben dolgozott, az információcsere pedig kizárólag a visszaküldött összefoglalón keresztül történt. Most a szakértők egy megosztott mappába írhatnak, a vezető ügynök pedig a munka előrehaladtával olvassa az eredményeket, nem csak a végén. Ez megoldja azt a problémát, hogy „mindenki egész nap dolgozott, a végén pedig kiderült, hogy két ember össze nem egyeztethető megközelítést alkalmazott”.

A második újítás a munkafolyamat közbeni bejelentkezés. A vezető ügynök megállhat, és bármelyik szakértőtől megkérdezheti, hogy „hogy halad”, majd módosíthatja az átfogó tervet. Ez hasonló ahhoz, ahogyan egy valódi csapatvezető dolgozik.

Outcomes: rubrika lépésről lépésre szóló utasítások helyett

Az Outcomes használatakor sikerkritériumokat írsz, az ügynök pedig megtalálja az elérésükhöz vezető utat. Egy külön értékelő a saját kontextusában ellenőrzi az eredményt, így azt nem „szennyezi be” a fő ügynök gondolatmenete.

A kihívást jelentő feladatoknál elért tízszázalékos javulás komoly eredmény. Különösen akkor, ha a feladat úgy szól, hogy „állíts össze egy hosszú cikket, amely megfelel ezeknek a minőségi kritériumoknak”, nem pedig úgy, hogy „kövesd az 1–7. lépést”.

Dreaming: az ügynökök a munkamenetek között is tapasztalatot gyűjtenek

Ez a leginkább újszerű koncepciójú funkció. Az ügynök átnézi a korábbi munkameneteket, mintákat keres a sikeres és a hibás esetekben, majd frissíti a memóriatárat. Beállíthatod, hogy a változtatások alkalmazása előtt kézi ellenőrzésre legyen szükség, vagy az ügynök önállóan is módosíthatja a memóriát.

Az Anthropic beszámolója szerint a jogi technológiával foglalkozó Harvey a Dreaming bevezetése után körülbelül hatszoros növekedést ért el a jogi szövegezési feladatok sikerességében. Ez már éles környezetben működik, nem csupán bemutatóban.

Mit jelent ez a programozni nem tudó vállalkozók számára?

A Multi-Agent Orchestration jelenleg a Claude Agent SDK-n keresztül érhető el, közvetlenül a Claude Code CLI-ben nem. Az irány azonban egyértelmű: a vezénylés a „kézzel indítasz el N alügynököt” módról afelé halad, hogy „leírod a feladatot, a vezető ügynök pedig eldönti, kinek és hogyan delegálja”. Ha most ismerkedsz az alügynökökkel, még ne aggódj a v2 miatt. Tanuld meg a klasszikus „1 fő beszélgetés + 3–5 különböző szerepű alügynök” mintát, és 3–6 hónap múlva természetesen áttérhetsz a Managed Agents használatára.

7 hiba, amely megbénítja az alügynököket#

1. hiba. A „Helper for X” leírások nem indítják el az ügynököt

Tünet: megírtál egy alügynököt, ellenőrizted a szerkezetét, minden érvényes, de Claude nem hívja meg a felhasználói kérésekre. Ennek szinte mindig ugyanaz az oka: a leírás túl elvont, például „Helper for code review.” A megoldás: írj 3–5 valódi felhasználói kifejezést idézőjelben közvetlenül a leírásba, és add hozzá a „use proactively” / „use immediately after” kifejezést.

2. hiba. Alügynök készítése Skill helyett

Az alügynök többe kerül, mint a Skill: saját kontextust hoz létre, betölti a saját rendszerpromptját, és több tokent használ. Ha a feladat rövid, nem foglalja el a fő kontextust, és egy menetben elvégezhető, akkor Skillt érdemes használni, nem alügynököt. Példa a kerülendő mintára: a format-validator alügynök, amely 20 szabály alapján ellenőriz egy JSON-sémát. Ez Skill legyen: egy modell, nincs szükség elszigetelésre, nem kell külön kontextust betölteni.

3. hiba. Azonnal „60 párhuzamos ügynök” indítása

Ez a legelterjedtebb illúzió. Látsz egy bejegyzést, amely szerint „1,500 ügynököm dolgozik”, és arra gondolsz, hogy „nekem is ezt kellene csinálnom”. A gyakorlatban 60 ügynök egy óra alatt felemészti a Pro csomag korlátait, egymásnak ellentmondó eredmények halmát állítja elő, a nap végére pedig semmi sem készül el.

Egy Mediumon publikáló szakember így fogalmaz:

A megoldás: kezdj egyetlen alügynökkel és egyetlen feladattal. Ha már magabiztosan használod, adj hozzá egy második, eltérő szerepű ügynököt. Ha a két ügynök vezénylését is elsajátítottad, lépj tovább egy 3–5 fős csapatra. Ha tegnap telepítetted a Claude Code-ot, ma pedig már „20 ügynököt futtatsz párhuzamosan”, az biztosan kódhibákhoz és a használati korlátok kimerítéséhez vezet.

4. hiba. Minden eszköz megadása minden ügynöknek

Ha a kódellenőr hozzáfér a Bashhez, a Write-hoz és a WebFetchhez, az komoly biztonsági és költségkockázat. Egy ellenőrnek ne legyen írási jogosultsága, és az internethez való hozzáférésre még kevésbé van szüksége.

A megoldás: korlátozd szigorúan a tools mezőt. A kódellenőr csak a Read, Grep, Glob eszközöket kapja meg. A biztonsági auditor ugyanezeket az olvasó- és keresőeszközöket, valamint a fő munkamenettől kapott diffet használja. A Bash hozzáadása shellképességet ad; nem korlátozza automatikusan az ügynököt a git diff használatára. A kutatóügynök a WebFetch, WebSearch, Read, Write eszközöket kapja. Egyetlen alügynöknek se adj több jogosultságot annál, mint amennyire az adott feladathoz szüksége van.

5. hiba. Az alügynök nyers eredményekkel tölti meg a fő kontextust

Ha egy kutatóügynök ezt küldi vissza a fő beszélgetésbe: „itt van mind a 30 oldal, amit találtam, majd döntsd el te”, akkor elvesztetted az alügynökök legfőbb előnyét: a zaj elkülönítését. A megoldás: írd elő kifejezetten a kimeneti formátumot az alügynök rendszerpromptjában. „CSAK ezt add vissza: 3 pontos TL;DR + 5 forrás listája. NE legyen benne kódhalmaz, és NE legyen benne nyers keresési eredmény.” A formátum legyen szigorú – az alügynök ne alakíthassa „esszévé”.

6. hiba. Homályos meghívás: nem egyértelmű delegálási kérés

Az alügynök nem látja a fő párbeszéd előzményeit. Tiszta kontextussal + CLAUDE.md-vel + mindazzal indul, amit kifejezetten megírtál neki. Ha csak annyit írsz, hogy „javítsd ki a hitelesítést”, az alügynök találgatni fog. Ehelyett ezt írd: „Javítsd ki azt az OAuth-átirányítási hurkot, amely miatt a felhasználó sikeres bejelentkezés után a /dashboard helyett a /login oldalra kerül. Fájl: src/lib/auth.ts.”

Egyszerű szabály: delegáláskor annyi kontextust adj az alügynöknek, amennyit egy frissen a projekthez csatlakozó új vállalkozónak adnál.

7. hiba. Feladat-alapú ügynökök helyett szerepkör-alapú ügynökök

Csábító lehet a következő minta: „hozzunk létre egy frontend-developer, backend-developer és qa-engineer ügynököt, és dolgozzanak csapatként”. Nem működik. Minden „szerep” elveszíti a teljes projekt kontextusát, és nem tudnak megegyezni a részletekben, mert nem látják egymás munkáját.

A megoldás: az alügynök visszatérő feladatot végezzen jól meghatározott kimenettel, ne egy szerepkört töltsön be. Ne „frontend-developer” legyen, hanem „explore-ui-tree”, „refactor-component” vagy „audit-accessibility”. Minden feladatalapú alügynök egy konkrét munkát végez, és egy konkrét eredményt ad vissza.

Mennyibe kerülnek a párhuzamos alügynökök, és mikor érik meg?#

Ha összetett feladatokon öt párhuzamos alügynököt indítasz, egy órán belül elfogy a Pro csomag kerete. A Max 5x ($100) reális minimum a rendszeres párhuzamos munkához. A csapatoknál és az Enterprise csomagnál a költség kérdését már az eszközkeret szintjén kezelik.

Ha többet szeretnél megtudni a Claude Code-ban való tokenmegtakarításról, olvasd el a használati korlátokról szóló külön útmutatót. Az alügynököknél az a legfontosabb szabály, hogy legalább 10 percnyi összpontosított munkát igénylő feladatra éri meg alügynököt használni. Ha a feladat ennél rövidebb, ne hozz létre alügynököt; végezd el a fő beszélgetésben vagy egy Skillel.

Hogyan illesztheted be az alügynököket az AI-klónodba és a Second Brainbe?#

Az alügynök három dologra támaszkodik, amelyeknek már a projektben kell lenniük, mielőtt létrehozod az első szakértőt:

1. A megfelelő CLAUDE.md. Az alügynök indulás előtt elolvassa a CLAUDE.md-t – ez a „munkaszerződése”. Enélkül nem ismeri a projekt kontextusát, korlátozásait és hangvételét. Találgatni fog.

2. Alapvető Skills. A Skill egy csomagba foglalt módszertan. Az alügynök csak azokat a Skilleket tölti be, amelyekre szüksége van, nem mindet egyszerre. Skillek nélkül minden alkalommal az elejéről kezdi ugyanazt a munkát.

3. Second Brain: tudásstruktúra. A business/ mappa (vagy a szakterületednek megfelelője) olyan könyvtár, amelyet az összes alügynök használ. Enélkül az alügynök átlagos ChatGPT-választ ad, amely nem különbözik mások válaszaitól.

Ha megfordítod a sorrendet, eredmények helyett csak felhajtást kapsz. A „60 párhuzamos alügynököm van” egy üres business/ mappával valójában 60 átlagos ChatGPT-munkamenetet jelent, ugyanazzal a megközelítéssel.

A teljes kombináció – AI-klón + Second Brain + Context Engineering – alkotja azt a három pillért, amely következetessé teszi Claude-ot. Az alügynökök az AI-klón részei: olyan módon adhatsz Claude-nak specializált csapatot, hogy az a te logikád szerint dolgozzon.

A leggyorsabban úgy kezdheted, ha az első példából a code-reviewer fájlt bemásolod a .claude/agents/code-reviewer.md útvonalra, újraindítod a Claude Code-ot, majd a következő commitnál meghívod az @agent-code-reviewer ügynököt. 5 perc alatt kiderül, hogy szükséged van-e alügynökökre, vagy elegendő a fő beszélgetés.