Respuesta breve
Ese estado importa: le dice al constructor que consulte la documentación actual y espere cambios, no que trate una publicación de lanzamiento como una certificación para su propia aplicación.
Un lanzamiento comienza con alcance
El anuncio de OpenAI de septiembre de 2026 presenta la API de agentes como una versión beta pública. Ese estado importa: le dice al constructor que consulte la documentación actual y espere cambios, no que trate una publicación de lanzamiento como una certificación para su propia aplicación. Antes de escribir un mensaje, defina la tarea del usuario, los datos que el agente puede leer y las acciones que puede realizar. Separe la recuperación de información de las acciones que cambian un registro, envían un mensaje o gastan dinero. Un agente exitoso no es aquel que actúa siempre; A veces el resultado correcto es un rechazo, un aviso de incertidumbre o un traspaso a una persona. El alcance es el primer criterio de evaluación.
Pruebe el camino, no sólo la respuesta
La orientación de Anthropic sobre las evaluaciones de agentes enfatiza las tareas realistas y la secuencia de comportamiento detrás de un resultado final. Un agente puede producir una respuesta persuasiva después de utilizar la fuente incorrecta o recurrir a una herramienta que no necesitaba. Construya un conjunto de evaluación que incluya trabajo rutinario, información faltante, registros contradictorios e intentos de redirigir el sistema. Inspeccione cada rastro para elegir la herramienta, la evidencia, los límites de los permisos y el punto donde apareció la incertidumbre. Califica tanto el resultado como el proceso. Una demostración con un mensaje cuidadosamente preparado no es una prueba representativa de lo que sucederá cuando los usuarios presenten solicitudes imperfectas e impredecibles.
Los permisos y la confirmación deben ser visibles.
Proporcione a un agente el mínimo acceso necesario para la tarea. Un prototipo de solo lectura puede responder preguntas sin tener autoridad para editar el registro de un cliente o aprobar una compra. Si posteriormente se requiere acceso de escritura, especifique qué acciones necesitan confirmación humana, cómo se muestra el cambio propuesto y qué sucede cuando se niega la aprobación. La interacción debe hacer que los límites del agente sean comprensibles para el usuario. La automatización oculta puede resultar cómoda hasta que resulta difícil rastrear un error. Este principio es independiente de cualquier modelo o API: el propietario de la aplicación controla el flujo de trabajo circundante, las credenciales de la herramienta y el registro de auditoría.
Los límites de costes y la recuperación son parte de la calidad
Un agente que recorre llamadas de herramientas innecesarias puede ser lento y costoso incluso cuando la respuesta final parece razonable. Establezca límites de pasos, tiempos de espera y un presupuesto por ejecución, luego mida el uso real en el conjunto de evaluación. Registre qué errores se pueden reintentar de forma segura y cuáles requieren que una persona los revise primero. Planifique cómo desactivar una herramienta problemática o revertir una acción errónea. Un procedimiento de reversión es particularmente importante cuando una salida llega a un sistema externo. Es mejor descubrir un modo de falla en una prueba por etapas que aprender de un cliente cuyos datos ya han cambiado.
Mantener la evaluación después del lanzamiento.
La implementación cambia la distribución de los insumos. Los usuarios hacen preguntas desconocidas; los servicios conectados cambian sus respuestas; un modelo o una rápida actualización pueden alterar una ruta que alguna vez fue confiable. Mantenga muestras de fallas reales, elimine datos confidenciales cuando corresponda y convierta casos recurrentes en pruebas. Revise los rastros en busca de costos crecientes, acceso innecesario y evidencia débil, no solo la tasa de finalización. La utilidad de un agente debe seguir siendo observable y corregible a lo largo del tiempo. Nuestra portada es una escena de desarrollo ilustrativa, no una fotografía de OpenAI o del personal de Anthropic. Las fuentes vinculadas describen herramientas y métodos de evaluación; Los estándares para este servicio en particular aún deben ser definidos y verificados por el equipo que lo opera.
Una puerta de lanzamiento para un agente con herramientas.
Un agente puede parecer capaz en una demostración y al mismo tiempo fallar en el límite exacto que importa en producción. Defina la tarea en términos de un resultado observable antes de agregar herramientas. ¿Qué información recibirá, qué sistemas puede leer, qué acciones puede tomar y qué debe hacer cuando la solicitud es ambigua? La API de agentes de OpenAI proporciona una forma de crear flujos de trabajo agentes, pero una versión beta pública no es evidencia de que un flujo de trabajo en particular sea seguro para sus clientes. El propietario de la aplicación sigue siendo responsable de los permisos, los registros y la experiencia del usuario final.
Cree un pequeño conjunto de evaluación a partir de formas de tareas reales, incluidos casos comunes, instrucciones incompletas, datos contradictorios y solicitudes que el agente debe rechazar o escalar. Obtenga más de una respuesta final plausible. Inspeccione la secuencia de llamadas a herramientas, si el agente conservó la evidencia correcta, cuánto gastó y si un humano pudo reconstruir un error. La guía de evaluación de Anthropic es útil aquí porque el fracaso de un agente puede ocurrir a lo largo del camino incluso cuando su mensaje final suena confiado. Una demostración aprobada no sustituye a las pruebas repetidas en casos representativos.
Establezca límites al costo y al impacto de una carrera. Establecer un número máximo de pasos, un techo presupuestario, tiempos de espera y confirmación explícita ante acciones irreversibles. Prefiere el acceso de solo lectura hasta que el flujo de trabajo demuestre que necesita autorización de escritura. Un plan de reversión debe identificar quién puede desactivar el sistema y cómo se corregirá una acción errónea. Estos controles no son señales de que el modelo sea débil; hacen que el servicio sea inspeccionable. Sin ellos, un mensaje mal redactado puede convertirse en una cadena de llamadas a herramientas costosas o difíciles de revertir.
Después del lanzamiento, revise los seguimientos y los informes de los usuarios comparándolos con el mismo conjunto de evaluación en lugar de tratar la primera semana como una vuelta de victoria. Agregue fallas a las pruebas, documente cambios en el modelo o entorno de la herramienta y monitoree si una nueva característica altera silenciosamente una ruta previamente confiable. Nuestra imagen es una escena de desarrollo conceptual, no una fotografía de un equipo de producto específico. El estándar para un agente no es si puede completar una tarea sorprendente una vez. Se trata de si la tarea sigue siendo limitada, explicable y corregible cuando los usuarios reales aportan información inesperada.
Los casos de falla que vale la pena probar antes de que lo hagan los clientes
Un conjunto de evaluación debe incluir las fallas mundanas que rara vez aparecen en los videos de lanzamiento. Entregue al agente un documento al que le falta un campo, una respuesta de herramienta que llega tarde, dos fuentes que no están de acuerdo y una solicitud cuya acción autorizada no está clara. Comprueba si pide aclaraciones, conserva la evidencia original y se detiene ante una escritura arriesgada. Agregue casos en los que una página recuperada contenga instrucciones que no sean la solicitud del usuario. Un sistema que trata el contenido fuente como autoridad sobre su tarea real no es seguro incluso si puede resolver un ejemplo común y corriente. Estas pruebas no son garantía de perfección; Revelan si el diseño de control está funcionando.
Por cada ejecución fallida, mantenga suficiente contexto para reproducir la secuencia sin almacenar más información personal de la necesaria. Clasifique la falla: interpretación incorrecta, herramienta incorrecta, respuesta no respaldada, costo excesivo, incumplimiento de permiso o escalada inútil. Luego haga un cambio y vuelva a ejecutar el conjunto de referencia. Esto hace que la mejora sea observable. El lanzamiento de la API de OpenAI crea una nueva opción de construcción y el material de ingeniería de Anthropic ofrece un marco independiente para la evaluación, pero ninguno de los proveedores puede certificar una aplicación creada por otra persona. El equipo que implementa el agente debe demostrar los límites de su propio flujo de trabajo y conservar una ruta humana cuando el sistema sea incierto.
Una pregunta de liberación para el propietario.
Antes del lanzamiento, pregunte quién tiene la autoridad para pausar al agente y cómo sabrán que es necesario hacerlo. Defina un desencadenante concreto, como errores repetidos de permisos, escrituras externas no verificadas o un aumento repentino en el costo por tarea exitosa. Luego, ensaye el camino de pausa y recuperación en un entorno de puesta en escena. Esto suena más operativo que glamoroso, pero es donde la confianza en el producto se vuelve tangible. Un agente que sólo resulta útil cuando todos los sistemas conectados se comportan perfectamente no está preparado para su uso sin supervisión. La API proporciona componentes básicos; el propietario debe proporcionar los límites, las pruebas y el proceso de respuesta en torno a ellos.