OpenManus 默认不强制执行令牌限制。其自身的上限是 max_input_tokens，app/config.py 将其声明为 Optional，默认值为 None，描述为“Maximum input tokens to use across all requests (None for unlimited)”，并且该字段没有出现在任何随附的配置示例中。因此，标准安装永远不会触发自身的令牌限制错误——你遇到的任何限制都来自提供商。当你设置该字段后，它会以两种人们意想不到的方式运行，而当前 main 中存在的缺陷会使其缓慢失败，而不是快速失败。
本页面涵盖的另一个错误 Error: Unknown tool 'BrowserUseTool' 根本不是当前存在的 bug。它所指的类已于 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 路径现在只是一个说明项目已迁移的占位 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 上限已达到。没有发送请求 |
| 一条提及模型名称的上下文长度或令牌错误 | 你的提供商，通过 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}'"。其中没有任何内容专门针对浏览器，因此模型臆造任何工具时都会出现相同字符串。
令牌限制是选择启用的、累积的，并且是近似值
三个不同的数字都被称为“令牌限制”，而错误消息始终只涉及其中一个。
| 设置 | 它限制的内容 | 默认值 | 随附示例中有吗？ |
|---|---|---|---|
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 限制累积输入，它会直接转化为单次运行输入部分的成本上限。下面的数值是基于所述上限的示例性令牌算术，不是测得的任务成本，也不是账单上限：它们按照实时Kunavo 目录中的每百万令牌费率，为该设置所限制的输入令牌定价。输出完全不受该设置覆盖——最后一列按照示例配置发布的 max_tokens = 8192 为单次响应定价，而一次二十步的运行可能产生二十次响应。
| 模型 | 每 1M 个令牌的输入 / 输出 | 输入达到 100,000 上限 | 输入达到 400,000 上限 | 一次 8,192 令牌响应 |
|---|---|---|---|---|
| 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 计数，它所强制执行的上限与提供商计费的令牌是两种不同的度量——设置该数字是为了限制失控循环，然后根据账户实际记录的内容进行核对。Kunavo 目录金额是计费底线而不是上限：上游报告费用后，账单取目录成本与上游成本乘以适用加价两者中的较大值。Kunavo 的最低充值金额是$10 的预付余额，这是资金最低要求，而不是任务费用或订阅费用——请参阅账单详情。
为什么令牌错误会延迟出现
这是当前 main 中可以从代码读出的缺陷，也是令牌限制失败感觉像卡住的原因。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 的原因，只确认它们未合并。历史报告 issue #779 “hitting token limit” 创建于 2025 年 3 月 17 日，于 2026 年 9 月 17 日被不活跃机器人以 state_reason: not_planned 关闭——这是超时，而不是解决。在其中一个修复落地前，实际可行的缓解措施是保持 max_input_tokens 未设置，让提供商拒绝过大的请求，或设置它并接受延迟。
Unknown tool 'BrowserUseTool' 是来自一个已不存在版本的错误
Issue #789“Result: Error: Unknown tool 'BrowserUseTool'”创建于 2025 年 3 月 18 日，截至 2026 年 9 月 21 日仍处于开放状态，标记为 inactive。其原因从来不是端点或密钥。报告者自己的日志显示，模型输出了 Python 类名 BrowserUseTool，而注册的工具名是 browser_use；在同一次运行中，下一步改为调用 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 代理中，一个进程外 MCP 服务器通过 uvx browser-use --cli-mcp 启动 |
| 注册名称 | browser_use | 根据 README，为 browser_exec 和 browser_screenshot |
| Manus 代理上本地注册的工具 | 包含浏览器工具 | PythonExecute、StrReplaceEditor、AskHuman、Terminate——浏览器工具通过 MCP 到达 |
| 依赖项固定 | 在 requirements.txt 中固定 | 没有 browser-use 条目；由 uvx 在运行时获取，因此浏览器技术栈独立于你的代码检出 |
| 凭据 | 你的模型密钥 | 本地模式无需密钥。云模式是单独的 Browser Use 账户，并使用其自身的环境变量 |
| 关闭开关 | 移除工具 | OPENMANUS_DISABLE_BROWSER_USE=1 |
因此，今天针对这一确切字符串的修复是更新你的代码检出，并停止依据针对旧仓库路径编写的教程进行推理。有一点需要明确说明，而不是凭猜测补充：当 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_main.py 会构建一个 SandboxManus 代理，从 app/tool/sandbox/sb_browser_tool.py 注册 SandboxBrowserTool 作为本地工具——名称为 sandbox_browser，而不是 browser_use。因此，“没有本地浏览器工具”指的是你通过 main.py 获得的默认 Manus 代理，而不是整个代码树。
搜索时需要区分的一个名称：OpenManus/OpenManus-RL 是另一个组织中的独立仓库，是一个强化学习研究项目，而不是代理运行时的某个版本，其文件布局无法说明上述任一错误。
不同 API 端点会改变和不会改变的内容
上面的两种症状都在 OpenManus 内部产生，因此对于“换一个提供商能修复它吗”，诚实答案是否定的。端点选择会影响的是一组相邻的故障，而这些故障很容易被误读成上述两种故障。
| 失败 | 端点形状？ | 首先检查什么 |
|---|---|---|
| OpenManus 自身的令牌限制消息 | 否——在发送任何请求前就已引发 | 你的 max_input_tokens 值，以及你是否本来就打算设置它 |
Unknown tool | 否——模型指定了一个未注册的名称 | 该代理注册了哪些工具，以及模型的工具调用能力是否足够强 |
| 提供商拒绝了上下文长度 | 是 | 模型的上下文窗口，以及 max_tokens 是否超出该窗口 |
| 首次运行时出现身份验证错误或找不到模型错误 | 是 | 随附的示例仍指定了一个 Claude ID，而 Anthropic 已于 2026 年 2 月 19 日将其停用——详见 OpenManus 定价与 API 设置 |
temperature 返回 400 | 是 | OpenManus 会在每次请求中发送 temperature（其两个硬编码推理 ID 除外），并附带 temperature = 0.0 |
| 屏幕截图悄无声息地始终未到达模型 | 部分如此 | 视觉能力取决于与六个硬编码模型 ID 的精确字符串匹配，而其中每个 Anthropic 模型都已弃用。设置页面也对此有说明 |
第五行有一项仅针对该端点、而非一般性建议的第一方细节。对于声明不支持这些参数的目录模型——目前为 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——Kunavo 的分发器会在转发前移除 temperature、top_p 和 top_k，并且是在协议切换处执行，因此任何重试尝试看到的也是移除字段后的请求体。对于其他所有模型，该字段都会按 OpenManus 发送的样子转发。这会为这些模型消除一个特定的 400 错误；但这并不表示 OpenManus 已在此处经过测试。Kunavo 未对 OpenManus 进行运行时测试，本页面的任何内容都不是兼容性结果。
如果你是在权衡路由，而不是调试单个路由，OpenAI 兼容 API介绍通用路径能传递和不能传递的内容，LLM 网关介绍何时值得用一个密钥覆盖多个模型系列，AI 成本优化介绍最低标价与完成任务的最低成本之间的差异——而这一区别决定了代理循环的成本。若要对另一客户端进行同类诊断，请参阅 找不到 OpenCode 提供商。
要设置 OpenManus，而不是修复它？端点侧在 [llm] 中需要填写三个字段：model、base_url 和 api_key。从 快速入门开始，对照 聊天补全检查请求结构，准备为密钥充值时再创建 Kunavo 账户。尝试期间保留一条可用路由，并先运行一个有边界的任务，再更改其他内容。
常见问题
OpenManus 的令牌限制是多少？
默认情况下没有。OpenManus 自身的上限是 max_input_tokens 字段，app/config.py 将其声明为 Optional，默认值为 None，并描述为“无限制”；该字段也没有出现在任何随附的配置示例中——因此，标准安装永远不会触发自身的令牌限制错误，你遇到的任何限制都来自提供商。当你设置该字段后，LLM.check_token_limit() 会将 self.total_input_tokens + input_tokens 与它进行比较，因此它是整个运行过程的累积输入预算，而不是每个请求的上下文检查。它与模型的上下文窗口无关，也与 max_tokens 无关；后者限制单次响应，并在 config/config.example.toml 中以 8192 发布。以上三项均于 2026 年 9 月 21 日在 main 分支读取。
为什么 OpenManus 在报告令牌限制之前会卡住？
因为即使注释声称不会重试，该限制错误仍会被重试。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 随后按 wait_random_exponential(min=1, max=60) 进行退避重试，直到达到 stop_after_attempt(6) 规定的总计六次尝试上限。代理自身的处理器也确认了这一结构：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_main.py 仍注册自己的本地浏览器工具，名称为 sandbox_browser。在 issue #789 报告者运行的 2025 年 3 月代码中，原因是模型输出了 Python 类名，而不是已注册的工具名——他们自己的日志显示，下一步改为调用 browser_use 后便正常分发，结尾写着“BrowserUseTool seems not work, but browser_use can”。该字符串本身是通用的：对于 available_tools.tool_map 中缺失的任何名称，app/agent/toolcall.py 都会返回 f"Error: Unknown tool '{name}'"，因此如今模型臆造任何工具时都可能出现相同消息。
issue #789 修复了吗？哪个 OpenManus 版本包含修复？
没有修复，也没有可引用的版本。issue #789“Result: Error: Unknown tool 'BrowserUseTool'”于 2025 年 3 月 18 日创建，截至 2026 年 9 月 21 日仍处于开放状态，标记为 inactive，共有三条评论——一条建议使用更强的模型，报告者同意尝试，以及一条不活跃机器人评论。相关的令牌限制报告 issue #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 的令牌或工具错误吗？
不能，而且这两种故障模式都应与真正具有提供商特征的故障区分开来。上面提到的令牌限制消息，是 OpenManus 在发送任何请求之前根据你自己配置的上限进行自身计数产生的，因此任何端点都无法改变它。Unknown tool 消息则由 OpenManus 的工具分发产生，原因是模型命名了未注册的工具，这是模型工具调用保真度的问题；issue #789 中唯一给出的建议正是尝试不同模型。不同端点会改变的情况包括：提供商侧的上下文长度拒绝会以 OpenAIError 而不是 TokenLimitExceeded 到达；使用随附示例配置的新副本会产生模型错误而不是令牌错误，因为其中仍然指定了 Anthropic 于 2026 年 2 月 19 日停用的 Claude ID；此外，除两个硬编码的推理 ID 外，OpenManus 始终发送 temperature，因此在提供商已弃用该参数的模型上会产生类似 400 的失败。
OpenManus 计算令牌的方式与我的提供商相同吗？
不相同。OpenManus 使用 tiktoken 在本地计数，LLM.__init__ 会在 try 中调用 tiktoken.encoding_for_model(self.model)，遇到 KeyError 时回退到 cl100k_base。对于 Claude 或 Gemini ID，或任何 tiktoken 没有预设的网关命名空间 ID，OpenManus 强制执行的预算是 cl100k_base 估算值，而不是提供商的计数；其 TokenCounter 还会加入自身的固定常量——每条消息 4 个令牌、2 个格式令牌、低细节图像 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 的令牌费率来自实时目录，每个美元金额都只是示例性令牌算术，而不是实测任务成本。