AI-agenter, der bygger og udruller rigtig software: Inde i Jobbits arkitektur

De fleste "AI-agenter" stopper ved samtalen. De svarer, og så udfører et menneske selve arbejdet. Den interessante — og oprigtigt svære — tekniske udfordring er at bygge agenter, der udfører arbejdet: skriver en fuld-stack-applikation, kører den, retter deres egne fejl og udruller den i produktion. Det er den udfordring, ingeniørteamet hos Jobbit og dets R&D-division, Jobbit Labs (jobbitlabs.com), arbejder med hver eneste dag.

Dette indlæg er et teknisk dybdedyk i mønstrene bag AI-agenter, der bygger og udruller software — arkitekturen, fejltilstandene og erfaringerne. Det er bevidst praktisk og uafhængigt af leverandør: uanset om du bygger på LLM'er, multi-agent-orkestrering, tool calling eller RAG, kan principperne overføres.

Chatbots svarer; agenter handler

Springet fra en chatbot til en agent er springet fra at generere tekst til at udføre handlinger i verden. En agent skal planlægge en opgave i flere trin, kalde værktøjer, læse resultaterne og beslutte, hvad den skal gøre derefter — og så gentage det, indtil målet er nået. Den løkke, ofte kaldet den agentiske løkke (eller reason–act-løkken), er hjertet i systemet.

Den tekniske udfordring er, at hvert trin kan fejle. Modellen kan hallucinere en funktion, der ikke findes, skrive kode, der ikke kompilerer, fejllæse et værktøjs output eller stille og roligt drive væk fra opgaven. En chatbot, der tager fejl, producerer en dårlig sætning; en agent, der tager fejl, producerer en ødelagt deploy. Pålidelighed, ikke rå kapacitet, er det egentlige ingeniørarbejde.

Arkitekturen: planlægger, eksekvering, værktøjer

En robust agentplatform adskiller planlægning fra eksekvering. Et planlægningslag dekomponerer et mål ("byg en bookingapp med betalinger") til konkrete trin; et eksekveringslag udfører hvert trin ved hjælp af værktøjer (tools). At holde disse to ting adskilt gør systemet nemmere at fejlsøge: du kan inspicere planen uafhængigt af, hvordan hvert trin blev kørt.

Tool use er der, hvor en agent får sine hænder. Værktøjer er veldefinerede funktioner, som modellen kan kalde — læse en fil, skrive kode, køre et build, forespørge en database, udrulle. Den tekniske disciplin her er interfacedesign: hvert værktøj har brug for et stramt, utvetydigt skema, validerede input og strukturerede output, som modellen pålideligt kan parse. Løse værktøjsgrænseflader er en af de største kilder til agentfejl; stramme er den billigste gevinst i pålidelighed, der findes.

Til komplekse opgaver viger en enkelt agent ofte for multi-agent-orkestrering — specialiserede agenter, der planlægger, skriver kode, reviewer og verificerer, koordineret af en orkestrator. Dekomponering køber dig fokus (hver agent har en snæver opgave og en snæver kontekst) og parallelisme (uafhængige delopgaver kører samtidig). Afvejningen er koordineringsomkostninger, så orkestreringslaget skal være deterministisk, hvor det kan være det, og modstandsdygtigt, hvor det ikke kan.

At køre og udrulle rigtig kode — sikkert

En agent, der skriver software, skal køre den software — og at køre modelgenereret kode er et sikkerhedsproblem, før det er noget som helst andet. Svaret er sandboxet kodekørsel: kode, der ikke kan stoles på, kører i et isoleret miljø med begrænsede ressourcer, ingen adgang til hemmeligheder og stramme netværksgrænser. Sandboxen er det, der lader en agent iterere — kompilere, teste, læse fejlen, rette — uden at sætte platformen eller andre brugere på spil.

Deployment er det trin, der forvandler en genereret app til et produkt. En rigtig AI-app-builder ejer vejen fra kode til en live-URL: build, provisionering af hosting, tilknytning af domæne, terminering af TLS. At lave det godt teknisk betyder at gøre deploys gentagelige og reversible — de samme input giver det samme resultat, og en dårlig deploy kan rulles tilbage. Idempotens og ren rollback er ikke prangende, men det er det, der gør autonom deployment til at stole på.

Kontekst, hukommelse og retrieval

LLM'er har begrænset kontekst, og rigtige projekter passer ikke ind i den. Derfor investerer et seriøst agentsystem kraftigt i context engineering: at beslutte, hvad modellen ser ved hvert trin. At proppe alt ind i prompten er både dyrt og kontraproduktivt — for meget irrelevant kontekst forringer ræsonnementet.

Det er her, RAG (retrieval-augmented generation) og vektordatabaser gør sig fortjent til deres plads. I stedet for at dumpe en hel kodebase ind i konteksten henter systemet de få filer, symboler eller dokumenter, der er relevante for det aktuelle trin. Kombineret med struktureret hukommelse — en optegnelse over beslutninger, den udviklende specifikation og hvad der allerede er forsøgt — holder retrieval agenten jordforbundet gennem en lang opgave uden at sprænge kontekstvinduet. God retrieval er ofte et større kvalitetsgreb end en større model.

Pålidelighed: evals, verifikation og guardrails

Hvis der er én idé, der adskiller produktionsklar agent-engineering fra demoer, er det denne: du kan ikke udrulle det, du ikke kan måle. Agentiske systemer er stokastiske, så pålidelighed bygges gennem evals — automatiserede testsuiter, der scorer agenten på repræsentative opgaver og fanger regressioner, før brugerne gør det. En ændring, der "føles bedre", men sænker dine eval-scorer, er en ændring, du ikke udruller.

Oven på evals ligger runtime-guardrails og verifikation. Det mest effektive mønster er adversariel selvkontrol: efter en agent producerer et resultat — et stykke kode, en plan, en rettelse — forsøger et separat verifikationspas at modbevise det. Kompilerer koden? Består testene? Matcher outputtet skemaet? At behandle verifikation som et særskilt, skeptisk trin fanger en stor andel af de fejl, som et enkelt selvsikkert pas ville overse. Genforsøg med backoff, circuit breakers og eskalering til mennesker håndterer resten.

Observability, du kan fejlsøge

Når et autonomt system træffer dusinvis af beslutninger pr. opgave, har du brug for at kunne se dem. Observability — struktureret tracing af hver prompt, hvert værktøjskald og hvert resultat — er ikke til forhandling. Når en agent går galt, er tracen måden, hvorpå du finder det præcise trin, der drev af, reproducerer det og retter rodårsagen. Ingeniørteams, der behandler agent-traces som førsteklasses telemetri, fejlsøger på minutter; teams, der ikke gør det, fejlsøger på dage.

Edge og elastisk skalering

Agent-workloads er stødvise og latensfølsomme, hvilket gør edge computing til et naturligt valg. At køre tæt på brugerne — på platforme som Cloudflare Workers og edge-datalagre — skærer round-trip-latens ned og skalerer elastisk med efterspørgslen. Jobbit Labs læner sig op ad denne edge-first-tilgang til dele af sin data- og produktinfrastruktur: globalt distribueret, autoskalerende og betal-for-hvad-du-bruger, så kapaciteten følger belastningen i stedet for at stå ubenyttet hen.

Human-in-the-loop-laget

Det sidste stykke af arkitekturen er det, de fleste agentplatforme mangler: en human-in-the-loop-vej. AI håndterer volumen og hastighed, men nogle beslutninger — sikkerhedsfølsom logik, juridisk ordlyd, designvurdering — hører til hos et menneske. At lave dette teknisk betyder at bygge rene overdragelsespunkter, hvor en vetteret menneskelig ekspert kan træde ind, med escrow, der beskytter transaktionen. Agenten og det menneskelige netværk er ikke konkurrerende lag; de er en indbygget fallback, der gør hele systemet trygt at stole på.

Erfaringer til ingeniører, der bygger agenter

Hvis du bygger agentiske systemer, betaler nogle få principper investeringen tilbage mange gange.

Design stramme værktøjsgrænseflader. De fleste agentfejl kan spores tilbage til tvetydige værktøjer. Strikse skemaer og valideret I/O er den billigste pålidelighed, du nogensinde køber.

Verificér adversarielt. Stol ikke på et selvsikkert første pas. Tilføj et separat trin, hvis opgave er at modbevise resultatet.

Mål med evals. Byg eval-harnesset, før du skalerer agenten. Du kan ikke forbedre det, du ikke kan score.

Engineer konteksten, dump den ikke. Hent det relevante; husk det vigtige. Større prompts er ikke bedre prompts.

Sandbox alt, der ikke kan stoles på. Hvis en agent kører kode, er isolation en forudsætning, ikke en feature.

Bevar en menneskelig vej. Det sikreste autonome system er ét, der ved, hvornår det skal spørge et menneske.

Ofte stillede spørgsmål

Hvad gør en AI-agent anderledes end en chatbot?

En chatbot genererer tekst; en AI-agent planlægger og udfører handlinger — kalder værktøjer, kører kode og itererer mod et mål. Den tekniske vanskelighed er pålidelighed på tværs af mange trin, hvor en enkelt fejl kan ødelægge resultatet.

Hvordan kører man AI-genereret kode sikkert?

Med sandboxet kodekørsel: kode, der ikke kan stoles på, kører i et isoleret miljø med begrænsede ressourcer, ingen adgang til hemmeligheder og begrænset netværk, så agenten kan kompilere, teste og rette uden risiko for platformen.

Hvorfor er evals så vigtige for agentsystemer?

Fordi agenter er stokastiske, har du brug for automatiserede evals til at måle kvaliteten på repræsentative opgaver og fange regressioner, før du udruller. Uden dem er "forbedringer" gætterier.

Hvad laver Jobbit Labs?

Jobbit Labs (jobbitlabs.com) er R&D- og datadivisionen bag Jobbit, fokuseret på den tungere, dataintensive og enterprise-rettede engineering — forskning, dataplatforme og de agent-fundamenter, produktet er bygget på.

Nysgerrig efter ingeniørarbejdet bag agenter, der udruller software? Udforsk jobbit.uk og jobbitlabs.com.