Cara Menguji Agen AI yang Memanggil API Anda Tanpa Kehilangan Data

Seorang agen coding AI menjalankan skrip, melihatnya berhasil, lalu melihat tabel database produksi menghilang. Post-mortem Hacker News menjadi viral dengan judul tajam: "AI tidak menghapus database Anda, Anda yang melakukannya." Poin ini tepat karena memang benar. Agen mengikuti definisi alat, alat tersebut memukul endpoint nyata, endpoint tersebut tidak memiliki pagar pembatas, dan manusia telah menyerahkan kunci ke proses yang tidak berhenti untuk bertanya apakah DELETE FROM users terlihat mencurigakan. Sebuah utas r/ClaudeAI terpisah menceritakan kisah serupa dari sudut pandang berbeda: seorang agen dalam loop penagihan menghabiskan ratusan dolar dalam token sebelum ada yang menyadarinya. Permukaan berbeda, kelas kegagalan yang sama. Masalahnya bukan karena modelnya bodoh. Masalahnya adalah tidak ada yang menguji API.

TL;DR

Agen gagal dalam produksi ketika alat mereka tidak memiliki pagar pembatas sisi API: batas laju yang hilang, tanpa idempoten, penghapusan langsung, skema yang rusak. Anda memperbaikinya dengan empat langkah: uji kontrak definisi alat agen terhadap spesifikasi OpenAPI Anda, jalankan server tiruan untuk endpoint destruktif, terapkan batas anggaran per agen dan kunci idempoten, dan putar ulang skenario kegagalan di CI. Apidog memberi Anda impor OpenAPI, tiruan (mock), dan pelari skenario untuk melakukan semua itu dari satu proyek.

Pendahuluan

Setahun yang lalu, "menguji agen AI" berarti memberikan prompt ke Claude atau GPT dan menilai jawabannya. Itu bukan lagi standar. Agen saat ini memanggil fungsi, fungsi-fungsi tersebut memukul API Anda, dan API Anda berbicara dengan database nyata, pemroses pembayaran, dan layanan pihak ketiga. Definisi alat yang buruk atau batas laju yang hilang bukanlah masalah gaya. Itu adalah insiden produksi yang mencantumkan nama Anda.

Kisah viral Hacker News bulan ini menangkap perubahan tersebut. Penulis berargumen bahwa AI tidak menghapus database; manusialah yang melakukannya, dengan memberikan agen akses tulis tanpa menempatkan kontrol apa pun antara model dan data. Utas tersebut meledak karena setiap pengembang yang membacanya pasti berpikir, "Saya hampir mengirimkan itu." Beberapa minggu sebelumnya, sebuah postingan Reddit menjelaskan loop penagihan di mana seorang agen mencoba lagi panggilan yang gagal berkali-kali sehingga tagihan melampaui 800 euro sebelum ada yang menyadarinya. Akar masalah yang sama: kepercayaan ditempatkan pada lapisan yang salah.

Anda bisa memperbaikinya. Lapisan model itu penting, tetapi lapisan API adalah tempat Anda menghentikan pendarahan. Artikel ini menunjukkan kepada Anda cara menguji integrasi API agen AI secara end-to-end. Kami akan membahas empat pagar pembatas yang dibutuhkan setiap pengaturan agen-API, membahas alur kerja Apidog langkah demi langkah untuk memalsukan endpoint destruktif, dan diakhiri dengan teknik lanjutan seperti deteksi pergeseran skema dan pemisahan kunci ganda. Anda akan pulang dengan pola konkret yang dapat Anda salin ke repo Anda hari ini. Unduh Apidog sebelum Anda mulai sehingga Anda dapat mengikuti langkah-langkah server tiruan (mock-server).

Mengapa Kegagalan Agen Terlihat Seperti Kegagalan API

Bacalah cukup banyak post-mortem agen dan sebuah pola akan muncul: model bukanlah protagonisnya. API-lah yang menjadi protagonis.

Ambil contoh injeksi prompt. Pengguna mengunggah PDF dengan instruksi tersembunyi, agen membacanya, dan panggilan alat berikutnya menuju ke endpoint /admin/users Anda dengan delete_all=true. Model tidak memilih ini; ia mengikuti instruksi yang tidak ada alasan untuk tidak dipercayai. Perbaikannya bukan memperkeras prompt. Perbaikannya adalah membangun API yang tidak mengekspos delete_all=true ke token yang berasal dari sesi konteks pengguna. OWASP menyebut ini LLM01 dalam LLM Top 10 mereka, dan mitigasinya adalah otorisasi sisi API, bukan rekayasa prompt (prompt engineering).

Ambil contoh skema alat yang salah. Spesifikasi OpenAPI Anda mengatakan amount adalah bilangan bulat dalam sen. Definisi alat agen mengatakan amount adalah float dalam dolar. Tiga bulan kemudian, seseorang mengembalikan biaya 19 sen sebagai 19 dolar dan Anda mengetahui ketidakcocokan dari bagian akuntansi. Model tidak salah; model menggunakan skema yang Anda berikan. Skema tersebut menyimpang dari API. Tidak ada yang menguji kontrak.

Ambil contoh batas laju yang hilang. Sebuah agen dalam loop coba ulang (retry loop) menghantam endpoint email transaksional Anda seribu kali dalam dua menit karena perencana agen terus menandai langkah tersebut sebagai "belum berhasil." Setiap percobaan ulang membutuhkan biaya. Setiap percobaan ulang mengantrekan email nyata. Pada saat Anda bangun, penyedia Anda telah menandai akun Anda dan pelanggan Anda menerima spam. Model tidak berniat jahat. Model bekerja dari alat yang tidak memiliki batas.

Ambil contoh idempoten yang hilang. Agen memanggil POST /payments untuk menagih pelanggan, mendapatkan batas waktu jaringan (network timeout), mencoba lagi karena perencana mengira panggilan gagal, dan sekarang pelanggan ditagih dua kali. Lapisan agen tidak dapat mengetahui apakah panggilan asli berhasil; API tidak memberinya cara untuk bertanya. Kunci idempoten mengatasi ini dalam lima baris kode server, tetapi Anda harus menulisnya.

Benang merahnya: dalam setiap insiden ini, agen melakukan persis seperti yang diinstruksikan oleh alatnya. Alat-alat tersebut adalah API. Jadi, ketika Anda mengaudit di mana keandalan agen rusak, lihatlah kontrak API terlebih dahulu, perangkat agen kedua, dan model itu sendiri hampir tidak pernah. Pembingkaian ulang ini penting karena memberi tahu Anda di mana harus berinvestasi. Anda tidak memerlukan model yang lebih pintar. Anda memerlukan API yang dapat diuji dengan pagar pembatas diaktifkan.

Empat Pagar Pembatas yang Dibutuhkan Setiap Integrasi Agen-API

Empat kontrol memisahkan pengaturan agen yang gagal dengan aman dari pengaturan yang gagal dengan mahal. Jika Anda hanya punya waktu untuk menambahkan satu saja kuartal ini, mulailah dari yang teratas. Jika Anda bisa melakukan keempatnya, Anda telah mencakup lebih dari 90 persen skenario insiden yang akan Anda lihat pada tahun 2026.

1. Pengujian Kontrak Skema Alat

Spesifikasi OpenAPI Anda adalah sumber kebenaran untuk API Anda. Agen Anda memiliki definisi alat yang terpisah, seringkali ditulis tangan atau disalin-tempel dari dokumen. Kedua artefak ini terus-menerus menyimpang. Pengujian kontrak akan menggagalkan build CI Anda saat mereka menyimpang.

Berikut adalah pemeriksaan Python minimal yang memvalidasi definisi alat gaya Claude terhadap spesifikasi OpenAPI langsung:

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Return a list of mismatch errors, empty list = pass."""
    errors = []
    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Tool missing required field: {missing}")
    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]
            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Type mismatch on {prop}: API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )
    return errors

Jalankan ini pada setiap PR yang menyentuh spesifikasi OpenAPI atau definisi alat. Gagalkan build jika daftar tidak kosong. Pemeriksaan tunggal ini akan menangkap bug float-vs-cents di bagian sebelumnya berbulan-bulan sebelum ada pengembalian dana keluar.

2. Lingkungan Sandbox dan Mock untuk Endpoint Destruktif

Agen membutuhkan tempat untuk berlatih. Mereka tidak boleh berlatih dalam produksi. Polanya lugas: setiap endpoint yang mengubah status memiliki padanan tiruan (mock) yang mengembalikan bentuk respons yang sama tanpa melakukan pekerjaan. Loop pengembangan agen Anda menggunakan tiruan. Pengujian staging Anda menggunakan database sandbox. Produksi tetap tidak tersentuh sampai manusia menyetujui penerapan.

Apidog menghasilkan tiruan langsung dari spesifikasi OpenAPI, termasuk nilai bidang realistis yang didorong oleh pola Faker. Anda mengarahkan URL dasar agen Anda ke server tiruan, menjalankan seratus iterasi prompt Anda, dan mengamati bagaimana perilakunya. Jika agen terus mencoba PUT ke /users/{id}/delete karena salah memahami dokumen, tiruan akan menangkapnya. Tabel pengguna di produksi tidak pernah melihat kesalahan tersebut. Lihat pengembangan berbasis kontrak (contract-first development) untuk pola yang lebih luas yang cocok dengan ini.

3. Kunci Idempoten dan Penghapusan Lunak untuk Operasi yang Tidak Dapat Dibatalkan

Setiap endpoint tulis yang dapat dipanggil agen Anda harus menerima kunci idempoten. Setiap penghapusan harus berupa penghapusan lunak (soft delete) secara default dengan jalur penghapusan keras terpisah yang diotorisasi oleh manusia.

Middleware-nya terlihat seperti ini di Express:

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers['idempotency-key'];
  if (!key) {
    return res.status(400).json({ error: 'Missing Idempotency-Key header' });
  }
  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }
  const originalJson = res.json.bind(res);
  res.json = function (body) {
    idempotencyCache.set(key, { status: res.statusCode, body });
    setTimeout(() => idempotencyCache.delete(key), 24 * 60 * 60 * 1000);
    return originalJson(body);
  };
  next();
}

app.post('/payments', idempotency, createPayment);

Agen menghasilkan UUID per operasi logis dan menggunakannya kembali pada percobaan ulang. API Anda mengembalikan respons yang di-cache pada panggilan kedua alih-alih menagih dua kali. Pola yang sama ini melindungi dari pengiriman ganda di API perpesanan, pembuatan baris duplikat di CRM, dan sebagian besar skenario "agen mencoba lagi dan sekarang kita kacau" lainnya.

4. Batas Anggaran Per Agen

Setiap agen mendapatkan anggaran. Anggaran token, anggaran permintaan, anggaran dolar, anggaran waktu. Ketika anggaran habis, agen berhenti. Tanpa pengecualian. Insiden Reddit 800 euro terjadi karena tidak ada yang menetapkan batas pada loop yang tidak terkendali, dan pada saat manusia memeriksanya, kerusakan telah terjadi.

Middleware anggaran yang membungkus gateway API Anda mungkin melacak:

• Token per sesi, dibatasi hingga 50.000
• Panggilan API per menit, dibatasi hingga 30
• Pengeluaran kumulatif dalam sen, dibatasi hingga 500
• Kedalaman panggilan alat, dibatasi hingga 10 panggilan bersarang

Ketika batas tercapai, kembalikan HTTP 429 dengan Retry-After terstruktur dan header X-Budget-Exceeded yang menyebutkan batas tersebut. Perencana agen kemudian dapat meningkatkan ke manusia atau membatalkan tugas. Pasangkan ini dengan logging sehingga Anda dapat melihat agen mana yang mendorong batas dan menyesuaikannya.

Keempat kontrol ini saling melengkapi. Pengujian kontrak menangkap kesalahan skema yang jelas. Tiruan menangkap yang merusak. Idempoten menangkap badai percobaan ulang. Anggaran menangkap loop yang tidak terkendali. Bersama-sama, mereka mengubah "agen melakukan sesuatu yang mengerikan" menjadi "agen mencapai 429, mencatat masalah, dan meminta bantuan." Itulah standarnya.

Uji Panggilan API Agen dengan Apidog

Sekarang bagian praktisnya. Berikut cara menyiapkan alur kerja pengujian agen-API lengkap di Apidog. Anda akan memerlukan spesifikasi OpenAPI untuk API yang dipanggil agen Anda, ditambah daftar definisi alat agen.

Langkah 1: Impor Spesifikasi OpenAPI

Buka Apidog, buat proyek baru, dan impor file OpenAPI 3.x Anda. Apidog mengurai setiap jalur, skema, dan contoh, serta membuat endpoint yang sesuai dalam proyek. Jika API Anda belum didokumentasikan dalam OpenAPI, inilah saatnya untuk melakukannya; keandalan agen bergantung pada memiliki satu sumber kebenaran yang dibaca oleh manusia dan agen AI Anda. Panduan alur kerja API design-first akan memandu Anda melalui ini jika Anda memulai dari awal.

Langkah 2: Definisikan Respons Mock untuk Endpoint Destruktif

Temukan setiap endpoint yang mengubah data: POST, PUT, PATCH, DELETE. Untuk setiap endpoint, klik dan tambahkan respons mock. Apidog dapat secara otomatis menghasilkan mock realistis dari skema Anda, tetapi Anda harus menimpa nilai bidang sehingga terlihat seperti data pengujian, bukan data produksi. Gunakan awalan seperti mock_user_ dan stempel waktu di tahun 1970 agar setiap kebocoran jelas terlihat di log.

Mulai server mock. Apidog memberi Anda URL stabil seperti https://mock.apidog.com/m1/your-project-id/. Arahkan URL dasar agen Anda ke server mock selama pengembangan. Sekarang DELETE /users/{id} Anda mengembalikan 200 dengan payload pengguna palsu, dan database asli Anda aman.

Langkah 3: Tulis Skenario yang Mensimulasikan Urutan Panggilan Agen

Skenario Apidog memungkinkan Anda merangkai panggilan API dengan pernyataan (assertions), sama seperti yang dilakukan suite pengujian. Untuk agen yang melakukan triase tiket dukungan, skenarionya mungkin:

1. POST /auth/token dengan kredensial pengujian, tangkap token bearer
2. GET /tickets?status=open dengan token, tangkap ID tiket pertama
3. POST /tickets/{id}/triage dengan kategori, pastikan 200 dan tangkap bidang assigned-to
4. POST /notifications dengan pesan ber-template, pastikan badan pesan cocok dengan regex

Anda secara efektif melatih apa yang akan dilakukan agen, pada server mock, dengan pernyataan pada setiap lompatan. Jika pengembang mengubah skema tiket dan regex berhenti cocok, skenario gagal dan Anda mengetahuinya sebelum agen masuk ke produksi. Lihat pengujian API untuk insinyur QA untuk playbook pengujian skenario yang lebih luas.

Langkah 4: Jalankan dari CI

Apidog menyediakan CLI yang menjalankan skenario dari GitHub Action, GitLab pipeline, atau runner CI mana pun. Perintahnya terlihat seperti apidog run -t scenario-id --env test. Sambungkan ini ke pipeline PR Anda sehingga setiap perubahan pada spesifikasi OpenAPI atau definisi alat agen memicu putar ulang skenario penuh.

Langkah 5: Bandingkan Dua Versi Model Secara Berdampingan

Saat Anda mengevaluasi apakah akan meng-upgrade dari satu model ke model lain, Anda ingin mengetahui apakah panggilan alat model baru berperilaku sama pada skenario yang sama. Jalankan agen terhadap skenario Apidog yang sama dengan model A, tangkap jejaknya. Jalankan lagi dengan model B, tangkap jejaknya. Bandingkan badan permintaan (request bodies). Kejutan akan segera muncul: model B meneruskan nilai priority yang berbeda, atau menghilangkan bidang, atau menggunakan format yang berbeda untuk tanggal. Anda menangkap pergeseran perilaku sebelum diluncurkan. Ini adalah salah satu pola yang dibahas dalam integrasi API GPT-5.5, di mana mengevaluasi perilaku model baru adalah kebutuhan yang berulang.

Seluruh alur kerja membutuhkan waktu sekitar satu jam untuk pengaturan pertama kali dan menit per eksekusi setelahnya. Hasilnya adalah setiap perubahan pada API atau alat agen Anda diuji terhadap dasar harapan yang sama.

Teknik Lanjutan dan Kiat Pro

Beberapa pola yang dicari tim berpengalaman setelah dasar-dasarnya sudah ada.

• Tetapkan suhu ke nol dalam pengujian. Agen non-deterministik menghasilkan kegagalan pengujian non-deterministik. Saat Anda menguji perilaku panggilan alat, atur suhu ke 0 dan berikan seed pada sumber keacakan apa pun. Anda sedang menguji lapisan alat, bukan lapisan kreativitas.
• Tangkap jejak panggilan alat. Setiap eksekusi pengujian merekam urutan panggilan alat yang tepat yang dilakukan agen, beserta argumennya. Bandingkan dengan baseline sebelumnya. Jika agen tiba-tiba mulai memanggil /users dua kali alih-alih sekali, Anda ingin segera mengetahuinya, bukan tiga minggu kemudian saat tagihan datang.
• Jangan pernah memberikan kredensial produksi kepada agen. Agen mendapatkan akun layanan dengan cakupan terbatas. Kredensial produksi disimpan di vault, bukan di file .env yang dapat dibaca agen. Jika agen perlu memanggil endpoint produksi, ia melewati proxy yang menandatangani permintaan dengan token berjangka pendek.
• Pisahkan kunci API baca dan tulis. Sebagian besar tugas agen adalah membaca. Berikan kunci hanya-baca untuk tugas-tugas tersebut. Kunci tulis disediakan untuk tugas-tugas yang memiliki gerbang persetujuan manusia. Perubahan tunggal ini mengurangi radius ledakan agen yang dikompromikan menjadi setengahnya.
• Gunakan HTTP 423 Locked untuk endpoint persetujuan manusia. Ketika agen mencoba memanggil endpoint yang memerlukan konfirmasi manusia, kembalikan 423 dengan bidang confirmation_url. Perencana agen melihat status terkunci, menampilkan URL tersebut kepada manusia, dan menunggu. Ini lebih bersih daripada 403, karena 403 menyiratkan "Anda tidak dapat melakukan ini" sementara 423 menyiratkan "Anda belum dapat melakukan ini".
• Gagal tertutup pada pergeseran skema. Jika definisi alat agen tidak cocok dengan spesifikasi OpenAPI Anda, build akan gagal. Jangan mengirimkan peringatan. Kirimkan kesalahan. Biaya beberapa build tambahan yang gagal jauh lebih rendah daripada satu insiden produksi.

Kesalahan umum yang harus dihindari:

• Meng-hardcode URL mock ke dalam prompt agen. Gunakan variabel lingkungan sehingga prompt yang sama berjalan melawan mock, staging, dan produksi.
• Melewatkan idempoten pada endpoint "kecil". Setiap operasi tulis membutuhkannya. Pengiriman email tidak terkecuali.
• Mencatat seluruh badan permintaan di produksi. PII bocor ke tumpukan observabilitas Anda. Sensor token, email, dan pengenal sebelum mencapai log.
• Membiarkan agen memiliki akses langsung ke database. Selalu melalui API. API adalah tempat pengujian Anda berada.
• Mempercayai skor kepercayaan agen. Skor tersebut mencerminkan kepastian model tentang jawaban, bukan keamanan API. Agen yang 99 persen percaya diri masih bisa memanggil endpoint yang salah.

Jika agen Anda berbicara dengan layanan internal yang tidak berada di belakang satu gateway API, pola pengujian layanan mikro (microservices testing patterns) membahas cara menyebarkan pengujian skenario di seluruh layanan.

Alternatif dan Alat

Anda memiliki pilihan. Berikut adalah perbandingan yang adil dari empat pendekatan umum.

Ringkasan jujurnya: jika Anda terbiasa dengan LangSmith, terus lakukan apa yang berhasil di sisi agen dan tambahkan lapisan pengujian API terpisah. Jika Anda sudah tidak cocok dengan harga Postman atau model mock-nya, Apidog adalah pengganti yang kuat. Jika Anda memulai dari awal, pilih alat yang menangani OpenAPI, mock, dan skenario dalam satu proyek, karena di situlah 80 persen waktu pengujian agen-API Anda dihabiskan.

Beberapa tim menggabungkan ini. Mereka mempertahankan LangSmith untuk evaluasi tingkat prompt dan menggunakan Apidog untuk pengujian kontrak sisi API dan pemutaran ulang skenario. Itu bekerja dengan baik; alat-alat tersebut melayani lapisan yang berbeda.

Studi Kasus Dunia Nyata

• Agen memperbarui baris database produksi. Tim customer success membangun agen yang memperbarui bidang akun dari tiket dukungan. Sebelum diluncurkan, mereka menghubungkan setiap endpoint tulis untuk memerlukan kunci idempoten dan menjalankan 200 pemutaran ulang skenario di Apidog terhadap database sandbox. Pemutaran ulang tersebut menangkap dua kasus di mana agen mencoba mengatur subscription_status ke string yang tidak ada dalam enum. Mereka menambahkan validasi skema dan mengirimkan tanpa insiden.
• Agen memanggil API pembayaran. Tim fintech yang membangun agen pengembalian dana otomatis menetapkan batasan keras: maks 5 pengembalian dana per sesi, maks 50 dolar per pengembalian dana, idempoten wajib pada setiap panggilan. Mereka menjalankan suite pengujian kontrak terhadap OpenAPI Stripe pada setiap PR. Enam bulan kemudian, mereka telah memproses 12.000 pengembalian dana tanpa biaya duplikat.
• Agen melakukan triase masalah GitHub. Tim platform membangun agen triase masalah yang terinspirasi oleh Clawsweeper. Mereka memalsukan API GitHub di Apidog, menjalankan agen melalui 50 pengujian skenario yang mencakup kasus-kasus ekstrem (masalah yang dihapus, label yang hilang, input pengguna yang salah bentuk), dan menemukan tiga crash sebelum peluncuran. Agen tersebut sekarang menangani triase pada repo publik dengan 5.000 masalah terbuka.

Kesimpulan

Jika Anda mengambil satu hal dari panduan ini, ambillah ini: agen bukanlah masalahnya. API-lah masalahnya, atau solusinya, tergantung pada apakah Anda mengujinya.

• Perlakukan skema alat sebagai kontrak dan jalankan pengujian kontrak di CI.
• Palsukan endpoint destruktif untuk setiap loop pengembangan agen.
• Wajibkan kunci idempoten pada setiap operasi tulis yang dapat dipanggil agen Anda.
• Tetapkan batas anggaran per agen yang gagal tertutup saat tercapai.
• Putar ulang skenario pada setiap PR yang menyentuh API atau definisi alat.

Insiden viral tahun ini tidak akan menjadi yang terakhir. Setiap tim yang mengirimkan agen akan mengalami salah satu mode kegagalan ini setidaknya sekali. Tim yang pulih dengan cepat adalah tim yang sudah memiliki pagar pembatas. Unduh Apidog dan mulailah dengan langkah server mock; itu saja akan menyelamatkan Anda dari malam tanpa tidur kuartal ini. Untuk perspektif tim QA tentang masalah yang sama, lihat alat pengujian API untuk insinyur QA. Untuk konteks yang lebih luas tentang penulisan definisi alat yang dapat digunakan agen dengan aman, lihat cara menulis file AGENTS.md.

FAQ (Pertanyaan yang Sering Diajukan)

Bagaimana cara menguji panggilan API agen AI tanpa menghabiskan uang untuk token?

Jalankan agen Anda terhadap server mock selama pengembangan. URL mock Apidog mengembalikan respons realistis secara gratis, sehingga loop pengujian Anda tidak menghabiskan kredit API nyata. Atur suhu ke 0 dan gunakan set prompt tetap yang kecil. Anda dapat menjalankan ribuan iterasi pengujian dengan biaya server mock yang nol. Lihat daftar periksa pengujian insinyur QA untuk pengaturan lengkap.

Apa perbedaan antara menguji agen dan menguji API?

Pengujian agen memeriksa apakah model memilih alat yang tepat dan mengisi argumen dengan benar. Pengujian API memeriksa apakah endpoint berperilaku benar saat dipanggil. Keduanya penting. Agen yang sempurna memanggil API yang rusak masih menghasilkan hasil yang rusak, dan agen yang rusak memanggil API yang sempurna masih mengirimkan bug. Anda perlu menguji kedua lapisan secara terpisah.

Apakah saya membutuhkan kunci idempoten pada setiap endpoint?

Ya, pada setiap endpoint tulis. Pembacaan bersifat idempoten berdasarkan definisi. Penulisan tidak, dan agen akan mencoba lagi. Lima baris middleware untuk mendukung header idempoten akan membayar sendiri pada saat pertama agen mencoba kembali kesalahan 500 dan Anda tidak mendapatkan baris duplikat.

Bagaimana cara mencegah injeksi prompt memicu panggilan API yang buruk?

Jangan hanya mengandalkan lapisan prompt. API harus memberlakukan otorisasi berdasarkan konteks pengguna asli, bukan permintaan agen. Jika sesi konteks pengguna biasanya tidak dapat mengakses /admin/delete-all-users, maka agen yang bertindak atas nama pengguna tersebut juga tidak boleh dapat melakukannya, terlepas dari apa yang dikatakan prompt. LLM Top 10 OWASP membahas ini secara rinci.

Bisakah saya menggunakan Apidog dengan Claude atau GPT secara langsung, tanpa menulis lapisan alat saya sendiri?

Anda mengarahkan definisi alat agen Anda ke URL mock Apidog selama pengujian. Baik Claude maupun GPT mendukung URL dasar HTTP arbitrer dalam definisi alat mereka, sehingga pertukarannya adalah satu variabel lingkungan. Saat Anda siap untuk menguji terhadap staging atau produksi, ubah variabel tersebut.

Berapa batas anggaran yang tepat untuk agen?

Mulailah dengan ketat dan longgarkan dengan data. Mulailah dengan 50.000 token per sesi, 30 panggilan API per menit, 5 dolar per tugas. Pantau metrik selama dua minggu. Naikkan batas yang Anda temui secara sah. Turunkan batas yang tidak pernah Anda capai. Tinjau setiap bulan. Tujuannya bukanlah angka tetap; itu adalah angka yang cukup ketat untuk menangkap loop yang tidak terkendali dan cukup longgar untuk memungkinkan pekerjaan nyata terjadi.

Bagaimana cara mendeteksi pergeseran skema antara alat agen saya dan API saya?

Jalankan perbandingan skema (schema diff) di CI pada setiap PR. Bandingkan definisi alat agen (skema JSON) dengan skema badan permintaan OpenAPI untuk endpoint yang sama. Gagalkan build jika mereka menyimpang. Cuplikan Python 30 baris di bagian pagar pembatas di atas melakukan ini; salin ke repo Anda dan hubungkan ke GitHub Actions.