Identificare responsabilità, rischi, anti-modelli e esigenze di tracciabilità
Man mano che gli agenti diventano più capaci, potrebbe essere tentante immaginare gli spostamenti di responsabilità nel sistema. Non lo fa. I sistemi agenti possono eseguire il lavoro, ma gli esseri umani rimangono responsabili per i risultati e per i controlli che regolano l'esecuzione.
In questa unità, imparerai
Chi è responsabile delle azioni e dei risultati dell'agente
Quali rischi comuni e anti-pattern compaiono nei sistemi di agenti
In che modo i controlli GitHub attenuano questi rischi
Perché la tracciabilità e l'osservabilità sono necessarie per i sistemi affidabili
La responsabilità non si sposta con l'esecuzione
Quando un agente crea una richiesta pull, modifica il codice o risponde al feedback, partecipa al flusso di lavoro, ma non assume la proprietà dei risultati. Le parti responsabili sono ancora le persone e i team che:
Definizione dell'attività
Impostare le autorizzazioni
Scegliere e configurare i controlli
Approvazione della modifica risultante
Un modello di revisione delle richieste pull rende questo esplicito: il sistema può proporre, ma gli esseri umani decidono cosa viene accettato.
Rischi comuni e anti-modelli
I sistemi agenti nelle fasi iniziali in genere falliscono in modi prevedibili.
Esecuzione senza piani L'agente inizia a modificare il codice senza un approccio chiaro e ispezionabile.
Agenti con autorizzazioni eccessive L'agente (o il token di workflow o le credenziali dello strumento) ha un accesso più ampio del necessario.
Ragionamento nascosto Il flusso di lavoro espone solo gli output (il diff) senza artefatti intermedi (piano, presupposti, punti decisionali, contesto di esecuzione).
Fiducia cieca nell'automazione Superare i controlli CI è importante, ma verificano solo ciò che sono progettati per rilevare. Una build riuscita non significa automaticamente che la modifica sia completa, appropriata o che comporti pochi rischi.
Mappatura dell'implementazione: mitigazione del rischio tramite GitHub
| Rischio/anti-modello | come si presenta in GitHub | La mitigazione tramite i controlli di GitHub |
|---|---|---|
| Esecuzione senza piano | Pr ha un diff, ma nessun piano o razionale | Richiedere una sezione di pianificazione tramite il modello di pull request; richiedere la revisione prima della fusione |
| Agenti con autorizzazioni eccessive | I flussi di lavoro possono scrivere nel repository, accedere ai segreti su larga scala | GITHUB_TOKEN con privilegi minimi; ambienti con revisori necessari; limitare chi può attivare i flussi di lavoro |
| Ragionamento nascosto | Nessun presupposto/ambito/percorso decisionale | Richiedere il piano e collegare le esecuzioni del flusso di lavoro e registrare le decisioni nei commenti delle pull request |
| Fiducia cieca nell'automazione | "Superato il CI, mettilo in produzione" | Combinare controlli con CODEOWNERS, revisioni richieste e approvazioni basate sul rischio |
Tracciabilità e osservabilità
Per supervisionare bene un agente, è necessaria più di una differenza finale: è necessaria una traccia. In GitHub tale traccia può includere:
Pull request e cronologia commit
Esaminare commenti e approvazioni
Esecuzioni del flusso di lavoro e risultati caricati (report di test, log)
Scansione del codice: caricamenti e avvisi
Avvisi di analisi dei segreti ed eventi di protezione push
Gli eventi del log di verifica dell'organizzazione (la disponibilità e l'accesso dipendono dalla configurazione di organizzazione o impresa)
L'obiettivo non è solo la conformità. È una comprensione operativa: quando si verifica un errore, è necessario sapere cosa è cambiato, chi lo ha approvato, quali prove esistevano e cosa è successo dopo.
Tracciamento minimo degli interventi dell'agente
Obiettivo dichiarato (collegamento al problema o descrizione richiesta pull)
Un piano ispezionabile (sezione o file del Piano di Relazione Pubblica)
Set di modifiche limitato (branch e commit)
Evidenza automatizzata (esecuzione del flusso di lavoro e artefatti)
Giudizio umano (revisione e approvazione)
Risultato chiaro (fusione, ripristino o escalation)
Supponiamo che la correzione della vulnerabilità dell'agente software superi il CI (integrazione continua), ma successivamente causi una regressione. La domanda chiave non è solo se l'agente ha commesso un errore, è se il sistema ha commesso l'errore comprensibile ed evitabile:
C'era un piano visibile e una chiara portata?
Sono stati richiesti i revisori corretti (e sono stati approvati)?
I controlli corrispondono al rischio della modifica?
L'audit trail è sufficiente per ricostruire ciò che è successo?
I sistemi agentic cambiano chi esegue il lavoro, ma non chi possiede risultati. I team umani rimangono responsabili, motivo per cui devono progettare contro schemi anti-pattern comuni e richiedere una tracciabilità avanzata tramite artefatti e log nativi di GitHub.
Una volta compreso il funzionamento della responsabilità, il passaggio finale consiste nel decidere come deve essere valutato il lavoro dell'agente. Nell'unità successiva si applicherà il modello di collaboratore all'output generato dall'agente.