OpenWorker: AI Agent Open-Source dari Andrew Ng

Jika Anda ingin sistem AI yang menyelesaikan pekerjaan alih-alih sekadar menjawab prompt, OpenWorker punya satu ide utama dalam satu kalimat: ia merencanakan tugas, memakai tool, dan berhenti untuk minta persetujuan sebelum aksi berisiko tinggi.

Saya akan merangkumnya begini: OpenWorker adalah kerangka kerja agent open-source dan local-first yang berjalan lewat aplikasi desktop dan server Python lokal, merutekan pekerjaan lintas model cloud dan lokal, serta memakai 4 tingkat izin untuk mengontrol akses file, eksekusi perintah, dan pesan ke luar. Ia cocok untuk tim yang menginginkan kontrol lebih ketat atas data, hambatan penyiapan yang lebih rendah antar model, serta pemeriksaan manusia yang jelas sebelum apa pun yang berisiko terjadi.

Berikut versi singkatnya:

• Apa yang dilakukannya: mengubah sebuah tujuan menjadi alur kerja multi-langkah
• Bagaimana ia berjalan: aplikasi desktop Tauri 2 + antarmuka React 18 + server lokal FastAPI/Uvicorn
• Akses model: penyedia cloud dan model lokal melalui aisuite, plus Ollama untuk penggunaan lokal
• Model keamanan: read, write_local, exec, dan external
• Peninjauan manusia: setiap langkah exec dan external menunggu persetujuan
• Tool terhubung: file, kalender, Slack, dan sistem tim lain
• Opsi endpoint model: APIMart lewat satu API yang kompatibel dengan OpenAI
• Pekerjaan paling cocok: laporan, riset, paket konten, tugas dukungan, dan pipeline media
• Kebutuhan produksi: tracing, evals, versioning prompt, pelacakan biaya, dan alur peninjauan outbox

Beberapa fakta menonjol. OpenWorker memakai 4 tipe aksi, memblokir 100% aksi exec dan external sampai seseorang menyetujuinya, dan dapat berpindah antar model seperti GPT-5, Claude Sonnet 4.6, dan Gemini 3 Pro Preview tanpa mengubah logika alur kerja.

Kalau saya memutuskan apakah ini cocok untuk tim saya, saya akan melihat satu hal lebih dulu: apakah saya punya pekerjaan berulang dengan langkah yang jelas dan kebutuhan persetujuan manusia atas aksi berisiko? Jika ya, OpenWorker masuk akal.

Andrew Ng: State of AI Agents | LangChain Interrupt

Cara Kerja OpenWorker: Arsitektur, Model, dan Izin

Keandalan OpenWorker berasal dari tiga lapisan: eksekusi lokal, routing model, dan gerbang persetujuan.

Aplikasi desktop dan server agent lokal

OpenWorker berjalan sebagai aplikasi desktop Tauri 2 dengan antarmuka React 18, dipasangkan dengan server Python 3.10+ lokal yang memakai FastAPI dan Uvicorn. Dalam bahasa sederhana, aplikasi yang Anda lihat di desktop bekerja berdampingan dengan server lokal yang berjalan di mesin Anda.

Penyiapan itu menjaga agent tetap dekat dengan data sekaligus pengguna. Ini juga membantu menjaga segalanya lebih ketat dari sisi kontrol, karena server secara default mendengarkan di localhost.

Routing model lintas LLM cloud dan lokal

OpenWorker memakai aisuite untuk merutekan permintaan antara penyedia model cloud dan runtime lokal seperti Ollama. Itu memberi tim keleluasaan untuk menentukan ke mana setiap tugas sebaiknya diarahkan, alih-alih mengirim semuanya lewat satu jalur.

Misalnya, tim dapat menjaga tugas privat tetap lokal dan merutekan pekerjaan berisiko lebih rendah ke tempat lain. Jika datanya sensitif, tugas dapat dikirim ke model lokal melalui Ollama.

Perencanaan tugas, aksi bertipe, dan gerbang persetujuan

Saat Anda memberi OpenWorker sebuah tujuan, ia memecah tujuan itu menjadi langkah-langkah terpisah dan menetapkan tipe izin untuk setiap aksi sebelum apa pun dijalankan. Jadi alih-alih satu kotak hitam besar, Anda mendapatkan serangkaian langkah yang dapat diperiksa dan ditinjau.

Keempat tipe izin memetakan langsung ke tingkat risiko:

Gerbang persetujuan memblokir setiap aksi exec dan external sampai seorang manusia menyetujuinya. Model kontrol itulah yang membuat lapisan integrasi berikutnya menjadi praktis.

Tool, Integrasi, dan Akses Model Bertenaga APIMart

Bekerja lintas file, kalender, Slack, dan sistem tim

OpenWorker terhubung ke file lokal, kalender, Slack, dan sistem tim lain melalui tool bawaan, integrasi terkelola, dan konektor.^[4] Itu membuatnya berguna untuk mengotomatiskan pekerjaan yang saling terhubung, bukan sekadar tugas sekali jalan.

Beginilah gambarannya dalam praktik. Sebuah tim operasional meminta OpenWorker menyiapkan laporan kinerja mingguan dan membagikannya ke tim. Agent membaca ekspor analitik lokal, menyusun dokumen yang rapi di folder bersama, membuat draf ringkasan Slack dengan metrik utama, lalu berhenti untuk meminta persetujuan sebelum mengirim apa pun keluar dari tim.^[4] OpenWorker mengerjakan koordinasinya. Manusia tetap yang memutuskan apa yang keluar.

Tim konten dan pemasaran dapat memakai penyiapan yang sama untuk paket konten. OpenWorker dapat menarik riset sumber dari file lokal, membuat draf brief atau dokumen blog, dan menandai tenggat peninjauan di kalender tim - semuanya tanpa menyentuh sistem eksternal sampai seseorang menyetujuinya.^[4]

Memakai APIMart sebagai endpoint model terpadu

Setelah tool terhubung, langkah berikutnya adalah akses model. OpenWorker dapat memakai APIMart sebagai endpoint model terpadunya melalui satu base URL yang kompatibel dengan OpenAI.^[2][3]

Penyiapannya cukup sederhana:

• Buat API key APIMart
• Kirim payload JSON standar yang kompatibel dengan OpenAI untuk permintaan chat, completion, dan media

Dari sudut pandang OpenWorker, APIMart tampak seperti satu penyedia yang stabil. Namun di balik satu endpoint itu, tim dapat berpindah antar model seperti GPT-5, Claude Sonnet 4.6, atau Gemini 3 Pro Preview tanpa mengubah alur kerja agent sama sekali. Artinya satu lapisan routing dan lebih sedikit pemeliharaan lintas model yang dipakai tim.

Alur kerja multi-modal untuk tim konten dan media

Penyiapan routing yang sama juga mendukung pekerjaan multimodal di luar teks. Dengan APIMart, OpenWorker dapat berpindah dari riset ke skrip lalu ke pembuatan video melalui satu endpoint.^[1]

Untuk tim yang memproduksi konten video mingguan, OpenWorker dapat mengoordinasikan seluruh pipeline - riset, penulisan skrip, pembuatan aset, dan penyiapan peninjauan - sementara APIMart menangani pemilihan model di latar belakang. Alur kerjanya tetap sama. Hanya modelnya yang berubah.

Menjalankan OpenWorker Secara Andal di Produksi

Penggunaan produksi memerlukan tracing, kontrol, dan visibilitas biaya lintas model, tugas, dan tim. Dibangun di atas izin dan routing model yang sudah ada, bagian ini membahas lapisan operasional yang membuat fondasi tersebut bekerja dalam praktik. Langkah berikutnya adalah mengubah penyiapan itu menjadi sesuatu yang dapat Anda amati, audit, dan kontrol di produksi.

Tracing, evals, dan versioning prompt

Keandalan produksi dimulai dengan visibilitas ke setiap langkah dari setiap eksekusi.

Setiap eksekusi agent sebaiknya mencatat seluruh status eksekusi: status percakapan, input dan output tool, model mana yang dipakai, jumlah token, dan latensi per langkah. Tanpa itu, debugging berubah menjadi tebak-tebakan. Dengan itu, Anda dapat melihat persis di mana sebuah alur kerja gagal dan memperbaiki bagian itu tanpa mengganggu sisanya.

Versioning prompt sama pentingnya. Saat sebuah tim memperbarui system prompt untuk meningkatkan kualitas keluaran, selalu ada kemungkinan ia merusak sesuatu yang sebelumnya sudah berfungsi. Menjalankan golden test - sekumpulan kecil input yang diketahui baik dengan keluaran yang diharapkan - terhadap setiap perubahan prompt membantu menangkap regresi sebelum sampai ke produksi. Golden test menangkap regresi prompt sebelum penerapan.

Kontrol risiko dan pengawasan manusia untuk aksi sensitif

Ketika sebuah agent dapat memengaruhi sistem bersama, eksekusinya memerlukan serah terima yang dapat ditinjau.

Untuk aksi sensitif, gunakan pola outbox: agent mencatat aksi yang diniatkan untuk ditinjau sebelum dieksekusi.^[5] Ini pas untuk sistem bersama, di mana peninjauan manusia sebaiknya terjadi sebelum eksekusi, bukan setelah kerusakan terjadi.

Ini terkait langsung dengan tipe izin exec dan external yang disiapkan sebelumnya - pola outbox mengatur serah terima akhir untuk aksi berisiko lebih tinggi tersebut. Pada penyiapan multi-agent yang lebih kompleks, struktur folder yang dibangun di sekitar direktori inbox/, outbox/, dan workspace/ menjaga batas data tetap bersih dan serah terima tetap dapat diprediksi.^[5] Setiap agent tahu dari mana harus membaca dan ke mana harus menulis, yang membuat pipeline lebih mudah diaudit.

Manajemen biaya dan model dengan routing APIMart

Setelah alur kerja berjalan, kontrol biaya menjadi kebutuhan operasional.

Dengan APIMart sebagai endpoint pusat, tim dapat melacak pengeluaran, menetapkan batas harga, dan memantau latensi di satu tempat. Jika Anda sudah menjalankan alur kerja multi-model, routing terpusat memangkas overhead pengelolaan key, SDK, dan dashboard yang terpisah untuk tiap penyedia.

Dengan key langsung, lonjakan biaya sering baru ditemukan di akhir siklus penagihan. Dengan routing APIMart, tim dapat menetapkan batas harga dan aturan routing sebelum sebuah alur kerja berubah menjadi masalah yang mahal.

Kasus Penggunaan Praktis dan Kesimpulan

Riset, operasional konten, dan alur kerja media

Setelah kontrol alur kerja disiapkan, OpenWorker cenderung bersinar pada pekerjaan berulang bervolume tinggi. Ia bekerja paling baik ketika sebuah tugas mengikuti rangkaian langkah yang sama berulang kali.

Itulah sebabnya ia sangat cocok untuk alur kerja pemasaran, riset, dan media. Tim dapat mengotomatiskan penyusunan konten dengan mengoordinasikan bagian-bagian proses yang berbeda dan memeriksa hasil akhir terhadap standar merek. Dalam satu pipeline, tim dapat membuat draf teks, menghasilkan gambar, dan membuat video pendek melalui satu endpoint.

Penyiapan itu membuat lompatan dari riset ke pembuatan teks, gambar, dan video jauh lebih mulus. Alih-alih menyambungkan tool secara manual, tim dapat menjalankan seluruh alur di satu tempat.

Dukungan, operasional, dan otomatisasi operasional internal

Ide yang sama berlaku untuk dukungan dan operasional internal. OpenWorker dapat melakukan lebih dari sekadar mengirim balasan sederhana. Ia dapat menjawab, memverifikasi, dan mengambil tindakan pada tugas rutin seperti pengecekan status pesanan, reset kata sandi, dan permintaan penagihan.

Bagi tim, hal itu penting karena banyak pekerjaan internal tidak sulit. Ia hanya berulang. OpenWorker membantu memajukan pekerjaan itu sambil menjaga aksi sensitif tetap berada di balik gerbang persetujuan.

Kesimpulan: Apa yang dapat dibangun tim hari ini

Digabungkan, alur kerja ini menunjukkan di mana OpenWorker paling kuat saat ini. Desain open-source-nya memberi tim kontrol langsung atas kustomisasi, data, dan biaya. Penyiapan itu dibangun di sekitar eksekusi local-first dan otomatisasi praktis yang menyelesaikan pekerjaan alih-alih sekadar memulainya.

Cara cerdas untuk memulai sederhana saja: mulai dengan satu alur kerja berulang bervolume tinggi, buktikan nilainya, lalu perluas.

FAQ

Untuk siapa OpenWorker paling cocok?

OpenWorker bekerja paling baik untuk tim lintas fungsi, developer, dan unit bisnis yang ingin membawa AI dari demo menjadi otomatisasi yang andal dan siap produksi.

Ia cocok untuk tim yang menskalakan alur kerja multi-langkah lintas riset, operasional konten, dukungan pelanggan, dan otomatisasi proses bisnis - terutama saat mereka ingin tetap mengendalikan kustomisasi, integrasi, dan biaya.

Bisakah OpenWorker menjaga data sensitif tetap lokal?

Ya. Kerangka kerja agent open-source sering mendukung penerapan lokal, sehingga developer dapat membangun dan menguji agent sambil menjaga data sensitif tetap di dalam sistem mereka sendiri.

Dengan model penerapan lokal dan protokol komunikasi berbasis file, tim dapat menjaga batas data yang ketat tetap ada dan menjaga operasi tetap internal.

Tugas apa yang sebaiknya diotomatiskan tim lebih dulu?

Mulai dengan alur kerja berbasis aturan bervolume tinggi. Target awal terbaik adalah tugas berulang, mudah diukur, dan sudah terhubung ke sistem seperti CRM, ERP, atau help desk.

Kasus penggunaan awal yang baik mencakup triase dukungan pelanggan dan pemrosesan faktur. Mengapa ini dulu? Keduanya dapat memangkas pekerjaan manual dengan cepat dan menurunkan biaya layanan tanpa perombakan proses besar.

Dari sana, tim dapat bercabang ke pemrosesan dokumen, ekstraksi data, dan pembuatan konten.