Microsoft APM: il gestore di pacchetti per gli agenti AI

Se lavori con più assistenti di programmazione, sai già qual è il problema: ogni strumento vuole le sue istruzioni, le sue skill, i suoi server MCP, e ogni sviluppatore del team finisce con una configurazione leggermente diversa. Microsoft prova a mettere ordine con APM, Agent Package Manager, un gestore di dipendenze open source per la configurazione degli agenti AI.

L’idea è semplice da spiegare: quello che package.json fa per le librerie JavaScript, APM lo fa per il contesto che dai ai tuoi agenti. Il progetto, pubblicato con licenza MIT nel repository microsoft/apm, è stato segnalato nei riepiloghi di novembre come uno dei rilasci open source più interessanti per chi sviluppa con gli agenti.

Che cos’è APM e quale problema risolve

APM è uno strumento da riga di comando. Dichiari in un unico file, chiamato apm.yml, tutto ciò che serve ai tuoi agenti per lavorare bene: istruzioni, skill, prompt, agenti, hook, plugin e server MCP. Poi lanci apm install e lo strumento ricostruisce la stessa configurazione su qualsiasi macchina.

Il vantaggio è la riproducibilità. Oggi capita spesso che la cartella delle istruzioni di un repository sia stata copiata a mano, che una skill sia stata aggiornata solo da una persona e che un server MCP sia presente sul portatile di un collega ma non sul tuo. Con un manifesto condiviso e versionato, il contesto dell’agente diventa codice da rivedere, non un’abitudine personale.

Non è un tema nuovo per chi segue il settore. Ne abbiamo parlato quando è nato lo standard aperto per le estensioni, raccontato nell’articolo su Agent Plugins e la portabilità delle estensioni degli agenti AI. APM si colloca un livello sopra: non definisce il formato di un singolo plugin, ma si occupa di installarlo, fissarne la versione e distribuirlo in modo coerente.

Come funziona il manifesto apm.yml

Secondo la documentazione ufficiale, il file richiede due campi obbligatori, il nome e la versione. Tutto il resto è facoltativo: descrizione, autore, licenza, i target di destinazione, le dipendenze e anche gli script che puoi lanciare con un comando dedicato.

Le dipendenze si dividono in due famiglie: quelle APM, cioè pacchetti di contesto presi da un repository git, e quelle MCP, cioè i server da collegare agli agenti. Puoi fissare un riferimento preciso, per esempio un tag di versione, e prevedere anche dipendenze di sviluppo che non finiscono nei pacchetti distribuiti.

Quando esegui l’installazione, APM risolve l’albero delle dipendenze, applica i controlli di sicurezza e di policy, scrive un file di blocco e compila le primitive nelle cartelle che ciascun ambiente si aspetta. In pratica il tuo apm.yml diventa la fonte unica da cui nascono i file nativi di ogni strumento.

Gli ambienti supportati

Qui APM mostra il suo lato più pratico. La documentazione elenca come destinazioni GitHub Copilot, Claude Code, Cursor, Codex, Gemini, OpenCode, Windsurf, Kiro e Grok Build, con altri target che si possono attivare in modo esplicito. Non devi più mantenere a mano un file diverso per ogni assistente.

Un caso concreto: se il tuo team usa Claude Code per alcuni compiti e Cursor per altri, puoi dichiarare le stesse istruzioni una volta sola. Lo strumento genera i file attesi da ciascun ambiente, compresi quelli di tipo AGENTS.md. Sul rischio che proprio quei file diventino un vettore di attacco puoi leggere il nostro approfondimento su AGENTS.md e l’attacco tramite la cartella di download.

Il confronto con il mondo dei pacchetti tradizionali regge fino a un certo punto, ma aiuta a capire la direzione. Prima arrivano i singoli file sparsi, poi un formato comune, infine un gestore che si occupa di versioni, cache e dipendenze. APM prova a occupare quest’ultimo gradino per il mondo degli agenti.

Sicurezza: il vero motivo per cui conta

Installare istruzioni e skill scritte da altri significa dare testo a un agente che poi lo esegue. È una superficie di attacco concreta, e APM la tratta come tale. Ogni installazione analizza le primitive alla ricerca di caratteri Unicode nascosti, per esempio caratteri a larghezza zero o di controllo della direzione del testo, che possono alterare il comportamento di un agente senza che un revisore umano se ne accorga.

I risultati critici bloccano l’installazione, a meno che tu non forzi esplicitamente l’operazione. Un comando di verifica dedicato, apm audit, permette di ripetere gli stessi controlli quando vuoi e, in modalità per l’integrazione continua, di far fallire la pipeline se qualcosa non torna.

C’è poi il file di blocco, che registra le versioni risolte e gli hash dei contenuti file per file. Se qualcosa cambia a tua insaputa, lo scopri. Anche i server MCP trasversali, quelli introdotti da una dipendenza di una dipendenza, devono essere dichiarati o dichiarati affidabili: niente collegamenti silenziosi.

Policy aziendali

Per le organizzazioni c’è un file di policy, apm-policy.yml, che stabilisce quali sorgenti, ambiti e tipi di primitive sono ammessi. La regola viene applicata prima di scrivere i file e vale anche per i server MCP transitivi. I livelli aziendale, di organizzazione e di repository possono solo restringere le regole, mai allargarle.

Dopo gli episodi degli ultimi mesi, è un argomento che non possiamo ignorare. Pensa a quanto è successo con l’estensione di Claude Code compromessa: la catena di fornitura del software per agenti è diventata un bersaglio, e un gestore con scansione e blocco delle versioni è un tassello sensato.

Cosa cambia per chi sviluppa e per chi fa consulenza

Per un team piccolo, il beneficio immediato è l’onboarding. Un nuovo collaboratore clona il repository, lancia l’installazione e ottiene lo stesso set di skill, istruzioni e connessioni di tutti gli altri. Per un libero professionista che segue più clienti, vuol dire poter tenere una configurazione separata per ciascun progetto senza ricordarsi cosa è installato dove.

Per chi lavora in azienda, la parte interessante è la governance. Un responsabile può decidere quali pacchetti di contesto sono consentiti, controllare che nessuno sia stato alterato e generare un inventario dei componenti. La documentazione parla di esportazione del lockfile in formati standard per l’inventario del software, un dettaglio che interessa chi deve rispondere a un audit.

Va detto con chiarezza che si tratta di uno strumento giovane e che molti numeri sulle prestazioni o sull’adozione vanno presi con cautela. Il repository conta migliaia di stelle, ma le stelle non sono una prova di maturità, e conviene provarlo su un progetto di test prima di portarlo in produzione.

Vale anche la pena osservare il contesto più ampio. Microsoft sta spingendo da tempo l’integrazione tra i suoi strumenti di sviluppo e gli agenti, come si vede nel nostro articolo su GitHub Copilot Fusion e i dati di Octoverse 2026. APM va nella stessa direzione, ma con una scelta controcorrente: supporta anche i prodotti dei concorrenti.

Come provarlo senza rischi

Per cominciare, scegli un repository non critico e crea il manifesto con il comando di inizializzazione. Dichiara due o tre elementi che già usi, per esempio un file di istruzioni e un server MCP, e lancia l’installazione in modalità di prova per vedere cosa verrebbe scritto prima di toccare i file.

Poi passa alla verifica con il comando di audit e controlla che il file di blocco entri nel controllo di versione. Solo a quel punto ha senso estendere l’uso al resto del team e introdurre una policy.

Conclusioni

APM non è una novità spettacolare, ed è proprio questo il suo pregio: affronta un problema noioso ma reale, quello di tenere sotto controllo ciò che gli agenti leggono ed eseguono. Se gestisci più assistenti nello stesso progetto, vale la pena dedicargli un pomeriggio di prova.

Dai un’occhiata alla documentazione ufficiale, prova il manifesto su un progetto di test e poi dimmi com’è andata: la gestione del contesto degli agenti sarà uno dei temi più caldi dei prossimi mesi, e seguiremo l’evoluzione qui su Intelligenza Artificiale.