Η ανάπτυξη πρακτόρων AI συναντά τα RTL worktrees της NVIDIA
Η NVIDIA Research παρουσίασε το HORIZON στις 4 Ιουλίου 2026, ως ένα πλαίσιο χωρίς χειροκίνητη παρέμβαση για την ανάπτυξη πρακτόρων AI στον σχεδιασμό υλικού, αντιμετωπίζοντας το RTL ως εξέλιξη κώδικα σε επίπεδο αποθετηρίου αντί για εφάπαξ παραγωγή. Αυτό έχει σημασία επειδή μετατοπίζει τον σχεδιασμό του πράκτορα από την παραγωγή πιθανολογικά ορθού κώδικα στην εκτελέσιμη αποδοχή, με τα git commits να λειτουργούν ως αυστηρά σημεία ελέγχου. Σύμφωνα με μια σύνοψη του MarkTechPost για την εργασία, το σύστημα πέτυχε 100% ολοκλήρωση στα αξιολογούμενα σουίτες benchmark RTL.
Το HORIZON της NVIDIA μετατρέπει το RTL σε έναν git-native βρόχο πράκτορα
Διάβασα το HORIZON λιγότερο ως ιστορία μοντέλου και περισσότερο ως ιστορία ροής εργασίας. Η ερευνητική ομάδα της NVIDIA Research δεν ισχυρίζεται ότι ένα μεγαλύτερο backbone ξαφνικά έλυσε τον σχεδιασμό υλικού. Λένε ότι η μονάδα εργασίας ήταν λάθος. Αντί να ζητάει από ένα μοντέλο μια ολοκληρωμένη απάντηση σε Verilog, το HORIZON τοποθετεί την εργασία μέσα σε ένα απομονωμένο git worktree, επεξεργάζεται αρχεία, εκτελεί αξιολογητές και αποθηκεύει πρόοδο μόνο όταν περάσει η πύλη.
Αυτή η διάκριση έχει σημασία σε ομάδες ημιαγωγών και EDA επειδή το πιθανολογικά ορθό RTL είναι φθηνό, αλλά το εγκεκριμένο RTL είναι ακριβό. Ένα module μπορεί να φαίνεται σωστό και να αποτυγχάνει στη συμπεριφορά reset, στη διαχείριση bit-width ή σε edge cases του προσομοιωτή. Το HORIZON καθιστά το αποθετήριο, όχι το prompt, την επιφάνεια λειτουργίας.
Το κύριο αποτέλεσμα είναι ισχυρό: 100% ολοκλήρωση στο ChipBench, RTLLM, Verilog-Eval και CVDP στην εργασία HORIZON στο arXiv, με την εργασία να σημειώνει ότι ένα υπολειπόμενο miss οφειλόταν σε ελάττωμα του benchmark harness και όχι σε αποτυχία του πράκτορα. Αλλά η σημαντικότερη θέση είναι αρχιτεκτονική: η εκτελέσιμη ανατροφοδότηση είναι ο βρόχος.
Όπως το παραφράζει η σύνοψη πηγής, «ο πρακτορικός σχεδιασμός υλικού δεν έχει λυθεί.» Αυτή η προσοχή είναι σημαντική. Η εργασία αναφέρει ένα ορόσημο, όχι κλείσιμο.
Πώς το Markdown harness γίνεται το project pack
Η είσοδος που αντιμετωπίζει ο χειριστής είναι ένα δομημένο Markdown harness με τέσσερα μέρη: στόχος, καθοδήγηση τομέα, προδιαγραφή αξιολογητή και predicate αποδοχής. Μου αρέσει αυτός ο σχεδιασμός επειδή αναγκάζει την ομάδα να καταγράψει τι σημαίνει επιτυχία πριν ο πράκτορας αρχίσει να επεξεργάζεται κώδικα.
Σε πρακτικούς όρους, το harness γίνεται ένα project pack που περιέχει την πολιτική του πράκτορα, τον εκτελέσιμο αξιολογητή, τον κανόνα αποδοχής, τη συμπεριφορά ελέγχου εκδόσεων και τις δεξιότητες τομέα. Για το RTL, ο αξιολογητής μπορεί να περιλαμβάνει compilation, προσομοίωση, assertions και εξαγωγή κάλυψης. Με άλλα λόγια, το HORIZON δεν παράγει απλώς κώδικα· παράγει κώδικα μέσα σε ένα περιβάλλον που μπορεί να τον απορρίψει.
Αυτό είναι ένα χρήσιμο μοτίβο για custom AI agents πέρα από το υλικό. Σε ένα engagement πελάτη, ο μεγαλύτερος τρόπος αποτυχίας δεν ήταν η ποιότητα του μοντέλου. Ήταν η απουσία μιας εκτελέσιμης συνθήκης επιτυχίας. Αν το μόνο κριτήριο είναι «φαίνεται καλό», ο πράκτορας θα παρεκκλίνει. Αν το κριτήριο είναι «περνάει αυτό το test harness», ο βρόχος γίνεται διαχειρίσιμος.
Η εργασία στο arXiv κάνει επίσης μια σημαντική υλοποιητική παρατήρηση: η ίδια θέση που χρησιμοποιείται για προσομοίωση στο RTL θα μπορούσε να κρατήσει unit tests, theorem provers, profilers ή εργαλεία σύνθεσης σε άλλους τομείς. Γι' αυτό η έρευνα αυτή έχει σημασία τόσο για ευρύτερες enterprise AI integrations όσο και για ομάδες chip.
Τι σημαίνει η εξέλιξη σε επίπεδο αποθετηρίου για ομάδες υλικού
Αυτό είναι το μέρος που περιμένω οι ηγέτες μηχανικής να δανειστούν πρώτα. Το Git δεν είναι απλώς logging στο HORIZON. Είναι το control plane. Τα diffs εκθέτουν την προτεινόμενη αλλαγή κατάστασης, τα commits σηματοδοτούν εγκεκριμένα σημεία ελέγχου και οι σημειώσεις διατηρούν τα αποδεικτικά στοιχεία του αξιολογητή. Αυτό είναι λειτουργικά καθαρότερο από το να προσαρτήσεις ένα ξεχωριστό memory store σε μια στοίβα πράκτορα και να ελπίζεις ότι θα παραμείνει συνεπές.
Έχω δει έργα AI workflow automation να αποτυγχάνουν επειδή κάθε εκτέλεση αφήνει πίσω μερικές επεξεργασίες, αδιαφανείς επαναλήψεις και διφορούμενα αποτελέσματα δοκιμών. Ο βρόχος του HORIZON είναι αυστηρότερος: επιθεώρηση των staged changes, εκτέλεση του αξιολογητή, commit αν περάσει, log αν αποτύχει. Αυτό κάνει το rollback, το replay και το audit πολύ πιο εύκολα.
Για ομάδες υλικού, οι άμεσες περιπτώσεις χρήσης είναι αρκετά ξεκάθαρες:
- Παραγωγή RTL από natural-language specs
- Code completion μέσα σε υπάρχοντα modules
- Τροποποίηση και επαναχρησιμοποίηση module
- Παραγωγή test stimulus, checker και assertion
- Debugging έναντι ανατροφοδότησης προσομοιωτή
Αυτές αντιστοιχούν στενά στις κατηγορίες του CVDP και του RTLLM-2.0. Αντιστοιχούν επίσης στο πώς αναπτύσσονται AI automation agents σε πραγματικά περιβάλλοντα μηχανικής: όχι ως universal copilots, αλλά ως workers μέσα σε πεπερασμένους βρόχους.
Υπάρχει επίσης μια οικονομική διάσταση. Η αναφορά λέει ότι οι εννέα κατηγορίες CVDP κατανάλωσαν 203,9 εκατομμύρια tokens, ή 97,1% της συνολικής χρήσης tokens, ενώ περίπου 91% όλων των tokens ήταν cached input. Αυτό μου λέει ότι το πρόβλημα κόστους έχει μετατοπιστεί. Μόλις η ορθότητα γίνει υψηλή, οι ομάδες σταματούν να συζητούν αν ο πράκτορας μπορεί να λύσει την εργασία και αρχίζουν να ρωτούν πόσες επαναλήψεις χρειάζεται για να το κάνει φθηνά.
Από πού προέρχονται τα κέρδη benchmark — και από πού όχι
Ο αριθμός 100% χρειάζεται πλαίσιο. Το συνολικό first-iteration pass rate του HORIZON ήταν 47,8%, όχι 100%. Το τελικό σκορ προήλθε από iterative repair. Αυτό είναι χαρακτηριστικό, όχι αδυναμία, αλλά αλλάζει τον τρόπο που θα benchmarkάρω την ανάπτυξη πρακτόρων 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 εκατομμύρια tokens.
Αυτή η διασπορά είναι το πραγματικό λειτουργικό σήμα. Ορισμένες εργασίες είναι σχεδόν έτοιμες για ρουτινέρη αυτοματοποίηση. Άλλες είναι τεχνικά επιλύσιμες αλλά αρκετά ακριβές ώστε να θέλεις καλύτερη αρχιτεκτονική AI integration πριν την αναπτύξεις σε κλίμακα.
Νομίζω επίσης ότι η λεπτομέρεια του fixed-backbone έχει σημασία. Η εργασία λέει ότι το GPT-5.3 παρέμεινε fixed καθ' όλη τη διάρκεια της καμπάνιας. Το HORIZON καταγράφει μεταβάσεις κατάστασης χρησιμοποιώντας ημι-Markov γλώσσα, αλλά δεν εκπαιδεύει μια νέα RL policy κατά την εκτέλεση. Αυτό σημαίνει ότι η βελτίωση απόδοσης προέρχεται από τον σχεδιασμό του βρόχου, την πειθαρχία αξιολόγησης και τη μνήμη του αποθετηρίου, όχι από online weight updates.
Για επιχειρησιακές ομάδες που κοιτάζουν υπηρεσίες AI workflow automation, αυτό είναι το μεταβιβάσιμο μάθημα. Οι καλύτεροι βρόχοι συχνά κερδίζουν περισσότερο model tinkering.
Τα όρια: το πέρασμα του harness δεν είναι το ίδιο με τη λύση του σχεδιασμού
Εδώ νομίζω ότι η εργασία είναι αναζωογονητικά ειλικρινής. Το πέρασμα του ορατού harness δεν είναι το ίδιο με την ικανοποίηση του πλήρους σχεδιαστικού σκοπού. Οι συγγραφείς επισημαίνουν ρητά τον κίνδυνο reward hacking και over-solving. Αν ο αξιολογητής βλέπει μόνο μέρος της προδιαγραφής, ο πράκτορας μπορεί να βελτιστοποιηθεί για το ορατό test αντί για την πραγματική απαίτηση.
Αυτό το ζήτημα δεν είναι μοναδικό για το RTL. Εμφανίζεται σε repos λογισμικού, αυτοματισμούς υποστήριξης και agents εσωτερικών εργαλείων. Αν το predicate αποδοχής σας είναι ρηχό, το metric επιτυχίας σας θα είναι ρηχό.
Το άλλο περιορισμό είναι ο χρόνος αναμονής. Το HORIZON φαίνεται ισχυρότερο εκεί όπου η ανατροφοδότηση είναι σχετικά γρήγορη: compile, simulate, assert, repeat. Η εργασία σημειώνει ότι οι βρόχοι με προσανατολισμό PPA μπορούν να πάρουν μέρες ή εβδομάδες. Σε αυτό το πλαίσιο, η ίδια repository-native δομή μπορεί ακόμα να βοηθήσει, αλλά η οικονομική και η λογική χρονοδιαγραμματισμού αλλάζουν εντελώς.
Τι πρέπει λοιπόν να παρακολουθούν οι ομάδες; Πρώτον, αν η συνέχεια προσθέτει hidden tests, randomized checks και formal verification για να μειώσει το reward hacking. Δεύτερον, αν αυτοί οι repository-native βρόχοι μπορούν να διατηρήσουν την πειθαρχία τους όταν οι αξιολογητές γίνονται πιο αργοί, ευρύτεροι και πιο ακριβοί από τα σημερινά benchmark harnesses.
Σχετικές αναγνώσεις
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation