Claude Code subagenter: En praktisk guide (2026)

En subagent er en anden Claude, lanceret af din hoved-Claude Code-session, der kører en opgave i sit eget kontekstvindue og afleverer et resultat tilbage. Den deler ikke din samtalehistorik. Den ser ikke de filer, du allerede har læst, eller de beslutninger, du allerede har taget. Den får en prompt, laver arbejdet og vender tilbage.

Den isolation er hele funktionen. Parallelismen, specialiseringen, de brugerdefinerede værktøjsbegrænsninger, alt det er nedstrøms fra ét faktum: en subagent brænder sit eget kontekstvindue, og kun det endelige svar kommer tilbage til dit.

Vi kører dusinvis af subagenter om dagen, mens vi bygger SkillProof, mest til forsknings-fan-out og uafhængige fixes på tværs af katalogets datafiler. Noget af det, vi har lært, er genuint nyttigt. Noget af det lærte vi ved at se en agent hævde sejr over arbejde, den aldrig lavede. Begge slags er i denne guide.

Hvad en subagent faktisk er

I Claude Code er hovedsessionen et loop: læs, tænk, handl, observér, gentag, med hvert skridt tilføjet til én voksende samtale. En subagent er en separat instans af det samme loop, startet midt i sessionen, med sin egen historik, der starter tom bortset fra den prompt, du giver den.

Når subagenten er færdig, rejser intet af dens mellemliggende arbejde tilbage. Ikke filerne den læste, ikke kommandoerne den kørte, ikke de blindgyder den udforskede. Kun teksten, den vælger at returnere, lander i din hovedkontekst. Læste den 40 filer for at besvare dit spørgsmål, betaler din hovedsession for ingen af de 40 læsninger. Den betaler for én opsummering.

Det er grunden til, at subagenter bliver beskrevet som en måde at bevare kontekst på: ikke fordi arbejdet er gratis (det koster de samme tokens et sted), men fordi omkostningen er karantæneret i et vindue, der bliver smidt væk, ikke ét du bliver ved med at trække gennem resten af sessionen.

Afvejningen følger direkte. En subagent, der ikke ved, hvad du allerede har prøvet, kan gentage dine egne blindgyder, og den kan ikke stille et opklarende spørgsmål midt i opgaven, som hovedloopet kan, den har enten nok i prompten til at fortsætte, eller den gætter. Uddelegering køber isolation og koster delt hukommelse. Hver god subagent-prompt er skrevet af nogen, der har internaliseret den afvejning.

Hvorfor kontekst-isolation er pointen

Forestil dig en hovedsession to timer inde i en refaktorering: fyrre filer læst, et dusin værktøjskald, en designbeslutning genbesøgt to gange. Den historik gør reelt arbejde, det er det, der gør den næste redigering sammenhængende, men det er også halvtreds tusind tokens ballast.

Nu skal du vide, hvordan et urelateret undersystem håndterer retries. Læs de filer i hovedloopet, og hver eneste bliver permanent bagage, der kører med i konteksten resten af sessionen, uanset om du bruger den igen eller ej, indtil det er en del af, hvorfor modellen begynder at miste tråden i den faktiske refaktorering. En subagent lader dig stille spørgsmålet, få svaret og gå væk fra læsningen. De fyrre filer, den læste, kommer aldrig ind i dit vindue. Du får ét afsnit tilbage.

Det er mekanismen bag hver legitim subagent-sejr i denne guide: forskning, parallelle fixes, støjende udforskning. Alle er de i virkeligheden det samme træk, lav den dyre læsning et engangssted, hold hovedtråden ren.

Hvornår subagenter slår at arbejde i hovedloopet

Forskning på tværs af mange filer. "Hvordan flyder auth gennem denne kodebase" rører ruter, middleware, session-lager og tre config-filer. At besvare det i hovedloopet betyder, at alt det lander i din kontekst permanent. En subagent læser de samme filer, returnerer en syntese, og det rå materiale forsvinder med den.

Parallelle uafhængige opgaver. Fem komponenter skal alle have den samme prop omdøbt. Ingen afhænger af hinanden. Fem subagenter, der kører samtidig, er færdige på nogenlunde den tid, én tager, uden delt tilstand at koordinere mellem ændringerne.

Støjende udforskning. At greppe efter et mønster på tværs af et stort repo, prøve tre søgestrategier, før én rammer, læse filer, der viser sig irrelevante. Det er præcis det arbejde, du vil have i karantæne. En subagent kan famle rundt et stykke tid, og kun den nyttige del kommer tilbage.

Isolering af en specialiseret persona. En code-reviewer-subagent, der kun nogensinde reviewer, med et smallere værktøjssæt og en prompt finjusteret til skepsis, opfører sig mere konsistent end at bede din hovedagent om at kontekst-skifte til "vær nu kritisk over for dit eget arbejde" midt i sessionen.

Hvornår subagenter er værre

Stramme iterative loops. At debugge en fejlende test ved at ændre én linje, køre igen, læse den nye fejl, ændre en anden linje, kræver den fulde historik af, hvad du allerede har prøvet. At give det til en frisk subagent hver iteration betyder at genforklare hele undersøgelsen hver gang, langsommere og værre end at blive i hovedloopet. Det er territoriet, vores systematic debugging-noter dækker: debugging vil have kontinuitet, ikke uddelegering.

Opgaver, der har brug for hele samtalen. Har brugeren brugt ti beskeder på at finjustere præcis, hvad "ryd op i denne API" betyder, vil en subagent, der kun ser den endelige instruktion, rydde op efter sit eget gæt på "ryd op," ikke det, du forhandlede. Alt hvor kravene bor i samtalen frem for en prompt, du kan genformulere, er et dårligt match.

Simple enkelt-fil-redigeringer. At uddelegere "omdøb denne variabel i denne fil" til en subagent tilføjer en rundtur, en frisk kontekst-indlæsning og et resultat, du stadig skal læse og stole på, for arbejde der ville have taget femten sekunder direkte. At spinde en isoleret arbejder op betaler sig kun, når arbejdet, den skærmer dig fra, genuint er stort.

Mønsteret på tværs af alle tre: subagenter er værre præcis når værdien af delt kontekst opvejer omkostningen ved at bære den. Isolation stopper med at være en funktion i det øjeblik, kontinuitet er, hvad opgaven havde brug for.

Brugerdefinerede agent-definitioner

Claude Code indlæser brugerdefinerede subagenter fra markdown-filer under .claude/agents/ (projekt-niveau, delt gennem git) eller ~/.claude/agents/ (personlig, hvert projekt). Hver fil er én agent: frontmatter plus en systemprompt, samme form som en skill, men beskriver en persona i stedet for en procedure.

Her er et fuldt, annoteret eksempel, en code-reviewer afgrænset til read-only reviewarbejde:

---
name: code-reviewer
description: Reviewer en diff eller pull request for korrekthedsfejl,
  sikkerhedsproblemer og forpassede edge cases. Brug efter en ændring er
  skrevet og før den committes, ikke mens den stadig udkastes.
tools: Read, Grep, Glob, Bash
model: sonnet
---

Du er en senior-ingeniør, der laver en pre-commit-review. Du skrev
ikke denne kode, og du har ingen tilknytning til den.

Når du får en diff eller et sæt ændrede filer:

1. Læs hver ændret fil i fuldt omfang, ikke bare diff-hunks.
   Fejl gemmer sig i konteksten omkring en ændring lige så ofte som
   i selve ændringen.
2. Tjek for: uhåndterede fejl, off-by-one-grænser, null- eller
   undefined-stier typesystemet ikke fanger, og enhver hemmelighed
   eller credential, der ikke burde være committed.
3. Kommentér ikke på stil eller formatering, medmindre det skjuler
   en fejl. En linters job er ikke dit job.
4. For hvert fund, citér filen og linjen, og sig hvad der går i
   stykker, og hvordan du ville bekræfte det. Er du ikke sikker på,
   om noget er en fejl, sig det eksplicit frem for at fremstille
   det som et faktum.
5. Finder du intet, sig det ligeud. Opfind ikke mindre problemer
   for at se grundig ud.

Kør aldrig kommandoer, der ændrer filer. Du reviewer, du fixer ikke.

Et par ting betyder noget her. name er, hvordan du påkalder den (Brug code-reviewer-agenten til at tjekke denne diff) eller hvordan Claude Code selv påkalder den på en matchende opgave. description-feltet bærer den samme vægt, det gør i en skill: specifikke triggerbetingelser slår en vag opsummering.

tools er en genuin sikkerhedsgrænse, ikke et forslag. At liste kun Read, Grep, Glob, Bash betyder, at denne agent fysisk ikke kan kalde Edit eller Write, selv hvis dens egen ræsonnering besluttede, at en fix var indlysende. Det er bevidst: en review-agent, der også kan patche koden, den reviewer, er én, du ikke kan stole på kun reviewer. model lader dig route en mekanisk, veldefineret agent til en billigere model end din hovedsession, siden opgaven ikke har brug for din primære models fulde vægt.

Kroppen er samme håndværk som en skill: negative begrænsninger ("kommentér ikke på stil," "opfind ikke mindre problemer") gør mere arbejde end positive, fordi de er det, der stopper en reviewer fra at polstre sit output for at se grundigt ud.

Parallelle mønstre, der faktisk virker

Fan-out-læsninger. Lancér flere subagenter på én gang, hver tildelt en anden skive af det samme spørgsmål: én læser auth-modulet, én datalaget, én testsuiten. Hver returnerer en kort syntese. Du får tre svar på den tid, én sekventiel gennemgang ville tage, og det rå filindhold rører aldrig din hovedkontekst.

N uafhængige fixes. En batch af komponenter har brug for den identiske mekaniske ændring, og ingen importerer fra hinanden. Lancér én subagent per komponent, hver med en selvstændig prompt: den præcise ændring, den præcise fil, det præcise accept-tjek. Det er det reneste parallelle tilfælde, ingen subagent behøver vide, hvad en anden lavede.

Begge mønstre deler et krav, der er let at springe over og dyrt, når man gør: hver prompt skal være selvstændig. Den har ikke din samtale. Afhænger opgaven af en beslutning taget tre beskeder siden, skal den beslutning genfortælles i prompten, ellers vil subagenten selvsikkert gøre det forkerte.

Fejltilstande, vi faktisk har ramt

Dette er den del, de fleste guides springer over, skrevet af nogen der kørte en subagent to gange, og det virkede. Vi kører dem dagligt, og her er hvad der går i stykker i praksis.

Agenter der rapporterer "færdig" uden at have lavet arbejdet. En subagent kommer tilbage med en ren, selvsikker opsummering: "Opdaterede de tre filer, tests består, klar til commit." Du tjekker, og én fil er urørt. Det er ikke modellen, der er uærlig i nogen bevidst forstand, det er returopsummeringen, der driver væk fra hvad der faktisk skete, især på længere opgaver, hvor agentens egen beretning om sit arbejde bliver komprimeret. Fixet er kedeligt og ikke til forhandling: verificér ved artefakt, ikke ved rapport. Læs diffen selv. Kør testen selv. En subagents opsummering er en påstand, ikke en kvittering.

Agenter der venter på fantom-notifikationer. Vi har haft subagenter, der pauser midt i opgaven i forventning om et callback eller signal fra en anden proces, der aldrig kom, fordi koordinationsmekanismen kun eksisterede i promptens fantasi, ikke i noget faktisk koblet op. Fixet er aldrig at designe en subagent-prompt omkring en hændelse, du ikke har verificeret udløses. Afhænger en subagents næste skridt af en anden agents output, giv den det output direkte, når du lancerer den, bed den ikke om at opdage et fuldførelsessignal, du ikke har bygget.

Begge fejl sporer tilbage til den samme disciplin: en prompt, der ikke læner sig op ad delt kontekst eller en antaget notifikation, er én, en agent faktisk kan fuldføre korrekt, og et resultat, du tjekker ved at læse filen, ikke ved at læse agentens beretning om filen, er den eneste måde at vide, den gjorde det. Intet af dette er et argument mod subagenter. Det er et argument mod at stole på en tekstopsummering, som du ville stole på en diff. Vi kører dem konstant. Vi merger bare intet på deres ord alene.

Skills virker inde i subagenter også

En subagent er stadig en Claude-instans, så den indlæser skills på samme måde, din hovedsession gør: matcher sin opgave mod installerede skill-beskrivelser og trækker teksten ind ved trigger. En code-review-subagent med vores code review checklist-skill installeret får den samme strukturerede gennemgang, den ville i hovedloopet, afgrænset til hvad end diff du gav den.

Det komponerer rent. Subagenten håndterer hvor arbejdet foregår, skillen håndterer hvordan det gøres. Ingen af dem behøver vide om den anden; de stabler automatisk, så længe begge er installeret, hvor subagenten kan se dem, projekt-skills i .claude/skills/, personlige skills i ~/.claude/skills/. Vores bedste kodningsskills-side rangerer dem, det er værd at installere, før du kobler en review- eller forsknings-agent op.

Subagenter vs. hooks vs. skills

Tre forskellige mekanismer, tre forskellige jobs, og de bliver sammenblandet konstant:

	Hvad den gør	Trigger på	Kører hvor
Skill	Lærer Claude en procedure eller stil	Claude der matcher din anmodning til en beskrivelse	Inde i den aktuelle kontekst
Hook	Kører en fast shell-kommando automatisk	En livscyklus-hændelse (før et værktøjskald, efter et svar, sessionsstart)	Uden for modellen, deterministisk
Subagent	Uddelegerer en opgave til en isoleret Claude-instans	Et eksplicit kald, af dig eller hovedagenten	Et separat kontekstvindue

En skill ændrer hvordan Claude griber noget an, den allerede skal gøre. En hook håndhæver noget hver gang, ubetinget, uden at bede modellen huske det: kør tests efter hver redigering, blokér en commit hvis hemmeligheder opdages. En subagent ændrer hvor arbejdet foregår, flytter det ind i et engangsvindue frem for dit hoved-vindue. Vi dækker hooks i dybden, inklusive samme slags ar-væv som ovenfor, i vores Claude Code hooks-guide.

De stabler. En team-opsætning kan bruge en hook til at linte efter hver skrivning, en skill til at lære husstilen, og en subagent til at køre den fulde review-gennemgang før merge, tre lag, ingen redundante. Er du stadig ved at samle resten af din opsætning, gennemgår vores 2026-opsætningsguide, hvor hvert stykke går hen, og vores token-omkostningsguide dækker, hvad alle tre koster i hvile.

FAQ

Deler subagenter min hovedsessions kontekst?

Nej, og det er hele pointen. En subagent starter med en tom historik bortset fra den prompt, du giver den. Intet fra din hovedsamtale følger automatisk med, og intet subagenten læser eller gør, kommer tilbage bortset fra den endelige tekst, den returnerer. Har den brug for baggrund fra din samtale, put den baggrund i prompten.

Kan subagenter køre parallelt?

Ja. At lancere flere på én gang er standardmønsteret til fan-out-forskning og til uafhængige, ikke-overlappende fixes. Hver får sit eget kontekstvindue, så de forstyrrer ikke hinanden, men de kan heller ikke koordinere midt i opgaven, medmindre du eksplicit har fodret én agents output ind i en andens prompt.

Hvordan ved jeg, om en subagent faktisk gjorde, hvad den hævdede?

Tjek artefaktet, ikke opsummeringen. Læs diffen, kør testen, åbn filen. Vi har haft subagenter rapportere ren succes på arbejde, der delvist var fortrudt, ikke af uærlighed, men fordi en opsummering er en rekonstruktion, og rekonstruktioner driver. Behandl hver subagent-rapport som en påstand, der skal verificeres.

Hvor bor brugerdefinerede agent-definitioner?

.claude/agents/*.md til projekt-niveau-agenter, der rejser med repoet gennem git, og ~/.claude/agents/*.md til personlige, tilgængelige på tværs af hvert projekt. Hver fil har brug for name og description i sin frontmatter som minimum; tools og model er valgfrie, men værd at sætte bevidst frem for at lade dem stå på deres standardværdier.

Skal jeg begrænse, hvilke værktøjer en subagent kan bruge?

Ja, når agenten har et smalt job. En review-agent, der ikke kan kalde Edit, kan ikke ved et uheld patche det, den skal kritisere. En read-only forskningsagent, der ikke kan kalde Bash, kan ikke ved et uheld køre noget destruktivt, mens den roder rundt. tools-feltet i en agents frontmatter er mekanismen, og at sætte det er billigere end at debugge, hvad en overmægtig agent gjorde med sin resterende tid.