Claude Code Workflows: Hva de er og når du faktisk trenger ett

Claude Code Workflows: Hva de er og når du faktisk trenger ett

Oppdater til Claude Code v2.1.154 og du finner en ny rad i /config merket Dynamic workflows. Skru det på, og Claude kan nå skrive et JavaScript-skript som fordeler arbeid til opptil 16 agenter som kjører samtidig. Det er funksjonen alle hvisker om. Den offisielle dokumentasjonen forteller deg hva den gjør. Den forteller deg ikke det du faktisk lurer på: trenger du det, eller holder subagentene du allerede har?

Det er her gapet ligger. Claude Code workflows ble lansert som en research preview, og dokumentasjonen leses som referansemateriale, ikke råd. Så vi kjørte det ene medfølgende workflowet, /deep-research, inne i vår egen innholdspipeline, logget de reelle tallene og skrev ned den ærlige vurderingen. Kortversjonen: hvis du fortsatt kan holde oversikt over agentene dine manuelt, trenger du ikke et workflow ennå. Noen av dere gjør det absolutt. La oss sortere ut hvilken gruppe du tilhører.

Viktige punkter:

• Et Claude Code workflow er et JavaScript-skript Claude skriver for å orkestrere subagenter i stor skala (research preview, v2.1.154+, alle betalte planer).
• Du trenger ett bare når en oppgave trenger flere agenter enn én samtale kan koordinere. Ellers holder subagenter.
• Én workflow følger med i dag: /deep-research. Den kjører i bakgrunnen mens sesjonen din forblir responsiv.
• Workflows er tokenkrevende. Vi målte en real kjøring før vi anbefalte ett (tallene nedenfor).

Hva er en Claude Code Workflow?

En Claude Code workflow er et JavaScript-skript som orkestrerer subagenter i stor skala. Du beskriver oppgaven, Claude skriver skriptet, og en runtime kjører det i bakgrunnen mens chat-sesjonen din forblir responsiv. Det er en research preview-funksjon i Claude Code, krever Claude Code v2.1.154+, og kjører på alle betalte planer (Pro, Max, Team, Enterprise, pluss API-et og Bedrock/Vertex/Foundry).

Her er hverdagsversjonen. Tenk deg at du går bort til en kjøkkendisk og beskriver måltidet du ønsker. Kokken skriver en oppskrift, gir den til et fullstaffet kjøkken, og de setter i gang mens du fortsetter å prate ved disken. Du mikrostyrer ikke hver kokk. Oppskriften gjør det. Den oppskriften er workflowet, kokkene er subagenter, og kjøkkenet som kjører bak scenen er runtimen.

Et workflow er ikke enda en agent. Det er skriptet som forteller agentene dine hva de skal gjøre, i hvilken rekkefølge, og hva de skal gjøre med resultatene. Den distinksjonen betyr mer enn noe annet i dette innlegget, og vi gjør den konkret i neste seksjon.

En rask ting å rydde opp i. Søk på "claude code workflows" og du treffer GitHub-repoer, plugins og en marketplace full av community swarm-verktøy som Ruflo, claude-flow og wshobson/agents. Det er tredjepartsorkestratorer. Anthropics offisielle Dynamic workflows er en annen, innebygd funksjon. Hvis den ikke er i /config på v2.1.154+, er det ikke den offisielle.

Dette plasserer seg ved siden av andre Anthropic research preview-lanseringer som den nylige fast mode research preview: lansert tidlig, bak en veksleknapp, og fortsatt litt uferdig i kantene. Behandle det som en preview, for det er det det er. Hele spesifikasjonen ligger i den offisielle workflows-dokumentasjonen.

Workflows vs. Subagenter vs. Skills: Hvem holder planen?

Den ryddigste måten å skille disse tre fra hverandre er å stille ett spørsmål: hvem holder planen? En skill er pakkede instruksjoner og kunnskap som Claude laster inn etter behov. En subagent er en separat kontekst som gjør én delegert jobb. Et workflow er orkestrasjonsskriptet som koordinerer subagenter i stor skala, opptil 16 på én gang. Samme verktøykasse, tre forskjellige jobber.

Her er sammenligningen den offisielle dokumentasjonen antyder men aldri legger ut side om side:

Hvis én Claude-samtale fortsatt kan holde hele planen i hodet, vil du ha en subagent, ikke et workflow. I det øyeblikket du spawner flere agenter enn du som menneske kan holde oversikt over, hvem som gjør hva og i hvilken rekkefølge, har planen vokst ut av samtalen. Det er grensen et workflow krysser.

Vil du gå dypere på det første beinet? Vår skills-tutorial dekker pakking av kunnskap Claude laster inn etter behov. Og hvis du vurderer om du skal bruke et fullt agent-rammeverk i stedet for native orkestrering, hjelper den sammenligningen. Vår ærlige vurdering: native primitiver rekker lenger enn du tror før et rammeverk fortjener plassen sin.

Når trenger du faktisk en Claude Code Workflow?

Du trenger en Claude Code workflow når (a) oppgaven trenger flere agenter enn én samtale kan koordinere, (b) du vil ha orkestrasjon lagret som gjenbrukbar kode i stedet for en engangs-prompt, eller (c) du trenger adversarial eller kryssjekket gjennomgang der flere agenter sjekker hverandres arbeid. Hvis ingen av disse er sanne, holder subagenter. Vær ærlig med deg selv her.

Dette er delen dokumentasjonen ikke vil si høyt, så det gjør vi: du trenger sannsynligvis ikke et workflow ennå. En håndfull subagenter, koordinert på tvers av en vanlig samtale, håndterer dagligdags arbeid. Workflows er ikke en oppgradering du gradvis avanserer til. De er et verktøy for én bestemt type problem: flere agenter enn ett hode kan holde oversikt over.

Kjør deg selv gjennom denne sjekklisten. Du trenger sannsynligvis et workflow hvis du svarer ja på minst ett punkt:

• Oppgaven trenger flere agenter enn én samtale kan holde oversikt over.
• Du vil ha orkestrasjon som gjenbrukbar kode, ikke en engangs-prompt du skriver på nytt.
• Du trenger adversarial eller kryssjekket gjennomgang (flere agenter som verifiserer hverandre).
• Du skal kjøre den samme multi-agent-jobben gjentatte ganger, som en regelmessig kodebase-revisjon eller en migrering av 500 filer.

Svarte nei på alle fire? Hold deg til subagenter. Du sparer tokens, holder ting feilsøkbart, og mister ingenting. De spec-drevne vil kjenne igjen dette mønsteret fra gode CLAUDE.md beste praksiser: skriv planen ned én gang, gjør den gjenbrukbar, slutt å skrive den på nytt. Et workflow er den ideen presset til punktet der selve planen trenger en runtime for å kjøre.

Det ene workflowet du allerede har: /deep-research

/deep-research er det ene medfølgende workflowet som følger med i preview-utgivelsen. Invokér det med et spørsmål, og det sprer subagenter ut for å undersøke emnet parallelt, kryssjekker funnene deres mot hverandre, og returnerer ett syntetisert svar til konteksten din, alt mens det kjører i bakgrunnen slik at sesjonen din forblir brukbar.

/deep-research Hva er de reelle tokenkostnadene ved multi-agent research i Claude Code?

Det er hele grensesnittet. Under panseret beveger det seg gjennom faser: det bryter spørsmålet ditt ned i research-tråder, spawner agenter for å jakte på hver, kjører en krysssjekk- eller gjennomgangsfase slik at agentene fanger hverandres svake påstander, og syntetiserer deretter ett endelig svar tilbake i chatten din. Du styrer det ikke underveis. Du spør, det jobber, det rapporterer tilbake.

Dette er genuint nyttig for de rotete research-spørsmålene der du ellers ville åpnet ti faner og mistet ettermiddagen din. Hvis du allerede kobler opp research-verktøy, passer vår oversikt over de beste MCP-serverne godt med denne typen fan-out research. Men "nyttig" og "verdt token-regningen" er ikke det samme, og det er nøyaktig det vi satte oss for å måle.

Hva som skjedde da vi kjørte et Workflow i vår egen Pipeline

Vår /deep-research-kjøring spawnet 9 subagenter over 4 faser, forbrente drøye 1 million tokens, og ble ferdig på ca. 8 minutter klokketid. Var det verdt det? For et raskt spørsmål, ikke sjansen. For en research-oppgave vi ellers ville koordinert manuelt over et halvt dusin agenter, betalte det seg. Her er den ærlige gjennomgangen.

I vår pipeline var dette innlegget du leser selv produsert av et multi-agent-system: research, brief, skriving, validering, oversettelse og publisering kjøres hver som separate subagenter. Vi lever altså allerede i "for mange agenter til én samtale"-verdenen fra sjekklisten ovenfor. Det gjorde oss til det rette testcaset, ikke et konstruert ett.

Vi kjørte /deep-research på et live nøkkelord vi allerede undersøkte og logget hele kjøringen:

Det som overrasket oss mest var krysssjekk-fasen. Et par tidlige påstander én agent produserte ble stille korrigert etter at en annen agent utfordret dem, noe en enkelt samtale pleier å la passere. Det adversariale steget er den reelle verdien, mer enn rå parallelisering. Tokenkostnaden er bratt, og disse agentene kjører på Opus-tier-modeller (se hva som er nytt i Opus 4.8 for hvorfor det betyr noe for regningen). En million tokens for et spørsmål du kunne besvart med to prompts er en dårlig handel. For et spørsmål som genuint trenger seks kilder forsonet, er det et røverkjøp for tiden din.

Dette er typen orkestrering vi bygger for klienter hos Techsy, så vi hadde et sterkt forhandsskjønn på hvor det lønner seg og hvor det bare brenner budsjett. Vår vurdering: kjør det på de vanskelige spørsmålene, hopp over det for de enkle.

Slik skriver og lagrer du ditt eget Workflow

For å lage ditt eget workflow, beskriv oppgaven til Claude på vanlig språk med workflow-nøkkelordet, gjennomgå og godkjenn skriptet det genererer, og lagre deretter skriptet som en gjenbrukbar /command. For høyere innsats, sett /effort ultracode og Claude planlegger et workflow på egen hånd. Ingen JavaScript kreves fra deg; Claude skriver skriptet, du godkjenner det.

Her er hele løkken, som også fungerer som trinnene hvis du følger med:

1. Aktiver Dynamic workflows. På Pro, åpne /config og sett på Dynamic workflows-raden. (Du er på v2.1.154+, ikke sant?)

   bash

   /config
   # aktiver deretter "Dynamic workflows"-raden

2. Beskriv oppgaven med workflow-nøkkelordet. Inkluder ordet workflow et sted i prompten din, for eksempel: "Kjør et workflow for å revidere hver rutefil i dette repoen for manglende auth-sjekker." Claude Code fremhever ordet og skriver et skript i stedet for å jobbe tur for tur. Vil du at Claude skal bestemme selv? Sett /effort ultracode, som kombinerer xhigh-resonnering med automatisk workflow-orkestrering for alle vesentlige oppgaver (og brenner flere tokens, så gå tilbake til /effort high for rutinearbeid).

3. Gjennomgå og godkjenn det genererte skriptet. Claude viser deg JavaScript-orkestrasjon før den kjører noe som helst. Les det. Dette er sjansen din til å oppdage en fan-out som er bredere enn du vil ha.

4. Lagre det som en /command for gjenbruk. Når det virker, lagre workflowet som en tilpasset slash-kommando slik at neste kvartalets revisjon er ett tastetrykk.

Gjenbrukbarheten er den stille gevinsten. En engangs /deep-research er hendig, men et lagret workflow for "revider auth på tvers av alle ruter" eller "migrer denne katalogen til det nye API-et" gjør en flertimerslang koordineringsjobb til en enkelt gjentakbar kommando. Det er da tokenkostnaden begynner å amortisere seg over kjøringer i stedet for å svi én gang.

Grenser, kostnad og hvordan du slår Workflows av

Workflows kjører opptil 16 samtidige agenter med et hard tak på 1 000 agenter per kjøring, aksepterer ingen input underveis, og kan bare gjenopptas innen samme sesjon. De er tokenkrevende per design, siden hver agent forbruker kontekst. Du kan deaktivere funksjonen helt med disableWorkflows i config eller miljøvariabelen CLAUDE_CODE_DISABLE_WORKFLOWS.

Hvert av disse grensene betyr noe for oppgaven din. Ingen input underveis betyr at du ikke kan korrigere kursen etter at den starter, så en vag prompt sløser en hel kjøring verdt tokens. Kan bare gjenopptas i samme sesjon betyr at hvis du lukker terminalen, er kjøringen borte. 1 000 agenter per kjøring høres enormt ut, men en bred fan-out til Opus-tier-priser er reelle penger, så behandle standarden på 16 samtidige som en funksjon, ikke et tak å presse.

For å slå det av:

export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# eller sett "disableWorkflows": true i config-filen din

Versjons-problemet snubler folk: hvis /config ikke viser en Dynamic workflows-rad, er du under v2.1.154. Oppdater først. Og hvis du bygger agentpipelines som dette for ordentlig arbeid og vil at de faktisk skal lønne seg, bygger vi agentpipelines for B2B-team. Få en gratis konsultasjon → hvis orkestrering er i ferd med å bli en flaskehals.

Avslutning

Her er hele innlegget på fem linjer. En Claude Code workflow er et JavaScript-skript Claude skriver for å orkestrere subagenter i stor skala, levert som en research preview i v2.1.154. Det eneste som finnes i dag er /deep-research. Du trenger et workflow bare når en oppgave vokser ut av hva én samtale kan koordinere, når du vil ha gjenbrukbar orkestrering, eller når du trenger agenter som krysssjekker hverandre. Vår reelle kjøring kostet ~1M tokens for 9 agenter på 8 minutter, noe som er overkill for enkle spørsmål og verdt det for vanskelig research. Du trenger sannsynligvis ikke ett ennå, og det er greit.

Ofte stilte spørsmål

Hva er en Claude Code workflow?

En Claude Code workflow er et JavaScript-skript som orkestrerer subagenter i stor skala. Du beskriver oppgaven, Claude skriver skriptet, og en runtime kjører det i bakgrunnen mens sesjonen din forblir responsiv. Det er en research preview-funksjon i Claude Code v2.1.154+, tilgjengelig på alle betalte planer.

Hva er forskjellen mellom en workflow og en subagent?

En subagent er én enkelt delegert jobb som kjører i sin egen separate kontekst, koordinert av deg i samtalen. Et workflow er orkestrasjonsskriptet som koordinerer subagenter på én gang, opptil 16 av dem. Hvis én samtale fortsatt kan holde hele planen, bruk en subagent. Hvis planen trenger en runtime for å holde oversikt over agentene, bruk et workflow.

Hvor mye koster en Claude Code workflow i tokens?

I vår målte /deep-research-kjøring forbrente 9 subagenter over 4 faser ca. 1,05 millioner tokens på ca. 8 minutter. Workflows er tokenkrevende per design fordi hver agent forbruker sin egen kontekst, og disse agentene kjører på Opus-tier-modeller. For enkle spørsmål er det sløseri; for genuin flerkildes research tjener det inn kostnaden.

Trenger jeg en betalt plan for å bruke Claude Code workflows?

Ja. Dynamic workflows kjører på alle betalte Claude-planer (Pro, Max, Team, Enterprise) pluss API-et og Bedrock/Vertex/Foundry. Det finnes ingen gratis tilgang. På Pro aktiverer du funksjonen ved å slå på Dynamic workflows-raden i /config etter oppdatering til Claude Code v2.1.154 eller nyere.

Hva er /deep-research i Claude Code?

/deep-research er det ene medfølgende workflowet som følger med i research preview. Du gir det et spørsmål og det sprer subagenter ut for å undersøke emnet parallelt, kjører en krysssjekk-fase der agenter verifiserer hverandres funn, og syntetiserer deretter ett svar tilbake i konteksten din, alt mens det kjører i bakgrunnen.

Hvordan lagrer jeg et workflow som en slash-kommando?

Beskriv oppgaven til Claude med workflow-nøkkelordet, gjennomgå og godkjenn JavaScript-skriptet det genererer, og lagre deretter det godkjente skriptet som en tilpasset /command. Etter det kjører hele multi-agent-jobben med ett tastetrykk, og det er der workflows begynner å amortisere tokenkostnaden over gjentatte kjøringer.

Hvor mange agenter kan et workflow kjøre på én gang?

Et workflow kjører opptil 16 samtidige agenter, med et hard tak på 1 000 agenter per kjøring. Standarden på 16 samtidige eksisterer av god grunn: en bred fan-out til Opus-tier-priser blir kostbart raskt. Behandle grensene som sikkerhetsnett snarere enn mål, og hold fan-outen så smal som oppgaven tillater.

Hvordan slår jeg av Dynamic workflows?

Sett disableWorkflows til true i config-filen din, eller eksporter miljøvariabelen CLAUDE_CODE_DISABLE_WORKFLOWS=1 før du starter Claude Code. Begge slår av funksjonen fullstendig. Hvis du rett og slett ikke ser en Dynamic workflows-rad i /config, er du sannsynligvis under den påkrevde v2.1.154 og må oppdatere først.

Trenger du faktisk Claude Code workflows, eller holder subagenter?

Subagenter holder inntil en oppgave vokser ut av én samtale. En håndfull subagenter koordinert i en vanlig samtale dekker dagligdags arbeid uten tokenkostnad. Du trenger genuint et workflow bare når en oppgave spawner flere agenter enn én samtale kan holde oversikt over, når du vil ha gjenbrukbar orkestrering som kode, eller når du trenger agenter som krysssjekker hverandre adversarialt.