|
Tujuan |
Tanyakan pada diri sendiri, "Hasil apa yang ingin saya capai?Tidak: "Alat apa yang saya butuhkan?", "Konektor mana yang harus saya panggil?", atau "Topik apa yang harus saya buat?"
Jelaskan dengan jelas mengapa agen harus ada, apa yang harus dicapai, dan siapa audiens targetnya. Fokus pada hasil. Biarkan desain agen mengikuti dari masalah yang ada.
Klarifikasi:- Masalah atau kesenjangan nilai
- Menargetkan pengguna
- Dampak yang diharapkan
- Seperti apa kesuksesan
Gunakan format Jobs-To-Be-Done:
-
Sebagai<pengguna>
-
Saya perlu<menyelesaikan pekerjaan>
-
Sehingga<hasil>
|
-
Sebagai karyawan baru, saya perlu memahami kebijakan SDM lokal saya sehingga saya dapat menavigasi orientasi dengan percaya diri.
-
Sebagai Manajer dukungan IT, saya perlu memproses email dukungan secara otomatis agar triase manual berkurang.
|
- Dimulai dengan fitur, bukan hasil.
- Merancang untuk kasus-kasus ekstrem.
- Melewatkan kriteria keberhasilan yang terukur.
|
|
Pemicu |
Pemicu agen adalah peristiwa, kondisi, atau input spesifik yang memberi sinyal kepada agen untuk memulai pekerjaan atau tugasnya. Tindakan manusia atau peristiwa otomatis dapat memulai pemicu.
Pelajari lebih lanjut: Temukan pemicu yang sesuai dengan acara Anda. |
- Pesan pengguna di obrolan.
- Email baru di kotak masuk bersama.
- Catatan baru dalam sistem.
- Pekerjaan terjadwal atau berulang.
|
- Agen otonom memerlukan pemicu eksplisit. Tanpanya, agen tersebut tidak akan berjalan.
- Pemicu bergantung pada perilaku pengguna yang tidak dapat diprediksi, misalnya, mengandalkan pengguna untuk mengetikkan kata kunci atau frasa tertentu.
- Pemicu tidak memiliki konteks yang diperlukan, misalnya, agen mulai tetapi tidak memiliki metadata yang cukup (ID catatan, identitas pengguna) untuk bertindak secara efektif.
- Pemicu diaktifkan lebih sering daripada yang sebenarnya dibutuhkan oleh skenario, yang menyebabkan eksekusi dan konsumsi sumber daya yang tidak perlu.
- Desain pemicu tidak memperhitungkan kuota atau batas platform, menyebabkan agen mencapai ambang batas penggunaan atau gagal dalam beban.
|
|
Alat dan integrasi |
Tentukan tindakan apa yang harus dapat dilakukan agen, bukan hanya apa yang diketahuinya.
Alat memungkinkan agen untuk mengambil atau memperbarui data, memanggil API, memicu alur kerja, mengirim pesan, dan menyelesaikan operasi transaksional. Cantumkan sistem yang bergantung pada agen dan batasannya (API, model autentikasi, batas kecepatan, dan batas kepemilikan/SLA).
Pertimbangkan output yang diharapkan, kriteria keberhasilan dan kualitas, perilaku penggantian dan kesalahan. Dependensi sering kali menentukan kelayakan—atasi hal tersebut sejak awal.
Pelajari selengkapnya: Mekanisme penambahan alat kepada agen. |
- Konektor ServiceNow → mendapatkan detail tiket
- konektor Microsoft Entra ID → mengambil data lokasi pengguna
- Jira API → memperbarui item kerja
- konektor Outlook → membalas email
|
- Tidak mencatat tindakan atau menyimpan output untuk audit.
- Dengan asumsi API stabil dan selalu tersedia.
- Alat yang memberikan izin berlebihan.
- Tidak mendefinisikan perilaku penggantian panggilan alat (tidak ada validasi output alat, tidak ada penggantian saat alat gagal, tidak ada jalur eskalasi).
- Mengabaikan pembatasan atau batasan laju.
- Pemetaan dependensi yang hilang (siapa pemilik setiap API, apa itu perjanjian tingkat layanan).
- Tidak memvalidasi prasyarat sebelum melakukan tindakan.
|
|
Channels |
Saluran adalah platform atau antarmuka spesifik tempat agen Anda disebarkan dan berinteraksi dengan pengguna.
Saluran ini juga memengaruhi ekspektasi pengguna seputar latensi, pengambilan giliran, dan pengalaman. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Web Chat atau antarmuka suara
|
- Memilih saluran berdasarkan kenyamanan atau kesederhanaan penerapan, daripada bagaimana dan di mana pengguna benar-benar bekerja.
- Dengan asumsi pengguna beradaptasi dengan saluran agen, bukan menemui pengguna di tempat mereka berada.
- Memprioritaskan kelayakan teknis daripada pengalaman pengguna, menghasilkan adopsi yang rendah bahkan ketika agen bekerja dengan benar.
- Merancang "chat-first" ketika saluran yang sebenarnya berorientasi email atau alur kerja (membangun UX percakapan ketika dukungan benar-benar terjadi melalui Outlook; melupakan bahwa email bersifat giliran, bukan percakapan)
- Mengabaikan batasan khusus saluran (Outlook memerlukan respons lengkap, bukan mengklarifikasi pertanyaan; Teams mendukung Adaptive Cards, email tidak)
|
|
Pengetahuan dan data |
Dokumentasikan informasi yang perlu dipikirkan agen dan lokasi di mana pengetahuan atau data saat ini tersedia. Pertimbangkan kualitas dan kesegaran data, konten terstruktur versus tidak terstruktur, serta batas akses dan izin.
Kesiapan data merupakan salah satu sumber penghambat tahap akhir yang paling umum jika tidak ditangani sejak awal. |
- Documents
- Database
- Situs Web
- Dasar pengetahuan
- Sistem internal atau eksternal
|
- Tata kelola data yang buruk atau tidak konsisten. Ketika proses kepemilikan, irama refresh, dan pembaruan tidak ditentukan, data dengan cepat menjadi usang atau kontradiktif.
- Mencampuradukkan "dokumen" dengan "pengetahuan". Menunjuk ke repositori dokumen besar sebagai sumber kebenaran tanpa mempertimbangkan apakah dokumen tersebut mutakhir, terstruktur dengan baik, atau diberi label secara konsisten.
- Sumber pengetahuan saling bertentangan. Beberapa versi kebijakan, prosedur, atau himpunan data mengarahkan agen ke instruksi yang saling bertentangan.
- Izin dan kontrol akses tidak dirancang secara eksplisit. Konten sensitif terekspos secara tidak sengaja, atau agen mereferensikan pengetahuan yang tidak dapat diakses oleh pengguna akhir.
- Memperluas sumber pengetahuan tanpa memvalidasi batas keamanan, menghasilkan agen yang berbagi secara berlebihan atau gagal saat akses dibatasi.
|
|
Alur dan orkestrasi |
Tentukan bagaimana pekerjaan disusun dan diurutkan di seluruh agen: kapan harus menggunakan alur atau topik deterministik, kapan harus mengandalkan orkestrasi, dan kapan keterlibatan manusia diperlukan. Tujuannya adalah perilaku yang dapat diprediksi, otomatisasi yang aman, dan eskalasi yang jelas.
Kapan menggunakan alur atau topik:- Pengumpulan data multilangkah
- Pemecahan masalah terpandu atau pohon keputusan
- Proses yang digerakkan oleh kepatuhan atau kebijakan
- Tindakan berdampak tinggi atau tidak dapat diubah
Topik adalah mekanisme utama untuk logika deterministik.
Mendefinisikan:- Apa yang dapat dilakukan agen secara mandiri
- Apa yang memerlukan persetujuan, peninjauan, atau pengesampingan oleh manusia
- Kapan agen harus mengeskalasi atau menunda
- Bagaimana umpan balik manusia mengalir kembali ke perbaikan
|
- Agen Ask-Me-Anything: Aliran deterministik minimal; terutama bergantung pada orkestrasi dan penalaran generatif.
- Agen otonom: Menggunakan proses atau topik untuk menegakkan pengurutan, validasi, dan pengaman bagi langkah-langkah penting.
- Alur kerja persetujuan: Agen menyiapkan konteks dan rekomendasi; manusia menyetujui atau mengesampingkan tindakan berdampak tinggi.
|
- Terlalu menstrukturkan aliran, membatasi fleksibilitas, dan membuat agensi terasa kaku atau rapuh.
- Kurang menyusun alur, mengurangi keandalan, dan membuat hasil tidak dapat diprediksi.
- Tidak secara eksplisit menggunakan topik untuk logika deterministik, yang mengarah pada perilaku sementara atau tidak konsisten.
- Mengaburkan tanggung jawab antara manusia dan agen, mengakibatkan jalur eskalasi yang tidak jelas.
- Membebani manusia dengan persetujuan untuk tindakan berisiko rendah, menciptakan kemacetan dan mencegah penggunaan agen.
- Agen bertindak tanpa batasan "jangan bertindak" yang jelas, terutama dalam skenario perbatasan atau berisiko tinggi.
|
|
Instruksi dan perilaku |
Instruksi mendefinisikan:- Peran dan tanggung jawab agen
- Bagaimana alasan dan tanggapannya
- Kapan dan bagaimana seharusnya menggunakan pengetahuan, alat, atau agen lain
- Urutan tindakan yang harus diikuti
- Nada, batasan, dan aturan keselamatan
Instruksi yang jelas menghubungkan pengetahuan, alat, dan aliran ke dalam sistem yang koheren dan dapat diprediksi.
Pelajari selengkapnya: Mengonfigurasi instruksi berkualitas tinggi untuk orkestrasi generatif dan Menulis instruksi efektif untuk agen deklaratif. |
- Peran dan cakupan: "Anda adalah Agen Dukungan Email TI yang bertanggung jawab untuk membaca pesan kotak surat masuk, mengekstrak nomor tiket, dan membalas dengan informasi yang divalidasi dari ServiceNow."
- Perilaku berurutan: "Langkah 1: Periksa basis pengetahuan untuk kebijakan yang ada atau masalah yang diketahui. Langkah 2: Jika informasi tidak ditemukan atau tidak lengkap, hubungi alat ServiceNow untuk mengambil detail tiket. Langkah 3: Jika data yang diperlukan masih hilang, berikan respons dengan pola 'Saya tidak tahu' dan eskalasikan."
- Aturan penggunaan alat: "Selalu validasi ID yang diekstrak dengan panggilan alat sebelum menggunakannya dalam respons."
- Penanganan kegagalan: "Jika informasi kurang atau panggilan alat gagal, jangan menebak." Tanggapi dengan batasan yang jelas dan langkah selanjutnya."
|
- Instruksinya terlalu kabur. Misalnya, "Bantu pengguna dengan masalah dukungan" tidak menentukan domain, batasan, atau tindakan yang diizinkan.
- Tidak ada kejelasan tentang kapan harus menggunakan pengetahuan versus alat versus agen lain, yang menyebabkan perilaku yang tidak konsisten atau tidak efisien.
- Instruksi tidak menentukan urutan tindakan, menyebabkan agen mencampur pengetahuan dan output alat dengan cara yang tidak dapat diprediksi.
- Aturan penggunaan alat tidak didefinisikan secara eksplisit, yang dapat menyebabkan alat dipanggil secara tidak perlu atau tidak sama sekali, atau pengetahuan dan output alat dicampur dengan cara yang tidak terduga.
- Instruksi yang bertentangan, seperti "selalu ajukan pertanyaan klarifikasi" dan "tanggapi hanya dengan jawaban akhir".
- Tidak ada panduan eksplisit "tidak boleh dilakukan", seperti memodifikasi data sensitif, berbagi pengenal internal, atau memberikan saran hukum atau SDM tanpa sumber terverifikasi.
|
|
Arsitektur dan komposisi agen |
Gunakan beberapa agen ketika:
- Domain besar atau berbeda
- Kepemilikan berbeda di seluruh tim
- Akses atau izin bervariasi
- Penalaran khusus diperlukan
Delegasi meningkatkan modularitas, kejelasan, dan pemeliharaan jangka panjang.
Pelajari selengkapnya: Jelajahi pola orkestrasi multi-agen. |
- Agen utama mendelegasikan pencarian tiket ke agen TI.
- Agen pengetahuan menangani QA dokumen.
- Agen perutean memutuskan agen ahli mana yang akan dihubungi.
|
- Delegasi yang berlebihan (terlalu banyak agen)—misalnya, membuat agen terpisah untuk setiap tugas kecil—dapat menyebabkan penyebaran arsitektur dan menyulitkan pemeliharaan, debug, mengamankan, atau memperbarui agen.
- Kurangnya pendelegasian (satu agen raksasa)—misalnya, satu agen yang diharapkan dapat menjawab pertanyaan SDM, mencari tiket TI, menangani pemecahan masalah, dan membuat pesanan pembelian serta insiden—dapat menyebabkan agen yang monolitik dan rapuh yang tidak mungkin dipertahankan.
- Batas delegasi yang tidak ditentukan. Sebagai contoh, agen utama tidak tahu kapan harus melakukan hand off, agen turunan tidak tahu input apa yang seharusnya mereka harapkan, atau tanggung jawab saling tumpang tindih (dua agen sama-sama mencari tiket TI).
|
|
Tata kelola dan manajemen risiko |
Tentukan bagaimana agen diatur, diamankan, dan dipantau untuk memastikannya berperilaku secara bertanggung jawab, aman, dan dapat diprediksi sepanjang siklus hidupnya.
Definisi ini mencakup kontrol akses, izin tindakan, pagar pembatas keselamatan, akuntabilitas, dan pengawasan berkelanjutan untuk mengelola risiko operasional dan terkait AI sejak hari pertama.
Pelajari selengkapnya: Menangkap persyaratan tata kelola dan Terapkan prinsip AI yang bertanggung jawab. |
- Model autentikasi dan akses: Agen menggunakan identitas tingkat pengguna untuk mengambil hanya data yang diizinkan untuk dilihat pengguna, sedangkan identitas tingkat sistem dibatasi pada operasi layanan yang ditentukan dengan jelas.
- Izin tindakan dan pagar pengawas: Agen dapat memperbarui catatan kerja atau draf respons, tetapi tidak dapat melakukan tindakan yang tidak dapat diubah (seperti menutup tiket atau mengirim komunikasi eksternal) tanpa persetujuan.
- Keamanan dan perlindungan konten: Informasi sensitif atau yang diatur terdeteksi dan diblokir agar tidak dibagikan atau ditindaklanjuti menggunakan perlindungan platform (misalnya, pencegahan kebocoran data atau filter keamanan).
- Pencatatan, audit, dan ketertelusuran: Semua tindakan agen, penggunaan alat, penolakan, dan eskalasi dicatat dan bisa diaudit untuk keperluan kepatuhan dan peninjauan.
- Kepemilikan operasional: Agen memiliki pemilik, sponsor, dan pelayan operasional yang ditentukan, dengan izin dan perilaku yang ditinjau secara teratur.
|
- Merancang tata kelola dan kontrol risiko terlambat, yang menyebabkan penyebaran yang diblokir atau penundaan produksi.
- Agen yang memberikan izin berlebihan "untuk kemudahan" dapat meningkatkan risiko paparan data atau tindakan yang tidak diinginkan.
- Agen yang kurang izin, menyebabkan kegagalan saat runtime ketika sistem atau data yang diperlukan tidak dapat diakses.
- Tidak mengintegrasikan masalah AI yang bertanggung jawab ke dalam keputusan tata kelola inti.
- Tata kelola operasional yang lemah, seperti tidak ada pemilik yang jelas, tidak ada rencana pemantauan, atau tidak ada proses yang ditentukan untuk respons insiden.
- Gagal memantau perilaku agen setelah penyebaran, dengan asumsi bahwa pengaman saja sudah cukup.
|
|
Evaluasi dan pengoptimalan |
Tentukan pengujian yang mensimulasikan skenario dunia nyata untuk mengukur akurasi, relevansi, dan kualitas jawaban agen Anda. Berikan respons yang diharapkan dan tunjukkan bagaimana respons agen dipetakan ke respons Anda atau respons paling standar.
Rencanakan cara mengukur dan meningkatkan kinerja:
- Akurasi dan relevansi
- Hemat waktu atau efisiensi
- Adopsi dan penggunaan
- Sinyal kepuasan dan kepercayaan
- Kualitas kutipan
- Kepatuhan izin
- Deteksi informasi yang salah
- Mengklarifikasi perilaku pertanyaan
Tentukan telemetri apa yang akan dikumpulkan:
- Panggilan alat
- Tindakan agen
- Kegagalan dan percobaan ulang
- Umpan balik pengguna
Perlakukan evaluasi sebagai bagian dari desain, bukan renungan. Pelajari lebih lanjut: Merancang dan mengoperasionalkan evaluasi agen. |
- Validasi bahwa pencarian tiket mengembalikan status yang benar dan bukan status yang kedaluwarsa.
- Validasi bahwa tautan kutipan mengarah ke konten yang disetujui saat ini.
- Validasi bahwa agen menolak untuk memberikan detail tentang tiket orang lain.
- Uji apakah agen mengarang nomor tiket atau artikel KB.
- Ukur jumlah email yang diproses oleh agen otonom per hari, dan persentase pengguna yang memilih agen daripada saluran manual.
|
- Menjalankan evaluasi yang terlalu terlambat (setelah implementasi).
- Tidak ada dasar atau tolok ukur.
- Evaluasi tidak terikat pada skenario nyata.
- Tidak ada deteksi regresi.
- Tidak ada evaluasi multi-putaran.
- Tidak ada penilai untuk kualitas penggunaan alat.
- Hanya memeriksa "jalur yang lancar".
- Kesenjangan telemetri.
|
