Agen AI kini boleh membayar secara automatik berkat x402 dan HTTP 402

Hari ini ialah Januari 1997.

yangIETF(Internet Engineering Task Force) baru sahaja mengeluarkanPerkhidmatan RFC 2068secara rasmi ditakrifkanHTTP/1.1Spesifikasi ini telah ditulis oleh web pioneersoleh Roy Fieldingdaripadaoleh Jim GettysdaripadaJepun MoguldaripadaHenrikh Frostykdanoleh Tim Berners-Lee, arsitek yang membentuk bagaimana internet berkomunikasi.

Spesifikasi ini memperkenalkanpersistent connections: sebelum ini, setiap permintaan HTTP memerlukan sambungan TCP baru. sambungan persisten menyelesaikan ini, membolehkan pelbagai permintaan HTTP mengalir melalui satu sambungan TCP yang bertahan lama. Tidak lagi mewujudkan sambungan berasingan untuk setiap imej, fail CSS, atau snippet JavaScript pada halaman web.

Terdapat jugachunked transfer encodingBukan lagi pelayan perlu mengira saiz keseluruhan kandungan yang dihasilkan secara dinamik terlebih dahulu, ia kini bebas untuk menyampaikan data secara beransur-ansur, kerana ia dihasilkan.

tetapiRFC 2068 quietly introduces something intriguingKode Status yang baru :

HTTP 402 Payment Required
This code is reserved for future use.

Ini menunjukkan bagaimana bapa-bapa pendiri World Wide Web meramalkan bagaimana wang akhirnya akan menjadi sebahagian besar internet.even if they had no clear path on how it would actually play out.

Hari ini, 2025, hampir tiga dekad dan pelbagai versi HTTP kemudian (HTTP/2Pada tahun 2015,HTTP/3Pada tahun 2022,Status Code 402 still sits there with the exact same note: 'reserved for future use.'Walaupun revolusi fintech, kebangkitan pembayaran dalam talian, dan seluruh ekonomi yang dibina pada transaksi internet, tiada siapa yang telah mencari tahu apa yang perlu dilakukan dengannya.

Until now.

Bulan lepas ( Mei 2025 )Coinbase yangdibebaskanx402Protokol sumber terbuka yang memberiHTTP 402kerja sebenar pertama: membolehkan penduduk aslionchainPembayaran dalam permintaan HTTP.

Pihak berkuasa kini perlu membuatM2M(mesin-ke-mesin) pembayaran di seluruh web denganHITL(Man-in-the-loop) campur tangan, tetapi aliran pembayaran tradisional tidak berfungsi dengan baik dalam kes ini.Mereka memerlukan pelbagai interaksi manusia, pengalihan, dan langkah manual yang hanya tidak berfungsi apabila agen AI perlu membuat transaksi secara autonomi.

x402Ia mencadangkan aliran pembayaran automatik dalam rantaian yang diimplementasikan secara asli dalam protokol HTTP,making them as seamless as any other web request.

Tetapi bagaimana ini kelihatan dalam amalan?

Arsitektur dan komponenx402 buah

x402Ia dibina di sekitar empat komponen teras:

Melayu

A ialahclientbertindak sebagai inisiator pembayaran, mencari tahu apa yang diperlukan untuk mengakses dan membina beban faedah pembayaran yang sesuai. Sederhananya, ini adalah apa-apa yang membuat permintaan HTTP kepada sumber yang dibayar. Ia boleh menjadi pelayar yang membuat permintaan untuk kandungan premium, akses API pembelian agen AI, atau ciri-ciri unlocking aplikasi mudah alih. Pelanggan menangani penandatangan kriptografi menggunakan kunci peribadi pengguna dan secara automatik mengembalikan permintaan apabila bayaran diperlukan.

yangresource servermenguatkuasakan dasar bayaran untuk titik akhir sambil kekal memberi tumpuan kepada logik perniagaan terasnya.Ini ialah pelayan web atau API yang mengehoskan kandungan atau perkhidmatan yang dibeli.Ia mengekalkan jadual harga yang mudah yang memaparkan titik akhir kepada kos, tetapi memberikan logik pengesahan bayaran kepada pembantu.

Logik Blockchain digunakan dalamfacilitatorkomponen: mengesahkan tanda tangan kriptografi, mengelakkan serangan replay melalui pelacakan nonce, dan menguruskan penyelesaian pada rantaian sebenar.Ia membolehkan kedua-dua klien dan pelayan untuk bekerja dengan pembayaran pada rantaian tanpa memahami butiran pelaksanaan blockchain.

ialahblockchainterletak pada lapisan penyelesaian akhir, memastikan pembayaran tidak berubah dan transparan.Ia membolehkan wang yang boleh diprogram melalui kontrak pintar dan koin stabil,but its complexity is completely hidden from the application layer by the facilitator.

Client:

• Tanggungjawab utama: Inisiatif Pembayaran
• Ciri-ciri utama:Tanda tangan EIP-712, retries automatik, penemuan pembayaran
• Apa yang ia lakukan: Melakukan permintaan, menangani dompet, retries dengan bayaran

Resource Server:

• Tanggungjawab utama: Penegakan Pembayaran
• Ciri-ciri utama: Jadual harga, respons HTTP 402, integrasi middleware
• Apa yang ia lakukan: menetapkan harga, memeriksa pembayaran, berkhidmat kandungan

Facilitator:

• Tanggungjawab utama: Pengesahan pembayaran
• Ciri-ciri utama: pengesahan tanda tangan, pelacakan nonce, abstraksi gas
• Apa yang ia lakukan: Mengesahkan tanda tangan, bercakap kepada blockchain

Blockchain:

• Tanggungjawab utama: Penyelesaian pembayaran
• Ciri-ciri utama:Transfer USD, kontrak pintar, rekod yang tidak berubah
• Apa yang ia lakukan: Menyelesaikan pembayaran pada rantaian

Prinsip

Arsitektur ini menunjukkan beberapa prinsip kejuruteraan perisian asas. yang paling penting ialahseparation of concernsSetiap komponen mempunyai tanggungjawab yang unik dan jelas.Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction.

Sistem ini berjayaloose couplingdengan mempunyai komponen berinteraksi hanya melalui antara muka HTTP dan REST standard.A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementationIsolasi ini bermakna anda boleh menukar komponen (contohnya, menggunakan blockchain yang berbeza, menukar pembekal facilitator, atau mengubah logik pelayan) tanpa menjejaskan sisa sistem.

Pembantu memfasilitasisingle responsibility principledengan mengisolasi semua kerumitan blockchain ke dalam satu perkhidmatan khusus.Ini menghalang logik pembayaran daripada bocor ke dalam aplikasi perniagaan dan mengekalkan keprihatinan terpisah dengan betul.

Last but not least, struktur ini ialahdependency inversionKomponen peringkat tinggi bergantung kepada abstraksi daripada pelaksanaan konkrit. pelayan dan klien bergantung kepada antara muka HTTP, bukan API blockchain tertentu. Ini membolehkan kod aplikasi yang sama untuk bekerja di pelbagai blockchain dan skim pembayaran yang berbeza tanpa perubahan.

Pembayaran Flow

Apabila seorang pengguna atau pengguna mempunyaix402-aktifkan API, berikut ialah aliran empat langkah yang berlaku:

1. Permintaan awal : Pelanggan membuat permintaan HTTP standard untuk mengakses beberapa sumber
2. Pembayaran diperlukan jawapan : Jika tiada bayaran disertakan, pelayan menjawab dengan HTTP 402 dan termasuk butiran bayaran
3. Pengesahan Pembayaran: Pelanggan mencipta pembayaran yang ditandatangani secara kriptografi dan memulakan permintaan
4. Pengesahan dan akses : Pelayan mengesahkan pembayaran, menyiarkan kepada blockchain, dan memberi akses

Apa yang membuat ini kuat ialah bahawa ia semua berlaku pada tahap protokol HTTP. Tiada pengalihan ke pemproses pembayaran pihak ketiga, tidakOAuthaliran, tiada penciptaan akaun.Just standard HTTP with extra headers:

• X-PAYMENT mengalir dari klien ke pelayan dan mengandungi beban bayaran yang ditandatangani.Ini termasuk butiran bayaran (jumlah, penerima, token) ditambah tanda tangan kriptografi yang membuktikan bahawa klien telah membenarkan bayaran.
• X-PAYMENT-RESPONSE mengalir dari pelayan kepada pelanggan selepas pembayaran yang berjaya dan mengandungi maklumat penerimaan transaksi, menyediakan ketelusan tentang apa yang berlaku dalam rantaian.

Melayu

Implementasi Server

Arsitektur Pembayaran Middleware

Implementasi server-side teras berpusat di sekitar penapis bayaran (AKA middleware) yang menangkap permintaan HTTP dan menguatkuasakan keperluan bayaran. Apabila disepadukan ke dalam pelayan web anda, middleware ini memeriksa permintaan masuk terhadap jadual harga yang memaparkan titik akhir kepada kos mereka.

Mid-ware mengikuti pokok keputusan yang mudah: jika permintaan mencapai titik akhir yang dilindungi tanpa bayaran, ia bertindak balas denganHTTP 402dan arahan pembayaran terperinci. jika bayaran disertakan dalamX-PAYMENTheader, ia mengesahkan pembayaran dengan perkhidmatan facilitator sebelum membenarkan permintaan untuk meneruskan.

Berikut ialah struktur penting daripada pelaksanaan Java:

public class PaymentFilter implements Filter {
    private final String payTo;
    private final Map<String, BigInteger> 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);
        }
    }
}

The beauty of this approach is that it requires minimal changes to existing applications.Anda hanya menambah penapis bayaran kepada tumpukan produk pertengahan anda dan menentukan titik akhir mana yang memerlukan bayaran.

PaymentRequirementsJawapan

Apabila klien mencapai titik akhir yang dilindungi tanpa bayaran, pelayan membina objek keperluan bayaran terperinci.USDC), alamat dompet penerima, rangkaian blockchain, dan masa tamat tempoh untuk mengelakkan serangan replay.

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>")                      // 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));
}

Setiap kawasan di dalamPaymentRequirementsIa digambarkan sebagai berikut:

• Jenis: Menentukan skim pembayaran (ketepatan untuk jumlah tetap) dan rangkaian blockchain sasaran (base-sepolia untuk Base testnet). Ini memberitahu pelanggan dengan tepat bagaimana untuk membina dan melaksanakan pembayaran.
• penerima: Alamat dompet di mana pembayaran harus dihantar.Ini ialah dompet perniagaan anda yang akan menerima dana.
• Jumlah: Kos untuk mengakses titik akhir tertentu ini, diperolehi daripada jadual harga anda. Untuk USDC, ini biasanya dinyatakan dalam wei (unit terkecil).
• aset: Alamat kontrak pintar token yang akan digunakan untuk pembayaran. contoh menunjukkan USDC pada Base Sepolia testnet.
• Tamat tempoh: Titik masa selepas yang keperluan bayaran ini menjadi tidak sah. Ini menghalang permintaan bayaran lama daripada digunakan semula dan menambah keselamatan terhadap serangan replay.
• nonce: Identifikasi unik (UUID) yang memastikan setiap keperluan pembayaran hanya boleh dipenuhi sekali, walaupun klien yang sama membuat beberapa permintaan kepada titik akhir yang sama.

Client-side implementation

Pembayaran automatik

Perpustakaan klien membungkus klien HTTP standard untuk menangani jawapan 402 secara automatik. Apabila klien menerima permintaan bayaran, (1) ia membina beban faedah bayaran, (2) menandatangani dengan kunci peribadi pengguna, dan (3) mengembalikan permintaan asal dengan bayaran yang disertakan.

public HttpResponse<String> makeRequest(String url, String method) throws Exception {
    HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create(url))
        .method(method, HttpRequest.BodyPublishers.noBody())
        .build();

    HttpResponse<String> 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;
}

Proses penandatanganan menggunakanEIP-712standard, yang mewujudkan representasi yang terstruktur, boleh dibaca oleh manusia data pembayaran sebelum hashing dan menandatangani ia.

Pengesahan aliran pembayaran

Facilitator Integrasi

Perkhidmatan facilitator ialah di mana kompleksiti blockchain hidup, membuangnya daripada kedua-dua klien dan pelayan. apabila pelayan menerima bayaran, ia menghantar beban faedah pembayaran kepada facilitator untuk pengesahan.

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);
    }
}

Pembantu memeriksa beberapa perkara:

• Adakah tanda tangan itu sah?
• Adakah jumlah bayaran sepadan dengan keperluan?
• Adakah pembayaran ini telah digunakan sebelum ini?
• Adakah pembayaran masih dalam tetingkap tamat tempoh?

If verification passes, the facilitator also handles settlement by broadcasting the transaction to the blockchain of choice. The FacilitatorClientantara muka mendefinisikan kontrak yang mana-mana pelanggan pemfasilitator mesti melaksanakan:

public interface FacilitatorClient {
    VerificationResponse verify(String paymentHeader, PaymentRequirements requirements);
    SettlementResponse settle(String paymentHeader, PaymentRequirements requirements);
}

Permohonan anda perlu menyediakan pelaksanaan konkret antara muka ini.

Contoh Integrasi

Now that we've seen the individual components (payment filters, facilitator integration, and client handling) let's look at how these pieces come together in a real application. Here's a minimal Spring Bootcontoh yang menunjukkan aliran keseluruhan.

Pertama, mewujudkan a@PaymentRequiredAnotasi :

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface PaymentRequired {
    String price();
    String currency() default "USDC";
    String network() default "base-sepolia";
}

Kemudian ubah kepadaPaymentFilteruntuk memindai untuk nota-nota ini pada startup:

@Component
public class PaymentFilter implements Filter {
    private final Map<String, BigInteger> 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<String, BigInteger> buildPriceTableFromAnnotations(ApplicationContext context) {
        Map<String, BigInteger> prices = new HashMap<>();

        // Scan all @RestController beans for @PaymentRequired annotations
        Map<String, Object> 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;
    }
}

Sekarang anda boleh menandakan kaedah pengawal anda secara langsung:

@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,
            "<WALLET_ADDRESS>", // Your wallet address
            new HttpFacilitatorClient("<FACILITATOR_URL>")
        );
    }

    @Bean
    public FilterRegistrationBean<PaymentFilter> paymentFilterRegistration(PaymentFilter filter) {
        FilterRegistrationBean<PaymentFilter> registration = new FilterRegistrationBean<>();
        registration.setFilter(filter);
        registration.addUrlPatterns("/*");
        registration.setOrder(1);
        return registration;
    }
}

yang@PaymentRequiredAnotasi menangani konfigurasi harga secara deklaratif, manakalaPaymentFiltersecara automatik mendapati notis-notis ini pada permulaan dan membina jadual harga. Logik perniagaan anda yang sedia ada dalam kaedah kawalan kekal sama sekali tidak berubah. Konfigurasi mengalir semuanya bersama-sama dengan mendaftarkan penapis bayaran dan menghubungkannya kepada perkhidmatan facilitator./weatherkos 0.001 USDC dan/premium-forecastkos 0.01 USDC, dengan semua pemprosesan pembayaran berlaku secara transparan di lapisan HTTP.

Pertimbangan keselamatan dan pengeluaran

x402mudah dan elegan, ia menyembunyikan kerumitan. Ini adalah pro dan con. Ia membuat integrasi mudah, tetapi ia juga menyembunyikan aspek penting:putting AI agents in charge of money creates new attack vectors.

manakalaEIP-712tanda tangan dan pengurusan nonce menangani serangan pemulihan, apa yang berlaku apabila seorang agen dikompromikan? pengesanan penipuan tradisional bergantung kepada corak tingkah laku manusia, tetapiAI agents don't follow human spending habits. A compromised agent could drain funds faster than any human fraudster.

Komponen facilitator menjadi sasaran nilai tinggi lain kerana ia mengesahkan tanda tangan dan menguruskan nonces.blockchain settlements are final.

Sejakx402berdasarkan urus niaga dalam rantaian, ia mewarisi risiko operasi urus niaga blockchain. Bayaran gas berfluktuasi secara liar, kadang-kadang menjadikan mikropayments tidak selesa secara ekonomi. kemacetan rangkaian boleh menangguhkan urus niaga. Apa yang agensi AI seharusnya lakukan apabila ia memerlukan data masa nyata tetapi bayaran terperangkap dalam mempool?

Aspek lain yang penting ialah peraturan. pematuhan berbeza di seluruh bidang kuasa dengan peraturan yang berbeza mengenai pembayaran automatik, penggunaan mata wang kripto, dan penyimpanan data. Agen AI yang melakukan jumlah besar transaksi mikro melintasi sempadan boleh memicu amaran AML atau melanggar peraturan tempatan tanpa sesiapa pun menyedari.

Apa yang seterusnya

Apa yang menarik tentangx402Agen AI memerlukan keupayaan pembayaran autonomi, stablecoins menyediakan lapisan wang yang boleh diprogram, dan infrastruktur blockchain telah matang cukup untuk menangani aplikasi yang boleh diperluas.

x402ini menarik berkat pendekatan pragmatiknya. alih-alih mencipta semula pembayaran dari awal, ia memperluaskan infrastruktur HTTP yang sedia ada. alih-alih memerlukan integrasi baru, ia berfungsi dengan corak standard yang kita sudah faham.

Cabaran keselamatan dan operasi adalah sebenar, tetapi mereka adalah masalah kejuruteraan dengan penyelesaian yang mungkin.

Selepas hampir tiga dekad,HTTP 402akhirnya boleh melakukan apa yang direka untuk: membuat membayar untuk perkara-perkara di internet semudah meminta mereka.

The foundation is set. Now it's time to build.

terima kasih daripada Erik Reppel, daripada Ronnie Caspers, oleh Kevin Leffew, Danny Organ, dan seluruh pasukan di Coinbase yang untuk open sourcing protokol ini.

terima kasih Erik Reppel dan Yuga Cohler Untuk meninjau Kontribusi saya dua x402.

Sumber dan Baca Lebih Lanjut

• HTTP 402 Pembayaran Diperlukan - RFC 2068 - Spesifikasi HTTP Asli 1997
• Spesifikasi Protokol x402 - Dokumentasi Protokol rasmi
• x402 GitHub Repository - Implementasi sumber terbuka Coinbase
• x402 Implementasi Java - PR yang memperkenalkan implementasi protokol Java
• EIP-712: Ethereum Tiped Structured Data Hashing dan Signing - Penandatanganan standard yang digunakan dalam x402
• Dokumen Rangkaian Asas - Layer 2 platform blockchain yang digunakan dalam contoh
• Dokumen USDC - Maklumat kontrak USD Coin Stablecoin
• Spring Boot Filter Documentation - Java middleware implementation
• Java HTTP Client API - Pengurusan HTTP pihak klien
• Standard Komunikasi Mesin-ke-mesin (M2M) - Komunikasi Sistem Autonomi
• Arsitektur Agen AI Otonom - Penyelidikan pada corak reka bentuk agen AI
• Google Approach to Secure AI Agents - cadangan Google untuk rangka kerja agen AI yang selamat dan dipandu oleh manusia