L’ANALISI
Factory Droid: cosa cambia con Script mode
Analisi dell'harness annunciato il 29 ottobre: programmi JavaScript per chiamare gli strumenti, risultati filtrati e limiti dei confronti pubblicati da Factory.
In breve: Droid cambia il modo in cui un modello usa gli strumenti: può scrivere un programma che richiama più operazioni e stampare solo il riepilogo utile. È un cambiamento dell'harness, non un nuovo modello. Il beneficio si valuta su una sequenza concreta, controllando anche errori, permessi e risultati, non contando soltanto le chiamate risparmiate.
Modello e harness sono due componenti distinti
Factory definisce l'harness come il sistema attorno al modello: istruzioni, strumenti, restituzione dei risultati e ciclo di esecuzione. Il lancio del 29 ottobre riguarda questo livello. Il changelog del 30 ottobre indica già CLI e desktop 1.1.0: non bisogna usare quel numero per cambiare retroattivamente il nome dell'annuncio Droid 1.0. Factory Research: Droid 1.0, Building a Frontier Harness, 29 ottobre.
Che cosa fa il programma JavaScript
Nella descrizione ufficiale, lo Script gira in una sandbox senza accesso autonomo a file, rete o sistema; le operazioni passano attraverso i tool esposti. I risultati intermedi possono restare nelle variabili del programma e il modello riceve ciò che viene stampato. Questa separazione riduce la necessità di riportare ogni risultato grezzo nel contesto, ma non rende innocue le azioni consentite ai tool. Factory Research: Droid 1.0, Building a Frontier Harness, 29 ottobre.
Dove il raggruppamento è plausibilmente utile
Una sequenza di letture indipendenti, filtri e conteggi si presta a essere espressa in codice. Un'azione che dipende da una nuova decisione o autorizzazione non dovrebbe invece essere inglobata soltanto per ridurre i turni. La distinzione utile per chi progetta un agente è fra dipendenze note, controlli deterministici e scelte che richiedono ancora una revisione. Factory Research: Droid 1.0, Building a Frontier Harness, 29 ottobre.
I benchmark non sono una prova propria
Il rapporto presenta confronti con altri harness e ne discute condizioni e compromessi. Sono misure e dimostrazioni selezionate dal produttore. Non sono state ripetute in questa analisi: non viene quindi dichiarato un risparmio personale, né un vincitore generale. Un costo inferiore e una latenza inferiore sono risultati distinti, da verificare separatamente. Factory Research: Droid 1.0, Building a Frontier Harness, 29 ottobre.
Un protocollo per confrontare senza cambiare le regole
Un confronto pratico proposto usa stesso modello, repository, compito, autorizzazioni e budget; conserva le tracce delle chiamate e verifica il risultato con gli stessi test. Occorre distinguere richieste al modello, chiamate ai tool, token, costo e tempo complessivo. Ripetere la prova aiuta a non trasformare un singolo caso favorevole in una proprietà generale del prodotto. Factory Research: Droid 1.0, Building a Frontier Harness, 29 ottobre.
Condizioni e limitazioni
Documentazione e benchmark del produttore, non una prova runtime nell'account di Francesco. Meno chiamate al modello non garantisce meno tempo totale o risultati migliori in ogni compito. L'annuncio è del 29 ottobre; il changelog del client riporta separatamente la versione 1.1.0 del 30 ottobre. Factory Research: Droid 1.0, Building a Frontier Harness, 29 ottobre.
Checklist pratica
- Fissare versione del client, modello e configurazione usati nel confronto.
- Scegliere un compito ripetibile su dati non sensibili e definire il risultato atteso.
- Tenere uguali permessi, budget e condizioni di partenza.
- Registrare separatamente chiamate al modello, chiamate ai tool, token, costo e tempo.
- Verificare gli effetti delle scritture oltre al messaggio finale dell'agente.
- Pubblicare anche fallimenti e condizioni in cui il raggruppamento non conviene.