Sådan opbygger du en AI-agent

Sådan opbygger du en AI-agent

Kort svar: For at bygge en AI-agent, der fungerer i praksis, skal du behandle den som et kontrolleret loop: tag input, beslut den næste handling, kald et snævert afgrænset værktøj, observer resultatet, og gentag, indtil en klar "udført"-kontrol består. Den tjener sin plads, når opgaven er flertrins og værktøjsdrevet; hvis en enkelt prompt løser den, skal du springe agenten over. Tilføj strenge værktøjsskemaer, tringrænser, logføring og en validator/kritiker, så når værktøjer fejler, eller input er tvetydige, eskalerer agenten i stedet for at loope.

Vigtige konklusioner:

Controller-loop : Implementer input→act→observer gentagelse med eksplicitte stopbetingelser og maksimale trin.

Værktøjsdesign : Hold værktøjerne begrænsede, typebestemte, tilladelsesbaserede og validerede for at forhindre "gør_hvad_som_du_gør"-kaos.

Hukommelseshygiejne : Brug kompakt korttidstilstand plus langtidshentning; undgå at dumpe fulde transkripter.

Modstand mod misbrug : Tilføj tilladelseslister, hastighedsgrænser, idempotens og "tørkørsel" for risikable handlinger.

Testbarhed : Vedligehold en scenariesuite (fejl, tvetydighed, injektioner) og genkør ved hver ændring.

Hvordan opbygger man en AI-agent? Infografik
Artikler du måske har lyst til at læse efter denne:

🔗 Sådan måler du AI-ydeevne
Lær praktiske målinger til at måle hastighed, nøjagtighed og pålidelighed.

🔗 Sådan taler du med AI
Brug prompts, kontekst og opfølgninger for at få bedre svar.

🔗 Sådan evaluerer du AI-modeller
Sammenlign modeller ved hjælp af tests, rubrikker og resultater fra den virkelige verden.

🔗 Sådan optimerer du AI-modeller
Forbedr kvalitet og omkostninger med finjustering, beskæring og overvågning.

1) Hvad en AI-agent er, set ud fra et almindeligt menneskes synspunkt 🧠

En AI-agent er et loop. LangChain “Agenter”-dokumentation

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

Input → tænk → handl → observer → gentag . ReAct-papir (ræsonnement + handling)

Hvor:

  • Inputtet er en brugeranmodning eller en hændelse (ny e-mail, supportticket, sensorping).

  • Think er en sprogmodel, der ræsonnerer om det næste skridt.

  • Act kalder et værktøj (søg i interne dokumenter, kør kode, opret en ticket, udkast til et svar). Vejledning til kald af OpenAI-funktioner

  • Observe læser værktøjets output.

  • Gentagelse er den del, der får det til at føles "agentisk" i stedet for "snakkeligt". LangChain "Agenter"-dokumentation

Nogle agenter er dybest set smarte makroer. Andre fungerer mere som en junioroperatør, der kan jonglere opgaver og rette op på fejl. Begge dele tæller.

Du behøver heller ikke fuld autonomi. Faktisk ... du ønsker det sandsynligvis ikke 🙃

2) Hvornår du bør opbygge en agent (og hvornår du ikke bør) 🚦

Opbyg en agent når:

  • Arbejdet er i flere trin og ændrer sig afhængigt af, hvad der sker undervejs.

  • Jobbet kræver brug af værktøjer (databaser, CRM'er, kodeudførelse, filgenerering, browsere, interne API'er). LangChain "Værktøjer"-dokumentation

  • Du ønsker gentagelige resultater med rækværk, ikke bare engangsløsninger.

  • Du kan definere "færdig" på en måde, som en computer kan kontrollere, selv løst.

Opret ikke en agent, når:

  • En simpel prompt + svar løser det (overkonstruer ikke, du vil hade dig selv senere).

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

  • Du har ingen værktøjer eller data til at oprette forbindelse – så er det mest bare vibrationer.

Lad os være ærlige: halvdelen af ​​"AI-agentprojekter" kunne være en arbejdsgang med et par forgreningsregler. Men hey, nogle gange betyder stemningen også noget 🤷♂️

3) Hvad gør en god version af en AI-agent ✅

Her er afsnittet "Hvad gør en god version af", du bad om, bortset fra at jeg vil være lidt direkte:

En god version af en AI-agent er ikke den, der tænker hårdest. Det er den, der:

Hvis din agent ikke kan testes, er det dybest set en meget selvsikker spillemaskine. Sjov til fester, skræmmende i produktion 😬

4) De centrale byggesten i en agent ("anatomien" 🧩)

De fleste solide stoffer har disse dele:

A) Controller-løkken 🔁

Dette er orkestratoren:

B) Værktøjer (også kendt som muligheder) 🧰

Værktøjer er det, der gør en agent effektiv: LangChain “Værktøjer”-dokumentation

  • databaseforespørgsler

  • afsendelse af e-mails

  • trækker filer

  • kørende kode

  • kald af interne API'er

  • skrivning til regneark eller CRM-systemer

C) Hukommelse 🗃️

To slags har betydning:

  • Korttidshukommelse : den aktuelle løbeturkontekst, seneste skridt, nuværende plan

  • Langtidshukommelse : brugerpræferencer, projektkontekst, hentet viden (ofte via indlejringer + et vektorlager) RAG-papir

D) Planlægnings- og beslutningspolitik 🧭

Selv hvis du ikke kalder det "planlægning", har du brug for en metode:

E) Autoværn og evaluering 🧯

Ja, det er mere ingeniørarbejde end at give et forslag. Hvilket jo… ligesom er pointen.

5) Sammenligningstabel: populære måder at opbygge en agent på 🧾

Nedenfor er en realistisk "sammenligningstabel" - med et par særheder, fordi rigtige hold er finurlige 😄

Værktøj / Framework Målgruppe Pris Hvorfor det virker Noter (lille kaos)
LangChain bygherrer, der kan lide lego-lignende komponenter gratis + infrarød stort økosystem for værktøjer, hukommelse og kæder kan blive spaghettihurtig, hvis man ikke navngiver tingene tydeligt
LlamaIndeks RAG-tunge hold gratis + infrarød stærke hentningsmønstre, indeksering, forbindelser Fantastisk, når din agent grundlæggende er "søg + handle" ... hvilket er almindeligt
OpenAI Assistants-stiltilgang hold, der ønsker hurtigere opsætning brugsbaseret indbyggede værktøjsopkaldsmønstre og kørselstilstand mindre fleksibel i nogle hjørner, men ren for mange apps OpenAI kører API OpenAI Assistants-funktionskald
Semantisk kerne udviklere, der ønsker struktureret orkestrering frit-agtigt pæn abstraktion for færdigheder/funktioner føles "ordentlig i virksomheden" - nogle gange er det en kompliment 😉
AutoGen multi-agent eksperimentatorer frit-agtigt samarbejdsmønstre mellem agenter kan overtale; sætte strenge opsigelsesregler
CrewAI "Hold af agenter"-fans frit-agtigt roller + opgaver + overdragelser er lette at udtrykke Fungerer bedst, når opgaverne er sprøde, ikke bløde
Høstak søge- og pipeline-folk frit-agtigt solide rørledninger, hentning, komponenter mindre "agentteater", mere "praktisk fabrik"
Rul-din-egen (brugerdefineret loop) kontrolfreaks (kærlige) din tid minimal magi, maksimal klarhed normalt det bedste på lang sigt ... indtil du genopfinder alting 😅

Ingen enkelt vinder. Det bedste valg afhænger af, om din agents primære opgave er hentning , værktøjsudførelse , koordinering med flere agenter eller automatisering af arbejdsgange .

6) Sådan bygger du en AI-agent trin for trin (den faktiske opskrift) 🍳🤖

Det er den del, de fleste springer over, og derefter undrer sig over, hvorfor agenten opfører sig som en vaskebjørn i et spisekammer.

Trin 1: Definer jobbet i én sætning 🎯

Eksempler:

  • "Udarbejd et kundesvar ved hjælp af politik- og sagskontekst, og bed derefter om godkendelse."

  • "Undersøg en fejlrapport, reproducer den og foreslå en løsning."

  • "Forvandl ufuldkomne mødenotater til opgaver, ejere og deadlines."

Hvis du ikke kan definere det enkelt, kan din agent heller ikke. Jeg mener, den kan, men den vil improvisere, og improvisation er der, hvor budgetterne ender.

Trin 2: Bestem autonominiveau (lav, medium, stærk) 🌶️

  • Lav autonomi : foreslår trin, menneskelige klik "godkend"

  • Medium : kører værktøjer, udarbejder output, eskalerer ved usikkerhed

  • Høj : udfører end-to-end, pinger kun mennesker ved undtagelser

Start lavere end du ønsker. Du kan altid skrue op for hastigheden senere.

Trin 3: Vælg din modelstrategi 🧠

Du vælger typisk:

  • én stærk model for alting (simpelt)

  • en stærk model + mindre model til billige trin (klassificering, routing)

  • specialiserede modeller (vision, kode, tale) hvis nødvendigt

Beslut også:

  • maks. antal tokens

  • temperatur

  • om du tillader lange ræsonnementsspor internt (du kan, men eksponér ikke rå tankekæder for slutbrugere)

Trin 4: Definer værktøjer med strenge skemaer 🔩

Værktøjer bør være:

I stedet for et værktøj kaldet do_anything(input: string) , lav:

  • search_kb(forespørgsel: streng) -> resultater[]

  • create_ticket(titel: streng, krop: streng, prioritet: enum) -> ticket_id

  • send_email(to: string, subject: string, body: string) -> status Vejledning til kald af OpenAI-funktioner

Hvis du giver agenten en motorsav, så bliv ikke overrasket, når den trimmer en hæk ved også at fjerne hegnet.

Trin 5: Byg controller-løkken 🔁

Minimumsløjfe:

  1. Start med mål + indledende kontekst

  2. Spørg modellen: "Næste handling?"

  3. Hvis værktøjskald - udfør værktøj

  4. Tilføj observation

  5. Kontroller stoptilstand

  6. Gentag (med maks. trin) LangChain “Agents”-dokumentationen

Tilføje:

Trin 6: Tilføj hukommelse forsigtigt 🗃️

Kortsigtet: Hold et kompakt "tilstandsresumé" opdateret ved hvert trin. LangChain "Hukommelsesoversigt".
Langsigtet: Gem varige fakta (brugerpræferencer, organisationsregler, stabile dokumenter).

Tommelfingerregel:

  • hvis det ændrer sig ofte - hold det kortsigtet

  • hvis det er stabilt - opbevar det i lang tid

  • hvis det er følsomt - opbevar minimalt (eller slet ikke)

Trin 7: Tilføj validering og et "kritik"-passage 🧪

Et billigt, praktisk mønster:

  • agent genererer resultat

  • validator kontrollerer struktur og begrænsninger

  • valgfrie kritikermodeller for manglende trin eller politikovertrædelser NIST AI RMF 1.0

Ikke perfekt, men den fanger en chokerende mængde vrøvl.

Trin 8: Log alt, hvad du vil fortryde ikke at have logget 📜

Log:

  • værktøjskald + input + output

  • beslutninger truffet

  • fejl

  • endelige resultater

  • Primer til observation af tokens og latenstid

Fremtiden - du vil takke dig. Nutiden - du vil glemme. Sådan er livet bare 😵💫

7) Værktøjskald der ikke knækker din sjæl 🧰😵

Værktøjsopkald er hvor "Sådan bygger du en AI-agent" bliver til ægte softwareudvikling.

Gør værktøjer pålidelige (pålideligt er godt)

Pålidelige værktøjer er:

Tilføj beskyttelsesrækværk på værktøjslaget, ikke kun prompter

Prompter er høflige forslag. Værktøjsvalidering er en låst dør. OpenAI Strukturerede output

Gør:

  • tilladelseslister (hvilke værktøjer kan køre)

  • inputvalidering

  • hastighedsgrænser OpenAI vejledning til hastighedsgrænser

  • Tilladelsestjek pr. bruger/organisation

  • "Dry-run mode" til risikable handlinger

Design til delvis svigt

Værktøjer fejler. Netværk vakler. Godkendelse udløber. En agent skal:

Et stille og effektivt trick: returner strukturerede fejl som:

  • type: auth_error

  • type: ikke_fundet

  • type: rate_limited
    Så modellen kan reagere intelligent i stedet for at gå i panik.

8) Hukommelser der hjælper i stedet for at hjemsøge dig 👻🗂️

Hukommelse er kraftfuld, men den kan også blive en skrammelskuffe.

Korttidshukommelse: Hold den kompakt

Bruge:

  • sidste N skridt

  • en løbende opsummering (opdateres hvert loop)

  • nuværende plan

  • nuværende begrænsninger (budget, tid, politikker)

Hvis man sætter alt i kontekst, får man:

  • højere omkostninger

  • langsommere latenstid

  • mere forvirring (ja, selv da)

Langtidshukommelse: genfinding frem for "udstopning"

Det meste af "langtidshukommelsen" er mere som:

  • indlejringer

  • vektorbutik

  • hentningsforstærket generation (RAG) RAG-papir

Agenten husker ikke. Den henter de mest relevante uddrag under kørsel. LlamaIndex “Introduktion til RAG”

Praktiske hukommelsesregler

  • Gem "præferencer" som eksplicitte fakta: "Brugeren kan lide punktformede resuméer og hader emojis" (lol, ikke her dog 😄)

  • Gem "beslutninger" med tidsstempler eller versioner (ellers hober modsigelser sig op)

  • Gem aldrig hemmeligheder, medmindre du virkelig er nødt til det

Og her er min uperfekte metafor: hukommelse er som et køleskab. Hvis du aldrig rengør det, smager din sandwich til sidst af løg og fortrydelse.

9) Planlægningsmønstre (fra simple til fancy) 🧭✨

Planlægning er blot kontrolleret nedbrydning. Gør det ikke mystisk.

Mønster A: Tjeklisteplanlægger ✅

  • Modellen udskriver en liste over trin

  • Udføres trin for trin

  • Opdaterer status for tjekliste

God til onboarding. Enkel og testbar.

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

  • modellen bestemmer næste værktøjskald

  • observerer output

  • gentager ReAct-papiret

Dette er den klassiske agentfølelse.

Mønster C: Supervisor-medarbejder 👥

Dette er værdifuldt, når opgaver kan paralleliseres, eller når du ønsker forskellige "roller" som:

  • forsker

  • koder

  • redaktør

  • QA-tjekker

Mønster D: Planlæg-så-udfør med omplanlægning 🔄

  • opret plan

  • udføre

  • Hvis værktøjsresultaterne ændrer virkeligheden, skal du omplanlægge

Dette forhindrer agenten i stædigt at følge en dårlig plan. Mennesker gør det samme, medmindre de er trætte, i hvilket tilfælde de også følger dårlige planer.

10) Sikkerhed, pålidelighed og ikke at blive fyret 🔐😅

Hvis din agent kan handle, har du brug for sikkerhedsdesign. Ikke "rart at have". Behov for NIST AI RMF 1.0

Hårde grænser

  • maksimale skridt pr. løb

  • maks. værktøjsopkald pr. minut

  • maksimalt forbrug pr. session (tokenbudget)

  • begrænsede værktøjer bag godkendelse

Datahåndtering

  • rediger følsomme input før logføring

  • separate miljøer (udvikling vs. produktion)

  • værktøjstilladelser med færrest rettigheder

Adfærdsmæssige begrænsninger

  • tvinge agenten til at citere interne bevisuddrag (ikke eksterne links, kun interne referencer)

  • kræver usikkerhedsflag, når tilliden er lav

  • kræve "stil et afklarende spørgsmål", hvis input er tvetydige

En pålidelig agent er ikke den mest selvsikre. Det er den, der ved, hvornår den gætter ... og siger det.

11) Test og evaluering (den del alle undgår) 🧪📏

Du kan ikke forbedre det, du ikke kan måle. Ja, den sætning er lidt klichéagtig, men den er irriterende sand.

Byg et scenariesæt

Opret 30-100 testcases:

Scoreresultater

Brug målinger som:

  • succesrate for opgaven

  • tid til færdiggørelse

  • gendannelsesrate for værktøjsfejl

  • hallucinationsrate (påstande uden beviser)

  • menneskelig godkendelsesrate (hvis i overvåget tilstand)

Regressionstests for prompts og værktøjer

Hver gang du ændrer dig:

  • værktøjsskema

  • systeminstruktioner

  • hentningslogik

  • hukommelsesformat
    Kør pakken igen.

Agenter er følsomme bæster. Ligesom stueplanter, men dyrere.

12) Implementeringsmønstre, der ikke smelter dit budget 💸🔥

Start med en enkelt tjeneste

Tilføj omkostningsstyring tidligt

  • cache-hentningsresultater

  • komprimering af samtaletilstand med resuméer

  • brug af mindre modeller til fræsning og udtrækning

  • begrænser "dyb tænkningstilstand" til de sværeste trin

Fælles arkitekturvalg

  • statsløs controller + ekstern tilstandslager (DB/redis)

  • Værktøjskald er idempotente hvor det er muligt Stripe “Idempotente anmodninger”

  • kø til lange opgaver (så du ikke holder en webanmodning åben for evigt)

Også: byg en "afbryder". Du får ikke brug for den, før du virkelig, virkelig har brug for den 😬

13) Afsluttende noter - den korte version af, hvordan man opbygger en AI-agent 🎁🤖

Hvis du ikke kan huske andet, så husk dette:

En agent er ikke magi. Det er et system, der træffer gode beslutninger ofte nok til at være værdifuldt ... og indrømmer nederlag, før det forårsager skade. Stille og roligt trøstende, på en måde 😌

Og ja, hvis man bygger det rigtigt op, føles det som at ansætte en lille digital praktikant, der aldrig sover, af og til går i panik og elsker papirarbejde. Så, dybest set en praktikant.

Ofte stillede spørgsmål

Hvad er en AI-agent, kort sagt?

En AI-agent er dybest set et loop, der gentager sig: tager input, beslutter det næste trin, bruger et værktøj, læser resultatet og gentager, indtil det er færdigt. Den "agentiske" del kommer fra at handle og observere, ikke bare chatte. Mange agenter er blot smart automatisering med værktøjsadgang, mens andre opfører sig mere som en junioroperatør, der kan komme sig over fejl.

Hvornår skal jeg bygge en AI-agent i stedet for blot at bruge en prompt?

Byg en agent, når arbejdet er flertrins, ændringer er baseret på mellemresultater og kræver pålidelig værktøjsbrug (API'er, databaser, ticketing, kodeudførelse). Agenter er også nyttige, når du ønsker gentagelige resultater med beskyttelsesforanstaltninger og en måde at kontrollere "udført". Hvis et simpelt prompt-respons fungerer, er en agent normalt unødvendig overhead og ekstra fejltilstande.

Hvordan bygger jeg en AI-agent, der ikke sidder fast i løkker?

Brug hårde stopbetingelser: maks. antal trin, maks. antal værktøjskald og klare færdiggørelseskontroller. Tilføj strukturerede værktøjsskemaer, timeouts og gentagne forsøg, der ikke forsøger for evigt. Log beslutninger og værktøjsoutput, så du kan se, hvor det går galt. En almindelig sikkerhedsventil er eskalering: hvis agenten er usikker eller gentager fejl, bør den bede om hjælp i stedet for at improvisere.

Hvad er minimumsarkitekturen for "Sådan bygger du en AI-agent"?

Som minimum har du brug for en controller-loop, der giver modellen et mål og en kontekst, beder om den næste handling, udfører et værktøj, hvis det bliver bedt om det, tilføjer observationen og gentager. Du har også brug for værktøjer med strenge input/output-former og en "udført"-kontrol. Selv en roll-your-own-loop kan fungere godt, hvis du holder tilstanden ren og håndhæver tringrænser.

Hvordan skal jeg designe værktøjskald, så det er pålideligt i produktion?

Hold værktøjerne begrænsede, typebestemte, tilladelsesbaserede og validerede – undgå et generisk "gør_hvad_som_du_gør-det-selv"-værktøj. Foretræk strenge skemaer (som strukturerede output/funktionskald), så agenten ikke kan sende input manuelt. Tilføj tilladelseslister, hastighedsgrænser og bruger-/organisationstilladelseskontroller på værktøjslaget. Design værktøjer, der er sikre at genkøre, når det er muligt, ved hjælp af idempotensmønstre.

Hvad er den bedste måde at tilføje hukommelse uden at forværre agenten?

Behandl hukommelse som to dele: kortsigtet kørselstilstand (seneste trin, nuværende plan, begrænsninger) og langsigtet hentning (præferencer, stabile regler, relevante dokumenter). Hold kortsigtet kompakt med løbende resuméer, ikke fulde transkripter. For langtidshukommelse er hentning (indlejringer + vektorlagring/RAG-mønstre) normalt bedre end at "proppe" alt ind i kontekst og forvirre modellen.

Hvilket planlægningsmønster skal jeg bruge: tjekliste, ReAct eller supervisor-medarbejder?

En tjeklisteplanlægger er fantastisk, når opgaver er forudsigelige, og du ønsker noget, der er nemt at teste. ReAct-lignende loops er fremragende, når værktøjsresultater ændrer, hvad du gør derefter. Supervisor-medarbejder-mønstre (som rolleadskillelse i AutoGen-stil) hjælper, når opgaver kan paralleliseres eller drage fordel af forskellige roller (forsker, koder, QA). Planlæg-og-udfør med genplanlægning er en praktisk mellemvej for at undgå genstridige dårlige planer.

Hvordan gør jeg en agent sikker, hvis den kan foretage reelle handlinger?

Brug tilladelser med færrest rettigheder, og begræns risikable værktøjer bag godkendelses- eller "test"-tilstande. Tilføj budgetter og grænser for: maksimale trin, maksimale forbrug og grænser for værktøjskald pr. minut. Redigér følsomme data før logføring, og adskil udviklings- fra produktionsmiljøer. Kræv usikkerhedsflag eller afklarende spørgsmål, når input er tvetydige, i stedet for at lade tillid erstatte beviser.

Hvordan tester og evaluerer jeg en AI-agent, så den forbedres over tid?

Byg en scenariesuite med "happy paths", "edge cases", værktøjsfejl, tvetydige anmodninger og forsøg på promptinjektion (OWASP-stil). Score resultater som opgavesucces, tid til færdiggørelse, gendannelse fra værktøjsfejl og påstande uden bevis. Hver gang du ændrer værktøjsskemaer, prompter, hentning eller hukommelsesformatering, skal du køre pakken igen. Hvis du ikke kan teste den, kan du ikke levere den pålideligt.

Hvordan implementerer jeg en agent uden at øge latenstid og omkostninger?

Et almindeligt mønster er en statsløs controller med et eksternt tilstandslager (DB/Redis), værktøjstjenester bagved og stærk logging/overvågning (ofte OpenTelemetry). Kontroller omkostninger med hentningscaching, kompakte tilstandsoversigter, mindre modeller til routing/udtrækning og begrænsning af "dyb tænkning" til de sværeste trin. Brug køer til lange opgaver, så du ikke holder webanmodninger åbne. Inkluder altid en kill switch.

Referencer

  1. National Institute of Standards and Technology (NIST) - NIST AI RMF 1.0 (troværdighed og gennemsigtighed) - nvlpubs.nist.gov

  2. OpenAI - Strukturerede output - platform.openai.com

  3. OpenAI - Guide til funktionskald - platform.openai.com

  4. OpenAI - Guide til hastighedsgrænser - platform.openai.com

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

  6. OpenAI - Funktionskald til assistenter - platform.openai.com

  7. LangChain - Agenter dokumentation (JavaScript) - docs.langchain.com

  8. LangChain - Værktøjsdokumentation (Python) - docs.langchain.com

  9. LangChain - Oversigt over hukommelse - docs.langchain.com

  10. arXiv - ReAct-artikel (begrundelse + handling) - arxiv.org

  11. arXiv - RAG-artikel - arxiv.org

  12. Amazon Web Services (AWS) Builders' Library - Timeouts, genforsøg og backoff med jitter - aws.amazon.com

  13. OpenTelemetry - Observerbarhedsprimer - opentelemetry.io

  14. Stripe - Idempotente anmodninger - docs.stripe.com

  15. Google Cloud - Gentag strategi (backoff + jitter) - docs.cloud.google.com

  16. OWASP - Top 10 til store sprogmodeller - owasp.org

  17. OWASP - LLM01 Prompt injektion - genai.owasp.org

  18. LlamaIndex - Introduktion til RAG - udviklere.llamaindex.ai

  19. Microsoft - Semantisk kerne - learn.microsoft.com

  20. Microsoft AutoGen - Multi-agent framework (dokumentation) - microsoft.github.io

  21. CrewAI - Agentkoncepter - docs.crewai.com

  22. Haystack (deepset) - Dokumentation til apportører - docs.haystack.deepset.ai

Find den nyeste AI i den officielle AI-assistentbutik

Om os

Tilbage til bloggen