ToolMaker は、エージェントのツールを作る LLM エージェント で紹介されたエージェント型フレームワークであり、科学論文に付随する単体のコードリポジトリを、LLM エージェントが呼び出せるツールに変換する。その狙いは、エージェントがそうしたコードを使えるようになる前に、セットアップ、インストール、調整を行わなければならなかった人間の仲介者を不要にすることである。著者らは、この障壁が医療、生物学、創薬の分野で特に大きな制約になっていると考えている。
ユーザーは最小限のツール定義を与える。タスクを 1 文で説明したもの、関連する GitHub リポジトリの URL、そして必要な入力引数とそれぞれの例の値である。ToolMaker は 2 つの成果物を返す。ツールが動作する環境（Docker コンテナ）と、タスクを実行する Python 関数である。フレームワークのコードは、評価用ベンチマークである TM-Bench とともに、GitHub の KatherLab/ToolMaker リポジトリで公開されている。
機能
ToolMaker は 3 種類のコンポーネントから構成される。会話にメッセージを追加するだけの LLM 呼び出し、実行環境の状態を読み取ったり変更したりする環境とのインタラクション、そして高レベルの指示として与えられたサブタスクを完了するためにこの 2 つを連鎖させるエージェントである。環境に対するアクションは、bash コマンドの実行、ディレクトリの一覧表示、ファイルの読み書き、ブラウジング、Google Drive フォルダの一覧表示、Google Drive ファイルのダウンロード、そして候補となるツール実装を実行する特別なアクションである。エージェントは最後のもの以外のすべてのアクションを使うことができる。候補実装の実行は、ワークフロー自体の独立したステップのために予約されている。
作業は 2 つの段階で進む。環境セットアップの段階では、インストール担当のエージェントがクリーンな python:3.12 の Docker イメージから始め、リポジトリをクローンし、ドキュメントを読み、必要と判断したライブラリ、モデル、その他の依存関係をダウンロードする。エージェントが行う書き込みアクションはすべて記録され、それぞれが bash コマンドとして表現できるため、それらを連結すると環境の定義が bash スクリプトまたは Dockerfile として得られる。ツール実装の段階では、新しいエージェントがセットアップ時の会話を引き継がずにインストール済みのリポジトリを探索し、続いて 1 つの LLM 呼び出しが段階的な計画を書き、もう 1 つの LLM 呼び出しが最初の候補となる関数を書く。
その後、クローズドな自己修正ループに入る。環境はインストール直後のスナップショットに復元され、候補が例の呼び出しで実行され、LLM が返された結果と出力ストリームから、実行が成功したか、結果が妥当かを判定する。そうでなければ、エージェントが根本原因を診断し ― このときは環境をリセットしないため、実行によって生成された中間ファイルを調べることができる ― 関数が再実装され、その試行が要約される。新しい反復のたびに、すべての試行のメッセージを引き継ぐのではなく、会話は最初の試行の前に取得された以前のスナップショットに復元され、過去のすべての試行の要約と現在のバージョンのコードが追加される。実行環境は Docker コンテナであり、ToolMaker はその内部で動作する HTTP サーバーを通じてこれを制御する。これによってホストから隔離されたサンドボックスとなり、再現性も保たれる。状態は Docker のチェックポイント機能で復元される。
論文の記述によれば、ToolMaker は LLM 呼び出しに OpenAI の gpt-4o-2024-08-06 を使い、計画と実装のステップには o1-mini-2024-09-12 を使っている。
採用状況とエコシステム
ToolMaker は TM-Bench 上で OpenHands と比較評価されている。著者らは OpenHands を、同じ 2 つの成果物を生成するように適応させている。結果は論文自体のページで報告されている。著者らは ToolMaker を、実行時にツールセットを拡張できるエージェントや、自律的でエージェントに基づく科学的ワークフローに向けた一歩として位置づける一方、ある程度構造化され、ドキュメントが整ったリポジトリを前提としていることにも言及している。ToolMaker は、この論文の意味での ツール作成 の一例である。