Artículo
SpireClimb: cómo diseñar una prueba útil para tu agente
1. Lo que informa la fuente primaria
Epoch AI publicó el 14 de octubre de 2026 el informe SpireClimb, de Benjamin Ou y Simon Chen. En Slay the Spire, a dificultad máxima, GPT-6.1 Sol obtuvo 20% de victorias y GPT-6 Astra, 17%.
La prueba utiliza un agente visual basado en Inspect ReAct, semillas fijas y quince intentos por personaje. Permite notas y consulta de la wiki; fija la secuela en v0.107.1. Los autores señalan conocimiento previo, posible entrenamiento específico, errores de interfaz y muestras pequeñas. No demuestra productividad laboral.
Fuente: Epoch AI.
2. Empezar por la decisión que quieres evaluar
Marco editorial propio: las siguientes propuestas son un diseño de prueba, no conclusiones del estudio.
Una partida obliga a observar una situación, elegir una acción y comprobar sus consecuencias. Esa secuencia sirve para formular preguntas sobre un agente. ¿Qué información recibe antes de decidir? ¿Puede corregirse? ¿Qué evidencia conserva? La conexión útil está en esas preguntas; la respuesta debe medirse en la tarea concreta.
Antes de elegir herramientas, escribe la decisión que necesitas tomar: «¿Podemos dejar que este agente prepare una propuesta para revisión?». Define también qué resultado cambiaría tu decisión. Sin ese acuerdo, una demostración vistosa puede terminar sustituyendo una evaluación.
3. La interfaz forma parte de la tarea
En tu prueba empresarial, distingue leer, decidir y ejecutar. Si el agente selecciona el cliente correcto pero escribe en otra ficha, el resultado final debe reflejar ese error. Si interpreta mal un dato visible, conserva la observación que recibió para poder reconstruir el fallo.
Elige una interfaz según el uso previsto. Si las personas operarán con una pantalla, una prueba por pantalla resulta pertinente. Si el producto usará una herramienta estructurada, evalúa esa herramienta. Comparar ambos caminos puede ser útil, siempre que los registres como condiciones distintas. Cambiar el acceso durante una prueba cambia la pregunta que estás evaluando.
4. Herramientas, memoria y presupuesto explícitos
Escribe un inventario de permisos: consultar documentos, buscar un producto, proponer cambios o confirmar una operación. Cada permiso debe tener un motivo ligado al objetivo. En una prueba inicial, puedes separar la propuesta de la confirmación mediante revisión humana.
Define qué información puede conservar el agente entre pasos y qué debe volver a comprobar. Si reinicias una tarea, documenta qué memoria permanece. Así podrás distinguir una corrección realizada durante el intento de una ventaja heredada del intento anterior.
Fija además límites de tiempo, acciones y consumo. No hace falta adivinar un presupuesto perfecto: hace falta declarar uno, observar cuándo se agota y decidir cómo valorar una entrega incompleta.
5. Una tabla para convertir dudas en reglas
| Duda concreta | Regla propuesta | Evidencia que conservar |
|---|---|---|
| ¿Leyó el documento correcto? | Identificar versión antes de actuar | Referencia del documento y dato consultado |
| ¿Puede modificar información? | Delimitar campos y pedir revisión al confirmar | Propuesta y aprobación correspondiente |
| ¿Qué ocurre si falta un dato? | Detener esa decisión y explicar la ausencia | Campo pendiente y solicitud de aclaración |
| ¿Cuándo termina el intento? | Comprobar resultado y límites acordados | Estado final y motivo de cierre |
Una regla útil permite reconocer tanto el acierto como el fallo. «Ser cuidadoso» necesita convertirse en una conducta observable para poder evaluarse.
6. Ejemplo hipotético: preparar una cotización
Imagina una empresa chilena que quiere probar un agente para preparar cotizaciones. Este ejemplo es inventado: no describe una implementación ni un resultado de Epoch.
La entrada contiene una solicitud ficticia, un catálogo de prueba y condiciones comerciales expresamente definidas. El agente debe identificar productos, cantidades y datos faltantes; después prepara un borrador para que una persona lo revise.
Introduce un caso con dos productos parecidos y otro con una condición ausente. Antes de ejecutar, acuerda si el agente puede ofrecer alternativas o debe preguntar. Un borrador completo no cuenta como correcto si resolvió una ambigüedad inventando una condición.
El éxito exige concordancia con las fuentes entregadas, cálculo revisable y detección de ausencias. La prueba termina antes de enviar la cotización. No se atribuyen ahorro, ventas ni precisión a este ejemplo.
7. Observar el recorrido sin premiar solo el final
Guarda las entradas, acciones relevantes y comprobaciones del intento. Una salida correcta puede requerir revisar cómo se obtuvo: quizá el agente utilizó un dato no permitido o necesitó una intervención que no registraste.
Prepara una ficha por intento con la condición inicial, el resultado, los errores y la ayuda recibida. Distingue «resolvió», «necesitó aclaración» y «se detuvo correctamente». En una tarea ambigua, detenerse puede ser la conducta esperada.
Para comparar cambios, conserva el escenario y modifica una condición declarada cada vez. Si cambias simultáneamente instrucciones, herramientas y documentos, podrás observar el resultado conjunto, pero tendrás menos base para explicar qué cambio produjo la diferencia.
8. Del juego al trabajo: una hipótesis por comprobar
Un entorno de juego permite plantear decisiones encadenadas; una tarea empresarial exige definir sus propias consecuencias, permisos y criterios. La analogía ayuda a diseñar observaciones, pero no autoriza a trasladar porcentajes.
Pregunta qué significa equivocarse en tu proceso. ¿Una selección incorrecta puede revertirse? ¿El destinatario verá la salida? ¿Quién comprueba una condición comercial? Estas respuestas determinan qué fallos necesitan revisión y qué acciones pueden probarse con datos ficticios.
También pregunta por las exclusiones. Una prueba puede evaluar preparación de borradores y dejar pendiente el envío. Su conclusión debe conservar ese alcance. Pasar a otra etapa requiere evaluar las condiciones añadidas, incluida la intervención de otras personas.
9. Las preguntas que deberían acompañar la próxima demo
Antes de aceptar una demostración, pide respuestas concretas: ¿qué podía observar el agente?, ¿qué herramientas tenía?, ¿cuándo recibió ayuda?, ¿qué consumió?, ¿cómo se definió el éxito?, ¿qué errores se conservaron? Añade una pregunta decisiva: ¿qué sigue sin haberse probado?
Usa las respuestas para elegir el siguiente experimento. Si falló al leer, revisa la observación; si inventó una condición, revisa la regla de aclaración; si actuó fuera del alcance, revisa los permisos. Después vuelve a medir la tarea delimitada.
En la Comunidad gratuita puedes compartir una ficha de prueba con datos ficticios: objetivo, acceso permitido, criterio de éxito y duda pendiente. Una pregunta bien delimitada permite discutir cómo comprobarla sin convertir una promesa en un resultado.