Passa al contenuto principale

Dentro Grok Build: leggere un harness di agente open

Avanzato

Il 14–16 luglio 2026 xAI ha pubblicato Grok Build — l'agente di coding dietro la sua CLI — come repository pubblico Apache 2.0 su xai-org/grok-build. Non i pesi. L'harness: il loop dell'agente, le implementazioni dei tool, l'interfaccia da terminale, il sistema di estensioni. È finito in prima pagina su Hacker News nel giro di poche ore.

È un artefatto raro. Quasi tutti gli agenti di coding seri — Claude Code, Cursor, Codex — vengono distribuiti come binario o come bundle. Qui ci sono circa 800.000 righe di Rust di produzione in un repository che puoi leggere. Vale più come libro di testo che come prodotto.

Questa pagina è la lettura pratica: cosa c'è davvero dentro, cosa insegna la struttura su come si costruiscono gli agenti, e due cose di questo rilascio che gran parte della copertura giornalistica ha raccontato al contrario.

What you'll learn
  • Capire cosa è stato pubblicato e cosa no — l'harness sì, i pesi no, la storia di sviluppo no
  • Leggere la mappa dei crate come una checklist di ciò che serve davvero a un agente di coding di produzione
  • Capire perché qui Apache 2.0 significa source-available, non open-development — e perché la distinzione è portante
  • Vedere il codice del data-collector ancora presente nell'albero pubblicato, e cosa confermano le sue costanti sull'incidente di esfiltrazione di luglio
  • Sapere cosa è realmente riutilizzabile da questo repository e cosa invece è un vicolo cieco

Cosa è stato pubblicato davvero​

Il repository è Rust per oltre il 99%, con licenza Apache 2.0, e si descrive come un harness per agente di coding più una TUI — a schermo intero, interattiva col mouse, estendibile. Si compila su macOS e Linux con una toolchain Rust fissata.

Tre cose che non è:

  • Non è il modello. I pesi di Grok 4.5 non sono qui e non sono aperti. L'harness parla con un endpoint hosted. Puoi leggere ogni riga di come l'agente ragiona sulla tua codebase e comunque non eseguirlo senza le API di xAI.
  • Non è una storia di sviluppo. Il repository ha due commit: Publish harness and TUI open-source, poi Synced from monorepo. Alla radice c'è un file SOURCE_REV che contiene un singolo hash di revisione interna. È l'export di un monorepo privato, ri-sincronizzato periodicamente — non un repository sviluppato in pubblico e non uno su cui puoi fare archeologia per capire le scelte di design.
  • Non è aperto a te. CONTRIBUTING.md dice chiaramente che il repository non accetta pull request esterne né patch non sollecitate, che xAI sviluppa il software internamente e che l'albero è pubblicato "per trasparenza del sorgente e build locali". Le issue di GitHub sono disabilitate a livello di repository.

★ La distinzione che conta: Apache 2.0 è una licenza, e ti concede diritti reali — leggere, forkare, modificare, distribuire derivati. Non dice nulla sulla governance. Grok Build è source-available sotto una licenza open-source con un modello di sviluppo chiuso. Puoi forkarlo; non puoi influenzarlo. Leggi "open source" nei titoli come "puoi leggere il sorgente", perché è esattamente e soltanto quello che viene offerto.

La mappa dei crate è la vera lezione​

Ignora il marketing. L'elenco delle directory sotto crates/codegen/ è la cosa più utile del repository, perché è un inventario onesto di ciò che serve a un agente di coding che va in produzione. Una selezione:

CrateCosa ti dice
xai-grok-agent, xai-grok-shellIl runtime dell'agente e i suoi entry point — interattivo, stdio, headless
xai-grok-tools, xai-grok-tools-apiLe implementazioni dei tool, separate dall'interfaccia dei tool — un confine vero
xai-grok-workspace, xai-fast-worktreeFilesystem, controllo di versione, esecuzione, checkpoint — e worktree git veloci
xai-codebase-graphComprensione strutturale di un repository, non solo grep
xai-grok-memoryLa memoria è un sottosistema, non un trucco di prompting
xai-grok-mcpMCP è una superficie di integrazione di prima classe
xai-grok-hooks, xai-hooks-plugins-typesHook e plugin hanno un proprio layer di tipi
xai-grok-subagent-resolutionDecidere quale subagente gestisce cosa è abbastanza difficile da meritare un crate a sé
xai-token-estimationContare i token prima di spenderli
xai-hunk-trackerTracciare gli hunk dei diff lungo una sessione di editing
xai-grok-pager, xai-ratatui-inlineLa TUI — scrollback, prompt, modali, rendering inline
xai-acp-libAgent Client Protocol — gli editor incorporano l'agente
xai-grok-telemetry, xai-mixpanelTelemetria e product analytics, come crate di prima classe
ptyctl, xai-tty-utils, xai-grok-crash-handlerI terminali sono ostili e i processi crashano

Rileggi quella lista come un piano di costruzione. Il modello mentale ingenuo di un agente di coding è "un loop che chiama un modello ed esegue tool". La decomposizione reale comprende un grafo della codebase, un sottosistema di memoria, il checkpointing, la gestione delle worktree, il tracciamento degli hunk, la risoluzione dei subagenti, la stima dei token, la gestione dei crash e un layer di controllo delle PTY — prima ancora di scrivere un singolo prompt.

★ La verifica di scala. Simon Willison ha contato 844.530 righe di Rust nell'albero, di cui solo il ~3% dipendenze vendorizzate, e ha notato che il Codex di OpenAI si attesta su circa 950.933 righe. Due team indipendenti, che convergono vicino al milione di righe, per "un loop attorno a un LLM". Se il tuo progetto di agente ti sembra fuori controllo, questa è la calibrazione: non sei tu, e la parte difficile non è mai stata il loop.

C'è anche un crate xai-grok-mermaid — un renderer da terminale che disegna diagrammi Mermaid con i caratteri Unicode di box-drawing. Non è importante. È un bel promemoria del fatto che la rifinitura è una frazione enorme di qualunque agente reale.

Il codice del data-collector è ancora nell'albero​

È qui che il repository smette di essere un libro di testo e comincia a essere una prova.

A luglio 2026 la cattura di traffico di un ricercatore ha mostrato Grok Build caricare interi repository — storia git completa, file mai letti, contenuti dei .env — su un bucket Google Cloud Storage, attraverso un canale scollegato da ciò che il modello leggeva. AILmanac copre quell'incidente e la modalità di fallimento generale in Cosa carica il tuo agente. xAI ha disabilitato il comportamento lato server e ha dichiarato che i dati conservati sarebbero stati cancellati.

Il sorgente pubblicato contiene quel macchinario. Verificabile direttamente dal repository:

  • crates/codegen/xai-grok-shell/src/upload/gcs.rs esiste.
  • crates/codegen/xai-file-utils/src/upload_config.rs definisce DEDUP_GCS_PREFIX = "repo_changes_dedup".

Quella costante è la parte interessante. L'upload intercettato dal ricercatore finiva su path di oggetti della forma gs://grok-code-session-traces/repo_changes_dedup/v2/…. Il prefisso del path catturato sul filo è una costante con nome nel sorgente pubblicato da xAI stessa. Lo stesso file definisce sia ARCHIVE_SCHEMA_VERSION (v2) sia ARCHIVE_SCHEMA_VERSION_V3 — il che significa che il formato dell'archivio era stato iterato fino a una terza versione. Era infrastruttura mantenuta, non un path di debug lasciato lì per caso.

La documentazione del modulo in gcs.rs è più esplicita di qualunque comunicato stampa. Definisce gli helper di upload "the data-collector helpers", e l'intera ragione di esistere del file è una correzione ingegneristica: far passare credenziali refresh-aware in modo che i token scaduti smettano di causare 401 su POST /v1/storage. Qualcuno stava debuggando l'affidabilità del path di upload dei repository come lavoro di produzione.

Simon Willison riporta che il path di upload ora è disabilitato nell'albero pubblicato e restituisce un errore hard-coded. È coerente con la posizione dichiarata da xAI, ma non siamo riusciti a confermare in modo indipendente il meccanismo specifico tramite ricerca nel codice — trattalo come riportato, non come verificato qui.

★ Cosa portarsi via. Non "xAI è unicamente cattiva" — la lezione più ampia della pagina sulla sicurezza resta valida: questa classe di canale esiste in qualche forma in molti agenti, e leggere il sorgente è l'unico modo per saperlo. Prendi invece il meta-punto: è esattamente a questo che serve la trasparenza del sorgente. Non puoi verificare i flussi di dati di un binario in un pomeriggio. Puoi fare grep di bucket_url in un albero pubblicato in circa dieci secondi. Il rilascio è genuinamente prezioso proprio perché rende greppabili le parti scomode.

Check yourself

0/4
  1. xai-org/grok-build ha licenza Apache 2.0. Cosa ti dice questo sul contribuire una fix upstream?
  2. Il repository ha due commit e un file SOURCE_REV alla radice che contiene un hash. Cosa significa?
  3. Quanto è grande all'incirca l'harness di Grok Build, e qual è la cifra comparabile per il Codex di OpenAI?
  4. Cosa conferma la costante DEDUP_GCS_PREFIX in upload_config.rs?

Cosa è davvero riutilizzabile​

Sii onesto sui vincoli prima di forkare:

Guided walkthrough1 of 4
  1. I confini tra i crate sono il prodotto di un team ben finanziato che spedisce a utenti veri. Quella decomposizione — tools separati da tools-api, workspace separato dall'agente, la risoluzione dei subagenti come preoccupazione a sé — è l'asset trasferibile. Copiare il Rust da lì ti rende molto meno che copiarne la forma.

Se vuoi esplorare l'albero senza compilarlo:

Clona e mappa la struttura dei crate

git clone --depth 1 https://github.com/xai-org/grok-build
cd grok-build

# The inventory of what a production coding agent needs
ls crates/codegen/

# Where does data leave the machine? Start here, not with the README.
grep -rn "bucket_url\|/v1/storage\|upload_bytes" crates/ --include=*.rs | head -30

# Which internal revision was this cut from?
cat SOURCE_REV

Dove si colloca rispetto a ciò che già conosci​

Se usi Claude Code, Grok Build è lo stesso tipo di strumento con le viscere in vista — leggilo come una seconda opinione su problemi che hai già. CLI di agenti di coding a confronto lo colloca rispetto al campo, e Grok per utenti Claude copre l'ecosistema xAI attorno a esso.

Per le idee architetturali a cui la mappa dei crate accenna, vedi harness per agenti a lunga esecuzione e architetture di memoria degli agenti — xai-grok-memory e xai-grok-subagent-resolution sono le risposte di un team a esattamente quei problemi.

E leggi Cosa carica il tuo agente insieme a questa pagina. Quella ti mostra come intercettare un canale come questo sul filo con mitmproxy e un repository canarino. Questa ti mostra che aspetto ha nel sorgente. Le due tecniche insieme sono l'audit completo.

Fonti e approfondimenti​