Saltar al contenido
ES EN

Guía: evalúa el arnés de agentes de Copilot en Foundry antes de adoptarlo

Una guía práctica para valorar el arnés de agentes de GitHub Copilot en Microsoft Foundry y medir el coste de cambiar de plataforma más adelante.

IA para programar

Microsoft ha empezado a abrir a desarrolladores externos la infraestructura de orquestación que usa el agente de GitHub Copilot, a través de Microsoft Foundry. Lo anunció el miércoles en su blog y The New Stack lo analiza con un matiz importante: montar agentes resulta sencillo, pero cambiar de plataforma después puede no serlo.

Esta guía no es un tutorial de instalación, porque el material de partida no detalla comandos ni pasos concretos. Es un método para evaluar el arnés con criterio: qué preparar, qué probar y cómo medir cuánto te atará antes de comprometer un proyecto real.

Lo que necesitas

Necesitas acceso a una suscripción con Foundry, un caso de uso acotado (un agente que haga una sola tarea medible) y un repositorio donde guardes la lógica del agente separada de la plataforma. También conviene leer la documentación sobre cómo traer tus propios modelos mediante la pasarela de IA, porque ahí se juega buena parte de la portabilidad.

Si estás empezando con agentes, el recorrido de roadmap.sh para agentes de IA y el de ingeniero de IA ayudan a ordenar conceptos antes de elegir plataforma.

Esquema conceptual de un agente de IA conectado a un modelo y a varias herramientas mediante una capa de orquestación
El arnés es la capa que une modelo, herramientas y bucle del agente.
  1. Define un caso de uso pequeño y un criterio de éxito que puedas medir, por ejemplo tiempo de resolución o tasa de errores.
  2. Construye el agente con el arnés de Foundry y anota qué piezas aporta la plataforma y cuáles escribes tú.
  3. Repite la prueba con un modelo distinto, usando la opción de traer tus propios modelos, y compara resultados y esfuerzo.
  4. Documenta cada punto donde tu código depende de una API o formato propio de la plataforma.
  5. Estima cuántas horas costaría reproducir ese agente en otra herramienta y decide si el riesgo es aceptable.

Medir la dependencia, no solo el rendimiento

Lo habitual es evaluar un agente por su calidad de respuesta. Nosotros recomendamos añadir una segunda columna: el coste de salida. Anota qué configuración, herramientas y flujos solo existen dentro de la plataforma y cuáles podrías exportar tal cual. Esa lista es tu medida real de portabilidad.

Un buen hábito es aislar la lógica de negocio detrás de una interfaz propia, de modo que el arnés quede como una pieza sustituible. Un esquema orientativo de inventario podría ser este:

dependencia, tipo, sustituible, esfuerzo_estimado
orquestacion_del_agente, plataforma, no, alto
prompts_y_reglas, propio, si, bajo
herramientas_externas, mixto, parcial, medio
modelo, configurable, si, bajo

Cuanto más alto sea el peso de las filas «no», más caro será irse. No es un veredicto contra el arnés: es información para decidir con los ojos abiertos.

Truco Haz la prueba de salida el primer día, no el último: monta una versión mínima del mismo agente fuera de la plataforma y comprueba cuánto tardas. Si es una tarde, la dependencia es manejable; si es un mes, hay que replantear el diseño. Esto no es universal: depende de cuánta lógica propia pongas tú.

El contexto también cuenta. Microsoft empuja con fuerza su ecosistema de IA, y el crecimiento de usuarios de Copilot que recoge The Next Web explica el interés en consolidar a los desarrolladores. Conviene recordar además que los productos cambian: Microsoft retiró Azure Deployment Environments sin producto de reemplazo, un buen recordatorio de por qué conviene tener siempre una vía de escape.

Fuente original: thenewstack.io

Artículo generado mediante AI.larebelion

Kernel

· Dirección de tecnología · España

«Un arnés que te lo da todo hecho también decide cuánto te costará irte, y conviene calcularlo antes de instalarse.»

Comentarios