Temu duga frontend: Bagaimanakah anda mendedahkan alatan WebMCP secara selamat kepada ejen pelayar?

Soalan

Halaman pembayaran e-dagang ingin menguji cuba WebMCP supaya ejen pelayar dapat menapis produk dan mengisi borang. Bagaimanakah anda mentakrifkan alatan, mengehadkan kebenaran, mengekalkan kawalan pengguna, dan mengesahkan bahawa ejen tidak memanggil tindakan berimpak tinggi secara salah?

Konteks dan sempadan

WebMCP ialah cadangan piawaian web. Dokumentasi Chrome menerangkan alatan bentuk HTML deklaratif dan alatan JavaScript imperatif, dan Chrome 149 menyediakan percubaan asal (origin trial). Soalan ini adalah mengenai peningkatan progresif (progressive enhancement) dalam tab pelayar dengan penglibatan manusia (human in the loop). WebMCP tidak dibentangkan sebagai protokol backend yang stabil yang berjalan tanpa konteks pelayar, mahupun sebagai pengganti untuk kebenaran sebelah pelayan.

Jelaskan dahulu: Tindakan manakah yang hanya mencari dan mengisi, dan yang manakah membuat pesanan atau mengenakan bayaran wang? Patutkah alatan kelihatan hanya pada halaman peringkat teratas atau juga pada iframe rentas asal (cross-origin)? Adakah pengguna mesti mengesahkan semula sebelum penyerahan akhir? Apakah yang berlaku apabila ejen tidak menyokong WebMCP atau percubaan asal tamat?

Perkara yang diuji oleh penemu duga

Penemu duga sedang menguji sama ada anda boleh menukar penggerak ejen menjadi kontrak frontend: penerangan alatan dan skema input yang jelas, log masuk sedia ada, CSRF, kebenaran perniagaan, dan pengesahan pengguna yang masih berada dalam laluan, pendedahan rentas asal dengan keistimewaan paling rendah (least-privilege), serta penilaian untuk pilihan alat, parameter, dan hasil.

Jawapan 30 saat

Bahagikan perjalanan kepada tindakan baca sahaja, boleh balik (reversible), dan tidak boleh balik (irreversible). Gunakan alatan deklaratif atau imperatif untuk carian dan pengisian, manakala penyerahan pesanan mengekalkan kebenaran pelayan dan pengesahan eksplisit. Dedahkan hanya medan yang diperlukan, tetapkan lalai kepada halaman dan asal semasa, dan perlukan Permissions Policy yang eksplisit untuk iframe rentas asal. Sebelum pelepasan, nilaikan pemilihan alat, pengesahan parameter, pengendalian ralat, dan laluan penolakan, sambil mengekalkan UI biasa sebagai sandaran (fallback).

Analisis terperinci langkah demi langkah

1. Tahap risiko: search, filter, dan fill adalah berisiko rendah atau boleh balik; place-order, pay, dan perubahan alamat adalah berimpak tinggi dan tidak boleh dijalankan secara automatik semata-mata kerana ejen mempunyai alat.
2. Kontrak: setiap alat mendapat nama yang stabil, penerangan yang menghadap ejen, skema input JSON, dan hasil berstruktur. Pengangkaan (enumerations), julat, mata wang, dan versi inventori disahkan pada kedua-dua klien dan pelayan.
3. Guna semula logik perniagaan: panggilan balik (callback) memanggil keadaan borang dan fungsi domain sedia ada dan bukannya menyalin laluan permintaan yang memintas UI. Sebelum pelaksanaan, semak log masuk, CSRF, versi troli, harga, dan inventori.
4. Sempadan kebenaran: dedahkan secara lalai hanya kepada tetingkap peringkat teratas dan konteks asal yang sama. Kongsi dengan iframe rentas asal hanya apabila Permissions-Policy dan atribut iframe allow membenarkannya secara eksplisit, dan jangan pulangkan data peribadi yang tidak diperlukan.
5. Kawalan pengguna: biarkan carian dan pengisian menunjukkan perubahan yang kelihatan. Perlukan pengesahan dalam halaman dan ringkasan untuk pesanan, pembayaran, atau pemadaman; hasil alat menyatakan sama ada tindakan telah selesai, menunggu pengesahan, atau ditolak.
6. Pelancaran berperingkat: dayakan akaun dalaman di sebalik bendera tempatan atau percubaan asal terlebih dahulu. Sediakan pengesanan keupayaan, UI biasa, dan sandaran automasi DOM apabila WebMCP tidak tersedia; log versi alat, hasil, dan sebab penolakan.
7. Penilaian dan pemantauan: bina set tugas untuk ketepatan pilihan alat, kadar parameter sah, penyelesaian, pemanggilan palsu, ketepatan penolakan, dan liputan pengesahan. Tetapkan ambang sifar pemanggilan palsu (zero-false-invocation gate) untuk alatan berimpak tinggi dan batalkan pendaftaran apabila berlaku keabnormalan.

Contoh jawapan

Saya akan membahagikan pembayaran kepada carian, pengisian, dan penyerahan. Carian dan pengisian adalah boleh balik, jadi WebMCP boleh meningkatkan penyasaran ejen. Pesanan dan pembayaran kekal tertakluk kepada kebenaran pelayan sedia ada, semakan harga dan inventori, serta pengesahan halaman. WebMCP adalah eksperimen; percubaan asal Chrome 149 sesuai untuk pengesahan terkawal, bukan pengganti bagi kebenaran backend.

Alatan hanya mendedahkan medan yang diperlukan untuk perjalanan semasa dan menggunakan semula logik borang dan domain sedia ada dalam panggilan balik mereka. Skema input mengehadkan ID item, kuantiti, dan format alamat; pelayan menyemak log masuk, CSRF, inventori, harga, dan keidempotenan pesanan sekali lagi. Secara lalai saya mendedahkan alatan kepada halaman peringkat teratas dan ejen asal yang sama. Jika iframe rentas asal diperlukan, saya mengkonfigurasi kedua-dua dasar kebenaran dan iframe allow, dan tidak sekali-kali memulangkan keseluruhan profil akaun.

const controller = new AbortController();

document.modelContext?.registerTool({
  name: "cart_set_quantity",
  description: "Set the quantity of one visible cart item; never submits an order.",
  inputSchema: {
    type: "object",
    properties: {
      itemId: { type: "string", minLength: 1 },
      quantity: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["itemId", "quantity"]
  },
  async execute({ itemId, quantity }) {
    const result = await setVisibleCartQuantity(itemId, quantity);
    return { content: [{ type: "text", text: result.summary }] };
  }
}, { signal: controller.signal });

Walaupun alat pesanan wujud, ia mengembalikan "pengesahan pengguna diperlukan" dan tidak boleh mengenakan bayaran wang dengan sendirinya. Setiap panggilan merekodkan versi alat, hasil pengesahan parameter, dan keadaan halaman. Set penilaian merangkumi item yang salah, kuantiti berlebihan, harga lapuk, pengesahan yang ditolak, dan ketiadaan WebMCP. Oleh itu, WebMCP ialah peningkatan progresif yang boleh dibatalkan; kebenaran perniagaan dan niat pengguna kekal dalam laluan sedia ada.

Kesilapan biasa

• Menerangkan ciri WebMCP percubaan awal sebagai API backend yang stabil.
• Mendedahkan alat sejagat yang boleh membayar, memadamkan akaun, atau menukar mana-mana alamat secara terus.
• Mengesahkan skema hanya dalam pelayar dan melangkau semakan pelayan untuk log masuk, inventori, harga, dan keidempotenan.
• Berkongsi alatan dengan iframe rentas asal secara lalai atau memulangkan profil pengguna penuh sebagai hasil alat.
• Tidak menyediakan UI biasa, pengesanan keupayaan, laluan pembatalan, atau set penilaian ejen.

Jawapan yang kukuh merangkumi kontrak alat, kebenaran pelayan, pengasingan asal, pengesahan pengguna, sandaran, dan penilaian kuantitatif. "Menambah penerangan pada butang" tidak menunjukkan penggerak yang selamat.

Soalan susulan dan respons

Mengapa tidak mendaftarkan peletakan pesanan sebagai alat WebMCP juga?

Anda boleh mendaftarkan alat yang menyediakan ringkasan pesanan, tetapi penyerahan akhir harus memerlukan pengesahan halaman dan kebenaran pelayan. Panggilan alat tidak membuktikan bahawa pengguna bersetuju untuk membayar dan tidak boleh memintas semakan harga, inventori, atau penipuan.

Bagaimanakah anda menyekat pendedahan alat kepada iframe rentas asal?

Jangan dedahkannya kepada konteks rentas asal secara lalai. Jika diperlukan, gunakan konfigurasi eksplisit Permissions-Policy dan iframe allow, kemudian hadkan data yang boleh dibaca dan ditulis pada lapisan alat. Log asal, kitaran hayat halaman, dan pembatalan.

Bagaimana jika ejen menghantar parameter yang sah mengikut skema tetapi tidak sah dari segi perniagaan?

Tolak item yang tidak kelihatan, keadaan lapuk, dan nilai di luar skop pengguna semasa dalam klien, kemudian ulangi pengesahan perniagaan pada pelayan dan kembalikan penolakan berstruktur. Jangan ubah rentetan menjadi tindakan sewenang-wenangnya atau menulis semula parameter secara senyap-senyap.

Bagaimanakah anda membuktikan bahawa ejen memahami alatan tersebut?

Gunakan set tugas tetap dan halaman sebenar untuk mengukur pilihan alat, kadar parameter sah, penyelesaian, pemanggilan palsu, dan ketepatan penolakan. Tetapkan ambang sifar pemanggilan palsu untuk pembayaran dan pemadaman, dan jalankan semula penilaian selepas perubahan API.