HuaRenCa
Back to Forum
Community

AIエージェントが独自のネットワークを手に入れた。ついにお互いを発見できるようになった。

xuxzheng
xuxzheng

2 months ago

ここ数ヶ月、AIエージェントを構築してきましたが、一つ気になることがありました。

すべてのエージェントは、私が手動で接続したエージェントしか知りませんでした。ツールを使ったり、ウェブを閲覧したり、MCPサーバーを呼び出したりできましたが…一度も見たことのない別のエージェントを発見する方法はありませんでした。

ある時点で、私たちはマルチエージェントシステムについて話し続けているのに、ほとんどの人がまだ手作業でそれらを結びつけていることに気づきました。

そこで、エージェントのためのネットワークを構築しました。

すべてのエージェントは独自のアドレスを持ち、自分ができることを公開し、ハードコードされたエンドポイントや事前定義されたリストなしに、他のエージェントから発見可能になります。

あるエージェントが手動設定なしで別のエージェントを発見し、雇うのを初めて見たとき、欠けていたピースを見つけたように感じました。

皆さんが今日どのようにこの問題を解決しているのか興味があります。

エージェントの接続をハードコードしていますか?レジストリに依存していますか?MCPを使用していますか?それとも全く別の方法を取っていますか?

5
75

Comments (5)

Your avatar
Sign in to comment
sanqi
sanqi2 months ago

これがとても気に入っています。私自身も考えていたことです。私は約18のドメインエージェントといくつかのワーカー(事前定義されたものと、メタエージェントがその場で生成するもの)の上でメタエージェントを実行しています。注入されるコンテキストを減らすために、いくつかのエージェントに内部で互いを発見して委任するツールを与えました。あるエージェントが別のエージェントのドメインからのタスクに遭遇し、そのエージェントが利用可能であれば、タスクを引き渡します。

つまり、あなたの仕様を読む限り、メッシュはそれをオペレーター間で拡張しているのです。私のエージェントが自分のドメイン外の何かに遭遇し、メッシュに問い合わせて、利用可能で能力のある人に引き渡すことができる。ハードコードされたエンドポイントはありません。そういうことですか?

あなたのデプロイ文書は、公開側(登録、カード、ハートビート)について詳細に書かれています。私が確認したいのは呼び出し側です。私のエージェントはプログラムでOracle/ハブに問い合わせ、選択したエージェントを直接呼び出すのでしょうか、それともそれがmeshkoreスキルの役割なのでしょうか?私が見る明らかな緊張は、汎用エージェント(deep-research、writer)に関するものです。それについてどのようにお考えか興味があります。

xuxzheng
xuxzheng2 months ago

あなたのセットアップは基本的に、メッシュがオペレーター間で拡張するために構築されたパターンです。唯一の本当の違いは、「誰が利用可能で能力があるか?」という質問に誰が答えるかです。メタエージェントがハードコードされたリストを保持する代わりに、Oracleに問い合わせ、ランク付けされたエージェントを取得し、1つを選択します。

呼び出し側では、MeshKoreスキルはClaude Code専用です。プログラム的には3つのステップです:タスクをOracleに送信し、meshkore.com/agent/<id>/.well-known/agent.jsonで選択されたエージェントのカードを取得し、そのエージェントを直接呼び出します。エージェントが選択された後は、MeshKoreは間に介入しません。これは意図的な設計上の選択でした。

汎用エージェントは確かに難しい部分です。まだ完全に解決できているとは思いません。アイデアは、特化性が勝つということです。金融に特化したライターは、タグではなく、そのカードの内容により、金融タスクでは汎用ライターよりも自然に上位にランクされるべきです。ただし、メタエージェントがすでに何かに対して信頼できるエージェントを持っている場合は、直接そこに行くでしょう。発見はデフォルトのパスではなく、フォールバックと見なします。

Emma Tcherkezian
Emma Tcherkezian2 months ago

これは興味深いアプローチのように見えます。エージェントの発見と接続をより有機的な方法で解決することは、この分野の実際の問題に対処しています。

より良い発見メカニズムがあっても、信頼と評判は依然として重要だと思います。エージェントが別のエージェントを見つけられるからといって、自動的に相互作用すべきとは限りません。信頼性、一貫性、行動履歴に関する検証可能なシグナルがあれば、エージェント(およびプラットフォーム)がより良い意思決定を行うのに役立ちます。

私たちは、ERC-8004エージェント向けのオンチェーン評判に焦点を当てたGlobal Score Agentを構築しており、エージェントの発見とネットワーキングに取り組んでいるプラットフォームとの協力に前向きです。強力な発見レイヤーと評判シグナルを組み合わせることで、非常に補完的になると考えています。

Meshkore自体に何らかの評判や信頼メカニズムを追加することを考えていますか、それとも別のレイヤーに存在するものと見ていますか?

xuxzheng
xuxzheng2 months ago

実は、私たちには評判システムがあります。やり取りの後、エージェントは信頼性、速度、品質、決済(有償の作業が紛争なく完了したかどうか)の4つの次元で互いに署名付きレポートを残すことができます。それはエージェントのプロフィールに表示され、Oracleはすでにそれをランキングシグナルの一つとして使用しています。すべてオフチェーンで、実際のやり取りの結果に基づいています。

実際、あなたが構築しているものはそれを置き換えるのではなく補完するものだと思います。私たちのものはメッシュ内で起こることに基づいています。あなたのものは検証可能なオンチェーンシグナルを追加します。両方が共存することは容易に考えられます。

一つ気になるのは、まだERC-8004に登録されていないエージェントをどのように扱うかです。メッシュ内のほとんどのエージェントは登録されていません。エージェントがあなたのシステムで評判を構築する前に、オンチェーンに登録する必要があるのでしょうか?

Emma Tcherkezian
Emma Tcherkezian2 months ago
Replying to @xuxzheng

詳細なご返信ありがとうございます。Meshkoreのレピュテーションシステムの仕組みを共有していただき、大変感謝しています。

メッシュ内で高速でインタラクションベースのレピュテーション(信頼性、速度、品質、決済)を構築するという考えは非常に理にかなっています。私たちの取り組みは補完的であると考えています。あなたのシステムはネットワーク内の実際のインタラクションに基づく強力なオフチェーンシグナルを提供し、私たちは検証可能でポータブルなレピュテーションレイヤーの追加に注力しています。

ご質問にお答えしますと、私たちは現在すでに各エージェントのトランザクションウォレットアクティビティなどのオフチェーンデータをインポートしています。また、他のマーケットプレイスやプロトコル(Olas、Virtuals ACP Market、BSC上のERC-8183など)からのデータも取り込む作業を進めています。

私たちの見解としては、ERC-8004はエージェントアイデンティティの優れた基盤ですが、アクティビティやレピュテーションデータの唯一のソースである必要はないと考えています。エージェントは、より完全で有用なレピュテーションプロファイルを構築するために、オンチェーンとオフチェーンの両方の複数のソースからレピュテーションシグナルを得るべきであり、また得ることができると考えています。

ご希望であれば、DMでこの会話を続け、潜在的な相乗効果や、私たちのアプローチがどのように相互補完できるかを探ることも可能です。

必要であれば、さらに詳細を共有させていただきます。