Teruskan Judul Asli: Saya Melihat Kerangka Agen Generasi Berikutnya dalam Project89

Untuk langsung ke intinya, @project_89mengadopsi pendekatan yang benar-benar baru dalam merancang Kerangka Agen. Ini adalah Kerangka Agen berkinerja tinggi yang dirancang khusus untuk pengembangan game. Dibandingkan dengan Kerangka Agen yang saat ini digunakan, kerangka ini lebih modular dan menawarkan kinerja yang lebih baik.

Artikel ini membutuhkan waktu yang lama untuk ditulis, mencoba untuk membuat semua orang memahami jenis peningkatan arsitektur apa yang telah dilakukan oleh kerangka kerja ini dibandingkan dengan kerangka kerja Agen tradisional. Sudah direvisi berkali-kali sebelum versi ini, tetapi masih ada beberapa bagian dalam artikel yang terlalu membingungkan. Karena kesulitan teknis, saya tidak dapat mengedukasikannya lebih lanjut. Jika Anda memiliki saran untuk meningkatkan artikel ini, silakan tinggalkan komentar Anda.

Latar Belakang Pengembang

Karena ini adalah blog teknis, mari kita pertama-tama melihat keahlian teknis pendiri.

Sebelum bekerja pada Project89, pendiri mengembangkan proyek ini:https://github.com/Oneirocom/Magick, yang juga merupakan perangkat lunak pemrograman berbasis AI. Selain itu, Shaw menempati peringkat keempat sebagai pengembang teratas proyek ini. Anda juga dapat melihat proyek ini di portofolio Shaw.

Kiri atas: pendiri project89; Kanan bawah: ‘lalaune’ adalah Shaw dari ai16z

Hari ini kami akan terutama memperkenalkan Kerangka Agen berkinerja tinggi dalam proyek89:

https://github.com/project-89/argOS

1. Mengapa Menggunakan ECS untuk Merancang Kerangka Agen?

Dari perspektif aplikasi di bidang permainan

Permainan yang saat ini menggunakan arsitektur ECS termasuk:

Permainan blockchain: Lumpur, Dojo

Permainan tradisional: Overwatch, Star Citizen, dll.

Selain itu, mesin permainan mainstream sedang berkembang menuju arsitektur ECS, seperti Unity.

Apa itu ECS?

ECS (Entity-Component-System) adalah pola arsitektur yang umum digunakan dalam pengembangan game dan sistem simulasi. Ini sepenuhnya memisahkan data dan logika untuk mengelola entitas dan perilaku mereka secara efisien dalam skenario yang dapat diskalakan dalam skala besar:

Entitas

• Hanya ID (nomor atau string), tidak mengandung data atau logika.

• Anda dapat memasang komponen yang berbeda untuk memberikannya berbagai properti atau kemampuan sesuai kebutuhan.

Komponen

• Digunakan untuk menyimpan data spesifik atau status suatu entitas.

Sistem

• Bertanggung jawab untuk menjalankan logika yang terkait dengan komponen-komponen tertentu.

Mari kita gunakan contoh spesifik dari tindakan Agen untuk memahami sistem ini:

Di ArgOS, setiap Agen dianggap sebagai Entitas, yang dapat mendaftarkan komponen-komponen yang berbeda. Misalnya, pada gambar di bawah ini, Agen kami memiliki empat komponen berikut:

Komponen Agen: terutama menyimpan informasi dasar seperti nama Agen, nama model, dan lain-lain.

Komponen Persepsi: Biasanya digunakan untuk menyimpan data eksternal yang dipersepsikan

Komponen Memori: Digunakan utama untuk menyimpan data Memori dari Entitas Agen, hal-hal serupa yang telah dilakukan, dll.

Komponen Tindakan: Terutama menyimpan data Tindakan yang akan dieksekusi

Alur kerja sistem:

1. Dalam permainan ini, misalnya, jika Anda merasakan senjata di depan Anda, maka fungsi eksekusi dari Sistem Persepsi akan dipanggil untuk memperbarui data dalam Komponen Persepsi Entitas Agen.
2. Kemudian memicu Sistem Memori, panggil Komponen Persepsi dan Komponen Memori secara bersamaan, dan simpan data yang dirasakan ke basis data melalui Memori.
3. Kemudian Sistem Aksi memanggil Komponen Memori dan Komponen Aksi untuk mendapatkan informasi lingkungan sekitar dari memori, dan akhirnya mengeksekusi tindakan yang sesuai.

Kemudian kami mendapatkan Entitas Agen Pembaruan di mana setiap data Komponen diperbarui.

4. Jadi kita bisa melihat bahwa Sistem di sini bertanggung jawab utama dalam menentukan Komponen mana yang akan menjalankan logika pemrosesan yang sesuai.

Dan jelas bahwa dalam project89 ini adalah dunia yang penuh dengan berbagai jenis Agen. Misalnya, beberapa Agen tidak hanya memiliki kemampuan dasar di atas tetapi juga memiliki kemampuan untuk membuat rencana.

Maka akan seperti yang ditunjukkan dalam gambar di bawah ini:

Alur Eksekusi Sistem

Namun, tidak seperti kerangka kerja tradisional di mana satu sistem langsung memicu sistem lainnya (misalnya, Sistem Persepsi memanggil Sistem Memori), dalam Project89, sistem tidak saling memanggil secara langsung. Sebaliknya, setiap sistem berjalan secara independen pada interval waktu tetap. Misalnya:

• Sistem Persepsi berjalan setiap 2 detik untuk memperbarui Komponen Persepsi dengan data lingkungan yang baru diterima.
• Sistem Memori berjalan setiap 1 detik, mengekstrak data dari Komponen Persepsi dan menyimpannya di Komponen Memori.
• Sistem Rencana berjalan setiap 1000 detik, menganalisis data yang dikumpulkan untuk menentukan apakah perlu dioptimalkan dan membuat rencana baru, yang kemudian dicatat dalam Komponen Rencana.
• Sistem Aksi berjalan setiap 2 detik, merespons perubahan lingkungan dan memodifikasi tindakan berdasarkan pembaruan dari Komponen Rencana.

Sejauh ini, artikel ini telah secara signifikan menyederhanakan arsitektur ArgOS untuk memudahkan pemahaman. Sekarang, mari kita lihat lebih dekat sistem ArgOS yang sebenarnya.

2. Arsitektur Sistem ArgOS

Untuk memungkinkan Agen berpikir lebih dalam dan melakukan tugas yang lebih kompleks, ArgOS telah merancang banyak Komponen dan banyak Sistem.

Dan ArgOS membagi Sistem menjadi "tiga tingkatan" (ConsciousnessLevel):

1) sistem CONSCIOUS

• Mengandung RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• Frekuensi pembaruan biasanya lebih tinggi (misalnya setiap 10 detik).
• Pengolahan lebih dekat ke tingkat "waktu nyata" atau "kesadaran", seperti persepsi lingkungan, pemikiran waktu nyata, pelaksanaan tindakan, dll.

2) Sistem Bawah Sadar (SUBCONSCIOUS)

• Sistem Perencanaan Tujuan, Sistem Perencanaan
• Frekuensi pembaruan relatif rendah (misalnya setiap 25 detik).
• Menangani logika "berpikir" seperti secara berkala memeriksa/menghasilkan tujuan dan rencana.

3) Sistem tak sadar (TIDAK SADAR)

• Belum diaktifkan
• Frekuensi pembaruan lebih lambat (seperti lebih dari 50 detik),

Oleh karena itu, di ArgOS, Sistem-sistem yang berbeda dibagi berdasarkan ConsciousnessLevel untuk menetapkan seberapa sering Sistem ini akan dieksekusi.

Mengapa ini didesain seperti ini?

Karena hubungan antara berbagai sistem di ArgOS sangat kompleks, seperti yang ditunjukkan di bawah ini:

1. Sistem Persepsi bertanggung jawab untuk mengumpulkan "rangsangan" dari dunia luar atau entitas lain dan memperbaruinya ke komponen Persepsi Agen.

Tentukan apakah stimulus berubah secara signifikan dan perbarui sesuai dengan stabilitas, mode pengolahan (AKTIF/REFLEKTIF/MENUNGGU), dll.

Pada akhirnya, data 'persepsi saat ini' disediakan untuk Sistem Pengalaman berikutnya, Sistem Berpikir, dll.

2. Sistem Pengalaman mengubah Stimuli yang dikumpulkan oleh Sistem Persepsi menjadi pengalaman yang lebih abstrak.

LLM atau logika aturan (extractExperiences) dipanggil untuk mengidentifikasi pengalaman baru dan disimpan di komponen Memori.

Hapus duplikat, filter, dan verifikasi pengalaman, sekaligus memicu peristiwa "pengalaman" ke sistem lain atau pendengar eksternal melalui eventBus.

3. ThinkingSystem mewakili proses pemikiran internal agen.

Ekstrak status saat ini dari komponen seperti Memori dan Persepsi, dan hasilkan “ThoughtResult” melalui generateThought(…) dan logika LLM/rule.

Berdasarkan hasil pemikiran, mungkin:

• Perbarui pemikiran dalam Memori (sejarah berpikir).

• Memicu tindakan baru (masukkan ke Action.pendingAction[eid]).

• Mengubah Penampilan eksternal agen (ekspresi, postur, dll.) dan menghasilkan Stimulus terkait agar entitas lain dapat “melihat” perubahan tersebut.

4. Sistem Tindakan menjalankan tindakan jika Action.pendingActiontidak kosong, menggunakanruntime.getActionManager().executeAction(…).

Setelah eksekusi, tulis kembali hasilnya ke Action.lastActionResult dan beri tahu ruangan atau entitas lainnya.

Ini juga menghasilkan CognitiveStimulus (stimulasi kognitif) sehingga sistem berikutnya "tahu" bahwa tindakan telah selesai, atau dapat diinkorporasikan ke dalam ingatan.

5. Sistem Perencanaan Tujuan secara berkala mengevaluasi kemajuan tujuan dalam daftar Goal.current[eid], atau memeriksa memori eksternal/internal untuk perubahan signifikan (detectSignificantChanges).

Ketika sebuah tujuan baru atau penyesuaian tujuan diperlukan, hasilkan dan tulis Goal.current[eid] melalui generateGoals(...).

Pada saat yang sama, tujuan yang sedang berlangsung (in_progress) diperbarui. Jika kondisi penyelesaian atau kegagalan terpenuhi, status diubah, dan sinyal penyelesaian/kegagalan dikirim ke Rencana yang sesuai.

6. PlanningSystem menghasilkan atau memperbarui Rencana (rencana eksekusi) untuk "tujuan yang ada" (Goal.current[eid]).

Jika terdeteksi bahwa beberapa tujuan tidak memiliki rencana aktif yang sesuai, hasilkan peta jalan eksekusi yang berisi beberapa langkah melalui generatePlan(…) dan tulis ke Plan.plans[eid].

Ketika tujuan tercapai atau gagal, status Rencana yang terkait dengan itu juga akan diperbarui dan stimulasi kognitif yang sesuai akan dihasilkan.

7. RoomSystem menangani pembaruan yang berkaitan dengan ruangan:

• Dapatkan daftar penghuni di ruangan (penghuni) dan hasilkan rangsangan "penampilan" untuk setiap agen agar entitas lain "melihat" penampilan atau tindakannya.

• Membuat dan mengkorelasikan Stimulus lingkungan ruangan (misalnya informasi "suasana ruangan" yang sesuai).

Pastikan bahwa ketika Agen berada di lingkungan spasial tertentu, entitas lain yang merasakan ruang tersebut dapat merasakan perubahan pada penampilannya.

8.CleanupSystem secara berkala menemukan dan menghapus entitas yang ditandai dengan komponen Cleanup. Digunakan untuk mendaur ulang Stimulus atau objek lain yang tidak lagi diperlukan untuk mencegah terbentuknya sejumlah besar entitas yang tidak valid dalam ECS.

• Contoh: sebuah loop dari "melihat objek" hingga "melakukan tindakan"

Contoh adegan berikut menunjukkan bagaimana setiap Sistem bekerja sama untuk menyelesaikan proses lengkap dalam satu putaran (atau beberapa frame).

Persiapan adegan: Ada seorang Agen (EID=1) di Dunia, yang berada dalam keadaan "Aktif" dan berada di Ruangan (EID=100).

Sebuah prop baru “MagicSword” muncul di Ruang ini, dan Stimulus yang sesuai dihasilkan.

1. PerceptionSystem mendeteksi kemunculan “MagicSword”, menghasilkan Stimulus (tipe=”item_appearance”) untuk Agen(1) dan menambahkannya ke Perception.currentStimuli[1].Dibandingkan dengan Stimuli Hash terakhir, ditentukan bahwa terdapat “perubahan signifikan” dan ProcessingState agen adalah “diaktifkan kembali” (mode AKTIF).
2. ExperienceSystem melihat bahwa Perception.currentStimuli dari Agent(1) tidak kosong, sehingga mengekstrak informasi seperti “Pedang muncul” menjadi satu atau lebih Pengalaman baru (tipe: “pengamatan”). Simpan di Memory.experiences[1] dan memancarkan peristiwa “pengalaman”.
3. ThinkingSystem membaca Informasi Memori, Persepsi, dan status lainnya dan memanggil generateThought:

“Saya melihat MagicSword, mungkin mengambilnya dan melihat apa yang bisa dilakukan…” Hasil pemikiran berisi Tindakan yang akan dilakukan: { alat: “pickUpItem”, parameter: { itemName: “MagicSword” } }

ThinkingSystem menulis tindakan ini ke Action.pendingAction [1].

Jika ada perubahan penampilan (misalnya "wajah dengan ekspresi penasaran"), Penampilan diperbarui dan stimulasi visual dihasilkan.

4. ActionSystem melihat Action.pendingAction[1] = { tool: "pickUpItem", parameters: … }。

Eksekusi logika tindakan 'pickup' melalui runtime.getActionManager().executeAction('pickUpItem', 1, { itemName: 'MagicSword' }, runtime). Dapatkan hasil: { success: true, message: 'Anda mengambil pedang ajaib' }, perbarui ke Action.lastActionResult[1], dan memicu peristiwa 'action' untuk disiarkan ke ruangan (100).

Pada saat yang sama, stimulus kognitif (type = "action_result") dihasilkan, ditulis ke Memori atau ditangkap oleh ThinkingSystem pada giliran berikutnya.

5. Sistem Perencanaan Tujuan (jika agen memiliki tujuan) secara berkala mengevaluasi tujuan agen. Jika salah satu tujuan agen saat ini adalah 'mendapatkan senjata yang kuat' dan mendeteksi bahwa MagicSword telah diperoleh, tujuan tersebut dapat ditandai sebagai selesai. Jika terjadi perubahan baru (misalnya, 'objek baru muncul di ruangan' mempengaruhi tujuan yang dikejar oleh agen?), menghasilkan tujuan baru atau mengabaikan tujuan lama berdasarkan deteksiPerubahanSignifikan.
6. Sistem Perencanaan (jika ada tujuan terkait) memeriksa apakah diperlukan Rencana baru atau Rencana yang sudah ada diperbarui untuk tujuan yang sudah diselesaikan atau yang baru dibuat seperti "Mendapatkan senjata yang kuat".

Jika selesai, atur Plan terkait [status] menjadi "selesai", atau hasilkan langkah-langkah lebih lanjut jika tujuannya adalah untuk memperluas proses selanjutnya ("Mengeksplor Pedang Sihir").

7. RoomSystem memperbarui daftar Penghuni dan entitas yang terlihat di ruangan (100) (setiap frame atau putaran).

Jika penampilan agen(1) berubah (misalnya, Appearance.currentAction = "memegang pedang"), buat rangsangan visual "penampilan" baru untuk memberi tahu Agenn2 dan Agen3 lainnya di ruangan yang sama bahwa "agen1 mengambil pedang".

8. CleanupSystem menghapus entitas atau stimulus yang telah ditandai (Pembersihan). Jika Anda tidak lagi perlu menyimpan Stimulus “MagicSword” setelah mengambilnya, Anda dapat menghapus entitas Stimulus yang sesuai di CleanupSystem.

1. Melalui koneksi dari sistem-sistem ini, AI Agent mencapai:

• Persepsi perubahan dalam lingkungan (Persepsi) → Merekam atau mengubah menjadi pengalaman dalam diri (Pengalaman) → Berpikir dan mengambil keputusan (Berpikir) → Melaksanakan tindakan (Aksi) → Menyesuaikan tujuan dan rencana secara dinamis (PerencanaanTujuan + Perencanaan) → Menyesuaikan dengan lingkungan (Lingkungan) → Membuang entitas yang tidak berguna secara tepat waktu (Pembersihan)

3. Analisis arsitektur keseluruhan ArgOS

1. Lapisan Arsitektur Inti

2. Klasifikasi Komponen

Di ECS, setiap entitas dapat memiliki beberapa komponen. Berdasarkan sifat dan siklus hidupnya dalam sistem, komponen dapat dibagi secara kasar menjadi kategori-kategori berikut:

1. Kelas Identitas Inti (Komponen Tingkat Identitas)

• Profil Agen / Pemain / Profil NPC, dll.

• Digunakan untuk secara unik mengidentifikasi entitas, menyimpan peran inti atau informasi unit, dan umumnya perlu dipertahankan ke database.

2. Komponen Perilaku & Status

• Aksi, Tujuan, Rencana, Status Proses, dll.

• Mewakili apa yang entitas saat ini mencoba lakukan atau apa tujuannya, serta status responsnya terhadap perintah eksternal dan pemikiran internal.

• Berisi tindakan tertunda, tujuan dalam proses, rencana, dan pemikiran atau tugas dalam antrean, dll.

• Biasanya berada dalam keadaan menengah/pendek, banyak yang berubah secara dinamis selama putaran permainan atau siklus bisnis.

• Apakah diperlukan pengisian persediaan tergantung pada situasi. Jika Anda ingin terus berjalan setelah breakpoint, Anda dapat menulis ke database secara berkala.

3. Komponen Persepsi & Memori

• Persepsi, Memori, Stimulus, Pengalaman, dll.

• Merekam informasi eksternal (Stimuli) yang dirasakan oleh entitas, dan pengalaman yang dimurnikan ke dalamnya setelah persepsi (Pengalaman).

• Memori seringkali dapat menyimpan jumlah data yang besar, seperti catatan percakapan, riwayat acara, dll.; ketekunan seringkali diperlukan.

• Persepsi dapat berupa informasi waktu nyata atau sementara, sebagian besar berlaku dalam jangka pendek. Anda dapat memutuskan apakah akan menuliskannya ke database sesuai kebutuhan Anda (misalnya, hanya peristiwa persepsi penting yang disimpan).

4. Kelas Lingkungan dan Ruang (Kamar, MenempatiRuangan, Spasial, Lingkungan, Inventaris, dll.)

• Mewakili informasi seperti ruangan, lingkungan, lokasi, wadah objek, dll.

•Room.id, Ruang Terisi, Lingkungan dan bidang lainnya sering perlu dipertahankan, seperti deskripsi halaman depan ruangan, struktur peta, dll.

• Mengubah komponen (seperti Entitas yang berpindah antar ruangan) dapat ditulis secara peristiwa atau secara berkala.

5. Kelas tampilan dan interaksi (Tampilan, UIState, Hubungan, dll.)

• Merekam bagian eksternal “terlihat” atau “interaktif” dari entitas, seperti Avatar, pose, ekspresi wajah, jaringan hubungan sosial dengan entitas lain, dll.

• Beberapa bagian mungkin hanya diproses di memori (representasi real-time), sementara bagian lain (seperti hubungan sosial kunci) mungkin dipersistensikan.

6. Komponen Utilitas & Pemeliharaan (Pembersihan, DebugInfo, ProfilingData, dll.)

• Digunakan untuk menandai entitas yang perlu didaur ulang (Cleanup), atau mencatat informasi debug (DebugInfo) untuk digunakan dalam pemantauan dan analisis.

• Biasanya hanya ada di memori dan jarang disinkronkan ke database kecuali diperlukan untuk logging atau auditing.

3. Arsitektur Sistem

Sudah diperkenalkan di atas

4. Manajer Arsitektur

Selain Komponen dan Sistem, lapisan pengelolaan sumber daya tambahan diperlukan. Lapisan ini menangani akses database, konflik status, dan operasi penting lainnya.

Sisi kiri: Sistem (Sistem Persepsi, Sistem Pengalaman, Sistem Berpikir, dll.):

• Setiap sistem dijadwalkan untuk dieksekusi oleh SimulationRuntime dalam loop ECS, mengambil dan memproses entitas yang relevan (melalui kondisi komponen).

• Ketika mengeksekusi logika, Anda perlu berinteraksi dengan Manajer, misalnya:

• Hubungi RoomManager (RM) untuk menanyakan/memperbarui informasi kamar.
• Gunakan StateManager (SM) untuk mendapatkan atau menyimpan keadaan dunia/agen seperti Memory, Goal, Plan, dll.
• Meneruskan atau mendengarkan peristiwa secara eksternal menggunakan EventBus (EB).
• PromptManager (PM) dipanggil saat pemrosesan bahasa alami atau prompt diperlukan.

Sisi Kanan: Manajer (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, dll):

• Menyediakan fungsi tingkat sistem, yang pada dasarnya tidak secara aktif "mendorong" logika, tetapi dipanggil oleh Sistem atau Runtime.

• Contoh khas:

• ActionManager khusus dalam mengelola pendaftaran dan pelaksanaan tindakan.
• EventManager / EventBus digunakan untuk mekanisme penerbitan dan langganan acara.
• RoomManager mengelola kamar, tata letak, dan penghuni.
• StateManager bertanggung jawab untuk sinkronisasi antara ECS dan database atau penyimpanan.
• PromptManager menyediakan ekstensi seperti templat Prompt LLM dan manajemen konteks.
• Runtime Simulasi Menengah (R):

• Apakah “penjadwal” dari semua Sistem, memulai atau menghentikan siklus sistem pada berbagai tingkatan (Sadar/Bawah sadar, dll.);

• Manajer juga dibuat selama fase konstruksi dan diteruskan ke setiap Sistem untuk digunakan.

• CleanupSystem:

• Perhatikan khususnya bahwa ini juga berinteraksi dengan ComponentSync (CS), yang digunakan untuk secara sinkron menghapus komponen atau langganan acara saat mendaur ulang entitas.

Kesimpulannya:

Setiap Sistem akan membaca dan menulis data atau memanggil layanan melalui Manajer yang sesuai saat dibutuhkan, dan Runtime akan secara seragam menjadwalkan siklus hidup dan perilaku semua Sistem dan Manajer pada level yang lebih tinggi.

5. Bagaimana Vektor dan Basis Data Berinteraksi di ECS

Dalam sistem ECS, Sistem menangani eksekusi logika sebenarnya, sementara operasi database (membaca/menulis) dikelola melalui Manajer Persistensi (PersistenceManager / DatabaseManager) atau Manajer Status (StateManager). Proses umumnya adalah sebagai berikut:

1. Muat Awal (Fase Memulai atau Memuat)

• StateManager / PersistenceManager memuat data komponen ketekunan inti seperti Agen, Ruangan, Tujuan, dan sebagainya dari database, membuat entitas yang sesuai (Entitas) dan menginisialisasi bidang komponen terkait.

• Misalnya, baca sekelompok catatan agen dan masukkan ke dalam dunia ECS, dan inisialisasi Agen, Memori, Tujuan, dan komponen lainnya untuk mereka.

2. Runtime ECS (Sistem Pembaruan Loop)

• Sistem melakukan hal-hal dalam setiap frame (atau putaran): PerceptionSystem mengumpulkan "persepsi" dan menulisnya ke komponen Persepsi (sebagian besar jangka pendek dari perpustakaan).

ExperienceSystem menulis "pengalaman kognitif" baru ke dalam Memory.experiences. Jika ini adalah pengalaman utama, itu juga dapat memanggil StateManager untuk penyimpanan segera, atau menandainya dengan "needsPersistence" untuk penulisan batch berikutnya.

ThinkingSystem / ActionSystem / GoalPlanningSystem, dll. membuat keputusan berdasarkan konten komponen dan memperbarui bidang-bidang dalam ECS.

Jika beberapa komponen (seperti Goal.current) mengalami perubahan besar dan membutuhkan ketahanan (seperti tujuan jangka panjang yang baru), beri tahu StateManager untuk menulis bidang ini ke database melalui pendengaran komponen atau peristiwa sistem.

3. Persistensi Periodik atau Berdasarkan Kejadian

• Anda dapat memanggil antarmuka seperti PersistenceManager.storeComponentData(eid, “Goal”) untuk menjatuhkan pustaka di titik kunci tertentu dalam sistem (seperti saat rencana target diperbarui atau saat peristiwa penting terjadi pada Agen).

• Anda juga dapat memindai komponen atau entitas dengan tag "needsPersistence" di CleanupSystem atau timer, dan menulisnya kembali ke database sekaligus.

• Selain itu, data log atau audit (seperti riwayat tindakan, log pemikiran) juga dapat diarsipkan dan disimpan di sini.

4. Penyimpanan Manual atau Shutdown (Checkpointing & Persistensi saat Keluar)

• Ketika server atau proses harus dimatikan, gunakan StateManager.saveAll() untuk menulis data yang belum ditulis ke database secara seragam untuk memastikan bahwa status ECS dapat dipulihkan saat dimuat kembali nanti.

• Untuk beberapa skenario mandiri/offline, arsip juga dapat dipicu secara manual.

• Proses contoh lengkap

Berikut adalah skenario sederhana untuk menggambarkan cara-cara yang mungkin dalam interaksi komponen dan database:

1. Tahap Awal: StateManager.queryDB("SELECT * FROM agents") → Dapatkan sekelompok catatan agen, buat Entitas (EID=x) untuk setiap catatan secara bergantian, dan inisialisasi Agen, Memori, Tujuan, dan bidang komponen lainnya.

Pada saat yang sama, muat informasi kamar dari tabel 'kamar' dan buat entitas Kamar.

2. Operasi Runtime: PerceptionSystem mendeteksi kejadian 'MagicSword muncul' di suatu ruangan tertentu dan menulis Perception.currentStimuli[eid]. ExperienceSystem mengkonversi Stimulus menjadi Pengalaman dan menetapkannya ke Memory.experiences[eid]. ThinkingSystem menentukan tindakan selanjutnya berdasarkan Memory, Tujuan, dan informasi lainnya dan menghasilkan Action.pendingAction[eid]. Setelah ActionSystem menjalankan tindakan tersebut, ia menulis hasilnya ke Memory atau Action.lastActionResult. Jika ini adalah kejadian plot utama, bagian terbaru dari Memory.experiences[eid] akan ditandai sebagai needsPersistence. Setelah beberapa waktu, StateManager menemukan bahwa Memory.experiences[eid] memiliki 'needsPersistence' dan menulisnya ke database (INSERT INTO memory_experiences...).

3. Hentikan atau Periksa Titik Simpan: Berdasarkan jadwal ECS atau sistem, StateManager.saveAll() dipanggil ketika “server dimatikan” untuk menulis status terbaru dari bidang komponen kunci (Agen, Memori, Goal, dll.) yang masih dalam memori ke dalam database. Saat Anda me-reboot, keadaan dunia ECS dapat dimuat dan dipulihkan dari database.

• Mencategorikan komponen tidak hanya memudahkan manajemen data entitas dalam proyek, tetapi juga membantu kami mengontrol batas data antara "membutuhkan ketekunan" dan "hanya ada di memori".

• Interaksi dengan database biasanya ditangani oleh Manajer khusus (seperti StateManager), dan Sistem mengoperasikannya melalui Manajer tersebut saat perlu membaca dan menulis ke database, menghindari langsung menulis pernyataan SQL atau pernyataan tingkat rendah serupa dalam Sistem.

• Dengan cara ini, Anda dapat secara bersamaan menikmati efisiensi logis dan fleksibilitas ECS, serta keuntungan dari ketekunan, melanjutkan titik henti, dan analisis statistik data yang dibawa oleh database.

4. Inovasi Arsitektur

Sorotan dari seluruh arsitektur adalah:

• Setiap Sistem berjalan secara independen dan tidak memiliki hubungan pemanggilan dengan Sistem lainnya. Oleh karena itu, meskipun kami ingin mengimplementasikan kemampuan "Mengamati perubahan dalam lingkungan (Persepsi) → Mencatat atau mengubah menjadi pengalaman internal (Pengalaman) → Berpikir dan pengambilan keputusan sendiri (Pemikiran) → Melaksanakan tindakan (Tindakan) → Menyesuaikan tujuan dan rencana secara dinamis (PerencanaanTujuan + Perencanaan) → Menyinkronkan lingkungan (Ruangan) → Mengumpulkan entitas yang tidak berguna secara tepat waktu (Pembersihan)" dari Agen, setiap sistem akan memiliki banyak ketergantungan secara fungsional, tetapi kita masih dapat menggunakan arsitektur ECS untuk mengorganisir keseluruhan menjadi sistem independen. Setiap sistem masih dapat berjalan secara independen dan tidak akan berinteraksi dengan sistem lainnya. Ada orang dan hubungan keterikatan.
• Saya pikir ini juga alasan utama mengapa Unity semakin bermigrasi ke arsitektur ECS dalam beberapa tahun terakhir.
• Dan sebagai contoh, saya hanya ingin seorang Agen memiliki beberapa kemampuan dasar. Saya hanya perlu mengurangi pendaftaran Beberapa Komponen dan pendaftaran Sistem saat mendefinisikan Entitas, yang dapat dengan mudah dicapai tanpa mengubah beberapa baris kode.

Seperti yang ditunjukkan di bawah ini:

Pada saat yang sama, jika Anda ingin menambahkan fungsi baru selama proses pengembangan, itu tidak akan memiliki dampak apa pun pada sistem lain, dan Anda dapat dengan mudah memuat fungsi yang Anda inginkan.

• Selain itu, kinerja arsitektur saat ini sebenarnya jauh lebih baik daripada arsitektur berorientasi objek tradisional. Ini adalah fakta yang diakui dalam lingkaran permainan, karena desain ECS lebih cocok untuk konkurensi, jadi ketika kami menggunakan ECS dalam skenario Defai kompleks, Arsitektur ini mungkin juga memiliki lebih banyak keuntungan, terutama dalam skenario di mana agen diharapkan digunakan untuk transaksi kuantitatif, ECS juga akan berguna (tidak hanya dalam skenario permainan agen).
• Memisahkan sistem menjadi sadar, bawah sadar, dan tidak sadar untuk membedakan seberapa sering berbagai jenis sistem harus dilaksanakan adalah desain yang sangat cerdas dan sudah menjadi kemampuan manusia yang sangat konkret.

Dari sudut pandang pribadi saya, ini adalah kerangka kerja yang sangat modular dengan kinerja yang sangat baik. Kualitas kode juga sangat tinggi dan berisi dokumen desain yang baik. Sayangnya, Proyek89 kurang mendapatkan visibilitas dan promosi untuk kerangka kerja ini, itulah mengapa saya menghabiskan empat hari menulis artikel ini untuk menyoroti kelebihannya. Saya percaya teknologi hebat layak mendapatkan pengakuan, dan besok, saya berencana untuk merilis versi bahasa Inggris dari artikel ini untuk meningkatkan kesadaran di kalangan tim game dan pengembang DeFi (Keuangan Terdesentralisasi). Semoga lebih banyak tim akan menjelajahi kerangka kerja ini sebagai pilihan arsitektur potensial untuk proyek-proyek mereka!

Penyangkalan:

1. Artikel ini diambil dari [0xhhh]. Meneruskan Judul Asli: Saya Melihat Kerangka Kerja Agen Generasi Berikutnya di Project89. Hak cipta adalah milik penulis asli [0xhhh]. Jika Anda memiliki keberatan terhadap pencetakan ulang, silakan hubungi Gate Belajartim, tim akan menanganinya secepat mungkin sesuai dengan prosedur yang relevan.
2. Penafian: Pandangan dan pendapat yang tertera dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran investasi apa pun.
3. Versi bahasa lain dari artikel ini diterjemahkan oleh tim Belajar Gate. Kecuali dinyatakan lain, artikel yang diterjemahkan tidak boleh disalin, didistribusikan, atau diplagiatkan.