¿Qué es el modo de plan de GitHub Copilot?

Completado

GitHub Copilot en Visual Studio Code proporciona tres agentes integrados, cada uno que funciona bajo un nivel diferente de autonomía y con una relación diferente con el área de trabajo:

• Agente: un agente de implementación totalmente autónomo. Descompone un objetivo en subtareas, ejecuta llamadas a herramientas (lecturas de archivos, escrituras, comandos de terminal, llamadas al servidor MCP) y aplica los cambios directamente al área de trabajo. El bucle del agente se ejecuta hasta que se alcanza el objetivo o hasta que llega a una ambigüedad que no se puede resolver.
• Pregunta: agente de respuesta a preguntas sin estado con acceso al área de trabajo de solo lectura. Puede razonar sobre el código, explicar conceptos y sugerir enfoques, pero nunca escribe o ejecuta nada.
• Plan: Un agente que da prioridad al razonamiento y opera en un modelo deliberado de dos fases. La investigación y la síntesis se realizan primero, después la implementación, con una puerta de revisión humana obligatoria entre las dos fases.

La distinción que importa para el trabajo de operaciones no es solo sobre la seguridad. Es acerca de en qué parte del bucle de agencia se encuentra el juicio humano. Con el agente, revise la salida después de que se haya producido. Con el agente Plan, revise y apruebe el enfoque antes de hacer una única llamada a la herramienta que modifique el estado.

Funcionamiento interno del agente de Plan

El agente de plan es una instancia de un patrón agente más amplio denominado plan y ejecución, donde el razonamiento sobre lo que se debe hacer está separado de hacerlo. Comprender cómo el agente recopila información en cada fase le ayuda a escribir mejores mensajes e interpretar su salida de forma más crítica.

Fase 1: Recopilación de contextos

Al enviar una solicitud, el agente del plan no genera inmediatamente un plan. En primer lugar, crea un modelo de contexto del entorno invocando un conjunto de herramientas de solo lectura en secuencia:

• Enumeración de archivos del área de trabajo: el agente examina el árbol de archivos del área de trabajo para comprender la estructura del proyecto. Qué lenguajes, marcos y archivos de configuración están presentes.
• Lecturas de archivos específicas: en función del árbol de archivos, el agente lee los archivos pertinentes para la solicitud. Para un indicador de infraestructura, lee los módulos de Bicep existentes, los archivos de parámetros y cualquier bicepconfig.json. Para un símbolo del sistema de PowerShell, lee los scripts existentes, los manifiestos de módulo y PSScriptAnalyzer la configuración.
• Instrucciones personalizadas: el agente lee .github/copilot-instructions.md si existe en la raíz del área de trabajo. Este archivo se trata como contexto autoritativo que da forma a cada plan que genera el agente en esa área de trabajo.
• Memoria de sesión: el agente lee /memories/session/ para recoger cualquier contexto anterior en la misma conversación. Planes anteriores, respuestas a preguntas aclaratorias o hechos que usted declaró anteriormente.

No se realizan llamadas de red externa a sitios de documentación ni API durante esta fase. El conocimiento del agente sobre servicios de Azure, APIs de PowerShell o sintaxis de Bicep procede de sus datos de entrenamiento, no de búsquedas en directo.

Fase 2: Aclarar preguntas

Si el contexto recopilado en la fase 1 no es suficiente para generar un plan inequívoco, el agente expone preguntas aclaratorias. Estas preguntas no se generan aleatoriamente. Corresponden a los puntos de decisión de la implementación en los que diferentes respuestas conducen a planes significativamente diferentes.

En el caso de un indicador de decisiones operacionales, los puntos de decisión típicos incluyen:

• Ámbito: ¿Qué suscripción, grupo de recursos o servidor tiene como destino?
• Dependencias: ¿El nuevo recurso necesita hacer referencia a algo que ya existe o debe crear sus propias dependencias?
• Restricciones: ¿Existen convenciones de nomenclatura, requisitos de cumplimiento o límites de presupuesto que descartan determinados enfoques?
• Estrategia de prueba: ¿Debe el plan incluir un paso de validación mediante simulación o análisis hipotético y, si es así, en qué entorno?

La calidad de las preguntas que realiza el agente es una señal útil. Si el agente no formula preguntas aclarantes y genera inmediatamente un plan para un mensaje complejo, infraespecificado, trate el plan resultante con un examen adicional. Se hicieron suposiciones que puede que no coincidan con su entorno.

Fase 3: Planeamiento de la síntesis

Con un contexto suficiente, el agente sintetiza un plan estructurado. Lo que implica el razonamiento sobre:

• Ordenación de dependencias: qué recursos o pasos de configuración se deben crear para que otros usuarios puedan hacer referencia a ellos.
• Superficie de riesgo: qué pasos son reversibles y cuáles no, y dónde deben colocarse las puertas de verificación.
• Alineación de herramientas: Qué comandos CLI de Azure, cmdlets de PowerShell o construcciones de Bicep son adecuados dadas las restricciones y los patrones existentes que se encuentran en el área de trabajo.
• Cierre de la verificación: ¿Qué evidencia confirmaría que cada paso se realizó correctamente y cómo se pueden recopilar pruebas sin intervención humana?

La salida del plan se escribe en /memories/session/plan.md automáticamente, lo que hace que esté disponible para referencia a lo largo del resto de la conversación.

Fase 4: Iteración

El plan no es final después de la primera generación. Cada mensaje de seguimiento que envíe hace que el agente vuelva a entrar en la fase de síntesis con el contexto actualizado. Se tiene en cuenta la inclusión del plan anterior, sus comentarios y las nuevas restricciones que introdujo. El agente no se reinicia desde cero; Trata el plan anterior como un anterior que se puede modificar.

Este bucle iterativo es donde el modo Plan obtiene la mayor parte de su valor para el trabajo de operaciones. Los requisitos que surgen a mitad de la conversación se pueden incorporar sin perder el contexto establecido en turnos anteriores.

Accede al agente de Plan

Puede acceder al agente de Plan de dos maneras:

• Selector de agentes: abra la vista Chat (Ctrl+Alt+I) y seleccione Plan en la lista desplegable agentes.
• Comando de barra: introduzca /plan seguido de la descripción de la tarea en el cuadro de entrada del chat. Por ejemplo:

/plan Create a PowerShell script to audit all expired user accounts in Active Directory

Aspecto de un plan

Cuando el agente de plan genera un plan, normalmente genera tres secciones:

• Resumen: información general de alto nivel sobre lo que logra el plan y el enfoque que toma. Escritos para ser comprensibles tanto por los implementadores técnicos como por las partes interesadas no técnicas.
• Pasos de implementación: tareas ordenadas que describen qué archivos crear o modificar, qué código escribir y cómo se conectan los componentes entre sí. Los pasos se secuencian para respetar las dependencias. Por ejemplo, una subred debe existir para que un grupo de seguridad de red pueda hacer referencia a ella.
• Pasos de comprobación: acciones para confirmar que la implementación funciona correctamente, como ejecutar az deployment what-if, validar el cumplimiento de DSC con Test-DscConfigurationo comprobar el estado de los recursos después de la implementación. Los pasos de comprobación se limitan para que se puedan ejecutar sin necesidad de acceso de producción.

Por ejemplo, si pide al agente de plan que cree una directiva de etiquetado de grupos de recursos de Azure, el plan puede incluir pasos para crear un archivo JSON de definición de directiva, asignar la directiva a un grupo de administración y comprobar el cumplimiento mediante la ejecución de un comando CLI de Azure.

Dónde se almacenan los planes

El agente de plan guarda automáticamente su plan de implementación en un archivo de memoria de sesión en /memories/session/plan.md. Para acceder a este archivo, ejecute el comando Chat: Mostrar archivos de memoria en la paleta de comandos y seleccione plan.md. Dado que la memoria de sesión se borra cuando finaliza la conversación, el plan no está disponible en sesiones posteriores. Si necesita conservar un plan, cópielo en un archivo del repositorio antes de cerrar la sesión.

Modo de plan frente al modo agente

La diferencia entre el modo plan y el modo de agente no se trata principalmente de la funcionalidad. Ambos tienen acceso al mismo modelo subyacente. La diferencia radica en la posición de la puerta de revisión humana en el bucle agéntico y el contrato de efectos secundarios bajo el cual opera cada modo.

Dimensión	Agente de planificación	Agente
Efectos secundarios durante el razonamiento	Ninguno; sólo lectura	Escribe archivos, ejecuta comandos, llama a herramientas
Filtro de revisión humana	Antes de que comience cualquier implementación	Una vez completada la implementación (o durante, si se producen errores)
Reversibilidad del estado intermedio de la tarea	Siempre reversible; no se han realizado cambios	Depende de lo que se ejecutó
Adecuado para flujos de trabajo de administración de cambios	Sí; el plan es el artefacto enviado para su aprobación	No; la salida es el artefacto, que puede que ya se aplique.
Uso de la ventana de contexto	Inferior; no hay resultados de llamadas a herramientas de los pasos de implementación	Superior; acumula los resultados de las llamadas a herramientas ejecutadas.
Control de ambigüedad	Expone la ambigüedad como preguntas antes de continuar	Realiza suposiciones y continúa; podría fallar o requerir un reinicio

La implicación práctica para los equipos de operaciones es esta: cuando una tarea implica varios recursos interdependientes, pasos irreversibles (como cambios de esquema de base de datos o modificaciones de reglas de firewall), o requiere una pista de aprobación documentada, el modo Plan es la opción estructuralmente correcta, no solo la más segura.

Use el modo agente cuando se delimite la tarea, el estado del área de trabajo es fácilmente reversible y la iteración rápida importa más que un enfoque previamente aprobado.

Entrega a la implementación

Después de finalizar un plan, tiene varias opciones para continuar:

• Implementar en la misma sesión: seleccione Iniciar implementación para permitir que el agente implemente el plan directamente en el área de trabajo. El Agente recibe el documento del plan como contexto inicial y comienza a ejecutar los pasos de implementación.
• Continue en Copilot CLI: seleccione Iniciar implementación>Continue en Copilot CLI para ejecutar la implementación como sesión en segundo plano. Copilot CLI crea un worktree de Git; una copia aislada del repositorio en el commit actual. Por lo tanto, la implementación se ejecuta en un estado limpio sin afectar al árbol de trabajo.
• Continuar en un agente en la nube: delegar a un agente en la nube de Copilot que se ejecuta en la infraestructura de GitHub. El agente en la nube implementa el plan real, abre un pull request, crea una canalización de CI/CD y establece un registro de aprobación auditable.

El mecanismo de transferencia tiene una importancia significativa a nivel arquitectónico: el documento del plan escrito en /memories/session/plan.md se convierte en la especificación de tareas para el agente de implementación. La calidad y la especificidad del plan controlan directamente la calidad de la implementación. Un plan impreciso genera una implementación vaga y un plan con puertas de comprobación explícitas hace que el agente de implementación pause y compruebe en cada puerta antes de continuar.