"En la actualidad, x402 es solo una "loli" 😅 en la pista de pago He experimentado x402 en los últimos días, desde el punto de vista de un ingeniero, todavía hay mucho margen de mejora en esto, y habrá varios problemas que dificultarán el desarrollo general de x402. Si no se pueden resolver, creo que solo pueden permanecer en la etapa de concepto y no se pueden aplicar a gran escala. 1. Complejidad de la incrustación de ⚙️ ingeniería x402 proporciona un SDK de recuperación y algún middleware HTTP para implementar esta función de pago. Pero el paquete fetch es en realidad un paquete especial, si necesita usarlo, entonces en el código solo puede usar su fetch para acceder fácilmente, de lo contrario, debe completar manualmente una lógica de acceso muy compleja. Al mismo tiempo, se prioriza el acceso al middleware, aunque ya es compatible con los marcos convencionales, pero aún debe perfeccionarse. Por supuesto, este es el problema más pequeño, y con el desarrollo del ecosistema, estos problemas son cosas pequeñas después de todo. 2. No se produjeron cambios 🧩 esenciales Aunque el código de estado 402 suena fanfarrón e impresionante, en realidad no importa lo que devuelva en absoluto, puede devolver un 402, 200 con un json o cualquier cosa y un montón de datos. Esencialmente, es solo una encapsulación de ingeniería que agrega un proceso de pago. 3. Falta de fiabilidad ⏱️ en las llamadas de alta frecuencia En el caso del segundo artículo, surgirá un problema, que es el llamado problema de alta frecuencia. Sabemos que el concepto dominante actual es que AI Agent llama a una API para obtener datos u otro contenido, pero con la adición de esta lógica de pago, todo el proceso se vuelve muy largo. Las solicitudes de baja frecuencia de AI Agent están bien (porque los agentes ya son lentos para realizar solicitudes...... Una vez que ingresa a una solicitud de alta frecuencia, el tiempo de solicitud de una API se duplicará y una solicitud de API puede extenderse de 3 a 10 veces la original (la prueba oficial es que cada solicitud se retrasa 2 segundos, pero creo que son datos optimistas). Si necesito obtener muchos datos, el tiempo de todo el proceso es devastador. Debido a que aumenta la cantidad de solicitudes y también debe esperar la confirmación de la transacción en cadena y el retraso de RPC, las API de alta frecuencia básicamente no pueden elegir el modo x402 actual (por supuesto, se puede modificar en el futuro). 4. Procesos extremadamente imperfectos 🔁 Como protocolo orientado al pago, no veo el rigor de este producto como un middleware financiero en absoluto. No tengo idea de cómo maneja la solicitud real después del pago debido a las fluctuaciones de la red, y no veo ninguna relación vinculante entre las solicitudes de API y los registros de transacciones. En el caso tradicional de Web2, el pago no solo tiene un método de devolución de llamada (una vez completado el pago, se redirigirá a la página designada por el comerciante), sino también una nueva solicitud periódica (si no se ejecuta la devolución de llamada, será de 3 segundos, 5 segundos, 1 minuto,。。。 espere un período de tiempo para intentar volver a llamar hasta evitar con éxito que se pierda la transacción). No lo veo en absoluto en x402. Es como si fueras un pequeño comerciante en un puesto callejero y compraras algo en un supermercado. Compras algo en el puesto, no hay factura, ni información del producto, ni cantidad, y cuando vuelves a casa, te encuentras con que las cosas que compraste están podridas, y solo quieres defender tus derechos y descubrir, oye, este puesto ya se ha escapado. Pero cuando compras algo en el supermercado, al menos hay uno físico, hay una factura, hay un seguimiento, y si te encuentras con un Donglai gordo, incluso puedes disfrutar de un reembolso incondicional. x402 como producto de gama B, ahora esta cosa no está calificada y no es responsable. 5. Apenas hay proceso ⚖️ regulatorio Sé que mucha gente piensa que ninguna supervisión es algo bueno, la llamada descentralización, lo que se paga es que no hay KYC y no hay supervisión, no hablaremos de la frecuente ocurrencia de incidentes de seguridad causados por la implementación de nuevas tecnologías aquí, hablemos de un llamado proveedor de API, si debido a varios problemas, proporciona datos no conformes, o porque la cantidad de solicitudes es demasiado grande, lo que resulta en un error en una determinada solicitud del comerciante, o una serie de solicitudes son incorrectas, pero ya ha pagado, ¿cómo reembolsa la pregunta? No veo ningún mecanismo relevante en este momento, es decir, si un día tienes mala suerte y te quedas atascado en la red después de pagar, o ellos se atascan en la red, o se atascan en el servicio, o lo actualizas, entonces felicidades, tu pago no es válido. Luego estás buscando cómo reembolsar, y después de mirar mucho a tu alrededor, encuentras que jeje, no hay ninguno, nadie puede ser responsable de este comportamiento de pago, a lo sumo vas al proveedor, dices que has pagado, pero no brindaste el servicio, y luego juegas la pelota durante meses. Si no tiene suerte, el proveedor de servicios no tiene suficiente monitoreo para el código y ni siquiera podrá encontrar su registro de solicitud.

@taowang1 @Cloudflare Escribir mal nombre barato