Subagentes de inteligencia artificial en Visual Studio Copilot

Inicio » Software » Subagentes de inteligencia artificial en Visual Studio Copilot

Si usas Visual Studio o VS Code y solo ves GitHub Copilot como un simple autocompletado de código, estás dejando escapar gran parte de su potencial. La llegada de los agentes y subagentes de inteligencia artificial lo está transformando en un auténtico sistema de orquestación capaz de repartir trabajo, coordinar tareas complejas y apoyarse en herramientas del IDE de forma casi automática.

La idea clave es que Copilot ya no actúa como un único asistente genérico, sino como un conjunto de agentes especializados que entienden el código, hablan con las herramientas de Visual Studio, pueden conectarse a fuentes externas mediante MCP y, además, permiten que tú mismo definas agentes personalizados alineados con tu equipo, tu stack y tus procesos internos.

Qué es un agente y cómo encajan los subagentes en Copilot

Un agente de IA se puede entender como un programa inteligente compuesto por tres bloques fundamentales: lo que sabe, lo que es capaz de procesar y lo que puede hacer en los sistemas con los que está conectado. En Copilot esto se traduce en el acceso al repositorio, la memoria de la sesión, los modelos de lenguaje, las herramientas del IDE y, opcionalmente, orígenes externos mediante MCP.

En términos prácticos, cada agente combina: datos y contexto (tu solución, tu historial de chat, documentación conectada), capacidad de razonamiento (el modelo de IA que elijas) y acciones concretas (leer y editar ficheros, buscar referencias, lanzar comandos, hacer profiling, etc.). Eso le permite no solo contestar preguntas, sino también ejecutar flujos de trabajo completos en tu workspace.

Sobre esa base surge el patrón conductor-subagentes: un agente principal actúa como “director de orquesta” y delegan partes del trabajo en subagentes especializados. Cada subagente se centra en una tarea muy específica (por ejemplo, pruebas, refactorización o diseño de niveles de un juego) y solo ve el contexto necesario, aplicando el principio de mínimo privilegio para evitar que “toque” lo que no debe.

En la práctica, el agente conductor se encarga de entender bien el objetivo, planificar los pasos, decidir qué subagente es el adecuado para cada fase, encadenar resultados y revisar que todo encaje. Los subagentes, por su parte, ejecutan tareas acotadas siguiendo instrucciones y herramientas muy delimitadas, sin asumir más responsabilidades de las necesarias.

Este enfoque encaja con una tendencia más amplia en las empresas: los agentes de inteligencia artificial se utilizan ya en finanzas, sanidad, retail, industria o atención al cliente para automatizar tareas repetitivas, acelerar la toma de decisiones, mejorar la experiencia de usuario y simplificar operaciones. Copilot simplemente traslada ese patrón al entorno de desarrollo.

Agentes integrados de Visual Studio: debugger, profiler, test y modernize

Visual Studio incluye una serie de agentes nativos mantenidos por Microsoft que se integran profundamente con las funciones del IDE, y que van mucho más allá de lo que podría hacer un chatbot genérico sin acceso directo a las herramientas internas.

Estos agentes integrados se centran en flujos de trabajo muy concretos del día a día de desarrollo: diagnóstico de errores, rendimiento, pruebas automatizadas y modernización tecnológica. Cada uno expone un alias con sintaxis @nombreDelAgente, que puedes usar tanto en la ventana de Copilot Chat como dentro del código.

Para acceder a ellos en Visual Studio dispones de dos opciones. Por un lado, el selector de agentes en la ventana de chat (Agent picker), que muestra todos los agentes disponibles; actualmente esta característica está presente en la compilación Visual Studio 2026 Insiders. Por otro, puedes invocarlos escribiendo @seguido del nombre directamente en el mensaje de chat, por ejemplo @debugger o @profiler.

El agente @debugger se apoya en la pila de llamadas, el estado de las variables y las herramientas de diagnóstico para localizar de forma sistemática el origen real de los fallos en toda la solución. No se limita a leer el texto de la excepción: aprovecha el contexto vivo de depuración. El agente @profiler se conecta a la infraestructura interna de perfiles de Visual Studio para detectar cuellos de botella y proponer optimizaciones ajustadas a tu código, evitando caer en consejos genéricos.

El agente @test está orientado a la generación de pruebas unitarias adaptadas al framework y a los patrones de tu proyecto, evitando test boilerplate que la integración continua tiraría a la basura. Por último, el agente @modernize (disponible para .NET y C++) te ayuda a gestionar actualizaciones de frameworks y dependencias teniendo en cuenta el grafo real de proyectos, marca cambios potencialmente disruptivos, sugiere código de migración y respeta los estilos existentes.

Cómo usar los agentes integrados con la sintaxis @ en Copilot Chat

El uso de estos agentes dentro de Visual Studio es muy directo gracias a la sintaxis @. Basta con abrir Copilot Chat, colocarte en el contexto correcto (por ejemplo, con un punto de interrupción activo o con un método seleccionado) y escribir el alias del agente seguido de tu pregunta en lenguaje natural.

Con el agente @debugger puedes, por ejemplo, lanzar consultas como: “@debugger Why is this exception being thrown?” o “@debugger Analyze the current call stack and explain what went wrong”. El agente analizará la pila de llamadas, las variables capturadas y el estado de ejecución para señalar qué parte del flujo está rompiendo y por qué.

Además, @debugger admite un flujo de extremo a extremo pensado para la resolución guiada de bugs: es capaz de ayudarte a reproducir el error, instrumentar la aplicación con trazas y puntos de interrupción condicionales, y validar la corrección utilizando datos en tiempo de ejecución. Todo ello sin que tengas que ir saltando manualmente entre ventanas y configuraciones.

El agente @profiler responde a peticiones del estilo: “@profiler Find the performance bottlenecks in my application”, “@profiler Why is this method taking so long to execute?” o “@profiler Suggest optimizations for the hot path”. Gracias a su integración con las herramientas de rendimiento del IDE, puede señalar rutas críticas, métodos especialmente costosos o patrones ineficientes y proponer cambios concretos.

En el caso de @test, bastan indicaciones como “@test Generate unit tests for the selected method”, “@test Create tests that cover edge cases for this class” o “@test Write integration tests for this API endpoint”. El agente generará pruebas alineadas con tus convenciones de nombres, tu framework de testing y tu estilo habitual, algo clave para que la pipeline de CI las acepte sin fricción.

Por último, @modernize soporta un proceso guiado en tres fases para proyectos .NET: evaluación, planificación y ejecución de tareas. Puede revisar las versiones de paquetes y frameworks, detectar riesgos de compatibilidad de APIs, elaborar un plan de migración coherente con las prioridades del equipo y mantener un archivo de tareas dinámico que se va actualizando durante el trabajo.

Creación de agentes personalizados en Visual Studio y GitHub

Más allá de los agentes integrados, uno de los puntos fuertes de Copilot es la posibilidad de definir tus propios agentes personalizados, adaptados a tu forma de trabajar, a los estándares de tu organización y a las herramientas que usas cada día.

Estos agentes personalizados se almacenan como ficheros .agent.md dentro de una carpeta específica. A nivel de repositorio, se colocan en .github/agents/, de manera que viajan con el código y se comparten con todo el equipo. Por ejemplo, podrías tener your-repo/.github/agents/code-reviewer.agent.md para un revisor de código especializado en tus normas.

También tienes la opción de crear agentes de usuario que funcionen en todos tus proyectos, con independencia del repositorio. En ese caso, los archivos se guardan por defecto en %USERPROFILE%\.github\agents, y puedes cambiar esta ruta desde el menú Herramientas > Opciones > GitHub > Copilot de Visual Studio.

Cada archivo de agente sigue una plantilla muy sencilla basada en frontmatter YAML en la parte superior y, a continuación, un bloque de instrucciones escritas en Markdown. En el YAML defines propiedades como el nombre visible, la descripción, el modelo a utilizar o la lista de herramientas permitidas. En la parte inferior estableces la “personalidad” del agente, sus responsabilidades, su flujo de trabajo y sus límites.

Un ejemplo típico de definición incluiría campos como name, description, model y tools, seguidos de párrafos donde explicas, con lenguaje natural, cómo debe comportarse el agente: qué estilo de código seguir, cómo marcar errores, qué convenciones respetar y qué tipo de salida producir. De esta forma, dejas por escrito el rol exacto que quieres que desempeñe dentro del equipo.

Propiedades de frontmatter y configuración de herramientas

El bloque YAML del archivo .agent.md soporta varias propiedades que conviene conocer bien para sacarle todo el partido. La propiedad name no es obligatoria, pero te permite definir el nombre que se mostrará en el selector de agentes. Si la omites, Copilot tomará el nombre del archivo: por ejemplo, code-reviewer.agent.md pasará a verse como “code-reviewer”.

La propiedad description sí es obligatoria y se utiliza para mostrar un breve texto explicativo cuando pasas el ratón por encima del agente en la interfaz. Conviene que sea concisa y clara, ya que ayuda a que el resto del equipo entienda rápidamente en qué situaciones debe usar ese agente concreto.

El campo model te permite elegir el modelo de IA que empleará el agente. Si no lo especificas, se usará el modelo seleccionado en el selector global de modelos de Copilot. Esto da bastante juego, porque puedes reservar modelos más potentes para agentes que toman decisiones clave (por ejemplo, planificación o refactorización profunda) y utilizar modelos más ligeros en agentes que hagan tareas repetitivas.

Por su parte, la propiedad tools es un array con los nombres de las herramientas a las que el agente tendrá acceso. Si no la indicas, el agente podrá usar todas las herramientas disponibles, pero por buenas prácticas suele ser preferible limitarlo a las que realmente necesita: code_search, readfile, editfiles, find_references, runcommandinterminal, getwebpages, etc., según el cliente y la plataforma.

Esta configuración granular de herramientas es crítica porque define qué acciones puede llevar a cabo el agente dentro del IDE o de GitHub. Por ejemplo, un agente de planificación solo necesitará leer archivos y buscar referencias; un agente full-stack, en cambio, podrá además editar ficheros y lanzar comandos de build o test en la terminal integrada.

Conexión a fuentes externas con MCP y habilidades reutilizables

Uno de los elementos más potentes del ecosistema de agentes personalizados es la integración con MCP (Model Context Protocol), que permite conectar el agente a orígenes de conocimiento externos y convertirlo en un auténtico “experto interno” de tu organización.

Mediante servidores MCP, un agente puede acceder a documentación corporativa y wikis internos, sistemas de diseño y bibliotecas de componentes, APIs internas, bases de datos o repositorios de decisiones técnicas (ADR). De esta forma, no se limita a lo que hay en el repositorio, sino que puede consultar información estratégica que normalmente tendrías que buscar tú a mano.

Un caso muy típico es el del agente de revisión de código que, además de ver el diff y el repositorio, consulta la guía de estilo oficial de la empresa a través de MCP. Así puede comprobar en tiempo real si las nuevas contribuciones respetan los estándares reales del equipo, incluyendo convenciones de nombres, directrices de logging, requisitos de documentación o patrones de diseño aceptados.

Otro concepto interesante son las aptitudes reutilizables del agente (skills). Se trata de bloques de instrucciones orientadas a tareas muy específicas que cualquier agente puede detectar y usar automáticamente. Mientras que un agente define un rol general y las herramientas asociadas, las aptitudes actúan como piezas modulares que se pueden aprovechar desde varios agentes diferentes.

Esta combinación de agentes personalizados, MCP y aptitudes hace posible construir verdaderos sistemas multiagente dentro de tu organización, donde cada agente tiene un rol bien definido, acceso solo a la información que necesita y la capacidad de ejecutar flujos complejos apoyándose en tus fuentes internas de conocimiento.

Ejemplos de agentes personalizados: revisor, planificador y diseño de UI

Para aterrizar ideas, merece la pena revisar algunos patrones de agentes personalizados que ya se están utilizando en proyectos reales y que puedes tomar como base para tus propios .agent.md. El primero es el clásico revisor de código, cuyo objetivo es asegurar que las contribuciones respetan las normas del equipo antes de llegar a producción.

Un agente de este tipo suele tener un nombre del estilo “Code Reviewer”, una descripción clara y acceso a herramientas como code_search y readfile. Sus instrucciones internas pueden incluir reglas concretas, como el uso de PascalCase para métodos públicos y camelCase para campos privados, exigencia de manejo de errores con logging estructurado en llamadas asíncronas, verificación de que todo método público tiene al menos una prueba unitaria asociada y comprobación de que las APIs públicas disponen de comentarios XML.

Otro patrón muy útil es el agente de planificación de características (Feature Planner). Este agente se centra en ayudar antes de escribir código: cuando le pides una nueva funcionalidad, se toma su tiempo para hacer preguntas aclaratorias, identificar los componentes afectados en el código, desglosar el trabajo en tareas manejables, señalar dependencias y riesgos y producir un plan estructurado listo para que alguien lo implemente.

En el ámbito de la interfaz de usuario, es frecuente definir un agente de sistema de diseño (Design System). Este tipo de agente revisa el código de UI para asegurar que se usan los componentes estándar en lugar de versiones caseras, comprueba que el espaciado y el layout respetan los tokens de diseño, valida que se cumplen requisitos de accesibilidad (etiquetas ARIA, navegación por teclado, etc.) y marca cualquier desviación respecto a los patrones de diseño establecidos.

Al construir estos agentes, la clave es que las instrucciones sean lo bastante detalladas como para que el agente actúe de forma consistente, pero también lo bastante acotadas como para que no intente salirse de su papel. El objetivo es que se comporten como miembros del equipo especializados que saben exactamente qué se espera de ellos.

Agentes full‑stack y agentes curados para .NET (C# y WinForms)

Además de agentes muy enfocados en una tarea (revisión, planificación, diseño), también es posible configurar agentes full‑stack con acceso a un conjunto más amplio de herramientas, pensados para acompañarte durante todo el ciclo de desarrollo: búsqueda de código, edición de ficheros, ejecución de builds y tests, consulta de documentación en la web, etc.

Un agente de este tipo puede declararse con herramientas como code_search, readfile, editfiles, find_references, runcommandinterminal y getwebpages, y unas instrucciones que lo guíen para seguir patrones ya existentes, respetar convenciones del repositorio, probar los cambios antes de darlos por buenos y consultar documentación externa cuando se encuentre con algo desconocido.

En el ecosistema .NET, el equipo de la plataforma mantiene un conjunto de agentes personalizados curados publicados en el repositorio awesome-copilot. Entre ellos destacan dos: CSharpExpert.agent.md y WinFormsExpert.agent.md, orientados respectivamente al desarrollo moderno en C# y al trabajo con Windows Forms en versiones recientes de .NET.

El agente experto de C# se centra en aplicar las convenciones actuales del lenguaje: sintaxis moderna, buen rendimiento, uso correcto de async/await, control de excepciones y cancelación, eliminación de código sin usar (interfaces, métodos, parámetros supérfluos) y soporte para diferentes tipos de pruebas (unitarias, de integración y TDD). La idea es que genere solo el código necesario sin introducir ruido.

Por su parte, el agente experto en WinForms está pensado para proyectos en .NET 8 hasta .NET 10 y se obsesiona especialmente con proteger el código del diseñador (.Designer.cs) para evitar que el Diseñador de formularios se rompa tras las modificaciones sugeridas por Copilot. También aplica patrones modernos de UI como MVVM y MVP con Community Toolkit, maneja temas como modo oscuro y alta resolución (DPI), trata correctamente los tipos de referencia anulables y domina la serialización CodeDOM con atributos y métodos ShouldSerialize*().

Si te interesa este enfoque, el repositorio awesome-copilot mantiene además configuraciones aportadas por la comunidad que puedes reutilizar como punto de partida. Eso sí, siempre conviene comprobar que los nombres de herramientas que usan esas plantillas son compatibles con Visual Studio antes de desplegarlos de forma general en tu equipo.

Patrón conductor-subagentes en VS Code: orquestación real de trabajo

En el mundo de VS Code ya hay desarrolladores que han llevado esta filosofía multiagente un paso más allá, diseñando prompts reutilizables para construir planes y dividir tareas en subplanes que Copilot ejecuta usando subagentes internos. Aunque la integración de subagentes en VS Code todavía está en evolución, la base ya funciona y permite repartir trabajo de forma bastante estructurada.

La idea suele partir de un agente principal (conductor) que se define también en un .agent.md, y cuyo rol es pensar a largo plazo, no ir corriendo a generar código a la primera. Este agente interpreta la intención del usuario, elige el lenguaje y la arquitectura adecuados, decide qué partes deben resolverse mediante subagentes especializados y se encarga de mantener la coherencia de todo el resultado.

Por ejemplo, podrías pedirle: “Quiero un juego 2D retro tipo shooter espacial con niveles cortos”. El conductor genera un plan, define entidades como jugador, enemigos, bucle de juego y niveles, y acto seguido reparte responsabilidades en un “escuadrón” de subagentes: uno para la lógica del game loop, otro para el diseño de niveles, otro para refactorizar el código y otro para generar tests.

Cada subagente opera solo sobre el contexto que le corresponde. El agente de mecánicas se ocupa de físicas 2D y entidades, pero no entra a discutir el diseño de niveles. El agente de level design define geometría, progresión y configuración de escenarios sin meterse en la implementación de colisiones. El refactorer limpia y organiza sin inventar nuevas funcionalidades. El tester se limita a crear pruebas automatizadas para comprobar reglas de juego y colisiones.

El pegamento que lo hace posible es la capacidad del agente principal para invocar subagentes con contexto acotado, indicando qué deben hacer, qué archivos pueden tocar y qué formato de salida deben devolver. Así conviertes Copilot en un sistema que no solo responde a prompts aislados, sino que ejecuta procesos completos con etapas y responsabilidades bien definidas.

Lo interesante es que este patrón de “juego retro” es prácticamente idéntico al que puedes aplicar a tareas serias: implementación de autenticación OAuth, construcción de módulos AL en Business Central, automatización de análisis de código, pipelines avanzados, documentación continua o exposición de datos internos mediante MCP. Cambia el dominio, pero la arquitectura de conductor y subagentes es la misma.

Cómo integrar agentes de IA en la organización y buenas prácticas

Si quieres llevar estos agentes más allá de una prueba puntual, lo razonable es empezar por identificar casos de uso concretos donde la automatización aporte valor real: revisión de código repetitiva, migraciones tecnológicas, generación de test, refactorizaciones masivas o soporte a desarrolladores más junior, por citar algunos.

Una vez detectados esos escenarios, conviene seleccionar qué combinación de solución de IA y agentes encaja mejor con tus necesidades: agentes integrados de Visual Studio, agentes personalizados en .agent.md, integración con MCP, o incluso un setup multiagente en VS Code. A partir de ahí, lo sensato es hacer un piloto controlado con un equipo pequeño y recoger feedback.

En paralelo tendrás que integrar el agente con tus sistemas ya existentes: conectarlo al repositorio, a la documentación corporativa, a los pipelines de CI/CD o, si es necesario, a APIs internas mediante MCP. No olvides formar al equipo para que entiendan tanto lo que el agente puede hacer como lo que no debe hacer, y para que aprendan a formular prompts eficientes.

Desde el punto de vista de diseño de agentes, hay una serie de buenas prácticas que suelen marcar la diferencia. Es preferible limitar al máximo las herramientas a las que tiene acceso cada subagente para evitar que derive hacia tareas no deseadas. También es importante no mezclar roles: un agente implementador no debería actuar a la vez como revisor, y viceversa.

Igualmente, es recomendable definir salidas bien estructuradas (por ejemplo, listas de tareas, bloques de código marcados, resúmenes con secciones explícitas) en lugar de respuestas abiertas y ambiguas. Los modelos más potentes deberían reservarse para decisiones estratégicas o planificación, mientras que los modelos más ligeros pueden ocuparse de ejecuciones repetitivas para no quemar recursos sin necesidad.

Por último, conviene establecer contratos claros entre agentes: quién hace qué, qué contexto ve, qué formato de resultados debe producir. Y, en todos los casos, mantener la revisión humana obligatoria antes de aceptar cambios críticos. Copilot y sus subagentes multiplican tu capacidad, pero no sustituyen la responsabilidad de las personas que firman el código.

Modelos de IA en Copilot, límites, retirada de modelos y aspectos de IP

Todo este sistema de agentes se apoya en una variedad de modelos de IA disponibles en GitHub Copilot, cada uno con puntos fuertes diferentes: algunos priorizan velocidad y coste, otros están optimizados para razonamiento profundo, otros admiten entradas multimodales (como imágenes junto con código), etc.

En función de tu plan de Copilot (Individual, Business, Enterprise…) y del entorno donde lo uses (GitHub.com, Visual Studio, VS Code, otros IDE compatibles), tendrás acceso a un subconjunto concreto de modelos. GitHub mantiene tablas actualizadas donde se enumeran los modelos disponibles, su estado de versión, las combinaciones válidas con selección automática de modelo y las posibles restricciones derivadas de políticas de residencia de datos o cumplimiento normativo como FedRAMP.

También existe un catálogo de modelos en retirada o ya retirados, con sus fechas correspondientes y las alternativas recomendadas. Del mismo modo, verás especificadas las versiones mínimas de extensiones o IDE necesarias para determinados modelos, información que puede cambiar según se despliegan nuevas capacidades. En general, mantener tanto el IDE como la extensión de Copilot en la última versión estable es la mejor garantía de compatibilidad.

Cada modelo tiene asociado un multiplicador de solicitudes premium que refleja su complejidad y consumo de recursos. Si estás en un plan de pago, tus límites de solicitudes premium se descuentan en función de ese multiplicador, por lo que es importante tenerlo en cuenta al definir qué modelos usará cada agente personalizado.

En cuanto a propiedad intelectual, Copilot se entrena con una gran colección de código accesible públicamente, incluyendo código bajo copyright. La legislación de muchos países (UE, Japón, Singapur y otros mediante figuras de uso legítimo) permite este tipo de uso para fines de aprendizaje automático. El modelo no “busca y copia” fragmentos, sino que genera sugerencias sintéticas a partir del contexto del usuario.

Aun así, en un pequeño porcentaje de casos las sugerencias pueden coincidir casi literalmente con trozos de código presentes en los datos de entrenamiento, especialmente cuando hay poco contexto en el editor o cuando se trata de patrones muy habituales. En esos escenarios, existe un riesgo potencial de conflicto deIP similar al de copiar código de Internet o reutilizar fragmentos de librerías de terceros, por lo que es prudente aplicar políticas de revisión, análisis de similitud y cumplimiento de licencias.

Copilot permite habilitar o deshabilitar las sugerencias que coinciden con código público de GitHub.com. Si las activas, la herramienta puede proporcionarte detalles sobre el código coincidente cuando aceptas esas sugerencias. La coincidencia por sí sola no implica infracción, pero eres tú (o tu organización) quien debe decidir si reutilizar ese código y cómo atribuirlo correctamente en cada caso.

Al final, el gran cambio que traen los subagentes y agentes personalizados en Visual Studio y VS Code es que Copilot deja de ser un generador de líneas sueltas para convertirse en un director que coordina cómo se escribe y mantiene el software. Entender esta arquitectura y adaptarla a los flujos de trabajo de tu equipo es lo que marcará la diferencia entre simplemente “usar Copilot” y aprovechar de verdad un sistema de desarrollo asistido por IA a nivel profesional.