skipMiddlewareRequestBody de Vercel: una trampa al depurar agentes

La bandera que parece una ganancia gratuita de 20ms

La opción skipMiddlewareRequestBody de Vercel hace exactamente lo que su nombre dice: evita que el cuerpo de la solicitud se transmita al Middleware de Edge. Para una carga útil POST de 50KB, eso ahorra 10–30ms por salto. Es opcional, está documentado, y se lee como una ganancia de latencia limpia. La característica existe porque la mayoría del middleware de autenticación y redirección solo inspecciona encabezados y cookies—nunca tocan el cuerpo. Entonces, ¿por qué leerlo?

En un modelo tradicional de solicitud-respuesta, eso es correcto. Pero en sistemas de agentes, no tenemos "una" solicitud. Tenemos una solicitud que explota en 6–12 llamadas de herramientas secuenciales, cada una de las cuales vuelve a entrar en tu pila de middleware. La optimización se ve local. El fallo es distribuido.

Los agentes no tienen "una" solicitud — tienen una cadena

Cuando tu agente ejecuta un turno, el mensaje del usuario no golpea un único punto final y regresa. En su lugar, genera un bucle: llamar al LLM, obtener una decisión de herramienta, invocar esa herramienta, alimentar el resultado nuevamente, bucle. Cada una de esas llamadas de herramientas es su propia solicitud HTTP. Cada una vuelve a entrar en tu middleware de enrutamiento, tu middleware de límite de velocidad, tu middleware de autenticación.

Seis llamadas de herramientas por turno significa seis pasos a través de tu pila de middleware. Si el middleware lee el cuerpo en cualquiera de esos pasos—para extraer un ID de correlación, para verificar un límite de velocidad codificado en body.model, para enrutar basado en body.workspaceId—entonces omitir la transmisión del cuerpo no es una ganancia de 20ms. Es una pérdida de contexto en cada salto.

La varianza se compone. Hemos enviado sistemas de agentes donde la varianza de latencia, no la latencia media, determinó el SLA. Un pico p99 de comportamiento inconsistente del middleware—encabezados presentes en algunos saltos, contexto derivado del cuerpo faltante en otros—enviará agentes a una pared más rápido que una línea de base constante de 50ms.

El acoplamiento invisible: lo que el middleware estaba haciendo silenciosamente

La mayoría de los equipos de agentes no se dan cuenta de que su middleware depende del cuerpo hasta que se rompe. Aquí está lo que hemos visto que el middleware hace con cuerpos de solicitud:

• Extraer messages[0].id e inyectarlo como x-correlation-id para que los rastros permanezcan coherentes en toda la cadena de llamadas de herramientas.
• Leer workspaceId para enrutar al depósito de límite de velocidad del inquilino correcto.
• Inspeccionar model o tool para decidir temprano si una solicitud alcanza la cuota.
• Propagar traceParentId del cuerpo al contexto para observabilidad descendente.

Cuando skipMiddlewareRequestBody está habilitado, el middleware ve un cuerpo vacío o de stub. No puede extraer el ID de correlación. No puede enrutar por espacio de trabajo. No puede aplicar el límite de velocidad correctamente. El controlador descendente eventualmente lee el cuerpo y ve todo el contexto—pero para entonces, el registro ya se ha dividido en dos ID de rastro diferentes. La brecha de observabilidad aparece en el alcance del agente, no en el alcance de la herramienta.

El acoplamiento es invisible porque es implícito. Nadie documenta "nuestro middleware asume que el cuerpo está presente para rutas de agentes." Pero la suposición vive en el código.

La superficie de depuración de las 2am que nadie anunció

Aquí está lo que hemos visto suceder en producción: un equipo de agentes habilita skipMiddlewareRequestBody en su ruta de agente principal como parte de un PR "afeita 20ms de la ruta crítica". Los histogramas de latencia mejoran en 10–15ms. El PR se integra.

Seis semanas después, el personal de guardia recibe una alerta porque el 1–2% de los turnos de agentes están "olvidando" resultados de herramientas. El agente llama a una función, obtiene un resultado, luego llama a la siguiente función como si el resultado anterior nunca hubiera llegado. Los reintentos lo enmascaran por un tiempo—pero una reconciliación de facturación expone brechas donde los costos de herramientas no coinciden con los registros de ejecución de herramientas. Extraes rastros y ves un único turno de agente dividido en tres ID de correlación diferentes. El middleware devolvió 200, pero los controladores descendentes devolvieron 400 en encabezados workspaceId faltantes. El controlador de reintentos lo capturó, pero la solicitud inicial se perdió.

Git blame apunta a un PR de rendimiento de hace seis semanas. La bandera está a tres archivos de distancia del síntoma. La superficie de depuración es observabilidad, no gobernanza—y para cuando la ves, estás reconstruyendo tus rastros.

Una regla para cada bandera 'Skip' en tu ruta de agente

Antes de cambiar cualquier bandera "skip" en una ruta de agente, haz tres cosas:

Primero, mide el costo de middleware p50 y p99 por salto en tu tráfico de producción. Si tu agente promedia 8 llamadas de herramientas por turno y el middleware agrega 5ms p99, entonces estás viendo un impacto de cola de 40ms por turno. Si skipMiddlewareRequestBody ahorra 3ms p99, has reducido la latencia de cola en un 7.5%. Eso es real. Pero escribe eso—es el número contra el que argumentarás cuando la observabilidad se rompa.

Segundo, audita tu middleware. Si algún middleware lee req.json(), req.body, o deriva cualquier decisión de enrutamiento del cuerpo, entonces skipMiddlewareRequestBody es un cambio de ruptura. No es una optimización. Promueve esos valores derivados del cuerpo a encabezados antes de cambiar la bandera. Envía x-correlation-id, x-workspace-id, x-model en la solicitud misma. Los encabezados siempre están disponibles para el middleware.

Tercero, trata la bandera como una decisión por ruta, nunca como un valor predeterminado global. Las rutas de agentes que se ramifican en cadenas de herramientas necesitan propagación de contexto completo. Las rutas simples de solo autenticación pueden omitirlo. Haz esa distinción explícita en tu configuración de ruta.

Finalmente, escribe una evaluación que falle cuando los ID de correlación se dividan en un único turno de agente. Si tu agente realiza 8 llamadas y ves 3 ID de rastro diferentes, esa prueba debe romper tu implementación. La bandera crea una superficie de depuración—asegúrate de que la estés monitoreando.

Las optimizaciones de plataforma son cambios de API de agentes disfrazados

El skipMiddlewareRequestBody de Vercel es un ejemplo de un patrón que hemos visto repetidamente: los equipos de plataforma envían ganancias de latencia que son cambios de ruptura para arquitecturas de agentes. El patrón se repite con Connect, límites de gasto, implementaciones sub-segundo, y ahora transmisión de cuerpo de middleware.

Cada bandera de edge/runtime es implícitamente parte de tu superficie de API de agente. Un cambio que ahorra 15ms para una ruta de archivo estático puede ser un modo de fallo silencioso para una ruta de agente. El diff del registro de cambios pertenece a tu arnés de evaluación de agente, no solo a un hilo de Slack de infraestructura.

La única defensa es tratar tu configuración de plataforma como parte de tu contrato de agente. Cuando Vercel envía una nueva optimización, pregunta: ¿mi agente atraviesa esta ruta? ¿Mi middleware lee estado que la optimización omitirá? Si es sí, abre un ticket y pruébalo antes de que se envíe a producción.

Busca en tu repositorio skipMiddlewareRequestBody, runtime: 'edge', y cualquier middleware que lea req.json(). Si esos tres se superponen en una ruta de agente, tienes una superficie de depuración esperando. Abre un ticket hoy. Si quieres que ejecutemos esa auditoría contigo, hablemos.