Hvad betyder Agenttilstand?
Agenttilstand, eller agent state, er de oplysninger, som styrer næste trin i et agentforløb. Det kan være opgave-ID, aktiv rolle, kendte input, udvalgte kilder, fejlstatus og nødvendige godkendelser. Tilstanden giver systemet et fælles grundlag for at fortsætte uden at udlede alt fra en lang samtale.
Tilstand er ikke kun hukommelse. Den kan også beskrive, hvad systemet må gøre nu. Et felt som “afventer godkendelse” bør have betydning for, hvilke overgange og værktøjer der er tilladt. Dermed bliver status en del af selve styringen.
Brug felter, der kan kontrolleres
Skeln mellem fakta, udkast og kontroloplysninger. Et svarudkast kan ligge i ét felt, dets kilder i et andet og godkendelsen i et tredje med reference til den godkendte version. Det gør det muligt at opdage, at udkastet er ændret efter review. Hvis alt ligger i en samlet tekststreng, bliver sådanne sammenhænge vanskeligere at håndhæve.
Når flere trin ændrer tilstand samtidig, skal reglerne for samling være tydelige. To grene må ikke stiltiende overskrive hinandens oplysninger. Vælg, hvilke felter der erstattes, hvilke der tilføjes til en samling, og hvilke konflikter der kræver en beslutning.
Gem nok til at fortsætte korrekt
Et checkpoint kan bevare tilstanden, så opgaven kan genoptages efter pause eller nedbrud. Men et gemt felt er ikke automatisk sandt: en ordre kan have ændret status i et eksternt system siden sidst. Ved genoptagelse bør kritiske aktuelle forhold derfor læses igen. Gem referencer og kvitteringer for gennemførte handlinger, og afklar hvordan delvist udførte trin håndteres, så genoptagelse ikke skaber dobbeltvirkninger.
Et eksempel fra praksis
En dokumentagent samler oplysninger til et projektoplæg. Tilstanden angiver, hvilke dokumentversioner der er læst, hvilke krav der har en kilde, og hvilke spørgsmål der står åbne. Hvis processen afbrydes, kan den fortsætte med de manglende dokumenter. Hvis et allerede læst dokument opdateres, markeres de afledte konklusioner til genkontrol. Testen kan ændre én kilde og undersøge, om netop de berørte dele bliver vurderet igen.
Typiske faldgruber
- At bruge en chatbesked som eneste kilde til opgavens status.
- At lade parallelle trin overskrive samme felt uden en konfliktregel.
- At genoptage gamle beslutninger uden at kontrollere ændringer i kildesystemet.
Det skal I afklare
- Definér opgave-ID, statusfelter og lovlige overgange.
- Knyt konklusioner og godkendelser til konkrete versioner.
- Afprøv pause, genstart og ændrede kilder.
Spørgsmål og svar
Skal tilstanden ligge i en database?
Det afhænger af behovet. En kort prøve kan bruge hukommelse, men længere eller driftskritiske opgaver kræver typisk vedvarende lagring for at overleve procesgenstart.
Kan modellen selv bestemme status?
Den kan foreslå en ændring, men vigtige overgange bør valideres. Status “sendt” bør eksempelvis bygge på et bekræftet senderesultat, ikke alene på modellens formulering.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- LangGraph: Graph API ↗Tilstand, noder og betingede overgange.
- LangGraph: Persistence ↗Vedvarende checkpoints og begrænsninger ved hukommelse i RAM.

