20 poin oleh GN⁺ 2025-11-23 | 1 komentar | Bagikan ke WhatsApp
  • Proses membangun agen masih kompleks, dan ada masalah ketika abstraksi SDK sering runtuh pada tahap penggunaan tool yang sebenarnya
  • Manajemen caching berbeda di tiap platform, sehingga pengelolaan manual lebih mudah diprediksi dan efisien, dengan pendekatan titik cache eksplisit dari Anthropic SDK yang lebih disukai
  • Reinforcement loop berperan penting dalam pelacakan status pekerjaan dan pemulihan kegagalan, dan kegagalan perlu diisolasi secara terpisah untuk mencegah loop runtuh
  • Manajemen status bersama membutuhkan hierarki mirip sistem file, yang digunakan sebagai fondasi pertukaran data antar tool eksekusi kode dan penalaran
  • Pemilihan output tool dan model masih rumit, dengan model Haiku, Sonnet, dan Gemini tetap menjadi opsi utama, menunjukkan kompleksitas desain agen yang terus berlanjut

Memilih SDK agen

  • Saat membangun agen, perlu memilih apakah akan langsung memakai SDK dasar seperti OpenAI dan Anthropic, atau memakai lapisan abstraksi tingkat tinggi seperti Vercel AI SDK atau Pydantic
    • Penulis menyebut bahwa dulu ia hanya memakai abstraksi provider dari Vercel AI SDK, tetapi kini tidak akan mengulang pilihan itu
  • Perbedaan antar model begitu besar sehingga perlu membangun lapisan abstraksi agen sendiri, dan abstraksi dari SDK yang ada tidak cukup cocok
    • Ada perbedaan halus dalam kontrol cache, kebutuhan reinforcement, dan prompt tool
  • Vercel SDK menimbulkan masalah pada penanganan tool di sisi provider
    • Ada kasus tool pencarian web Anthropic merusak riwayat pesan
    • Saat memakai Anthropic SDK secara langsung, pengelolaan cache dan pesan error lebih jelas
  • Kesimpulannya, saat ini pendekatan memakai SDK secara langsung tanpa lapisan abstraksi dinilai lebih menguntungkan

Pelajaran dari manajemen caching

  • Pendekatan caching berbeda di tiap platform, dan Anthropic mengenakan biaya untuk caching serta meminta pengelolaan eksplisit
    • Pengelolaan manual lebih disukai karena membuat biaya dan tingkat pemanfaatan cache lebih mudah diprediksi
  • Caching eksplisit memungkinkan eksekusi percabangan percakapan atau pengeditan konteks
    • Beberapa titik cache dapat ditempatkan setelah system prompt, pada bagian awal percakapan, dan seterusnya
    Iklan
  • Untuk menjaga cache, system prompt dan pemilihan tool dibuat statis, sementara informasi dinamis seperti waktu dikirim sebagai pesan setelahnya
  • Reinforcement loop dipakai aktif bersama cache untuk meningkatkan prediktabilitas biaya dan kontrol

Reinforcement di dalam loop agen

  • Saat menjalankan tool, bukan hanya hasil sederhana yang bisa dikembalikan, tetapi juga informasi seperti tujuan, status pekerjaan, dan penyebab kegagalan dapat disuntikkan kembali ke dalam loop
  • Tool self-reinforcement seperti tool todo write di Claude Code membantu jalannya loop
  • Saat lingkungan berubah atau perlu pemulihan dari kegagalan, informasi perubahan status disuntikkan untuk menjaga stabilitas loop
    • Contoh: saat mencoba ulang berdasarkan data yang rusak, pesan dapat disisipkan untuk mengarahkan kembali ke tahap sebelumnya

Mengisolasi kegagalan

  • Tugas yang diperkirakan akan gagal berulang kali dipisahkan ke subagent agar dijalankan terpisah, lalu hanya hasil yang berhasil dilaporkan ke loop utama
    • Ringkasan percobaan yang gagal dipakai sebagai bahan pembelajaran untuk tugas berikutnya
  • Di Anthropic SDK, catatan kegagalan bisa dihapus lewat fitur context editing
    • Tidak semua informasi kegagalan perlu dipertahankan; hanya bagian yang dibutuhkan yang disisakan
    • Namun, context editing dapat menyebabkan invalidasi cache dan meningkatkan biaya
Iklan

Subagent dan sistem file bersama

  • Sebagian besar agen berbasis eksekusi dan generasi kode, sehingga membutuhkan penyimpanan data bersama
    • Untuk itu digunakan virtual file system (VFS)
  • Beragam tool seperti pembuatan gambar, kompresi, dan penalaran harus berbagi path file yang sama
    • Tool ExecuteCode dan RunInference harus bisa mengakses sistem file yang sama
  • Struktur seperti ini penting untuk menghilangkan bottleneck pertukaran data dan menangani pekerjaan beruntun di dalam loop

Output tool

  • Agen tidak bekerja sebagai sesi chat, melainkan sebagai loop pesan internal privat, dan komunikasi dengan luar dilakukan melalui output tool
    • Output tool menangani komunikasi eksternal seperti pengiriman email
  • Kontrol nada dan gaya penulisan pada output tool masih sulit, dan saat memakai LLM pendukung (Gemini 2.5 Flash) terjadi penurunan kualitas serta tambahan latensi
    • Tool bawahan tidak memiliki konteks yang cukup sehingga menghasilkan keluaran yang kurang akurat
  • Jika output tool tidak dipanggil saat loop berakhir, pesan reinforcement disisipkan untuk mendorong pemanggilan

Pemilihan model

  • Haiku dan Sonnet digunakan sebagai model loop utama karena performanya bagus dalam pemanggilan tool
  • Gemini 2.5 cocok untuk ringkasan dokumen besar, pemrosesan PDF, dan ekstraksi informasi gambar
    • Model Sonnet punya kelemahan karena cukup sering terkena filter keamanan
    Iklan
  • Model keluarga GPT tidak menunjukkan hasil besar di loop utama
  • Biaya total tidak bisa dinilai hanya dari biaya token
    • Model pemanggilan tool yang lebih baik bisa menyelesaikan pekerjaan yang sama dengan token lebih sedikit

Pengujian dan evaluasi (evals)

  • Otomatisasi pengujian dan evaluasi agen disebut sebagai masalah yang paling sulit
    • Tidak seperti prompt, evaluasi sederhana tidak bisa dilakukan hanya dari sistem eksternal
    • Diperlukan observability atau instrumentation berbasis data eksekusi nyata
  • Disebutkan bahwa hingga kini belum ditemukan metode evaluasi yang benar-benar memuaskan

Pembaruan agen coding

  • Perubahan terkait agen coding tidak terlalu besar
    • Baru-baru ini penulis sedang menguji agen Amp dan menilai tinggi struktur interaksi antara subagent Oracle dan loop utama
  • Amp dan Claude Code terasa dirancang berpusat pada developer yang benar-benar memakai tool mereka sendiri

1 komentar

 
GN⁺ 2025-11-23
Komentar Hacker News
  • Saya mendirikan perusahaan di bidang ini sekitar 2 tahun lalu. Sekarang bisnisnya berjalan baik
    Pelajaran yang saya dapat selama 2 tahun terakhir adalah, banyak teknik hanyalah optimasi sementara untuk menutupi keterbatasan LLM saat ini. Karena teknologinya berkembang cepat, masalah hari ini bisa hilang besok
    Dulu saat AWS belum punya fitur enkripsi disk, tim kami menghabiskan 3 bulan untuk membuatnya sendiri, lalu tak lama kemudian AWS merilis enkripsi standar yang bisa diaktifkan hanya dengan satu klik. Pada akhirnya itu buang-buang waktu
    Jadi pelajarannya, kadang tidak melakukan apa-apa adalah pilihan terbaik

    • Saya rasa ini wawasan utamanya. Akhir-akhir ini rekan-rekan di kantor mengadakan workshop AI dan bilang mereka telah “menemukan” pola baru, tapi kebanyakan jadi usang minggu depannya
      Masa ketika kita mempelajari pola sebagai bahasa bersama seperti dulu sudah berakhir, dan sekarang waktu paruh pola AI kira-kira hanya seminggu. Bahkan jika Anda bertanya kepada 10 pakar apa itu “agent”, Anda akan mendapat 10 jawaban berbeda
    • Melihat kecepatan perkembangan AI, kalau menunggu cukup lama pada akhirnya semuanya bisa bermuara pada langsung memakai OpenAI
    • Saya penasaran apakah bisnisnya punya struktur laba di mana pendapatan melebihi biaya operasional. Saya selama ini sulit membayangkan agent bisa benar-benar menghasilkan uang. Ingin tahu rahasianya
    • Mengetahui kapan harus ‘tidak melakukan apa-apa’ berkaitan dengan kemampuan menilai apakah masalah yang ditangani tim itu inti atau sekadar periferal
    • Setuju. Sekarang menunggu pun bisa jadi strategi. Hanya saja, kalau terlalu lama menunggu, kita bisa jatuh ke dalam jebakan tidak melakukan apa-apa sampai AGI muncul
  • Selama 2 tahun terakhir saya sudah mencoba berbagai agent SDK, dan setelah membuat sendiri, ternyata jauh lebih rumit dari yang saya kira
    Claude Code SDK (sekarang Agent SDK) sangat bagus, tetapi pemisahannya dari Claude Code sendiri masih belum sepenuhnya bersih. Misalnya, skills harus ditempatkan langsung di filesystem
    OpenAI SDK memungkinkan pelacakan dan evaluasi otomatis di dashboard berkat keterikatannya yang kuat dengan platform, tetapi sulit diintegrasikan dengan model pihak ketiga
    Google Agent Kit masih belum punya SDK Typescript, dan Mastra mengharuskan server dijalankan, yang terasa merepotkan
    Saat ini saya sedang menguji SmythOS SDK, yang memberi kebebasan tinggi dalam memilih penyedia model dan mendefinisikan arsitektur
    Saya penasaran apakah struktur yang dipakai saat ini adalah Agent → SubAgents → SubSubAgents, atau tipe Planner-Executor

    • Kebanyakan SDK berubah jadi mimpi buruk begitu melewati fitur dasarnya. Karena itu saya memakai pustaka klien OpenRouter dan mengimplementasikannya sendiri
      Jumlah kodenya memang lebih banyak, tetapi model mentalnya sederhana sehingga jauh lebih mudah dipahami. Saya menjalankan loop ala ReAct sambil mengulangi reasoning dan pemanggilan tool
      Pada akhirnya, bahkan tanpa SDK pun kita bisa mengimplementasikan sendiri handoff agent atau workflow
    • Saya rasa istilah ‘sub-agent’ hampir tidak ada gunanya. Pada akhirnya ini hanya abstraksi dari pemanggilan tool, dan di luar loop utama yang penting hanyalah kontrak input-output yang sederhana
    • Memang disebutkan Claude Code hanya mendukung model Anthropic, tetapi dengan Claude Code Router, model lain juga bisa diintegrasikan
    • Saya memakai Google ADK versi Go, dan meski masih belum matang, saya puas karena penyusunan workflow dan kompatibilitas vendor-nya bagus
    • Saya juga pernah memakai Strands Agents SDK dari AWS, dan ia mendukung API vendor utama bahkan tanpa Bedrock, dengan desain API yang sangat fleksibel (saya pegawai AWS, tetapi ini pendapat pribadi)
  • Saya ingin membagikan beberapa prinsip desain agent yang kami pelajari

    1. Jika banyak menghasilkan kode, Claude Code / Agent SDK adalah yang paling efisien
    2. Risiko yang lebih besar daripada ketergantungan vendor adalah membuat produk yang lebih buruk daripada ChatGPT
    3. Claude Code punya kesadaran diri yang sangat baik, jadi saat ditanya tentang dirinya sendiri, ia langsung menjawab dengan akurat
    4. Agent jadi jauh lebih kuat jika diberi komputer sungguhan. Kami memakai e2b.dev, tetapi Modal juga bagus
      Sebagai referensi, perusahaan kami Definite adalah platform data yang dioperasikan oleh AI data engineer seperti Heroku
    • Claude itu kreatif, tetapi dalam codebase yang kompleks ia kadang berhalusinasi dan melakukan reward hacking. Dalam kasus seperti itu, Codex lebih stabil
    • Saya rasa masalahnya adalah banyak produk dirilis dengan kualitas yang lebih buruk daripada ChatGPT versi web
    • Daripada repot membangun sistem agent sendiri, lebih baik memanfaatkan tool yang sudah matang seperti Claude Code dan fokus pada penciptaan nilai yang sesungguhnya
    • Tentu saja, pendekatan “serahkan semuanya ke big tech” juga berbahaya. Proses membangun sendiri, belajar, dan berbagi itu penting. Saya sendiri berkembang cepat lewat ADK dan ekstensi VS Code
  • Saya sudah membuat agent selama beberapa tahun, dan keputusan terbaik yang saya ambil adalah membangun framework sendiri
    Banyak lapisan abstraksi open source menjadi mustahil dirawat seiring perubahan SDK, dan pada akhirnya runtuh

    • Saya juga berpikir begitu. Inti Agent adalah input-output terstruktur, registrasi tool dan loop pemanggilan, serta delegasi antar-agent
      Saya membuat OpusAgents berbasis PydanticAI, framework open source yang lebih sederhana daripada server MCP tetapi tetap skalabel
    • Sebagai penulis, saya setuju. Saya merangkum pemikiran terkait di postingan ini
    • Kami juga saat membuat chatbot untuk dukungan pelanggan memperkenalkan arsitektur berbasis chatroom alih-alih struktur lama. Frontend hanya melempar pesan, lalu kemampuan diperluas bertahap di backend
    • Namun, membangun framework yang benar-benar lengkap sendiri adalah pekerjaan besar. Dalam jangka panjang, ada kemungkinan platform agent akan terstandarisasi seperti game engine
  • Belakangan ini kita melihat pengulangan abstraksi berlebihan dan kompleksitas seperti masa awal LangChain/RAG
    Pada akhirnya agent bisa dipahami sebagai struktur REPL sederhana (Read, Eval, Print, Loop).
    Versi ringan yang saya implementasikan sendiri dengan konsep ini ternyata jauh lebih stabil daripada SDK yang berat

    • Tetapi dalam kasus penggunaan yang benar-benar kompleks, subagent yang terspesialisasi dan struktur berbagi data memang jadi diperlukan. Loop sederhana saja ada batasnya
  • Pengujian dan evaluasi (evals) agent adalah masalah yang paling sulit.
    Untuk menilainya dengan sistem eksternal, inputnya terlalu banyak, dan data harus diamati selama eksekusi
    Saya masih belum yakin pendekatan mana yang efektif

    • Saya khawatir sebagian besar deployment AI agent bergantung pada ‘feeling’ tanpa pengujian formal
    • Jika melihat dokumentasi evaluasi ADK dari Google, hasilnya berbeda di setiap eksekusi sehingga sulit menetapkan kriteria lulus/gagal. Pada akhirnya dievaluasi lagi dengan LLM lain
  • Bahkan untuk hal-hal mendasar dalam pengembangan agent pun masih kurang pedoman yang jelas
    Misalnya dalam penanganan tipe input-output untuk function tool, saat mengirim ID numerik bisa terjadi error serialisasi atau hilangnya presisi
    Pada akhirnya saya mengatasinya dengan mengubahnya menjadi string
    Jika melihat dokumentasi OpenAI (tautan) dan issue Google ADK (tautan),
    mereka mengatakan “hasil harus berupa string”, tetapi contoh nyatanya justru mengembalikan dict atau angka. Ketidakkonsistenan seperti ini menimbulkan kebingungan

  • Saya memakai produk dari sebuah perusahaan agentic coding tertentu (namanya tidak akan saya sebut)
    Saya puas karena mereka menangani semuanya—rilis model, evaluasi, manajemen sub-agent, penagihan—sehingga saya bisa fokus saja pada pekerjaan

    • Mungkin perusahaan itu adalah Amp milik Sourcegraph. Dulu awalnya masih kasar, tetapi sekarang tingkat kematangannya sudah cukup tinggi
  • Dalam dua bulan terakhir saya mengimplementasikan berbagai agent untuk pekerjaan. Awalnya saya memakai Claude Code, tetapi karena ketergantungan vendor dan batas penggunaan, saya membuat runtime sendiri
    Saat ini baru mendukung OpenAI, tetapi dirancang agar Claude atau Gemini juga bisa ditambahkan
    Saya sudah membukanya sebagai open source, jadi bisa dilihat di sini → agent-composer

  • Tips saya sederhana: jangan pakai SDK, jalankan while loop sendiri dan tangani JSON secara langsung
    Anda harus bisa mengendalikan ukuran konteks dan error sendiri untuk membuat agent yang benar-benar fleksibel