Microsoft APM: gestor de paquetes para habilidades

Tu configuración de agente vive en seis lugares y ninguno coincide. Una persona guarda habilidades en una carpeta para Claude Code. Otra guarda instrucciones dentro de Copilot. Los servidores MCP, los programas que dan a un agente acceso a herramientas y datos externos, están en un archivo de configuración que alguien editó a mano y nunca compartió. Un compañero nuevo clona el repositorio y obtiene el código, pero no la configuración de agente que hace que el código sea fácil de trabajar.

Microsoft APM existe para cerrar esa brecha. APM significa Agent Package Manager. Trata el contexto del agente como npm trata las bibliotecas de código. Declaras qué necesita un proyecto en un archivo de manifiesto. Cualquiera que clone el proyecto ejecuta un comando de instalación y cada pieza aterriza en la carpeta correcta para la herramienta de agente que usa.

Un manifiesto, muchos escritorios: APM despliega las mismas piezas declaradas en las carpetas que lee cada herramienta de agente. Ilustración: Dirty Static

El problema es la deriva, no el talento

Las herramientas de agentes se multiplicaron más rápido que los hábitos para compartirlas. Una habilidad es una carpeta con un archivo SKILL.md que enseña a un agente una tarea. Una instrucción es un flujo de trabajo guardado. Un archivo de instrucciones guarda las reglas para un repositorio. Cada herramienta lee estas piezas desde su propia carpeta, en su propio formato, y la mayoría de los equipos tiene más de una herramienta en juego.

Copiar archivos a mano funciona durante una semana. Luego una copia cambia y las demás no. Dos personas piden al mismo agente el mismo trabajo y obtienen un comportamiento diferente, porque sus configuraciones se separaron en silencio. APM convierte la configuración en una dependencia declarada en su lugar, con la misma disciplina que los equipos ya aceptan para el código: un manifiesto, un archivo de bloqueo y una revisión cuando cualquiera de los dos cambia.

Esta es la misma pregunta de suministro que nuestro análisis de PlugVet planteó desde el otro lado. PlugVet califica habilidades y servidores antes de que confíes en ellos. APM trata de qué pasa después de esa elección, cuando un equipo necesita que las piezas elegidas se instalen de la misma manera, en cada computadora, para cada herramienta.

Un manifiesto, tres archivos que importan

El manifiesto es apm.yml. Está en la raíz de un repositorio, como package.json, y nombra el proyecto y lista dos tipos de dependencia: paquetes APM bajo dependencies.apm y servidores MCP bajo dependencies.mcp. Un paquete puede ser una sola habilidad, un solo archivo de agente, un complemento o un paquete completo que lleva varias piezas a la vez. Los fijados de versión viajan en la cadena de dependencia, para que un equipo pueda mantener una habilidad en una versión fija mientras el resto se mueve.

Ejecutar apm install hace el resto. Resuelve el conjunto completo de dependencias, incluidas piezas de las que dependen otras piezas. Trae cada una a una carpeta local de caché, averigua qué herramientas de agente usa el proyecto y escribe cada pieza en la carpeta que esa herramienta lee. También escribe el archivo de bloqueo.

La prueba del clon es toda la propuesta en una línea. Según la guía rápida, un compañero clona un repositorio, ejecuta apm install en la raíz y obtiene las mismas piezas, en las mismas versiones, con los mismos hashes de contenido. Las carpetas desplegadas para cada herramienta también se confirman, para que la configuración permanezca visible en la revisión, no escondida en una caché.

Qué gestiona APM

Microsoft llama a cada unidad de contexto de agente una primitiva. Vale la pena conservar la palabra, porque APM gestiona ocho tipos de ellas y un paquete puede llevar cualquier mezcla.

Instructions son estándares y pautas de codificación, con alcance a archivos por un patrón. Prompts son flujos de trabajo guardados que un agente puede ejecutar. Agents son personas especialistas con su propio alcance y límites de herramientas. Skills son guías de tareas en el formato SKILL.md. Hooks son scripts que se ejecutan en puntos establecidos de una sesión, como antes o después de una llamada de herramienta. Commands son los archivos de instrucción en la forma que esperan las herramientas con una paleta de comandos. Plugins son paquetes que APM desempaqueta en las piezas anteriores en el momento de la instalación. MCP servers se declaran en el propio manifiesto y APM escribe la configuración MCP para cada herramienta cuando instala.

Dos comandos están junto a instalar. apm compile pliega instrucciones en los archivos de contexto compartidos que las herramientas leen, como AGENTS.md y CLAUDE.md, y puede colocar un archivo enfocado junto a cada carpeta en lugar de un archivo grande en la raíz. apm run ejecuta scripts con nombre declarados en el manifiesto, al estilo de los scripts de npm. Cada script llama a un comando de tiempo de ejecución que ya tienes instalado, como copilot o claude. APM no incluye esos tiempos de ejecución. Invoca el que tu script nombra.

Nueve objetivos principales y el soporte no es igual

Un objetivo es una herramienta de agente a la que APM puede desplegar. La lista principal llega a nueve: GitHub Copilot, Claude Code, Grok Build, Cursor, OpenCode, Codex, Gemini, Windsurf y Kiro. Tres más, Antigravity, Hermes y Grok Bot, pueden nombrarse a propósito pero nunca se eligen por detección. APM encuentra objetivos de tres maneras, en orden: una bandera en el comando, una lista targets: en el manifiesto o las carpetas ya presentes en un repositorio, como .claude/ o .cursor/. Sin ninguna señal, la instalación se detiene con un error en lugar de adivinar.

Un centro, nueve puertas: cada objetivo todavía decide qué piezas puede aceptar. Ilustración: Dirty Static

Lee la tabla como una herramienta de planificación, no como una lista de defectos. Un equipo que vive de instrucciones dentro de Copilot obtiene valor completo el primer día. Un equipo repartido entre Codex y Gemini debería construir su configuración compartida en torno a habilidades y servidores MCP, las piezas que viajan a todas partes, y mantener extras específicos de herramienta en carpetas específicas de herramienta. Nuestro perfil de WordPress Studio mostró la misma forma desde dentro de una aplicación: el arnés decide qué puede alcanzar un agente externo y las herramientas honestas lo dicen en una tabla.

Seguridad y políticas, dichas con claridad

Instalar piezas de agente significa instalar prosa que dirige a un agente y, en el caso de los servidores MCP, código que un agente puede llamar. APM trata eso como un riesgo de suministro por defecto. Según la documentación, cada instalación escanea contenido en busca de Unicode oculto, fija hashes de contenido en el archivo de bloqueo y bloquea servidores MCP que llegan solo como dependencia de una dependencia, a menos que esos servidores estén declarados en tu propio manifiesto o se confíe en ellos a propósito.

El archivo de políticas agrega control organizacional. apm-policy.yml se hace cumplir cuando se ejecutan instalaciones y cubre los servidores MCP transitivos además de los directos. La política fluye del nivel empresarial al nivel organizacional al nivel de repositorio y cada nivel solo puede ajustar lo que el nivel superior permitió. La documentación dirige a las organizaciones a apm audit --ci para bloquear compilaciones con las mismas reglas.

Cómo ponerlo en una computadora

La CLI funciona en macOS, Linux y Windows. Homebrew es el camino corto en una Mac. La documentación también lista un instalador de shell para Linux y macOS, un instalador de PowerShell para Windows e instalaciones con Scoop, pip y archivo manual para equipos que los necesitan.

brew install apm
apm init my-agent
apm install microsoft/apm-sample-package

El paquete de ejemplo en la última línea es el propio paquete inicial de Microsoft. Es la manera más rápida de ver la forma de una instalación real: instrucciones, agentes, indicaciones y una habilidad aterrizando en las carpetas correctas, con el archivo de bloqueo escrito junto al manifiesto. Desde ahí, agregar una pieza es una línea en apm.yml o un comando de instalación que nombra un repositorio y una ruta dentro de él.

Precios y plataformas

APM no cuesta nada. La CLI y el formato de manifiesto son de código abierto bajo la organización microsoft en GitHub, bajo la licencia MIT. No hay tarifa de registro alojado ni cargo por puesto en la documentación, porque no hay registro alojado en absoluto en el sentido de npm. Una cadena de dependencia nombra un repositorio git, en GitHub u otro host git, y APM lo trae desde ahí con tu propio acceso git. Los equipos pagan solo por las herramientas de agente y los modelos que ya usan.

Aquí importa una nota de estado. La documentación describe el contrato del manifiesto como un borrador de trabajo y la página del esquema del manifiesto lleva la misma etiqueta. La forma en uso hoy está documentada en detalle, pero un borrador todavía puede cambiar. Fija tu versión de APM en la documentación del equipo, lee el registro de cambios cuando actualices y deja que el archivo de bloqueo haga su trabajo entre actualizaciones.

Cuál deberías elegir

Adopta APM ahora si tu equipo comparte la configuración de agente por folclore. Si las habilidades viven en mensajes de chat, las instrucciones viven en una laptop y las configuraciones MCP difieren por persona, APM reemplaza esa deriva con un archivo que un equipo puede revisar. Empieza con habilidades y uno o dos servidores MCP, las piezas con el soporte más amplio, y agrega el resto según lo permitan tus herramientas.

Adóptalo si ejecutas más de una herramienta de agente. Un desarrollador solo que cambia entre Claude Code y Cursor para trabajos diferentes obtiene la misma ganancia a menor escala. Una declaración, dos despliegues y sin sincronización manual cuando una habilidad mejora. Se combina bien con un hábito de verificación: califica una pieza nueva con un directorio como el de nuestro perfil de PlugVet antes de que gane una línea en el manifiesto.

Espera si usas una herramienta, solo, con una configuración que nunca cambia. APM resuelve un problema de compartir y deriva. Una configuración única y estable tiene poca deriva que resolver y el manifiesto es un archivo más que atender. Lo mismo aplica a equipos que necesitan control en tiempo de ejecución como su salvaguarda principal. APM los ayudará a gobernar instalaciones y todavía necesitarán los controles dentro de sus herramientas de agente para el resto.

Reflexiones finales

APM es poco glamoroso en el mejor sentido. No promete un modelo más inteligente ni un agente más rápido. Promete que la configuración de agente que un equipo acordó es la configuración que cada persona ejecuta en realidad, en cada herramienta, después de cada clon. Esa promesa necesitaba un manifiesto, un archivo de bloqueo y una puerta de políticas y Microsoft construyó los tres sobre estándares abiertos que nombra en la documentación: AGENTS.md, Agent Skills y MCP. La etiqueta de borrador en el formato es la única advertencia real. Adóptalo por la deriva que elimina hoy, fíjalo como si lo dijeras en serio y mantén tus controles de tiempo de ejecución donde pertenecen, en las propias herramientas.

Fuentes

• Qué es APM, el ejemplo de manifiesto, rutas de instalación, valores predeterminados de seguridad y políticas, licencia: APM home, Microsoft
• El flujo del consumidor, apm init, la instalación de ejemplo, el archivo de bloqueo y qué confirmar: Quickstart, Microsoft
• Las ocho primitivas, el catálogo de objetivos, la colocación de compilación y el orden de selección de objetivos: Primitives and targets, Microsoft
• Soporte por objetivo para cada pieza, carpetas de despliegue y señales de detección: Targets matrix, Microsoft
• Scripts de ejecución y la regla de que APM invoca tiempos de ejecución que no incluye: Run scripts, Microsoft
• Ilustraciones principal y del cuerpo: Dirty Static