確實，Manus 很聰明，他們把工具分成了 3 層： 第 1 層：函數調用 (Function Calling) 這是最基礎的一層，只保留一小組固定的、原子化的函數，比如：讀寫文件、執行 Shell 命令、搜索文件等。在 LLM 的系統提示詞中就只有這一層的工具定義，相對比較少，15 個以內，輸入格式和輸出格式都很清晰，不容易出錯，但這裡面有兩個工具很特殊，一個是 Shell， 一個是 File。 第 2 層：沙箱工具 (Sandbox Utilities) 每個 Manus 會話都運行在一個完整的虛擬機沙箱裡。就是原推文提到的，虛機預裝了很多命令行工具，比如格式轉換器、語音識別工具，甚至一個 mcp 命令行客戶端。 然後這些工具都通過第 1 層中定義的 Shell 來調用，就是命令行工具，命令行調用。 但是這麼多工具模型怎麼知道呢？ Manus 在系統提示詞裡會直接告訴 LLM，在一個特定的文件夾裡有很多預裝的命令行工具。對於最常用的工具，直接列出它們的名字。不常用的，LLM 可以直接通過原推提到的命令列出所有命令行工具，通過 --help 參數來查看任何一個工具的用法，因為所有這些工具都是他們自己開發的，格式統一。 第 3 層：代碼包與 API (Packages and APIs) 這一層其實就是 LLM 實時編寫 Python 代碼，通過代碼實現更複雜的功能。比如用戶想查詢某個 API 的數據，可以直接用 Python 寫一個函數，fetch API 的數據，並解析成需要的格式。 其實在 Codex 中，用 Python 代碼當工具已經用的很多了。 由於複雜的運算都是代碼完成的，返回給 主 Agent 的知識計算後的結果，所以並不會佔用主 Agent 的上下文。 這樣 3 層設計的好處是，從模型的角度看，它需要調用的工具就固定是第 1 層的十幾個，而藉助命令行和代碼，它又可以衍生出無數的工具組合。 還有一點就是我在之前推文提到的子智能體，Manus 也是大量採用“智能體即工具 (agent as tool)”的模式。把子智能體當工具用，比如負責檢索是一個子智能體，但是這個子智能體在主 Agent 看來就是一個工具。同時也可以很好的起到減少上下文的效果。