Catatan penulis: Artikel ini ditujukan bagi developer yang sudah menggunakan Agent dalam pekerjaan. Kita akan membahas konteks, bahan referensi, dan kriteria penerimaan yang perlu disiapkan sebelum menyerahkan tugas, serta membedakan hal-hal yang masih membutuhkan pemeriksaan manusia.
Setelah menggunakan Agent, hasil kerja memang bertambah, tetapi orang justru semakin lelah. Pada 3 November 2026, seorang developer di V2EX menggambarkan situasi ini: manusia tetap berada dalam alur kerja, harus memeriksa hasil sekaligus siap mengoreksi penyimpangan tugas dan masalah desain. Alhasil, sulit untuk benar-benar lepas tangan. Dalam unggahan tersebut, ia menyebutkan pengalaman yang sudah dikenal: memberikan konteks dan bahan referensi yang lebih lengkap dapat membantu Agent memahami tugas dan meningkatkan kualitas hasil kerja. Namun, unggahan itu tidak menjelaskan seperti apa “lebih lengkap” secara konkret.
Ini bukan artikel umum tentang “menulis petunjuk yang baik”. Artikel ini berfokus pada persiapan sebelum menyerahkan tugas: menguraikan kebutuhan yang masih samar menjadi tujuan, batasan, bahan referensi, dan kriteria penyelesaian yang dapat diperiksa. Dengan begitu, Agent bisa melakukan pemeriksaan mandiri, sementara Anda hanya perlu turun tangan pada beberapa titik penting. Perlu dicatat, saat ini belum ada data perbandingan publik yang dapat mengukur dampak berbagai cara persiapan. Kasus dalam artikel ini merupakan rangkuman situasi yang umum ditemui, jadi uji sendiri efektivitasnya pada tugas Anda.
Manfaat utama: Setelah membaca artikel ini, Anda akan memiliki struktur penjelasan tugas Agent dan cara menulis kriteria penerimaan yang bisa digunakan kembali. Anda juga dapat menentukan bagian mana yang bisa diperiksa sendiri oleh Agent dan mana yang harus diputuskan oleh manusia.
Poin Penting Konteks dan Kriteria Penerimaan untuk Agent
Sebelum menulis deskripsi tugas, pahami dulu gambaran besarnya: Agent biasanya melenceng karena pemahamannya tentang “apa yang harus dilakukan”, “sejauh mana harus dikerjakan”, atau “apa yang tidak boleh diubah” berbeda dengan pemahaman Anda. Tabel berikut merangkum lima unsur yang perlu ada dalam deskripsi tugas yang baik.
| Unsur | Penjelasan | Masalah yang diatasi |
|---|---|---|
| Tujuan | Jelaskan dalam satu kalimat apa yang harus dihasilkan dan untuk siapa | Mencegah Agent memperluas kebutuhan sendiri atau bekerja ke arah yang salah |
| Konteks latar belakang | Kondisi proyek saat ini, modul terkait, dan upaya yang sudah dilakukan | Mencegah pengerjaan ulang yang tidak perlu atau pembongkaran desain yang sudah ada |
| Batasan | File yang tidak boleh diubah, teknologi yang wajib digunakan, serta persyaratan performa atau kompatibilitas | Mencegah solusi yang “bisa dijalankan, tetapi tidak bisa digunakan” |
| Materi referensi | Contoh kode yang sudah ada, dokumentasi antarmuka, dan contoh gaya | Membantu hasil mengikuti gaya dan struktur proyek yang sudah ada |
| Kriteria penerimaan | Syarat penyelesaian yang bisa diperiksa satu per satu dan, jika memungkinkan, diverifikasi secara otomatis | Memungkinkan Agent memeriksa hasilnya sendiri sehingga Anda tidak perlu memeriksa setiap baris |
Tanda-tanda umum Agent melenceng dari tugas
Tulisan aslinya tidak memberikan contoh spesifik tentang tugas yang melenceng. Berikut beberapa situasi yang umum terjadi pada Agent pemrograman dan Agent yang mengerjakan tugas. Meski terlihat berbeda, akar masalahnya sering kali bisa ditelusuri ke unsur yang hilang dalam deskripsi tugas.
| Tanda-tanda melenceng | Penyebab umum | Pencegahan sejak awal |
|---|---|---|
| Memperbaiki satu bug, tetapi sekaligus merombak separuh modul | Batas tujuan tidak jelas dan cakupan perubahan tidak disebutkan | Nyatakan dalam batasan “file atau fungsi mana saja yang boleh diubah” |
| Menambahkan dependensi baru yang belum ada di proyek | Tidak memahami teknologi yang sudah digunakan | Cantumkan dependensi yang ada dan aturan larangan menambahkan dependensi baru dalam konteks |
| Gaya kode tidak konsisten dengan bagian lain proyek | Tidak ada contoh referensi | Lampirkan satu atau dua implementasi serupa sebagai materi referensi |
| Mengaku “selesai”, tetapi belum mencakup skenario penting | Kriteria penyelesaian tidak jelas | Tulis kriteria penerimaan sebagai daftar pemeriksaan yang bisa dijalankan |
| Solusi layak secara teknis, tetapi tidak sesuai dengan tujuan produk | Keputusan desain tidak dijelaskan sejak awal | Manusia membuat keputusan desain terlebih dahulu, lalu menyerahkan implementasinya kepada Agent |
Kategori terakhir ini perlu mendapat perhatian khusus. Masalahnya bukan karena konteksnya “kurang banyak”, melainkan karena pertimbangan desainnya memang perlu diputuskan oleh manusia. Hal ini akan dibahas tersendiri nanti.
Cara Menyiapkan Instruksi Tugas Agent: Struktur Lima Bagian
Kelima elemen di atas bisa dituangkan ke dalam satu dokumen instruksi yang dapat dipahami Agent dan digunakan untuk memeriksa pekerjaannya sendiri. Sebaiknya gunakan Markdown dan simpan dokumen di repositori proyek, misalnya dengan nama TASK.md. Alternatifnya, letakkan batasan umum dalam file instruksi tingkat proyek seperti AGENTS.md, lalu tulis tujuan spesifik dalam dokumen untuk setiap tugas.
Bagian Pertama: Menulis Tujuan Tugas Agent
Jelaskan dalam satu kalimat apa yang harus dihasilkan, siapa penggunanya, dan dalam situasi apa hasilnya digunakan. Deskripsi seperti “optimalkan modul login” bisa ditafsirkan Agent sebagai optimasi performa, refaktor kode, atau perombakan antarmuka. Penulisan yang lebih baik adalah: “Buat antarmuka login mengembalikan kode error yang konsisten saat kata sandi salah, agar frontend dapat menampilkan pesan yang sesuai, tanpa mengubah alur login yang berhasil.”
Jika tugasnya cukup besar, tambahkan juga kalimat tentang hal-hal yang tidak dikerjakan kali ini. Pengecualian yang jelas sering kali lebih efektif untuk mencegah Agent memperluas cakupan tugas.
Bagian Kedua: Memberikan Konteks Latar Belakang kepada Agent
Kunci konteks latar belakang bukanlah jumlahnya, melainkan relevansinya. Memberikan seluruh repositori kepada Agent tidak otomatis berarti konteksnya sudah cukup. Agent tetap perlu tahu bagian mana yang berkaitan dengan tugas ini. Sebaiknya susun informasi dengan urutan berikut:
- Modul terkait: Cantumkan file atau direktori yang berkaitan langsung dengan tugas, misalnya logika login di
src/auth/dan file pengujiannya. - Keputusan yang sudah dibuat: Jelaskan alasan desain sebelumnya, misalnya “kode error didefinisikan secara terpusat oleh modul
errors, bukan ditulis langsung dalam kode bisnis”. - Solusi yang sudah dicoba: Jika suatu pendekatan pernah dicoba lalu ditinggalkan, jelaskan alasannya agar Agent tidak mengulanginya.
- Penjelasan istilah: Jelaskan istilah bisnis internal proyek yang tidak dapat disimpulkan Agent secara andal dari kode.
Bagian Ketiga: Daftar Batasan untuk Agent
Batasan penting untuk mengurangi hasil yang “bisa dijalankan, tetapi tidak bisa digunakan”. Batasan umum dapat ditulis sebagai daftar agar Agent bisa memeriksanya sebelum mulai dan setelah selesai:
- Cakupan yang boleh diubah serta file yang dilarang diubah, misalnya skrip migrasi database dan definisi antarmuka publik.
- Batasan tumpukan teknologi, misalnya “jangan menambah dependensi pihak ketiga” atau “hanya gunakan library logging yang sudah ada di proyek”.
- Persyaratan kompatibilitas dan performa, misalnya “pertahankan signature antarmuka yang sudah ada”.
- Cara menangani situasi yang tidak pasti, misalnya “jika ternyata antarmuka publik perlu diubah, hentikan pekerjaan dan jelaskan alasannya; jangan ubah sendiri”.
Poin terakhir sangat penting. Memberi Agent kondisi yang jelas untuk berhenti dan bertanya kepada manusia jauh lebih menghemat waktu daripada mengetahui belakangan bahwa ia mengambil keputusan sendiri.
Bagian Keempat: Memilih Referensi untuk Agent
Referensi membantu Agent mengikuti praktik yang sudah ada, bukan membuat semuanya dari awal. Referensi yang paling efektif biasanya berupa implementasi sejenis dalam proyek yang sama, misalnya: “Untuk menambahkan antarmuka, ikuti pola di src/user/, termasuk validasi parameter dan penanganan error.” Untuk dokumentasi eksternal, berikan hanya bagian yang relevan dengan tugas dan cantumkan versinya agar Agent tidak menulis kode berdasarkan antarmuka versi lama.
Cara Menulis Kriteria Penerimaan Agent yang Bisa Diperiksa
Kriteria penerimaan adalah bagian dari penjelasan tugas yang paling mudah ditulis secara samar, sekaligus paling layak mendapat perhatian. Patokannya sederhana: jika Agent tidak bisa memverifikasi sendiri apakah sebuah kriteria terpenuhi, itu hanyalah harapan, bukan kriteria.
| Penulisan yang samar | Penulisan yang bisa diperiksa | Cara verifikasi |
|---|---|---|
| Kualitas kode harus baik | Lulus pemeriksaan lint yang sudah ada di proyek, tanpa peringatan baru | Agent menjalankan perintah pemeriksaan dan melaporkan hasilnya |
| Fitur berfungsi dengan baik | Tambahkan unit test yang mencakup tiga kasus: kata sandi salah, akun tidak ada, dan login berhasil. Semua tes harus lulus | Jalankan tes dan sertakan ringkasan hasilnya |
| Jangan memengaruhi fitur lain | Seluruh rangkaian tes yang ada lulus, dan tidak ada perubahan pada file yang dilarang dalam batasan | Jalankan semua tes dan tampilkan daftar file yang diubah |
| Dokumentasi harus lengkap | Tambahkan penjelasan kode error dalam dokumentasi antarmuka, dengan format yang konsisten dengan entri yang sudah ada | Bandingkan setiap bagian dengan contoh acuan |
| Performa tidak boleh menurun | Tidak ada kueri database baru pada jalur utama | Jelaskan perubahan jumlah kueri dalam ringkasan |
Setelah selesai menulisnya, minta Agent di akhir penjelasan tugas untuk melaporkan hasilnya dengan membandingkan satu per satu terhadap kriteria penerimaan: apakah setiap kriteria terpenuhi, apa buktinya, dan jika belum terpenuhi, apa alasannya. Dengan begitu, saat memeriksa hasilnya, kamu cukup melihat tabel perbandingan ini tanpa harus membaca semua perubahan dari awal.
Panduan Cepat Konteks dan Kriteria Penerimaan Agent
Berikut rangkuman langkah-langkah yang bisa langsung diterapkan. Tidak perlu alat tambahan; cukup mulai dengan satu dokumen Markdown.
5 Langkah Menyiapkan Instruksi Tugas Agent
- Tulis kriteria penerimaan sebelum tujuan: Urutan ini membantu Anda memperjelas seperti apa hasil yang dianggap “selesai” dan mencegah tujuan yang terlalu luas.
- Lengkapi konteks latar belakang: Cantumkan hanya modul, keputusan yang sudah dibuat, dan upaya yang pernah gagal yang relevan dengan tugas. Jaga agar tetap ringkas.
- Cantumkan batasan dan kondisi berhenti: Jelaskan apa yang tidak boleh disentuh dan situasi yang mengharuskan Agent berhenti untuk bertanya.
- Pilih satu atau dua contoh referensi: Utamakan implementasi serupa di dalam proyek. Untuk dokumentasi eksternal, berikan hanya bagian yang relevan.
- Minta laporan terstruktur: Setelah selesai, minta Agent melaporkan hasil berdasarkan setiap kriteria penerimaan, disertai daftar file yang diubah dan masalah yang belum terselesaikan.
Contoh instruksi tugas Agent (memperbaiki pesan kesalahan login)
Berikut kerangka instruksi tugas untuk skenario hipotetis dalam bentuk daftar. Kamu bisa langsung menggantinya dengan kebutuhanmu sendiri:
- Tujuan: Antarmuka login mengembalikan kode kesalahan yang sama saat kata sandi salah atau akun tidak ditemukan, lalu frontend menampilkan pesan berdasarkan kode tersebut. Alur login yang berhasil dan tampilan halaman tidak diubah.
- Latar belakang: Kode kesalahan didefinisikan secara terpusat di modul
errors. Sebelumnya, ada upaya untuk memeriksa teks kesalahan di frontend, tetapi dibatalkan karena masalah dukungan multibahasa. - Batasan: Hanya boleh mengubah
src/auth/dan pengujian terkait; tidak menambah dependensi; jika perlu mengubah definisi antarmuka publik, berhenti dan jelaskan alasannya terlebih dahulu. - Referensi: Cara penanganan kesalahan pada antarmuka pendaftaran di
src/user/. - Kriteria penerimaan: Tambahkan unit test untuk tiga skenario dan pastikan semuanya lolos; semua pengujian yang ada tetap lolos; lint tidak menghasilkan peringatan baru; tambahkan penjelasan dua kode kesalahan pada dokumentasi antarmuka.
- Format laporan: Bahas setiap kriteria penerimaan, cantumkan file yang diubah, dan jelaskan masalah yang masih tersisa.
🚀 Saran untuk memulai: Instruksi tugas yang sama bisa diberikan kepada beberapa model secara terpisah untuk membandingkan model mana yang paling patuh pada batasan dan kondisi berhenti. Melalui platform agregasi seperti APIYI apiyi.com, kamu bisa menggunakan satu antarmuka dan satu kunci API untuk beralih antar-model dari berbagai penyedia. Dengan begitu, kamu tidak perlu mendaftar dan mengonfigurasi banyak akun, sehingga lebih mudah melakukan pengujian perbandingan pada tugas nyata.
Audit silang solusi Agent dengan model dari berbagai vendor
Penulis unggahan asli juga menyampaikan satu kekhawatiran: model dari vendor yang sama mungkin memiliki titik buta yang serupa. Karena itu, ia ingin Agent dari berbagai vendor saling mengaudit. Namun, saat ini informasi masih harus diteruskan lewat dokumen Markdown atau salin-tempel, sehingga koordinasinya memakan banyak upaya. Gagasan ini bisa dipadukan dengan metode dalam artikel ini: deskripsi tugas dan kriteria penerimaan adalah acuan bersama terbaik untuk audit silang. Pengaudit tidak perlu memahami seluruh maksud Anda, cukup memeriksa dan mempertanyakan setiap poin berdasarkan standar yang sama.
Salah satu cara yang lebih ringan adalah memberi peran berbeda kepada setiap model, lalu menggunakan deskripsi tugas yang sama sebagai input untuk semuanya:
| Peran | Input | Tanggung jawab | Cara akses |
|---|---|---|---|
| Pelaksana | Deskripsi tugas | Menerapkan solusi dan memeriksa hasilnya sendiri berdasarkan kriteria penerimaan | Agent pemrograman yang biasa Anda gunakan |
| Pengaudit A | Deskripsi tugas + ringkasan perubahan | Memeriksa setiap kriteria penerimaan dan menunjukkan skenario yang belum tercakup | Model dari vendor lain, dapat dipanggil melalui antarmuka terpadu APIYI |
| Pengaudit B | Deskripsi tugas + ringkasan perubahan | Memeriksa secara khusus apakah ada pelanggaran terhadap batasan dan kondisi penghentian | Model dari vendor ketiga; cukup ganti nama model pada antarmuka yang sama |
| Manusia | Ringkasan hasil audit | Hanya menangani perbedaan pendapat antarpengaudit dan masalah desain | Tidak ada |
Jika Anda bersedia menulis skrip kecil yang menghubungkan alur “hasil pelaksanaan → kirim ke model pengaudit → rangkum masukan”, sebagian besar pekerjaan salin-tempel manual bisa dihilangkan. APIYI menyediakan antarmuka terpadu yang kompatibel dengan SDK populer. Cukup ganti nama model di skrip untuk memanggil model dari vendor lain. Ini mempermudah proses integrasi yang biasanya paling merepotkan saat melibatkan Agent dari berbagai vendor. Namun, perlu diingat bahwa yang diotomatisasi adalah penyampaian informasi; keputusan akhir tetap harus dibuat oleh manusia.
Masalah apa yang bisa diselesaikan dengan konteks Agent, dan apa yang tetap perlu pengawasan manusia
Konteks yang lengkap bisa mengurangi banyak koreksi, tetapi tidak bisa menghilangkan keterlibatan manusia sepenuhnya. Dalam unggahan aslinya, “tugas yang menyimpang” dan “masalah desain” disebutkan berdampingan. Padahal, keduanya berbeda: yang pertama biasanya disebabkan oleh kurangnya informasi, sedangkan yang kedua sering kali membutuhkan pertimbangan atas berbagai pilihan.
| Jenis masalah | Bisa diselesaikan dengan konteks? | Alasan | Peran manusia |
|---|---|---|---|
| Perubahan melampaui cakupan | Pada dasarnya bisa | Agent dapat memeriksa sendiri jika batasannya ditulis dengan jelas | Memeriksa daftar perubahan secara acak |
| Gaya dan format tidak konsisten | Pada dasarnya bisa | Contoh referensi sudah cukup untuk ditiru | Memeriksa sesekali |
| Cakupan pengujian tidak lengkap | Sebagian besar bisa | Skenario cukup dicantumkan dalam kriteria penerimaan | Meninjau kelengkapan daftar skenario |
| Pertimbangan arsitektur dan desain | Sulit | Memerlukan penilaian terhadap beberapa opsi yang sama-sama masuk akal | Memutuskan sebelumnya dan menuliskannya dalam penjelasan tugas |
| Tujuan produk dan pengalaman pengguna | Sulit | Bergantung pada pemahaman tentang tujuan bisnis dan pengguna | Mendefinisikan sebelumnya dan melakukan penerimaan setelahnya |
| Ketepatan kriteria penerimaan itu sendiri | Tidak bisa | Agent hanya bisa membandingkan hasil dengan kriteria, tetapi tidak bisa mempertanyakan dasar kriteria tersebut | Harus menjadi tanggung jawab manusia |
Masalah desain sulit diserahkan sepenuhnya kepada Agent karena biasanya tidak ada satu jawaban yang paling benar. Misalnya, “apakah kode kesalahan sebaiknya ditempatkan di modul umum atau modul bisnis?” Keduanya bisa berfungsi, tetapi pilihannya bergantung pada arah pengembangan dan kebiasaan pemeliharaan tim. Informasi seperti ini sering kali tersimpan dalam pertimbangan manusia dan sulit dituangkan secara lengkap ke dalam tulisan.
Karena itu, strategi yang lebih praktis adalah melibatkan manusia lebih awal: buat keputusan desain dan tuliskan sebagai batasan sebelum tugas dimulai. Dengan begitu, Anda tidak perlu terus memantau Agent saat bekerja. Setelah selesai, Anda hanya perlu memeriksa daftar perbandingan dengan kriteria penerimaan dan poin-poin yang masih diperdebatkan oleh para peninjau. Posisi manusia dalam alur kerja pun berubah: dari “mendampingi sepanjang proses” menjadi “menentukan arah di awal dan melakukan penerimaan di akhir”.
Pertanyaan Umum (FAQ)
Q1: Apa itu kriteria penerimaan untuk Agen?
Kriteria penerimaan adalah syarat yang harus dipenuhi saat tugas selesai dan bisa diperiksa satu per satu, misalnya “semua pengujian yang ditentukan lulus” atau “tidak ada perubahan pada file yang dilarang untuk diubah”. Kriteria ini membantu Agen memeriksa hasilnya sendiri dan memudahkan manusia menilai hasil dengan cepat tanpa membaca seluruh output baris demi baris.
Q2: Apakah semakin banyak konteks selalu semakin baik?
Tidak. Informasi yang tidak relevan bisa mengaburkan fokus, bahkan membuat Agen mengubah bagian yang seharusnya tidak disentuh. Pilih konteks yang sesuai dengan tugas, seperti modul terkait, keputusan yang sudah dibuat, upaya yang pernah gagal, dan istilah yang diperlukan. Jika belum yakin suatu informasi berguna atau tidak, gunakan APIYI apiyi.com untuk memanggil berbagai model dan menguji penjelasan tugas versi ringkas maupun lengkap. Lihat versi mana yang membuat hasilnya lebih jarang melenceng.
Q3: Apakah setiap tugas kecil perlu penjelasan selengkap ini?
Tidak perlu. Batasan umum dan latar belakang proyek bisa ditulis dalam file petunjuk tingkat proyek untuk digunakan berulang kali. Untuk setiap tugas, Anda cukup menambahkan tujuan, referensi, dan kriteria penerimaan. Untuk perubahan kecil yang bisa diselesaikan dalam beberapa menit, satu kalimat tujuan dan dua atau tiga kriteria penerimaan biasanya sudah cukup.
Q4: Metode ini cocok untuk Agen dan jenis tugas apa saja?
Metode ini terutama cocok untuk Agen pemrograman dan Agen tugas dengan hasil yang jelas, seperti memperbaiki bug, mengimplementasikan antarmuka, membuat dokumentasi, dan mengolah data. Untuk tugas yang sangat eksploratif dan tujuannya belum jelas, kriteria penerimaan sulit ditentukan sejak awal. Sebaiknya manusia dan Agen mendiskusikan arahnya terlebih dahulu sebelum mulai mengerjakannya.
Q5: Bagaimana cara menggunakan model dari berbagai penyedia untuk saling memeriksa tanpa bolak-balik menyalin dan menempel?
Anda bisa menulis skrip kecil yang mengirimkan hasil pekerjaan dan penjelasan tugas ke model peninjau, lalu merangkum masukannya. Dengan antarmuka terpadu APIYI apiyi.com, Anda cukup mengganti nama model dalam skrip untuk memanggil model dari penyedia lain, tanpa perlu mengintegrasikan SDK dan akun masing-masing secara terpisah. Cara ini cocok untuk membuat prototipe alur kerja “pelaksanaan + peninjauan oleh beberapa pihak” dengan cepat.
Q6: Apa saja keterbatasan metode ini?
Pertama, metode ini tidak bisa menggantikan pertimbangan desain: pilihan arsitektur dan tujuan produk tetap harus diputuskan oleh manusia. Kedua, jika kriteria penerimaan salah, Agen akan tetap berusaha memenuhi kriteria yang salah tersebut. Selain itu, saat ini belum ada data publik yang mengukur perbedaan efektivitas berbagai cara persiapan. Sebaiknya lakukan perbandingan skala kecil pada tugas Anda sendiri dan catat berapa kali Anda perlu mengoreksi arah pekerjaan sebagai bahan pertimbangan.
Poin Utama Konteks dan Kriteria Penerimaan Agent
- Hasil yang melenceng biasanya disebabkan oleh informasi yang kurang: Tujuan, batasan, atau referensi yang tidak lengkap dapat memicu pekerjaan ulang.
- Lima unsur penjelasan tugas: Tujuan, konteks latar belakang, batasan, referensi, dan kriteria penerimaan semuanya wajib ada.
- Kriteria penerimaan harus bisa diperiksa: Kriteria yang tidak bisa diverifikasi sendiri oleh Agent hanyalah harapan.
- Tetapkan kondisi berhenti: Jelaskan kapan Agent harus berhenti dan bertanya. Ini lebih mudah daripada mengoreksi hasil belakangan.
- Buat keputusan desain sejak awal: Manusia menentukan kompromi arsitektur dan produk terlebih dahulu, lalu memasukkannya ke dalam batasan.
- Gunakan standar yang sama untuk tinjauan silang: Panggil model dari beberapa penyedia melalui antarmuka terpadu APIYI untuk membandingkan hasil tinjauan.
Kesimpulan
Keterlibatan manusia dalam siklus kerja Agent terasa melelahkan, sebagian besar karena tugas diserahkan dengan informasi yang tidak lengkap. Akibatnya, kamu harus terus memantau dan mengoreksi arahnya. Ada tiga hal utama yang perlu disiapkan sejak awal:
- Tulis penjelasan tugas dalam lima bagian: Tujuan, latar belakang, batasan, referensi, dan kriteria penerimaan. Dengan begitu, Agent tahu apa yang harus dikerjakan, seberapa jauh hasilnya, dan apa yang tidak boleh disentuh.
- Susun kriteria penerimaan sebagai hal-hal yang bisa diperiksa: Minta Agent melaporkan hasilnya berdasarkan setiap kriteria. Kamu cukup meninjau tabel perbandingan dan masalah yang belum terselesaikan.
- Bedakan masalah yang bisa ditangani lewat konteks dan yang harus diperiksa manusia: Tentukan kompromi desain sebelumnya, dan pastikan manusia tetap bertanggung jawab atas kriteria penerimaan itu sendiri.
Mulai dari tugas nyata berikutnya: tulis kriteria penerimaan terlebih dahulu, lalu lengkapi bagian lainnya. Catat juga berapa kali kamu perlu turun tangan di tengah proses sebagai dasar perbaikan. Jika kamu juga ingin mencoba tinjauan silang menggunakan model dari beberapa penyedia, APIYI di apiyi.com menyediakan antarmuka terpadu untuk mengakses berbagai model. Uji pada tugas nyata untuk melihat kombinasi mana yang paling mengurangi kebutuhanmu untuk turun tangan.
📚 Referensi
- Diskusi V2EX – Cara mengurangi intervensi manusia agar agent bekerja mandiri dan meningkatkan kualitas hasil: Sumber topik artikel ini
- Tautan:
v2ex.com/t/1254207 - Keterangan: Membahas kelelahan manusia dalam siklus kerja Agent, peran konteks, dan gagasan untuk melakukan tinjauan silang oleh Agent dari berbagai penyedia
Penulis: Tim Teknis APIYI
Diskusi teknis: Hubungi kami melalui beranda APIYI di apiyi.com untuk berbagi pengalaman tentang penyusunan instruksi tugas Agent dan kolaborasi multimodel
