Giới hạn token của OpenManus và lỗi Unknown BrowserUseTool: một lỗi vẫn còn, một lỗi đã biến mất

OpenManus mặc định không áp dụng giới hạn token. Giới hạn riêng của nó là max_input_tokens, được app/config.py khai báo là Optional với giá trị mặc định None và mô tả “Maximum input tokens to use across all requests (None for unlimited)”, đồng thời không xuất hiện trong bất kỳ ví dụ cấu hình nào được đóng gói. Vì vậy, bản cài đặt mặc định không bao giờ tự tạo lỗi giới hạn token — bất kỳ giới hạn nào bạn gặp đều đến từ nhà cung cấp. Khi bạn đặt trường này, nó hoạt động theo hai cách mà mọi người thường không ngờ tới, và một lỗi có trong main hiện tại khiến nó thất bại chậm thay vì nhanh.

Lỗi còn lại mà trang này đề cập, Error: Unknown tool 'BrowserUseTool', thực ra hoàn toàn không phải lỗi đang xảy ra. Lớp mà nó đề cập đã bị xóa khỏi OpenManus vào ngày 15 tháng 8 năm 2026, và agent Manus mặc định trên main hiện tại không đăng ký công cụ trình duyệt cục bộ. Không triệu chứng nào trong hai triệu chứng này liên quan đến khóa API, endpoint hay nhà cung cấp, và việc trỏ lại base_url cũng không khắc phục được chúng.

Một lưu ý về phạm vi trước khi bắt đầu. Không có phiên bản OpenManus nào để trích dẫn: ba tag duy nhất, v0.1.0, v0.2.0 và v0.3.0, đều được phát hành trong vòng 34 giây kể từ nhau vào ngày 10 tháng 4 năm 2025, và từ đó không có tag nào mới, nên mọi người đều chạy main chưa gắn tag. Kho lưu trữ chính tắc là FoundationAgents/OpenManus — chưa lưu trữ, giấy phép MIT, 58.371 sao, lần push gần nhất ngày 22 tháng 8 năm 2026 (GitHub API, ngày 21 tháng 9 năm 2026). Đường dẫn mannaandpoem/OpenManus cũ hiện chỉ còn README sơ lược nói rằng dự án đã chuyển đi, vì vậy các đường dẫn tệp và số dòng được trích dẫn trong các hướng dẫn năm 2025 trỏ đến mã không còn tồn tại. Mọi nội dung dưới đây được đọc trực tiếp từ mã nguồn trên nhánh main vào ngày 21 tháng 9 năm 2026 và không có nội dung nào được thực thi.

Bạn thực sự đang gặp thông báo nào trong bốn thông báo

Đoạn dispatch tạo ra hàng thứ ba chỉ gồm ba dòng và không bị thay đổi bởi bản viết lại trình duyệt năm 2026: name = command.function.name, sau đó là if name not in self.available_tools.tool_map: return f"Error: Unknown tool '{name}'". Không có phần nào trong đó dành riêng cho trình duyệt, nên cùng một chuỗi sẽ xuất hiện với bất kỳ công cụ nào do model tự tạo tên.

Giới hạn token là tùy chọn, cộng dồn và mang tính xấp xỉ

Ba con số khác nhau đều được gọi là "giới hạn token", nhưng thông báo lỗi chỉ liên quan đến một trong số đó.

Hàng thứ hai là điều khiến nhiều người bất ngờ. LLM.check_token_limit() trong app/llm.py trả về (self.total_input_tokens + input_tokens) <= self.max_input_tokens — một tổng đang chạy cho cả phiên, không phải phép kiểm tra đối với một request đơn lẻ. Vì vậy, một lần chạy agent dài sẽ chạm giới hạn do cộng dồn, ngay cả khi từng request riêng lẻ đều nhỏ; văn bản lỗi cũng nêu rõ phép tính: hiện tại, cần thiết, tối đa. Agent Manus mặc định đặt max_steps = 20, và mỗi bước gửi lại toàn bộ cuộc hội thoại cho đến thời điểm đó, nên con số cộng dồn tăng nhanh hơn số bước.

Con số này cũng là ước tính riêng của OpenManus. LLM.__init__ gọi tiktoken.encoding_for_model(self.model) và dùng cl100k_base dự phòng khi gặp KeyError, vì vậy với mọi model ID mà tiktoken không có preset — chẳng hạn ID của Claude hoặc Gemini, hay ID có namespace của gateway — ngân sách được thực thi chỉ là giá trị xấp xỉ, không phải số đếm của nhà cung cấp.

# 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

Một giới hạn đáng giá bao nhiêu tiền

Vì max_input_tokens giới hạn input cộng dồn, nó trực tiếp chuyển thành mức trần chi phí cho phía input của một lần chạy. Các con số dưới đây là phép tính token minh họa dựa trên mức trần đã nêu, không phải chi phí tác vụ được đo và cũng không phải mức trần hóa đơn: chúng định giá số token input bị cài đặt giới hạn, theo mức giá catalog Kunavo hiện hành trên mỗi triệu token. Output hoàn toàn không được cài đặt đó bao phủ — cột cuối định giá một response ở mức max_tokens = 8192 mà cấu hình mẫu cung cấp, và một lần chạy 20 bước có thể tạo ra 20 response như vậy.

Có hai cách hiểu. Giới hạn là điểm dừng, không phải ngân sách: nó cho biết phía input của một lần chạy có thể tốn tối đa bao nhiêu, nhưng không nói liệu tác vụ đã hoàn tất hay chưa. Ngoài ra, vì OpenManus đếm bằng tiktoken, giới hạn mà nó thực thi và số token nhà cung cấp tính phí là hai phép đo khác nhau — hãy đặt con số để giới hạn vòng lặp chạy mất kiểm soát, rồi đối chiếu với dữ liệu thực tế được ghi nhận trong tài khoản. Mức tiền trong catalog của Kunavo là mức sàn thanh toán thay vì mức trần: khi upstream báo chi phí, hóa đơn là giá catalog hoặc chi phí upstream nhân với mức markup áp dụng, lấy giá trị lớn hơn. Mức nạp tối thiểu của Kunavo là $10 tín dụng trả trước, là mức tối thiểu để nạp tiền chứ không phải phí tác vụ hay gói thuê bao — xem chi tiết thanh toán.

Vì sao lỗi token xuất hiện muộn

Đây là một lỗi có thể đọc thấy trong main hiện tại, và là lý do lỗi giới hạn token tạo cảm giác như bị treo. Cả ba decorator @retry trong app/llm.py — trên ask, ask_with_images và ask_tool — đều được viết giống hệt nhau:

Vòng lặp agent ở phía sau xác nhận cấu trúc này thay vì mâu thuẫn với nó. app/agent/toolcall.py bắt exception và kiểm tra isinstance(e.__cause__, TokenLimitExceeded) — việc tháo lớp bọc __cause__ đó là cách một RetryError của tenacity xuất hiện, và dòng log riêng của nó ghi "Token limit error (from RetryError)". Chỉ sau đó mã mới thêm thông báo hiển thị cho người dùng "Đã đạt đến giới hạn token tối đa, không thể tiếp tục thực thi" và đặt trạng thái agent thành finished. Nói cách khác, mã tiêu thụ đã mặc định rằng retry sẽ xảy ra, trái với điều mà bình luận của decorator nói.

Chưa có bản sửa nào được hợp nhất. PR #1348, có tiêu đề "fix: prevent needless retry of TokenLimitExceeded and fix search engine fallback", đã bị đóng mà chưa hợp nhất vào ngày 10 tháng 8 năm 2026; bản gửi lại của nó, #1407, vẫn đang mở và chưa được hợp nhất vào ngày 21 tháng 9 năm 2026. Một PR liên quan đến tràn ngữ cảnh, #1391, "add tool description token budget to prevent context overflow", đã bị đóng mà chưa hợp nhất vào ngày 18 tháng 8 năm 2026. Ở đây không đọc lý do maintainers đóng chúng, chỉ xác nhận rằng chúng chưa được hợp nhất. Báo cáo lịch sử, issue #779 "hitting token limit" từ ngày 17 tháng 3 năm 2025, đã bị bot do không hoạt động đóng vào ngày 17 tháng 9 năm 2026 với state_reason: not_planned — một lần hết thời gian, không phải cách giải quyết. Cho đến khi một trong các bản đó được hợp nhất, biện pháp thực tế là để max_input_tokens không được đặt và để nhà cung cấp từ chối request quá lớn, hoặc đặt nó và chấp nhận độ trễ.

Unknown tool 'BrowserUseTool' là lỗi từ một phiên bản không còn tồn tại

Issue #789, "Result: Error: Unknown tool 'BrowserUseTool'", được mở vào ngày 18 tháng 3 năm 2025 và vẫn mở vào ngày 21 tháng 9 năm 2026, với nhãn inactive. Nguyên nhân chưa bao giờ là endpoint hay khóa. Log của chính người báo cáo cho thấy model phát ra tên lớp Python, BrowserUseTool, trong khi tên công cụ đã đăng ký là browser_use — và ngay bước tiếp theo của cùng lần chạy đã dispatch thành công khi gọi browser_use. Log họ dán kết thúc ở "Activating tool: 'browser_use'", còn dòng kết luận của họ chính là toàn bộ chẩn đoán: "BrowserUseTool seems not work, but browser_use can". Lời khuyên duy nhất từ người bình luận là thử model mạnh hơn, đây là hướng trả lời phù hợp cho vấn đề độ chính xác khi gọi công cụ.

Chẩn đoán đó không áp dụng cho main hiện tại, vì không còn công cụ nào tên browser_use để gọi cho đúng. Vào ngày 15 tháng 8 năm 2026, các commit ab8dfe43 ("feat(browser): use Browser Use CLI 3.0") và 05c5bbb1 ("refactor(browser): use CLI 3.0 MCP server") đã xóa công cụ trình duyệt cục bộ. Danh sách thư mục của app/tool/ trên main không chứa browser_use_tool.py, và lần xuất hiện duy nhất còn lại của chuỗi BrowserUseTool trong cây thư mục là một dòng bị chú thích trong app/agent/sandbox_agent.py.

Vì vậy, cách sửa chính xác chuỗi này hiện nay là cập nhật bản checkout của bạn và ngừng suy luận dựa trên các hướng dẫn viết theo đường dẫn kho lưu trữ cũ. Có một điểm cần nêu rõ thay vì đoán: khi kết nối MCP thất bại, app/agent/manus.py ghi log Failed to connect to Browser Use CLI 3.0 rồi tiếp tục với bốn công cụ cục bộ, khiến model vẫn có thể gọi tên một công cụ trình duyệt chưa được đăng ký. Việc điều đó trên thực tế có tạo ra thông báo Unknown tool hay không, và dưới tên nào, chưa được quan sát ở đây — hãy xem đây là nơi cần kiểm tra, không phải triệu chứng đã được ghi nhận. Cũng lưu ý rằng requirements.txt ghim uv>=0.6.0; việc cài đặt thông thường có đưa uvx vào PATH của bạn hay không chưa được xác minh.

Một điều mà tìm kiếm vẫn sẽ trả về, và các đoạn trên cố ý không khẳng định: kho lưu trữ thực sự có mã trình duyệt mà đường dẫn mặc định không bao giờ tải. Entry point Daytona-sandbox riêng biệt sandbox_main.py tạo một agent SandboxManus đăng ký SandboxBrowserTool từ app/tool/sandbox/sb_browser_tool.py làm công cụ cục bộ — với tên sandbox_browser, không phải browser_use. Vì vậy, "không có công cụ trình duyệt cục bộ" là nhận định về agent Manus mặc định mà bạn nhận được từ main.py, không phải về toàn bộ cây mã nguồn.

Một tên cần phân biệt khi tìm kiếm: OpenManus/OpenManus-RL là một kho lưu trữ riêng trong một tổ chức riêng, là dự án nghiên cứu reinforcement learning chứ không phải phiên bản của runtime agent, và bố cục tệp của nó không cho biết gì về hai lỗi này.

Một endpoint API khác thay đổi và không thay đổi điều gì

Cả hai triệu chứng trên đều được tạo bên trong OpenManus, vì vậy câu trả lời trung thực cho câu hỏi "đổi nhà cung cấp có khắc phục được không" là không. Điều mà lựa chọn endpoint thực sự ảnh hưởng là một nhóm lỗi lân cận dễ bị nhầm với hai lỗi này.

Ở hàng thứ năm đó có một chi tiết riêng của bên thứ nhất, chỉ áp dụng cho endpoint này chứ không phải lời khuyên chung. Dispatcher của Kunavo loại bỏ temperature, top_p và top_k trước khi chuyển tiếp đối với các model trong catalog khai báo rằng chúng không hỗ trợ các tham số đó — hiện tại là 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 — và thực hiện việc này tại bước chuyển giao thức, nên phần body đã bị loại cũng là phần mà mọi lần retry nhìn thấy. Với mọi model khác, trường này được chuyển tiếp đúng như OpenManus đã gửi. Điều đó loại bỏ một lỗi 400 cụ thể đối với các model này; đây không phải khẳng định rằng OpenManus đã được kiểm thử tại đây. Kunavo chưa kiểm thử OpenManus trong runtime, và không có nội dung nào trên trang này là kết quả tương thích.

Nếu bạn đang cân nhắc các hướng đi thay vì gỡ lỗi một vấn đề cụ thể, API tương thích OpenAI trình bày những gì đường dẫn chung có và không truyền tải, gateway LLM trình bày khi nào một khóa dùng cho nhiều dòng model là đáng giá, còn tối ưu chi phí AI trình bày sự khác biệt giữa mức giá được niêm yết rẻ nhất và cách rẻ nhất để hoàn thành một tác vụ — đây là khác biệt quyết định đối với vòng lặp agent. Để xem chẩn đoán cùng loại trên client khác, hãy xem Không tìm thấy nhà cung cấp OpenCode.

Bạn đang thiết lập OpenManus thay vì sửa lỗi? Phía endpoint gồm ba trường trong [llm]: model, base_url và api_key. Bắt đầu từ hướng dẫn bắt đầu nhanh, kiểm tra hình dạng request với chat completions, và tạo tài khoản Kunavo khi bạn sẵn sàng nạp tiền cho một khóa. Hãy duy trì một route đang hoạt động trong khi thử nghiệm và chạy một tác vụ có giới hạn trước khi thay đổi bất kỳ điều gì khác.

Câu hỏi thường gặp

Đã kiểm tra ngày 21 tháng 9 năm 2026 và không kiểm tra rộng hơn: 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 và README trên nhánh main; danh sách thư mục của app/tool/; lịch sử commit của công cụ trình duyệt đã bị xóa; các bản ghi GitHub cho issue #779 và #789, bình luận của chúng, cùng các pull request #1348, #1391 và #1407; metadata của kho lưu trữ và bản phát hành; và trang ngừng hỗ trợ model của Anthropic. Không có nội dung nào được thực thi — không cài đặt, không chạy OpenManus, không tái hiện hai lỗi và không có request nào đi qua OpenManus tại bất kỳ endpoint nào — vì vậy mọi khẳng định về hành vi ở đây đều dựa trên việc đọc các nguồn chứ không phải lỗi được quan sát, và không có lần chạy tối thiểu thành công nào được báo cáo vì chưa có lần nào được thực hiện. Mức giá token của Kunavo lấy từ catalog hiện hành, và mọi con số dollar đều là phép tính token minh họa chứ không phải chi phí tác vụ được đo.