1. 为什么你的 OpenClaw 智能体总是“搜得到、读不懂”
如果你正在给 OpenClaw 智能体接联网能力，大概率遇到过这种场景：模型能返回一串搜索结果，标题摘要看着都对，但让它基于这些内容做判断时，回答就开始飘——要么把两条不相干的新闻拼在一起，要么引用了一个根本不存在的数字。问题不在模型本身，而在于你只给了它 Web-Search 的摘要，没给它 Web-Fetch 的原文。
Web-Search 和 Web-Fetch 是 OpenClaw 工具体系里最容易混淆的一对工具。前者输入自然语言查询词，交给搜索引擎做全网检索，输出的是标题、摘要、URL 列表，本质是“发现资源”；后者输入一个确定的 URL，访问页面、清洗广告导航、提取正文转成 Markdown，再送进模型上下文，本质是“精读页面”。一个负责广域探索，一个负责深度挖掘，顺序不能反，职责不能混。
这篇内容面向需要把这两个工具写进 TOOLS.md 的开发者。我会给出一份可直接复制的配置骨架，包含调用顺序约束、权限边界、并发上限和验证动作，确保工具注册后能被智能体正确调用。你不需要先理解 OpenClaw 的全部架构，只要跟着把 TOOLS.md 写对，再跑一次验证请求，就能看到 Search 找链接、Fetch 读原文、模型做决策的完整链路。
2. 前置准备：TaoToken 接入与 OpenClaw 工具链的关系
OpenClaw 的工具体系本身不绑定某一家模型服务，它通过统一的 API 层调用大模型。我实测下来，用 TaoToken 作为模型接入层比较省事，因为它同时提供 OpenAI 兼容接口和 Anthropic 兼容接口，OpenClaw 里配置 base_url 和 api_key 就能跑通，不用为不同模型改两套代码。
你需要先拿到一个可用的 API Key。打开 https://taotoken.net/api-keys ，登录后创建一个 Key，复制保存。注意这个 Key 只在创建时完整显示一次，后面配置进 OpenClaw 的 config 或环境变量里。
TaoToken 的 API 根地址是 https://taotoken.net/api ，不带任何查询参数。OpenClaw 的模型配置里通常填这个作为 base_url，再拼上 /v1/chat/completions 或 /v1/messages 这样的路径。如果你用的是 Claude 系列模型做智能体主脑，走 Anthropic 兼容格式会更顺，具体路径参考 https://taotoken.net/doc 里的接入说明。
这里要区分两件事：模型接入是“智能体的大脑”，Web-Search 和 Web-Fetch 是“智能体的手”。TOOLS.md 管的是手的动作规范，不负责模型鉴权。但两者必须同时配好，否则工具注册了也调不动，因为模型请求本身会失败。建议先把模型对话跑通，确认 Key 和 base_url 没问题，再写 TOOLS.md。你可以用 https://taotoken.net/chat 快速验证模型是否正常响应，确认后再进入工具配置环节。
3. 可复制的 TOOLS.md 配置骨架
TOOLS.md 是 OpenClaw 读取工具规则的入口文件，它不定义工具的实现代码，而是用自然语言加结构化约束告诉智能体：什么情况下用哪个工具、调用顺序是什么、权限归谁、并发上限多少。下面这份骨架可以直接复制到你的项目根目录，按实际业务改工具名和阈值。
# TOOLS.md - Web-Search 与 Web-Fetch 调用规范 ## 1. 工具清单 ### 1.1 Web-Search - 入参：query（自然语言搜索词） - 输出：候选网页列表，含 title、snippet、url - 定位：发现资源、缩小信息范围 - 适用：不知道准确来源、查实时资讯、探索性调研 ### 1.2 Web-Fetch - 入参：url（单个精准链接） - 输出：清洗后的正文 Markdown - 定位：精读指定页面、深度提取 - 适用：研读官网文档、政策原文、技术手册、提取表格 ## 2. 调用顺序约束 2.1 必须优先执行 Web-Search 获取候选 URL，再按需调用 Web-Fetch 精读。 2.2 禁止无目的批量 Fetch，禁止跳过 Search 直接猜测 URL 并 Fetch。 2.3 单次任务中，Web-Fetch 最多同时处理 3 个网页，防止上下文过载。 2.4 Search 返回结果后，模型需先筛选高价值链接，再决定 Fetch 哪些。 ## 3. 权限约束 3.1 仅主 Agent 可调用联网工具。 3.2 子 Agent 只能提出联网需求，由主 Agent 代为执行。 3.3 内网地址、需要登录鉴权的页面，禁止调用 Web-Search 和 Web-Fetch。 ## 4. 结果处理约束 4.1 Web-Search 的摘要仅用于筛选链接，不得直接作为最终结论依据。 4.2 Web-Fetch 的正文作为上下文送入模型分析、总结、提炼。 4.3 精读后形成的长期业务知识，由 MemoryEditor 写入 MEMORY.md。 4.4 已写入 MEMORY.md 的内容，后续任务不必重复联网查询。 ## 5. 异常处理 5.1 Fetch 返回空正文或 403/404 时，标记该 URL 失败，不重试超过 1 次。 5.2 Search 无结果时，允许改写 query 重试一次，仍无结果则终止联网。 5.3 页面为 JS 动态渲染导致正文为空时，记录限制，不强行解析。这份骨架的关键在于第 2 节和第 3 节。调用顺序约束防止模型“先 Fetch 再 Search”这种反逻辑操作；权限约束防止子 Agent 乱开联网口子导致 Token 失控。第 4 节把 Search 摘要和 Fetch 正文的用途分开，避免模型拿摘要当结论。第 5 节是排障兜底，后面会展开。
写进 TOOLS.md 后，OpenClaw 在组装系统提示时会读取这个文件，把规则注入模型上下文。你不需要改工具的实现代码，规则层就能约束行为。
4. 验证请求：确认工具注册后可被正确调用
配置写完不代表生效，必须跑一次验证请求。我通常用一个“先 Search 再 Fetch”的复合任务来测，因为单步调用测不出顺序约束是否生效。
在 OpenClaw 的对话入口或 API 调用里，发一条这样的指令：
请查询 OpenClaw 官方文档中关于工具注册的说明。 要求：先用 Web-Search 找到候选链接，筛选后最多 Fetch 2 个页面， 基于 Fetch 到的正文总结工具注册的三个关键步骤。观察返回结果里是否出现这些信号：第一，模型先输出了搜索动作和候选 URL 列表；第二，模型明确说了“筛选后选择以下链接进行精读”；第三，Fetch 结果里有正文片段而不是只有标题；第四，最终总结基于正文而非摘要。
如果模型直接开始编造步骤，没有调用 Search，说明 TOOLS.md 没被读取，检查文件路径和 OpenClaw 的配置项是否指向了它。如果模型调用了 Search 但没 Fetch，检查第 2.1 条约束是否写得太弱，可以改成“必须执行 Fetch 后才能给出结论”。
验证通过后，你可以再测一次权限约束：让子 Agent 发起联网请求，看它是否被主 Agent 拦截。这一步能确认第 3 节的权限规则真正生效。
5. 本篇常见错排查
5.1 Fetch 返回空正文
最常见的原因是目标页面是 JS 动态渲染。Web-Fetch 只能抓静态 HTML，遇到 React、Vue 这类前端渲染的页面，拉下来的 HTML 里没有正文。排查方法：用 curl 直接拉一次页面，看返回的 HTML 里有没有实际内容。如果没有，说明这个页面不适合 Fetch，换静态文档源或官方 API。
5.2 Search 有结果但 Fetch 全部 403
部分站点对非浏览器请求做了拦截。Web-Fetch 的请求头如果没带 User-Agent 或 Referer，容易被拒。检查 OpenClaw 的 Fetch 工具配置里是否允许自定义请求头。如果站点有公开 API 或 RSS，优先走 API，不要硬抓页面。
5.3 模型跳过 Search 直接 Fetch
这是 TOOLS.md 约束不够硬导致的。把第 2.1 条从“必须优先执行”改成“禁止在未执行 Web-Search 的情况下调用 Web-Fetch”，并在系统提示里重复一次。模型对“禁止”类指令的遵循度通常高于“必须”类。
5.4 Token 消耗异常高
检查第 2.3 条的并发上限是否生效。如果模型一次 Fetch 了 5 个以上页面，上下文会被正文塞满，后续推理变慢且容易丢重点。把上限压到 3，并在 Fetch 后加一步“正文摘要压缩”，只保留与任务相关的段落。
5.5 子 Agent 绕过权限调用联网
确认 TOOLS.md 第 3 节是否被主 Agent 的调度逻辑读取。有些 OpenClaw 版本需要把权限规则同时写进主 Agent 的 system prompt 和 TOOLS.md，双写才生效。另外检查子 Agent 的工具白名单里是否误放了 Web-Search。
6. 把联网能力接进长期编码与 Agent 工作流
Web-Search 和 Web-Fetch 配好之后，真正的价值在于把它们嵌进长期运行的 Agent 工作流。比如你让 OpenClaw 持续跟踪某个技术栈的更新，Search 负责发现新文档，Fetch 负责精读变更日志，MemoryEditor 把结论写进 MEMORY.md，后续任务直接读记忆，不再重复联网。这条链路跑顺了，Token 消耗会明显下降。
如果你要跑的是长时间编码任务或常驻 Agent，建议用 Coding Plan 这类按周期计费的方案，比按次调用更划算，配置入口在 https://taotoken.net/coding-plan 。模型对话的快速验证走 https://taotoken.net/chat ，API Key 管理在 https://taotoken.net/api-keys ，接入细节和路径说明看 https://taotoken.net/doc 。Claude Code 相关的 Anthropic 兼容配置参考 https://taotoken.net/claude-code 。
最后提醒一个实操细节：TOOLS.md 改完后，OpenClaw 可能需要重启或重新加载配置才会生效。我踩过的坑是改完文件直接发请求，结果模型还在用旧规则，排查了半天才发现是缓存。每次改完 TOOLS.md，先重启一次再验证，能省很多时间。
