Valutare e approvare l’agente di modernizzazione dell’esperienza evaluate
Questa pagina è destinata alla persona che approva l’agente di modernizzazione esperienza per un team che crea o migra siti Adobe Experience Manager su Edge Delivery Services: un architetto, un lead tecnico o un proprietario di piattaforma che non potrà mai utilizzare l’agente personalmente. Spiega le modifiche per il team, i tre modi in cui eseguire una migrazione, il modo in cui il team di Adobe lavora con il tuo, i sistemi e i dati che l’agente tocca, come le modifiche vengono controllate e tracciate e cosa rimane del lavoro del progetto.
Per sapere che cos’è Edge Delivery Services e come si inserisce un progetto, consulta Com’è costruito e aggiornato il tuo sito. Un risultato nelle tue pagine ti dice più di qualsiasi descrizione, quindi chiedi a un membro del team di iniziare con la modalità automatica o di importare una pagina passo dopo passo durante la lettura.
Modifiche per il team team-impact
Senza l’agente, la migrazione a Edge Delivery Services inizia con settimane di lavoro per sviluppatori prima che chiunque possa giudicarne il risultato: elencare le pagine sorgente, raggrupparle per layout, mappare il loro contenuto in blocchi, scrivere codice e stili di blocco e scrivere script di importazione. L’agente esegue questo lavoro ripetitivo con il team, in un ambiente in hosting senza elementi da installare.
- Il tuo team decide e rivede; l’agente produce. Le persone impostano l’ambito, il modello di contenuto, la progettazione del target e le integrazioni e accettano il risultato. L’agente scrive il codice, importa il contenuto e confronta il risultato con l’origine.
- Altre persone contribuiscono direttamente. Designer, specialisti di contenuti e professionisti del marketing che conoscono HTML e le nozioni di base di Git apportano modifiche descrivendole in un linguaggio semplice. Gli sviluppatori controllano ciò che raggiunge la produzione esaminando tali modifiche come richieste pull. Vedi Contributo Più Ampio, Stesso Controllo Di Produzione.
- L’impegno aumenta con i layout, non con le pagine. Una correzione consente di modificare un blocco riutilizzabile o uno script di importazione anziché una pagina, in modo da applicarlo a ogni pagina dello stesso layout. Un sito di 5.000 pagine che condividono 12 layout è principalmente il lavoro di 12 modelli. Vedi Migrazione dell’agente su scala e per ridimensionare il lavoro dei primi modelli, Stima prima del commit.
- Il risultato è un progetto standard. Il codice è normale HTML, CSS e JavaScript nell’archivio Git, seguendo le convenzioni della piattaforma standard di AEM. Il sito non dipende dall’agente in fase di esecuzione e gli sviluppatori possono continuare nel proprio editor o con altri strumenti di intelligenza artificiale.
- La conoscenza del progetto rimane nell’archivio. Le convenzioni che il tuo team accetta di utilizzare in
AGENTS.mde i file correlati, che l’agente e i nuovi membri del team seguono entrambi. Consulta Istruzioni progetto e memoria.
Funzionamento dell’agente e del team responsibilities
Per informazioni sul modo in cui il lead di migrazione coordina i collaboratori, vedere Guida della migrazione. Diverse persone possono lavorare a un progetto, ognuna nella propria area di lavoro della console; vedi Lavoro come team.
Che cosa rimane del lavoro del progetto project-work
L’agente è un agente di sviluppo: con esso è possibile costruire ciò che può essere costruito su Edge Delivery Services. Una migrazione copia ciò che viene mostrato dalle pagine sorgente, tuttavia, non dai sistemi dietro di esse. L’agente ricostruisce il sito: le pagine, i blocchi, gli stili e il codice che chiama i servizi. I flussi di lavoro di approvazione e pubblicazione, i sistemi di back-end alla base delle integrazioni e il modo in cui i team lavorano sul nuovo sito rimangono il lavoro dell’organizzazione. Queste esigenze richiedono una decisione da parte del team prima che l’agente possa generarle:
Per l’accesso all’origine, il contenuto interattivo e altri limiti dell’importazione, vedere Limitazioni.
Figma e sistemi di progettazione figma
Figma può essere la fonte di un nuovo design. Con il componente aggiuntivo di importazione Figma, l’agente legge il componente o il frame selezionato tramite l’API di Figma, utilizzando un server MCP (Model Context Protocol), nel modo in cui uno sviluppatore legge un handoff di progettazione. Scrive le variabili e gli stili del design, come i colori, la tipografia e la spaziatura, come proprietà personalizzate CSS negli stili globali del progetto. Queste proprietà sono i token di progettazione del sito. Vivono nel codice, non in un’esportazione di token separata, quindi i designer e gli sviluppatori li esaminano come qualsiasi altra modifica. Per informazioni sul modo in cui i designer utilizzano Figma con l’agente, vedere Lavoro da un design Figma.
Cosa approvare:
- Accesso: Ogni persona che utilizza Figma con l’agente crea un token di accesso personale Figma con ambiti di sola lettura e lo memorizza nelle impostazioni della console. Figma emana e gestisce questo token di accesso, che non ha nulla a che fare con i token di progettazione. Non esiste una connessione Figma a livello di organizzazione e un token di accesso personale non può essere limitato a file specifici: legge ogni file che il proprietario può aprire.
- Posti e limiti di velocità: Figma limita la frequenza con cui un token può leggere i file, in base alla postazione del proprietario del token e al piano a cui appartiene il file. Con una postazione View o Collab, un token può leggere i file tramite l’API di Figma solo poche volte al mese, quindi le persone che utilizzano Figma con l’agente hanno bisogno di un posto Dev o Full. Vedi i limiti di tariffa di Figma.
- Dati: Per la cornice o il componente selezionato, l’agente invia la struttura, uno screenshot, le variabili e il testo al modello di IA. Vedi Elementi elaborati dal modello di IA.
Scegli come viene eseguita la migrazione approaches
Lo stesso agente può eseguire una migrazione in tre modi. Si differenziano per chi guida l’agente e chi risponde per il risultato. Tutti e tre producono un progetto Edge Delivery Services standard, con codice in un archivio Git e contenuto modificato dagli autori, che ti consente di passare da uno all’altro: trasferire un risultato in modalità automatica al tuo sito e continuare nella console, oppure continuare con l’agente autonomamente dopo un impegno con Agentic Outcome Engineers.
Team dietro l’agente adobe-team
Quando scegli l’agente, scegli anche il team che lo crea e la direzione che prende. Il modo in cui le persone trovano le informazioni sul web sta cambiando: più di loro chiedono a un assistente di intelligenza artificiale, che risponde da ciò che legge sul sito del brand. E un agente può modificare il contenuto, la progettazione e il codice di un sito insieme, in modo che una volta necessario un progetto possa richiedere ore. La missione del team è quella di aiutarti a passare a Edge Delivery Services, ottenere il massimo da Experience Manager e utilizzare strumenti di sviluppo per creare siti che rimangano rilevanti man mano che questi cambiamenti continuano. Il suo lavoro con te non termina al momento della migrazione e l’agente continua a cambiare; le note sulla versione elencano ogni modifica.
Quando i cambiamenti sono economici, la parte difficile è decidere cosa cambiare, mantenerlo governato e dare all’agente il marchio, il design e il contesto di business giusti. Questa conoscenza è condivisa dai tuoi team e sistemi. Il team di Adobe ti consente di collegarlo alla piattaforma:
- Tecnici in grado di eseguire la migrazione con te. Per una migrazione complessa, gli ingegneri del risultato agenti di Adobe possono gestire l’agente con il tuo team e passare il sito a esso. Vedere Scegliere la modalità di esecuzione della migrazione.
- Corrente man mano che il prodotto cambia. L’avviso Novità della console elenca gli elementi di rilievo di ogni versione. Per applicare una modifica al tuo sito, rivedere l’architettura o discutere di un’esigenza che l’agente non soddisfi ancora, chiedi al tuo Customer Success Manager o account team di Adobe di organizzare un incontro con esperti in materia e con il team di prodotto.
- L’esperienza determina la forma del prodotto. Il team di prodotto scambia esperienze con clienti e partner e collabora con alcuni di loro su nuove funzionalità. Il rapporto contiene informazioni sulle correzioni e le generazioni successive del team.
Per raggiungere il team dalla console, utilizzare Richiedi supporto o Ottieni assistenza nelle pagine in modalità automatica. Il messaggio viene inviato direttamente al team che crea l’agente, che lo esamina e lo controlla tramite e-mail. Consulta Richiedi supporto e, per ciò che una richiesta condivide, Richieste di supporto.
Il team di Adobe lavora allo stesso modo con i partner di implementazione, in modo che con il tuo partner il sito continui a migliorare dopo la migrazione.
Sistemi e flusso di dati systems
L’agente funziona in un ambiente in hosting e raggiunge i sistemi solo tramite connessioni configurate dalle persone e autorizzazioni concesse.
aemcoder.adobe.io in cui le persone lavorano con l’agente.aem.page e il sito live su aem.live.Sicurezza e gestione dei dati security
La console consente all’agente di lavorare sul sito senza fornirgli le credenziali configurate e di decidere quando le modifiche raggiungono l’archivio Git e la destinazione del contenuto.
Accesso e isolamento security-access
- Accedi alla console con il tuo Adobe ID. Ogni richiesta è autenticata con Adobe Identity Management Services (IMS).
- Ogni utente lavora in un ambiente back-end separato con il proprio spazio di archiviazione, uno in ogni organizzazione Adobe con cui accede. La console crea l’ambiente quando l’utente accede per la prima volta e lo mette in pausa quando è inattivo.
- La console non ha alcun ruolo di progetto. Chiunque abbia accesso può chiedere all’agente qualsiasi modifica nel proprio workspace. Experience Manager e il provider Git continuano a imporre le proprie autorizzazioni per qualsiasi codice o contenuto che esce dall’area di lavoro.
Credenziali security-credentials
- L’agente di IA non riceve le credenziali configurate nella console. I token per GitHub, gli archivi Git di Cloud Manager, Experience Workspace, Figma e i siti di origine protetti sono conservati al di fuori dell’ambiente dell’agente. Un componente separato aggiunge ogni credenziale solo alle richieste del servizio a cui appartiene. Lo stesso vale per le credenziali utilizzate per chiamare il modello di IA.
- Le credenziali appartengono all’utente che le configura, non al progetto. Ogni membro del team collega il proprio account Git e memorizza il proprio token Figma.
- Le autorizzazioni dell’agente sono disattivate finché non vengono attivate. Attivandone una, l’agente può agire in base a tale accesso, ad esempio per inviare messaggi push all’archivio, senza visualizzare le credenziali. Per impostazione predefinita, un’autorizzazione utilizza l’accesso dell’utente. Per limitare ciò che l’agente può raggiungere, immetti un token per esso: un token di accesso personale dettagliato con ambito negli archivi di cui ha bisogno o il token di un account del servizio Adobe.
- Altri servizi chiamati dall’agente mentre funziona, ad esempio un’API di test, ottengono le credenziali allo stesso modo da una voce in Autenticazione sito protetto per il nome host del servizio. Vedi Credenziali per altri servizi.
- Memorizza le credenziali solo nelle impostazioni della console, mai nei prompt, nella chat, nel contenuto sorgente o nei file di progetto: l’agente legge questi elementi e può inviarli al modello di intelligenza artificiale. Rendi questa parte dell’onboarding: gli utenti non esperti di agenti di codifica possono incollare nella chat una password o una chiave per completare un’attività. Chiedi a tutti coloro che utilizzano la console di leggere prima i segreti fuori dalla chat e di comunicare quali sono i criteri della tua organizzazione che consentono loro di condividere con gli strumenti di intelligenza artificiale.
Elaborazione del modello di intelligenza artificiale security-model-data
Per eseguire la richiesta, l’agente può inviare quanto segue al modello in lingua grande (LLM) utilizzato, attualmente un modello Claude:
- Le tue richieste e istruzioni.
- URL di pagine Source, markup e contenuto, oppure contenuto CMS esportato.
- Codice e configurazione dell’archivio, ad esempio blocchi, stili e configurazione del sito.
- Design e riferimenti del marchio, come i design e le schermate di Figma.
- Contenuto generato e codice in revisione.
Adobe non utilizza le tue conversazioni o altri dati dei clienti per addestrare o perfezionare i modelli di intelligenza artificiale.
Controllo sulle modifiche security-control
L’agente funziona nell’area di lavoro della console, dove puoi esaminare le modifiche e l’anteprima. Il lavoro raggiunge il tuo sito in passaggi separati e ogni passaggio ha il proprio controllo:
- I controlli della console sono salvaguardie, non gate di approvazione. La modalità piano opzionale consente di approvare un piano prima dell’avvio dell’agente. La console inoltre impedisce all’agente di caricare, visualizzare in anteprima o pubblicare, a meno che il messaggio corrente non lo richieda o tu non accetti quando l’agente lo richiede, ma non può rilevare tutti i modi di effettuare una tale richiesta. Nessuno dei due controlli impedisce a un utente con accesso di eseguire il push o la pubblicazione.
- Con un’autorizzazione Git, l’agente può inviare messaggi push a qualsiasi ramo in cui le credenziali possano scrivere, incluso
main. Un push amainmodifica il codice del sito live. - Per richiedere la revisione, applicala dove arriva la modifica. Proteggi
maincon protezione ramo che richiede una richiesta pull rivista, invia Crea nuova PR e limita gli utenti che possono pubblicare con il ruolo pubblicazione del sito. La richiesta di pull elenca i file modificati e gli URL di anteprima delle pagine interessate, in modo che uno sviluppatore verifichi il risultato prima di unire. Impostare questi controlli prima che più persone contribuiscano e attivare le autorizzazioni dell’agente solo quando un’attività ne ha bisogno. Vedi Contributo Più Ampio, Stesso Controllo Di Produzione. - Considera le pagine sorgente e i file di progettazione come input non attendibile. Possono contenere testo che tenta di dirigere l’agente. Rivedi le modifiche prima di inviarle, visualizzarle in anteprima o pubblicarle.
Autorizzazioni push per contenuti content-push-permissions
Quando carichi contenuti utilizzando l’accesso Adobe, la destinazione applica le autorizzazioni del tuo account. Per i contenuti basati su documenti modificati in Experience Workspace, è necessario accedere in scrittura al contenuto di destinazione. Per l’authoring in Experience Manager, è necessaria l’autorizzazione per scrivere pagine e risorse nei percorsi selezionati nell’istanza di authoring. L’accesso alla console non concede tali diritti.
Quando si attiva l’autorizzazione delle credenziali Adobe dell’agente, il contenuto inviato all’archivio dei contenuti basati su documenti utilizza l’accesso dell’account. Chiedere all’agente di caricare non ignora le autorizzazioni della destinazione. Per l’authoring Experience Manager, carica i contenuti autonomamente tramite la console; i caricamenti diretti degli agenti non sono supportati.
Se un caricamento basato su documento utilizza un account di fallback configurato perché l’accesso non è disponibile o l’autenticazione non riesce, la destinazione applica invece le autorizzazioni dell’account. Lo stesso vale quando si configura esplicitamente un account di servizio per l’agente. Conferma quale account viene utilizzato prima di affidarti alle tue autorizzazioni personali per limitare le modifiche.
Tracciare le operazioni eseguite dall’agente audit-trail
La console non mantiene alcun registro di controllo separato, ma il lavoro dell’agente non viene annullato. Ciò che l’agente produce raggiunge il tuo sito solo tramite l’archivio Git o tramite Experience Manager ed entrambi conservano una cronologia:
- Il codice è il record primario. La cronologia Git registra ogni modifica apportata a blocchi, stili e script di importazione e gli script di importazione definiscono la struttura di ogni pagina importata.
- Le modifiche al contenuto sono registrate con il contenuto. Experience Workspace conserva una cronologia delle versioni di ciascun documento e l’istanza dell’autore mantiene le proprie versioni di pagina.
- La conversazione mostra ciò che è stato chiesto. Scarica chat salva la conversazione come file Markdown. Scaricala prima di selezionare Cancella chat. I messaggi verranno rimossi e non sarà possibile annullarli. Vedi Pannello chat.
Il record è più semplice da seguire quando ogni richiesta all’agente termina con il proprio commit, inviato a un ramo di lavoro anziché a main e, se le pagine vengono modificate, con il caricamento del proprio contenuto, che l’agente offre e che una persona approva. Chiedi questo elemento in AGENTS.md del progetto; vedi Lascia un record di ogni richiesta. I revisori leggono quindi cosa è cambiato l’agente, richiesta per richiesta, negli strumenti già in uso.
Dove è memorizzato il lavoro security-storage
- Il codice inviato viene memorizzato nell’archivio Git e il contenuto caricato in Experience Workspace o nell’istanza Autore. Vengono applicate le regole di conservazione e di cronologia delle versioni.
- Il lavoro che non hai inviato o caricato esiste solo nella tua area di lavoro della console, insieme alla cronologia delle chat e alle trascrizioni delle sessioni dell’agente. Cancella chat rimuove i messaggi dal pannello chat ma mantiene le trascrizioni. Per eliminare il lavoro del progetto aperto nell’area di lavoro della console, incluse le trascrizioni, utilizzare Reimposta area di lavoro.
Per informazioni su percorsi di elaborazione, conservazione dei dati e conformità, contatta il team del tuo account Adobe o visita il Centro protezione Adobe.
Dati sanitari e HIPAA security-hipaa
L’agente di modernizzazione dell’esperienza è uno strumento per sviluppatori per la migrazione e la creazione di siti. I visitatori del sito non lo raggiungono mai: Edge Delivery Services fornisce il sito pubblicato e le richieste dei visitatori non passano attraverso la console o l’agente. È possibile eseguire la migrazione delle pagine, delle progettazioni e delle risorse di un sito sanitario senza i dati dei pazienti. Non fornire mai all’agente dati reali sull’utente finale, come le cartelle dei pazienti o le credenziali degli utenti, e non eseguire la migrazione di pagine o risorse che li contengono. Utilizza dati fittizi per sviluppare e testare layout specifici per il paziente. Qualsiasi valore assegnato all’agente può raggiungere il modello di IA. Vedere Elementi elaborati dal modello di IA.
Questa restrizione non viene modificata da un sito di gestione temporanea, da un inserisco nell’elenco Consentiti di accesso di origine o da un sito di accesso di origine. Prima di importare un’origine protetta, controlla le pagine e le risorse nell’ambito e limita l’account di origine al contenuto senza informazioni sanitarie protette (PHI). Configura l’account tramite autenticazione di origine, non in chat.
Per un sito che elaborerà PHI in base all’Health Insurance Portability and Accountability Act (HIPAA), conferma la configurazione dell’authoring e della consegna con il team del tuo account Adobe, incluse la licenza richiesta, l’accordo per i collaboratori aziendali (Business Associate Agreement, BAA) e la configurazione. In conformità HIPAA per Adobe Experience Manager as a Cloud Service Edge Delivery Services è elencato come compatibile con HIPAA, ma l’editor universale non è compatibile con HIPAA. Può essere aggiunto a un programma di sicurezza esteso solo quando non viene introdotto alcun PHI. Un servizio di consegna compatibile con HIPAA non estende la copertura PHI all’agente o a un editor non compatibile con HIPAA.
Richieste di assistenza security-support
Una richiesta di supporto viene inviata al team di Adobe che crea l’agente. Con l’argomento e la descrizione che il mittente scrive, condivide:
- Il nome del mittente, l’indirizzo e-mail e gli ID utente e organizzazione di Adobe.
- L’ID sessione, il nome del progetto e l’URL di anteprima e l’host Git per GitHub Enterprise.
- Eventuali richieste recenti che il mittente sceglie di allegare. Per impostazione predefinita, nessuno è allegato.
Questi dettagli consentono al team di trovare la conversazione e i registri della sessione. Prima di configurare l’area di lavoro della console del mittente, una richiesta condivide solo il nome, l’indirizzo e-mail e l’organizzazione. Nelle pagine della modalità automatica, Ottieni aiuto condivide solo il nome e l’indirizzo di posta elettronica del mittente con il relativo messaggio. Chiedere agli utenti di non includere password, token o dati personali nella descrizione. Vedi Richiedi supporto.
Passaggi successivi next-steps
Una volta che il team ha concordato l’ambito, l’approccio e i controlli, segui Migrare un sito di produzione. Utilizza la modalità automatica per eseguire un primo controllo sulle tue pagine prima di eseguire il commit a quel lavoro.