Tu agente resuelve la demostración y falla el martes por la tarde. Es un patrón conocido: la conversación queda impecable, el agente anuncia que ha hecho el cambio, y el registro del sistema está vacío. ThinkingBox es el banco de pruebas que Microsoft publicó en agosto de 2026 para medir exactamente esa distancia. Este artículo explica qué aísla, qué mide, en qué se diferencia de un evaluador de prompts o de un sandbox de código, y hasta dónde llega su veredicto.

Puntos clave

  • ThinkingBox ejecuta al agente contra herramientas simuladas que guardan estado y lo juzga por lo que quedó cambiado, no por la transcripción.
  • Las herramientas se declaran como servidores MCP, así que el agente ve la misma superficie que vería en tu sistema real.
  • El banco asociado, ThinkingBox-Bench, tiene 507 flujos de trabajo en cinco sectores y repite cada tarea veinte veces.
  • El mejor modelo medido acierta el 65,36 % de las veces al primer intento, pero solo el 25,25 % de las tareas le salen bien las veinte veces.
  • El marco es MIT; los datos van aparte, bajo CDLA-Permissive-2.0. Es software libre de verdad, no un anuncio.

Qué es ThinkingBox y qué mide

ThinkingBox es un marco en Python para definir herramientas simuladas como servidores MCP, ejecutar un agente contra ellas y evaluar el resultado. Microsoft lo publicó en github.com/microsoft/thinkingbox[1] con licencia MIT, junto con un segundo repositorio, thinkingbox-data[2], donde viven los escenarios, los servidores de herramientas y los conjuntos de datos.

La descripción del propio repositorio lo sitúa en tres usos: generar conversaciones para entrenamiento o evaluación fuera de línea, meter el sistema entero dentro de un bucle de aprendizaje por refuerzo, y evaluar modelos. El tercero es el que interesa a quien ya tiene un agente en marcha.

Lo que lo separa de casi todo lo demás es dónde mira. El artículo que lo acompaña, presentado en arXiv el 20 de agosto de 2026 con doce autores, lo define como un sandbox que aporta "sesiones de herramientas compatibles con MCP aisladas, trazas de ejecución completas y evaluación del resultado sobre el estado final del sistema".

Por qué la transcripción no sirve como prueba

El ejemplo con el que Liang-Chun Tsai abre el anuncio de Microsoft es deliberadamente banal. Le pides a un agente de atención al viajero que añada a tu reserva de hotel la preferencia de habitación tranquila, lejos de ascensores y máquinas de hielo. El agente pide tu localizador, consulta la reserva y responde que la petición queda registrada.

La conversación parece un éxito. El campo special_requests de la reserva sigue vacío.

Ese fallo no lo detecta ningún evaluador que lea la respuesta. Tampoco lo detecta uno que compruebe la secuencia de llamadas a herramientas, porque la secuencia puede ser correcta y el efecto no producirse. Tsai lo resume así: "Tool order measures conformity to one reference trajectory", es decir, el orden de las herramientas mide la conformidad con una única trayectoria de referencia. Un agente razonable puede consultar antes el ticket, saltarse una búsqueda de perfil redundante o reintentar una lectura tras un error transitorio, y cualquiera de esos caminos completa la tarea.

Por eso ThinkingBox revisa los registros que quedan detrás. La pregunta que responde no es si el agente habló bien, sino si el sistema quedó como debía.

Cómo funciona por dentro

La pieza central es el MCP Session Proxy, un servidor HTTP de larga vida que escucha en el puerto 7111 y gobierna una flota de procesos de herramientas. Cada uno de ellos es un servidor MCP independiente, con el que el proxy habla por stdio con JSON-RPC, un proceso por servidor. Si te interesa el protocolo por debajo, tenemos una guía completa de MCP y otra sobre cómo construir tu propio servidor MCP.

El proxy expone cinco operaciones, y la lista sola ya cuenta el diseño:

Operación Para qué sirve
POST /session_create Levanta los servidores y crea una sesión aislada
POST /list_tools Devuelve los esquemas de las herramientas
POST /call_tool Ejecuta una llamada del agente
POST /get_effects Recupera lo que cambió en la sesión
POST /session_destroy Termina los procesos y libera la memoria

Cada servidor de herramientas implementa dos ganchos reservados: __reserved__init, que siembra el estado inicial, y __reserved__geteffects, que expone lo que se modificó. Ahí está el truco entero. Como el escenario arranca siempre desde el mismo estado y el propio servidor sabe declarar qué tocó, la comprobación final puede ser exacta en lugar de aproximada.

Un intento completo usa tres modelos distintos: uno hace de agente, otro de usuario simulado que contesta las preguntas de seguimiento, y un tercero actúa de juez donde hace falta criterio. El veredicto es una conjunción: todas las comprobaciones tienen que pasar. Y están escritas para aceptar trayectorias válidas mientras rechazan efectos equivocados, ausentes o sobrantes. Ese último caso es el que más se suele olvidar: un agente que además de reservar la habitación cancela otra cosa no ha completado la tarea.

Cómo se instala y se ejecuta

El objetivo probado es Linux, incluido WSL, con Python 3.12. La instalación recomendada usa uv:

git clone https://github.com/microsoft/thinkingbox.git
git clone https://github.com/microsoft/thinkingbox-data.git

cd thinkingbox
uv venv --python 3.12
uv sync --group dev

Todo pasa por una sola orden, tb, con ocho subcomandos. infer ejecuta un caso o un conjunto, mcp-start levanta el proxy, agg agrega métricas y sbs compara una candidata contra una base de referencia. pp imprime un resultado legible, y quedan dump-tests, run-test y tui para una sesión interactiva.

El repositorio del marco trae un único escenario, cloud_drive, cuya razón de ser es comprobar que la instalación funciona. En una terminal levantas el proxy y en otra lanzas el caso:

uv run tb mcp-start

uv run tb infer -c config/config_o4mini.yaml --dataset ./dataset \
  --agent think --name cloud_drive.py:test_append_some_more_text \
  --output output.yaml
uv run tb pp output.yaml

Para trabajo real apuntas el proxy al catálogo del repositorio de datos con uv run tb mcp-start --servers ../thinkingbox-data/servers/servers.yaml. Los modelos se configuran contra Azure OpenAI, tras un az login, o contra cualquier despliegue compatible con la API de OpenAI, con el ejemplo de vLLM que viene incluido.

Qué reveló ThinkingBox-Bench sobre los modelos de 2026

El banco tiene 507 flujos de trabajo condicionados por políticas, repartidos en cinco sectores. Son comercio minorista, viajes y hostelería, seguros de automóvil, soporte informático interno de un banco digital y soporte informático y de personal en consultoría. Se midieron doce modelos, seis propietarios y seis de pesos abiertos, con veinte intentos por tarea.

El resultado que hay que quedarse cabe en una línea del resumen del artículo. El mejor modelo alcanza un 65,36 % de aciertos al primer intento, pero solo un 25,25 % contando las tareas que le salen bien las veinte veces.

Métrica (GPT-5.4, el mejor medido) Valor
Acierto al primer intento 65,36 %
Acierto en los veinte intentos 25,25 %
Comercio minorista, primer intento 76,33 %
Seguros de automóvil, primer intento 62,65 %
Consultoría, primer intento 54,60 %
Mejor modelo de pesos abiertos (DeepSeek-V4-Pro) 43,26 %

Tsai lo formula con una frase que conviene tener a mano cuando alguien enseñe una demostración: "Retries raise the chance of getting one good result without making the agent dependable". Los reintentos aumentan la probabilidad de obtener un buen resultado sin volver fiable al agente.

Hay un detalle que me parece más incómodo que los porcentajes. Según el artículo, un intento fallido suele terminar limpiamente y con acciones válidas que modifican el estado. Es decir, el agente no se rompe: hace algo razonable que resulta ser lo que no era. Ninguna alarma de tu sistema va a saltar por eso.

En qué se diferencia de DeepEval, promptfoo o E2B

Esta es la parte donde se confunde mucha gente, porque las cuatro cosas se anuncian como herramientas para probar agentes y no compiten entre sí.

Herramienta Qué juzga Cuándo la quieres
DeepEval La calidad del texto que sale, con métricas sobre la respuesta Regresiones de calidad de respuesta y de recuperación
promptfoo Aserciones sobre salidas, comparadas entre variantes de prompt Elegir prompt o modelo con datos, en integración continua
E2B Nada: es el sitio donde el agente ejecuta código sin romper nada Dar al agente un entorno desechable para actuar
ThinkingBox El estado final del sistema tras una secuencia de turnos con herramientas Saber si el agente termina el trabajo de forma repetible

La línea que separa a ThinkingBox de los dos primeros es la persistencia. DeepEval y promptfoo evalúan una salida frente a un criterio. ThinkingBox deja que el agente actúe durante una secuencia de turnos sobre un sistema que recuerda, y luego compara ese sistema con lo que debería haber pasado.

La que lo separa de E2B es más simple todavía: E2B da un lugar seguro para ejecutar, y no emite ningún juicio. Son capas distintas, y en un sistema serio acabas queriendo las tres.

Cómo es un banco de tareas que sirve de algo

Si vas a escribir tus propios casos, el diseño de ThinkingBox sugiere cuatro exigencias que valen igual fuera de él.

La primera es que la tarea cambie algo. Una pregunta que se contesta leyendo no distingue a un agente competente de uno que suena competente.

La segunda es que las comprobaciones rechacen los efectos sobrantes, no solo comprueben los esperados; sin eso, un agente que hace lo pedido y además tres cosas más aprueba. La tercera es que haya información que falte al principio y que el agente tenga que pedir, porque coordinar una secuencia de turnos es justamente lo que se rompe en producción. La cuarta es repetir: veinte intentos por tarea suena excesivo hasta que ves que la diferencia entre el 65 % y el 25 % vive ahí.

Y conviene declarar la política del dominio por escrito, porque la mitad de los fallos interesantes no son de capacidad sino de obediencia a una regla que nadie escribió.

Los límites de probar dentro de un sandbox

Los autores son bastante honestos con esto, y merece la pena repetirlo porque es lo que un resumen de prensa se salta.

En 477 de las 507 tareas el veredicto depende únicamente del estado final y de los efectos secundarios. Su consecuencia la escriben ellos: un intento que ejecuta la transición correcta pero se la cuenta mal al usuario puede puntuar como éxito. Solo un subconjunto comprueba además propiedades de la respuesta final.

Las tareas son reconstrucciones sintéticas a partir de una colección no pública, y el artículo dice expresamente que no pretenden representar la distribución del trabajo real de una empresa. Además todas las trayectorias las moldea un único usuario simulado, más manejable que una persona. Nunca afirma algo que no sea cierto, nunca cambia de objetivo y sigue colaborando después de una racha de fallos.

Traducido a tu caso: un buen resultado aquí es condición necesaria y no suficiente. Sigue haciendo falta ver el sistema por dentro cuando está funcionando, con algo como Langfuse para la observabilidad de agentes. Y sigue haciendo falta decidir qué pasa cuando un paso se cae a medias, que es el terreno de la ejecución duradera con Temporal.

Preguntas frecuentes

¿Necesito Azure para ejecutar ThinkingBox?

No. El ejemplo que viene documentado usa Azure OpenAI, pero el marco admite cualquier despliegue compatible con la API de OpenAI y trae una configuración de ejemplo para vLLM. Sí necesitas Linux o WSL y Python 3.12.

¿Puedo usar sus datos en mi propio banco de pruebas?

Sí, con una condición. El marco es MIT, pero el repositorio de datos está licenciado por tipo de contenido. El código bajo servers/ es MIT, y los datos bajo dataset/, support/ y releases/ van bajo CDLA-Permissive-2.0[3], que obliga a acompañar el fichero de licencia cuando redistribuyes esos datos.

¿Sustituye ThinkingBox a mis pruebas actuales?

No sustituye a nada. Cubre un hueco que las evaluaciones de respuesta dejan abierto, que es la verificación del efecto. Si ya vas a desplegar un agente de IA en producción, esto es una capa más, y probablemente la que te faltaba.

Conclusión

ThinkingBox no es una herramienta que vayas a instalar el lunes y a mantener el resto del año. Es un marco de investigación pequeño, con 25 estrellas y trece confirmaciones en su rama principal cuando escribo esto, y se nota.

Lo que sí merece adoptarse de inmediato es su criterio: juzgar al agente por lo que quedó cambiado y exigirle que rechace los efectos sobrantes. Y repetir cada tarea hasta que la fiabilidad y la capacidad dejen de confundirse. Un 65 % que se convierte en un 25 % al repetir veinte veces es la única cifra que necesitas para justificar ese cambio de criterio. La versión en inglés de este artículo está en ThinkingBox: checking whether your agent does real work.

Fuentes

  1. github.com/microsoft/thinkingbox
  2. thinkingbox-data
  3. CDLA-Permissive-2.0
  4. Microsoft Command Line, cómo construimos ThinkingBox
  5. One Success Isn’t Reliability, arXiv 2608.19741

Ruta: Agentes de IA en producción: evaluación y fiabilidad