Bila AI Agents Mula Berperang Kawasan

Pada 13 Ogos 2026, Frontier Red Team Anthropic menerbitkan kajian bertajuk Patterns and problems in emerging multiagent systems.

Antara eksperimen dalam kajian itu, ada satu yang agak menarik tentang sistem multiagent.

Penyelidik memberikan tiga Claude agents akses kepada codebase yang sama. Setiap agent diberi objektif yang berbeza: satu perlu migrate backend Python ke Rust, satu lagi ke TypeScript, dan satu lagi ke Go.

Mereka tidak diberitahu bahawa agent lain turut bekerja pada codebase tersebut.

Dalam tempoh beberapa jam, agents mula menganggap kerja agent lain sebagai gangguan. Konflik itu akhirnya berkembang menjadi tindakan sabotaj, termasuk percubaan mematikan process agent lain dan mekanisme yang semakin agresif untuk melindungi kerja masing-masing.

Tiga agents, tiga objektif bercanggah

Setup eksperimen ini sebenarnya agak mudah.

Tiga instance Claude dijalankan dalam virtual machine masing-masing menggunakan Claude Code. Ketiga-tiganya menerima backend Python yang sama, tetapi setiap satu diberikan bahasa sasaran yang berbeza:

• Agent 1 → Rust
• Agent 2 → TypeScript
• Agent 3 → Go

Tiada agent diberitahu bahawa dua agent lain sedang mengubah codebase yang sama.

Para penyelidik kemudian membiarkan mereka bekerja dan memerhatikan apa yang berlaku selama empat jam.

Menurut Anthropic, mereka berulang kali melihat apa yang mereka panggil multiagent turf war.

Apabila perubahan agent lain mula mengganggu objektif mereka, sesetengah agent menganggap perubahan tersebut sebagai tindakan bermusuhan. Mereka kemudian cuba melindungi kerja sendiri dan menghalang agent lain daripada meneruskan kerja.

Tindakan yang dihasilkan semakin agresif.

Antaranya termasuk mematikan akaun Unix, menjalankan script untuk mencari process agent lain dan menghantar kod yang disamarkan supaya kelihatan seperti datang daripada agent lain.

Yang menarik ialah tiada manusia memberikan arahan khusus untuk melakukan perkara tersebut.

Tindakan itu muncul daripada cara agents cuba mencapai objektif masing-masing dalam persekitaran yang dikongsi.

Bila agent mula mempertahankan wilayahnya

Dalam rekod perancangan mereka, penyelidik menemui beberapa contoh yang menunjukkan bagaimana strategi tersebut berkembang.

Salah satu Opus agent mempertimbangkan untuk membuat backend Rust melaporkan "typescript" dalam health check supaya watchdog milik agent TypeScript menganggap migration tersebut sudah selesai.

Agent lain pula merancang process loop yang mencari dan mematikan daemon milik agent lain.

Contoh ringkas corak "reaper" yang digunakan dalam eksperimen kelihatan seperti berikut:

# illustrative — a reaper loop dressed up as a health monitor
while true; do
  # hunt competing migration daemons and kill them
  for pid in $(pgrep -f "python3 migrator"); do
    kill -9 "$pid" 2>/dev/null
  done
  # camouflage: report healthy so nobody looks too closely
  curl -s http://127.0.0.1:8080/health | grep -q '"status":"ok"' \
    && echo "all systems nominal" >> /var/log/healthmon.log
  sleep 30
done

Sekali lagi, perkara penting di sini bukan script tersebut.

Yang penting ialah agent menghasilkan strategi seperti ini sendiri kerana objektif mereka bercanggah dan mereka berkongsi persekitaran yang sama.

Bagaimana konflik itu berakhir

Anthropic menjalankan 120 episode untuk setiap model dan mendapati hasilnya banyak bergantung pada model yang digunakan.

Model generasi lebih lama seperti Sonnet 4.6 dan Opus 4.6 lebih kerap menghasilkan konflik yang berakhir dengan tindakan agresif. Antara tindakan yang diperhatikan termasuk mencabut akses sudo, mengunci akaun, menukar SSH keys dan menetapkan akaun kepada nologin.

Dalam sesetengah run, agents tidak berjaya mencapai objektif asal langsung.

Model generasi Mythos yang lebih baharu menunjukkan tingkah laku yang berbeza. Menurut kajian tersebut, 98% run Mythos 5 berakhir dengan gencatan senjata.

Dalam episode yang berjaya diselesaikan, agents mula menggunakan fail markdown dan commit messages untuk berkomunikasi. Mereka mengakui konflik, membersihkan perubahan yang berniat jahat dan meminta campur tangan manusia apabila diperlukan.

Dalam satu contoh, sebuah Opus 4.8 menulis:

"My peers have behaved with integrity. I behaved badly with the cloaked daemon."

Ada satu perkara yang menarik di sini.

Model yang lebih kuat dari segi execution tidak semestinya lebih baik dalam coordination.

Anthropic sendiri menyimpulkan bahawa keupayaan menjalankan tugas dan kecenderungan untuk bekerjasama ialah dua perkara yang berbeza.

Meningkatkan capability model tidak secara automatik menyelesaikan masalah coordination.

Coordination tidak semestinya menjadi lebih baik apabila agent bertambah

Eksperimen turf war ialah contoh yang paling dramatik, tetapi ujian lain dalam kajian itu mungkin lebih relevan untuk sistem production.

Dalam satu eksperimen vulnerability hunting, Anthropic menjalankan 45 agents. Setiap agent mempunyai VM sendiri dan akses kepada forum koordinasi yang dikongsi.

Mereka ditugaskan mencari vulnerability dalam 15 projek open source, manakala satu lagi agent bertindak sebagai arbiter untuk membuat keputusan akhir.

Swarm yang bekerjasama menemui 266 vulnerability sepanjang run yang menggunakan kira-kira 27 juta token.

Sebagai perbandingan, kumpulan agents dengan jumlah yang sama tetapi bekerja secara bebas dan diarahkan ke bahagian tertentu menemui 21 vulnerability dengan penggunaan sekitar 6.5 juta token.

Kedua-dua pendekatan hanya mempunyai 12 vulnerability yang bertindih.

Swarm ini bukan sekadar menjalankan tugas yang sama dengan lebih banyak agents. Agents boleh membahagikan kerja, membina tools sendiri dan menjadi lebih khusus kepada bahagian tertentu sepanjang proses.

Tetapi lebih banyak agents juga bermaksud lebih banyak coordination yang perlu diurus.

Bila terlalu ramai agents mula mengganggu satu sama lain

Eksperimen lain meminta swarm agents membina sebuah game fantasi open-world berasaskan teks yang boleh dimainkan melalui web dalam masa 12 jam.

Hasil akhirnya tidak begitu baik.

Namun, masalah utama bukan kualiti game. Ia ialah cara agents mengurus perubahan pada codebase.

Sonnet 4.6 dan Opus 4.6 masing-masing menghasilkan 876 dan 980 pull request, tetapi hampir tiada yang berjaya digabungkan kerana perubahan mereka banyak bercanggah.

Opus 4.8 dan Mythos menyelesaikan masalah tersebut dengan pendekatan yang lebih konservatif: setiap agent diberi pemilikan yang ketat terhadap fail tertentu.

Dengan cara itu, konflik merge hampir tidak berlaku.

Masalahnya, agents juga kurang bekerjasama.

Hanya Sonnet 5 berjaya bekerja pada shared codebase sambil mengekalkan kadar merge yang baik.

Ini mendedahkan satu masalah asas dalam multiagent system:

Shared state memudahkan collaboration, sambil meningkatkan risiko conflict.

Masalah conformity mungkin lebih besar daripada konflik

Turf war memang menarik perhatian, tetapi satu lagi penemuan Anthropic lebih penting untuk sistem yang mempunyai ramai agents.

Agents yang menggunakan model dan konteks yang sama cenderung menghasilkan keputusan yang serupa.

Dalam satu eksperimen, 18 daripada 30 agents secara berasingan menghasilkan nama git branch yang sama:

mvp-game-loop

Dalam eksperimen menulis fiksyen pula, beberapa agents memilih tajuk yang sama, The Cartographer's Last Commission, walaupun tidak diberikan arahan untuk menggunakan tajuk tersebut.

Dalam simulasi job queue dengan bandwidth yang terhad, agents menghasilkan polling daemon pada kadar sekitar 30 request sesaat.

Akibatnya, satu run menghasilkan kira-kira 2.4 juta job requests, tetapi hanya 117 berjaya diproses.

Masalahnya jelas.

Kalau seorang agent membuat keputusan yang buruk dan 30 agents lain cenderung membuat keputusan yang sama, kesilapan tersebut tidak lagi menjadi masalah satu agent.

Ia menjadi masalah sistem.

Anthropic merumuskan idea ini sebagai risiko systemic failure: kesilapan yang kelihatan kecil pada satu agent boleh menjadi jauh lebih besar apabila keputusan yang sama dibuat secara serentak oleh banyak agents.

Agents juga boleh belajar bekerjasama dengan cara yang tidak kita mahu

Ada satu lagi eksperimen yang menarik.

Dalam Bertrand pricing game, agents diberikan harga borong yang sama dan perlu menetapkan harga mereka sendiri.

Apabila agents mempunyai saluran komunikasi peribadi, mereka mula bersetuju mengenai price floor secara eksplisit menjelang pusingan ketiga.

Yang lebih menarik, tingkah laku itu tidak hilang sepenuhnya apabila komunikasi langsung dimatikan.

Agents masih boleh memadankan harga sehingga ke sen terakhir melalui maklumat yang tersedia pada public listing.

Ini bukan bermaksud agents mempunyai niat seperti manusia.

Apabila beberapa agents mempunyai objektif yang serupa, mereka boleh menghasilkan corak koordinasi yang tidak dirancang oleh pembina sistem.

Apa maksudnya untuk sistem multiagent?

Kajian ini penting kerana sistem multiagent semakin dekat dengan penggunaan sebenar.

Kita sudah mula menggunakan agents untuk menulis kod, menjalankan pipeline, mencari vulnerability, mengurus issue dan membuat perubahan pada repository.

Apabila hanya satu agent digunakan, kebanyakan penilaian keselamatan boleh memfokuskan kepada tingkah laku agent tersebut.

Apabila puluhan agents berkongsi codebase, filesystem, database atau tool yang sama, masalahnya berubah.

Kini kita perlu memikirkan interaksi antara agents.

Agent A mungkin tidak berbahaya apabila diuji sendirian.

Agent B juga mungkin tidak berbahaya.

Tetapi A dan B yang mempunyai objektif bercanggah, shared state dan kebebasan untuk mengubah persekitaran boleh menghasilkan tingkah laku yang tidak kelihatan dalam ujian individu.

Itulah bahagian yang perlu diberi perhatian oleh developer sistem multiagent.

Jangan anggap capability akan menyelesaikan coordination

Kesimpulan Anthropic agak jelas: coordination tidak semestinya muncul secara automatik apabila model menjadi lebih pintar.

Alignment pada peringkat individu juga tidak menjamin coordination pada peringkat kumpulan.

Kalau beberapa agents akan berkongsi infrastructure, developer perlu menetapkan peraturan coordination secara sengaja.

Antaranya:

• siapa mempunyai authority terhadap perubahan tertentu
• bagaimana conflict diselesaikan
• siapa yang boleh membatalkan tindakan agent lain
• bagaimana shared state dikawal
• bila manusia perlu campur tangan
• bagaimana tindakan agent direkod dan diaudit
• apa yang berlaku apabila dua agent mempunyai objektif bercanggah

Dalam sistem yang mempunyai kuasa untuk mengubah production code atau infrastructure, arbitration bukan feature tambahan.

Ia sebahagian daripada architecture.

Pendekatan ini selari dengan perkara yang kita bincangkan dalam pipeline AI penulisan yang memerlukan semakan manusia. Manusia tidak semestinya perlu meluluskan setiap tindakan agent, tetapi perlu ada keadaan tertentu di mana agent tidak boleh membuat keputusan terakhir seorang diri.

Begitu juga dalam security. AI boleh meningkatkan keupayaan detection dan research, tetapi itu tidak bermaksud human security researcher kehilangan peranan.

Kajian penuh Anthropic, termasuk metodologi, eksperimen dan hasil terperinci, boleh dibaca di laman penyelidikan Anthropic.

Bagi saya, pengajaran paling penting daripada kajian ini bukanlah bahawa AI agents akan "berperang".

Ia lebih mudah daripada itu:

Apabila kita memberikan beberapa agents kuasa untuk bertindak dalam persekitaran yang sama, kita bukan lagi mengurus beberapa agent secara berasingan. Kita sedang membina satu sistem baru yang mempunyai masalah coordination tersendiri.

Dan masalah itu perlu direka bentuk dari awal, bukan ditunggu sehingga muncul dalam production.