Por qué las operaciones largas del editor son jobs y no llamadas
Un bake de lighting no cabe en el timeout de un request MCP. Aquí está el porqué MCP4Unreal movió builds, bakes, renders e imports a semántica de job — start, status, cancel, result — en vez de fingir que una llamada bloqueante iba a sobrevivir.
El problema que ningún marketing menciona
MCP es un protocolo de request/response. Un bake de lighting toma minutos. Un envío a Movie Render Queue puede tomar una hora. Si tu puente de automatización expone esas operaciones como llamadas bloqueantes, pasa una de dos cosas: el cliente hace timeout y la operación sigue corriendo sin nadie conectado a ella, o el puente mantiene la conexión abierta y reza. En ambos casos el agente termina con un estado del editor a medias sobre el que no puede razonar — que es exactamente la situación que un puente de automatización existe para prevenir.
La mayoría de los plugins MCP para Unreal exponen las operaciones largas igual y dejan que el timeout sea tu problema. Nosotros decidimos que era nuestro problema.
Semántica de jobs
MCP4Unreal incluye un dominio de servicio jobs dedicado. Las operaciones declaradas como
largas — builds, bakes de lighting, renders MRQ, imports, exports, reimports — se ejecutan
como jobs con una API de ciclo de vida completa:
startdevuelve un id de job de inmediato en lugar de bloquear el request.statusreporta progreso sin tocar la operación.canceldetiene un job limpiamente.resultrecupera el resultado cuando el job termina.- Un
log tailacotado expone la salida reciente sin inundar la ventana de contexto. cleanupyrecoveryse encargan de la parte sin glamour: jobs que sobrevivieron a su cliente.
Los contratos de job incluyen timeouts e idempotencia, así que un agente que reintenta no
hace bake doble de tus lightmaps. Los metadatos async se anuncian por discovery y
system.health, de modo que un cliente puede saber qué operaciones son jobs antes de
llamarlas.
Por qué esto importa especialmente para agentes
Un humano mirando una barra de progreso puede decidir cuándo intervenir. Un agente no — necesita que la máquina de estados sea explícita. La semántica de jobs convierte el “dispara y reza” en un bucle sobre el que el agente sí puede razonar: start, poll, decidir, cancelar o recoger. Combinado con el log tail acotado, el agente obtiene observabilidad sin arrastrar megabytes de salida de build a su contexto.
Por eso también las compuertas async estática y en vivo están cableadas en nuestro pipeline de validación: el ciclo de vida de los jobs es parte de la superficie del producto, así que se valida como tal. Las operaciones largas son el lugar donde la automatización suele morir en silencio. Preferimos que sean el lugar donde demuestra que se puede confiar en ella.