AI Observabilidad del agente para las fallas de las herramientas: prueba de cinco capas

Un agente AI puede no utilizar una herramienta incluso cuando su modelo es receptivo, su proceso está vivo y la llamada de la herramienta aparece en un rastro. Por lo tanto, el defecto práctico para la observabilidad del agente AIZ es probar una llamada de herramienta en cinco capas ordenadas: transporte, protocolo, autorización, ejecución y resultado. Deténgase en la primera capa fallida. Esa regla convierte una alerta ambigua herramienta no disponible en una reparación limitada, y evita que un sobre de respuesta verde sea confundido con el trabajo entregado. Esta guía aplica la regla a las herramientas de estilo MCP sobre HTTP y JSON RPC, pero la forma de diagnóstico también funciona para herramientas REST personalizadas y adaptadores de comandos locales. El objetivo no es recopilar todas las solicitudes o cargas útiles. Es conservar la menor evidencia necesaria para responder: ¿dónde se detuvo la llamada, qué autoridad se requiere y el resultado prometido llegó a su destino? Comience con la primera capa fallida Un solo contador tool call failed se derrumba por fallos que requieren respuestas incompatibles. Un error DNS puede justificar un nuevo intento de conectividad limitada. Un token expirado puede justificar una actualización. El alcance faltante requiere una persona o un administrador; volver a intentar lo mismo es un desperdicio. Una respuesta de herramienta válida sin cambios de archivo, boleto, mensaje o base de datos necesita investigación de resultados, no reparación de transporte. Utilice esta prioridad: Capa Evidencias mínimas Ejemplos de fracasos El siguiente movimiento razonable Transporte resultado de la conexión, estado HTTP, tiempo transcurrido Fallo DNS, conexión rechazada, HTTP 503 comprobar la accesibilidad; volver a intentarlo sólo dentro de un presupuesto fijo Protocolo Identificación de solicitud, método, código de error JSON RPC Falta el método 32601 , parámetros inválidos 32602 actualizar el descubrimiento o fijar el contrato de solicitud Autorización Estatus HTTP, error de autor desinfectado, alcance requerido 401 invalid token , 403 insufficient scope actualizar una vez o solicitar a la autoridad ausente Ejecución estado del resultado de la herramienta, tiempo de espera, veredicto del esquema de salida MCP isError: true , tiempo de espera, salida estructurada malformada inspeccionar la implementación o entrada de la herramienta El resultado Verificador de destino y frescura La respuesta dice "creado", pero el artefacto está ausente. verificar el destino; no declarar la finalización El orden importa. Si la resolución DNS falla, la autorización y el resultado son unobserved , no fallaron. Emitir cinco fallas por una pausa temprana aumenta el número de incidentes y envía a los que responden a pruebas que nunca existieron. Mantenga el fallo del protocolo separado del fallo de la herramienta La invocación de herramientas MCP utiliza tools/call , mientras que la definición de herramientas lleva una inputSchema y puede llevar una outputSchema . El Especificación de las herramientas de MCP actual también muestra un resultado de herramienta con isError: false . Esos son puntos de control distintos: el cliente puede llegar al servidor, intercambiar una respuesta JSON RPC válida, y aún así recibir una falla a nivel de herramienta. JSON RPC hace explícita la distinción externa. Su Especificación 2.0 reserva 32601 para Método no encontrado y 32602 para Parámetros inválidos; una respuesta de error contiene error , mientras que una respuesta exitosa contiene result . Un JSON RPC result sólo prueba que el intercambio de protocolos se ha completado. No demuestra que la herramienta haya aceptado la operación, que su salida estructurada coincida con el esquema anunciado o que exista el efecto secundario externo. Graba el límite sin almacenar argumentos sensibles: Este evento omite deliberadamente el token portador, los argumentos de herramientas, el cuerpo de respuesta, el texto del boleto y los caminos absolutos. Identificadores de hash o mapas cuando se necesitan conjuntos de ejecución cruzada. Una identificación de rastro es útil sólo si el historial médico todavía puede explicar la primera capa fallida y el veredicto final cuando el rastro crudo no está disponible. No vuelva a intentar un problema de autoridad como si fuera una pérdida de paquetes La autorización merece su propia capa porque 401 y 403 implican diferentes acciones. El Especificación de la autorización del MCP requiere que los clientes manejen 401 Unauthorized y describe el descubrimiento de recursos protegidos a través de WWW Authenticate . También recomienda una orientación de alcance para que el cliente pueda conocer la autoridad requerida para la solicitud actual. RFC 6750 define invalid token para un token portador expirado, revocado, malformado o de otra manera inválido y lo asocia con HTTP 401. Se define insufficient scope para un token que carece de los privilegios requeridos y lo asocia con HTTP 403. Eso le da a un operador una regla de decisión segura: 1. Para invalid token , intente el camino de actualización configurado una vez. Si la credencial actualizada falla, deténgase y aparezca el titular de la credencial. 2. Para el insufficient scope , no haga bucle. Indique el alcance requerido si el servidor lo proporciona y solicite una autoridad explícita. 3. Nunca ponga el token, refresh token, autorization header, o desafío en bruto en la telemetría de propósito general. Esta distinción también evita un patrón de automatización perjudicial: ampliar los permisos cada vez que falla una llamada de herramienta. Un incidente de conectividad no debe convertirse en una escalada de privilegios, y una negación de alcance no debe ser fijada silenciosamente cambiando a una credencial más poderosa. Reproduce la brecha de falsos resultados El dispositivo de acompañamiento contiene ocho llamadas sintéticas: dos fallos de transporte, un error del método JSON RPC, dos fallos de autorización, un error de ejecución de la herramienta, un fallo de éxito y una entrega verificada. Ejecutar el clasificador desde el directorio de artefactos: El resultado decisivo es: Tres llamadas devolvieron un envase de resultados, pero sólo una produjo un resultado verificado por el destino. Un sobre llevaba un error de ejecución; otro reclamaba éxito mientras que su artefacto prometido estaba ausente. Los resultados del protocolo de conteo reportarían una tasa de éxito del 37,5%. El recuento de los resultados verificados informa del 12,5%. La diferencia no es una puntuación del detector o un juicio de LLM: proviene de cambiar el criterio de finalización. La fijación es intencionalmente determinista. Los sistemas reales añaden ambigüedad: una API de boletos puede comprometer un registro y tiempo de descanso antes de devolver su ID; una búsqueda de destino puede ser obsoleta; una clave de idempotencia puede permitir una consulta de reconciliación segura. Marque esos casos uncertain . No vuelva a intentar una llamada con efectos secundarios hasta que sepa si se cometió el primer intento. Convertir la evidencia en una regla de funcionamiento Instrumento un evento de salud por intento de operación de la herramienta, vinculado a la carrera de propiedad. Preserva la primera capa fallida, el código desinfectado, la frescura de la evidencia, el propietario de la prueba y el verificador de resultados. Luego aplica cuatro controles: Alerta sobre incidentes agrupados, no todos los intentos. Cinco llamadas que no obtienen la misma credencial vencida son un incidente de autoridad. Cap vuelve a intentar por capa. Los fallos de transporte pueden recibir un respaldo limitado; los fallos de protocolo y alcance generalmente requieren un contrato o un cambio humano. Distingue entre esperar y quedar atrapado. Una llamada esperando un flujo OAuth aprobado no está progresando, pero no es un bucle de ejecución. Eliminar el incidente sólo después de que la capa fallida pase and se observa el resultado previsto. Un comando exitoso es actividad, no recuperación. Por consiguiente, la fila útil del tablero de instrumentos es pequeña: agente afectado, primera capa fallida, impacto, tiempo de prueba, confianza, recuento de retas, autoridad requerida y resultado del verificador. Las huellas crudas pueden seguir siendo un simulacro. Esta es la salud del agente operativo, no un requisito para reemplazar el tiempo de ejecución o la ruta de cada solicitud de modelo a través de una nueva puerta de enlace. También hay una dura limitación. No todos los resultados tienen un verificador determinista. Un archivo se puede comprobar por camino y digestión; un boleto por ID estable; un despliegue por punto final de salud y revisión. La investigación es buena puede requerir una revisión rubrica o humana. Etiquetar el método y la confianza junto al veredicto en lugar de convertir la evidencia faltante en saludable. Sidewisp se encuentra actualmente en versión preliminar privada. Por lo general, no se envían sus adaptadores de monitoreo de producción y ejecución de recuperación. La dirección planificada es una capa de salud junto con los tiempos de ejecución existentes que separa la accesibilidad, el progreso, el acceso a las herramientas y los resultados verificados mientras mantiene a los humanos en control. Si ese modelo de operación coincide con sus agentes, Únete a la vista previa privada. Fuentes Modelo de Protocolo de Contexto: Herramientas, versión de especificaciones 2025 11 25 Modelo de Protocolo Contextual: Autorización, versión de especificación 2025 11 25 JSON RPC 2.0 Especificación RFC 6750, OAuth 2.0 Uso de las fichas del portador