Image for post VS Code 1.109: Agent Skills GA, MCP Apps y Multi-Agente

VS Code 1.109: Agent Skills GA, MCP Apps y Multi-Agente

Escrito por Sergio Márquez

VS Code 1.109 (enero 2026) es la primera versión que Microsoft define explícitamente como plataforma de desarrollo multi-agente. Agent Skills pasa a disponibilidad general, MCP Apps llega antes que a ningún otro editor, y Claude Agent se integra de forma oficial junto a Copilot y Codex. Esta entrada explica qué cambia en la práctica y cómo configurar el stack desde cero.

De editor a orquestador de agentes

Si usas VS Code con agentes de IA desde hace meses, la experiencia hasta ahora era fragmentada: Copilot en el panel de chat, Claude Code en un terminal externo y Gemini CLI en otra ventana. El problema no era de capacidad sino de contexto: cada agente vivía en su silo sin visibilidad sobre el estado del resto.

En VS Code Agent Mode cubrimos el setup inicial con Claude, Codex y Gemini. La versión 1.109 formaliza ese setup con tres cambios estructurales: Agent Skills en GA, MCP Apps como extensión de protocolo y una vista unificada para gestionar sesiones locales, en background y en la nube desde el mismo panel.

Agente Tipo de sesión MCP client Skills Coste base
GitHub Copilot Local / cloud Sí (v1.109) .github/skills/ ~10 €/mes
Claude Agent Local / background / cloud Sí .claude/skills/ Incluido en Copilot Business/Pro+ o por tokens
Codex Local / cloud Sí Via workspace instructions Incluido en Copilot Business/Pro+
Gemini CLI Terminal local Sí (client + server) Via MCP / prompts Tier gratuito disponible

¿Qué son Agent Skills y por qué están en GA ahora?

Agent Skills es un estándar abierto para empaquetar conocimiento especializado en carpetas reutilizables que cualquier agente compatible puede cargar automáticamente. No es un concepto exclusivo de Copilot: la especificación la puede implementar cualquier agente, y VS Code busca skills en varias rutas por diseño.

La estructura es deliberadamente simple. Cada skill es una carpeta con un fichero SKILL.md que contiene instrucciones probadas para un dominio concreto: estrategias de testing, diseño de APIs, optimización de rendimiento. El agente carga el skill cuando detecta que la tarea es relevante para ese dominio.

VS Code busca skills en cuatro ubicaciones:

  • .github/skills/ — skills del repositorio para Copilot
  • .claude/skills/ — skills del repositorio para Claude Agent
  • ~/.copilot/skills/ — skills globales del usuario para Copilot
  • ~/.claude/skills/ — skills globales del usuario para Claude

El punto que más importa aquí: .github/skills/ y .claude/skills/ coexisten en el mismo repositorio. Un skill bien escrito puede estar disponible para ambos agentes porque el estándar es el mismo, solo cambia la ruta de búsqueda.

Si ya trabajas con skills en Claude Code, la transición al formato de VS Code es directa. La diferencia principal es que ahora el editor gestiona el ciclo de vida del skill, no el agente individual.

# Estructura de skills en el repositorio
.claude/skills/
  api-review/
    SKILL.md     # instrucciones para revisión de API
    examples/    # opcional: ejemplos de uso

.github/skills/
  api-review/
    SKILL.md     # mismo dominio, mismo estándar
---
name: api-review
description: Revisa endpoints REST siguiendo las convenciones del proyecto
version: 1.0
---

## Cuándo aplicar este skill

Cuando el usuario pida revisar, crear o modificar endpoints de la API.

## Convenciones del proyecto

- Rutas en kebab-case: /user-sessions, no /userSessions
- Respuestas siempre con envelope: { data, error, meta }
- Códigos HTTP estándar: 200, 201, 400, 401, 403, 404, 422, 500

## Checklist de revisión

- [ ] Ruta sigue la convención de nomenclatura
- [ ] Respuesta usa el envelope estándar
- [ ] Tests unitarios y de integración incluidos

Para crear un skill desde VS Code: ejecuta Chat: New Skill File desde la paleta de comandos. Para ver todos los skills que detecta el editor en el workspace actual: Chat: Configure Skills. El campo name en el frontmatter debe coincidir exactamente con el nombre del directorio, o el skill no se carga.

MCP Apps: VS Code como primer editor con UI interactiva en el chat

MCP Apps es la primera extensión oficial del Model Context Protocol. Permite que las herramientas de un servidor MCP devuelvan componentes de interfaz de usuario que se renderizan directamente en el panel de chat, en lugar de solo texto o JSON. VS Code 1.109 es el primer editor en implementar esto.

En la práctica, un agente puede responder con un dashboard interactivo, un formulario, una visualización de datos o una lista de tareas con checkboxes directamente en la conversación. Un caso concreto: un servidor MCP de feature flags que en lugar de devolver una lista plana renderiza una tabla con estado en tiempo real donde activas o desactivas flags con un clic desde la respuesta del agente.

Para la configuración MCP en el workspace, el fichero es .vscode/mcp.json:

// .vscode/mcp.json
{
  "servers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "@modelcontextprotocol/server-filesystem",
        "${workspaceFolder}"
      ]
    },
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${env:GITHUB_TOKEN}"
      }
    },
    "memory": {
      "type": "stdio",
      "command": "npx",
      "args": ["@modelcontextprotocol/server-memory"]
    }
  }
}

VS Code gestiona el ciclo de vida de estos servidores mientras el editor está abierto. Cualquier agente compatible que se ejecute en ese workspace puede consumir las herramientas expuestas sin configuración adicional por su parte. Esto conecta directamente con la filosofía detrás del uso eficiente de herramientas MCP para reducir tokens: cuando el servidor ya está activo, el agente no paga el coste de inicialización en cada sesión.

Gemini CLI como tercer actor en el terminal integrado

Gemini CLI opera desde el terminal integrado de VS Code y tiene soporte nativo para MCP tanto como cliente como servidor. Esto lo convierte en un participante natural del hub: ejecuta desde el terminal integrado y accede al mismo contexto del workspace que Copilot y Claude Agent.

La configuración de servidores MCP en Gemini CLI usa .gemini/settings.json para el proyecto o ~/.gemini/settings.json para configuración global. El formato difiere de .vscode/mcp.json, pero apunta a los mismos servidores:

// .gemini/settings.json (configuración del proyecto)
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "@modelcontextprotocol/server-filesystem",
        "."
      ]
    },
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "$GITHUB_TOKEN"
      }
    },
    "memory": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-memory"]
    }
  }
}
# Verificar estado de conexión desde Gemini CLI
gemini /mcp

# Salida esperada:
# ✓ filesystem — connected (6 tools)
# ✓ github     — connected (12 tools)
# ✓ memory     — connected (4 tools)
# Total: 22 tools available

Con este setup, Gemini CLI y VS Code Agent Mode comparten el mismo servidor memory. Cuando Copilot o Claude Agent escriben contexto en memoria durante la sesión, Gemini CLI lo lee desde el terminal sin configuración adicional. El estado es compartido de forma natural.

Un detalle sobre conflictos de nombres: si dos servidores exponen herramientas con el mismo nombre, el primero en registrarse obtiene el nombre sin prefijo, y los siguientes reciben el prefijo del servidor en formato serverName__toolName. Cuando configures los mismos servidores en VS Code y en Gemini CLI, mantén el mismo orden para que los prefijos sean consistentes entre sesiones.

Sesiones locales, en background y en la nube

La Agent Sessions view de VS Code 1.109 es el panel de control del hub. Desde un único lugar gestionas tres tipos de sesión:

  • Locales: respuesta inmediata e interactiva. Copilot y Claude Agent en modo local encajan aquí para pair programming o revisión de código.
  • Background: agentes que corren en Git worktrees aislados, de forma no interactiva. Son ideales para tareas bien definidas como implementar un plan ya especificado, ejecutar la suite de tests completa o refactorizar un módulo sin tocar tu rama activa.
  • Cloud: agentes remotos sin interacción directa, diseñados para tareas de mayor alcance con integración directa con pull requests. Disponibles a día de hoy para suscripciones Copilot Business y Pro+.

La clave de este modelo es que los tres tipos aparecen en la misma vista de sesiones. Puedes delegar una tarea a un agente background mientras sigues trabajando con Copilot en local, y comparar los resultados desde el mismo panel cuando el agente termina. En revisión cruzada entre agentes vimos cómo coordinar este tipo de flujos mediante prompts; con la vista de sesiones, la coordinación tiene ahora soporte nativo en el editor.

Los agentes background usan Git worktrees para aislar su trabajo. Esto previene conflictos con la rama activa y permite inspeccionar los cambios antes de integrarlos. Para flujos spec-driven, el agente background puede implementar una especificación completa en su worktree mientras el agente local continúa con otra tarea en paralelo.

En Producción

Consumo de tokens con Agent Skills: Un skill bien escrito reduce el token overhead porque el agente carga solo el contexto relevante para la tarea, no el histórico completo del proyecto. Un skill de 150-200 líneas puede reemplazar 2-4k tokens de instrucciones manuales en el primer turno. Si ya monitorizas el consumo con control de tokens en tiempo real, notarás la diferencia desde la primera sesión con skills activos.

Servidores MCP y carga del sistema: Cada servidor MCP corre como proceso stdio en tu máquina. Con tres agentes activos consultando el servidor filesystem en un proyecto grande, la latencia puede ser perceptible. El servidor memory es el cuello de botella más frecuente en setups multi-agente porque todos escriben en él. Una solución práctica es mantener el servidor memory como proceso persistente en lugar de iniciarlo por demanda.

Coste a marzo 2026: Copilot Individual cuesta 10 €/mes. Claude y Codex como cloud agents están incluidos en Copilot Business (19 €/usuario/mes) y Pro+ desde el 26 de febrero de 2026. Gemini CLI tiene un tier gratuito suficiente para exploración diaria. Para uso intensivo de todos simultáneamente en local, calcula entre 20-40 €/mes contando el consumo de tokens de Claude en tareas largas.

Secretos en mcp.json: El fichero .vscode/mcp.json puede contener referencias a variables de entorno sensibles. Si el repositorio es compartido, añade .vscode/mcp.json al .gitignore y distribuye un .vscode/mcp.json.example sin valores reales. Gemini CLI aplica sanitización automática de variables sensibles cuando pasa el entorno a servidores MCP externos; VS Code no lo hace por defecto, así que la gestión de secretos recae sobre ti.

Aislamiento de agentes background: Los agentes en modo background trabajan en Git worktrees separados, lo que previene conflictos con la rama activa. Antes de integrar los cambios, revisa el diff con git diff main...worktree-branch. No des por asumido que el agente terminó correctamente solo porque la sesión aparece como completada en la vista: verifica el output.

Errores comunes en el setup del hub

Error: Agent Skills no se carga aunque exista la carpeta .claude/skills/.
Causa: El fichero SKILL.md no tiene el campo name en el frontmatter, o el valor no coincide con el nombre del directorio.
Solución: Verifica que el frontmatter incluya exactamente name: nombre-del-directorio. Usa Chat: Configure Skills en la paleta de comandos para depurar qué skills detecta VS Code en el workspace actual.

Error: Gemini CLI no encuentra las herramientas MCP configuradas en .vscode/mcp.json.
Causa: VS Code y Gemini CLI tienen ficheros de configuración MCP independientes. No hay sincronización automática entre ellos.
Solución: Replica la configuración en .gemini/settings.json. Ejecuta gemini /mcp para confirmar qué servidores están conectados antes de iniciar la sesión de trabajo.

Error: Claude Agent y Copilot generan cambios conflictivos en el mismo fichero durante una sesión paralela.
Causa: Dos agentes activos sin coordinación pueden sobrescribirse mutuamente en tareas solapadas.
Solución: Asigna responsabilidades por módulo o tipo de tarea. Usa el servidor memory para registrar qué ficheros están siendo modificados en cada momento y por qué agente. Los agentes background usan worktrees aislados por diseño, así que reserva ese modo para tareas que requieran aislamiento completo.

Preguntas frecuentes

¿Agent Skills funciona con Claude Code fuera de VS Code?

Sí. Claude Code busca skills en ~/.claude/skills/ y .claude/skills/ independientemente de si corre dentro o fuera de VS Code. El estándar lo define Anthropic, no Microsoft. Los skills que crees para Claude Code son directamente compatibles con Claude Agent en VS Code sin ningún cambio de formato.

¿MCP Apps requiere cambios en mis servidores MCP existentes?

Solo si quieres devolver UI interactiva. Los servidores MCP estándar que devuelven texto o JSON funcionan sin modificaciones. MCP Apps es una extensión aditiva del protocolo: si el servidor no la implementa, el agente recibe el resultado como texto plano igual que antes. No es un breaking change.

¿Claude Agent en VS Code es lo mismo que Claude Code en el terminal?

No exactamente. Claude Agent en VS Code usa el Claude Agent SDK de Anthropic con el harness oficial, incluyendo sus propias herramientas y arquitectura de prompts. Claude Code es una CLI independiente con su propio ciclo de vida. Ambos pueden coexistir en el mismo workspace, y ambos leen de los mismos servidores MCP si los configuras en las rutas correspondientes.

La inversión en estándares abiertos tiene retorno

Lo más relevante de VS Code 1.109 no es ninguna feature individual: es que MCP y Agent Skills se consolidan como capa de interoperabilidad que agentes de distintos proveedores implementan de forma independiente. La inversión en configurar tu workspace con servidores MCP y skills bien definidos hoy es portable: si cambias de modelo o proveedor mañana, la infraestructura del hub permanece.

Un editor que gestiona el ciclo de vida de los servidores MCP, que busca skills en rutas compartidas entre Copilot y Claude, y que unifica sesiones locales, en background y en la nube desde un panel, es infraestructura real, no solo tooling. Es la diferencia entre tener tres agentes distintos y tener un equipo coordinado.

¿Tienes ya skills definidos en tu repositorio o sigues usando instrucciones en el prompt directamente? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. La próxima entrada analiza cuándo compensa el hardware self-hosted para agentes locales frente a seguir pagando por APIs en la nube.

Volver al blog