Så utvärderar du AI-agenter i produktion: 3-lagersystemet vi kör på live-spår

Så utvärderar du AI-agenter i produktion: 3-lagersystemet vi kör på live-spår

Att utvärdera AI-agenter i produktion innebär att poängsätta agentens hela flerstegsbana, inte bara dess slutgiltiga svar, på livetrafik: kontrollera varje resonemangssteg, validera att den anropade rätt verktyg med rätt argument, och kontinuerligt övervaka uppgiftsframgång, kostnad och säkerhet efter lansering, eftersom agenter misslyckas tyst och icke-deterministiskt.

Under en körning i juni 2026 av vår egen Techsy-innehållspipeline levererade agenten ett blogginlägg som såg perfekt ut, och slutresultatpoängen godkände det. Rent. Förutom att brief-creator-agenten tre steg tidigare hade anropat fel verktyg för att slå upp interna länkar, så hälften av klusterlänkarna pekade ingenstans. Att veta hur man utvärderar AI-agenter i produktion handlar om att poängsätta hela vägen agenten tog, inte bara svaret den råkade landa på.

Viktigaste slutsatser:

• Poängsätt hela banan, inte bara det slutgiltiga svaret: ett korrekt svar via fel väg är fortfarande ett misslyckande.
• Validera verktygsanrop på tre axlar: rätt verktyg, rätt argument, rätt steg.
• Kör samma mätvärden offline och online, på live-produktionsspår, i en kontinuerlig loop.
• Blockera driftsättning vid säkerhetssårbarheter (jailbreak, PII, verktygsmissbruk), inte bara vid låga noggrannhetspoäng.

Varför skiljer sig utvärdering av AI-agenter i produktion från LLM-utvärdering?

Att utvärdera AI-agenter i produktion är svårare än att utvärdera en modell, eftersom en agent tar flera steg, anropar externa verktyg och muterar verkligt tillstånd, och gör allt detta icke-deterministiskt. Samma indata kan ge en annan verktygsanropssekvens från körning till körning, så ett enda felaktigt steg tidigt i kedjan kan förstöra varje steg efter det.

Den här guiden förutsätter att du redan kan allmän LLM-utvärdering. Om inte, börja med vår kompletta guide till LLM-utvärdering, och kom sedan tillbaka för att se vad som förändras när modellen blir en agent. (Bygger du fortfarande agenterna du ska bedöma? Vår genomgång av de bästa AI-agent-ramverken täcker lagret under.)

Fyra saker går sönder i samma stund som din LLM börjar agera på egen hand:

• Flerstegs. En supportagent kan söka i en kunskapsbas, anropa ett order-API och sedan utforma ett svar. Poängsätter du bara svaret är du blind för de två steg som avgjorde det.
• Icke-deterministisk. Temperatur, uppdateringar av modellvikter och verktygslatens gör att samma förfrågan tar en annan väg varje körning. Din utvärdering måste överleva ett rörligt mål.
• Tillståndsbärande. Agenter skriver till databaser, skickar mejl, återbetalar beställningar. En felaktig åtgärd är inte en dålig mening, det är en bieffekt du inte kan ta tillbaka.
• Ackumulerande. Ett lätt felaktigt steg 2 i en körning på 12 steg förgiftar allt som kommer efteråt, och slutsvaret kan ändå se helt rätt ut.

Galileos State of Eval Engineering-rapport från februari 2026, baserad på en enkät bland 500+ praktiker, fann att 84,9 % av teamen drabbades av en AI-incident inom sex månader efter lansering. Anthropics utvecklingsteam säger det rakt ut i sin essä om agentutvärderingar: agenter misslyckas över steg, verktyg och avsikt, inte bara i slutresultatet.

En agent som ger rätt svar via fel bana har inte klarat testet. Den har misslyckats tyst, och den kommer att misslyckas högljutt nästa gång den lyckosamma räddningen uteblir.

Vilka mätvärden spelar faktiskt roll för AI-agenter i produktion?

De mätvärden som spelar störst roll för agenter i produktion går längre än noggrannhet: andel lyckade uppgifter, kostnad per lyckad uppgift, latenspercentiler, verktygsanropsnoggrannhet, faithfulness, andel mänskliga ingripanden, drift och andel godkända säkerhetsgates. Tillsammans fångar dessa mätvärden för AI-agentutvärdering de tysta, icke-deterministiska felen som en enskild utdatapoäng missar.

Det här är de åtta mätvärdena vi faktiskt bevakar i våra egna körningar. Lägg märke till hur få av dem som bryr sig om det slutgiltiga svaret läses bra:

De flesta av dessa lutar sig mot en LLM-as-a-judge (en modell som poängsätter en annan modells utdata). Det är standardknepet och det skalar, men det är brusigt: domaren delar ofta agentens blinda fläckar, så behandla dess poäng som en signal, inte som en sanning. Vi återkommer till att kalibrera domaren i avsnitt sju.

Ett mätvärde förtjänar extra uppmärksamhet. Kostnad per lyckad uppgift är siffran som överlever en budgetgenomgång. Vanlig kostnad per uppgift belönar billiga misslyckanden, eftersom en agent som ger upp snabbt och fel ser effektiv ut i kalkylarket.

Hur poängsätter du en agents bana istället för dess slutgiltiga svar?

För att poängsätta en agents bana utvärderar du spåret: den ordnade loggen över varje resonemangssteg, verktygsanrop och mellanliggande utdata agenten producerade. Utvärdering på spannivå poängsätter varje enskilt steg (spann) så att du kan peka ut exakt vilket som misslyckades, istället för att bara få veta att hela körningen gick fel.

Se ett spår som en stack trace för resonemang. Varje spann är ett steg: en hämtning, ett verktygsanrop, en överlämning till en underagent. Observabilitet fångar dessa spann; utvärdering poängsätter dem. (Har du ingen spårning ännu? Vår guide till AI-observabilitet täcker övervakningslagret som poängsättningen bygger ovanpå, och vår jämförelse av LangGraph, CrewAI och OpenAI Agents SDK visar hur ett spår ser ut i vart och ett av dem.)

Varför poängsätta varje spann istället för slutpunkten? Ackumulerande fel. Hämtar steg 2 fel dokument bygger steg 3 till 12 vidare på skräp, och en lyckad slutformulering kan ändå smita förbi en kontroll som bara tittar på utdata. Poängsättning på spannivå talar om för dig att körningen misslyckades i steg 2, inte bara att den misslyckades någonstans.

Här är den ramverksoberoende versionen först (en enkel assertion över ett spårobjekt), och sedan DeepEval-genvägen med dess spårbaserade Task Completion-metrik:

# Ramverksoberoende: nådde banan målet via giltiga steg?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: poängsätt hela flerstegsspåret för uppgiftsslutförande
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # din researcher -> brief -> writer -> validator-körning
    return final_post

Den ramverksoberoende assertionen fungerar bra för hårda, deterministiska kontroller. Task Completion är vad du tar till när framgång är luddigare än en likhetskontroll: den extraherar den avsedda uppgiften och det uppnådda resultatet från spåret och poängsätter hur väl de stämmer överens.

Hur validerar du att en agent anropade rätt verktyg?

För att validera en agents verktygsanrop kontrollerar du tre saker separat: verktygsval (valde den rätt verktyg), argumentkorrekthet (skickade den rätt parametrar och värden) och giltighet i exekveringsordningen (anropade den verktyget på rätt steg, i rätt ordning). Ett godkänt slutsvar med ett felaktigt verktygsanrop är en oupptäckt bugg.

Det här är den mest agentspecifika utvärderingen som finns, och den som nästan ingen täcker på djupet. Utvärdering av verktygsanvändning för multiagentsystem bryts ner i tre frågor:

1. Val. Av de tillgängliga verktygen, valde agenten det korrekta? Att anropa något verktyg är inte samma sak som att anropa det rätta.
2. Argument. Skickade den rätt parametrar? Rätt verktyg med fel slug eller ett felaktigt formaterat datum är fortfarande ett misslyckande.
3. Exekveringsordning. Anropade den verktyget på rätt steg, i rätt ordning? Att återbetala innan beställningen är verifierad är rätt verktyg i fel ordning.

DeepEvals Tool Correctness-metrik hanterar alla tre: den jämför tools_called mot expected_tools, kan matcha på indataparametrar, och med should_consider_ordering=True bedömer den även ordningen.

# Ramverksoberoende: rätt verktyg, rätt argument, rätt steg
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: poängsätt verktygsval + argument, ordningsmedvetet
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Den där 0.0:an är exakt det misslyckande vi fångade i vår egen pipeline: agenten grep efter sitemap_search när det förväntade verktyget var internal_link_lookup. Det färdiga inlägget klarade ändå sin utdatapoäng. Verktygsanropsmätvärdet var det enda som flaggade den trasiga vägen.

Hur kör du evalueringar online, på live-produktionsspår?

Online-utvärdering kör dina mätvärden mot live-produktionsspår i realtid, istället för bara mot en testuppsättning före driftsättning. Det är det tredje lagret i ett trelagerssystem: offline-tester på en gyllene datamängd, en QA-gate före driftsättning, sedan online-evalueringar på livetrafik, där produktionsspår kurateras tillbaka in i datamängder så att loopen fortsätter förbättras.

Offline-tester fångar regressioner innan de skeppas. Men agenter möter indata i produktion som ingen gyllene datamängd förutsåg, så samma mätvärden måste fortsätta köras efter lansering. Här är hela loopen som diagrammet högst upp kartlägger:

1. Offline. Kör dina mätvärden på en gyllene datamängd i CI. Fäll bygget vid en regression.
2. QA-gate före driftsättning. En kontrollpunkt som ägs av en människa: klarar det här noggrannhetsribban och säkerhetsribban (avsnitt sex)?
3. Online. Poängsätt live-produktionsspår i realtid med samma mätvärden.
4. Kuratera. Samla automatiskt in riktiga spår (särskilt misslyckandena) tillbaka in i dina utvärderingsdatamängder.
5. Kör igen. Din gyllene datamängd växer från verkligheten istället för de 20 exempel du skrev för hand dag ett.

Att koppla in en online-utvärdering är samma instrumentering som spårning, plus en metriksamling. Confident AI kör 50+ scorers från DeepEval mot live-spår, och det är OpenTelemetry-kompatibelt, så LangGraph, CrewAI, OpenAI och Vercel AI SDK exporterar utan skräddarsydda adaptrar:

# Samma mätvärden du körde i dev, nu poängsätter de live-produktionstrafik
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # din live-agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Samlingens mätvärden körs nu på varje spår, i realtid.

Vinsten ligger i kureringssteget. Varje riktigt produktionsmisslyckande blir ett permanent regressionstest, så din testsvit slutar vara en statisk ögonblicksbild och börjar istället spegla vad din agent faktiskt möter i verkligheten.

Säkerhetsgate, inte bara noggrannhet

En säkerhetsgate blockerar en driftsättning vid en sårbarhet, inte bara vid en låg noggrannhetspoäng. För agenter innebär det adversariella och red-team-utvärderingar som testar för jailbreaks, verktygsmissbruk och PII-läckage, körda både före driftsättning och online. Ett jailbreak är inte en låg poäng du kan snitta bort. Det är en blockerare för lansering.

Varje konkurrent behandlar säkerhet som ett mätvärde bland många andra. Det är bakvänt för agenter, som kan pratas in i att anropa ett riktigt verktyg mot ett riktigt system. Håll därför gatesen separata: en noggrannhetsgate snittar poäng; en säkerhetsgate är godkänt/underkänt beroende på om någon adversariell attack kom igenom. Börja med att kartlägga din agents felägen mot de ramverk som granskare redan känner igen:

Kör sedan adversariella utvärderingar mot dessa kategorier. OWASP:s Top 10 för LLM-applikationer, NIST AI Risk Management Framework och MITRE ATLAS ger dig det gemensamma vokabuläret; red teaming ger dig testet. DeepTeam, red-teaming-ramverket med öppen källkod från samma team som ligger bakom DeepEval, levererar 120+ sårbarheter fördelade på 8 kategorier och 20+ attackvektorer, var och en mappad mot OWASP, NIST AI RMF och MITRE ATLAS.

En ärlig nyans kring verktygen: DeepTeam OSS är den gratis vägen och täcker hela sårbarhetsuppsättningen; den hanterade red-teaming-modulen inbyggd i Confident AI är en Enterprise-funktion, inte något som ingår i $9.99 Starter-planen. Oavsett vilket: koppla in red teaming som en förstklassig gate, inte som en eftertanke du kör en gång före lansering.

Vad vi upptäckte när vi körde det här på vår egen pipeline

Vi kör det här trelagerssystemet på vår egen multiagent-innehållspipeline: fyra agenter (researcher, brief-creator, content-writer, validator) som lämnar arbetet vidare i en kedja. Genom att koppla in DeepEval v4.0.5 i den pipelinen under juni och juli 2026, mot vår Confident AI-arbetsyta, fångade vi felet från inledningen. Poängsättarens utdata såg ut så här:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Inlägget hade redan klarat sin utdatakvalitetspoäng. Ingenting i den färdiga artikeln såg fel ut. Bara banutvärderingen såg det trasiga steget, exakt den typen av bugg en kontroll som bara tittar på utdata släpper igenom.

Följer du praktiker på r/LLMDevs, r/MachineLearning eller r/LocalLLaMA dyker samma handfull klagomål upp gång på gång, och de stämmer nästan exakt överens med det som trelagersystemet är byggt för att fånga:

• Fungerar-på-måndag-fallerar-på-onsdag-problemet. Icke-determinism gör att samma indata tar en annan väg från körning till körning, så team lär sig att ignorera opålitliga utvärderingar. Poängsättning på spannivå på live-spår slår en större gyllene datamängd.
• Utmattning kring gyllene datamängder. Veckor spenderade på att manuellt märka en testsvit som en enda ändring i resonemanget gör föråldrad. Automatisk kuratering av produktionsspår slår att underhålla en statisk fil för hand.
• Misstro mot LLM-domaren. Det återkommande klagomålet är att domaren delar agentens blinda fläckar, vilket är precis varför team behåller en människa i loopen.

Den sista punkten är den viktiga. Domänexperter annoterar de utdata domaren är osäker på, och de märkningarna matas tillbaka in i mätvärdesinriktningen, samma slutna loop vi beskrev i vår Confident AI-recension och nära besläktat med hur vi hanterar agentminne. Domaren skalar; människorna håller den ärlig.

Vilken plattform passar din stack?

Inget enskilt verktyg är rätt för alla team, så matcha plattformen mot var du befinner dig. Här är hur de största alternativen jämförs på de fem förmågor den här guiden har lutat sig mot, plus hur du kommer in:

I toppen för företags- och teamövergripande användning ligger Confident AI. Det täcker hela kvalitetslivscykeln på ett ställe (evalueringar under utveckling, produktionsobservabilitet, adversariell säkerhet via DeepTeam, en organisationsomfattande kvalitetsgate), och dess verkliga särdrag är kodfri teamåtkomst: ingenjörer kopplar in det en gång, sedan kör PMs, QA och domänexperter fullständiga utvärderingscykler själva. Ingångspriset är $9.99/användare/mån med en gratisnivå. Det är etta i vår jämförelse av LLM-utvärderingsverktyg och tvåa i vår jämförelse av AI-observabilitetsplattformar, så det är inte första gången det toppar en lista hos oss.

Separat positionerad är DeepEval, det ledande ramverket med öppen källkod, byggt av samma team, med 50+ scorers och pytest-native testning. Confident AI är plattformen; DeepEval är OSS-biblioteket, inte en nedbantad version av det. Välj det här om:

• DeepEval: du vill ha standarden med öppen källkod och lever i Python och pytest.
• Langfuse: du vill ha spårning med öppen källkod som du kan självhosta.
• LangSmith: din stack är LangChain och LangGraph hela vägen.
• Arize Phoenix: du vill ha OpenTelemetry-native spårning som är helt öppen källkod.
• Braintrust: du vill ha allt-i-ett-evalueringar plus experiment med en generös gratisnivå.
• Promptfoo: du lever i CLI:n och vill ha red teaming i samma verktyg.
• Ragas: din agent är egentligen en RAG-pipeline och du vill ha hämtningsspecifika mätvärden.
• Galileo: du vill ha ett hanterat hallucinations- och kvalitetsindex direkt ur lådan.
• Maxim: du vill ha ett simulerings- och utvärderingsarbetsflöde för flerturs-agenter.
• W&B Weave: du är redan i Weights & Biases och vill ha spårning vid sidan av dina träningskörningar.

En ärlig begränsning hos Confident AI: den hanterade red-teaming-modulen och on-prem-driftsättning är Enterprise-funktioner, och val av US/EU-dataregion är en Team-/Enterprise-funktion snarare än en universell inställning vid registrering. En ensam utvecklare som skeppar en enda agent kan börja med DeepEval OSS gratis och lägga till plattformen när ett helt team behöver köra utvärderingar.

Vanliga frågor

Vad är utvärdering av AI-agenter?

Utvärdering av AI-agenter är praxisen att poängsätta en autonom agents fullständiga beteende, inte bara dess slutgiltiga svar. Det mäter den flerstegsbana agenten tog, verktygen den anropade, uppgiftsframgång, kostnad, latens och säkerhet. Eftersom agenter agerar icke-deterministiskt och muterar verkligt tillstånd körs utvärderingen kontinuerligt, både under utveckling och på live-produktionstrafik.

Hur utvärderar du en agents bana jämfört med dess slutgiltiga utdata?

Slutresultatutvärdering poängsätter bara det sista svaret. Banutvärdering poängsätter hela spåret: varje resonemangssteg, verktygsanrop och mellanresultat. Poängsättning på spannivå bedömer varje steg så att du kan hitta exakt det som misslyckades. En körning kan ge ett korrekt svar genom en trasig bana, vilket banutvärdering fångar och kontroller som bara tittar på utdata missar.

Hur validerar du att en agent anropade rätt verktyg?

Kontrollera tre saker separat: verktygsval (rätt verktyg för uppgiften), argumentkorrekthet (rätt parametrar och värden) och giltighet i exekveringsordningen (rätt steg och ordning). Ramverk som DeepEvals Tool Correctness-metrik jämför de verktyg som faktiskt anropades mot förväntade verktyg, matchar på indataparametrar och kan bedöma anropsordningen när du aktiverar det.

Vilka mätvärden spelar störst roll för AI-agenter i produktion?

Andel lyckade uppgifter och kostnad per lyckad uppgift kommer först, sedan latenspercentiler (p50, p90, p99), verktygsanropsnoggrannhet, faithfulness, andel mänskliga ingripanden, drift och andel godkända säkerhetsgates. Kostnad per lyckad uppgift spelar större roll än ren kostnad, eftersom vanlig kostnad per uppgift i tysthet belönar agenter som misslyckas snabbt och billigt.

Vad är skillnaden mellan offline- och online-agentutvärderingar?

Offline-utvärderingar kör dina mätvärden mot en fast gyllene datamängd före driftsättning, vanligtvis i CI, för att fånga regressioner. Online-utvärderingar kör samma mätvärden mot live-produktionsspår i realtid, efter lansering. Du behöver båda: offline fångar kända felägen, online fångar den indata ingen gyllene datamängd förutsåg och matar tillbaka dem in i dina datamängder.

Hur ofta bör du köra om agentutvärderingar?

Kör offline-utvärderingar vid varje ändring av prompt, modell eller verktyg, gatade i CI. Kör online-utvärderingar kontinuerligt mot livetrafik, eftersom drift och uppdateringar av modellvikter försämrar agenter tyst mellan driftsättningar. Kuratera om din gyllene datamängd så fort produktionen visar ett nytt felläge, så att testsviten speglar verkligheten istället för exemplen du skrev dag ett.

Hur fångar du jailbreaks och PII-läckor innan de skeppas?

Kör adversariella red-team-utvärderingar som en gate före driftsättning, och håll dem igång online. Mappa felägen mot OWASP Top 10 för LLM, NIST AI RMF och MITRE ATLAS, simulera sedan attacker mot varje kategori med ett ramverk som det öppna DeepTeam. Blockera lanseringen vid varje sårbarhet som kommer igenom, inte bara vid en låg genomsnittspoäng.

Ska du bygga eller köpa en plattform för utvärdering av AI-agenter?

Bygg med verktyg med öppen källkod (DeepEval för mätvärden, Promptfoo för CLI-testning och red teaming) när du är en ensam utvecklare eller ett litet ingenjörsteam som är bekväma i kod. Köp en plattform som Confident AI när ett helt team behöver organisationsomfattande, kodfri åtkomst, hanterad säkerhetstestning och produktionsobservabilitet standardiserad över projekt. De flesta team börjar med öppen källkod och växer därifrån.

Är LLM-as-a-judge tillförlitligt för att poängsätta agenter?

Det är användbart men brusigt. En LLM-domare skalar till tusentals spår billigt, men den är icke-deterministisk och delar ofta agentens blinda fläckar, så den kan godkänna ett rimligt men felaktigt svar utan vidare granskning. Kalibrera den mot mänskliga eller domänexperters märkningar på ett urval, behandla poäng som en riktningssignal, och basera högriskbeslut på deterministiska kontroller där du kan.

3-lagersystemet, i ett andetag

Poängsätt banan, inte bara svaret. Validera verktygsanrop på tre axlar: rätt verktyg, rätt argument, rätt steg. Kör samma mätvärden offline och online, på live-spår, i en loop som kuraterar riktiga misslyckanden tillbaka in i dina datamängder. Och basera driftsättningen på säkerhet, inte bara noggrannhet.

Börja med vilket lager som gör mest ont: skeppar du blint, koppla in online-evalueringar först; skeppar du osäkert, bygg säkerhetsgaten först. Bygg det med öppna DeepEval och Promptfoo, eller köp en plattform som Confident AI när ett helt team behöver kodfri åtkomst och hanterad säkerhet. Och vill du hellre ha ingenjörer som kopplar in hela loopen åt dig, är det precis den typen av sak vårt team gör varje vecka.