NVIDIA Research har løftet sløret for HORIZON, et agent‑rammeværk der kører selvstændigt, styrer ændringer i et isoleret git‑worktree og kun committer, når en eksekverbar acceptance predicate siger god for det. Tørt på papiret, men praktisk vigtigt. Ifølge MarkTechPost beskriver forskerholdet 100% gennemførsel på de evaluerede RTL‑benchmarks. Det fik mig til at standse op. Hvis det holder i praksis, flytter det barren for automatiseret hardware‑arbejde væsentligt. Kilder: MarkTechPost og det tilhørende arXiv‑paper, som bør gennemlæses i fuldtekst før konklusioner cementeres.
Hvorfor er det her interessant? Fordi hardware sjældent kan klares med ét godt prompt og noget pæn Verilog. Korrekthed handler om cyklus‑nøjagtighed, reset‑konventioner, bitbredder og alt det, der vælter designet, hvis det ikke testes i en simulator. HORIZON behandler derfor opgaven som repo‑evolution, ikke som prompt‑engang. Den forskel kan mærkes i praksis.
Hvad HORIZON grundlæggende er
Kernen i HORIZON er idéen om at hoste hver designopgave som et versionskontrolleret projekt, typisk et git‑worktree. Ikke en flygtig samtale med en model, men et faktisk repo‑spor, hvor hver ændring kan spores, genskabes, afvises eller bygges videre på. MarkTechPost fremhæver netop den framing: hardware‑design som repository‑niveau kodeevolution med verificerbar evidens som indgangsbillet til commit.
Forskerne formaliserer en “projektpakke” og sætter struktur over alt det, som ellers bliver til løs tekst i en prompt. Der optræder en kortfattet notation i paperet — p = (πagent, Ep, Ap, Γp, Ωp) — hvor hvert symbol repræsenterer et praktisk element i et kørbart setup. Det kan virke akademisk, men pointen er enkel: indpak opgaven og dens regler, så den kan køres igen i morgen.
Markdown‑harnessen der rammer ind
Den påkrævede input er en struktureret Markdown‑harness med fire felter: et mål, domæne‑vejledninger, en evaluator‑specifikation og et acceptance predicate. Det er det, der gør opgaven reproducerbar på tværs af kørsel og tid: retning, domænehints, en kørbar evaluator og en binær regel for godkendelse.
Strukturen tvinger arbejdet væk fra floskler og hen mod noget, der kan automatiseres. Og godt det samme: uden simulatorer og hårde checks er “pæn kode” ingen garanti for korrekt opførsel.
Fra harness til projektpakke
HORIZON starter med en bootstrap‑agent, som kompilerer harnessen til en projektpakke p = (πagent, Ep, Ap, Γp, Ωp). Her dækker πagent agentens beslutningspolitik, Ep er den eksekverbare evaluator, Ap er acceptance predicate, Γp er politikken for versionsstyring, og Ωp er domæne‑færdigheder og værktøjer. Det lyder ceremonielt, men formålet er drift: få alle afhængigheder skrevet ned og gjort kørbare.
Operationelt betyder det, at når pakken er dannet, kan systemet køre uden mere menneskelig input, fordi spillereglerne ligger i p. Skulle noget fejle, er det enten i evalueringen, acceptance‑reglen eller i selve ændringsforslaget. Fejlfinding får dermed et klart startsted — ikke et mysterium begravet i et langt chatforløb.
Agent‑looppet der lever i git
Når pakken er på plads, kører HORIZON et lukket loop: planlæg ændring, rediger worktree, kør værktøjer, evaluer, og enten commit eller log en fejl. Git er ikke et tilfældigt valg. Diffs bruges aktivt til at beskrive foreslåede ændringer, git diff –cached til at inspicere staged edits, commits bliver klare checkpoints, og git notes kan bære evaluatorevidens eller et “verdict”.
Pointen er sporbarhed til lav pris. Ingen separat erfaringsdatabase, fordi repo‑historikken i sig selv er experience buffer. Godkendte commits bliver positive reparations‑eksempler, afviste forsøg indgår som negative. MarkTechPost noterer også, at session‑genbrug og caching bruges til at sænke token‑forbrug, så nye tokens primært går til aktuelle diffs og seneste evaluatoroutput.
Evaluatoren for RTL‑arbejde
For RTL‑opgaver omtaler MarkTechPost, at Ep typisk inkluderer kompilering, simulation, coverage‑udtræk og assertion‑ eller testbench‑tjek. Det er præcis de trin, der fanger realiteterne i hardware. En syntaktisk korrekt Verilog‑fil er uinteressant, hvis resetsekvensen knækker på cyklus tre, eller en assertion i en TB råber “nej”.
Det interessante er, at samme Ep‑slot i andre domæner kan huse alt fra unit tests og profiler til theorem provers og synteseværktøjer. En slags adapter. Ideen er, at acceptance predicate først godkender et commit, når evaluatorens output opfylder en hård betingelse — ikke bare “det ser rigtigt ud”.
Resultaterne og 100%‑påstanden
MarkTechPost refererer, at HORIZON rammer “100% completion across every evaluated RTL benchmark suite”. Det er stærkt, hvis det bekræftes. Men konklusionens vægt afhænger af den fulde benchmark‑liste og eksperimentopstilling, som bør verificeres i arXiv‑paperet, før man ekstrapolerer til industrielle designs.
Forbeholdene fra forskerne selv
Det er værd at notere, at MarkTechPost anfører en udtrykkelig sætning fra holdet: agentisk hardware‑design er ikke løst. En nyttig tonic mod overoptimisme. Et system, der klarer benchmarks, har demonstreret kapacitet — ikke nødvendigvis generalisering til fulde SoC’er med mange tværgående afhængigheder.
Der er stadig huller: værktøjsintegration ved større skala, interaktion med eksterne verificeringsmiljøer, håndtering af afvigende reset‑/clock‑domæner, constraints og kroge ud i CDC, STA eller formal. Og så er der tiden: lange simulationer spiser ressourcer, og ingen agent gør dem gratis.
Reproducerbarhed og sporbarhed i praksis
Repo‑evolution som metode har en jordnær fordel: man kan genskabe alt. Acceptance‑beslutninger hænger på det commit, hvor de blev truffet. Evaluatorens output kan gemmes som artefakt og knyttes til versions‑ID. Når noget går galt to uger senere, findes konteksten i loggen — ikke kun i hukommelsen hos én senioringeniør med for mange opgaver.
Omkostninger, tokens og køretid
MarkTechPost fremhæver session‑genbrug og caching for at holde token‑forbrug nede. Fint. Men i RTL‑arbejde bliver regningen ofte domineret af simulationer og verificering. Her er kø‑ og cluster‑styring nødvendig, ellers drukner løbet i ventetid. Et pipeline‑design, der kan orkestrere lange simulationsserier headless i CI, er næsten et forkrav, hvis HORIZON‑stil automation skal betale sig.
Der er også spørgsmålet om latens. Hvis hver loop‑iteration kræver fuld regression, ender time‑to‑commit i rødt. Et mere realistisk mønster er incremental evaluering: hurtige sanity‑checks tidligt, dybere runs ved kandidater til endelig commit. Det er ikke nævnt direkte i kilderne, så betragt det som faglig vurdering, ikke citat.
Sikkerhed, compliance og versionsstyring
Automatiske commits i produktionsnære repoer rejser governance‑spørgsmål. Hvem må merge hvad, hvornår. Signed commits, obligatoriske reviewer‑krav og begrænsede tokens med least‑privilege er oplagte værn. IP‑beskyttelse kræver også, at evaluator‑logs og artefakter håndteres korrekt, så der ikke lækker designhemmeligheder i CI‑systemets bilag.
Det er almindelige principper fra CI/CD, men her skærpes de af, at en agent kan arbejde hurtigt og uden pause. En lille fejl i adgangspolitik kan lave stor skade. Politik for branches, worktrees og artifacts bør være på plads før første pilot — ikke efter første incident.
Kan det løftes til andre domæner
Strukturen med Ep som evaluator‑slot gør rammeværket overførbart: software‑moduler med unit tests, formelle beviser for kernekode eller profileringsmål i performancearbejde. Men overførbarhed er ikke lig garanti. De bedste resultater i hardware kommer netop af, at acceptance‑kriteriet er skarpt, simulatoren er autoritativ, og artifacts er veldefinerede.
I komplekse systemer med mange eksterne services bliver signal‑til‑støj lavere. Det kræver mere kuratering af acceptance‑predicate for at undgå falske positives. Muligt — men det kræver disciplin og tid.
Sammenligning med beslægtet arbejde
VentureBeat beskriver Alibabas SkillWeaver som et rammeværk, der opbygger en eksekveringsgraf og vælger relevante værktøjer per node med en feedback‑sløjfe kaldet Skill‑Aware Decomposition. Målet er bl.a. at undgå at loade hele værktøjskataloget for hver opgave, hvilket ifølge artiklen kan reducere tokenforbrug med over 99% sammenlignet med naive opsætninger.
Hvad en pilot bør indeholde
Et fornuftigt første skridt er at vælge en lavrisiko RTL‑komponent: en simpel datapath, en perifer controller, noget hvor testbench allerede findes. Skriv en stram Markdown‑harness med et tydeligt acceptance predicate. Kør agent‑looppet i et isoleret worktree med begrænset adgang.
Mål noget konkret: succesrate per iteration, tid til første godkendte commit, antal manuelle rettelser før merge til main. Sæt også governance‑hager i: signed commits, reviewer‑krav og artifacts‑arkivering. Hvis det hele virker, kan scope vokse. Ikke før.
Tooling, infra og kompetencer
For at lykkes kræves CI‑piber, der kan køre simulatorer headless, gemme artefakter og håndtere køer. Git‑disciplin med worktrees, branch‑politik og audit‑hooks. Og teamkompetencer i blandingen: RTL og testbenches, DevOps‑vaner samt evnen til at skrive robuste harnesses og acceptance‑regler. En lille detalje mange glemmer: definer konvention for logniveau, så fejl ikke drukner i normal støj.
Der kan også være brug for en cache‑politik for prompts og evaluator‑kilder, så opstartstiden ikke æder gevinsten. Her giver session‑genbrug mening, som MarkTechPost nævner, men det skal konfigureres omhyggeligt for ikke at bære forældet kontekst ind i nye loops.
Åbne spørgsmål der bør verificeres
Der er en række forhold, som den fulde arXiv‑tekst (og evt. forfatterne) bør afklare, før man lægger vægt bag de mest markante resultater. En prioriteret liste:
- Komplet benchmark‑liste og præcis testopsætning: navne, kompleksitet, simulatortyper, timeouts og iterationsgrænser for “100% completion”.
- Model‑backbone og agent‑infrastruktur: hvilken LLM, session‑krav, hukommelse, og om der er specialinstruktioner eller værktøjsintegrationer.
- Compute‑budget og runtime: gennemsnitlig tid per episode, fordeling mellem LLM‑kald og simulatorkørsel, samt maskinopsætning.
- Failure cases: hyppige fejlkilder, hvordan negative commits logges, og eksempler på mislykkede forløb.
- Skalering: resultater på større, flerkomponent designs og tværmodulære afhængigheder.
- Governance: praksis for adgangsrettigheder, commit‑signering og compliance i følsomme repoer.
- Licens og tilgængelighed: er koden til HORIZON, harness‑formatet og evaluatorer frigivet, og i givet fald hvordan.
- Token‑/latensdata for caching og session‑genbrug; målinger frem for anekdoter.
Hvorfor det her betyder noget
Den git‑drevne tilgang rykker automation tættere på de processer, teams allerede bruger: commits, reviews, artifacts. Hvis acceptance predicate kobles stramt til evaluatorens evidens, kan man opbygge en kæde af auditerbare checkpoints, som ikke bare er rare at have — de er praktiske ved fejlretning og ved regulatorisk dokumentation.
Det ændrer ikke verden på én dag. Men det flytter grænsen for, hvad der kan overlades til en agent uden at miste overblik og kontrol. Og det er trods alt pointen.
Konklusion
HORIZON orienterer agentarbejde mod repos, ikke prompts. Det er et klogt valg for hardware og andre domæner, hvor korrekthed måles ved eksekverbar evidens. 100%‑resultatet i MarkTechPosts gengivelse er stærkt, men kalder på fuld verifikation i arXiv‑paperet, herunder benchmark‑dækning og runtime‑profil. Indtil da er vurderingen nøgtern: lovende arkitektur, god sporbarhed og realistiske driftskrav. Vær nysgerrig — og forsigtig. Man opdager først forskellen, når man sidder med det i hænderne.
