Cara Menguji Agen AI yang Memanggil API Anda Tanpa Kehilangan Data

Sebuah agen pengodean AI menjalankan skrip, menyaksikannya berhasil, lalu melihat tabel basis data produksi menghilang. Post-mortem Hacker News menjadi viral dengan judul tajam: "AI tidak menghapus basis data Anda, Andalah yang menghapusnya." Poin ini diterima karena memang benar. Agen mengikuti definisi alat, alat tersebut mengenai *endpoint* sungguhan, *endpoint* tersebut tidak memiliki *guardrail*, dan seorang manusia telah menyerahkan kunci kepada 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 *billing loop* menghabiskan ratusan dolar dalam *token* sebelum ada yang menyadarinya. Permukaan berbeda, kelas kegagalan yang sama. Masalahnya bukan modelnya yang bodoh. Masalahnya adalah tidak ada yang menguji API.

TL;DR

Agen gagal dalam produksi ketika alat mereka tidak memiliki *guardrail* sisi-API: batas laju yang hilang, tidak ada *idempotency*, penghapusan langsung, skema yang rusak. Anda memperbaikinya dengan empat langkah: melakukan *contract test* definisi alat agen terhadap spesifikasi OpenAPI Anda, menjalankan *mock server* untuk *endpoint* yang merusak, menegakkan anggaran per agen dan kunci *idempotency*, dan memutar ulang skenario kegagalan di CI. Apidog memberi Anda impor OpenAPI, *mock*, dan *scenario runner* untuk melakukan semuanya dari satu proyek.

Pendahuluan

Setahun yang lalu, "menguji agen AI" berarti memberikan *prompt* kepada Claude atau GPT dan menilai jawabannya. Itu bukan lagi standarnya. Agen saat ini memanggil fungsi, fungsi-fungsi itu mengenai API Anda, dan API Anda berbicara dengan basis data sungguhan, 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.

Cerita viral Hacker News bulan ini menangkap pergeseran tersebut. Penulis berpendapat bahwa AI tidak menghapus basis data; manusialah yang melakukannya, dengan memberikan akses tulis kepada agen tanpa menempatkan kontrol apa pun antara model dan data. Utas tersebut meledak karena setiap pengembang yang membacanya berpikir, "Saya hampir saja mengirimkan itu." Beberapa minggu sebelumnya, sebuah postingan Reddit menjelaskan *billing loop* di mana seorang agen mencoba kembali panggilan yang gagal berkali-kali sehingga tagihan melampaui 800 euro sebelum ada yang menyadarinya. Akar penyebab 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 menyeluruh. Kami akan membahas empat *guardrail* yang dibutuhkan setiap pengaturan agen-API, memandu Anda melalui alur kerja Apidog langkah demi langkah untuk memalsukan *endpoint* yang merusak, dan diakhiri dengan teknik lanjutan seperti deteksi *schema-drift* dan pemisahan kunci ganda. Anda akan pulang dengan pola konkret yang dapat Anda salin ke repositori Anda hari ini. Unduh Apidog sebelum Anda mulai agar Anda dapat mengikuti langkah-langkah *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 *prompt injection*. Seorang pengguna mengunggah PDF dengan instruksi tersembunyi, agen membacanya, dan panggilan alat berikutnya menuju *endpoint* /admin/users Anda dengan delete_all=true. Model tidak memilih ini; ia mengikuti instruksi yang tidak ada alasan untuk tidak dipercayai. Perbaikannya bukanlah memperketat *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 *prompt engineering*.

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

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

Ambil contoh *idempotency* yang hilang. Agen memanggil POST /payments untuk menagih pelanggan, mengalami *timeout* jaringan, 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 *idempotency* memecahkan masalah ini dalam lima baris kode server, tetapi Anda harus menulisnya.

Benang merahnya: dalam setiap insiden ini, agen melakukan persis seperti yang diperintahkan alatnya. Alat-alat itu adalah API. Jadi, saat Anda mengaudit di mana keandalan agen rusak, lihat kontrak API terlebih dahulu, kemudian *harness* agen, 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 cerdas. Anda memerlukan API yang dapat diuji dengan *guardrail* yang diaktifkan.

Empat *guardrail* 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 paling atas. Jika Anda bisa melakukan keempatnya, Anda telah mencakup lebih dari 90 persen skenario insiden yang akan Anda lihat pada tahun 2026.

1. *Contract test* skema alat

Spesifikasi OpenAPI Anda adalah sumber kebenaran untuk API Anda. Agen Anda memiliki definisi alat terpisah, seringkali ditulis tangan atau disalin-tempel dari dokumentasi. Dua artefak ini terus-menerus bergeser. *Contract test* 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. Gagal *build* jika daftar tidak kosong. Pemeriksaan tunggal ini akan menangkap *bug float-vs-cents* di bagian sebelumnya berbulan-bulan sebelum ada pengembalian dana dikeluarkan.

2. Lingkungan *sandbox* dan *mock* untuk *endpoint* yang merusak

Agen membutuhkan tempat untuk berlatih. Mereka tidak boleh berlatih dalam produksi. Polanya lugas: setiap *endpoint* yang mengubah *state* memiliki *mock* yang setara yang mengembalikan bentuk respons yang sama tanpa melakukan pekerjaan. *Dev loop* agen Anda menggunakan *mock*. *Staging test* Anda menggunakan basis data *sandbox*. Produksi tetap tidak tersentuh sampai manusia menyetujui *deploy*.

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

3. Kunci *idempotency* dan *soft delete* untuk operasi yang tidak dapat diubah

Setiap *endpoint* tulis yang dapat dipanggil agen Anda harus menerima kunci *idempotency*. Setiap penghapusan harus berupa *soft delete* secara *default* dengan jalur *hard-delete* terpisah yang diotorisasi oleh manusia.

*Middleware* 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 berantakan" 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 *runaway loop*, dan pada saat manusia memeriksanya, kerugian telah terjadi.

Sebuah *budget middleware* yang membungkus *API gateway* Anda mungkin melacak:

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

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

Keempat kontrol ini saling melengkapi. *Contract test* menangkap kesalahan skema yang jelas. *Mock* menangkap yang merusak. *Idempotency* menangkap badai coba ulang. Anggaran menangkap *runaway loop*. Bersama-sama, mereka mengubah "agen melakukan sesuatu yang mengerikan" menjadi "agen menemui 429, mencatat masalah, dan meminta bantuan." Itulah standarnya.

Uji panggilan API agen dengan Apidog

Sekarang bagian praktisnya. Berikut cara mengatur alur kerja pengujian agen-API lengkap di Apidog. Anda 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 berkas 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 melakukannya; keandalan agen bergantung pada memiliki satu sumber kebenaran yang dibaca oleh manusia dan agen AI Anda. Panduan alur kerja API *design-first* menjelaskan hal ini jika Anda memulai dari awal.

Langkah 2: Definisikan *mock response* untuk *endpoint* yang merusak

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

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

Langkah 3: Tulis skenario yang mensimulasikan urutan panggilan agen

Skenario Apidog memungkinkan Anda merangkai panggilan API dengan *assertion*, sama seperti yang dilakukan oleh *test suite*. Untuk agen yang menyeleksi tiket dukungan, skenarionya mungkin:

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

Anda secara efektif berlatih apa yang akan dilakukan agen, pada *mock server*, dengan *assertion* pada setiap lompatan. Jika seorang pengembang mengubah skema tiket dan *regex* berhenti cocok, skenario gagal dan Anda tahu sebelum agen melihat 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 apa pun. Perintahnya terlihat seperti apidog run -t scenario-id --env test. Kaitkan ini ke *pipeline* PR Anda sehingga setiap perubahan pada spesifikasi OpenAPI atau definisi alat agen memicu pemutaran ulang skenario lengkap.

Langkah 5: Bandingkan dua versi model secara berdampingan

Saat Anda mengevaluasi apakah akan meningkatkan dari satu model ke model lain, Anda ingin tahu apakah panggilan alat model baru berperilaku sama pada skenario yang sama. Jalankan agen terhadap skenario Apidog yang sama dengan model A, tangkap *trace*-nya. Jalankan lagi dengan model B, tangkap *trace*-nya. Bedakan isi permintaan. Kejutan segera muncul: model B melewati nilai priority yang berbeda, atau menghilangkan bidang, atau menggunakan format yang berbeda untuk tanggal. Anda menangkap *behavioural drift* sebelum dikirim. 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 sekitar satu jam untuk pengaturan pertama kali dan menit per jalankan setelahnya. Imbalannya adalah setiap perubahan pada API atau alat agen Anda diuji terhadap *baseline* ekspektasi yang sama.

Teknik Lanjutan dan Kiat Profesional

Beberapa pola yang dicari oleh tim berpengalaman setelah dasar-dasarnya diterapkan.

Sematkan 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 acak apa pun. Anda menguji lapisan alat, bukan lapisan kreativitas.

*Snapshot tool-call traces*. Setiap jalankan pengujian mencatat urutan panggilan alat yang tepat yang dibuat agen, beserta argumennya. Bandingkan dengan *baseline* sebelumnya. Jika agen tiba-tiba mulai memanggil /users dua kali alih-alih sekali, Anda ingin tahu itu segera, bukan tiga minggu kemudian saat tagihan datang.

Jangan pernah memberikan kredensial produksi kepada agen. Agen mendapatkan *scoped service account*. Kredensial produksi disimpan di *vault*, bukan di berkas .env yang dapat dibaca agen. Jika agen perlu memanggil *endpoint* produksi, ia melewati *proxy* yang menandatangani permintaan dengan *token* berumur pendek.

Pisahkan kunci API baca dan tulis. Sebagian besar tugas agen bersifat hanya-baca. Keluarkan kunci hanya-baca untuk tugas-tugas tersebut. Kunci tulis dicadangkan 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 bisa melakukan ini" sementara 423 menyiratkan "Anda belum bisa melakukan ini."

Gagal tertutup pada *schema drift*. Jika definisi alat agen tidak cocok dengan spesifikasi OpenAPI Anda, *build* akan gagal. Jangan kirim peringatan. Kirim kesalahan. Biaya beberapa *build* yang gagal tambahan jauh lebih rendah daripada satu insiden produksi.

Kesalahan umum yang harus dihindari:

• *Hardcoding* URL *mock* ke dalam *prompt* agen. Gunakan variabel lingkungan agar *prompt* yang sama berjalan terhadap *mock*, *staging*, dan *prod*.
• Melewatkan *idempotency* pada *endpoint* "kecil". Setiap operasi tulis membutuhkannya. Pengiriman email bukanlah pengecualian.
• Mencatat *full request body* dalam produksi. PII bocor ke *observability stack* Anda. Sembunyikan *token*, email, dan *identifier* sebelum mencapai *log*.
• Membiarkan agen memiliki akses basis data langsung. 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 yakin masih dapat memanggil *endpoint* yang salah.

Jika agen Anda berbicara dengan layanan internal yang tidak berada di belakang *API gateway* tunggal, pola pengujian *microservices* mencakup cara menyebarkan *scenario test* di seluruh layanan.

Alternatif dan Perkakas

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

Ringkasan jujur: jika Anda menggunakan LangSmith, terus lakukan apa yang berfungsi di sisi agen dan tambahkan lapisan pengujian API terpisah. Jika Anda sudah tidak sesuai 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 memadukan ini. Mereka menggunakan LangSmith untuk evaluasi tingkat *prompt* dan menggunakan Apidog untuk *contract test* sisi-API dan pemutaran ulang skenario. Itu bekerja dengan baik; alat-alat tersebut melayani lapisan yang berbeda.

Kasus Penggunaan Dunia Nyata

Agen memperbarui baris basis data produksi. Sebuah tim keberhasilan pelanggan membangun agen yang memperbarui bidang akun dari tiket dukungan. Sebelum peluncuran, mereka mengikat setiap *endpoint* tulis untuk memerlukan kunci *idempotency* dan menjalankan 200 pemutaran ulang skenario di Apidog terhadap basis data *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. Sebuah tim *fintech* yang membangun agen pengembalian dana otomatis menetapkan batas keras: maksimal 5 pengembalian dana per sesi, maksimal 50 dolar per pengembalian dana, *idempotency* diperlukan pada setiap panggilan. Mereka menjalankan *contract test suite* terhadap OpenAPI Stripe pada setiap PR. Enam bulan kemudian, mereka telah memproses 12.000 pengembalian dana tanpa biaya ganda.

Agen menyeleksi masalah GitHub. Sebuah tim platform membangun agen penyeleksi masalah yang terinspirasi oleh Clawsweeper. Mereka membuat *mock* API GitHub di Apidog, menjalankan agen melalui 50 *scenario test* yang mencakup *edge case* (masalah yang dihapus, label yang hilang, *input* pengguna yang salah format), dan menemukan tiga *crash* sebelum peluncuran. Agen tersebut sekarang menangani penyeleksian di repositori publik dengan 5.000 masalah terbuka.

Kesimpulan

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

Lima poin penting:

• Perlakukan skema alat sebagai kontrak dan jalankan *contract test* di CI.
• Buat *mock* *endpoint* yang merusak untuk setiap *dev loop* agen.
• Wajibkan kunci *idempotency* pada setiap operasi tulis yang dapat dipanggil agen Anda.
• Tetapkan batas anggaran per agen yang akan gagal tertutup saat batas tersebut 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 *guardrail*. Unduh Apidog dan mulailah dengan langkah *mock-server*; itu saja akan menyelamatkan Anda dari malam tanpa tidur kuartal ini. Untuk perspektif tim QA tentang masalah yang sama ini, 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 berkas AGENTS.md.

FAQ

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

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

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 menghasilkan *bug*. Anda memerlukan kedua lapisan diuji secara terpisah.

Apakah saya memerlukan kunci *idempotency* pada setiap *endpoint*?

Ya, pada setiap *endpoint* tulis. Operasi baca bersifat *idempotent* berdasarkan definisi. Operasi tulis tidak, dan agen akan mencoba lagi. Lima baris *middleware* untuk mendukung *header idempotency* akan terbayar sendiri saat agen mencoba kembali kesalahan 500 dan Anda tidak mendapatkan baris duplikat.

Bagaimana cara mencegah *prompt injection* memicu panggilan API yang buruk?

Jangan hanya bergantung pada lapisan *prompt*. API harus menegakkan otorisasi berdasarkan konteks pengguna asli, bukan permintaan agen. Jika sesi konteks pengguna biasanya tidak dapat mencapai /admin/delete-all-users, maka agen yang bertindak atas nama pengguna tersebut juga tidak boleh dapat melakukannya, terlepas dari apa yang dikatakan *prompt*. OWASP's LLM Top 10 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. Ketika Anda siap untuk menguji terhadap *staging* atau produksi, ubah variabel tersebut.

Berapa batas anggaran yang tepat untuk agen?

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

Bagaimana cara mendeteksi *schema drift* antara alat agen saya dan API saya?

Jalankan *schema diff* di CI pada setiap PR. Bandingkan definisi alat agen (skema JSON) dengan skema *request body* OpenAPI untuk *endpoint* yang sama. Gagal *build* jika mereka menyimpang. Cuplikan Python 30 baris di bagian *guardrail* di atas melakukan ini; salin ke repositori Anda dan sambungkan ke GitHub Actions.