Snilld

GLM-5-guide peger på næste skridt fra AI-demo til drift

En ny hands-on tutorial om Z.AI’s GLM-5 samler streaming, thinking mode, tool calling, structured outputs og multi-turn-forløb i ét praktisk byggeforløb. Det gør ikke modellen bevist bedre end konkurrenterne. Men det viser noget vigtigere lige nu: hvordan et agentsystem faktisk kan sættes sammen, så det ligner drift mere end demo.

5. april 2026 Peter Munkholm

Marktechpost har 3. april udgivet en usædvanligt konkret tutorial om Z.AI’s GLM-5. Ikke endnu en modelrundtur med flotte svar på velvalgte prompts, men et forløb der går fra basal opsætning til en multi-tool-agent med streaming, thinking mode, function calling, structured outputs og samtaler over flere trin. Det lyder måske som endnu en udviklerartikel i bunken. Det er det ikke helt.

Grunden er enkel. Mange virksomheder er forbi fascinationsfasen. De spørger ikke længere kun, om en model kan skrive tekst, opsummere et møde eller lave et stykke kode. De spørger, om den kan udføre et stykke arbejde på tværs af systemer, holde styr på kontekst, bruge værktøjer i den rigtige rækkefølge og levere et svar i et format, som resten af forretningen faktisk kan bruge.

Det er præcis dér, tutorialen rammer noget reelt. Ifølge Marktechpost gennemgår den GLM-5 med fokus på virkelige agentiske applikationer, starter med miljøopsætning via Z.AI SDK og en OpenAI-kompatibel grænseflade, og bygger derefter lag på med streaming-svar, thinking mode til dybere ræsonnering, multi-turn-samtaler, function calling og structured outputs. Til sidst ender forløbet i en fuldt funktionel multi-tool-agent drevet af GLM-5. Det er i hvert fald det, kilden viser.

Fra enkeltkald til arbejdsgang

Det interessante er ikke de enkelte funktioner hver for sig. Streaming har vi set før. Tool calling også. Structured outputs lige så. Men i praksis er det sjældent nok, at en model kan én ting isoleret. Det svære er at få kæden til at holde, når brugeren skriver uklart, skifter mening undervejs eller bare forventer svar nu, ikke om 14 sekunder.

Vi har set nok agentdemoer til at vide, hvor kæden plejer at knække. Ikke i første skærmbillede. Det ser næsten altid nydeligt ud. Fejlene kommer i trin tre eller fire, når modellen både skal huske samtalen, vælge et værktøj, kalde det korrekt, parse resultatet og svare tilbage uden at opfinde noget på vejen. Så når en tutorial faktisk samler de byggesten i ét sammenhængende flow, er det mere værd end endnu en liste over benchmarktal.

Marktechposts gennemgang lægger også vægt på, at Z.AI’s økosystem gør det muligt at bygge skalerbare, produktionsklare AI-systemer. Den formulering skal man læse med lidt køligt blod. Det er en påstand i tutorialen, ikke uafhængig dokumentation. Men som signal om retning er den vigtig nok: fokus flytter fra modelshowcase til systemhåndværk.

En bærbar computer med terminaloutput og en udvikler ved tastaturet i et kontormiljø.

Den lidt usexede fordel ved OpenAI-kompatibilitet

Der er en detalje i tutorialen, som ikke er specielt sexet, men som i virkeligheden betyder meget: den OpenAI-kompatible grænseflade. Det lyder som en fodnote. Det er det ikke. For mange teams betyder kompatibilitet mindre omskrivning, hurtigere prototyper og færre mentale gearskift hos udviklere, der allerede arbejder med samme API-mønster.

Banner

Det er den slags, ledelser sjældent klapper af på en scene, men som gør forskellen i et rigtigt projekt. Hvis et team kan genbruge biblioteker, kaldemønstre og testopsætning, falder skifteomkostningen mærkbart. Ikke til nul, selvfølgelig, men nok til at man faktisk gider evaluere en ny model i stedet for bare at tale om det på et møde med for meget filterkaffe og for lidt beslutning.

Konkret viser tutorialen installation af pakkerne zai-sdk og openai, brug af miljøvariablen ZAI_API_KEY til autentificering og initialisering af ZaiClient. Derefter kaldes chat completions med modellen glm-5. Det er lavpraktisk stof, ja, men netop derfor vigtigt. Når en leverandør vil ind i eksisterende udviklerflows, er den slags friktion ofte mere afgørende end endnu et markedsføringsord om intelligens.

Fakta først, for kilden er ret konkret

Kodeeksemplerne i Marktechpost-artiklen er konkrete nok til, at man kan se opbygningen uden at gætte sig frem. Først installeres SDK og hjælpebiblioteker. API-nøglen læses fra ZAI_API_KEY, og hvis den ikke findes, indtastes den via skjult terminalinput med getpass. Derefter initialiseres ZaiClient. Ikke dramatisk. Bare ordentlig opsætning.

Så kommer et almindeligt chat completion-eksempel, hvor klienten kalder client.chat.completions.create med modellen “glm-5”. Prompten beder modellen forklare Mixture-of-Experts-arkitektur i tre sætninger. Efter det viser tutorialen et særskilt streaming-eksempel, hvor tokens sendes løbende tilbage, mens modellen genererer en Python one-liner til primtalstjek. Det er værd at nævne, fordi streaming i praksis ofte er forskellen på et system, der føles responsivt, og et system der føles som om det tænker i kælderen.

Derfra bevæger forløbet sig videre til thinking mode. Kilden beskriver det som en måde, hvor GLM-5 kan eksponere intern ræsonnering før et endeligt svar, især til matematik, logik og komplekse kodeopgaver. Her skal man lige holde tungen lige i munden. Tutorialen viser funktionen og dens tiltænkte brug. Den dokumenterer ikke i sig selv, at den altid giver bedre svar i drift. Det er en vigtig forskel, og den bliver tit sjusket væk i dækningen af nye modeller.

Når noget bliver agentisk og ikke bare interaktivt

Lad os være ærlige. Alt for mange kalder en chatbot med ét API-kald for en agent. Det er det sjældent. En agentisk arbejdsgang begynder først at ligne noget, når modellen kan operere over flere trin, holde styr på samtalen, vælge blandt værktøjer og levere et resultat, der kan bruges videre uden menneskelig oprydning bagefter.

Det er netop kombinationen af thinking mode, multi-turn-samtaler og function calling, der gør tutorialen mere interessant end en pæn promptdemo. Multi-turn betyder, at samtalen kan udvikle sig, og at systemet skal kunne bevare relevant kontekst. Tool calling betyder, at modellen ikke kun svarer med ord, men kan aktivere funktioner eller systemhandlinger. Structured outputs betyder, at resultatet kan bindes op på et forventet format i stedet for at komme som en løs tekstklump, der bagefter skal lirkes ind i et workflow med tape og håb.

Og så er der streaming ovenpå. Det lyder som pynt, men det er det ikke. I mange arbejdsgange er oplevet hastighed næsten lige så vigtig som faktisk hastighed. Brugeren vil se, at der sker noget. Et system, der svarer gradvist og tydeligt, får ofte mere tillid end et system, der tænker tavst og så afleverer noget sent og lidt for selvsikkert.

Tre medarbejdere diskuterer et systemflow på en stor skærm i et mødelokale.

Det tutorialen ikke beviser

Her kommer det kedelige, men nødvendige forbehold. Marktechpost er primært en tutorialkilde, og artiklen dokumenterer først og fremmest arbejdsgange, API-brug og funktionsomfang. Den viser ikke uafhængige benchmarks for robusthed, pris, svartider under belastning eller fejlprocenter i produktion. Vi får heller ikke cases fra virksomheder, der har kørt GLM-5-agenter i stor skala over tid.

Banner

Derfor skal man passe på med den hurtige oversættelse fra “kan bygges sådan her” til “er bevist produktionsklar i vores miljø”. Det er ikke det samme. Påstanden om skalerbare, produktionsklare systemer kommer fra tutorialen selv. Z.AI’s egen blog placerer også GLM-5 som en model rettet mod komplekse system engineering-opgaver og langsigtede agentiske opgaver, men heller ikke leverandørens egen positionering er det samme som neutral validering.

Det gør ikke kilden ubrugelig. Tværtimod. Den er nyttig, fordi den viser byggeklodserne klart. Men hvis man sidder med ansvar for drift, compliance eller bare et budget, så mangler der stadig dokumentation, før man kan kalde noget afgjort. Den sunde skepsis er ikke en bremseklods her. Den er bare almindelig voksenadfærd.

Hvor det bliver relevant for danske virksomheder

For danske produktfolk og tekniske ledere er nyheden ikke, at endnu en model kan tale med værktøjer. Nyheden er, at tutorialen samler et mønster, som mange virksomheder faktisk mangler lige nu: broen fra demo til drift. Ikke magi. Håndværk. En måde at sætte et system sammen på, så det kan håndtere mere end én prompt og ét svar.

Det kan for eksempel være intern support, hvor en assistent både skal kunne læse dokumentation, slå op i et system og returnere svaret i et fast format, så sagen kan oprettes korrekt. Eller sagshåndtering på tværs af systemer, hvor modellen først skal afklare brugerens hensigt, derefter kalde et værktøj og til sidst levere et struktureret output tilbage til et workflow. Pointen står ret tydeligt: værdien ligger i kæden, ikke i chatvinduet.

Et tredje spor er research-agenter. Ikke de flamboyante, der lover at “analysere hele markedet”, men de mere jordnære, der skal hente oplysninger, holde kontekst over flere trin og aflevere et svar i et bestemt skema eller JSON-format. Det lyder småt. Det er ofte dér, gevinsten faktisk starter. Ikke i science fiction, men i mindre bøvl.

GLM-5 i et marked, der flytter sig

GLM-5 står ikke alene i den bevægelse. På tværs af markedet prøver modelleverandører at vinde på udvikleroplevelse, integrationsmønstre og agentegenskaber, ikke kun på rå modelscore. Det er en vigtig ændring. For de fleste virksomheder er den bedste model på papiret ikke automatisk den bedste model i drift, hvis den er tung at integrere, svær at styre eller kræver særbehandling overalt i stakken.

Sådan læst er GLM-5-tutorialen også et tegn på, hvad konkurrencen nu handler om. Ikke bare om hvem der har højeste score i en tabel, men om hvem der gør det lettest at bygge noget, der kan overleve mødet med virkeligheden. Og virkeligheden er som bekendt usexet. Den består af dårlige input, halve instrukser, systemer der svarer langsomt, og brugere der skriver “virker ikke” uden yderligere detaljer.

Vi har ikke kilder til at sige, at GLM-5 er bedre end OpenAI, Anthropic eller Google på agentiske opgaver samlet set. Det ville være for smart, og der er ikke belæg for det her. Men vi har belæg for at sige, at tutorialen gør én ting rigtigt: den flytter opmærksomheden fra modelmagi til systemdesign. Det er mere nyttigt, end det måske lyder.

Nærbillede af en skærm med kode og strukturerede data i et kontor om aftenen.

Det vigtigste at tage med

Hvis man skærer historien ind til benet, er pointen ikke, at GLM-5 pludselig løser agentproblemet. Det gør ingen model alene. Pointen er, at Marktechposts tutorial viser et sammenhængende mønster for, hvordan man kan bygge et agentsystem, der opfører sig nogenlunde fornuftigt i praksis: klare værktøjsgrænser, samtaler over flere trin, strukturerede outputformater og responsivitet undervejs.

Det er også derfor, nyheden er mere relevant, end overskriften måske antyder. For den passer ind i det, mange virksomheder tumler med lige nu: hvordan man går fra en lovende demo til noget, der faktisk kan indgå i en arbejdsgang uden konstant babysitting. Der er stadig åbne spørgsmål om robusthed, pris og drift. Helt sikkert. Men retningen er svær at overse.

Så ja, hold igen med hype. Men lad også være med at reducere agentiske systemer til PowerPoint og røgmaskine. Det her begynder at ligne byggevejledninger til rigtige workflows. Forskellen bliver tydelig, når man sidder med det i hænderne.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?