Introducción
Los sistemas agenticos están cambiando cómo se compila y mantiene el software. En lugar de confiar solo en desarrolladores para escribir y actualizar código, los equipos adoptan sistemas que pueden interpretar objetivos, proponer soluciones y tomar medidas dentro de los repositorios. En GitHub, un agente puede crear una rama, modificar archivos, abrir una solicitud de incorporación de cambios y, a continuación, iterar en función de los comentarios de las pruebas, los exámenes de seguridad y las revisiones de código.
Sin embargo, la funcionalidad por sí sola no hace que un agente sea confiable. Sin una arquitectura bien definida, los agentes pueden actuar demasiado pronto, producir cambios poco claros o funcionar sin una validación suficiente. En entornos de producción, estos errores crean riesgos reales para la calidad del código, la seguridad y la estabilidad operativa.
Diseñar un sistema de agente en GitHub no trata de dar más libertad al agente. Se trata de definir cómo fluye el trabajo a través del sistema mediante funciones de GitHub ejecutables, como solicitudes de incorporación de cambios, flujos de trabajo y reglas de repositorio. Una arquitectura bien diseñada garantiza que todas las acciones del agente abandonan un registro visible, se validan mediante señales objetivas y solo se aceptan cuando cumplen los requisitos de directiva.
Glossary
Términos y definiciones clave
En este módulo se usa un pequeño conjunto de términos periódicos. Las definiciones siguientes aclaran cómo se usan en todo el contenido.
Plan (artefacto) Una descripción estructurada de los cambios previstos, que normalmente se incluye en la descripción de un pull request. Describe el objetivo, el ámbito, los pasos, los riesgos y los criterios de validación del trabajo.
Planeación (funcionalidad del agente) Proceso por el que un agente genera o refina un plan en función de una tarea, un problema o una entrada del usuario. Esto puede ocurrir en distintos puntos de entrada, como un problema de GitHub o la interfaz Agentes.