Los flujos de trabajo de los agentes son complicados. Cada proveedor tiene una forma distinta de almacenar habilidades, reglas, configuraciones de MCP, comandos, subagentes y hooks. Creemos que los agentes deberían ser una opción de herramientas, no una forma de quedar atado a un proveedor. Los entornos deben funcionar igual a nivel local y en la nube, ya uses GitHub Copilot, Claude Code o Gemini.

Agent Playground es nuestra plantilla de referencia para entornos de agentes portátiles. Estandariza la configuración, el acceso a las herramientas y la puesta en marcha para que puedas definirlo todo una sola vez y ejecutarlo de forma idéntica en cualquier lugar.

https://github.com/LN-Zap/agent-playground

Principios de diseño

Había algunos aspectos no negociables:

  • Portabilidad en lugar de dependencia - los ingenieros pueden usar la herramienta que mejor se adapte a su trabajo.
  • Una única fuente de verdad - las configuraciones se definen una sola vez.
  • Reproducibilidad - los entornos local, de CI y de nube son idénticos.

Si mañana aparece un nuevo entorno de ejecución de agentes, deberíamos poder añadirlo sin tener que reescribir todo lo demás.

Cómo funciona

1. Configuración centralizada con rulesync

rulesync nos permite almacenar habilidades, reglas, configuración de MCP, comandos, subagentes y hooks en un formato independiente del proveedor.

Una única configuración declara los destinos de agentes compatibles y las habilidades remotas que se deben incorporar.

{
  "targets": [ "copilot", "claudecode", "opencode" ],
  "features": [ "mcp", "rules", "skills", "subagents" ],
  "sources": [ {
    "source": "https://github.com/anthropics/skills",
    "skills": [ "skill-creator" ]
  } ]
}

Las salidas se regeneran de forma determinista a partir del código fuente.

.
├── rulesync.jsonc    # Config
├── rulesync.lock     # Lockfile
└── .rulesync/        # Canonical source
    ├── mcp.json      # Shared MCP
    ├── rules/        # Project rules
    └── skills/       # Pinned skills

2. Habilidades fijadas mediante archivos de bloqueo

Descargar código remoto no fijado supone un riesgo de seguridad. Incorporamos la compatibilidad con archivos de bloqueo a rulesync (enlace al PR) para fijar las instalaciones a hashes de commits específicos.

Un archivo rulesync.lock mantiene la reproducibilidad del entorno:

{
  "lockfileVersion": 1,
  "sources": {
    "anthropics/skills": {
      "requestedRef": "main",
      "resolvedRef": "1ed29a03dc85...",
      "resolvedAt": "2026-02-17T09:49:59.986Z",
      "skills": {
        "skill-creator": {
          "integrity": "sha256-e141..."
        }
      }
    }
  }
}

Cuando actualizamos una habilidad, el flujo de trabajo es deliberado:

  1. Ejecuta rulesync install --update para descargar el código y actualizar el archivo de bloqueo.
  2. Revisa las diferencias en el directorio fuente «curated» durante el proceso de PR.
  3. Haz la combinación solo después de examinar el código del repositorio upstream para detectar problemas de seguridad.

Esto hace que la cadena de suministro de los agentes sea tan auditable como el resto de nuestra pila tecnológica.

Cuando ejecutamos el sistema en entornos de nube, el flujo de trabajo es determinista:

  1. Ejecuta rulesync install --frozen para incorporar código revisado y bloqueado.
  2. El proceso se interrumpe si las fuentes difieren de los hashes del archivo de bloqueo.

Esto garantiza que no haya ninguna diferencia entre la validación local y la ejecución en la nube.

3. MCP unificado mediante rulesync

Mantenemos una configuración central del servidor MCP dentro del código fuente de rulesync. A continuación, rulesync sincroniza esta configuración con cada destino. Como el acceso a las herramientas se define una sola vez, los agentes conservan las mismas capacidades incluso cuando cambias de entorno de ejecución.

4. Reproducibilidad

Usamos devenv para garantizar que la cadena de herramientas sea idéntica en todos los entornos. npm install ejecuta una instalación de rulesync en modo bloqueado y regenera las salidas. La configuración se realiza automáticamente mediante direnv; basta con entrar en el repositorio para inicializar el entorno.

5. Agentes en la nube preconfigurados

Los pasos complejos para configurar el entorno pueden ser lentos y engorrosos de ejecutar para los agentes en la nube cada vez. Usamos devenv como única fuente de verdad para preconfigurar fácilmente imágenes de ejecución para el agente de programación GitHub Copilot (consulta devenv-actions).

La acción genera un contenedor Docker que el agente de programación GitHub Copilot utiliza como entorno. Al preconfigurar la imagen, conseguimos tiempos de inicio ultrarrápidos para el agente de programación en la nube y garantizamos que tenga exactamente el mismo entorno coherente que usamos localmente.

También usamos devenv para generar especificaciones de Dev Container y utilizarlas para generar imágenes preconstruidas. Esto nos permite usar el mismo entorno de programación completamente configurado en IDE basados en la nube, como GitHub Codespaces.

Agent Playground en Strike

Mantenemos un Agent Playground compartido que amplía la plantilla con nuestras propias habilidades, servidores MCP y agentes personalizados. Cada ingeniero puede obtener un entorno que incorpora nuestros patrones internos y se conecta a nuestra pila tecnológica.

Los ingenieros aportan sus propias claves de API y credenciales de OAuth. Los secretos se mantienen fuera de las máquinas compartidas y se ajustan a los permisos individuales. Los equipos de producto usan el mismo patrón en sus propios repositorios, lo que mantiene portátiles y reproducibles las capacidades de sus agentes.

Cabe señalar que Agent Playground es una colección de patrones, no un marco que deba adoptarse en su totalidad o rechazarse por completo. Aunque adoptar toda la infraestructura (rulesync, archivos de bloqueo, devenv) ofrece los mejores resultados, los equipos pueden incorporar estas prácticas gradualmente. Puedes empezar simplemente centralizando tus configuraciones de Agent Skills y MCP, y añadir entornos reproducibles más adelante.

Estándares o nada

Las herramientas para agentes cambian demasiado rápido como para quedar atrapados en una solución propietaria. Cada nuevo entorno de ejecución introduce un formato de configuración único y el coste de configurarlo manualmente. Esa fragmentación ralentiza a los ingenieros.

Defendemos estándares abiertos e independientes de los proveedores. Una convención compartida como AGENTS.md es mejor que un montón de archivos CLAUDE.md y GEMINI.md. Tu sistema de agentes debería ser más amplio que la herramienta que elijas.

Nuestro objetivo es tratar los entornos como elementos de primera clase: portátiles, reproducibles y agnósticos respecto a las herramientas. La portabilidad da sus frutos. Nos ayuda a mantenernos ágiles a medida que evoluciona el sector.

Únete a nosotros

En Strike desarrollamos este tipo de infraestructura todos los días y creemos que es importante. Si quieres profundizar en los sistemas de agentes, las herramientas para desarrolladores y las primitivas que hacen que la IA esté realmente lista para producción, echa un vistazo a nuestros puestos disponibles.

Postúlate aquí: https://job-boards.greenhouse.io/strike