ほとんどのAIエージェントは、同梱して出荷されたツール一覧の能力にしか匹敵しません。
それらは閲覧したり、クリックしたり、ファイルを読んだり、場合によってはいくつかのシェルコマンドを実行したり、既成の関数をいくつか呼び出したりできます。しかし、内蔵されたアクションがカバーしていないタスクにぶつかると、たいてい止まってしまいます。その時点で、足りない機能を自分で追加するか、外部のスキルシステムを組み込むか、あるいはそのエージェントが自分の世界の限界に到達したのだと受け入れる必要があります。
それはいつも、私にとって大きな制限のように感じていました。
そこで私は、GrimmBotを作りました。オープンソースのAIエージェントで、私がはるかに面白いと感じることができます。つまり、能力のギャップに遭遇したとき、自分のために新しいPythonツールを生成し、それをテストし、将来の利用のために自分のツールキットに追加できるのです。
これが主な特徴ですが、それが全てではありません。GrimmBotはサンドボックス化されたDebianのDocker環境で動作し、デフォルトブラウザとしてChromiumを使い、永続メモリを備え、スケジューリングをサポートし、APIトークンを常に燃やし続けることなく、長時間にわたってウェブページや画面領域を監視できます。より大きな目標は、「ただ行動するだけ」のエージェントではなく、待つこと、覚えること、仕事をスケジュールすること、そして内蔵ツールだけでは不十分になったときに適応できるエージェントを作ることでした。
Repo: https://github.com/grimm67123/grimmbot
デモ動画はリポジトリ内にあります。
静的エージェントの問題点
現在の多くのAIエージェントは、既に知っていることの範囲を超えて「それができるとは限らない」ような一つのことが必要になった瞬間まで、印象的です。
それは、たとえば次のような小さくて面倒なものかもしれません。
- 奇妙なファイル形式をパースすること
- 独自のログ構造からデータを抽出すること
- 特定の変換ステップを扱うこと
- 珍しいワークフローをナビゲートすること
- 内蔵された2つの機能を、独自のロジックでつなぐこと
モデルは「何をするべきか」を正確に理解しているとしても、環境がそのための適切な関数を公開していなければ、エージェントは行き詰まります。
そこには奇妙なミスマッチが生まれます。システムの「知性」は多くの場合、前に進む道筋を見通せますが、実際のアクション層は固定されたツールのメニューによって枠づけられています。
私は別のアプローチで実験したいと思いました。もしエージェントが、そのメニュー自体を拡張できたらどうでしょうか。
GrimmBotが違うところ
GrimmBotには、自律的なツール生成のための機能があります。
実用的には、現在のツールセットで処理できないタスクに遭遇した場合、新しいPythonツールを作成し、それを利用可能なツールに統合し、必要になったときは後でもう一度使えるようにできるということです。
つまり、同梱されているツールセットを“絶対的な境界”として扱うのではなく、GrimmBotはそれを“出発点”として扱えるのです。
それは、エージェントがドラマチックなSF的な意味で自分自身を書き換えているということではありません。もっと実務的な話です。つまり、タスク固有の壁にぶつかったとき、システムが適応するための道筋が用意されているということです。
私にとって、それによってエージェントはずいぶん脆くなりにくく感じられます。
なぜこれが重要だと思うのか
多くのエージェントシステムで現在見られるパターンは次のようなものです。
- 内蔵ツールのセットを定義する
- モデルにその中から選ばせる
- どれも合わなければ失敗する
それは予測可能なワークフローではうまく機能しますが、現実の世界は例外だらけで、非常に具体的な要件に満ちています。
もしエージェントが、開かれたタスクで本当に役に立つ存在になるなら、あらかじめ用意された道筋が十分でないときに適応できる何らかの能力が必要だと思います。そうでなければ、常に一つの不足した関数によって行き詰まることになります。
自律的なツール生成について私が最も惹かれたのは、「すごい」要素ではなく、実務的に脆さが減る点です。
硬直したエージェントはデモでは見栄えがします。
適応できるエージェントのほうが、実際の利用ではずっと面白いのです。
それを取り巻くより広いシステム
私は、生成されたツールまわりの“おもちゃ”実験にとどめたくありませんでした。そうではなく、この能力が、より大きなエージェント環境の中に存在することを望んでいました。
そこでGrimmBotはDebianのDockerコンテナ内で動作し、デフォルトブラウザとしてChromiumを使います。仮想デスクトップ環境、ブラウザ制御、ファイル操作、シェルアクセス、コーディング関連の関数、メモリシステム、スケジューリング、そしてセンシティブなアクションのための人間の承認待ち（ポーズ）を備えています。
これは重要です。なぜなら、ツール生成そのものだけでは、他のシステムがあまりに狭い作りだとあまり有用にならないからです。
ポイントは単に「エージェントがコードを書けること」ではありません。ポイントは、その新しいコードが、サンドボックス化された環境の中で、より大きなワークフローの一部になれるということです。
たとえば、役に立つエージェントには次のようなことが必要になるかもしれません。
- ページにアクセスする
- データを調べる
- カスタムパーサが必要だと気づく
- そのパーサを新しいツールとして生成する
- 結果を保存する
- 結果を記憶する
- フォローアップをスケジュールする
- 次の変更を監視する
私にとって、それは「モデルがPythonを出力できること」を示すだけよりずっと面白いことです。
ゼロトークンでの監視も、もう一つの主要な設計目標
自律的なツール生成は、私にとってGrimmBotの中で最も概念的に面白い部分ですが、もう一つ解決したかった大きな問題は監視です。
多くのAIエージェントは、待っている間にトークンを消費します。
もしそれらに、ウェブページを監視すること、テキストが表示されるのを待つこと、ステータスページを見続けること、あるいは画面領域の変化を監視することを頼むと、多くのシステムでは何も起きていないのにLLMを何度も呼び続けます。
それは無駄に感じます。
待つことは推論ではありません。
そこでGrimmBotには、DOMや画面領域に対してローカルループを回せる監視ツールが含まれています。モデルを継続的に起こすことなく実行できます。LLMは、何を監視するべきかを判断し、必要な引数付きで適切な監視ツールを呼び出し、その後はローカルループが退屈な部分を行っている間、眠ります。トリガ条件が実際に満たされたときだけ、起き上がります。
私はこれを、同じ設計思想の重要な一部だと考えています。
エージェントは、利用可能だからといって、すべてをモデルで使うべきではありません。
永続メモリとスケジューリング
また、GrimmBotにはワンショットのタスクを超えて役立つことも望みました。
実際のワークフローでは、エージェントはしばしば次のようなことを必要とします。
- セッションをまたいで文脈を記憶する
- 役に立つ事実やタスクの状態を保存する
- あとで何かを見返す
- 一定間隔で実行する
- 遅延の後に作業を続ける
そのため、GrimmBotには永続メモリとスケジューリングの機能を、より広いシステムの一部として組み込みました。
これにより、エージェントは「どのタスクもゼロから始まり、すぐ終わる」というふるまいを強いられずに済みます。時間の経過の中でより良く連続性を維持できます。
これは、監視や生成されたツールと組み合わせたときに、さらに重要になります。
次のことができるエージェントは。
- 記憶する
- 待つ
- スケジュールする
- 適応する
一瞬その場で行動できるだけのエージェントより、運用上の有用性にずっと近いのです。
私がこのように作った理由
これらすべてに共通する糸は、私は脆さを減らしたかったということです。
静的なツールセットは脆いです。
絶え間ないLLMのポーリングは脆く、無駄が多いです。
メモリがないことも脆さにつながります。
スケジューリングがないことも脆いです。
ブラウザアクセス、永続的なコンテキスト、監視、そしてタスク固有のツールを生成できる能力を備えたサンドボックス環境は、より面白い方向性だと感じました。
私はこれがエージェントのあらゆる問題を魔法のように解決すると主張するつもりはありません。しかし、それは「備え付けの機能が十分であることを祈る」ことに依存しすぎず、実際のワークフローにより根ざしたエージェントのモデルへと向かうヒントになると私は思っています。
