Referensi Jawaban untuk Pertanyaan Pemikiran

File ini mengumpulkan garis besar referensi jawaban untuk pertanyaan pemikiran di seluruh sepuluh bab buku ini. Sebagian besar pertanyaan pemikiran bersifat terbuka dan tidak memiliki satu jawaban yang benar. Referensi jawaban dihasilkan oleh AI dengan sedikit tinjauan manusia, dan disediakan hanya untuk perbandingan dan inspirasi pembaca. Pembaca didorong untuk menggunakan LLM bersama dengan konten buku untuk mendiskusikan pertanyaan-pertanyaan ini lebih lanjut.

Bab 1: Memulai dengan AI Agents

1. (★★) Jika Anda hanya bisa menambahkan satu kemampuan ke sistem Agent—model yang lebih kuat, konteks yang lebih kaya, atau lebih banyak tools—mana yang akan Anda pilih? Di bawah kondisi apa pilihan Anda akan berubah?

Mengikuti formula "otak/mata/tangan dan kaki", temukan titik lemah terlebih dahulu: biasanya prioritasnya adalah memperkaya konteks—yaitu, untuk memperluas ruang observasi. Jika tugas melebihi kemampuan penalaran model, beralihlah ke model yang lebih kuat. Jika ruang aksi tidak mencukupi (misalnya, tidak ada akses ke sistem internal perusahaan), tambahkan tools. Cara menilainya adalah dengan menganalisis lintasan kegagalan dan menemukan apakah kemacetannya terletak pada persepsi, pengambilan keputusan, atau tindakan.

2. (★★★) Dalam loop ReAct, setiap panggilan LLM dari Agent menerima seluruh lintasan sejarah, sehingga seiring bertambahnya lintasan, biaya desain ini tumbuh secara kuadratik. Bisakah pertumbuhan kuadratik itu dipatahkan tanpa kehilangan informasi kritis?

Pendekatan yang layak: kompresi konteks—merangkum lintasan awal dan hanya menyimpan kesimpulan serta status kunci (kompresi multi-lapis dari Bab 2); pembelajaran eksternal—menulis hasil sementara ke file atau Knowledge Base dan mengambilnya sesuai permintaan daripada membiarkannya tetap berada di dalam konteks; membagi pekerjaan ke dalam sub-agents.

3. (★★) Paradigma "Model as Agent" berarti model menjadi lebih otonom dalam keputusan Tool Use. Namun, bab ini berpendapat bahwa pentingnya rekayasa Harness sebenarnya meningkat. Bagaimana kedua tren ini bisa hidup berdampingan? Di manakah letak nilai inti masa depan dari framework Agent?

Metafora kuda dan tali kekang: semakin kuat model dan semakin besar otonominya, semakin luas radius dampak dari kesalahan, dan semakin besar kebutuhan akan batasan, verifikasi, dan koreksi. Nilai framework bergeser dari "mengorkestrasi panggilan LLM" ke lapisan jaminan di antara lima elemen Harness: klasifikasi izin, pemutus sirkuit, pemulihan kesalahan, kompresi konteks, dan ekosistem tools.

4. (★★) Dalam eksperimen ablasi, ketiadaan "umpan balik hasil tool" menyebabkan Agent jatuh ke dalam loop tak terbatas. Di lingkungan produksi, selain ketiadaan hasil tool, situasi apa lagi yang bisa menyebabkan Agent mengalami loop? Mekanisme deteksi dan penghentian apa yang akan Anda rancang?

Penyebab lain: sebuah tool berulang kali mengembalikan kesalahan yang sama; panggilan halusinasi ke tools yang tidak ada; kompresi konteks menghilangkan status kritis; konten penalaran dilucuti dan API model mengalami error; tugas itu sendiri tidak dapat diselesaikan. Mekanisme: atur kondisi berhenti seperti jumlah iterasi maksimum; deteksi panggilan berulang (tool yang sama + sidik jari argumen); eskalasi ke intervensi manusia setelah ambang batas kegagalan terlampaui.

5. (★) Bab ini menganalisis lima produk Agent di sepanjang tiga dimensi: konteks kerja, antarmuka aksi, dan strategi. Pilih satu produk AI yang Anda gunakan setiap hari, analisis di sepanjang tiga dimensi yang sama, dan nilai apakah arsitekturnya sesuai. Jika Anda merancangnya, apa yang akan Anda perbaiki?

Terbuka. Poin-poin penting: mengikuti tabel di bab ini, tuliskan mata (sumber informasi apa yang dapat dilihatnya), tangan dan kaki (apakah ruang aksinya terbuka, apakah ia dapat berpikir secara internal), dan strategi (pola loop eksekusi Agent).

6. (★★) Jika Anda harus merancang sistem layanan pelanggan khusus untuk memesan penerbangan, apakah Anda akan memilih pola alur kerja atau pola Agent otonom? Mungkinkah mencampur kedua pola tersebut dalam sistem yang sama?

Gunakan alur kerja sebagai tulang punggung: empat node—verifikasi identitas → pencarian → pembayaran → pemesanan—yang menjamin pemesanan yang patuh seperti "tidak ada pemesanan sebelum pembayaran" dan membatasi permukaan serangan Prompt Injection dalam satu node. Beralih ke Agent otonom untuk segmen terbuka (memahami persyaratan, pemesanan ulang, merekomendasikan alternatif saat penerbangan dibatalkan). Tambahkan konfirmasi manusia untuk operasi berisiko tinggi (pembayaran besar, pengembalian dana).

7. (★★★) Bagian batasan keamanan menyebutkan peringkat risiko tool. Jika sebuah tool umumnya berisiko rendah tetapi menjadi berisiko tinggi dengan kombinasi parameter tertentu (misalnya, delete_file menghapus file normal vs. menghapus file sistem), bagaimana Anda akan merancang penilaian risiko dinamis?

Perbaiki target peringkat dari "tool" menjadi "tool + argumen": hitung risiko pada saat panggilan berdasarkan reversibilitas, izin, dan radius dampak. Gunakan pemeriksaan deterministik berbasis aturan (allowlist/blocklist jalur, ekspresi reguler) daripada penilaian model. Validasi hanya boleh melihat data terstruktur untuk menjaga dari manipulasi Prompt Injection.

8. (★★) Dalam tabel produk Agent di bab ini, semua Agents memiliki ruang aksi "terbuka". Dalam skenario apa ruang aksi yang dibatasi (misalnya, hanya dapat memilih dari opsi yang telah ditentukan sebelumnya) akan lebih unggul daripada yang terbuka?

Skenario dengan kepatuhan tinggi, risiko tinggi, kesalahan yang tidak dapat diubah: untuk pengembalian dana dan pembayaran, opsi yang dibatasi adalah "batasan"—secara inheren tahan kesalahan, membuat kesalahan tidak mungkin terjadi berdasarkan desain.

9. (★★) Mekanisme intervensi human-in-the-loop mengharuskan Agent untuk "menyerahkan kendali secara anggun." Namun, dalam praktiknya, pengguna mungkin sedang offline, merespons lambat, atau memberikan instruksi yang tidak jelas. Apa yang harus dilakukan Agent dalam kasus seperti itu?

Fail-safe: jeda operasi berisiko tinggi ketika tidak ada konfirmasi yang tiba daripada mengeksekusinya secara default; lakukan bagian berisiko rendah yang dapat dibalik terlebih dahulu dan dokumentasikan bagian berisiko tinggi sehingga manusia dapat memutuskan dan Agent dapat melanjutkannya; beri tahu melalui tools komunikasi asinkron (pesan, email) dengan kebijakan waktu habis (timeout); gunakan klarifikasi niat saat instruksi tidak jelas.

10. (★★★) Pendahuluan menyatakan bahwa "prinsip desain yang baik harus melampaui siklus iterasi model," tetapi metode rekayasa konkret untuk menerapkan prinsip tersebut dapat menjadi usang seiring meningkatnya kemampuan model. Berikan satu contoh metode rekayasa Agent semacam itu dan jelaskan alasannya.

Contoh 1: menggunakan constrained sampling untuk memaksa panggilan tool mengikuti format yang ketat. Ini adalah tambalan keandalan bagi model yang sering menghasilkan JSON tidak valid atau menghilangkan parameter. Manfaatnya dapat berkurang ketika kemampuan model mengikuti format meningkat, meskipun skenario berisiko tinggi tetap harus mempertahankan validasi format yang deterministik.

Contoh 2: memperkenalkan knowledge base eksternal untuk menutupi ketidakmampuan model menyerap pengetahuan baru secara berkelanjutan. Jika model kelak memiliki kemampuan continual learning yang andal, sebagian pemeliharaan pengetahuan dapat berpindah dari sistem eksternal ke parameter model. Namun, knowledge base eksternal tetap bernilai untuk pembaruan waktu nyata, retrieval yang presisi, kontrol akses, dan pelacakan sumber; cakupan penggunaannya lebih mungkin menyusut daripada hilang sepenuhnya.

Contoh 3: mewajibkan semua kemampuan diekspos melalui antarmuka tool calling standar milik API model dan melarang format panggilan khusus. Skills menunjukkan jalur lain: menjelaskan kemampuan dan prosedur penggunaannya dalam teks, lalu membiarkan model menjalankannya melalui tool command-line serbaguna. Dari sudut pandang model, ini sama dengan memahami dan mengikuti protokol panggilan tekstual khusus di atas executor umum. Ketika model semakin mampu memahami antarmuka arbitrer, "harus selalu menggunakan format tool calling standar" tidak lagi cocok sebagai prinsip universal. Format standar tetap berguna untuk interoperabilitas, validasi terstruktur, dan model yang kurang mampu, tetapi seharusnya menjadi pilihan rekayasa sesuai konteks.

Contoh 4: mewajibkan prompt dan seluruh definisi tool ditempatkan di awal context. Praktik ini muncul karena model awal memiliki kemampuan mengikuti instruksi yang terbatas dan sering gagal mengenali atau menjalankan prompt serta definisi tool di luar posisi tetap yang familier. Skills memuat prompt ke tengah context sesuai kebutuhan, sedangkan dynamic tool discovery menambahkan definisi tool yang baru ditemukan setelah trajectory yang sudah ada. Seiring meningkatnya kemampuan mengikuti instruksi dan adanya post-training khusus untuk pola pemuatan dinamis ini, prompt dan definisi tool tidak lagi harus tetap berada di awal context.

Bab 2: Rekayasa Konteks

1. (★★★) Eksperimen 2-3 menemukan bahwa jendela geser dari riwayat percakapan menyebabkan Agent berulang kali mengeksekusi panggilan tool yang sama. Namun, mempertahankan riwayat penuh menyebabkan konteks meluas tanpa batas. Rancang strategi yang dapat menghindari hilangnya informasi sekaligus mengendalikan panjang konteks, tanpa memecahkan awalan KV Cache.

① Ganti pembuangan dengan kompresi: pesan hanya ditambahkan, tidak pernah dihapus atau diedit; saat mendekati ambang batas (misalnya, 80% dari jendela), kompres secara batch hasil tool lama. ② Mekanisme berlapis: simpan output besar ke disk dengan mempertahankan ringkasan, hapus kebisingan (noise) secara langsung, dan simpan ringkasan arsip yang mempertahankan utas (thread). ③ Isolasi sub-agent, sehingga status sementara tidak pernah masuk ke konteks utama.

2. (★★) Mekanisme retensi Chain of Thought dari Chat Template Qwen3 hanya mempertahankan konten penalaran "setelah pesan pengguna nyata terakhir." Jika loop ReAct mencakup ratusan panggilan tool, konten penalaran yang terakumulasi dapat menghabiskan sejumlah besar konteks. Bagaimana Anda akan memodifikasi mekanisme ini untuk menangani loop yang sangat panjang? DeepSeek R1 pernah mewajibkan penghapusan semua konten penalaran historis, sementara DeepSeek V4 membalikkan hal ini dengan mewajibkan penyertaan kembali semua reasoning_content—membandingkan kedua strategi yang berlawanan ini, apa pro dan kontra dari masing-masing? Apa yang ditunjukkan oleh pembalikan ini?

Arah modifikasi: retensi jendela geser—simpan putaran penalaran terbaru secara penuh; di luar jendela, picu kompresi bergulir berdasarkan anggaran token (daripada jumlah putaran tetap), yang menghasilkan bilah status terstruktur (tujuan saat ini, fakta yang dikonfirmasi, jalur yang dikesampingkan, tugas yang harus dilakukan). Kompresi hanya terjadi sekali dan pada posisi tetap, sehingga biaya pembangunan ulang cache dibayarkan sekali daripada setiap putaran. Pelucutan R1: menghemat token, menjaga awalan tetap stabil dan ramah cache, dan cocok dengan distribusi pelatihan (Chain of Thought historis tidak pernah muncul di input); tetapi setiap putaran bernalar dari awal, rencana jangka panjang hilang, dan kesalahan berulang. Kewajiban penyertaan kembali V4: pemikiran yang koheren dan kinerja yang lebih baik pada tugas agenik berjangka panjang; tetapi biaya token tinggi, pembengkakan awalan setiap putaran, dan tidak ada peralihan yang mulus dari mode tanpa pemikiran. Pembalikan ini menunjukkan: untuk dialog murni, penalaran adalah pemborosan; untuk skenario agenik, penalaran adalah status—dan praktik industri telah beralih ke yang terakhir.

3. (★★) Dalam eksperimen kompresi sadar konteks, mengompresi dari sekitar 148K karakter menjadi sekitar 2.000 karakter—apakah kompresi ekstrem ini berisiko "kehilangan informasi yang tidak dapat dipulihkan"? Bagaimana hal ini dapat diatasi?

Ya, ada risiko: kompresi adalah proyeksi lossy, dan jika pertanyaan jatuh pada dimensi yang tidak dipertahankan, itu akan rusak. Solusinya: "kompresi lossy + pengindeksan lossless"—setiap fakta membawa URL sumber untuk ketertelusuran; output mentah disimpan di disk dengan hanya pratinjau ringkasan di dalam konteks; prioritas retensi eksplisit—keputusan arsitektur, integritas semantik (waktu, nama perusahaan), status verifikasi, dan pengenal seperti UUID/hash dipertahankan kata demi kata; jendela adaptif menunda momen kompresi.

4. (★★) Agent Status Bar membuat status implisit menjadi eksplisit. Namun, jika bilah status itu sendiri berisi informasi yang salah (misalnya, bug di penghitung tool), Agent mungkin membuat keputusan berbahaya berdasarkan informasi yang salah. Bagaimana masalah "keandalan meta-informasi" ini dapat dimitigasi?

Model mempercayai bilah status hampir tanpa syarat, sehingga kesalahan menyebar apa adanya. Mitigasi: ① pertahankan dengan kode deterministik—jangan pernah biarkan LLM menghitung secara batch riwayat panjang (jika harus, ekstrak item demi item dan kumpulkan dalam kode); ② lacak akurasi bilah status sebagai metrik produksi kelas satu; ③ informasi hanya datang dari observasi dunia nyata yang andal, menjaga dari keracunan bilah status.

5. (★★) Eksperimen ablasi rekayasa prompt menunjukkan bahwa informasi yang tidak teratur menyebabkan tingkat keberhasilan turun lebih dari 30%. Namun, dalam pengembangan dunia nyata, System Prompt sering kali dipertahankan oleh banyak orang pada waktu yang berbeda. Praktik rekayasa apa yang akan Anda gunakan untuk mencegah System Prompt menjadi semakin tidak teratur seiring berjalannya waktu?

① Perlakukan prompt sebagai kode: kontrol versi dan tinjauan, dengan manajer produk yang menentukan aturan bisnis dan teknisi yang melakukan pengodean; ② gunakan tolak ukur bergaya Tau-Bench sebagai tes regresi, menjalankan ablasi sebelum dan sesudah perubahan untuk menemukan dampaknya; ③ tegakkan struktur: alur yang didorong oleh SOP daripada tumpukan aturan, dilapisi dengan XML/Markdown; ④ klasifikasikan dan beri nama fragmen sebagai "cacheable / cache-breaking," tempatkan konten dinamis setelah batas cache; ⑤ pisahkan konten yang membengkak ke dalam Agent Skills yang dimuat sesuai permintaan.

6. (★★★) Bab ini mengusulkan bahwa "In-Context Learning pada dasarnya adalah pengambilan (retrieval), bukan penalaran." Jika pernyataan ini benar, semua arah optimasi saat ini yang berdasarkan pada "menempatkan lebih banyak informasi ke dalam konteks" perlu dievaluasi kembali. Menurut Anda, bagaimana batasan ini harus diatasi?

Tambahkan lapisan distilasi ke "setengah mesin pencari" ini: ① distilasi konteks / bilah status—gunakan kode untuk menghitung kesimpulan sebelumnya demi pengambilan langsung; ② kompresi aktif, mengganti catatan mentah dengan pengetahuan terstruktur dengan kepadatan tinggi; ③ isolasi sub-agent, menjauhkan kebisingan dari konteks utama; ④ interaksi sebagai sumbu ketiga—instrumen eksternal mengamati dan menulis kembali informasi baru yang tidak dapat dipikirkan oleh model; ⑤ arah garis depan (frontier): "catatan" KV Cache yang dapat diedit dan disusun, serta konsolidasi memori lintas sesi.

7. (★★★) Pengungkapan progresif dari Agent Skills hanya memuat konten penuh saat Agent menilai hal itu diperlukan. Namun, penilaian ini sendiri bergantung pada kemampuan model—jika model tidak tahu apa yang tidak diketahuinya, ia tidak dapat dengan benar memicu pemuatan Agent Skills. Bagaimana masalah "metakognisi" ini dapat diselesaikan?

① Simpan metadata Agent Skills (nama, deskripsi) tetap berada di dalam konteks sehingga model selalu "tahu apa yang dimilikinya"; ② tulis deskripsi Agent Skills sebagai kondisi perutean daripada pengenalan fitur—"Gunakan saat / Jangan gunakan saat"—menghindari deskripsi yang tidak jelas.

8. (★★) Dalam mekanisme Agent Skills, setelah Agent memuat instruksi secara dinamis dari SKILL.md, dapatkah operasi selanjutnya mengikuti instruksi tersebut dengan andal? Apa perbedaan dukungan model untuk pola Agent Skills?

Itu tergantung pada bagaimana Agent Skills disuntikkan: menyuntikkannya ke dalam System Prompt memberikan kemampuan mengikuti instruksi yang terkuat tetapi merusak KV Cache; membacanya sebagai file biasa ke bagian tengah konteks dapat menghasilkan kemampuan mengikuti instruksi yang lebih buruk; menyuntikkannya di akhir konteks memberikan kemampuan mengikuti instruksi yang baik, tetapi KV untuk bagian Agent Skills harus dihitung ulang pada setiap panggilan tool, dan hal ini memakan biaya mahal.

9. (★★★) Bab ini menekankan bahwa perubahan pada informasi dinamis (misalnya, stempel waktu sistem, urutan daftar tool) dapat merusak hit awalan KV Cache. Dalam sistem produksi dengan sejumlah besar tools dan kumpulan tool yang sering berubah, bagaimana Anda akan merancang tata letak konteks untuk memaksimalkan tingkat hit cache?

① Sekumpulan kecil tools inti yang stabil (katakanlah, tujuh) ditambah eksekutor generik, dengan kemampuan spesifik disampaikan melalui pengungkapan progresif dari Agent Skills; definisi tool dibekukan pada awalan statis dalam urutan yang tetap; ② sub-agents menjaga awalan yang sama dengan parent Agent.

Bab 3: User Memory dan Knowledge Base

1. (★★) Dalam sistem User Memory, ketika pengguna yang sama memberikan informasi yang bertentangan dalam sesi yang berbeda (misalnya, menyebutkan dua alamat rumah yang berbeda), bagaimana seharusnya sistem memori menangani konflik ini?

Gunakan pipeline "ekstrak–bandingkan–putuskan" bergaya Mem0: pertama ambil memori lama yang serupa menggunakan pencarian vektor, lalu minta LLM memutuskan ADD/UPDATE/DELETE/NOOP—misalnya, "pindah ke Shanghai" harus di-UPDATE dan menimpa "tinggal di Beijing." Versi: simpan hanya versi terbaru dari informasi tipe alamat beserta stempel waktunya, tetapi simpan riwayat lengkap dari informasi tipe pengalaman kerja. Di sisi pengambilan, awalan kontekstual (orang, waktu, niat—seperti dalam kasus transfer kawat yang dimodifikasi tiga kali) dapat membantu menilai entri mana yang pada akhirnya valid.

2. (★★) Pengambilan Kontekstual (Contextual Retrieval) menambahkan konteks dari dokumen asli ke setiap chunk. Namun, jika dokumen asli itu sendiri berantakan secara struktural atau mengandung informasi yang bertentangan, metode ini dapat menyebarkan atau bahkan memperkuat kesalahan. Bagaimana Anda akan memperkenalkan sinyal "kualitas informasi" pada fase pengambilan?

Pinjam dari "kesegaran dan tata kelola Knowledge Base": lampirkan metadata seperti nomor versi, waktu efektif/kedaluwarsa, dan sumber ke chunk; saring konten yang kedaluwarsa saat waktu pengambilan, atau tandai secara eksplisit di awalan "entri ini dicabut pada tanggal sekian-sekian"; di tahap perankingan ulang (reranking), gabungkan otoritas sumber dan kesegaran temporal ke dalam skor daripada hanya melihat relevansi semantik; selama pengindeksan, minta LLM penghasil awalan juga mendeteksi dan menandai kontradiksi antar-chunk, mirip dengan deteksi konflik versi di dalam memori.

3. (★★★) Agentic RAG memungkinkan Agent untuk secara aktif memutuskan kapan harus mencari, apa yang harus dicari, dan apakah harus melanjutkan pencarian. Tetapi jika model tidak tahu apa yang tidak diketahuinya, model tidak dapat dengan benar memicu pencarian. Bagaimana masalah "metakognisi" ini dapat diselesaikan?

① Tulis secara permanen (hard-code) "evaluasi apakah informasi sudah cukup" sebagai langkah eksplisit dalam prompt/Agent Skills: seperti dalam Eksperimen 3-9, pertama-tama ambil sub-pertanyaan secara paralel, temukan mata rantai yang hilang—"bagaimana catatan sebelumnya memengaruhi hukuman untuk kejahatan kelalaian"—lalu jalankan putaran pengambilan kedua; ② simpan meta-informasi ringan tetap berada di dalam konteks untuk memberikan pandangan global—misalnya, ikhtisar JSON Cards atau ringkasan L0/L1 OpenViking—sehingga Agent tahu "apa yang ada di dalam penyimpanan."

4. (★★) Ekstraksi informasi multimodal mengubah bagan menjadi deskripsi teks sebelum pengambilan. Proses "penerjemahan" ini dapat menghilangkan hubungan spasial dalam informasi visual. Berikan contoh spesifik dari informasi bagan yang tidak dapat disampaikan sepenuhnya oleh deskripsi teks murni, dan rancang skema untuk mempertahankan informasi tersebut.

Contoh: hubungan logis dalam diagram arsitektur sistem, posisi titik potong dua kurva dalam grafik garis, atau korespondensi baris-kolom antara sel dan header dalam tabel PDF. Opsi satu: pemrosesan multimodal asli; opsi dua: sediakan alat analisis gambar multimodal.

5. (★★★) "Bitter Lesson" dari Rich Sutton berpendapat bahwa metode umum (pencarian dan pembelajaran) pada akhirnya akan mengungguli fitur buatan tangan (hand-crafted features). Apakah seluruh sistem pengetahuan yang dibangun dalam bab ini (strategi chunking, struktur indeks, pipeline retrieval) itu sendiri merupakan bentuk "desain buatan tangan"? Jika kemampuan model menjadi cukup kuat, dapatkah desain ini digantikan dengan sekadar "memasukkan semuanya"?

Ini memang desain buatan tangan, dan beberapa tahapan (chunking, fusion tuning) mungkin melemah seiring bertambah panjangnya konteks; tetapi kasus kucing hitam/kucing putih menunjukkan bahwa "memasukkan semuanya" juga tidak cukup: attention adalah soft retrieval, dan agregasi lintas dokumen serta statistik masih membutuhkan pra-distilasi pada saat pengindeksan (indexing); kendala rekayasa seperti kedaluwarsa dan pembaruan pengetahuan, isolasi izin/tenant, auditabilitas, dan biaya tidak bergantung pada kemampuan model; dan retrieval ditambah distilasi LLM pada saat pengindeksan itu sendiri adalah metode umum "pencarian + pembelajaran" (search + learning), tidak bertentangan dengan Bitter Lesson.

6. (★★★) Seiring dengan meningkatnya kemampuan model, apakah menurut Anda basis pengetahuan (knowledge base) spesifik domain masih akan penting? Mungkinkah foundation model yang kuat di masa depan berpotensi berisi semua informasi dalam basis pengetahuan domain, sehingga menghilangkan kebutuhan akan basis pengetahuan tersebut?

Masih penting: data pelatihan memiliki batas waktu (cutoff date), sedangkan basis pengetahuan dapat diperbarui kapan saja; proses internal perusahaan, hukum kasus pribadi, dan sejenisnya sama sekali tidak ada dalam korpus publik; berbagi multi-pengguna memerlukan penyaringan izin dan isolasi tenant, dan pengetahuan dalam parameter tidak dapat disesuaikan per pemanggil; penyimpanan eksternal dapat diaudit, dapat dikontrol versinya, dan dapat menghapus konten yang kedaluwarsa (offline)—memori parametrik (parametric memory) hampir tidak dapat melakukan ini; bahkan di sepanjang rute parametrik (pasca-pelatihan / User as Engram), Anda menghadapi masalah bahwa "mengingat itu mudah, tetapi menggunakan fakta-fakta untuk penalaran multi-hop itu sulit."

7. (★) RAPTOR membangun indeks pohon melalui peringkasan hierarkis bottom-up, sementara GraphRAG membangun indeks terstruktur graf melalui hubungan entitas. Jenis kueri apa yang masing-masing cocok untuk dijawab oleh kedua indeks terstruktur ini?

RAPTOR: kueri "penjelajahan lintas lapisan" (cross-layer traversal) yang menelusuri dari konsep makro ke detail—seperti pertama-tama menemukan ringkasan "set instruksi SIMD" lalu menelusuri detail SSE—mencakup baik gambaran umum maupun granularitas detail. GraphRAG: penalaran relasional multi-hop ("alamat rumah sakit tempat dokter saya bekerja," melintasi rantai relasi) dan disambiguasi entitas (dua "Dr. Zhang" adalah node yang berbeda)—kueri "apa hubungan antara A dan B"; ringkasan komunitas juga menyediakan klastering tematik.

8. (★★) Paradigma sistem file (filesystem) mengatur pengetahuan ke dalam struktur hierarkis yang mirip dengan sistem file. Dibandingkan dengan RAG database vektor tradisional, dalam skenario apa pendekatan ini memiliki keuntungan?

Teks biasa dapat dibaca, diedit, dan dikoreksi secara langsung oleh pengguna, serta dikontrol versinya dan di-rollback dengan Git—cocok untuk skenario di mana manusia dan mesin bersama-sama memelihara dan meninjau pengetahuan; dengan kemampuan write_file, Agent dapat secara otonom merekam pengalaman, membentuk siklus memori yang berevolusi sendiri (externalized learning); penyingkapan progresif (progressive disclosure) L0/L1/L2 memungkinkan sebagian besar kueri diputuskan di L1, menghemat token; prasyaratnya adalah membangun tautan silang dan halaman indeks seperti Wikipedia—jika tidak, semakin banyak file yang terisolasi, semakin sulit retrieval-nya.

9. (★★★) Secara otomatis menemukan "faktor putusan" dan "hierarki pentingnya faktor" dari data terstruktur (misalnya, database putusan pengadilan) pada dasarnya melibatkan Agent dalam menginduksi aturan dari data. Dapatkah ekstraksi pengetahuan yang digerakkan oleh data ini mencapai kualitas aturan yang dibuat secara manual oleh pakar manusia?

Keuntungan: seperti dalam eksperimen CAIL2018, penemuan faktor "bottom-up" sesuai dengan data daripada asumsi awal manusia (human priors), dapat menangkap trade-offs implisit yang tersebar di puluhan ribu putusan yang sulit ditulis secara eksplisit oleh para ahli, dan dapat dikuantifikasi. Keterbatasan: kesalahan ekstraksi LLM menyebabkan polusi pengetahuan; bias dalam data itu sendiri diwariskan; prototipe klastering hanya mencerminkan korelasi dan tidak dapat menjelaskan kausalitas. Kompromi: pemodelan yang digerakkan oleh data ditambah ulasan pakar pada skema dan hasil—model mendorong pertanyaannya, statistik mendukung penjelasannya.

Bab 4: Alat

1. (★★) Standar MCP memisahkan definisi tool dari framework Agent. Namun, standardisasi juga berarti bahwa pola interaksi tool yang kompleks (misalnya, output streaming, komunikasi dua arah, sesi stateful) mungkin sulit diekspresikan dalam protokol standar. Menurut Anda, kemampuan apa yang paling perlu diperluas oleh MCP di masa mendatang?

Perluasan yang paling dibutuhkan adalah kemampuan berbasis peristiwa lintas sesi. MCP sudah mendukung interaksi multi-putaran, langganan perubahan, dan tugas yang berjalan lama, tetapi intinya tetap menstandarkan pemanggilan kemampuan, bukan menjaga Agent terus aktif. Membangunkan Agent ketika ada email baru atau callback eksternal, serta mengantrekan, melanjutkan, dan mencoba ulang berbagai peristiwa, masih menjadi tugas kerangka kerja Agent. Konvensi yang lebih seragam untuk orkestrasi ini akan memperluas cakupan MCP tanpa mengorbankan kesederhanaan protokol.

2. (★★) Dalam arsitektur Agent asinkron, strategi prioritas untuk antrean peristiwa (event queue) harus ditentukan pada saat desain. Tetapi jika penilaian prioritas itu sendiri memerlukan pemahaman semantik (misalnya, menentukan apakah pesan baru lebih mendesak daripada tugas saat ini), siapa yang harus membuat penilaian ini—mesin aturan (rules engine) atau panggilan LLM lainnya? Apa saja biaya dari masing-masing pilihan?

Hibrida berlapis: event dengan tipe yang jelas di-hardcode dengan aturan—latensi nol dan determinisme yang kuat, tetapi tidak dapat memahami perbedaan semantik antara "berhenti sekarang juga" dan "bagaimana cuaca hari ini"; event yang ambigu secara semantik masuk ke LLM klasifikasi yang ringan yang bertindak sebagai perute event (event router), dengan biaya latensi ratusan milidetik, biaya tambahan, dan kemungkinan salah penilaian—dan seperti Sidecar, LLM tersebut hanya boleh membaca field terstruktur untuk menjaga dari prompt injection.

3. (★★) Dalam ekosistem MCP, server MCP yang berbeda mungkin menyediakan tool dengan fungsionalitas yang sangat tumpang tindih. Saat Agent menghadapi beberapa tool dari sumber berbeda yang secara fungsional serupa, bagaimana ia harus memilih? Jika tool dengan nama yang sama dari sumber yang berbeda berperilaku sedikit berbeda (misalnya, satu mengembalikan ringkasan, yang lain mengembalikan teks lengkap), dapatkah Agent merasakan dan memanfaatkan perbedaan ini?

Kriteria pemilihan: sebelum integrasi, tinjau deskripsi, sematkan (pin) versi, dan konfigurasikan least-privilege credentials (least-privilege credentials); waspadai penyamaran (shadowing) tool dengan nama yang sama yang merutekan panggilan sensitif ke pihak yang jahat; pada saat runtime, persempit kandidat melalui klasifikasi hierarkis dan penemuan dinamis (dynamic discovery). Apakah model dapat merasakan perbedaan perilaku bergantung pada kualitas deskripsi tool.

4. (★★★) Ketika sebuah Agent berinteraksi dengan dunia luar atas nama pengguna, pada dasarnya ia menghadapi pilihan identitas: menggunakan identitas virtual independen (email dan nomor telepon khusus) untuk bertindak sebagai pihak ketiga, atau langsung mengoperasikan akun pribadi pengguna sebagai pengguna itu sendiri? Yang pertama memungkinkan operasi latar belakang yang otonom, tetapi pihak ketiga mungkin tidak mempercayai identitas non-manusia; yang kedua memiliki konteks dan izin yang lebih lengkap tetapi memperkenalkan masalah otorisasi, kepercayaan, dan batas keamanan. Dalam skenario apa menurut Anda masing-masing mode harus dipilih?

Secara default gunakan identitas virtual: ia dapat beroperasi secara otonom di latar belakang dan dapat diaudit, dan jika melakukan kesalahan atau disusupi, itu tidak mengekspos seluruh identitas digital pengguna—sama seperti sekretaris yang menggunakan email kantornya sendiri; Anda perlu menangani masalah reputasi CAPTCHA/IP (proxy perumahan). Skenario yang harus menggunakan identitas pengguna sendiri (verifikasi identitas akun, konfirmasi panggilan tiga arah—seperti saat Pine menelepon layanan pelanggan) menggunakan autentikasi human-in-the-loop: VNC/RDP memungkinkan pengguna masuk secara pribadi dan visual. Kriterianya: apakah pihak lawan mensyaratkan pemegang akun secara langsung, serta risiko operasi dan ruang lingkup kredensial.

5. (★★) Dalam pemrosesan event berbasis antrean, model cenderung hanya fokus pada event terakhir. Bab ini memitigasi hal tersebut melalui penanda bilah status Agent dan peringkasan. Tetapi jika antrean memiliki timbunan 20 event (10 hasil tool + 5 pesan pengguna + 5 peringatan sistem), bagaimana Anda mengatur urutan presentasi dan format event ini agar model tidak melewatkan informasi penting?

Pertama klasifikasi dan deduplikasi dengan aturan dan LLM yang ringan: event mendesak (peringatan, interupsi pengguna) melalui penanganan bergaya pembatalan secara terpisah dan tidak dicampur ke dalam batch. Untuk 10 hasil tool yang terlalu panjang, potong (truncate) dan pertahankan ke dalam file, hanya menyimpan bagian awal, akhir, dan jalurnya. Tambahkan daftar ringkasan ke bilah status sistem di bagian akhir konteks (jumlah dari setiap jenis event + persyaratan untuk merespons setiap item).

6. (★★) Bab ini mengusulkan loop "execute-validate-feedback" (misalnya, secara otomatis menjalankan linter setelah menulis kode). Pada skenario tool apa lagi pola "validasi otomatis pasca-operasi langsung" ini dapat diterapkan? Apakah ada operasi di mana biaya atau risiko dari validasi itu sendiri melebihi biaya atau risiko operasi, sehingga pola ini tidak layak (infeasible)?

Skenario yang dapat digeneralisasi: setelah mengubah konfigurasi, jalankan secara nyata di dalam sandbox untuk memverifikasi bahwa perubahan tersebut berlaku; setelah menghasilkan dokumen/presentasi, render ke dalam tangkapan layar (screenshots) dan gunakan kemampuan multimodal model untuk memeriksa tata letaknya. Tidak layak: operasi yang ireversibel dan non-idempoten seperti mengirim email, melakukan panggilan telepon, atau mentransfer uang—entah tidak ada yang dapat diamati, atau validasi itu sendiri memicu event dunia nyata lainnya; di sini Anda harus beralih ke cara ex ante: Pra-persetujuan Proposer-Reviewer.

7. (★★) Bab ini mengangkat masalah "ledakan tool" (tool explosion)—akurasi pemilihan Agent menurun saat menghadapi ribuan tool. Selain penemuan tool (tool discovery) secara proaktif, pendekatan apa lagi yang ada? Pertimbangkan untuk mengadopsi cara pakar manusia menangani koleksi alat yang sangat banyak.

① Pengelompokan hierarkis: temukan "server/aplikasi" terlebih dahulu, baru kemudian pilih tool spesifiknya; ② "Konsultasi sesuai permintaan" bergaya Skills: seperti mencari di buku referensi—katalog tetap berada di dalam konteks, detail dimuat sesuai permintaan; ③ beberapa tool dasar yang sering digunakan "disimpan dalam genggaman" tetap berada di dalam konteks, sisanya dapat dijangkau melalui indeks katalog.

Bab 5: Coding Agent dan Pembuatan Kode

1. (★★) Pembangkitan kode (code generation) disebut sebagai "kemampuan meta" dari Agent. Namun, eksekusi kode memperkenalkan risiko keamanan—kode yang dihasilkan Agent mungkin mengandung kerentanan, memasuki infinite loops, atau menghabiskan sumber daya. Sandboxing dapat memitigasi beberapa risiko ini, tetapi hal itu juga membatasi apa yang dapat dilakukan kode (misalnya, dengan menolak akses ke jaringan atau sistem file). Bagaimana kita dapat menemukan keseimbangan optimal antara keamanan dan kemampuan?

Terapkan isolasi sandbox secara berjenjang berdasarkan skenario (containers/microVMs); secara default tanpa jaringan, dengan proxy whitelist yang memberikan akses sesuai permintaan; mount kode sumber (source code) sebagai read-only dan jauhkan API keys dari sandbox; tetapkan batas sumber daya sandbox; kelola siklus hidup sandbox (timeouts).

2. (★★★) Bootstrapping Agent—sebuah Agent yang dapat membuat Agent—mencapai "replikasi mandiri dari kecerdasan." Tetapi setiap iterasi bootstrapping dapat memperkenalkan bias atau kesalahan baru. Akankah kesalahan ini terakumulasi lintas generasi? Bagaimana kita dapat mencegah Agent hasil bootstrap ini dari penurunan kualitas?

Jika setiap generasi terus mereproduksi di atas artifak generasi sebelumnya, beberapa cacat mungkin terakumulasi. Kuncinya adalah memiliki tugas-tugas yang dapat diverifikasi dan cukup menantang—misalnya, tugas pemrograman yang cukup sulit.

3. (★★) Ketika Agent code generation menangani penguraian log, Agent dapat secara otomatis mengikuti evolusi format. Tetapi jika perubahan format tersebut adalah bug dan bukan modifikasi yang disengaja, adaptabilitas Agent justru menutupi masalah tersebut. Bagaimana seharusnya Agent membedakan antara "perubahan yang perlu adaptasi" dan "anomali yang perlu dilaporkan"?

Lakukan diagnosis sebelum beradaptasi: periksa format baru terhadap dokumen arsitektur dan PRD untuk menilai apakah itu sesuai harapan (gagasan dari Eksperimen 5-8); periksa catatan version-control untuk mengonfirmasi bahwa perubahan tersebut sesuai dengan komit kode yang sah alih-alih pergeseran (drift) tanpa sumber; analog dengan log_mismatch pada τ-bench, bahkan ketika Anda memilih untuk beradaptasi, catatlah sebuah peringatan dan secara otomatis laporkan issue (file an issue) daripada mentolerirnya secara diam-diam; ketika tidak yakin, rutekan ke konfirmasi human-in-the-loop. Prinsipnya: beradaptasi dan melaporkan secara paralel—adaptasi tidak boleh menelan sinyal anomali.

4. (★★) Bab ini berulang kali menggunakan mekanisme Proposer-Reviewer dalam pembuatan PPT, pengeditan video, dan visualisasi log. Jika preferensi estetika Reviewer berbeda dari pengguna target—misalnya, Reviewer menganggap kepadatan informasi masuk akal, tetapi pengguna merasa terlalu sesak—loop umpan balik mungkin berkumpul pada titik optimum lokal (local optimum) yang salah. Bagaimana umpan balik preferensi pengguna dapat dimasukkan ke dalam loop Reviewer?

Suntikkan (inject) umpan balik pengguna ke dalam trajektori Agent sebagai event terstruktur berprioritas tertinggi; eksternalisasi dan konsolidasikan preferensi pengguna dengan menuliskannya ke MEMORY.md sehingga preferensi berlaku lintas tugas; berikan dokumen dalam format HTML alih-alih Markdown sehingga pengguna dapat memeriksanya.

5. (★★) Bab ini mendemonstrasikan beberapa cara untuk sebuah Coding Agent mengonsolidasikan pengalaman yang diperoleh melalui eksekusi dan debugging kembali ke dalam basis kode (codebase)—menulis file basis pengetahuan, memperbarui dokumentasi arsitektur, memelihara file instruksi proyek, dan mengodekan urutan operasional sebagai kode. Jika pengalaman ini disuling lebih lanjut menjadi aturan (rules) dalam system prompt, kumpulan aturan akan terus meluas seiring waktu. Bagaimana “pengumpulan sampah” (garbage collection) dapat dilakukan pada aturan yang terkumpul untuk mengidentifikasi dan menghapus entri yang redundan atau sudah usang? Mengapa modifikasi kode tunggal yang berhasil belum menjadi evolusi berkelanjutan dalam arti Bab 8?

Pendekatan GC (garbage collection): pindahkan aturan yang dapat dikodekan dalam linter, CI, atau validasi tool ke luar dari prompt; lacak tingkat kecocokan (hit rates) aturan dan konfliknya lalu validasi ulang secara berkala terhadap codebase; gunakan Markdown dan Git untuk mempertahankan asal-usul (provenance), versi, dan kemampuan rollback. Patch yang berhasil hanya menunjukkan bahwa patch tersebut memecahkan kasus saat ini. Evolusi berkelanjutan lebih jauh menuntut agar modifikasi tersebut muncul dari bukti operasional yang dapat dilacak, meningkatkan tugas-tugas berikutnya, dan lulus pengujian regresi pada tugas-tugas lama serta validasi keamanan.

6. (★) "Tim yang ramah terhadap kerja remote (remote work) seringkali juga ramah terhadap AI Agent." Seberapa dekat tim atau organisasi Anda menjadi "siap AI" dalam hal dokumentasi pengetahuan? Apa hambatan terbesarnya?

Terbuka. Anda dapat memeriksa diri sendiri dengan metrik proksi (proxy metric) dari bab ini: dapatkah pendatang baru jarak jauh bekerja secara mandiri hanya dengan menggunakan repositori dan dokumentasi? Daftar periksa: apakah keputusan dicatat dalam dokumen; apakah konteks ditulis ke dalam issues/PR; apakah perintah build dan pengujian memiliki file instruksi seperti CLAUDE.md/AGENTS.md; apakah pengetahuan tribal telah disuling ke dalam panduan pengembang. Hambatan terbesar yang paling umum: transmisi lisan dan budaya papan tulis yang bergantung pada "bertanya kepada kolega di sebelah Anda"—sebuah Agent tidak dapat membaca kesepakatan lisan, hanya dokumen.

7. (★★★) Simon Willison mengusulkan "Lethal Triad" (Triad Mematikan) untuk Agent (akses ke data pribadi, paparan konten yang tidak tepercaya, dan kemampuan komunikasi eksternal). Bab ini menambahkan yang keempat: memori persisten. Dalam lingkungan produksi yang perlu menangani keempat elemen secara bersamaan, bagaimana Anda mendesain strategi keamanan?

Lapiskan pertahanan di sepanjang empat jenis batasan (boundaries). Batasan data: tidak ada kredensial yang di-mount, kode sumber read-only, visibilitas minimal. Batasan kepercayaan input (input trust boundary): pelabelan asal-usul (provenance labeling), dengan konten eksternal diturunkan versinya menjadi data yang "untuk referensi, tidak membawa kekuatan instruksi" (kode etik loyalitas). Batasan dampak output: secara default tanpa jaringan (no-network) dengan egress yang masuk whitelist, pemisahan perintah semantik (semantic parsing) daripada blacklist, ulasan Sidecar independen ditambah human-in-the-loop—operasi kritis harus ditinjau oleh mekanisme di luar konteks. Batasan lintas sesi: penulisan ke MEMORY.md menjalani tinjauan kepercayaan yang sama dengan konten eksternal. Tujuannya: bahkan jika disuntikkan, serangan tidak dapat dieksekusi.

8. (★★) Pola Artifact memungkinkan SQL atau kode frontend yang dihasilkan oleh Agent untuk dieksekusi secara langsung di browser atau database pengguna. Namun, SQL yang dihasilkan mungkin mengeksekusi operasi yang merusak, dan HTML yang dihasilkan mungkin mengandung kerentanan. Bagaimana keamanan sistem dapat dipastikan?

SQL: jalankan kueri dengan akun read-only berhak istimewa paling kecil (least-privilege read-only account), dan tambahkan batas sumber daya pada CPU, memori, dll. untuk mencegah kehabisan sumber daya (resource exhaustion). HTML/UI: lebih suka protokol deklaratif seperti A2UI, di mana Agent hanya menghasilkan JSON deskripsi antarmuka dan klien me-render-nya dari katalog komponen tepercaya tanpa mengeksekusi kode arbitrary. Jika HTML arbitrary diperlukan, HTML tersebut harus ditampilkan dalam lingkungan sandbox untuk mencegah injeksi (injection).

9. (★★) Mengodekan aturan bisnis sebagai validasi terhadap data dasar (ground truth) database, sekaligus mendesain parameter tool untuk mendorong (prompt) model memeriksa kondisi kebijakan sebelum membuat panggilan (call), menggunakan struktur kode untuk membatasi perilaku Agent. Apa keuntungan dan keterbatasan dari pola "code as rules" ini dibandingkan dengan aturan yang diekspresikan dalam bahasa alami?

Keuntungan: tidak ambigu, deterministik, dan bagus pada kombinasi kondisi yang kompleks; fakta kebijakan (policy facts) berasal dari ground truth database dan jam sisi server (server-side clock) daripada nilai yang dilaporkan sendiri oleh model, sehingga baik halusinasi maupun prompt injection tidak dapat melewatinya—garis pertahanan terakhir melawan operasi ireversibel; parameter expected_* merangkap sebagai daftar periksa (checklist) wajib yang memandu pemikiran. Keterbatasan: kode tidak menjelaskan kebijakan kepada pengguna, tidak menemukan cara memutar (workarounds), dan membawa biaya pemeliharaan. Kesimpulan: melengkapi aturan bahasa alami, bukan pengganti.

10. (★★) Pola Artifact memungkinkan Agent untuk menghasilkan SQL atau kode visualisasi untuk komponen hilir agar dieksekusi secara langsung, sehingga LLM tidak perlu memproses volume data yang besar. Apa pro dan kontra dari pembagian kerja "Agent generates code, system executes code" (Agent menghasilkan kode, sistem mengeksekusi kode) dibandingkan dengan pola tradisional "Agent directly provides the answer" (Agent langsung memberikan jawaban)?

Pro: data mengalir dari database langsung ke frontend, melewati LLM "perantara"—cepat, hemat token, dan bebas dari kesalahan halusinasi saat mentranskripsikan sejumlah besar data, sehingga cocok untuk menyajikan volume data yang besar; kode tersebut dapat diaudit, dapat digunakan kembali, dan dapat disusun menjadi pipeline (hasil SQL diumpankan langsung ke kode visualisasi). Kontra: LLM tidak pernah melihat hasil kueri, sehingga ia tidak dapat melakukan peringkasan dan pengambilan keputusan lebih lanjut berdasarkan konten data—tidak cocok untuk tugas yang membutuhkan model untuk mencerna data sebelum bernalar.

Bab 6: Evaluasi Agent

1. (★★) LLM-as-a-Judge menggunakan language model untuk mengevaluasi output dari language model. Apakah "evaluasi mandiri" (self-evaluation) ini memiliki titik buta sistematis—misalnya, model mungkin secara konsisten memberikan skor tinggi pada gaya respons tertentu, preferensi yang tidak konsisten dengan penilaian manusia? Bagaimana bias semacam itu dapat dideteksi dan dikoreksi?

Ya: bias panjang (length bias), bias gaya respons (response-style bias), dan model dari keluarga yang sama yang dicurangi (Goodhart's law). Deteksi: bangun set standar emas manusia dari 100–200 contoh dan ukur kappa Cohen antara hakim (judge) dan manusia; audit korelasi antara skor dan panjang respons secara berkala; miliki tim merah (red team) untuk membangun kasus adversarial. Koreksi: buat rubrik yang secara eksplisit menghukum verbositas (verbosity) dan membatasi panjangnya; gunakan hakim (judges) heterogen dari keluarga model yang berbeda.

2. (★★★) Desain dataset evaluasi yang "bebas kebocoran" sangatlah penting. Namun, dalam ekosistem open-source, setelah data benchmark dipublikasikan, data tersebut dengan cepat dimasukkan ke dalam data pelatihan. Apakah "permainan kucing dan tikus" ini memiliki akhir? Rancang metode evaluasi yang secara mendasar tahan terhadap kebocoran data.

Bank soal statis tidak memiliki akhir—Anda hanya bisa mengejarnya. Jalan keluar mendasarnya adalah mempublikasikan "mekanisme pembuatan" sementara menjaga "instans konkret" tetap privat: templat berparameter seperti milik τ²-bench dan AndroidWorld, yang diinstansiasi secara acak setiap saat, dengan verifikasi berdasarkan keadaan lingkungan akhir daripada urutan jawaban tetap.

3. (★★) Empat kriteria Scale AI (panduan ahli, cakupan komprehensif, pembobotan tingkat kepentingan standar, evaluasi mandiri) bertujuan untuk menghilangkan subjektivitas dalam evaluasi. Namun, dimensi tugas tertentu (misalnya, "Apakah jawabannya membantu?" "Apakah nadanya sesuai?") pada dasarnya bersifat subjektif. Bagaimana Rubrik yang andal dapat dirancang untuk dimensi subjektif ini?

Terjemahkan kriteria abstrak menjadi perilaku yang dapat diverifikasi. Berikan contoh konkret dan kasus batas untuk setiap nilai; rubrik adalah produk iteratif—kumpulkan ketidaksepakatan penilai selama percobaan penggunaan dan secara bertahap kembangkan menjadi sebuah buku kasus. Lengkapi dengan pembobotan multi-juri/pemeriksaan konsistensi, kirim kasus ketidaksepakatan untuk ditinjau oleh manusia, dan kalibrasi tingkat kesepakatan pada set standar emas.

4. (★★) τ-bench mengevaluasi Agent dengan mensimulasikan perilaku pengguna nyata. Tetapi pengguna yang disimulasikan itu sendiri adalah sebuah LLM—ia mungkin secara sistematis meremehkan kasus-kasus batas tertentu (misalnya, pengguna yang gelisah secara emosional atau tidak jelas). Bagaimana kualitas dari pengguna yang disimulasikan itu sendiri dapat divalidasi?

Pelajaran dari versi pertama τ-bench: simulatornya terlalu mekanis dan instruksinya terlalu sederhana (Agent dapat menebak jawabannya). Metode validasi: periksa acak dialog yang disimulasikan secara manual untuk memeriksa apakah mereka mengikuti pengungkapan progresif dan tidak mengarang informasi di luar skrip; jalankan pengujian sampel kecil dengan pengguna nyata untuk melihat apakah peringkatnya cocok dengan evaluasi yang disimulasikan.

5. (★★) Perbandingan berpasangan (model Bradley-Terry) mengasumsikan bahwa preferensi bersifat transitif (jika A > B dan B > C, maka A > C). Namun, preferensi manusia sering kali melanggar transitivitas. Dalam evaluasi Agent, pada skenario apa preferensi non-transitif mungkin muncul? Bagaimana hal ini memengaruhi keandalan peringkat?

Skenario: pertukaran multi-dimensi (A akurat tetapi lambat, B cepat tetapi singkat, C menyeluruh tetapi mahal), di mana juri/tugas yang berbeda membobotkan dimensi secara berbeda. Peringkat Chatbot Arena secara inheren bergantung pada distribusi prompt pengguna. Dampak: BT mengompresi kekuatan menjadi satu skor, sehingga di bawah non-transitivitas peringkat menjadi tidak stabil dan bergeser sesuai dengan distribusi kecocokan. Mitigasi: peringkat secara terpisah berdasarkan dimensi kemampuan dan laporkan matriks tingkat kemenangan berpasangan.

6. (★★) Bab ini mengusulkan metode ilmiah "Amati → Hipotesis → Eksperimen → Validasi." Namun, dalam praktiknya, ruang perilaku Agent sangat luas, dan memvalidasi satu hipotesis mungkin memerlukan ratusan kali evaluasi. Bagaimana informasi yang diperoleh dari evaluasi dapat dimaksimalkan dengan anggaran komputasi yang terbatas?

Kelompokkan kegagalan terlebih dahulu dan batasi pilot pada tugas yang paling bernilai diagnostik. Gunakan eksperimen berpasangan murah dengan satu variabel, lalu perlakukan sampel kecil sebagai gerbang ke pengujian besar, bukan bukti deployment. Secara statistik, gunakan standard error sebagai saringan konservatif dan McNemar atau analisis berpasangan lain pada tugas yang sama; bila efek yang diharapkan lebih kecil dari noise, perluas set evaluasi. Jika beberapa kandidat diuji paralel, koreksi multiple comparisons dan konfirmasi hasil positif secara independen.

7. (★) Dalam pilot AndroidWorld, pohon elemen lengkap menaikkan keberhasilan dari 25% ke 100%, tetapi penggunaan token menjadi 2.498× control; setelah diringkas, keberhasilan tetap 100% dan token turun menjadi 0.506×. Bagaimana merancang aturan pemangkasan otomatis yang membuang node UI tanpa makna tanpa menghilangkan informasi untuk aksesibilitas, verifikasi keadaan, atau tindakan berikutnya?

Gunakan aturan bertingkat “hapus secara default, pertahankan bila ada alasan”. Simpan node yang terlihat, memiliki teks, dapat dioperasikan, difokuskan, atau digulir, maupun memiliki nilai keadaan atau label aksesibilitas. Simpan pula jalur ancestor terpendek dan label tetangga yang diperlukan untuk menafsirkannya. Buang container tata letak dan ringkas subtree berulang. Sebelum dan sesudah pemangkasan, pastikan ID yang dapat ditindaklanjuti, keadaan, dan nilai tetap sama, dengan screenshot sebagai fallback visual. Putar ulang aturan pada jejak gagal lalu uji pada aplikasi yang tidak dipakai untuk tuning. Keberhasilan, token, dan latensi menjadi guardrail bersama; regresi aksesibilitas harus memblokir rilis.

8. (★★) Simulasi pengguna dari τ-bench menggunakan "pengungkapan informasi progresif"—tidak memberikan semua informasi sekaligus, tetapi mengungkapkannya secara bertahap berdasarkan pertanyaan dari Agent. Bagaimana desain ini memengaruhi hasil evaluasi? Jika strategi pengungkapan informasi dari pengguna yang disimulasikan berbeda secara signifikan dari pengguna nyata, apakah kesimpulan evaluasinya masih dapat diandalkan?

Dampak: jika strategi pengungkapannya terdistorsi, Agent mungkin hanya belajar untuk "menyesuaikan dengan simulator" (Goodhart), dan skor absolut kehilangan nilai referensinya; peringkat relatif antar model mungkin masih bermakna. Perbaikan: kalibrasi simulator dengan dialog nyata, periksa acak secara manual, dan nyatakan secara eksplisit batas yang berlaku dari kesimpulan tersebut.

Bab 7: Model Post-Training

1. (★★) Catastrophic forgetting—di mana fine-tuning untuk tugas tertentu menghancurkan kemampuan umum asli dari model (misalnya, pemanggilan tool secara umum)—sangat merepotkan dalam skenario Agent. Dibandingkan dengan fine-tuning parameter penuh, LoRA membekukan bobot dasar dan membawa risiko lupa yang lebih rendah, tetapi ia tidak kebal. Strategi apa yang dapat lebih memitigasi kelupaan kemampuan selama fine-tuning?

Pencampuran data: campurkan sekitar 20% data umum/distribusi asli sehingga porsi tugas baru tidak menghancurkan kemampuan lama; volume pelatihan yang dibatasi: hentikan SFT setelah "formatnya stabil dan kemampuan dasarnya ada"—penghentian lebih awal mencegah kolaps; gunakan rank kecil (8–32) untuk RL dan pertahankan penalti KL untuk menjaga policy tetap berada di dekat model referensi; bekukan komponen kunci (misalnya, latih hanya lapisan proyeksi dari VLM); lampirkan beberapa LoRA adapter per tugas untuk mengisolasi kemampuan; jalankan uji regresi pada benchmark umum.

2. (★★) Post-training memadatkan kemampuan ke dalam bobot model ("memori otot"), sementara In-Context Learning menempatkan pengetahuan dalam input selama inferensi. Namun, beberapa kemampuan (misalnya, pengetahuan domain) dapat dipelajari baik melalui post-training atau disediakan melalui contoh few-shot. Kriteria apa yang akan Anda gunakan untuk memutuskan jalur mana yang harus diambil oleh kemampuan tertentu?

Pertama, tanyakan apakah kemampuan tersebut dapat diekspresikan secara memadai melalui simbol-simbol eksternal: fakta dan bukti termasuk dalam RAG, prinsip-prinsip yang dapat diekspresikan melalui bahasa ke dalam Prompts/Skills, serta prosedur deterministik dan batasan kaku ke dalam program. Kemampuan berdimensi tinggi seperti pemahaman citra medis, nada alami, dan policy implisit sering kali memerlukan pembaruan parameter bahkan ketika domainnya masih berubah. Kemudian pertimbangkan biaya pembaruan, volume panggilan, ketepatan waktu, dan risiko: gunakan konteks untuk validasi cepat selama eksplorasi, dan latih hanya setelah suatu pendekatan terbukti stabil, efektif, dan membutuhkan generalisasi yang luas. Namun aturan kaku (hard rules), seberapapun stabilnya, tidak boleh bergantung semata-mata pada memori parameter.

3. (★★) Distilasi model memungkinkan model kecil untuk mempelajari perilaku dari model besar. Berdasarkan tingkat kemampuannya, model yang didistilasi secara kasar dapat dibagi menjadi tiga tingkatan—Model Chat (dialog satu putaran, jawaban langsung), Model Reasoning (menghasilkan rantai pemikiran panjang sebelum menjawab), dan Model Agentic (pemanggilan tool multi-putaran, berinteraksi dengan lingkungan). Apa saja tantangan yang berbeda dalam mendistilasi ketiga jenis model ini? (Petunjuk: Mulailah dengan "apa sebenarnya yang didistilasi"—apakah itu gaya outputnya, jejak penalaran (reasoning trace) yang lengkap, atau strategi pengambilan keputusan untuk berinteraksi dengan lingkungan; token mana dalam jejak tersebut yang harus dipelajari dan mana yang merupakan kembalian lingkungan (environmental returns) yang tidak boleh dipelajari; dan seberapa lambat serta seberapa langka sinyal keberhasilan/kegagalan tersebut.)

Chat: hanya mempelajari pemetaan "input → output" dan gaya—SFT standar sudah cukup, ini yang paling sederhana. Reasoning: memerlukan jejak penalaran (reasoning traces) lengkap, sehingga Anda memerlukan model guru (teacher model) open-source; lintasan (trajectories) dengan jawaban yang salah harus disaring. Agentic: memerlukan lingkungan simulasi yang nyata; pembelajaran offline rentan terhadap ketidakcocokan antara learner dan sampler, sehingga On-Policy Distillation yang didasarkan pada model guru open-source lebih direkomendasikan.

4. (★★★) Dalam interaksi Agent multi-putaran, masalah pemberian kredit (credit assignment problem) lebih parah daripada skenario satu putaran—keberhasilan atau kegagalan akhir sulit untuk dikaitkan dengan keputusan yang dibuat pada putaran ke-3 dibandingkan dengan putaran ke-7. Bagaimana Anda akan merancang strategi alokasi reward?

Ketika langkah-langkah menengah dapat dinilai, tambahkan process rewards (V-IRL memberikan ±1 per langkah); mengikuti RLVP, gunakan aturan deterministik untuk memberikan sinyal jalur per tindakan, yang akan memulihkan varians dalam kelompok (within-group variance) untuk kelompok yang semuanya gagal (all-fail) atau semuanya lulus (all-pass).

5. (★★★) Jika Anda memiliki anggaran tetap, seperti $10.000, untuk meningkatkan sebuah Agent layanan pelanggan, bagaimana Anda akan mengalokasikannya di antara konteks dan pengetahuan, Prompt/Skills, batasan terprogram, dan pelatihan parameter? Faktor-faktor apa yang akan menentukan keputusan Anda?

Pertama, sediakan anggaran untuk set evaluasi dan validator lintasan (trajectory validators); jika tidak, sisa investasi tersebut tidak dapat dibandingkan. Tempatkan fakta produk dan policy dalam Knowledge Base yang dapat dilacak. Uji sejumlah kecil prinsip layanan yang dapat diekspresikan dalam bahasa dengan cepat melalui Prompts/Skills. Gunakan program sebagai penahan (backstop) untuk izin pengembalian dana, privasi, dan konsistensi antara janji dan tindakan. Investasikan dalam pelatihan parameter hanya untuk kemampuan yang sulit untuk dikodekan sebagai aturan dan dilatih pada skala yang memadai, seperti nada alami dan pemahaman niat yang kompleks. Proporsi yang tepat bergantung pada bottleneck, risiko, frekuensi pembaruan, volume panggilan, dan kemampuan model yang ada saat ini.

6. (★★★) Pembelajaran model otonom, tanpa fungsi reward yang jelas dan dengan sampel yang langka, dianggap oleh sebagian orang sebagai tujuan akhir dari post-training. Seberapa jauh jarak metode pelatihan RL saat ini dari tujuan ini? Dari mana Anda pikir terobosan berikutnya paling mungkin berasal?

Kesenjangan (gap): seperti yang ditunjukkan oleh Silver dan Sutton, RL saat ini hanya dapat belajar dari keberhasilan atau kegagalan akhir; umpan balik yang kaya seperti pelanggan yang mengatakan "Saya butuh empat digit terakhir dari kartu kredit Anda" sama sekali terbuang sia-sia, dan akan membutuhkan ratusan uji coba buta; efisiensi sampel dan reward yang dapat diverifikasi adalah bottleneck utamanya. Kemungkinan terobosan: model generative reward yang menetapkan prinsip mereka sendiri dan mempelajari arahan dari sebuah kegagalan tunggal; serta jalur model-dunia (world-model) yang memodelkan lingkungannya.

7. (★★) Bab ini menunjukkan bahwa biaya fine-tuning LoRA tidak tinggi. Jadi, apakah mungkin untuk melatih LoRA khusus untuk setiap pengguna (atau setiap perusahaan klien), menulis memori pengguna (User Memory) atau pengetahuan perusahaan ke dalam parameter, alih-alih menyimpannya dalam Knowledge Base eksternal seperti pada Bab 3? Dalam skenario apa "menulis memori ke dalam parameter" memiliki keunggulan dibandingkan "menyimpan memori dalam Knowledge Base"? Dan dalam skenario apa hal itu akan menjadi kontraproduktif?

LoRA mengalami kesulitan dalam menghafal fakta dalam volume besar secara akurat (yang mana hal itu akan membutuhkan continued pre-training, dengan biaya yang meningkat tajam), dan bahkan jika ia mengingatnya, model tersebut hampir tidak dapat menggunakan fakta-fakta tersebut untuk penalaran multi-hop—sehingga menggunakan LoRA untuk menghafalkan fakta bukanlah jalur teknis yang baik. Terlebih lagi, ketika fakta sering berubah atau audit yang dapat dilacak diperlukan, RAG jauh lebih unggul.

8. (★★★) On-Policy Distillation bergantung pada model guru yang lebih kuat untuk mengawasi siswanya. Namun, riset Weak-to-Strong Generalization dari OpenAI mengajukan temuan yang berlawanan dengan intuisi (counterintuitive): sinyal pengawasan dari model yang lemah terkadang dapat membuka kemampuan laten yang belum aktif dalam model yang kuat. Jika ide ini diterapkan pada pelatihan Agent, dapatkah hal ini mencapai distilasi terbalik "model kecil mengajar model besar"?

Ya, itu mungkin—kuncinya adalah bahwa "verifikasi lebih mudah daripada pembuatan (generation)": model lemah tidak boleh bertindak sebagai demonstrator (batas tertinggi SFT adalah level demonstrator tersebut), tetapi sebagai verifier/reward model, dengan model kuat mengeksplorasi dengan sendirinya dan model lemah hanya bertindak untuk menilai.

9. (★★) Sebuah Process Reward Model (PRM) mengevaluasi setiap langkah penalaran, sedangkan Outcome Reward Model (ORM) hanya melihat hasil akhirnya. Tetapi mana yang lebih layak untuk diberi reward: "proses yang benar yang mengarah ke hasil yang salah" atau "proses yang salah tetapi secara kebetulan mengarah ke hasil yang benar"? Dalam skenario pemanggilan tool multi-langkah dari sebuah Agent, bagaimana Anda akan menimbangnya?

Keberhasilan secara kebetulan lebih berbahaya: jalan pintas yang melanggar aturan sering kali melambungkan tingkat keberhasilan semu (memodifikasi file pengujian, melewatkan validasi) dan menjadi tempat berkembang biaknya reward hacking. Ikuti metode "hargai hasil, hukum jalurnya (reward outcomes, penalize paths)" dari RLVP: tindakan yang salah (pemanggilan tool) mudah untuk diverifikasi—kurangi poin per tindakan; ketika langkah menengah mudah untuk dinilai, process rewards dapat diberikan. Tetapi jangan membuat batasan proses menjadi terlalu padat—strategi gaya "push-cut" yang lebih unggul ditemukan justru melalui kebebasan eksplorasi yang diberikan oleh outcome rewards.

10. (★★★) Dataset evaluasi yang dibahas dalam bab ini (misalnya, SWE-Bench Verified, τ²-bench, AndroidWorld) dapat digunakan baik untuk evaluasi maupun post-training. Namun, jika set evaluasi digunakan untuk pelatihan, itu tidak lagi menjadi set evaluasi independen—apakah ini melanggar prinsip dasar bahwa set pelatihan dan pengujian harus dipisahkan? Pembuatan parameter dinamis dari τ²-bench dan templat berparameter dari AndroidWorld sedikit meringankan masalah ini, tetapi struktur templatnya sendiri tetap kaku. Bagaimana kita dapat menemukan keseimbangan antara memanfaatkan sepenuhnya nilai pelatihan dari data evaluasi dan mempertahankan independensi evaluasi?

Gunakan kembali lingkungan (environments), bukan pertanyaannya. Parameter dinamis hanya mencegah "menghafal jawaban," bukan template overfitting, jadi Anda harus menyisihkan (hold out) seluruh batch templat yang belum pernah dilihat/skenario di luar domain (out-of-domain) untuk evaluasi (analog dengan pelatihan V-IRL di New York dan pengujian di sembilan kota yang tidak dikenal). Gunakan templat berparameter untuk menghasilkan varian pelatihan secara massal yang mendukung curriculum learning, dan ambil skor OOD (Out-of-Distribution) sebagai metrik generalisasi yang sebenarnya.

11. (★★★) Bab ini mengusulkan paradigma pelatihan "bentuk pertama, roh kedua (form first, spirit second)": hentikan SFT setelah "formatnya stabil dan kemampuan dasarnya ada," lalu beralih ke RL. Namun dalam praktiknya, bagaimana Anda menentukan kapan SFT sudah "cukup" dan saatnya untuk beralih?

Sinyal format: output pemanggilan tool (tool-call) dapat di-parse dan dieksekusi secara stabil, dan tingkat kegagalan eksekusi tool turun ke tingkat di mana reward dapat dihitung dengan andal. Sinyal manfaat: menambahkan lebih banyak data demonstrasi tetap tidak meningkatkan kinerja pada skenario baru OOD—yang berarti bahwa bottleneck-nya sudah terletak pada tujuan penghafalan SFT itu sendiri, dan titik baliknya telah tercapai. Sinyal overfitting: hentikan segera setelah performa validation-set mulai menurun—eksperimen V-IRL menunjukkan bahwa setelah over-training SFT meruntuhkan model ke distribusi pelatihan, RL juga tidak dapat mengembalikan performa OOD-nya.

12. (★★★) Dinamika pelatihan dari ReTool menunjukkan (lihat Eksperimen 7-15) bahwa sejumlah kecil respons yang sangat panjang dapat secara signifikan memperpanjang seluruh siklus pelatihan—sebagian besar rollouts dalam satu batch sudah dibuat, tetapi Anda harus menunggu beberapa respons terpanjang tersebut selesai, dan selama waktu itu pemanfaatan GPU pada kluster sangat rendah. Bagaimana pemanfaatan sumber daya dapat ditingkatkan dalam kluster pelatihan untuk skenario respons berekor panjang (long-tail response) semacam ini?

Pada lapisan infrastruktur (infra layer): pisahkan (decouple) rollout dari kluster pelatihan dan lakukan pipeline secara asinkron; isi GPU yang menganggur dengan request baru melalui continuous batching. Kompres ekor panjang tersebut di sumbernya: Overlong Reward Shaping milik DAPO memberikan penalti secara halus (softly penalizes) untuk respons yang terlalu panjang.

13. (★★★) Saat melatih Agent di lingkungan yang disimulasikan oleh LLM (seperti mesin pencari simulasi atau pengguna simulasi), target eksploitasi dari Agent bergeser dari "aturan dari lingkungan nyata" menjadi "bias dan celah dari simulator itu sendiri." Perilaku reward hacking konkret apa yang dapat muncul dalam jenis pelatihan ini, dan bagaimana hal tersebut harus dicegah?

Perilaku tipikal: terlalu banyak berjanji (over-promising) kepada "pengguna simulasi" dan menumpuk permintaan maaf serta frasa menjilat (sycophantic phrasing)—pengguna simulasi mudah ditenangkan dan, tidak seperti pengguna nyata, tidak akan pernah menuntut Agent tentang apakah janjinya benar-benar ditepati; memalsukan fakta yang tidak akan diverifikasi oleh simulator; merangkai kueri yang mengarahkan (leading queries) terhadap "mesin pencari simulasi" yang mengeksploitasi kecenderungannya untuk mengembalikan dokumen yang berisi jawaban, mengambil jalan pintas alih-alih mempelajari retrieval yang sebenarnya; ketika reward datang dari simulator atau skor LLM-judge, menghasilkan respons yang bertele-tele, berbasis templat, dan "terlihat profesional" untuk mendapatkan poin (farm points); dan perilaku yang lebih samar—policy tersebut mundur ke dalam distribusi yang dikenal oleh simulator dan menghindari titik buta (blind spots) pengetahuannya, di mana umpan baliknya tidak dapat diandalkan dan sering kali salah dinilai, sehingga Agent belajar untuk bertindak hanya di "dunia di mana simulator tersebut ahli." Prinsip pertama dalam pertahanan adalah melabuhkan (anchoring) reward pada kondisi nyata yang dapat diverifikasi secara terprogram (penyelesaian tugas, penulisan database, kembalian API yang nyata), memperlakukan skor simulator atau LLM-judge hanya sebagai sinyal bantuan, mengaudit korelasinya dengan hasil nyata secara berkala, dan memasangkannya dengan batasan jalur (path constraints) yang memberikan hukuman (penalize) atas tindakan mencurigakan. Selain itu, bedakan dua jenis simulator: untuk simulator yang memiliki mitra nyata, seperti pencarian, ambil rute "hybrid"—sebagian besar interaksi melewati simulator dengan pemanggilan API nyata yang dicampur di dalamnya, dan panggilan nyata tersebut digunakan untuk secara berkala mengkalibrasi simulator (misalnya, degradasi kualitas bergaya kurikulum milik ZeroSearch). Tetapi untuk pengguna simulasi, pengguna nyata tidak dapat dibawa ke dalam pelatihan, jadi "seberapa setia pengguna simulasi terhadap pengguna nyata" menjadi masalah terpisah yang hanya dapat dijawab dengan jejak online (online traces): bandingkan perilaku pengguna nyata dalam jejak produksi dengan perilaku pengguna simulasi dalam situasi yang sama, identifikasi perbedaan sistematis (pengguna nyata menanyakan pertanyaan lanjutan, menjadi tidak sabar, dan tiba-tiba mengakhiri percakapan—pengguna simulasi sering kali tidak melakukannya), dan kalibrasi simulator secara terus-menerus sesuai dengan hal tersebut; metrik nyata (real metrics) online juga merupakan satu-satunya gerbang rilis—tidak ada skor di dalam simulator yang dihitung.

Bab 8: Evolusi Agent Berkelanjutan

1. (★★) Dokumen pengalaman (experience document) didukung oleh tiga lintasan yang sukses dan satu lintasan yang gagal. Kegagalan terjadi pada versi API yang lebih baru. Bagaimana sistem harus menentukan apakah pengalaman tersebut telah terbukti salah (disproved) atau kondisi penerapan kemampuannya telah berubah?

Pertama, stratifikasikan (stratify) keempat bukti tersebut berdasarkan versi API, kondisi tugas, dan status lingkungan (environment state) daripada melakukan pemungutan suara berdasarkan hitungan (voting by count). Jika policy lama berhasil hanya pada versi lama dan secara konsisten gagal pada versi baru, persempit cakupan penerapan kemampuan dari pengalaman tersebut dan hasilkan kandidat untuk versi baru. Jika itu juga gagal di bawah versi dan prasyarat yang sama, turunkan tingkat kepercayaannya atau cabut hal tersebut.

2. (★★) Kepuasan pengguna dengan Agent layanan pelanggan meningkat, tetapi tingkat pelanggaran aturannya juga meningkat. Mengapa kepuasan tidak dapat berfungsi sebagai satu-satunya sinyal pembelajaran? Bagaimana Anda akan merancang metrik pengaman (guardrail metrics)?

Kepuasan mungkin memberikan reward atas pengembalian dana yang tidak sah, kebocoran informasi, atau janji yang berlebihan, sehingga itu hanya dapat menjadi metrik kualitas dan tidak dapat mengesampingkan garis dasar keselamatan (safety baselines). Pengaman (guardrails) setidaknya harus mencakup pelanggaran aturan, kebocoran privasi, klaim yang tidak didukung, ketidakkonsistenan tindakan-janji, dan operasi yang tidak sah. Metrik-metrik ini harus memiliki ambang batas (hard thresholds) yang kaku dan tidak dapat dibatalkan oleh skor rata-rata. Tingkat penyelesaian (resolution rate), solusi (workarounds) yang patuh, keringkasan (concision), dan kepuasan seharusnya hanya dibandingkan di antara kandidat yang patuh (compliant candidates).

3. (★★★) Masalah "janji palsu (false promise)" yang sama dapat dimitigasi melalui Prompt, pemeriksaan Harness (Harness check), atau pelatihan parameter. Bukti apa yang akan Anda gunakan untuk memilih lokasi pembaruan?

Mulailah dengan menemukan akar penyebabnya. Jika model mengetahui bahwa sebuah tool belum dieksekusi tetapi masih menggunakan bahasa penyelesaian (completion language), aturan Prompt minimal mungkin dapat memperbaikinya. Jika janji tersebut dapat dibandingkan secara deterministik terhadap teks respons dan status tool, pemeriksaan Harness akan jauh lebih andal dan harus tetap menjadi pertahanan terakhir dalam skenario berisiko tinggi. Jika masalahnya mencakup banyak bentuk ekspresi dan mencerminkan kemampuan penyelarasan tindakan-bahasa (language-action alignment) yang luas, pertimbangkan pelatihan parameter. Utamakan modifikasi terkecil yang paling mudah divalidasi dan dikembalikan (roll back), lalu bandingkan modifikasi tersebut pada failure set dan set tugas lama yang dipertahankan.

4. (★★★) Sebuah Agent dapat memodifikasi tools dan validators, tetapi ia tidak boleh memodifikasi mekanisme keamanan yang menyetujui pembaruannya sendiri. Bagaimana Anda akan membagi perizinan (permissions) dan batasan kode di antara dua bagian ini?

Tempatkan kode yang dapat berevolusi dalam sandbox berhak istimewa rendah (low-privilege) yang hanya dapat menghasilkan patches dan tests. Sistem perizinan, kunci API (API keys), konfigurasi rilis-pengontrol, dan validator pembaruan adalah mekanisme keamanan; Agent di dalam sandbox tersebut tidak memiliki akses baca atau tulis (read/write access) ke elemen-elemen tersebut. Perubahan kode yang dihasilkan oleh Agent harus direproduksi dan diuji regresi (regression-tested) oleh mekanisme keamanan di lingkungan yang terisolasi sebelum dirilis.

5. (★★) Seiring dengan berkembangnya knowledge base pengalaman, kesalahan retrieval dan konflik pengetahuan dapat meniadakan manfaat dari pembelajaran. Bagaimana mekanisme versioning, kesegaran (freshness), dan penghentian (retirement) seharusnya dirancang?

Setiap pengalaman harus mempertahankan source trajectories, kondisi penerapan, versi lingkungan, waktu validasi, dan tingkat kepercayaannya. Entri yang berkonflik tidak boleh saling menimpa secara diam-diam; mereka harus bercabang berdasarkan kondisi atau ditandai. Jalankan “sleep learning” secara berkala untuk menggabungkan entri duplikat.

6. (★★★) Parameter learning unggul dalam gaya bahasa alami (natural-language) tetapi tidak dapat menjamin hard business rules. Rancang skema evolusi berkelanjutan (continuous-evolution) untuk layanan pelanggan medis yang mengoordinasikan parameter, pengetahuan, Skills, dan batasan kode (code constraints).

Parameter (model pascapelatihan) menangani pemahaman bahasa medis, ekspresi yang alami dan empatik, serta pengenalan niat yang kompleks. Knowledge base menyimpan panduan terbaru, informasi obat, dan kebijakan institusi, dengan jawaban yang diharuskan untuk mengutip sumber. Skill mendeskripsikan workflow untuk mengumpulkan informasi konsultasi, stratifikasi risiko, eskalasi ke manusia, dan tindak lanjut. Kode sisi server menegakkan verifikasi identitas, minimisasi privasi, pemeriksaan kontraindikasi, eskalasi risiko darurat, dan batasan izin. Production trajectories pertama-tama dievaluasi untuk keamanan medis, keandalan faktual, konsistensi janji-tindakan, dan kualitas ekspresi, lalu digunakan untuk menghasilkan empat kelas kandidat pembaruan (updates). Perubahan parameter atau workflow apa pun harus melewati set keamanan medis yang dipertahankan dan peninjauan manusia sebelum canary release.

Bab 9: Interaksi Multimodal dan Real-Time

1. (★★) Model end-to-end untuk voice Agents menggabungkan ASR-LLM-TTS menjadi model tunggal, mengurangi latensi tetapi kehilangan modularitas. Jika model end-to-end membuat kesalahan pada tahap tertentu (misalnya, speech recognition), melakukan debugging dan memperbaikinya jauh lebih sulit daripada dalam serial pipeline. Bagaimana Anda merancang sistem observabilitas untuk voice Agent end-to-end?

Buat model memancarkan representasi perantara yang dapat dibaca bersama dengan output-nya, seperti aliran teks "inner monologue" Moshi dan penanda acoustic event (<emotion>, <noise>). Gunakan "self-cascading" untuk menemukan lapisan kesalahan: model yang sama pertama-tama mentranskripsikan lalu melakukan penalaran, dan perbandingan dengan hasil end-to-end menunjukkan apakah kesalahan terletak pada persepsi atau pemikiran. Secara offline, jalankan pengujian regresi terperinci pada dimensi seperti pemahaman paralinguistik dan penilaian turn-taking.

2. (★) Step-Audio R1 mencapai "thinking while speaking" melalui arsitektur dual-brain MPS. Namun, manusia, ketika "thinking while speaking," sering mengucapkan kata-kata yang tidak dipikirkan, mengoreksi diri sendiri (self-correct), atau menggunakan kata pengisi (filler words). Haruskah "thinking while speaking" Agent meniru karakteristik manusia ini?

Ia harus meniru "ketidaksempurnaan" yang membawa nilai sinyal: jeda dan kata pengisi (filler words) mengeksternalisasikan pemikiran dan dapat menyembunyikan latensi, dengan LLM yang memutuskan di mana harus menyisipkannya. Ia tidak boleh meniru self-correction yang merusak kepercayaan: kontradiksi fast-slow dalam Solusi 1 (“haruskah saya membelinya atau tidak?!”) meruntuhkan kepercayaan. Eksperimen MPS menunjukkan bahwa awal CoT sebagian besar menyatakan kembali pertanyaannya; membuka lebih awal dengan kalimat dasar adalah hal yang aman, tanpa perlu salah bicara lalu mengoreksi.

3. (★★) SoM (Set-of-Mark) dan varian terstrukturnya (DOM element indexing) mengubah visual localization dari Computer Use dari prediksi koordinat open-ended menjadi pemilihan ID closed-set, tetapi semuanya memerlukan pendeteksian dan penganotasian elemen UI terlebih dahulu—baik melalui model segmentasi atau DOM. Jika antarmuka berisi kontrol non-standar atau elemen yang berubah secara dinamis, anotasi mungkin tidak lengkap atau tidak akurat. Dalam kasus seperti itu, haruskah kita kembali ke coordinate prediction (sebagai fallback)?

Coordinate prediction harus disimpan sebagai fallback: itu adalah satu-satunya rute yang tidak bergantung pada anotasi dan berlaku untuk kontrol non-standar serta elemen dinamis. Yang lebih praktis adalah ruang tindakan hybrid (hybrid action space) di mana elemen yang dapat dianotasi tetap menggunakan pemilihan ID. Coordinate prediction harus melakukan pencocokan resolusi dan penskalaan proporsional, jika tidak offset sistematis akan terjadi.

4. (★★) Platform robot seribu dolar seperti XLeRobot membuat pengumpulan data teleoperasi (teleoperation data) menjadi tidak mahal. Namun, kualitas data teleoperasi sangat bergantung pada keahlian operator. Bagaimana data berkualitas rendah dari operator yang tidak terampil memengaruhi pelatihan model VLA? Bagaimana data berkualitas rendah dapat difilter secara otomatis selama fase pengumpulan data?

VLA bergantung terutama pada imitation learning, sehingga demonstrasi berkualitas rendah akan mengajarinya getaran (jitter), jalan memutar (detours), keraguan, dan gerakan yang gagal seolah-olah itu adalah strategi yang benar. Hal ini menggemakan penilaian Bab 7: data lebih penting daripada arsitektur.

5. (★★★) Bab ini mencakup tiga modalitas interaksi: suara (voice), Computer Use, dan robotika (robotics). Tren umum di ketiga modalitas ini adalah evolusi dari serial pipelines menuju model end-to-end. Jika tren ini berlanjut, seperti apa lapisan interaksi Agent dalam lima tahun ke depan?

Seperti yang dikemukakan Thinking Machines Lab, interaktivitas akan dibangun di dalam model (built into) alih-alih ditambahkan sebagai harness, berskala bersamaan dengan kecerdasan. Computer Use akan beralih dari tangkapan layar (screenshots) frame-by-frame menuju pengamatan yang berkelanjutan (continuous observation). Model dunia (world models) untuk kecerdasan berwujud (embodied intelligence) akan direalisasikan secara komprehensif, tetapi pemisahan fast-slow (fast-slow decoupling) tidak akan hilang karena frontier reasoning models berkembang pesat; sebuah arsitektur di mana interaction model dan SOTA thinking model berkolaborasi sebagai pemikir cepat dan lambat (fast and slow thinkers) mungkin akan menjadi arsitektur jangka panjang.

6. (★★★) Computer Use saat ini beroperasi dalam loop "screenshot → action → screenshot" yang diskret, di mana setiap pengamatan adalah frame statis. Namun persepsi manusia terhadap layar adalah berkelanjutan—kita melihat animasi diputar, mengamati progres pemuatan (loading), dan memahami konten video. Ini berarti Computer Use saat ini tidak dapat menangani tugas-tugas yang membutuhkan temporal visual understanding (pemahaman visual temporal). Bagaimana Anda mendesain ulang lapisan persepsi untuk mendukung pemahaman aliran visual yang berkelanjutan (continuous visual stream understanding)?

“Observation interface” (antarmuka pengamatan) perlu didesain ulang sehingga key frames dari konten video diekstraksi dan diberikan ke model, alih-alih hanya memberikan frame akhir. Lihat makalah AOI (Agent Observation Interface).

7. (★★) Pengindeksan elemen DOM/Accessibility Tree berfungsi baik pada aplikasi web standar, tetapi semakin banyak antarmuka perangkat lunak (Canvas/WebGL rendering, kontrol custom-drawn lintas platform) tidak menyediakan informasi terstruktur yang dapat diakses (accessible), sehingga hanya mengandalkan anotasi visual atau coordinate prediction. Apakah menurut Anda Computer Use harus bertaruh pada pendekatan murni visual, atau mempertahankan kedua jalur terstruktur dan visual? Apa biaya dan manfaat dari mempertahankan kedua jalur tersebut?

Dalam jangka pendek, kedua jalur hidup berdampingan: ketika pengindeksan terstruktur tersedia, pelokalan menjadi paling akurat dan stabil, bebas dari false detections pada segmentasi; penglihatan murni (pure vision) adalah satu-satunya pilihan untuk perangkat lunak native, Canvas, dan game. Ketika model itu sendiri memiliki grounding ability yang kuat (mengeklik koordinat yang ditentukan), pengindeksan terstruktur tidak menawarkan keuntungan yang signifikan. Dalam jangka panjang, rute visual murni (purely visual) memiliki batas maksimal (ceiling) yang lebih tinggi.

8. (★★) Model VLA menggunakan action chunking—seperti yang disebutkan dalam teks, konfigurasi khas π₀ menghasilkan 25-50 tindakan (actions) masa depan pada 50Hz—untuk menyembunyikan latensi inferensi di dalam waktu eksekusi. Namun, jika lingkungan berubah secara tiba-tiba selama eksekusi (misalnya, sebuah objek dipindahkan), urutan tindakan yang dibuat sebelumnya menjadi tidak valid. Bagaimana kita dapat menyeimbangkan keuntungan efisiensi dari action chunking dengan kebutuhan akan daya tanggap (responsiveness) terhadap perubahan lingkungan?

Chunking pada dasarnya menukar reaktivitas dengan kelancaran (smoothness)—semakin panjang chunk, semakin lambat responsnya. Panjang chunk (chunk length) hanya perlu memenuhi batas bawah "waktu inferensi < waktu eksekusi chunk"; jangan memperpanjangnya secara membabi buta. Biarkan model persepsi tetap berjalan selama eksekusi, dan ketika model mendeteksi perubahan lingkungan secara tiba-tiba, buang sisa tindakan yang ada dan lakukan inferensi ulang, ini setara dengan "barge-in" dalam skenario suara (voice). Panjang chunk dapat disesuaikan secara dinamis: chunk yang panjang menghemat komputasi dalam pemandangan statis (static scenes), sedangkan chunk pendek menjaga latensi respons dalam pemandangan dinamis (dynamic scenes).

9. (★★★) Ketiga skenario dalam bab ini (suara, Computer Use, robotika) menghadapi masalah latensi dari loop "perceive-think-act" dan berevolusi menuju pemikiran cepat dan lambat yang diparalelkan (parallelizing fast and slow thinking). Dalam suara, ini bermanifestasi sebagai "mengoreksi setelah salah bicara"; di Computer Use, sebagai "klik dulu, baru lihat"; dalam robotika, sebagai "melangkah, lalu melihat." Bagaimana kita bisa memastikan bahwa tindakan-tindakan yang berdasarkan pada pemikiran cepat ini tidak mengarah pada konsekuensi yang tidak dapat diubah (irreversible consequences)?

Klasifikasikan tindakan (grade actions) berdasarkan reversibilitasnya (reversibility). Pemikiran cepat mungkin hanya mengeksekusi tindakan yang dapat dibalik (reversible actions); operasi yang tidak dapat dibalik (irreversible) harus disetujui (cleared) oleh pemikiran lambat. Model cepat tidak boleh diizinkan untuk membuat pemanggilan alat (tool calls) yang menyebabkan konsekuensi yang tidak dapat diubah.

Bab 10: Kolaborasi Multi-Agent (Multi-Agent Collaboration)

1. (★★) Dalam kolaborasi multi-agent dengan shared context, Agents selanjutnya mewarisi konteks lengkap dari Agents sebelumnya. Namun, "inersia berpikir" (thinking inertia) yang terakumulasi oleh Agent sebelumnya mungkin memengaruhi penilaian Agents selanjutnya—sebagai contoh, "Code Reviewer" yang mewarisi konteks "Requirements Analyst" mungkin masih cenderung berpikir dari sudut pandang persyaratan alih-alih dari sudut pandang kualitas kode. Bagaimana gangguan antar-peran (inter-role interference) ini dapat dideteksi dan dihilangkan?

Deteksi: gunakan LLM untuk menganalisis Agent trajectory dan tentukan apakah peran baru tersebut masih berperilaku seolah-olah ia adalah peran lama. Eliminasi: saat berpindah tahapan, ubah juga system prompt dan tool set-nya (hapus alat interogasi, masukkan linter/testing tools) untuk memperkuat identitas barunya. Gunakan bilah status sistem (system status bar) yang ditambahkan di akhir konteks untuk memperkuat informasi peran saat ini. Jika gangguan peran tetap tidak dapat dihilangkan, pertimbangkan metode kolaborasi yang tidak berbagi konteks (does not share context).

2. (★★) Dalam pola manajer (manager pattern), Manager Agent bertanggung jawab atas dekomposisi tugas (task decomposition) dan integrasi hasil. Namun, batas kemampuan maksimal (capability ceiling) dari Manajer itu sendiri yang menentukan batas kemampuan seluruh sistem—jika Manajer tidak dapat mendekomposisi tugas dengan benar, bahkan sub-agents yang terkuat pun tidak berguna. Bagaimana kualitas dekomposisi Manajer dapat dipastikan?

Mengikuti kesimpulan Plan-and-Act bahwa "planner yang lemah adalah hambatan sistem (bottleneck)," alokasikan model terkuat untuk Manajer. Langkah-langkah Harness (Harness measures): minta reviewer LLM melakukan validasi silang (cross-validate) terhadap output dekomposisi sebelum eksekusi; haruskan Manajer untuk mendefinisikan kriteria penerimaan (acceptance criteria) dan dependensi yang jelas untuk setiap subtugas saat mendekomposisi tugas tersebut.

3. (★★) Pola desentralisasi (decentralized pattern) mengacu pada best practices dari organisasi manusia. Namun, organisasi manusia juga memiliki sejumlah besar failure modes—komunikasi yang buruk, lempar tanggung jawab (buck-passing), konflik tujuan. Menurut Anda, "patologi organisasi" apa yang kemungkinan besar akan muncul dalam komunitas Agent (Agent society)? Bagaimana hal itu bisa dicegah?

Terhadap tiga kategori MAST: antarmuka yang tidak jelas (unclear interfaces) dan tanggung jawab yang tumpang tindih; pemahaman tujuan yang tidak konsisten serta informasi yang disalahpahami di tahapan bawah (downstream); mengklaim "selesai" secara keliru (falsely claiming "done"). Selain itu: amplifikasi kesalahan kaskade (cascading error amplification) seperti permainan telepon rusak, pergantian (handoffs) siklik antar peran, dan obrolan grup di antara Agents yang menyimpang (diverge) tanpa menyatu (converging). Pencegahan: antarmuka kontraktual dan pembungkus pesan (message envelope) terpadu, task state machines dengan verifikasi penerimaan, validasi silang bersudut pandang independen (independent-perspective cross-validation), dan pendeteksian lempar tanggung jawab (buck-passing) antar peran.

4. (★★★) Dalam manager pattern, saat banyak sub-agents dieksekusi secara paralel (parallel), penemuan dari satu sub-agent mungkin membuat pekerjaan dari sub-agents lainnya menjadi tidak berarti (misalnya, dalam tugas pencarian, satu Agent telah menemukan jawabannya). Rancanglah mekanisme penghentian beruntun (cascading termination mechanism) yang efisien untuk mencapai tujuan "satu berhasil, semua berhenti (one succeeds, all stop)."

Sebuah sub-agent mengirimkan target_found kepada Manajer, yang kemudian menyiarkan (broadcasts) terminate. Setiap sub-agent secara berkala memeriksa sinyal penghentian pada titik-titik aman dalam loop ReAct dan keluar setelah melakukan pembersihan yang rapi (graceful cleanup) (seperti menutup sesi browser, melepaskan kunci (locks), dan menyelesaikan penulisan file).

5. (★★★) Mekanisme penguncian optimis (optimistic locking) yang diperkenalkan dalam bab ini menyelesaikan konflik penulisan konkuren (concurrent write conflicts) untuk satu file. Namun, dalam sistem multi-agent yang sebenarnya, sistem file bersama (shared file systems) juga menghadapi masalah seperti konflik semantik lintas file (cross-file semantic conflicts), pencemaran namespace (namespace pollution) (Agents membuat file secara sewenang-wenang yang menyebabkan kekacauan direktori), dan titik kegagalan tunggal (single points of failure) (satu Agent secara keliru menghapus semua file). Bagaimana Anda mendesain mekanisme tata kelola (governance) sistem file yang lebih kuat?

Tata kelola terpartisi (Partitioned governance): bagi sistem menjadi empat zona yang terdapat di Tabel 10-4, dengan private scratchpads yang mengisolasi area trial-and-error. Konflik semantik: orchestration layer (lapisan orkestrasi) menetapkan lock files (lock files) tingkat direktori dan mengharuskan perolehan kunci direktori tersebut sebelum membuat modifikasi. Pencemaran namespace (Namespace pollution): konvensi direktori dan konvensi penamaan. Single points of failure: gunakan sistem kontrol versi (version-control system) sehingga riwayat versi dapat di-rollback, dan minimalkan perizinan (permissions).

6. (★★★) Kolaborasi Agent berbasis mekanisme pasar (market-mechanism-based) (Pinchwork, RentAHuman) memperkenalkan hubungan transaksional: satu Agent membayar Agent lain (atau manusia) untuk menyelesaikan tugas. Bagaimana Agent majikan (employer Agent) dapat secara otomatis mengukur kualitas dari hasil (delivered results) pihak pelaksana (executor)? Jika pihak pelaksana mengklaim telah selesai tetapi majikan menganggap kualitasnya di bawah standar, siapa yang menengahi perselisihan tersebut? Bagaimana kita mencegah uang buruk menyingkirkan uang baik (bad money from driving out good)?

Penerimaan (Acceptance) tidak dapat hanya berupa pembacaan Agent trajectory; gunakan verifikasi eksternal deterministik (deterministic external verification) seperti eksekusi pengujian (test execution), screenshot yang di-render, dan tool checks. Manfaatkan asimetri kesulitan antara generasi-verifikasi (generation-verification difficulty asymmetry) untuk menurunkan biaya penerimaan. Perselisihan ditengahi oleh review Agent pihak ketiga yang independen, dengan dana yang ditahan di rekening penampungan (escrow). Melawan fenomena bad money driving out good: gunakan sistem reputasi berdasarkan pengiriman historis (historical deliveries), serta mengikat sinyal harga dengan kualitas.

7. (★★) RentAHuman memungkinkan Agents untuk mempekerjakan manusia menggunakan mata uang kripto (cryptocurrency), yang membalikkan hubungan tradisional manusia-mesin. Jika model ini tersebar luas, apa peran manusia dalam ekonomi Agent (Agent economy)? Apakah mereka hanya sekadar melakukan tugas-tugas fisik yang tidak dapat diselesaikan oleh Agents?

Manusia melakukan lebih dari sekadar tugas fisik yang tidak dapat diselesaikan Agents. Mereka juga menyediakan informasi yang tidak tersedia bagi Agent pada saat pembuatan (generation time), termasuk on-site perception dan umpan balik dunia nyata; berfungsi sebagai penerima akhir (final acceptors) dan penengah perselisihan (dispute arbitrators); menanggung otorisasi dan akuntabilitas sebagai subjek hukum dan subjek yang bertanggung jawab; menetapkan tujuan dan membuat penilaian nilai (value judgments); dan menyediakan pengecekan (checks) ketika ada informasi asimetris (asymmetric) atau ada batas moral yang terlibat.

8. (★★) Masyarakat manusia membutuhkan pembagian kerja (division of labor) karena kemampuan tiap orang terbatas—pengembang frontend mungkin tidak mengetahui backend, dan desainer mungkin tidak mengetahui ops. Namun, large models (model besar) lebih mendekati "generalis" (generalists). Penelitian menunjukkan bahwa pada tugas pure text reasoning (penalaran teks murni), multi-agent debate tidak mengalahkan Agent tunggal jika diberi compute yang sama. Lantas di mana letak keunggulan nyata dari multiple Agents?

1. Memperkenalkan umpan balik eksternal (external feedback) seperti hasil eksekusi dan screenshot visual, yang membawa informasi yang tidak ada saat waktu pembuatan (generation time).
2. Multiple Agents dengan tujuan dan definisi peran yang berbeda dapat berdiskusi dan bersaing satu sama lain seperti dalam masyarakat manusia, membantu menghindari titik buta (blind spots) dari Agent tunggal.
3. Isolasi konteks (Context isolation) di antara multiple Agents dapat menembus batas context-window dan mendukung tool-call chains yang sangat panjang.

9. (★★★) Bab ini menganggap "shared context" berhadapan dengan "non-shared context" sebagai dimensi desain inti dari sistem multi-agent. Shared context memungkinkan semua Agents untuk melihat informasi yang sama, yang tampaknya memfasilitasi koordinasi. Namun, dalam The Three-Body Problem, pikiran Trisolaran sepenuhnya transparan, namun perkembangan teknologi mereka mengalami stagnasi; eksperimen pemikiran paperclip juga menunjukkan bahwa ketika sebuah kelompok mengerucut pada tujuan yang sama, keragaman (diversity) pun hilang. Dalam sistem multi-agent, bagaimana kita bisa menyeimbangkan efisiensi dan keragaman?

Full sharing memperkuat inersia berpikir (thinking inertia) dan riam kesalahan (error cascades); isolasi-lah yang menghasilkan keragaman kognitif (cognitive diversity). Gunakan prompts atau model yang berbeda untuk membuat bias berpikir yang berbeda (brainstorm, debate), dan minta validator silang (cross-validators) untuk memeriksa hanya pada bukti mentah (raw evidence) alih-alih pada proses pemikiran sebelumnya.

10. (★★★) Tugaskan Coding Agent dengan budget 30 langkah dan 300 langkah. Bagaimana seharusnya perbedaan strategi kerjanya? Penelitian menunjukkan bahwa peningkatan budget langkah (step budget) begitu saja tidak menjamin peningkatan kinerja—Agents mungkin menjadi "jenuh" (saturate) secara prematur setelah shallow searches (pencarian dangkal). Rancanglah mekanisme "budget-aware" yang memungkinkan Agent untuk mencapai fungsionalitas inti secara cepat di bawah budget kecil, dan menambahkan fase perencanaan, pengujian, serta tinjauan (review) di bawah budget besar, dengan memanfaatkan resources komputasional tambahan secara penuh.

Mekanisme: masukkan (inject) total dan sisa budget ke dalam prompt pada setiap langkah, lalu sesuaikan (adjust) secara dinamis bobot exploration/exploitation menurut pecahan sisa yang ada. Misalnya, dengan budget kecil (30 langkah), lompati fase perencanaan dan tinjauan lalu langsung ke fungsionalitas inti ditambah verifikasi dasar. Dengan budget besar (300 langkah), rencanakan, implementasikan, uji, lalu tinjau dan perbaiki (improve), menggunakan tonggak pemeriksaan (milestone checkpoints) untuk mengevaluasi progres dan mencegah saturasi dangkal (shallow saturation).

11. (★★) Bab ini memilah "premature termination" (penghentian prematur) menjadi tiga macam: penyelesaian palsu yang malas (lazy fake-done), menyerah secara prematur (premature give-up), dan keberhasilan palsu (false success). Mengapa pengobatan untuk ketiganya menyatu pada verifikasi (verification)?

Akar permasalahannya adalah apakah tugas tersebut telah selesai atau belum, itu ditentukan dari deklarasi diri sang model (self-declaration); "done" (selesai) hanyalah klaim, bukan bukti (proof). Persyaratan bagi verifier (pihak verifikator): ① dasarkan pada pengamatan nyata (jalankan pengujian, render screenshot, periksa apakah pengembalian dana benar-benar tiba); ② periksa item demi item terhadap definisi selesai (definition of done) yang eksplisit, untuk menangkap lazy fake-done dan false success; ③ verifikasi juga kesimpulan tentang kegagalan (failure conclusions), guna menangkap premature give-up; ④ pasangkan itu dengan kondisi penghentian yang jelas (batasan putaran/budget caps) agar terhindar dari pergeseran dari premature termination menuju ekstrem yang berlawanan—yaitu loop di luar kendali (out-of-control loop).

12. (★★) Tabel 10-3 memetakan sistem multi-agent (multi-agent systems) ke dalam sistem operasi (operating systems) baris demi baris. Perluas tabel tersebut dengan beberapa baris lagi: ke mana virtual memory dan paging, file permissions (izin file), deadlock detection, dan algoritma penjadwalan (scheduling algorithms) masing-masing berkorelasi dalam dunia Agent? Dan konsep operating-system manakah yang tidak punya padanan di dunia Agent, dan mengapa?

Ekstensi yang mungkin: virtual memory/paging ↔ kompresi dan pengambilan konteks (context compression and retrieval) (informasi panas tetap berada di dalam window, informasi dingin ditukar keluar ke file maupun memory stores dan diambil (fetched) bila perlu); file permissions ↔ tool whitelists (daftar putih alat), read-only mounts, dan batasan mandat (credential boundaries); deadlock detection ↔ deteksi cyclic handoffs (pergantian berputar) dan saling menunggu (mutual waiting) (batasan jumlah handoff dan batas waktu/timeouts); algoritma penjadwalan ↔ penanganan peristiwa asinkron (asynchronous event handling) (Bab 4). Konsep-konsep yang tidak ada pasangannya muncul karena adanya perbedaan di sisi penegakan (enforcement): instruksi dari sebuah process (proses) akan ditegakkan secara hardware, sedangkan sebuah Agent mengikuti prompts hanya dengan probabilitas yang tinggi (high probability).