Pendekatan yang tetap menjaga kompatibilitas Node.js sambil mengisolasi lewat sandbox WASM terdengar menarik.
Minggu ini saya melihat Flowise mengalami masalah besar karena node MCP mengeksekusi input pengguna apa adanya dengan Function(), dan dengan struktur seperti itu rasanya kalau sekali ditembus, semuanya langsung terbuka, jadi agak mengkhawatirkan.
Mungkin bisa dicegah sampai tingkat tertentu dengan sesuatu seperti --safe, tapi sepertinya tetap harus benar-benar dijalankan dulu baru ketahuan.
Saya sempat membuat server MCP dan mengunggahnya ke npm, jadi membaca laporan insiden ini terasa cukup mengerikan.
Pada akhirnya server MCP juga langsung dipublikasikan ke npm dan PyPI, dan cukup sering ada kasus pemasangan tanpa pinning versi. Sistem pelaporan atau hal seperti trusted publisher juga masih belum ada. Meski LiteLLM hanya terekspos sedikit lebih dari 2 jam, kalau jumlah unduhannya sudah sebanyak itu, saya jadi merasa di ranah ini sekali ada yang lolos masuk, dampaknya bisa bertahan cukup lama.
Dari yang saya lihat di sisi Claude Code juga ada kasus di mana pengaturan perlindungan seperti ini tidak diterapkan dengan benar saat pip install, jadi kalau alurnya agen memasang paket sendiri secara otomatis, jadi tidak jelas harus diblok di mana.
Saya dari Repair Life, yang menangani perbaikan Magic Keyboard dan keyboard MacBook. Tentu saja perbaikan individual per tombol juga memungkinkan. Selama umur sirkuit filmnya belum habis, sebenarnya tidak harus selalu diganti satu set penuh, jadi itu cukup disayangkan. Jika kondisinya seperti tombol terus tertekan sehingga input berlanjut, ada kasus di mana titik kontak pada sirkuit film saling tertekan akibat benturan jatuh dari benda kecil namun berat (misalnya sudut iPhone). Dalam kasus seperti ini juga bisa diperbaiki, tetapi meskipun itu pusat servis, tidak semua orang bisa melakukannya dan bisa saja gagal, jadi... Sambil menulis ini, saya jadi berpikir bahwa dari sudut pandang pusat servis resmi, mereka pada akhirnya tidak punya banyak pilihan selain mengambil opsi yang mengurangi tenaga kerja sekaligus memiliki kemungkinan perbaikan yang lebih tinggi.
Melihat proyek ini melaju liar sampai meraih 170 ribu bintang tanpa lisensi, rasanya benar-benar seperti mentalitas era Wild West: "tinju (kode) lebih dulu daripada hukum" sedang terjadi di Korea.
Membayangkan mereka kebingungan sambil berkata, "Lho, kenapa kode kami berjalan di Rust dengan pesan commit berbahasa Korea? Bahkan bintangnya 170 ribu?" saja sudah bikin ngakak.
Setelah menjalankannya sebentar, saya merasa hermes lebih jarang kehilangan memori dibanding openclaw, dan ternyata itu karena ada logika session context replay untuk situasi seperti restart atau fallback model. openclaw juga terus meningkatkan fitur terkait memori, jadi ke depannya sepertinya akan membaik juga.
Fitur perbaikan mandirinya juga mengesankan, karena saat alur kerja yang kompleks terdeteksi, ada logika yang otomatis mengubahnya menjadi skill, dan untuk keperluan modifikasi, ada struktur yang memungkinkan ia menerima source code ke workspace-nya sendiri lewat git dan mengaksesnya secara langsung. Namun, sama sekali tidak ada pengelolaan perubahan antara git source code di workspace dan repositori resmi GitHub, jadi saat diperbarui, perubahan lokal bisa ter-reset. Saya sedang mencoba mencari cara untuk mengatasinya dengan git worktree, tetapi sejauh ini belum ada solusi yang benar-benar rapi... hmm...
Memang benar, sejauh ini belum ada perbedaan yang akan terasa bagi non-developer.
Perbedaan antara hermes agent dan openclaw muncul dari struktur memory dan kemampuan modifikasi diri, tetapi pada kondisi awal yang masih kosong setelah instalasi pertama, hal-hal seperti ini belum terlihat.
Mengingat LLM juga sekadar mengumpulkan banyak informasi, saya paham kalau ini tidak dianggap sebagai tindakan yang terlalu ‘jahat’, tetapi saya tidak yakin apakah ini sesuatu yang bisa dilakukan dengan begitu terang-terangan.
Saya melihat ini lalu rajin... mencobanya menulis. Dan tentang kenapa ini tidak berhasil... saya juga jadi sempat mengunggah tulisan ke GeekNews. hehe
Senang karena otomatis tertangkap di artikel rekomendasi GeekNews untuk dibaca bersama! :) Mengapa orkestrasi multi-agent sering tidak berjalan dengan baik?
Wow, bahkan setelah membaca isi artikelnya saya masih merasa bingung, tetapi setelah merujuk ke repo Git tersebut saya mulai melihat arahnya. Terima kasih banyak.
Karena bm25 kurang kuat untuk pencarian bahasa Korea, saya juga menerapkan guardrail terpisah agar pencarian dalam bahasa Korea tetap berjalan dengan baik.
Dalam konteks besar, ini pada dasarnya adalah pencarian percakapan lama, jadi jika isu pengorganisasiannya bisa ditata dengan baik, menurut saya ini ide yang bagus. Dalam praktiknya, saya juga melihat ini sangat membantu untuk merapikan proyek.
Saya juga sudah mencoba mengimplementasikannya. Saya menambahkan sedikit agar Obsidian vault bisa terhubung ke backup GitHub saat menggunakan beberapa perangkat keras. Saya juga membuat parser untuk Codex dan Gemini lalu menyertakannya. https://github.com/hang-in/seCall
Jika Anda sudah menggunakan tim agen Claude Code, tidak ada yang terlalu istimewa.
Namun, membangun infrastruktur dengan memanfaatkan agents atau skills agar bisa dilanjutkan bahkan di sesi baru, termasuk informasi susunan tim, terasa praktis.
Saat tim disusun secara manual, hal-hal seperti boilerplate untuk tim terus berulang.
Ada satu masalah: karena lingkungannya mempertimbangkan baik subagent maupun tim agen, dalam pola Supervisor sering muncul situasi yang tidak tepat di mana supervisor mendelegasikan pekerjaan ke subagent meskipun tim sudah terbentuk.
Berani sekali mereka mencuri barang yang dicuri Anthropic dari para programmer manusia??
-Elon Musk
Setelah clean room, kini giliran ketegangan hukum. Keren, saya suka.
Pendekatan yang tetap menjaga kompatibilitas Node.js sambil mengisolasi lewat sandbox WASM terdengar menarik.
Minggu ini saya melihat Flowise mengalami masalah besar karena node MCP mengeksekusi input pengguna apa adanya dengan
Function(), dan dengan struktur seperti itu rasanya kalau sekali ditembus, semuanya langsung terbuka, jadi agak mengkhawatirkan.Mungkin bisa dicegah sampai tingkat tertentu dengan sesuatu seperti
--safe, tapi sepertinya tetap harus benar-benar dijalankan dulu baru ketahuan.Saya sempat membuat server MCP dan mengunggahnya ke npm, jadi membaca laporan insiden ini terasa cukup mengerikan.
Pada akhirnya server MCP juga langsung dipublikasikan ke npm dan PyPI, dan cukup sering ada kasus pemasangan tanpa pinning versi. Sistem pelaporan atau hal seperti trusted publisher juga masih belum ada. Meski LiteLLM hanya terekspos sedikit lebih dari 2 jam, kalau jumlah unduhannya sudah sebanyak itu, saya jadi merasa di ranah ini sekali ada yang lolos masuk, dampaknya bisa bertahan cukup lama.
Dari yang saya lihat di sisi Claude Code juga ada kasus di mana pengaturan perlindungan seperti ini tidak diterapkan dengan benar saat
pip install, jadi kalau alurnya agen memasang paket sendiri secara otomatis, jadi tidak jelas harus diblok di mana.Rapi sekali.
Bagian penuh harapan: menemukan kerentanan Linux
Bagian penuh keputusasaan: penghapusan bounding di curl
Terus bertambah ya
Vercel di http://localhost:4000
GitHub di http://localhost:4001
Google di http://localhost:4002
Slack di http://localhost:4003
Apple di http://localhost:4004
Microsoft di http://localhost:4005
AWS di http://localhost:4006
Di https://github.com/vercel-labs/emulate/releases/tag/v0.4.0,
Next.js, MongoDB, Stripe, Resend (email), dan Okta juga sudah ditambahkan.
Saya dari Repair Life, yang menangani perbaikan Magic Keyboard dan keyboard MacBook. Tentu saja perbaikan individual per tombol juga memungkinkan. Selama umur sirkuit filmnya belum habis, sebenarnya tidak harus selalu diganti satu set penuh, jadi itu cukup disayangkan. Jika kondisinya seperti tombol terus tertekan sehingga input berlanjut, ada kasus di mana titik kontak pada sirkuit film saling tertekan akibat benturan jatuh dari benda kecil namun berat (misalnya sudut iPhone). Dalam kasus seperti ini juga bisa diperbaiki, tetapi meskipun itu pusat servis, tidak semua orang bisa melakukannya dan bisa saja gagal, jadi... Sambil menulis ini, saya jadi berpikir bahwa dari sudut pandang pusat servis resmi, mereka pada akhirnya tidak punya banyak pilihan selain mengambil opsi yang mengurangi tenaga kerja sekaligus memiliki kemungkinan perbaikan yang lebih tinggi.
Melihat proyek ini melaju liar sampai meraih 170 ribu bintang tanpa lisensi, rasanya benar-benar seperti mentalitas era Wild West: "tinju (kode) lebih dulu daripada hukum" sedang terjadi di Korea.
Membayangkan mereka kebingungan sambil berkata, "Lho, kenapa kode kami berjalan di Rust dengan pesan commit berbahasa Korea? Bahkan bintangnya 170 ribu?" saja sudah bikin ngakak.
Setelah menjalankannya sebentar, saya merasa hermes lebih jarang kehilangan memori dibanding openclaw, dan ternyata itu karena ada logika
session context replayuntuk situasi seperti restart atau fallback model. openclaw juga terus meningkatkan fitur terkait memori, jadi ke depannya sepertinya akan membaik juga.Fitur perbaikan mandirinya juga mengesankan, karena saat alur kerja yang kompleks terdeteksi, ada logika yang otomatis mengubahnya menjadi
skill, dan untuk keperluan modifikasi, ada struktur yang memungkinkan ia menerima source code ke workspace-nya sendiri lewat git dan mengaksesnya secara langsung. Namun, sama sekali tidak ada pengelolaan perubahan antara git source code di workspace dan repositori resmi GitHub, jadi saat diperbarui, perubahan lokal bisa ter-reset. Saya sedang mencoba mencari cara untuk mengatasinya dengangit worktree, tetapi sejauh ini belum ada solusi yang benar-benar rapi... hmm...Memang benar, sejauh ini belum ada perbedaan yang akan terasa bagi non-developer.
Perbedaan antara hermes agent dan openclaw muncul dari struktur memory dan kemampuan modifikasi diri, tetapi pada kondisi awal yang masih kosong setelah instalasi pertama, hal-hal seperti ini belum terlihat.
Mengingat LLM juga sekadar mengumpulkan banyak informasi, saya paham kalau ini tidak dianggap sebagai tindakan yang terlalu ‘jahat’, tetapi saya tidak yakin apakah ini sesuatu yang bisa dilakukan dengan begitu terang-terangan.
Saya melihat ini lalu rajin... mencobanya menulis. Dan tentang kenapa ini tidak berhasil... saya juga jadi sempat mengunggah tulisan ke GeekNews. hehe
Senang karena otomatis tertangkap di artikel rekomendasi GeekNews untuk dibaca bersama! :)
Mengapa orkestrasi multi-agent sering tidak berjalan dengan baik?
Apakah ini bot? Kecerdasan alien (???)
Wow, bahkan setelah membaca isi artikelnya saya masih merasa bingung, tetapi setelah merujuk ke repo Git tersebut saya mulai melihat arahnya. Terima kasih banyak.
Karena
bm25kurang kuat untuk pencarian bahasa Korea, saya juga menerapkan guardrail terpisah agar pencarian dalam bahasa Korea tetap berjalan dengan baik.Dalam konteks besar, ini pada dasarnya adalah pencarian percakapan lama, jadi jika isu pengorganisasiannya bisa ditata dengan baik, menurut saya ini ide yang bagus. Dalam praktiknya, saya juga melihat ini sangat membantu untuk merapikan proyek.
Saya juga sudah mencoba mengimplementasikannya. Saya menambahkan sedikit agar Obsidian vault bisa terhubung ke backup GitHub saat menggunakan beberapa perangkat keras. Saya juga membuat parser untuk Codex dan Gemini lalu menyertakannya. https://github.com/hang-in/seCall
Jika Anda sudah menggunakan tim agen Claude Code, tidak ada yang terlalu istimewa.
Namun, membangun infrastruktur dengan memanfaatkan agents atau skills agar bisa dilanjutkan bahkan di sesi baru, termasuk informasi susunan tim, terasa praktis.
Saat tim disusun secara manual, hal-hal seperti boilerplate untuk tim terus berulang.
Ada satu masalah: karena lingkungannya mempertimbangkan baik subagent maupun tim agen, dalam pola Supervisor sering muncul situasi yang tidak tepat di mana supervisor mendelegasikan pekerjaan ke subagent meskipun tim sudah terbentuk.
Pembaruan situs resmi sudah dilakukan sebelum perilisan Gnuboard 7.