Everything is a File: Una Filosofia di Design da Unix agli AI Agent

Originale di Ethan 业成

Un'eco che attraversa mezzo secolo

Già nei primi anni '70 presso i Bell Labs, i padri di Unix, Ken Thompson e Dennis Ritchie, proposero per la prima volta un principio di progettazione audace al limite della paranoia: Everything is a file - Tutto è un file.

Oggi, più di cinquant'anni dopo, si assiste a un'esplosione di framework per AI Agent. Manus, Claude Code, OpenClaw... provengono da team diversi, stack tecnologici diversi, obiettivi commerciali diversi, ma hanno fatto tutti la stessa scelta: utilizzare il file system come scheletro cognitivo dell'Agent.

Manus fornisce all'Agent una macchina virtuale, e i risultati del task vengono salvati su disco come file. Claude Code legge e scrive direttamente sul file system locale dell'utente, utilizzando un file CLAUDE.md per contenere tutte le istruzioni e il contesto. Anche i framework open source come OpenClaw organizzano la scomposizione dei task e gli stati intermedi tramite una struttura di directory.

Quando ingegneri distanti mezzo secolo, di fronte a problemi tecnici completamente diversi, convergono indipendentemente sulla stessa soluzione, non si tratta di una coincidenza, ma di una risonanza della filosofia di progettazione.

La decisione di Unix

Per comprendere l'importanza di questo, dobbiamo prima capire cosa ha fatto Unix.

Il design del file system di Unix è riconosciuto come uno dei design più eleganti nella storia dell'informatica. Ha risolto un problema estremamente complesso: come gestire risorse hardware e risorse dati eterogenee con un'interfaccia uniforme e semplice.

Prima degli anni '70, i sistemi operativi funzionavano così: per leggere un disco, si chiamava l'interfaccia del disco; per leggere un nastro magnetico, si chiamava l'interfaccia del nastro magnetico; per accedere a un terminale, si chiamava l'interfaccia del terminale. Ogni dispositivo aveva la propria API, e ogni API aveva la propria semantica. Se si avevano N tipi di dispositivi e M tipi di operazioni, la complessità del sistema era N × M.

Thompson e Ritchie fecero una cosa apparentemente semplice fino alla stupidità:

Trasformare tutto in file. Utilizzare i quattro verbi open, read, write, close per operare su tutto.

Il suo significato fondamentale è: tutte le risorse nel sistema operativo - documenti, directory, dischi rigidi, modem, tastiere, stampanti, persino connessioni di rete e informazioni sui processi - possono essere astratte in un flusso di file (Stream of Bytes).

Ciò significa che è sufficiente imparare un set di API - open(), read(), write(), close() - per operare su tutte le risorse del computer.

D'ora in poi, la complessità è crollata da N × M a 4 × 1. Quattro verbi, un livello di astrazione.

Il genio di questa cosa non sta nel sostantivo "file", ma in una visione più profonda:

Non è necessario sapere cosa c'è dietro un file descriptor. L'interfaccia è un contratto.

Un fd (file descriptor) è un handle opaco. Si esegue read() su di esso e ne esce un flusso di byte. Per quanto riguarda il fatto che questi byte provengano da settori del disco rigido, buffer della scheda di rete o dall'output standard di un altro processo, non ti interessa e non dovrebbe interessarti.

Questa è la potenza di un'interfaccia uniforme: rende l'ignoranza un vantaggio.

L'Agent di fronte allo stesso problema

Ora torniamo alla situazione dell'AI Agent.

Un Agent deve completare task complessi e si trova di fronte a un dilemma sorprendentemente simile a quello del sistema operativo degli anni '70:

• Memoria persistente: la finestra di contesto degli LLM è volatile e la catena di pensiero svanisce con la sessione. Proprio come la memoria viene recuperata dopo che un processo termina, hai bisogno di un posto dove persistere lo stato intermedio, altrimenti ogni conversazione ricomincia da zero.
• Contesto incrementale: i compiti complessi non possono essere completati in un solo passaggio. L'agente deve accumulare gradualmente il contesto in più round di ragionamento, proprio come un processo Unix trasmette lo stato tra più esecuzioni leggendo e scrivendo file. Il file system fornisce naturalmente questa modalità di lavoro incrementale "scrivi un po', leggi un po', poi scrivi un altro po'".
• Pianificazione unificata di strumenti e competenze: l'agente deve richiamare strumenti eterogenei (Tools/Skills) come ricerca, esecuzione di codice, generazione di immagini, proprio come Unix deve gestire dispositivi eterogenei come dischi, reti, stampanti. Hai bisogno di un livello di astrazione unificato, altrimenti dovrai scrivere una nuova logica di integrazione per ogni nuovo strumento che aggiungi.
• Confini di autorizzazione per l'uso del computer: quando un agente ha la capacità di operare su un computer, "cosa può toccare e cosa non può toccare" diventa una questione di vita o di morte. Il sistema di permessi dei file di Unix (rwx) fornisce proprio un modello sandbox già pronto: la directory è il confine, il permesso è il contratto.

Quattro requisiti. Suona familiare?

Questo è esattamente il problema che i sistemi operativi hanno affrontato negli anni '70.

Memoria persistente: il file system lo risolve naturalmente, la scrittura è persistente. Contesto incrementale: la struttura delle directory è essa stessa costruita in modo incrementale, mkdir, touch, append, il contesto cresce con il file. Pianificazione unificata degli strumenti: l'essenza della pipeline Unix: lo stdout di un processo è lo stdin di un altro processo, il mezzo intermedio è il flusso di byte. Lo stesso vale per la catena di strumenti dell'agente: il file di output del passaggio precedente è l'input del passaggio successivo. Confini di autorizzazione: i permessi rwx del file system, la sandbox chroot, definiscono naturalmente la "cerchia di capacità" dell'agente.

Quindi, quando i progettisti del framework dell'agente si trovano di fronte alla domanda "dove mettere lo stato di lavoro dell'agente", la risposta è quasi predeterminata: nel file system. Perché non esiste una soluzione più semplice che possa soddisfare contemporaneamente questi quattro vincoli.

Quando il sistema ha bisogno di "gestire l'interazione di un gran numero di risorse eterogenee", hai due strade:

Percorso A: progettare un'interfaccia dedicata per ogni risorsa. N risorse × M operazioni = NM interfacce. Preciso ma esplosivo.

Percorso B: trovare un livello di astrazione sufficientemente sottile da far indossare a tutte le risorse lo stesso vestito. 4 operazioni × 1 livello di astrazione. Grezzo ma componibile.

Unix ha scelto B. Più di cinquant'anni dopo, il framework dell'agente ha scelto di nuovo B.

Uno strato più profondo: il file è l'esteriorizzazione del pensiero

Ma se ci fermiamo solo alla "convergenza delle soluzioni tecniche", ci perderemo qualcosa di più essenziale.

Ricorda come gli esseri umani gestiscono i compiti complessi.

Quando ricevi un grande progetto, la prima cosa che fai non è iniziare a lavorare, ma: creare cartelle. Directory radice del progetto, directory delle sotto-attività, directory dei materiali di riferimento, directory di output. Utilizzi la struttura delle directory per scomporre il compito caotico in unità gestibili. Utilizzi i nomi dei file per nominare ogni unità. Utilizzi il contenuto dei file per registrare il processo di pensiero e i prodotti intermedi.

Il file system non è solo una soluzione di archiviazione. È lo strumento originale per l'esteriorizzazione del pensiero umano.

Questa intuizione spiega perché il framework dell'agente converge verso il file system: il "pensiero" dell'LLM deve essere esteriorizzato: la sua finestra di contesto è limitata e il ragionamento a lungo termine deve fare affidamento sulla memoria esterna. E il file system è proprio il formato di "memoria esterna" più universale che l'umanità abbia mai inventato.

Da questo punto di vista, CLAUDE.md di Claude Code non è un file di configurazione. È un contratto cognitivo esteriorizzato: gli esseri umani scrivono l'intenzione in un file, l'agente legge il file come intenzione. Il file diventa il livello di interfaccia tra la mente umana e l'intelligenza artificiale.

Questo è sorprendentemente coerente con la filosofia della pipeline Unix:

Write programs to handle text streams, because that is a universal interface.Sostituire "programmi" con "agenti" e "flussi di testo" con "file", questa affermazione sarà ancora valida nel 2026.

Ritorno ai principi primi

Le grandi astrazioni non diventano mai obsolete, trovano solo nuove istanze in nuovi ambiti.

"Un'interfaccia unificata risolve la complessità" non è un'invenzione di Unix, è una legge eterna della progettazione di sistemi. Unix l'ha implementata per caso con il nome di "file". Gli AI Agent l'hanno implementata di nuovo per caso nella forma di "directory di lavoro".

Anche i sistemi di prossima generazione si troveranno di fronte alla stessa scelta: progettare interfacce dedicate per ogni cosa o trovare un'astrazione sottile, generica e componibile?

Se la storia ci insegna qualcosa, la risposta è già scritta accanto a /dev/null:

Keep it simple. Make it compose. Everything is a file. (Semplifica al massimo. Rendilo componibile. Ogni cosa è un file.)