Author: Shlok Khemani, Oliver Jaros Source: Decentralised.co Translated by Good Oba, Golden Finance
本日の投稿は、エージェントフレームワークについての説明です。本日の投稿は、エージェントフレームワークについての説明と、その進化についての評価です。
本日の投稿は、エージェント・フレームワークについての説明と、それらがどこまで進化しているかの評価です。また、インターネット・マネー・トラック(暗号)とプロキシの交差点で働く創業者を対象とした、提案の募集でもあります。
過去1年間、Decentralised.coは暗号とAIの交差点を掘り下げてきました。私たちは、AIエージェントとエージェント・インフラを追跡するために、7万人以上に利用される製品まで構築しました。AIをめぐる熱狂はここ数週間で沈静化したが、AIはインターネット以来見られなかった方法でテクノロジーと社会に影響を与えている。私たちが予測するように、暗号通貨が未来の金融鉄道になるのであれば、AIとの絡みは一過性のものではなく、繰り返し起こるテーマになるだろう。
この波から生まれたプロジェクトのより興味深いカテゴリの1つが、暗号ネイティブAIエージェントフレームワークである。これらのプロジェクトは、ブロックチェーンの核となる原則(許可なしの価値移転、透明性、一貫したインセンティブ)をAI開発にもたらす魅力的な試みです。そのオープンソースという性質は、内部構造を覗き見し、その約束だけでなく、実際にどのように機能するのかを分析する貴重な機会を提供している。
この投稿では、エージェントフレームワークが実際に何を意味し、どれほど重要なものなのかを解剖することから始めます。そして、LangChainのような実績のある選択肢があるのに、なぜ暗号ネイティブフレームワークが必要なのかという明白な疑問に取り組みます。そのために、主要なクリプトネイティブフレームワークを分析し、様々なユースケースにおける長所と限界について説明します。最後に、もしあなたがAIエージェントを構築するのであれば、どのフレームワークがあなたのニーズに合うかを決めるお手伝いをします。あるいは、構築のためにフレームワークを使用すべきかどうかについても説明します。
それでは、本題に入りましょう。
抽象化
「文明の進歩は、その文明を発展させることにある。「文明の進歩は、考えずにできる重要な操作の数を増やすことにある。 - Alfred North Whitehead
私たちの祖先がどのように暮らしていたかを考えてみましょう。各家族は自分たちで食べ物を育て、自分たちで服を作り、自分たちでシェルターを作らなければならなかった。基本的な生存のための作業に数え切れないほどの時間を費やし、それ以外のことにはほとんど時間を割けなかった。2世紀前でさえ、人口の90%近くが農業に従事していた。今日、私たちはスーパーマーケットで食料を買い、専門家が建てた家に住み、遠くの工場で生産された服を着ている。かつては何世代もの労力を費やした仕事も、今では簡単な取引になった。現在、農業に従事しているのは世界人口のわずか27%である(先進国では5%未満に減少)。
新しい技術をマスターし始めると、おなじみのパターンが現れる。私たちはまず、何がうまくいき、何がうまくいかず、どのようなパターンが生まれ続けているのかという基本を理解することから始める。これらのパターンが明らかになれば、それをより簡単で、より速く、より信頼できる抽象化へとパッケージ化する。このような抽象化によって、より多様で有意義な課題のために時間とリソースが解放される。ソフトウェアの構築も同じです。

ウェブ開発を例にとってみましょう。初期の頃、開発者はHTTPリクエストの処理、状態の管理、UIの作成など、すべてをゼロから書かなければなりませんでした。その後、Reactのようなフレームワークが登場し、便利な抽象化機能を提供することで、これらの課題を大幅に簡素化した。モバイル開発も同様の道をたどった。React NativeやFlutterのようなツールの登場により、一度コードを書けばどこにでもデプロイできるようになるまでは、当初、開発者はプラットフォーム固有の深い知識を必要としていた。
同じような抽象化のパターンが、機械学習にも現れました。2000年代初頭、研究者たちはMLワークロードのためのGPUの可能性を発見しました。当初、開発者はグラフィックス・プリミティブやOpenGLのGLSLのような言語と格闘しなければならなかった。すべてが変わりました。
ML開発が勢いを増すにつれて、GPUプログラミングの複雑さを抽象化するための専門的なフレームワークが登場しました。 TensorFlowとPyTorchによって、開発者は基盤となるGPUコードや実装の詳細に煩わされることなく、モデルアーキテクチャに集中できるようになりました。これにより、モデル・アーキテクチャの反復が加速され、ここ数年で見られるようになったAI/MLの急速な進歩がもたらされました。
私たちは今、AIエージェント-人間のアシスタントや従業員のように、目標を達成するために決定を下し、行動を起こすことができるソフトウェアプログラム-においても同様の進化を見ています。大規模な言語モデルを「頭脳」として使用し、ウェブ検索、API呼び出し、データベースへのアクセスなど、さまざまなツールを使用してタスクを完了することができます。
エージェントをゼロから構築するには、開発者は、エージェントが問題についてどのように考えるか、どのツールをいつ使うかをどのように決定するか、それらのツールとどのように相互作用するか、初期の相互作用のコンテキストをどのように記憶するか、大きなタスクを管理しやすいステップにどのように分割するかなど、あらゆる側面に対処する複雑なコードを書かなければなりません。.これらのパターンはそれぞれ別々に対処しなければならず、重複した努力や一貫性のない結果につながります。
そこでAIエージェントフレームワークの登場です。ReactがUIの更新や状態管理の厄介な部分を処理することでWeb開発を単純化するように、これらのフレームワークはAIエージェントを構築する際の一般的な課題に対処します。それらは、エージェントを構築する方法の意思決定プロセス、異なるツールの統合、複数のインタラクションにわたるコンテキストの維持など、私たちが効果的であると発見したパターンのための、すぐに使えるコンポーネントを提供します。
フレームワークを使用することで、開発者はこれらの基本的なコンポーネントを再構築するのではなく、エージェントをユニークなものにする側面、つまり特定の機能やユースケースに集中することができます。何ヶ月もかかる代わりに、数日から数週間で複雑なAIエージェントを作成し、より簡単にさまざまなアプローチを試し、他の開発者やコミュニティによって発見されたベストプラクティスから学ぶことができます。
フレームワークの重要性をよりよく理解するために、医師が医療レポートをレビューするのを助けるエージェントを作る開発者を考えてみましょう。フレームワークがなければ、電子メールの添付ファイルを処理し、PDFからテキストを抽出し、正しいフォーマットでLLMにテキストを入力し、何が議論されたかを追跡するために対話履歴を管理し、エージェントが適切に応答することを保証するために、すべてのコードをゼロから書く必要があります。これは、特定のユースケースに特有ではないタスクのための、多くの複雑なコードです。
これらのビルディングブロックの多くは、エージェントフレームワークで使用するのが簡単です。このフレームワークは、電子メールやPDFの読み取りを処理し、医療知識のプロンプトを構築するためのパターンを提供し、会話の流れを管理し、さらに複数の交換にわたって重要な詳細を追跡するのに役立ちます。開発者は、一般的なパターンを再発明する代わりに、医療分析プロンプトの微調整や診断固有の安全性チェックの追加など、エージェントをユニークなものにする側面に集中することができます。ゼロから構築するのに数ヶ月かかったかもしれないコンテンツも、今では数日でプロトタイプを作成することができます。
LangChainはAI開発のスイスアーミーナイフとなり、LLMベースのアプリを構築するための柔軟なツールキットを提供しています。技術的にはエージェントフレームワークではないが、LLMコールの順序付けに使用されるチェーンから、コンテキストを維持するために使用されるインメモリシステムまで、ほとんどのエージェントフレームワークを構築するための基本的なビルディングブロックを提供する。その広範な統合エコシステムと豊富なドキュメントは、実用的なAIアプリケーションを構築しようとしている開発者にとって好ましい出発点となっています。
そして、CrewAIやAutoGenのようなマルチインテリジェンスフレームワークがあり、開発者は、各エージェントが独自の役割と能力を持ち、複数のAIインテリジェンスが連携するシステムを構築することができます。これらのフレームワークは、単にタスクを逐次的に実行するのではなく、対話を通じてインテリジェントな身体が協力し、一緒に問題を解決することを重視しています。

たとえば、研究論文を割り当てるとき、あるエージェントはその構造の概要を説明し、別のエージェントは関連情報を収集し、3人目は最終的な草稿にコメントや改良を加えるかもしれません。3人目は最終稿にコメントや推敲を加える。これは、AIエージェントが解決策を改善するために議論し、討論し、協力し合える仮想チームを結成するようなものだ。高レベルの目標を達成するためにこのように協力するマルチエージェントシステムは、しばしばAIエージェント「クラスタ」と呼ばれる。
AutoGPTは伝統的なフレームワークではないが、自律型AIエージェントの概念を開拓した。これは、AIがどのように高レベルの目標を持ち、それをサブタスクに分解し、最小限の人間の入力で独立して完了できるかを示しています。その限界にもかかわらず、AutoGPTは自律型エージェントの革新の波を巻き起こし、その後の、より構造化されたフレームワークの設計に影響を与えた。
しかし、なぜ暗号化なのでしょうか?
このような背景があり、最終的に暗号化ネイティブAIエージェントフレームワークの台頭につながっています。この時点で、Web2にはLangchainやCrewAIのような比較的成熟したフレームワークがあるのに、なぜWeb3には独自のフレームワークが必要なのかと疑問に思うかもしれません。確かに、開発者はこれらの既存のフレームワークを使って好きなエージェントを作ることができる。Web3をあらゆる物語に押し付けようとする業界の傾向を考えると、懐疑的になるのも無理はありません。
私たちは、Web3特有のエージェントフレームワークが存在する3つの正当な理由があると考えています。
チェーン上で動作する金融エージェント
私たちは、将来、金融取引の大部分はブロックチェーントラック上で行われると考えています。これにより、オンチェーン・データを解析し、ブロックチェーン取引を実行し、複数のプロトコルとネットワークにわたってデジタル資産を管理できるクラスのAIエージェントの必要性が加速します。裁定取引の機会を検出できる自動取引ボットから、収益戦略を実行するポートフォリオ・マネージャーまで、これらのエージェントは、ブロックチェーン機能をコア・ワークフローに深く統合することに依存しています。

レガシーWeb2フレームワークは、これらのタスクのためのネイティブコンポーネントを提供していません。スマートコントラクトと対話し、生のオンチェーンイベントを解析し、秘密鍵管理を処理するために、サードパーティのライブラリを寄せ集めなければなりません。代わりに、専用のWeb3フレームワークがこれらの機能をすぐに処理するため、開発者は低レベルのブロックチェーンの配管と格闘するよりも、エージェントのロジックと戦略に集中することができます。
ネイティブなオーケストレーションとインセンティブ
ブロックチェーンは単なるデジタル通貨ではありません。ブロックチェーンは、マルチエージェントの協調を強化する金融ツールを組み込んだ、グローバルで信頼を最小限に抑える記録システムを提供します。オフチェーンの評判やサイロ化されたデータベースに頼る代わりに、開発者は誓約、エスクロー、インセンティブプールなどのオンチェーンプリミティブを使用して、複数のAIエージェントの利益を調整することができます。
複雑なタスク(たとえば、新しいモデルを訓練するためのデータのラベル付け)を共同で行うエージェントのグループを想像してみてください。各エージェントのパフォーマンスはチェーン上で追跡でき、貢献度に応じて報酬が自動的に分配されます。ブロックチェーンベースのシステムの透明性と不変性により、公正な報酬、より強力な評判の追跡、リアルタイムで進化するインセンティブスキームが可能になります。
暗号ネイティブフレームワークは、これらの機能を明示的に埋め込むことができるため、開発者は、エージェントが他のエージェントを信頼したり支払ったりする必要があるたびに車輪を再設計することなく、スマートコントラクトを使用してインセンティブ構造を設計することができます。
初期市場における新たな機会
LangChainのようなフレームワークはすでにアイデアの共有やネットワーク効果を持っていますが、AIエージェントの分野はまだ初期段階にあります。これらのシステムの最終的な状態がどのようなものになるかは明らかではなく、市場をロックダウンする方法は1つではありません。
クリプトエコノミクスのインセンティブは、従来のSaaSやWeb2エコノミクスには完全にマッピングされない、フレームワークの構築、管理、収益化の方法について新たな可能性を開きます。この初期段階での実験は、その上に構築されたエージェントだけでなく、フレームワーク自体の新しい収益化戦略を解き放つかもしれません。
競合他社
ElizaOS は、人気のあるプロジェクト AI16Z に関連しています。AIエージェントを作成、デプロイ、管理するためのTypescriptフレームワークです。これは、開発者がユニークな個性を持つエージェントを構築し、ブロックチェーン相互作用のための柔軟なツール、マルチエージェントシステムによる容易なスケーラビリティを可能にする、Web3に適したAIエージェントオペレーティングシステムとして設計されています。
Rigは、Playgrounds Analytics Inc.によって開発されたオープンソースのAIエージェントフレームワークで、モジュール式でスケーラブルなAIエージェントを作成するためにRustプログラミング言語を使用して構築されています。AI Rig Complex (ARC)プロジェクトに関連しています。
Daydreamsは生成エージェントフレームワークで、元々はオンチェーンゲーム用の自律エージェントを作成するために作成されましたが、後にオンチェーンタスクを実行するために拡張されました。
Pippinは、BabyAGIの創設者である中島洋平氏によって開発されたAIエージェントフレームワークです。その後、汎用のフレームワークに拡張した。
ZerePyはオープンソースのPythonフレームワークで、創造的なAIとソーシャルメディアの統合に重点を置き、複数のプラットフォームとブロックチェーンに自律型エージェントを展開するように設計されています。Pippinのように、ZerepyはスタンドアローンエージェントZerebro として始まり、その後フレームワークに拡張されました。
基準
各フレームワークの強みを評価するために、AIエージェントを作りたい開発者の立場になって考えてみました。彼らは何を気にするでしょうか?私たちは、評価を3つの主要なカテゴリーに分けることが有用であると考えました:コア、機能、開発者の経験です。
フレームワークのコアは、他のすべてのエージェントが構築される土台だと考えることができます。もしコアが弱かったり、遅かったり、進化しなかったりすると、フレームワークを使用して作成されたエージェントは同じように制限されます。
Core Reasoning Loop(コア推論ループ):あらゆるエージェントフレームワークの頭脳。強力なフレームワークは、基本的な入出力フローから思考チェーンのような複雑なパターンまで、すべてをサポートします。強力な推論がなければ、エージェントは複雑なタスクを効果的に分解したり、複数の選択肢を評価して、派手なチャットボットに落とし込むことはできません。
記憶メカニズム:エージェントは、進行中の会話のための短期記憶と、永続的な知識のための長期記憶の両方が必要です。優れたフレームワークは、単に記憶するだけでなく、さまざまな情報の断片間の関係を理解し、どれを保持する価値があり、どれを忘れる価値があるのか、優先順位をつけることができます。
埋め込みとRAGサポート:現代のエージェントは、文書や市場データなどの外部知識を扱う必要があります。強力なフレームワークにより、このような情報を簡単に埋め込み、RAGを介してコンテキストから取得することができるため、基本的なモデルトレーニングのみに依存するのではなく、特定の知識に基づいて応答することができます。
パーソナリティ設定:カスタマーサービスエージェントのコミュニケーション方法(声のトーン、エチケット、パーソナリティ)を形成する能力は、ユーザーエンゲージメントにとって重要です。優れたフレームワークは、カスタマーサービスエージェントのパーソナリティがユーザーの信頼に大きな影響を与える可能性があることを認識し、これらの特徴を簡単に設定できるようにします。
複数エージェントの協調:強力なフレームワークは、構造化された対話、タスクの委任、または共有メモリシステムなど、エージェントの協調のための組み込みモードを提供します。これにより、各エージェントがユニークな能力を活用して一緒に問題を解決する、専門家のチームが生まれます。
コア機能を超えて、フレームワークの実際の実用性は、その機能と統合に大きく依存します。ツールはエージェントの実際の機能を大きく拡張します。LLM アクセスを持つエージェントは会話に参加することしかできませんが、ウェブブラウザへのアクセスを許可すれば、リアルタイムの情報を取得することができます。カレンダーAPIに接続すれば、ミーティングのスケジュールを立てることができます。それぞれの新しいツールは、エージェントの機能を飛躍的に向上させる。開発者の観点からは、ツールの数が多ければ多いほど、選択肢や実験の幅が広がります。
クリプトネイティブフレームワークの機能性を3つの次元で評価します:
AIモデルのサポートおよび機能性:この強力なフレームワークは、OpenAIのGPTファミリーからLlamaやMistralのようなオープンソースの代替まで、複数の言語のモデルとのネイティブな統合を提供します。しかし、LLMだけではありません。音声合成、ブラウザ使用、画像生成、ネイティブモデル推論などの他のAI機能をサポートすることで、エージェントの機能を大幅に拡張することができます。強力なモデルサポートは、これらのフレームワークの多くにとって必須となりつつあります。
Web3インフラストラクチャのサポート:暗号プロキシを構築するには、ブロックチェーンインフラストラクチャと深く統合する必要があります。これは、トランザクション署名用のウォレット、チェーン通信用のRPC、データアクセス用のインデクサなど、必要なWeb3コンポーネントをサポートすることを意味します。堅牢なフレームワークは、NFTマーケットプレイスやDeFiプロトコルからIDソリューションやデータ可用性レイヤーに至るまで、エコシステム全体の重要なツールやサービスと統合する必要があります。
チェーンオーバーレイ: Web3のインフラサポートがエージェントにできることを決定する一方で、チェーンオーバーレイはエージェントがどこでできるかを決定します。暗号エコシステムは分散型マルチチェーンの巨大なものへと進化しており、幅広いチェーンカバレッジの重要性が強調されています。
結局のところ、最も強力なフレームワークであっても、開発者のエクスペリエンスと同程度のものでしかありません。フレームワークはクラス最高の機能を持つことができますが、開発者がそれを効果的に使用するのに苦労すれば、広く採用されることはありません。
フレームワークが使用する言語は、誰がそのフレームワークを使って構築できるかに直接影響します。PythonはAIとデータサイエンスの両方を支配しているため、AIフレームワークとしては当然の選択です。ニッチな言語で書かれたフレームワークには独自の利点があるかもしれませんが、より広範な開発者のエコシステムから孤立してしまうかもしれません。JavaScriptはウェブ開発において偏在しているため、特にウェブ統合をターゲットとするフレームワークにとっては、もう1つの強力な候補となります。
明確で包括的なドキュメントは、新しいフレームワークを採用する開発者にとって生命線です。APIリファレンスだけではありません。強力なドキュメントには、核となる原則を説明する概念的な概要、ステップバイステップのチュートリアル、よくコメントされたサンプルコード、教育的なチュートリアル、トラブルシューティングガイド、確立されたデザインパターンなどが含まれます。
結果
次の表は、先ほど定義したパラメーターに対して各フレームワークがどの程度優れているかをまとめたものです(1~5位)。

これらの各データポイントの背後にある理由について議論することは、この記事の範囲を超えていますが、各フレームワークについて私たちの目に留まった点をいくつか紹介します。
Elizaは、このリストの中で圧倒的に成熟したフレームワークです。Elizaフレームワークは、最近のプロキシの波の中で、暗号エコシステムがAIに触れる際のシェリングポイントとなっていることを考えると、その際立った点の1つは、サポートしている機能と統合の数が非常に多いことです。

その人気の高さから、あらゆるブロックチェーンや開発ツールがこのフレームワークに統合しようと躍起になっています(現在、100近くの統合を誇っています!)。.同時に、Elizaは他のフレームワークよりも多くの開発者の活動を引きつけている。少なくとも短期的には、Elizaは非常に明確なネットワーク効果の恩恵を受けている。このフレームワークはTypeScriptで書かれており、初心者にも経験豊富な開発者にもよく使われている言語である。
エライザはまた、フレームワークを使う開発者のための豊富な教育コンテンツとチュートリアルでも際立っている。
Spore、Eliza (agent)、Pillzumiなど、Elizaフレームワークを使用したさまざまなエージェントをすでに見てきました。
Rigのアプローチは、Elizaとは根本的に異なります。強力で軽量かつ高性能なコアを備えていることが特徴だ。キュー・チェイニング(キューを順次適用する)、オーケストレーション(複数のエージェントを調整する)、条件論理、並列処理(同時に処理を実行する)など、さまざまな推論パターンをサポートしている。
しかし、Rig自体はそれほど豊富には統合されていません。その代わり、チームが「Arc Handshake」と呼ぶ別のアプローチを取っている。ここでは、ArcチームがWeb2やWeb3のさまざまな高品質チームと協力し、Rigの機能を拡張している。これらのコラボレーションには、エージェントのパーソナリティを開発するためのSoulgraphとの協力や、ブロックチェーン機能を開発するためのListenやSolana Agent Kitとの協力などがある。
それにもかかわらず、Rigには2つの欠点がある。第一に、Rustで書かれており、性能は非常に良いが、それに精通している開発者は比較的少ない。第二に、私たちは実世界のアプリケーションで限られた数のRig駆動エージェントしか見ていません(AskJimmyは例外です)。
Daydreamsを始める前、創設者のLordOfAFewはElizaフレームワークの主要な貢献者でした。daydreamsは、エージェントが長期的な目標を達成するのを助けるために、心の連鎖推論に焦点を当てているという点で、他のフレームワークとは異なります。つまり、高レベルで複雑な目標が与えられたとき、エージェントは多段階の推論を行い、様々な行動を提案し、目標達成に役立つかどうかによってそれらを受け入れたり捨てたりし、進歩を遂げるためにプロセスを継続する。これにより、Daydreamsで作成されたエージェントは真に自律的なものとなる。
このアプローチには、ゲームプロジェクトの構築における創設者たちのバックグラウンドが影響しています。ゲーム、特にオンチェーンゲームは、エージェントを訓練し、その能力をテストするための理想的な温床です。驚くなかれ、Daydreamsエージェントの初期の使用例のいくつかは、Pistols、Istarai、PonziLandのようなゲームでした。
フレームワークはまた、強力なマルチエージェントコラボレーションとオーケストレーションワークフローの実装を特徴としています。
Daydreamsと同様に、Pippinはフレームワーク ゲームの後発組です。Yoheiのビジョンの中心にあるのは、エージェントを、適切なツールにアクセスすることでインテリジェントかつ自律的に動作する「デジタルプレゼンス」にするというアイデアだ。このビジョンは、Pippinのシンプルでエレガントなコアに具現化されている。わずか数行のコードで、自律的に動作し、それ自身のためにコードを書くことさえできる複雑なエージェントを作ることができる。

このフレームワークの欠点は、ベクター埋め込みやRAGワークフローのサポートのような基本的な機能さえ欠けていることです。また、ほとんどの統合にサードパーティライブラリComposioを使用するよう開発者に促しています。これまで説明した他のフレームワークと比較すると、単に十分に成熟していないだけです。
Pippinで構築されたエージェントには、DittoとTelemafiaがあります。
Zerepyは、比較的シンプルなコア実装を持っています。設定されたタスクのセットから効果的にタスクを選択し、必要なときに実行する。しかし、ゴール駆動や思考連鎖計画のような複雑な推論パターンが欠けている。
複数のLLMへの推論呼び出しをサポートしているが、エンベッディングやRAGの実装がない。また、メモリやマルチエージェントの協調のためのプリミティブもありません。
このコア機能と統合の欠如は、Zerepyの採用に反映されています。私たちは、フレームワークを使用する実際のエージェントが稼動するのを見たことがありません。

フレームワークを使って構築する
このすべてが非常に技術的で理論的に聞こえるのであれば、私たちはそのようなことはしません。技術的で理論的に聞こえるかもしれませんが、それは仕方ありません。もっと簡単な質問は、"自分でたくさんのコードを書くことなく、これらのフレームワークを使ってどのようなエージェントを構築できるか "です。
です。
これらのフレームワークを実際に評価するために、開発者がよく作りたがる5つの一般的なタイプのエージェントを特定しました。これらは異なる複雑さのレベルを表し、各フレームワークの機能の側面をテストします。
Document Chat Agent:ドキュメントの処理、コンテキストの維持、参照の正確さ、メモリ管理など、RAGの中核となる機能をテストします。このテストは、真のドキュメント理解と単純なパターンマッチの間を行き来するフレームワークの能力を明らかにします。
チャットボット: メモリシステムと行動の一貫性を評価します。フレームワークは一貫したパーソナリティ特性を維持し、セッションからの重要な情報を記憶し、パーソナリティの設定を可能にする必要があり、本質的にステートレスチャットボットを永続的なデジタルエンティティに変換します。
オンチェーン取引ボット:リアルタイムの市場データを処理し、クロスチェーン取引を実行し、社会的センチメントを分析し、取引戦略を実装することで、外部統合をストレステストします。これにより、フレームワークが複雑なブロックチェーンインフラストラクチャとAPI接続をどのように処理するかが明らかになります。
ゲームNPC:世界がプロキシに注目し始めたのは昨年のことですが、エージェントは何十年もの間、ゲームのノンプレイヤーキャラクター(NPC)として重要な役割を果たしてきました。ゲームエージェントは、ルールベースのエージェントからLLMによって駆動されるインテリジェントエージェントに移行しつつあり、フレームワークの主要なユースケースであり続けています。ここでは、環境を理解し、シナリオについて自律的に推論し、長期的な目標を達成するエージェントの能力をテストします。
音声アシスタント:音声処理、高速応答時間、およびメッセージングプラットフォームの統合を通じて、リアルタイム処理とユーザーエクスペリエンスを評価します。これは、単純なリクエスト-レスポンス・モデルだけでなく、真にインタラクティブなアプリケーションをサポートするフレームワークの能力をテストします。
私たちは、各エージェントタイプについて、各フレームワークに5点満点のスコアを与えました。

オープンソース指標

これらのフレームワークを評価するとき、ほとんどの分析ではスターやフォークといったGitHubのメトリクスが重視されます。ここでは、これらのメトリクスがどのようなもので、フレームワークの品質をどの程度示しているのかについて簡単に説明します。
スターは人気の最も明白なシグナルとして機能します。スターは基本的に、開発者が面白いと思う、またはフォローしたいと思うプロジェクトにつけるブックマークです。スターマークの数が多いということは、広く認知され、興味を持たれているということですが、誤解を招くこともあります。プロジェクトは、技術的価値よりもむしろマーケティングによってスターマークを蓄積することがある。スターマークは、品質の指標というよりも、社会的証明だと考えてください。
フォーク数は、何人の開発者がそのコードベースのコピーを作成したかを示します。フォーク数が多いということは、開発者がそのプロジェクトを積極的に利用し、拡張しているということです。とはいえ、多くのフォークは最終的に放棄されるので、生のフォークカウントにはコンテキストが必要です。
貢献者数は、何人の異なる開発者が実際にそのプロジェクトにコードを投稿したかを明らかにします。これは通常、スターやフォークよりも意味があります。定期的な貢献者の数が健全であるということは、そのプロジェクトが活発なコミュニティによって維持・改善されていることを示しています。
私たちはさらに一歩踏み込んで、独自の指標である貢献者スコアを考案しました。私たちは、過去の他のプロジェクトへの貢献、活動の頻度、アカウントの人気度など、各開発者の公開履歴を評価し、各貢献者にスコアを割り当てます。そして、プロジェクトへのすべての貢献者を平均し、彼らが行った貢献の数によって重み付けを行います。
私たちのフレームワークにとって、これらの数字は何を意味するのでしょうか?
ほとんどの場合、スターマークの数はごくわずかです。採用の指標としては意味がない。例外はElizaで、一時はGitHubの全プロジェクトの中でトレンド1位のリポジトリとなり、すべての暗号AIのシェリングポイントとなった。さらに、0xCygaarのような有名な開発者がプロジェクトに貢献している。これはコントリビューターの数にも反映されており、他のどのプロジェクトよりも10倍多く、Elizaはコントリビューターを惹きつけている。
それに加えて、Daydreamsが私たちにとって興味深いのは、単純に開発者の質が高いからです。誇大広告の絶頂期の後に立ち上げられた後発組であるため、Elizaのネットワーク効果の恩恵は受けられませんでした。
次は何でしょうか?
あなたが開発者であるなら、少なくとも、どのフレームワークを構築するか、必要であればそれを選択するための出発点を与えられたことを願っています。それ以上に、各フレームワークのコアとなる推論と統合があなたのユースケースに適切かどうかをテストする努力をしなければなりません。これは避けられない。
傍観者の視点から見ると、これらのAIエージェントフレームワークはすべて3ヶ月未満であることを覚えておくことが重要です。(そう、もっと長く感じる)。その間に、極端な誇大宣伝から「空中の城」と呼ばれるまでになった。それがテクノロジーの本質なのだ。このようなボラティリティにもかかわらず、私たちはこのスペースが暗号における興味深く、永続的な新しい試みであると信じている。
次に重要なのは、これらのフレームワークが技術と収益化の面でどのように成熟するかです。
技術面では、フレームワークが生み出すことができる最大の利点は、エージェントがチェーン上でシームレスにやり取りできるようにすることです。これが、開発者が汎用フレームワークよりもクリプトネイティブフレームワークを選ぶ最大の理由です。さらに、プロキシとプロキシ構築技術は世界的に最先端の技術課題であり、日々新たな開発が行われている。フレームワークも進化し、これらの進歩に適応しなければなりません。
フレームワークがどのように収益化されるかは、より興味深い。
フレームワークがどのようにマネタイズされるかは、より興味深いものです。しかし、ここには多くの実験の余地があると考えている。私たちは、想像しうるあらゆるニッチに特化した何百万ものエージェントがいる未来に向かっている。彼らが効果的に連携するのを助けるツールは、取引コストから莫大な価値を得ることができる。ビルダーのためのゲートウェイとして、フレームワークは確かにその価値を獲得するのに最も適している。
同時に、フレームワークの収益化は、オープンソースプロジェクトを収益化し、歴史的に無償で感謝されることのない仕事をしてきた貢献者に報いるという問題に見せかける。もしチームが、彼らのコードの根底にある精神を保ちながら、持続可能なオープンソース経済を生み出す方法を解読することができれば、その影響はプロキシフレームワークをはるかに超えるでしょう。
これらは、私たちが今後数ヶ月で探求したいテーマです。