Manus AI 执行 Tools：Key 用 TaoToken 验证调用

1. Tools 是 Manus 的执行单元但 file_read、shell_exec、browser_navigate 都在等一条模型通道Manus 的 Tools 系列解析讲到第三篇把消息通知、文件读写、Shell 执行、浏览器操作、联网搜索、部署发布全部摊开在 JSON Schema 里。乍看是一份工具清单细看会发现每一条 function 定义都在强调同一件事Manus 不靠 Prompt 空想做事而是靠模型在合适的时机返回一次 tool_calls再由执行单元去接触真实文件系统、真实终端环境、真实浏览器页面。只要模型通道不畅file_read 读不到配置项shell_exec 启动不了进程browser_navigate 只能停在白屏。这就是我把 Key 验证环节放在 TaoToken 上的原因——TaoToken 提供统一 API 兼容通道去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key就能把 Tools 背后的 tool calling 请求真正跑通。原文把 Tools 分成 Message、File Processing、Bash/Shell、Browser-use、Web Search、Deploy、Other 几组。分组看着像功能分类实际上是按「与外部环境交互的强度」划分的Message 工具最轻只跟用户对话File 工具开始碰磁盘Shell 工具进入进程级操作Browser 工具接管页面渲染和控制台Deploy 工具直接把服务暴露到公网。越往后每一步都要求模型把 Tools 的 JSON Schema 消化成一次准确的参数返回。1.1 Message Tools 与 File Processing ToolsSchema 细节决定了 Agent 行为边界先看 Message Tools。message_notify_user 只有 text 和可选 attachments用来向用户推送进度、报告任务完成不需要等回复。message_ask_user 多了一个 suggest_user_takeover 字段枚举值是 none 或 browser。这个字段值得注意Manus 在执行浏览器流程时如果拿不准可以建议用户接管浏览器操作。它不是把控制权硬抛出去而是给用户一个明确的接管入口。这类「人机切换」设计比普通聊天框的「继续/中止」更细因为接手对象是浏览器页面不是一段对话。File Processing Tools 的参数定义更见功力。file_read 的 start_line 从 0 开始end_line 是开区间这意味着模型要像程序员一样理解切片语义file_find_in_content 需要传正则表达式file_find_by_name 需要传 glob 通配符file_write 提供 append、leading_newline、trailing_newline 三个开关能精确控制文件内容的拼接方式。Manus 把文件操作的粒度定义成这样说明它不是在玩玩具这些函数会被真实地调用在服务器上的某个绝对路径上。1.2 file_str_replace 要求模型先读后改上下文与计费都不能含糊真正要求模型「先看后写」的是 file_str_replace。它需要 old_str 与目标文件中的内容逐字匹配模型必须先 file_read 确认现状再生成 new_str 提交替换任何一个多余空格都会导致替换失败。这暴露了 Manus Tools 的核心依赖模型必须在足够大的上下文里保留文件原文同时准确生成差异。上下文窗口越大token 消耗越明显。如果只是拿官方默认配额跑一两个 Demo 还能撑住一旦连续修改多个配置文件额度消耗就会变得不可控。这也是用独立 Key 验证调用的第一个好处你能在控制台清楚看到每次 File 操作吃了多少 token而不是等月底账单来了才后悔。2. Bash/Shell Tools 的会话机制shell_exec 的 id 是理解 Manus 终端能力的钥匙2.1 五个 Shell 工具构成一个完整的进程管理闭环原文中 Bash/Shell Tools 一共有五个shell_exec、shell_view、shell_wait、shell_write_to_process、shell_kill_process。shell_exec 的参数是 id、exec_dir、commandid 标识一个唯一的 shell 会话exec_dir 要求绝对路径作为工作目录。这意味着 Manus 可以同时在多个会话里跑不同命令比如一个会话在执行 npm run build另一个会话在跑 pytest互不干扰。配合 shell_wait 的 seconds 参数和 shell_view 的查看能力这套工具能处理长时间运行的任务先 shell_exec 启动再 shell_wait 阻塞等待最后 shell_view 读取输出。shell_write_to_process 用于向交互式进程写输入并决定是否按 Enter比如安装脚本里的确认提示shell_kill_process 则处理卡死的进程。2.2 会话类工具最怕通道断连这也是验证 Key 的真正意义这五个工具联动起来模型扮演的是远程终端里的操作员发起、等待、读回、应答、必要时终止。每一步都是一次独立的模型推理。尤其 shell_wait 之后的 shell_view必须把前一轮命令的输出作为下一轮请求的一部分送回去模型才能判断下一步做什么。如果通道不稳、上下文截断或 function calling 返回异常这个循环就断了——你看到的不是 Manus 写错了代码而是命令跑完后没有下文。这里有一个常见误区以为 Tools 调用失败是模型指令写错了其实多半是底层 API 通道没有把上一轮的 tool result 正确送回模型。TaoToken 这类兼容通道的核心价值就在这里它按 OpenAI 兼容格式处理多轮 tool_calls 的输入输出让 shell_exec 之后的 shell_wait、shell_view 能在同一条 Key 下稳定衔接。验证 Key 时不要只发一句话测试至少要模拟「发起命令 → 读取输出 → 追加指令」三轮请求才能看出通道是否真的稳。3. Browser-use、Web Search 与 Deploy外延越大的 Tools 越依赖稳定 function calling3.1 browser_console_exec 能进浏览器控制台但协议与运行环境有边界Browser-use Tools 在原文里占了最大篇幅。browser_navigate 要求 url 必须带协议前缀browser_click 可以传元素 index 或坐标browser_input 需要 text 和 press_enter 两个必填字段browser_select_option 的 option 从 0 开始计数。这些细节都在说明同一件事模型要根据当前页面结构决定操作目标页面状态一变参数就要重新生成。browser_console_exec 允许在浏览器控制台执行 JavaScript唯一参数是 javascript。注意描述里明确说运行环境是浏览器 console不是 Node.js所以没有 require、module只能用页面上下文里的对象。browser_console_view 可以拉取控制台日志。对于调试登录态、检查 fetch 请求、验证页面脚本的开发者来说这两个工具组合起来就是一个可编程的浏览器调试器。配合 browser_press_key 的 ControlEnter 组合键Manus 能处理绝大多数网页交互。3.2 deploy_expose_port 会开公网端口Tools 越多单次请求的 token 越大Web Search Tools 里比较实用的是 info_search_webquery 按 Google 风格写 3-5 个关键词date_range 可以过滤过去一小时、一天、一周。它让 Agent 不依赖训练数据里的旧知识而是去搜索引擎拿最新页面——前提是模型能把「需要搜索什么」翻译成高质量 query。Deploy Tools 则暴露了更多执行边界deploy_expose_port 把本地端口映射成临时公网地址deploy_apply_deployment 支持 static 和 nextjs 两种部署类型。一个端口暴露的请求发出后后续还有网络访问等待、日志拉取、失败回滚等一连串工具调用。工具越靠后单次请求的 token 消耗越大。因为 Manus 要把当前页面内容、Shell 输出、搜索结果摘要全部塞进上下文再生成下一步的 tool_calls。如果模型通道的上下文窗口偏小或者按量计费的价格偏高验证成本会被显著放大。建议在用它跑完整 Browser/Deploy 流程前先看模型广场标注的上下文长度和价格再决定哪个模型承担 Tools 调用——这一步在 TaoToken 的模型广场上都能直接查到。4. 用 TaoToken 给 Manus 式 Tools 准备一条可验证的模型通道4.1 打开 TaoToken 创建 Key区分落地页与接口地址第一步是打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并登录在控制台创建一个 API Key复制后保存为 YOUR_API_KEY。注意落地页和接口地址是两回事人看的页面是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 填进工具的是 Base URL https://taotoken.net/api 末尾不要加 /v1也不要把落地页完整网址当成接口地址贴进去。Key 只和请求鉴权有关和模型 ID、Base URL 无关所以你可以用同一个 Key 在不同的 Agent 工具里切换模型。这样切模型时不需要重新申请 Key只需要改 model 字段。我通常会把 Key 存在环境变量里避免反复复制出错尤其当你有多个终端窗口同时验证时环境变量能减少粘贴带来的首尾空格问题。4.2 用 taotoken cc 发一次真实请求验证 Key 与模型 ID验证 Key 是否有效用 TaoToken 官方 CLI 最快。安装并执行npm install -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID命令里 -k 是 API Key-u 是 Base URL-m 是模型 ID。模型 ID 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场上列出的为准不同时间上线的模型 ID 不一样不建议凭记忆填某个带日期后缀或版本号的名字。如果执行后返回了正常的对话内容说明 Key、Base URL、模型 ID 三个字段全部匹配。4.3 在 Agent 客户端里填 Base URL 的三个字段如果你用的是 OpenAI 兼容的 Agent 客户端配置只需要三个字段base_url 填 https://taotoken.net/apiapi_key 填 YOUR_API_KEYmodel 填模型广场里的 ID。有些客户端会默认在 base_url 后面补 /v1如果遇到 404先检查你的 base_url 是否写成了 https://taotoken.net/api/v1正确写法是不带 /v1。从 Manus Tools 的角度看配置完成后你要观察的第一个指标不是有没有回复而是模型返回的 tool_calls 是否稳定连续。Manus 的 Message 工具是给用户看的File、Shell、Browser 工具是给外部环境看的中间这一层就是 API 通道。Key 配好后用 file_read 的 tools 定义发请求本质上是在验证这条链路的「最后一公里」——请求能进去、参数能出来、结果能回来。5. 验证 Tools 调用从 CLI 回包到控制台用量记录5.1 成功的标志是返回里出现 tool_callsCLI 返回一段正常对话只是说明 Key 有效。要验证 Manus 这类 Tools 调用还需要发一次带 tools 参数的请求。不必把整套 Manus Tools 全部塞进去挑一个典型就行比如 file_read 的定义观察模型返回的 tool_calls 里是否出现 namefile_read 和带 file 字段的 arguments。参考 OpenAI 兼容格式的回包结构大致如下{ choices: [ { message: { tool_calls: [ { function: { name: file_read, arguments: {\file\: \/etc/nginx/nginx.conf\} } } ] } } ] }如果返回了这样的结构说明这条通道支持 function callingManus 的 File Processing 和 Bash/Shell 类工具在同一套协议下都能跑通。5.2 排障对照401、404、把落地页当成 Base URL验证中可能遇到三个问题。第一是 401Key 前后多了空格或复制漏了字符回 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 重新创建一次粘贴时检查引号和不可见字符。第二是 404大概率是 Base URL 写成了 https://taotoken.net/api/v1 或直接贴了落地页网址改成 https://taotoken.net/api 后再试。第三是请求成功但回包里没有 tool_calls说明所选模型不支持函数调用或者请求里没有正确携带 tools 描述。换一个在模型广场标注支持 Tools 的模型再发起同样的请求。5.3 回 TaoToken 控制台对用量确认这次调用真实发生请求跑通后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台的用量页面找到刚才那次调用的时间点比对 prompt_tokens 与 completion_tokens。带 file_read 定义的请求会比普通聊天多出不少 prompt_tokens因为 Tools 的 JSON Schema 本身要占上下文。看到记录入账就说明这次验证不是 mock而是真实发生的模型调用。之后再用同一条 Key 去跑 shell_exec、browser_navigate你会发现 Manus 的 Tools 从 Schema 到执行之间差的不是代码而是一条能持续返回 tool_calls 的稳定通道。