Serah Terima Multi-Agen: Transfer Konteks Antar Sub-Agen

Serah Terima Multi-Agen Tanpa Kehilangan Konteks

Agen penelitian menemukan akun pelanggan, mengonfirmasi paket, dan mengambil empat faktur terakhir. Namun, agen itu hanya menyerahkan ringkasan satu baris kepada agen penagihan: “Pelanggan ingin pengembalian dana.” Agen kedua tidak mengetahui akun, paket, atau faktur yang dimaksud, lalu mulai dengan menanyakan ID akun. Setiap fakta yang dikumpulkan agen pertama hilang di batas serah terima. Inilah masalah serah terima: Anda membayar dua kali—melalui panggilan API yang berulang dan kesalahan akibat agen kedua bekerja dengan informasi yang lebih sedikit.

Coba Apidog hari ini

Panduan ini membahas:

• Informasi yang harus tetap ada setelah serah terima
• Tiga cara meneruskan status dan kapan menggunakannya
• Mengapa ringkasan sering kehilangan detail penting
• Cara menguji bahwa serah terima membawa informasi yang benar

Tulisan kami tentang mengapa agen gagal dalam produksi menganggap status yang hilang sebagai mode kegagalan inti. Artikel ini membahas versi multi-agennya.

Solusi termurah sering kali adalah tidak meneruskan payload sama sekali—cukup teruskan pengenal. Namun, pola ini hanya bekerja jika setiap agen dapat mengambil catatan yang sama dengan izin dan cara yang konsisten.

Informasi yang perlu melewati batas

Menyalin seluruh percakapan sama buruknya dengan tidak menyalin apa pun. Agen kedua mewarisi jendela konteks penuh dan harus mencari sendiri bagian yang relevan.

Pisahkan status serah terima menjadi empat kategori.

1. Pengenal

Contohnya:

• ID akun
• ID pesanan
• ID pekerjaan
• Nomor tiket

Pengenal berukuran kecil, stabil, dan memungkinkan agen penerima mengambil data yang diperlukan. Ini adalah informasi paling berharga untuk diteruskan, tetapi sering dihilangkan.

2. Keputusan yang sudah dibuat

Contoh:

Pelanggan berhak menerima pengembalian dana berdasarkan kebijakan 3.

Agen penerima tidak seharusnya mengulang keputusan ini. Jika keputusan dibahas ulang, dua agen dapat menghasilkan keputusan yang bertentangan dalam satu tugas.

3. Batasan

Bawa informasi seperti:

• Batas anggaran
• Persetujuan yang telah diberikan
• Tindakan yang sudah dilakukan

Jika batasan hilang, tugas dapat menagih pelanggan dua kali atau meminta persetujuan yang sama lebih dari sekali. Ini berkaitan langsung dengan idempotensi untuk agen AI.

4. Pertanyaan terbuka

Catat hal-hal yang belum dapat diselesaikan agen pertama. Dengan begitu, agen kedua tidak perlu membuat asumsi diam-diam.

Yang tidak perlu diteruskan

Jangan teruskan:

• Respons API mentah
• Transkrip penalaran
• Data yang dapat diambil agen penerima sendiri dalam satu panggilan API

Tiga cara meneruskan status

Meneruskan seluruh percakapan

Ini sederhana dan cukup untuk dua agen dalam satu tugas singkat.

Masalah muncul ketika transkrip menjadi panjang. Agen penerima menghabiskan sebagian besar anggaran konteks untuk membaca riwayat, sementara fakta penting terkubur di tengah. Baca juga penjelasan tentang menjaga respons alat tetap di luar jendela konteks.

Meneruskan ringkasan

Agen pertama menulis pesan serah terima, lalu agen kedua memulai dari pesan tersebut.

Ini adalah default di banyak kerangka kerja, tetapi ringkasan bersifat lossy. Model cenderung meringkas menjadi narasi:

Pelanggan telah berlangganan selama dua tahun dan merasa frustrasi.

Padahal agen penagihan membutuhkan fakta yang dapat ditindaklanjuti:

Akun 8812, paket Pro, empat faktur, pengembalian dana disetujui untuk faktur inv_44.

Ringkasan tetap berguna untuk konteks dan nuansa, tetapi jangan menjadikannya satu-satunya sumber kebenaran.

Meneruskan objek terstruktur

Agen pertama mengisi skema, lalu agen kedua membaca bidang yang telah ditentukan—bukan mencari fakta di dalam prosa.

{
  "task_id": "task_2026_08_26_0031",
  "from_agent": "research",
  "to_agent": "billing",
  "entities": {
    "customer_id": "cus_8812",
    "invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
    "subscription_id": "sub_119"
  },
  "decisions": [
    { "decision": "refund_eligible", "value": true, "basis": "policy 3.2, charged twice in one cycle" }
  ],
  "constraints": {
    "max_refund_cents": 4900,
    "human_approval_granted": false,
    "actions_taken": ["read_invoices"]
  },
  "open_questions": ["Customer has not confirmed which invoice to refund"],
  "summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}

Bidang summary tetap diperlukan untuk membawa nuansa yang tidak cocok dimasukkan ke skema. Namun, prosa harus melengkapi bidang terstruktur, bukan menggantikannya.

Validasi objek sebelum serah terima berjalan. Jika customer_id tidak ada, gagalkan proses di batas serah terima—jangan biarkan agen kedua baru menemukannya setelah tiga panggilan API.

Teruskan referensi, bukan payload

Pola serah terima yang paling kuat hampir tidak meneruskan data. Pola ini hanya meneruskan ID, lalu agen penerima mengambil data terbaru.

Keuntungannya:

1. Status tetap segar. Jika data berubah di antara dua agen, agen kedua melihat nilai terbaru.
2. Payload tetap kecil. Serah terima hanya berisi beberapa ratus byte, bukan puluhan ribu token.
3. Audit trail lebih jelas. Setiap pembacaan tercatat sebagai panggilan API, bukan teks yang disalin antar-prompt.

Prasyaratnya adalah setiap agen dapat mengakses API yang sama dengan izin yang tepat. Setiap agen sebaiknya memiliki kredensial yang dibatasi sesuai tugasnya. Agen penagihan yang hanya memiliki token penelitian read-only tidak boleh mengeluarkan pengembalian dana. Sebaliknya, memberikan token penagihan kepada agen penelitian memperbesar radius dampak jika terjadi kesalahan.

Gunakan kunci API dengan hak istimewa terkecil untuk membatasi akses setiap agen.

Jika pengambilan ulang data mahal atau lambat, simpan catatan di cache orchestrator dan teruskan referensi ke entri cache. Agen penerima tetap meminta data secara eksplisit, tetapi pembacaan kedua menjadi murah.

Di mana serah terima biasanya rusak

Empat kegagalan berikut mencakup sebagian besar insiden.

Pengenal hilang

Ringkasan hanya menyebut “pelanggan”. Agen kedua mencari berdasarkan nama, menemukan dua kecocokan, lalu memilih akun yang salah.

Pencegahan: validasi bahwa semua ID entitas wajib tersedia sebelum serah terima dilanjutkan.

Tindakan berulang

Agen pertama sudah mengirim email, tetapi tidak mencatatnya. Agen kedua mengirim email yang sama sekali lagi.

Pencegahan:

• Catat tindakan dalam actions_taken
• Periksa daftar tersebut sebelum melakukan penulisan
• Gunakan kunci idempotensi agar pengulangan tidak menimbulkan efek samping

Persetujuan hilang

Seorang manusia menyetujui pengembalian dana saat agen pertama sedang berjalan. Agen kedua tidak mengetahui persetujuan tersebut dan meminta konfirmasi lagi.

Bawa persetujuan sebagai batasan eksplisit yang melekat pada tugas, bukan pada agen tertentu.

Penemuan yang terlalu percaya diri

Agen penerima membutuhkan data yang tidak diteruskan. Alih-alih bertanya, agen tersebut mengarang nilai yang sesuai dengan narasi.

Ini adalah kegagalan paling berbahaya karena hasilnya tampak seperti tugas yang selesai.

Pencegahan:

• Gunakan bidang open_questions
• Tambahkan aturan keras pada prompt agen penerima
• Jika ID atau fakta wajib tidak ada, agen harus berhenti dan bertanya

Perulangan membuat semua masalah ini semakin buruk. Ketika agen A menyerahkan ke B, lalu B menyerahkan kembali ke A, status dapat membusuk di setiap lintasan seperti fotokopi dari fotokopi.

Batasi jumlah hop dan teruskan objek tugas asli pada setiap hop. Jangan membangun ulang status dari awal di setiap batas.

Uji batas serah terima, bukan hanya agen

Serah terima adalah titik integrasi. Karena itu, uji serah terima sebagai integrasi.

Uji objek serah terima

Jalankan agen pertama terhadap skenario tetap, lalu periksa objek yang dihasilkannya:

• Pengenal wajib tersedia
• Keputusan tercatat
• Tindakan yang sudah dilakukan terdaftar
• Batasan dan persetujuan tidak hilang

Pemeriksaan ini bersifat deterministik pada payload terstruktur, meskipun agen yang menghasilkannya tidak deterministik. Itulah yang membuatnya dapat digunakan sebagai tes. Lihat juga panduan menguji agen AI non-deterministik.

Uji agen penerima secara terpisah

Berikan objek serah terima buatan tangan kepada agen penagihan, lalu periksa tindakannya.

Kemudian berikan objek yang sengaja rusak—misalnya hapus customer_id—dan pastikan agen bertanya alih-alih menebak. Tes negatif seperti ini menangkap masalah penemuan yang terlalu percaya diri.

Jalankan terhadap mock

Jangan menguji serah terima dengan pengembalian dana nyata. Arahkan kedua agen ke endpoint tiruan agar test suite dapat dijalankan pada setiap perubahan. Ikuti pola menjalankan agen terhadap mock alih-alih produksi.

Di Apidog, mock dibuat dari definisi API yang sama dengan yang digunakan kedua agen. Dengan demikian, kontrak API tidak terpisah antara agen pertama dan agen kedua.

Catat setiap serah terima

Rekam objek lengkap di setiap batas bersama ID tugas. Ketika eksekusi multi-agen gagal, log serah terima dapat menunjukkan:

• Agen mana yang memiliki informasi
• Di batas mana informasi hilang
• Agen mana yang mulai membuat asumsi

Panduan tentang melacak panggilan alat agen membahas data lain yang sebaiknya dimasukkan ke log.

Apa yang diberikan kerangka kerja kepada Anda

Sebagian besar kerangka kerja orkestrasi menyediakan primitif serah terima. Pahami apa yang sebenarnya dipindahkan sebelum menjadikannya fondasi sistem.

• Dokumentasi serah terima OpenAI Agents SDK memodelkan serah terima sebagai alat yang dapat dipanggil agen. Model menentukan kapan kontrol berpindah. Ini nyaman, tetapi juga menempatkan keputusan pada bagian paling tidak deterministik dari sistem. Pasangkan dengan validasi saat keluar.
• Panduan multi-agen LangGraph menggunakan objek grafik eksplisit yang dibaca dan ditulis setiap node. Pola ini mirip dengan objek serah terima terstruktur; Anda tetap perlu menentukan bidang yang wajib.
• Tulisan Anthropic tentang membangun sistem penelitian multi-agen berguna untuk memahami detail operasional dan jumlah instruksi yang dibutuhkan sub-agen agar dapat bekerja secara mandiri.

Intinya: setiap kerangka kerja akan memindahkan sesuatu, tetapi tidak ada yang menentukan fakta mana yang menjadi penentu beban kerja Anda. Daftar tersebut harus Anda definisikan dan tinjau ketika eksekusi gagal.

Simpan objek tugas di luar percakapan

Satu perubahan struktural dapat mencegah banyak bug: simpan status tugas di penyimpanan tahan lama berdasarkan ID tugas. Minta setiap agen membaca dan memperbarui objek tersebut, bukan meneruskan status melalui pesan.

Percakapan adalah wadah yang buruk untuk status karena dapat:

• Dipadatkan
• Dipotong
• Ditulis ulang oleh ringkasan

Tidak ada operasi tersebut yang memahami bidang mana yang tidak boleh hilang. Baris database tidak memiliki masalah itu.

Pola implementasinya sederhana:

1. Pada awal giliran, agen memuat objek tugas.
2. Setelah mengambil tindakan, agen menambahkan tindakan tersebut ke actions_taken.
3. Agen menyimpan objek tugas.
4. Saat serah terima, agen hanya meneruskan task_id.
5. Agen penerima memuat objek tugas yang sama.

Tidak ada informasi penting yang harus melewati prompt, sehingga tidak ada informasi penting yang dapat hilang saat diringkas.

Pola ini juga menyediakan titik pemulihan. Jika eksekusi berhenti pada langkah keempat, objek tugas masih menyimpan hasil tiga langkah pertama. Percobaan ulang dapat dimulai dari status tersebut, bukan dari nol.

Platform untuk menyimpan status

Jika agen berjalan sebagai runtime CLI di mesin pengembang, objek tugas tahan lama adalah sesuatu yang perlu Anda bangun sendiri. Beberapa platform manajemen pekerjaan agen sudah memodelkan pola ini.

Sharkly mengelola pekerjaan untuk manusia dan agen menggunakan unit tugas. Sebuah tugas membawa tujuan, status, penanggung jawab, Agen atau Kru yang ditugaskan, komentar, status eksekusi, dan hasil agen. Kru memasangkan agen pemimpin dengan agen lain dan manusia, sehingga pekerjaan yang membutuhkan beberapa spesialis dapat diberikan ke grup yang dapat digunakan kembali.

Karena status berada pada tugas, bukan di percakapan, serah terima antaragen tidak bergantung pada kemampuan salah satu agen dalam membuat ringkasan.

Runtime yang Anda gunakan tetap dapat dipertahankan. Claude Code, Codex, dan runtime lain menjalankan pekerjaan pada Komputer yang Anda daftarkan, sementara platform menyediakan catatan tugas, penugasan, dan proses review. Dokumentasi Sharkly dapat menjadi referensi untuk menentukan bidang yang penting saat membangun sistem tugas tahan lama.

Daftar periksa serah terima

• [ ] Skema serah terima ditentukan dan divalidasi di batas.
• [ ] Pengenal entitas adalah bidang wajib.
• [ ] Keputusan menyertakan dasar pengambilannya.
• [ ] Tindakan yang sudah dilakukan dicatat dan diperiksa sebelum penulisan.
• [ ] Persetujuan dan anggaran melekat pada tugas, bukan agen.
• [ ] Pertanyaan terbuka ditulis secara eksplisit.
• [ ] Agen bertanya jika informasi wajib tidak tersedia.
• [ ] Data diteruskan melalui referensi jika pengambilan ulang murah.
• [ ] Jumlah hop dibatasi.
• [ ] Objek tugas asli dipertahankan pada setiap hop.
• [ ] Setiap serah terima dicatat bersama ID tugas.
• [ ] Tes batas dijalankan di CI menggunakan mock, termasuk payload yang sengaja tidak lengkap.

Sebagian besar kegagalan multi-agen bukan kegagalan penalaran. Masalahnya adalah fakta yang tersedia pada satu agen tidak tersedia pada agen berikutnya.

Perlakukan batas serah terima sebagai antarmuka: gunakan skema, validasi, log, dan tes. Dengan begitu, agen kedua tidak perlu menanyakan ulang pertanyaan yang sudah dijawab agen pertama. Unduh Apidog untuk mengelola mock dan tes batas di samping API yang digunakan kedua agen.

Pertanyaan yang sering diajukan

Apakah serah terima terstruktur sepadan untuk dua agen?

Untuk dua agen dalam tugas singkat, meneruskan percakapan biasanya cukup. Objek terstruktur menjadi sangat berharga ketika:

• Ada tiga agen atau lebih
• Tugas berlangsung lama
• Serah terima melewati batas proses atau eksekusi

Haruskah model menulis objek serah terima?

Kode sebaiknya mengisi data yang dapat diverifikasi:

• Pengenal
• Tindakan yang sudah dilakukan
• Persetujuan

Orchestrator harus mengambilnya dari kejadian aktual, bukan dari ingatan model. Model cukup menulis summary dan pertanyaan terbuka.

Bagaimana menghentikan peluruhan konteks dalam perulangan?

Bawa satu objek tugas melalui seluruh eksekusi dan perbarui objek tersebut di setiap langkah. Jangan membuatnya kembali pada setiap batas. Batasi jumlah hop; jika tugas membutuhkan terlalu banyak hop, dekomposisinya mungkin perlu diperbaiki.

Bagaimana dengan kerangka kerja yang memiliki dukungan serah terima bawaan?

Gunakan fitur tersebut, tetapi periksa apa yang sebenarnya ditransfer. Banyak kerangka kerja hanya meneruskan riwayat pesan. Akibatnya, pengenal hanya bertahan jika kebetulan muncul di dalam teks.

Tambahkan payload terstruktur di samping data yang dibawa kerangka kerja.

Apakah sub-agen memerlukan kredensial API terpisah?

Ya. Kredensial harus dibatasi sesuai fungsi setiap agen. Berbagi satu kunci kuat di semua agen menghilangkan kemampuan Anda untuk membatasi dampak dan mengetahui agen mana yang melakukan panggilan. Lihat panduan tentang kunci API dengan hak istimewa terkecil untuk agen.

Berapa banyak isi yang sebaiknya ada di summary?

Gunakan beberapa kalimat untuk menjelaskan niat dan nuansa yang tidak dapat diwakili bidang terstruktur. Jika summary mulai dipenuhi ID, jumlah, atau status yang harus divalidasi, pindahkan informasi tersebut ke bidang terstruktur.