AIエージェントの継続的なマイナス成長は、最近爆発したMCPプロトコルが原因か？

著者: Haotian

友人の中には、#ai16zや$arcなどのWeb3 AI Agentのターゲットがマイナスに落ち続けているのは、最近爆発的に普及したMCPプロトコルが原因だと言う人もいる。一見したところ、私はちょっと混乱した。しかし、よくよく考えてみると、あるロジックがあることがわかった。既存のweb3 AI Agentの評価と価格ロジックが変わり、物語の方向性と製品の着地ルートを調整することが急務である。

1）MCP（モデルコンテキストプロトコル）は、オープンソースの標準化されたプロトコルで、あらゆる種類のAI LLM/エージェントが、プラグアンドプレイのUSBと同じように、さまざまなデータソースやツールにシームレスに接続できるように設計されています。"MCP（モデルコンテキストプロトコル）は、AI LLM/エージェントが様々なデータソースやツールにシームレスに接続できるように設計された、オープンソースで標準化されたプロトコルです。

簡単に言えば、元のAIアプリケーションの間には明らかなデータのサイロがあり、エージェント/LLMは相互運用性のために独自のAPIインターフェースを開発する必要があります。

MCPの登場は、AIアプリケーションに統一されたフレームワークを提供し、過去のデータサイロを取り除き、外部データやツールへの「動的な」アクセスの可能性を実現し、開発の複雑さと統合効率を大幅に削減します。これにより、開発の複雑さや統合効率を大幅に軽減できるほか、タスクの実行やリアルタイムのデータクエリ、クロスプラットフォームでのコラボレーションを自動化できる。そういえば、多くの人がすぐに考えたのは、これと統合されたマルチエージェントコラボレーションManusの技術革新は、マルチエージェントコラボレーションMCPオープンソースのフレームワークを促進することができる場合は、無敵ではありませんか？

その通り、Manus + MCPはweb3 AI Agentのインパクトの鍵です。

2)しかし、ManusもMCPもWeb2 LLM/Agent指向のフレームワークとプロトコルであり、中央集権化されたサーバー間のデータ相互作用とコラボレーションに対処するもので、パーミッションとアクセス制御は各サーバーノードの「能動的な」オープン性に依存しているというのは驚きです。「言い換えれば、それは単なるオープンソースツールなのです。

定義からすると、web3 AI Agentが追求している「分散サーバー、分散コラボレーション、分散インセンティブ」などの中心的な考えからは完全に逸脱しており、中央集権化されたイタリアの大砲が分散化されたバンカーを爆破できるわけがありません。

その理由は、web3 AI Agentの最初の段階があまりにも「web2指向」だからです。一方では、多くのチームがweb2のバックグラウンドから来ており、web3 Nativeのネイティブな要件を完全に理解していないという事実に起因しています。例えば、ElizaOSフレームワークは、当初は開発者が迅速にAIエージェントアプリケーションを展開するためのパッケージングフレームワークであり、正確にTwitter、Discordおよび他のプラットフォームといくつかのOpenAI、Claude、DeepSeekおよび他のAPIインタフェースの統合は、適切にメモリ、Charater一般的なフレームワークの一部をカプセル化し、開発者が迅速にAIエージェントアプリケーションを開発し、最終化するのに役立ちます。開発者がAIエージェント・アプリケーションを素早く開発し、完成させるのを助ける。しかし、もっと深刻なのは、この一連のサービス・フレームワークとweb2のオープンソース・ツールの違いは何なのか？また、差別化できる利点は何でしょうか？

ええと、利点は一連のトークノミクス・インセンティブを持つことでしょうか？そして、web2が完全に置き換えることができるフレームワークのセットで、新しいコインを配るために存在する、より多くのAIエージェントにインセンティブを与えることですか？ ひどい。このロジックで考えると、なぜManus + MCPがweb3のAIエージェントに影響を与えるのかがわかるのではないでしょうか？ウェブ3のAIエージェントのフレームワークやサービスは、ウェブ2のようなAIエージェントの迅速な開発やアプリケーションのニーズに対応するだけで、技術的なサービスや標準、差別化の優位性という点ではウェブ2の技術革新のペースに追いつくことができないため、市場や資本はウェブ3向けのAIエージェントの最後のバッチを再評価し、価格を再設定したのです。

3）そうはいっても、一般的な問題は、問題の核心を見つけたに違いない。分散システムの運用とインセンティブアーキテクチャは、web3の絶対的な差別化であるため、web3ネイティブソリューションを行うことに集中する？

例として、分散クラウドコンピューティングパワー、データ、アルゴリズム、およびその他のサービスプラットフォームを取る、表面上では、コンピューティングパワーとデータを集約する理由として、アイドルリソースのこの種のは、単に短期的な技術革新を達成するためのエンジニアリングの必要性を満たすことができないように見えるかもしれませんが、AI LLMの多数で画期的な軍拡競争のパフォーマンスに従事する集中コンピューティングパワーを綴られている、 "アイドルリソース、低コスト "に、 "低コスト"。しかし、多数のAI LLMが中央集権的なコンピューティング・パワーで性能のブレークスルーの軍拡競争を繰り広げている今、「アイドル・リソース、低コスト」というギミックを持つサービス・モデルは、当然、ウェブ2の開発者やVCグループから軽蔑されるだろう。

しかし、ウェブ2のAIエージェントが性能革新をスペルする段階を過ぎると、必然的に垂直的な応用シナリオの拡大とセグメンテーションの微調整モデルの最適化の方向を追求することになり、その時に初めてウェブ3のAIリソースサービスの利点が本当に現れることになる。実際、リソースの独占がWeb2 AI上の巨大な位置に登る方法が一定の段階に達すると、都市のアイデアに囲まれた田舎に戻ることは難しく、1つ1つ細分化されたシーンのブレークスルーは、その時点で、余剰のWeb2 AI開発者+ Web3 AIリソースは、時間の力を受け入れることです。

だから、今、web3 AIエージェントの機会空間も非常に明確です：web3 AIリソースのプラットフォームでは、web2開発者の需要の顧客のオーバーフローを持っている、web3分散アーキテクチャのセットを探索するための実行可能なソリューションとパスすることはできません。

例えば、分散型コンセンサスコラボレーションフレームワークのセットを備えています。

たとえば、オフチェーン計算＋オンチェーン状態保存というLLMの大規模なモデルを考慮した分散型コンセンサスコラボレーションフレームワークなど、適応可能なコンポーネントを多数必要とします。

1.エージェントが、スマートコントラクトの実行VMによって生成された固有のアドレスのような、検証可能なオンチェーンアイデンティティを持つことを可能にする分散DID認証システム。

2.分散型オラクル予言マシンシステムのセットは、主にオフチェーンデータの信頼できる取得と検証を担当し、以前のオラクルとは異なり、AIエージェントに適応したこの予言マシンのセットはまた、エージェントのオンチェーンデータとオフチェーン計算と意思決定を促進するために、データ収集層、意思決定とコンセンサス層、実行とフィードバック層を含む複数のエージェントアーキテクチャの組み合わせを行う必要があるかもしれません。

3.分散ストレージDAシステムのセット、AIエージェントの動作中の知識ベースの状態の不確実性、およびアドホック推論プロセスのため、LLMの背後にあるキー状態ベースと推論パスの記録のセットは、分散ストレージシステムに格納する必要があり、キー状態ベースとLLMの背後にある推論パスの記録のセットは、AIエージェントに提供する必要があります。

4.ゼロ知識証明ZKPプライバシー・コンピューティング・レイヤーのセットは、TEEタイム、FHEなどのプライバシー・コンピューティング・ソリューションにリンクすることができ、リアルタイムのプライバシー・コンピューティング+データ証明検証を実現します。

5、クロスチェーン相互運用性プロトコルのセットは、フレームワークによって定義されたMCPオープンソースプロトコルに多少似ています。相互運用性ソリューションは、エージェントの操作、配信、リレーの検証、通信スケジューリングメカニズムに適応する必要があり、エージェントの異なるチェーン間の資産の転送を完了することができ、特に、エージェントのコンテキストとPromopt、知識ベース、メモリ、およびその他の複雑な状態などを含む状態の同期の問題、