Protocolos de agentes AI: elegir por la evidencia que exponen

Elige los protocolos de agente AI por el límite que estandarizan, no por el acrónimo que aparece más a menudo. Utilice MCP cuando un host necesita herramientas o contexto. Utilice A2A cuando un agente opaco delega una tarea de estado a otro. Tratar a los ACP como una entrada migratoria, porque el proyecto ACP ahora dice que forma parte de A2A. Añadir protocolos más estrechos sólo para obligaciones más estrechas, como el pago o la autorización de pago. Luego añadir un verificador de resultados sobre cada protocolo: un apretón de manos exitoso, resultado de la herramienta, tarea terminal o recibo de pago son evidencia, pero ninguna prueba necesariamente que el trabajo previsto del usuario es correcto. Esa regla evita dos costosos errores. El primero es pedir un protocolo para resolver el descubrimiento, ejecución, monitoreo, autorización y verificación de negocios. El segundo es apilar protocolos que cruzan la misma frontera, creando más adaptadores sin crear más evidencia. Comience con el límite, luego inspeccione los recibos. Los protocolos actuales son más fáciles de razonar como capas. MCP cruza el límite del host a la herramienta. El Especificación del MCP de fecha 2025 11 25 define hosts, clientes y servidores; negociación de capacidades; recursos, instrucciones y herramientas; además de utilidades para el progreso, cancelación, errores y registro. Eso es un buen ajuste cuando un agente host necesita descubrir una herramienta de base de datos, leer un recurso o invocar una función externa a través de un contrato común. MCP no convierte al servidor en un agente remoto con un ciclo de vida de tareas portátil y duradero. Una solicitud de JSON RPC puede correlacionarse y una herramienta puede devolver contenido estructurado, pero una aplicación aún tiene que preservar la identidad de operación que es importante para la empresa. Si una herramienta de correo electrónico termina, un error de transporte no le dice si el destino aceptó el mensaje. Reutilizar el resultado del protocolo por sí solo puede duplicar el efecto. A2A cruza el límite de agente a agente. La Especificación A2A 1.0 actual define tarjetas de agente para el descubrimiento de capacidades, tareas con ID y estado estables, mensajes, artefactos, actualizaciones de transmisión, notificaciones push, recuperación y cancelación. Apoya explícitamente el trabajo de larga duración y humano en el circuito entre agentes que pueden mantener su memoria interna y herramientas opacas. Ese ciclo de vida extra es una evidencia significativa de salud. Un cliente puede distinguir una tarea que todavía está funcionando de una que está esperando entrada, completado, fallido, cancelado o rechazado. Puede recuperar la tarea después de que una corriente se desconecte e inspeccionar artefactos en lugar de tratar el cierre de la conexión como una finalización. Sin embargo, una tarea A2A COMPLETED todavía informa lo que el agente remoto cree que sucedió. El solicitante deberá comprobar que el artefacto cumple con el contrato original. ACP es ahora una cuestión de migración. El Repositorio ACP todavía documenta los manifiestos del agente, ejecuciones, sesiones, transmisión, solicitudes de espera, salidas y errores. En su anuncio actual destacado también se dice: ACP es ahora parte de A2A bajo la Fundación Linux. Para un servicio ACP existente, inventar la semántica en la que se basa y mapearlos a A2A. En el caso de un límite de agentes remotos de campo verde, tratar a ACP y A2A como apuestas independientes competidoras ignoraría el propio aviso de convergencia del proyecto. Domain protocolos agregan recibos de dominio. Guía para desarrolladores de protocolos de agentes actual de Google separa el acceso a herramientas MCP y la colaboración A2A de la caja de UCP y la autorización de pago AP2. Esa composición es defendible porque las capas responden a preguntas diferentes. UCP puede estructurar una operación comercial. AP2 puede vincular la autorización a una intención y producir un recibo de pago. Ningún recibo prueba que las mercancías hayan llegado o que hayan resuelto el problema del usuario. Por lo tanto, el incumplimiento razonable es: elegir el MCP para las herramientas y el contexto; elegir A2A para las tareas de agente remoto; migrar ACP en lugar de iniciar una segunda norma de agente a agente; añadir un protocolo de dominio sólo cuando sus recibos de tipografía coincidan con una obligación real de dominio; nunca permita que el éxito del protocolo sustituya la verificación de resultados. Puntuación de seis campos de pruebas, no recuento de características Una comparación de protocolo se vuelve operativa cuando cada fila responde a seis preguntas: 1. ¿Puede el que llama descubrir la capacidad y su contrato actual? 2. ¿Existe una identidad que sobreviva a retrasos, reconecta, y trabajo asincrónico? 3. ¿Puede la persona que llama distinguir entre el estado de trabajo, espera, fallo y terminal? 4. ¿Es representada la cancelación y se puede comprobar su efecto? 5. ¿Hay evidencia de que el efecto secundario externo ocurrió exactamente como se pretendía? 6. ¿Hay pruebas de que el resultado prometido por el usuario está presente y válido? Los primeros cuatro tienen forma de protocolo. Los dos últimos generalmente se cruzan en el estado de aplicación y negocio. Fronteras Mejor ajuste de corriente Pruebas nativas fuertes Las pruebas aún deben ser probadas. Host a las herramientas o contexto MCP Negociación de capacidades, solicitudes, progreso, cancelación, errores, resultados de las herramientas identidad de la operación comercial duradera, reconciliación de efectos externos, resultado final Agente opaco a agente opaco A2A 1.0 Tarjeta de agente, identificación de tarea, ciclo de vida, historial, artefactos, transmisión, cancelación Validación semántica de artefactos y prueba de resultados del usuario Servicio de agentes ACP existente Emigrar hacia A2A manifiesto, ejecutado, sesión, espera, salida, error en el contrato heredado Paridad de migración, pruebas de ejecución, resultado final Autorización de comercio y pagos UCP más AP2 la facturación tipografiada, la intención y los mandatos de pago, el recibo de pago entrega, aceptación, utilidad y cualquier trabajo no comercial Native no significa que cada implementación habilite o implemente una característica correctamente. Una tarjeta de agente puede estar obsoleta. Un servidor puede anunciar la transmisión y manejar mal las conexiones. Un resultado de la herramienta puede ser válido sintáticamente pero se refiere al cliente equivocado. Trate la capacidad anunciada, el comportamiento de transporte observado, el efecto registrado y el resultado verificado como recibos separados. Esta separación también no deja de esperar para parecer un fracaso. A2A tiene vocabulario de protocolo para el trabajo de larga duración y la entrada humana. El MCP dispone de instalaciones de obtención y progreso. Su capa de salud todavía necesita un propietario, fecha límite, recorrido y regla de frescura. Una espera válida sin propietario se abandona operacionalmente incluso si el estado del protocolo es legal. Ejecutar la auditoría de la deuda de pruebas antes de elegir un adaptador El artefacto que acompaña codifica cuatro escenarios y los seis campos de evidencia en protocol health matrix.json . Su auditoría no premia a un solo ganador. Selecciona el protocolo que coincida con el límite y informa de recibos parciales o faltantes. Ejecutar con: La fijación fija devuelve: Cada fila requiere un verificador de resultados. Ese es el resultado importante, no un protocolo de clasificación. Para la herramienta de base de datos, el envase puede registrar un ID de operación estable, el conjunto de filas esperado, el alcance de las autorizaciones y una consulta de postcondición. Para la investigación delegada, podría validar que cada pregunta requerida tiene una respuesta citada y que el artefacto se generó después de la solicitud. Para una migración ACP, debe reproducir los casos de espera, transmisión, cancelación y error contra ambas implementaciones antes de que se mueva el tráfico. Para una compra, debe conciliar la autorización firmada y el recibo de pago, y luego verificar por separado la aceptación y entrega del pedido. La auditoría marca deliberadamente algunas pruebas como parciales. La cancelación de MCP puede detener el trabajo del protocolo sin revertir una escritura externa. La cancelación de A2A puede producir una tarea cancelada mientras un sistema descendente permanece activo. AP2 puede presentar un recibo de pago sin demostrar el cumplimiento. Estos no son defectos de protocolo. Son hechos de límite que una aplicación debe hacer visibles. Mantenga la finalización del protocolo y la finalización del resultado separados Modela los dos veredictos explícitamente: Este registro rechaza un falso verde. El agente remoto ha completado su tarea de protocolo y ha suministrado un artefacto. El trabajo del usuario no está completo porque falta una respuesta requerida y las verificaciones de origen. La siguiente acción más segura es no reiniciar toda la tarea automáticamente. Es solicitar la evidencia limitada que falta, preservar la tarea original y las identidades del artefacto, y verificar el delta. Utilice la misma división para las llamadas de herramientas. Registro de la solicitud de transporte por separado de la conciliación de efectos. Si la herramienta se agotó después de enviar una escritura, consulta el destino con la clave de operación estable antes de volver a intentarlo. Si el protocolo no puede exponer una clave duradera, cree una en el límite de la aplicación. El cumplimiento de la orden es actividad; un estado de destino verificado es evidencia. La frescura pertenece a ambos veredictos. Una capacidad descubierta ayer puede haber desaparecido hoy. Una tarea terminada puede indicar un artefacto que más tarde fue reemplazado. Un recibo de pago puede ser válido mientras la entrega esté atrasada. Guarde la fuente, el tiempo de observación, el intervalo de actualización esperado y la confianza para cada señal decisiva. Una regla de selección compacta Utilice este orden durante la revisión de arquitectura: 1. Nombre el límite en una frase. 2. Lista de los estados de falla que el operador debe distinguir. 3. Seleccione el protocolo de corriente más estrecho que exponga esos estados. 4. Marque todos los recibos requeridos como nativos, parciales o desaparecidos. 5. Añadir pruebas de aplicación sólo para los campos parciales y faltantes. 6. Prueba de reconexión, espera, cancelación, entrega duplicada, descubrimiento obsoleto y casos falsos. 7. Solo limpie el trabajo después de que el resultado prometido pase su propio contrato. No compongan MCP y A2A simplemente porque ambos son populares. Componerlos cuando un agente remoto de A2A necesita herramientas MCP: A2A posee el estado de delegación y tarea, mientras que MCP posee el límite de herramientas de ese agente. Mantenga sus identificaciones vinculadas pero distintas. No agregue UCP o AP2 a menos que el flujo de trabajo tenga en realidad obligaciones de pago o pago. La matriz es una auditoría a nivel de especificación, no prueba de que un SDK o servidor particular interactúa correctamente. Las características opcionales, las extensiones, la autenticación, la autorización, el comportamiento de reconexión y la retención de telemetría necesitan pruebas de implementación. Los protocolos también evolucionan; se fija la versión de especificación utilizada por cada adaptador y se repite la auditoría antes de actualizarla. Sidewisp se encuentra actualmente en versión preliminar privada. Su dirección prevista es hacer más clara la salud de los agentes, la evidencia, los estados de espera y la verificación segura a lo largo de los tiempos de ejecución existentes; generalmente no se envían adaptadores de monitoreo de producción y sistemas de recuperación. El principio útil hoy en día es independiente de cualquier producto: elegir el protocolo para el límite, retener los recibos que puede proporcionar, y hacer imposible ignorar la prueba de resultado faltante.