[ blog · tutorial ]8 min read

给 n8n AI Agent 接上实时网页搜索

Sarah Choy·发布于 2026年9月23日·约 8 分钟阅读

n8n 没有内置的网页搜索节点，而大家常用的两种绕法，在 AI Agent 驱动下表现差别很大。本文讲清 HTTP Request Tool 路线、子工作流路线，以及那个把多数人打回论坛的失败模式。

一句话总结

• •n8n 没有原生网页搜索节点——要么用 HTTP Request Tool，要么用子工作流工具，自己接一个。
• •HTTP Request Tool 用的是它自己的占位符机制；$fromAI() 是更新的表达式，在这个节点里目前并不可靠。
• •子工作流路线（Call n8n Workflow Tool）配置慢一些，但能用上 $fromAI()、重试分支，内部还是普通的 HTTP Request 节点。
• •两条路都指向 POST https://www.apipick.com/api/search/web，带 x-api-key 头——每次 15 额度，仅 HTTP 200 扣费。
• •失败不计费这点在 n8n 里尤其重要：Agent 循环一旦配错，往往要连着重试好几次才肯放弃。

n8n 为什么没有网页搜索节点？

因为搜索是厂商选择，不是平台原语。n8n 给了你 AI Agent 节点、一组工具子节点，以及一个 HTTP 逃生口，把选哪家搜索留给你自己决定。这个架构判断是对的，同时也解释了为什么每一个「n8n 网页搜索」的帖子，最后都以有人贴出一张 HTTP Request 节点截图收尾。

真正能让 Agent 自己决定搜什么（而不是你把查询词写死）的机制只有两个。本文两个都讲，而它们的差别比文档暗示的要大。

Agent 实际可用的是哪两条路？

HTTP Request Tool 怎么接？

先放一个 AI Agent 节点，然后把一个 HTTP Request Tool 挂到它的 Tool 连接点上，按下面配：

Method:        POST
URL:           https://www.apipick.com/api/search/web
Authentication: Generic Credential Type → Header Auth
  Name:        x-api-key
  Value:       pk_yourkey

Send Body:     on
Body Content Type: JSON
Specify Body:  Using JSON
JSON:
{
  "query": "{searchQuery}",
  "max_num_results": 5
}

然后翻到 Placeholder Definitions，加一行：

Name:        searchQuery
Description: 要在实时网络上执行的搜索词。按普通人往搜索框里敲的方式写——
             不要用操作符，不要加引号，不要写 site: 过滤。

这段描述就是模型为这个参数看到的全部提示。这里写得含糊，是「Agent 把用户的问题五个字原样拿去搜」的头号成因。

最后在 AI Agent 节点的系统提示里，告诉它什么时候该伸手拿这个工具：

你有一个 web_search 工具。只要答案依赖训练截止之后的信息、依赖价格、
依赖新闻，或者依赖任何一个正常人会打开浏览器去查的东西，就调用它。
引用你用到的 URL。如果搜索没返回有用的东西，就直说——不要猜。

$fromAI 的坑是什么？

在 n8n 的 AI 工具体系里，其他地方填动态值都用 {{ $fromAI('query', '搜索词', 'string') }}：表达力强、自带说明、有类型。但它不是 HTTP Request Tool 用的那套机制，把它塞进那个节点，一直是「Agent 一调用就执行失败」的常见来源。

子工作流路线怎么搭？

1. 新建一个工作流。第一个节点选 When Executed by Another Workflow，定义一个输入字段 query（string）。
2. 第二个节点是普通的 HTTP Request 节点——POST 到 https://www.apipick.com/api/search/web，Header Auth 用 x-api-key，JSON 体 { "query": "{{ $json.query }}", "max_num_results": 5 }。
3. 第三个节点用 Code 或 Set，把响应压扁成模型真正需要的三个字段：标题、URL、摘要。这一步正是 HTTP Request Tool 给不了你的。
4. 保存。回到 Agent 工作流，挂一个 Call n8n Workflow Tool 节点指向它，query 字段填 {{ $fromAI('query', '要在实时网络上执行的搜索词', 'string') }}。

第 3 步那个压扁动作，单凭它自己就值回多花的五分钟。原始搜索负载里带着一堆字段，模型会老老实实花 token 读完，然后一个都用不上。

// Code 节点 —— 只留三个字段，其余丢掉
return $input.all().flatMap(item =>
  (item.json.results ?? []).map(r => ({
    json: { title: r.title, url: r.url, snippet: r.snippet }
  }))
);

失败和成本怎么处理？

n8n 里一个工具配错了的 Agent，不会只失败一次——它会失败、重新考虑、再调一次，一次执行里往往要来三四轮。按次订阅计费时这是一笔明账；而在仅成功计费下它是免费的：额度只在 HTTP 200 时扣，头写错拿到的 401、体写错拿到的 400，都是零成本。

不过有两样还是该设：

• 超时。把 HTTP 节点的超时设在 Agent 循环能熬过去的量级——20 秒对一次搜索已经很宽裕，也还给模型留了自救的余地。
• 在源头限制条数。max_num_results 取值 1–5，默认 5。多要几条结果很少能让答案更好；对最好的那两个 URL 追一次 Extract 通常可以。

同一把 key 还能挂什么？

同样的请求头、同样的计费模型覆盖了整个目录，所以第二个工具就是把第一个复制一份、换个路径。在 n8n 工作流里出现最多的三个：

• News Search——POST /api/search/news，用于简报与监控类工作流。完整示例见早报 Agent 那篇。
• URL Extract——POST /api/extract，每个 URL 2 额度，用于「搜完再读」这一步。
• Academic Search——POST /api/search/academic，5 额度，适合研究而非新闻类的工作流。

如果你还在选厂商而不是接一个已经选定的，2026 网页搜索 API 横评把各家的取舍讲全了。先拿一把免费 key——100 额度，不用卡。

作者

Sarah Choy

CEO, API Pick

Sarah Choy 是 API Pick 的 CEO，专注于为 AI Agent 与 LLM 工作流构建可用于生产的 API。