著者: Kevin、BlockBooster 研究者
業界発展の重要なパズルのピースとして、AI エージェント フレームワークには、テクノロジーの導入と生態系の成熟を促進するという 2 つの可能性が含まれている可能性があります。市場で活発に議論されているフレームワークには、Eliza、Rig、Swarms、ZerePy などが含まれます。これらのフレームワークは開発者を惹きつけ、Github リポジトリを通じて評判を築きます。これらのフレームワークは、光が波と粒子の両方の特性を持つのと同様に、「ライブラリ」コインの形で発行されます。エージェントフレームワークは、重大な外部性とミームコインの特性を同時に備えています。この記事では、フレームワークの「波動と粒子の二重性」と、エージェント フレームワークが最後のコーナーになり得る理由を説明することに重点を置きます。
エージェント フレームワークによってもたらされる外部性は、バブルが沈静化した後でも芽を残す可能性があります。
GOAT の誕生以来、エージェント ナラティブの市場への影響は増大しています。カンフーの達人のように、左の拳「ミームコイン」と右の掌「インダストリー ホープ」を使えば、必ず一手で負けます。 。実際、AI エージェントのアプリケーション シナリオは厳密には区別されておらず、プラットフォーム、フレームワーク、特定のアプリケーション間の境界があいまいですが、それでもトークンまたはプロトコルの優先順位に従って大まかに分類できます。ただし、トークンまたはプロトコルの開発環境に応じて、次のカテゴリに分類できます。
Launchpad: アセット ヘア プラットフォーム。 Base チェーンの Virtuals Protocol とクランカー、Solana チェーンの Dasha。
AI Agent アプリケーション: Agent と Memecoin の間は無料で、GOAT、aixbt などのメモリ構成に優れた機能を備えています。これらのアプリケーションは通常、一方向の出力と非常に制限された入力条件を持ちます。
AIエージェントエンジン：SolanaチェーンのGriffinとベースチェーンのSpectre AI。 griffain は、読み取りおよび書き込みモードから読み取り、書き込み、およびアクション モードに進化できます。Spectre AI は RAG エンジンおよびオンチェーン検索です。
AI エージェント フレームワーク: フレームワーク プラットフォームの場合、エージェント自体がアセットであるため、エージェント フレームワークはエージェントのアセット発行プラットフォームであり、エージェントの Launchpad です。現在の代表的なプロジェクトには、ここ 2 日間で熱く議論された ai16、Zerebro、ARC、Swarms が含まれます。
その他の小さな指示: 包括的な Agent Simmi、AgentFi プロトコル モードの改ざん、Agent Creator.Bid。
エージェント フレームワークについてさらに議論すると、十分な外部性があることがわかります。主要なパブリック チェーンやプロトコルとは異なり、開発者はさまざまな開発言語環境からしか選択できず、業界の開発者の総数はそれに応じた市場価値の増加を示していません。 Github Repo は、Web2 および Web3 開発者が合意を形成する場所です。ここで設立された開発者コミュニティは、任意のプロトコル単独で開発された「プラグ アンド プレイ」パッケージよりも Web2 開発者にとって魅力的で影響力があります。
この記事で言及されている 4 つのフレームワークはすべてオープンソースです。ai16z の Eliza フレームワークは 6200 個のスターを獲得し、Zerebro の ZerePy フレームワークは 1700 個のスターを獲得し、Swarms の Swarms フレームワークは 2100 個のスターを獲得しています。現在、Eliza フレームワークはさまざまなエージェント アプリケーションで広く使用されており、最も広範囲をカバーするフレームワークです。 ZerePy の開発レベルは高くなく、開発の方向性は主に X であり、ローカル LLM と統合メモリはまだサポートされていません。 RIG は開発が比較的難しいですが、開発者はパフォーマンスを最適化するための最大限の自由を得ることができます。 Swarms には mcs を立ち上げるチーム以外のユースケースはありませんが、Swarms はさまざまなフレームワークを統合でき、想像力の余地がたくさんあります。
また、上記の分類ではエージェントエンジンとフレームワークが分離されているため、混乱が生じる可能性があります。しかし、両者の間には違いがあると思います。まず、なぜエンジンなのでしょうか？ Lenovo と現実の検索エンジンとの類似点は比較的一貫しています。同種のエージェント アプリケーションとは異なり、エージェント エンジンのパフォーマンスはそれを上回っていますが、同時に完全にカプセル化されたブラック ボックスであり、API インターフェイスを通じて調整できます。ユーザーはエージェント エンジンのパフォーマンスをフォークの形で体験できますが、基本フレームワークのように全体像を把握したり、自由にカスタマイズしたりすることはできません。各ユーザーのエンジンは、調整されたエージェント上で画像を生成し、その画像と対話するようなものです。エージェントでエージェント フレームワークを作成する最終的な目標は、対応するチェーン、データ対話メソッドの定義方法、データ検証メソッドの定義方法、ブロックの定義方法を統合することであるため、フレームワークは本質的にチェーンに適応することです。サイズ、コンセンサスとパフォーマンスのバランスをとる方法など、フレームワークはこれらを考慮する必要があります。そしてエンジンはどうですか？必要なのは、モデルを完全に微調整し、データの相互作用とメモリの関係を特定の方向に設定することだけです。パフォーマンスが唯一の評価基準ですが、フレームワークはそうではありません。
「波動と粒子の二重性」の観点を使用してエージェントのフレームワークを評価することは、私たちが正しい方向に進んでいることを確認するための前提条件となる可能性があります。
入力と出力を実行するエージェントのライフサイクルには、3 つの部分が必要です。まず、基礎となるモデルが深さと考え方を決定し、その後、基本モデルが出力された後、メモリがカスタマイズの場所となり、メモリに基づいて修正され、最終的にさまざまなクライアント上で出力操作が完了します。
出典: @SuhailKakar
エージェントフレームワークが「波と粒子の二重性」を持っていることを証明するために、「波」は「ミームコイン」の特徴を持ち、コミュニティの文化と開発者の活動を表し、エージェントの魅力とコミュニケーション能力を強調します。「粒」は「業界」を表します。 「期待」の機能。基礎となるパフォーマンス、実際の使用例、技術的な深さを表します。例として 3 つのフレームワークを組み合わせて、2 つの側面から開発チュートリアルを説明します。
すぐに組み立てられるエリザフレーム
環境をセットアップする
出典: @SuhailKakar
イライザをインストールする
出典: @SuhailKakar
3. 設定ファイル
出典: @SuhailKakar
4.エージェントの性格を設定する
出典: @SuhailKakar
Eliza のフレームワークは比較的使いやすいです。これは、ほとんどの Web および Web3 開発者が使い慣れている言語である TypeScript に基づいています。フレームワークは簡潔で抽象的すぎないため、開発者は必要な機能を簡単に追加できます。ステップ 3 を通じて、Eliza が複数のクライアントと統合できることがわかり、Eliza をマルチクライアント統合用のアセンブラとして理解することができます。 Eliza は、DC、TG、および
Eliza は、フレームワークの単純さとインターフェイスの豊富さにより、アクセスしきい値を大幅に下げ、比較的統一されたインターフェイス標準を実現しました。
ワンクリックの ZerePy フレームワーク
1.ZerePyライブラリをフォークする
出典: https://replit.com/@blormdev/ZerePy?v=1
2. X と GPT を構成する
出典: https://replit.com/@blormdev/ZerePy?v=1
3.エージェントの性格を設定する
出典: https://replit.com/@blormdev/ZerePy?v=1
パフォーマンスが最適化されたリグフレームワーク
RAG (Retrieval Enhanced Generation) エージェントの構築を例に挙げます。
1.環境とOpenAIキーを設定する
出典: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
2. OpenAI クライアントをセットアップし、PDF 処理にチャンキングを使用する
出典: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
3. ドキュメント構造と埋め込みを設定する
出典: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
4. ベクターストレージとRAGエージェントを作成する
出典: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
Rig (ARC) は、LLM ワークフロー エンジン用の Rust 言語に基づく AI システム構築フレームワークであり、低レベルのパフォーマンス最適化の問題を解決します。言い換えれば、ARC は、AI 呼び出しとパフォーマンスの最適化を提供する AI エンジンの「ツールボックス」です。データ ストレージ、例外処理、その他のバックグラウンド サポート サービス。
Rig が解決したいのは、開発者が LLM をより適切に選択し、プロンプトワードをより適切に最適化し、トークンをより効果的に管理し、同時処理を処理する方法、リソースを管理する方法、遅延を削減する方法などを支援する「呼び出し」問題です。その焦点は AI です。 LLMモデル AIエージェントシステムと連携する際に「どう活用するか」。
Rig は、 LLM 駆動のアプリケーション (RAG Agent を含む) の開発を簡素化するように設計されたオープン ソースの Rust ライブラリです。 Rig はよりオープンであるため、開発者にとってより高い要件があり、Rust と Agent についての理解が深まります。 ここでのチュートリアルは、RAG エージェントの最も基本的な構成プロセスであり、LLM と外部ナレッジの取得を組み合わせて LLM を強化します。公式 Web サイトの他のデモでは、Rig に次のような特徴があることがわかります。
統合 LLM インターフェイス: 統合を簡素化するために、さまざまな LLM プロバイダーの一貫した API をサポートします。
抽象的なワークフロー: 事前に構築されたモジュラー コンポーネントにより、Rig は複雑な AI システムの設計を行うことができます。
統合されたベクトル ストレージ: カテゴリ ストレージのサポートが組み込まれており、RAG エージェントなどの同様の検索エージェントで効率的なパフォーマンスを提供します。
柔軟な埋め込み: 埋め込みを処理するための使いやすい API を提供し、RAG Agent などの同様の検索エージェントを開発する際の意味の理解の難しさを軽減します。
Eliza と比較すると、Rig は開発者にパフォーマンスを最適化するための追加の余地を提供し、開発者が LLM とエージェントの呼び出し、および協調的な最適化をより適切にデバッグできるように支援することがわかります。 Rig は Rust 主導のパフォーマンスを使用し、Rust のゼロコスト抽象化とメモリ安全で高性能、低レイテンシの LLM 操作を利用します。基礎的なレベルでより豊かな自由度を提供できます。
結合された Swarms フレームワークを分解する
Swarms は、エンタープライズ レベルの運用レベルのマルチ エージェント オーケストレーション フレームワークを提供することを目的としています。公式 Web サイトでは、数十のワークフローとエージェントの並列およびシリアル アーキテクチャが提供されています。
順次ワークフロー
出典: https://docs.swarms.world
Sequential Swarm アーキテクチャは、線形シーケンスでタスクを処理します。各エージェントはタスクを完了してから、チェーン内の次のエージェントに結果を渡します。このアーキテクチャは秩序ある処理を保証し、タスクに依存関係がある場合に役立ちます。
使用事例：
ワークフローの各ステップは、組み立てラインや順次データ処理など、前のステップに依存します。
操作の順序に厳密に従う必要があるシナリオ。
階層アーキテクチャ:
出典: https://docs.swarms.world
トップダウン制御を実現するために、上位エージェントは下位エージェント間のタスクを調整します。エージェントはタスクを同時に実行し、その結果をループにフィードバックして最終的な集計を行います。これは、高度に並列化可能なタスクに役立ちます。
スプレッドシート形式のアーキテクチャ:
出典: https://docs.swarms.world
同時に動作する複数のエージェントを管理するための大規模な swarm アーキテクチャ。それぞれが独自のスレッドで実行される、数千のエージェントを同時に管理できます。大規模なエージェントの出力を監視するのに最適です。
Swarms はエージェント フレームワークであるだけでなく、前述の Eliza、ZerePy、Rig フレームワークとも互換性があり、モジュール式のアイデアにより、さまざまなワークフローやアーキテクチャでエージェントのパフォーマンスを最大化し、対応する問題を解決します。 Swarms のコンセプトと開発者コミュニティの進歩はどちらも問題ありません。
Eliza: 最も使いやすく、初心者やラピッド プロトタイピングに適しており、特にソーシャル メディア プラットフォームでの AI インタラクションに適しています。このフレームワークはシンプルで、簡単に統合して迅速に変更でき、過度のパフォーマンスの最適化を必要としないシナリオに適しています。
ZerePy: ワンクリックのデプロイメント。Web3 およびソーシャル プラットフォーム用の AI エージェント アプリケーションの迅速な開発に適しています。シンプルなフレームワークと柔軟な構成を備えた軽量の AI アプリケーションに適しており、迅速な構築と反復に適しています。
Rig: パフォーマンスの最適化に焦点を当てており、特に同時実行性とパフォーマンスの高いタスクで優れたパフォーマンスを発揮し、詳細な制御と最適化を必要とする開発者に適しています。このフレームワークは比較的複雑で、ある程度の Rust の知識が必要なため、経験豊富な開発者に適しています。
Swarms: エンタープライズ レベルのアプリケーションに適しており、マルチ エージェントのコラボレーションと複雑なタスク管理をサポートします。このフレームワークは柔軟で、大規模な並列処理をサポートし、複数のアーキテクチャ構成を提供しますが、その複雑さのため、効果的なアプリケーションにはより強力な技術的背景が必要になる場合があります。
全体として、Eliza と ZerePy は使いやすさと迅速な開発という点で利点がありますが、Rig と Swarms は、高性能で大規模な処理を必要とするプロの開発者やエンタープライズ アプリケーションにより適しています。
これが、エージェント フレームワークに「業界希望」機能が備わっている理由です。上記のフレームワークはまだ初期段階にあり、先行者利益を獲得し、活発な開発者コミュニティを確立することが最優先事項です。フレームワーク自体のパフォーマンスと、一般的な Web2 アプリケーションに遅れをとっているかどうかは、主な矛盾ではありません。 Web3 業界は常に市場の注目を集める必要があるため、フレームワークのパフォーマンスがどれほど優れていても、基礎がどれほど強固であっても、始めるのが難しく、成功しない場合は、開発者が継続的に流入するフレームワークだけが最終的に勝つことができます。それを気にするのは本末転倒だ。フレームワーク自体が開発者を惹きつけることができるという前提で、より成熟した完全なトークンエコノミーモデルを備えたフレームワークが目立つようになるでしょう。
Agentフレームワークには「Memecoin」機能があり、非常にわかりやすいです。上記のフレームワーク トークンはいずれも、合理的なトークン経済設計を持っていません。トークンには、実証済みのビジネス モデルがなく、有効なトークン フライホイールもありません。トークンと完全に有機的な組み合わせが存在せず、トークン価格の成長はFOMO以外に根本的なサポートを得るのが難しく、安定的かつ持続的な価値の成長を保証するのに十分な堀がありません。一方で、上記のフレームワーク自体は比較的ラフな印象があり、実際の価値は現在の市場価値と一致しないため、「ミームコイン」としての性格が強いです。
エージェントフレームワークの「波動と粒子の二重性」は欠点ではなく、純粋なミームコインでもトークンの使用例でもない、半分空になった水のボトルとして大まかに理解することはできないことに注意してください。前回の記事で述べたように、軽量エージェントは曖昧な Memecoin のベールに覆われており、コミュニティの文化と基本はもはや矛盾しなくなり、エージェントの初期段階ではバブルと不確実性がありますが、新しい資産開発の道が徐々に現れています。フレームワークですが、開発者を引き付け、アプリケーションの実装を促進する可能性は無視できません。将来的には、完全なトークン経済モデルと強力な開発者エコシステムを備えたフレームワークが、この路線の重要な柱となる可能性があります。
