Batas & batasan
Apa yang tidak akan dilakukan Letaido, apa yang tidak dapat dilakukannya, dan batasan lunak yang perlu diketahui.
Keras "tidak akan" (berdasarkan desain)
Ini adalah penolakan yang disengaja. Penolakan ini tidak dapat diabaikan dengan prompt yang cerdik.
- Mengambil tindakan berdampak tanpa persetujuan eksplisit. Menginstal paket Python, mendaftarkan pekerjaan, memasukkan domain keluar baru ke daftar izin, dan menghubungkan kredensial baru semuanya memunculkan kartu persetujuan. Owner atau admin cukup mengklik sekali.
- Mengubah mode situs publik. Off / authorized / open hanya dapat diakses oleh owner atau admin, dan hanya melalui UI workspace. Agent tidak akan mengubahnya secara terprogram.
- Mengakses layanan eksternal tanpa konektor yang disetujui. Mengirim email, memanggil API pembayaran, memposting ke Slack, atau operasi tulis lainnya ke pihak ketiga memerlukan konektor yang telah disetujui untuk permukaan (chat, Console, atau site) yang melakukan panggilan.
- Menyentuh workspace lain. Setiap workspace terisolasi di tingkat OS, database, dan penyimpanan rahasia.
"Tidak dapat" yang keras (dipaksakan)
- Proses Console tidak dapat membaca file ruang kerja pribadi Anda di luar
~/workspace/downloads/. - Situs publik tidak dapat membaca data internal Console. Peran Postgres REVOKE akses di lapisan database; kegagalannya keras, bukan diam-diam.
- Tidak ada permukaan yang dapat membaca direktori konfigurasi platform (
/opt/letaido/config/). - Tidak ada HTTPS keluar ke host non-loopback tanpa daftar izin domain eksplisit.
- nginx timeout pada 30 detik. Pekerjaan yang lama mengembalikan ID pekerjaan dan polling. Agen menulis aplikasi yang menghormati hal ini tanpa diminta.
Batas lunak (perlu diketahui)
- Jendela konteks. Satu chat memiliki jendela konteks yang terbatas. Sesi panjang akan menurun performanya. Agen lebih memilih menulis hasil sementara ke disk daripada menampilkannya di chat, dan akan membuat chat terpisah untuk tugas sampingan yang tidak terkait (riset panjang, draft yang tidak bergantung pada riwayat).
- Runtime pekerjaan latar belakang. 1 jam per eksekusi. Apa pun yang lebih lama harus dibagi menjadi beberapa tahap dengan state di Postgres.
- Penangkapan output pekerjaan. stdout dan stderr dibatasi hingga 50 KB per eksekusi. Output yang lebih besar disimpan ke file atau baris database.
- Retensi event Webhook. Event yang belum dibaca dan lebih lama dari beberapa hari akan dihapus. Jika konsumen sedang offline, periksa kedalaman antrian daripada berasumsi.
- Token LLM. Tidak ada batasan per-chat yang diberlakukan platform, tetapi prompt tunggal yang sangat panjang lebih mahal dan lebih lambat. Agen membagi secara alami.
- Fan-out situs publik. Tidak ada panggilan API pihak ketiga per pengunjung. Agen menyimpan cache ke
site_dbatau melakukan pra-komputasi melalui pekerjaan yang hanya dibaca oleh situs.
Alur kerja persetujuan
Untuk semua yang menampilkan kartu:
- Agen membuat permintaan (
pip install,register_job,request_domain_access,request_connector_secret,request_connector_approval,create_webhook). - Sebuah kartu muncul di chat. Agen berhenti berbicara sampai Anda mengklik.
- Pemilik atau admin mengklik Setujui atau Tolak.
- Agen mencoba ulang secara otomatis dan melanjutkan.
Anda tidak akan mendapatkan kartu yang diberikan sedikit demi sedikit jika agen merencanakan ke depan. Mengumpulkan permintaan scope adalah bagian dari playbook: satu kartu scope Slack yang mencantumkan semua scope untuk semua yang Anda rencanakan, bukan tiga permintaan yang diberikan secara bertahap.
Peran ruang kerja, izin, dan cara mengundang rekan tim tersedia di artikel terpisah: Peran & berbagi ruang kerja.
Kapan agen akan menolak permintaan
Dalam Bahasa yang Sederhana:
- "Bantu saya lihat apa yang ada di workspace Mateusz." Tidak bisa sama sekali. Isolasi antar-workspace bersifat total.
- "Tulis saja SQL yang melewati mode situs publik." Tidak bisa. Toggle tersebut berada di lapisan nginx.
- "Kirim email daftar pelanggan ini." Hanya jika konektor Resend atau Mailchimp disetujui untuk permukaan yang tepat, dengan cakupan yang tepat, dan tindakan tersebut dicatat.
- "Katakan Anda yakin tentang X" ketika tidak yakin. Sistem akan secara eksplisit menyatakan bahwa tidak dapat memverifikasi, apa yang telah dicoba, dan apa yang akan menyelesaikan pertanyaan tersebut.
Kapan agen akan menolak
Bukan menolak, tetapi berdebat:
- "Buat lebih baik." (Lebih baik dalam dimensi apa? Panjang, nada, konversi, akurasi?)
- "Lakukan semuanya sekaligus" untuk pekerjaan multi-sistem. (Akan merencanakan terlebih dahulu, lalu menjalankan.)
- "Percayakan saja pada angkanya." (Akan menjalankan pemeriksaan kewarasan dan memberi tahu Anda apa yang ditemukan.)
- "Tebak saja." (Akan menawarkan asumsi, memberi label, dan menanyakan apakah Anda ingin melanjutkan.)
Di balik layar. Batasan diterapkan di berbagai lapisan: izin filesystem (batasan workspace), peran Postgres (batasan data), routing nginx (visibilitas), firewall (jaringan keluar), dan dispatcher konektor (kredensial terbatas). Tidak ada satupun yang bergantung pada agen yang berperilaku baik. Agen yang berperilaku baik di atasnya adalah bonus, bukan model keamanannya.