Chuyển tiếp Tiêu đề Ban đầu: Tôi Nhìn Thấy Khung làm việc Đại diện Thế hệ Tiếp theo trong Dự án89

Để đi thẳng vào vấn đề,@project_89adopts an entirely new approach to designing an Agent Framework. This is a high-performance Agent Framework specifically for game development. Compared to currently used Agent Frameworks, it is more modular and offers better performance.

Bài viết này mất rất nhiều thời gian để viết, cố gắng để mọi người hiểu rõ hơn về những nâng cấp kiến trúc mà framework này đã thực hiện so với framework Agent truyền thống. Nó đã được chỉnh sửa nhiều lần trước phiên bản này, nhưng vẫn còn một số phần trong bài viết quá khó hiểu. Do khó khăn kỹ thuật, tôi không thể tiếp tục phổ biến nó nữa. Nếu bạn có bất kỳ đề xuất nào để cải thiện bài viết, xin vui lòng để lại ý kiến của bạn.

Lý lịch phát triển viên

Vì đây là một blog kỹ thuật, hãy trước tiên xem xét về chuyên môn kỹ thuật của người sáng lập.

Trước khi làm việc trên Dự án89, người sáng lập đã phát triển dự án này:https://github.com/Oneirocom/Magick, cũng là một phần mềm lập trình được trang bị trí tuệ nhân tạo. Ngoài ra, Shaw cũng được xếp hạng là nhà phát triển hàng đầu thứ tư của dự án này. Bạn cũng có thể thấy dự án này trong danh mục của Shaw.

Trên bên trái: người sáng lập của project89; Dưới bên phải: ‘lalaune’ là Shaw của ai16z

Hôm nay chúng tôi sẽ chủ yếu giới thiệu Framework Đại lý hiệu suất cao trong dự án89:

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

1. Tại sao sử dụng ECS để thiết kế một khung việc cho đại lý?

Từ quan điểm ứng dụng trong lĩnh vực game

Các trò chơi hiện đang sử dụng kiến trúc ECS bao gồm:

Trò chơi Blockchain: Mud, Dojo

Các trò chơi truyền thống: Overwatch, Star Citizen, vv.

Hơn nữa, các công cụ game phổ biến đang phát triển theo kiến trúc ECS, như Unity.

ECS là gì?

ECS (Entity-Component-System) là một mô hình kiến trúc thường được sử dụng trong phát triển game và hệ thống mô phỏng. Nó hoàn toàn tách biệt dữ liệu và logic để quản lý một cách hiệu quả các thực thể và hành vi của họ trong các kịch bản có khả năng mở rộng lớn:

Thực thể

• Chỉ là một ID (số hoặc chuỗi), không chứa dữ liệu hoặc logic.

• Bạn có thể gắn kết các thành phần khác nhau để cung cấp cho nó các tính chất hoặc khả năng khác nhau theo nhu cầu.

Thành phần

• Được sử dụng để lưu trữ dữ liệu cụ thể hoặc trạng thái của một thực thể.

Hệ thống

• Chịu trách nhiệm thực hiện logic liên quan đến một số thành phần.

Hãy sử dụng một ví dụ cụ thể về hành động của Đại lý để hiểu hệ thống này:

Trong ArgOS, mỗi Đại lý được coi như một Thực thể, có thể đăng ký các thành phần khác nhau. Ví dụ, trong hình dưới đây, Đại lý của chúng tôi có bốn thành phần sau:

Component Đại lý: chủ yếu lưu trữ thông tin cơ bản như tên Đại lý, tên mô hình, v.v.

Bộ Phận Nhận Thức: Chủ yếu được sử dụng để lưu trữ dữ liệu bên ngoài được nhận thức

Bộ nhớ: Chủ yếu được sử dụng để lưu trữ dữ liệu bộ nhớ của Thực thể Đại lý, các công việc tương tự đã được thực hiện, v.v.

Component Hành động: Chủ yếu lưu trữ dữ liệu Hành động để thực thi

Quy trình hệ thống:

1. Trong trò chơi này, ví dụ, nếu bạn cảm nhận một vũ khí phía trước bạn, thì hàm thực thi của Hệ thống Nhận thức sẽ được gọi để cập nhật dữ liệu trong Bộ phận Nhận thức của Thực thể Đặc vụ.
2. Sau đó kích hoạt Hệ thống Bộ nhớ, gọi Thành phần Nhận thức và Thành phần Bộ nhớ cùng một lúc, và lưu trữ dữ liệu nhận thức vào cơ sở dữ liệu thông qua Bộ nhớ.
3. Sau đó, Hệ thống Hành động gọi thành phần Bộ nhớ và thành phần Hành động để lấy thông tin môi trường xung quanh từ bộ nhớ, và sau đó thực hiện hành động tương ứng.

Sau đó chúng ta nhận được một Đại lý Cập nhật Thực thể trong đó dữ liệu mỗi thành phần được cập nhật.

4. Vì vậy, chúng ta có thể thấy rằng Hệ thống ở đây chịu trách nhiệm chủ yếu để xác định các thành phần nào để thực thi logic xử lý tương ứng.

Và rõ ràng trong project89, đó là một thế giới đầy đủ các loại Đặc vụ. Ví dụ, một số Đặc vụ không chỉ có khả năng cơ bản như đã nêu trên mà còn có khả năng lập kế hoạch.

Sau đó, nó sẽ được hiển thị như trong hình ảnh dưới đây:

Luồng Thực Thi Hệ Thống

Tuy nhiên, khác với các khung việc truyền thống khác, trong đó một hệ thống kích hoạt trực tiếp hệ thống khác (ví dụ, Hệ thống Nhận thức gọi Hệ thống Bộ nhớ), trong Project89, các hệ thống không gọi nhau trực tiếp. Thay vào đó, mỗi hệ thống chạy độc lập trong các khoảng thời gian cố định. Ví dụ:

• Hệ thống Perception chạy sau mỗi 2 giây để cập nhật thành phần Perception với dữ liệu môi trường mới nhận được.
• Hệ thống Bộ nhớ chạy mỗi 1 giây, trích xuất dữ liệu từ thành phần Nhận thức và lưu trữ trong thành phần Bộ nhớ.
• Hệ thống Kế hoạch chạy mỗi 1000 giây, phân tích dữ liệu đã thu thập để xác định xem nó cần tối ưu hóa và tạo kế hoạch mới, sau đó được ghi lại trong Phần Kế hoạch.
• Hệ thống Hoạt động chạy qua mỗi 2 giây, phản ứng với các thay đổi môi trường và điều chỉnh các hoạt động dựa trên các cập nhật từ thành phần Kế hoạch.

Cho đến nay, bài viết này đã đơn giản hóa đáng kể kiến trúc của ArgOS để làm cho nó dễ hiểu hơn. Bây giờ, hãy cùng nhau xem xét kỹ hơn về hệ thống ArgOS thực sự.

2. Kiến trúc hệ thống ArgOS

Để cho phép Đại lý suy nghĩ sâu hơn và thực hiện các nhiệm vụ phức tạp hơn, ArgOS đã thiết kế nhiều Thành phần và nhiều Hệ thống.

Và ArgOS chia Hệ thống thành "ba cấp độ" (ConsciousnessLevel):

1) hệ thống CONSCIOUS

• Bao gồm Hệ thống Phòng, Hệ thống Nhận thức, Hệ thống Trải nghiệm, Hệ thống Tư duy, Hệ thống Hành động, Hệ thống Dọn dẹp
• Tần suất cập nhật thường cao hơn (ví dụ mỗi 10 giây).
• Xử lý gần hơn với mức độ "thời gian thực" hoặc "ý thức", chẳng hạn như nhận thức môi trường, suy nghĩ thời gian thực, thực hiện hành động, v.v.

2) Hệ thống tiềm thức (SUBCONSCIOUS)

• Hệ Thống Lập Kế Hoạch, Hệ Thống Lập Kế Hoạch
• Tần suất cập nhật tương đối thấp (ví dụ mỗi 25 giây).
• Xử lý logic "suy nghĩ" như kiểm tra / tạo ra định hướng và kế hoạch định kỳ.

3) Hệ thống vô thức (VÔ THỨC)

• Chưa được kích hoạt
• Tần suất cập nhật chậm hơn (ví dụ hơn 50 giây),

Do đó, trong ArgOS, các Hệ thống khác nhau được chia theo ConsciousnessLevel để quy định tần suất mà Hệ thống này sẽ được thực hiện.

Tại sao nó được thiết kế như vậy?

Vì mối quan hệ giữa các hệ thống khác nhau trong ArgOS rất phức tạp, như được thể hiện dưới đây:

1. Hệ thống Nhận thức là trách nhiệm của việc thu thập “tác nhân kích thích” từ thế giới bên ngoài hoặc các thực thể khác và cập nhật chúng vào thành phần Nhận thức của Đại lý.

Xác định xem tác nhân kích thích có thay đổi đáng kể và cập nhật tương ứng dựa trên tính ổn định, chế độ xử lý (ACTIVE/REFLECTIVE/WAITING), v.v.

Cuối cùng, dữ liệu "nhận thức hiện tại" được cung cấp cho các hệ thống Kinh nghiệm, Tư duy, v.v. sau này.

2.ExperienceSystem chuyển đổi các Kích thích được thu thập bởi PerceptionSystem thành một "trải nghiệm" trừu tượng hơn.

LLM hoặc logic luật (extractExperiences) được gọi là để xác định các trải nghiệm mới và lưu trữ trong thành phần Bộ nhớ.

Loại bỏ trùng lặp, lọc và xác minh các trải nghiệm, đồng thời kích hoạt sự kiện “trải nghiệm” đến các hệ thống khác hoặc người nghe bên ngoài thông qua eventBus.

3. ThinkingSystem đại diện cho quá trình suy nghĩ nội tại của người đại diện.

Trích xuất trạng thái hiện tại từ các thành phần như Bộ nhớ và Nhận thức, và tạo ra 'Kết quả suy nghĩ' thông qua generateThought(...) và logic LLM/rule.

Dựa trên kết quả suy nghĩ, nó có thể:

• Cập nhật suy nghĩ trong Bộ nhớ (lịch sử suy nghĩ).

• Kích hoạt một hành động mới (đưa vào Action.pendingAction[eid]).

• Thay đổi Bề ngoài bên ngoài của đặc vụ (biểu cảm, tư thế, v.v.) và tạo ra các Kích thích liên quan để cho các thực thể khác “nhìn thấy” sự thay đổi.

4. Hệ thống Hành động thực hiện các hành động nếu Hành động.chờ xử lýkhông trống, sử dụngruntime.getActionManager().executeAction(…).

Sau khi thực thi, ghi kết quả lại vào Action.lastActionResult và thông báo cho phòng hoặc các thực thể khác.

Điều này cũng tạo ra một CognitiveStimulus (kích thích nhận thức) để các hệ thống sau này “biết” rằng hành động đã được hoàn thành, hoặc có thể được tích hợp vào bộ nhớ.

5. Hệ thống Lập kế hoạch Mục tiêu định kỳ đánh giá tiến trình của các mục tiêu trong danh sách Mục tiêu hiện tại [eid] của Mục tiêu, hoặc kiểm tra bộ nhớ ngoại vi/tự sở hữu để xác định những thay đổi đáng kể (detectSignificantChanges).

Khi cần mục tiêu mới hoặc điều chỉnh mục tiêu, tạo và viết Goal.current[eid] thông qua generateGoals (...).

Cùng lúc đó, mục tiêu đang tiến hành (in_progress) được cập nhật. Nếu điều kiện hoàn thành hoặc thất bại được đáp ứng, trạng thái sẽ thay đổi và một tín hiệu hoàn thành/thất bại sẽ được gửi đến Kế hoạch tương ứng.

6. Hệ thống lập kế hoạch tạo ra hoặc cập nhật Kế hoạch (kế hoạch thực hiện) cho “mục tiêu hiện tại” (Mục tiêu hiện tại [eid]).

Nếu phát hiện rằng một số mục tiêu không có kế hoạch hoạt động tương ứng, tạo một lộ trình thực hiện chứa một số bước thông qua generatePlan(…) và ghi nó vào Plan.plans[eid].

Khi mục tiêu được hoàn thành hoặc thất bại, trạng thái Kế hoạch liên quan sẽ được cập nhật và tạo ra kích thích nhận thức tương ứng.

7. Hệ thống Phòng xử lý các cập nhật liên quan đến phòng:

• Lấy danh sách những người cư ngụ trong phòng (người cư ngụ) và tạo ra các kích thích "xuất hiện" cho mỗi tác nhân để cho các thực thể khác "nhìn thấy" ngoại hình hoặc hành động của mình.

• Tạo và liên kết kích thích môi trường phòng (ví dụ: thông tin "bầu không khí phòng" phù hợp).

Đảm bảo rằng khi Đại lý đang ở trong một môi trường không gian nhất định, các thực thể khác đang cảm nhận không gian có thể nhận thấy sự thay đổi trong diện mạo của anh ta.

8. Hệ thống dọn dẹp định kỳ tìm và loại bỏ các thực thể được đánh dấu bằng thành phần Cleanup. Được sử dụng để tái chế Kích thích hoặc các đối tượng khác không còn cần thiết để ngăn ngừa việc để lại một số lượng lớn các thực thể không hợp lệ trong ECS.

• Ví dụ: một vòng lặp từ “nhìn thấy đối tượng” đến “thực hiện hành động”

Ví dụ cảnh sau cho thấy cách mỗi Hệ thống hợp tác để hoàn thành một quy trình hoàn chỉnh trong một vòng (hoặc một số khung hình).

Chuẩn bị cảnh: Trong thế giới có một Đặc vụ (EID=1), đang ở trạng thái "Hoạt động" và đang ở một Phòng (EID=100).

Một prop mới 'MagicSword' xuất hiện trong Phòng này, và tạo ra Sự kích tương ứng.

1. PerceptionSystem phát hiện sự xuất hiện của “MagicSword”, tạo ra kích thích (loại = “item_appearance”) cho Agent(1) và thêm nó vào Perception.currentStimuli[1].So với Hash kích thích trước đó, xác định rằng có một “thay đổi đáng kể” và ProcessingState của agent là “kích hoạt lại” (chế độ ACTIVE).
2. Hệ thống Kinh nghiệm nhận thấy rằng Perception.currentStimuli của Đại lý(1) không trống, vì vậy nó trích xuất thông tin như “Roi xuất hiện” thành một hoặc nhiều Kinh nghiệm mới (loại: “quan sát”). Lưu trữ nó trong Memory.experiences[1] và phát ra sự kiện “kinh nghiệm”.
3. ThinkingSystem đọc thông tin Bộ nhớ, Nhận thức và các thông tin trạng thái khác và gọi hàm generateThought:

“Tôi nhìn thấy thanh kiếm Ma Thuật, có lẽ nên nhặt lên và xem nó có thể làm gì…” Kết quả suy nghĩ chứa một Hành động để thực hiện: { công cụ: “nhặtVật phẩm”, tham số: { tênVật phẩm: “thanhKiếmMaThuật” } }

ThinkingSystem viết hành động này vào Action.pendingAction[1].

Nếu có sự thay đổi về diện mạo (ví dụ: "mặt với biểu cảm tò mò"), diện mạo sẽ được cập nhật và kích thích thị giác được tạo ra.

4. ActionSystem nhìn thấy Action.pendingAction[1] = {tool: “pickUpItem”, parameters: …}.

Thực hiện logic hành động “pickup” thông qua runtime.getActionManager().executeAction(“pickUpItem”, 1, { itemName: “MagicSword” }, runtime). Nhận kết quả: { success: true, message: “Bạn đã nhặt thanh kiếm ma thuật” }, cập nhật vào Action.lastActionResult[1], và kích hoạt sự kiện “action” để phát sóng đến phòng (100).

Đồng thời, một kích thích nhận thức (type = "action_result") được tạo ra, ghi vào Bộ nhớ hoặc được Hệ thống tư duy nắm bắt trong lượt tiếp theo.

5. Hệ thống lập kế hoạch mục tiêu (nếu người đại diện có mục tiêu) định kỳ đánh giá mục tiêu của người đại diện. Nếu một trong các mục tiêu của người đại diện vào thời điểm này là "đạt được một vũ khí mạnh", và phát hiện rằng MagicSword đã được đạt được, mục tiêu có thể được đánh dấu là hoàn thành. Nếu có thay đổi mới xảy ra (ví dụ: "đối tượng mới xuất hiện trong phòng" ảnh hưởng đến mục tiêu mà người đại diện theo đuổi?), tạo một mục tiêu mới hoặc từ bỏ mục tiêu cũ dựa trên việc phát hiện các thay đổi quan trọng.
6. Hệ thống Kế hoạch (nếu có mục tiêu liên quan) kiểm tra xem có cần Kế hoạch mới hay cập nhật Kế hoạch hiện có cho các mục tiêu đã hoàn thành hoặc mới tạo ra như “Thu được vũ khí mạnh mẽ”.

Nếu hoàn thành, đặt kế hoạch liên quan [trạng thái] thành “hoàn thành”, hoặc tạo thêm bước nếu mục tiêu là mở rộng quy trình tiếp theo ("Nghiên cứu thanh kiếm ma thuật").

7. Hệ thống Room cập nhật danh sách của Người chiếm đóng và các thực thể hiển thị trong phòng (100) (mỗi khung hoặc vòng).

Nếu diện mạo của đặc vụ(1) thay đổi (ví dụ, Appearance.currentAction = "nắm kiếm"), tạo một kích thích thị giác mới "diện mạo" để cho phép Đặc vụ2 và Đặc vụ3 trong cùng một phòng biết rằng "đặc vụ1 đã nhặt lấy kiếm".

8. CleanupSystem loại bỏ các thực thể hoặc stimuli đã được đánh dấu (Cleanup). Nếu bạn không còn cần giữ kích thích "MagicSword" sau khi nhặt nó lên, bạn có thể xóa thực thể kích thích tương ứng trong CleanupSystem.

1. Thông qua kết nối của các hệ thống này, AI Agent đạt được:

• Nhận biết sự thay đổi trong môi trường (Nhận thức) → Ghi lại hoặc biến đổi thành trải nghiệm bên trong (Trải nghiệm) → Tự suy nghĩ và ra quyết định (Suy nghĩ) → Đưa vào hành động (Hành động) → Điều chỉnh mục tiêu và kế hoạch một cách linh hoạt (MụcTiêuKếHoạch + KếHoạch) → Đồng bộ hóa với môi trường (Phòng) → Tái sử dụng các thực thể không cần thiết đúng thời điểm (Dọn dẹp)

3. Phân tích kiến trúc tổng thể của ArgOS

1. Lớp Kiến trúc Cốt lõi

2. Phân loại thành phần

Trong ECS, mỗi thực thể có thể có nhiều thành phần. Theo tính chất và vòng đời trong hệ thống, các thành phần có thể được chia thành các loại sau:

1. Lớp Các thành phần cấp bậc danh tính (Cấu trúc cốt lõi danh tính)

• Agent / PlayerProfile / NPCProfile, v.v.

• Được sử dụng để định danh duy nhất các thực thể, lưu trữ vai trò cốt lõi hoặc thông tin đơn vị, và thông thường cần được lưu trữ vào cơ sở dữ liệu.

2. Thành phần Hành vi & Trạng thái

• Hành động, Mục tiêu, Kế hoạch, Trạng thái xử lý, v.v.

• Đại diện cho điều mà thực thể đang cố gắng thực hiện hoặc mục tiêu của nó, cũng như trạng thái phản ứng đối với các lệnh từ bên ngoài và suy nghĩ bên trong.

• Chứa pendingAction, goalsInProgress, plans và thoughts hoặc nhiệm vụ trong hàng đợi, v.v.

• Thường là các trạng thái trung và ngắn hạn, nhiều trạng thái thay đổi động trong các vòng chơi hoặc chu kỳ kinh doanh.

• Việc cần phải cung cấp hàng hóa phụ thuộc vào tình hình. Nếu bạn muốn tiếp tục chạy sau một điểm dừng, bạn có thể ghi vào cơ sở dữ liệu định kỳ.

3. Perception & Memory Components

• Nhận thức, Trí nhớ, Kích thích, Kinh nghiệm, v.v.

• Ghi lại thông tin bên ngoài (Kích thích) mà thực thể cảm nhận được và những trải nghiệm được tinh refine sau quá trình cảm nhận (Kinh nghiệm).

• Bộ nhớ thường có thể tích lũy một lượng lớn dữ liệu, như lưu trữ cuộc trò chuyện, lịch sử sự kiện, v.v.; thường cần có tính liên tục.

• Nhận thức có thể là thông tin thời gian thực hoặc tạm thời, phần lớn có hiệu lực trong thời gian ngắn. Bạn có thể quyết định viết nó vào cơ sở dữ liệu tùy theo nhu cầu của bạn (ví dụ, chỉ lưu trữ các sự kiện nhận thức quan trọng).

4. Lớp môi trường và không gian (Room, OccupiesRoom, Spatial, Environment, Inventory, v.v.)

• Đại diện cho thông tin như phòng, môi trường, vị trí, đồ đựng đồ vật, v.v.

•Room.id, OccupiesRoom, Môi trường và các lĩnh vực khác thường cần được lưu lại, như mô tả trang chủ phòng, cấu trúc bản đồ, v.v.

• Thay đổi các thành phần (ví dụ như một Thực thể di chuyển giữa các phòng) có thể được viết theo sự kiện hoặc định kỳ.

5. Các lớp về giao diện và tương tác (Giao diện, Trạng thái giao diện người dùng, Mối quan hệ, v.v.)

• Ghi lại các phần "hiển thị" hoặc "tương tác" bên ngoài của thực thể, chẳng hạn như Avatar, tư thế, biểu hiện khuôn mặt, mạng quan hệ xã hội với các thực thể khác, v.v.

• Một số phần có thể được xử lý chỉ trong bộ nhớ (biểu diễn thời gian thực), trong khi các phần khác (như mối quan hệ xã hội quan trọng) có thể được lưu trữ.

6. Các thành phần Tiện ích & Bảo trì (Dọn dẹp, Thông tin Debug, Dữ liệu Profiling, vv.)

• Được sử dụng để đánh dấu các thực thể cần tái chế (Cleanup), hoặc ghi lại thông tin gỡ lỗi (DebugInfo) để sử dụng trong quá trình giám sát và phân tích.

• Thông thường chỉ tồn tại trong bộ nhớ và hiếm khi được đồng bộ hóa vào cơ sở dữ liệu trừ khi cần thiết cho việc ghi nhật ký hoặc kiểm tra.

3. Kiến trúc Hệ thống

Đã giới thiệu ở trên

4. Kiến trúc quản lý

Ngoài các thành phần và hệ thống, một lớp quản lý tài nguyên bổ sung cũng được yêu cầu. Lớp này xử lý việc truy cập cơ sở dữ liệu, xung đột trạng thái và các hoạt động quan trọng khác.

Bên trái: Hệ thống (Hệ thống Nhận thức, Hệ thống Trải nghiệm, Hệ thống Tư duy, v.v.):

• Mỗi hệ thống được lập lịch để thực thi bởi SimulationRuntime trong vòng lặp ECS, truy vấn và xử lý các thực thể mà nó quan tâm (qua các điều kiện thành phần).

• Khi thực hiện logic, bạn cần tương tác với Gate Managers, ví dụ:

• Gọi RoomManager (RM) để truy vấn/cập nhật thông tin phòng.
• Sử dụng StateManager (SM) để lấy hoặc lưu trạng thái thế giới/đại lý như Bộ nhớ, Mục tiêu, Kế hoạch, v.v.
• Truyền phát hoặc lắng nghe sự kiện bên ngoài bằng cách sử dụng EventBus (EB).
• PromptManager (PM) được gọi khi xử lý ngôn ngữ tự nhiên hoặc cần các lời nhắc.

Bên Phải: Quản Lý (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, v.v.)：

• Cung cấp các chức năng cấp hệ thống, về cơ bản không hoạt động "đẩy" logic một cách tích cực, mà được gọi bởi Hệ thống hoặc Runtime.

• Ví dụ điển hình:

• ActionManager chuyên về quản lý đăng ký và thực thi các hành động.
• EventManager / EventBus được sử dụng cho cơ chế xuất bản và đăng ký sự kiện.
• RoomManager quản lý các phòng, bố cục và người sử dụng.
• StateManager đảm nhận việc đồng bộ giữa ECS và cơ sở dữ liệu hoặc lưu trữ.
• PromptManager cung cấp các phần mở rộng như mẫu LLM Prompt và quản lý ngữ cảnh.
• Giả lập Trung gian (R):

• Là "lập lịch" của tất cả các Hệ thống, bắt đầu hoặc dừng các chu kỳ hệ thống ở các cấp độ khác nhau (Tâm thức/Tiềm thức, v.v.);

• Các quản lý cũng được tạo ra trong giai đoạn xây dựng và được truyền cho mỗi Hệ thống để sử dụng.

• CleanupSystem：

• Lưu ý đặc biệt rằng nó cũng tương tác với ComponentSync (CS), được sử dụng để đồng bộ hóa việc loại bỏ các thành phần hoặc đăng ký sự kiện khi tái chế các thực thể.

Kết luận:

Mỗi Hệ thống sẽ đọc và ghi dữ liệu hoặc gọi dịch vụ thông qua Quản lý tương ứng khi cần, và Runtime sẽ đồng nhất lịch trình và hành vi của tất cả các Hệ thống và Quản lý ở mức độ cao hơn.

5. Cách Vector và Cơ sở dữ liệu tương tác trong ECS

Trong một hệ thống ECS, Hệ thống xử lý việc thực thi logic thực tế, trong khi các hoạt động cơ sở dữ liệu (đọc/viết) được quản lý thông qua Một Người quản lý Bền vững (PersistenceManager / DatabaseManager) hoặc Một Người quản lý Trạng thái (StateManager). Quá trình chung là như sau:

1. Khởi tạo Ban đầu (Bắt đầu hoặc Giai đoạn Tải dữ liệu)

• StateManager / PersistenceManager tải dữ liệu của các thành phần lưu trữ cốt lõi như Agents, Rooms, Goals và vân vân từ cơ sở dữ liệu, tạo các thực thể tương ứng (Entities) và khởi tạo các trường thành phần liên quan.

• Ví dụ, đọc một lô hồ sơ đại lý và chèn chúng vào thế giới ECS, và khởi tạo Agent, Memory, Goal và các thành phần khác cho chúng.

2. Thời gian chạy ECS (Vòng lặp cập nhật hệ thống)

• Hệ thống thực hiện các hoạt động trong mỗi khung (hoặc vòng): Hệ thống Nhận thức thu thập “cảm giác” và ghi chúng vào thành phần Nhận thức (chủ yếu là ngắn hạn từ thư viện).

ExperienceSystem viết trải nghiệm "nhận thức mới" vào Memory.experiences. Nếu đó là trải nghiệm chính, nó có thể gọi StateManager để lưu trữ ngay, hoặc đánh dấu nó với "needsPersistence" để sau này ghi theo lô.

ThinkingSystem / ActionSystem / GoalPlanningSystem v.v. đưa ra quyết định dựa trên nội dung thành phần và cập nhật trường trong ECS.

Nếu một số thành phần (như Goal.current) trải qua các thay đổi lớn và yêu cầu sự kiên trì (như một mục tiêu dài hạn mới), hãy thông báo cho StateManager để ghi trường này vào cơ sở dữ liệu thông qua việc lắng nghe thành phần hoặc sự kiện hệ thống.

3. Sự kiên định định kỳ hoặc theo sự kiện

• Bạn có thể gọi các giao diện như PersistenceManager.storeComponentData(eid, "Goal") để xóa thư viện tại một số điểm quan trọng trong hệ thống (ví dụ như khi kế hoạch mục tiêu được cập nhật hoặc khi một sự kiện quan trọng xảy ra trên Đại lý).

• Bạn cũng có thể yêu cầu StateManager quét các thành phần hoặc thực thể có thẻ "needsPersistence" trong CleanupSystem hoặc bộ đếm thời gian, và viết lại chúng vào cơ sở dữ liệu cùng lúc.

• Ngoài ra, dữ liệu nhật ký hoặc dữ liệu kiểm toán (như lịch sử hoạt động, nhật ký suy nghĩ) cũng có thể được lưu trữ và lưu trữ ở đây.

4. Lưu trữ thủ công hoặc tắt máy (Checkpointing & Khả năng tồn tại sau khi thoát)

• Khi máy chủ hoặc quy trình sẽ được tắt, sử dụng StateManager.saveAll () để ghi dữ liệu chưa được viết vào cơ sở dữ liệu một cách đồng nhất để đảm bảo trạng thái ECS có thể được khôi phục lần tải tiếp theo.

• Đối với một số tình huống độc lập/ngoại tuyến, cũng có thể kích hoạt các bản ghi thủ công.

• Quá trình mẫu hoàn chỉnh

Dưới đây là một tình huống đơn giản để minh họa các cách có thể mà các thành phần và cơ sở dữ liệu tương tác:

1. Giai đoạn khởi động: StateManager.queryDB("SELECT * FROM agents") → Lấy một lô bản ghi đại diện, tạo Entity (EID=x) cho từng bản ghi một cách tuần tự và khởi tạo các trường Agent, Memory, Goal và các thành phần khác.

Đồng thời, tải thông tin phòng từ bảng “rooms” và tạo một thực thể Phòng.

2. Hoạt động thời gian chạy: Hệ thống Nhận thức phát hiện sự kiện "MagicSword xuất hiện" trong một phòng nhất định và ghi Perception.currentStimuli[eid]. Hệ thống Trải nghiệm chuyển đổi Kích thích thành Trải nghiệm và gán nó cho Memory.experiences[eid]. Hệ thống Tư duy xác định hành động tiếp theo dựa trên Memory, Mục tiêu và thông tin khác và tạo Action.pendingAction[eid]. Sau khi Hệ thống Hành động thực hiện hành động, nó ghi kết quả vào Memory hoặc Action.lastActionResult. Nếu đây là một sự kiện cốt truyện chính, phần cuối cùng nhất của Memory.experiences[eid] sẽ được đánh dấu là needsPersistence. Sau một thời gian, StateManager nhận thấy rằng Memory.experiences[eid] có "needsPersistence" và ghi nó vào cơ sở dữ liệu (INSERT INTO memory_experiences...).

3. Dừng hoặc Lưu điểm kiểm tra: Dựa trên lịch trình ECS hoặc hệ thống, StateManager.saveAll() được gọi khi “máy chủ được tắt” để ghi lại trạng thái mới nhất của các trường thành phần chính (Agent, Bộ nhớ, Mục tiêu, v.v.) vẫn còn trong bộ nhớ vào cơ sở dữ liệu. Lần khởi động tiếp theo, trạng thái thế giới ECS có thể được tải và khôi phục từ cơ sở dữ liệu.

• Phân loại các thành phần không chỉ giúp quản lý dữ liệu thực thể trong dự án một cách rõ ràng, mà còn giúp chúng tôi kiểm soát ranh giới dữ liệu giữa "yêu cầu lưu trữ" và "chỉ tồn tại trong bộ nhớ".

• Tương tác với cơ sở dữ liệu thường được xử lý bởi một Quản lý chuyên dụng (như StateManager), và Hệ thống hoạt động thông qua nó khi cần đọc và ghi vào cơ sở dữ liệu, tránh việc trực tiếp viết SQL hoặc các câu lệnh cấp thấp tương tự trong Hệ thống.

• Bằng cách này, bạn có thể đồng thời tận hưởng hiệu quả logic và linh hoạt của ECS, cũng như những lợi ích về sự kiên trì, việc tiếp tục điểm dừng và phân tích thống kê dữ liệu mà cơ sở dữ liệu mang lại.

4. Cải tiến kiến trúc

Những điểm nổi bật của toàn bộ kiến trúc là:

• Mỗi Hệ thống chạy độc lập và không có mối quan hệ gọi điện với các Hệ thống khác. Do đó, ngay cả khi chúng ta muốn triển khai khả năng "Nhận thức thay đổi trong môi trường (Nhận thức) → Ghi hoặc biến đổi thành trải nghiệm bên trong (Trải nghiệm) → Tự suy nghĩ và ra quyết định (Suy nghĩ) → Đưa ra hành động (Hành động) → Điều chỉnh động thái mục tiêu và kế hoạch (Lập kế hoạch mục tiêu + Lập kế hoạch) → Đồng bộ hóa môi trường (Phòng) → Tái chế kịp thời các thực thể vô dụng (Dọn dẹp)", mỗi hệ thống sẽ có nhiều phụ thuộc trong chức năng, nhưng chúng ta vẫn có thể sử dụng kiến trúc ECS để cấu trúc toàn bộ thành các hệ thống độc lập. Mỗi hệ thống vẫn có thể chạy độc lập và sẽ không tương tác với các hệ thống khác. Có người và mối quan hệ gắn kết.
• Tôi nghĩ đây cũng là lý do chính mà Unity ngày càng chuyển sang kiến trúc ECS trong những năm gần đây.
• Và ví dụ, tôi chỉ muốn một Đại lý có một số khả năng cơ bản. Tôi chỉ cần giảm đăng ký một số thành phần và đăng ký Hệ thống khi xác định Thực thể, điều này có thể dễ dàng đạt được mà không cần thay đổi một vài dòng code.

Như được hiển thị dưới đây:

Cùng lúc đó, nếu bạn muốn thêm các chức năng mới trong quá trình phát triển, nó sẽ không ảnh hưởng đến các hệ thống khác, và bạn có thể dễ dàng tải các chức năng bạn muốn.

• Ngoài ra, hiệu suất của kiến trúc hiện tại thực tế còn tốt hơn nhiều so với kiến trúc hướng đối tượng truyền thống. Điều này là một sự thực được công nhận trong cộng đồng game thủ, vì thiết kế ECS phù hợp hơn với đồng thời, vì vậy khi chúng ta sử dụng ECS trong các kịch bản Defai phức tạp, kiến trúc cũng có thể có nhiều ưu điểm hơn, đặc biệt là trong các kịch bản mà người chơi mong đợi sử dụng các giao dịch định lượng, ECS cũng sẽ hữu ích (không chỉ trong các kịch bản game của đại lý).
• Phân chia hệ thống thành ý thức, tiềm thức và vô thức để phân biệt cách thực hiện các loại hệ thống khác nhau là một thiết kế rất thông minh và đã là một khả năng con người rất cụ thể.

Từ quan điểm cá nhân của tôi, đây là một khung công việc cực kỳ linh hoạt với hiệu suất xuất sắc. Chất lượng mã cũng rất cao và chứa tài liệu thiết kế tốt. Rất tiếc, Dự án89 đã thiếu sự hiển thị và quảng bá cho khung công việc này, đó là lý do tôi đã mất bốn ngày để viết bài viết này nhằm nhấn mạnh những điểm mạnh của nó. Tôi tin rằng công nghệ tuyệt vời xứng đáng được công nhận và ngày mai, tôi dự định phát hành một phiên bản tiếng Anh của bài viết này để tăng cường nhận thức trong các đội game và nhà phát triển DeFi (Tài chính phi tập trung). Hy vọng, nhiều đội sẽ khám phá khung công việc này như một lựa chọn kiến trúc tiềm năng cho dự án của họ!

Thông báo:

1. Bài viết này được sao chép từ [0xhhh]. Chuyển tiếp tiêu đề gốc: Tôi thấy khung tác nhân thế hệ tiếp theo trong Project89. Bản quyền thuộc về tác giả gốc [0xhhh]. Nếu bạn có bất kỳ ý kiến ​​nào về việc tái bản, vui lòng liên hệ Gate Họcđội, đội sẽ xử lý nó càng sớm càng tốt theo các thủ tục liên quan.
2. Thông báo miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn. Trừ khi có quy định khác, bài viết dịch có thể không được sao chép, phân phối hoặc đạo văn.