Pi come harness minimale

In breve

Pi è un coding-agent harness da terminale progettato per essere piccolo e componibile. Il nucleo offre gli strumenti essenziali per leggere, scrivere, modificare ed eseguire comandi; skill, estensioni e convenzioni restano visibili come aggiunte del progetto. «Minimale» non significa automaticamente più semplice o più sicuro: significa che l’adozione deve decidere esplicitamente ciò che altri prodotti includono nel core.

La sottrazione come contratto

La sezione Philosophy del repository ufficiale dichiara fuori dal nucleo MCP, sub-agent, popup di autorizzazione, plan mode, to-do e bash in background. Sono assenze intenzionali, non divieti: estensioni e strumenti esterni possono aggiungerle. Il vantaggio editoriale è la tracciabilità; quando compare una funzione, si può chiedere quale componente l’abbia introdotta.

Necessità	Nel nucleo	Decisione dell’adozione
lettura, modifica, shell	strumenti built-in	restringere perimetro e processo
workflow ripetibile	skill o prompt	versionare istruzioni e criteri
integrazione remota	non implicita	scegliere adattatore e autorizzazioni
più worker	non impliciti	definire delega, isolamento e verifica
consenso prima di un’azione	non fornito come popup universale	applicarlo nel launcher o nella sandbox

Quattro modalità, quattro consumer

Pi documenta quattro modalità: interattiva, print/JSON, RPC e SDK. La distinzione conta perché cambia il consumer. Una persona può interpretare testo e correggere in corsa; un processo ha bisogno di eventi stabili, exit status, timeout e una regola per riconoscere il risultato finale.

interattivo → persona legge e interviene
print/JSON  → processo consuma testo finale oppure eventi JSONL
RPC         → client esterno governa il processo via protocollo
SDK         → applicazione Node governa direttamente la sessione

Passare dalla prima alla quarta riga non è un refactoring cosmetico. Richiede un contratto di integrazione: directory consentita, strumenti, formato dell’esito, limite temporale, gestione del silenzio e politica di retry. La pagina Canali di accesso ai modelli offre la scheda minima.

Un’assenza che sposta responsabilità

Pi non include una sandbox universale: secondo la guida di sicurezza, il processo opera con i permessi con cui è stato avviato. Un launcher che concede scrittura su un’intera macchina non diventa prudente perché l’harness è piccolo. La restrizione deve vivere nel sistema operativo, nel contenitore o nel perimetro del processo, ed essere verificata con un’azione innocua prima di affidare lavoro reale.

Lo stesso vale per le estensioni. Una componente TypeScript che legge dati o invoca un servizio amplia la superficie di fiducia. Prima di adottarla servono provenienza, manutenzione, strumenti esposti e comportamento di errore; «plugin installato» non equivale a «capacità approvata».

Quando conviene

Il modello è adatto quando si preferisce comporre poche capacità controllabili e accettare il costo di governarle. È meno adatto quando il progetto cerca un ambiente già completo, con consenso, orchestrazione e integrazioni uniformi. La scelta non è fra leggero e pesante in astratto: è fra responsabilità incorporate dal prodotto e responsabilità mantenute dall’adozione.

Limiti

Pi evolve: modalità, strumenti ed esclusioni vanno ricontrollati sulla revisione adottata. Le pagine latest e il branch principale sono fonti mobili; un’integrazione riproducibile deve registrare versione o commit e verificare le capacità del binario effettivamente eseguito.

Voci correlate

• Portabilità degli agenti
• Setup verificabile degli agenti
• Canali di accesso ai modelli

Fonti

• Pi documentation
• Pi repository, fonte primaria supplementare e mutevole.
• Pi coding-agent README, documento sul branch main; per decisioni stabili preferire una revisione fissata.