Evaluar y aprobar el agente de modernización de experiencias evaluate
Esta página es para la persona que aprueba el Experience Modernization Agent para un equipo que crea o migra sitios de Adobe Experience Manager en Edge Delivery Services: un arquitecto, un jefe técnico o un propietario de plataforma que nunca puede utilizar el agente personalmente. En él se explican los cambios que se han producido en su equipo, las tres formas de ejecutar una migración, cómo funciona el equipo de Adobe con el suyo, qué sistemas y datos ha de modificar el agente, cómo se controlan y rastrean los cambios y qué sigue funcionando en el proyecto.
Para saber qué es Edge Delivery Services y cómo encaja un proyecto, consulta Cómo se crea y actualiza tu sitio. Un resultado en tus propias páginas te dice más que cualquier descripción, así que pídele a un miembro del equipo que empiece con el modo automático o que importe una página paso a paso mientras lees.
Cambios para su equipo team-impact
Sin el agente, una migración a Edge Delivery Services comienza con semanas de trabajo del desarrollador antes de que nadie pueda juzgar el resultado: enumerar las páginas de origen, agruparlas por diseño, asignar su contenido a bloques, escribir código de bloque y estilos, y escribir scripts de importación. El agente realiza ese trabajo repetitivo con su equipo, en un entorno alojado sin nada que instalar.
- Su equipo decide y revisa; el agente produce. Las personas establecen el ámbito, el modelo de contenido, el diseño de destinatario y las integraciones, y aceptan el resultado. El agente escribe el código, importa el contenido y compara el resultado con el origen.
- Más personas contribuyen directamente. Los diseñadores, especialistas en contenido y especialistas en marketing que conocen algunos HTML y los conceptos básicos de Git realizan cambios al describirlos en un lenguaje sencillo. Los desarrolladores controlan lo que llega a la producción y revisan esos cambios como solicitudes de extracción. Vea Contribución más amplia, mismo control de producción.
- El esfuerzo aumenta con los diseños, no con las páginas. Una corrección cambia un bloque reutilizable o un script de importación en lugar de una página, por lo que se aplica a todas las páginas del mismo diseño. Un sitio de 5000 páginas que comparten 12 diseños es principalmente el trabajo de 12 plantillas. Ver Cómo migra el agente a escala y, para calcular el tamaño del trabajo de las primeras plantillas, Calcular antes de confirmar.
- El resultado es un proyecto estándar. El código es HTML, CSS y JavaScript sin formato en el repositorio de Git, siguiendo las convenciones de la plantilla de AEM. El sitio no depende del agente en tiempo de ejecución y los desarrolladores pueden continuar en su propio editor o con otras herramientas de IA.
- El conocimiento del proyecto permanece en el repositorio. Las convenciones en las que está de acuerdo su equipo están activas en
AGENTS.mdy los archivos relacionados, que siguen tanto el agente como los nuevos integrantes del equipo. Ver Instrucciones y memoria del proyecto.
Qué hace el agente y qué hace su equipo responsibilities
Para obtener información sobre cómo coordina el posible cliente de la migración a los contribuyentes, consulte Liderar la migración. Varias personas pueden trabajar en un proyecto, cada una en su propio área de trabajo de la consola; vea Trabajar como un equipo.
Qué queda del trabajo del proyecto project-work
El agente es un agente de desarrollo: lo que se puede crear en Edge Delivery Services se puede crear con él. Sin embargo, una migración copia lo que muestran las páginas de origen, no los sistemas detrás de ellas. El agente reconstruye el sitio: sus páginas, bloques, estilos y el código que llama a sus servicios. Los flujos de trabajo de aprobación y publicación, los sistemas back-end detrás de las integraciones y cómo trabajan sus equipos en el nuevo sitio siguen siendo el trabajo de su organización. Estas necesidades requieren una decisión de su equipo antes de que el agente pueda crearlas:
Para obtener acceso al origen, contenido interactivo y otros límites de la importación, consulte Limitaciones.
Figma y Sistemas de Diseño figma
Figma puede ser la fuente de un nuevo diseño. Con el complemento de importación Figma, el agente lee el componente o marco seleccionado a través de la API de Figma, utilizando un servidor de Protocolo de contexto de modelo (MCP), de la forma en que un desarrollador lee un traspaso de diseño. Escribe las variables y los estilos del diseño, como los colores, la tipografía y el espaciado, como propiedades personalizadas de CSS en los estilos globales del proyecto. Estas propiedades son los tokens de diseño del sitio. Se alojan en el código, no en una exportación de tokens independiente, por lo que los diseñadores y desarrolladores las revisan como cualquier otro cambio. Para ver cómo los diseñadores trabajan desde Figma con el agente, vea Trabajar desde un diseño Figma.
Qué se debe aprobar:
- Acceso: Cada persona que usa Figma con el agente crea un token de acceso personal Figma con ámbitos de solo lectura y lo almacena en la configuración de la consola. Figma emite y rige este token de acceso, que no tiene nada que ver con los tokens de diseño. No hay una conexión Figma en toda la organización, y un token de acceso personal no se puede limitar a archivos específicos: lee todos los archivos que su propietario puede abrir.
- Plazas y límites de tarifa: Figma limita la frecuencia con la que un token puede leer archivos, según el asiento del propietario del token y el plan que posee el archivo. Con un asiento de vista o colaboración, un token puede leer archivos a través de la API de Figma solo unas pocas veces al mes, por lo que las personas que utilizan Figma con el agente necesitan un asiento completo o de desarrollo. Consulte los límites de tarifa de Figma.
- Datos: Para el marco o componente seleccionado, el agente envía su estructura, una captura de pantalla, sus variables y su texto al modelo de IA. Ver Lo que procesa el modelo de IA.
Elija cómo se ejecuta la migración approaches
El mismo agente puede ejecutar una migración de tres formas. Difieren en quién conduce al agente y quién responde por el resultado. Los tres producen un proyecto estándar de Edge Delivery Services, con código en un repositorio Git y contenido que los autores editan, para que pueda pasar de uno a otro: transfiera un resultado de modo automático a su propio sitio y continúe en la consola, o continúe con el agente usted mismo después de un compromiso con los ingenieros de resultados del agente.
El equipo detrás del agente adobe-team
Al elegir el agente, también elige el equipo que lo crea y la dirección que toma. La forma en que la gente encuentra información en la web está cambiando: muchos de ellos preguntan a un asistente de IA, que responde a lo que lee en el sitio de la marca. Y un agente puede cambiar el contenido, el diseño y el código de un sitio juntos, de modo que un cambio que una vez que se necesita un proyecto puede tomar horas. La misión del equipo es ayudarle a pasar a Edge Delivery Services, sacar el máximo partido a Experience Manager y utilizar herramientas de desarrollo auténticas para crear sitios que sigan siendo relevantes a medida que estos cambios continúan. Su trabajo con usted no termina con la migración y el agente sigue cambiando; las notas de la versión enumeran cada cambio.
Cuando los cambios son baratos, la parte difícil es decidir qué cambiar, mantenerlo controlado y darle al agente la marca, el diseño y el contexto comercial correctos. Ese conocimiento pertenece a sus equipos y sistemas. El equipo de Adobe le ayuda a conectarlo a la plataforma:
- Ingenieros que pueden ejecutar la migración con usted. Para una migración compleja, los ingenieros de resultados del agente de Adobe pueden operar el agente con su equipo y entregarle el sitio. Consulte Elegir cómo se ejecuta la migración.
- Actual a medida que cambia el producto. El aviso de Novedades de la consola enumera los aspectos destacados de cada versión. Para aplicar un cambio a su propio sitio, revisar su arquitectura o discutir una necesidad que el agente aún no haya satisfecho, pida a su gestor de éxito de clientes o a su equipo de cuenta de Adobe una reunión con expertos en la materia y al equipo de productos.
- Su experiencia da forma al producto. El equipo de productos intercambia experiencia con clientes y socios y trabaja con algunos de ellos en nuevas funciones. Lo que informa se integra en lo que el equipo corrige y crea a continuación.
Para comunicarte con el equipo desde la consola, usa Solicitar ayuda o Obtener ayuda en las páginas de Modo automático. El mensaje va directamente al equipo que crea el agente, que lo analiza y lo sigue por correo electrónico. Consulte Solicitar soporte técnico y, para lo que una solicitud comparte, Solicitudes de soporte técnico.
El equipo de Adobe trabaja del mismo modo con los socios de implementación, de modo que con su socio el sitio siga mejorando después de la migración.
Sistemas y flujo de datos systems
El agente funciona en un entorno alojado y llega a sus sistemas únicamente a través de las conexiones que las personas configuran y los permisos que conceden.
aemcoder.adobe.io donde las personas trabajan con el agente.aem.page y el sitio activo de aem.live.Seguridad y gestión de datos security
La consola permite que el agente trabaje en el sitio sin proporcionarle las credenciales que ha configurado y usted decide cuándo llegan los cambios al repositorio de Git y al destino del contenido.
Acceso y aislamiento security-access
- Inicie sesión en la consola con su Adobe ID. Cada solicitud se autentica con Adobe Identity Management Services (IMS).
- Cada usuario trabaja en un entorno backend independiente con su propio almacenamiento de espacio de trabajo, uno en cada organización de Adobe con la que inicia sesión. La consola crea el entorno cuando el usuario inicia sesión por primera vez y lo pone en pausa cuando está inactivo.
- La consola no tiene funciones de proyecto. Cualquier persona con acceso a puede solicitar al agente cualquier cambio en su propio espacio de trabajo. Experience Manager y su proveedor de Git siguen aplicando sus propios permisos a cualquier código o contenido que salga del espacio de trabajo.
Credenciales security-credentials
- El agente de IA no recibe las credenciales que configuró en la consola. Los tokens para GitHub, repositorios Git de Cloud Manager, Experience Workspace, Figma y sitios de origen protegidos se conservan fuera del entorno del agente. Un componente independiente agrega cada credencial solo a las solicitudes del servicio al que pertenece. Lo mismo se aplica a la credencial utilizada para llamar al modelo de IA.
- Las credenciales pertenecen al usuario que las configura, no al proyecto. Cada miembro del equipo conecta su propia cuenta de Git y almacena su propio token de Figma.
- Los permisos de agente están desactivados hasta que los active. Activar una permite al agente actuar con ese acceso, por ejemplo, para insertar en el repositorio, sin ver las credenciales. De forma predeterminada, un permiso utiliza el inicio de sesión del propio usuario. Para reducir el alcance del agente, introduzca un token para él en su lugar: un token de acceso personal detallado orientado a los repositorios que necesita o el token de una cuenta de servicio de Adobe.
- Otros servicios a los que llama el agente mientras funcionan, como una API de prueba, obtienen sus credenciales del mismo modo, a partir de una entrada en Autenticación de sitios protegidos para el nombre de host del servicio. Ver credenciales de otros servicios.
- Almacenar credenciales solo en la configuración de la consola, nunca en mensajes de texto, charlas, contenido de origen o archivos de proyecto: el agente lee estas credenciales y puede enviarlas al modelo de IA. Incluya esto en la incorporación, ya que las personas que son nuevas en los agentes de codificación pueden pegar una contraseña o clave en el chat para realizar una tarea. Pídale a todas las personas que usen la consola que lean Mantener los secretos fuera del chat primero y díganles qué política de su organización les permite compartir con las herramientas de IA.
Qué procesa el modelo de IA security-model-data
Para realizar su solicitud, el agente puede enviar lo siguiente al modelo de lenguaje grande (LLM) que utiliza, actualmente un modelo de Claude:
- Sus indicaciones e instrucciones.
- URL, marcado y contenido de páginas Source, o contenido CMS exportado.
- Código y configuración del repositorio, como bloques, estilos y configuración del sitio.
- Referencias de diseño y marca, como diseños y capturas de pantalla de Figma.
- Contenido generado y código en revisión.
Adobe no utiliza sus conversaciones ni otros datos de clientes para entrenar o ajustar modelos de IA.
Control de cambios security-control
El agente funciona en el espacio de trabajo de la consola, donde puede revisar sus cambios y previsualizar. El trabajo llega al sitio en pasos separados y cada paso tiene su propio control:
- Las comprobaciones propias de la consola son salvaguardas, no puertas de aprobación. El modo de plan opcional permite aprobar un plan antes de que se inicie el agente. La consola también impide que el agente cargue, previsualice o publique a menos que el mensaje actual se lo pida o que usted esté de acuerdo cuando el agente se lo pida, pero no puede detectar todas las formas de realizar dicha solicitud. Ninguna comprobación impide que una persona con acceso inserte o publique.
- Con un permiso Git, el agente puede insertar en cualquier rama en la que puedan escribir sus credenciales, incluido
main. Una inserción enmaincambia el código del sitio activo. - Para requerir una revisión, haga que se aplique donde aterrice el cambio. Proteja
maincon protección de ramas que requiera una solicitud de extracción revisada, inserte Crear nueva PR y limite quién puede publicar con el rol de publicación del sitio. La solicitud de extracción enumera los archivos modificados y las direcciones URL de vista previa de las páginas afectadas, de modo que un desarrollador compruebe el resultado antes de combinar. Configure estos controles antes de que más personas contribuyan y active los permisos de agente solo cuando una tarea los necesite. Vea Contribución más amplia, mismo control de producción. - Tratar las páginas de origen y los archivos de diseño como entradas que no son de confianza. Pueden contener texto que intente dirigir al agente. Revise los cambios antes de insertarlos, previsualizarlos o publicarlos.
Permisos de inserción de contenido content-push-permissions
Al cargar contenido mediante el inicio de sesión en Adobe, el destino aplica los permisos de la cuenta. Para el contenido basado en documentos editado en Experience Workspace, es necesario tener acceso de escritura al contenido de destino. Para la creación en Experience Manager, necesita permiso para escribir páginas y recursos en las rutas seleccionadas en la instancia de autor. El inicio de sesión en la consola no concede esos derechos.
Cuando activa el permiso de credenciales de Adobe del agente, su contenido se inserta en el repositorio de contenido basado en documentos para utilizar el acceso de su cuenta. Pedir al agente que realice la carga no evita los permisos del destino. Para la creación de Experience Manager, cargue el contenido usted mismo a través de la consola; no se admiten las cargas directas del agente.
Si una carga basada en documentos utiliza una cuenta de reserva configurada porque el inicio de sesión no está disponible o la autenticación falla, el destino aplica los permisos de esa cuenta en su lugar. Lo mismo se aplica cuando se configura explícitamente una cuenta de servicio para el agente. Confirme qué cuenta se utiliza antes de depender de sus permisos personales para limitar los cambios.
Rastree lo que hizo el agente audit-trail
La consola no mantiene ningún registro de auditoría independiente, pero el trabajo del agente no queda sin registrar. Lo que el agente produce llega a su sitio solo a través de su repositorio de Git o a través de Experience Manager, y ambos mantienen un historial:
- El código es el registro principal. El historial de Git registra cada cambio en bloques, estilos y scripts de importación, y los scripts de importación definen la estructura de cada página importada.
- Los cambios de contenido se registran con el contenido. Experience Workspace mantiene un historial de versiones de cada documento y la instancia de autor mantiene sus propias versiones de página.
- La conversación muestra lo que se le pidió. Descargar chat guarda la conversación como un archivo Markdown. Descárgalo antes de seleccionar Borrar chat, lo cual elimina los mensajes y no se puede deshacer. Ver Panel de chat.
El registro es más fácil de seguir cuando cada solicitud al agente termina en su propia confirmación, insertada en una rama de trabajo en lugar de en main y, cuando las páginas cambian, su propia carga de contenido, que el agente ofrece y una persona aprueba. Pedir esto en AGENTS.md del proyecto; consulte Dejar un registro de cada solicitud. Los revisores leen lo que ha cambiado el agente, solicitud por solicitud, en las herramientas que ya utilizan.
Dónde Se Almacena El Trabajo security-storage
- El código que inserte se almacenará en el repositorio Git y el contenido que cargue se almacenará en Experience Workspace o en la instancia de autor. Se aplican sus propias políticas de retención e historial de versiones.
- El trabajo que no ha insertado ni cargado sólo existe en su espacio de trabajo de la consola, junto con el historial de chat y las transcripciones de las sesiones del agente. Borrar chat elimina los mensajes del panel de chat pero mantiene las transcripciones. Para eliminar el trabajo del proyecto abierto en el área de trabajo de la consola, incluidas las transcripciones, use Restablecer área de trabajo.
Para obtener información sobre ubicaciones de procesamiento, retención de datos e información de conformidad, póngase en contacto con el equipo de su cuenta de Adobe o visite el Centro de confianza de Adobe.
Datos de estado e HIPAA security-hipaa
Experience Modernization Agent es una herramienta para desarrolladores que permite migrar y crear sitios. Los visitantes del sitio nunca llegan a él: Edge Delivery Services sirve al sitio publicado y las solicitudes de los visitantes no pasan a través de la consola o del agente. Puede migrar las páginas, los diseños y los recursos de un sitio de atención médica sin datos de los pacientes. Nunca dé al agente datos reales del usuario final, como registros de pacientes o credenciales de usuarios, ni migre páginas o recursos que los contengan. Utilice datos ficticios para desarrollar y probar diseños específicos del paciente. Sea lo que sea lo que le dé al agente, puede llegar al modelo de IA; consulte Qué procesa el modelo de IA.
Un sitio de ensayo, una lista de permitidos o un inicio de sesión de origen no cambian esta restricción. Antes de importar una fuente protegida, compruebe las páginas y los recursos en ámbito y restrinja la cuenta de origen al contenido sin información médica protegida (PHI). Configure esa cuenta mediante autenticación de origen, no en el chat.
Para un sitio que procesará la PHI según la Ley de Portabilidad y Responsabilidad del Seguro de Salud (HIPAA, Health Insurance Portability and Accountability Act), confirme la configuración de creación y entrega con su equipo de cuenta de Adobe, incluida la licencia requerida, el Contrato de asociación comercial (BAA, Business Associate Agreement) y la configuración. Preparación para HIPAA para Adobe Experience Manager as a Cloud Service enumera Edge Delivery Services como compatible con HIPAA, pero el editor universal no lo está; se puede agregar a un programa de seguridad extendida solo cuando no se introduce ninguna PHI. Un servicio de entrega compatible con HIPAA no extiende su cobertura PHI al agente o a un editor que no esté preparado para HIPAA.
Solicitudes de soporte security-support
Se enviará una solicitud de asistencia al equipo de Adobe que cree el agente. Con el tema y la descripción que escribe el remitente, comparte:
- Nombre del remitente, dirección de correo electrónico e ID de usuario y organización de Adobe.
- El ID de sesión, el nombre del proyecto, la URL de vista previa y el host Git para GitHub Enterprise.
- Cualquier mensaje reciente que el remitente decida adjuntar. Ninguno está adjunto de forma predeterminada.
Estos detalles permiten al equipo encontrar la conversación y los registros de la sesión. Antes de configurar el espacio de trabajo de la consola del remitente, una solicitud comparte únicamente el nombre, la dirección de correo electrónico y la organización. En las páginas en modo automático, Obtener ayuda comparte únicamente el nombre y la dirección de correo electrónico del remitente con su mensaje. Pida a los usuarios que no incluyan contraseñas, tokens o datos personales en la descripción. Ver Solicitar asistencia.
Próximos pasos next-steps
Una vez que su equipo haya acordado el ámbito, el enfoque y los controles, siga Migrar un sitio de producción. Use Modo automático para realizar una primera comprobación de sus propias páginas antes de comprometerse con ese trabajo.