Catatan penulis: Berangkat dari prinsip “hanya meminta keputusan manusia saat menghapus data, mengeluarkan uang, atau mengubah arah”, artikel ini membahas tiga dimensi untuk menentukan batas keputusan manusia dalam sistem otomatisasi Agent, desain alur persetujuan, serta pembagian tugas verifikasi dengan CI.
Ketika Agent berubah dari “teman mengobrol” menjadi “pelaksana tugas”, tantangan terbesar sering kali bukan membuatnya berjalan, melainkan menentukan kapan ia harus berhenti. Terlalu banyak titik persetujuan membuat otomatisasi berubah menjadi sekadar “manusia menekan tombol konfirmasi”. Terlalu sedikit, satu kesalahan penghapusan atau pengeluaran yang tak terkendali bisa menghapus manfaat efisiensi selama berbulan-bulan. Artikel ini menawarkan pendekatan yang dapat digunakan kembali untuk menjawab pertanyaan: kapan Agent harus berhenti dan bertanya kepada manusia.
Ini bukan pembahasan umum yang hanya berkata “AI berbahaya, jadi harus berhati-hati”. Kita berangkat dari sistem nyata yang telah dibagikan secara publik: kreator konten Kazike membangun sistem otomatisasi Agent selama hampir setahun. Sistem itu hanya meminta keputusannya melalui kartu Feishu untuk tiga jenis keputusan penting: menghapus data, mengeluarkan uang, dan mengubah arah. Kita akan merumuskan prinsip tersebut menjadi dimensi penilaian dan melengkapinya dengan cara merancang alur persetujuan.
Manfaat utama: Setelah membaca artikel ini, Anda bisa menilai tindakan mana yang cocok dijalankan Agent secara mandiri, mana yang harus dikonfirmasi manusia, serta cara merancang alur persetujuan yang menjaga risiko tetap terkendali tanpa menghambat otomatisasi.
Kapan Agent Harus Berhenti dan Bertanya kepada Manusia: 3 Titik Keputusan Utama
Sistem Kazik memberikan jawaban yang sangat sederhana: manusia hanya turun tangan pada tiga situasi. Tabel berikut menunjukkan ketiga titik keputusan tersebut dan risiko yang mendasarinya.
| Titik keputusan | Contoh tindakan | Sifat risiko | Mengapa perlu manusia |
|---|---|---|---|
| Menghapus data | Membersihkan catatan database, menghapus file, menimpa versi lama | Tidak dapat dibatalkan | Setelah dilakukan, biaya pemulihan sangat tinggi atau data bahkan tidak bisa dipulihkan |
| Mengeluarkan uang | Memanggil layanan berbayar, membeli sumber daya, menggunakan kuota model dalam jumlah besar | Pengeluaran dana | Ada biaya nyata yang bisa membengkak akibat proses berulang |
| Mengubah arah | Menyesuaikan topik konten, mengubah strategi produk, menulis ulang aturan yang telah ditetapkan | Memengaruhi tujuan | Agent tidak memiliki konteks bisnis dan pertimbangan nilai secara lengkap |
Posisi batas keputusan manusia dalam arsitektur empat lapisan
Berdasarkan ringkasan yang tersedia untuk publik, gagasan utama sistem Kazik adalah “mengalihkan titik awal tugas dari manusia”. Agent mulai bekerja karena dipicu oleh peristiwa, bukan karena manusia memulai setiap tugas. Sistem ini terdiri dari empat lapisan, dengan keputusan manusia ditempatkan pada lapisan terakhir sebagai “rem”, bukan “gas”, bagi seluruh alur.
| Lapisan | Tanggung jawab | Implementasi dalam informasi yang tersedia untuk publik |
|---|---|---|
| Platform otomatisasi | Mengelola pemicu peristiwa dan penjadwalan Agent secara terpusat | Aturan dikonfigurasi secara terpusat melalui rules.json |
| Lapisan eksekusi Agent | Menjalankan tugas Agent | Berjalan secara lokal di Mac Mini |
| Platform CI | Menjalankan lima tahap: tinjau, periksa, gabungkan, rilis, dan verifikasi | Dibangun sendiri |
| Lapisan keputusan Feishu | Meminta keputusan manusia pada titik penting | Kartu Feishu |
Pembagian ini menunjukkan arah desain yang penting: sebagian besar pertanyaan “apakah ini benar?” diserahkan ke platform CI untuk diverifikasi secara otomatis. Hanya pertanyaan “apakah ini sebaiknya dilakukan?” yang diserahkan kepada manusia. Pertanyaan pertama bisa diperiksa dengan standar objektif, sedangkan pertanyaan kedua melibatkan pertimbangan dan tanggung jawab. Inilah garis pemisah utama dalam batas keputusan manusia.
Perlu dicatat bahwa sumber aslinya hanya berupa ringkasan. Rincian kolom pada kartu Feishu, frekuensi dan waktu respons keputusan manusia, serta definisi tepat dari “mengubah arah” tidak dijelaskan di sana. Pembahasan selanjutnya tentang desain kartu dan aspek penilaian merupakan saran pengembangan kami berdasarkan prinsip tersebut, bukan penjelasan ulang tentang sistem aslinya.
Cara menentukan kapan Agent harus berhenti dan bertanya kepada manusia: metode tiga dimensi
“Menghapus data, mengeluarkan uang, dan mengubah arah” adalah titik awal yang bagus. Namun, operasi dalam sistem nyata jauh lebih beragam. Dengan merangkumnya menjadi tiga dimensi yang bisa digunakan berulang kali, kamu bisa mengelompokkan operasi baru dengan cepat: reversibilitas, dampak biaya, dan arah.
Dimensi pertama: reversibilitas menentukan apakah konsekuensi bisa dibatalkan
Reversibilitas menjawab pertanyaan, “Kalau terjadi kesalahan, apakah tindakan ini bisa dibatalkan?” Menulis draf, membuat branch, dan menjalankan skrip di lingkungan pengujian adalah operasi yang bisa dibatalkan. Jika salah, hasilnya bisa dibuang dan pekerjaan diulang. Sebaliknya, menghapus data produksi, mengirim email ke pihak luar, dan menerbitkan konten secara resmi adalah operasi yang tidak bisa atau hanya sebagian bisa dibatalkan. Biaya untuk membatalkannya jauh lebih tinggi daripada biaya pelaksanaannya.
Untuk menilainya, ajukan pertanyaan yang lebih spesifik: jika Agent langsung menyadari kesalahan setelah menjalankan operasi, berapa lama dan berapa banyak tenaga yang dibutuhkan untuk memulihkannya? Jika jawabannya melampaui batas yang bisa kamu terima, operasi tersebut harus melalui persetujuan.
Dimensi dua: dampak biaya menentukan perlu tidaknya batas anggaran
Dampak biaya bukan hanya soal “berapa biaya kali ini”, tetapi juga “apakah biayanya bisa membengkak”. Risiko finansial terbesar dari Agent sering kali berasal dari pengulangan: satu kesalahan dalam logika percobaan ulang atau kondisi pemicu yang terlalu luas bisa membuat pemanggilan model terus berulang selama berjam-jam. Operasi yang murah untuk sekali jalan pun bisa menjadi terlalu mahal jika frekuensinya lepas kendali.
Karena itu, pendekatan yang lebih praktis adalah menetapkan ambang anggaran: Agent boleh bekerja secara mandiri selama biaya per operasi dan biaya kumulatif masih dalam batas. Jika terlampaui, Agent harus berhenti dan meminta persetujuan manusia. Jika Agent perlu memanggil beberapa Model Bahasa Besar, platform antarmuka terpadu seperti APIYI apiyi.com dapat menghimpun penggunaan dalam satu tempat. Dengan begitu, biaya kumulatif lebih mudah dipantau terhadap ambang anggaran tanpa perlu bolak-balik memeriksa dasbor beberapa penyedia.
Dimensi tiga: dampak pada arah menentukan siapa yang bertanggung jawab atas tujuan
Dampak pada arah adalah dimensi yang paling sulit didefinisikan dari ketiganya. Dimensi ini menilai apakah suatu operasi akan mengubah “ke mana kita ingin menuju”, misalnya dengan mengubah strategi pemilihan topik, menyesuaikan konfigurasi aturan, atau mengubah prioritas produk. Agent pandai mencari jalur terbaik untuk mencapai tujuan yang sudah ditetapkan, tetapi kurang cocok untuk menilai apakah tujuan itu sendiri perlu diubah. Penilaian tersebut membutuhkan konteks bisnis, pertimbangan merek, dan pihak yang bertanggung jawab atas keputusan tersebut.
Cara praktis untuk menentukannya: jika suatu operasi mengubah aturan atau tujuan Agent itu sendiri (misalnya menulis ulang kondisi pemicu dalam rules.json), atau hasilnya akan menjadi dasar bagi banyak tugas berikutnya, anggaplah operasi itu sebagai “perubahan arah”.
| Dimensi | Ciri risiko rendah | Ciri risiko tinggi | Penanganan yang disarankan |
|---|---|---|---|
| Dapat dibatalkan | Draf, branch, lingkungan pengujian, dapat dipulihkan dengan sekali klik | Penghapusan, penimpaan, publikasi ke luar, pengiriman pesan | Risiko tinggi wajib mendapat persetujuan |
| Dampak biaya | Biaya per operasi rendah, total masih dalam anggaran | Melampaui ambang batas, berpotensi membengkak akibat pengulangan | Mandiri dalam batas, perlu persetujuan jika melampaui |
| Dampak pada arah | Bekerja sesuai tujuan yang sudah ditetapkan | Mengubah aturan, tujuan, atau strategi jangka panjang | Selalu serahkan keputusan kepada manusia |
| Penilaian gabungan | Ketiganya berisiko rendah | Salah satu berisiko tinggi | Jika salah satu dimensi berisiko tinggi, berhenti dan tanyakan kepada manusia |
Dampak Terlalu Banyak dan Terlalu Sedikit Persetujuan
Menentukan batas pada dasarnya berarti mencari keseimbangan antara dua risiko kegagalan. Terlalu banyak maupun terlalu sedikit persetujuan bisa menggagalkan proyek otomatisasi Agent, meski dengan cara yang berbeda.
| Situasi | Ciri umum | Dampak langsung | Dampak jangka panjang |
|---|---|---|---|
| Terlalu banyak persetujuan | Setiap langkah meminta konfirmasi, kartu menumpuk | Otomatisasi berubah menjadi “manusia mengeklik tombol” | Kelelahan persetujuan: orang mulai mengeklik setuju tanpa membaca isinya |
| Terlalu sedikit persetujuan | Operasi penting juga dijalankan secara mandiri | Penghapusan yang keliru, anggaran terlampaui, atau pekerjaan melenceng | Satu insiden menghancurkan kepercayaan pada sistem |
| Batas yang tepat | Hanya berhenti pada tiga jenis titik berisiko tinggi | Manusia hanya menangani hal yang benar-benar perlu dinilai | Kepercayaan tumbuh secara bertahap, sehingga wewenang bisa dilimpahkan secara bertahap |
Dampak paling tersembunyi dari terlalu banyak persetujuan adalah “kelelahan persetujuan”. Ketika seseorang menerima puluhan kartu konfirmasi setiap hari, mereka akan segera terbiasa mengeklik setuju tanpa membaca isinya. Persetujuan pun tinggal formalitas. Ini justru lebih berbahaya daripada tidak ada persetujuan sama sekali, karena semua orang mengira ada yang mengawasi. Sistem Kazik sengaja membatasi diri untuk “hanya meminta bantuan manusia pada tiga situasi” agar setiap interupsi layak mendapat perhatian serius.
Panduan cepat batas keputusan manusia untuk Agent: Lima langkah membangun alur persetujuan
Berikut langkah-langkah merancang alur persetujuan dari nol. Pendekatan ini tidak bergantung pada framework tertentu, jadi kamu bisa menggunakan alat penjadwalan peristiwa dan platform pesan instan apa pun.
Langkah pertama: Inventarisasi semua tindakan Agent
Buat daftar semua alat dan tindakan yang dapat digunakan Agent, seperti membaca file, menulis file, menghapus rekaman, memanggil API eksternal, mengirim pesan, dan mengubah konfigurasi. Beri label pada setiap tindakan berdasarkan tiga dimensi untuk membentuk “daftar risiko tindakan”. Daftar ini menjadi dasar bagi semua aturan berikutnya sekaligus acuan bersama saat tim mendiskusikan batasan.
Langkah kedua: Kelola aturan secara terpusat
Ikuti pendekatan Kazike yang menggunakan rules.json untuk mengelola pemicu dan penjadwalan secara terpusat. Masukkan juga aturan tentang “tindakan apa saja yang memerlukan persetujuan” ke dalam konfigurasi tersebut, alih-alih menyebarkannya di petunjuk setiap Agent. Konfigurasi terpusat punya dua keuntungan:
- Dapat diaudit: siapa pun bisa melihat operasi mana saja yang saat ini memerlukan konfirmasi manusia;
- Mudah disesuaikan: ketika batasannya perlu diperketat atau dilonggarkan, cukup ubah di satu tempat.
Perlu diingat, mengubah konfigurasi ini sendiri termasuk “mengubah arah”, sehingga hanya boleh dilakukan oleh manusia.
Langkah ketiga: Biarkan CI melakukan verifikasi otomatis terlebih dahulu
Sebelum meminta persetujuan manusia, biarkan pemeriksaan otomatis memeriksa semua hal yang bisa diperiksa. Platform CI Kazike mencakup lima langkah: peninjauan, pemeriksaan, penggabungan, rilis, dan verifikasi. Dengan begitu, keputusan yang sampai ke tangan manusia sudah terbebas dari masalah mendasar seperti kesalahan format dan kegagalan pengujian. Manusia tidak seharusnya melakukan pemeriksaan yang bisa dikerjakan mesin, dan mesin tidak seharusnya mengambil keputusan yang memerlukan pertimbangan manusia.
Langkah keempat: Rancang kartu keputusan
Berikut adalah saran kami untuk merancang kartu keputusan (bukan detail sistem aslinya). Prinsip utamanya adalah membantu orang mengambil keputusan dalam hitungan puluhan detik:
- Jelaskan tindakan dalam satu kalimat: Misalnya, “Menghapus catatan draf sebelum bulan Maret”;
- Dimensi risiko yang terpicu: Tandai apakah tindakan tidak dapat dibatalkan, melebihi anggaran, atau mengubah arah;
- Cakupan dampak dan biaya: Berapa banyak data yang terdampak dan berapa perkiraan biayanya;
- Alasan dan bukti dari Agent: Mengapa tindakan ini perlu dilakukan dan bagaimana hasil verifikasi CI;
- Tombol tindakan yang jelas: Setujui, tolak, dan bila perlu sediakan opsi “Ubah lalu jalankan”.
Langkah kelima: Tentukan batas waktu dan perilaku default
Tidak semua orang selalu online. Tentukan sejak awal berapa lama kartu boleh menunggu sebelum dianggap melewati batas waktu, serta apakah tindakan default setelahnya adalah “tidak dijalankan” atau “dijalankan dengan cakupan terbatas”. Untuk tindakan seperti menghapus data atau mengeluarkan biaya, default-nya harus “tidak dijalankan”. Lebih baik tugas menunggu daripada menganggap tidak adanya respons sebagai persetujuan.
🚀 Mulai cepat: Saat membuat prototipe, sebaiknya gunakan satu titik akses model terpadu untuk menguji seluruh alur “Agent menjalankan → CI memverifikasi → kartu disetujui”. Dengan memanggil berbagai model populer melalui APIYI apiyi.com, Anda dapat berganti model tanpa mengubah logika persetujuan, lalu membandingkan seberapa sering setiap model memicu persetujuan dan kualitas alasan yang diberikannya.
Pembagian tugas antara verifikasi CI dan keputusan manusia
Banyak tim bertanya, jika CI bisa melakukan pemeriksaan, mengapa manusia masih diperlukan? Jawabannya: keduanya menjawab pertanyaan yang berbeda. Tabel berikut menjelaskan batas pembagian tugasnya:
| Tahap | Pertanyaan yang dijawab | Dasar penilaian | Penanggung jawab |
|---|---|---|---|
| Tinjauan / pemeriksaan | Apakah hasil sesuai standar | Aturan, pengujian, format | Platform CI terpusat |
| Penggabungan / rilis | Apakah bisa masuk ke tahap berikutnya | Apakah semua pemeriksaan lulus | Platform CI terpusat |
| Verifikasi | Apakah hasil benar-benar berlaku | Validasi setelah pelaksanaan | Platform CI terpusat |
| Menghapus data / mengeluarkan biaya / mengubah arah | Apakah tindakan tersebut perlu dilakukan | Pertimbangan bisnis dan tanggung jawab | Keputusan manusia |
| Sumber pemanggilan model | Model mana yang digunakan dan berapa biayanya | Batas anggaran | Aturan konfigurasi + penanganan oleh manusia bila diperlukan; APIYI apiyi.com dapat membantu merekap penggunaan |
Pertanyaan Umum (FAQ)
Q1: Apa itu batas keputusan manusia untuk Agent?
Ini adalah batas yang memisahkan tindakan yang boleh dilakukan Agent secara mandiri dari tindakan yang memerlukan konfirmasi manusia. Di dalam batas tersebut, Agent dapat bekerja tanpa hambatan. Saat mencapai batas, Agent berhenti dan menyerahkan keputusan kepada manusia. Batas ini biasanya ditetapkan berdasarkan tiga dimensi: apakah tindakan dapat dibatalkan, dampak biaya, dan dampaknya terhadap arah kerja.
Q2: Apa perbedaan persetujuan manusia dan pemeriksaan otomatis CI?
CI menjawab “apakah ini benar” berdasarkan aturan dan pengujian, sehingga cocok dilakukan oleh mesin. Persetujuan manusia menjawab “apakah ini sebaiknya dilakukan” berdasarkan pertimbangan bisnis dan tanggung jawab. Pemeriksaan CI sebaiknya diotomatisasi semaksimal mungkin, sedangkan persetujuan manusia sebaiknya dibatasi pada hal-hal yang penting. Keduanya diperlukan agar proses tetap cepat dan andal.
Q3: Bagaimana menentukan kategori yang samar seperti “mengubah arah”?
Sumber asli tidak menjelaskan cara penulis menetapkannya secara spesifik. Saran kami: perlakukan semua tindakan yang mengubah aturan atau tujuan Agent itu sendiri, serta tindakan yang hasilnya menjadi landasan bagi banyak tugas berikutnya, sebagai “mengubah arah”. Jika batasnya belum jelas, lebih baik masukkan dulu ke kategori yang memerlukan persetujuan, lalu perluas kewenangan Agent secara bertahap sesuai kondisi nyata.
Q4: Skenario apa yang paling memerlukan titik keputusan manusia?
Terutama:
– **Tugas pembersihan data**: menghapus catatan atau file kedaluwarsa secara berkala;
– **Publikasi konten otomatis**: konfirmasi akhir sebelum dipublikasikan ke publik;
– **Pemanggilan model secara massal**: pemanggilan berbayar yang jumlahnya bisa membengkak akibat perulangan;
– **Penyesuaian strategi**: mengubah arah pemilihan topik, aturan penjadwalan, dan sebagainya.
Q5: Bagaimana mengendalikan biaya Agent saat memanggil Model Bahasa Besar?
Sebaiknya tetapkan dua ambang anggaran: untuk setiap pemanggilan dan untuk total kumulatif. Agent dapat bekerja mandiri selama masih di bawah ambang, lalu meminta persetujuan jika melewatinya. Pusatkan pemanggilan model pada platform antarmuka terpadu seperti APIYI apiyi.com agar penggunaan lebih mudah dipantau dan dievaluasi terhadap ambang tersebut.
Q6: Bagaimana cara cepat memeriksa apakah batas persetujuan sudah tepat?
Mulailah dengan uji coba pada tugas nyata berskala kecil. Catat jumlah permintaan persetujuan harian, tingkat penolakan, dan rata-rata waktu respons. Jika permintaan persetujuan banyak tetapi tingkat penolakannya sangat rendah, batasnya mungkin terlalu ketat. Jika masalah baru ditemukan setelah kejadian, batasnya mungkin terlalu longgar. Pada tahap awal, gunakan beberapa model melalui APIYI apiyi.com untuk menjalankan kumpulan tugas yang sama, lalu amati perbedaan permintaan persetujuan yang dipicu oleh masing-masing model.
Q7: Apa keterbatasan pendekatan ini?
Persetujuan manusia bergantung pada ketersediaan dan respons seseorang, sehingga tugas bisa menumpuk pada larut malam atau hari libur. Jika informasi pada kartu persetujuan tidak lengkap, manusia juga bisa salah menilai. Selain itu, sumber asli yang menjadi dasar artikel ini berupa ringkasan. Detail kasus eksekusi keliru tanpa persetujuan dan mekanisme perlindungan spesifiknya belum dipublikasikan. Karena itu, saat menerapkannya, lengkapi sistem dengan mekanisme batas waktu, pencatatan log, dan rollback yang sesuai.
Kapan Agent Harus Berhenti dan Bertanya kepada Manusia: Poin Penting
- Prinsip utama: Libatkan manusia hanya saat menghapus data, mengeluarkan biaya, atau mengubah arah agar setiap persetujuan tetap bermakna.
- Penilaian tiga dimensi: Kelompokkan setiap operasi baru berdasarkan apakah tindakan bisa dibatalkan, dampak biaya, dan pengaruhnya terhadap arah pekerjaan.
- Pembagian tugas yang jelas: CI memeriksa “apakah ini benar”, sedangkan manusia memutuskan “apakah ini perlu dilakukan”. Keduanya tidak saling menggantikan.
- Waspadai kelelahan akibat persetujuan: Terlalu banyak permintaan persetujuan bisa membuat orang terbiasa menyetujui tanpa berpikir. Ini lebih berbahaya daripada tidak meminta persetujuan sama sekali.
- Utamakan keamanan secara default: Jika batas waktu habis tanpa respons, operasi berisiko tinggi tidak dijalankan.
- Satu titik akses: Gunakan APIYI apiyi.com untuk memanggil berbagai model dari satu tempat agar pengelolaan batas biaya dan perbandingan model lebih mudah.
Kesimpulan
Menentukan kapan agent harus berhenti dan bertanya kepada manusia pada dasarnya berarti menetapkan batas yang jelas antara efisiensi dan risiko:
- Mulai dari tiga titik keputusan: menghapus data, mengeluarkan biaya, dan mengubah arah. Ketiganya mencakup sebagian besar skenario berisiko tinggi;
- Perluas dengan tiga dimensi: kemungkinan membatalkan tindakan, dampak biaya, dan pengaruh terhadap arah pekerjaan. Dengan begitu, batas ini bisa diterapkan pada operasi baru apa pun;
- Kurangi beban dengan verifikasi otomatis: biarkan CI menyaring masalah mendasar, sementara manusia menangani hal-hal yang benar-benar memerlukan pertimbangan.
Batas ini tidak ditetapkan sekali untuk selamanya, tetapi bisa dilonggarkan secara bertahap seiring tumbuhnya kepercayaan. Mulailah uji coba dengan batas yang ketat, lalu gunakan data untuk menentukan bagian mana yang bisa lebih dipercayakan kepada agent. Saat membangun dan menyempurnakan sistem, gunakan APIYI apiyi.com untuk mengakses berbagai model dari satu tempat dan menguji dengan cepat kinerja masing-masing model dalam alur persetujuan Anda.
📚 Referensi
- Arsitektur sistem otomasi Agent yang dibagikan oleh 数字生命卡兹克 setelah setahun bereksperimen: Sumber prinsip dan informasi arsitektur dalam artikel ini
- Tautan:
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - Keterangan: Memperkenalkan arsitektur empat lapis yang terdiri dari platform otomasi, eksekusi Agent, platform CI, dan pengambilan keputusan melalui Feishu, serta prinsip “hanya melibatkan manusia saat menghapus data, mengeluarkan uang, atau mengubah arah” (sumber ini berupa ringkasan; baca artikel aslinya untuk memverifikasi detail)
Penulis: Tim Teknis APIYI
Diskusi teknis: Hubungi kami melalui halaman utama APIYI di apiyi.com untuk berbagi pengalaman menerapkan otomasi Agent dan kolaborasi manusia-AI. Kunjungi pusat dokumentasi di docs.apiyi.com untuk informasi lebih lanjut
