Các đại lý AI giờ đây có thể tự thanh toán nhờ x402 và HTTP 402

Đó là tháng 1 năm 1997. Các (Internet Engineering Task Force) vừa phát hành chính thức định nghĩa Các thông số kỹ thuật được viết bởi các nhà tiên phong web , , , và , các kiến trúc sư đã định hình cách Internet giao tiếp. IETF RFC 2068 HTTP/1.1 bởi Roy Fielding Jim Gettys Jeffrey Mogul HENRIK FRYSTYK Tác giả Tim Berners-Lee IETF Công ty RFC 2068 bởi Roy Fielding Jim Gettys Jeffrey Mogul HENRIK FRYSTYK Tác giả Tim Berners-Lee Specification giới thiệu : trước đây, mỗi yêu cầu HTTP yêu cầu một kết nối TCP mới. kết nối liên tục giải quyết điều này, cho phép nhiều yêu cầu HTTP chảy qua một kết nối TCP duy nhất, kéo dài. không còn thiết lập các kết nối riêng biệt cho mỗi hình ảnh, tệp CSS, hoặc đoạn JavaScript trên một trang web. persistent connections Ngoài ra còn có , một cách mới cho các máy chủ web để phát trực tuyến nội dung mà không biết kích thước đầy đủ trước. không còn một máy chủ cần phải tính toán tổng kích thước của nội dung được tạo động trước, nó bây giờ là tự do để cung cấp dữ liệu dần dần, khi nó được sản xuất. chunked transfer encoding Nhưng Mã trạng thái mới: RFC 2068 quietly introduces something intriguing HTTP 402 Payment Required This code is reserved for future use. Điều này cho thấy làm thế nào những người sáng lập của World Wide Web dự đoán làm thế nào tiền cuối cùng sẽ trở thành một phần lớn của Internet. . even if they had no clear path on how it would actually play out Ngày nay, năm 2025, gần ba thập kỷ và nhiều phiên bản HTTP sau đó ( Trong năm 2015, Đến năm 2022, Mặc dù cuộc cách mạng fintech, sự trỗi dậy của thanh toán trực tuyến, và toàn bộ nền kinh tế được xây dựng trên các giao dịch internet, không ai biết phải làm gì với nó. HTTP/2 HTTP/3 Status Code 402 still sits there with the exact same note: 'reserved for future use.' Until now. Tháng trước (tháng 5 năm 2025), Giải phóng , một giao thức mã nguồn mở cung cấp công việc thực sự đầu tiên của mình: cho phép người bản xứ thanh toán trong các yêu cầu HTTP. Coinbase x402 HTTP 402 onchain Ngày nay, các nhân viên cần phải (machine-to-machine) thanh toán trên web với giảm Các can thiệp (con người trong vòng tròn) nhưng các luồng thanh toán truyền thống không hoạt động tốt trong trường hợp này. chúng đòi hỏi nhiều tương tác của con người, chuyển hướng và các bước thủ công mà chỉ đơn giản là không hoạt động khi một đại lý AI cần thực hiện một giao dịch một cách độc lập. M2M HITL Nó đề xuất một luồng thanh toán tự động trên chuỗi được thực hiện tự nhiên trong giao thức HTTP, . x402 making them as seamless as any other web request Nhưng điều này trông như thế nào trong thực tế? Kiến trúc và các thành phần của x402 x402 được xây dựng xung quanh bốn thành phần cốt lõi: x402 Thì a là hoạt động như người khởi xướng thanh toán, khám phá những gì được yêu cầu để truy cập và xây dựng tải trọng thanh toán thích hợp. Nói một cách đơn giản, đây là bất cứ điều gì đang làm cho yêu cầu HTTP thành một tài nguyên có tường trả tiền. Nó có thể là một trình duyệt làm cho một yêu cầu cho nội dung cao cấp, một đại lý AI mua API truy cập, hoặc một ứng dụng di động mở khóa các tính năng. client Các thực thi các chính sách thanh toán cho các điểm cuối của nó trong khi vẫn tập trung vào logic kinh doanh cốt lõi của nó. Đây là máy chủ web hoặc API lưu trữ nội dung hoặc dịch vụ được mua. Nó duy trì các bảng giá đơn giản mà bản đồ điểm cuối để chi phí, nhưng chuyển giao logic xác minh thanh toán cho người hỗ trợ. resource server Logic Blockchain được thực hiện trong thành phần: xác minh chữ ký mã hóa, ngăn chặn các cuộc tấn công tái phát thông qua theo dõi nonce, và quản lý thanh toán trên chuỗi thực tế. Nó cho phép cả khách hàng và máy chủ làm việc với thanh toán trên chuỗi mà không hiểu chi tiết triển khai blockchain. facilitator Có nằm ở tầng thanh toán cuối cùng, đảm bảo thanh toán không thay đổi và minh bạch. Nó cho phép tiền có thể lập trình thông qua các hợp đồng thông minh và stable-coins, . blockchain but its complexity is completely hidden from the application layer by the facilitator : Client Trách nhiệm chính: Bắt đầu thanh toán Các tính năng chính:Đăng ký EIP-712, trả lại tự động, phát hiện thanh toán Nó làm gì: Gửi yêu cầu, xử lý ví, trả lại với thanh toán : Resource Server Primary Responsibility: Payment enforcement Các tính năng chính: Bảng giá, phản hồi HTTP 402, tích hợp middleware Nó làm gì: Đặt giá, kiểm tra thanh toán, cung cấp nội dung : Facilitator Trách nhiệm chính: Kiểm tra thanh toán Các tính năng chính: Kiểm tra chữ ký, theo dõi nonce, trừu tượng khí Nó làm gì: Kiểm tra chữ ký, nói chuyện với blockchain : Blockchain Trách nhiệm chính: Thanh toán Các tính năng chính: Chuyển khoản USD, hợp đồng thông minh, hồ sơ không thay đổi Nó làm gì: Giải quyết thanh toán trên chuỗi Nguyên tắc Kiến trúc này thể hiện một số nguyên tắc cơ bản của kỹ thuật phần mềm. Mỗi thành phần có một trách nhiệm duy nhất, được xác định rõ ràng. . separation of concerns Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction Hệ thống đạt được bằng cách có các thành phần tương tác chỉ thông qua giao diện HTTP và REST chuẩn hóa. Sự cô lập này có nghĩa là bạn có thể trao đổi các thành phần (ví dụ, sử dụng một blockchain khác, thay đổi nhà cung cấp facilitator, hoặc sửa đổi logic máy chủ) mà không ảnh hưởng đến phần còn lại của hệ thống. loose coupling A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementation Các facilitator thể hiện các bằng cách cô lập tất cả sự phức tạp của blockchain thành một dịch vụ chuyên biệt. điều này ngăn chặn logic thanh toán rò rỉ vào các ứng dụng kinh doanh và giữ cho các mối quan tâm được tách rời một cách chính xác. single responsibility principle Cuối cùng nhưng không kém phần quan trọng, kiến trúc này sau Các thành phần cấp cao phụ thuộc vào trừu tượng thay vì thực hiện cụ thể. máy chủ và khách hàng phụ thuộc vào giao diện HTTP, không phải API blockchain cụ thể. Điều này cho phép cùng một mã ứng dụng để làm việc trên các blockchain khác nhau và các chương trình thanh toán mà không cần sửa đổi. dependency inversion flow thanh toán Khi một đại lý AI hoặc người dùng nhấn một -enabled API, đây là dòng chảy bốn bước xảy ra: x402 Yêu cầu ban đầu: Khách hàng thực hiện một yêu cầu HTTP tiêu chuẩn để truy cập một số tài nguyên Trả lời yêu cầu thanh toán: Nếu không có thanh toán được đính kèm, máy chủ sẽ trả lời bằng HTTP 402 và bao gồm các chi tiết thanh toán Quyền ủy quyền thanh toán: Khách hàng tạo một khoản thanh toán được ký mã hóa và trả lại yêu cầu Xác minh và truy cập: Máy chủ xác nhận thanh toán, phát sóng nó đến blockchain và cấp quyền truy cập Điều làm cho điều này mạnh mẽ là tất cả mọi thứ xảy ra ở cấp độ giao thức HTTP. Không chuyển hướng đến các bộ xử lý thanh toán của bên thứ ba, không dòng, không tạo tài khoản. OAuth Just standard HTTP with extra headers: X-PAYMENT chảy từ khách hàng đến máy chủ và chứa khối lượng thanh toán được ký kết. Điều này bao gồm chi tiết thanh toán (số tiền, người nhận, token) cộng với một chữ ký mã hóa chứng minh rằng khách hàng đã ủy quyền thanh toán. flows from server to client after successful payment and contains , providing transparency about what happened on-chain. X-PAYMENT-RESPONSE transaction receipt information Thì Server-side thực hiện Kiến trúc Middleware Việc thực hiện bên máy chủ cốt lõi xoay quanh một bộ lọc thanh toán (AKA middle-ware) chặn các yêu cầu HTTP và thực thi các yêu cầu thanh toán. Khi được tích hợp vào máy chủ web của bạn, middle-ware này kiểm tra các yêu cầu đến với một bảng giá mà bản đồ điểm cuối với chi phí của họ. Trung bình theo một cây quyết định đơn giản: nếu một yêu cầu đạt đến một điểm cuối được bảo vệ mà không cần thanh toán, nó đáp ứng với và các hướng dẫn thanh toán chi tiết. Nếu thanh toán được bao gồm trong header, nó xác minh thanh toán với một dịch vụ facilitator trước khi cho phép yêu cầu tiến hành. HTTP 402 X-PAYMENT Dưới đây là cấu trúc thiết yếu từ việc thực hiện Java: public class PaymentFilter implements Filter { private final String payTo; private final Map priceTable; // path → amount private final FacilitatorClient facilitator; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String path = req.getRequestURI(); String paymentHeader = req.getHeader("X-PAYMENT"); if (!priceTable.containsKey(path)) { chain.doFilter(request, response); // Free endpoint return; } if (paymentHeader == null) { send402Response(resp, path); // Request payment return; } // Verify payment, process request, then settle VerificationResponse verification = facilitator.verify(paymentHeader, requirements); if (verification.valid) { chain.doFilter(request, response); facilitator.settle(paymentHeader, requirements); } } } Bạn chỉ cần thêm bộ lọc thanh toán vào stack trung bình của bạn và xác định điểm cuối nào yêu cầu thanh toán. The beauty of this approach is that it requires minimal changes to existing applications. Trả lời PaymentRequirements Khi một máy khách chạm vào một điểm cuối được bảo vệ mà không cần thanh toán, máy chủ xây dựng một đối tượng yêu cầu thanh toán chi tiết. ), địa chỉ ví nhận, mạng blockchain và thời gian hết hạn để ngăn chặn các cuộc tấn công tái phát. USDC private void send402Response(HttpServletResponse response, String path) throws IOException { response.setStatus(HttpStatus.PAYMENT_REQUIRED); response.setContentType("application/json"); PaymentRequirements requirements = PaymentRequirements.builder() .paymentRequirement(List.of( PaymentRequirement.builder() .kind(new Kind("exact", "base-sepolia")) // Payment scheme + blockchain network .receiver(payTo) // Wallet address to receive payment .amount(priceTable.get(path)) // Cost for this specific endpoint .asset(" ") // USDC token contract .expiry(Instant.now().plus(Duration.ofMinutes(5))) // Payment window .nonce(UUID.randomUUID().toString()) // One-time use identifier .build() )) .build(); response.getWriter().write(Json.MAPPER.writeValueAsString(requirements)); } Mỗi lĩnh vực trong được mô tả như sau: PaymentRequirements Loại: Xác định kế hoạch thanh toán (chính xác đối với số tiền cố định) và mạng blockchain mục tiêu (base-sepolia cho Base testnet). Người nhận: Địa chỉ ví nơi thanh toán nên được gửi. Đây là ví kinh doanh của bạn sẽ nhận được tiền. Số tiền: Chi phí truy cập vào điểm cuối cụ thể này, được lấy từ bảng giá của bạn. Đối với USDC, điều này thường được thể hiện bằng wei (đơn vị nhỏ nhất). tài sản: Địa chỉ hợp đồng thông minh của token được sử dụng để thanh toán. ví dụ cho thấy USDC trên Base Sepolia testnet. hết hạn: Một dấu hiệu thời gian sau đó yêu cầu thanh toán này trở nên vô hiệu. Điều này ngăn chặn các yêu cầu thanh toán cũ được tái sử dụng và thêm bảo mật chống lại các cuộc tấn công tái phát. Nonce: Một ID duy nhất (UUID) đảm bảo mỗi yêu cầu thanh toán chỉ có thể được đáp ứng một lần, ngay cả khi cùng một khách hàng thực hiện nhiều yêu cầu đến cùng một điểm cuối. Ứng dụng client-side xử lý thanh toán tự động Thư viện khách hàng đóng gói các khách hàng HTTP tiêu chuẩn để tự động xử lý các câu trả lời 402.Khi một khách hàng nhận được yêu cầu thanh toán, (1) nó xây dựng tải trọng thanh toán, (2) ký nó với khóa riêng của người dùng, và (3) tái tạo yêu cầu ban đầu với thanh toán đính kèm. public HttpResponse makeRequest(String url, String method) throws Exception { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .build(); HttpResponse response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); // Handle 402 Payment Required if (response.statusCode() == 402) { PaymentRequirements requirements = Json.MAPPER.readValue( response.body(), PaymentRequirements.class); // Create payment payload matching the requirements PaymentPayload payment = PaymentPayload.builder() .receiver(requirements.getPaymentRequirement().get(0).getReceiver()) .amount(requirements.getPaymentRequirement().get(0).getAmount()) .asset(requirements.getPaymentRequirement().get(0).getAsset()) .nonce(requirements.getPaymentRequirement().get(0).getNonce()) .expiry(requirements.getPaymentRequirement().get(0).getExpiry()) .build(); // Sign using EIP-712 structured data signing String signature = signer.sign(payment.toSigningMap()); // Retry with payment header String paymentHeader = encodePaymentHeader(payment, signature); HttpRequest paidRequest = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .header("X-PAYMENT", paymentHeader) .build(); return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString()); } return response; } Quá trình ký kết sử dụng tiêu chuẩn, tạo ra một đại diện có cấu trúc, có thể đọc được bởi con người của dữ liệu thanh toán trước khi hash và ký nó. EIP-712 Thanh toán Verification Flow Facilitator hội nhập Dịch vụ facilitator là nơi sự phức tạp của blockchain sống, trừu tượng nó xa cả khách hàng và máy chủ.Khi một máy chủ nhận được thanh toán, nó chuyển tải trọng thanh toán cho facilitator để xác minh. public class HttpFacilitatorClient implements FacilitatorClient { private final HttpClient http; private final String baseUrl; @Override public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) throws Exception { // Construct verification request with payment and requirements VerifyRequest body = VerifyRequest.builder() .paymentHeader(paymentHeader) // The X-PAYMENT header from client .requirements(requirements) // What the server expects .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/verify")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, VerificationResponse.class); } @Override public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) throws Exception { // Settlement happens after successful verification SettleRequest body = SettleRequest.builder() .paymentHeader(paymentHeader) .requirements(requirements) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/settle")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, SettlementResponse.class); } } Nhà cung cấp kiểm tra một số điều: Chữ ký có hợp lệ không? Does the payment amount match the requirements? Việc thanh toán này đã được sử dụng trước đây chưa? Thanh toán vẫn còn trong cửa sổ hết hạn của nó? Nếu xác minh được thông qua, người facilitator cũng xử lý thanh toán bằng cách phát sóng giao dịch đến blockchain của sự lựa chọn. giao diện xác định hợp đồng mà bất kỳ khách hàng facilitator nào phải thực hiện: FacilitatorClient public interface FacilitatorClient { VerificationResponse verify(String paymentHeader, PaymentRequirements requirements); SettlementResponse settle(String paymentHeader, PaymentRequirements requirements); } Ứng dụng của bạn cần cung cấp một triển khai cụ thể của giao diện này. Integration Ví dụ Bây giờ chúng ta đã thấy các thành phần riêng lẻ (lọc thanh toán, tích hợp facilitator, và xử lý khách hàng) hãy xem làm thế nào những mảnh này đến với nhau trong một ứng dụng thực sự. Một ví dụ cho thấy toàn bộ dòng chảy. Spring Boot Đầu tiên, tạo a Ghi chú : @PaymentRequired @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface PaymentRequired { String price(); String currency() default "USDC"; String network() default "base-sepolia"; } Sau đó thay đổi các để quét cho các ghi chú này tại startup: PaymentFilter @Component public class PaymentFilter implements Filter { private final Map priceTable; private final String payTo; private final FacilitatorClient facilitator; public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) { this.payTo = payTo; this.facilitator = facilitator; this.priceTable = buildPriceTableFromAnnotations(context); } private Map buildPriceTableFromAnnotations(ApplicationContext context) { Map prices = new HashMap<>(); // Scan all @RestController beans for @PaymentRequired annotations Map controllers = context.getBeansWithAnnotation(RestController.class); for (Object controller : controllers.values()) { Method[] methods = controller.getClass().getMethods(); for (Method method : methods) { PaymentRequired payment = method.getAnnotation(PaymentRequired.class); if (payment != null) { String path = extractPathFromMapping(method); BigInteger amount = new BigInteger(payment.price().replace(".", "")); prices.put(path, amount); } } } return prices; } } Bây giờ bạn có thể ghi chú các phương pháp điều khiển của mình trực tiếp: @RestController public class WeatherController { @GetMapping("/weather") @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia") public WeatherData getWeather(@RequestParam String city) { // Your existing business logic return weatherService.getWeatherForCity(city); } @GetMapping("/premium-forecast") @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia") public ExtendedForecast getPremiumForecast(@RequestParam String city) { return weatherService.getExtendedForecast(city); } } @Configuration public class PaymentConfig { @Bean public PaymentFilter paymentFilter(ApplicationContext context) { return new PaymentFilter( context, " ", // Your wallet address new HttpFacilitatorClient(" ") ); } @Bean public FilterRegistrationBean paymentFilterRegistration(PaymentFilter filter) { FilterRegistrationBean registration = new FilterRegistrationBean<>(); registration.setFilter(filter); registration.addUrlPatterns("/*"); registration.setOrder(1); return registration; } } Các ghi chú xử lý cấu hình giá một cách tuyên bố, trong khi tự động phát hiện các ghi chú này tại khởi động và xây dựng bảng giá. logic kinh doanh hiện có của bạn trong các phương pháp điều khiển vẫn hoàn toàn không thay đổi. cấu hình kết nối mọi thứ với nhau bằng cách đăng ký bộ lọc thanh toán và kết nối nó với một dịch vụ facilitator. giá 0.001 USDC và chi phí 0.01 USDC, với tất cả các thanh toán xử lý xảy ra một cách minh bạch tại lớp HTTP. @PaymentRequired PaymentFilter /weather /premium-forecast Các vấn đề an toàn và sản xuất đơn giản và thanh lịch, nó che giấu sự phức tạp. Đây là một lợi thế và một con. Nó làm cho hội nhập dễ dàng, nhưng nó cũng che giấu một khía cạnh quan trọng: . x402 putting AI agents in charge of money creates new attack vectors Trong khi chữ ký và quản lý nonce xử lý các cuộc tấn công tái phát, điều gì xảy ra khi một đại lý bị xâm phạm? phát hiện gian lận truyền thống dựa trên các mô hình hành vi của con người, nhưng Một đại lý bị xâm phạm có thể rút tiền nhanh hơn bất kỳ kẻ lừa đảo nào. EIP-712 AI agents don't follow human spending habits Các thành phần facilitator trở thành một mục tiêu giá trị cao khác vì nó xác minh chữ ký và quản lý nonces. không giống như các bộ xử lý thanh toán truyền thống có thể đảo ngược giao dịch, . blockchain settlements are final Since được dựa trên các giao dịch trên chuỗi, nó thừa hưởng rủi ro hoạt động của các giao dịch blockchain. Phí khí dao động hoang dã, đôi khi làm cho thanh toán vi mô bất tiện về mặt kinh tế. tắc nghẽn mạng có thể trì hoãn các giao dịch. Một đại lý AI được cho là làm gì khi nó cần dữ liệu thời gian thực nhưng thanh toán bị mắc kẹt trong một mempool? x402 Một khía cạnh quan trọng khác là quy định. tuân thủ khác nhau giữa các khu vực với các quy tắc khác nhau về thanh toán tự động, sử dụng tiền điện tử và lưu giữ dữ liệu. Một đại lý AI thực hiện một khối lượng lớn các giao dịch vi mô xuyên biên giới có thể kích hoạt cảnh báo AML hoặc vi phạm các quy định địa phương mà không ai nhận ra. Điều gì tiếp theo Điều gì thú vị về Các đại lý AI cần khả năng thanh toán tự trị, stablecoins cung cấp một lớp tiền có thể lập trình, và cơ sở hạ tầng blockchain đã trưởng thành đủ để xử lý các ứng dụng có thể mở rộng. những mảnh này chưa được sắp xếp trước đó. Internet bây giờ cần một hình thức thanh toán mới, và các luồng truyền thống không được xây dựng cho các đại lý tự trị hoặc thanh toán vi mô. x402 Thay vì tái tạo thanh toán từ đầu, nó mở rộng cơ sở hạ tầng HTTP hiện có. Thay vì yêu cầu tích hợp mới, nó hoạt động với các mô hình tiêu chuẩn mà chúng ta đã hiểu. x402 Các thách thức an ninh và hoạt động là có thật, nhưng chúng là các vấn đề kỹ thuật với các giải pháp có thể. Sau gần ba thập kỷ, cuối cùng có thể làm những gì nó được thiết kế cho: làm cho việc trả tiền cho những thứ trên internet đơn giản như yêu cầu chúng. HTTP 402 The foundation is set. Now it's time to build. cảm ơn Lời bài hát: Erik Reppel bởi Ronnie Caspers bởi Kevin Leffew, Danny Organ, và toàn bộ đội Coinbase để mở nguồn cho giao thức này. Lời bài hát Erik Reppel bởi Ronnie Caspers bởi Kevin Leffew Đàn organ Coinbase . cảm ơn Lời bài hát Erik Reppel và Yuga Cohler Để xem xét Những đóng góp của tôi hai x402 Lời bài hát Erik Reppel Yuga Cohler Những đóng góp của tôi Tài nguyên và đọc thêm Yêu cầu thanh toán HTTP 402 - RFC 2068 - Thông số kỹ thuật HTTP 1997 gốc Thông số kỹ thuật giao thức x402 - Tài liệu giao thức chính thức x402 GitHub Repository - triển khai mã nguồn mở của Coinbase x402 Java Implementation - PR đã giới thiệu thực hiện Java của giao thức EIP-712: Ethereum Typed Structured Data Hashing and Signing - Chữ ký tiêu chuẩn được sử dụng trong x402 Base Network Documentation - Layer 2 blockchain nền tảng được sử dụng trong ví dụ Tài liệu USDC - Chi tiết hợp đồng USD Coin Stablecoin Spring Boot Filter Documentation - Cài đặt Java middleware Java HTTP Client API - Quản lý HTTP ở phía khách hàng Machine-to-Machine (M2M) Communication Standards - Hệ thống thông tin liên lạc tự trị Autonomous AI Agent Architectures - Nghiên cứu về mô hình thiết kế đại lý AI Google Approach to Secure AI Agents - Google đề xuất một khuôn khổ nhân viên AI an toàn, được hướng dẫn bởi con người