実際、Manusは賢く、ツールを3つのレイヤーに分割しました。 レイヤー 1: 関数呼び出し これは最も基本的なレイヤーであり、ファイルの読み取りと書き込み、シェルコマンドの実行、ファイルの検索など、少数の固定されたアトマイズされた機能のみを保持します。 LLM システム プロンプトには、この層のツール定義しかなく、比較的少なく、15 以内であり、入出力形式は非常に明確で間違いを犯しにくいですが、その中には 2 つの特別なツールがあり、1 つはシェル、もう 1 つはファイルです。 Tier 2: サンドボックスユーティリティ 各 Manus セッションは、完全な仮想マシン サンドボックスで実行されます。 元のツイートで述べたように、仮想マシンには、フォーマット コンバーター、音声認識ツール、さらには MCP コマンド ライン クライアントなど、多くのコマンド ライン ツールがプリインストールされています。 これらのツールは、レイヤー 1 で定義されたシェル (コマンド ライン ツール、コマンド ライン呼び出し) を介して呼び出されます。 しかし、これほど多くのツールモデルがどうやって知っているのでしょうか? Manus は、システム プロンプトで LLM に、特定のフォルダーに多数のコマンド ライン ツールがプリインストールされていることを直接伝えます。 最も一般的に使用されるツールについては、名前で直接リストします。 あまり使用されていない人のために、LLM は元のプッシュで言及されたコマンドを通じてすべてのコマンド ライン ツールを直接リストし、--help パラメーターを使用してそれらの使用状況を確認できます。 レイヤー 3: パッケージと API この層は実際には LLM が Python コードをリアルタイムで記述し、より複雑な関数がコードを通じて実装されます。 たとえば、ユーザーが API のデータにクエリを実行する場合、Python で関数を直接記述して API のデータを取得し、必要な形式に解析できます。 実際、コーデックスでは、Pythonコードをツールとして使用することが多く使用されています。 複雑な操作はコードによって行われるため、メインエージェントに返される知識計算の結果はメインエージェントのコンテキストを占有しません。 この 3 層設計の利点は、モデルの観点から見ると、呼び出す必要のあるツールが最初の層の十数個に固定されており、コマンド ラインとコードの助けを借りて、無数のツールの組み合わせを導き出すことができることです。 もう一つのポイントは、前回のツイートで言及したサブエージェントですが、マヌスも「ツールとしてのエージェント」モデルを多く使用しています。 サブエージェントをツールとして使用する場合、たとえば、検索を担当するサブエージェントはサブエージェントですが、このサブエージェントはメインエージェントの目にはツールです。 同時に、コンテキストを減らすのにも良い役割を果たすことができます。