OpenManus 預設不強制任何 token 限制。其自身的上限是 max_input_tokens；app/config.py 將其宣告為預設值為 None的 Optional，描述為「Maximum input tokens to use across all requests (None for unlimited)」，而且隨附的任何設定範例中都沒有這個欄位。因此標準安裝不會觸發自身的 token-limit 錯誤——您遇到的任何限制都來自提供者。實際設定後，它會以兩種出乎意料的方式運作，而目前 main中的一項缺陷會使它緩慢失敗，而不是快速失敗。
本頁涵蓋的另一個錯誤 Error: Unknown tool 'BrowserUseTool'根本不是現存的錯誤。它所指的類別已於 2026 年 8 月 15 日從 OpenManus 刪除，而目前 main的預設 Manus代理程式不會在本機註冊瀏覽器工具。這兩種症狀都不是 API 金鑰、端點或提供者問題，重新指定 base_url也無法修正任何一種。
在開始之前先說明一點。沒有可引用的 OpenManus 版本：僅有的三個標籤 v0.1.0、v0.2.0和 v0.3.0於 2025 年 4 月 10 日在 34 秒內全部發布，此後沒有任何新標籤，因此所有人都執行未標記的 main。標準儲存庫是 FoundationAgents/OpenManus——並非已封存，採 MIT 授權，擁有 58,371 顆星，最後推送於 2026 年 8 月 22 日（GitHub API，2026 年 9 月 21 日）。舊的 mannaandpoem/OpenManus路徑現在只是說明專案已搬遷的 stub README，因此 2025 年教學中引用的檔案路徑和行號指向的程式碼已不存在。以下所有內容都於 2026 年 9 月 21 日在 main分支從原始碼讀取，其中沒有任何內容被執行。
您實際遇到的四種訊息中，哪一種是
| 你看到的情況 | 由誰輸出 | 含義 |
|---|---|---|
Maximum token limit reached, cannot continue execution: Request may exceed input token limit (Current: …, Needed: …, Max: …) | OpenManus，app/agent/toolcall.py | 您為該次執行設定的 max_input_tokens上限已達到。未發送請求 |
| 指出模型的內容長度或 token 錯誤 | 您的提供者，透過 OpenAIError顯示 | 請求超過模型的內容情境視窗或端點自身的限制。與 OpenManus 的上限無關 |
Error: Unknown tool 'X' | OpenManus，app/agent/toolcall.py第 179–181 行 | 模型指定了不在 available_tools.tool_map中的工具。它會作為工具結果回傳，因此迴圈會繼續並消耗一個步驟 |
Failed to connect to Browser Use CLI 3.0: … | OpenManus，app/agent/manus.py第 99 行 | 預設的瀏覽器 MCP 伺服器未啟動。執行會繼續：Manus代理程式保留四個本機工具，以及您設定的任何其他 MCP 伺服器 |
產生第三列的分派只有三行，而且不受 2026 年瀏覽器改寫影響：name = command.function.name，接著是 if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'"。其中沒有任何內容專屬於瀏覽器，因此模型捏造的任何工具都會出現相同字串。
token 限制是選用的、累計的，而且是近似值
三個不同的數字都被稱為「token 限制」，而錯誤訊息只涉及其中一個。
| 設定 | 它限制的內容 | 預設值 | 隨附範例中有嗎？ |
|---|---|---|---|
max_tokens | 單次回應 | 程式碼中的 4096 | 有——設為 8192 |
max_input_tokens | 整個執行過程的累計輸入 | None，表示無限制 | 沒有。您必須手動加入，否則不適用 |
| 模型的內容情境視窗 | 由提供者限制的單次請求 | 模型自身的 | 根本不是 OpenManus 設定 |
第二列最容易讓人意外。LLM.check_token_limit()在 app/llm.py中會回傳 (self.total_input_tokens + input_tokens) <= self.max_input_tokens——這是工作階段的累計總量，而不是針對單次請求的檢查。因此，即使每次請求都很小，長時間的代理程式執行仍會因累積而觸發限制；錯誤文字會列出算式：目前值、所需值、最大值。預設 Manus 代理程式會設定 max_steps = 20，而每個步驟都會重新傳送截至目前的對話，因此累計數字上升得比步驟數更快。
這個計數也是 OpenManus 自己的估算。LLM.__init__會呼叫 tiktoken.encoding_for_model(self.model)，並在 KeyError時退回 cl100k_base；因此對於任何 tiktoken 沒有預設值的模型 ID——Claude 或 Gemini ID，或閘道命名空間 ID——實際執行的預算都是近似值，而不是提供者的計數。
# config/config.toml
[llm]
model = "claude-sonnet-4-6"
base_url = "https://api.kunavo.com/v1"
api_key = "sk-kn-..."
# The RESPONSE cap. Ships as 8192 in config.example.toml; the code default is 4096.
max_tokens = 8192
# The CUMULATIVE INPUT budget for the whole run. Absent from every shipped
# example, and None in code — so a stock install enforces no ceiling at all.
max_input_tokens = 400000上限在金錢上的價值
因為 max_input_tokens限制累計輸入，所以它會直接轉換為一次執行之輸入端的成本上限。以下數字是根據所述上限計算的示意 token 算術，不是測得的工作成本，也不是帳單上限：它們按照即時的Kunavo 目錄每百萬 token 費率，為設定所限制的輸入 token 定價。輸出完全不受該設定涵蓋——最後一欄按照範例設定所提供的 max_tokens = 8192為單次回應定價，而二十步執行可能產生二十次回應。
| 模型 | 每 1M 的輸入／輸出 | 100,000上限下的輸入 | 400,000上限下的輸入 | 一次 8,192token 回應 |
|---|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.070 | $0.280 | $0.029 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.070 | $0.280 | $0.034 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.210 | $0.840 | $0.086 |
| Claude Opus 5 | $3.50 / $17.50 | $0.350 | $1.400 | $0.143 |
有兩種解讀。上限是停止條件，而非預算：它告訴你單次執行的輸入端最多可能花費多少，卻完全不表示任務是否已完成。而且，由於 OpenManus 使用 tiktoken 計數，它所執行的上限與供應商計費的 token 數是兩種不同的衡量方式——設定此數值以限制失控的迴圈，再與帳戶實際記錄的用量核對。Kunavo 定價表上的金額是計費下限，而非上限：當上游回報費用時，帳單金額會取定價表費用與上游費用乘以適用加價倍率兩者中的較高值。Kunavo 的最低儲值金額為 $10 的預付額度，這是最低入金金額，而非任務費用或訂閱費用——請參閱計費詳情。
為什麼 token 錯誤會延遲出現
這是目前 main中可從程式碼讀出的缺陷，也是 token 限制失敗感覺像卡住的原因。app/llm.py中的三個 @retry裝飾器——分別位於 ask、ask_with_images和 ask_tool——寫法完全相同：
| 裝飾器所說的內容 | 它比對到的內容 | 結果 |
|---|---|---|
尾端註解：# Don't retry TokenLimitExceeded | retry_if_exception_type((OpenAIError, Exception, ValueError)) | TokenLimitExceeded 是 OpenManusError 的子類別，而後者又是 Exception 的子類別——因此，未加限定的 Exception 項目會與該例外相符 |
引發位置註解：# Raise a special exception that won't be retried | stop_after_attempt(6), wait_random_exponential(min=1, max=60) | 在錯誤浮現前最多嘗試六次，並使用指數退避；每次都重新計算相同的失敗總量 |
下游的代理程式迴圈確認了這個形態，而非否定它。app/agent/toolcall.py捕捉例外並測試 isinstance(e.__cause__, TokenLimitExceeded)——這種 __cause__解包方式就是 tenacity RetryError到達時的形式，而其自身的記錄列為「Token limit error (from RetryError)」。只有在此之後，它才會加入面向使用者的「Maximum token limit reached, cannot continue execution」訊息，並將代理程式狀態設為 finished。換句話說，消費端程式碼已經假設了裝飾器註解聲稱不會發生的重試。
沒有已合併的修正。PR #1348標題為「fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback」，於 2026 年 8 月 10 日關閉且未合併；其重新提交版本 #1407於 2026 年 9 月 21 日仍處於開啟且未合併狀態。相關的內容溢位 PR #1391「add tool description token budget to prevent context overflow」於 2026 年 8 月 18 日關閉且未合併。本文沒有讀取維護者關閉這些 PR 的原因，只確認它們尚未合併。歷史回報 問題 #779「hitting token limit」於 2025 年 3 月 17 日提出，於 2026 年 9 月 17 日由不活躍機器人以 state_reason: not_planned關閉——這是逾時，而非解決。在其中一項修正合併前，實際可行的緩解方式是保持 max_input_tokens未設定，讓提供者拒絕過大的請求；或設定它並接受延遲。
Unknown tool 'BrowserUseTool'是來自已不存在版本的錯誤
問題 #789「Result: Error: Unknown tool 'BrowserUseTool'」於 2025 年 3 月 18 日提出，至 2026 年 9 月 21 日仍未關閉，標記為 inactive。其原因從來不是端點或金鑰。回報者自己的記錄顯示，模型在已註冊工具名稱應為 browser_use的地方輸出了 Python 類別名稱 BrowserUseTool；而同一次執行的下一步在改為呼叫 browser_use後便順利分派。他們貼出的記錄最後是「Activating tool: 'browser_use'」，結尾完整呈現診斷結果：「BrowserUseTool seems not work, but browser_use can」。任何留言者給出的唯一建議是嘗試更強的模型，這正是工具呼叫可靠性問題應有的回答方向。
這項診斷不適用於目前的 main，因為現在已沒有名為 browser_use的工具可供正確指定。2026 年 8 月 15 日的提交 ab8dfe43（「feat(browser): use Browser Use CLI 3.0」）和 05c5bbb1（「refactor(browser): use CLI 3.0 MCP server」）刪除了本機瀏覽器工具。在 main上的 app/tool/目錄列表中沒有 browser_use_tool.py，而樹狀目錄中留下的 BrowserUseTool字串唯一出現處，是 app/agent/sandbox_agent.py中的一行註解。
| 2025 年 3 月的程式碼（問題 #789） | 目前的 main，讀取於 2026 年 9 月 21 日 | |
|---|---|---|
| 瀏覽器工具 | app/tool/browser_use_tool.py中的本機類別 | 已刪除。在預設的 Manus代理程式上，以 uvx browser-use --cli-mcp啟動的程序外 MCP 伺服器 |
| 註冊名稱 | browser_use | 根據 README，為 browser_exec和 browser_screenshot |
| Manus 代理程式上在本機註冊的工具 | 包含瀏覽器工具 | PythonExecute、StrReplaceEditor、AskHuman、Terminate——瀏覽器工具透過 MCP 到達 |
| 相依套件固定版本 | 固定於 requirements.txt中 | 沒有 browser-use項目；由 uvx在執行時擷取，因此瀏覽器堆疊獨立於您的 checkout 而浮動 |
| 憑證 | 您的模型金鑰 | 本機模式不需要金鑰。雲端模式是獨立的 Browser Use帳戶，具有自己的環境變數 |
| 關閉方式 | 移除工具 | OPENMANUS_DISABLE_BROWSER_USE=1 |
因此，今天修正這個確切字串的方法是更新您的 checkout，並停止根據針對舊儲存庫路徑撰寫的教學進行推理。有一項值得明確說明而不是猜測的注意事項：MCP 連線失敗時，app/agent/manus.py會記錄 Failed to connect to Browser Use CLI 3.0並繼續使用四個本機工具，這會讓模型仍能指定未註冊的瀏覽器工具。這實際上是否會產生 Unknown tool訊息，以及會以哪個名稱出現，本文未觀察到——請把它視為可檢查之處，而不是有文件記載的症狀。另請注意，requirements.txt固定 uv>=0.6.0；一般安裝是否會將 uvx放在您的 PATH上，本文未予驗證。
搜尋時仍會找到一件事，而以上段落刻意沒有聲稱這件事：儲存庫確實包含預設路徑永遠不會載入的瀏覽器程式碼。獨立的 Daytona-sandbox 入口點 sandbox_main.py會建立一個 SandboxManus代理程式，從 app/tool/sandbox/sb_browser_tool.py註冊 SandboxBrowserTool作為本機工具——名稱是 sandbox_browser，而不是 browser_use。因此，「沒有本機瀏覽器工具」是指您從 main.py取得的預設 Manus代理程式，而不是指整個樹狀目錄。
搜尋時要分開看待的一個名稱：OpenManus/OpenManus-RL是另一個組織中的獨立儲存庫，是強化學習研究專案，而不是代理程式執行環境的版本；其檔案配置與這兩種錯誤都無關。
不同 API 端點會改變和不會改變的內容
上述兩種症狀都是在 OpenManus 內部產生的，因此對於「換另一個提供者會修好嗎」這個問題，誠實答案是否定的。端點選擇會影響的是另一組相鄰的失敗；這些失敗很容易被誤認為上述兩種錯誤。
| 失敗 | 端點形狀？ | 首先要檢查的事項 |
|---|---|---|
| OpenManus 自己的 token 限制訊息 | 否——在傳送任何請求前就已引發 | 您的 max_input_tokens 值，以及您是否原本就打算設定它 |
Unknown tool | 否——模型名稱對應到未註冊的模型 | 該代理程式註冊了哪些工具，以及模型是否具備足夠強的工具呼叫能力 |
| 供應商拒絕，因內容長度超出限制 | 是 | 模型的內容視窗，以及 max_tokens 是否超出該限制 |
| 首次執行時的驗證或找不到模型錯誤 | 是 | 隨附的範例仍使用 Claude ID；Anthropic 已於 2026 年 2 月 19 日將其淘汰——詳見 OpenManus 定價與 API 設定 |
temperature 回傳 400 | 是 | OpenManus 對其兩個寫死的推理 ID 以外的每個請求都傳送 temperature，並且會傳送 temperature = 0.0 |
| 螢幕截圖悄悄地永遠未到達模型 | 部分是 | 視覺功能是透過與六個寫死的模型 ID 的精確字串比對來控管的，而其中所有 Anthropic 模型都已淘汰。設定頁面也涵蓋此主題 |
在第五列中，有一項專屬於此端點而非一般建議的第一方細節。對於宣告不支援這些參數的目錄模型，Kunavo 的分派器會在轉送前移除 temperature、top_p 和 top_k——目前包括 Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5——而且是在通訊協定切換處執行，因此任何重試嘗試看到的也是已移除欄位的本文。對其他所有模型，該欄位會依 OpenManus 傳送的原樣轉送。這會為這些模型移除一個特定的 400 錯誤；但不代表 OpenManus 已在此測試。Kunavo 尚未對 OpenManus 進行執行期測試，本頁也沒有任何相容性結果。
如果您是在權衡路由，而不是除錯單一問題，OpenAI 相容 API說明一般路徑會或不會傳遞哪些內容，LLM 閘道說明何時值得使用一個金鑰跨越多個模型系列，而 AI 成本最佳化說明已列出的最低費率與完成任務的最低成本之間的差異——這正是決定代理程式迴圈的區別。若要查看另一個用戶端的同類診斷，請參閱 找不到 OpenCode 供應商。
你是要設定 OpenManus，而不是修復它嗎？端點方面只需設定 [llm] 中的三個欄位：model、base_url 和 api_key。先從快速入門指南開始，對照聊天補全確認請求格式，並在準備好為金鑰儲值時建立 Kunavo 帳戶。試用時，請保留一條可正常運作的路由，並在變更其他任何設定之前，先執行一項範圍明確的任務。
常見問題
OpenManus 的 token 限制是多少？
預設沒有。OpenManus 自身的上限是 max_input_tokens 欄位；app/config.py 將其宣告為 Optional，預設值為 None，並描述為「unlimited」，而且任何隨附的設定範例中都沒有這個欄位——因此標準安裝不會觸發自身的權杖上限錯誤，您遇到的任何限制都來自提供者。實際設定後，LLM.check_token_limit() 會將 self.total_input_tokens + input_tokens 與它比較，因此它是整個執行過程的累計輸入預算，而不是針對每次請求的上下文檢查。它與模型的上下文視窗無關，也與 max_tokens 無關；後者限制單次回應，並在 config/config.example.toml 中預設為 8192。這三項內容都於 2026 年 9 月 21 日在 main 分支讀取。
為什麼 OpenManus 在報告 token 限制前會卡住？
因為限制錯誤會被重試，儘管註解聲稱不會。app/llm.py 中的三個 @retry 裝飾器——位於 ask、ask_with_images 和 ask_tool 上——都寫成 retry_if_exception_type((OpenAIError, Exception, ValueError))，尾端註解為「# Don't retry TokenLimitExceeded」。TokenLimitExceeded 繼承自 OpenManusError，而 OpenManusError 繼承自 Exception，因此單獨列出的 Exception 項目會比對到它，tenacity 便會重試，直到達到 stop_after_attempt(6) 的停止條件，並使用 wait_random_exponential(min=1, max=60) 退避。代理程式自身的處理器確認了這個形式：app/agent/toolcall.py 會檢查 isinstance(e.__cause__, TokenLimitExceeded)，這就是 tenacity RetryError 到達時的形式，之後才會印出「Maximum token limit reached, cannot continue execution」。修正方案存在但尚未合併：PR #1348 於 2026 年 8 月 10 日關閉且未合併，其重新提交版本 #1407 於 2026 年 9 月 21 日仍處於開啟且未合併狀態。這是從原始碼讀取的結果，並非透過執行程式重現。
如何修正 OpenManus 中的 Error: Unknown tool 'BrowserUseTool'？
更新您的程式碼工作副本，因為在目前的 OpenManus main 中不存在該類別。本機瀏覽器工具已於 2026 年 8 月 15 日在提交 ab8dfe43 和 05c5bbb1 中移除；app/tool/ 不包含 browser_use_tool.py，而整個程式碼樹中唯一出現 BrowserUseTool 字串的地方，是 app/agent/sandbox_agent.py 中的一行已註解程式碼。在 main.py 建立的預設 Manus 代理程式中，瀏覽器工作現在由以 uvx browser-use --cli-mcp 啟動的程序外 MCP 伺服器負責，並公開名為 browser_exec 和 browser_screenshot 的工具；獨立的 Daytona-sandbox 入口點 sandbox_main.py 仍會註冊自己的本機瀏覽器工具，名稱為 sandbox_browser。在問題 #789 的回報者當時執行的 2025 年 3 月程式碼版本中，原因是模型輸出了 Python 類別名稱，而不是已註冊的工具名稱；他們自己的記錄顯示，緊接著的下一步改為呼叫 browser_use 後便順利分派，結尾寫著「BrowserUseTool seems not work, but browser_use can」。該字串本身是通用的：app/agent/toolcall.py 對 available_tools.tool_map 中不存在的任何名稱都會傳回 f"Error: Unknown tool '{name}'"，因此今天對模型捏造的任何工具都會出現相同訊息。
問題 #789 修好了嗎？哪個 OpenManus 版本包含修正？
尚未修好，也沒有可引用的版本。問題 #789「Result: Error: Unknown tool 'BrowserUseTool'」於 2025 年 3 月 18 日提出，至 2026 年 9 月 21 日仍未關閉，標記為 inactive，共有三則留言——一則建議使用更強的模型、回報者同意嘗試，以及一個不活躍機器人。相關的 token 限制回報問題 #779「hitting token limit」於 2026 年 9 月 17 日由同一個不活躍機器人關閉，state_reason 為 not_planned，這是逾時而非修正。而且 OpenManus 沒有可命名的目前版本：僅有的三個標籤 v0.1.0、v0.2.0 和 v0.3.0 都在 2025 年 4 月 10 日的 34 秒內發布，此後沒有任何新標籤，因此所有人都執行未標記的 main。請引用提交日期，而不是版本號。
切換 API 提供者會修正 OpenManus 的 token 或工具錯誤嗎？
不會，而且這兩種失敗模式值得與真正涉及提供者端的失敗分開看待。上述 token-limit 訊息是在發送任何請求前，由 OpenManus 根據您自行設定的上限進行內部計算所產生，因此沒有任何端點能改變它。Unknown tool 訊息則由 OpenManus 的工具分派產生，原因是模型指定了未註冊的項目，這取決於模型能否準確呼叫工具；問題 #789 中唯一曾給出的建議，就是正因如此嘗試不同模型。不同端點確實會改變的事項包括：提供者端因上下文長度而拒絕請求時，會以 OpenAIError 而不是 TokenLimitExceeded 到達；全新的隨附範例設定會產生模型錯誤而不是 token 錯誤，因為其中仍指定了 Anthropic 於 2026 年 2 月 19 日退役的 Claude ID；此外，OpenManus 除了兩個寫死的推理 ID 外，總是傳送 temperature，而在供應商已棄用該參數的模型上，這會形成 400 類型的失敗。
OpenManus 計算 token 的方式與我的提供者相同嗎？
不相同。OpenManus 使用 tiktoken 在本機計算，而 LLM.__init__ 會在 try 中呼叫 tiktoken.encoding_for_model(self.model)，若發生 KeyError 則退回 cl100k_base。對於 Claude 或 Gemini ID，或任何 tiktoken 沒有預設值的閘道命名空間 ID，OpenManus 執行的預算是 cl100k_base 的估算，而不是提供者的計數；其 TokenCounter 也會加入自身的固定常數——每則訊息 4 個 token、2 個格式化 token、低細節圖像 85 個，以及每個高細節圖像圖磚 170 個。請以提供者帳戶記錄的用量核對，而不要以 OpenManus 記錄的總量核對。已於 2026 年 9 月 21 日在 main 分支確認，requirements.txt 固定 tiktoken~=0.9.0。
於 2026 年 9 月 21 日檢查，且未進行更廣泛的查核：app/llm.py、app/config.py、app/agent/toolcall.py、app/agent/manus.py、app/agent/base.py、app/agent/sandbox_agent.py、app/tool/sandbox/sb_browser_tool.py、sandbox_main.py、app/exceptions.py、requirements.txt、config/config.example.toml，以及分支 main 上的 README；app/tool/ 的目錄清單；已刪除瀏覽器工具的提交歷史；GitHub 中 issue #779 和 #789、其留言，以及 pull request #1348、#1391 和 #1407 的紀錄；儲存庫與版本發布中繼資料；以及 Anthropic 的模型淘汰頁面。未執行任何操作——未安裝、未執行 OpenManus、未重現任一錯誤，也未透過 OpenManus 對任何端點提出請求；因此本頁所有行為描述都來自閱讀來源，而非觀察到的失敗，也沒有報告成功的最小執行，因為根本未進行該操作。Kunavo token 費率來自即時目錄，所有美元數字都是示意性的 token 算術，而非量測所得的任務成本。