Di halaman ini
Bayangkan tugas browser ilustratif dengan seratus langkah. Anggap setiap langkah berhasil 99% dari waktu, secara independen dari langkah lain. Peluang semuanya berhasil adalah 0.99^100, sekitar 36,6%.
Sembilan puluh sembilan persen terdengar sangat baik. Tiga puluh enam persen tidak.
Diskusi sumber tentang pekerjaan transaksi di browser memakai perhitungan ini untuk satu poin yang terbatas: pelanggan memperoleh nilai ketika tugas selesai, sedangkan biaya dan risiko kegagalan bertambah pada setiap langkah. Ini perhitungan berdasarkan asumsi, bukan angka keberhasilan yang dipublikasikan untuk agen browser atau sinkronisasi Tajo. Dalam praktik, kesalahan bisa saling bergantung. Satu sesi login yang kedaluwarsa dapat merusak beberapa tindakan berikutnya sekaligus.
Karena itu, pertanyaan yang berguna bukan “Seberapa akurat klik terakhir model?” melainkan “Apakah keadaan yang diminta pengguna benar-benar tercapai?”
Transaksi adalah satuan yang penting
Bayangkan agen membuka portal asuransi, menemukan dokumen, mengunduhnya, lalu memastikan dokumen itu milik akun yang benar. Agen dapat melewati 99 layar dengan benar tetapi mengunduh berkas yang salah di layar ke-100. Catatan penuh klik yang berhasil tidak memperbaiki hasilnya.
Perbedaan yang sama berlaku untuk integrasi. Agen dapat menemukan API, mengusulkan pemetaan bidang, dan menyimpan draf. Tak satu pun berarti kontak di sistem tujuan kini memiliki status persetujuan yang dimaksud. Pekerjaan baru selesai ketika operasi yang disetujui telah dijalankan dan keadaan akhirnya yang relevan telah diperiksa.
Inilah perbedaan antara aktivitas dan penyelesaian. Aktivitas mudah dihitung. Penyelesaian perlu didefinisikan.
Untuk unduhan, buktinya mungkin berkas dengan nomor akun yang sesuai permintaan. Untuk sinkronisasi kontak, buktinya mungkin catatan tujuan dengan pengenal, bidang, dan status izin pesan yang tepat. Pemeriksaan harus melihat hal yang memang dibutuhkan pengguna. Respons hijau dari panggilan sebelumnya membuktikan panggilan itu mendapat jawaban. Respons itu belum tentu membuktikan bahwa sistem tujuan berubah sesuai rencana.
Panduan Tajo untuk menghubungkan alat bisnis dimulai dari alur kerja dan sumber kebenaran bagi tiap objek data. Keputusan itu memberi makna pada pemeriksaan terakhir. Jika dua sistem sama-sama mengaku memiliki satu bidang, bahkan penulisan yang berhasil sempurna bisa menghasilkan keadaan jangka panjang yang salah.
Biaya satu keputusan lagi
Dengan asumsi 99% yang sama, sepuluh keputusan independen memberi peluang keberhasilan seluruh rangkaian sekitar 90,4%. Lima puluh keputusan memberi sekitar 60,5%. Seratus keputusan memberi sekitar 36,6%.
Peluang keberhasilan seluruh rangkaian (%)
Jumlah langkah independen
- Asumsi keberhasilan 99% per langkah
Baca nilai yang dihitung
| Langkah | Keberhasilan seluruh rangkaian (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Kurva turun tajam karena perkalian tidak peduli bahwa rata-ratanya terlihat baik. Setiap keputusan tambahan harus mempunyai alasan untuk tetap ada.
Itu tidak berarti semua panggilan API harus digabungkan menjadi satu operasi raksasa. Beberapa panggilan bersifat deterministik: mengambil halaman dengan kursor yang diketahui, membandingkan pengenal, atau menulis bidang sesuai pemetaan yang telah disetujui. Model tidak perlu mengulang keputusan itu untuk tiap catatan. Panggilan lain mengandung ambiguitas nyata: bidang baru dari penyedia, pesan kesalahan yang berubah, atau permintaan dengan penanggung jawab yang tidak jelas. Kasus itu mungkin memerlukan penilaian.
Pembagian praktisnya ialah memakai penilaian untuk merancang atau memperbaiki aturan, lalu memakai kode biasa untuk menjalankan aturan yang stabil. Reverse ETL menunjukkan pemindahan data berulang: pipeline, bukan percakapan, seharusnya mengerjakan setiap baris rutin. Agen masih dapat membantu menentukan apa yang semestinya dilakukan pipeline.
Ini batas kerja, bukan slogan. Jika penyedia mengubah arti suatu bidang, aturan deterministik dapat mengulangi tindakan yang salah dengan sempurna. Sistem perlu mendeteksi perubahan asumsi itu dan mengembalikan kasusnya untuk ditinjau.
Mengapa satu alat besar bukan jawabannya
Keberatan yang wajar adalah: “Jika rangkaian panjang mudah gagal, masukkan seluruh tugas ke satu panggilan alat.” Itu membantu bila alat menjalankan transaksi yang terdefinisi jelas dan hasilnya dapat diperiksa. Itu gagal bila alat hanya menyembunyikan proses panjang yang tidak pasti.
Misalkan syncCustomer() mengembalikan success: true setelah mengirim pembaruan. Jika sistem tujuan memproses pembaruan belakangan, panggilan itu belum bisa membuktikan status akhir kontak. Alat mengurangi jumlah langkah yang terlihat. Ketidakpastian belum berkurang.
Antarmuka yang lebih baik memperlihatkan keadaan penting: diterima, diterapkan, diperiksa, atau gagal. Tiap istilah harus sesuai dengan bukti. Penulisan yang diterima mungkin cukup untuk pratinjau berisiko rendah. Audiens kampanye atau perubahan persetujuan memerlukan pemeriksaan di sistem tujuan sebelum dinyatakan selesai.
Dalam tampilan Tajo yang diusulkan ini, permintaan diterima dan pembaruan diterapkan berbeda dari keadaan tujuan yang terverifikasi. Pemeriksaan terakhir masih tertunda. Langkah berikutnya jelas: periksa apa yang disimpan tujuan. Menghitung satu panggilan alat berhasil lagi tidak menjawab pertanyaan awal.
Penulisan yang selesai tetap memerlukan bukti
Apakah sinkronisasi pelanggan selesai?
Penulisan diterapkan. Verifikasi tertunda.
Keadaan di tujuan belum diperiksa.
Aktivitas sinkronisasi
- Permintaan diterima
- Pembaruan diterapkan
- Pemeriksaan tujuan tertunda
Proses contoh · 14:32 UTC
Yang diketahui
- Respons penyedia
- Diterima
- Hasil penulisan
- Diterapkan
- Baca ulang dari tujuan
- Tertunda
Panggilan berhasil tidak membuktikan keadaan akhir.
Tata letak yang diusulkan berdasarkan umpan aktivitas Tajo. Ilustrasi ini menambahkan status verifikasi; fitur baca ulang tujuan belum dinyatakan tersedia.
Ini juga mengubah apa yang diukur. Catat jumlah percobaan jika berguna untuk menelusuri biaya. Catat kesalahan antara jika menunjukkan langkah yang rusak. Namun nilai alur kerja berdasarkan transaksi yang benar-benar selesai dan diverifikasi, dengan metode verifikasi di samping angkanya. Tim yang melaporkan “99% panggilan berhasil” belum menjawab apakah pelanggan memperoleh hasil yang diminta.
Penjelasan server MCP menunjukkan bagaimana alat memungkinkan asisten memanggil sistem lain. Akses alat hanyalah langkah awal. Kontraknya adalah keadaan yang ditinggalkan sesudahnya.
Seratus klik yang baik masih bisa tidak menghasilkan apa-apa. Hitung hasilnya.
Pertanyaan yang sering diajukan
Mengapa alur kerja panjang gagal jika tiap langkah biasanya berhasil?
Jika tiap langkah berhasil secara independen dengan peluang p, peluang keberhasilan rangkaian n langkah adalah p pangkat n. Dengan asumsi 99% per langkah, seratus langkah selesai sekitar 36,6% dari waktu. Kegagalan nyata bisa saling terkait; hitungan ini ilustrasi, bukan tingkat keberhasilan agen yang diukur.
Apakah mengurangi panggilan alat menjamin keandalan?
Tidak. Panggilan yang lebih sedikit membantu hanya jika operasi gabungannya tetap menyediakan pemeriksaan dan titik pemulihan yang diperlukan. Satu panggilan yang tidak transparan pun bisa menyembunyikan penulisan yang gagal.
Apa yang perlu diukur tim untuk alur kerja agen?
Ukur penyelesaian transaksi pengguna yang telah diverifikasi, bukan hanya keberhasilan panggilan model. Tetapkan artefak atau keadaan di sistem tujuan yang membuktikan pekerjaan selesai, lalu catat seberapa sering keadaan itu tercapai setelah seluruh alur kerja.