ส่งต่อชื่อเรื่องต้นฉบับ: ฉันเห็นโครงสร้างเอเจนต์รุ่นถัดไปในโปรเจกต์89

ให้ไปตรงไปเลย,@project_89นำเสนอแนวทางการออกแบบเฟรมเวิร์กเอเย่นต์ที่แตกต่างกันอย่างสิ้นเชิง นี่เป็นเฟรมเวิร์กเอเย่นต์ที่มีประสิทธิภาพสูงโดยเฉพาะสำหรับการพัฒนาเกม เมื่อเปรียบเทียบกับเฟรมเวิร์กเอเย่นต์ที่ใช้ในปัจจุบัน มันมีความโมดูลาร์มากขึ้นและมีประสิทธิภาพที่ดีกว่า

บทความนี้ใช้เวลานานในการเขียนโดยพยายามให้ทุกคนเข้าใจว่าๆ และมีการปรับปรุงทางสถาปัตยกรรมเชิงรุกนี้เมื่อเปรียบเทียบกับเฟรมเวิร์คเอเจนต์ทั่วไป ได้รับการแก้ไขหลายครั้งก่อนเวอร์ชันนี้ แต่เพียงใดก็มีบางส่วนในบทความที่ยังค่อนข้างสับสน ด้วยความยากลำบากทางเทคนิค ฉันไม่สามารถสาธิตได้ไกลยิ่งขึ้น หากคุณมีข้อเสนอแนะในการปรับปรุงบทความ กรุณาแสดงความคิดเห็นของคุณ

ประวัตินักพัฒนา

เนื่องจากนี่เป็นบล็อกที่เกี่ยวกับเทคนิค ให้เรามาดูทักษะทางเทคนิคของผู้ก่อตั้งก่อน

ก่อนเริ่มทำโครงการ 89 ผู้ก่อตั้งได้พัฒนาโครงการนี้:https://github.com/Oneirocom/Magick, ซึ่งเป็นซอฟต์แวร์โปรแกรมที่มีพลังปัญญาประดิษฐ์เช่นกัน นอกจากนี้ Shaw ยังอยู่อันดับที่สี่ของนักพัฒนาโครงการนี้ คุณยังสามารถเห็นโครงการนี้ในพอร์ตโฟลิโอของ Shaw

มุมบนซ้าย: ผู้ก่อตั้งของโครงการ 89; มุมล่างขวา: 'lalaune' คือ Shaw ของ ai16z

วันนี้เราจะนำเสนอโครงสร้างเอเจนท์ความสามารถสูงในโปรเจค 89 โดยส่วนใหญ่

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

1. เหตุใดจึงต้องใช้ ECS เพื่อออกแบบ Agent Framework

จากมุมมองของการใช้งานในเขตเกม

เกมที่ใช้สถาปัตยกรรม ECS ปัจจุบันได้แก่:

เกมบล็อกเชน: Mud, Dojo

เกมแบบดั้งเดิม: Overwatch, Star Citizen, ฯลฯ

นอกจากนี้เครื่องเกมสตรีมเมากน์ก็กำลังพัฒนาไปทางสถาปัตยกรรม ECS เช่น Unity

ECS คืออะไร?

ECS (Entity-Component-System) เป็นรูปแบบสถาปัตยกรรมที่ใช้กันอย่างแพร่หลายในการพัฒนาเกมและระบบจำลอง มันแยกข้อมูลและตรรกะออกจากกันอย่างสมบูรณ์เพื่อจัดการเอนทิตีและพฤติกรรมของเอนทิตีต่างๆ ในสถานการณ์ที่มีขนาดใหญ่และสามารถขยายออกไปได้:

Entity

• เพียงแค่ ID (ตัวเลขหรือข้อความ) ที่ไม่มีข้อมูลหรือตรรกะใดๆ

• คุณสามารถติดตั้งส่วนประกอบต่างๆ เพื่อให้ได้คุณสมบัติหรือความสามารถตามต้องการ

ส่วนประกอบ

• ใช้เก็บข้อมูลเฉพาะหรือสถานะขององค์ประกอบ

ระบบ

• รับผิดชอบในการดำเนินการตามตรรกะที่เกี่ยวข้องกับส่วนประกอบบางส่วน

Let’s use a specific example of Agent action to understand this system:

ใน ArgOS แต่ละเอเจนต์ถูกพิจารณาว่าเป็น Entity ที่สามารถลงทะเบียนส่วนประกอบต่าง ๆ ตัวอย่างเช่นในรูปภาพด้านล่างเอเจนต์ของเรามีส่วนประกอบทั้งหมดสี่ส่วนดังต่อไปนี้:

ส่วนประกอบของตัวแทน: เก็บข้อมูลพื้นฐาน เช่น ชื่อตัวแทน ชื่อโมเดล เป็นต้น

Perception Component: ใช้เป็นหลักในการเก็บข้อมูลภายนอกที่รับรู้

องค์ประกอบของหน่วยความจำ: ใช้เก็บข้อมูลหน่วยตัวแทน Memory อย่างหลัก ๆ เช่นสิ่งที่เคยทำไปแล้ว เป็นต้น

องค์ประกอบการกระทำ: เก็บข้อมูล Action ที่จะถูกดำเนินการ

กระบวนการของระบบ:

1. ในเกมนี้เช่น ถ้าคุณรับรู้ว่ามีอาวุธอยู่ข้างหน้าคุณ ฟังก์ชันการดำเนินการของระบบการรับรู้จะถูกเรียกใช้เพื่ออัปเดตข้อมูลในส่วน Perception ของเอนทิตี้ของตัวละคร
2. จากนั้นเรียกใช้ระบบหน่วยความจำเรียกคอมโพเนนต์และคอมโพเนนต์หน่วยความจำพร้อมกันพยายามเก็บข้อมูลที่รับรู้ไว้ในฐานข้อมูลผ่านหน่วยความจำ
3. จากระบบการกระทำจะเรียกใช้คอมโพเนนต์ของหน่วยความจำและคอมโพเนนต์การกระทำเพื่อขอข้อมูลสภาพแวดล้อมรอบตัวจากหน่วยความจำ และในที่สุดจะดำเนินการกระทำที่เกี่ยวข้อง

จากนั้นเราจะได้รับ Entity ตัวแทนการอัปเดต ที่แต่ละข้อมูลของส่วนประกอบถูกอัปเดต

4.ดังนั้นเราสามารถเห็นได้ว่าระบบที่นี่รับผิดชอบหลักในการกำหนดว่าคอมโพเนนต์ใดที่จะดำเนินการตามตรรกะการประมวลผลที่เกี่ยวข้อง

และมันเป็นเรื่องที่ชัดเจนว่าในโปรเจกต์ 89 นั้นเป็นโลกที่เต็มไปด้วยตัวแทนชนิดต่าง ๆ เช่น บางตัวแทนไม่เพียงแต่มีความสามารถพื้นฐานที่กล่าวถึงข้างต้นแล้ว แต่ยังมีความสามารถในการวางแผนด้วย

จากนั้นมันจะเป็นตามที่แสดงในรูปด้านล่าง:

กระบวนการดำเนินการของระบบ

อย่างไรก็ตาม ไม่เช่นเดิมที่กรอบการทำงานแบบดั้งเดิมที่ระบบหนึ่งเรียกใช้ระบบอื่นๆ โดยตรง (ตัวอย่างเช่นระบบการรับรู้ที่เรียกใช้ระบบหน่วยความจำ) ในโครงการ 89 ระบบไม่เรียกใช้กันโดยตรง แต่แต่ละระบบทำงานอิสระในช่วงเวลาที่แน่นอน ตัวอย่างเช่น:

• Perception System ทำงานทุก 2 วินาทีเพื่ออัปเดต Perception Component ด้วยข้อมูลสภาพแวดล้อมที่ได้รับเข้ามาใหม่
• Memory System ทำงานทุก 1 วินาที และดึงข้อมูลจาก Perception Component และเก็บข้อมูลไว้ใน Memory Component
• ระบบแผนทำงานทุก ๆ 1000 วินาที โดยวิเคราะห์ข้อมูลที่เก็บได้เพื่อกำหนดว่าจะต้องปรับปรุงและสร้างแผนใหม่หรือไม่ แล้วจะบันทึกลงในองค์ประกอบแผน
• Action System ทำงานทุก 2 วินาที เพื่อตอบสนองต่อการเปลี่ยนแปลงในสภาพแวดล้อมและปรับเปลี่ยนการกระทำตามการอัปเดตจาก Plan Component

จนถึงตอนนี้บทความนี้ได้ทำให้โครงสร้างของ ArgOS ง่ายขึ้นอย่างมากเพื่อทำให้เข้าใจง่ายขึ้น ตอนนี้เรามาดูระบบ ArgOS จริงๆ กันเถอะ

2. โครงสร้างระบบ ArgOS

เพื่อให้เอเจนต์คิดอย่างลึกซึ้งและกระทำงานที่ซับซ้อนมากขึ้น อาร์โกซ์ออกแบบออกแบบองค์ประกอบหลายรายการและระบบหลายรายการ

และ ArgOS แบ่งระบบเป็น "สามระดับ" (ConsciousnessLevel):

1) ระบบ CONSCIOUS

• มี RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• ความถี่ของการอัพเดทมักจะสูงกว่า (เช่นทุก ๆ 10 วินาที)
• การประมวลผลใกล้เคียงกับระดับ "เรียลไทม์" หรือ "ระดับความตระหนักรู้" เช่นการรับรู้สิ่งแวดล้อมเรียลไทม์ ความคิดเรียลไทม์ การดำเนินการในเรียลไทม์ ฯลฯ

2) ระบบอย่างไม่ตั้งใจ (SUBCONSCIOUS)

• GoalPlanningSystem, PlanningSystem
• ความถี่ในการอัปเดตสูงไม่มาก (เช่นทุก 25 วินาที)
• จัดการตรรกะ "ความคิด" เช่นการตรวจสอบ / สร้างเป้าหมายและแผนเป็นระยะๆ

3) ระบบที่ไม่รู้สติ (UNCONSCIOUS)

• ยังไม่ได้เปิดใช้งาน
• ความถี่ในการอัปเดตช้าลง (เช่นมากกว่า 50 วินาที)

ดังนั้น ใน ArgOS ระบบที่แตกต่างกันถูกแบ่งตามระดับความตื่นตัวเพื่อกำหนดว่าระบบนี้จะถูกดำเนินการบ่อยแค่ไหน

ทำไมถึงออกแบบแบบนี้?

เนื่องจากความสัมพันธ์ระหว่างระบบต่าง ๆ ใน ArgOS มีความซับซ้อนมาก ดังที่แสดงด้านล่าง:

1. PerceptionSystem รับผิดชอบในการเก็บรวบรวม "สิ่งกระตุ้น" จากโลกภายนอกหรือส่วนอื่น ๆ และอัปเดตให้กับองค์ประกอบการรับรู้ของเอเจนต์

กำหนดว่าสิ่งกระตุ้นเปลี่ยนแปลงอย่างมีนัยสำคัญและอัปเดตตามความเสถียรภาพ โหมดการประมวลผล (ACTIVE / REFLECTIVE / WAITING) เป็นต้น

โดยท้ายที่สุดข้อมูล "การรับรู้ปัจจุบัน" ถูกให้สำหรับ ExperienceSystem ที่จะเกิดขึ้น, ThinkingSystem, ฯลฯ

2. ระบบประสบการณ์แปลงสิ่งกระตุ้นที่เก็บรวบรวมโดยระบบการรับรู้เป็น "ประสบการณ์" ที่มีระดับสูงกว่า

LLM หรือตรรกะกฎ (extractExperiences) ถูกเรียกใช้เพื่อระบุประสบการณ์ใหม่ ๆ และเก็บไว้ในส่วนประกอบของหน่วยความจำ

ลบซ้ำซ้อน กรองและยืนยันประสบการณ์ในขณะที่เรียกเกิดเหตุการณ์ "ประสบการณ์" ไปยังระบบอื่น ๆ หรือผู้ฟังภายนอกผ่าน eventBus

3. ThinkingSystem แทนกระบวนการความคิดภายในของตัวแทน

สกัดสถานะปัจจุบันจากส่วนประกอบเช่นหน่วยความจำและการรับรู้ และสร้าง "ผลคิด" ผ่าน generateThought(...) และตรรกะของ LLM/กฎ

โดยอ้างอิงจากผลความคิด อาจจะ:

• อัปเดตความคิดในหน่วยความจำ (ประวัติความคิด)

• เรียกใช้การกระทำใหม่ (ใส่ใน Action.pendingAction [eid])

• เปลี่ยนลักษณะภายนอกของตัวแทน (อารมณ์, ท่าทาง เป็นต้น) และสร้างสิ่งกระตุ้นที่เกี่ยวข้องให้ภาคีอื่น 'เห็น' การเปลี่ยนแปลง

4. ระบบการดำเนินการดำเนินการหากAction.pendingActionไม่ว่างเปล่า ใช้runtime.getActionManager().executeAction(…).

หลังจากทำการดำเนินการเสร็จสิ้น ให้เขียนผลลัพธ์กลับไปยัง Action.lastActionResult และแจ้งให้ห้องหรือตัวแปรอื่น ๆ ทราบ

นี่ยังสร้างสิ่งกระตุ้นสติ (การกระตุ้นสติ) เพื่อให้ระบบต่อมา “รู้” ว่าการกระทำได้เสร็จสมบูรณ์แล้ว หรือสามารถนำมาผสมกับหน่วยความจำ

5. ระบบวางแผนเป้าหมาย จะประเมินความก้าวหน้าของเป้าหมายในรายการ Goal.current[eid] อย่างสม่ำเสมอ หรือตรวจสอบความเปลี่ยนแปลงที่สำคัญในหน่วยความจำภายนอก/ภายใน (detectSignificantChanges)

เมื่อต้องการเป้าหมายใหม่หรือการปรับปรุงเป้าหมาย ให้สร้างและเขียน Goal.current[eid] ผ่าน generateGoals(…)

ในเวลาเดียวกัน จุดมุ่งหมายที่กำลังดำเนินการ (in_progress) ถูกอัปเดต หากเกิดเงื่อนไขการเสร็จสิ้นหรือล้มเหลว สถานะจะเปลี่ยนและส่งสัญญาณเสร็จสิ้น/ล้มเหลวไปยังแผนที่เกี่ยวข้อง

6.ระบบวางแผนสร้างหรืออัพเดตแผน (execution plan) สำหรับ "เป้าหมายที่มีอยู่" (Goal.current[eid])

หากตรวจพบว่าบางเป้าหมายไม่มีแผนที่ใช้งานอยู่ให้สร้างแผนการดำเนินงานที่ประกอบด้วยขั้นตอนหลายขั้นตอนผ่านการสร้างแผน (generatePlan (...)) และเขียนลงใน Plan.plans [eid]

เมื่อเป้าหมายเสร็จสิ้นหรือล้มเหลว สถานะแผนที่เกี่ยวข้องก็จะได้รับการอัปเดตและจะสร้างการสะท้อนทางความคิดที่สอดคล้องกัน

7. ระบบห้องจัดการการอัปเดตที่เกี่ยวข้องกับห้อง:

• ได้รับรายชื่อผู้อยู่ในห้อง (ผู้อยู่อาศัย) และสร้างสถานการณ์ “ที่พบกัน” สำหรับแต่ละตัวแทนเพื่อให้ส่วนอื่น ๆ “เห็น” รูปลักษณ์หรือการกระทำของเขา

• สร้างและเชื่อมโยงสิ่งแวดล้อมห้องและสถานการณ์ที่กระตุ้น (เช่น ข้อมูล "บรรยากาศห้องที่เหมาะสม").

ให้แน่ใจว่าเมื่อตัวแทนอยู่ในสภาพแวดล้อมที่แน่นอน สิ่งกิจกรรมอื่น ๆ ที่มีการรับรู้พื้นที่สามารถรับรู้การเปลี่ยนแปลงในลักษณะของเขา

8.CleanupSystem พบและลบ entity ที่มี tcomponentCleanup อย่างสม่ำเสมอ ใช้เพื่อ recycle Stimulus หรือ object อื่น ๆ ที่ไม่จำเป็นอีกต่อไปเพื่อป้องกันไม่ให้มีจำนวนมากของ entity ที่ไม่ถูกต้องที่สุดใน ECS

• ตัวอย่าง: ลูปจาก "เห็นวัตถุ" ถึง "ดำเนินการ"

ตัวอย่างฉากต่อไปนี้แสดงให้เห็นว่าแต่ละระบบทำงานร่วมกันเพื่อทำกระบวนการที่สมบูรณ์ในรอบเดียว (หรือหลายเฟรม)

เตรียมฉาก: มีเอเจนต์ (EID=1) ในโลกที่อยู่ในสถานะ "Active" และอยู่ในห้อง (EID=100)

ในห้องนี้เกิดขึ้นครั้งใหม่ "MagicSword" และมีการสร้างสิ่งกระตุ้นที่สอดคล้องกัน

1. PerceptionSystem ตรวจจับการปรากฏของ "MagicSword", สร้างสิ่งกระตุ้น (ประเภท ="การปรากฏของไอเท็ม") สำหรับเอเจนต์ (1) และเพิ่มไปยัง Perception.currentStimuli[1] เมื่อเปรียบเทียบกับ Stimuli Hash ล่าสุด พบว่ามี "การเปลี่ยนแปลงที่สำคัญ" และ ProcessingState ของเอเจนต์เป็น "เริ่มใช้งานใหม่" (โหมด ACTIVE)
2. ExperienceSystem เห็นว่า Perception.currentStimuli ของเอเจนต์ (1) ไม่ว่างเปล่า ดังนั้นจึงแยกข้อมูล เช่น "มีดปรากฏ" เป็นประสบการณ์ใหม่หนึ่งหรือมากกว่า (ประเภท: "การสังเกต") จัดเก็บไว้ใน Memory.experiences[1] และส่งออก "เหตุการณ์ประสบการณ์"
3. ThinkingSystem อ่านข้อมูลสถานะการทำงานของหน่วยความจำ การรับรู้และข้อมูลสถานะอื่น ๆ และเรียกใช้ generateThought:

“ฉันเห็น MagicSword อาจจะเก็บมันขึ้นมาและดูว่ามันทำอะไรได้...” ผลความคิดมีการดำเนินการที่จะดำเนินการ: { เครื่องมือ: “pickUpItem”, พารามิเตอร์: { ชื่อรายการ: “MagicSword” } }

ThinkingSystem เขียนการกระทำนี้ไปยัง Action.pendingAction[1]

หากมีการเปลี่ยนแปลงทางลักษณะ (เช่น "ใบหน้าที่แสดงความอยากรู้") ลักษณะภาพจะถูกอัปเดตและการกระตุ้นทางสายตาจะถูกสร้างขึ้น

4.ActionSystem เห็น Action.pendingAction[1] = { tool: “pickUpItem”, parameters: … }。

รันตรรกะการดําเนินการ "pickup" ผ่าน runtime.getActionManager().executeAction("pickUpItem", 1, { itemName: "MagicSword" }, runtime) รับผลลัพธ์: { success: true, message: "You picked up the magic sword" }, update to Action.lastActionResult[1], and trigger the "action" event to be broadcast to the room (100).

ในเวลาเดียวกัน กระตุ้นสติสัมผัส (ประเภท = "action_result") ถูกสร้างขึ้น เขียนลงในหน่วยความจำ หรือถูกจับกล้องโดย ThinkingSystem ในรอบถัดไป

5. ระบบวางแผนเป้าหมาย (หากตัวแทนมีเป้าหมาย) จะประเมินเป้าหมายของตัวแทนเป็นครั้งคราว หากเป้าหมายหนึ่งของตัวแทนในเวลานี้คือ "ได้รับอาวุธที่มีพลัง" และตรวจพบว่าได้รับมีดเวทย์แล้ว เป้าหมายอาจถูกทำเครื่องหมายว่าเสร็จสมบูรณ์ หากการเปลี่ยนแปลง /keySeatTr ใหม่เกิดขึ้น (ตัวอย่างเช่น "วัตถุใหม่ปรากฏในห้อง" มีผลต่อเป้าหมายที่ตัวแทนกำลังตามหาหรือไม่) สร้างเป้าหมายใหม่หรือละทิ้งเป้าหมายเก่าขึ้นอยู่กับการตรวจพบการเปลี่ยนแปลงที่สำคัญ
6. ระบบวางแผน (หากมีเป้าหมายที่เกี่ยวข้อง) ตรวจสอบว่าต้องการแผนใหม่หรืออัปเดตแผนที่มีอยู่สำหรับเป้าหมายที่เสร็จสิ้นหรือเพิ่มเติมเช่น "ได้รับอาวุธที่มีพลัง"

หากเสร็จสิ้นแล้วให้ตั้งค่าแผนที่เกี่ยวข้อง [สถานะ] เป็น "เสร็จสิ้น" หรือสร้างขั้นตอนเพิ่มเติมหากเป้าหมายคือการขยายกระบวนการถัดไป ("วิจัยดาบมหาเวท")

7.RoomSystem อัปเดตรายชื่อผู้อยู่อาศัยและสิ่งมีชีวิตที่มองเห็นในห้อง (100) (ทุกเฟรมหรือรอบ)

หากมีการเปลี่ยนแปลงในการปรากฏของตัวแทน (เช่น Appearance.currentAction = "ถือดาบ") ให้สร้างสิ่งกระตุ้นทางสายตาใหม่ "การปรากฏของตัวแทน" เพื่อให้ตัวแทนอื่น ๆ ในห้องเดียวกันรู้ว่า "ตัวแทน1 หยิบดาบขึ้นมา"

8.CleanupSystem ลบ entity หรือ stimuli ที่ถูกทำเครื่องหมาย (Cleanup) หากคุณไม่ต้องการเก็บ “MagicSword” Stimulus ต่อจากที่เก็บมันไว้แล้ว คุณสามารถลบ entity Stimulus ที่เกี่ยวข้องใน CleanupSystem ได้

1. ผ่านการเชื่อมต่อระบบเหล่านี้ AI Agent ได้บรรลุเป้าหมาย:

• รับรู้การเปลี่ยนแปลงในสภาพแวดล้อม (การรับรู้) → บันทึกหรือแปลงเป็นประสบการณ์ภายใน (ประสบการณ์) → การคิดและการตัดสินใจของตนเอง (การคิด) → นำมันเข้าสู่การดำเนินการ (การดำเนินการ) → ปรับเปลี่ยนเป้าหมายและแผน (การวางเป้าหมาย + การวางแผน) → การซิงโครไนส์กับสภาพแวดล้อม (ห้อง) → การรีไซเคิลองค์อิสระที่ไม่เป็นประโยชน์ทันเวลา (การทำความสะอาด)

3. การวิเคราะห์โครงสร้างโดยรวมของ ArgOS

1. ชั้นคอร์อากิเทคเจอร์

2. การจัดประเภทส่วนประกอบ

ใน ECS แต่ละ entity สามารถมี components หลายตัว ตามลักษณะและวงจรชีวิตของ components ในระบบ สามารถแบ่งเป็นหมวดหมู่ต่อไปนี้ได้โดยรวม:

1. คลาสอัตลักษณ์หลัก (ส่วนประกอบระดับอัตลักษณ์)

• ตัวแทน / โปรไฟล์ผู้เล่น / โปรไฟล์ NPC ฯลฯ

• ใช้ในการระบุตัวบุคคลหรือสิ่งของให้เป็นเอนทิตี้ที่ไม่ซ้ำกัน เก็บข้อมูลบทบาทหลักหรือข้อมูลหน่วยและต้องเก็บรักษาไว้ในฐานข้อมูลโดยทั่วไป

2. ส่วนประกอบของพฤติกรรมและสถานะ

• การกระทำ, เป้าหมาย, แผน, สถานะการประมวลผล, เป็นต้น

• แทนสิ่งที่ส่วนประกอบกำลังพยายามทำหรือเป้าหมายของมันอยู่ในขณะนี้ รวมถึงสถานะการตอบสนองต่อคำสั่งภายนอกและความคิดภายใน

• มี pendingAction, goalsInProgress, plans และความคิดหรืองานในคิว ฯลฯ

• โดยทั่วไปมักเป็นสถานะระยะกลาง/สั้น ๆ ซึ่งมีการเปลี่ยนแปลงอย่างไดนามิกขณะเกมรอบหรือวงจรธุรกิจ

• การเก็บข้อมูลอยู่ที่ความเป็นจริงว่าจำเป็นหรือไม่ หากคุณต้องการที่จะดำเนินการต่อหลังจากจุดพัก คุณอาจเขียนลงในฐานข้อมูลเป็นระยะๆ

3. ส่วนประกอบของการรับรู้และความจำ

• การรับรู้, ความจำ, สิ่งกระตุ้น, ประสบการณ์, ฯลฯ

• บันทึกข้อมูลข้างนอก (สิ่งกระตุ้น) ที่ตระหนักได้โดยสิ่งแวดล้อมของตัวประกอบ และประสบการณ์ที่ถูกปรับปรุงเข้าไปในตัวประกอบหลังจากการตระหนัก (ประสบการณ์)

• หน่วยความจำสามารถสะสมข้อมูลมากมาย เช่น บันทึกการสนทนา ประวัติเหตุการณ์ เป็นต้น ส่วนคงที่ต้องการอยู่ตลอดเวลา

• การรับรู้อาจเป็นข้อมูลแบบเรียลไทม์หรือชั่วคราว เป็นข้อมูลที่ถูกต้องในระยะสั้น คุณสามารถตัดสินใจว่าจะเขียนลงในฐานข้อมูลหรือไม่ ตามความต้องการของคุณ (เช่นเก็บเฉพาะเหตุการณ์การรับรู้ที่สำคัญเท่านั้น)

4. คลาสสภาพแวดล้อมและพื้นที่ (ห้อง, คลาสที่มีการครองห้อง, พื้นที่, สภาพแวดล้อม, สินค้าคงคลัง, ฯลฯ)

• แทนข้อมูล เช่น ห้อง สิ่งแวดล้อม ตำแหน่ง ภาชนะวัตถุ เป็นต้น

•Room.id, จองห้องพัก, สภาพแวดล้อม และบริเวณอื่น ๆ มักต้องถูกเก็บไว้ เช่น คำอธิบายหน้าห้อง, โครงสร้างแผนที่ ฯลฯ

• การเปลี่ยนแปลงส่วนประกอบ (เช่น Entity ที่เคลื่อนไหวระหว่างห้อง) สามารถเขียนเป็นเหตุการณ์หรือเป็นระยะเวลาได้

5. คลาสการแสดงผลและการปฏิสัมพันธ์ (การแสดงผล, สถานะ UI, ความสัมพันธ์, เป็นต้น)

• บันทึกส่วน “ที่มองเห็น” หรือ “ปฏิสัมพันธ์” ภายนอกของมิติเอนทิตี เช่น อวาตาร์ ท่าทาง อารมณ์ของใบหน้า เครือข่ายความสัมพันธ์ทางสังคมกับมิติเอนทิตีอื่น ๆ และอื่น ๆ

• บางส่วนอาจถูกประมวลผลในหน่วยความจำเท่านั้น (การแสดงสดเรียลไทม์) ในขณะที่ส่วนอื่น (เช่นความสัมพันธ์ทางสังคมที่สำคัญ) อาจถูกจัดเก็บไว้

6.ส่วนประกอบการใช้งานและการบำรุงรักษา (การล้างข้อมูล, ข้อมูลการแก้ไขข้อบกพร่อง, ข้อมูลการประมวลผลเสถียรภาพ เป็นต้น)

• ใช้เพื่อทำเครื่องหมายบริษัทที่ต้องรีไซเคิล (Cleanup) หรือบันทึกข้อมูลในกระบวนการดีบั๊ก (DebugInfo) เพื่อใช้ในการตรวจสอบและวิเคราะห์

• โดยทั่วไปมีอยู่เฉพาะในหน่วยความจำและน้อยที่จะซิงโครไนซ์กับฐานข้อมูล ยกเว้นจำเป็นสำหรับการล็อกหรือตรวจสอบ

3. สถาปัตยกรรมระบบ

เป็นสิ่งที่ได้ถูกนำเสนอไว้ข้างต้นแล้ว

4. สถาปัตยกรรมของผู้จัดการ

นอกจากองค์ประกอบและระบบแล้ว ยังต้องมีชั้นการจัดการทรัพยากรเพิ่มเติม ชั้นนี้จัดการการเข้าถึงฐานข้อมูล การขัดแย้งสถานะ และการดำเนินการสำคัญอื่น ๆ

ฝั่งซ้าย: ระบบ (PerceptionSystem, ExperienceSystem, ThinkingSystem, ฯลฯ):

• ทุกระบบจะถูกกำหนดเวลาสำหรับการดำเนินการโดย SimulationRuntime ในลูป ECS โดยการค้นหาและประมวลผลองค์ประกอบที่มีความสำคัญ (ผ่านเงื่อนไขของส่วนประกอบ)

• เมื่อทำการดำเนินการตรรกะ คุณต้องปฏิสัมพันธ์กับผู้จัดการ เช่น:

• เรียก RoomManager (RM) เพื่อสอบถาม/อัปเดตข้อมูลห้อง
• ใช้ StateManager (SM) เพื่อรับหรือบันทึกสถานะของโลก/ตัวแทน เช่น Memory, Goal, Plan, ฯลฯ
• ส่งข่าวสารหรือฟังเหตุการณ์จากภายนอกโดยใช้ EventBus (EB)
• PromptManager (PM) เรียกใช้เมื่อต้องการประมวลผลภาษาธรรมชาติหรือโปรมป์

Right Side: Managers (EventBus、RoomManager、StateManager、EventManager、ActionManager、PromptManager, etc)：

• ให้ฟังก์ชันระดับระบบ ซึ่งโดยพื้นฐานไม่ได้ "ขับเคลื่อน" ตรรกะโดยเป็นการเรียกโดย Systems หรือ Runtime

• ตัวอย่างทั่วไป:

• ActionManager เชี่ยวชาญในการจัดการการลงทะเบียนและการดำเนินการของการดำเนินการ
• EventManager / EventBus ใช้สําหรับกลไกการเผยแพร่และการสมัครสมาชิกเหตุการณ์
• ผู้จัดการห้องจัดการห้อง การจัดวางและผู้อยู่อาศัย
• StateManager รับผิดชอบการซิงโครไนซ์ระหว่าง ECS และฐานข้อมูลหรือการจัดเก็บข้อมูล
• PromptManager ให้คุณส่วนขยายเช่นเทมเพลต LLM Prompt และการจัดการบริบท
• Intermediate SimulationRuntime (R):

• เป็น "ตัวกำหนดเวลา" ของระบบทั้งหมด ที่เริ่มหรือหยุดวงจรของระบบในระดับต่าง ๆ (ตระกูลอคัล / ไร้สตรีมคอนเชียส เป็นต้น)

• ผู้จัดการถูกสร้างขึ้นระหว่างขั้นตอนการก่อสร้างและถูกส่งผ่านให้แต่ละระบบเพื่อใช้งาน

• CleanupSystem:

• โปรดทราบเป็นพิเศษว่ามันยังมีปฏิสัมพันธ์กับ ComponentSync (CS) ซึ่งใช้สำหรับการลบส่วนประกอบหรือการสมัครสมาชิกกิจกรรมเมื่อนำเอนทิตี้กลับมาใช้ใหม่

สรุปผล

แต่ละระบบจะอ่านและเขียนข้อมูลหรือเรียกใช้บริการผ่านผู้จัดการที่เกี่ยวข้องเมื่อจำเป็น และ Runtime จะตั้งเวลาและพฤติกรรมของระบบและผู้จัดการทุกระดับในระดับสูง

5. วิธีการประสานงานระหว่างเวกเตอร์และฐานข้อมูลใน ECS

ในระบบ ECS ระบบจัดการการดำเนินการตรรกะจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรมจริยธรรม

1. โหลดเริ่มต้น (เฟสเริ่มต้นหรือเฟสการโหลด)

• StateManager / PersistenceManager โหลดข้อมูลของส่วนประกอบความต้านทานแก่สถานะหลัก เช่น เอเจ็นต์ เห้อง เป้าหมาย และอื่นๆ จากฐานข้อมูล สร้างองค์ประกอบที่เกี่ยวข้อง (Entities) และเริ่มต้นฟิลด์ขององค์ประกอบที่เกี่ยวข้อง

• ตัวอย่างเช่นอ่านบันทึกตัวแทนจำนวนมากและแทรกเข้าสู่โลก ECS และเริ่มต้นองค์ประกอบต่าง ๆ ของเอเจนต์ เช่น หน่วยความจำ เป้าหมาย และอื่น ๆ สำหรับพวกเขา

2. ระบบการทำงานของ ECS (รอบการอัปเดตของระบบ)

•ระบบทําสิ่งต่าง ๆ ในแต่ละเฟรม (หรือรอบ): PerceptionSystem รวบรวม "การรับรู้" และเขียนลงในองค์ประกอบการรับรู้ (ส่วนใหญ่เป็นระยะสั้นออกจากห้องสมุด)

ExperienceSystem เขียน "ประสบการณ์การรับรู้" ใหม่ลงใน Memory.experiences หากเป็นประสบการณ์ที่สำคัญ อาจเรียกใช้ StateManager เพื่อบันทึกทันที หรือทำเครื่องหมายด้วย "needsPersistence" เพื่อเขียนเป็นชุดภายหลัง

ThinkingSystem / ActionSystem / GoalPlanningSystem เป็นการตัดสินใจโดยขึ้นอยู่กับเนื้อหาของส่วนประกอบและอัปเดตฟิลด์ใน ECS โดยเฉพาะ

หากบางส่วน (เช่น Goal.current) มีการเปลี่ยนแปลงที่สำคัญและต้องการความต่อทน (เช่นเป้าหมายระยะยาวใหม่) แจ้งให้ StateManager เขียนฟิลด์นี้ลงในฐานข้อมูลผ่านการฟังบนวัสดุหรือเหตุการณ์ของระบบ

3.ความต่อเนื่องหรือการบันทึกเหตุการณ์

• คุณสามารถเรียกใช้อินเทอร์เฟซเช่น PersistenceManager.storeComponentData(eid, “Goal”) เพื่อลดความซับซ้อนของไลบรารีที่จุดสำคัญบางประการในระบบ (เช่นเมื่อแผนเป้าหมายถูกอัปเดตหรือเมื่อเกิดเหตุการณ์สำคัญบางอย่างบนเอเจนต์)

• คุณยังสามารถให้ StateManager สแกนคอมโพเนนต์หรือเอนทิตี้ที่มีแท็ก "needsPersistence" ใน CleanupSystem หรือตั้งเวลา และเขียนข้อมูลกลับไปยังฐานข้อมูลทันที

• นอกจากนี้ยังสามารถเก็บข้อมูลบันทึกหรือตรวจสอบ (เช่นประวัติการดำเนินการ, บันทึกความคิด) ไว้ที่นี่

4.บันทึกหรือปิดการใช้งานแบบกำหนดเอง (Checkpointing & Persistence ขณะปิด)

• เมื่อเซิร์ฟเวอร์หรือกระบวนการต้องการปิดใช้งาน ให้ใช้ StateManager.saveAll() เพื่อเขียนข้อมูลที่ยังไม่ได้เขียนลงในฐานข้อมูลเพื่อให้แน่ใจว่าสถานะ ECS สามารถกู้คืนได้ครั้งต่อไปเมื่อโหลด

• สำหรับบางสถานการณ์ที่เป็นเอนกประสงค์/ออฟไลน์ สามารถเรียกใช้เอกสารเองได้ด้วยตนเอง

• กระบวนการตัวอย่างที่สมบูรณ์

ข้อความต่อไปนี้คือสถานการณ์ที่ง่ายเพื่อแสดงให้เห็นถึงวิธีที่สามารถเกิดปฏิสัมพันธ์ระหว่างส่วนประกอบและฐานข้อมูลได้

1. ระยะเริ่มต้น: StateManager.queryDB(“SELECT * FROM agents”) → รับชุดบันทึกตัวแทน สร้าง Entity (EID=x) สำหรับแต่ละบันทึกตามลำดับ และเริ่มต้นเขตความจำ, วัตถุประสงค์ และฟิลด์อื่น ๆ ของเอกสาร

ในเวลาเดียวกัน, โหลดข้อมูลห้องจากตาราง 'ห้อง' และสร้างองค์ประกอบห้อง

2. การดำเนินการในเวลาที่ระบบ: PerceptionSystem ตรวจจับเหตุการณ์ "MagicSword ปรากฏขึ้น" ในห้องที่กำหนดและเขียน Perception.currentStimuli[eid] ExperienceSystem แปลง Stimuli เป็น Experience และกำหนดให้ Memory.experiences[eid] คิดค้นการกระทำถัดไปขึ้นอยู่กับ Memory, Goal และข้อมูลอื่นๆและสร้าง Action.pendingAction[eid] หลังจากที่ ActionSystem ดำเนินการกระทำแล้ว จะเขียนผลลัพธ์ลงใน Memory หรือ Action.lastActionResult หากนี้เป็นเหตุการณ์สำคัญในเรื่องหลัก ส่วนท้ายล่าสุดของ Memory.experiences[eid] จะถูกทำเครื่องหมายว่า needsPersistence หลังจากผ่านไปสักพัก StateManager พบว่า Memory.experiences[eid] มี "needsPersistence" และเขียนลงในฐานข้อมูล (INSERT INTO memory_experiences...)

3.Stop หรือ Checkpoint Save: ขึ้นอยู่กับ ECS หรือการจัดกําหนดการระบบ StateManager.saveAll() จะถูกเรียกเมื่อ "เซิร์ฟเวอร์ถูกปิด" เพื่อเขียนสถานะล่าสุดของฟิลด์ส่วนประกอบหลัก (Agent, Memory, Goal ฯลฯ ) ที่ยังคงอยู่ในหน่วยความจําลงในฐานข้อมูล ครั้งต่อไปที่คุณรีบูตสถานะโลกของ ECS สามารถโหลดและกู้คืนจากฐานข้อมูลได้

• การจัดหมวดหมู่ส่วนประกอบไม่เพียงช่วยในการจัดการข้อมูลขององค์กรในโครงการอย่างชัดเจนเท่านั้น แต่ยังช่วยในการควบคุมขอบเขตข้อมูลระหว่าง "ต้องการคงทน" และ "มีอยู่เฉพาะในหน่วยความจำเท่านั้น"

• ปฏิสัมพันธ์กับฐานข้อมูลมักจะถูกจัดการโดยผู้จัดการที่เชี่ยวชาญ (เช่น StateManager) และระบบทำงานผ่านมันเมื่อต้องการอ่านและเขียนข้อมูลลงในฐานข้อมูลโดยหลีกเลี่ยงการเขียน SQL โดยตรงหรือคำสั่งระดับต่ำที่คล้ายกันในระบบ

• ด้วยวิธีนี้ คุณสามารถเพลิดเพลินไปพร้อมกันกับความมีประสิทธิภาพทางตรรกะและความยืดหยุ่นของ ECS พร้อมกับข้อดีของความต่อทน การกลับมาจุดเริ่มต้น และการวิเคราะห์ข้อมูลที่นำมาโดยฐานข้อมูล

4. นวัตกรรมทางสถาปัตยกรรม

จุดเด่นของทั้งสถาปัตยกรรมคือ:

• แต่ละระบบทํางานอย่างอิสระและไม่มีความสัมพันธ์ในการโทรกับระบบอื่น ๆ ดังนั้นแม้ว่าเราต้องการใช้ "การรับรู้การเปลี่ยนแปลงในสภาพแวดล้อม (การรับรู้) ของตัวแทน→บันทึกหรือเปลี่ยนเป็นประสบการณ์ภายใน (ประสบการณ์) → การคิดด้วยตนเองและการตัดสินใจ (การคิด) → นําไปปฏิบัติ (การกระทํา) → ปรับเป้าหมายและแผนแบบไดนามิก (GoalPlanning + Planning) → ซิงโครไนซ์สภาพแวดล้อม (ห้อง) → ความสามารถรีไซเคิลเอนทิตีที่ไร้ประโยชน์ในเวลาที่เหมาะสม (การล้างข้อมูล) " ความสามารถแต่ละระบบจะมีการพึ่งพาซึ่งกันและกันมากมายในการทํางาน แต่เรายังคงสามารถใช้สถาปัตยกรรม ECS เพื่อจัดโครงสร้างทั้งหมดให้เป็นระบบอิสระได้ แต่ละระบบยังคงสามารถทํางานได้อย่างอิสระและจะไม่โต้ตอบกับระบบอื่น มีผู้คนและความสัมพันธ์แบบคัปปลิ้ง
• ฉันคิดว่านี่เป็นเหตุผลหลักที่ Unity ได้ย้ายไปใช้โครงสร้าง ECS มากขึ้นในปีหลัง
• และตัวอย่างเช่น ฉันเพียงแค่ต้องการให้เอเจนต์มีความสามารถพื้นฐานบางอย่างเท่านั้น ฉันเพียงแค่ต้องการลดการลงทะเบียนของส่วนประกอบบางส่วนและการลงทะเบียนของระบบเมื่อกำหนด Entity ซึ่งสามารถทำได้ง่ายๆโดยไม่ต้องเปลี่ยนบรรทัดโค้ดน้อยๆ

ตามที่แสดงด้านล่าง:

ในเวลาเดียวกันหากคุณต้องการเพิ่มฟังก์ชันใหม่ในระหว่างกระบวนการพัฒนา จะไม่มีผลกระทบต่อระบบอื่น ๆ และคุณสามารถโหลดฟังก์ชันที่ต้องการได้อย่างง่ายดาย

• นอกจากนี้ประสิทธิภาพของสถาปัตยกรรมปัจจุบันจริงๆ แล้วดีกว่าสถาปัตยกรรมเชิงวัตถุแบบดั้งเดิม นี่เป็นสิ่งที่รู้จักในวงการเกม เพราะการออกแบบของ ECS นั้นเหมาะสำหรับการทำงานพร้อมกัน ดังนั้นเมื่อเราใช้ ECS ในสถานการณ์ Defai ที่ซับซ้อน สถาปัตยกรรมอาจมีข้อดีมากขึ้น โดยเฉพาะในสถานการณ์ที่คาดว่าตัวแทนจะถูกใช้สำหรับธุรกรรมทางปริมาณ ECS ก็จะเป็นประโยชน์ (ไม่ใช่เฉพาะในสถานการณ์เกมตัวแทน)
• การแบ่งระบบเป็นอัตราการฉลาด อคติ และไร้ความตระหนกเพื่อแยกแยะว่าระบบชนิดต่าง ๆ ควรถูกดำเนินการบ่อยขนาดไหน นั้นเป็นการออกแบบอย่างชาญฉลาดและเป็นความสามารถของมนุษย์ที่มีเชื่อมั่นมากแล้ว

จากมุมมองส่วนตัวของฉัน นี่เป็นกรอบงานที่มีโมดูลอย่างยิ่งและประสิทธิภาพที่ดีมาก คุณภาพของโค้ดยังสูงมากและมีเอกสารออกแบบที่ดี แต่น่าเสียดายที่โครงการ 89 ขาดความเห็นและการส่งเสริมโดยเฉพาะสำหรับกรอบงานนี้ นี่เป็นเหตุผลที่ฉันใช้เวลาสี่วันเขียนบทความนี้เพื่อเน้นจุดเด่นของมัน ฉันเชื่อว่าเทคโนโลยีที่ยอดเยี่ยมควรได้รับการยอมรับและพรุ่งนี้ฉันวางแผนที่จะเผยแพร่เวอร์ชันภาษาอังกฤษของบทความนี้เพื่อเพิ่มความตระหนักรู้ในทีมเกมและนักพัฒนา DeFi (Decentralized Finance) หวังว่าทีมจะสำรวจกรอบงานนี้เพื่อเลือกเป็นทางเลือกสถาปัตยกรรมสำหรับโครงการของพวกเขา!

คำประกาศ:

1. บทความนี้ถูกคัดลอกมาจาก[0xhhh]. ส่งต่อชื่อเดิม: ฉันเห็น The Next Generation Agent Framework ใน Project89 ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [0xhhh]. หากคุณมีการโต้แย้งใด ๆ เกี่ยวกับการเผยแพร่ฉบับสำเนา กรุณาติดต่อ Gate Learnทีมผู้บริหาร ทีมจะดำเนินการตามขั้นตอนที่เกี่ยวข้องโดยเร็วที่สุด
2. คำอธิบาย: มุมมองและความเห็นที่แสดงในบทความนี้เป็นเพียงมุมมองส่วนตัวของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำในการลงทุนใด ๆ
3. เวอร์ชันภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn หากไม่ระบุไว้เป็นอย่างอื่น บทความที่ถูกแปลอาจไม่สามารถคัดลอก แจกจ่าย หรือลอกเลียน