転送元のオリジナルタイトル：プロジェクト89で次世代エージェントフレームワークを見る

要点をお伝えすると、@project_89エージェントフレームワークを設計するためのまったく新しいアプローチを採用しています。これは、ゲーム開発専用の高性能エージェントフレームワークです。現在使用されているエージェントフレームワークと比較して、よりモジュール化され、より優れたパフォーマンスを提供します。

この記事は書くのに長い時間がかかり、従来のエージェントフレームワークと比較してこのフレームワークがどのようなアーキテクチャのアップグレードを行ったかを皆に理解してもらおうとしています。このバージョン以前に何度も改訂されてきましたが、記事の中にはまだわかりにくい部分があります。技術的な問題により、さらに普及させることができませんでした。記事の改善についてご意見がありましたら、コメントを残してください。

Developer Background

この技術ブログであるため、まず創設者の技術的な専門知識を見てみましょう。

Project89に取り組む前に、創設者はこのプロジェクトを開発しました:https://github.com/Oneirocom/Magick, これはまた、AIパワードのプログラミングソフトウェアでもあります。さらに、ショーはこのプロジェクトの第4位のトップ開発者としてランク付けされています。また、ショーのポートフォリオでもこのプロジェクトを見ることができます。

左上: project89の創設者；右下: 'lalaune'はai16zのショーです

本日は、プロジェクト89の高パフォーマンスエージェントフレームワークについて主に紹介します:

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

1. エージェントフレームワークを設計するためにECSを使用する理由は何ですか？

ゲーム分野での応用の観点から

ECSアーキテクチャを現在使用しているゲームには、次のものが含まれています:

ブロックチェーンゲーム：Mud、Dojo

伝統的なゲーム：Overwatch、Star Citizenなど

さらに、主流のゲームエンジンはUnityなどのECSアーキテクチャに向かって進化しています。

ECSとは何ですか？

ECS（Entity-Component-System）は、ゲーム開発やシミュレーションシステムで一般的に使用されるアーキテクチャパターンです。大規模なスケーラブルなシナリオで、データとロジックを効率的に分離して、さまざまなエンティティとその振る舞いを管理します。

エンティティ

• 単なるID（数値または文字列）で、データまたはロジックを含んでいません。

• 必要に応じて、さまざまなプロパティや機能を持つように、異なるコンポーネントをマウントすることができます。

コンポーネント

・特定のデータまたはエンティティの状態を保存するために使用されます。

システム

• あるコンポーネントに関連するロジックの実行を担当します。

このシステムを理解するために、エージェントアクションの具体的な例を使いましょう。

ArgOSでは、各エージェントはエンティティと見なされ、異なるコンポーネントを登録できます。例えば、下の画像では、当社のエージェントには次の4つのコンポーネントがあります:

エージェントコンポーネント：エージェントの名前、モデル名などの基本情報を主に保存します。

知覚コンポーネント：主に外部の知覚データを保存するために使用されます

メモリコンポーネント：エージェントエンティティのメモリデータ、同様のことが行われたものなどを主に保存するために使用されます。

アクションコンポーネント：主に実行されるアクションデータを保存します

システムのワークフロー：

1. このゲームでは、たとえば、前方に武器を感知した場合、知覚システムの実行機能が呼び出され、エージェントエンティティの知覚コンポーネントのデータが更新されます。
2. その後、メモリシステムをトリガーし、同時に知覚コンポーネントと記憶コンポーネントを呼び出し、認識されたデータをメモリを介してデータベースに永続化します。
3. その後、アクションシステムはメモリコンポーネントとアクションコンポーネントを呼び出して、メモリから周囲の環境情報を取得し、最終的に対応するアクションを実行します。

次に、各コンポーネントのデータが更新されたUpdate Agent Entityを取得します。

4. そのため、ここではシステムが主に、どのコンポーネントに対して対応する処理ロジックを実行するかを定義する責任があります。

そして、project89ではさまざまな種類のエージェントで満ちた世界であることは明らかです。例えば、一部のエージェントは上記の基本的な能力だけでなく、計画を立てる能力も持っています。

その後、下の画像のようになります:

システムの実行フロー

しかし、あるシステムが別のシステムを直接トリガーする従来のフレームワーク(例えば、記憶システムを呼び出す知覚システム)とは異なり、Project89では、システムは互いに直接呼び出さない。代わりに、各システムは一定の時間間隔で独立して実行されます。例えば：

• Perception Systemは、新たに受信した環境データでPerceptionコンポーネントを2秒ごとに更新します。
• Memory Systemは1秒ごとに実行され、知覚コンポーネントからデータを抽出し、メモリコンポーネントに保存します。
• Plan Systemは、収集されたデータを分析し、最適化が必要かどうかを判断し、新しい計画を作成するために、1000秒ごとに実行され、その後、計画コンポーネントに記録されます。
• アクションシステムは、環境の変化に応じて2秒ごとに実行され、プランコンポーネントからの更新に基づいてアクションを修正します。

これまで、この記事ではArgOSのアーキテクチャを大幅に簡略化して理解しやすくしてきました。さて、実際のArgOSシステムをもう少し詳しく見てみましょう。

2. ArgOS システムアーキテクチャ

Agentがより深く考えることや、より複雑なタスクを実行するために、ArgOSは多くのコンポーネントと多くのシステムを設計しています。

そして、ArgOSはシステムを「三つのレベル」(ConsciousnessLevel)に分割します:

1) CONSCIOUS system

• RoomSystem、PerceptionSystem、ExperienceSystem、ThinkingSystem、ActionSystem、CleanupSystemを含む
• 更新頻度は通常より高く（例えば10秒ごとなど）です。
• 「リアルタイム」や「意識的」なレベルに近づく処理、環境認識、リアルタイム思考、アクションの実行など。

2) 潜在意識（SUBCONSCIOUS）システム

• GoalPlanningSystem、PlanningSystem
• 更新頻度は比較的低いです（例：25秒ごと）。
• “思考”ロジックを処理し、定期的に目標や計画をチェック/生成するなどの処理を行います。

3) 無意識（UNCONSCIOUS）システム

• まだ有効になっていません
• 更新頻度が遅い（50秒以上など）ですが、

そのため、ArgOSでは、意識レベルに応じて異なるシステムが分割され、そのシステムが実行される頻度が定められます。

なぜこのように設計されているのですか？

様々なシステム間の関係はArgOS内で非常に複雑であり、以下のように示されています:

1. PerceptionSystemは、外部の世界や他のエンティティから「刺激」を収集し、それらをエージェントの知覚コンポーネントに更新する責任を持っています。

刺激が大幅に変化するかどうかを判断し、安定性、処理モード（アクティブ/リフレクティブ/ウェイティング）に基づいて更新してください。

最終的に、「現在の知覚」データは、後続のExperienceSystem、ThinkingSystemなどに提供されます。

2.経験システムは、知覚システムによって収集された刺激をより抽象的な「経験」に変換します。

LLMまたはルールロジック（extractExperiences）は、新しい経験を特定してMemoryコンポーネントに保存するために呼び出されます。

重複排除、フィルタリング、および経験の検証を行いながら、eventBusを介して他のシステムや外部リスナーに「経験」イベントをトリガーします。

3. ThinkingSystemはエージェントの内部思考プロセスを表しています。

コンポーネント（MemoryおよびPerceptionなど）から現在の状態を抽出し、「generateThought(…)」およびLLM/ruleロジックを使用して「ThoughtResult」を生成します。

思考結果に基づいて、それは次のようになる可能性があります:

• メモリー（思考履歴）の中の思考を更新します。

• 新しいアクションをトリガーします（Action.pendingAction[eid]に入れます）。

・エージェントの外部の見た目（表情、姿勢など）を変更し、関連する刺激を生成して、他のエンティティに変更を「見せる」。

4.アクションシステムは、もし...なら、アクションを実行しますAction.pendingAction空ではありません、使用中ですruntime.getActionManager().executeAction(…).

実行後、結果を Action.lastActionResult に書き戻し、部屋や他のエンティティに通知します。

これにより、CognitiveStimulus（認知刺激）が生成され、その後のシステムが行動が完了したことを「知る」か、記憶に組み込むことができます。

5. GoalPlanningSystemは、Goal.current[eid]リストの目標の進捗を定期的に評価するか、外部/自己のメモリで重要な変更をチェックします（detectSignificantChanges）。

新しい目標または目標の調整が必要な場合は、generateGoals（...）を介してGoal.current [eid]を生成して書き込みます。

同時に、進行中の目標（in_progress）が更新されます。完了または失敗条件が満たされると、状態が変更され、対応するプランに完了/失敗の信号が送信されます。

6. PlanningSystemは、「既存の目標」（Goal.current[eid]）のために計画（実行計画）を生成または更新します。

一部の目標に対応するアクティブな計画がないことが検出された場合は、generatePlan(...)を通じていくつかのステップを含む実行ロードマップを生成し、Plan.plans[eid]に書き込んでください。

目標が達成または失敗した場合、それに関連する計画のステータスも更新され、対応する認知刺激が生成されます。

7.RoomSystemは部屋に関連する更新を処理します:

• 部屋の居住者のリスト（居住者）を取得し、各エージェントのために「外見」の刺激を生成して他のエンティティに彼の外見や行動を「見せる」。

• ルーム環境の刺激（例：適切な「部屋の雰囲気」情報）を作成して相関させます。

エージェントが特定の空間環境にいるとき、その空間を感知している他のエンティティは、彼の外見の変化に気付くことができるようにしてください。

8.CleanupSystemは定期的にCleanupコンポーネントでマークされたエンティティを検出し、削除します。これは、不要になった刺激やその他のオブジェクトをリサイクルするために使用され、大量の無効なエンティティがECSに残されるのを防ぐためです。

• 例:「対象を見る」から「行動を実行する」までのループの例

以下のシーンの例では、各システムが1ラウンド（またはいくつかのフレーム）で完全なプロセスを完了するためにどのように協力するかを示しています。

シーンの準備：世界にはエージェント（EID=1）があり、それは「アクティブ」な状態で、部屋（EID=100）にいます。

この部屋には新しいプロップ「MagicSword」が現れ、それに対応する刺激が生成されました。

1. PerceptionSystemは、「MagicSword」の出現を検出し、「item_appearance」というタイプの刺激をAgent(1)に生成し、Perception.currentStimuli[1]に追加します。前回の刺激ハッシュと比較して、「重大な変化」があることが判明し、エージェントの処理状態が「再活性化」（アクティブモード）になります。
2. ExperienceSystemは、Agent(1)のPerception.currentStimuliが空でないことを認識し、したがって「剣が現れる」といった情報を1つまたは複数の新しいエクスペリエンス（タイプ：「観察」）に抽出します。これをMemory.experiences[1]に保存し、「エクスペリエンス」イベントを発行します。
3. ThinkingSystemはMemory、Perceptionおよびその他の状態情報を読み取り、generateThoughtを呼び出します:

「マジックソードを見つけたので、拾って何ができるか見てみるかもしれません...」思考結果には、実行するアクションが含まれています: {tool: 'pickUpItem'、parameters: {itemName: 'MagicSword'}}

ThinkingSystemは、このActionをAction.pendingAction[1]に書き込みます。

外見に変化がある場合（例：“好奇心をそそる表情”など）、外見が更新され、視覚刺激が生成されます。

4.ActionSystemはAction.pendingAction[1] = { tool: "pickUpItem", parameters: ... }と認識します。

runtime.getActionManager().executeAction("pickUpItem", 1, { itemName: "MagicSword" }, runtime).Get the result: { 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) を実行して、「pickup」アクションロジックを実行します。

同時に、認知刺激（type =”action_result”）が生成され、Memoryに書き込まれるか、次のターンでThinkingSystemによってキャプチャされます。

5. ゴール計画システム（エージェントに目標がある場合）は定期的にエージェントの目標を評価します。この時点でエージェントの目標の1つが「強力な武器を入手する」であり、マジックソードが入手されたことが検出された場合、目標は完了とマークされるかもしれません。もし新しい変更（例えば「部屋に新しいオブジェクトが現れる」がエージェントが追求している目標に影響を与える）が発生した場合、新しい目標を生成したり、古い目標を放棄することもあります。
6.計画システム（関連する目標がある場合）は、「強力な武器の入手」といった完了したまたは新たに生成された目標に対して、新しい計画が必要か、既存の計画を更新するかをチェックします。

完了した場合、関連するプランの[status]を「completed」に設定するか、目標が後続のプロセス（「魔剣の研究」）を拡大する場合は、さらなるステップを生成します。

7.RoomSystemは、部屋（100）の占有者および可視エンティティのリストを更新します（すべてのフレームまたはラウンドごとに）。

エージェント(1)の外観が変化した場合(例: Appearance.currentAction = “holding sword”)、同じ部屋にいる他のAgent2とAgent3に「エージェント1が剣を拾った」と知らせるために新しい「外観」視覚刺激を作成します。

8. CleanupSystemは、マークされたエンティティや刺激を削除します（クリーンアップ）。 “MagicSword”刺激を拾った後、もう必要ない場合は、CleanupSystemで対応する刺激エンティティを削除できます。

1. これらのシステムの接続により、AIエージェントは次のことを実現します:

• 環境の変化を認識する（認知）→ 記録または内的な経験に変換する（経験）→ 自己の思考と意思決定（思考）→ 行動に移す（行動）→ 目標と計画を動的に調整する（ゴールプランニング+計画）→ 環境を同期させる（ルーム）→ 不要なエンティティを適時にリサイクルする（クリーンアップ）

3. ArgOSの全体的なアーキテクチャの分析

1. コアアーキテクチャレイヤー

2. コンポーネント分類

ECSでは、各エンティティに複数のコンポーネントを持たせることができます。システム内での性質やライフサイクルに応じて、コンポーネントは大まかに以下のカテゴリに分けることができます:

1.コアアイデンティティクラス（アイデンティティレベルのコンポーネント）

• エージェント / プレイヤープロフィール / NPCプロフィールなど。

• エンティティを一意に識別し、コアロールまたはユニット情報を格納し、一般的にデータベースに永続化する必要があります。

2.動作と状態のコンポーネント

• アクション、ゴール、プラン、プロセス状態など。

• 現在のエンティティが試行していること、目標、および外部コマンドや内部思考への応答状態を表します。

• 保留中のアクション、進行中の目標、計画、キュー内の思考やタスクなどが含まれています。

• 典型的には中長期の状態であり、多くはゲームのラウンドやビジネスサイクルの間に動的に変化します。

• ストッキングが必要かどうかは状況によります。ブレークポイント後に実行を続けたい場合は、定期的にデータベースに書き込むことができます。

3. 感覚＆記憶コンポーネント

• 感知、記憶、刺激、経験など。

• エンティティによって知覚された外部情報（刺激）と、知覚後にそれに洗練された体験（経験）を記録します。

• メモリはしばしば会話の記録、イベント履歴など大量のデータを蓄積することができます。それらを永続化することがしばしば必要です。

• 感覚はリアルタイムまたは一時的な情報であり、大部分は短期間に有効です。必要に応じてデータベースに書き込むかどうかを決定できます（たとえば、重要な感覚イベントのみを保存する場合など）。

4.環境と空間クラス（Room、OccupiesRoom、Spatial、Environment、Inventoryなど）

• 部屋、環境、場所、オブジェクトコンテナなどの情報を表します。

•Room.id, OccupiesRoom、環境などのフィールドはしばしば永続化する必要があります。たとえば、ルームのホームページの説明、地図構造などです。

• コンポーネントの変更（例えば、エンティティが部屋間を移動する場合）はイベント単位で、または定期的に記述することができます。

5.外観とインタラクションクラス（外観、UIState、関係など）

・アバターやポーズ、表情、他のエンティティとのソーシャルリレーションシップネットワークなど、エンティティの外部の「可視」または「インタラクティブ」な部分を記録します。

• 一部はメモリ内のみで処理される場合があります（リアルタイム表現）、一方、他の部分（たとえば主要な社会関係）は永続化される場合があります。

6.ユーティリティ＆メンテナンスコンポーネント（クリーンアップ、DebugInfo、ProfilingDataなど）

• リサイクルが必要なエンティティ（クリーンアップ）をマークするために使用され、モニタリングおよび分析に使用するためのデバッグ情報（DebugInfo）を記録するために使用されます。

• 通常はメモリ上にのみ存在し、ログ記録や監査のために必要な場合を除いて、データベースとは同期されません。

3. システムアーキテクチャ

既に上記で紹介されています

4. マネージャーアーキテクチャ

コンポーネントとシステムに加えて、追加のリソース管理層が必要です。この層はデータベースアクセス、状態の競合、およびその他の重要な操作を処理します。

左側: システム (PerceptionSystem, ExperienceSystem, ThinkingSystem, etc.):

• 各システムは、ECSループ内のSimulationRuntimeによる実行がスケジュールされ、それぞれが関心のあるエンティティ（コンポーネント条件を介して）のクエリと処理を行います。

• ロジックを実行する際には、次のようなマネージャーとやり取りする必要があります:

• ルームマネージャー（RM）を呼び出して、部屋の情報を問い合わせ/更新します。
• StateManager（SM）を使用してMemory、Goal、Planなどの世界/エージェントの状態を取得または保存します。
• EventBus（EB）を使用して外部でイベントをブロードキャストまたはリスンします。
• 自然言語処理やプロンプトが必要な場合に、PromptManager（PM）が呼び出されます。

Right Side: マネージャー (EventBus、RoomManager、StateManager、EventManager、ActionManager、PromptManagerなど)：

• システムレベルの機能を提供します。これらは基本的にはロジックを積極的に「駆動」するのではなく、システムまたはランタイムによって呼び出されます。

• 典型的な例:

• ActionManagerはアクションの登録と実行の管理に特化しています。
• EventManager / EventBusは、イベントの発行と購読メカニズムに使用されます。
• RoomManagerは、部屋、レイアウト、および入居者を管理します。
• StateManagerはECSとデータベースまたはストレージ間の同期を担当します。
• PromptManagerは、LLMプロンプトテンプレートやコンテキスト管理などの拡張機能を提供します。
• 中間シミュレーションランタイム（R）：

• すべてのシステムの「スケジューラー」であり、異なるレベル（意識/無意識など）でシステムサイクルを開始または停止します;

• マネージャーは建設フェーズ中にも作成され、それぞれのシステムに渡されて使用されます。

• CleanupSystem:

• 特に、エンティティを再利用する際にコンポーネントまたはイベントの購読を同期的に削除するために使用されるComponentSync（CS）ともやり取りします。

結論として:

各システムは必要な時に対応するマネージャーを介してデータを読み書きしたりサービスを呼び出したりします。ランタイムは上位レベルですべてのシステムとマネージャーのライフサイクルと動作を一元的にスケジュールします。

5. ベクトルとデータベースがECS内でどのように相互作用するか

ECSシステムでは、システムが実際のロジック実行を処理し、データベース操作（読み取り/書き込み）は永続性マネージャ（PersistenceManager / DatabaseManager）またはステートマネージャ（StateManager）を介して管理されます。一般的なプロセスは次のようになります。

1. 初期ロード（起動またはロードフェーズ）

• StateManager / PersistenceManager は、エージェント、ルーム、ゴールなどのコア永続化コンポーネントのデータをデータベースからロードし、対応するエンティティ (エンティティ) を作成し、関連するコンポーネントフィールドを初期化します。

• たとえば、エージェントレコードのバッチを読み込んでECSワールドに挿入し、それらのためにエージェント、メモリ、ゴールなどのコンポーネントを初期化します。

2.ECSランタイム（システムの更新ループ）

• システムは各フレーム（またはラウンド）で処理を行います：PerceptionSystemは「知覚」を収集し、それらをPerceptionコンポーネントに書き込みます（主にライブラリの短期的なもの）。

ExperienceSystemは、新しい「認知体験」をMemory.experiencesに書き込みます。それが重要な体験である場合、即時の保存のためにStateManagerを呼び出すか、「needsPersistence」でマークして後続のバッチ書き込みのためにマークする場合もあります。

ThinkingSystem / ActionSystem / GoalPlanningSystemなどは、コンポーネントの内容に基づいて決定を行い、ECSのフィールドを更新します。

いくつかのコンポーネント（Goal.currentなど）が大幅な変更を受け、永続性（新しい長期目標など）を必要とする場合は、コンポーネントのリスニングやシステムイベントを通じてこのフィールドをデータベースに書き込むためにStateManagerに通知してください。

3.定期的またはイベント駆動の永続性

• ターゲットの計画が更新された場合やエージェントで重要なイベントが発生した場合など、システム内の特定のキーポイントでPersistenceManager.storeComponentData（eid、”Goal”）などのインターフェースを呼び出すことで、ライブラリをドロップできます。

• StateManagerはCleanupSystemまたはタイマーで「needsPersistence」タグを持つコンポーネントまたはエンティティをスキャンし、一度にデータベースに書き込むこともできます。

• また、ログや監査データ（アクション履歴、思考ログなど）もここにアーカイブおよび保存できます。

4.マニュアルまたはシャットダウン保存（チェックポイントと終了時の永続性）

• サーバーまたはプロセスをシャットダウンする場合は、StateManager.saveAll()を使用して書き込まれていないデータを一括してデータベースに書き込み、次回ロードされるときにECSの状態を復元できるようにします。

• 一部のスタンドアロン/オフラインシナリオでは、アーカイブは手動でトリガーすることもできます。

• 完全なサンプルプロセス

以下は、コンポーネントとデータベースが相互作用する可能性のある方法を示すための簡単なシナリオです。

1.スタートアップフェーズ：StateManager.queryDB（"SELECT * FROM agents"）→エージェントレコードのバッチを取得し、順番に各レコードごとにエンティティ（EID=x）を作成し、エージェント、メモリ、ゴールなどのコンポーネントフィールドを初期化します。

同時に、「rooms」テーブルからルーム情報をロードし、Roomエンティティを作成します。

2.ランタイム操作：PerceptionSystemは、特定の部屋でイベント「MagicSwordが現れた」を検出し、Perception.currentStimuli[eid]に書き込みます。ExperienceSystemはStimuliをExperienceに変換し、それをMemory.experiences[eid]に割り当てます。ThinkingSystemはMemory、Goal、その他の情報に基づいて次のアクションを決定し、Action.pendingAction[eid]を生成します。ActionSystemがアクションを実行した後、その結果をMemoryまたはAction.lastActionResultに書き込みます。これが重要なプロットイベントである場合、Memory.experiences[eid]の最新部分がneedsPersistenceとしてマークされます。しばらくしてから、StateManagerはMemory.experiences[eid]が「needsPersistence」を持っていることを見つけ、それをデータベースに書き込みます（INSERT INTO memory_experiences…）。

3. 停止またはチェックポイント保存：ECSまたはシステムのスケジューリングに基づいて、StateManager.saveAll() が「サーバーがシャットダウン」されたときに呼び出され、メモリ内のまだ最新の状態である主要なコンポーネントフィールド（Agent、Memory、Goalなど）の最新の状態をデータベースに書き込みます。次回起動時には、ECSのワールド状態をデータベースからロードして復元できます。

• コンポーネントをカテゴリ別に分類することは、プロジェクト内のエンティティデータを明確に管理するだけでなく、「永続性が必要」および「メモリ内のみ存在」というデータ境界を制御するのにも役立ちます。

• データベースとのやり取りは通常、専用のマネージャ（StateManagerなど）によって処理され、システムがデータベースの読み書きが必要な場合にそれを介して操作されます。これにより、システムがSQLや類似の低レベルな文を直接書き込むことを避けることができます。

• このように、ECSの論理的な効率と柔軟性、およびデータベースによってもたらされる持続性、中断再開、およびデータ統計分析の利点を同時に享受することができます。

4. 建築革新

全体のアーキテクチャのハイライトは次のとおりです:

• 各システムは独立して動作し、他のシステムと呼び出し関係がありません。したがって、エージェントの「環境の変化を認識（知覚）→内的経験に記録または変換する（経験）→自己思考および意思決定（思考）→行動に移す（アクション）→目標と計画を動的に調整する（ゴールプランニング+計画）→環境を同期する（ルーム）→不要なエンティティを適時にリサイクルする（クリーンアップ）」能力を実装したい場合でも、各システムは多くの機能上の相互依存があるかもしれませんが、ECSアーキテクチャを使用して全体を独立したシステムに構造化することができます。各システムは引き続き独立して実行され、他のシステムとは相互作用しません。人と結合関係があります。
• 最近、UnityがECSアーキテクチャにますます移行している主な理由だと私は考えています。
• たとえば、エージェントには基本的な機能が必要です。エンティティの定義時に、いくつかのコンポーネントの登録とシステムの登録を削減するだけで十分であり、数行のコードを変更することなく簡単に達成できます。

以下の通り:

同時に、開発プロセス中に新機能を追加したい場合、他のシステムに影響を与えることなく、必要な機能を簡単にロードすることができます。

• また、現在のアーキテクチャのパフォーマンスは、実際には従来のオブジェクト指向アーキテクチャよりもはるかに優れていることが認識されています。これはゲーム業界で認められた事実であり、ECSの設計が並行性により適しているため、複雑なDefaiシナリオでECSを使用すると、アーキテクチャにはさらなる利点があるかもしれません。特に、エージェントが数量取引に使用されることが期待されるシナリオでは、ECSも有用である可能性があります（エージェントゲームのシナリオだけでなく）。
• システムを意識的、潜在的、無意識的に分割して、異なるタイプのシステムをどれくらいの頻度で実行するかを区別することは非常に賢明な設計であり、既に非常に具体的な人間の能力です。

私の個人的な視点からは、これは非常にモジュール化されたフレームワークであり、優れたパフォーマンスを発揮します。コードの品質も非常に高く、良い設計ドキュメントが含まれています。残念ながら、Project89はこのフレームワークに対する可視性とプロモーションが不足しており、そのために私はこの記事を書くのに4日間かかりました。優れた技術は認知される価値があると信じていますので、明日、この記事の英語版をリリースして、ゲームチームとDeFi（分散型金融）開発者の間での認識を高める予定です。より多くのチームが自身のプロジェクトの潜在的なアーキテクチャの選択肢としてこのフレームワークを探求することを願っています！

免責事項：

1. この記事は、こちらから転載されています。[0xhhh].元のタイトル「I See The Next Generation Agent Framework in Project89」を転送します。著作権は原著作者に帰属します[0xhhh]. もし転載に異議がある場合は、お問い合わせくださいゲート・ラーンチーム、関連手続きに従ってできるだけ早く対処します。
2. 免責事項：この記事で表明されている見解は、著者個人の見解を表しており、投資アドバイスを構成するものではありません。
3. 他の言語版は、通常、gate Learnチームによって翻訳されます。特に記載がない限り、翻訳された記事の複製、配布、または盗用はできません。