Hvordan redusere tokenkostnadene for AI-agenter i produksjon

TL;DR

Token‑kostnader for AI‑agenter øker når hvert steg gjentatte ganger prosesserer instruksjoner, samtalehistorikk, verktøyresultater og mellomliggende tilstand.

Reduser tokenvolumet med budsjett på kjørenivå, filtrering av verktøyresultater, kontekstkomprimering, grense for retrier og kontrollert resonnering. Bruk promptbufring for stabilt, gjentatt input, men optimaliser agent‑løkken før du bytter til en billigere modell.

Det mest nyttige produksjonsmålet er kostnad per vellykket oppgave, målt for hele kjøringen—ikke pris per forespørsel eller kontekstsiden i den siste kallet.

Denne veiledningen fokuserer spesifikt på flerstegs AI‑agenter. Den forklarer hvordan gjentatt kontekst forsterkes gjennom en kjøring, hvordan du identifiserer største kilde til sløsing, og hvilke kontroller du bør implementere først.

Introduksjon

En chatbot kan gjøre én modellforespørsel per brukermelding. En AI‑agent kan gjøre 10, 20, eller flere kall før én oppgave er fullført.

Hvert steg kan sende instruksjoner, samtalehistorikk, verktøyresultater og mellomliggende tilstand på nytt. Retries, resonnering og underagenter øker bruken, så et kort sluttresultat kan likevel bruke et stort antall tokens.

Etter hvert som bruken skalere, blir disse kostnadene vanskeligere å forutsi og kan raskt redusere marginene. For å senke dem må hele agent‑løkken optimaliseres—ikke bare bytte til en billigere modell.

Denne artikkelen konsentrerer seg om agentspesifikke kostnader. For en bredere guide som dekker promptbufring, bufring av nøyaktige svar, semantisk bufring, modellruting og generell API‑kostnadsstyring, se Hvordan redusere AI API‑kostnader.

Hvorfor øker AI‑agenters tokenkostnader?

I en flerstegs agent er kostnaden for én oppgave summen av hvert eneste modellkall—ikke bare sluttsvaret.

Hovedkildene til agentens tokenbruk er:

Det finnes to ulike måter å redusere regningen på:

1. Prosesser færre tokens gjennom filtrering, komprimering, utdata‑grenser og løkkekontroller.
2. Reduser effektiv pris på nødvendige tokens med promptbufring eller modellvalg.

Nøkkelforskjell: Promptbufring senker kostnaden for gjentatt input. Kontekstkomprimering reduserer selve gjentakelsen av input.

Hvordan kan en 12‑trinns agent prosessere 147,000 tokens?

Tenk på en hypotetisk supportagent med:

• Et stabilt prefiks på 4,000 tokens
• 1,500 nye tokens lagt til etter hvert steg
• Hele akkumulert historikk sendt på nytt ved hver forespørsel
• 12 totale modellkall

Inputen ved steg n er:

Input at step n = 4,000 + 1,500 × (n - 1)

Den kumulative inputen på tvers av 12 kall er:

Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens

Det siste kallet inneholder bare 20,500 input tokens, men hele kjøringen prosesserer 147,000 kumulative input tokens.

Anvend nå to kontroller:

1. Bufre det stabile prefikset på 4,000 tokens etter første kall.
2. Komprimer historikken etter steg seks til en tilstandsoppsummering på 2,500 tokens.

Dette er en planleggingsberegning, ikke en leverandørbenchmark.

Den antar at hver forespørsel inkluderer hele akkumulert historikk. Agenter som konstruerer tilstand selektivt, oppsummerer gamle meldinger eller bare henter relevant informasjon, kan følge en annen kostnadskurve.

Kostnadsvekst‑regel: Mål kumulativ input for hele kjøringen. Den siste kontekststørrelsen representerer ikke totalt antall behandlede tokens.

Hvilke målinger avslører agenters token‑sløsing?

Ikke begynn med å endre modeller. Identifiser først hvor arbeidsflyten bruker tokens uten å forbedre resultatet.

Registrer disse feltene for hvert agentsteg:

Den primære metrikk bør være:

cost per successful task
= total workflow cost
/ accepted tasks

En billigere kjøring er ikke en forbedring hvis den gir flere mislykkede oppgaver, gjentatte verktøy eller behov for menneskelig korrigering.

Fire agentspesifikke metrikker hjelper deg å finne problemet.

Kontekstforsterkning

context amplification
= cumulative input tokens
/ final-step input tokens

En høy verdi indikerer at tidligere kontekst er prosessert gjentatte ganger.

Verktøyretensjonsforhold

tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools

Et høyt forhold kan indikere at agenten bærer for mye rå evidens mellom steg.

Retry‑avgift

retry tax
= retry and repair cost
/ total workflow cost

Resonneringsandel

reasoning share
= reasoning-token cost
/ total model cost

Mål hver arbeidsbelastning separat. Forsknings‑, kode‑, nettleser‑ og kundestøtteagenter bør ikke dele én global baseline.

Seks måter å redusere AI‑agenters tokenkostnader

1. Sett et budsjett for hele kjøringen

En per‑forespørsel utdata‑grense kontrollerer ikke en flerstegs agent.

Sett grenser på kjørenivå for:

• Totalt antall modellsteg
• Kumulative input og output
• Verktøykall og størrelse på verktøyresultater
• Retries etter feiltype
• Underagenter
• Total medgått tid eller estimert kostnad

Følgende leverandørnøytrale Python‑eksempel evaluerer kjøringen før hver modellforespørsel:

from dataclasses import dataclass
from enum import Enum


class Action(str, Enum):
    CONTINUE = "continue"
    COMPACT = "compact"
    STOP = "stop"


@dataclass(frozen=True)
class Budget:
    max_steps: int = 12
    max_input_tokens: int = 120_000
    max_output_tokens: int = 18_000
    compact_at: float = 0.80


@dataclass
class Usage:
    steps: int = 0
    input_tokens: int = 0
    output_tokens: int = 0


def evaluate_budget(usage: Usage, budget: Budget) -> Action:
    if (
        usage.steps >= budget.max_steps
        or usage.input_tokens >= budget.max_input_tokens
        or usage.output_tokens >= budget.max_output_tokens
    ):
        return Action.STOP

    input_ratio = usage.input_tokens / budget.max_input_tokens

    if input_ratio >= budget.compact_at:
        return Action.COMPACT

    return Action.CONTINUE

Kjør sjekken før hver modellforespørsel og oppdater Usage fra leverandørrapporterte tokendata.

Ved 80% av inputbudsjettet, komprimer tilstand eller snevre inn neste verktøyspørring. Ved 100% stopper du med en strukturert årsak.

Vanlig feil: Å begrense hver respons samtidig som ubegrensede steg, verktøy og retrier tillates.

2. Filtrer verktøyresultater før de kommer inn i transkriptet

Returner bare evidensen som kreves for agentens neste beslutning.

Ikke legg ved hele:

• Nettsiden
• Loggfilen
• Kode‑repoet
• Databaseresponsen
• Terminaløkten
• API‑payloaden

når neste steg bare trenger noen få felt.

Et søkeverktøy kan returnere:

{
  "source_id": "search_17",
  "title": "Relevant page title",
  "url": "https://example.com/page",
  "relevant_passage": "A short evidence block"
}

Lagre hele artefaktet utenfor prompten og hent en smalere del senere.

Verktøyfiltrerings‑regel: Returner feltene som trengs for neste beslutning—ikke alle felter som kanskje blir nyttige senere.

Vanlig feil: Å trunkere de første 1,000 tegnene i en JSON‑payload. Dette kan ødelegge strukturen eller fjerne oppføringene agenten faktisk trenger.

Parse payloaden først, velg felter strukturelt, begrens arrayer, og serialiser deretter gyldig JSON.

3. Komprimer operasjonell tilstand, ikke bare samtaletekst

Komprimering bør bevare informasjonen som trengs for å fortsette oppgaven, samtidig som historikk som ikke lenger påvirker neste handling fjernes.

En nyttig komprimert tilstand inneholder:

• Brukermål og suksesskriterier
• Beslutninger som allerede er gjort
• Verifiserte fakta og kilde‑ID‑er
• Filer eller poster som er endret
• Mislykkede tilnærminger
• Åpne spørsmål
• Neste handling
• Sikkerhets‑ og output‑begrensninger

Den skal ikke gjenfortelle hele samtalen.

OpenAI dokumenterer komprimering for langvarige Responses API‑interaksjoner. Anthropic tilbyr konteksthåndtering for å rydde eller oppsummere eldre innhold. Implementasjonene varierer, så verifiser gjeldende leverandørfelter før integrering.

Komprimerings‑regel: Bevar beslutninger og uavsluttet arbeid. Fjern fortelling og evidens som kan hentes igjen.

Vanlig feil: Å droppe kilde‑ID‑er, endrede filnavn, avviste tilnærminger eller uløste begrensninger.

Etter at du legger til komprimering, mål om agenten gjentar søk eller verktøykall. En kortere prompt er ikke billigere hvis agenten må gjenoppbygge tapt tilstand.

4. Hold det gjenbrukbare prefikset stabilt

Agent‑prompter inneholder ofte store gjenbrukbare blokker:

• Systeminstruksjoner
• Verktøyskjemaer
• Sikkerhetspolicyer
• Outputformater
• Delt referansemateriale
• Repo‑ eller produktinstruksjoner

Plasser disse stabile elementene før forespørselsspesifikke data:

1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data

Unngå å plassere tidsstempler, forespørsel‑ID‑er, session‑data eller ofte endrede verdier tidlig.

Buffering er mest nyttig når prefikset er langt, stabilt og gjenbrukt. Det kan gi liten gevinst for korte økter eller ofte endrede prompter.

Vanlig feil: Å optimalisere for cache‑treffrate uten å måle kostnad for cache‑skriv,‑lesing eller lagring.

For en bredere sammenligning av leverandørers promptbufring, bufring av nøyaktige svar og semantisk bufring, se Hvordan redusere AI API‑kostnader.

5. Hindre at retrier repeterer samme kontekst

En retry er enda et agentsteg, ofte med samme store prompt.

Ikke gjenta en mislykket forespørsel uten å endre årsaken til feilen.

Bruk idempotensnøkler for operasjoner med sideeffekter som betalinger, e‑poster, utrullinger og database‑skriv.

Vanlig feil: Å retrye en rate‑begrenset modell flere ganger mens hele agentkonteksten sendes på nytt hver gang.

Spor retry‑avgift per feiltype slik at teamet kan fikse den største løkken først.

6. Begrens resonnering og underagenter til stegene som trenger dem

Ikke hvert agentsteg krever dyp resonnering.

Ekstraksjon, formatering, klassifisering, validering og rutinemessig verktøyvalg kan ofte bruke lavere resonneringsinnsats og kompakt, strukturert output.

Reserver høyere resonneringsinnsats for oppgaver som:

• Kompleks planlegging
• Vanskelig koding
• Syntese av flere dokumenter
• Tvetydige beslutninger
• Gjenoppretting etter mislykket kjøring

Resonnerings‑regel: Bruk lavest mulig resonneringsinnsats som bevarer andelen aksepterte oppgaver.

Underagenter krever også en klar grense. Gi hver arbeider:

• En smal oppgave
• En oppgavespesifikk kontekstskive
• En tillatliste for verktøy
• Et tokenbudsjett
• Et kompakt outputskjema

Root‑agenten trenger vanligvis funn, evidens‑ID‑er, konfidens og uløste problemer—ikke hele transkriptet til arbeideren.

Underagent‑regel: Paralleliser uavhengig arbeid, ikke duplisert kontekst.

Vanlig feil: Å sende hele root‑agentens historikk til hver arbeider før en smal oppgave er tildelt.

Hvilken optimalisering bør du bruke først?

Bruk agenttelemetri for å velge første tiltak.

Tersklene nedenfor er utgangspunkt for undersøkelser, ikke universelle standarder.

En trygg implementeringsrekkefølge er:

1. Mål kumulativ input, verktøyretensjon, retrier og resonnering.
2. Legg til harde grenser for steg, verktøy, retrier og totalt tokens.
3. Filtrer store verktøyresultater.
4. Komprimer eldre tilstand ved en målt terskel.
5. Stabiliser det gjenbrukbare prompt‑prefikset.
6. Sammenlign modellruter først etter at agent‑løkken er ryddet.

Endre én større variabel om gangen og kjør samme evalueringssett.

Sammenlign:

• Andel aksepterte oppgaver
• Kostnad per vellykket oppgave
• Kumulativ input
• Antall verktøykall
• Retry‑avgift
• Resonneringsandel
• p50 og p95 latens
• Tid for menneskelig gjennomgang

Rull tilbake endringer som sparer tokens ved å redusere oppgavekvalitet eller fjerne nødvendig evidens.

Test agent‑arbeidsflyter med CometAPI

Før du kjører en multi‑modell evaluering, bruk CometAPI prisside og kostnadsestimeringsguide for å estimere input, output, bufrede tokens og resonneringskostnader.

Bruk deretter modellkatalogen til å identifisere aktuelle ruter og Quickstart for å konfigurere en OpenAI‑kompatibel klient.

For produksjons‑fallback, følg CometAPI veiledning for modell‑fallback for å bytte ruter uten å gjenta fullførte verktøykall eller forkaste validert tilstand.

Samlet tilgang forenkler modellsammenligning og fallback‑integrasjon. Tokenbudsjetter, komprimering, validering, verktøyfiltrering, retry‑grenser og akseptkriterier hører fortsatt hjemme på applikasjonsnivå.

FAQ

Hvorfor bruker AI‑agenter flere tokens enn chatboter?

Agenter gjør flere modellkall og kan sende tidligere meldinger, verktøyresultater, instruksjoner og mellomliggende tilstand på nytt i hvert steg. Dette gjør at tidligere kontekst prosesseres flere ganger.

Reduserer promptbufring bruken av kontekstvinduet?

Nei. Promptbufring kan redusere effektiv pris eller latens for gjentatt input, men bufrede tokens utgjør fortsatt en del av prosessert kontekst. Bruk komprimering, filtrering eller selektiv henting for å redusere promptstørrelsen.

Når bør en AI‑agent komprimere konteksten sin?

Komprimer før kontekstvekst begynner å påvirke kostnad, latens eller tilgjengelig utplass for output. Verifiser at den komprimerte tilstanden bevarer beslutninger, evidens‑ID‑er, endrede filer, åpne spørsmål og sikkerhetsbegrensninger.

Reduserer underagenter tokenkostnader?

Ikke automatisk. De kan redusere medgått tid eller forbedre dekning for uavhengig arbeid, men duplisert kontekst og overlappende analyse øker ofte total tokenbruk.

Hva er den beste metrikk for kostnadsoptimalisering av AI‑agenter?

Bruk kostnad per vellykket oppgave som primærmetrikk. Diagnostiser den med kumulativ input, kontekstforsterkning, verktøyretensjon, retry‑avgift, resonneringsandel, latens og tid for menneskelig gjennomgang.