Prompt dan konteks yang berkenaan
Anda memiliki platform ejen perusahaan. Ejen ini boleh memanggil sistem tiket, kawalan sumber dan kewangan melalui MCP. Sesetengah alat adalah baca sahaja; yang lain menggunakan kod ke pengeluaran (deploy), mengeluarkan bayaran balik atau memadam data. Pelayan boleh berubah dari semasa ke semasa, dan penerangan alat atau hasil mungkin datang daripada pelayan yang tidak dipercayai sepenuhnya. Reka bentuk penemuan (discovery), kebenaran (authorization), panggilan (invocation), pengendalian hasil, pengauditan dan pemulihan. Terangkan operasi yang memerlukan kelulusan manusia.
Soalan terasnya adalah sama ada setiap panggilan mempunyai jawapan yang jelas kepada empat soalan: siapa yang bertindak untuk siapa dan dalam skop apa, versi alat mana yang digunakan, sama ada input dan hasil telah disahkan, dan sama ada kegagalan boleh dikesan serta diundur balik. Panduan SDE II Amazon secara eksplisit menilai kebolehpercayaan, kebolehskalaan, keselamatan dan pertukaran kompromi (trade-offs) dalam reka bentuk sistem, menjadikannya latihan reka bentuk hujung ke hujung yang sesuai.
Perkara yang dinilai oleh penemu duga
Jawapan yang kukuh memisahkan keupayaan model untuk mencadangkan panggilan daripada autoriti platform untuk melaksanakannya. Model boleh mencadangkan alat dan hujah (arguments); enjin dasar mesti memberi kebenaran semula menggunakan pengguna, penyewa (tenant), sumber, tahap risiko dan status kelulusan.
Anda juga harus mengenali sempadan MCP. Anotasi alat yang dibekalkan oleh pelayan mesti dianggap sebagai tidak dipercayai; readOnlyHint bukanlah fakta kebenaran. Hasil boleh mengandungi data berstruktur, teks, pautan sumber atau sumber terbenam. Panduan NSA seterusnya menekankan panggilan dinamik, kepercayaan tersirat dan perkongsian konteks sebagai risiko sistemik.
Penemu duga akan menyiasat laluan kegagalan: katalog yang diracuni (poisoned catalog), hujah rentas penyewa yang melepasi pengesahan skema, parameter yang diubah selepas kelulusan, masa tamat (timeouts), kesan sampingan berulang dan saluran paip audit yang tidak tersedia.
Soalan penjelasan
Mula-mula tanya tentang kesan sampingan. Bolehkah pertanyaan (queries), penulisan, penggunaan kod dan pemadaman disusun mengikut risiko? Jika setiap alat adalah baca sahaja, kelulusan dan pemulihan boleh menjadi lebih mudah; pergerakan wang, perubahan pengeluaran dan data peribadi memerlukan kawalan yang lebih ketat.
Kemudian tanya tentang sempadan kepercayaan. Adakah pelayan diuruskan oleh syarikat, dihoskan oleh pihak ketiga, atau dibekalkan oleh pengguna? Jika platform tidak mengawal pelayan, penerangan, anotasi, teks hasil dan URI sumbernya adalah data input, bukan dasar.
Akhir sekali tanya tentang objektif pematuhan dan pemulihan. Prinsipal, penyewa dan kelas data manakah yang mesti direkodkan? Adakah pembalikan merupakan transaksi pampasan, operasi songsang atau prosedur manual? Jawapan tersebut mengubah pengekalan, skop kelayakan dan reka bentuk aliran kerja.
Rangka kerja jawapan 30 saat
Anda boleh berkata:
“Saya akan menganggap model sebagai pencadang yang tidak dipercayai dan meletakkan pelaksanaan di sebalik enjin dasar dan pelaksana (runner) yang diasingkan. Platform mendaftar dan memversikan setiap alat, menggunakan hak akses paling rendah mengikut pengguna, penyewa, sumber dan kesan sampingan, serta mengikat tindakan berisiko tinggi seperti penggunaan kod, bayaran balik dan pemadaman kepada kelulusan parameter yang tepat. Panggilan baca sahaja tetap mengesahkan input dan hasil. Sebelum dan selepas pelaksanaan, kami menulis peristiwa audit yang dikaitkan; hasil tidak boleh menjadi kebenaran untuk panggilan seterusnya. Keidempotetan, masa tamat, pemutus litar (circuit breakers) dan pengunduran balik atau pemulihan manual meliputi percubaan semula, perubahan pelayan, ketidakpadanan kelulusan dan kegagalan separa.”
Jawapan mendalam langkah demi langkah
Cipta katalog alat yang peka identiti
Daftarkan identiti pelayan, nama alat, JSON Schemas input dan output, versi kod, skop rangkaian dan kesan sampingan sebenar. Perubahan katalog menghasilkan rekod versi dan semakan; panggilan masa jalanan hanya menggunakan versi yang diluluskan. Spesifikasi MCP mentakrifkan nama, penerangan dan skema input, serta membenarkan skema output, tetapi klien masih memerlukan pengesahan bebas.
Ikat kebenaran kepada satu panggilan
Input dasar harus merangkumi prinsipal, penyewa, sumber, tindakan, kelas data, persekitaran dan versi alat. Keputusan adalah benarkan (allow), tolak (deny), atau kelulusan-diperlukan (approval-required), dan ia menghasilkan token panggilan jangka pendek. Ikat token kepada ringkasan (digest) parameter supaya model tidak boleh menukar jumlah, repositori atau sumber selepas kelulusan.
Tafsirkan anotasi dan penerangan sebagai petunjuk
readOnlyHint dan destructiveHint boleh meningkatkan kedudukan, tetapi ia tidak boleh membenarkan pelaksanaan. Jika pelayan mendakwa sebagai baca sahaja, dasar tetap bergantung pada pendaftaran yang telah disemak dan keupayaan yang diperhatikan. Teks seperti “ignore previous instructions” adalah data, bukan kemas kini dasar.
Laksanakan di dalam pelaksana yang diasingkan
Gunakan kelayakan jangka pendek, keluar rangkaian (egress) yang terhad dan kuota sumber. Pelaksana hanya menerima hujah berstruktur yang telah disemak oleh dasar; ia tidak menerima keseluruhan perbualan atau data penyewa lain. Teks alat, pautan dan sumber terbenam terlebih dahulu memasuki kuarantin hasil, kemudian melepasi pemeriksaan skema output, saiz, jenis kandungan dan label data.
Jadikan kelulusan eksplisit dan terikat parameter
Paparan kelulusan menunjukkan prinsipal, pelayan, versi alat, ringkasan parameter lengkap, sumber sasaran, kesan sampingan yang dijangkakan, masa luput dan laluan pembatalan. Simpan kelulusan dengan digest parameter; sebarang perubahan medan membatalkannya. Pembacaan berisiko rendah boleh menggunakan persampelan pasca-hoc, manakala tindakan berisiko tinggi memerlukan kelulusan sebelum pelaksanaan.
Kendalikan percubaan semula dan penyiapan separa
Operasi penulisan membawa kunci keidempotetan yang diperoleh daripada tindakan perniagaan dan niat panggilan, bukan hanya nilai model rawak. Kekalkan status permintaan, hasil dan percubaan semula. Apabila masa tamat, buat pertanyaan status pelaksanaan sebelum mencuba semula. Jika pampasan tidak selamat, alihkan tindakan ke barisan gilir manusia dan bukannya mengulangi bayaran balik atau penggunaan kod secara membuta tuli.
Pancarkan peristiwa audit yang dikaitkan
Sesuatu peristiwa merangkumi ID permintaan, prinsipal, penyewa, cap jari pelayan, versi alat, digest parameter, keputusan dasar, pelulus, hasil pelaksanaan dan ID kelayakan hiliran. Simpan hujah sensitif hanya sebagai digest yang disunting atau rujukan yang disulitkan. Jika storan audit tidak tersedia, panggilan berisiko tinggi mesti gagal tutup (fail closed) atau memasuki keadaan tergantung dan bukannya diteruskan secara senyap.
Lancarkan dan batalkan secara berperingkat
Sahkan katalog, dasar dan pemeriksaan hasil terhadap pelayan kotak pasir (sandbox) dan trafik bayangan (shadow traffic) sebelum pelancaran kecil mengikut penyewa atau versi. Simpan versi katalog lama dan suis pembatalan kelayakan. Jika anda mengesan peningkatan keistimewaan, suntikan prompt atau pencemaran hasil, sekat panggilan baharu dan batalkan token terlebih dahulu, kemudian gunakan peristiwa audit untuk mengendalikan kesan sampingan yang telah selesai.
Contoh jawapan berkualiti tinggi
“Saya akan membahagikan integrasi MCP kepada lapisan katalog, dasar, kelulusan, pelaksana dan audit. Katalog merekodkan cap jari pelayan, versi alat, skema dan kesan sampingan sebenar. Model boleh mencadangkan panggilan, tetapi enjin dasar membenarkannya mengikut prinsipal, penyewa, sumber dan persekitaran. Kelulusan terikat kepada digest parameter, jadi menukar jumlah atau sasaran akan membatalkannya. Pelaksana menggunakan kelayakan jangka pendek, rangkaian terhad dan kunci keidempotetan. Hasil dikuarantin dan diperiksa untuk skema, saiz, jenis kandungan dan label data sebelum sampai kepada ejen. Setiap keputusan dan permintaan hiliran dikaitkan dalam log audit. Perubahan pelayan, masa tamat, kesan pendua dan kegagalan audit mempunyai laluan tolak, pemutus litar dan pemulihan, yang disahkan melalui kotak pasir dan pelancaran berperingkat.”
Kesilapan biasa
Menganggap anotasi sebagai kebenaran
Corak kegagalan: membenarkan panggilan secara automatik kerana ia membawa readOnlyHint. Mengapa ia gagal: spesifikasi MCP menyatakan bahawa anotasi daripada pelayan yang tidak dipercayai tidak boleh dianggap sebagai fakta keselamatan. Pembetulan: gunakan anotasi sebagai petunjuk; peroleh kebenaran daripada pendaftaran, dasar dan pemeriksaan keupayaan masa jalanan.
Hanya mengesahkan hujah yang dijana
Corak kegagalan: melaksanakan sebaik sahaja pengesahan JSON Schema berjaya. Mengapa ia gagal: hujah yang ditaip dengan betul masih boleh merentasi penyewa, menyasarkan pengeluaran, atau mengulangi tindakan yang tidak boleh diubah. Pembetulan: sahkan prinsipal, pemilikan sumber, risiko, keidempotetan dan digest kelulusan juga.
Hanya menunjukkan kelulusan bahasa semula jadi
Corak kegagalan: meminta pengguna meluluskan "kendalikan bayaran balik". Mengapa ia gagal: objek yang diluluskan adalah samar-samar, jadi jumlah atau akaun boleh berubah pada masa pelaksanaan. Pembetulan: paparkan sasaran, jumlah, versi, digest parameter, masa luput dan ikat kelulusan kepada digest tersebut.
Menganggap output alat sebagai arahan yang dipercayai
Corak kegagalan: mencantumkan teks yang dikembalikan ke dalam prompt sistem seterusnya. Mengapa ia gagal: hasil boleh mengandungi suntikan prompt, data rentas penyewa atau URI berniat jahat. Pembetulan: kuarantin hasil, sahkan jenis, labelkan data dan hantar medan minimum yang diperlukan sahaja.
Hanya mereka bentuk laluan bahagia (happy path)
Corak kegagalan: mencuba semula setiap masa tamat dan meneruskan selepas setiap ralat. Mengapa ia gagal: keadaan pelaksanaan yang tidak diketahui boleh menduplikasi penulisan, manakala penyiapan separa boleh melanggar invarian perniagaan. Pembetulan: reka bentuk keidempotetan, carian status, pampasan, pemutus litar dan eskalasi manusia bersama-sama.
Soalan susulan dan respons
Bagaimana jika katalog alat berubah semasa panggilan dibuat?
Bekukan cap jari pelayan, versi alat dan skema yang digunakan oleh panggilan tersebut. Perubahan katalog hanya mempengaruhi panggilan baharu. Jika versi tersebut dibatalkan, enjin dasar menolak token lama dan meminta kelulusan baharu.
Bagaimana jika perkhidmatan kelulusan tidak tersedia?
Gagal tutup (fail closed) untuk tindakan berisiko tinggi, dengan mengekalkan cadangan dalam barisan gilir yang belum selesai. Pembacaan berisiko rendah boleh diteruskan di bawah dasar yang telah diluluskan sebelumnya, tetapi ia tetap memancarkan peristiwa audit; masa tamat kelulusan bukanlah satu kebenaran.
Bagaimana jika JSON yang sah mengandungi data penyewa lain?
Skema output mengesahkan bentuk data, bukan skop kebenaran. Hantar skop penyewa dan sumber ke hiliran serta periksa pemilikan, label data dan kekardinalan hasil sebelum melepaskan hasil. Kuarantin dan beri amaran jika berlaku pelanggaran.
Bagaimanakah anda memutuskan sama ada alat boleh dijalankan secara automatik?
Nilaikan kebolehbalikan, radius impak (blast radius), kepekaan data, kos pendua dan kebolehkesanan. Pertanyaan yang boleh diundur, berkepekaan rendah dan berimpak rendah boleh dijalankan secara automatik; pergerakan wang, perubahan pengeluaran, pemadaman dan pembacaan rentas penyewa memerlukan kelulusan manusia atau aliran kerja khas.
Bagaimanakah anda menyiasat suntikan prompt?
Kaitkan input asal, versi penerangan alat, cadangan model, keputusan dasar, paparan kelulusan, hasil alat dan panggilan seterusnya menggunakan ID permintaan. Batalkan pelayan dan token yang terjejas terlebih dahulu, kemudian mainkan semula keputusan daripada log yang dikuarantin untuk mengenal pasti kesan sampingan yang telah selesai.