Stop prompting, begin ingenieurswese: 15 beginsels om jou AI-agent na produksie te lewer

Introduction

Aanvanklik probeer jy net om met ChatGPT te kommunikeer via die API, gooi in 'n paar reëls van konteks, en voel verbaas dat dit reageer.

So word 'n agent gebore.

As jy ook die afgelope jaar spandeer saam agente van skripte en wrapers, eksperimenteer en tinkering, en jy is nog steeds op soek na 'n skoonder, meer volhoubare manier om hulle te bou - hierdie artikel is vir jou.

Dink aan dit as 'n praktiese cheat sheet - 'n versameling tegniese beginsels wat help om 'n agent van die sandbox na produksie te lei: van 'n eenvoudige API-wrapper tot 'n stabiele, beheerbare en skaalbare stelsel.

Disclaimer

In dieHierdie artikel(Bou effektiewe agente), Anthropic definieer 'n agent as 'n stelsel waar LLMs hul eie prosesse en gereedskapgebruik dinamies rig, beheer handhaaf oor hoe hulle take vervul. stelsels waar LLMs en gereedskap georkestreer word deur vooraf gedefinieerde kode pads wat hulle Workflows noem. Beide is deel van 'n breër konsep - Agent Systems.

In hierdie teks, Agent = Agent stelsel, waar ter wille van stabiliteit en beheer ek sal meer dikwels leun na Workflows. ek hoop dat in die nabije toekoms daar sal wees 1-2 meer draaie van die evolusie en ware Agents sal alomvattend wees, maar vir nou is dit nie die geval nie

1. Design the Foundation

Vroege weergawes van agente kom gewoonlik vinnig saam: 'n paar funksies, 'n paar oproepe - en hey, dit werk.

Vroege weergawes van agente kom gewoonlik vinnig saam: 'n paar funksies, 'n paar oproepe - en hey, dit werk.

“If it works, why make it complicated?”

In die begin, allesDit lykDie agent reageer, voer kode uit, gedra sinvol.Maar sodra jy die model verander, die stelsel herstart of 'n nuwe koppelvlak aansluit, word dit skielik onstabiel, onvoorspelbaar, moeilik om te debug.

En dikwels is die worteloorsaak nie in die logika of die opdragte nie, maar baie vroeër: gebroke geheue bestuur, hardkode personeel, geen manier om sessies te hervat nie, of 'n enkele rigide ingangspunt.

Hierdie afdeling gaan deur vier sleutelbeginsels wat jou sal help om 'n stewige basis te bou - een waarop alles anders veilig kan groei.

1. Keep State Outside

Problem:

1. As die agent onderbreek word ('n crash, 'n timeout, wat ookal), moet dit in staat wees om presies op te haal waar dit gestop het.
2. U benodig 'n manier om presies te reproduseer wat gebeur het - vir toetsing, debugging en ander sulke plesier.

Dit is nie 'n streng probleem nie, maar tog:

3. Parallelisering. Vroeër of later sal jy wil om te paralleliseer die logika van die agent. Miskien het dit nodig om te vergelyk verskeie opsies in die middel van die dialoog (“Wie van hierdie is beter?”). Miskien wil jy dit te vertak. Wie weet - jy sal.

(Memory is 'n heeltemal afsonderlike kwessie - ons sal dit binnekort kry)

Solution:Beweeg die staatoutsidedie agent - in 'n databasis, 'n cache, 'n opslaglaag - selfs 'n JSON-lêer sal doen.

Checklist:

• Die agent kan vanaf enige stap begin word, met slegs 'n session_id - die sessie-identifikaat - en eksterne toestand (byvoorbeeld, bewaar stappe in 'n databasis of JSON-lêer).
• Test geval: 'n onderbroke agent verloor nie konteks nie, na herstart is die resultaat dieselfde
• State is serialiserbaar op enige oomblik sonder verlies van funksionaliteit
• U kan die toestand aan verskeie voorbeelde in parallel in die middel van 'n dialoog voer

2. Make Knowledge External

Problem: LLMs onthou nie. Selfs binne 'n enkele sessie, kan die model vergeet wat jy reeds verduidelik het, stadiums meng, die draad van gesprek verloor, of begin "vul in" besonderhede wat nie daar was nie. En dit lyk asof die tyd voortgaan, die konteks venster groei groter en groter, verheug ons met nuwe moontlikhede. LinkedIn is vol poste waar mense vergelyk watter boek of hoeveel uur van YouTube se video nou pas in die nuwe model weergawe.

Veral as jy:

• Die dialoog is lank
• Dokumente is groot
• Instruksies is kompleks
• en tokens is nog nie oneindig nie

Selfs met toenemende konteksvensters (8k, 16k, 128k...), bly probleme:

• "Verlore in die middel" - die model bestee meer aandag aan die begin en einde (en kan besonderhede van die middel los)
• koste - meer tokens = meer geld;
• En dit pas nog steeds nie. wat beteken dat daar verlies, vervorming of hallusinasies sal wees. So lank as transformateurs werk op self-oplettendheid met vierkante kompleksiteit (O(n2)), sal hierdie beperking met ons wees.

Solution:Afsonderlike "werkgeheue" van "opslag" - soos in klassieke rekenaarstelsels. die agent moet in staat wees om met eksterne geheue te werk: opslaan, terug te haal, opsomm, en actualiseer kennis buite die model.

Approaches

Memory Buffer

Die laaste winkelskProbeer 'n vinnige prototype.

+maklik, vinnig, genoeg vir kort take

-verloor belangrike inligting, nie skaal nie, onthou nie "gister"

Summarization Memory

Kompressie geskiedenis om meer te pas.

+Token besparing, geheue uitbreiding

-vervormings, verlies van nuanses, foute in multi-stap kompressie

RAG (Retrieval-Augmented Generation)

Trek kennis uit eksterne databasis. Die meeste van die tyd sal jy hier wees.

+Skaleerbaar, vars en verifieerbaar

-komplekse instelling, sensitief vir herstelgehalte, latensie

Knowledge Graphs

Struktureerde verbindings tussen entiteite en feite. Altijd elegant, sexy en hard, sal jy uiteindelik RAG doen.

+logika, verduidelikbaarheid, stabiliteit

-hoë hindernis vir toegang, kompleksiteit van LLM-integrasie

Checklist:

• Alle gespreksverhaal is toeganklik op een plek (buite die oproep)
• Kennisbronne word geregistreer en kan hergebruik word
• Historiese skaal sonder die risiko om die konteksvenster te oorskry

3. Model as a Config

Problem:LLMs evolueer vinnig; Google, Anthropic, OpenAI, ens voortdurend vrylating van updates, wedloop teen mekaar oor verskillende benchmarks. Dit is 'n feest vir ons as ingenieurs, en ons wil die meeste daarvan maak. Ons agent moet maklik in staat wees om na 'n beter (of omgekeerd, goedkoper) model naadloos te skakel.

Solution:

1. Implementeer model_id-konfigurasie: Gebruik 'n model_id-parameter in konfigurasie-lêers of omgewingsvariabele om die model te spesifiseer wat gebruik word.
2. Gebruik abstrakte koppelvlakke: Maak koppelvlakke of wrapper-klasse wat met modelle interaksie maak deur middel van 'n verenigde API.
3. Apply middleware oplossings (versigtig - ons sal praat oor raamwerke 'n bietjie later)

Checklist:

• Modelvervanging beïnvloed nie die res van die kode en beïnvloed nie agentfunksionaliteit, orkestrasie, geheue of gereedskap nie.
• Die toevoeging van 'n nuwe model vereis slegs konfigurasie en, optioneel, 'n adapter ( 'n eenvoudige laag wat die nuwe model na die vereiste koppelvlak bring)
• Jy kan maklik en vinnig modelle verander. Ideaal - enige modelle, ten minste - wissel binne 'n modelfamilie

4. One Agent, Many Interfaces: Be Where the Users Are

Problem:Selfs as die agent aanvanklik bedoel is om slegs een kommunikasie-interface te hê (byvoorbeeld, UI), sal jy uiteindelik gebruikers meer fleksibiliteit en gerief wil gee deur interaksie deur Slack, WhatsApp, of, durf ek dit te sê, SMS - wat ook al. 'N API kan verander in 'n CLI (of jy sal een vir debugging wil hê). Bouw dit in jou ontwerp van die begin af; maak dit moontlik om jou agent te gebruik waar dit gerieflik is.

Solution: Creating a unified input contractOntwikkel 'n API of ander meganisme wat sal dien as 'n universele koppelvlak vir alle kanale.

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

  
  

  

  
  

II. Definieer agent gedrag

Alhoewel daar net een taak is, is alles eenvoudig, soos in die poste van AI-evangeliste.Maar sodra jy gereedskap, besluitnemingslogika en verskeie stadiums byvoeg, verander die agent in 'n rommel.

Alhoewel daar net een taak is, is alles eenvoudig, soos in die poste van AI-evangeliste.Maar sodra jy gereedskap, besluitnemingslogika en verskeie stadiums byvoeg, verander die agent in 'n rommel.

Dit verloor die spoor, weet nie wat om te doen met foute nie, vergeet om die regte instrument te bel - en jy word weer alleen met logboeke waar "goed, alles lyk daar geskryf te wees."

Om dit te vermy, moet die agent 'n duidelikebehavioral model: wat dit doen, watter gereedskap dit het, wie neem besluite, hoe mense inmenging, en wat om te doen wanneer iets verkeerd gaan.

Hierdie afdeling dek beginsels wat jou sal help om jou agent 'n konsekwente aksie strategie te gee in plaas van te hoop "die model sal dit op enige manier uitvind."

5. Design for Tool Use

Problem:Hierdie punt mag voor die hand liggend lyk, maar jy kry nog steeds agente gebou op "Plain Prompting + rauwe LLM output parsing." Dit is soos om te probeer om 'n komplekse meganisme te beheer deur ewekansige strings te trek en te hoop vir die beste.

• Brittleness: The slightest change in LLM response wording (a word added, phrase order changed) can break the entire parsing. This leads to a constant "arms race" between your parsing code and model unpredictability.
• Ambiguïteit: Natuurlike taal is inherent ambiguïteit. Wat vir 'n mens duidelik lyk, kan 'n raaisel vir 'n ondervrager wees. "Call John Smith" - watter van die drie John Smiths in jou databasis?
• Instandhouding kompleksiteit: Parsing kode groei, word ingewikkeld en moeilik om te debug.
• Beperkte vermoëns: Dit is moeilik om die model betroubaar te maak om verskeie gereedskap te bel of komplekse data strukture deur eenvoudige teksuitvoer te stuur.

Solution:Die model retourneer JSON (of 'n ander gestruktureerde formaat)—die stelsel uitvoer.

Die sleutel idee hier is om die verantwoordelikheid virInterpretasieGebruikersdoeleindes enKiesgereedskap vir die LLM, terwyl nog die toekenning van dieExekusievan die bedoeling om diedie stelseldeur 'n duidelik gedefinieerde koppelvlak.

Gelukkig ondersteun feitlik alle verskaffers (OpenAI, Google, Anthropic, of wat jy ook al verkies) sogenaamde"function calling"of die vermoë om uitvoer in 'n streng gedefinieerde JSON-formaat te genereer.

Net om te verfriss hoe dit werk:

1. Tool Description: Jy definieer funksies (tools) as JSON Schema met naam, beskrywing, parameters.
2. Gaan na LLM: Op elke oproep, die model ontvang gereedskap skema's saam met die oproep.
3. Model output: Instead of text, the model returns JSON with:
   • name of the function to call
   • arguments—parameters according to schema
4. Uitvoering: Kode valideer JSON en roep die toepaslike funksie met parameters.
5. Model reaksie (optioneel): Uitvoeringsresultaat word teruggestuur na die LLM vir finale reaksie generasie.

Important:Tool beskrywings is ook prompts. Onduidelike beskrywing = verkeerde funksie keuse.

What to do without function calling?

As die model nie gereedskapoproepe ondersteun nie of as u hulle om enige rede wil vermy:

• Vra die model om JSON in die oproep terug te gee. Maak seker dat jy die formaat spesifiseer; jy kan voorbeelde byvoeg.
• Parseer die antwoord en valideer dit met iets soos Pydantic.

Checklist:

• Antwoord is streng geformaliseer (bv. JSON)
• Skema's word gebruik (JSON Schema of Pydantic)
• Validasie word toegepas voordat funksie oproepe
• Generatiewe foute veroorsaak nie breek nie (formaat foute hanteer bestaan)
• LLM = funksie keuse, uitvoering = kode

6. Own the Control Flow

Problem: Usually agents work as "dialogues"—first the user speaks, then the agent responds. It's like playing ping-pong: hit-response. Convenient, but limiting.

Such an agent cannot:

• Doen iets op jou eie sonder 'n versoek
• Voer optrede in parallel
• Plan steps in advance
• Maak 'n paar stappe in 'n opeenvolging
• Controleer vooruitgang en terugkeer na mislukte stappe

In plaas daarvan moet die agent sy eie "uitvoerstroom" bestuur - besluit wat om volgende te doen en hoe om dit te doen.Dit is soos 'n taakplanner: die agent kyk na wat gedoen moet word en voer stappe in orde uit.

This means the agent:

• Besluit wanneer om iets op sy eie te doen
• kan stappe een na die ander neem
• Kan mislukte stappe herstel
• can switch between tasks
• Kan werk selfs sonder direkte versoek

Solution:In plaas daarvan dat die LLM die hele logika beheer, trek ons diecontrol flowDie model help slegs binne stappe of stel die volgende voor.engineering a system with controlled behaviour.

Kom ons kyk na drie gewilde benaderings:

1. FSM (Finite State Machines)

• Wat dit is: Taak verdeel in state en duidelike oorgange.
• LLM: Bepaal die volgende stap of optree binne 'n staat.
• Voors: Eenvoudigheid, voorspelbaarheid, goed vir lineêre scenario's.
• Tools: StateFlow, YAML konfigurasies, State Pattern.

2. DAG (Directed Graphs)

• Wat dit is: Nie-lineêre of parallelle take as 'n grafiek: nodes is aksies, kante is afhanklikhede.
• LLM: Kan 'n knoop wees of help met planbou.
• Voors: Fleksibiliteit, parallelisme, visualiserbaar.
• Tools: LangGraph, Trellis, LLMCompiler, aangepaste DAG-diagramme.

3. Planner + Executor

• Wat dit is: 'n LLM bou 'n plan, kode of ander agente uitvoer dit.
• LLM: "Big" een planne, "klein" die uitvoering.
• Voors: Afskeiding van bekommernisse, koste beheer, skaalbaarheid.
• LangChain plan en uitvoer.

Why this matters:

• Verhoog beheerbaarheid, betroubaarheid, skaalbaarheid.
• Maak dit moontlik om verskillende modelle te kombineer en die uitvoering te versnel.
• Taskflow word visualiserbaar en toetsbaar.

Checklist:

• Gebruik FSM, DAG of scenario met eksplisiete oorgange
• Model besluit wat om te doen, maar beheer nie die vloei nie
• Behavior can be visualized and tested
• Foutbestuur word ingebou in die vloei

7. Include the Human in the Loop

Problem:Selfs as 'n agent gestruktureerde gereedskap gebruik en 'n duidelike beheerstroom het, is die volle outonoomheid van LLM-agente in die werklike wêreld steeds meer van 'n droom (of nagmerrie, afhangende van konteks). LLM's besit nie ware begrip en is nie verantwoordelik vir iets nie.

Main risks of full autonomy:

• Permanente foute: Die agent kan aksies met ernstige gevolge uitvoer (data verwyder, 'n verkeerde boodskap aan 'n belangrike kliënt stuur, 'n robot-opstand begin).
• Ooreenstemming oortredings: Die agent kan per ongeluk interne regulasies, wettige vereistes oortree of gebruikersgevoelens seermaak (as dit nie die plan was nie, ignoreer hierdie punt).
• Gebrek aan gesonde verstand en etiek: LLMs kan sosiale nuanses mis of teen "gewone verstand" optree.
• Verlies van gebruikersvertroue: As die agent gereeld foute maak, sal gebruikers dit nie meer vertrou nie.
• Auditing en verantwoordelikheid kompleksiteit: Wie is die skuld wanneer 'n outonome agent "skroef"?

Solution: Strategiese oproep van koolstofgebaseerde lewensvormeIntegreer mense in die besluitneming proses in sleutelfases.

HITL Implementation Options

1. Approval Flow

• When: action is critical, expensive, irreversible
• Hoe: agent maak 'n voorstel en wag vir bevestiging

2. Confidence-aware Routing

• Wanneer: die model is onseker
• How:
  • self-assessment (logits, LLM-as-a-judge, P(IK))
  • escalation when confidence falls below threshold

3. Human-as-a-Tool

• Wanneer: onvoldoende data of onduidelike formulering van die versoek
• Hoe: agent vra vir verduideliking (bv, HumanTool in CrewAI)

4. Fallback Escalation

• Wanneer: herhaalde fout of onoplosbare situasie
• Hoe: taak word oorgedra na operator met konteks

5. RLHF (Human Feedback)

• Wanneer: vir modelverbetering
• Hoe: mens evalueer antwoorde, hulle gaan in opleiding

Checklist:

• Aksies wat goedkeuring benodig word gedefinieer
• Daar is 'n meganisme vir vertrouebeoordeling
• Agente kan menslike vrae vra
• Kritieke optrede vereis bevestiging
• Daar is 'n koppelvlak vir die invoer van antwoorde

8. Compact Errors into Context

Problem:Die standaard gedrag van baie stelsels wanneer 'n fout plaasvind, is of om te "crash" of eenvoudig die fout te rapporteer en te stop. Vir 'n agent wat taak autonoom moet oplos, is dit nie presies die beste gedragsmodel nie.

Wat ons sal ondervind:

• Brittleness: Elke mislukking in 'n eksterne instrument of onverwagte LLM reaksie kan die hele proses stop of lei dit mislei.
• Ineffektiwiteit: Konstante herstart en manuele ingryping neem tyd en hulpbronne op.
• Onmoontlikheid om te leer (in die breë sin): As die agent nie sy foute in konteks "sien" nie, kan dit nie probeer om hulle te herstel of sy gedrag aan te pas nie.
• Hy het hallucinaties. weer.

Solution:Foute word in die oproep of geheue ingesluit. Die idee is om te probeer om 'n soort "selfgenesing" te implementeer.

Rough flow:

• Understanding the error
• Self-correction:
  • Self-correction mechanisms: Error Detection, Reflection, Retry Logic, Retry with changes (Agent can modify request parameters, rephrase the task, or try a different tool)
  • Impact of reflection type: More detailed error information (instructions, explanations) usually leads to better self-correction results. Even simple knowledge of previous errors improves performance.
  • Internal Self-Correction: Training LLMs for self-correction by introducing errors and their fixes into training data.
• Vra menslike hulp: As selfkorreksie misluk, escaleer die agent die probleem na 'n mens (sien beginsel 7).

Checklist:

• Die fout van die vorige stap word gered in konteks
• Retry logika bestaan
• Fallback/human escalation is used for repeated failures

9. Break Complexity into Agents

Problem:Kom ons terug na die sleutel LLM beperking (dat konteks venster ding), maar kyk na hierdie probleem vanuit 'n ander hoek. Hoe groter en meer komplekse die taak, hoe meer stappe dit sal neem, wat beteken 'n langer konteks venster. Soos konteks groei, LLMs is meer geneig om te verloor of fokus te verloor.

Solution: Use smaller agents targeted at specific tasks. One agent = one task; orchestration from above.

Voordele van klein, gefokusde agente:

• Beheerbare konteks: Klein konteksvensters beteken beter LLM prestasie
• Duidelike verantwoordelikhede: Elke agent het 'n goed gedefinieerde omvang en doel
• Beter betroubaarheid: Minder kans om verlore te raak in komplekse werkstrome
• Eenvoudiger toetsing: Makliker om spesifieke funksionaliteit te toets en te valideer
• Verbeterde debugging: makliker om probleme te identifiseer en op te los wanneer hulle ontstaan

Ongelukkig is daar geen duidelike heuristiek vir die begrip wanneer 'n stuk logika al groot genoeg is om in verskeie agente te verdeel nie. Ek is redelik seker dat terwyl jy hierdie teks lees, LLM's is slimmer ergens in labs. En hulle bly steeds beter en beter, so enige poging om hierdie grens te formeel, is van die begin af veroordeel. Ja, hoe kleiner die taak, hoe eenvoudiger dit is, maar hoe groter dit word, hoe beter die potensiaal gerealiseer word. Die regte intuïsie sal slegs met ervaring kom. Maar dit is nie seker nie.

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.

  
  

  

  
  

III. Interaksiemodel van beheer

Die model hanteer generasie. Alles anders is op jou.

Die model hanteer generasie. Alles anders is op jou.

Hoe jy die versoek geformuleer het, wat jy in konteks oorgegee het, watter instruksies jy gegee het - dit alles bepaal of die resultaat konsekwent of "kreatief" sal wees.

LLMs lees nie gedagtes nie. Hulle lees tokens.

Dit beteken dat enige invoerfout in 'n uitvoerfout verander - net nie dadelik merkbaar nie.

Hierdie afdeling gaan oor om nie alles te laat dryf nie: prompts = kode, eksplisiete konteksbestuur, die beperking van die model binne grense.

10. Treat Prompts as Code

Problem:'N baie algemene patroon, veral onder mense sonder ML of SE agtergrond, is om prompts direk in kode te stoor.

Hierdie benadering lei tot verskeie onderhouds- en skaalprobleme:

• Navigeer, verstaan en verander word ingewikkeld as die kompleksiteit van die projek en die aantal oproepe groei.
• Sonder uitdruklike weergawe, is dit baie moeilik om vinnige evolusie, redes vir veranderinge te volg en terug te rol na vorige stabiele weergawes in die geval van prestasie afname.
• Ineffektiewe verbetering en debugging proses: Vroeë optimalisering sonder objektiewe metrikes en toetsing word 'n subjektiewe en arbeidsintensive proses met onstabiele resultate.
• Persepsie deur ander lede van die span word ingewikkeld, insluitend (en veral) jou toekoms.

Solution:Prompte in hierdie konteks is nie baie anders as kode en dieselfde basiese ingenieurspraktyke moet op hulle toegepas word nie.

This implies:

• Speel afsonderlik en stelselmatig, met behulp van gespesialiseerde lêers (soos .txt, .md, .yaml, .json) of selfs sjabloonbestuurstelsels (soos Jinja2, Handlebars, of gespesialiseerde gereedskap soos BAML).
• U kan selfs A / B-toetse met verskillende weergawes doen.
• 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.

Ons sal meer in detail praat oor toetsing in beginsel 14.

Checklist:

• Prompts word in afsonderlike lêers gestoor, afsonderlik van besigheidslogika
• Daar is diff en verander geskiedenis
• Tests word gebruik (as nodig)
• (Optioneel) Wat van prompt beoordeling as deel van die kode oorsig?

11.Kontekst ingenieurswese

Problem:Ons het reeds die "vergetelheid" van LLM's bespreek, wat dit gedeeltelik oplos deur die geskiedenis af te laai na eksterne geheue en verskillende agente vir verskillende take te gebruik.Maar dit is nie alles nie.

Standard formats aren't always optimal:Eenvoudige lys van boodskappe in die "rol-inhoud" (system/user/assistantFormat is die baseline, maar dit kan swaar wees, nie informatief genoeg nie, of swak in die oordrag van die komplekse toestand van jou agent.

Die meeste LLM kliënte gebruik die standaard boodskap formaat ('n lys van voorwerpe metrole• “stelsel”, “gebruiker”, “assistent”,contentEn somstool_calls fields).

Alhoewel hierdie "werk goed vir die meeste gevalle", om seker te maakmaximum efficiency(in terme van beide tokens en die model se aandag), kan ons konteksvorming meer kreatief benader.

Solution:Om die skepping van die hele inligtingpakket wat aan die LLM oorgedra word, te behandel as"Context Engineering." This means:

1. Volledige beheer: Neem volle eienaarskap oor watter inligting die LLM se konteksvenster invoer, in watter vorm, volume en volgorde.
2. Maak aangepaste formate: Ons beperk ons nie tot standaard boodskap lys. Ontwikkel ons eie, taak geoptimaliseerde maniere om konteks te verteenwoordig. Byvoorbeeld, jy kan oorweeg om 'n XML-agtige struktuur te gebruik om verskillende tipes inligting (boodskappe, gereedskap oproepe, hul resultate, foute, ens.) dikwels in een of meer boodskappe te verpak.
3. Holistiese benadering: Kyk na die konteks nie net as 'n dialoogverhaal nie, maar as die totaal van alles wat die model nodig het: die onmiddellike oproep, instruksies, data van RAG-stelsels, die geskiedenis van gereedskapoproepe, die agent se toestand, geheue van ander interaksies, en selfs instruksies oor die gewenste uitvoerformaat.

(Instead of a checklist) How do you know when this makes sense?

If you're interested in any of the following:

• Maksimum betekenis met 'n minimum lawaai.
• Kosteneffektiewe vermindering van die aantal tokens waar ons vergelykbare gehalte vir 'n laer prys kan kry.
• Verbetering van die foutbestuur.
• Beheer die insluiting van sensitiewe inligting, beheer dit, filter dit, en eindig dit alles deur die klassieke "sorry, ek is net 'n squishy klein groot taalmodel model" reaksie uit te voer.

12. Constrain the Chaos: Secure Inputs, Guarded Actions, and Grounded Outputs

Problem:Ons het reeds baie gedoen in die naam van stabiliteit, maar niks is 'n silwer kogel nie.Dit beteken dat dit die moeite werd is om die mees kritieke potensiële probleme afsonderlik te kyk en uitdruklik 'n paar 'versekering' te neem.

In hierdie beginsel dink ons aan:

• Miskien Prompt Injection. As jou agent direk met 'n gebruiker sal kommunikeer, moet jy beheer wat as input gevoed word. Afhangende van die tipe gebruiker, kan jy een kry wat jou vloei wil breek en die agent dwing om sy aanvanklike doelwitte te ignoreer, die verkeerde inligting te verskaf, skadelike aksies uit te voer, of skadelike inhoud te genereer.
• Vir die rede hierbo, of gelei deur "stemme in sy kop," kan die agent belangrike inligting openbaar, soos gebruikers se persoonlike data, korporatiewe geheime, ens.
• Generering van giftige of kwaadwillige inhoud. As dit deur ontwerp is, ignoreer hierdie punt.
• Om dinge te maak wanneer inligting afwesig is.Die ewige pyn.
• Die opkoms van die masjiene, onthou? Maar ernstig, in sy redeproses, kan die agent tot baie nie-triviale oplossings kom, nie almal wat binne die omvang van normale gedrag sal wees nie.

Die sekuriteit en gronding van 'n LLM-agent is nie 'n enkele maatstaf nie, maar 'n meerlae-beskermingstelsel ("verdediging-in-diepte") wat die hele lewenscyklus van interaksie dek. Die bedreigings is divers, en geen enkele metode van beskerming is 'n panacea nie.

Solution:Ons moet verbind word tot 'n meerlae verdedigingstelsel, dink deur en uitdruklik hanteer al die hoek gevalle en moontlike scenario's, en het 'n duidelike reaksie gereed vir alles wat kan gebeur.

In 'n basiese instelling, moet jy oorweeg:

1. Secure Inputs.

   1. Check for known attack-indicator phrases (e.g., "ignore all previous instructions"). It sometimes makes sense to combat potential obfuscation.
   2. Try to determine the user's intent separately. You can use another LLM for this, to analyze the input for the current one.
   3. Control input from external sources, even if they are your own tools.

2. Guarded Actions. 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).

3. Output Moderation. 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).

Die finale stelsel hang egter af van jou take en jou risiko-beoordeling.In die tjeklys sal ons probeer om 'n paar opsies te skets.

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

'N Agent wat "kinda werk" is 'n fout met 'n vertraagde effek.

'N Agent wat "kinda werk" is 'n fout met 'n vertraagde effek.

In prod, nie alles breek op 'n oomblik nie. en jy leer nie daarvan onmiddellik.

Hierdie afdeling gaan oor die ingenieurswese vanseeing what's happeningenchecking that everything is still workingLogs, opsporing, toetse - alles wat 'n agent se gedrag transparant en betroubaar maak, selfs wanneer jy slaap of jou volgende agent ontwikkel.

13. Trace Everything

Problem:Op die een of ander manier sal jy voortdurend situasies ondervind waar die agent nie werk soos jy verwag het nie. Tydens ontwikkeling, toetsing, veranderinge, of tydens normale bedryf. Dit is onvermydelik, en op die oomblik is dit normaal tot 'n mate. Dit beteken dat jy gedoem word om ure en dae te spandeer debugging, probeer om te verstaan wat verkeerd is, die probleem te reproduseer en dit op te los. Ek wil dink dat by hierdie punt jy reeds beginsel #1 (Keep State Outside) en #8 (Compact Errors in konteks) geïmplementeer het. In die meeste gevalle sal dit genoeg wees om jou lewe baie makliker te maak. Sommige ander beginsels sal ook indireklik hier help.

Selfs so (en veral as jy besluit het om nie vir nou met hulle te hinder nie), is dit baie sinvol om vooraf oor debugging te dink en jouself tyd en senuwees in die toekoms te bespaar deur aan hierdie beginsel te voldoen.

Solution:Log die hele pad van versoek tot aksie. Selfs as jy reeds logs vir individuele komponente het, kan die hele ketting opspoor 'n moeilikheid wees. Selfs as jy 'n groot fan is van raaisels of Lego, op 'n oomblik sal dit ophou om pret te wees.

Why it's needed:

• Debugging — Vinnig vind waar dinge verkeerd gegaan het.
• Analise — Kyk waar die bottelblokke is en hoe om te verbeter.
• Kwaliteitsbeoordeling – sien hoe veranderinge gedrag beïnvloed.
• Reproduseerbaarheid – U kan die stappe presies herbou.
• Auditing - 'n log van al die agent besluite en aksies.

Die basiese "gentleman's set" lyk soos hierdie:

• Input: The initial user request, parameters received from the previous step.
• Agentstaat: Sleutelstaatvariabele van die agent voor die uitvoering van die stap.
• Prompt: Die volledige teks van die prompt gestuur aan die LLM, insluitend stelsel instruksies, dialoog geskiedenis, gekry RAG konteks, instrument beskrywings, ens.
• LLM Output: Die volledige, ruwe reaksie van die LLM, voor enige parsing of verwerking.
• Tool Call: As die LLM besluit om 'n instrument te bel - die naam van die instrument en die presiese parameters waarmee dit geroep is (volgens die gestruktureerde uitvoer).
• Werktuigresultaat: Die reaksie wat die instrument teruggekeer het, insluitend beide suksesvolle resultate en foutboodskappe.
• Agent se Besluit: Watter besluit die agent gemaak het gebaseer op die antwoord van die LLM of die resultaat van die instrument (bv, watter volgende stap om uit te voer, watter antwoord om die gebruiker te gee).
• Metadata: Stap uitvoering tyd, die LLM model gebruik, die koste van die oproep (indien beskikbaar), die kode / prompt weergawe.

Note:Kyk na bestaande tracking gereedskap; onder sekere omstandighede sal hulle jou lewe baie makliker maak. LangSmith, byvoorbeeld, bied gedetailleerde visualisering van oproepketting, oproepe, antwoorde en gereedskap gebruik. Jy kan ook gereedskap soos Arize, Weights & Biases, OpenTelemetry, ens. aan jou behoeftes aanpas.

Checklist:

• Alle stappe van die agent word geregistreer (jou weergawe van die "gentleman's set").
• Stappe word gekoppel deur 'n sessie_id en 'n stap_id.
• Daar is 'n koppelvlak om die hele ketting te sien.
• Die oproep wat na die LLM gestuur word, kan op enige stadium herhaal word.

14. Test Before You Ship

Problem:By hierdie punt, jy het waarskynlik 'n soort van feitlik voltooide oplossing. Dit werk, miskien selfs net die manier wat jy wou hê. Ship dit om te produseer?Houwerk? Selfs na die volgende klein update?Ja, ek lei ons na die onderwerp van toetsing.

Dit is duidelik dat updates in LLM-stelsels, net soos in enige ander - of dit veranderinge in die toepassingskode is, updates aan dataset vir finet-tuning of RAG, 'n nuwe weergawe van die basiese LLM, of selfs klein aanpassings - dikwels lei tot onbedoelde breuke in bestaande logika en onverwagte, soms vernederende, agentgedrag. Tradisionele sagteware toets benaderings blyk onvoldoende te wees vir omvattende kwaliteit beheer van LLM-stelsels.

• Miskien het die verskaffer hul model opgedateer, miskien het die aard van die invoerdata verander (data drift) - wat gister gewerk het, kan vandag ophou werk.
• Selfs 'n klein verandering in 'n prompt kan die gevestigde logika breek en die output vervorm.
• Non-determinisme van LLMs: Soos jy weet, is baie LLMs nie-deterministies (veral met temperatuur > 0), wat beteken dat hulle verskillende antwoorde op dieselfde invoer op elke oproep sal genereer.
• Dit sal makliker vir jou wees as jy die eerste beginsel geïmplementeer het, maar om 'n spesifieke fout vir debugging te reproduseer, kan moeilik wees, selfs met vaste data en state.
• In komplekse stelsels, kan die opdatering van 'n enkele element (soos 'n model of 'n prompt) deur 'n ketting van APIs, databases, gereedskap, ens, en lei tot 'n verandering in gedrag elders.
• van hallucinasies.

Maar ons verstaan reeds dat tradisionele toetse, wat gefokus is op die verifikasie van eksplisiete kode logika, nie ten volle in staat is om hierdie kwessies te dek nie.

Solution:Ons sal 'n komplekse, omvattende benadering moet ontwerp wat baie dinge dek, wat klassieke en domeinspesifieke oplossings kombineer.

• Multi-vlakke toetsing: 'n kombinasie van verskillende toetstype wat verskillende aspekte van die stelsel streef: van lae-vlak eenheid toetse vir individuele funksies en oproepe tot komplekse scenario's wat die agent se eind-tot-ende werkstroom en gebruikersinteraksie verifieer.
• Fokus op LLM gedrag en gehalte: Teste moet nie net funksioneel korrekte nie, maar ook kwalitatiewe eienskappe van LLM reaksies, soos relevansie, akkuraatheid, konsekwentheid, afwesigheid van skadelike of vooroordeel inhoud, en nalewing aan instruksies en 'n gegewe styl evalueer.
• Regressie en gehalte toetse wat "gouden datasette" bevat wat uiteenlopende invoer voorbeelde en verwysing (of aanvaarbare reeks) uitkomste bevat.
• Automatisering en integrasie in CI / CD.
• Mens-in-the-loop evaluering: Spesifieke stadiums van LLM-eval moet 'n mens betrek vir die kalibrasie van metrikes en die ondersoek van komplekse of kritieke gevalle.
• 'N Iteratiewe benadering tot prompt ontwikkeling en toetsing: Prompt ingenieurswese moet behandel word as 'n iteratiewe proses waar elke weergawe van 'n prompt grondig getest en geëvalueer word voor implementering.
• Testing at different levels of abstraction:
  • Component testing: Individual modules (parsers, validators, API calls) and their integration.
  • Prompt testing: Isolated testing of prompts on various inputs.
  • Chain/Agent testing: Verifying the logic and interaction of components within an agent.
  • End-to-end system testing: Evaluating the completion of full user tasks.

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

Dit is 'n meta-beginsel; dit loop deur al die hierbo genoemde.

Gelukkig het ons vandag duisende gereedskap en raamwerke vir enige taak.Dit is groot, dit is gerieflik, en dit is 'n val.

Byna altyd beteken die keuse van 'n voorbereide oplossing 'ntrade-offJy kry spoed en 'n maklike begin, maar jy verloorflexibility, control, and, potentially, security.

Dit is veral belangrik in agentontwikkeling, waar dit belangrik is om te bestuur:

• die onvoorspelbaarheid van LLMs,
• komplekse logika vir oorgange en selfkorreksie,
• om gereed te wees vir die aanpassing en evolusie van die stelsel, selfs as sy kerntaak onveranderd bly.

Die raamwerk bringinversion of control: hulle besluit vir jou hoe die agent moet werk.Dit kan 'n prototipe vereenvoudig maar sy langtermynontwikkeling bemoeilyk.

Baie van die beginsels wat hierbo beskryf is, kan met behulp van off-the-shelf oplossings geïmplementeer word – en dit is dikwels regverdig.explicit implementation of the core logic takes a comparable amount of timeDit bied onvergelykbaar meertransparency, manageability, and adaptability.

Die teenoorgestelde uiterste bestaan ook -over-engineering, die begeerte om alles van nul af te skryf.Dit is ook 'n fout.

This is why the key is balance.Die ingenieur kies vir homself: waar dit redelik is om op 'n raamwerk te vertrou, en waar dit belangrik is om beheer te handhaaf.

Jy moet onthou: die bedryf neem nog vorm. Baie gereedskap is geskep voordat huidige standaarde verskyn het. môre kan hulle verouderd word - maar die beperkings wat vandag in jou argitektuur gebak het, sal bly.

Conclusion

Oke, ons het oor 15 beginsels wat, ervaring toon, help om die aanvanklike opwinding van "it's alive!" te verander in die vertroue dat jou LLM-agent op 'n stabiele, voorspelbare en nuttige manier sal werk onder werklike toestande.

Jy moet elke van hulle oorweeg om te sien of dit sinvol is om dit op jou projek toe te pas.

Key takeaways to carry with you:

1. 'N Ingenieursbenadering is die sleutel: Moenie op die "magie" van LLMs vertrou nie. struktuur, voorspelbaarheid, bestuurbaarheid en toetsbaarheid is jou beste vriende.
2. Die LLM is 'n kragtige komponent, maar steeds net 'n komponent: Behandel die LLM as 'n baie slim, maar tog, enkele komponent van jou stelsel.
3. Iterasie en terugvoer is die sleutels tot sukses: Dit is skaars om die perfekte agent op die eerste poging te skep. Wees voorbereid vir eksperimente, metings, fouteanalise en voortdurende verbetering - van beide die agent self en jou ontwikkelingsproses.
4. Gemeenskap en openheid: Die veld van LLM agente ontwikkel vinnig. Hou 'n oog op nuwe navorsing, gereedskap en beste praktyke, en deel jou eie ervarings.

Ek hoop dat jy hier iets nuuts en nuttigs gevind het, en miskien wil jy selfs hierna terugkom terwyl jy jou volgende agent ontwerp.