元のタイトルを転送する: AIエージェントフレームワークはパズルの最終ピースですか？フレームワークの「波粒二重性」をどのように解釈しますか？

AIエージェントフレームワークは、業界の発展において重要な役割を果たし、技術の実装とエコシステムの成熟の両方を促進する可能性を持っている。市場で最も議論されているフレームワークには、Eliza、Rig、Swarms、ZerePyなどがあります。これらのフレームワークは、GitHubのリポジトリを通じて開発者を引き寄せ、評判を築いています。これらのフレームワークは、「ライブラリ」を通じてトークンを発行することで、光のように波と粒子の特性を持っています。同様に、エージェントフレームワークは、重要な外部性とメームコインの特性を持っています。本記事では、これらのフレームワークの「波粒子二重性」を解釈し、エージェントフレームワークがパズルの最後のピースになり得る理由を探求します。

バブルがはじけた後も、エージェントフレームワークによってもたらされる外部性は持続的な成長をもたらす可能性があります。

GOATの登場以来、エージェントの物語は、格闘技の達人が強力な一撃を放つように、市場の注目を集めています - 左の拳は「ミームコイン」を表し、右の手のひらは「業界の希望」を体現しており、これらの動きのいずれかに敗北する可能性があります。実際には、AI エージェントのアプリケーションシナリオは厳密に区別されておらず、プラットフォーム、フレームワーク、および特定のアプリケーション間の境界は曖昧です。ただし、これらはトークンまたはプロトコルの好みに応じて大まかに分類できます。トークンやプロトコルの開発設定に基づいて、一般的に次のカテゴリに分類できます。

• Launchpad: アセット発行プラットフォーム。Virtuals ProtocolやBaseチェーン上のClanker、Solanaチェーン上のDashaなどがあります。
• AIエージェントの応用: これらはエージェントとメメコインの間を浮動しており、GOAT、aixbtなどのようなメモリ構成の特徴を持っています。これらのアプリケーションは一方向の出力であり、非常に限られた入力条件を持っています。
• AIエージェントエンジン: 例えば、Solanaチェーン上のGriffainやBaseチェーン上のSpectre AIなどがあります。Griffainは読み書きモードから読み書きアクションモードに進化し、Spectre AIはオンチェーン検索に使用されるRAGエンジンです。
• AI エージェントフレームワーク: フレームワークプラットフォームの場合、エージェント自体が資産です。したがって、エージェントフレームワークは資産発行プラットフォームおよびエージェントのためのランチパッドとして機能します。代表的なプロジェクトには、ai16、Zerebro、ARC、そして話題のスワームが含まれます。
• その他のより小さな方向: シンミ、エージェントFiプロトコルモード、偽造タイプのエージェントセラフ、およびリアルタイムAPIエージェントクリエーターなど、包括的なエージェントプロジェクト。

エージェントフレームワークについてさらに議論すると、大きな外部性があることがわかります。さまざまなプログラミング言語環境からしか選択できない主要なパブリックチェーンやプロトコルの開発者とは異なり、業界の開発者コミュニティの全体的な規模は、時価総額に対応する成長率を示していません。GitHub リポジトリは、Web2 と Web3 の開発者がコンセンサスを構築する場所です。ここで開発者コミュニティを構築することは、Web2開発者にとって、プロトコルによって個別に開発された「プラグアンドプレイ」パッケージよりもはるかに魅力的で影響力があります。

この記事で言及されている4つのフレームワークはすべてオープンソースです:

• ai16zのElizaフレームワークは6,200のスターを受け取りました。
• ZerePy framework by Zerebro has received 191 stars.
• ARCのRIGフレームワークは1,700のスターを獲得しました。
• Swarms framework by Swarms has received 2,100 stars.

現在、Elizaフレームワークはさまざまなエージェントアプリケーションで広く使用されており、最も広く使用されているフレームワークです。ZerePyの開発はあまり進んでおらず、開発方向性は主にXにあります。まだローカルLLMsおよび統合メモリをサポートしていません。RIGは最も相対的な開発の難しさを持っていますが、開発者に最も大きな自由を与えてパフォーマンスの最適化を実現します。Swarmsは、チームがmcsを立ち上げた以外にはまだ他のユースケースはありません。ただし、Swarmsは異なるフレームワークと統合することができ、大きな潜在能力を提供します。

さらに、前述の分類では、エージェントエンジンとフレームワークを分離すると混乱を招く可能性があります。しかし、私はこの2つは違うと考えています。まず、なぜエンジンと呼ばれるのですか?現実の検索エンジンとの類似性は比較的適切です。均質化されたエージェントアプリケーションとは異なり、エージェントエンジンのパフォーマンスはより高いレベルにありますが、完全にカプセル化されており、調整はブラックボックスのようなAPIインターフェイスを介して行われます。ユーザーは、エージェントエンジンをフォークすることでパフォーマンスを体験できますが、基本的なフレームワークのように全体像やカスタマイズの自由度を制御することはできません。各ユーザーのエンジンは、トレーニングされたエージェントでミラーを生成し、そのミラーと対話するようなものです。一方、AgentがAgentフレームワークを構築する場合、最終的な目標は対応するチェーンとの統合であるため、フレームワークは基本的にチェーンに適応するように設計されています。データ相互作用メソッドの定義方法、データ検証メソッドの定義方法、ブロックサイズの定義方法、コンセンサスとパフォーマンスのバランスを取る方法など、フレームワークで考慮する必要があるのはこれらです。エンジンに関しては、モデルを微調整し、データの相互作用とメモリの関係を一方向に調整するだけで済みます。パフォーマンスが唯一の評価基準ですが、フレームワークはこれに限定されません。

「波粒二重性」の観点からエージェントフレームワークを見ることは、正しい方向に進むための前提条件であるかもしれません

エージェントの入出力ライフサイクルには3つのパーツが必要です。まず、基本モデルが考える深さと方法を決定します。次に、カスタマイズが行われるのはメモリです。基本モデルが出力を生成した後、メモリに基づいて修正されます。最後に、出力操作が異なるクライアントで完了します。

ソース：@SuhailKakar

Agentフレームワークが「波粒二重性」を持っていることを確認するために、『波』は「Memecoin」の特徴を表し、コミュニティの文化や開発者の活動を象徴し、エージェントの魅力と普及能力を強調します。『粒』は「業界の期待」を表し、基礎的なパフォーマンス、実際のユースケース、技術の深さを示します。私はこれを2つの側面を組み合わせて説明し、3つのフレームワークの開発チュートリアルを例に説明します。

急速な統合エリザフレームワーク

1. 環境を設定する

出典: @SuhailKakar

1. Elizaをインストールする

ソース: @SuhailKakar

1. 設定ファイル

ソース: @SuhailKakar

4. エージェントの性格を設定する

ソース：@SuhailKakar

Elizaフレームワークは比較的簡単に始めることができます。それはTypeScriptに基づいており、ほとんどのWebおよびWeb3開発者が馴染みがあります。このフレームワークはシンプルで、過剰な抽象化を避けており、開発者が簡単に望む機能を追加できます。ステップ3から、Elizaはマルチクライアント統合をサポートしており、マルチクライアント統合のアセンブラとして理解することができます。ElizaはDC、TG、Xなどのプラットフォームをサポートし、さまざまな大規模言語モデルもサポートしています。上記のソーシャルメディアを介して入力し、LLMモデルを介して出力することも可能であり、また組み込みのメモリ管理もサポートしています。これにより、異なる習慣を持つ任意の開発者が迅速にAIエージェントを展開できます。

フレームワークのシンプルさとインタフェースの豊富さにより、Elizaはアクセスの敷居を大幅に下げ、比較的統一されたインタフェース規格を達成します。

ワンクリックでZerePyフレームワークを使用する

1.フォークZerePyのリポジトリ

ソース:https://replit.com/

1. XとGPTを設定する

ソース：https://replit.com/

3.エージェントパーソナリティを設定する

ソース:https://replit.com/

パフォーマンス最適化されたリグフレームワーク

RAG（Retrieval-Augmented Generation）エージェントの構築を例に取ると：

1. 環境とOpenAIキーを設定する

ソース：https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422

1. OpenAIクライアントの設定とPDF処理のためのチャンキングの使用

ソース：https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422

1. ドキュメント構造と埋め込みの設定

source:https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422

1. ベクトルストレージとRAGエージェントを作成する

source:https://dev.to/0thtachi/100行のコードでRigを使用したRAGシステムを構築する

Rig（ARC）は、LLMワークフローエンジンのためのRust言語ベースのAIシステム構築フレームワークです。ARCは、より低レベルのパフォーマンス最適化の問題を解決します。つまり、ARCはAIエンジンの「ツールボックス」であり、AI呼び出しやパフォーマンス最適化、データストレージ、例外処理などのバックグラウンドサポートサービスを提供します。

Rigが解決しようとしているのは、「呼び出し」問題であり、開発者がより適切にLLMを選択し、プロンプトワードをより効果的に最適化し、トークンをより効果的に管理し、並行処理をどのように処理し、リソースを管理し、遅延を削減するかなどです。その焦点はAIのLLMモデルにあり、AIエージェントシステムと協力してそれを「うまく活用する」方法です。

リグRig（リグ）は、RAGエージェントを含むLLM駆動アプリケーションの開発を簡素化するために設計されたオープンソースのRustライブラリです。Rigはよりオープンなため、開発者に対してより高い要件とRustおよびエージェントのより高い理解が必要です。ここでは、最も基本的なRAGエージェントの設定プロセスについてのチュートリアルをご紹介します。RAGはLLMと外部知識検索を組み合わせることでLLMを強化します。公式ウェブサイトの他のデモでは、Rigには以下の特徴があります:

• 統一されたLLMインターフェース：さまざまなLLMプロバイダーの一貫したAPIをサポートし、統合を簡素化します。
• 抽象的なワークフロー：事前に構築されたモジュラーコンポーネントにより、Rigは複雑なAIシステムの設計を行うことができます。
• 統合ベクトルストレージ：ジャンルストレージの組み込みサポートにより、RAGエージェントなどの類似検索エージェントで効率的なパフォーマンスを提供します。
• 柔軟な埋め込み：埋め込みの処理に使いやすいAPIを提供し、RAGエージェントなどの類似の検索エージェントを開発する際の意味理解の難しさを軽減します。

Elizaと比較すると、Rigは開発者にパフォーマンスの最適化に関する余地を提供し、LLMとAgentの呼び出しとコラボレーションの最適化をより良くデバッグできることがわかります。RigはRustを活用したパフォーマンスを提供し、Rustのゼロコスト抽象化とメモリ安全性、高性能、低遅延のLLM操作を活用しています。これにより、より豊かな自由度を基礎レベルで提供することができます。

モジュラーコンポジションスワームフレームワーク

Swarmsは、エンタープライズグレードの製品レベルのマルチエージェントオーケストレーションフレームワークを提供することを目指しています。公式ウェブサイトでは、エージェントタスクのためのワークフローと並列/直列アーキテクチャが数多く提供されています。以下に、それらの一部の簡単な紹介を示します。

シーケンシャルワークフロー

ソース：https://docs.swarms.world

Sequential Swarmアーキテクチャはタスクを直線的に処理します。各エージェントは、次のエージェントに結果を渡す前に自身のタスクを完了します。このアーキテクチャは整然な処理を保証し、タスクに依存関係がある場合に便利です。

ユースケース：

• 組み立てラインや順次データ処理のように、ワークフローの各ステップは前のステップに依存しています。
• 操作順序に厳密な遵守が必要なシナリオ

階層構造:

ソース: https://docs.swarms.world

このアーキテクチャでは、上位レベルのエージェントが下位レベルのエージェント間のタスクを調整するトップダウン制御が実装されています。エージェントはタスクを同時に実行し、その結果をループにフィードバックして最終的な集計を行います。これは、並列化が可能なタスクに特に役立ちます。

ソース：https://docs.swarms.world

このアーキテクチャは、同時に作業する大規模なエージェントグループを管理するように設計されています。各々が独自のスレッドで実行される数千のエージェントを管理できます。大規模なエージェント操作の出力を監視するのに最適です。

SwarmsはAgentフレームワークだけでなく、以前に言及されたEliza、ZerePy、およびRigフレームワークとも互換性があります。モジュラーなアプローチを採用して、異なるワークフローとアーキテクチャにおいてエージェントのパフォーマンスを最大化し、対応する問題を解決します。Swarmsの概念と開発は、開発者コミュニティと共に順調に進んでいます。

• Eliza：最も使いやすさを提供し、特にソーシャルメディアプラットフォームでのAIの対話に適しており、初心者や迅速なプロトタイプ開発に適しています。このフレームワークはシンプルで簡単に統合や変更ができるため、高度なパフォーマンスの最適化を必要としないシナリオに適しています。
• ZerePy: One-clickデプロイメント、Web3やソーシャルプラットフォーム上でAIエージェントアプリケーションを迅速に開発するのに最適です。軽量なAIアプリケーションに適しており、簡単なフレームワークと迅速なセットアップとイテレーションのための柔軟な構成が可能です。
• Rig: パフォーマンスの最適化に焦点を当て、特に高並行性および高パフォーマンスのタスクに優れています。詳細な制御と最適化が必要な開発者に最適です。フレームワークはより複雑で、Rustの知識が必要ですので、より経験豊富な開発者に適しています。
• Swarms: 企業レベルのアプリケーションに適しており、マルチエージェントの連携や複雑なタスク管理をサポートしています。このフレームワークは柔軟で、大規模な並列処理をサポートし、さまざまなアーキテクチャ構成を提供しています。ただし、その複雑さから、効果的な利用にはより強力な技術的バックグラウンドが必要になるかもしれません。

一般的に、ElizaとZerePyは使いやすさと迅速な開発の利点を持っていますが、RigとSwarmsは高性能と大規模な処理を必要とするプロの開発者や企業向けのアプリケーションにより適しています。

これがエージェントフレームワークが「業界の希望」という特性を持つ理由です。上記で言及されたフレームワークはまだ初期段階にあり、直近の優先事項はファーストムーバーアドバンテージを得て、活発な開発者コミュニティを確立することです。フレームワークのパフォーマンスやWeb2の人気アプリに遅れをとるかどうかは主要な懸念事項ではありません。最終的に成功するのは、常に市場の注目を集める必要があるため、開発者を継続的に引き付けることができるフレームワークだけです。フレームワークのパフォーマンスがどれほど優れていたり、基盤がどれほど堅固であろうとも、使用が難しくユーザーを引き付けることに失敗すれば逆効果です。フレームワーク自体が開発者を引き付けることができれば、より成熟し完全なトークン経済モデルを持つものが際立つでしょう。

エージェントフレームワークの「Memecoin」の特徴は非常に理解しやすいです。上記のフレームワークのトークンには、合理的なトークン経済設計がなく、使用ケースがないか非常に限られており、ビジネスモデルも検証されていません。効果的なトークンフライホイールはありません。フレームワークは単なるフレームワークであり、フレームワークとトークンの間には有機的な統合がありませんでした。FOMO以外のトークン価格の成長は、基本的な要素からのサポートがほとんどなく、安定した長期的な価値成長を確保するための強力な堀を欠いています。同時に、フレームワーク自体はまだやや粗野であり、実際の価値は現在の市場価値と一致していないため、強い「Memecoin」の特徴を示しています。

エージェントフレームワークの「波粒子二重性」は欠点ではなく、純粋なメメコインでもなく、トークンの使用例なしの中途半端な解決策として乱暴に解釈されるべきではないことに注意する価値があります。前回の記事で述べたように、軽量エージェントは曖昧なメメコインのヴェールで覆われています。コミュニティの文化と基本的な要素はもはや矛盾ではなく、新たな資産開発の道が徐々に現れつつあります。エージェントフレームワークに関する初期のバブルと不確実性にもかかわらず、開発者を引きつけ、アプリケーションの採用を推進する潜在能力を無視するべきではありません。将来、トークン経済モデルが十分に開発され、強力な開発者エコシステムを備えたフレームワークがこの分野の重要な柱となる可能性があります。

免責事項:

1. この記事は[から再現されていますodaily]. オリジナルタイトルの転送: AIエージェントフレームワークはパズルの最後のピースですか？ フレームワークの「波粒子二重性」をどのように解釈しますか？ 著作権はオリジナルの著者[BlockBoosterの研究者であるケビン]に帰属します。 転載に異議がある場合は、お問い合わせくださいゲートラーンチーム、チームは関連手続きに従ってできるだけ早く処理します。
2. 責任の免責事項：本文に表現されている見解や意見はすべて著者個人のものであり、投資アドバイスを構成するものではありません。
3. gate Learnチームは、記事を他の言語に翻訳しました。翻訳された記事の複製、配布、または盗作は、特に記載がない限り禁止されています。