大きなモデルを実際の作業につなぐには、以前ならしばらくフレームワークの抽象を渡り歩く必要があった。ノードを定義し、ツールを記述し、状態の遷移を配線する。動き出すころには熱意の半分は配線に消えている。ここで扱うライブラリは逆の立場を取り、その立場こそが要点だ。エージェントに必要なのはフレームワークではなく、行動する手段である。

smolagents は小さなオープンソースのライブラリで、中核のロジックはおよそ千行。この界隈の多くがその周りを回っているモデルコミュニティのチームが公開している。中心の主張はこうだ。モデルにツール呼び出し専用の形式を覚えさせる必要はない。得意な言語でコードを書かせ、それを実行すればよい。

表を埋めるのではなくコードで考える

従来のやり方は、モデルに構造化された指示を出力させる。どのツールを、どの引数で呼ぶか。形式は固定で、フレームワークが解析してから実行する。ここでの代替案は、実行できる短い Python のコードを書かせ、ライブラリがそれを走らせ、出力をモデルに返して推論を続けさせるというものだ。コードにはループも条件分岐も入れ子の呼び出しも最初から備わっているので、何度も往復が必要だった多段の作業が、短いスクリプト一つで済むことが多い。

この方式とともに示された数字では、比べられる作業においてステップとモデル呼び出しが構造化方式よりおよそ三分の一少ない。呼び出し回数で課金されるサービスにとって、これは四捨五入の誤差ではなく、繰り返し走らせられるかどうかの差になる。能力の宣言も同じくらい素朴だ。普通の関数と、明確な説明を用意すれば、エージェントが使う時を自分で決める。つなぎのコードも、呼び出しの順番を事前に並べておく作業も要らない。

モデルは自分で決める

このライブラリはモデルに対して中立で、そこが気楽なところの一つでもある。ホストされた推論サービス、ルーティング層を挟んで接続する商用各社、自分のマシンで動くローカルのモデル。エージェントから見ればどれも同じ形をしていて、切り替えはたいてい初期化の一行を変えるだけで済み、ロジックを書き直す必要はない。

モデルの能力が上限を決める。コードを書くのがうまいモデルほど、この方式はよく働く。コミュニティで繰り返し指摘されている点であり、採用の前に真剣に受け止める価値がある。コードを書いて動くエージェントは、使うモデルがコードを書く力の長所も短所もそのまま受け継ぐ。

何が、どこで実行されるか

コードを生成して走らせるとなれば、例の疑問がすぐ出る。プロジェクトの答えは曖昧でない。ローカルの実行器は開発とデバッグのためのもので、安全の境界ではない。重要な作業は隔離された環境で走らせるべきで、その手段はいくつかある。ホストされたサンドボックスか、自分で管理するコンテナか。エージェントを定義するときにパラメータ一つで選ぶ。

もう二つの抑制も理にかなっている。生成されたコードは既定では言語の標準モジュールしか使えず、第三者パッケージは明示的に許可する必要がある。これで、ネットワークに触るものを何気なく読み込む経路が塞がれる。コードが失敗すれば、エージェントはエラーを読み、直して再試行する。試行の回数は既定値の小さいステップ上限で抑えられるので、混乱したエージェントが請求の上で永遠に回り続けることはない。

エコシステムの内側にいる強み

大きなモデルコミュニティのチームが作っていることには、まねしにくい利点がある。できあがったツールやエージェントをそのコミュニティに公開し、他の誰かが依存関係を入れるのと同じ感覚で取り込める。オンラインのデモアプリを丸ごと一つのツールとしてエージェントに渡すことさえできる。その外側でも、あるオープンな取り決めのツールや別の有名なフレームワークのツールを接続でき、入力はテキストに限らない。画像も動画も音声も扱える。

エージェントの仕組みを学びたい人にとって、最も価値がある性質は読みやすさだ。千行なら、層になった抽象と格闘する代わりにソースコードを読んで問題を特定できる。この規模の透明さ、コードで行動する効率、モデルとツールを自由に差し替えられる柔軟さ。三つが重なって、思ったより扱いやすい出発点になっている。

向いている人

一つの部分だけを変えて残りを固定したい研究者。新しいアプリをその上に作るのではなく、既存のプログラムの中にエージェントを入れたい開発者。抽象が節約する以上の手間をかけるフレームワークに辟易したことのある人。無料でオープンソース、そして千行は午後一つで読み切れる長さだ。