# Hur återskapar du ett fel hos en kodningsagent mellan modellversioner? > Återskapa ett fel hos en kodningsagent genom att spara hela körningen som en versionshanterad testfixture. Kör sedan samma prompt, commit, verktygskontrakt, miljö och stoppregler flera gånger mot låsta modell-ID:n. Jämför strukturerade händelser och kodförrådets sluttillstånd, inte bara assistentens text. # Hur återskapar du ett fel hos en kodningsagent mellan modellversioner? En användbar reproduktion är ett körbart experiment, inte en kopierad transkription. Börja från kodförrådets felande tillstånd, lås all indata agenten kunde se och definiera ett maskinkontrollerbart villkor för felet. Spela sedan upp fixturen flera gånger mot låsta modellversioner. En agentkörning kombinerar modellbeteende med verktyg, filer, nätverksresultat, orkestrering och timing. Om något av detta ändras bevisar ett annat resultat inte att modellen löste eller orsakade problemet. ## Definiera felet som ett villkor Skriv det minsta observerbara villkoret som skiljer fel från framgång. Bra villkor är ett test som förblir rött, en oväntad filändring, ett förbjudet kommando, en saknad migrering eller en patch som kompilerar men ändrar beteende. Undvik villkor som "svaret ser sämre ut". Ett acceptanspaket kan kräva att: * det ursprungliga regressionstestet godkänns; * alla befintliga tester fortfarande godkänns; * inga filer utanför en allowlist ändras; * agenten stoppar inom ett fast antal modellanrop; * slutdiffen saknar genererade hemligheter och lockfile drift. ## Spara hela körningens envelope Prompten är bara en indata. Spara följande intill fixturen: | Lager | Vad som ska låsas | Varför det ändrar resultatet | |---|---|---| | Kodförråd | Commit, submodules, ocommittad patch, ospårade fixture-filer | Agenten resonerar från exakt källtillstånd | | Instruktioner | Systemprompt, kodförrådsregler, användaruppgift | Små ordskillnader ändrar planeringen | | Modell | Leverantör, oföränderligt modell-ID, parametrar | Alias och standardvärden kan flyttas | | Verktyg | Namn, JSON-scheman, behörigheter, timeout | Verktygens möjligheter formar planen | | Miljö | Containeravbildning, OS, arkitektur, beroendelås | Kommandon och tester kan bete sig olika | | Externa data | Mockade HTTP-svar, klockor, slumpindata | Livetjänster introducerar drift | | Orkestrator | Loopgräns, retry-policy, kontextkomprimering | Samma modell kan få olika historik | Maskera hemligheter, men bevara om autentiseringsuppgifter fanns och vilken omfattning de hade. ## Registrera strukturerade händelser, inte bara text Spara varje modellbegäran, modellsvar, verktygsanrop, verktygsresultat, omförsök och stoppbeslut som en ordnad händelse. Lägg till innehållshash för stora resultat och lagra originalartefakten separat. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Strukturerade händelser visar om den nya modellen valde ett annat verktyg, tolkade samma fel annorlunda eller fick andra belägg. ## Lås versioner och ta bort live-variation Använd daterade eller oföränderliga modell-ID:n när de finns. Jämför inte ett historiskt fel med aliaset `latest`, eftersom det redan kan peka på en annan build. Kör i en ren container eller virtuell maskin. Ersätt livesökningar och föränderliga paketindex med inspelade svar eller interna snapshots. Lås klockan när logiken är datumkänslig. Om nätverk krävs, registrera alla svar och märk testet som delvis kontrollerat. Ett slumpfrö hjälper, men låser inte distribuerad inference, verktygstiming eller ändringar hos leverantören. ## Spela upp en matris, inte ett enda par En körning per version kan inte skilja regression från samplingsvariation. Använd en liten matris som håller fixturen konstant: | Modellversion | Upprepningar | Godkänd andel | Mediananrop | Felsignatur | |---|---:|---:|---:|---| | Låst baslinje-ID | 5 | 4/5 | 9 | Test av gränsfall missades | | Låst kandidat-ID | 5 | 1/5 | 13 | Genererad fil ändrades | | Kandidat med gammal prompt | 5 | 1/5 | 12 | Samma signatur | Fem upprepningar ger en första bild. Öka urvalet för intermittenta eller viktiga fel. Håll temperatur och andra samplingskontroller lika om experimentet inte handlar om dem. ## Jämför beslut och kodförrådets tillstånd Jämför fyra lager separat: * normaliserade modell- och verktygshändelser; * kommandon och exitkoder; * slutligt filträd och patch; * acceptanstest och resursanvändning. Kräv inte identiskt naturligt språk. Två versioner kan ta olika vägar till likvärdiga korrekta patchar. Liknande text kan däremot dölja ett väsentligt annorlunda kommando eller filbyte. ## Minimera fixturen efter reproduktion När felet upprepas tar du bort irrelevanta filer, verktyg, promptstycken och externa anrop ett i taget. En liten fixture kör snabbare och visar den kausala gränsen. Behåll två artefakter: full incidentuppspelning för granskning och ett minimerat regressionstest för kontinuerlig utvärdering. Lägg till det minimerade fallet i grinden för modelluppgraderingar. ## Använd en portabel modelladapter En gateway som Atlas Cloud kan lägga flera modeller bakom en OpenAI-kompatibel klient, men kompatibilitet gör inte modeller beteendemässigt identiska. Håll modell-ID:n, leverantörsalternativ och skillnader i verktygsformat i en adapter. Den gemensamma testmiljön ska äga fixtures, händelseloggar, omförsök och villkor. Strukturen låter samma reproduktion köras mellan leverantörer utan omskrivning av utvärderingslogiken. ## Slutsats För att återskapa ett fel hos en kodningsagent låser du körningens envelope, spelar upp låsta modeller flera gånger och bedömer körbara resultat. Om den exakta incidenten inte går att återskapa, märk vilka indata som förblev live och behandla resultatet som en jämförelsestudie, inte bevis på modellregression. ## FAQ ### Vad måste sparas för att återskapa ett fel hos en kodningsagent? Spara commit och ocommittad patch, prompt och systeminstruktioner, modell-ID, parametrar, verktygsscheman och resultat, miljöavbildning, beroendelås, policy för autentiseringsuppgifter och nätverk samt det exakta framgångsvillkoret. ### Bör jag spela upp felet med modellaliaset latest? Nej. Använd oföränderliga eller daterade modell-ID:n. Ett latest-alias kan ändras under testet och gör att resultatet inte kan knytas till en bestämd version. ### Varför räcker inte ett fast slumpfrö? Ett frö låser inte leverantörens infrastruktur, verktygens timing, retrieval-resultat eller modellrevisioner. Det är en kontroll bland flera, inte en garanti för deterministisk utdata. ### Vilken är den bästa godkänd- eller underkändsignalen för en kodningsagent? Föredra körbara villkor som tester, lintresultat, förväntade fildiffar, kontroller av förbjudna filer och kommandons exitkoder. Textlikhet är oftast för svagt för kodningsuppgifter. ### Hur många upprepningar bör jag köra per modellversion? Kör tillräckligt många för att skilja en deterministisk regression från samplingsvariation. Fem körningar är en bra start, medan fel med stor påverkan kan motivera tjugo eller fler. ### Kan samma testmiljö jämföra modeller från olika leverantörer? Ja, om du normaliserar begäran, verktygskontraktet, händelseloggen och utdatavillkoren. Håll leverantörsspecifika alternativ i adaptrar.