Tôi nhìn thấy khung làm việc Agent thế hệ tiếp theo trong Project89
Tuyển chọn TechFlowTuyển chọn TechFlow
Tôi nhìn thấy khung làm việc Agent thế hệ tiếp theo trong Project89
Project89 áp dụng một cách thức hoàn toàn mới để thiết kế Framework Agent hiệu suất cao dành riêng cho phát triển trò chơi.
Chuyên sâu báo cáo Web3Tác giả: 0xhhh
Trước tiên xin nêu kết luận, @project_89 đã sử dụng một cách thức hoàn toàn mới để thiết kế Agent Framework – đây là một framework agent hiệu năng cao dành riêng cho phát triển game, so với các framework agent hiện tại thì nó có tính mô-đun hóa cao hơn và hiệu suất tốt hơn.
Bài viết này mất rất nhiều thời gian để hoàn thành, cố gắng giúp tất cả mọi người hiểu được những nâng cấp về kiến trúc của framework này so với các framework agent truyền thống. Tôi đã sửa đi sửa lại nhiều lần mới có được phiên bản hiện tại, tuy nhiên trong bài vẫn còn một số phần quá kỹ thuật mà tôi chưa thể diễn giải đơn giản hơn. 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 bình luận.
Giới thiệu nền tảng của nhà phát triển
Đây là một bài blog kỹ thuật, vì vậy trước tiên hãy cùng tìm hiểu năng lực kỹ thuật của người sáng lập:
Trước khi thực hiện project89, founder đã từng tham gia dự án sau: https://github.com/Oneirocom/Magick, cũng là một phần mềm lập trình sử dụng AI, đồng thời shaw cũng là nhà phát triển xếp thứ tư trong dự án này, điều này cũng được ghi rõ trong lý lịch của anh ấy.
Trên trái: founder của project89, dưới phải: lalaune chính là shaw từ ai16z
Hôm nay chúng ta sẽ giới thiệu về framework Agent hiệu năng cao bên trong project89:
https://github.com/project-89/argOS
Một, Vì sao nên dùng ECS để thiết kế Agent Framework
Xét theo ứng dụng trong lĩnh vực game, hiện nay các game sử dụng kiến trúc ECS bao gồm: Game blockchain: Mud, Dojo; Game truyền thống: Overwatch, Star Citizen... Hơn nữa, các công cụ game phổ biến hiện nay cũng đang tiến hóa theo hướng ECS như Unity.
Vậy ECS là gì?
ECS (Entity-Component-System) là một mô hình kiến trúc thường dùng trong phát triển game và hệ thống mô phỏng. Nó tách biệt hoàn toàn dữ liệu và logic, nhằm quản lý hiệu quả các thực thể và hành vi của chúng trong các tình huống quy mô lớn và có khả năng mở rộng:
-
Entity (Thực thể) • Chỉ là một ID (số hoặc chuỗi ký tự), không chứa bất kỳ dữ liệu hay logic nào. • Có thể gắn các component khác nhau để trao cho nó các thuộc tính hoặc khả năng khác nhau tùy theo nhu cầu.
-
Component (Thành phần) • Dùng để lưu trữ dữ liệu hoặc trạng thái cụ thể của thực thể.
-
System (Hệ thống) • Chịu trách nhiệm thực thi logic liên quan đến một số component nhất định.
Lấy ví dụ cụ thể về hành động của một Agent để hiểu rõ hệ thống này: Trong ArgOS, mỗi Agent được coi là một Entity, nó có thể đăng ký các component khác nhau. Ví dụ trong hình dưới đây, Agent này sở hữu bốn component sau: Component Agent: chủ yếu lưu thông tin cơ bản như tên Agent, tên mô hình, v.v. Component Perception: dùng để lưu dữ liệu cảm nhận môi trường bên ngoài Memory Component: dùng để lưu dữ liệu bộ nhớ của Entity Agent, như những việc đã làm, v.v. Action Component: dùng để lưu dữ liệu hành động cần thực hiện.
Quy trình hoạt động của System:
-
Trong trò chơi, nếu cảm nhận được trước mặt mình có một vũ khí, hệ thống sẽ gọi hàm thực thi của Perception System để cập nhật dữ liệu vào component Perception của Entity Agent;
-
Sau đó kích hoạt Memory System, đồng thời gọi cả Perception Component và Memory Component, đưa dữ liệu cảm nhận được ghi vào cơ sở dữ liệu thông qua bộ nhớ;
-
Tiếp theo Action System gọi Memory Component và Action Component, lấy thông tin môi trường xung quanh từ bộ nhớ, rồi cuối cùng thực hiện hành động tương ứng;
-
Kết quả là ta có một Agent Entity đã được cập nhật toàn bộ dữ liệu ở các component. Như vậy có thể thấy rằng System chủ yếu chịu trách nhiệm xác định cần áp dụng logic xử lý nào lên các Component cụ thể.
Rõ ràng trong project89, thế giới đầy rẫy các loại Agent khác nhau. Một số Agent không chỉ có những khả năng cơ bản trên mà còn có thêm khả năng lập kế hoạch. Điều này được minh họa như hình dưới đây:
Quy trình vận hành của System
Nhưng thực tế quy trình thực thi của system không giống như suy nghĩ thông thường là Perception System thực thi xong rồi gọi Memory System — cách làm truyền thống này. Các System khác nhau KHÔNG có mối quan hệ gọi lẫn nhau; mỗi System đều được thực thi một lần trong một chu kỳ nhất định, ví dụ:
-
Perception System có thể chạy mỗi 2 giây để cập nhật dữ liệu cảm nhận từ bên ngoài và ghi vào component Perception;
-
Memory System có thể chạy mỗi 1 giây, trích xuất dữ liệu từ component Perception và tải vào component Memory;
-
Plan System có thể chạy mỗi 1000 giây, căn cứ vào thông tin nhận được để đánh giá xem có cần tối ưu mục tiêu và xây dựng kế hoạch hợp lý hay không, rồi ghi phần cập nhật này vào Plan Component;
-
Action System cũng có thể chạy mỗi 2 giây, để kịp thời phản ứng theo thông tin môi trường, đồng thời nếu Plan Component có cập nhật thì cần cập nhật Action Component dựa trên dữ liệu này, từ đó ảnh hưởng đến hành động ban đầu.
Các nội dung đến đây đều là sự đơn giản hóa lớn về kiến trúc ArgOS do tôi hiểu được nhằm giúp mọi người dễ tiếp cận hơn. Tiếp theo, chúng ta hãy xem xét ArgOS thực tế.
Hai, Kiến trúc System của ArgOS
Để giúp Agent có thể 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ế rất nhiều Component và System.
ArgOS chia System thành "ba cấp độ" (ConsciousnessLevel):
1) Hệ thống Có ý thức (CONSCIOUS)
-
Gồm RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem
-
Tần suất cập nhật thường cao (ví dụ mỗi 10 giây).
-
Gần với xử lý ở mức "thời gian thực" hoặc "ý thức rõ ràng", như cảm nhận môi trường, suy nghĩ tức thì, thực hiện hành động, v.v.
2) Hệ thống Vô thức (SUBCONSCIOUS)
-
GoalPlanningSystem, PlanningSystem
-
Tần suất cập nhật thấp hơn (ví dụ mỗi 25 giây).
-
Xử lý logic "suy nghĩ", như kiểm tra hoặc tạo ra mục tiêu và kế hoạch theo chu kỳ.
3) Hệ thống Vô thức hoàn toàn (UNCONSCIOUS)
-
Hiện tại tạm thời chưa được kích hoạt
-
Tần suất cập nhật chậm hơn nữa (trên 50 giây)
Do đó, trong ArgOS, các System khác nhau được phân loại theo ConsciousnessLevel để xác định tần suất thực thi.
Tại sao lại thiết kế như vậy? Bởi vì mối quan hệ giữa các system trong ArgOS cực kỳ phức tạp, như hình dưới đây:
-
PerceptionSystem chịu trách nhiệm thu thập “kích thích” (stimuli) từ môi trường bên ngoài hoặc các thực thể khác, và cập nhật vào component Perception của Agent. Đánh giá xem kích thích có thay đổi đáng kể hay không, dựa trên độ ổn định, chế độ xử lý (ACTIVE/REFLECTIVE/WAITING) để cập nhật phù hợp. Cuối cùng cung cấp thông tin “cảm nhận hiện tại” cho các hệ thống phía sau như ExperienceSystem, ThinkingSystem, v.v.
-
ExperienceSystem chuyển đổi các Stimuli mà PerceptionSystem thu thập được thành những “trải nghiệm” (Experience) trừu tượng hơn. Gọi LLM hoặc logic quy tắc (extractExperiences) để nhận diện trải nghiệm mới, và lưu trữ vào component Memory. Loại bỏ trùng lặp, lọc, xác minh trải nghiệm, đồng thời thông qua eventBus phát sự kiện “experience” cho các hệ thống khác hoặc người nghe bên ngoài.
-
ThinkingSystem là hệ thống “suy nghĩ” của chính Agent. Trích xuất trạng thái hiện tại từ các component như Memory, Perception, v.v., thông qua generateThought(...) cùng với LLM / logic quy tắc để tạo ra “kết quả suy nghĩ” (ThoughtResult). Dựa trên kết quả suy nghĩ, có thể: • Cập nhật thoughts (lịch sử suy nghĩ) trong Memory. • Kích hoạt một hành động mới (đưa vào Action.pendingAction[eid]). • Thay đổi diện mạo bên ngoài Appearance của agent (biểu cảm, tư thế, v.v.), đồng thời tạo ra Stimulus liên quan để các thực thể khác “nhìn thấy” sự thay đổi.
-
ActionSystem nếu pendingAction của một Agent không rỗng, sẽ thực sự thực hiện hành động thông qua runtime.getActionManager().executeAction(...). Sau khi thực hiện xong, ghi kết quả trở lại Action.lastActionResult, và thông báo cho phòng hoặc các thực thể khác. Cũng sẽ tạo ra CognitiveStimulus (kích thích nhận thức), để các hệ thống phía sau “biết” hành động đã hoàn tất, hoặc có thể đưa vào bộ nhớ.
-
GoalPlanningSystem định kỳ đánh giá tiến độ danh sách mục tiêu Goal.current[eid], hoặc kiểm tra xem bộ nhớ bên trong hay bên ngoài có thay đổi lớn nào không (detectSignificantChanges). Khi cần mục tiêu mới hoặc điều chỉnh mục tiêu, thông qua generateGoals(...) để tạo và ghi vào Goal.current[eid]. Đồng thời cập nhật trạng thái của các mục tiêu đang tiến hành (in_progress); nếu đáp ứng điều kiện hoàn thành hoặc thất bại thì thay đổi trạng thái, và gửi tín hiệu hoàn thành/thất bại đến Plan tương ứng.
-
PlanningSystem tạo hoặc cập nhật Plan (kế hoạch thực hiện) cho các “mục tiêu đã có” (Goal.current[eid]). Nếu phát hiện một số mục tiêu không có kế hoạch đang hoạt động (active), sẽ thông qua generatePlan(...) tạo ra lộ trình thực hiện chứa một vài bước, và ghi vào Plan.plans[eid]. Cũng sẽ cập nhật trạng thái Plan liên quan khi mục tiêu hoàn thành hoặc thất bại, đồng thời tạo kích thích nhận thức tương ứng.
-
RoomSystem xử lý các cập nhật liên quan đến phòng (Room): • Lấy danh sách cư dân (occupants) trong phòng, tạo “kích thích ngoại hình (appearance)” cho mỗi agent, để các thực thể khác “nhìn thấy” vẻ ngoài hoặc hành động của anh ta. • Tạo Stimulus môi trường phòng (ví dụ thông tin “khí氛 phòng” phù hợp) và liên kết. Đảm bảo rằng khi Agent ở 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ể cảm nhận được sự thay đổi ngoại hình của anh ta.
-
CleanupSystem định kỳ tìm và loại bỏ các thực thể được đánh dấu bằng component Cleanup. Dùng để thu hồi các Stimulus hoặc đối tượng không cần thiết nữa, tránh để lại lượng lớn thực thể vô hiệu trong ECS.
-
Ví dụ: Một vòng lặp từ “nhìn thấy vật thể” đến “thực hiện hành động”
Tình huống dưới đây minh họa cách các System phối hợp tuần tự trong một lượt (hoặc vài khung hình) để hoàn thành một quy trình đầy đủ.
-
Chuẩn bị tình huống: Trong thế giới (World) tồn tại một Agent (EID=1), đang ở trạng thái “Active”, và đang ở trong một phòng (EID=100). Trong phòng này vừa xuất hiện một đạo cụ “MagicSword”, tạo ra Stimulus tương ứng.
-
PerceptionSystem phát hiện sự xuất hiện của “MagicSword”, tạo Stimulus (type=“item_appearance”) cho Agent(1) và thêm vào Perception.currentStimuli[1]. So sánh hash Stimuli lần trước, xác định “có thay đổi đáng kể”, “kích hoạt lại” ProcessingState của agent (chế độ ACTIVE).
-
ExperienceSystem thấy Perception.currentStimuli của Agent(1) không rỗng, liền trích xuất thông tin kiểu “Sword appears” thành một hoặc nhiều Experience mới (type: “observation”). Lưu vào Memory.experiences[1], và phát sự kiện 「experience」.
-
ThinkingSystem đọc thông tin trạng thái từ Memory, Perception, v.v., gọi generateThought: “Tôi nhìn thấy MagicSword, có lẽ có thể nhặt lên xem nó dùng để làm gì...”. Kết quả suy nghĩ này bao gồm một hành động chờ thực hiện: { tool: "pickUpItem", parameters: { itemName: "MagicSword" } }. ThinkingSystem ghi Action này vào Action.pendingAction[1]. Nếu có thay đổi appearance (ví dụ “biểu cảm tò mò”), thì cập nhật Appearance và tạo kích thích thị giác.
-
ActionSystem thấy Action.pendingAction[1] = { tool: "pickUpItem", parameters: ... }. Thực hiện logic hành động “nhặt đồ” thông qua runtime.getActionManager().executeAction("pickUpItem", 1, { itemName: "MagicSword" }, runtime). Nhận được 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à phát sự kiện 「action」 phát sóng đến phòng (100). Đồng thời tạo kích thích nhận thức (type=“action_result”), ghi vào Memory hoặc để ThinkingSystem bắt được ở lượt tiếp theo.
-
GoalPlanningSystem (nếu agent này có mục tiêu) định kỳ đánh giá mục tiêu của agent. Nếu lúc này một mục tiêu của agent là “có được vũ khí mạnh”, và phát hiện MagicSword đã vào tay, có thể đánh dấu mục tiêu này là hoàn thành. Nếu phát hiện thay đổi lớn (ví dụ “vật thể mới xuất hiện trong phòng” ảnh hưởng đến mục tiêu đang theo đuổi?), thì dựa trên detectSignificantChanges để tạo mục tiêu mới hoặc từ bỏ mục tiêu cũ.
-
PlanningSystem (nếu có mục tiêu liên quan) kiểm tra xem có cần kế hoạch mới hoặc cập nhật kế hoạch hiện có cho mục tiêu kiểu “có được vũ khí mạnh” đã hoàn thành hoặc vừa tạo hay không. Nếu đã hoàn thành, đặt [status] của Plan liên quan thành “completed”; hoặc nếu mục tiêu cần mở rộng quy trình tiếp theo (“nghiên cứu kiếm ma thuật”), thì tạo thêm các bước.
-
RoomSystem (mỗi khung hình hoặc mỗi lượt) cập nhật danh sách Occupants và các thực thể có thể nhìn thấy trong phòng (100). Nếu ngoại hình của agent(1) thay đổi (ví dụ Appearance.currentAction = “holding sword”), sẽ tạo kích thích thị giác 「appearance」 mới, để các agent khác trong cùng phòng như Agent2, Agent3 biết “agent1 đã cầm kiếm”.
-
CleanupSystem loại bỏ các thực thể hoặc kích thích đã được đánh dấu (Cleanup). Nếu sau khi nhặt đồ, Stimulus “MagicSword” không cần giữ lại nữa, có thể xóa entity Stimulus tương ứng trong CleanupSystem.
Thông qua sự kết nối giữa các hệ thống này, AI Agent đạt được: • Cảm nhận thay đổi môi trường (Perception) → Ghi lại hoặc chuyển đổi thành kinh nghiệm nội tại (Experience) → Tự suy nghĩ và ra quyết định (Thinking) → Hành động (Action) → Điều chỉnh động mục tiêu và kế hoạch (GoalPlanning + Planning) → Đồng bộ môi trường (Room) → Thu hồi kịp thời các thực thể vô dụng (Cleanup).
Ba, Phân tích kiến trúc tổng thể ArgOS
1. Phân tầng kiến trúc cốt lõi
2. Phân loại Component
Trong ECS, mỗi thực thể (Entity) có thể sở hữu nhiều component (Component). Dựa trên đặc tính và vòng đời trong hệ thống, component có thể được chia thành các nhóm chính sau:
-
Loại định danh cốt lõi (Identity-Level Components) • Agent / PlayerProfile / NPCProfile, v.v. • Dùng để định danh duy nhất thực thể, lưu trữ thông tin nhân vật hoặc đơn vị cốt lõi, thường cần ghi vào cơ sở dữ liệu.
-
Loại hành vi và trạng thái (Behavior & State Components) • Action, Goal, Plan, ProcessingState, v.v. • Đại diện cho những việc thực thể đang làm hoặc mục tiêu, cũng như trạng thái phản hồi với lệnh bên ngoài hoặc tư duy nội bộ. • Bao gồm pendingAction, goalsInProgress, plans, cũng như các suy nghĩ hoặc nhiệm vụ đang xếp hàng. • Thường là trạng thái ngắn/trung hạn, nhiều cái thay đổi động theo lượt chơi hoặc chu kỳ nghiệp vụ. • Việc có cần ghi cơ sở dữ liệu hay không tùy theo trường hợp. Nếu muốn tiếp tục từ điểm dừng, có thể định kỳ ghi vào cơ sở dữ liệu.
-
Loại cảm nhận và bộ nhớ (Perception & Memory Components) • Perception, Memory, Stimulus, Experience, v.v. • Ghi lại thông tin bên ngoài mà thực thể cảm nhận được (Stimuli), và trải nghiệm (Experiences) được rút ra sau khi cảm nhận. • Memory thường tích lũy được lượng lớn dữ liệu, ví dụ như ghi chép hội thoại, lịch sử sự kiện, v.v.; thường cần ghi dữ liệu. • Perception có thể là thông tin thời gian thực hoặc tạm thời, hiệu lực ngắn hạn, có thể quyết định có ghi vào cơ sở dữ liệu hay không tùy theo nhu cầu (ví dụ chỉ lưu các sự kiện cảm nhận quan trọng).
- Môi trường và không gian (Room, OccupiesRoom, Spatial, Environment, Inventory, v.v.) • Đại diện cho thông tin phòng, môi trường, vị trí, thùng đồ, v.v. •Room.id, OccupiesRoom, Environment, v.v. thường cần ghi dữ liệu, như mô tả trang chủ phòng, cấu trúc bản đồ, v.v. • Các component thay đổi liên tục (ví dụ Entity di chuyển giữa các phòng khác nhau) có thể ghi theo dạng sự kiện hoặc định kỳ.
-
Loại ngoại hình và tương tác (Appearance, UIState, Relationship, v.v.) • Ghi lại phần “có thể nhìn thấy” hoặc “tương tác” bên ngoài của thực thể, như Avatar, pose, facialExpression, mạng lưới quan hệ xã hội với các thực thể khác, v.v. • Một phần có thể xử lý chỉ trong bộ nhớ (biểu hiện thời gian thực), một phần khác (ví dụ quan hệ xã hội then chốt) có thể cần ghi dữ liệu.
-
Loại hỗ trợ hoặc vận hành (Cleanup, DebugInfo, ProfilingData, v.v.) • Dùng để đánh dấu thực thể nào cần thu hồi (Cleanup), hoặc ghi thông tin gỡ lỗi (DebugInfo) phục vụ giám sát và phân tích. • Thường chỉ tồn tại trong bộ nhớ, hiếm khi đồng bộ vào cơ sở dữ liệu trừ khi cần log hoặc kiểm toán.
3. Kiến trúc System
Phần trên đã giới thiệu
4. Kiến trúc Manager
Ngoài Component và System, chúng ta còn thiếu một người quản lý tài nguyên, ví dụ như cách truy cập cơ sở dữ liệu, xử lý xung đột trạng thái khi cập nhật, v.v.
Bên trái Systems (PerceptionSystem, ExperienceSystem, ThinkingSystem, v.v.):
• Mỗi hệ thống được SimulationRuntime lên lịch thực thi trong vòng lặp ECS, truy vấn và xử lý các thực thể mà nó quan tâm (qua điều kiện component).
• Khi thực thi logic, cần tương tác với các 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/agent, như Memory, Goal, Plan, v.v.
-
Tận dụng EventBus (EB) để phát hoặc lắng nghe sự kiện.
-
Khi cần xử lý ngôn ngữ tự nhiên hoặc prompt, gọi PromptManager (PM).
----------------
Bên phải Managers (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, v.v.):
• Cung cấp chức năng cấp hệ thống, cơ bản không “thúc đẩy” logic một cách chủ động, mà bị các Systems hoặc Runtime gọi đến.
• Ví dụ điển hình:
-
ActionManager chuyên quản lý đăng ký và thực thi hành động (Action).
-
EventManager / EventBus dùng cho cơ chế phát hành và đăng ký sự kiện.
-
RoomManager quản lý rooms, bố cục và occupant.
-
StateManager chịu trách nhiệm đồng bộ giữa ECS và cơ sở dữ liệu hoặc bộ nhớ.
-
PromptManager cung cấp mẫu prompt LLM, quản lý ngữ cảnh, v.v.
-
Ở giữa là SimulationRuntime (R):
• Là “người điều phối” cho tất cả các Systems, khởi động hoặc dừng vòng lặp hệ thống ở các cấp độ khác nhau (Có ý thức/Vô thức, v.v.);
• Cũng tạo các Managers trong giai đoạn khởi tạo và truyền cho từng System sử dụng.
-
CleanupSystem:
• Đặc biệt chú ý rằng nó còn tương tác với ComponentSync (CS), dùng để đồng bộ loại bỏ component hoặc đăng ký sự kiện khi thu hồi thực thể.
Kết luận: Mỗi System sẽ đọc/ghi dữ liệu hoặc gọi dịch vụ thông qua Manager tương ứng khi cần, trong khi Runtime thống nhất điều phối vòng đời và hành vi của tất cả System và Manager ở cấp độ cao hơn.
5. Cách tương tác với vector và cơ sở dữ liệu
Trong ECS, Systems là nơi thực sự thực thi logic, còn việc đọc/ghi cơ sở dữ liệu có thể được thực hiện thông qua “bộ quản lý bền vững (PersistenceManager / DatabaseManager)” hoặc “bộ quản lý trạng thái (StateManager)”. Quy trình đại khái như sau:
-
Khởi động hoặc tải (Initial Load) • StateManager / PersistenceManager tải dữ liệu các component cốt lõi như Agents, Rooms, Goals từ cơ sở dữ liệu, tạo các thực thể (Entities) tương ứng và khởi tạo các trường component liên quan. • Ví dụ, đọc một loạt bản ghi agent chèn vào thế giới ECS, khởi tạo các component như Agent, Memory, Goal cho chúng.
-
Chạy ECS (Vòng lặp cập nhật Systems) • Hệ thống làm việc trong mỗi khung hình (hoặc lượt): PerceptionSystem thu thập “cảm nhận” và ghi vào component Perception (phần lớn là tạm thời, không ghi cơ sở dữ liệu). ExperienceSystem chuyển “trải nghiệm nhận thức” mới thành Memory.experiences, nếu là trải nghiệm quan trọng có thể đồng thời gọi StateManager để lưu ngay lập tức, hoặc đánh dấu “needsPersistence” để sau này ghi hàng loạt. Các hệ thống như ThinkingSystem / ActionSystem / GoalPlanningSystem ra quyết định và cập nhật các trường trong ECS dựa trên nội dung component. Nếu một số component (ví dụ Goal.current) thay đổi lớn và cần ghi dữ liệu (ví dụ mục tiêu dài hạn mới), thông qua lắng nghe component hoặc sự kiện hệ thống, thông báo cho StateManager ghi trường đó vào cơ sở dữ liệu.
-
Ghi dữ liệu định kỳ hoặc theo sự kiện (Periodic or Event-Driven) • Có thể gọi các interface như PersistenceManager.storeComponentData(eid, "Goal") tại các điểm then chốt trong hệ thống (ví dụ khi kế hoạch mục tiêu cập nhật hoặc xảy ra sự kiện quan trọng của Agent) để ghi vào cơ sở dữ liệu. • Cũng có thể trong CleanupSystem hoặc bộ hẹn giờ, để StateManager quét các component hoặc thực thể có đánh dấu “needsPersistence”, ghi hàng loạt vào cơ sở dữ liệu. • Ngoài ra, dữ liệu log hoặc kiểm toán (ví dụ lịch sử hành động, nhật ký suy nghĩ) cũng có thể lưu trữ tại đây.
-
Lưu thủ công hoặc khi tắt (Manual or Shutdown Save) • Khi máy chủ hoặc tiến trình chuẩn bị đóng, gọi StateManager.saveAll() để ghi统 nhất tất cả dữ liệu chưa ghi vào cơ sở dữ liệu, đảm bảo lần sau tải có thể khôi phục trạng thái ECS. • Đối với một số tình huống offline/máy đơn, cũng có thể kích hoạt lưu trữ thủ công.
-
Quy trình ví dụ đầy đủ
Dưới đây là một tình huống đơn giản minh họa cách tương tác giữa component và cơ sở dữ liệu:
-
Khởi động: StateManager.queryDB("SELECT * FROM agents") → nhận được một loạt bản ghi agent, lần lượt tạo Entity (EID=x) cho mỗi bản ghi, khởi tạo các trường component như Agent, Memory, Goal. Đồng thời tải thông tin phòng từ bảng “rooms”, tạo thực thể Room.
-
Giai đoạn chạy: PerceptionSystem trong một phòng phát hiện sự kiện “MagicSword xuất hiện”, ghi vào Perception.currentStimuli[eid]. ExperienceSystem chuyển Stimuli thành Experience, gán vào Memory.experiences[eid]. ThinkingSystem dựa trên thông tin Memory, Goal, v.v. quyết định thực hiện hành động tiếp theo, tạo Action.pendingAction[eid]. Sau khi ActionSystem thực hiện hành động, ghi kết quả vào Memory hoặc Action.lastActionResult. Nếu đây là một sự kiện cốt truyện quan trọng, sẽ đánh dấu phần mới nhất của Memory.experiences[eid] là needsPersistence. StateManager sau một thời gian phát hiện Memory.experiences[eid] mang “needsPersistence”, sẽ ghi vào cơ sở dữ liệu (INSERT INTO memory_experiences ...).
-
Dừng hoặc điểm dừng: Dựa trên ECS hoặc lịch trình hệ thống, khi “tắt máy chủ” gọi StateManager.saveAll(), ghi trạng thái mới nhất của các trường component cốt lõi trong bộ nhớ (Agent, Memory, Goal, v.v.) vào cơ sở dữ liệu. Lần khởi động sau, có thể tải từ cơ sở dữ liệu và khôi phục trạng thái thế giới ECS.
• Phân loại component giúp quản lý rõ ràng dữ liệu thực thể trong dự án, đồng thời hỗ trợ kiểm soát ranh giới giữa dữ liệu “cần ghi” và “chỉ tồn tại trong bộ nhớ”. • Việc tương tác với cơ sở dữ liệu thường do một Manager chuyên biệt (ví dụ StateManager) xử lý; Systems khi cần đọc/ghi cơ sở dữ liệu sẽ thao tác thông qua nó, tránh viết trực tiếp SQL hoặc các câu lệnh底层 trong System. • Như vậy có thể tận hưởng đồng thời hiệu quả và linh hoạt về logic từ ECS, cũng như lợi thế từ cơ sở dữ liệu về tính bền vững, tiếp tục từ điểm dừng, và phân tích thống kê dữ liệu.
Năm, Điểm sáng kiến trúc
-
Điểm nổi bật của toàn bộ kiến trúc nằm ở:
-
Mỗi System đều chạy độc lập, không có mối quan hệ gọi lẫn nhau với các System khác. Do đó, dù chúng ta mong muốn thực hiện khả năng “cảm nhận thay đổi môi trường (Perception) → ghi lại hoặc chuyển đổi thành kinh nghiệm nội tại (Experience) → tự suy nghĩ và ra quyết định (Thinking) → hành động (Action) → điều chỉnh động mục tiêu và kế hoạch (GoalPlanning + Planning) → đồng bộ môi trường (Room) → thu hồi kịp thời thực thể vô dụng (Cleanup)” cho Agent, các System về chức năng có nhiều điểm phụ thuộc lẫn nhau, nhưng vẫn có thể nhờ kiến trúc ECS tổ chức thành các System không liên quan, mỗi System vẫn chạy độc lập, không có bất kỳ mối liên hệ ràng buộc nào với System khác. Tôi nghĩ đây cũng là lý do chính khiến Unity những năm gần đây ngày càng chuyển mạnh sang kiến trúc ECS.
-
Thêm nữa, nếu bây giờ tôi chỉ muốn một Agent có một số khả năng cơ bản, tôi chỉ cần giảm bớt việc đăng ký một số Component và System khi định nghĩa Entity, có thể dễ dàng thực hiện mà không cần sửa mấy dòng code.
Như hình dưới đây:
-
Đồng thời, nếu trong quá trình phát triển bạn muốn thêm chức năng mới, cũng sẽ không ảnh hưởng gì đến các System khác, có thể dễ dàng tích hợp chức năng mong muốn vào. Ngoài ra, hiệu suất của kiến trúc hiện tại thực tế cao hơn nhiều so với kiến trúc hướng đối tượng truyền thống, đây là sự thật được công nhận trong ngành game, vì thiết kế ECS phù hợp hơn với xử lý song song. Khi ở các tình huống DeFi phức tạp, việc áp dụng kiến trúc ECS cũng có thể mang lại lợi thế, đặc biệt trong các tình huống hy vọng dùng Agent làm giao dịch định lượng, ECS cũng sẽ phát huy tác dụng (không chỉ giới hạn trong tình huống game Agent).
-
Việc chia System thành có ý thức, vô thức và vô thức hoàn toàn để phân biệt tần suất thực thi của các loại System khác nhau là một thiết kế cực kỳ tinh tế, đã mô phỏng rất sinh động khả năng con người.
Theo quan điểm cá nhân tôi, đây là một framework cực kỳ mô-đun hóa, hiệu suất cực kỳ xuất sắc, đồng thời chất lượng mã nguồn cũng rất cao và đi kèm tài liệu thiết kế tốt. Tuy nhiên đáng tiếc là dự án $project89 luôn thiếu tuyên truyền về framework này, vì vậy tôi đã dành rất nhiều thời gian (4 ngày) viết bài này. Tôi nghĩ những sản phẩm tốt xứng đáng được biết đến. Ngày mai tôi sẽ đăng thêm phiên bản tiếng Anh, hy vọng có thêm nhiều đội ngũ game hoặc DeFi biết đến framework này, cung cấp cho mọi người một lựa chọn kiến trúc tiềm năng mới!
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@hhh69251498
