Meta-körmiljö säkrare självförbättrande AI-flöden för företag

En strukturerad Meta-körmiljö hjälper företagsteam att säkert förbättra Agent-flöden för långvariga kodningsuppgifter.

Sammanfattning

  • Befintliga system för autonom förbättring har gett starka resultat i kodningsuppgifter, men det är fortfarande oklart om de kan förbättra komplexa och långvariga AI-flöden som liknar verkliga företagsimplementeringar.

  • Vår forskning om Meta-körmiljö tillämpar autonom självförbättring på agentbaserad sökning, Djup forskning och signalanalys. Samtidigt tillför den företagskrav som utvärdering mot undanhållna data, spårbarhet, budgetkontroller och mänskligt godkännande.

  • Meta-körmiljö förbättrade prestandan avsevärt i tre representativa arbetslaster, bland annat med 84 % bättre resultat i undanhållna tester för Signal Engine och högre träffsäkerhet med 16 gånger snabbare körning för agentbaserad multimodal sökning.

  • Till skillnad från de flesta tidigare metoder mäter Meta-körmiljö när det är möjligt framgång på undanhållna datamängder. Det visar om förbättringarna går att generalisera bortom de data som användes vid optimeringen.

  • Resultaten tyder på att autonom förbättring av arbetsflöden kan gå bortom riktmärken för kodning och användas i verkliga AI-system för företag. Det skapar en praktisk väg mot AI-tillämpningar som kontinuerligt blir bättre.

Ny forskning om autonom AI-forskning, däribland artikeln om Meta-körmiljö, ramverket CORAL och karpathy/autoresearch, har visat att kodningsagenter stegvis kan förbättra en lösning utifrån ett utvärderingsmått. Den öppna frågan är om metoderna fungerar för långvariga AI-flöden, exempelvis agentbaserad multimodal sökning där en Agent stegvis söker i multimodala ämneskorpusar för att besvara en fråga, eller komplexa databehandlingsflöden som kräver många beroende steg, verktygsanrop och beslut om undantagshantering. Den djupare frågan är om förbättringarna håller även för data som optimeraren aldrig ser.

Vårt utvecklingsarbete med Meta-körmiljö är vårt svar på den frågan. Det bygger på idéer från ny forskning och anpassar dem efter företagens behov: utvärdering mot undanhållna data, granskningsspår, kostnadstak och en tydlig överlämning till en mänsklig granskare före driftsättning.

Vi testade det på tre långvariga uppgifter utformade efter verkliga kunduppdrag. Signal Engine övervakar ett direktflöde med X-inlägg om AI-marknaden och skapar strukturerade trendrapporter med tydliga källor. Agentbaserad multimodal sökning resonerar över frågor som kombinerar text och bild för att hitta de mest relevanta dokumentsidorna. Djup forskning samordnar flera agenter som söker på webben, dubbelkontrollerar källor och skriver utförliga forskningsrapporter.

Resultaten i korthet

  • Signal Engine: det sammansatta resultatet i undanhållna tester ökade från 0,456 till 0,841, en relativ förbättring på 84 %. CORAL och karpathy/autoresearch låg kvar under 0,50 med samma budget.

  • Agentbaserad multimodal sökning: NDCG@10 för undanhållna data ökade från 0,705 till 0,744, samtidigt som den faktiska tiden per utvärdering sjönk från 869 s till 54 s. Det innebär 16 gånger högre hastighet och samtidigt bättre träffsäkerhet.

  • Djup forskning: det sammansatta måttet för rapportkvalitet ökade från 0,449 till 0,802 för tio referensfrågor, jämfört med cirka 0,52 för baslinjerna. Uppgiften saknade en undanhållen datamängd, så vi betraktar endast resultatet som ett mått på träningsdata.

  • Sökeffektivitet: med prediktiv omrangordning av hypoteser nådde Signal Engine 91 % av referenskörningens bästa resultat på 3 iterationer i stället för 20, med samma utvärderingsbudget.

De flesta autonoma forskningssystem optimerar och utvärderar mot samma datamängd, vilket gör det omöjligt att avgöra om resultatet går att generalisera. För Signal Engine och agentbaserad multimodal sökning tillämpar vi en strikt uppdelning: en träningsmängd som kandidaterna kan poängsättas mot, en utvecklingsmängd för rimlighetskontroller och en undanhållen testmängd som optimeraren aldrig ser. Varje redovisat resultat kommer från en specifik kodversion som poängsatts på samtliga datamängder. Vi blandar därför aldrig den bästa träningspoängen från en kandidat med den bästa testpoängen från en annan.

Så fungerar det

I varje runda genererar körmiljön en uppsättning strukturerade hypoteser om hur koden kan ändras. Varje hypotes anger vilken mekanism som ska ändras, vilken tidigare version den bygger på och vilket feltillstånd den ska åtgärda. Ett rangordningssteg filtrerar uppsättningen innan resurser läggs på kostsamma utvärderingar. De återstående hypoteserna skickas till parallella arbetsagenter som delar en gemensam kunskapsbas men redigerar kod i helt isolerade Arbetsytor. Därmed bedöms varje kandidat rättvist och oberoende. I slutet av rundan utser körningen en vinnare: kandidaten med högst poäng som dessutom klarade samtliga kontroller i de synliga datamängderna. Vinnaren blir utgångspunkten för nästa runda. Varje försök sparar ett fast paket i ett evidenslager där data bara kan läggas till: kodändringen, poäng per datamängd, en händelselogg och fyra korta LLM-skrivna analyser av körspår, fel, kostnad och reflektion. Nästa rundas förslagsgenerator läser historiken, så att körmiljön bygger vidare på sina lärdomar i stället för att upprepa samma återvändsgränder.

Flödesschema för Meta-Harness med indata, utvärdering av startversionen, hypotesutforskning, parallella Agent-team, en Arbetsyta för utvärdering, granskningsresultat, ett evidenslager samt säkerhets- och kostnadskontroller.

Tre skyddsmekanismer gör loopen säker att köra. En omfångspolicy begränsar vilka filer en kandidat får ändra och återställer allt utanför det tillåtna omfånget. Budgetar för Token och faktisk körtid stoppar körningen när kostnadstaket nås, medan samtidighetsgränser håller körmiljön inom Modellernas och GPU:ernas kapacitetsgränser. Körmiljön driftsätter heller aldrig något på egen hand. Den levererar en rangordnad och fullständigt dokumenterad kandidat. En mänsklig utvecklare granskar kodskillnaden och avgör om den ska driftsättas.

Bakom kulisserna

I en lokal teknikstack ligger fem tekniska grundkomponenter bakom varje runda i loopen ovan.

  • Isolering av Arbetsytor. Ett git-arbetsträd per kandidat. Kodkopiorna delar en objektdatabas men aldrig varandras filer. Kandidater kan därför köras parallellt med nästan konstant diskkostnad, och det blir enkelt att jämföra skillnader mot den aktuella ledande versionen.

  • Exekveringssandlåda. Två lägen via konfigurationen: en inbyggd underprocess för snabba iterationer eller en helt isolerad körmiljö. Korpusen monteras skrivskyddad och den tillfälliga katalogen för varje försök raderas efter bedömningen. Ett försök kan därför varken ändra datamängden eller läcka tillstånd till nästa försök.

  • Omfångspolicy. En lista över tillåtna sökvägar som anges i experimentkonfigurationen. Alla ändringar utanför listan återställs innan försöket bedöms, och försöket flaggas. Kodskillnaden som granskaren ser ligger därför garanterat inom det angivna omfånget.

  • Budgetkontroll. Tre nivåer: gränser för Token och faktisk körtid per försök, ett totalt tak per körning och en samtidighetsgräns. Tillsammans gör de kostnaden förutsägbar och säkerställer att körmiljön håller sig inom Modellernas och infrastrukturens kapacitetsgränser.

  • Evidenslager. En JSONL-fil där endast tillägg tillåts och som innehåller kodändringen, poäng per datamängd, händelseloggen och de fyra LLM-skrivna analyserna. Materialiserade vyer – topplista, ledande version och felindex – återskapas efter varje försök. Senare rundor kan då bygga vidare på historiken, samtidigt som varje körning kan återskapas exakt, byte för byte.

Ingen av dessa grundkomponenter är valfri. Syftet med körmiljön är att granskaren efter en körning ska ha något som faktiskt går att godkänna: en vinnande kandidat, en avgränsad kodskillnad, fullständig dokumentation över allt som provats och en känd kostnad. Om någon av de fem tas bort försvinner en av dessa garantier.

Prediktiv omrangordning av hypoteser

Alla tre experiment använder samma hypotesstrategi. I varje iteration skapar förslagsgeneratorn fler hypoteser än budgeten tillåter att köra: M = 8 kandidater för en körbudget på K = 4. En separat LLM-rangordnare sorterar sedan alla åtta i ett enda trettiosekundersanrop med hela bilden framför sig: det nuvarande bästa resultatet och dess svaga dimensioner, felanalyser från de senaste försöken samt alla åtta förslag sida vid sida. De fyra främsta skickas till exekveraren och tar 15–30 minuter vardera. De övriga fyra tas bort innan de förbrukar några resurser.

Utvärderingar

De underliggande Modellerna var oförändrade genomgående. Körmiljön redigerade endast koden runt dem. Signal Engine och Djup forskning kördes på gpt-5.5. Agentbaserad multimodal sökning kördes på den öppenviktade Qwen3.6-35B-A3B, som tillhandahölls lokalt via vLLM och kombinerades med bildsökningsmodellen ColQwen3-4B. Kombinationen valdes för att ge en förutsägbar lokal kostnad.

Diagrammet nedan visar hur resultaten förändrades för våra tre huvuduppgifter. ”Seed” är den ursprungliga koden som skrevs av en mänsklig utvecklare. ”Meta-körmiljö” är den bästa version som Meta-körmiljön hittade. Prestandan förbättrades för alla tre uppgifterna i den undanhållna testmängden.

Stapeldiagram som jämför startversionens och Meta-Harness prestanda för Signal Engine, agentbaserad multimodal sökning och Djup forskning. Meta-Harness presterar bättre i alla undanhållna tester.

Signal Engine utvärderades av en LLM-domare utifrån aktualitet, faktakorrekthet, detaljnivå och ton, med 150 träningsinlägg och 150 undanhållna testinlägg från X. Under körningen förbättrade den bästa versionen det sammansatta träningsresultatet från 0,431 till 0,756 och resultatet för undanhållna data från 0,456 till 0,841. Förbättringarna kom från ändringar i själva körmiljön, inte bara justerade Promptar. De vinnande iterationerna lärde sig att filtrera bort brus från sociala medier, lade till steg för faktakontroll och krävde att varje resultat skulle förankras i tydliga belägg. Diagrammet nedan visar iterationsprocessen.

Linjediagram över Signal Engines träningsförsök. Bästa löpande resultat och poäng för undanhållna data förbättras från startversionen mot målet genom iterativa utforsknings- och finjusteringsförsök.

Försökshistoriken visar hur förbättringarna byggdes upp. En tidig strukturell ändring höjde det hittills bästa resultatet till 0,625. Mer detaljerad hantering av belägg lyfte det till 0,679, och en förbättrad loop för reflektion och bedömningskriterier höjde det till 0,819. Ungefär hälften av alla kandidatförsök presterade sämre eller misslyckades helt, men de påverkade inte topplistan: varje kodkopia kördes isolerat, förlorande kodskillnader kasserades och felen sparades i reflektionslagret så att nästa förslagsgenerator inte skulle upprepa samma återvändsgränd.

Viktigast av allt var att kurvan för undanhållna data steg parallellt med träningskurvan under hela körningen. Det tyder på att körmiljön förbättrade arbetsflödet i stället för att memorera träningskorpusen. Resultaten för undanhållna data var något högre än träningsresultaten. Vi tolkar det som normal urvalsvariation mellan två små, åtskilda datamängder.

Agentbaserad multimodal sökning mäts med NDCG@10 på den offentliga datamängden Computer Science i ViDoRe V3, uppdelad i 20 träningsfrågor, 10 utvecklingsfrågor och 20 undanhållna testfrågor. Körmiljön höjde NDCG@10 för undanhållna data från 0,705 till 0,744 och minskade samtidigt den totala faktiska utvärderingstiden från 869 sekunder till 54 sekunder.

Djup forskning bedöms med ett LLM-baserat sammansatt mått för innehållskvalitet och referenskvalitet enligt DeepResearch-Eval, över tio referensfrågor. Den förbättrade koden höjde genomsnittet från 0,449 till 0,802. De vinnande ändringarna framgick tydligt av kodskillnaden: ett inledande planeringssteg som jämför metoder innan några forskningsagenter startas och ett avslutande granskningssteg inriktat på de dimensioner där rapporterna historiskt hade fått låga poäng. Eftersom datamängden är liten och dyr att utvärdera delade vi inte upp den, och vi betraktar resultatet som ett mått på samma data som användes vid optimeringen.

Jämförelse med CORAL och karpathy/autoresearch

Stapeldiagram som jämför Meta-Harness, CORAL och karpathy/autoresearch för Signal Engine, agentbaserad multimodal sökning och Djup forskning utifrån resultat och utvärderingstid.

Vi jämförde alla tre metoder med samma budget: samma datamängder, samma underliggande Modeller, samma iterationsgräns och samma totala antal kandidatutvärderingar. För Signal Engine når Meta-körmiljö 0,841 i det undanhållna testet, medan båda baslinjerna låg kvar under 0,50. För agentbaserad multimodal sökning får vårt team högst NDCG@10 på undanhållna data (0,744 jämfört med 0,700 för CORAL och 0,738 för karpathy) och kör den officiella utvärderingen 12–14 gånger snabbare: 54 s jämfört med 786 s och 650 s. För Djup forskning når vårt team 0,802, medan båda baslinjerna låg kvar kring 0,52. En reservation gäller genomgående: vi implementerade CORAL och karpathy/autoresearch på nytt utifrån deras publicerade beskrivningar. En del av skillnaden kan därför bero på implementeringen och inte enbart på metoderna.

Fyra designval förklarar skillnaden. För det första skapar vårt team en strukturerad designspecifikation innan någon kod redigeras. Det styr arbetet mot strukturella ändringar, som nya steg i processen, snarare än justeringar av Promptar. För det andra körs samtidiga kodkopior med en gemensam ledande kandidat som utgångspunkt. Förbättringar byggs därför på varandra snabbare än med CORALs oberoende agenter eller karpathys strikt sekventiella loop. För det tredje lämnar varje försök strukturerade artefakter – poäng, händelseloggar och fyra LLM-skrivna analyser – som nästa förslagsgenerator läser. Baslinjerna behåller endast enkla försöksloggar. För det fjärde styr en adaptiv kontroll förslagsgeneratorn mot utforskning efter ett stillestånd och mot finjustering efter en framgång. Ovanpå detta används prediktiv omrangordning av hypoteser för att sålla bort svaga idéer innan de förbrukar budget.

Det här har vi inte visat

Kurvorna för undanhållna data visar generalisering inom samma område, inte överföring mellan områden. Ett arbetsflöde som optimerats för att hitta signaler på AI-marknaden kan inte förväntas fungera lika bra för juridisk eller biomedicinsk text utan att körmiljön körs på nytt. Körmiljön optimerar dessutom enbart mot det mål som bedömaren definierar. En brusig träningsmängd eller en felkalibrerad domare kommer därför att överanpassas troget. Inför en omfattande körning rekommenderar vi minst 20 noggrant utvalda träningsobjekt och en separat utvecklingsmängd. Kostnaden är den största praktiska begränsningen. Varje utvärdering kör hela processen på nytt mot samtliga datamängder. Enbart den valda sökkandidaten förbrukade cirka 2,2 miljoner indata-Token, och en omfattande optimering med en Modell i gpt-5.5-klassen kostar från några hundra till drygt tusen dollar per uppgift. Slutligen kommer siffrorna från enskilda körningar och inte upprepade försök. Därför delar vi dem i ett tekniskt blogginlägg snarare än i en formell studie.

Slutsats

Meta-körmiljö visar att autonom kodförbättring kan göras tillräckligt strukturerad för företagsanvändning. Grundkomponenterna är strukturella hypoteser, prediktiv förfiltrering, isolerad utvärdering, testning mot undanhållna data när underlaget tillåter det och ett fullständigt granskningsspår för varje ändring som går vidare. Tillsammans ger de utvecklingsteamet en förutsägbar väg från en fungerande startprocess till en mätbart bättre version. Samtidigt får den driftansvariga en enkel Modell: fördelarna med autonom utforskning inom ett strikt, budgetmedvetet ramverk där en människa alltid granskar före driftsättning.

Författare

David Huang, Bjorn Jee