Introduction Introduktion I første omgang, du bare forsøge at kommunikere med ChatGPT via API, kaste i et par linjer af kontekst, og føle sig forbløffet over, at det reagerer overhovedet. Sådan er en agent født. Hvis du også har brugt det sidste år til at koble agenter sammen fra scripts og emballager, eksperimentere og tinkering, og du stadig leder efter en renere, mere bæredygtig måde at opbygge dem på - denne artikel er for dig. Tænk på det som et praktisk cheat sheet - en samling af ingeniørprincipper, der hjælper med at guide en agent fra sandkassen til produktion: fra en simpel API-emballage til et stabilt, kontrollerbart og skalerbart system. Disclaimer i (Building Effective Agents), Anthropic definerer en agent som et system, hvor LLM'er dynamisk styrer deres egne processer og brug af værktøjer og opretholder kontrol over, hvordan de udfører opgaver. Denne artikel I denne tekst, Agent = Agent system, hvor for stabilitet og kontrol vil jeg oftere læne sig til Workflows. jeg håber, at i den nærmeste fremtid vil der være 1-2 flere omgange af evolutionen og sande Agenter vil være overalt, men for nu er dette ikke tilfældet 1. Design the Foundation 1) Design af stiftelsen Tidlige versioner af agenter kommer normalt sammen hurtigt: et par funktioner, et par opfordringer - og hey, det virker. Tidlige versioner af agenter kommer normalt sammen hurtigt: et par funktioner, et par opfordringer - og hey, det virker. “If it works, why make it complicated?” I begyndelsen af alt Agenten reagerer, kører kode, opfører sig fornuftigt, men når du skifter model, genstarter systemet eller tilslutter en ny grænseflade, bliver det pludselig ustabilt, uforudsigeligt, svært at debugge. synes Og ofte ligger roden ikke i logikken eller opfordringerne, men meget tidligere: brudt hukommelseshåndtering, hardcodede medarbejdere, ingen måde at genoptage sessioner på eller et enkelt stivt indgangspunkt. Denne sektion går gennem fire nøgleprincipper, der vil hjælpe dig med at opbygge et solidt fundament - et, som alt andet sikkert kan vokse på toppen af. 1. Keep State Outside Problem: Hvis agenten bliver afbrudt (en crash, en timeout, hvad som helst), skal det være i stand til at afhente nøjagtigt, hvor det stoppede. Du har brug for en måde at præcist reproducere, hvad der skete - til test, debugging og andre sådanne fornøjelser. Dette er ikke strengt et problem, men alligevel: Parallelisering. Før eller senere vil du ønsker at parallelisere agentens logik. Måske det har brug for at sammenligne flere muligheder midt i dialogen (“Hvilken af disse er bedre?”). Måske du vil have det til at grene. (Memory er et helt separat problem - vi kommer til det snart) Flyt staten agenten - ind i en database, en cache, et lagringsniveau - selv en JSON-fil vil gøre. Solution: outside Checklist: Agent kan startes fra ethvert trin, med kun en session_id – session-identifikatoren – og ekstern tilstand (f.eks. gemte trin i en database eller JSON-fil). Testsager: en afbrudt agent mister ikke kontekst, efter genstart er resultatet det samme Staten kan serialiseres til enhver tid uden tab af funktionalitet Du kan føje tilstanden til flere instanser parallelt midt i en dialog 2. Make Knowledge External : LLMs husker ikke. Selv inden for en enkelt session kan modellen glemme, hvad du allerede har forklaret, blande trin, miste samtaletråden eller begynde at "fylde" detaljer, der ikke var der. Og det ser ud til, at tiden går, kontekstvinduet vokser større og større, glæder os med nye muligheder. LinkedIn er fuld af indlæg, hvor folk sammenligner, hvilken bog eller hvor mange timer af YouTube-video nu passer ind i den nye modelversion. Problem Især hvis: Dialogen er lang Dokumenterne er store Instruktioner er komplekse og tokens er stadig ikke uendelige Selv med stigende kontekstvinduer (8k, 16k, 128k...), problemer forbliver: "Lost in the middle" - modellen betaler mere opmærksomhed til begyndelsen og slutningen (og kan løsne detaljer fra midten) Omkostninger – flere tokens = flere penge Det betyder, at der vil være tab, forvrængning eller hallucinationer. Så længe transformatorer arbejder på selvopmærksomhed med kvadratisk kompleksitet (O(n2)), vil denne begrænsning være med os. At skille "arbejdshukommelse" fra "opbevaring" - som i klassiske computersystemer. agenten skal være i stand til at arbejde med ekstern hukommelse: gemme, hente, opsummere og opdatere viden uden for modellen. Solution: Approaches Memory Buffer Sælger den sidste Få en hurtig prototype. k Nemt, hurtigt og tilstrækkeligt til korte opgaver + mister vigtige oplysninger, ikke skalerer, husker ikke "i går" - Summarization Memory Komprimer historie for at passe mere. Token besparelser, hukommelsesudvidelse + forvrængninger, tab af nuancer, fejl i multi-trins kompression - RAG (Retrieval-Augmented Generation) Trækker viden fra eksterne databaser. Det meste af tiden vil du være her. Skalerbar, frisk og kontrollerbar + Kompliceret opsætning, følsom over for hentningskvalitet, latens - Knowledge Graphs Altid elegant, sexet og hårdt, vil du ende med at gøre RAG alligevel. Logik, forklaringsevne og stabilitet + høj barriere for adgang, kompleksitet af LLM integration - Checklist: Hele samtalehistorikken er tilgængelig på ét sted (uden for prompt) Kendskabskilder logges og kan genbruges Historiske skalaer uden risiko for at overskride kontekstvinduet 3. Model as a Config LLM'er udvikler sig hurtigt; Google, Anthropic, OpenAI osv. udgiver konstant opdateringer, der konkurrerer mod hinanden på tværs af forskellige benchmarks. Dette er en fest for os som ingeniører, og vi ønsker at få mest muligt ud af det. Problem: Solution: Implementer model_id-konfiguration: Brug en model_id-parameter i konfigurationsfiler eller miljøvariabler til at angive den model, der anvendes. Brug abstrakte grænseflader: Opret grænseflader eller indpakningsklasser, der interagerer med modeller gennem et forenet API. Anvend middleware-løsninger (forsiktigt - vi vil tale om rammer lidt senere) Checklist: Udskiftning af model påvirker ikke resten af koden og påvirker ikke agentfunktionalitet, orkestrering, hukommelse eller værktøjer. Tilføjelse af en ny model kræver kun konfiguration og, valgfrit, en adapter (et simpelt lag, der bringer den nye model til det krævede interface) Du kan nemt og hurtigt skifte modeller. Ideelt set – alle modeller, i det mindste – skift inden for en modelfamilie 4. One Agent, Many Interfaces: Be Where the Users Are Selvom agenten oprindeligt er beregnet til kun at have et kommunikationsgrænseflade (for eksempel brugergrænseflade), vil du i sidste ende ønsker at give brugerne mere fleksibilitet og bekvemmelighed ved at tilføje interaktion gennem Slack, WhatsApp eller, tør jeg sige det, SMS - hvad som helst. Problem: Udvikle en API eller anden mekanisme, der vil tjene som et universelt interface for alle kanaler. Solution: Creating a unified input contract Checklist: Agent is callable from CLI, API, UI All input goes through a single endpoint/parser/schema All interfaces use the same input format No channel contains business logic Adding a new channel = only an adapter, no changes to core Definere agent adfærd Mens der kun er én opgave, er alting simpelt, som i AI-evangelisternes indlæg.Men så snart du tilføjer værktøjer, beslutningstagningslogik og flere trin, bliver agenten til et rod. Mens der kun er én opgave, er alting simpelt, som i AI-evangelisternes indlæg.Men så snart du tilføjer værktøjer, beslutningstagningslogik og flere trin, bliver agenten til et rod. Det mister spor, ved ikke, hvad man skal gøre med fejl, glemmer at ringe til det rigtige værktøj - og du er tilbage alene igen med logs, hvor "ja, alt synes at være skrevet der." For at undgå dette, har agenten brug for en klar Hvad det gør, hvilke værktøjer det har, hvem der træffer beslutninger, hvordan mennesker griber ind, og hvad man skal gøre, når noget går galt. behavioral model Dette afsnit dækker principper, der vil hjælpe dig med at give din agent en sammenhængende handlingsstrategi i stedet for at håbe "modellen vil finde ud af det på en eller anden måde." 5. Design for Tool Use Dette punkt kan synes indlysende, men du støder stadig på agenter bygget på "Plain Prompting + rå LLM output parsing." Det er som at forsøge at kontrollere en kompleks mekanisme ved at trække tilfældige strenge og håbe på det bedste. Problem: Brittleness: Den mindste ændring i LLM respons formulering (et ord tilføjet, sætning rækkefølge ændret) kan bryde hele parsing. Tvetydighed: Det naturlige sprog er iboende tvetydigt.Det, der synes indlysende for et menneske, kan være et puslespil for en analytiker. "Call John Smith" - hvilken af de tre John Smiths i din database? Vedligeholdelseskompleksitet: Parsing-kode vokser, bliver forvirret og vanskelig at debugge. Begrænsede muligheder: Det er svært at gøre modellen pålideligt at kalde flere værktøjer eller passere komplekse datastrukturer gennem simpel tekstudgang. Modellen returnerer JSON (eller et andet struktureret format) – systemet udfører. Solution: Det afgørende her er, at ansvaret for brugerens hensigt og værktøjer til LLM, mens du stadig tildeler Af denne hensigt til den Gennem et klart defineret system. fortolkning Vælger Eksekvering Systemet Heldigvis understøtter stort set alle udbydere (OpenAI, Google, Anthropic eller hvem du foretrækker) såkaldt eller evnen til at generere output i et strengt defineret JSON-format. "function calling" Bare for at forklare, hvordan det fungerer: Værktøjsbeskrivelse: Du definerer funktioner (værktøjer) som JSON Schema med navn, beskrivelse, parametre. Overgang til LLM: På hvert opkald modtager modellen værktøjsordninger sammen med prompt. Instead of text, the model returns JSON with: Model output: name of the function to call arguments—parameters according to schema Kode validerer JSON og kalder den relevante funktion med parametre. Model respons (valgfrit): Eksekveringsresultatet sendes tilbage til LLM for endelig responsgenerering. Værktøjsbeskrivelser er også prompts. uklar beskrivelse = forkert funktion valg. Important: What to do without function calling? Hvis modellen ikke understøtter værktøjsopkald, eller du vil undgå dem af en eller anden grund: Spørg modellen om at returnere JSON i prompt. Sørg for at angive formatet; du kan tilføje eksempler. Analysér svaret og valider det med noget som Pydantic. Der er rigtige fans af denne tilgang. Checklist: Response is strictly formalized (e.g., JSON) Skemaer anvendes (JSON Schema eller Pydantic) Validering anvendes før funktionsopkald Genereringsfejl forårsager ikke brud (formatfejlhåndtering eksisterer) LLM = funktion valg, udførelse = kode 6. Own the Control Flow Normalt agenter fungerer som "dialoger" - først bruger taler, så agenten reagerer.Det er som at spille ping-pong: hit-respons. Problem: Such an agent cannot: Gør noget selv uden en anmodning Udførelse af aktiviteter parallelt Planlæg skridt i forvejen Tag flere trin i rækkefølge Tjek fremskridt og vende tilbage til fejlagtige trin I stedet skal agenten styre sin egen "execution flow" - beslutte, hvad der skal gøres næste og hvordan man gør det. This means the agent: Bestemmer, hvornår man skal gøre noget selv Kan tage skridt efter skridt Kan genskabe mislykkede skridt can switch between tasks Kan arbejde selv uden direkte anmodninger I stedet for at lade LLM kontrollere al logik, udtrækker vi Modellen hjælper kun inden for trin eller foreslår den næste. med en kontrolleret adfærd. Solution: control flow engineering a system Lad os se på tre populære tilgange: 1. FSM (Finite State Machines) Task broken down into states and clear transitions. What it is: LLM: Bestemmer det næste skridt eller handler inden for en stat. Fordele: Enkelhed, forudsigelighed, god til lineære scenarier. StateFlow, YAML configurations, State Pattern. Tools: 2. DAG (Directed Graphs) Ikke-lineære eller parallelle opgaver som et diagram: knuder er handlinger, kanter er afhængigheder. LLM: Kan være en knudepunkt eller hjælp med planlægning. Fordele: Fleksibilitet, parallelisme og visualisering. Værktøjer: LangGraph, Trellis, LLMCompiler, brugerdefinerede DAG-diagrammer. 3. Planner + Executor Hvad det er: LLM bygger en plan, kode eller andre agenter udføre det. LLM: "Big" en planer, "små" dem udføre. Fordele: Separation af bekymringer, omkostningskontrol, skalerbarhed. Værktøjer: LangChain Plan-and-Execute Why this matters: Øger kontrol, pålidelighed og skalerbarhed. Det giver mulighed for at kombinere forskellige modeller og fremskynde udførelsen. Taskflowet bliver visualiserbart og testbart. Checklist: Brug af FSM, DAG eller scenario med eksplicitte overgange Model beslutter, hvad der skal gøres, men kontrollerer ikke strømmen Behavior can be visualized and tested Fejlhåndtering er indbygget i strømmen 7. Include the Human in the Loop Selv hvis en agent bruger strukturerede værktøjer og har en klar kontrolstrøm, er fuld autonomi af LLM-agenter i den virkelige verden stadig mere af en drøm (eller mareridt, afhængigt af konteksten). LLM'er besidder ikke sand forståelse og er ikke ansvarlige for noget. Problem: Main risks of full autonomy: The agent might perform actions with serious consequences (delete data, send an incorrect message to an important client, start a robot uprising). Permanent mistakes: Overtrædelser af overensstemmelse: Agenten kan ved et uheld overtræde interne regler, juridiske krav eller såre brugerens følelser (hvis det ikke var planen, skal du ignorere dette punkt). Mangel på sund fornuft og etik: LLM'er kan gå glip af sociale nuancer eller handle imod "almindelig fornuft". Tab af brugertillid: Hvis agenten begår hyppige fejl, vil brugerne stoppe med at stole på den. Revision og ansvarlighed kompleksitet: Hvem har skylden, når en selvstændig agent "skruer op"? Integrere mennesker i beslutningsprocessen i centrale faser. Solution: Strategisk indkaldelse af kulstofbaserede livsformer HITL Implementation Options 1. Approval Flow Hvornår: handling er kritisk, dyrt, irreversibelt Hvordan: Agent formulerer et forslag og venter på bekræftelse 2. Confidence-aware Routing Hvornår: Modellen er usikker How: self-assessment (logits, LLM-as-a-judge, P(IK)) escalation when confidence falls below threshold 3. Human-as-a-Tool Hvornår: utilstrækkelige data eller uklar formulering af anmodningen Hvordan: Agent beder om præcisering (f.eks. HumanTool i CrewAI) 4. Fallback Escalation Hvornår: gentagen fejl eller uopklaret situation Hvordan: opgave overføres til operator med kontekst 5. RLHF (Human Feedback) Hvornår: Til modelforbedring Hvordan: Mennesket evaluerer svarene, de går i træning Checklist: Foranstaltninger, der kræver godkendelse, defineres Der er en mekanisme til tillidsvurdering Mennesker kan stille spørgsmål Kritiske handlinger kræver bekræftelse Der er et interface til indtastning af svar 8. Compact Errors into Context Den standard adfærd af mange systemer, når en fejl opstår, er enten at "krasche" eller blot rapportere fejlen og stoppe. For en agent, der skal selvstændigt løse opgaver, er dette ikke præcis den bedste adfærdsmodel. Problem: Hvad vi står over for: Any failure in an external tool or unexpected LLM response can stop the entire process or lead it astray. Brittleness: Ineffektivitet: Konstant genstart og manuel indgriben spiser tid og ressourcer. Manglende evne til at lære (i bred forstand): Hvis agenten ikke "ser" sine fejl i kontekst, kan den ikke forsøge at rette dem eller tilpasse sin adfærd. Hallucinationer – igen Fejl er inkluderet i opfordringen eller hukommelsen. ideen er at forsøge at gennemføre en slags "selvheling." agent bør i det mindste forsøge at rette sin adfærd og tilpasse sig. Solution: Stærke strømninger: Forstå fejltagelsen Self-correction: Error Detection, Reflection, Retry Logic, Retry with changes (Agent can modify request parameters, rephrase the task, or try a different tool) Self-correction mechanisms: More detailed error information (instructions, explanations) usually leads to better self-correction results. Even simple knowledge of previous errors improves performance. Impact of reflection type: Training LLMs for self-correction by introducing errors and their fixes into training data. Internal Self-Correction: Ansøg om menneskelig hjælp: Hvis selvkorrigeringen mislykkes, eskalerer agenten problemet til et menneske (se Princip 7). Checklist: Fejl i forrige trin gemmes i kontekst Retry logik eksisterer Fallback / menneskelig eskalering bruges til gentagne fejl 9. Break Complexity into Agents Lad os vende tilbage til nøgle LLM begrænsning (den kontekst vindue ting), men se på dette problem fra en anden vinkel. Jo større og mere kompleks opgaven, jo flere skridt det vil tage, hvilket betyder en længere kontekst vindue. Som kontekst vokser, LLMs er mere tilbøjelige til at blive tabt eller miste fokus. Ved at fokusere agenter på specifikke domæner med 3-10, måske maksimalt 20 trin, vi opretholde håndterbare kontekst vinduer og høj LLM ydeevne. Problem: Brug mindre agenter rettet mod specifikke opgaver. En agent = én opgave; orkestrering ovenfra. Solution: Fordele ved små, fokuserede agenter: Håndterbar kontekst: Mindre kontekstvinduer betyder bedre LLM-præstation Tydelige ansvarsområder: Hver agent har en veldefineret rækkevidde og formål Bedre pålidelighed: Mindre chance for at gå tabt i komplekse arbejdsprocesser Enklere test: Nemmere at teste og validere specifikke funktionaliteter Easier to identify and fix problems when they arise Improved debugging: Desværre er der ingen klar heuristik for forståelse, når et stykke logik allerede er stort nok til at opdele sig i flere agenter. Jeg er ret sikker på, at mens du læser denne tekst, har LLM'er fået smartere et sted i laboratorier. Og de fortsætter med at blive bedre og bedre, så ethvert forsøg på at formalisere denne grænse er dømt fra starten. Ja, jo mindre opgaven, jo enklere det er, men jo større det bliver, jo bedre potentialet realiseres. Checklist: Scenario is built from microservice calls Agents can be restarted and tested separately Agent = minimal autonomous logic. You can explain what it does in 1-2 sentences. Kontrolmodellen Interaktion Modellen håndterer generationen. Alt andet er op til dig. Modellen håndterer generationen. Alt andet er op til dig. Hvordan du formulerede anmodningen, hvad du passede i kontekst, hvilke instruktioner du gav - alt dette bestemmer, om resultatet vil være sammenhængende eller "kreativt". LLM'er læser ikke sind, de læser tokens. Det betyder, at enhver inputfejl bliver til en output bug – bare ikke umiddelbart mærkbar. Dette afsnit handler om ikke at lade alt drifte: prompts = kode, eksplicit kontekststyring, begrænsning af modellen inden for grænser. 10. Treat Prompts as Code Et meget almindeligt mønster, især blandt folk uden ML eller SE baggrund, er at gemme prompts direkte i kode eller i bedste fald usystematisk lagring i eksterne filer. Problem: Denne tilgang medfører flere vedligeholdelses- og skaleringsproblemer: Navigation, forståelse og ændring bliver kompliceret, da projektets kompleksitet og antallet af opfordringer vokser. Uden eksplicit versionering er det meget svært at spore den hurtige udvikling, årsagerne til ændringerne og rulle tilbage til tidligere stabile versioner i tilfælde af ydeevneforringelse. Ineffektiv forbedrings- og debuggingproces: Hurtig optimering uden objektive målinger og test bliver en subjektiv og arbejdskrævende proces med ustabile resultater. Opfattelsen af andre teammedlemmer bliver kompliceret, herunder (og især) fremtidige dig. Prompts i denne sammenhæng er ikke meget forskellig fra kode og de samme grundlæggende ingeniørpraksis bør anvendes til dem Solution: This implies: Gem separat og systematisk ved hjælp af specialiserede filer (såsom .txt, .md, .yaml, .json) eller endda skabelonstyringssystemer (såsom Jinja2, Handlebars eller specialiserede værktøjer som BAML). Du kan endda udføre A/B-tests med forskellige versioner efter dette. Testing. You heard that right. This could be something like unit tests, where you compare LLM responses to specific inputs against reference answers or expected characteristics depending on the prompt Evaluation datasets Format compliance checks and presence/absence of key elements - For example, if a prompt should return JSON, the test can validate its structure Even LLM-as-a-judge if your project and design justify it. Vi vil tale om test mere detaljeret i princip 14. Checklist: Prompts gemmes i separate filer, adskilt fra forretningslogik Der er diff og ændrer historie Tests anvendes (hvis det er nødvendigt) (Valgfri) Hvad med prompt gennemgang som en del af kode gennemgang? Kontekstteknik 11. Vi har allerede diskuteret "glemsomheden" af LLM'er, delvist løser dette ved at aflade historie til ekstern hukommelse og bruge forskellige agenter til forskellige opgaver. men det er ikke alt. Problem: En simpel liste over meddelelser i "rol-indholdet" ( ) format er baseline, men det kan være token tung, ikke informativt nok, eller dårlig til at formidle den komplekse tilstand af din agent. Standard formats aren't always optimal: system/user/assistant De fleste LLM-klienter bruger standardmeddelelsesformatet (en liste over objekter med : “system”, “bruger”, “assistent”, Og nogle gange af felter). role content tool_calls Selvom dette "fungerer godt for de fleste tilfælde", for at (i form af både tokens og modelens opmærksomhed) kan vi nærme os kontekstdannelse mere kreativt. maximum efficiency At behandle oprettelsen af hele informationspakken overført til LLM som Det betyder: Solution: "Context Engineering." Fuld kontrol: At tage fuld ejerskab for, hvilke oplysninger der kommer ind i LLM's kontekstvindue, i hvilken form, volumen og sekvens. Oprettelse af brugerdefinerede formater: Ikke at begrænse os til standard meddelelseslister. Udvikle vores egne, opgaveoptimerede måder at repræsentere kontekst på. For eksempel kan du overveje at bruge en XML-lignende struktur til tæt at pakke forskellige typer oplysninger (beskeder, værktøjsopkald, deres resultater, fejl osv.) i en eller flere meddelelser. Holistisk tilgang: Se konteksten ikke bare som en dialoghistorik, men som summen af alt, hvad modellen måtte have brug for: den øjeblikkelige opfordring, instruktioner, data fra RAG-systemer, historien om værktøjsopkald, agentens tilstand, hukommelse fra andre interaktioner og endda instruktioner om det ønskede outputformat. (Instead of a checklist) How do you know when this makes sense? Hvis du er interesseret i et af følgende: Informationstæthed: Maksimal betydning med minimal støj. Reducering af antallet af tokens, hvor vi kan få sammenlignelig kvalitet til en lavere pris. Forbedret håndtering af fejl. Håndtering af inkludering af følsomme oplysninger, kontrollere det, filtrere det, og afslutte det hele ved at udstede den klassiske "Undskyld, jeg er bare en squishy lille stor sprogmodel model" svar. 12. Constrain the Chaos: Secure Inputs, Guarded Actions, and Grounded Outputs Vi har allerede gjort meget i stabilitetens navn, men intet er en sølvkugle.Dette betyder, at det er værd at se på de mest kritiske potentielle problemer separat og udtrykkeligt tage nogle "forsikring". Problem: I dette princip tænker vi på: Mulig promptinjektion. Hvis din agent vil kommunikere direkte med en bruger, skal du kontrollere, hvad der føres som input. Afhængigt af typen af bruger, kan du få en, der ønsker at bryde dit flow og tvinge agenten til at ignorere sine oprindelige mål, give de forkerte oplysninger, udføre skadelige handlinger eller generere ondsindet indhold. Af ovennævnte årsager, eller ledet af "stemmer i hovedet", kan agenten afsløre vigtige oplysninger, såsom brugeres personlige data, virksomhedshemmeligheder osv. Generering af giftigt eller ondsindet indhold.Hvis dette er designet, skal du ignorere dette punkt. At gøre tingene op, når informationen er fraværende. Men seriøst, i sin ræsonnementsproces, kan agenten komme til meget ikke-trivielle løsninger, som ikke alle vil være inden for rammerne af normal adfærd. Sikkerheden og grundlaget for en LLM agent er ikke en enkelt foranstaltning, men et flerlags beskyttelsessystem ("forsvar-i-dybde"), der dækker hele interaktionens livscyklus. Truslerne er forskellige, og ingen enkelt beskyttelsesmetode er en panacea. Vi skal forpligte os til et flerlags forsvarssystem, tænke igennem og udtrykkeligt håndtere alle hjørne tilfælde og potentielle scenarier, og have et klart svar klar til hvad der måtte ske. Solution: I en grundlæggende indstilling skal du overveje: Secure Inputs. Check for known attack-indicator phrases (e.g., "ignore all previous instructions"). It sometimes makes sense to combat potential obfuscation. Try to determine the user's intent separately. You can use another LLM for this, to analyze the input for the current one. Control input from external sources, even if they are your own tools. Control the privileges of both the agent and its tools (granting the minimum necessary), clearly define and limit the list of available tools, validate parameters at the input to tools, and enable Principle #7 (Human in the Loop). Guarded Actions. Design a system of checks for what the model outputs, especially if it goes directly to the user. These can be checks for relevance (ensuring the model uses what's in the RAG and doesn't just make things up) as well as checks for general appropriateness. There are also ready-made solutions (e.g., the OpenAI Moderation API). Output Moderation. Det endelige system afhænger dog af dine opgaver og din risikovurdering.I checklisten vil vi forsøge at skitsere nogle muligheder. Checklist: User input validation is in place. For tasks requiring factual information, the data within the RAG is used. The prompt for the LLM in a RAG system explicitly instructs the model to base its answer on the retrieved context. LLM output filtering is implemented to prevent PII (Personally Identifiable Information) leakage. The response includes a link or reference to the source. LLM output moderation for undesirable content is implemented. The agent and its tools operate following the principle of least privilege. The agent's actions are monitored, with HITL (Human-in-the-Loop) for critical operations. IV. Keep It Alive En agent, der "kinda virker" er en bug med en forsinket effekt. En agent, der "kinda virker" er en bug med en forsinket effekt. Ikke alt går i stykker på én gang, og du finder ikke ud af det med det samme, nogle gange finder du ikke ud af det overhovedet. Dette afsnit handler om den tekniske vane af og Logs, sporing, tests - alt, hvad der gør en agents adfærd gennemsigtig og pålidelig, selv når du sover eller udvikler din næste agent. seeing what's happening checking that everything is still working 13. Trace Everything På den ene eller anden måde vil du konstant stå over for situationer, hvor agenten ikke fungerer, som du forventede. Under udvikling, test, ændringer eller under normal drift. Dette er uundgåeligt, og i øjeblikket er det normalt til en vis grad. Dette betyder, at du er dømt til at bruge timer og dage på at debugge, forsøge at forstå, hvad der er galt, reproducere problemet og rette det. Jeg vil gerne tro, at du allerede har implementeret Princip #1 (Keep State Outside) og #8 (Compact Errors in Context). I de fleste tilfælde vil det være nok til at gøre dit liv meget enklere. Nogle andre principper vil også indirekte hjælpe her. Problem: Alligevel (og især hvis du har besluttet ikke at bryde med dem for nu), er det meget fornuftigt at tænke på debugging på forhånd og spare dig tid og nerver i fremtiden ved at overholde dette princip. Log hele vejen fra anmodning til handling. Selv hvis du allerede har logs for individuelle komponenter, kan spore hele kæden være et problem. Selv hvis du er en stor fan af puslespil eller Lego, på et tidspunkt, vil det ophøre med at være sjovt. Solution: Why it's needed: Debugging – Find hurtigt, hvor tingene gik galt. Analyse – Se, hvor flaskehalse er, og hvordan man kan forbedre dem. Kvalitetsvurdering – Se, hvordan ændringer påvirker adfærd. Reproducerbarhed – Du kan præcist rekonstruere trinene. Revision - En log af alle agentbeslutninger og handlinger. Den grundlæggende "gentleman set" ser sådan ud: Indtastning: Den oprindelige brugerforespørgsel, parametre modtaget fra det foregående trin. Agentstatus: Nøglestatusvariabler for agenten før udførelsen af trinnet. Prompt: Den fulde tekst af prompt sendt til LLM, herunder systeminstruktioner, dialoghistorik, hentet RAG-kontekst, værktøjsbeskrivelser osv. The full, raw response from the LLM, before any parsing or processing. LLM Output: Tool Call: Hvis LLM besluttede at kalde et værktøj – navnet på værktøjet og de nøjagtige parametre, det blev kaldt med (ifølge den strukturerede output). Værktøjsresultat: Svaret, som værktøjet returnerede, herunder både vellykkede resultater og fejlmeddelelser. Agentens beslutning: Hvilken beslutning agenten tog baseret på LLM's svar eller værktøjets resultat (f.eks. hvilket næste skridt at udføre, hvilket svar at give brugeren). Metadata: Step eksekveringstid, den anvendte LLM-model, omkostningerne ved opkaldet (hvis tilgængeligt), koden / prompt-versionen. Tag et kig på eksisterende sporingsværktøjer; under visse omstændigheder vil de gøre dit liv meget lettere. LangSmith, for eksempel, giver en detaljeret visualisering af opkaldskæder, opfordringer, svar og brug af værktøjer. Du kan også tilpasse værktøjer som Arize, Weights & Biases, OpenTelemetry osv. til dine behov. Note: Checklist: Alle agent trin er logget (din version af "gentleman sæt"). Trinnene er forbundet med en session_id og en step_id. Der er en grænseflade til at se hele kæden. Prøven sendt til LLM kan reproduceres på ethvert tidspunkt. 14. Test Before You Ship På dette tidspunkt har du højst sandsynligt en slags praktisk færdig løsning. Det virker, måske endda bare på den måde, du ønskede. arbejder? selv efter den næste mindre opdatering?Ja, jeg fører os til emnet af test. Problem: Holder Det er tydeligt, at opdateringer i LLM-systemer, ligesom i alle andre – hvad enten det er ændringer i applikationskoden, opdateringer til datasæt til finjustering eller RAG, en ny version af basis LLM eller endda mindre promptjusteringer – ofte fører til utilsigtede brud i eksisterende logik og uventede, nogle gange nedværdigende, agentadfærd. Du har ikke gjort noget, men ydeevnen er faldet over tid. Måske har udbyderen opdateret deres model, måske har arten af inputdataene ændret sig (data drift) - hvad der fungerede i går kan stoppe med at fungere i dag. Selv en lille ændring i en prompt kan bryde den etablerede logik og fordreje output. Ikke-determinisme af LLM'er: Som du ved, er mange LLM'er ikke-deterministiske (især med temperatur > 0), hvilket betyder, at de vil generere forskellige svar på samme input på hvert opkald. Det vil være lettere for dig, hvis du har implementeret det første princip, men at reproducere en bestemt fejl til debugging kan være svært selv med faste data og tilstande. In complex systems, updating a single element (like a model or a prompt) can cascade through a chain of APIs, databases, tools, etc., and lead to a change in behavior elsewhere. "The Butterfly Effect." af hallucinationer. ...and I suppose we could go on. But we already understand that traditional tests, focused on verifying explicit code logic, are not fully capable of covering these issues. Vi bliver nødt til at udvikle en kompleks, omfattende tilgang, der dækker mange ting og kombinerer klassiske og domænespecifikke løsninger. Solution: Multi-level test: En kombination af forskellige testtyper, der målretter forskellige aspekter af systemet: fra lavt niveau enhedstest for individuelle funktioner og opfordringer til komplekse scenarier, der bekræfter agentens end-to-end arbejdsproces og brugerinteraktion. Fokus på LLM adfærd og kvalitet: Testning bør vurdere ikke kun funktionel korrekthed, men også kvalitative egenskaber af LLM svar, såsom relevans, nøjagtighed, sammenhæng, fravær af skadeligt eller bias indhold, og overholdelse af instruktioner og en given stil. Regressions- og kvalitetstest, der omfatter "gyldne datasæt", der indeholder forskellige inputeksempler og reference (eller acceptable intervaller af) outputs. Automatisering og integration i CI/CD. Human-in-the-loop evaluering: Specifikke faser af LLM-eval bør involvere et menneske til at kalibrere målinger og gennemgå komplekse eller kritiske tilfælde. En iterativ tilgang til prompt udvikling og testning: Prompt engineering bør behandles som en iterativ proces, hvor hver version af en prompt grundigt testes og evalueres før implementering. Testing at different levels of abstraction: Individual modules (parsers, validators, API calls) and their integration. Component testing: Isolated testing of prompts on various inputs. Prompt testing: Verifying the logic and interaction of components within an agent. Chain/Agent testing: Evaluating the completion of full user tasks. End-to-end system testing: Checklist: Logic is broken down into modules: functions, prompts, APIs—everything is tested separately and in combination. Response quality is checked against benchmark data, evaluating meaning, style, and correctness. Scenarios cover typical and edge cases: from normal dialogues to failures and provocative inputs. The agent must not fail due to noise, erroneous input, or prompt injections—all of this is tested. Any updates are run through CI and monitored in prod—the agent's behavior must not change unnoticed. Principle 15: Own the Execution Path Dette er et meta-princip; det løber gennem alle de ovennævnte. Heldigvis har vi i dag snesevis af værktøjer og rammer til enhver opgave. Næsten altid, at vælge en klar løsning betyder en Du får fart og en nem start, men du taber . trade-off flexibility, control, and, potentially, security Dette er især afgørende i agentudvikling, hvor det er vigtigt at styre: den uforudsigelighed af LLMs, kompleks logik for overgange og selvkorrektion, være klar til systemets tilpasning og udvikling, selv om dets kerneopgaver forbliver uændrede. Rammerne bringer Dette kan forenkle en prototype, men komplicere dens langsigtede udvikling. inversion of control Mange af de principper, der er beskrevet ovenfor, kan implementeres ved hjælp af off-the-shelf-løsninger – og dette er ofte berettiget. Det giver uovertruffen mere . explicit implementation of the core logic takes a comparable amount of time transparency, manageability, and adaptability Det modsatte ekstreme findes også - Det er også et ønske om at skrive alt fra bunden, det er også en fejl. over-engineering Ingeniøren vælger for sig selv: hvor det er rimeligt at stole på en ramme, og hvor det er vigtigt at opretholde kontrol. This is why the key is balance. You have to remember: the industry is still taking shape. Many tools were created before current standards emerged. Tomorrow, they might become obsolete—but the limitations baked into your architecture today will remain. Conclusion Konklusionen Okay, vi har gået over 15 principper, der, erfaring viser, hjælper med at gøre den indledende spænding af "det er levende!" i tillid til, at din LLM agent vil arbejde på en stabil, forudsigelig og nyttig måde under virkelige forhold. Du bør overveje hver af dem for at se, om det giver mening at anvende det til dit projekt. Key takeaways to carry with you: En teknisk tilgang er nøglen: Stole ikke på "magien" af LLMs. Struktur, forudsigelighed, styring og testbarhed er dine bedste venner. LLM er en kraftfuld komponent, men stadig kun en komponent: Behandle LLM som en meget smart, men alligevel, enkelt komponent i dit system. Iteration og feedback er nøglen til succes: Det er sjældent at skabe den perfekte agent på første forsøg.Vær forberedt på eksperimenter, målinger, fejlanalyse og kontinuerlig forbedring - af både agenten selv og dine udviklingsprocesser. Fællesskab og åbenhed: Feltet af LLM agenter udvikler sig hurtigt. Hold øje med ny forskning, værktøjer og bedste praksis, og dele dine egne erfaringer. Jeg håber, at du har fundet noget nyt og nyttigt her, og måske vil du endda komme tilbage til dette, mens du designer din næste agent.
