Penulis：Yanhua
Antonio Gullí adalah Direktur Rekayasa di Google. Ia menulis buku berhalaman 453 yang memecah pengembangan AI Agent menjadi 21 pola desain.
Tetapi ini bukan ulasan buku. Motivasi saya membaca buku ini sangat spesifik: saya pernah menulis Harness Engineering, pengalaman gagal dengan Clawdbot, dan artikel “Agen AI Bukan Ajaib” yang menggambarkan tujuh perubahan dari pembakaran Token hingga benar-benar berguna; setiap kali selesai menulis, ada satu pertanyaan yang belum sepenuhnya terjawab: apakah ada logika dasar yang dapat digunakan kembali di balik semua ini?
This book gave me the answers, and deeper than I thought.
Yang kamu tulis mungkin sama sekali bukan Agent
Penilaian paling tajam dalam buku ini tersembunyi di prolog.
Sebagian besar orang menggunakan "AI" hanya Level 0: LLM telanjang, tanpa alat, tanpa memori, tidak bisa bertindak. Anda bertanya kepadanya film apa yang akan memenangkan Oscar 2025, ia menebak. Buku ini menjelaskan dengan jelas: sesuatu di Level 0 bukanlah Agent.
Naik ke atas baru yang sebenarnya Agent:
Level 1: Pengguna alat
Agen mulai menggunakan alat: pencarian, API, database. Tetapi ia tidak hanya “mampu memanggil antarmuka”, melainkan harus mampu menilai sendiri kapan harus memanggil, apa yang harus dipanggil, dan bagaimana menggunakan hasilnya. Buku ini memberikan contoh yang sangat spesifik: pengguna bertanya, “Apa ada drama baru terbaru?”, Agen menyadari sendiri bahwa informasi ini tidak ada dalam data pelatihan, sehingga secara aktif memanggil alat pencarian untuk mencari, lalu menyusun hasilnya. Langkah kuncinya ada pada “menyadari sendiri”. Bukan manusia yang menyuruhnya, “Cari dulu”, melainkan ia sendiri yang menilai bahwa pencarian diperlukan. Kemampuan penilaian ini adalah ambang batas Level 1.
Level 2: Pemikir Strategis
Dua hal tambahan: perencanaan dan Context Engineering. Buku ini mendefinisikan Context Engineering: bukan mengumpulkan informasi, melainkan memilih, memangkas, dan mengemas konteks dengan cermat. Contohnya sangat bagus: pengguna ingin mencari kedai kopi di antara dua lokasi. Agent terlebih dahulu memanggil alat peta untuk mendapatkan sejumlah data, lalu secara mandiri menentukan bahwa “langkah selanjutnya hanya membutuhkan nama jalan,” memangkas output peta menjadi daftar singkat, lalu memberikannya ke alat pencarian lokal. Setiap langkah melakukan reduksi kebisingan informasi.
Ada satu kalimat di buku itu yang saya baca berulang-ulang: “Untuk mencapai akurasi tertinggi pada AI, Anda harus memberinya konteks yang singkat, fokus, dan kuat.” Context Engineering adalah hal yang dilakukan untuk ini.
Pada tingkat ini, Agent masih bisa merefleksikan diri. Setelah menyelesaikan tugas, ia memeriksa sendiri dan memperbaiki masalah yang ditemukan. Saya akan menjelaskan lebih detail nanti.
Level 3: Kolaborasi Multi-Agent
Posisi buku sangat jelas: jangan terus-menerus berpikir untuk menciptakan super agent serba bisa. Pendekatan yang benar-benar andal adalah seperti membangun tim: Agent manajer proyek + Agent peneliti + Agent desainer + Agent penulis konten. Contoh yang diberikan dalam buku adalah peluncuran produk baru: seorang "Agent manajer proyek" mengoordinasikan secara keseluruhan dan mendistribusikan tugas kepada "Agent riset pasar", "Agent desain produk", dan "Agent pemasaran". Kuncinya adalah komunikasi: bagaimana Agent saling mentransmisikan data, menyinkronkan status, dan menangani konflik. Bab ini menggambarkan enam struktur topologi komunikasi, mulai dari Agent tunggal yang paling sederhana hingga campuran kustom yang paling fleksibel, dengan penjelasan masing-masing cocok untuk skenario apa.
Setelah melihat empat tingkatan ini, saya tiba-tiba mengerti mengapa banyak orang mengatakan "Agent saya tidak berguna." Modelnya tidak bermasalah, masalahnya adalah Anda menggunakannya seperti chatbot, mungkin ia bahkan belum mencapai Level 1.
Context Engineering: Konsep yang paling diremehkan dalam buku ini
Saya pernah menulis tentang Harness Engineering, yang membahas bahwa desain lintasan lebih penting daripada tenaga mesin. Setelah membaca buku ini, saya menyadari bahwa Context Engineering adalah penerapan Harness Engineering pada level prompt.
Prompt Engineering tradisional hanya mengatur "bagaimana Anda bertanya". Context Engineering dalam buku ini mengatur "apa yang ada di depan Agent sebelum Anda bertanya". Ini mencakup empat lapisan informasi:
Lapisan pertama, system prompt. Mendefinisikan siapa Agent, nada apa, dan batas apa. Kebanyakan orang hanya menulis lapisan ini.
Lapisan kedua, data eksternal. Dokumen yang diambil oleh RAG, nilai kembali dari pemanggilan alat, data API real-time. Ini adalah titik di mana kebanyakan orang terjebak: tahu bahwa mereka harus memberikan data, tetapi tidak tahu cara memberikannya tanpa membanjiri model.
Lapisan ketiga, data implisit. Identitas pengguna, riwayat interaksi, status lingkungan. Hal-hal yang tidak Anda katakan secara eksplisit tetapi seharusnya diketahui oleh Agent. Misalnya, ketika Anda mengatakan kepada Agent, "Bantukan saya mengirim email ke John untuk mengonfirmasi rapat besok," seharusnya Agent tahu apa rapat Anda besok di kalender Anda dan bagaimana hubungan Anda dengan John.
Lapisan keempat, umpan balik. Setiap kali Agent menghasilkan output, kualitasnya dievaluasi secara otomatis dan strategi konteks untuk output berikutnya disesuaikan. Buku ini menyebutnya sebagai "otomatisasi optimasi konteks", dan Google Vertex AI Prompt Optimizer adalah implementasi teknis dari ide ini.
Saat saya membaca ini, saya teringat tulisan saya sebelumnya berjudul "Agen AI Bukanlah Sihir", di mana salah satu pelajaran yang saya sampaikan adalah "Agen Anda memerlukan aturan, dan banyak aturan". Sekarang saya melihat kembali, aturan-aturan itu pada dasarnya adalah versi manual dari Context Engineering, yang diubah menjadi sistematis dalam buku ini.
Reflection: Dua Agent benar-benar lebih baik daripada satu
Ini adalah Pola paling bernilai secara praktis bagi saya dalam buku ini.
Inti dari Reflection sangat sederhana: Agent setelah menyelesaikan tugas, memeriksa sendiri dan memperbaiki masalah yang ditemukan. Namun, cara mewujudkannya memiliki pertimbangan khusus. Buku ini secara jelas menyatakan: Producer dan Critic harus menggunakan dua Agent berbeda dengan system prompt yang berbeda. Seorang persona yang meninjau karya sendiri pasti akan memiliki blind spot. Jika Anda meminta LLM yang sama untuk menulis kode lalu memeriksa kode yang ditulisnya sendiri, kemungkinan besar ia akan mengatakan “cukup baik”.
The book provides a complete code example.
Prompt dari Producer adalah “Anda adalah pengembang Python, tulis fungsi untuk menghitung faktorial, tangani kondisi batas dan pengecualian.”
Prompt Critic adalah "Anda seorang insinyur tingkat tinggi yang teliti, meninjau kode baris demi baris, memeriksa Bug, gaya, kondisi batas yang terlewatkan, dan area yang dapat ditingkatkan. Jika sempurna, keluarkan
CODE_IS_PERFECT, jika tidak, daftarkan semua masalah."Kemudian ada loop for: Producer menulis kode → Critic meninjau → Producer memperbaiki berdasarkan masukan → Critic meninjau lagi → hingga Critic mengatakan
CODE_IS_PERFECTatau mencapai jumlah iterasi maksimum.
Sangat sederhana. Namun, buku ini memperingatkan tentang masalah biaya yang sering diabaikan: setiap siklus refleksi adalah panggilan LLM baru, semakin banyak iterasi, semakin mahal harganya. Selain itu, seiring dengan membesarnya riwayat percakapan, jendela konteks penuh oleh versi sebelumnya dan komentar kritis, ruang inferensi yang tersedia secara aktual menyusut. Oleh karena itu, praktik terbaik untuk Reflection adalah: tetapkan jumlah iterasi maksimum yang masuk akal (buku ini menggunakan angka 3), dan berhenti begitu Critic puas, jangan mengejar kesempurnaan.
Gunanya jauh lebih dari sekadar menulis kode. Menulis artikel, membuat rencana, merangkum dokumen, menyelesaikan soal logika, model Producer-Critic bisa diterapkan semuanya. Buku ini mencantumkan tujuh aplikasi, dengan logika inti yang sama: menghasilkan terlebih dahulu, lalu meninjau, kemudian memperbaiki.
Multi-Agent tidak semakin kompleks semakin baik
Saya paling menyukai keenam diagram topologi komunikasi di bab Kolaborasi Multi-Agent. Banyak orang langsung memilih yang kompleks, tetapi sebenarnya sebagian besar skenario cukup dengan tiga:
Single Agent (independent execution): The task can be split into independent subproblems, each handled by its own Agent. Simple and easy to maintain.
Jaringan peer-to-peer: Agent berkomunikasi langsung satu sama lain tanpa node pusat. Terdesentralisasi, tahan terhadap kesalahan, satu agent yang gagal tidak memengaruhi keseluruhan sistem. Namun, biaya koordinasi tinggi dan mudah menjadi kacau.
Supervisor (pusat pengaturan): Sebuah Supervisor Agent mengelola sekelompok Worker Agent. Membagikan tugas, mengumpulkan hasil, menyelesaikan konflik. Hierarki jelas, mudah dikelola. Namun, Supervisor adalah titik kegagalan tunggal dan juga hambatan kinerja.
Tiga jenis lainnya (Supervisor-as-Tool, hirarkis, dan campuran khusus) adalah varian dan kombinasi dari tiga yang pertama. Buku ini menjelaskan dengan jujur: topologi yang Anda butuhkan tergantung pada kompleksitas tugas Anda. Semakin banyak tugas dibagi menjadi bagian-bagian kecil, semakin tinggi biaya komunikasinya; pada titik tertentu, pola Supervisor justru lebih efisien daripada pola hirarkis.
Pengalaman saya adalah, banyak orang menghabiskan 80% waktu mereka untuk protokol komunikasi saat membangun Multi-Agent, tapi lupa bertanya pertanyaan yang lebih mendasar: apakah tugas ini benar-benar memerlukan beberapa Agent? Buku ini menjelaskan dengan jelas, Level 2 dengan Single Agent + Reflection seringkali sudah cukup. Level 3 disiapkan untuk skenario di mana Single Agent benar-benar tidak mampu menanganinya.
Model tiga lapisan Memory, sebelumnya saya sempat merasakannya tapi belum memberi nama
Saya paling bersimpati dengan bab Memory, karena saat saya menulis dua artikel tentang Obsidian + Claude, saya terus memikirkan pertanyaan ini: Bagaimana cara mengelompokkan memori Agent?
Jawabannya ada di buku:
Sesi (sesi lapisan): Jendela konteks percakapan saat ini, ini adalah memori terpendek, dan akan hilang setelah percakapan berakhir. Model konteks panjang hanya memperbesar jendela ini, tetapi pada dasarnya masih bersifat sementara, dan setiap inferensi harus memproses seluruh jendela, sehingga mahal dan lambat.
State (tingkat status): Data sementara selama tugas sedang berlangsung. Misalnya, "tugas apa yang sedang dikerjakan", "sudah selesai sampai tahap mana", "data apa saja yang dihasilkan di tengah proses". Lebih panjang daripada Session, tetapi akan dibersihkan setelah tugas selesai; buku ini menggunakan mekanisme State Google ADK sebagai contoh lengkap.
Memori (lapisan persisten): Memori jangka panjang yang melintasi sesi dan tugas. Preferensi pengguna, pengalaman yang dipelajari, dan keputusan historis penting disimpan di database atau penyimpanan vektor, dengan pencarian semantik. Buku ini menekankan poin penting: Memori bukan hanya disimpan, tetapi juga harus dirancang dengan strategi lengkap tentang "apa yang disimpan, kapan disimpan, dan bagaimana cara mencarinya". Terlalu banyak disimpan akan menimbulkan noise, terlalu sedikit akan kurang memadai.
Saya sebelumnya menulis artikel tentang Clawdbot dan menyebutkan "file status" dan "dokumen workspace", yang pada dasarnya adalah membuat lapisan State dan Memory secara manual, dan buku ini merangkum hal tersebut dalam kerangka kerja.
Lima asumsi, yang kelima paling tidak masuk akal
Di akhir buku, lima asumsi tentang masa depan Agent disebutkan; empat yang pertama masih berada dalam lingkup perkiraan yang masuk akal: Agent generik mulai dari menulis kode hingga mengelola proyek, menemukan kebutuhan Anda secara aktif dengan personalisasi mendalam, kecerdasan tubuh keluar dari layar masuk ke dunia fisik, dan Agent menjadi entitas ekonomi independen.
Kelima yang membuat saya terkejut:变形 Multi-Agent.
Anda hanya menyatakan tujuan, misalnya "membuat bisnis e-commerce yang menjual kopi premium". Sistem secara otomatis menentukan: pertama membuat "Agent Riset Pasar" dan "Agent Brand". Setelah menjalankan satu putaran data, sistem secara mandiri menilai bahwa Agent Brand tidak diperlukan lagi, lalu membaginya menjadi tiga Agent baru: "Agent Desain Logo", "Agent Pembuatan Situs Web", "Agent Rantai Pasok". Jika Agent Pembuatan Situs Web menjadi bottleneck, sistem secara otomatis akan menggandakan tiga Agent paralel untuk mengerjakan halaman yang berbeda secara bersamaan. Sepanjang proses ini, sistem terus secara otomatis mengoptimalkan prompt setiap Agent dan terus mereorganisasi struktur tim.
Buku ini menyebutnya sebagai "sistem multi-agent yang berorientasi tujuan dan bersifat self-transforming". Ia tidak menjalankan rencana yang Anda tulis, tetapi membuat rencana sendiri, menyesuaikan rencana sendiri, dan mereorganisasi tim eksekusi sendiri.
Ini mengingatkan saya pada AutoResearch Karpathy: tulis sebuah program.md, tentukan tujuan, indikator, dan batasan, lalu “jalankan”. Manusia berada di luar siklus. Tetapi buku ini mendorong lebih jauh: bahkan bagaimana tim Agent dibentuk dan direstrukturisasi, semuanya diserahkan kepada sistem untuk memutuskan sendiri. Manusia hanya menyatakan “apa yang diinginkan”.
Tiga hal yang bisa langsung dilakukan
Setelah membaca buku ini, saya memiliki tiga tindakan yang bisa langsung diterapkan:
Pertama, tambahkan seorang Critic ke Agent saat ini. Entah Anda menggunakan Claude Code, CrewAI, atau kerangka yang Anda bangun sendiri, tambahkan satu langkah di akhir workflow Anda saat ini: biarkan Agent lain (dengan system prompt berbeda) meninjau output dari langkah sebelumnya. Pembuatan kode tambahkan tinjauan kode, penulisan artikel tambahkan verifikasi fakta, perencanaan tambahkan penilaian kelayakan. Satu panggilan LLM tambahan, tetapi peningkatan kualitas seringkali berlipat ganda. Pola Producer-Critic dalam buku ini siap pakai.
Kedua, mulailah melakukan Context Engineering, bukan hanya Prompt Engineering. Tinjau kembali file instruksi yang Anda tulis untuk Agent. Jika seluruhnya berisi aturan "Anda harus melakukan apa", tetapi tidak ada konteks "Anda sedang menghadapi lingkungan apa sekarang", tambahkan. Beri tahu Agent di proyek mana ia berada sekarang, keputusan apa yang telah diambil sebelumnya, dan preferensi pengguna seperti apa. Bab tentang Context Engineering dalam buku ini dan
AGENTS.mdAnda adalah dua penyampaian dari hal yang sama.Ketiga, jangan terburu-buru menggunakan Multi-Agent. Jadikan Agent tunggal Anda mencapai Level 2: memiliki alat, Reflection, dan Memory. Buku ini secara berulang menekankan bahwa Agent tunggal Level 2 ditambah Producer-Critic dan Context Engineering mampu mencakup sebagian besar skenario nyata. Level 3 dirancang untuk tugas lintas bidang, multi-tahap, yang memerlukan pembagian tugas paralel. Masalah kebanyakan orang bukanlah jumlah Agent yang terlalu sedikit, melainkan satu Agent pun belum disetel dengan baik.
Buku ini memiliki 453 halaman, diterbitkan oleh Springer pada tahun 2025. Contoh kode mencakup LangChain/LangGraph, Google ADK, CrewAI, dan OpenAI API. Kata pengantar ditulis oleh VP AI Google Cloud, dan ada kata sambutan dari CIO Goldman Sachs, yang secara tak terduga sangat menarik.
Tetapi alasan saya merekomendasikannya bukan karena "komprehensif". Setelah Anda membacanya, Anda akan menyadari satu hal: semua jebakan yang pernah Anda alami di Agent selama enam bulan terakhir telah dirangkum menjadi pola-pola. Anda tidak perlu lagi menciptakan Reflection, tidak perlu lagi menebak bagaimana membagi Memory, dan tidak perlu lagi mencoba topologi komunikasi seperti apa yang harus digunakan untuk Multi-Agent.
Seseorang telah membuatkan peta untukmu, yang tersisa hanyalah berjalan.
Apakah Anda mengembangkan menggunakan AI Agent? Agent Anda sekarang sudah mencapai Level berapa?