Agent graphs gør autonomi til noget, du kan styre.
Sådan designer du agentsystemer, der kan vælge vej, huske, pause og arbejde parallelt - uden at miste kontrollen.
Brug ikke en agent graph for at give systemet mest mulig frihed. Brug den til at gøre friheden tydelig, begrænset og målbar.
“Agent graphs” er ikke én standard. Begrebet bruges både om et arkitekturmønster og som produktnavn. Her handler det om mønsteret: en directed graph over eksplicit Strukturerede arbejdsdata for ét run. Nodes læser state og returnerer eksplicitte state updates., hvor nodes udfører arbejde, og edges bestemmer, hvad der sker bagefter.
Et agent graph bliver relevant, når et flow skal kunne vælge næste edge med Valget af næste edge. Det kan ske med kode, en typed classifier eller - ved reel semantisk tvetydighed - en model., køre branches parallelt, pause, vente på human approval og fortsætte efter en fejl. Det er ikke en genvej til mere autonomi. Det er en måde at holde autonomien under kontrol.
Alle agenter starter som et loop.
Tænk, handl, observér. Gentag, indtil opgaven er løst. Loopet er det simpleste agent-design, og det rækker langt - i en kortlægning af 70 open source-agentprojekter kørte 6 ud af 10 stadig det rene loop. Men strukturen har tre indbyggede svagheder.
Implicitte dependencies
Afhængigheder mellem steps lever kun i context-vinduet. Modellen skal selv huske dem.
I en graph: eksplicit stateUbegrænset recovery
Et retry har ingen indbygget stopmekanisme. Det brænder tokens, indtil vinduet er fuldt.
I en graph: termination conditionsMutérbar historik
Execution history er bare tekst i et context-vindue. Ikke struktureret, ikke auditerbar.
I en graph: checkpoints og tracesForskellen på et loop og en graph er scheduleren. I et loop er højst én enhed klar ad gangen, og modellen vælger implicit næste skridt. I en graph kan flere enheder være klar samtidig, og valget af næste step er en eksplicit politik, du kan inspicere og teste.
En graph erstatter derfor ikke loops. Hver node kører stadig sit eget lille loop. Grafen bestemmer, hvordan arbejdet flyder mellem dem, hvordan resultater merges, og hvornår systemet stopper.
Et agent graph består af fire ting.
Tænk på et agent graph som et workflow med memory. Nodes gør arbejdet. Edges vælger næste step. State holder styr på det, systemet ved. Runtime får det hele til at køre.
Nodes gør arbejdet
En node kan være almindelig kode, en model, et tool, en evaluator eller human input.
Edges vælger næste step
En edge sender arbejdet videre i en fixed sequence, efter en condition eller ud i flere branches.
State holder styr på runnet
State er de typed data, som nodes læser og opdaterer gennem hele runnet.
Runtime holder systemet ærligt
Runtime scheduler nodes, håndterer failures, gemmer checkpoints og terminerer runnet, når den skal.
Hvem skal vælge den næste edge?
Model classifier. Brug kun modellen, når valget kræver semantisk forståelse.
Fem graph patterns dækker næsten alt.
Parallel fan-out
- Brug når
- Uafhængige kilder undersøges samtidig. Resultaterne samles i et join.
- Kontrollen ligger hos
- Runtime og eksplicit join semantics.
- Pas på
- Lavere ventetid betyder ikke lavere tokenforbrug.
Fire slags state. Hold dem adskilt.
- 01
Run state
Typed arbejdsdata, der kun hører til det aktuelle run.
- 02
Thread state
Short-term memory og den checkpoint position, som threaden kan fortsætte fra.
- 03
Long-term memory
Brugerfakta og applikationsdata, der må leve på tværs af runs.
- 04
Runtime context
Identitet, tenant, credentials og deadlines. Det skal ikke automatisk ind i model context.
Se to state deltas blive merged
Deterministisk. Begge state deltas bliver merged af en deklareret reducer.
Et loop uden termination conditions er en produktionsfejl.
En eksplicit success condition
Et maksimalt antal iterations
En deadline
Et token- og cost budget
No-progress detection
En human escalation path
Uden de termination conditions kan et agent graph blive ved med at køre, gentage den samme fejl og bruge flere penge. Autonomi uden termination er bare et system, der ikke ved, at det har fejlet.
Hvor mange iterations må loopet bruge?
Loopet lykkes efter 3 iterations. Senere iterations bliver aldrig kørt.
Design til fejl, før du designer til skalering.
Et Et versionsbundet snapshot af state og ventende arbejde, som runtime kan genoptage efter en pause eller fejl. er et snapshot af ét runs state. Memory er data, der lever på tværs af runs. De løser to forskellige problemer. Bland dem ikke sammen, og læg aldrig credentials eller secrets i graph-state.
Når et run fortsætter efter en pause, kan den samme node blive kørt igen. Alle side effects skal derfor kunne tåle replay. Brug idempotency keys, deduplication eller en eksplicit compensation path.
Giv hver node så få permissions som muligt. Validér tool input ved execution. Gem state før en pause. Tjek permissions igen, når runnet fortsætter.
Approve før side effect
Paused. Ingen side effect er udført endnu.
Når runnet fortsætter, skal authorization og den aktuelle side effect valideres igen.
Diagrammet er den nemme del.
State schema, node contracts, edges og tydelige start- og end points
Routing, parallel fan-out, retries, loops og termination rules
Checkpoints, memory og en sikker recovery path efter fejl eller pauser
Permissions, approvals, budgets, guardrails og en kill switch
Traces, evals, alerts, versioning og migration af eksisterende runs
Vælg runtime efter den sværeste del af systemet.
Start med én agent.
Giv den få, tydelige tools. Introducér kun specialister, når de har reelt forskellige data, værktøjer, instruktioner eller evalkriterier.
Et agent graph betaler sig gennem kontrol, sporbarhed og driftssikkerhed. Ikke gennem antallet af nodes i diagrammet.
Se LangGraph-dokumentationen