CS 319 · buku: pangmandorin.kamil.web.id
EN ↗

CS 319 · Pertemuan 7 dari 10

Melihat
dan Mengeraskan

Saat loop ngaco jam 3 pagi, Anda tidak akan memperbaikinya dari output akhir. Anda harus bisa memutar ulang.

Agenda · 100 menit

  1. Observabilitas: log, snapshot, trace (30')
  2. Pengerasan: anggaran, pinning, idempotensi, runbook (25')
  3. Studi kasus: lonjakan token 4× (10')
  4. Workshop menulis runbook (25') · briefing A7 (10')

Bacaan: bab 14–15 · Lampiran B

Konsep inti · bab 14

Sistem multi-agent tanpa tracing adalah kotak hitam

Pertanyaan jam 3 pagi yang tak bisa dijawab

"Digest Selasa salah. Mengapa?" — dengan hanya output akhir, Anda punya tebakan. Kegagalannya hidup di apa yang dilihat agen-2 saat mengambil keputusan, empat langkah sebelumnya.

Yang Anda butuhkan

Mesin waktu: apa isi context window tiap agen di tiap panggilan, apa kata masing-masing, dengan keyakinan berapa, dan apa yang dilakukan agen berikutnya dengannya.

Aturan dari lapangan: snapshot context terpasang sebelum setiap panggilan model, simpan di samping output-nya. Penyimpanan murah; rekonstruksi mustahil.

Konsep inti · bab 14

Tiga primitif observabilitas

1 · Log terstruktur

Siapa bilang apa, dengan keyakinan berapa, dalam skema yang bisa di-parse. Bukan prosa. Bukan print.

2 · Snapshot state

Context terpasang per panggilan, dibekukan saat keputusan diambil. Unit replay.

3 · Visualisasi trace

Graf panggilan dalam waktu (LangSmith, OpenTelemetry, atau file dot dan kesabaran). Tempat loop-dalam-loop jadi terlihat.

{"t":"2026-09-22T03:12:04Z","loop":"digest","run":88,"agent":"collector",
 "call_id":"c4","tokens_in":4120,"tokens_out":380,
 "inputs_hash":"a1f3","snapshot":"runs/88/c4.ctx.json",
 "verdict":{"AC-1":"pass","AC-2":"pass","AC-3":"fail"},
 "next":"retry(capped 2) | escalate"}

Konsep inti · bab 15

Pengerasan: dari demo ke produksi

langkah idempoten — run ulang tidak boleh dobel-tagih, dobal-post, dobel-kirim

pelacakan progres — crash di langkah 7/10 dilanjutkan, bukan diulang

degradasi anggun — satu sumber mati → digest tetap terkirim dengan lubang dan catatan

anggaran biaya + token — batas keras per run dan per hari; graf adalah banyak loop membakar paralel

utilisasi konteks ≤ 60–80% — ruang lega itu fitur stabilitas (bab 5, lagi)

pinning versi model + stabilitas prompt-prefix — upgrade tindakan sadar, bukan regresi kejutan

Dan artefak yang membuat semuanya operasional: runbook — halaman yang dibaca manusia on-call jam 3 pagi. Kalau tidak ada, loop Anda bukan produksi; itu demo dengan uptime.

Artefak · 10 dari 75, dipilih untuk mata kuliah ini

Checklist produksi (terpilih)

☐ setiap langkah idempoten

☐ batas anggaran terpasang dan teruji

☐ stagnation breaker aktif

☐ snapshot konteks di setiap panggilan

☐ skip tercatat berbeda dari sukses

☐ versi model dipin, termasuk judge

☐ kolom hasil-landed di dashboard

☐ kredensial ter-scope per agen, per peran

☐ runbook ditulis dan dry-run oleh orang asing

☐ kill switch yang bisa ditemukan manusia jam 3 pagi

Butir 5 dan 7 datang dari praktik audit armada (Pertemuan 10): loop yang skip tak boleh mencatat ok — pembedaan tunggal itu menyembunyikan loop mati selama seminggu dalam kasus terdokumentasi.

Studi kasus · bagian 7 dari 10

Lonjakan token 4×, terdiagnosis dalam sebelas menit

Loop digest Kirana stabil di ~9k token/run selama tiga minggu. Lalu Selasa: 38k. Output terlihat normal. Tanpa snapshot ini cuma bisa dilakukan dengan mengangkat bahu.

Dengan snapshot: diff runs/88/c4.ctx.json terhadap runs/81/c4.ctx.json. Context agen collector membesar oleh dump HTML mentah — "perbaikan kecil" yang ditambahkan developer ke fetcher pada Senin. Satu batas sub-agent (bab 5) diam-diam dihapus, dan rawanya naik ke hulu ke setiap run.

Perbaikan: kembalikan langkah distilasi + assertion anggaran di verifier (gagalkan run bila tokens_in > 12k). Graf token mendatar. Retro menulis dirinya sendiri: "diff snapshot itu adalah seluruh investigasinya."

Workshop · 25 menit

Tulis runbook yang layak untuk loop Anda

Loop A6 Anda, satu halaman, untuk orang asing

  1. Apa yang loop ini lakukan — satu kalimat, dan apa yang tak boleh pernah dilakukannya.
  2. Membaca dashboard — tiga angka dan seperti apa "buruk" untuk masing-masing.
  3. Tiga cek pertama — berurutan, saat ada yang janggal (diff snapshot biasanya #1).
  4. Eskalasi — kapan menjeda loop, siapa dibangunkan, apa yang dikatakan.
  5. Prosedur kill — perintah/klik persisnya, ditulis untuk orang mengantuk.

Tes: serahkan ke pasangan sebelah. Mereka punya 90 detik untuk menemukan kill switch tanpa bertanya pada Anda. Kalau tidak bisa, revisi.

Tugas A7 · dikumpulkan sebelum Pertemuan 8

Instrumenkan loop Anda

Tugas
Tambahkan log terstruktur dan snapshot konteks per panggilan ke loop A6 Anda. Timbulkan satu kegagalan (input buruk, matikan dependensi, kecilkan anggaran) dan replay kegagalannya hanya dari log — tanpa menontonnya langsung. Lalu finalisasi runbook.

Deliverable
Tiga baris log dari replay + satu diff snapshot dengan anotasi ("di sinilah mulai salah") · runbook final · checklist 10 butir, dicentang jujur.

Rubrik
Replay-dari-log benar-benar bekerja 40% · anotasi diff snapshot 30% · runbook lulus tes orang-asang 30%.

Pekan depan: lapisan manusianya — coaching, codifying, dan katalog anti-pattern. Baca bab 16–17.