Slik bygger du skreddersydde KI-agenter: arkitektur, mønstre og skalering

Trinn 1: Definer KI-agentens arkitektur og styringsramme

Arkitekturen til en KI-agent har to hoveddeler: modellen og tjenestelaget rundt den. Tjenesten omfatter modellen, verktøyene, minnet og alt annet. Rundt kjernemodellen ligger hardkodet, deterministisk programvare bygget på if/else-logikk.

Skillet er tydelig. Når team lærer å bygge skreddersydde KI-agenter, gjør de ofte den feilen å be modellen gjøre alt. Det skaper store problemer med påliteligheten.

Det fungerer ikke. Modellen genererer tekst, mens tjenestelaget utfører logikk. Derfor må du behandle modellen som en isolert resonneringsmotor som aldri berører koden for ruting.

Tjenestelaget håndterer tilstand, ruting og feilretting. Modellen tar aldri beslutningene. Etter at vi tok i bruk dette hos et mellomstort SaaS-selskap, falt tiden det tok å løse supportsaker med 40 prosent fordi det deterministiske tjenestelaget håndterte rutingen presist i stedet for å støtte seg på modellens gjetninger.

Det var koden som gjorde jobben. En tydelig systemflyt gjør det enklere å se dette skillet. Tjenestelaget, ikke modellen, bestemmer flyten, så du trenger en klar plan for implementeringen.

Ikke hopp over de deterministiske kontrollpunktene. Anthropic har publisert en artikkel om mulige designmønstre for KI-agenter, fordelt på fire grunnleggende systemtyper: enkeltagenter, sekvensielle arbeidsflyter, parallelle arbeidsflyter og Evaluator-optimizer.

Vil du vite hvordan du bygger skreddersydde KI-agenter som kan skaleres? Du må velge mønster etter oppgaven. Hvis én agent tvinges til å håndtere en parallell arbeidsflyt med flere trinn, blir systemet tregt. Enkeltagenter fungerer godt for én oppgave.

• [ ] Definer deterministisk rutingslogikk
• [ ] Kartlegg verktøytilgang via MCP
• [ ] Velg grunnmodell
• [ ] Utform skjema for minnetilstand
• [ ] Konfigurer reserveløsninger for feilretting

Hvilket designmønster passer for din skreddersydde agent?

De er enkle å feilsøke, men har begrenset bruksområde. Sekvensielle arbeidsflyter sender resultatet fra én agent videre til den neste. Det passer godt for lineære prosesser som forskningsarbeid, der trinnene må utføres i en bestemt rekkefølge.

I en parallell arbeidsflyt utfører flere KI-agenter oppgaver samtidig og asynkront, omtrent som multitråding i tradisjonelle datamiljøer. Dette reduserer ventetiden betydelig for komplekse oppgaver. I Evaluator-optimizer-arkitektur arbeider to agentsystemer i gjentatte sykluser: Gruppe A utfører arbeidet, mens gruppe B vurderer og forbedrer det, omtrent som ved parprogrammering.

Dette gir høyere kvalitet på kode og tekst. Her er en Python-kodesnutt som setter opp en parallell arbeidsflyt der agentene arbeider asynkront. Slik kan du kjøre flere agenter uten å vente på at de skal bli ferdige én etter én. Se på koden nedenfor. `async def run_agent(task: str):`

# Simuler asynkron agentoppgave await asyncio.sleep(1)

import asyncio


return f"Result for {task}" async def parallel_workflow(tasks: list[str]): # Agents act asynchronously like multithreading results = await asyncio.gather(*[run_agent(task) for task in tasks])


return results tasks = ["fetch_market_data", "analyze_sentiment", "check_compliance"] results = asyncio.run(parallel_workflow(tasks)) print(results)

Når du utformer arbeidsflyten, må du vurdere disse avveiningene. For å bygge en KI-agent med Claude kombinerer utviklere Claude Agent SDK og Agent Skills. Det gir deg to hovedspor når du undersøker hvordan du bygger skreddersydde KI-agenter.

Velg verktøy med omhu. Du kan bruke Claude Agent SDK for tett integrasjon eller LangGraph for kompleks orkestrering med tilstandsmaskiner.

1. Ventetid: Parallelle arbeidsflyter kutter den samlede tidsbruken betydelig.
2. Kostnad: Parallelle arbeidsflyter bruker flere tokener per sekund.
3. Nøyaktighet: Evaluator-optimizer-sykluser øker nøyaktigheten, men dobler beregningsbruken.
4. Kompleksitet: Sekvensielle arbeidsflyter er enklest å feilsøke.

Trinn 2: Velg grunnmodell og orkestreringsrammeverk

Det er enkelt å forstå hvordan du bygger agenter med Claude: SDK-et styrer løkken, verktøy og MCP bestemmer hva agenten kan gjøre, og Skills beskriver hvordan den gjør det. Det gir et tydelig skille mellom ansvarsområdene. Claude Agent SDK tilbyr en agentløkke (hent kontekst, kall modellen, kjør verktøyet, send resultatet tilbake, gjenta) som kan programmeres i Python eller TypeScript.

LangGraph gir mer kontroll. Du kan definere egne grafnoder for logikken og bygge faste kontrollmekanismer som hindrer modellen i å kalle verktøy på avveie.

Orkestreringslaget sørger for nødvendige kontrollmekanismer som holder agentene på oppgaven. De kan hardkodes med verktøy som LangGraph eller håndteres i grafiske verktøy som Cursor Automations. Uten orkestrering kan en agent bli stående i en endeløs løkke ved én enkelt feil.

Sikker håndtering av innloggingsopplysninger er avgjørende. Aldri hardkod API-nøkler i systemprompten. For produksjonssystemer er det bare trygt å tilføre dem ved kjøring gjennom miljøvariabler.

Vi foretrekker LangGraph for kompleks ruting. Det tvinger deg til å tenke gjennom overganger mellom tilstander, mens Claude SDK passer bedre til rask prototyping og oppgaver med mange verktøy som krever hyppige justeringer.

{
 "orchestration": {
 "guardrails": {
 "max_iterations": 5,
 "timeout_seconds": 30
 },
 "secrets_manager": {
 "provider": "aws_secrets_manager",
 "keys": ["ANTHROPIC_API_KEY", "FIRECRAWL_API_KEY"]
 }
 }
}

Trinn 3: Implementer verktøy, nettilgang og minnehåndtering

KI-agenter bruker MCP (Model Context Protocol), kommandolinjeverktøy og rammeverk som LangChain for å få tilgang til verktøy. Skal du bygge skreddersydde KI-agenter, må du vite hvordan du forankrer dem i virkeligheten. Kunnskapen deres må bygge på faktiske forhold og oppdaterte data.

Uten slik tilgang er den begrenset til det som finnes i minnelagre og treningsdata.

De innebygde henteverktøyene fra selskaper som OpenAI og Anthropic gir bare begrenset nettilgang. Derfor trengs egne verktøy for nettilgang, som Firecrawl. Å hente rå HTML sløser med kontekstvinduet og forvirrer modellen.

Firecrawl har tre hovedendepunkter for nettilgang: /search (søk på nettet i sanntid), /scrape (hent nettsteder som strukturerte data eller Markdown) og /interact (åpne en ekte nettleser for å klikke på knapper og fylle ut skjemaer).

På en typisk side gir Firecrawl omtrent 2,788 tokener med ren Markdown i stedet for 38,381 tokener med rå HTML. Firecrawl gir 94 prosent færre input-tokener enn henting av rå HTML. Det forbedrer agentens ytelse direkte.

Strukturen på nettsider kan endre seg, og sidene kan inneholde irrelevant navigasjon eller skript. Foretrekk et dokumentert, strukturert endepunkt når det finnes, og test uttrekket mot representative sider og layoutendringer.

import requests


def search_web(query: str):
    response = requests.post("https://api.firecrawl.dev/v1/search", 
        json={"query": query, "limit": 5},
        headers={"Authorization": f"Bearer {API_KEY}"})
    return response.json()


def scrape_site(url: str):
    response = requests.post("https://api.firecrawl.dev/v1/scrape",
        json={"url": url, "formats": ["markdown"]},
        headers={"Authorization": f"Bearer {API_KEY}"})
    return response.json()

Minne er nødvendig i KI-systemer som kjører over tid, fordi alle modeller har et begrenset kontekstvindu som tilbakestilles når grensen nås. En KI-modell kan for eksempel ha et kontekstvindu på 200,000 tokener. Når det tilbakestilles, må konteksten bygges opp igjen fra minnet.

Du må lagre samtalehistorikk og tilstand i en ekstern database. Når kontekstvinduet er fullt, henter du et sammendrag og relevante fakta. Deretter bygger du opp prompten på nytt. Gå aldri ut fra at modellen husker noe utover det den får i den aktuelle forespørselen.

Hvordan håndterer du kostnader, API-nøkler og testing?

Hvis du kjører fem agenter samtidig, betaler du for fem modellkall på én gang. Enkeltagenter koster mindre per kjøring, men bruker betydelig lengre tid på å bli ferdige. Du må veie hastighet opp mot budsjett.

Se på et konkret eksempel med en supportagent som håndterer et middels høyt volum: 10,000 kjøringer i måneden. Manuell behandling koster $5 per sak, til sammen $50,000. Kostnadene ved automatisering fordeler seg annerledes.

Drift koster $100. Investeringen går i balanse nesten umiddelbart. Det er helt nødvendig å teste koden rundt agenten: Simuler verktøyfeil, og test logikken for tidsavbrudd grundig før du setter noe i produksjon.

Vi bruker deterministiske testtilfeller for koden rundt agenten og probabilistiske evalueringer for modellen. Vi setter aldri en agent i produksjon uten å teste hvordan den håndterer feil. Slutt å fylle systempromptene med unødvendige instruksjoner.

Agent Skills er mapper med en SKILL.md-fil som lærer agenten å utføre spesialiserte oppgaver. De lastes inn ved behov, slik at kontekstvinduet ikke fylles opp. Skal du lære å bygge tilpassede KI-agenter, må du skille de ulike ansvarsområdene fra hverandre.

En mindre kjent innsikt: Derfor hører prosedyrekunnskap hjemme i Skills

Det er nyttig å tenke slik når du bygger agenter med Claude: SDK-en er løkken, verktøy og MCP avgjør hva agenten kan gjøre, og Skills beskriver hvordan den gjør det. Verktøy er handlingene, Skills er bruksanvisningene. Hvis du legger alle instruksjonene i systemprompten, bruker du unødvendig plass i kontekstvinduet fordi modellen må lese instruksjoner som ikke er relevante for oppgaven.

Gradvis innlasting løser dette. Agenten laster bare inn SKILL.md-filen når den trenger å utføre den aktuelle oppgaven. Det holder kontekstvinduet ryddig og reduserer hallusinasjoner.

Agentene blir også mer modulære: Du kan oppdatere en Skill uten å endre den sentrale orkestreringslogikken.