Skip to main content

MKA1 Code

Use la aplicación de escritorio, la extensión de VS Code o la CLI para trabajar en un proyecto con un agente de programación. La guía explica cómo ejecutar una tarea, revisar los cambios y crear un commit.
QUÉ DEBE TENER A MANO
  1. Un enlace de invitación al clúster enviado por el administrador de su clúster. Le convierte en propietario de una organización completamente nueva.
  2. Esta guía todo lo que necesita para pasar de ese enlace a una integración funcional.
Enlaces rápidos

Bienvenido a MKA1

MKA1 es una plataforma para crear aplicaciones de IA. Ofrece a su equipo una única puerta de enlace a grandes modelos de lenguaje además de los bloques de construcción de alto nivel que los productos reales necesitan: agentes, conversaciones almacenadas, memoria a largo plazo, recuperación de documentos (RAG), herramientas y servidores MCP, prompts, habilidades, guardrails, voz y evaluaciones. Usted trabaja con MKA1 a través de dos superficies que comparten las mismas cuentas, equipos y recursos:
  • La Consola - un panel web para crear e inspeccionar todo manualmente: ejecutar prompts en el Playground, guardar agentes, indexar archivos, generar claves API, gestionar su organización y sus equipos. La consola vive en la dirección de su clúster (por ejemplo platform.mka1.com).
  • La API y los SDK - las mismas capacidades sobre HTTPS, llamadas desde su propio código mediante el SDK de TypeScript, Python o C#, la CLI mka1 o curl a secas. Así es como su aplicación habla con MKA1 en producción.
Esta guía recorre todo el camino en orden. Los pasos 1–7 le llevan desde el enlace de invitación hasta su primera solicitud exitosa; las secciones posteriores recorren cada bloque de construcción, la mayoría con ejemplos listos para copiar y pegar.

Antes de empezar

Solo necesita dos cosas para comenzar, y ya tiene ambas:
  1. Un enlace de invitación al clúster. Su administrador creó una invitación en el clúster y le envió el enlace. Al abrirlo, se convierte en propietario de una nueva organización dentro de ese clúster.
  2. Esta guía. Le lleva desde la invitación hasta una integración funcional con el SDK.
No hay nada que instalar de antemano. La consola se ejecuta en su navegador, y solo instala un SDK cuando esté listo para escribir código. El camino siguiente toma unos 15 minutos:
Configuración en 15 minutos
  • Paso 1 Acepte su invitación al clúster y cree su organización.
  • Paso 2 Oriéntese en la consola.
  • Paso 3 Invite a compañeros y añada equipos si desea dividir el acceso.
  • Paso 4 Cree una clave API.
  • Paso 5 Instale un SDK.
  • Paso 6 Autentique sus solicitudes.
  • Paso 7 Realice su primera solicitud.
El asistente de configuración en el que aterriza tras el Paso 1 ofrece los Pasos 3, 4 y 7 integrados. Omita cualquiera de ellos ahí y hágalo a mano más abajo.

Paso 1 · Acepte su invitación al clúster

Abra el enlace de invitación al clúster que le envió su administrador. Lleva un token de un solo uso y le deja en la página Set up your organization. Una invitación al clúster es una invitación de propietario - al aceptarla se crea una nueva organización y usted queda como propietario. Su administrador también puede haber preconfigurado una cuota de solicitudes y habilitado Compute en la invitación, de modo que la nueva organización arranca con ambos ya configurados.

Haga esto

  1. Abra el enlace de invitación. La página valida el token y muestra una insignia de Owner invite (y una fecha de caducidad, si se configuró una). Si dice que la invitación no está disponible, el token de invitación ha caducado o ha sido revocado. Pida a su administrador un enlace nuevo.
  2. Nombre su organización. Escriba un nombre como Acme Inc y suba un logo si tiene uno (PNG, JPEG, WebP, GIF o SVG, de hasta 5 MB). Se genera automáticamente un slug de URL del espacio de trabajo (p. ej. acme-inc); expanda Customize si desea editarlo. Un slug tiene de 1 a 64 caracteres: minúsculas, números y guiones. Si un slug está reservado o ya ocupado, el servidor lo rechaza y usted elige otro.
  3. Elija cómo iniciar sesión. Cree una cuenta con correo y contraseña, o continúe con Google. Si la invitación estaba vinculada a su dirección de correo, esa dirección aparece precargada y bloqueada.
  4. Verifique su correo. Si se registró con contraseña, MKA1 le envía un correo de verificación. Haga clic en el enlace para confirmar; después entra directamente en su nueva organización.
  5. Recorra el asistente de configuración. Aterriza en un breve asistente de configuración, no en el panel principal. Sus pasos van en este orden: Enable your models (se ejecuta automáticamente), Invite your team, Create teams, Create your first API key, Create your first response y You’re all set. Todos los pasos salvo el último tienen un botón Skip for now, y cada página enlaza de vuelta a esta guía. El paso de modelos se explica en Habilite sus modelos, más abajo. El Paso 3 cubre invitaciones y equipos, el Paso 4 la clave API y el Paso 7 la primera respuesta. La clave del asistente se crea con el preajuste Standard y sin límite de tasa. Cuando termina, aterriza en la consola como propietario de su organización.
Ahora usted es el propietario de la organizaciónEl propietario tiene control total. Uso, miembros, equipos y configuración. Todos los demás que incorpore serán administradores o miembros (se cubre en el Paso 3). Si ya había iniciado sesión en MKA1 con un correo distinto al de la invitación, cierre sesión primero: las invitaciones están vinculadas a una dirección específica.

Habilite sus modelos

Su clúster mantiene un catálogo de modelos, y cada organización tiene su propio registro. Un administrador del clúster concede a su organización acceso a los modelos del catálogo, ya sea en el selector Model access de la invitación o más tarde en Access → Organizations → Cluster, en la pestaña Available models de su organización, pero el acceso por sí solo no hace nada. Debe activar un modelo en el registro de su organización antes de que cualquier solicitud pueda resolverlo, y eso incluye model: "auto"; la puerta de enlace nunca activa un modelo por su cuenta. El primer paso del asistente activa todos los modelos disponibles del clúster a los que tiene acceso, siempre que nada en su registro esté activo todavía. Si omitió ese paso, o el administrador del clúster añade modelos más tarde, vaya a Admin → Model Registry → Models y haga clic en Activate. Cada entrada muestra available, active o nombre en uso (available_name_blocked en la API). Nombre en uso significa que otra entrada ya ocupa ese id, así que desactive esa entrada primero. Puede hacer lo mismo por la API: liste el catálogo con mka1.llm.models.listCatalog() y active una entrada con mka1.llm.models.activateRegistryEntry({ modelId, source: 'cluster' }) (en Python, sdk.llm.models.list_catalog() y sdk.llm.models.activate_registry_entry(model_id=..., source="cluster")). La guía Gestionar modelos cubre el catálogo, los estados de activación y a qué resuelve auto.

Paso 2 · Recorra la consola

Tómese un minuto para orientarse. La barra lateral izquierda agrupa cada superficie en Access, LLM, Agents y Admin. Settings, con sus pestañas Account y Preferences, vive en el menú de usuario al pie de la barra lateral y no en un grupo. Los propietarios y administradores ven todas las secciones de forma predeterminada. Los miembros ven una barra lateral recortada (API Keys, Usage y Playground) y pueden activar más secciones en Settings → Preferences. Esto es para qué sirve cada sección. Usará varias de ellas en los pasos siguientes. Configuración de organizaciones en la consola de MKA1

Access

LLM

Agents

Admin

Paso 3 · Invite a su equipo y organice el acceso

Página de detalle de equipo en Access → Teams El acceso a MKA1 se organiza como una jerarquía simple: organización → equipos → miembros, con roles que controlan lo que cada persona puede hacer y cuentas de servicio que representan a los llamadores no humanos.

La organización y su propietario

Cuando acepta la invitación al clúster, se convierte en propietario de su organización. El propietario tiene control total: métricas de uso, miembros, equipos y configuración. Todos los demás que incorpore son administradores o miembros:

Equipos

Cada organización empieza con un equipo Default, y las personas que invita desde la consola se unen a él automáticamente. Puede añadir más equipos, y los miembros pertenecen a uno o más de ellos. Los equipos son donde vive la mayor parte del trabajo y del acceso: las claves API y los agentes están limitados a un solo equipo, mientras que los repositorios y Compute pertenecen a la organización. Una clave generada en un equipo concede acceso únicamente a los recursos de ese equipo. Sacar a alguien (o a una cuenta de servicio) de un equipo revoca el acceso que venía con él, y las claves ligadas a ese equipo dejan de funcionar. Esto convierte a los equipos en la frontera natural para separar proyectos, entornos o unidades de negocio. Gestiónelos en Access → Teams, donde puede crear un equipo y gestionar su lista plana de miembros.

Invitar a compañeros

Diálogo de invitar personas con selección de rol y equipos Para añadir a una persona, envíele una invitación a la organización por correo. Puede hacerlo navegando a Access → Organizations y haciendo clic en Invite people en la esquina superior derecha. Comparta el enlace generado que abre la página Accept invite, que muestra la organización, quién le invitó, el rol que recibirá y cuándo caduca la invitación. Lo que hacen para aceptar depende de su estado:
  • Sin cuenta todavía (Este es el escenario más probable) - se registran (correo/contraseña o Google) con el correo invitado, lo verifican y vuelven a la invitación para terminar de unirse.
  • Ya con sesión iniciada con el correo invitado - un clic en Accept & join los añade a la organización.
  • Con sesión iniciada con otro correo - se les pide cambiar primero a la cuenta invitada, ya que las invitaciones están vinculadas a una dirección específica.
Las invitaciones pueden caducar o ser revocadas, así que envíe un enlace nuevo si alguien informa de uno muerto.

Cuentas de servicio para producción

Para sistemas de producción, ejecutores de CI, servicios backend y trabajos programados, use una cuenta de servicio en lugar de las credenciales de una persona. Una cuenta de servicio es una identidad máquina no humana que usted adjunta a uno o más equipos, y para la que genera claves API. Puede crear una navegando a Access → Service accounts y haciendo clic en New service account en la esquina superior derecha. Como las claves heredan el alcance del equipo, separar una cuenta de servicio de un equipo (o eliminarla) detiene inmediatamente todas las claves generadas para ella en ese equipo, dándole un interruptor de apagado limpio para las credenciales de producción.

Paso 4 · Cree una clave API

Formulario de nueva clave API con pasos de identidad, vinculación de alcance y permisos Una clave API es la credencial que su código envía en cada solicitud. En la consola, abra Access → API Keys y haga clic en Create API key. El formulario recorre cuatro pasos.

1 · Identidad

Nombre la clave (p. ej. Production gateway) y elija el principal como el que actúa: My user (usa su rol de org y el equipo seleccionado) o una Service account (una identidad no humana dedicada. Las cuentas de servicio se recomiendan para casos de uso en producción).

2 · Vinculación de alcance

Elija la organización y el equipo a los que pertenece la clave. Una clave solo puede ver recursos dentro de ese único equipo en esa única org, así que elija el equipo cuyos modelos, archivos y agentes debe alcanzar esta clave. Las claves deben estar limitadas a un equipo, y el equipo Default ya existe. Si es un miembro que no pertenece a ningún equipo, pida a un administrador que lo añada a uno antes de crear una clave.

3 · Permisos (scopes)

Elija qué recursos puede leer y escribir la clave. Los scopes se comprueban en cada solicitud. Use un preajuste para avanzar rápido y luego ajuste:
  • Standard - los scopes de lectura/escritura cotidianos para crear apps (respuestas, conversaciones, archivos, almacenes vectoriales, prompts, agentes y más). Para un administrador, el preajuste también incluye los scopes de repositorios.
  • Read-only - todos los scopes read: que usted puede emitir, y nada más.
  • All - todos los scopes, incluidos los exclusivos de administrador. Disponible solo para propietarios y administradores de la org.
Algunos scopes son solo de administrador: Compute, repositorios, presupuestos, lotes y autorización de grano fino (lectura y escritura), más el acceso de escritura al registro de modelos y a los guardrails. Estas filas aparecen solo si usted es propietario o administrador. Conceda el conjunto más estrecho que la clave realmente necesite.

4 · Limitación de tasa (opcional)

Opcionalmente limite la clave a un número máximo de solicitudes por minuto, hora o día. La puerta de enlace lo aplica y devuelve 429 Too Many Requests antes de que la solicitud llegue a un modelo, así que las llamadas por encima del límite no cuestan nada.
Copie el secreto ahora — se muestra una sola vezCuando hace clic en Create key, el secreto completo se revela una única vez. Cópielo inmediatamente y guárdelo en un lugar seguro (un gestor de secretos o su .env). Si lo pierde, no puede volver a verlo. Regenere la clave para obtener un secreto nuevo. Trátelo como una contraseña: nunca lo suba al control de versiones ni lo exponga en código de navegador. Eliminar una clave corta de inmediato el acceso de todas las aplicaciones que la usan.

Paso 5 · Instale un SDK

MKA1 ofrece SDK para TypeScript, Python y C#, además de una CLI mka1 independiente. Cada cliente se autentica con su clave API como token Bearer y apunta a la puerta de enlace de la API. La puerta de enlace alojada por defecto es https://apigw.mka1.com.
Clústeres privadosEn un despliegue privado, sustituya https://apigw.mka1.com por el host de la puerta de enlace de su propio clúster en todo lo que sigue. Páselo como la opción serverURL / server_url / serverUrl del SDK, o configúrelo una vez para la CLI. Su administrador puede decirle la URL de la puerta de enlace (es la contraparte de API de su dirección de consola).

TypeScript - @meetkai/mka1

El SDK de TypeScript se instala desde el registro de paquetes npm:

Python - meetkai-mka1

Requiere Python 3.10 o más reciente:

C# - MeetKai.MKA1

CLI - mka1

Los binarios precompilados se sirven desde downloads.mka1.com. En macOS (Apple silicon):
Cambie arm64 por x86_64 en Intel; los paquetes .deb/.rpm y un .zip para Windows están enlazados desde la guía de la CLI. Luego configure su clave y ejecute cualquier comando:
Para una configuración persistente que guarda los secretos en el llavero de su SO, vea autenticar la CLI.

Paso 6 · Autentique sus solicitudes

Cada solicitud lleva su clave API como token bearer en el encabezado Authorization. Para apps multiusuario del lado del servidor también envía X-On-Behalf-Of para identificar para cuál de sus usuarios finales es la solicitud.

Cuándo enviar X-On-Behalf-Of

Establezca X-On-Behalf-Of con un identificador estable de su propio sistema (p. ej. user_123) siempre que su servidor actúe para un usuario final específico. Esto mantiene las solicitudes, archivos, memoria y uso de ese usuario correctamente atribuidos. Use un ID que no cambie. Nunca use un correo ni un nombre visible.
  • Solo Authorization - su propio flujo de trabajo backend, no ligado a ningún usuario final.
  • Authorization + X-On-Behalf-Of - su servidor actuando para uno de sus usuarios finales; el uso y los recursos quedan asociados a él.

Emita tokens de corta duración (opcional)

Cuando un servicio descendente o un cliente de navegador necesita llamar a MKA1 sin poseer su clave API, intercambie la clave por un JWT de corta duración mediante POST /api/v1/authentication/api-keys/exchange-token, y luego use ese JWT como token bearer. Vea la guía de autenticación y el análisis en profundidad.

Paso 7 · Realice su primera solicitud

Con una clave en mano, genere su primera respuesta. Usar model: 'auto' permite que la puerta de enlace elija el modelo adecuado para la solicitud. Una respuesta completada en la consola con entrada, razonamiento y salida
Ese es el camino completo desde cero. Tiene una organización, un equipo, una clave API, un SDK y una solicitud funcionando. El resto de esta guía recorre los bloques de construcción que ensamblará en aplicaciones reales.

Construya con la plataforma

Todo lo que sigue puede llamarse con la clave API que acaba de crear. Cada sección se apoya en las guías oficiales de docs.mka1.com. Siga los enlaces incorporados para la referencia completa.

Generar respuestas (la llamada principal)

Playground con el panel de ajustes avanzados abierto El recurso Responses es cómo genera texto con MKA1. Pase una cadena simple en input para un prompt de un solo turno; el resultado incluye el texto generado en output_text. Use auto_routing: true para que la puerta de enlace elija el modelo adecuado por usted.

Llamada básica

Pase X-On-Behalf-Of cuando actúe para un usuario final; omítalo en caso contrario.

Qué hace auto_routing

auto_routing es un indicador de solicitud opcional, separado del alias de modelo auto. Cuando establece auto_routing: true, la puerta de enlace puntúa la complejidad de la solicitud y la enruta al mejor hermano cuantizado, MoE o denso dentro de la familia de modelos que usted solicitó. Nunca cambia a un modelo no relacionado, y recurre al modelo que pidió si esa familia no tiene un hermano compatible. La puntuación es aditiva. Sube con la longitud del prompt, muchas herramientas o herramientas de alta agencia (p. ej. code_interpreter, mcp), tool_choice: 'required', salida estructurada, un max_output_tokens grande, contexto multivuelta y señales de razonamiento complejo en el texto (debug, refactor, plan, incident, code); baja con prompts cortos y tareas simples reconocidas (traducir, resumir, clasificar, extraer). El total elige el nivel. Puntuaciones altas enrutan a dense, medias a moe, bajas a quantized. Se establece un reasoning.effort acorde (desde minimal hasta xhigh) a menos que usted mismo haya fijado el esfuerzo. Así, un breve “resuma esto” se enruta a quantized con esfuerzo minimal, mientras que un largo informe de incidente se enruta a dense con esfuerzo high (o xhigh). Siempre que el enrutamiento se ejecuta, los metadatos de la respuesta registran routed_model - la variante realmente usada. Añada auto_routing_debug: true para obtener también un campo de metadatos auto_routing_debug: una cadena JSON compacta con el modelo solicitado y el enrutado, el nivel elegido, el esfuerzo de razonamiento, la puntuación y las razones detrás de la decisión. Se registra incluso cuando no hay variante hermana disponible, así que es útil para validar el comportamiento del despliegue. Deje este campo desactivado para el tráfico normal de producción.

Transmita texto a medida que se genera

Establezca stream: true para recibir eventos enviados por el servidor en lugar de esperar la respuesta completa. Úselo para renderizar salida parcial a medida que llega.

Entrada multimodal (imagen + texto)

La API de Responses acepta texto, imágenes, audio y archivos en una sola solicitud. Use un arreglo input estructurado de elementos de mensaje, donde content es un arreglo que mezcla input_text e input_image (imagen por URL, URI de datos base64 o un file_id subido).

Respuestas en segundo plano

Para trabajo de larga duración, establezca background: true (con stream: false) para obtener de inmediato una respuesta en cola, y luego recupere el resultado más tarde sondeando con mka1.llm.responses.get(...) o mediante streaming. Vea la guía de respuestas en segundo plano.

Webhooks en lugar de sondeo

En lugar de sondear, pase webhook_url (y opcionalmente webhook_secret) al crear una respuesta en segundo plano. La puerta de enlace envía por POST cada cambio de estado a su endpoint — response.queued, response.in_progress, response.completed, response.failed, response.incomplete, response.cancelled — como { event, resource_id, created_at, data }, donde data es el objeto de evento completo. Con un secreto configurado, cada entrega lleva X-Webhook-Signature: sha256=<hex>, un HMAC-SHA256 del cuerpo JSON sin procesar — verifíquelo antes de confiar en la carga útil. La entrega nunca bloquea la respuesta: tres intentos con retroceso exponencial y un tiempo límite de 10 segundos. El endpoint debe ser accesible públicamente — las direcciones privadas y localhost se rechazan. La puerta de enlace requiere que webhook_secret tenga al menos 16 caracteres.
Para su lado receptor:

Conversaciones y memoria

Detalle de conversación con elementos y metadatos MKA1 le ofrece dos formas complementarias de mantener el contexto entre turnos: conversaciones con estado (historial guardado para una sesión, en el servidor) y el almacén de memoria a largo plazo (la herramienta history, persistente entre sesiones y con alcance por usuario final).

Conversaciones con estado

Una conversación es un contenedor del lado del servidor que la puerta de enlace usa para mantener el estado entre solicitudes de Responses, de modo que nunca reenvíe el historial completo. Cree una y luego pase su ID en cada respuesta de seguimiento.
Pase conversation en cada solicitud; la puerta de enlace mantiene el hilo por usted. Use una conversación cuando quiera un contenedor reutilizable e inspeccionable para muchos turnos y la capacidad de listar, obtener o eliminar elementos después. Use previous_response_id en su lugar cuando solo necesite bifurcar desde una única respuesta anterior.

Almacén de memoria a largo plazo

La herramienta history da al modelo memoria que persiste entre sesiones. Añada { type: 'history' } a tools y establezca store: true; cada par solicitud/respuesta se indexa en segundo plano y se busca semánticamente (embeddings vectoriales) cuando el modelo decide que necesita recordar algo. La memoria está aislada por usuario final mediante el encabezado X-On-Behalf-Of.
Regla general: las conversaciones mantienen coherente una sesión; la herramienta history lleva preferencias, decisiones y contexto hacia adelante a través de muchas sesiones para el mismo usuario.

Archivos, almacenes vectoriales y recuperación (RAG)

Un almacén vectorial con archivos adjuntos en indexación MKA1 divide la recuperación en dos recursos: Files contiene sus documentos subidos, y Vector Stores indexa esos archivos para que pueda ejecutar búsqueda semántica sobre los fragmentos resultantes. Este es el patrón estándar para asistentes respaldados por documentos y respuestas fundamentadas. La indexación es automática. Usted sube, adjunta y busca; MKA1 se encarga del troceado y los embeddings. Todos los fragmentos siguientes usan el SDK de MKA1 para TypeScript o Python. Inicialice el cliente una vez:

1. Suba un archivo

Suba el documento una vez. La respuesta devuelve un objeto de archivo cuyo id se parece a file_1783478060914_iemq10dh5h — páselo a los almacenes vectoriales en el siguiente paso.

2. Cree un almacén vectorial y adjunte archivos

Cree un almacén vectorial, pasando uno o más ID de archivos subidos en fileIds. El almacén devuelve un ID como vs_1783478061269_mptf5b93t0q. Los archivos adjuntos se indexan automáticamente.
Para añadir más archivos después sin recrear el almacén, use createFile:
Un archivo de almacén vectorial puede reportar status: "in_progress" mientras se ejecuta la indexación, así que espere a que el procesamiento termine antes de confiar en los resultados de búsqueda.

3. Busque fragmentos relevantes en el almacén

Ejecute una búsqueda semántica para recuperar los fragmentos más relevantes para la pregunta de un usuario. La respuesta devuelve coincidencias clasificadas con file_id, filename, datos de puntuación y el contenido del fragmento. Alimente ese texto a su propia lógica de aplicación o a una solicitud de Responses.

Extra: extracción estructurada

Cuando necesita JSON tipado de un documento en lugar de fragmentos de texto libre, use el recurso Extract. Para trabajo puntual, llame a extract con un JSON Schema en línea — pasado como cadena JSON — y el archivo a leer. Para trabajos repetidos, guarde el esquema una vez con createSchema (aquí el esquema es un objeto simple) y ejecútelo contra muchos archivos con extractWithSchema, referenciando el id del esquema devuelto bajo data.id. Nombre un modelo explícitamente en cada llamada de extracción. Una respuesta exitosa devuelve success, un objeto data con los campos extraídos y metadata sobre la ejecución.

Agentes, herramientas y MCP

Ejecutar un agente guardado desde la consola Un agente guardado es un objeto de agente reutilizable que almacena su propio comportamiento para que no reconstruya una solicitud de Responses cada vez. Cada agente persiste un modelo, instrucciones y una configuración de herramientas (tools, tool_choice, parallel_tool_calls, max_tool_calls, text, reasoning). Cuando lo ejecuta, el servicio combina su entrada por ejecución con la configuración guardada y la reenvía a la API de Responses a través de mkllm-gateway. Cada ejecución persiste la entrada más el resultado de Responses del upstream, así que también obtiene historial de ejecuciones gratis. Los agentes reciben un id estable como agt_....

Cree un agente

Cree un agente una vez con los SDK de MKA1 para Python, TypeScript o C#, incluyendo una herramienta integrada web_search para que las ejecuciones puedan incorporar información externa actual:
El arreglo tools completo (tal como se envía por HTTPS) configura la herramienta integrada:

Ejecute un agente

Ejecute enviando solo la entrada por ejecución. La ejecución persiste status, el gateway_response almacenado y gateway_response_id de la llamada upstream. Si la ejecución usó web_search, el gateway_response persistido incluye las entradas de llamadas a herramientas.
Use sdk.agents.list_agents(...) / sdk.agent_runs.list_agent_runs(agent_id=...) para inspeccionar agentes guardados y ejecuciones anteriores.

Historial de versiones y reversión

Cada cambio confirmado en un agente guardado — crear, actualizar, revertir — añade una versión inmutable, así que el historial de configuración de un agente siempre es inspeccionable. Revertir no reescribe el historial: añade una nueva versión restaurada desde la de destino.

Adjunte un servidor de herramientas MCP

Más allá de las herramientas integradas, puede permitir que el modelo llame a herramientas de un servidor MCP externo añadiendo una entrada mcp a tools. Establezca require_approval en "never" para ejecutar de inmediato, o "always" para pausar y pedir aprobación del usuario final. Limite las herramientas invocables con allowed_tools; pase credenciales upstream en headers (se enmascaran en las respuestas almacenadas).
El modelo llama a la herramienta MCP permitida y devuelve el mensaje final en una sola solicitud. Con require_approval: "always", cree la respuesta en modo de segundo plano, sondéela y maneje el elemento mcp_approval_request devolviendo un mcp_approval_response.

Programaciones y conectores de chat

Un agente guardado también puede ejecutarse sin una solicitud de su código. Una programación inicia ejecuciones con un temporizador. Su schedule.type es once, interval o cron, y el timezone de una programación cron es UTC por defecto. Un conector vincula el agente a un bot de Telegram o a un número de WhatsApp, de modo que cada mensaje de un chat permitido se convierte en una ejecución y la respuesta vuelve a ese chat. Un conector necesita un token de bot o credenciales de app de Meta, y sus endpoints devuelven 403 si la solicitud lleva X-On-Behalf-Of. Esta página los omite y crea una sola programación cron en el agente que creó arriba.
Una programación nueva está active. Pausarla la pone en paused, y una programación once pasa a completed después de dispararse. run_count y last_run_id se actualizan después de cada disparo. Vea Conectar agentes a apps de chat y programaciones para los conectores de Telegram y WhatsApp, pausar y actualizar programaciones, y cómo se registran las ejecuciones.

Ejecutar código en un sandbox

Una sesión de sandbox es un entorno de ejecución aislado con un directorio /workspace persistente. Usted mismo nombra la sesión, y create es idempotente sobre ese id. Una segunda llamada reutiliza una sesión en ejecución y reanuda una detenida. Las herramientas shell y code_interpreter de Responses se ejecutan en estas mismas sesiones, así que un modelo que necesita ejecutar código no necesita esta API. Llámela usted mismo cuando su propio programa decida qué se ejecuta, cuando quiera mover archivos hacia adentro y hacia afuera sin gastar un turno del modelo, o cuando necesite una sesión de navegador. La clave necesita read:sandbox y write:sandbox. Ambos son scopes ordinarios de miembro, así que cualquier miembro de la organización puede añadirlos en el formulario de claves del Paso 4.
El resultado lleva el stdout, el stderr y el exit_code del comando. Un comando que falla sigue siendo un 200, así que compruebe exit_code usted mismo; 0 significa que tuvo éxito. El SDK de Python toma el parámetro de ruta como session_id_param y el campo del cuerpo como session_id; pase ambos. Las sesiones se facturan por tiempo transcurrido, así que termine una en cuanto haya acabado con ella. Vea Ejecutar código en un sandbox para archivos, runtimes de código, sesiones de navegador y uso.

Prompts, habilidades y guardrails

Una plantilla de prompt versionada en el repositorio de prompts MKA1 separa el qué de una llamada LLM (sus prompts), las capacidades que agrupa para ella (habilidades) y la gobernanza que mantiene el uso seguro y con rendición de cuentas (guardrails, limitación de tasa y auditoría).

Repositorio de prompts

La API de Prompts almacena, versiona y renderiza plantillas de prompts de forma centralizada. Cada cambio de plantilla crea una versión inmutable, así que obtiene un historial de cambios completo y puede revertir a cualquier versión anterior en cualquier momento. Una reversión no es destructiva y solo cambia la versión activa. Las plantillas usan marcadores {{variable}} que se renderizan del lado del servidor cuando recupera un prompt, permitiéndole reutilizar una plantilla en distintos contextos. Los prompts están aislados por clave API.

Habilidades

Las habilidades son paquetes de capacidades reutilizables y versionados que usted sube a la puerta de enlace. Cada habilidad empaqueta el comportamiento de herramientas tras un manifiesto SKILL.md. El nombre y la descripción de la habilidad se leen directamente de ese manifiesto. Puede subir un conjunto de archivos único o un paquete completo, gestionar versiones (cada habilidad rastrea una versión por defecto y la más reciente) y revisar cada archivo antes de crearla. Gestione las habilidades en el panel bajo Skills, o mediante la API de Skills.

Guardrails, limitación de tasa y auditoría de uso

Estas tres funciones de gobernanza mantienen el tráfico delegado y multiusuario controlado y con rendición de cuentas:
  • Limitación de tasa - Cada clave API puede llevar una cuota sobre una ventana configurable — por minuto, hora o día. Cuando una clave supera su límite, la puerta de enlace devuelve 429 Too Many Requests antes de que la solicitud llegue al modelo, así que no se consumen tokens ni se factura uso. Maneje los 429 con reintentos de retroceso exponencial.
  • Auditoría de uso - Revise el uso de tokens, solicitudes y almacenamiento por org y equipo en Admin → Usage, filtrable por usuario (miembros de la org). Para informes por usuario final, consulte la API de uso con su filtro external_user_ids — la identidad X-On-Behalf-Of. Cada respuesta también devuelve un X-Request-ID que puede guardar como clave de correlación.
  • Guardrails - Las decisiones de política se registran en el mismo flujo de auditoría: resultados como policy_violation o throttled y valores de policy_action de warn, block o escalate fluyen a la página de Guardrails, dándole un camino consistente desde un informe de uso hasta la acción exacta que fue permitida, advertida, bloqueada o escalada.
Fuentes: repositorios de prompts, limitación de tasa, auditoría de uso y habilidades.

Habla y voz

Detalle de generación de texto a voz con salida de audio MKA1 expone la voz basada en archivos a través del recurso llm.speech del SDK. Use speak para texto a voz y transcribe para voz a texto. Para conversaciones bidireccionales en tiempo real, use el modo de voz avanzado en su lugar. El modo de voz avanzado se cubre por separado.

Texto a voz

speak devuelve un archivo WAV completo. El cuerpo de la respuesta es audio binario, y los encabezados de respuesta incluyen X-Language-Code.
Para reproducción de baja latencia que comienza antes de que el archivo completo esté listo, use speakStreaming y elija mp3 (más pequeño) o pcm (sin comprimir):

Voz a texto

transcribe acepta un archivo de audio (FLAC, MP3, MP4, M4A, OGG, WAV, WebM, PCM y más) y devuelve la transcripción junto con el idioma detectado y la confianza:
Para separación de múltiples hablantes, establezca includeSpeakerData: true (requiere audio WAV o PCM). La respuesta entonces incluye un arreglo speakers con segmentos etiquetados y tiempos offset_ms / duration_ms. Archivos fuente: voz, salida multimodal.

Evaluar y observar

Una vez que algo funciona, MKA1 le ayuda a medirlo y a vigilarlo en producción. Una evaluación con conjunto de datos, calificador y versiones
  • Evaluations - Construya una evaluación a partir de conjuntos de datos, prompts y calificadores, y luego lance ejecuciones duraderas contra uno o más modelos. Rastree la precisión y las puntuaciones por muestra, y compare modelos en una tabla de clasificación. Úselo para elegir un modelo y para detectar regresiones antes de que se publiquen.
  • Runs - Inspeccione la entrada almacenada, la respuesta de la puerta de enlace, la transcripción (mensajes, razonamiento y llamadas a herramientas) y el JSON sin procesar de cada ejecución de agente. Los eventos sin procesar solo se transmiten mientras la ejecución está activa.
  • Uso y auditoría - Revise el uso de tokens, solicitudes y almacenamiento por org y equipo en Admin → Usage, y filtre por usuario final cuando envíe X-On-Behalf-Of. Cada respuesta también devuelve un X-Request-ID que puede guardar como clave de correlación.

Auditoría

La vista de Audit del tráfico de la puerta de enlace en Admin → Audit Audit (Admin → Audit) es la superficie de revisión del tráfico que pasó por la puerta de enlace. Los administradores del clúster ven solicitudes de todas las organizaciones y equipos; los administradores de organización ven la actividad de su propia org. Busque por ruta, path o usuario; filtre por servicio, método, estado, modelo o estado de revisión; o pegue un X-Request-ID — devuelto en cada respuesta de la API — para saltar a la solicitud exacta. Marque entradas para revisión, agrupe solicitudes relacionadas en casos y exporte datos de respuesta para análisis fuera de línea.

Alertas

Endpoints de webhook de alertas en Admin → Alerts Las alertas convierten los fallos en webhooks. En Admin → Alerts, registre una URL de endpoint y elija su alcance: todo el clúster (administradores del clúster), su organización (propietarios y administradores de org) o un solo equipo — los administradores de org pueden apuntar a cualquier equipo, y los miembros de equipo pueden gestionar webhooks de su propio equipo activo. Suscriba el endpoint a uno o ambos tipos de evento — response.failed (una solicitud de respuesta falló en el proveedor del modelo) y gateway.request.failed (cualquier solicitud de la puerta de enlace devolvió un 5xx) — o deje la suscripción vacía para recibirlos todos. Los filtros opcionales limitan la entrega a claves API, códigos de error o modelos específicos. Cada endpoint tiene una página de detalle que muestra su configuración, su secreto de firma (revelarlo, copiarlo o rotarlo) y las entregas recientes con cargas útiles y estado succeeded / failed / pending. Desde ahí puede reenviar una entrega, disparar una alerta de prueba mientras integra, y editar, deshabilitar o eliminar el endpoint — editar nunca cambia el secreto de firma.

Precios, presupuestos y uso

Cada solicitud fluye por una tubería de facturación: el uso registra los volúmenes, el libro de precios de modelos los convierte en costos y los presupuestos aplican límites sobre el resultado. Esta sección cubre los tres.

Precios

Formulario de añadir precio de modelo en Admin → Pricing Cada solicitud se mide y se tarifica contra el libro de precios de modelos de su clúster. Los administradores del clúster mantienen el libro de precios en Admin → Pricing:
  • Moneda del clúster - La moneda en la que se denominan todos los precios y presupuestos.
  • Precios de modelos - La tarifa por defecto del clúster, un precio por modelo. Las dimensiones de tarifa siguen la modalidad del modelo: tokens de entrada, salida, entrada en caché y razonamiento para LLM; audio y caracteres para voz; tarifas por imagen con niveles opcionales por tamaño; búsqueda web.
  • Anulaciones por org - Precios por organización para cuando una org factura distinto del valor por defecto del clúster.
  • Tarifas efectivas - Una vista de resolución que muestra qué precio — por defecto del clúster, anulación de org o sin precio — resuelve cada modelo para una organización dada. Los modelos sin precio facturan a 0.
Los precios llevan fecha: guardar añade una nueva versión y nunca reescribe el costo pasado. El gasto aparece entonces en dos lugares:
  • Admin → Usage - Gasto total tarificado desde el libro de precios, desglosado por organización, equipo, clave API y modelo — junto con los volúmenes subyacentes (vea Uso más abajo).
  • La API - Consulte el gasto en cualquier rango de tiempo, agrupado por modelo, clave API, equipo, organización o usuario final (la identidad X-On-Behalf-Of). Este es el alimentador para sistemas de facturación; los Presupuestos (abajo) aplican límites contra el mismo gasto.

Presupuestos

Formulario de nuevo presupuesto de organización en Admin → Budgets Los presupuestos limitan el gasto total por período. En la consola puede fijarlos por organización y por miembro (con un tope predeterminado para toda la organización que se aplica a cada miembro); los administradores del clúster también los fijan por clave API. Por la API también puede fijarlos por equipo y por usuario externo, cada uno con su propio valor predeterminado. Créelos y gestiónelos en Admin → Budgets. Un presupuesto tiene tres partes:
  • Período y límite - Diario, semanal o mensual, con un límite en la moneda del clúster. Las ventanas de gasto se reinician en los límites del calendario UTC.
  • Umbrales - Porcentajes únicos del límite, cada uno emparejado con una acción: alert (notificar) o block (rechazar más solicitudes). Un presupuesto que superó un umbral de bloqueo muestra Blocked en las columnas en vivo Spend y Status.
  • Webhook de alerta (opcional) - Una URL más un secreto de firma HMAC que recibe las notificaciones de umbral.
Cada fila de presupuesto muestra el gasto en vivo contra su límite; abra el historial de un presupuesto para revisar los eventos de umbral del período, y edite o elimine presupuestos según cambien las necesidades. Los presupuestos tienen dos propietarios: los presupuestos de clúster son techos del operador (solo lectura para administradores de org), mientras que los presupuestos de org son autoimpuestos. La aplicación es de mejor esfuerzo y fail-open, así que dimensione los límites con margen. Las mismas operaciones están disponibles por la API — conceda a la clave los scopes de Presupuestos exclusivos de administrador (read:budgets / write:budgets) en el formulario de claves del Paso 4. La guía de Presupuestos cubre cada scope, los topes predeterminados por miembro y el 403 que devuelve una solicitud bloqueada. El ejemplo de abajo limita a un usuario final a 20 de la moneda del clúster por mes, identificado por el id que envía en X-On-Behalf-Of en sus solicitudes, y luego vuelve a leer el presupuesto con su gasto en vivo.
spend.pct es el porcentaje del límite gastado en la ventana actual, y spend.status pasa de ok a blocked en cuanto se dispara un umbral de bloqueo y vuelve a ok cuando la ventana se reinicia.

Uso

El panel de Usage con tokens en el tiempo y desgloses por modelo en Admin → Usage El uso es el libro de volúmenes detrás de los precios y los presupuestos — los tokens, conteos de solicitudes y almacenamiento de cada solicitud se miden por organización, equipo, clave API y usuario final. Vive en dos lugares:
  • En la consola - Admin → Usage muestra un gráfico de tokens en el tiempo (24h / 7d / 30d), desgloses por categoría (Responses, Completions, Embeddings, Classify, Extract) con tokens de entrada/salida y conteos de solicitudes por modelo, filas por usuario final, almacenamiento de archivos y vectores, y operaciones de sandbox — todo exportable como CSV. La sección de gasto tarifica estos volúmenes desde el libro de precios de modelos (vea Precios arriba).
  • Por la API - Los endpoints por categoría (llm.usage.responses, completions, conversations, embeddings, extract, classify, vectorStores, files) devuelven series agrupadas en el tiempo. Elija un bucket_width, filtre por models, user_ids o external_user_ids (la identidad X-On-Behalf-Of) y agrupe por model, api_key_id, user_id, org_id o background para informes por dimensión.

Compute

Compute convierte los aceleradores de su clúster en servicios en GPU (de larga duración, con un endpoint de red) y trabajos (que se ejecutan hasta completarse). Una vez que un administrador del clúster habilita Compute para su organización, ya sea en la invitación o más tarde, usted gestiona ambos en Admin → Compute:
  • Overview - Services, Jobs y Spend de su organización.
  • Secrets - Conjuntos de pares clave/valor con nombre que los servicios y los trabajos leen mediante secret_env, como la clave de un endpoint o un token de Hugging Face.
  • New workload - Plantillas como Fine-tune job y OpenAI-compatible server.
  • Catalog - Las ofertas de aceleradores disponibles para el clúster (administradores del clúster).
Tres guías cubren el trabajo: Desplegar un servidor de modelos para un endpoint compatible con OpenAI, Ejecutar un trabajo de ajuste fino para entrenar en el clúster y Gestionar repositorios para los pesos de modelo y los conjuntos de datos que ambos consumen.

En conjunto: construya un agente de principio a fin

Los bloques de construcción se componen. Este es el flujo insignia de principio a fin: indexe conocimiento, conecte herramientas, empaquete una habilidad, ensamble un agente, ejecútelo y rastree el resultado. Formulario de creación de agente con herramientas integradas
  1. Indexe conocimiento. Suba sus documentos como Files y adjúntelos a un Vector Store para que el agente pueda fundamentar respuestas en su contenido (vea Archivos, almacenes vectoriales y recuperación).
  2. Conecte herramientas. Registre un servidor MCP (o use herramientas integradas como web_search) para que el agente pueda actuar y obtener datos en vivo (vea Agentes, herramientas y MCP).
  3. Empaquete una habilidad. Agrupe comportamiento reutilizable tras un SKILL.md y súbalo bajo Skills, luego adjúntelo.
  4. Ensamble el agente. Cree un agente guardado con un modelo, instrucciones y ese conjunto de herramientas. Configura el agente una vez, así que no reconstruye la solicitud en cada llamada.
  5. Ejecútelo. Ejecute el agente con entrada nueva desde la consola o POST /api/v1/agents/{id}/runs. Cada ejecución persiste su entrada y la respuesta de la puerta de enlace.
  6. Rastree la ejecución. Abra Runs para revisar la transcripción almacenada y confirmar que el agente llamó a las herramientas correctas.

Referencia y soporte

Tenga esto a mano mientras construye:
Resumen rápido
  1. Acepte la invitación al clúster → es propietario de una nueva organización.
  2. Invite a compañeros y añada equipos si desea dividir el acceso.
  3. Genere una clave API en un equipo (copie el secreto una vez).
  4. Instale un SDK y autentíquese con Authorization: Bearer.
  5. Llame a responses.create — luego componga conversaciones, memoria, RAG, agentes, herramientas y voz en su app.
Bienvenido a bordo. Ahora vaya a construir algo.