Varför AI-agenter passerar QA men fortfarande misslyckas i produktion

Kontinuerligt lärande blir alltmer den ingenjörsvetenskap som förbättrar agenter efter distribution, utan att bryta det som redan fungerade.

En AI-agent kan passera varje för-test och fortfarande misslyckas i produktion en vecka senare. Det är inte en motsägelse. Testuppsättningen återspeglar vad teamet visste att testa före lansering. Produktion är där de saknade fallen dyker upp: underliga fraser, saknad kontext, verktygsgränser, otåliga användare, motsägelsefulla policys och arbetsflöden som ingen benchmarkdesigner föreställde sig.

Agenten blir korrekt av användarna hela tiden. Den besviker användarna. Sedan slutar sessionen, loggen lagras och nästa användare möter i princip samma system.

Det är därför kontinuerligt lärande blir alltmer centralt för agentteknik. Det är inte en funktion i en produkt. Det är en kategori av metoder för att förbättra agenter från erfarenhet samtidigt som man bevarar det som redan fungerar. Klassisk kontinuerligt lärande forskning formulerade problemet som lärande över tid utan katastrofalt glömska. Agenter gör att problemet blir bredare. Det som förändras kan vara en modell, men det kan också vara en prompt, ett verktyg, en färdighet, ett arbetsflöde eller minne.

Den distinktionen är viktig, eftersom de flesta agentfel inte löses genom att först nå fram till modellträning.

Finjusteringsreflexen är för smal

När team pratar om att förbättra ett AI-system låter den vanliga planen ofta så här: samla in fel, märk bättre svar, finjustera modellen. Den instinkten är förståelig. Övervakad finjustering, Direkt preferensoptimering, Grupp relativ policyoptimering, och parametrar-effektiva metoder som LoRA är användbara verktyg när modellen själv behöver förändras.

Men många produktionsfel är inte modellviktiga fel. De är systemfel.

Agenten kan förlita sig på föråldrad minne, hoppa över en obligatorisk bekräftelse, anropa ett verktyg med fel argument eller dirigera ett ärende genom fel arbetsflöde. Ofta är problemet inte basmodellens förmåga. Det är kontexten, minnet, verktygsgränssnittet eller arbetsflödet runt den.

En modern agent har flera lager. Modellen resoneras och genereras. Harnessen runt den definierar prompter, verktyg, färdigheter, kod, dirigering och arbetsflöde. Minnet bär fakta och inlärda procedurer över sessioner. Kontinuerligt lärande är disciplinen att bestämma vilket lager som ska förändras, hur liten förändringen kan vara och hur man kan verifiera att förändringen faktiskt hjälpte.

Ibland är den rätta lösningen ett minnesskrivande. Ibland är det en promptredigering. Ibland är det ett verktygsomslag, en dirigeringregel eller ett arbetsflödeskorrigering. Finjustering bör förbli tillgänglig, men den bör inte vara det första svaret på varje fel.

Benchmark är användbara, men produktion ger sällan en

Det finns spännande arbete på att optimera agentharnesset själv. Metoder som GEPA, Meta-Harness, och relaterade prompt- eller arbetsflödesoptimeringsmetoder behandlar agenten som ett system som kan muteras och testas. De kan föreslå redigeringar av prompter eller andra harnesskomponenter, köra kandidater och behålla versioner som poängsätter bättre.

Det är rätt riktning. Det flyttar förbättringen ut ur den smala ramen “uppdatera vikterna” och in i den bredare ramen “förbättra agenten”.

Men det finns en hake: dessa metoder förutsätter vanligtvis en benchmark. De behöver en uppgift som kan köras upprepade gånger och en utvärderare som säger om kandidat A är bättre än kandidat B. Utan det blir optimering gissning med bättre verktyg.

Det är inte vad de flesta team har i produktion.

Vad de har är loggar. De har spår, användarkorrigeringar, supportärenden, tummen-ner-händelser, eskalering anteckningar och ibland expertfeedback. Dessa signaler är värdefulla, men de är inte ännu en benchmark. De berättar att något hände. De berättar inte automatiskt hur man ska återspela det, vad framgång ska se ut som eller hur man ska poängsätta en föreslagen lösning.

Det är där många kontinuerliga inlärningsansträngningar stannar. Teamet har erfarenhet, men inte ännu en inlärningsmiljö.

Loggar är inte lektioner

En produktionslogg registrerar en väg genom en interaktion. En användare bad om en flygning. Agenten sökte. Användaren sa att datumet var fel. Det är bevis på ett fel, men det räcker inte för att lära sig av.

Loggen definierar inte den kontrafaktiska. Borde agenten ha begärt bekräftelse? Borde den ha dragit slutsatsen från tidigare kontext? Borde den ha anropat ett annat verktyg? Borde den ha vägrat att fortsätta tills oklarheten var löst? En människa kan veta svaret efter att ha läst spåret, men systemet får inte den strukturen gratis.

För att kontinuerligt lärande ska fungera måste ett rått fel förvandlas till något som kan återupprepas. Det betyder en uppgift som agenten kan möta igen, en användare eller simulator som återskapar det relevanta mönstret, verktyg som agenten kan anropa och utvärderare som definierar framgång. Utvärderaren kan kontrollera det slutliga svaret, verktygsanropen, en policygräns, fördröjning, kostnad eller allt ovanstående.

Detta är den mindre synliga delen av arbetet, men det är den del som gör förbättringen verklig. När ett fel förvandlas till en återupprepad miljö kan man ställa en konkret fråga: fungerade den föreslagna lösningen faktiskt?

Utan det steget är teamen mestadels patchande från minnet.

David Silver och Richard Sutton har beskrivit en kommande era av erfarenhet, där agenter lär sig främst från interaktion med världen snarare än från statisk mänsklig data. För företagsagenter beror den visionen på att förvandla oordnad produktionserfarenhet till miljöer som kan återupprepas, poängsättas och återanvändas.

Erfarenhet ensam räcker inte. Den måste göras testbar.

Regressionskostnad är den dolda kostnaden

Även när ett fel blir testbart kvarstår den svåraste delen: att fixa det utan att bryta något annat.

Vem som helst som har underhållit en komplex agent har sett det mönstret. Du lägger till en instruktion så att agenten eskalerar aggressiva återbetalningsbegäran. Nu eskalerar den vanliga återbetalningar som borde hanteras snabbt. Du minskar verktygsanrop i ett arbetsflöde. Nu hoppar ett annat arbetsflöde över en obligatorisk kontroll. Du korrigera ett föråldrat minne. Nu generaliserar agenten överdrivet korrigeringen till en annan produktlinje.

Varje patch förstås lokalt. Systemet drifter fortfarande globalt.

Det är agentversionen av katastrofalt glömska. I neurala nätverk hänvisar termen vanligtvis till ny utbildning som skriver över äldre förmågor. I agenter är felet bredare och ofta svårare att se. Glömska kan hända i prompter, verktyg, minne, dirigering och arbetsflöde. Det visar sig inte som en ren metric på en utbildningskurva, utan som en användare som säger: “Det fungerade tidigare”.

Det är därför regressionskontroll inte kan vara ett slutgiltigt granskningssteg. Det måste vara inuti inlärningsslingan själv.

Målet är inte bara att maximera prestanda på den senaste felet. Målet är att förbättra det nya fallet samtidigt som man bevarar de gamla fallen. Varje lösning som fungerar ska bli en del av agentens växande minne av vad som måste fungera. I praktiken betyder det att gamla fel blir regressions tester. Agentens historia blir en begränsning, inte bara ett arkiv.

Det är där kontinuerligt lärande blir mer som allvarlig programvaruutveckling än prompttinkering. En förändring är inte bra för att den låter bättre. Den är bra för att den förbättrar ett mätt beteende och inte regresserar beteendena systemet redan hade tjänat.

Vad praktiskt kontinuerligt lärande kräver

En produktionsklar kontinuerlig inlärningsslinga behöver fyra egenskaper.

Först måste fel vara återupprepningsbara. Ett engångsfel är en anekdot. En återupprepningsbar, graderad miljö är en test. Tills agenten kan möta samma mönster igen kan ingen bevisa att lösningen fungerade.

Andra, diagnosen måste vara holistisk. Lösningen kan tillhöra modellen, men den kan också tillhöra minnet, prompten, verktygslagret eller arbetsflödet. Den bästa lösningen är vanligtvis den minsta varaktiga förändringen som förklarar felet.

Tredje, inlärningen måste vara livslång. Agenten ska inte förbättras den här veckan genom att tyst förstöra förra veckans hårda vunna beteende. Tidigare framgångar ska bli begränsningar under optimering, inte överraskningar efter distribution.

Fjärde, slingan måste vara effektiv. Om varje förbättring kräver ett kvartalsomträningsprojekt kommer systemet aldrig att hinna med produktion. Slingan måste prova billiga lösningar först, eskalera endast när det behövs och hålla verifikation nära förändringen.

Inget av detta betyder att agenter ska uppdatera sig blint. Det betyder tvärtom. Förbättring ska bli mätbar. Varje förändring ska ha en test, en före- och efter-poäng och en regressionskontroll.

Det är vad som förvandlar kontinuerligt lärande från en vag aspiration till en ingenjörsvetenskap.

Agenternas framtid kommer inte att definieras enbart av större kontextfönster, starkare basmodeller eller fler verktyg. Det kommer att bero på vad som händer efter distribution.

När agenten misslyckas i morgon, kan systemet förvandla det felet till en test? Kan det dirigera lösningen till rätt lager? Kan det bevisa att lösningen hjälpte? Kan det bevisa att ingenting annat bröt?

Om svaret är nej, lär sig agenten inte verkligen från produktion. Den ackumulerar risk.

De agenter som betyder något nästa kommer att göra något bättre. De kommer att ackumulera.