Sistem Multi-Agent untuk Pusat Kontak: Cara Kerja dan Implementasi

Ringkasan artikel：SistemMulti-AgentuntukPusatKontak:CaraKerjadanImplementasiKetikapusatkontakperusahaanperlumenanganisecarabersamaanberbagaimasalahkomplekssepertipengecekanpesanan,verifikasi...

Sistem Multi-Agent untuk Pusat Kontak: Cara Kerja dan Implementasi

Ketika pusat kontak perusahaan perlu menangani secara bersamaan berbagai masalah kompleks seperti pengecekan pesanan, verifikasi tagihan, dan dukungan teknis, satu chatbot tunggal sering kali kewalahan. Sistem pusat kontak omnichannel cerdas Udesk yang menggunakan arsitektur multi-agent mampu memecah "satu robot serba bisa" menjadi "satu pusat koordinasi + banyak agen spesialis" yang bekerja sama secara terkoordinasi, secara drastis meningkatkan efisiensi dan akurasi penanganan skenario bisnis yang rumit. Artikel ini akan membahas secara mendalam cara kerja sistem multi-agent dan peta jalan implementasinya.

1. Dari "Prajurit Tunggal" ke "Kolaborasi Pasukan"

Robot layanan pelanggan tradisional umumnya menggunakan arsitektur tunggal: satu model, satu basis pengetahuan, satu alur pemrosesan. Desain seperti ini masih cukup untuk menangani tanya jawab sederhana, namun akan menunjukkan keterbatasan yang jelas ketika berhadapan dengan permintaan kompleks yang melibatkan berbagai sistem bisnis dan membutuhkan banyak langkah pemrosesan. Bayangkan skenario berikut: seorang pelanggan menghubungi pusat kontak dan berkata, "Pesanan saya sudah dibayar tapi belum sampai, tagihan saya sepertinya terpotong dua kali, dan bisakah dukungan teknis Anda membantu saya mengapa aplikasi Anda selalu crash di ponsel Android saya?" Ini adalah permintaan khas dengan banyak maksud yang melintasi berbagai departemen. Sistem single-agent akan kebingungan – apakah harus memeriksa pesanan terlebih dahulu, atau tagihan, atau dialihkan ke teknisi? Bahkan jika dipaksakan untuk memproses secara berurutan, ia harus bolak-balik antar sistem, sangat rentan terhadap kesalahan atau kelalaian.

2. Apa itu Sistem Multi-Agent?

Sistem multi-agent hadir untuk memecahkan masalah ini. Konsep intinya adalah memecah tugas kompleks menjadi beberapa subtugas, setiap subtugas ditangani oleh agent khusus, sekaligus memiliki pusat koordinasi (Orchestrator) untuk mengatur, mendistribusikan, dan menggabungkan hasil. Dalam konteks pusat kontak, nilai sistem multi-agent sangat menonjol: agent yang berbeda dapat fokus pada bidangnya masing-masing (seperti pesanan, tagihan, teknis, keluhan) dengan basis pengetahuan dan alat yang dapat disesuaikan secara mendalam, mencapai spesialisasi. Beberapa agent dapat memproses tugas yang independen secara bersamaan, memangkas waktu respons secara signifikan, mencapai paralelisasi. Jika satu agent mengalami masalah, agent lain tidak terpengaruh, dan pusat koordinasi dapat mengalihkan atau meminta intervensi manusia, memberikan ketahanan kesalahan yang baik. Ketika ada lini bisnis baru, cukup menambahkan agent spesialis yang sesuai tanpa perlu merekonstruksi seluruh sistem, sehingga sangat mudah diperluas.

Arsitektur: Pusat Koordinasi + Agent Spesialis

Sistem multi-agent untuk pusat kontak yang matang umumnya mengikuti arsitektur dua lapis yang jelas.

• Lapisan pertama: pusat koordinasi 

Pusat koordinasi merupakan "otak" dan "pengatur lalu lintas" dari seluruh sistem. Tugas inti pusat koordinasi meliputi: menggunakan large language model untuk melakukan identifikasi maksud dan pemecahan tugas dari input awal pengguna, mengurai permintaan kompleks menjadi beberapa subtugas yang dapat dieksekusi secara independen – misalnya memecah "pesanan saya belum sampai dan tagihan saya kepotong lebih" menjadi "pengecekan pesanan" dan "verifikasi tagihan". Kemudian berdasarkan jenis subtugas, menugaskannya ke agent spesialis yang paling sesuai; pusat koordinasi memelihara "peta kemampuan" yang mengetahui agent mana yang ahli dalam apa dan beban kerja saat ini. Setelah itu, ia mengumpulkan hasil dari setiap agent spesialis, menyusunnya sesuai urutan logis atau tingkat kepentingan menjadi balasan akhir yang lancar, serta memelihara konteks global seluruh sesi percakapan untuk memastikan tidak ada agent yang "bicara sendiri". Ketika suatu agent spesialis tidak dapat menyelesaikan tugas atau tingkat kepercayaan hasil terlalu rendah, pusat koordinasi dapat memicu percobaan ulang, beralih ke agent cadangan, atau langsung mengalihkan percakapan ke agen manusia secara mulus.

• Lapisan kedua: agent spesialis

Setiap agent spesialis hanya fokus pada satu domain vertikal dengan basis pengetahuan, perangkat API, dan aturan bisnis eksklusif. Agent spesialis yang umum antara lain: agent pesanan (terhubung ke sistem manajemen pesanan dan API logistik, ahli dalam mengecek status pesanan, mengubah alamat pengiriman, mengajukan retur); agent tagihan (terhubung ke sistem penagihan dan payment gateway, ahli dalam mengecek rincian tagihan, menangani sengketa pemotongan, mengajukan refund parsial); agent dukungan teknis (terhubung ke basis pengetahuan berisi manual produk dan panduan pemecahan masalah, ahli dalam menjawab pertanyaan tentang cara reset password, perangkat tidak bisa terhubung ke WiFi, dll.); serta agent keluhan dan penenangan (memiliki pustaka skrip standar dan kemampuan analisis emosi, ahli dalam menangani ketidakpuasan pelanggan, memberikan solusi kompensasi atau jalur eskalasi). Desain agent spesialis mengikuti prinsip tanggung jawab tunggal: ia tidak perlu memahami hal-hal di luar domainnya, sehingga dapat dibuat sangat mendalam dan akurat.

3. Alur Kolaborasi Dua Lapis

Saat pelanggan mengirimkan pertanyaan, alur kolaborasi dua lapis ini berjalan sebagai berikut: pusat koordinasi menerima pesan, kemudian menganalisis maksud, memutuskan agent spesialis mana yang akan dipanggil dan urutannya (serial atau paralel). Selanjutnya, pusat koordinasi membagikan subtugas ke agent spesialis yang sesuai beserta konteks terkait. Agent spesialis mengeksekusi tugas secara independen – menanyakan database, memanggil API, mencari basis pengetahuan. Akhirnya, hasilnya dikembalikan ke pusat koordinasi, yang menggabungkan hasil tersebut dan menghasilkan balasan akhir untuk dikirim ke pelanggan. Arsitektur ini menjaga fokus setiap agent sekaligus mencapai kolaborasi menyeluruh melalui pusat koordinasi.

• Contoh Proses Bisnis: Layanan Pelanggan ke Tagihan ke Dukungan Teknis

Agar arsitektur di atas lebih mudah dipahami, mari kita lihat contoh proses bisnis yang lengkap dari ujung ke ujung. Misalkan pelanggan mengetik: "Paket VIP saya bulan ini kenapa kepotong 50 ribu lebih? Juga, aplikasi Anda sering crash di ponsel Android saya. Oh iya, saya pernah komplain sebelumnya, ada hasilnya belum?"

•  Penguraian oleh Pusat Koordinasi

Pusat koordinasi pertama-tama mengurai tiga subtugas yang jelas: masalah tagihan (menanyakan rincian biaya paket VIP, memverifikasi penyebab kelebihan potongan), dukungan teknis (mencari solusi yang diketahui untuk crash aplikasi), status keluhan (memeriksa perkembangan tiket keluhan historis pelanggan tersebut). Pusat koordinasi menilai ketiga tugas ini independen satu sama lain dan dapat dijalankan secara paralel untuk efisiensi, namun karena "tagihan" dan "keluhan" mungkin terkait, balasan akhir perlu disusun dalam urutan logis.

• Distribusi Tugas

Selanjutnya, pusat koordinasi mengirim perintah ke agent tagihan: "Cari tagihan bulan ini untuk paket VIP pelanggan [X], temukan rincian yang lebih besar 50 ribu dari bulan lalu"; ke agent dukungan teknis: "Cari penyebab umum dan solusi untuk crash aplikasi versi Android"; ke agent pelacak keluhan: "Cari status tiket keluhan pelanggan [X] dalam seminggu terakhir."

• Eksekusi oleh Agent Spesialis

Masing-masing agent spesialis mulai mengeksekusi: agent tagihan memanggil API sistem penagihan dan menemukan bahwa pelanggan secara otomatis dilanggankan layanan nilai tambah (50 ribu per bulan) yang tidak dipesan secara aktif oleh pelanggan, lalu mengembalikan hasil "kelebihan 50 ribu berasal dari langganan layanan nilai tambah yang tidak sah, dapat diajukan refund"; agent dukungan teknis mencari basis pengetahuan dan menemukan dua catatan terkait "ada bug crash di versi 2.3.1, sudah diperbaiki di versi 2.4.0, sarankan pengguna upgrade ke versi terbaru dan hapus cache"; agent pelacak keluhan memanggil API sistem tiket dan menemukan bahwa keluhan pelanggan sebelumnya telah selesai diproses dengan status "selesai - kompensasi telah diberikan", mengembalikan "Keluhan Anda telah selesai diproses 3 hari lalu, kompensasi telah diberikan ke saldo akun Anda."

4. Penggabungan dan Balasan Akhir

Pusat koordinasi menggabungkan semua hasil menjadi balasan yang jelas dan koheren: "Terima kasih atas masukan Anda. Mengenai pertanyaan Anda: Pertama, kelebihan 50 ribu pada paket VIP Anda karena ada langganan layanan nilai tambah (bukan langganan aktif Anda). Kami telah mengajukan refund untuk Anda, akan kembali dalam 1-3 hari kerja. Kedua, masalah crash aplikasi: mohon upgrade aplikasi Anda ke versi terbaru 2.4.0 dan coba hapus cache. Masalah ini telah diperbaiki di versi terbaru. Ketiga, keluhan Anda sebelumnya telah selesai diproses 3 hari lalu, kompensasi telah diberikan ke saldo akun Anda. Ada lagi yang bisa kami bantu?" Seluruh proses hanya memakan waktu beberapa detik, tanpa perlu transfer atau pengulangan penjelasan.

Tantangan dalam Kolaborasi Multi-Agent

Meskipun arsitektur multi-agent terdengar ideal, dalam implementasi nyata akan menghadapi serangkaian tantangan. Memahami tantangan ini membantu perusahaan membuat keputusan yang lebih bijak saat memilih dan menerapkan.

 Akurasi pemecahan tugas

Bagaimana pusat koordinasi dapat secara akurat memecah satu kalimat alami menjadi beberapa subtugas? Jika pemecahan salah, semua pekerjaan selanjutnya akan salah arah. Misalnya, pelanggan berkata "pesanan saya kurang satu barang, bisakah saya refund selisih harga", pemecahan yang benar adalah "pengecekan pesanan (konfirmasi kekurangan)" ditambah "pengajuan refund (menghitung selisih)". Namun jika pusat koordinasi salah memahami "refund selisih" sebagai "retur barang", maka akan menyebabkan tindak lanjut yang keliru. Solusinya adalah menggunakan large language model yang sudah di-fine-tuning sebagai pusat koordinasi, dikombinasikan dengan few-shot learning dan aturan cadangan.

Berbagi informasi antar-agent dan resolusi konflik

Agent spesialis yang berbeda dapat mengembalikan informasi yang saling bertentangan. Misalnya, agent pesanan mengatakan "barang telah diterima", tetapi agent keluhan mendapati pelanggan telah mengajukan sengketa barang tidak sampai. Pusat koordinasi perlu memiliki kemampuan deteksi konflik dan keputusan, menilai informasi mana yang lebih kredibel, atau secara aktif mengonfirmasi ke pelanggan. Solusinya adalah merancang penyimpanan status sesi global sehingga pusat koordinasi dapat membandingkan keluaran setiap agent, serta menetapkan ambang batas kepercayaan; jika di bawah ambang batas, aktifkan peninjauan manual atau konfirmasi ulang.

Latensi dan overhead sumber daya

Memanggil beberapa agent secara paralel akan meningkatkan biaya panggilan API dan waktu respons. Jika memanggil 5 agent secara bersamaan, masing-masing memerlukan 200 milidetik, ditambah 50 milidetik untuk penggabungan oleh pusat koordinasi, total waktu respons bisa melebihi 1 detik. Meskipun untuk percakapan teks masih dapat diterima, untuk skenario panggilan suara real-time mungkin agak lambat. Solusinya adalah mengoptimalkan kecepatan respons agent (misalnya menggunakan cache, menyederhanakan prompt), dan mengizinkan hasil yang lebih cepat ditampilkan terlebih dahulu (streaming output).

4. Debugging dan observabilitas

Dalam sistem multi-agent, kesalahan dapat berasal dari pusat koordinasi, agent spesialis tertentu, kegagalan API, atau masalah data. Melacak akar penyebab jauh lebih sulit dibandingkan sistem single-agent. Perusahaan perlu menghasilkan ID pelacakan unik untuk setiap permintaan, mencatat keputusan pemecahan pusat koordinasi, input dan output setiap agent, serta langkah-langkah penggabungan antara. Framework multi-agent mainstream seperti LangGraph dan AutoGen sudah menyediakan alat observabilitas bawaan, dan perusahaan harus memanfaatkan fitur ini sebaik-baiknya.

Platform Teknologi yang Mendukung Multi-Agent

Membangun sistem multi-agent pusat kontak yang lengkap dari awal memiliki tingkat kesulitan teknis yang cukup tinggi. Untungnya, sudah ada framework open source dan platform enterprise yang dapat secara drastis menekan biaya pengembangan.

Framework open source

Framework open source yang cukup representatif antara lain: LangGraph (berbasis LangChain, mendukung state machine graf berarah, ahli dalam mendefinisikan alur kolaborasi multi-agent yang kompleks, cocok untuk perusahaan yang memerlukan kontrol alur kerja terperinci); Microsoft AutoGen (mendukung percakapan multi-agent, intervensi manusia, eksekusi kode, skalabilitas tinggi, cocok untuk penelitian, pembuatan prototipe, dan otomatisasi tugas kompleks); CrewAI (kolaborasi agent berbasis peran, sintaksis sederhana, cepat dipelajari, cocok untuk membuat proof-of-concept multi-agent dengan cepat). Perusahaan dapat memilih framework yang sesuai berdasarkan kemampuan tim teknis dan kompleksitas.

Platform enterprise

Bagi sebagian besar perusahaan, menggunakan platform pusat kontak cloud yang siap pakai lebih realistis. Platform semacam ini biasanya sudah memiliki mesin orchestration multi-agent bawaan dan menyediakan integrasi siap pakai dengan CRM, ERP, platform e-commerce, dll. Sebagai contoh, sistem pusat kontak omnichannel cerdas Udesk memiliki arsitektur yang secara alami mendukung mode multi-agent: mesin U-AIGC LLM-nya mengidentifikasi maksud pelanggan dan secara otomatis merutekan ke robot spesialis atau agen manusia yang paling sesuai. Perusahaan dapat melatih agent eksklusif untuk lini bisnis yang berbeda (penjualan, purna jual, dukungan teknis, keluhan), masing-masing dengan basis pengetahuan dan alur percakapan independen. Terlepas dari apakah pelanggan datang dari website, aplikasi, WhatsApp, atau telepon, pusat koordinasi dapat menanganinya secara terpusat, tanpa perlu agent spesialis peduli perbedaan saluran. Administrator juga dapat mendefinisikan urutan kolaborasi, kondisi cabang, dan penanganan pengecualian antar agent secara visual dengan drag-and-drop, tanpa perlu menulis kode.

Perbandingan: membangun sendiri vs platform matang

Membangun sendiri memerlukan pengembangan dari nol atau integrasi framework open source, sementara platform seperti Udesk memiliki mesin orchestration multi-agent bawaan yang siap pakai; membangun sendiri memerlukan pengembangan konektor API satu per satu, sementara platform menyediakan integrasi siap pakai dan API standar; membangun sendiri harus menangani adaptasi saluran sendiri, sementara platform mendukung integrasi terpusat untuk lebih dari 30 saluran; membangun sendiri perlu mengembangkan transfer ke manusia dan dashboard kolaborasi, sementara platform memiliki transfer ke manusia yang mulus dan workspace agen bawaan; membangun sendiri perlu membuat sistem logging sendiri, sementara platform menyediakan pemantauan dan audit log yang lengkap. Dari segi waktu implementasi, membangun sendiri biasanya membutuhkan 6 hingga 12 bulan, sementara menggunakan platform enterprise hanya 2 hingga 4 minggu.

5.FAQ

Q1. Apakah sistem multi-agent jauh lebih mahal daripada single-agent?

Jawaban: Belum tentu. Jika menggunakan framework open source, biaya utamanya adalah pengembang dan pemeliharaan; jika menggunakan platform enterprise seperti Udesk, biasanya dikenakan biaya berdasarkan jumlah agent dan volume panggilan, sehingga dapat dimulai dengan 2-3 agent spesialis dengan biaya terkendali. Peningkatan efisiensi yang dihasilkan oleh multi-agent (peningkatan tingkat penyelesaian pertama sebesar 30-50%) biasanya cepat menutup biaya tambahan.

Q2. Perusahaan kami hanya memiliki 5 agen customer service, apakah perlu menggunakan multi-agent?

Jawaban: Perlu. Nilai sistem multi-agent tidak tergantung pada jumlah agen, tetapi pada kompleksitas dan keragaman masalah pelanggan. Bahkan untuk tim kecil, jika sering menghadapi masalah yang memerlukan koordinasi lintas departemen, multi-agent dapat secara drastis mengurangi jumlah transfer dan pengulangan penjelasan oleh agen manusia. Selain itu, multi-agent dapat secara otomatis menangani banyak permintaan umum di luar jam kerja, setara dengan menambah "layanan malam hari" secara gratis.

Q3. Apakah pusat koordinasi bisa salah? Jika salah, bagaimana?

Jawaban: Tidak ada sistem AI yang dapat menjamin akurasi 100%. Kuncinya adalah merancang jalur degradasi yang elegan. Misalnya, ketika tingkat kepercayaan pusat koordinasi terhadap suatu identifikasi maksud di bawah ambang batas, percakapan dapat langsung dialihkan ke agen manusia, daripada dipaksakan dipecah. Selain itu, perusahaan harus membangun mekanisme peninjauan manual untuk secara berkala memeriksa log keputusan pusat koordinasi dan mengoreksinya.
Udesk Sistem layanan pelanggan cerdas omnichannel Udesk, ditenagai oleh teknologi AI Agent, memimpin transformasi industri layanan pelanggan cerdas. Satu platform mengintegrasikan pusat panggilan cloud, layanan pelanggan online, sistem tiket, terhubung dengan lebih dari 30 saluran komunikasi domestik dan internasional, menghubungkan pelanggan global Anda tanpa hambatan. Bangun hubungan dengan pelanggan melalui berbagai saluran, tingkatkan kinerja penjualan, perbaiki kualitas layanan, dan berikan pengalaman berkualitas kepada pelanggan. Pahami niat pelanggan secara real-time, dari akuisisi hingga konversi belum pernah semudah ini!

Klik gambar di bawah ini untuk uji coba gratis >>

Artikel ini merupakan karya asli Udesk. Jika akan diterbitkan ulang, wajib selalu mencantumkan sumber aslinya：https://id.udeskglobal.com/blog/sistem-multi-agent-untuk-pusat-kontak-cara-kerja-dan-implementasi