用 Clawdbot 实现联网搜索：通用接入方案与排障

TL;DR

• 我这里将“联网搜索”定义为：Subagent 调用外部搜索服务（API 或自建元搜索）拿到结果列表，再由主/子 agent 摘要与引用；不是“让模型自己在浏览器里点开网页”。
• 你给的是小红书短链与截断内容，我无法在线核验其具体做法；下文按通用 Agent/tool-calling 方式给出可落地的实现与排障路径，待你补 repo/配置后可精确对号入座。
• 你“为什么不行”最常见三类原因：没有可用的搜索后端/Key；运行环境禁止出站网络（DNS/代理/证书/防火墙）；工具未注册到 Subagent 或返回结构不符合解析/路由条件未触发。
• 最快验证路径：先在终端把搜索 API 单测通（拿到 JSON），再让 Clawdbot 仅调用工具并打印 raw result，最后才加网页抓取与答案生成/引用格式。

Key Insights

• “搜索(search)”与“抓取(fetch/read)”是两步：搜索解决“去哪儿找”，抓取解决“内容是什么”；只做搜索往往只有标题/摘要，不足以回答细节问题。
• 工具调用要稳定：明确输入/输出 JSON schema；对返回做字段校验、去重、排序（按域名、时间、相关性），避免模型在不确定结构上“脑补解析”。
• 可观测性决定排障速度：记录每次调用的 query、请求参数、HTTP 状态码、耗时、返回体截断，以及 Subagent 是否被路由命中/为何命中。
• 成本与合规要前置：直接爬搜索引擎网页常被 CAPTCHA；优先使用正规搜索 API 或自建元搜索；对网页抓取遵守 robots.txt、限制并发、避免落库敏感信息。

Playbook

1. 选一个“可控的搜索后端”并在同环境单测：Tavily/SerpAPI/Brave Search API，或自建 SearXNG；先用 curl/脚本确认出站访问、DNS、证书正常且能返回 JSON（请求参数以官方文档为准）。
2. 在 Clawdbot 中新增一个“Search Subagent + tool”：让该 Subagent 只负责 web_search(query, max_results)；输出固定结构如 {results:[{title,url,snippet}], source:"..."}，主 agent 再负责总结与引用。
3. 把“何时搜索”的策略写进系统提示词/路由规则：当问题包含“最新/今天/价格/对比/下载链接/报错信息/某产品是否支持某功能”时先搜索；并要求回答中给出 URL 引用列表，便于你肉眼验真。
4. 加固与回退：设置 10–20s 超时、2–3 次指数退避重试、缓存同一 query 的结果（SQLite/Redis/文件缓存）；当搜索失败时回退到“解释无法联网+给出离线替代方案+提示用户提供更多上下文/链接”。

Expert Views

• 开源 Agent 工程师（paraphrase）：先做“最小闭环”比追求全功能更重要；只要能稳定返回结构化结果，就能逐步叠加抓取、重排、引用格式与评测。
• DevOps/SRE（paraphrase）：多数“工具不工作”不是模型问题，而是网络与运行时问题；优先排查出站策略、DNS、代理、证书、容器网络、以及 API 配额/限流。
• 信息检索/搜索工程师（paraphrase）：结果质量取决于查询改写与重排；建议加入 query expansion（同义词/中英互译）、域名过滤、以及基于时间/权威性的 rerank。
• 数据隐私/合规顾问（paraphrase）：对外部网页内容应最小化存储；尽量只保留引用与必要片段，避免整页原文长期落库；对用户输入中的敏感信息做脱敏再发给第三方搜索服务。

Options

• 方案 A（本文默认定义）：使用搜索 API（Tavily/SerpAPI/Brave）实现“联网搜索”，返回结果列表；优点是稳定、低 CAPTCHA；缺点是需要 Key/可能付费。
• 方案 B：自建 SearXNG 作为元搜索后端（Clawdbot 走 HTTP 调用）；优点是可控与可审计；缺点是部署维护成本，上游引擎策略变化仍可能影响结果。
• 方案 C：如果 Clawdbot 支持 MCP/插件式工具：优先接入现成“搜索类 MCP server”；优点是集成标准化；缺点是需确认 Clawdbot 的协议与配置方式（目前无法在线核验）。
• 另一种“联网搜索”定义分支：如果你要的是“自动打开网页并阅读/翻页/登录”，则需要浏览器自动化（如 Playwright/Browserless）+ 内容抽取（Readability/Trafilatura），而不仅是搜索接口。

Evidence & Confidence

• “直接抓取主流搜索引擎网页易遇 CAPTCHA，优先使用搜索 API/元搜索”——high：业界常见现象，且存在成熟商用/开源替代。
• “实现应拆成 search 与 fetch/read 两步，并用结构化 schema 稳定工具输出”——high：通用 Agent 工程与 tool-calling 最佳实践。
• “你当前失败大概率与 Key/网络出站/工具注册与解析/路由不触发有关”——medium：缺少你的日志与环境信息，只能按高频故障推断。
• “Clawdbot 的具体配置项/是否支持 MCP/ Subagents 的精确写法”——low：缺少可核验的官方文档/仓库链接，小红书短链内容也无法在线核验。

Next Steps

• 请补充 4 样材料：Clawdbot 仓库 URL/版本号、运行方式（本地/容器/云函数）、你写的 Subagent/tool 配置片段、失败时完整日志（含 HTTP 状态码/超时）。
• 先确定一个后端：告诉我你更想用 Tavily、SerpAPI 还是自建 SearXNG（以及是否能付费/是否需要自托管），我会给出对应的最小请求与期望返回结构。
• 在 Clawdbot 中先做“只调用搜索并打印 raw JSON”的最小链路，确认通了再加“抓取正文+总结+引用”，避免一次集成太多导致无法定位问题。
• 若仍失败：按日志分层处理（网络层：DNS/代理/证书/超时；应用层：schema 不匹配/解析报错/路由不触发/限流），逐项给出你需要改的配置或代码位置。

Sources

• http://xhslink.com/o/1kLaGLQZeb2 （小红书短链，无法在线核验内容）
• https://docs.tavily.com/
• https://serpapi.com/
• https://github.com/searxng/searxng