Разработката на AI агенти среща RTL worktrees на NVIDIA
NVIDIA Research представи HORIZON на 4 юли 2026 г. като hands-free framework за разработка на AI агенти в хардуерния дизайн, който третира RTL работата като еволюция на код на ниво repository, а не като еднократно генериране. Това е важно, защото измества дизайна на агентите от правдоподобен кодов изход към изпълнимо приемане, при което git commit-ите действат като твърди контролни точки. Според резюме на статията в MarkTechPost, системата е постигнала 100% завършеност във всички оценявани RTL benchmark пакети.
NVIDIA’s HORIZON turns RTL into a git-native agent loop
Аз разчитам HORIZON по-малко като история за модел и повече като история за workflow. Изследователският екип на NVIDIA Research не твърди, че по-голям backbone модел внезапно е решил хардуерния дизайн. Тезата им е, че единицата работа е била дефинирана погрешно. Вместо да се иска от модел завършен Verilog отговор, HORIZON поставя задачата в изолиран git worktree, редактира файлове, стартира evaluators и записва напредък само когато gate-ът е преминат.
Това разграничение е важно за semiconductor и EDA екипите, защото правдоподобният RTL е евтин, но RTL, който минава проверките, е скъп. Един модул може да изглежда правилен и въпреки това да се провали при reset поведение, обработка на bit-width или гранични случаи в симулатора. HORIZON прави repository-то, а не prompt-а, оперативната повърхност.
Основният резултат е силен: 100% завършеност при ChipBench, RTLLM-2.0, Verilog-Eval-v2 и множество CVDP категории, като в статията се отбелязва, че един оставащ пропуск се дължи на дефект в benchmark harness-а, а не на провал на агента. Но по-важното твърдение е архитектурно: изпълнимата обратна връзка е самият цикъл.
Както е перифразирано в източника, „agentic hardware design is not solved.“ Тази предпазливост е важна. Статията отчита важен етап, а не окончателно решение.
How the Markdown harness becomes the project pack
Входът за оператора е структуриран Markdown harness с четири части: цел, домейн насоки, evaluator specification и acceptance predicate. Харесвам този дизайн, защото принуждава екипа да опише как изглежда успехът, преди агентът да започне да редактира код.
На практика harness-ът се превръща в project pack, който съдържа policy за агента, изпълним evaluator, правило за приемане, поведение за version control и домейн умения. За RTL този evaluator може да включва compilation, simulation, assertions и извличане на coverage. С други думи, HORIZON не просто генерира код; той генерира код в среда, която може да го отхвърли.
Това е полезен модел за custom AI агенти и извън хардуера. В един клиентски проект най-големият режим на провал не беше качеството на модела. Беше липсата на изпълнимо условие за приемане. Ако единствената оценка е „изглежда добре“, агентът ще започне да се отклонява. Ако оценката е „минава този test harness“, цикълът става управляем.
Статията в arXiv прави и важна имплементационна точка: същият слот, който се използва за simulation при RTL, може да съдържа unit tests, theorem provers, profilers или synthesis tools в други домейни. Именно затова това изследване е важно за по-широки enterprise AI integrations, а не само за chip екипи.
What repository-level evolution means for hardware teams
Тук очаквам engineering лидерите първо да заемат идеята. В HORIZON Git не е просто логване. Той е control plane. Diff-овете показват предложената промяна на състоянието, commit-ите маркират приетите контролни точки, а notes запазват доказателствата от evaluator-а. Оперативно това е по-чисто от това да добавите отделен memory store към agent stack и да се надявате, че ще остане консистентен.
Виждал съм проекти за AI workflow automation да се провалят, защото всяко изпълнение оставя частични редакции, трудно проследими retries и неясен test output. Цикълът на HORIZON е по-строг: преглед на staged промените, изпълнение на evaluator-а, commit при успех, log при неуспех. Това прави rollback, replay и audit значително по-лесни.
За хардуерните екипи краткосрочните use case-и са съвсем директни:
- RTL генериране от спецификации на естествен език
- code completion в съществуващи модули
- модификация и повторна употреба на модули
- генериране на test stimulus, checker-и и assertion-и
- debugging спрямо обратна връзка от симулатора
Те съвпадат в голяма степен с категориите в CVDP и RTLLM-2.0. Съвпадат и с начина, по който AI automation agents се внедряват в реални инженерни среди: не като универсални copilots, а като изпълнители в рамките на ограничени цикли.
Има и икономически аспект. Според доклада деветте CVDP категории са изразходвали 203.9 милиона токена, или 97.1% от общото използване на токени, докато около 91% от всички токени са били cached input. За мен това показва, че проблемът с разходите вече е на друго място. Когато коректността стане висока, екипите спират да спорят дали агентът може да реши задачата и започват да питат колко итерации са нужни, за да го направи икономично.
Where the benchmark gains come from—and where they do not
Числото 100% изисква контекст. Общият first-iteration pass rate на HORIZON е 47.8%, а не 100%. Финалният резултат идва от итеративно поправяне. Това е предимство, а не слабост, но променя начина, по който аз бих измервал вътрешно разработката на AI агенти.
Ако един екип следи само Pass@1, ще пропусне за какво е създадена тази система. HORIZON е проектиран така, че част от debugging-а да се отложи за следващи итерации. При по-лесни пакети като RTLLM-2.0 и Verilog-Eval-v2 конвергенцията е настъпила в рамките на две итерации. При по-трудните категории „опашката“ е дълга. CVDP CID 013 checker generation е започнала от 3.8% и е достигнала 100% до итерация 19. CID 002 code completion е изисквала 82 итерации и 56.0 милиона токена.
Тази вариация е реалният оперативен сигнал. Някои задачи са почти готови за рутинна автоматизация. Други са технически решими, но достатъчно скъпи, така че ще ви е нужна по-добра AI integration architecture, преди да ги внедрите в мащаб.
Смятам също, че детайлът с фиксирания backbone е важен. В статията се казва, че GPT-5.3 е останал непроменен през цялата кампания. HORIZON записва преходите на състоянието със semi-Markov терминология, но не обучава нова RL policy по време на изпълнението. Това означава, че подобрението в резултатите идва от дизайна на цикъла, дисциплината на оценяване и repository memory, а не от онлайн актуализации на теглата.
За enterprise екипите, които разглеждат AI workflow automation services, това е основният преносим извод. По-добрите цикли често побеждават допълнителното донастройване на модела.
The limits: passing the harness is not the same as solving design
Тук според мен статията е освежаващо честна. Минаването на видимия harness не е същото като покриване на пълния замисъл на дизайна. Авторите изрично посочват риска от reward hacking и over-solving. Ако evaluator-ът вижда само част от спецификацията, агентът може да оптимизира за видимия тест, а не за реалното изискване.
Този проблем не е уникален за RTL. Среща се и в software repository-та, support automation-и и вътрешни tooling агенти. Ако acceptance predicate-ът ви е плитък, и метриката ви за успех ще бъде плитка.
Другото ограничение е времето за обратна връзка. HORIZON изглежда най-силен там, където feedback-ът е сравнително бърз: compile, simulate, assert, repeat. В статията се отбелязва, че PPA-oriented loop-овете могат да отнемат дни или седмици. В такъв контекст същата repository-native структура може отново да помогне, но икономиката и логиката на планиране се променят изцяло.
И така, какво трябва да следят екипите по-нататък? Първо, дали следващите разработки ще добавят hidden tests, randomized checks и formal verification, за да намалят reward hacking-а. Второ, дали тези repository-native цикли ще запазят дисциплината си, когато evaluator-ите станат по-бавни, по-широки и по-скъпи от днешните benchmark harness-и.
Related reads
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation