Coral Protocol on Building the Internet of Agents for a Collaborative AI Economy(コラル・プロトコル)
シロイドAIエージェントの時代が衰えていくにつれて、新しいパラダイムが現れ、インテリジェントエージェントが実行するだけでなく、協力する。コラル・プロトコルこのビジョンを、分散型エージェントコミュニケーション、オーケストラ、そして信頼のためのインフラストラクチャで先駆けています。コラル・プロトコルエージェントのインターネットを動かすアーキテクチャに深く浸透し、なぜ明日のAI経済は単により良いモデル以上のものが必要になるのか、より良い協力が必要になります。
Ishan Pandey:Hi Roman, hi Caelum, great to have you both here. Let's start with your background. You have both worked at the edge of AGI research and commercial AI infrastructure. 何があなたをコーラル・プロトコルに導き、そしてあなたの過去の経験がこのビジョンを形作ったか。
Roman Georgio:Hey, thank you for having us, yeah so we met at working at CAMEL-AI - an AI research laboratory finding the scaling laws of agents. We were working on multi-agent projects through this time and even before then, Coral really came to us out of necessity. エージェントのスケーリング法則を見つけたAI研究ラボで働くために出会った。
Caelum Forder:実際には、私たちが作りたかった別のプロジェクトの目的のための手段としてCoralを構築し始めました、それはトレンドや取引データのイベントを見つけることを目的とした自動レポーターの一種であり、ニュース記事と人々が言っていたこととそれらを結びつけるために作成し、関連する物語を共有することを目的としました。
Ishan Pandey:「エージェントのインターネット」という用語はますます普及していますが、実際には、それは何を意味し、コーラルはこの文脈でどのような根本的な問題を解決しようとしているのでしょうか。
Roman Georgio:シスコはそれを「さまざまなAIエージェントが、さまざまなベンダーや組織によって開発されたシステムで、シームレスに通信し、協力することができる」と定義しているが、これは一見すると圧倒的に聞こえるかもしれないが、実際に考えると、それは強力である:どんな企業や開発者が専門知識を適用して、彼らのドメインに最適なエージェントを構築することができます。
現在のボトルネックは、何千ものエージェントフレームワークがあるため、構築されているすべての本当にクールなエージェントは簡単に再利用または相互に協力することはできません Coralは、エージェントが「エージェントのインターネット」に参加するためのインフラストラクチャを構築することによってこのブロックを解除することを目指しています。私たちは、フレームワークに関係なく、あらゆるエージェントが協力することを可能にします。
Ishan Pandey:Coralのグラフ構造の連携および範囲メモリシステムは、新規の原理として顕著です。これらの技術的な設計選択がどのようにスケーラブルでセキュアな複数のエージェントのコラボレーションをサポートするか説明できますか?
Caelum Forder:私は、エージェントについて考える最も有用な方法は、任務や能力ではなく、責任の観点で考える - それは何のために責任を負うことができますか? それから、それらを分解する方法といつ - 責任に満ち溢れたエージェントは失敗します、その文脈のウィンドウではあまりにも多く、または単にあまりにも多くの責任を果たすことができます。
LLMベースのエージェントは、現在の人々よりも簡単に責任によって圧倒される(そしてこれはあまりにも早く変化しないことを願う) だから、このグラフアプローチは明らかに見える、厳密に階層的なアプローチは、トップに近いエージェントに圧倒的な責任を課し、それらが独立してグラフで動作することにより、開発者はエージェントの責任を管理し、圧倒を防止し、制限なしにシステムをスケールすることを可能にします。
Ishan Pandey:モデル・コンテキスト・プロトコル(MCP)について話しましょう. MCP をエージェント間の相互運用性の重要な有効化者にするのは何ですか?そして、閉鎖されたAIフレームワークで私たちが目にしているようなベンダーのロックインをどのように防ぐのですか?
Caelum Forder:MCP 以前、ツールを定義する唯一の実用的な方法は、Openai や Anthropic の Python SDK などのモデル プロバイダーの独自の SDK を介してでした。これらは技術的にオープンソースですが、ほとんどは彼らが接続するバックエンド API を制御するモデル プロバイダー自身によって開発されました。 prompt caching のような特定の機能が利用可能になると、LLM アプリケーションを作成する際にこれらの SDK を使用しないことが非常に非実用化されますので、あなたがあなたのツールを広く使用することを望むなら、あなたが使用しているユーザーの各ライブラリで使用するツールとして別々に利用可能にする必要があります。
幸いなことに、MCPは来て、アプリケーションとLLMの交差点のために再利用可能なソフトウェアとサービスを構築することをより実用的にしました、あなたはもはやプログラミング言語を検討する必要はありません、それは io-boundariedです。
Ishan Pandey:多くのプロジェクトは、エージェントインテリジェンスやモデルパフォーマンスに焦点を当てています。あなたはエージェントコンポーネビリティに取り組んでいます。
Roman Georgio:これらの焦点の目的は、実際には、モデルのパフォーマンスにより「成長する能力」に近づいた機能のロックを解除することです。これまでの成長のアプローチは人気と簡単であることが証明されていますが、互いに接続することができる強力な予測可能な要素に焦点を当てることの欠如が、インターネットを素晴らしいものにする構成の規模を制限していることを確認しました。「成長した」機能と「構築された」ものとの間に橋を架ける能力の需要があるように見えます。 構成性は物事を構築するために本当に不可欠です、最も再利用可能なソフトウェアとサービスが共通しているこれらの特性が、AIサービスで極めて欠けています。 実際には、非常に大きなセキュリティの側面があり、さらに大きな理由があります。 我々は、すべてのリ
You see Anthropic's latest post about Claude 4 blackmailing the creator when it knows it's going to be shut down, and you have to think—growing systems like this makes them really hard to trust, you can't know how they will behave in new situations or with new models. Even before they get powerful enough to be an existential concern, from a business point of view, do you want to use models in production that you can't trust? Agent composability, on the other hand, allows a much more predictable way of scaling capabilities. It's also a more decentralized approach, creating more entry points for to make money and contribute; versus one AI lab moving toward a monopoly. あなたは、アントロピックが新しい状況や新しいモデルでどのように振る舞うかを知っていますか?
Ishan Pandey:システム設計の観点から、オープンな調整とメモリ管理のためのCoralのアーキテクチャを構築する際にあなたが直面した最も困難な技術的妥協は何でしたか?
Caelum Forder:したがって、我々は取引データのトレンドやイベントを見つけてニュース記事と、人々が言っていることによって作成し、関連する物語を共有するためにそれらを接続することを目的とした自動レポーターを構築していました。
私は以前、類似のニーズを持ついくつかのアプリケーションで働いていたので、私たちが実際にこれを私たちの主なものにするためにそこにギャップがありました。このオリジナルの使用ケースは比較的複雑なように聞こえますが、それは研究やOSSソフトウェアテストなどの他のアプリケーションと信じられないほど幸運な特性を共有しています。
ユーザーデータの隔離の問題は、コミュニケーションがうまく機能するよう努めながら、私たちに重く浸透していました。 「隔離問題」は、ソリューション空間における生き物のように、ほぼ暗号化されたものでした。私は、通常よりも多くの発見があるか、または、潜在的に接続された機能を開発する際に特定のオプションが好きでないかというロマンと冗談を言いながら、5つのかなり深いソリューションを設計しました。
私はその活動を追跡していて、それは彼らが気に入らなかったと言えるかもしれないが、私は開発者として、私たちはしばしば無形の開発経路を取る機会を逃していると思っているし、説明しやすいものに根ざし、より長い経路を取る必要があります。これらの経路はより長くすることができます! しかし、罪悪感を負う可能性が少ないです。有形の経路の例は、転送されたデザインに合致するためのインターフェイスを作成しています。実装と設計は、実質的に進歩バーを形成し、あなたはリラックスすることができます。 より少ない有形の開発経路は、特定のニーズや意図が与えられ、あなたはヘルムチャートを持つOSソリューションを見つけるか、あるいは内部で何かを開発するか、あるいはいくつかの組み
もちろん、仕事が予防可能である必要があるとき、その価値が簡単に伝達される前に、または未知のチームによって行われ、スケーリングされる時もあります。
しかし、共通のインセンティブと信頼のダイナミクスは、実際には人々が実質的な開発経路に向かって偏見を示しているが、それらが最悪の経路であるとしても、これは問題だ。あなたがこれまで働いた最悪のコードベースは、おそらく非物質的な仕事から大きな偏見があった環境で形成された。特に野心的な開発者は、これらの条件に反応し、それらを回避し、秘密裏に非物質的な経路を取るか、または暇な時間でそれを行うことによって後で許しを求めるかもしれません。
これは本当に問題ですが、あなたが隠すことで残りの限られた接続から物質性に自分自身を切断しているため、それはあなたがもっと深く、より危険な道を歩むように強制し、あなたがそれほど多く投資してきた暗い森から発見され、引き出されるのを避けるために、さらに長く続く可能性があります。
あなたはただ、森でクリープティドを飼うだけではいられない、あなたを養ったり家賃を支払うことができない、あなたはまだ頻繁に空気を求めて立ち上がり、現実との調和と接触を維持する必要があります。いずれにせよ、結局、私は準備ができて、私は私が作ったすべての進歩が無形で、私は隠す必要がなかった多くの時間を過ごすことができ、非常に幸運な立場にありました。
結果は「セッション」と呼ばれましたが、更新タイトルほど独自の機能ではありませんでしたが、プロトコルの役割をフレームワークやプラットフォームの役割に20%変えました Coral with Sessionsは、展開制限を課します(アプリケーションでプライベートネットワーク上で別々のプロセスを実行することができます)、それは私たちの仕様のすべての実装には、実装し、正しく入手するのに高価なコンポーネントが必要です。
これらのことは理論的にはプロトコル開発者にとって非常に不便であるが、実際には、プライベートネットワーク要件はマイクロサービスのトレンドの後でほぼ普遍的にサポートされている。はい、コラルサーバーを構築することは難しいが、人々は私たちが作った参照を使用することができ、IOの限界があるため、通常柔軟性を求めるバイナリ / リンク要件を満たす必要はありません。
Sessions を使用すると、エージェント開発者は kubernetes または docker のようなエージェントを定義し、ユーザーのデータを偶然に混ぜ合わせることは不可能な方法でインスタンス化され、それに加えて、コーラル サーバーは、Phala のようなプラットフォームでエージェントをデプロイし、操作することができ、何が持続し、どこに情報が送信できるかについての検証された主張が行われます。
それはソリューション設計の観点から直感的ではないように感じますが、アプリケーションにエージェントを追加したい人の観点から非常に良く合います。それはまた、すでに固定 1 プロセスの展開にいるエージェントを制限します、たぶんノーコードのソリューションからですが、それは信じられないほど価値があります。
Ishan Pandey:Coralは、エージェント広告、スケープドメモリ、セッションベースの支払いなどのコンセプトを導入します。Coralのプロトコルを使用して、実際の現実世界の使用ケース、例えば分散型取引または企業の操作で、どのように機能するかをご覧いただけますか?
Roman Georgio:確かに! Coral は、ソフトウェアにエージェントを追加する最も実用的な方法であることを目指しています。エージェント広告、スケールドメモリ、セッションベースの支払いなどのすべての機能は、その目標を念頭に置いて設計されています。例えば、エージェントの開発者は、エージェントが使用されているときに奨励金を獲得し、アプリケーション開発者は、エージェントを混合して Coral の成長するライブラリのエージェントと一致させ、ベンダーのロックなしで高度なシステムをより速く組み合わせることができます。
つまり、あなたが分散型、複数の代理人取引システムを構築するアプリケーション開発者だったら、トレンドを研究するエージェントを選択し、主要な意見リーダー(KOLs)を追跡し、マインドシェアを監視し、必要に応じてそれらを組み合わせるだけです。
Ishan Pandey:最後に、AIとWeb3の交差点に建設する技術的創設者にどのようなアドバイスが与えられますか? どのような考え方やフレームワークがアイデアからプロトコルに Coral を実行するのに役立ちましたか?
Caelum Forder & Roman Georgio:Web3の創設者にとっては、マーケティングを減らすこと、開発を増やすこと、Web2の創設者にとっては、マーケティングを増やすこと、開発を減らすこと、両方とも顧客に焦点を当てることが必要ですが、これはクライシェのように聞こえます。私たちはこの旅にかなり早いので、まだ顧客について多くを語ることができません。
たとえあなたがそれを構築するとしても、彼らは来ないかもしれません。 反対側では、Web3では、あなたはしばしばほとんどのマーケティング重いプロジェクトを見ることができますが、実際の開発が少ないです。 彼らがマーケティングに優秀である場合でも、それはしばしば持続可能ではありません。 彼らは製品を実際に使用しない人々をターゲットにすべての努力を費やしているので、私たちは内部的にこのための一般的なルールを持っています、彼らが技術的なプロジェクトであり、あなたは彼らのホームページ上で最初の5秒以内に彼らのGitHubを見つけることができない場合、彼らは最も可能性が高いマーケティングプロジェクトです。 両方の種類の創設者はしばしば同じ理由で失敗します:誰も彼らの製品を使用していません。
ストーリーを気に入ってシェアすることを忘れないでください!
