Hvordan bygge en AI-agent

Hvordan bygge en AI-agent

Kort svar: For å bygge en AI-agent som fungerer i praksis, behandle den som en kontrollert løkke: ta imot input, bestem neste handling, kall et verktøy med snevert omfang, observer resultatet og gjenta til en klar "ferdig"-sjekk består. Den fortjener sin plass når oppgaven er flertrinns og verktøydrevet; hvis en enkelt prompt løser den, hopp over agenten. Legg til strenge verktøyskjemaer, trinngrenser, logging og en validator/kritiker, slik at når verktøy feiler eller input er tvetydige, eskalerer agenten i stedet for å loope.

Viktige konklusjoner:

Kontrollersløyfe : Implementer input→act→observer repetisjon med eksplisitte stoppbetingelser og maks. trinn.

Verktøydesign : Hold verktøyene smale, typebestemte, tillatelsesbestemte og validerte for å forhindre «gjør_hva_som_som_du»-kaos.

Minnehygiene : Bruk kompakt korttidstilstand pluss langtidsgjenfinning; unngå å dumpe fullstendige transkripsjoner.

Motstand mot misbruk : Legg til tillatelseslister, hastighetsgrenser, idempotens og «tørrkjøring» for risikable handlinger.

Testbarhet : Oppretthold en scenarioserie (feil, tvetydighet, injeksjoner) og kjør på nytt ved hver endring.

Hvordan bygge en AI-agent? Infografikk
Artikler du kanskje vil lese etter denne:

🔗 Slik måler du AI-ytelse
Lær praktiske målinger for å måle hastighet, nøyaktighet og pålitelighet.

🔗 Hvordan snakke med AI
Bruk spørsmål, kontekst og oppfølging for å få bedre svar.

🔗 Hvordan evaluere AI-modeller
Sammenlign modeller ved hjelp av tester, rubrikker og resultater fra oppgaver i den virkelige verden.

🔗 Slik optimaliserer du AI-modeller
Forbedre kvalitet og kostnader med finjustering, beskjæring og overvåking.

1) Hva en AI-agent er, sett fra et vanlig menneskes perspektiv 🧠

En AI-agent er en løkke. LangChain «Agenter»-dokumentasjon

Det er det. En løkke med en hjerne i midten.

Input → tenk → handle → observer → gjenta . ReAct-oppgave (resonnering + handling)

Hvor:

  • Input er en brukerforespørsel eller en hendelse (ny e-post, supportbillett, sensorping).

  • Think er en språkmodell som resonnerer om neste steg.

  • Act kaller et verktøy (søk i interne dokumenter, kjør kode, opprett en sak, utkast til et svar). Veiledning for kalling av OpenAI-funksjoner

  • Observe leser verktøyets utdata.

  • Gjentakelse er den delen som får det til å føles «agentisk» i stedet for «pratsomt». LangChain «Agenter»-dokumentasjon

Noen agenter er i bunn og grunn smarte makroer. Andre fungerer mer som en junioroperatør som kan sjonglere oppgaver og gjenopprette feil. Begge deler teller.

Du trenger heller ikke full autonomi. Faktisk ... du vil sannsynligvis ikke ha det 🙃

2) Når du bør bygge en agent (og når du ikke bør) 🚦

Bygg en agent når:

  • Arbeidet er i flere trinn og endrer seg avhengig av hva som skjer underveis.

  • Jobben krever bruk av verktøy (databaser, CRM-er, kodeutførelse, filgenerering, nettlesere, interne API-er). LangChain «Verktøy»-dokumentasjon

  • Du ønsker repeterbare resultater med rekkverk, ikke bare engangsløsninger.

  • Du kan definere «ferdig» på en måte en datamaskin kan sjekke, selv løst.

Ikke bygg en agent når:

  • En enkel prompt + svar løser det (ikke overkonstruer, du kommer til å hate deg selv senere).

  • Du trenger perfekt determinisme (agenter kan være konsistente, men ikke robotiske).

  • Du har ingen verktøy eller data for å koble til – da er det stort sett bare vibber.

La oss være ærlige: halvparten av «AI-agentprosjekter» kan være en arbeidsflyt med noen få forgreningsregler. Men hei, noen ganger teller stemningen også 🤷♂️

3) Hva gjør en god versjon av en AI-agent ✅

Her er delen «Hva gjør en god versjon av» du ba om, bortsett fra at jeg skal være litt direkte:

En god versjon av en AI-agent er ikke den som tenker hardest. Det er den som:

Hvis agenten din ikke kan testes, er det i utgangspunktet en veldig selvsikker spilleautomat. Morsomt på fester, skremmende i produksjon 😬

4) De viktigste byggesteinene til en agent («anatomien» 🧩)

De fleste solide midler har disse delene:

A) Kontrollersløyfen 🔁

Dette er orkestratoren:

B) Verktøy (også kjent som evner) 🧰

Verktøy er det som gjør en agent effektiv: LangChain «Verktøy»-dokumentasjon

  • databasespørringer

  • sende e-poster

  • trekker filer

  • kjører kode

  • kaller interne API-er

  • skriving til regneark eller CRM-systemer

C) Minne 🗃️

To typer er viktige:

  • Korttidshukommelse : gjeldende løpeturkontekst, nylige skritt, gjeldende plan

  • Langtidshukommelse : brukerpreferanser, prosjektkontekst, hentet kunnskap (ofte via innebygde elementer + et vektorlager) RAG-oppgave

D) Planleggings- og beslutningspolicy 🧭

Selv om du ikke kaller det «planlegging», trenger du en metode:

E) Rekkverk og evaluering 🧯

Ja, det er mer ingeniørkunst enn å gi råd. Som jo er … litt av poenget.

5) Sammenligningstabell: populære måter å bygge en agent på 🧾

Nedenfor er en realistisk «sammenligningstabell» – med noen særegenheter, fordi ekte lag er særegne 😄

Verktøy / Rammeverk Publikum Pris Hvorfor det fungerer Notater (lite kaos)
LangChain byggere som liker lego-lignende komponenter gratis + infrarød stort økosystem for verktøy, minne og kjeder kan bli spaghetti-raskt hvis du ikke navngir ting tydelig
LamaIndeks RAG-tunge lag gratis + infrarød sterke hentemønstre, indeksering, koblinger flott når agenten din i utgangspunktet er «søk + handle» ... noe som er vanlig
OpenAI Assistants-stiltilnærming lag som ønsker raskere oppsett bruksbasert innebygde verktøyanropsmønstre og kjøretilstand mindre fleksibel i noen hjørner, men ren for mange apper OpenAI kjører API OpenAI Assistants-funksjonskall
Semantisk kjerne utviklere som ønsker strukturert orkestrering gratis-aktig pen abstraksjon for ferdigheter/funksjoner føles «ordentlig i bedriften» – noen ganger er det et kompliment 😉
AutoGen multiagent-eksperimentatorer gratis-aktig samarbeidsmønstre mellom agenter kan snakke for mye; sette strenge oppsigelsesregler
MannskapAI «Agentlag»-fans gratis-aktig roller + oppgaver + overleveringer er enkle å uttrykke fungerer best når oppgavene er sprø, ikke grøtete
Høystakk søke- og pipeline-folk gratis-aktig solide rørledninger, henting, komponenter mindre «agentteater», mer «praktisk fabrikk»
Rull-din-egen (tilpasset loop) kontrollfreaks (kjærlige) din tid minimal magi, maksimal klarhet vanligvis det beste på lang sikt ... helt til du gjenoppfinner alt 😅

Ingen enkelt vinner. Det beste valget avhenger av om agentens hovedoppgave er henting , verktøykjøring , koordinering mellom flere agenter eller automatisering av arbeidsflyt .

6) Hvordan bygge en AI-agent trinn for trinn (selve oppskriften) 🍳🤖

Dette er den delen folk flest hopper over, og så lurer de på hvorfor agenten oppfører seg som en vaskebjørn i et spiskammer.

Trinn 1: Definer jobben i én setning 🎯

Eksempler:

  • «Utkast et kundesvar ved å bruke retningslinjene og sakskonteksten, og be deretter om godkjenning.»

  • «Undersøk en feilrapport, reproduser den og foreslå en løsning.»

  • «Gjør ufullkomne møtenotater om til oppgaver, eiere og tidsfrister.»

Hvis du ikke kan definere det enkelt, kan ikke agenten din det heller. Jeg mener, den kan det, men den vil improvisere, og improvisasjon er der budsjettene går til spille.

Trinn 2: Bestem autonominivå (lav, middels, sterk) 🌶️

  • Lav autonomi : foreslår trinn, menneskelige klikk «godkjenner»

  • Medium : kjører verktøy, lager utkast til utdata, eskalerer ved usikkerhet

  • Høy : kjører ende-til-ende, pinger bare mennesker ved unntak

Start lavere enn du ønsker. Du kan alltids øke hastigheten senere.

Trinn 3: Velg modellstrategien din 🧠

Du velger vanligvis:

  • én sterk modell for alt (enkelt)

  • én sterk modell + mindre modell for billige trinn (klassifisering, ruting)

  • spesialiserte modeller (visjon, kode, tale) om nødvendig

Bestem også:

  • maks antall tokens

  • temperatur

  • om du tillater lange resonneringsspor internt (du kan, men ikke eksponer rå tankekjede for sluttbrukere)

Trinn 4: Definer verktøy med strenge skjemaer 🔩

Verktøy bør være:

I stedet for et verktøy som heter do_anything(input: string) , lag:

  • search_kb(spørring: streng) -> resultater[]

  • create_ticket(tittel: streng, kropp: streng, prioritet: enum) -> ticket_id

  • send_email(to: string, subject: string, body: string) -> status Veiledning for OpenAI-funksjonskall

Hvis du gir megleren en motorsag, ikke bli sjokkert når den trimmer en hekk ved å fjerne gjerdet også.

Trinn 5: Bygg kontrollerløkken 🔁

Minimumsløyfe:

  1. Start med mål + innledende kontekst

  2. Spør modellen: «Neste handling?»

  3. Hvis verktøykall - utfør verktøy

  4. Legg til observasjon

  5. Sjekk stopptilstanden

  6. Gjenta (med maks. trinn) LangChain-dokumentasjonen for «Agenter»

Legge til:

Trinn 6: Legg til minne forsiktig 🗃️

Kortsiktig: hold et kompakt «tilstandssammendrag» oppdatert for hvert trinn. LangChain «Minneoversikt»
Langsiktig: lagre varige fakta (brukerpreferanser, organisasjonsregler, stabile dokumenter).

Tommelfingerregel:

  • hvis det endrer seg ofte - hold det kortsiktig

  • hvis det er stabilt - oppbevar det på lang sikt

  • hvis det er sensitivt – oppbevar minimalt (eller ikke i det hele tatt)

Trinn 7: Legg til validering og et «kritiker»-pass 🧪

Et billig, praktisk mønster:

  • agent genererer resultat

  • validator sjekker struktur og begrensninger

  • valgfrie kritikermodellvurderinger for manglende trinn eller brudd på retningslinjene NIST AI RMF 1.0

Ikke perfekt, men den fanger opp en sjokkerende mengde tull.

Trinn 8: Logg alt du vil angre på at du ikke logget 📜

Logg:

Fremtiden – du vil takke deg. Nåtiden – du vil glemme. Sånn er bare livet 😵💫

7) Verktøykalling som ikke knuser sjelen din 🧰😵

Det er verktøyanrop som gjør at «Hvordan bygge en AI-agent» blir til ekte programvareutvikling.

Gjør verktøy pålitelige (pålitelig er bra)

Pålitelige verktøy er:

Legg til rekkverk på verktøylaget, ikke bare ledetekster

Instruksjoner er høflige forslag. Verktøyvalidering er en låst dør. OpenAI Strukturerte utdata

Gjøre:

  • tillatelseslister (hvilke verktøy kan kjøre)

  • validering av inndata

  • hastighetsgrenser OpenAI-veiledning for hastighetsgrenser

  • Tillatelseskontroller per bruker/organisasjon

  • «Tørrkjøringsmodus» for risikable handlinger

Design for delvis svikt

Verktøyene feiler. Nettverkene vingler. Autorisasjonen utløper. En agent må:

Et stille og effektivt triks: returner strukturerte feil som:

  • type: auth_error

  • type: ikke_funnet

  • type: rate_limited
    Slik at modellen kan reagere intelligent i stedet for å få panikk.

8) Minne som hjelper i stedet for å hjemsøke deg 👻🗂️

Minne er kraftig, men det kan også bli en skuff med søppel.

Korttidshukommelse: Hold den kompakt

Bruk:

  • siste N skritt

  • et løpende sammendrag (oppdateres hver løkke)

  • nåværende plan

  • nåværende begrensninger (budsjett, tid, retningslinjer)

Hvis du setter alt i kontekst, får du:

  • høyere kostnad

  • lavere ventetid

  • mer forvirring (ja, selv da)

Langtidshukommelse: gjenfinning fremfor «stuffing»

Det meste av «langtidshukommelsen» er mer som:

  • innebygginger

  • vektorbutikk

  • RAG-papir for utvidet generasjon av gjenfinning (RAG)

Agenten memorerer ikke. Den henter de mest relevante kodebitene under kjøring. LlamaIndex «Introduksjon til RAG»

Praktiske hukommelsesregler

  • Lagre «preferanser» som eksplisitte fakta: «Brukeren liker punktsammendrag og hater emojier» (lol, ikke her da 😄)

  • Lagre «beslutninger» med tidsstempler eller versjoner (ellers hoper det seg opp motsetninger)

  • Lagre aldri hemmeligheter med mindre du virkelig må

Og her er min ufullkomne metafor: minnet er som et kjøleskap. Hvis du aldri rengjør det, smaker smørbrødet ditt til slutt løk og anger.

9) Planleggingsmønstre (fra enkle til fancy) 🧭✨

Planlegging er bare kontrollert nedbrytning. Ikke gjør det mystisk.

Mønster A: Sjekklisteplanlegger ✅

  • Modellen viser en liste over trinn

  • Utføres trinn for trinn

  • Oppdaterer status for sjekkliste

Flott for onboarding. Enkelt og testbart.

Mønster B: ReAct-løkke (grunn + handling) 🧠→🧰

  • modellen bestemmer neste verktøykall

  • observerer utdata

  • gjentar ReAct-papiret

Dette er den klassiske agentfølelsen.

Mønster C: Veileder-arbeider 👥

Dette er verdifullt når oppgaver kan parallelliseres, eller når du ønsker forskjellige «roller» som:

  • forsker

  • koder

  • redaktør

  • QA-kontrollør

Mønster D: Planlegg-så-utfør med omplanlegging 🔄

  • lage en plan

  • henrette

  • Hvis verktøyresultatene endrer virkeligheten, planlegg på nytt

Dette hindrer agenten i å følge en dårlig plan. Mennesker gjør dette også, med mindre de er slitne, og i så fall følger de også dårlige planer.

10) Sikkerhet, pålitelighet og å ikke bli oppsagt 🔐😅

Hvis agenten din kan iverksette tiltak, trenger du sikkerhetsdesign. Ikke «kjekt å ha». Trenger du. NIST AI RMF 1.0

Harde grenser

  • maks skritt per løp

  • maks verktøyanrop per minutt

  • maks. forbruk per økt (tokenbudsjett)

  • begrensede verktøy bak godkjenning

Datahåndtering

  • rediger sensitive inndata før logging

  • separate miljøer (utvikling vs. produksjon)

  • verktøytillatelser med minst privilegier

Atferdsmessige begrensninger

  • tvinge agenten til å sitere interne bevisutdrag (ikke eksterne lenker, bare interne referanser)

  • krever usikkerhetsflagg når tilliten er lav

  • krever «still et avklarende spørsmål» hvis inndataene er tvetydige

En pålitelig agent er ikke den mest selvsikre. Det er den som vet når den gjetter ... og sier det.

11) Testing og evaluering (den delen alle unngår) 🧪📏

Du kan ikke forbedre det du ikke kan måle. Ja, den linjen er litt klisjéfylt, men den er irriterende sann.

Bygg et scenariosett

Lag 30–100 testtilfeller:

Poengsumresultater

Bruk målinger som:

  • suksessrate for oppgaver

  • tid til fullføring

  • gjenopprettingsrate for verktøyfeil

  • hallusinasjonsrate (påstander uten bevis)

  • menneskelig godkjenningsrate (hvis i overvåket modus)

Regresjonstester for prompter og verktøy

Hver gang du endrer deg:

  • verktøyskjema

  • systeminstruksjoner

  • hentelogikk

  • minneformat
    Kjør programmet på nytt.

Agenter er følsomme beist. Som stueplanter, men dyrere.

12) Implementeringsmønstre som ikke smelter budsjettet ditt 💸🔥

Start med én enkelt tjeneste

Legg til kostnadskontroller tidlig

  • resultater for henting i mellomlagring

  • komprimering av samtalestatus med sammendrag

  • bruk av mindre modeller for fresing og uttrekking

  • å begrense «dyp tenkningsmodus» til de vanskeligste trinnene

Vanlig arkitekturvalg

  • tilstandsløs kontroller + ekstern tilstandslager (DB/redis)

  • Verktøykall er idempotente der det er mulig Stripe «Idempotente forespørsler»

  • kø for lange oppgaver (slik at du ikke holder en nettforespørsel åpen for alltid)

Også: bygg en «kill switch». Du trenger den ikke før du virkelig, virkelig trenger den 😬

13) Avsluttende notater – kortversjonen av hvordan man bygger en AI-agent 🎁🤖

Hvis du ikke husker noe annet, husk dette:

En agent er ikke magi. Det er et system som tar gode avgjørelser ofte nok til å være verdifullt ... og innrømmer nederlag før det forårsaker skade. Stille og trøstende, på en måte 😌

Og ja, hvis du bygger det riktig, føles det som å ansette en liten digital praktikant som aldri sover, av og til får panikk og elsker papirarbeid. Så, i bunn og grunn en praktikant.

Vanlige spørsmål

Hva er en AI-agent, enkelt sagt?

En AI-agent er i bunn og grunn en løkke som gjentar seg: tar imot input, bestemmer neste trinn, bruker et verktøy, leser resultatet og gjentar til det er ferdig. Den «agentiske» delen kommer fra å handle og observere, ikke bare chatte. Mange agenter er bare smart automatisering med verktøytilgang, mens andre oppfører seg mer som en junioroperatør som kan gjenopprette feil.

Når bør jeg bygge en AI-agent i stedet for bare å bruke en ledetekst?

Bygg en agent når arbeidet er flertrinns, endringer er basert på mellomresultater og krever pålitelig verktøybruk (API-er, databaser, ticketing, kodekjøring). Agenter er også nyttige når du ønsker repeterbare resultater med beskyttelsesmekanismer og en måte å sjekke «ferdig» på. Hvis en enkel promptrespons fungerer, er en agent vanligvis unødvendig overhead og ekstra feilmoduser.

Hvordan bygger jeg en AI-agent som ikke setter seg fast i løkker?

Bruk harde stoppbetingelser: maks antall trinn, maks antall verktøykall og tydelige fullføringskontroller. Legg til strukturerte verktøyskjemaer, tidsavbrudd og nye forsøk som ikke vil prøve på nytt for alltid. Logg beslutninger og verktøyutdata slik at du kan se hvor det sporer av. En vanlig sikkerhetsventil er eskalering: hvis agenten er usikker eller gjentar feil, bør den be om hjelp i stedet for å improvisere.

Hva er minimumsarkitekturen for Hvordan bygge en AI-agent?

Som et minimum trenger du en kontrollerløkke som mater modellen med et mål og en kontekst, ber om neste handling, utfører et verktøy hvis det blir bedt om det, legger til observasjonen og gjentar. Du trenger også verktøy med strenge input/output-former og en "ferdig"-sjekk. Selv en roll-your-own-løkke kan fungere bra hvis du holder tilstanden ren og håndhever trinngrenser.

Hvordan bør jeg designe verktøykall slik at det er pålitelig i produksjon?

Hold verktøyene smale, typebestemte, tillatelsesbestemte og validerte – unngå et generisk «gjør_hva_som_som_du»-verktøy. Foretrekk strenge skjemaer (som strukturerte utganger/funksjonskall) slik at agenten ikke kan sende inndata manuelt. Legg til tillatelseslister, hastighetsgrenser og tillatelseskontroller for brukere/organisasjoner på verktøylaget. Design verktøy som er trygge å kjøre på nytt når det er mulig, ved hjelp av idempotensmønstre.

Hva er den beste måten å legge til minne uten å gjøre agenten verre?

Behandle hukommelse som to deler: kortsiktig kjøretilstand (nylige trinn, gjeldende plan, begrensninger) og langsiktig gjenfinning (preferanser, stabile regler, relevante dokumenter). Hold kortsiktig kompakt med løpende sammendrag, ikke fullstendige transkripsjoner. For langtidshukommelse er gjenfinning (innebygginger + vektorlagring/RAG-mønstre) vanligvis bedre enn å "proppe" alt inn i kontekst og forvirre modellen.

Hvilket planleggingsmønster bør jeg bruke: sjekkliste, ReAct eller veileder-arbeider?

En sjekklisteplanlegger er flott når oppgaver er forutsigbare og du ønsker noe som er enkelt å teste. ReAct-lignende løkker er nyttige når verktøyresultater endrer hva du gjør videre. Leder-arbeider-mønstre (som rolleseparasjon i AutoGen-stil) hjelper når oppgaver kan parallelliseres eller dra nytte av forskjellige roller (forsker, koder, QA). Planlegg-og-utfør med omplanlegging er en praktisk mellomvei for å unngå gjenstridige dårlige planer.

Hvordan gjør jeg en agent trygg hvis den kan iverksette reelle handlinger?

Bruk tillatelser med minst mulig rettigheter og begrens risikable verktøy bak godkjennings- eller «testmoduser». Legg til budsjetter og grenser: maks trinn, maks utgifter og grenser for verktøyanrop per minutt. Fjern sensitive data før logging, og skill utviklings- fra produksjonsmiljøer. Krev usikkerhetsflagg eller avklarende spørsmål når inndataene er tvetydige, i stedet for å la tillit erstatte bevis.

Hvordan tester og evaluerer jeg en AI-agent slik at den forbedres over tid?

Bygg en scenariopakke med lykkelige baner, kanttilfeller, verktøyfeil, tvetydige forespørsler og forsøk på promptinjeksjon (OWASP-stil). Vurder utfall som oppgavesuksess, tid til fullføring, gjenoppretting fra verktøyfeil og påstander uten bevis. Hver gang du endrer verktøyskjemaer, prompter, henting eller minneformatering, kjør pakken på nytt. Hvis du ikke kan teste den, kan du ikke levere den pålitelig.

Hvordan distribuerer jeg en agent uten å øke ventetiden og kostnadene?

Et vanlig mønster er en tilstandsløs kontroller med et eksternt tilstandslager (DB/Redis), verktøytjenester bak seg og sterk logging/overvåking (ofte OpenTelemetry). Kontroller kostnader med hentehurtigbuffering, kompakte tilstandssammendrag, mindre modeller for ruting/utvinning og begrensning av «dyp tenkning» til de vanskeligste trinnene. Bruk køer for lange oppgaver, slik at du ikke holder nettforespørsler åpne. Inkluder alltid en kill switch.

Referanser

  1. Nasjonalt institutt for standarder og teknologi (NIST) - NIST AI RMF 1.0 (pålitelighet og åpenhet) - nvlpubs.nist.gov

  2. OpenAI – Strukturerte utdata – platform.openai.com

  3. OpenAI – Veiledning for funksjonskall – platform.openai.com

  4. OpenAI – Veiledning for hastighetsgrenser – platform.openai.com

  5. OpenAI - Kjører API - platform.openai.com

  6. OpenAI – Funksjonskall for assistenter – platform.openai.com

  7. LangChain – Agenter-dokumentasjon (JavaScript) – docs.langchain.com

  8. LangChain – Verktøydokumentasjon (Python) – docs.langchain.com

  9. LangChain - Minneoversikt - docs.langchain.com

  10. arXiv - ReAct-artikkel (begrunnelse + handling) - arxiv.org

  11. arXiv - RAG-artikkel - arxiv.org

  12. Amazon Web Services (AWS) Builders' Library – Tidsavbrudd, nye forsøk og tilbaketrekking med jitter – aws.amazon.com

  13. OpenTelemetry – Observerbarhetsgrunnlag – opentelemetry.io

  14. Stripe - Idempotente forespørsler - docs.stripe.com

  15. Google Cloud – Strategi for nytt forsøk (backoff + jitter) – docs.cloud.google.com

  16. OWASP – Topp 10 for store språkmodellapplikasjoner – owasp.org

  17. OWASP - LLM01 Rask injeksjon - genai.owasp.org

  18. LlamaIndex – Introduksjon til RAG – utviklere.llamaindex.ai

  19. Microsoft – Semantisk kjerne – learn.microsoft.com

  20. Microsoft AutoGen – Rammeverk for flere agenter (dokumentasjon) – microsoft.github.io

  21. CrewAI – Agentkonsepter – docs.crewai.com

  22. Haystack (deepset) - Dokumentasjon for apportører - docs.haystack.deepset.ai

Finn den nyeste AI-en i den offisielle AI-assistentbutikken

Om oss

Tilbake til bloggen