Kata-kata kasar acak tentang di mana kita berada dengan agen AI:

Beberapa tidak menyebutnya agen, tetapi "agen alur kerja" dengan alur deterministik ada di mana-mana dan berfungsi. siapa pun dapat membangun agen alur kerja sederhana, bahkan memulai dengan alat tanpa kode seperti Zapier dan n8n. Agen alur kerja yang kompleks membutuhkan lebih banyak pemikiran untuk membangun dengan andal dan efisien. alur kerja yang kompleks untuk kasus penggunaan umum dan berharga, dengan integrasi yang relevan yang dipanggang, dapat berdiri sendiri sebagai bisnis, dan juga GTM yang bagus untuk diperluas nanti ke alur kerja lain atau pekerjaan yang lebih otonom.

Agen yang lebih dinamis/otonom mulai bekerja dan membantu untuk penelitian (terutama jika berbasis web) dan pengkodean. kurang dapat diandalkan setelah Anda mulai menambahkan lebih banyak sumber data (misalnya API). Agen hanya-baca terasa aman dan mudah diuji, tetapi membiarkan agen otonom mengambil tindakan (menulis) itu menakutkan. (ide acak tentang ini: akan keren jika alat seperti CRM memungkinkan Anda "bergarpu" cermin pengembang dan menjalankan eksperimen otomatisasi yang dapat Anda putar kembali atau gabungkan kembali.)

Agen dinamis bekerja dengan baik ketika mereka dapat (1) membuat dan melacak rencana yang baik dan (2) melaksanakan tugas dengan benar, sementara (3) menemukan konteks yang tepat untuk dimasukkan ke dalam setiap langkah (baik perencanaan maupun setiap tugas). Akhirnya, perlu (4) merefleksikan di sepanjang jalan (baik dengan atau tanpa masukan manusia) sehingga dapat menyesuaikan rencana dengan tepat, dan juga meningkatkan cara mengeksekusi tugas yang gagal atau berkinerja buruk.

Perencanaan tugas: Kemampuan penalaran LLM berfungsi dengan baik untuk daftar tugas sederhana yang tidak memerlukan konteks pribadi (seperti penelitian mendalam, hanya serangkaian pencarian web saat meringkas). Jika Anda ingin meneliti banyak entitas, penelitian mendalam tidak berfungsi dengan baik karena manajemen daftar tugas relatif mendasar. Alat AI berbasis spreadsheet bekerja lebih baik untuk meneliti banyak entitas karena Anda secara efektif memindahkan manajemen tugas ke spreadsheet, karena meneruskan daftar tugas yang panjang di antara petunjuk tidak berfungsi di sini. Manajemen tugas di agen pengkodean bekerja dengan masalah sederhana, kode sederhana, atau saat Anda memulai dari awal. Setelah Anda masuk ke proyek yang sudah ada sebelumnya yang lebih kompleks, mereka kurang dapat diandalkan - dan pengembang meningkatkan keandalan dengan mendokumentasikan cara kerja kode mereka dan diatur (file .md) yang memungkinkan agen untuk membuat daftar tugas yang lebih terinformasi. Kode kompleks membutuhkan lebih banyak dokumen dan akhirnya secara dinamis hanya menarik konteks yang relevan dari dokumen tersebut. Banyak orang/bisnis memiliki pendapat yang kuat tentang urutan/pendekatan/alat yang benar untuk menangani suatu proyek, dan kami membutuhkan lebih banyak pendekatan untuk mendokumentasikan ini di muka dan dengan cepat. Alasan lain mengapa pengkodean dan agen penelitian berbasis web bekerja dengan baik adalah karena mereka semua menggunakan alat yang sama sehingga tidak perlu "mempelajari" cara menggunakan alat tersebut (lebih lanjut tentang ini selanjutnya).

Eksekusi tugas: Tugas biasanya berupa panggilan API (membutuhkan autentikasi dan pemahaman tentang cara menggunakan API, dan struktur data yang mendasarinya - yang dapat unik seperti dalam CRM atau DB dengan tabel/kolom khusus), penalaran LLM (misalnya meringkas), kombinasi, dan bahkan agen alur kerja*. Agen penelitian sebenarnya hanyalah pencarian web dan ringkasan dalam lingkaran. agen pengkodean adalah CRUD pada basis kode Anda, dan mungkin pencarian web untuk API pembelajaran. Autentikasi dan akses API dasar terasa terpecahkan (MCP cocok di sini), tetapi saya ingin melihat lebih banyak seputar konteks khusus alat (tanyakan kepada pengguna, tetapi juga menganalisis koneksi awal, menggali data yang ada untuk memahami bagaimana alat digunakan, bagaimana data terstruktur, skenario/proyek apa yang kami gunakan alat ini.), kesalahan/refleksi/umpan balik perlu diubah menjadi pembelajaran terorganisir yang diumpankan kembali sebagai konteks bila relevan. Alat yang sama dapat digunakan untuk tujuan yang berbeda dan dengan cara yang berbeda antar organisasi dan kita perlu menangkap/mendokumentasikannya entah bagaimana untuk menjalankan tugas dengan baik.

Konteks: Bayangkan menjadi karyawan baru di perusahaan. Anda belajar banyak selama orientasi (dan semakin baik orientasi, semakin efektif Anda keluar dari gerbang), dan kemudian ada pembelajaran di tempat kerja yang dipecah menjadi belajar dari pengalaman organisasi ("Beginilah cara kami melakukan sesuatu") dan belajar dari pengalaman sendiri - sebelumnya lebih dominan di organisasi besar. Manajemen konteks serupa. ada lapisan konteks seperti meta (pengguna/perusahaan), spesifik proyek/departemen, spesifik tugas, khusus alat, dll. kami telah berevolusi dari perintah sistem sederhana ke strategi RAG hibrida (vektor, kata kunci, grafik), tetapi di luar memiliki data/konteks, kami membutuhkan panduan tentang kapan dan bagaimana mengambil konteks, yang kami lihat versi awal hari ini - tetapi banyak ruang untuk perbaikan. Ini bukan hanya masalah teknis, tetapi juga masalah bisnis - karena pada dasarnya Anda perlu membuat dokumen orientasi yang mencakup setiap skenario yang Anda harapkan. Saat proyek menjadi lebih rumit, dibutuhkan lebih banyak perhatian untuk memangkas konteks dengan benar sehingga hanya informasi yang relevan yang disertakan dalam prompt, sambil meminimalkan konteks yang tidak relevan.

refleksi: kami memiliki alat pemantauan agen yang mencakup biaya LLM/api, pengamatan, tetapi menetapkan keberhasilan/kegagalan adalah tantangan - satu area di mana agen pengkodean memiliki keunggulan pada yang lain adalah cara deterministik untuk melihat kegagalan (melalui pengujian kode). Untuk banyak tugas agen lainnya, kami masih mencari cara yang tepat untuk mengumpulkan masukan manusia untuk meningkatkan output di masa mendatang. AFAIK, Refleksi saat ini adalah manusia-dalam-lingkaran, di mana umpan balik sebagian besar diumpankan kepada pengembang manusia untuk meningkatkan agen, tetapi pembukaan datang ketika kita mencari cara mengubah refleksi menjadi peningkatan diri - di mana agen mengambil wawasan dari kegagalan dalam pembuatan daftar tugas dan eksekusi tugas untuk melakukan yang lebih baik di lain waktu. Pada dasarnya, refleksi perlu berubah menjadi konteks yang mengatur dengan baik yang dapat ditarik menjadi petunjuk kapan dan hanya jika relevan. ini berkembang menjadi potongan-potongan agen, dan kemudian lingkungan RL agen - masih terasa cukup awal di sini

*Sebelumnya saya menyebutkan penyerahan tugas kepada agen alur kerja, yang mulai masuk akal ketika agen Anda akan mendapat manfaat dari tidak memiliki agen alur kerja sebagai alat (vs mencari tahu daftar tugas yang diketahui setiap kali) atau ketika sistem Anda cukup rumit sehingga agen khusus dengan konteks dan alat khusus berkinerja lebih baik. Atau jika Anda memanfaatkan agen yang dibuat oleh orang lain (satu pola yang mulai saya lihat di sini adalah titik akhir API bahasa alami untuk kolaborasi agen yang lebih mudah).

jika kita memiliki kualitas model saat ini dengan jendela konten tak terbatas (tidak ada penurunan kualitas), komputasi tak terbatas, penyimpanan tak terbatas, akses browser, dan metode pembayaran, satu loop LLM mungkin cukup untuk menyelesaikan banyak hal inti dari poin-di atas (tidak ada yang tidak terbatas) adalah bahwa orkestrasi agen sebagian besar tentang mengelola keterbatasan dengan merancang cara untuk membongkar pekerjaan dari LLM melalui struktur dan kode.

Agen dalam produksi hadir dalam berbagai rasa: sebagai alat internal, sebagai produk yang berdiri sendiri yang menggabungkan berbagai alat, dan dipanggang sebagai fitur untuk alat inti. mereka bisa generik atau khusus. obrolan, suara, dan agen latar belakang tampaknya menjadi antarmuka UI yang paling umum untuk memicu alur agen.

Apa lagi yang saya lewatkan?