Chi sta integrando agenti AI in pipeline CI/CD si scontra presto con un problema pratico: come si testano in modo affidabile le “skill” di un agente (le istruzioni locali che gli insegnano quando e come usare una capacità) senza colpire API reali, senza costi imprevedibili e senza risultati non deterministici? La risposta che sta emergendo nella comunità DevOps combina due strumenti complementari: Dev Proxy di Microsoft per simulare le API a livello di rete, e Promptfoo per valutare in modo strutturato se una skill funziona meglio di un’altra.

Vale la pena approfondire entrambi gli approcci, perché il problema che risolvono — testare comportamento non deterministico in modo ripetibile — è ormai centrale per chiunque gestisca agenti AI in produzione, non solo per chi scrive skill per Claude o Codex.

Perché i mock server tradizionali falliscono con gli agenti AI

L’approccio classico al test di un’integrazione API è il mock server: si sostituisce l’endpoint reale con uno fittizio, spesso puntando l’applicazione a localhost. Con gli agenti AI questo approccio introduce un problema sottile ma serio: cambiare l’URL di una skill per puntare a un server di test altera il contesto di token visto dal modello. Il modello che si sta testando non è più identico, a livello di token, a quello che verrà effettivamente distribuito in produzione. Questa discrepanza introduce una variabile nascosta che può invalidare i risultati della valutazione e produrre comportamenti inattesi una volta in produzione, quando la skill torna a puntare agli URL reali.

Un approccio più efficace consiste nell’usare un proxy leggero che intercetta il traffico HTTP e restituisce dati predefiniti letti da file JSON locali, senza mai modificare gli URL che l’agente chiama. È esattamente il compito per cui è nato Dev Proxy: l’agente continua a chiamare gli URL di produzione, ma riceve risposte deterministiche senza che avvenga alcuna chiamata di rete reale né alcuna gestione di server. I dati si azzerano a ogni esecuzione, il contesto di token resta identico a quello di produzione, e diventa possibile eseguire test di regressione rigorosi all’interno di pipeline CI/CD.

Dev Proxy: simulare le API senza toccare il codice

Dev Proxy è uno strumento a riga di comando, open source e gratuito, che funziona su qualsiasi piattaforma e con qualsiasi stack tecnologico, perché intercetta le richieste di rete invece di agganciarsi al codice dell’applicazione. Le funzionalità principali coprono scenari che vanno ben oltre il semplice mocking:

• Simulare errori delle API senza modificare una riga di codice, per verificare che l’app non perda dati dei clienti quando una dipendenza esterna fallisce
• Simulare rate limiting per verificare che l’applicazione gestisca correttamente il throttling
• Simulare latenza e risposte lente per validare le protezioni lato UX
• Generare rapidamente mock API CRUD senza scrivere codice destinato a non essere mai distribuito
• Fornire guida contestuale su permessi e best practice, in particolare per chi integra Microsoft Graph

Per il caso specifico degli agenti AI, Dev Proxy include funzionalità dedicate ai language model che permettono di simulare scenari realistici e tracciare l’uso delle risorse, oltre a un tool integrato nel proprio server MCP che fornisce agli agenti di coding raccomandazioni su come costruire le configurazioni. In pratica, un team che sviluppa una skill che chiama un’API esterna può configurare Dev Proxy per intercettare quelle chiamate specifiche e restituire fixture JSON versionate insieme al codice, garantendo che ogni esecuzione della pipeline CI/CD parta da uno stato pulito e riproducibile.

Promptfoo: valutare quale versione di una skill funziona meglio

Simulare le API risolve solo metà del problema. L’altra metà è capire, in modo misurabile, se una skill fa il proprio lavoro correttamente e se una nuova versione è effettivamente migliore della precedente. È qui che entra in gioco Promptfoo, un framework di valutazione che permette di confrontare due versioni della stessa skill eseguendo gli stessi task fianco a fianco.

Il pattern di base è semplice: si mantengono identici il modello, i file di task e i permessi, cambiando solo il file SKILL.md tra una versione e l’altra. Una struttura tipica per confrontare due versioni di una skill review-standards è organizzata così:

skill-eval/
├── promptfooconfig.yaml
└── fixtures/
    ├── v1/
    │   ├── .claude/skills/review-standards/SKILL.md
    │   └── src/auth.ts
    └── v2/
        ├── .claude/skills/review-standards/SKILL.md
        └── src/auth.ts

Nel file di configurazione si definiscono due provider basati sul Claude Agent SDK, identici tranne che per la working_dir, che punta alla fixture v1 o v2:

providers:
  - id: anthropic:claude-agent-sdk
    label: review-standards-v1
    config:
      model: claude-sonnet-4-6
      working_dir: ./fixtures/v1
      setting_sources: ['project']
      skills: ['review-standards']
      append_allowed_tools: ['Read', 'Grep', 'Glob']
  - id: anthropic:claude-agent-sdk
    label: review-standards-v2
    config:
      model: claude-sonnet-4-6
      working_dir: ./fixtures/v2
      setting_sources: ['project']
      skills: ['review-standards']
      append_allowed_tools: ['Read', 'Grep', 'Glob']

Il parametro setting_sources: ['project'] fa scoprire a Promptfoo i file SKILL.md sotto .claude/skills/, mentre il filtro skills: restringe la sessione a una singola skill e ne abilita automaticamente il tool associato. Per Codex o OpenCode la struttura equivalente usa .agents/skills/ al posto di .claude/skills/, ma la logica di confronto resta identica.

Tre livelli di asserzioni per un confronto solido

Una valutazione utile si costruisce a strati. Il primo verifica semplicemente che la skill sia stata invocata:

defaultTest:
  assert:
    - type: skill-used
      value: review-standards

Claude espone le chiamate al tool Skill direttamente, e Promptfoo le normalizza nell’asserzione skill-used: questo distingue una risposta corretta ottenuta senza passare dalla skill da una prodotta effettivamente attraverso il workflow che si vuole testare, una distinzione che spesso sfugge a chi valuta solo la qualità della risposta finale.

Il secondo livello valuta la qualità del lavoro svolto, per esempio calcolando quanti problemi attesi sono stati effettivamente individuati in una revisione di codice, con una soglia di recall minima. Il terzo livello aggiunge segnali secondari come costo e latenza, utili quando due versioni sono entrambe corrette ma una è molto più lenta o costosa dell’altra:

defaultTest:
  assert:
    - type: cost
      threshold: 0.50
    - type: latency
      threshold: 120000

Per chi gestisce bundle di skill correlate, un errore comune è testare solo il percorso “felice” di ciascuna skill. Vale la pena aggiungere anche prompt limite che dovrebbero instradare verso una skill vicina, asserendo sia la skill desiderata sia quella che non deve attivarsi, con il costrutto not-skill-used. Questo cattura i casi in cui una skill risolve correttamente il task ma si attiva anche quando non dovrebbe, un problema di “routing” difficile da individuare guardando solo l’output finale.

Mettere insieme i due strumenti in CI/CD

La combinazione pratica è: Dev Proxy intercetta le chiamate API reali fatte durante l’esecuzione della skill e restituisce fixture deterministiche, mentre Promptfoo esegue lo stesso set di task contro versioni diverse della skill e assegna un punteggio ai risultati. L’eval si lancia con un semplice comando:

npx promptfoo@latest eval -c promptfooconfig.yaml

Aggiungendo --repeat 3 si ottiene un campione più robusto del comportamento non deterministico dell’agente, mentre --no-cache è utile durante l’iterazione sul testo della skill per garantire risultati sempre freschi. Il comando npx promptfoo@latest view apre una vista web che affianca i risultati delle due versioni, rendendo immediato individuare dove una skill supera l’altra.

Conclusione

Il punto centrale di entrambi gli strumenti è lo stesso: eliminare le variabili nascoste che rendono inaffidabile il test di un comportamento non deterministico. Dev Proxy garantisce che il contesto visto dal modello in test sia identico a quello di produzione, eliminando la variabile del cambio di URL. Promptfoo garantisce che il confronto tra due versioni di una skill sia equo, isolando l’unica variabile che conta — il testo della skill stessa — e fornendo asserzioni misurabili su invocazione, qualità, costo e latenza.

Per un team che già gestisce pipeline CI/CD tradizionali, l’investimento per aggiungere questo livello di test alle proprie skill AI è relativamente contenuto: entrambi gli strumenti sono open source, si integrano con gli SDK di Claude, Codex e OpenCode, e restituiscono risultati confrontabili senza richiedere infrastruttura dedicata oltre a quella già in uso per il testing tradizionale.

Fonti: 4sysops.com, Microsoft Learn – Dev Proxy, Promptfoo – Test Agent Skills