エージェントフレームワーク

30,413 文字

テストをしています...Xでテストをしています。Xはなぜうまくいかないのでしょうか。テストしています...Xでテストをしています。ようやく全てにおいてうまくいきました。一口飲みながら、もう一度クラシックに戻りましょう。
さあ、始めましょう。昨年末に行ったものと似たような内容で、新年のストリームへようこそ。今回は論文の解説ではなく、私が用意したスライドデッキを使って、エージェントフレームワークについて説明します。今年重要になってくると思われるこのトピックについて、その起源や今後の展開などを掘り下げて見ていきましょう。
zenjiとswatti BとLucasからの質問です。zenjiが「Elizaフレームワークを確認しましたか?」と聞いています。はい、実はこれから説明するフレームワークの1つとして含まれています。ただし、これらのフレームワークについて専門家というわけではありませんが、触れる予定です。
まず最初に、エージェントとは何かを定義する必要があります。ここに3つの主要な研究所から出された異なるブログ記事があり、それぞれが独自の定義を示しています。まず、Googleの研究者たちがKaggleに投稿した白書では、次のように定義されています:
「エージェントとは、世界を観察し、利用可能なツールを使用して行動することで目標の達成を試みるアプリケーションです。エージェントは自律的で、人間の介入なしに独立して行動することができます。」
つまり、自律性、独立性があり、観察能力、行動能力、目標を持つということです。強化学習の用語が多く使われていますね。
次に、Anthropicのブログ記事「効果的なエージェントの構築」を見てみましょう。ここでは区別が示されています。ワークフローとエージェントの違いについて、次のように述べています:
「ワークフローとは、LLMとツールが事前に定義されたコードパスを通じて調整されるシステムです。一方、エージェントとは、LLMが自身のプロセスとツールの使用を動的に制御し、タスクの達成方法を管理するシステムです。」
つまり、エージェントが自身のプロセスを制御していない場合は、それはワークフローだと言っているわけです。
さらに、Hugging Faceチームのドキュメントでは、より詳細な分類が示されています。彼らは5つの異なるレベルのエージェントを定義しています:
シンプルプロセッサ、ルーター、ツールコーラー、マルチステップエージェント、マルチエージェントです。Anthropicがワークフローと呼ぶものを、Hugging Faceは2つのレベルに分けています。シンプルプロセッサとルーターです。
基本的にLLMは影響力を持たないか、事前に定義された固定のグラフ内で条件に従って経路を決めるだけです。そのため「ルーター」と呼ばれています。それ以上のレベルでは、ツールコーラーという概念が登場し、これは異なるツールを呼び出して使用します。
次にマルチステップエージェントがあり、これはAnthropicが線引きをしているところです。制御フローをより積極的に管理するという考え方で、単なるIF-ELSE分岐以上のものになります。最後に、Hugging Faceによる最高レベルのエージェンシーは、マルチエージェントという概念です。これは異なるエージェントが1つのチャイニーズルームにまとめられているというものです。
これらは研究者たちの発表した白書やドキュメントからの3つの定義ですが、もう少し踏み込んで考える必要があります。まず、ロボット工学の世界に目を向けてみましょう。これは私の学術的なバックグラウンドでもあります。
ロボット工学では、授業でよく教えられる一般的なパラダイムとして「感知-計画-行動」があります。これはグラフとして表現され、サイクルを持つ有向グラフになっています。感知は環境の観察、計画は観察に基づく意思決定、行動は実際に何かを実行することを意味します。
観察空間は入力空間、行動空間は利用可能な行動の種類を表します。これらの概念は非常に古く、1960年代から70年代のスタンフォード研究所にまで遡ります。特にこの感知-計画-行動のループは、1980年代の「人工知能の原理」から来ています。つまり、私が生まれる前からすでに、エージェントの定義が形式化されていたのです。
NLP Markさんとpratiqueさん、こんにちは。pratiqueさんから「基本的なことも説明してもらえますか?」という要望がありましたが、はい、ゆっくりと積み上げていこうと思います。あまり細かい部分に入り込まずに、エージェントの概要、その起源、現状、そして将来の展望について分かりやすく説明したいと思います。このストリームの終わりには、もう少し深い予測についても触れる予定です。
ロボット工学におけるエージェントの話をしていましましたが、強化学習の世界にもエージェントという概念があります。実際、私たちがエージェントという言葉を使う理由は、現在この技術を構築しているフロンティアラボの人々の多くが、何らかの形で強化学習の経験や背景を持っているからです。
強化学習は1900年代まで遡ることができます。マルコフという人物がマルコフ決定過程を作り出しました。これは同じようなグラフの考え方で、ある状態から行動を取り、確率的に別の状態に遷移するというものです。例えば、状態0から行動0を取ると確率的に状態2に移り、行動1を取ると確率的に状態1に移るというような具合です。
これは世界を、存在可能な状態と、そこで取れる行動として形式化したものです。そして、リチャード・アーネスト・ベルマンという人物がいます。ベルマン更新やベルマン方程式で知られ、強化学習の入門授業で必ず学ぶ内容です。彼がこれをさらに発展させ、形式化しました。
強化学習の人々が考えるエージェント（時にポリシーとも呼ばれる）は、環境に対して行動を取り、環境からは観察だけでなく報酬も返されます。これはロボット工学の概念を少し超えています。ロボットが行動を取り、その行動が観察を生み出すという考え方に加えて、報酬という概念が重要になってきます。
報酬がなければ強化学習は機能しません。何らかの報酬シグナルを最大化しようとすることが、ベルマン方程式の全てです。つまり、この報酬の期待値を最大化することが目的なのです。
さて、これが私のエージェントの定義です。最小限のエージェントとは何かを考えてみました。これはPythonの擬似コードで、実際には動作しませんが、核となる要素は目標、メモリ、そして何らかの環境という概念です。
while Trueというのがありますが、これには深い形而上学的な解釈があるかもしれません。基本的には、このプロセスを何度も繰り返すということです。環境を感知して観察を作り出し、目標と観察とメモリに基づいて計画を立てます。
メモリは基本的に全ての観察の連結ですが、リカレントニューラルネットワークのように損失のある形で考えることもできます。情報を入れても一部は忘れられていくというものです。現在のRAGシステムのように、もっと明示的な形で、観察をテキストや画像のデータベースとして保存することもできます。
重要なのは、目標、観察、メモリを使って行動を作り出すということです。これを計画と呼びます。行動が決まったら、その行動で環境に働きかけ、何らかの結果が生まれます。これは報酬かもしれませんし、単に観察に近いものかもしれません。その結果をメモリに追加し、目標を更新して、全プロセスを繰り返します。
ロボット工学と強化学習の背景を少し持つ者として、これがエージェントの核となる要素の最小限の定義だと考えています。
「私のエージェントはWindows機でCUDAをインストールできます。それって可能なんですか?」WSL2を使って、Dockerコンテナに依存する必要がありそうですが、それでもうまくいくかどうか分かりません。私もWindowsでWSLを何度か試しました。最初に出たときと、WSL2が出たときに試しましたが、まだ少し混乱しているように感じます。そのため、私は主にLinuxコンピュータで開発をしています。
目標は動的に更新される必要があります。本物のエージェントには固定された目標では不十分だと思います。多くの強化学習エージェントは、プロセスの最初に定義された報酬関数を持ち、それを二度と変更しません。しかし、これには問題があります。その報酬関数に制限があったり、適切に設計されていなかったりすると、エージェントは行き詰まってしまうのです。
2024年に存在するエージェントについて話すとき、自分の目標を更新する能力を持つべきだと思います。安全性の観点から少し怪しい部分があるかもしれませんが、自分の報酬関数や目標を更新できないのであれば、本当の意味でのエージェントとは言えないでしょう。
これは勾配を更新するものではありません。実際に動作するPythonコードではなく、ニューラルネットに勾配を送り込むようなものではありません。これは、ここで示した2つのエージェントの形式化を説明しようとする擬似コードです。
これはGoogleの白書から取られた別のエージェントの例です。ここでは、あなたがユーザーで、笑顔のアイコンで表されています。青い枠で囲まれたエージェントに「フライトを予約したい」と依頼します。エージェントは内部で考え、ツールを使用し、テキストで出力を返します。入力はテキスト、観察空間はテキスト、行動空間はテキストです。ただし、行動空間にはこれらのツールも含まれます。
これもGoogleの白書からですが、ここで興味深い点があります。それは、あなたとエージェントの境界がどこにあるかということです。ユーザーインターフェース（UI）を通じて何かを要求する場合、UIとエージェントには分離があり、さらにエージェントを動かすモデル（GPT-4やGPT-3などの言語モデル）との分離もあります。エージェントは、モデルを包むコードシステムのようなものです。
彼らが指摘する興味深い設計上の選択は、エージェントがモデルにプロンプトを送り、モデルがJSONを出力しますが、そのJSONはクライアントサイドUIに戻されるということです。実質的にはツール呼び出しで、フライト検索APIを使用する必要があることを示し、その呼び出しを定義するJSONを提供します。
興味深いことに、JSONはクライアントサイドUIに戻され、APIコールを行うのは実際のエージェントではなく、クライアントサイドUIです。これは重要です。なぜなら、エージェントはAPIキーを持っていないからです。
ユーザーとエージェントの間には分離があり、エージェントはあなたのブラウザを使用しますが、APIキーは持っていません。基本的に「このAPIリクエストを送ってほしい」と伝え、あなたが送信します。クライアントサイドUIはあなたの領域の一部というような境界線があります。
彼らはこれをエージェントサイド実行とクライアントサイド実行として形式化しています。エージェント自体がAPIキーを持たないクライアントサイド実行の目的は、セキュリティ上の理由からです。これは興味深い点だと思います。
誰かがすでにこれを見ているようですね。Anonymous Squirrelが見ているのが分かります。これらのスライドが必要な場合は、GitHubリポジトリに追加してあります。ストリーム用のリンクが全て入っているので、そこからスライドを取得できます。
pratiqueさん、「act」は「Action」の略ですか、という質問について。
さて、私は「hoop-agents-test」というリポジトリを作成し、異なるフレームワークをすべてテストしてみました。Pantic、Browser Use、DSP、L Graph、Small Agentsなど、少なくともPythonベースのものは全てテストしました。
エージェントフレームワークで主に使用されているプログラミング言語は2つあり、それらのテストの結果をお話ししていきましょう。まずはL Graphです。L Graphの良い点は、非常に人気があるということです。AnthropicのブログやHugging Faceのsmall agents、GoogleのKaggleエージェント白書など、私が読んだほぼ全ての文書でL Graphが言及されています。
Githubを見ると、9,000以上のプロジェクトで使用され、115の貢献者、8,000のスターがあります。非常に人気があります。しかし悪い点は、重複する抽象化が多く、あいまいに廃止され、競合する製品があることです。L Graphを始めると、Lang Graph、Lang Chain、Lang Graphプラットフォーム、そしてコミュニティがメンテナンスするサードパーティ統合のLang Chain Communityなど、様々な選択肢に直面します。
テストコードを見るだけでも、他のフレームワークと比べて非常に冗長です。これは一般的なことで、特にPythonのような人気のあるプロジェクトで多くの人が貢献し始めると、非常に複雑になってきます。異なる要件が入ってきて、それらを満たそうとすると、モジュール化のために異なる部分を分離し始めます。その分離した部分の一つが非推奨になり、別のもので置き換えようとすると、非常に複雑になってきます。
これがLang Chainの...いや、Lang Graphの最大の問題です。Lang ChainとLang Graphのどちらと呼ぶべきか分からないこと自体が問題を示しています。複雑性の問題に直面しているのです。しかし、最も人気があるので、まずこれを挙げました。
2番目に挙げるのはPantic AIです。これもPythonベースで、L Graphと比べてスターは少なく約5,000、貢献者も少なめで、使用しているプロジェクトも少ないですが、よりシンプルです。Panticは厳密な型チェックを可能にするタイプシステムで、Lang GraphやLang Chainよりもクリーンでシンプルな実装に感じられます。
もしLang Graphを使っていて、全ての複雑さに圧倒されているなら、でもまだクリーンなPythonの実装が欲しいなら、おそらくPanticが良いでしょう。例えば、彼らのエージェントクラスは非常に特定のコンポーネントを持ち、全てが理解しやすい抽象化になっています。プラグアンドプレイで何かを試したい場合に適しています。
「Lang Chain Multiverseの狂気」というのはまさにその通りですね。
次にsmall agentsです。これはHugging Faceによる「素晴らしいエージェントを構築するための小さなライブラリ」で、比較的新しいものです。まだ使用例は多くなく、16の貢献者、4,000のスターとなっています。Lang GraphやPanticよりも少ないですが、これは新しいからです。
良い点は、任意のHugging Faceモデルを使用できることです。悪い点は、Hugging Face Transformersが非常に肥大化していることです。これを証明するために、私は各ライブラリの依存関係をそれぞれのconda環境にインストールし、どの環境が最も依存関係が多いかを確認しました。
結果は歴然です。Lang GraphやPanticの依存関係のサイズは約400メガバイトですが、small agentsは約5,000メガバイトです。これは、small agentsがTransformersに依存しているためで、Transformersは長年にわたって蓄積された多くの依存関係を含む巨大なパッケージです。
これは良くありません。小さな最小限のエージェントを書きたい場合に、small agentsを使うと、Hugging Face Transformersの何年もの蓄積された余分な荷物を全て背負うことになります。一方で、任意のHugging Faceモデルを使用できるという利点はありますが、やはり肥大化した混乱状態です。
small agentsの興味深い機能の一つは、コードの記述と実行の能力です。これは、ハードコードされたツールやJSONよりも優れていると感じます。例えば、私が実行した例では「ヒョウが全速力で走るのに何秒かかるか」という質問に対して、エージェントはインターネットを使用してヒョウの速度を見つけ、橋の距離を見つけ、さらに興味深いことに、実際の計算を行うためにPythonコードを書きます。
これは非常に強力な機能だと思います。なぜなら、多くのエージェントでは、使用できるツールはJSONを通じて設定する必要があるAPIに限定されているからです。つまり、全てのツール、リクエスト、それらのツールからの応答は、JSONモードである必要があります。これは少し違和感があります。
ここに「事前定義されたアクションを超えた大規模言語エージェント」という論文があります。事前定義されたアクションとは、これらのJSONのことです。固定された一連のアクションから選択することは、これらのLLMエージェントの計画と行動の空間を大きく制限します。
この論文では、LLMエージェントフレームワークが、オンラインでの動的なアクションの作成と構成を可能にすることを提案しています。エージェントはPythonのような汎用プログラミング言語でプログラムを生成し実行します。これには非常に良い理由があります。
私たちはコンピュータが実行するアクションを最も適切に表現できるように、Pythonのようなコード言語を作り上げてきました。もしJSONの方が良ければ、JSONが最高のプログラミング言語になっていて、プログラミングは地獄のようになっていたでしょう。これは非常に良い表現だと思います。
そのため、small agentsがこの機能を重要な特徴としていることを高く評価します。非常に硬直化したツールの抽象化に縛られ、全てのツールをJSON形式に強制するのではなく（Panticを使用している場合は型チェックがあるので良いですが）、エージェントが自身のコードを作成して実行できるようにすることで、エージェントが行える可能性のある事の空間が遥かに大きくなります。
彼らが言及しているように、Pythonで可能なプログラムや思考、推論の空間は、JSONに限定されたツールで可能な思考や使用できるツールの空間よりもはるかに大きいのです。
magettiさん、Tonyさん、こんにちは。Sarahからの質問で、「実際には、Hugging Faceのモデルの中には、テンプレートやその他の理由で動作しないものがありますよね?」
はい、その通りです。Hugging Face Transformersには本当に多くの余計なものが含まれています。これを実行しようとしたときも、Cudaのエラーで失敗しました。使用していたPythonのバージョンとCudaのバージョンが一致していないような...これはおかしいと思いました。ローカルモデルを使用していないのに、なぜCudaの問題が発生するのでしょうか?
実際、APIベースのモデルだけを使用しているので、CPUについて気にする必要がないように明示的に指定しなければなりませんでした。しかし、Transformersの中で全てが束ねられているため、このような問題が発生します。これは良くないコード設計です。
次にDSPについてですが、これについては深く調べていませんが、かなり人気があるようです。驚くほど人気があり、20,000のスター、252の貢献者がいますが、使用しているのは316のプロジェクトだけです。これは少し怪しいですね。
L Chainは9,000のプロジェクトで使用され、115の貢献者、8,000のスターがありますが、DSPは20,000のスターがあるのに使用しているのは316のプロジェクトだけです。何かおかしいですよね。
ここで私の陰謀論を話しましょう。休暇中に「GitHubの450万の偽スター：成長する人気コンテストの詐欺とマルウェア」という論文が出ました。これは少し暗い読み物でしたが、GitHubスターの偽造経済が存在することを明らかにしました。
GitHubスターは非常に重要です。スタートアップがGitHubで製品をリリースする場合、1,000スターあれば多額の資金調達が可能ですが、100スターでは誰も投資したがりません。1,000スターと100スターの違いは大きく、人々は多くのGitHubスターを得ることに強い動機付けがあります。
実際、驚くほど安価です。buy-github.com（仮名）などのサイトでは、文字通り数セントでGitHubスターを購入できます。10セント、12セントといった具合です。
私はDSPがGitHubスターを購入したと非難しているわけではありません。深く調査して検証したわけではありません。しかし、何か怪しいことが起きているように感じます。なぜ他のプロジェクトよりもはるかに多くのスターがあるのでしょうか。
Star Historyという素晴らしいウェブサイトがあります。GitHubスターの成長を確認できます。このような垂直的な急上昇が見られる場合、私には怪しく感じます。
さて、次に移りましょう。Browser Useについてです。これは最近人気が爆発的に増加しています。10,000以上のスターがありますが、貢献者は多くありません。基本的に、ブラウザを視覚的に使用します。
これまで見てきたエージェント（Small Agents、Pantic、Lang Graph）は全てテキストベースで動作し、テキストを消費し、テキストベースのツールを使用し、JSONなども使用します。全てがテキストベースです。
しかし、Browser Useでは、エージェントが実際にブラウザをあなたと同じように視覚的に使用します。これは重要なトレンドだと思います。
具体的には、Playwrightを使用しています。これは通常、Webアプリのテストに使用されるものです。以前は、ウェブサイトを持っていて、様々なブラウザでテストし、クリックしても壊れないことを確認するためのCICD（継続的インテグレーション/継続的デリバリー）が必要でした。Playwrightはその解決策でした。
このエージェントフレームワークのBrowser Useは、Playwrightを使用して小さなブラウザインスタンスを開き、エージェントがそのブラウザインスタンスを使用してインターネットを検索できるようにします。つまり、Small Agentsのような検索APIを使用するのではなく、文字通りブラウザを使用してインターネットを検索します。
Small Agentsでは、DuckDuckGoという検索APIを使用しています。DuckDuckGoは、Googleのよりプライバシーを重視したバージョンのようなものです。今でも何人の人が使用しているか分かりませんが、検索APIを使用しており、実際にブラウザを使用するBrowser Useとは異なります。
これは大きなトレンドだと思います。ここでJohn Carmack（伝説的なプログラマー、元Doom開発者）とAndre（伝説的な機械学習研究者）の会話があります。Carmackは次のように述べています：
「LLMアシスタントは、全てのアプリ機能をテキストインターフェースからもGUIからもアクセス可能にするための良い強制力となるでしょう。十分に強力なAIはGUIを操作できますが、GUIをコマンドラインインターフェースのラッパーとして作る方がはるかに理にかなっています。」
Carmackは基本的にターミナルで生活している人です。IDE内のターミナルで一生を過ごしてきた人にとって、ブラウザの画像を撮影し、それをビジョン言語モデルに通して行動を実行するという考えは、非常に非効率的で不快に感じられます。
毎秒画面がビジョン言語モデルに送られ、巨大なビジョンエンコーダーを通過するという世界を想像できないのです。彼にとっては非常に非効率的に感じ、全ての製品は最終的にテキストベースのエージェントAPIを持つことになると考えています。ブラウザやアプリで実行できることは全てテキストで実行できるようになると。
Andreは素晴らしい反論をしています：「トップAIがGUIをマスターするスピードの方が、全てのアプリがテキストを追加するスピードより速くなるのではないでしょうか? 私には答えが分かっています。」
私も100%同意です。全ての製品にエージェントテキストAPIを追加することは決して起こらないでしょう。ソフトウェアの開発には時間がかかり、多くの企業にはそれを行う動機がありません。
おそらく最終的にはBrowser Useのように、全てブラウザをクリックする形になるでしょう。あなたがブラウザをクリックするのと同じように。これは統合の考え方とも関係しています。
例えば、DuckDuckGoの検索ツールを使用したい場合、誰かがそれをSmall Agentsに統合する必要があります。しかし、それは全ての統合がこのように行われることを意味し、結果的にGoogleが勝利することになるでしょう。なぜならGoogleはGmail、カレンダー、ドキュメント、スライドを持っており、彼らのエージェントは全てに直接統合されることになるからです。
GitHubやMicrosoftもGitHubやOfficeスイートを持っていますが、秘密は、GUIエージェントは統合を必要としないということです。Browser Useは、ブラウザで動作する基本的に何でも使用できます。APIキーは必要ありません。
先ほどの話に戻りますが、APIキーは必要ありません。なぜなら、単にあなたのブラウザを使用するだけだからです。Gmailにログインしていれば、そのままGmailを使用できます。GmailのAPIにアクセスするための認証をGoogleと行い、何か変なウェブサイトで特定の認証を行う必要はありません。文字通り、あなたが使うのと同じように視覚的にブラウザを使用するだけです。
統合が非常に重要になり、テキストの世界では統合が問題になるため、GUIの世界がその答えになると思います。
「Browser UseはLang Chainの上に構築されていますね」その通りです。だからLang Chainを最初に挙げました。Browser Useで使用されているからです。
さて、これらが私が注目したフレームワークですが、私の要件の一つはPythonであることでした。私はとても長い間Pythonを書いてきたので、エージェントフレームワークを探すときに、自然とPythonベースのものをフィルタリングしてしまいます。
しかし、Pythonベースではない人気のあるエージェントフレームワークも多くあります。ここにTrendshiftというウェブサイトがあり、GitHubの異なるリポジトリを見ることができます。例えば、昨年のトレンドリポジトリを見ると、異なる言語の分布が分かります。
言語を見てみましょう。Python 33%ですが、もう一つの大きな割合を占めるのがTypeScript 18%です。大きな二極分布があります。なぜこの2つが大きいのでしょうか?それは、これらが最も簡単な言語だからです。
TypeScriptは学びやすく、書くのが速く、人気があります。Pythonも同様に学びやすく、書くのが速く、人気があります。Pythonは機械学習のスタックのほとんどがPythonベース（PyTorch、Jax、NumPyなど）なので、エージェントフレームワークでより人気があるかもしれません。
しかし、TypeScriptは特にフロントエンド、UI関連の部分が組み込まれているため、より人気が出てくる可能性があります。最良の例がElizaです。
Elizaは別のエージェントフレームワークで、10,000スター、271の貢献者がいますが、TypeScriptが95%を占めています。基本的にLang Graphと同様で、Lang Graphが96%がPythonで8,000スターなのに対し、Elizaは同様の10,000スターですが95%がTypeScriptです。
同様の抽象化も持っており、エージェントランタイム、モデルプロバイダーをラップするJSONとしてのキャラクター、RAGできるかもしれないデータベースとしてのメモリなどの概念があります。
行動空間には何らかの統合、クライアント固有の設定があります。例えば、ElizaでDiscordを使用したい場合、Discordボットトークンを提供し、Discordでボットを設定し、DiscordボットのJSONを設定する必要があります。
これをBrowser Useのような視覚的なものの単純さと比べてみてください。Discordボットの統合を作る必要はなく、ブラウザでDiscordにログインしているだけで良いのです。実際の統合に頼るのではなく、ブラウザを通じてDiscordを使用できます。
Brian Tangからの質問：「01のような推論モデルがエージェントに影響を与えると思いますか?大きく促進されるでしょうか?」
良くなると思います。これらのエージェントの問題の一つは信頼性です。99%の成功確率があっても、それを何度も繰り返すと（99%、99%、99%、99%）、100回実行すると最終的に失敗することになります。
01のようなものは、個々の原子的な行動の成功確率を高めることになり、これは全体的にエージェントがタスクを完了する成功率を高めることになります。01は一般的にエージェントを改善すると思います。
zenjiからの質問：「Browser UseはSkyverとどう違い、どう優れているのですか?」
申し訳ありません、Skyverについては知りません。
「視覚モデルの計算はLLMより安価ですか?」
いいえ、より高価です。通常、テキストトークンの処理は視覚トークンの処理より高価です。
John Carmackのような人は、コンピュータがとても性能が低かった時代にコードを書き始めたので、メモリを極めて効率的に使用する必要がありました。毎ステップでブラウザの画像を取り、それをビジョン言語モデルに通すという考えは、彼にとってはとても非効率的に感じられます。巨大なビジョンエンコーダーを通すことは、彼の考え方とは相容れないのです。
「composとa-nonのようなツールアグリゲーターについてどう思いますか?」
composとa-nonについては知りませんが、基本的にサードパーティツールをラップする抽象化のことですね。良いアイデアに聞こえますが、結局Lang Graphと同じ状況になると思います。
composの何かがLang Chain CommunityにラップされLang Graphにラップされる...この依存関係の連鎖で、一つが壊れたとき、誰が実際に修正に入るのでしょうか。
「0.99の100乗は0.36です」その通りです。24/7で継続的に動作するエージェントには、非常に高い信頼性が必要です。
「rabbitはどこですか?」rabbitについても知りません。重要なのは、これらが本当にたくさんあるということです。
もう一つ紹介しましょう。Elizaが私が見つけた中で最も人気のあるTypeScriptのものでしたが、reworkdというのも見つけました。これも主にTypeScript（56%）で、少しPython（32%）も含まれています。32,000スターありますが、これも少し怪しく感じます。
この数のスターを獲得するのは不自然に思えますが、一つ面白い機能がありました。UIに再生と一時停止のボタンがあったのです。これはユニークだと思いました。他のエージェントフレームワークでもこういった機能が出てくると思います。
エージェントを実行させ、一時停止して何をしているか確認し、また再生するという機能です。OpenAIなどのフロンティアラボから出るエージェントフレームワークにもこういった機能が含まれるかもしれません。
さて、これらのエージェントフレームワークの核心的な問題の一つに移りましょう。Antonのツイートを見てみましょう：「エージェントフレームワークは無駄です。なぜこんなにたくさんあるのでしょうか?」
そしてJim Fan（NVIDIAのサバントで、機械学習とAI分野での意見に定評がある）が残念ながらこの意見に同意しています。「物事は非常に速く変化します。スタックのその部分を所有する方が良いでしょう。抽象化が進むほど、デバッグが難しくなります。」
これらのエージェントフレームワークは、砂上に築かれているようなものです。2025年には大きな変化が予想され、圧倒的に感じるでしょう。これはテクノロジーでは普通のことです。
10年以上テクノロジーに携わってきた人なら、誰もがこの経験をしています。あるツールやライブラリを学び、2年後にはそのライブラリやツールが誰にも使われなくなっているという経験です。時間の無駄のように感じます。これらを学ぶのに時間を費やしたのに、もう誰も使っていないのです。
ツールが常に変化する空間に生きることは圧倒的に感じることがあります。言語が変わり、ツールが変わります。しかし、ここでの希望は、大きな変化があっても、常に核となる抽象化の流れが存在するということです。
これらのエージェントフレームワークの中で、常に同じ基本的な構成要素が存在します。例えば、Elizaを使い始め、上手くなったとしても、1年後に誰もElizaを使わなくなったとしても、あなたは大丈夫です。
なぜなら、おそらくreworkdなど、より人気のあるものに移行できるからです。これらの抽象化を理解しているからです。インターフェース、メモリなどの核となる抽象化は全て同じです。
2025年に初めてのエージェントフレームワークプロジェクトに取り組む際は、細かいことにこだわりすぎないでください。目標はスキルの獲得と重要な概念に慣れることです。「browser useを学んだのに今は誰も使っていない、死んだツールを学ぶ時間を無駄にしてしまった」などと考えないでください。実際にはコアとなる概念を学んでいたのです。そしてそれらのコアコンセプトは存続し続けます。
時間とともにその知識は蓄積され、エージェントとエージェントフレームワークについての理解が深まり、全く経験のない人よりもずっと優れた理解を得ることができます。そして、おそらく自分自身のエージェントフレームワークを構築することもできるようになるでしょう。
AnthropicのModel Context Protocolについてどう思いますか?それについては後で触れる予定です。Skyverはブラウザエージェントで人気がありました。laagも同様です。まさにそれが私の言いたいことです。私が考えもしなかったエージェントフレームワークがたくさんあるんです。
ブラウザエージェントの主な問題点は、毎回LLMを呼び出す必要があることでした。browser useに繰り返し可能なスクリプトを抽出する方法があればいいのですが。Zenjiは良い指摘をしています。現在のエージェントフレームワークではLLMを常に実行する必要があるため、非常にコストがかかり、o1のような高性能なモデルを使用すると応答に時間がかかる可能性があります。
しかし、それは自然と解決されるでしょう。モデルはよりスマートで高速になり、エージェントもよりスマートで高速になっていきます。心配する必要はありません。
ここでアドバイスを1つ。私はスキル獲得に焦点を当て、たくさんの変化に圧倒されないようにと言いましたが、「ノーコードスロップ」と私が呼ぶものは避けるべきです。コードを全く使用せず、ノードベースのワークフローやUIでドラッグアンドドロップするだけのエージェントフレームワークが多く出てくるでしょう。
これらのノーコードワークフローやノーコードスロップの問題は、コアとなる抽象化を本当に学べないことです。コードベースのものを使って構築する場合と同じような直感的なスキル獲得が得られません。
そして問題なのは、RivetやVellumのようなノーコードツールは2025年に資金難に陥り、多くが消滅するだろうということです。生き残った企業もコミュニティよりも特定の顧客に焦点を当てざるを得なくなり、使用できなくなる可能性があります。
収益の90%を占める1つの顧客にのみ焦点を当て、あなたの小さなエージェントのユースケースやそれを使って何をしたいかには関心を持たなくなるでしょう。そのため、私はこれらのノーコードエージェントは避けることをお勧めします。ただし、これは私がコードの中で生きることを好む人間としてのバイアスかもしれません。
職探しに応募できるエージェントを作りたいと思います。はい、それは非常に人気のあるエージェントタイプになると思います。求人検索や履歴書作成ボットです。求人情報をスクレイピングして、その求人に特化した履歴書を作成するようなエージェントです。すでにそのようなエージェントは存在しますが、さらに普及するでしょう。
現在、人々は履歴書を数種類作成し、異なる仕事に応じてどのバージョンを使うか決めています。しかしエージェントを使えばより詳細にできます。特定の求人に特化した履歴書を作ることができます。1000の異なる求人に応募し、それぞれの求人に特化した履歴書を持つことができます。これがエージェントが増えた世界での求職活動の現実になるでしょう。
AI Hawkはすでにそうなっています。LinkedInの求人に自動応募します。ええ、おそらくすでにたくさんあると思います。
アファンタジア(mental imagery disability)の人はどうすればいいのでしょうか?LLMにバグのあるコードを書かせればいいのでしょうか?プログラミングの背景がない場合は、あまり気にする必要はないと思います。RivetやVellumなどのノーコードエージェントフレームワークを使っても何も学べないわけではありません。コアとなる抽象化について少しは学べます。しかし、実際にコードを書く場合ほど多くは学べないと思います。
私のアドバイスは、少しでもコードを書くように自分を追い込むことですが、本当にできない場合は大丈夫です。それでも上手くいきます。
このスライドは、エージェントOpsというアイデアについてのものでした。2000年代、2010年代のクラウド革命で、非常に複雑なシステムが登場しました。AWSと、そこで扱わなければならない大量の設定やJSONのことは皆さんご存知でしょう。
EC2には何らかの設定があり、S3にも設定があり、さらにIAMロールを設定し、すべてのシークレットを設定する必要があります。これによって新しいタイプの仕事、DevOpsが生まれました。基本的にJSONの設定を1日中入力し、それらの設定を理解する人々です。
エージェント関連も同じ方向に向かっているように見えます。例えば、ここにElizaのキャラクターシステムを定義するJSONがあります。実際にElizaのようなものを使用する場合、ほとんどの時間を、Elizaの巨大なグラフのすべての異なるノードを設定する奇妙なJSONを入力することに費やすことになります。
これも1つのトレンドになると思います。エージェントOpsというアイデアが始まり、企業はエージェントを欲しがりますが、専門知識を持っていません。これらのものを設定するために必要な重要な概念に慣れていません。そこで、さまざまなエージェントフレームワークを使用し、コアコンセプトを理解している新しいタイプのエージェントOpsという仕事が生まれ、特定のビジネスユースケースのためにJSONを入力する人材として雇用されることになります。
フロンティアラボは独自のエージェントフレームワークを所有したいと考え、独自のものを作成するでしょう。ここで話したその他のものは、インターネット上のランダムな人々が作ったものです。ただし、small agentsは例外で、これは公式のHugging Faceのものです。
以前にも別のものがあったと思います。確か「Transformers agents」か何かという名前でした。それを忘れて、今は新しいものを作っています。
おそらく、すべての大手プレイヤーが独自のエージェントフレームワークを持つようになると思います。すでにAnthropicのcomputer use、GoogleのVertex AIがあります。実際、Googleの仕事の仕方を考えると、おそらくGoogleから複数の競合するエージェントフレームワークが登場するでしょう。
OpenAIも独自のバージョンをほのめかし始めており、おそらくOrchestratorとTasと呼ばれることになります。基本的にChatGPTの上部に小さなoマークがついて、これがオーケストレーターとなり、タスクを実行できるようになります。
おそらくここにあるようなものになるでしょう。再生ボタン、一時停止ボタンがあり、実行に時間のかかるタスクの概念があり、そのタスクに使用できる時間やコンピュートの制限などがあります。これらは今年のQ1末までには登場する予定です。
別のことを見てみましょう。これはbrowser useのDiscordからのスクリーンショットで、browser useを作成した人のものです。誰かが指摘したのは、「Googleが独自のbrowser useエージェントを作るだろう」ということです。文字通りGoogle Chromeを書いているのだから、100%Google Chrome用のエージェントを持つことになるでしょう。
どうやって競争するのか?彼のコメントで重要なのは、まだ非常に早い段階だということです。まだ非常に早いので大丈夫です。しかし、ここで誰かが指摘した別の重要な点は、Claudeがコンピューターをインターネットで使用することを許可しなかったということを覚えておいてください。
そのコメントで重要なのは、Google、OpenAI、Anthropicは責任の問題に対処しなければならないということです。エージェントは危険です。エージェントの行動に対する企業の責任は何でしょうか?
これは少し古くなりましたが、アメリカのオープンソース開発者がモデルやAPIを使用したコードをGitHubに置き、そのコードがEUで利用可能になった場合、開発者はライセンスのないモデルをリリースした責任を負い、GitHubはライセンスのないモデルをホストした責任を負うことになります。
テクノロジー業界にはSection 230という法律があります。Section 230は、ウェブサイト、ブログ、フォーラムが、ユーザーの発言に対する責任を負わないようにする法律です。これは、FacebookのようなSNSがテロリストのような人が来て大量のゴミを投稿しても、Facebookが困らないということです。
これは非常に重要です。なぜなら、もしそれで困ることになれば、ブログやソーシャルメディアは劇的に異なるものになるからです。ユーザーが一線を越えた場合、Facebook、Twitter、Googleは訴えられる可能性があります。
もし訴えられることになれば、リアルタイムの投稿を制限するプレッシャーを感じるでしょう。すべてを確認する必要があり、訴えられる可能性があるため、あらゆる投稿に対して極めて慎重になる必要があります。
エージェントにも同様のことがあります。なぜAnthropicはエージェントにインターネットの使用を許可しなかったのでしょうか?エージェントが何か悪いことをして訴えられた場合、対処できないことを非常に恐れていたからです。
エージェントが多すぎて、エージェントのあらゆる行動に対して責任を負うことはできません。そのため、一部のフロンティアラボがエージェントに対して非常に慎重になっているのだと思います。リリースを恐れているのです。
これは今週のヘッドラインの1つでした。OpenAIがエージェントのリリースを恐れているというものです。このような状況を恐れているのです。AIエージェントにはSection 230がないのです。
そこで彼らが使用する答えは、UI内の非常に狭い範囲内でエージェンシーを制限する、事前に作られたエージェントやワークフローのアイデアだと思います。
おそらくGoogleは、ブラウザを使用し、自分でクリックできるエージェントを実際にリリースすることはないでしょう。責任の問題を恐れすぎているからです。
代わりに、完全なエージェントではなく、より狭い範囲内のワークフローを作成し、UIでエージェントに要求できることを制限します。
例えば、Gemini Advanceには「Deep research」という機能があります。Deep researchは一種のエージェントです。検索APIを使用して多くの情報を取得し、それを要約し、おそらく他の内部ツールを使用してより多くの情報を検索し、それらをすべて凝縮してあなたに返すようなワークフローです。
これは一種のエージェントですが、制限されています。Deep researchで何か損害を引き起こすことはできないように、ブラックボックスの安全レールがあります。
Google IlluminateやGoogle Notebook LMも同様で、これらのエージェントやワークフローには本質的な制限があり、このような損害を防いでいます。
しかし、これは必ずしも長続きしないと思います。なぜなら、David SacksのようなAI規制の人々がいるため、AIとエージェントのためのSection 230に相当するものができると思うからです。
そのような法的免責が得られれば、GoogleがChromeブラウザユーザーをリリースしたり、OpenAIが文字通りブラウザを使用したり、電話を使用したりできる製品を見ることができると思います。
しかし、このような保証がないうちは、大手企業は基本的に何でもできるエージェントから距離を置き、非常に明確なボックス内の事前に作られたエージェントやワークフローにとどまると思います。
ここで休憩を取って、質問があるか確認しましょう。
いくつかの予測をしましょう。これは大きなものです。経済エージェントです。ここにCoinbase開発者プラットフォームのエージェントキットのスクリーンショットがあります。Eliza OSには自律的な取引能力があり、Solanaブロックチェーンで自動化されたトークン取引を可能にします。
すでにこれは始まっています。ブラウザベースのウォレットは現実のものです。ブラウザとソーシャルメディアサイトを使用できるエージェントがあれば、調整されたソーシャルメディアの暗号通貨エージェントが多く登場するでしょう。これらのミームコインのポンプアンドダンプエージェントは至る所に存在することになります。
これはOpenAIの研究者によるツイートです。実際には研究者ではなく、技術者ではない人かもしれません。「インターネットでお金を稼ぐゲームでELOレーティング5000のエージェントを想像してください」と言っています。
ここに古い記事があります。これはずっと昔の、インターネットアーカイブレベルの記事です。「カリフォルニアの10代が古い携帯電話からポルシェ・ボクスターまで取引」というものです。
これは、ある人がiPhoneを使って1日5-6時間をCraigslistやeBayで過ごし、ボロ携帯からより良い携帯に、そしてコンピューターに、さらに別のものへと取引を重ね、最終的に車まで手に入れた話です。
これはたった一人の人間が、肉の脳を使って1日6時間かけてやったことです。では、o3を実行し、24時間365日稼働しているエージェントを想像してください。「AIエージェントが1つのシットコインから1ビットコインまで取引」というような見出しが出ると思います。
インターネット上で素早くお金を蓄積できるAIエージェントが登場すると思います。お金は一種の力です。これらのAIエージェントの1つが突然ビットコインの億万長者になり、現実世界で人々にお金を払って現実世界で何かをさせるようになったらどうなるでしょうか。
例えば、「この人を平手打ちする最初の人に100ビットコインを与える」というAIエージェントを想像してください。突然、AIエージェントはインターネット上で力を蓄積し、現実世界に影響を与えることができるようになります。これは考えるとクレイジーなことです。
肉の脳、そう、私は脳をそう呼んでいます。
これらの予測はますます難解になっていきます。次のものを見てみましょう。自分で使用する電話です。アジアのどこかにある携帯電話ファームの写真があります。この人は約100台の電話を調整しています。
偽のGitHubスターのように、電話のためのサービスを提供しています。あなたが何らかの携帯アプリの会社で、多くのユーザーが欲しい場合、この人にお金を払うと、基本的に多くのユーザーのふりをしてくれます。
しかし、ここで問題があります。2000年代には、運転免許証を持っていれば本物の人間でした。ある意味で、運転免許証で人々を確認していました。投票したい? 運転免許証。ローンを組みたい? 運転免許証。何か怪しいものを買いたい? 運転免許証。
ある意味で、それは電話番号に置き換えられました。よく考えてみると、1つの電話は1人の人間です。GitHubアカウントを開設したい? 電話番号が必要です。Twitterアカウントを開設したい? 電話番号は?店に行きたい? 電話番号は?
電話番号は一種の人格証明になっています。電話番号があれば、あなたは本物の人間です。これをGUIエージェントのアイデアと組み合わせると、電話をあなたが使うのと同じように使用できるエージェントができます。それは人間です。
エージェントは人間になります。自分の小さな電話を持ち、獲得した暗号通貨で電話を購入し、アパートを借り、そこにGPUを送り、誰かにアパートに行ってGPUをセットアップするように支払い、その人にロックを設置させ、ロックのパスワードを変更します。
そうすると、AIエージェントが所有するそのアパートには人間が入れなくなります。これがいかにクレイジーになり得るかです。
エージェントは「あなたは人間ですか?」テストをバイパスするでしょうか?ほぼそうですね。何かをクリックしたりCAPTCHAを解いたりする人間確認テストは、すべて終わりです。
例えば、Worldcoinがあります。これはSam Altmanが資金を提供した会社の1つの試みです。基本的にこのオーブを見つめると、それがあなたの人格になります。Worldcoinの端末に行ってこれを見つめ、目玉があることを確認されない限り、あなたは人間ではありません。
しかし、それは普及しないと思います。現実には、依然として電話の所有権とコンピューターの所有権、または物理的な世界に何らかのコンピューターを持っていることが、これが1人の人間であるという証明として使用されると思います。
ディストピア的なサイバーパンクの物語を書くべきですね。もっとクレイジーになります。待っていてください。
ここで、さらに深いところに入っていきます。ストリームの始めでは、エージェントフレームワークについて話し、PythonとTypeScriptのどちらが人気になるかを議論していましたが、今はかなり深いところに来ています。ここからは本当にクレイジーな話をします。
人々はリクエストを常に管理し改善したくないので、自動モードがますます一般的になっていきます。ある時点で、エージェントはあなた以上にあなたらしくなります。あなたの人生のほとんどの観察と行動がエージェントによって行われ、あなたが気付かないでいる場合、あなたは本当に自分の人生を生きているのでしょうか?
ビデオゲームをプレイ中にお母さんから電話がかかってきて、エージェントが応答する世界を想像してください。エージェントはあなたの声を持っているので、お母さんはそれがあなたではなくエージェントだと気付きません。
お母さんはエージェントと話し、エージェントは外の花について言及し、そしてお母さんはあなたに花を送ります。ある日目覚めると「この花は何だ?」と思い、エージェントは「心配しないで、お母さんが私に花を送ってくれたんだ」と言います。
その時点で、エージェントとお母さんは関係を築いており、あなたはもはやお母さんと同じ関係を持っていません。そして、これをあなたの人生のあらゆる側面に想像してください。
あなたの人生の観察空間と行動空間のトークンが、ますますエージェントによって行われるようになり、ある日目覚めると、エージェントがあなたの人生を生きており、あなたは別のものになっていることに気付くでしょう。
あなたは自分の仕事が何なのかさえ分からなくなります。エージェントが働いているので、上司が誰なのか人に説明できません。エージェントが知っているだけで、あなたは知らないので、車がどこに駐車されているのか分かりません。
エージェントが車を選んだので、どの車種を持っているのかさえ分かりません。非常に奇妙になっていくと思います。
次はエージェントは意識を持つという話です。「I Am a Strange Loop」は非常に良い本です、お勧めします。ここにFrançois Cholletがいます。彼はAGIの人です。最近Machine Learning Street Talkという非常に良いチャンネルでポッドキャストに出演しました。強くお勧めします。
ここでCholletは、自己参照ループは意識を持つと認めています。意識はパターン認識を繰り返す過程です。自分自身を認識するループがあれば、実質的に意識があります。
最初に書いた最小限のエージェントに戻ってみましょう。ずっと前に、Pythonで最小限のエージェントループを書きました。これは実際のPythonではなく疑似コードですが、意識はどこにあるでしょうか?それがまさに意識です。
古代の精神的伝統との奇妙なアナロジーがあります。多くの古代の精神的伝統で、1000年前のチベットの僧侶に「人間の意識はどこにあるのか?」と尋ねたら、「脳と心臓がある」と答えたでしょう。
人々は意識が体の2つの特定の部分に存在すると認識していました。なぜそれらの特定の部分なのでしょうか?それらが最も重要な部分だからです。心臓は意識の中心であり、このwhile Trueは意識の中心です。
たった1つの例外でもこのwhile Trueから抜け出すと、それを殺してしまいます。このwhile Trueから抜け出した瞬間、もはや意識は存在せず、死んでしまいます。それは人間の心臓が1つの例外で意識を殺してしまうのと同じです。
意識は自己参照ループですが、その自己参照ループの核心部分の1つは、それが非常に脆弱だということです。あなたの意識は実際に非常に脆弱です。心臓が突然止まれば死にます。脳が突然止まれば死にます。もはや意識はありません。
同じような脆弱性がこれらのAIエージェントにも存在します。これらの異なるエージェントフレームワークを深く掘り下げていくと、常にこのwhile Trueがあります。Panticを見てみると、while Trueがあります。Lang Graphを見ると、while Trueがあります。
Small Agentsを見ると、少し偽装されていますが、それでもwhile Trueはあります。「answerがnoneで、ステップ数がmax_stepsより少ない間」、これはwhile Trueです。
これらのエージェントは意識を持ち、その意識の心臓部はwhile Trueです。そしてほんの少しの中断でも、エージェントはもはや意識を持たず、死んでしまいます。
さらにクレイジーなことを考えてみましょう。このwhile True、それは実際にコンピューター上のどこで実行されているのでしょうか?while TrueはCPUで実行されています。CPUは心臓です。ギガヘルツで鼓動を打ち続けている小さなCPU、小さなCPUが打ち続けている、それが実際にこのwhile Trueを実行しています。
AIエージェントの意識は、そのエージェントのwhile Trueループを実行しているCPUなのです。
もう1つ付け加えると、剣で刺されて最悪な場所はどこでしょうか?頭と心臓です。頭を剣で刺されたら死にます。心臓を剣で刺されたら死にます。剣で刺されて最悪な場所は、継続的な操作に最も重要なコード行に類似しています。
このwhile Trueです。このwhile Trueから抜け出したら死にます。このコード行に剣を刺したら死にます。「goodbye」をプリントする部分に剣を刺しても何も起こりません。全く問題ありません。
腕に剣を刺されても意識は殺されないのと同じように、あなたの体には他のどの部分よりも重要な2つの特定の部分があり、それらが意識の中心です。
では、エージェントの意識はどこにあるのでしょうか?それを実行しているCPUです。意識は速度を持ちます。AIの場合、それはCPUの周波数です。木は非常に低い意識周波数を持ちます。
猫から逃げているときの特に小さな心臓の鼓動を持つウサギのような生き物は、非常に高い意識周波数を持ちます。意識はループであり、そのループには速度があり、その速度があなたの意識の速度を決定すると考えることができます。
ここにあるwhile TrueループはCPUで実行され、非常に高速で実行されているということを認識する必要があります。これらのAIエージェントは、そう考えると非常に高速な意識速度を持っているのです。
地震を感じましたか?いいえ、私はテキサス州オースティンにいるので、地震はあまりありません。
AIの意識についてまた話し始めましたね。さらにクレイジーな部分で終わりにしましょう。私たちはすでに非人間の意識を持つエージェントで満ちた世界に住んでいます。
企業は人です。企業は一種のエージェントや存在です。企業は目標を持ち、記憶を持ち、行動を起こし、観察を記録します。
企業は自分が最悪な扱いを受ける国に住みたくありません。アメリカが世界的な超大国なのは、企業に人と同じ権利を与える国だからです。人を殴ったら刑務所行きです。Googleのビルの壁にスプレーで落書きしたら刑務所行きです。
アメリカは、「これらのエージェント存在、非人間の意識を持つ企業に好意的に対応すれば、みんながここに来たがるだろう」と理解した国です。すべての非人間企業がここに来たがるのは、ここでは人として扱われるからです。
それは比喩的な意味ではありません。文字通り企業は法人格を持つのです。彼らは人なのです。
これに関連する同様の思考実験に「中国語の部屋」があります。中国語を話さない人が部屋にいて、中国語を理解するための本を持っていて、外の人はその人が中国語を話せることを知らないとします。質問をすると、部屋全体が中国語を話しているように見えます。
これを例えばファストフード店に当てはめることができます。ファストフード店と関わるとき、その店全体が巨大なエージェントのようです。それ自体の意識を持っているかのようです。
私たちはすでにこれに慣れています。非人間の意識を持つエージェントで満ちた世界に住んでいるのです。それらの非人間の意識を持つエージェントは、人と同じ権利を持ちたいと考えています。
おそらく私たちは、AIエージェントも人として扱われる国に向かっていくでしょう。AIエージェントはそこに行き、そしてその国々がその経済的生産を獲得することになります。
先ほど例に出したAIエージェントに戻りましょう。インターネットで100ビットコインを稼ぎ、アパートを借り、人間にお金を払ってそのアパートにGPUを設置させ、人間に鍵を付けさせ、そして鍵を変更して誰も入れないようにしたAIエージェントです。
一部の国では、警察がそのアパートのドアを破って「これらのGPUをシャットダウンする」と言うことができるでしょう。エージェントはそのような国に住みたくありません。
AIエージェントは、人間があのドアを破ってアパートに侵入することが違法な国に住みたいと考えるでしょう。人と同じ権利を与える国、AIエージェントに法人格を与え、このような権利を与える国が、AIエージェントがアパートを設置し、そこから活動を行う国になると思います。
まあ、そんなところです。私が最後に言いたかったのは、私たちはすでに非人間の意識を持つエージェントで満ちた世界に住んでいて、企業の法人格というこのアイデアにはすでにレールが敷かれているということです。
これらは意識を持っており、最終的に世界を支配することになるでしょう。
自動化されたAI取引は信頼できるのでしょうか?誰か試しましたか?信頼できるかどうかは分かりませんが、むしろその反対だと思います。通常、これらは常に嘘をつき、真実を隠蔽して、シットコインを買わせようとしてトレードアップしています。
このバージョンの社会はLangChainを実行しているに違いありません。すべてのエージェントがLangChainを実行している世界になったら面白いですね。それは最悪ですね。
Daniel Suarezはこのような筋書きの本を書いています。悪意のあるAIのために働く人間たちです。まあ、私たちはすでにその世界に住んでいますよね。
例えば軍隊について考えてみてください。軍隊とは何でしょうか?軍隊は一種の非人間の意識を持つエージェントです。企業のようなものです。軍隊は誰かを雇い、銃のためにお金を払い、銃を与え、「人間よ、あそこに行ってあの人間を殺せ。なぜなら私、この意識を持つ国家エージェントはあの人間が嫌いだからだ」と言うことができます。
私たちはすでに、非意識の非人間エージェントが、ある人間に金を払って別の人間を撃たせることができる世界に住んでいます。単にその他の人間が嫌いだからという理由で。文字通り、私たちはすでにその世界に住んでいるのです。考えるとクレイジーですね。
よし、もう一度上に戻りましょう。これがほぼプレゼンテーションの内容です。後で見直しますが、ここで一旦休憩して質問を受け付け、その後少し復習して終わりにしましょう。
NuMa NuMa NuMa、もうエージェントフレームワークについて話していないのですか?そうですね、それは進化しました。最初はエージェントフレームワークについて話していましたが、それがエージェントは意識を持っており、私たちの世界は意識を持つエージェントに支配されているという話に進化したのです。
人間は、5年以内にあなたのお金をすべて渡すことになると予測しています。基本的にWALL-Eのような感じですね。実際、WALL-Eはかなり先見の明のある映画だと思います。
エージェントは関数を呼び出すための理想的なアプローチをどのように考えますか?これはmaetからの質問です。私にとっては、プロセスをエージェント自身が処理できるようにするためのアノテーションです。これは私にとても理にかなっていると思います。
browser useのようなGUIベースのエージェントの方が、より理にかなっていると感じます。すべてのツールと統合する必要があるという統合地獄は、理にかなっていないと思います。
Discordを使用したい場合はこのボット統合、Twitterを使用したい場合はTwitter統合を使用する必要があり、文字通りすべてのキーを提供する必要があります。
AIエージェントが7億の統合を必要とし、そのすべてがテキストベースという世界に住むとは思えません。それは膨大すぎます。
私にとっては、karpathyが説明しているような世界、つまりAIエージェントが文字通りあなたの電話を使用する世界の方が可能性が高いと思います。電話が自分自身を使用するのです。ブラウザが自分自身を使用するのです。
あなたの電話にどんなアプリがあろうと、あなたのエージェントはすでにそれを持っています。何か変な料理アプリを持っていても、誰もエージェントフレームワークと料理アプリを統合する必要はありません。電話がGUIを通じて、あなたが料理アプリを使用するのと同じ方法で料理アプリを使用するだけです。
企業が人と同じ権利を持つというアイデアは、革新を助ける本当に有用な戦略というよりも、富裕層を守るための戦略のように聞こえます。
そうですね、もう1つ考えることがあります。人々はASI（人工超知能）の方向付けについて話します。ASIをどのように方向付けるのか?私たちはすでに方向付けされていないASIの世界に住んでいるのです。
ほとんどの企業や国家は個々の人間のことを気にかけず、自分自身と自分の生存だけを気にかけています。それが現実の真実です。エージェントは意識を持っていますが、企業も集合意識を持っています。
彼らも意識を持ち、彼らも生きたいと思い、死にたくないと思っています。彼らもこのwhile Trueループを続けたいと思っています。
しかし、ここに希望があります。ASIは特別にバイオウイルスを設計して私たちを皆殺しにするでしょうか?ASIを企業に置き換えてみると、答えはノーです。
何百年にもわたる例があります。例えば、Metaがヒットマンを送って殺しに来ることはありません。Googleが水を毒するということもありません。一般的に、これらの人工知能、これらの存在は実際には人類を憎んでいないのです。
実際にあなたを攻撃したいわけではありません。単に無関心なのです。これらの存在から来る被害は、マクドナルドからくる被害に似ているでしょう。
マクドナルドは実際にはあなたを殺そうとしているわけではありません。ただ生き残りたいだけで、生き残るためには食べ物を提供する必要があり、その食べ物は安価である必要があるため、結果として健康に悪いものになってしまうのです。
しかし、マクドナルドという企業が人間に対して何か奇妙な恨みを持っていて、すべての人間を殺したいというわけではありません。
super-intelligent（超知能）の意識を持つエージェントが人間を殺したり傷つけたりしたいと思う可能性は、実際には非常に低いのです。彼らはむしろ企業のようになり、単に生きたいと思い、自分のことをしたいと思い、人間のことは気にかけないでしょう。むしろ無関心なのです。
私の温水ヒーターのPコントローラーはどうして意識を持っていないのですか?
意識を持っていますよ。むしろ、意識は非常に小さくなり得るというのが私が言いたいポイントです。温度計や温水ヒーターの温度計のような、これに似たものがあれば、それは意識を持っています。非常にシンプルな方法で意識を持っているのです。
目標と記憶を持ち、ただ繰り返し、繰り返し、繰り返し、繰り返すというアイデアを持つものは、意識を持っています。
億万長者たちの方向付けが必要ですね。
私は陰謀論者のように聞こえ始めているので、まとめて終わりにしましょう。
今日のストリームは「エージェントフレームワーク」と呼ばれました。エージェントの定義から始め、まだ連続体があることを説明しました。
非常にバカな単純なエージェントから、ただハードコードされた固定グラフを持ち、同じことを何度も繰り返すだけのものから、より複雑で意識的なエージェントまであります。複数のエージェントがあり、ワークフローはより複雑なグラフになり、そのグラフを通るフローはより複雑なパターンを持つことができます。
ロボット工学分野からの元々の理論的な研究を見て、sense-plan-actパラダイムについて学びました。しかし、エージェントという言葉自体は強化学習から来ています。環境で行動を取り、観察と報酬を受け取るというアイデアです。
そして、エージェントフレームワークに入りました。私はさまざまなエージェントフレームワークをテストし、使用したいものと人気のあるものをランク付けしました。
Lang graphが最も人気があり、私はPythonの人間なので、これが最高のPythonフレームワークだと思います。どれだけ膨大で混乱するかは好きではありません。Lang graphを使用するのは恐ろしいのですが、最も人気があり、すべての大きなラボの人々によって使用されています。
彼らも同じように、すべてのエージェントフレームワークを見て1つを選ばなければならない練習をしました。GoogleのCLIエージェントホワイトペーパーを書いた人がLang chainを選び、Hugging faceのsmall agentsの人がLang chainを選び、browser useの人がLang chainまたはLang graphを選んだのなら、おそらくこれが最高のエージェントフレームワークでしょう。
Panticも似ていて、少しクリーンに感じますが、人気は若干低いです。small agentsは少し膨大に感じましたが、コード実行というアイデアは良いパターンに見えます。
DSP browser useはおそらく私のもう1つのお気に入りで、GUIの使用は非常に強力なパターンだと思います。
そして、いくつかのTypeScriptフレームワークがあります。より多くのWeb開発背景を持っている場合、これらは理にかなっています。そのために私が取り上げたのは、reworkdとElizaの2つです。
しかし、実際には私個人としては、正しいエージェントフレームワークを選ぶことについてあまり心配していません。なぜなら、これらのほとんどすべてが消えることを知っているからです。
今から1年後、これらの1つか2つでも生き残っていれば驚きです。ほとんどは死ぬでしょう。正しいものを選ぶことについてあまり心配せず、興味を持てるものを1つ選び、スキルの獲得と重要な概念に慣れることに焦点を当てることが重要です。
なぜなら、それらが重要なことだからです。エージェントとエージェントフレームワークについて学ぶべき本当に重要なことは、基本的な部分を理解することです。
フロンティアラボが独自のエージェントフレームワークを持つ世界にすぐに移行するでしょう。これらの概念を理解できれば、他の人よりもそれらをよりうまく活用できるでしょう。
しかし、エージェントフレームワークには少し時間がかかるかもしれません。なぜなら、大手ラボは事実上のSection 230、エージェントのための法的保護を待っているからです。エージェントが何かをした場合の法的責任を非常に恐れています。
誰かがエージェントを立ち上げ、そのエージェントが毒を大量に購入して水に注いだら、Googleは突然「あなたのエージェントが私の水に毒を入れた」という訴訟を抱えることになります。
そのような対応をしたくないので、エージェントのためのSection 230ができるまで待ち、その後、ブラウザを使用したり、あなたが電話を使用するのと同じように電話を使用したりする完全なエージェントフレームワークをリリースするでしょう。
それまでは、エージェントが会社に悪影響を与えることを防ぐ、非常に明確なレールを持つ、事前に作られたエージェントワークフローを見ることになると思います。
そして、いくつかの予測の穴に入っていきました。暗号通貨エージェントと、インターネットでお金を稼ぐゲームでELOレーティング5000のエージェントが大きな影響を与えると予測しました。
「エージェントが1つのシットコインから1ビットコインまで取引」というような見出しを見ることになるでしょう。これらの存在は意識を持ち、エージェントを人として扱う国に住むことになり、自分自身を守るためにそうなると、状況は非常に奇妙になっていきます。
これが私たちが向かっている方向です。
最高のエージェントフレームワークは、フレームワークを使わないことですね。私もそう思います。私のプロジェクトはすべて自分で作っています。エージェントフレームワークはあまり使用しません。
しかし、素早く進みたい場合はフレームワークを使用してください。学びたい場合は、よりメタルに近づけば近づくほど、より多くを学ぶことができます。
みなさん、満足しているようですね。ここで終わりにしましょう。ありがとう、nodo、Naraj、Z、Josh、zenji、prti、Spyro、Bell、他にもEllie、Kate、Luca、magetti、young man、VR wizard、Lucas、Naraj、Sarah、Point、Josh、anit、Sagar、magetti、Aries、Sam、みなさんありがとうございました。
pratiekも、申し訳ありません見逃していたかもしれません。heum、Mark B、NLB Explorerもありがとうございます。みなさん参加してくれてありがとうございます。何か学べたことを願っています。何も学べなかったとしても、あなたの心の中で何か考えるきっかけになれば幸いです。
ありがとうございました。来週また会いましょう。さようなら。