TL;DR:n8n 只需要一个 HTTP Request 节点就能与 Scrapeless 的 LLM Chat Scraper 通信 —— 无需写代码、无需 SDK。只要用一个节点向https://api.scrapeless.com/api/v2/scraper/execute发起 POST请求带上x-api-token头和 JSON 请求体回答会以数据形式返回到工作流后续节点可以直接读取。请求体仅包含 { actor, input }别的都不用。将请求体设为{actor:scraper.chatgpt,input:{prompt:…,country:US,web_search:true}}节点会返回{ status, task_id, task_result }—— 这是所有 Scrapeless LLM actor 统一使用的响应包。用 Schedule Trigger 把调用变成常驻监控。将Schedule Trigger → HTTP Request → IF → Set/Sheet/DB串联起来n8n 会按设定间隔重复执行这组 prompt并把每次的答案追加到表格或数据库中无需有人打开终端。IF 节点把“空结果”当作数据处理而不是错误。模型会按会话填充task_result所以某次运行返回空表示这次该查询没有结果 —— 在 IF 节点分支判断记录“无数据可存储”然后继续下一次定时运行会捕获到有数据的结果。MCP Client 节点是面向 agent 的替代方案。当你的工作流是一个 AI agent 而非固定管道时把 n8n 的 MCP Client 节点指向 Scrapeless MCP 服务器同样的抓取能力就变成 agent 可以自主调用的工具。---引言答案引擎作为工作流输入大型语言模型驱动的答案引擎现在夹在用户与开放网络之间——品牌关心的问题比如谁会被推荐、哪些来源被引用、页面显示什么价格等都在 ChatGPT 内部先得到回答用户还没点击任何页面。按计划定期读取这些表面信息是一个数据采集任务而 n8n 已经是许多团队运行定时数据任务的首选地点。阻力在于 ChatGPT 没有官方的答案 API用自动化工具驱动聊天 UI 会遇到登录墙、流式响应以及答案渲染后才在客户端解析的字段。n8n 的 HTTP Request 节点可以 call any REST endpoint但在渲染、住宅出口residential egress和解析在别处先完成之前它并没有可以直接调用的端点。Scrapeless 的 LLM Chat Scraper 就是那个“别处”一次 POST 请求就能把 rendered HTML answer以 JSON 返回这样 HTTP Request 节点就有了干净的目标端点后续工作流可以读取 structured JSON fields。本文展示了如何在不写代码的情况下把 n8n 接入该 actor — 一个 Schedule Trigger、一个 HTTP Request 节点、一个用于空运行的 IF 分支以及一个存储节点 — 并说明了当工作流需要把该 scraper 作为 AI 工具调用时的 agent-node 路径。若想看到各答案引擎 scraper 的排名视图the best LLM scrapers 将这些表面进行了并排比较。关于范围的说明下面的请求契约已经针对在线的scraper.chatgptactor 进行了验证且所有 n8n 参数名均已对照当前 n8n 节点参考确认。端到端工作流的描述基于这两部分经验证的数据——本文并未用截图来作为运行的证明。---你可以用它做什么定期答案监控。按小时或每天早晨运行一组固定的 prompt将每次 ChatGPT 的回答追加到表格中这样回答漂移就能以时间序列呈现而不是靠人工抽查。引用份额跟踪。读取task_result.search_result中 ChatGPT 参考的来源统计多次运行中各域名的出现频次查看模型在你关注的类别里持续引用哪些站点。品牌提及告警。根据回答文本是否提到你的产品做分支当出现或消失提及时从 IF 分支触发并路由到 Slack 或邮件节点发送通知。在同一工作流中捕获多引擎。复制 HTTP Request 节点并把 actor 字符串换成scraper.gemini或scraper.perplexity—— 请求封装一致下游节点无需改动。让非开发者接手执行no-ops handoff。工作流搭建好后队友可以在 Set 节点或表格里编辑 prompt 列表无需改代码采集会继续运行。代理工具调用。通过 MCP Client 节点暴露 scraper让 n8n AI agent 在更大任务流程中决定何时查询某个答案引擎。---选择 合适 的 LLM Chat Scraper 用于 n8nScrapeless 的 LLM Chat Scraper 即scraper.chatgptactor属于 Universal Scraping API 系列。它之所以适合 n8n在于只需一次经过认证的 POST 请求输入 JSON输出 JSON。对于无代码工作流而言它带来的好处包括一个 REST 端点HTTP Request node 可直接调用——无需在 n8n 主机上安装任何 SDK也不用驱动浏览器。服务端渲染、住宅出站residential egress和反 bot 处理使节点接收到的是最终回答而不是登录页面。请求里的country字段可在 JSON 体内指定出站市场——一个节点即可覆盖每个市场的数据抓取。在scraper.chatgpt、scraper.gemini和scraper.perplexity之间统一采用{ status, task_id, task_result }这一封装格式因此配置好的节点可以无改动地复用到其他引擎。使用x-api-token头作为唯一的认证方式——只需在 n8n 中配置一个凭证或头部值就能在所有调用 Scrapeless 的节点间复用。工作流程概览整个抓取流程由四个节点按顺序串联Schedule Trigger 节点按设定间隔触发HTTP Request 节点调用scraper.chatgptIF 节点检查返回是否有内容存储节点将结果写入表中。IF 节点的empty分支用于记录并丢弃未返回答案的运行——不会再次发送。下面对各节点的描述只列出了当前 n8n 节点参考中存在的参数。---第 1 步 — Schedule Trigger定时触发Schedule Trigger 用来以固定的节奏启动工作流这样抓取就能在没人手动点击播放的情况下自动运行。添加一个Schedule Trigger节点type version 1.3并把它的Trigger Rules设置为interval—— 可以按小时、每隔几小时或每天一次具体频率根据你关注的答案变化速度来定。针对回答引擎的监控通常每天一次或一天两次就足够了因为真正有意义的是数周的趋势而不是每分钟的抖动。该触发器每次触发会发出一条 item。如果你希望每次运行发送多个 prompt就在后面跟一个 Set node输出你的 prompt 列表或者从表格中读取 prompts —— 这样每个 prompt 都会作为独立的 item 流入后面的 HTTP Request node。---第 2 步 — HTTP Request 节点调用 actorHTTP Request 节点负责和集成端通信。它把对 actor 的调用以 POST 方式发送到 Scrapeless并将解析后的回复带回工作流。添加一个HTTP Request节点type version 4.4并按下面配置参数Method→POSTURL→https://api.scrapeless.com/api/v2/scraper/executeSend Headers→ 打开。添加一条 headername 为x-api-tokenvalue 填入你的 Scrapeless API key或引用 n8n 的 credential。Send Body→ 打开。Body Content Type→JSON。Specify Body→ *Using JSON*然后把 actor 调用的 JSON 粘到JSON字段里。JSON body 就是整个契约——包含 actor 名称和一个input对象如果想让 prompt 可动态化把静态字符串换成读取入站 item 的 n8n 表达式例如从前面的 Set 节点或传入的表格行里取prompt。country用来指定本次请求的出口国家residential egressweb_search允许模型检索实时来源这通常能提升答案的命中率。注意所有字段必须放在input里如果把prompt或country放在 body 顶层actor 会拒绝该请求。给节点设置较大的Timeout。生成最终的、渲染好的答案可能需要一定时间默认的短超时会在答案返回前中断请求所以要留足时间。该节点会以 item 的 JSON 返回标准信封格式{ status, task_id, task_result }。下游节点应从task_result.result_text读取答案从task_result.search_result读取来源信息。---第 3 步 — IF 节点对空回答进行分支IF 节点用来判断是否有需要存储的内容。ChatGPT 的回答是按会话生成的同一个提示在一次运行中可能会返回完整回答而在下一次运行中task_result为空——这不是失败只是本次没有该查询的回答。在 HTTP Request 节点之后添加一个IF节点type version 2.3并写一条Conditions规则来检测答案字段是否为空例如检查表达式task_result.result_text是否非空。False branch有回答→ 连接到第 4 步的存储节点。True branch回答为空→ 记录本次运行未产生结果并停止。使用 NoOp node或用 Set node 写入一行 “empty run” 标记即可。空分支不会再次调用 actor。下一次定时触发才是获取有回答的下次机会真正返回答案的那些运行会被聚合起来形成整体模式。把空结果当作可为空的数据处理而不是需要追查的错误。---第 4 步 — 存储回答存储节点会把每个已填充的回答转换成一行可供后续查询的数据。把 IF 节点的 answer-present 分支接到最适合你流程的目标节点Set 节点→ 将条目裁剪到你要保留的字段prompt、task_result.result_text、来自task_result.search_result的源域名、task_id以及捕获时间戳。即便最终写入由其他节点完成这一步也常用于把数据整理成最终形态。Google Sheets 节点→ 每次运行追加一行适合做一个无需数据库、方便共享与编辑的日志非开发人员也能查看和修改。Postgres或其他数据库节点→ 当这些采集用于数据仓库或仪表盘时将记录插入表中。每行都要存储task_id和运行时间。回答长度、引用数量以及命名的来源会随每次运行而变化因此有价值的是跨多次采集形成的序列而不是单次的某个响应。---官方 Scrapeless 节点 — 以及本指南为何使用 HTTP Requestn8n 提供了官方的 Scrapeless 社区节点n8n-nodes-scrapeless。安装并用 Scrapeless 凭证完成一次认证后它会为三类接口提供类型化的操作Deep SerpApiGoogle Search 和 Google Trends、Universal Scraping APIWeb Unlocker和 CrawlerScrape 与 Crawl。针对这些场景直接使用该节点更为简洁——不用手动拼接 URL 或构造 JSON 请求体。不过目前节点版本并未把 LLM Chat Scraper 的 actors ——scraper.chatgpt、scraper.gemini、scraper.perplexity和scraper.aimode—— 作为操作暴露出来。因此如果需要捕获回答引擎的响应就需要走 HTTP Request 节点直接请求/api/v2/scraper/execute这正是上文步骤所构建的调用方式。如果未来节点版本增加了 LLM 相关操作Scrapeless 凭证和工作流结构都可以沿用唯一变化的只是中间那个节点。---agent-node 的替代方案MCP Client Scrapeless MCP server当工作流不是固定流水线而是以智能代理AI 代理为中心时n8n 的 MCP Client 节点就取代了手工写的 HTTP 调用。MCP Client 节点会连接到一个 MCP server并把该服务器上的工具暴露给 n8n 的智能代理让代理在其推理过程中按需自行调用这些工具。把它指向 Scrapeless MCP server 后answer-engine 的捕获就成为代理可调用的工具之一——由代理在更大的任务流程中决定何时把 ChatGPT 纳入查询而不是你把调用硬连到某个固定分支。这两条路径满足不同的需求。HTTP Request 节点适用于确定性的、按计划运行的捕获场景——相同的 prompt、相同的节奏、可预测的行数。MCP Client 节点则适合在代理需要动态决定是否以及查询什么时使用。底层的 Scrapeless 接口是一致的唯一变化的只是由谁去触发这次调用。---返回结果HTTP Request 节点会把 actor 的标准 envelope 作为 item 的 JSON 返回。回答放在task_result下文本部分在result_text检索到的来源在search_result。下面的结构是scraper.chatgpt返回的示例字段值来自一次真实运行为简洁文本与来源已做截断。在 n8n 中读取这些结果时需要注意的几点所有字段都可能为 null。在某次运行中result_text可能为空search_result也可能是空数组——第 3 步的IF节点正是为这种情况准备的。在任何读取这些字段的表达式里都要对缺失字段做防护检查。search_result是引用来源的载体。每条记录包含title、url、snippet和attribution在 Set 节点里从url中解析出主机host并在多次运行中汇总统计引用占比。web_search表示是否开启了在线检索。它反映本次运行是否启用了 live-source 抓取在对推荐类提示请求时建议在请求体里将其置为true以获得更准确的来源解析。每次运行的输出会有所不同。相同的 prompt 可能产出不同长度的回答和不同数量的来源因此每条存储记录都应包含采集时间戳和task_id。---结论四节点常驻抓取将 n8n 连接到 Scrapeless 的 LLM Chat Scraper本质上可以用一个 HTTP Request 节点来实现向/api/v2/scraper/execute发起 POSTbody 为{ actor, input }并在 header 中带上x-api-token读取返回的task_result对空跑结果做分支处理然后把行数据存入数据库。把这个流程用 Schedule Trigger 定时触发就能变成一个常驻的监控当工作流需要时MCP Client node 则能把它作为一个 agent 工具来调用。注意把 prompt 集合限定好、按市场固定 pincountry、把每个字段都当作可空nullable处理并同时存储task_id和时间戳这样时间序列才是有意义的信号。把固定的一组 prompts 按计划用 Universal Scraping API 的余额跑起来采集结果就能作为后续工作流的清晰输入。请求契约和字段名已与线上 LLM Chat Scraper actor 对照确认节点参数也已根据当前的 n8n node reference 校验。---FAQ问我需要写代码来把 n8n 连接到 LLM Chat Scraper 吗不需要。集成就是使用内置的 HTTP Request 节点配置为 POST 方法URL 为/api/v2/scraper/execute在请求头中加入x-api-token并发送 JSON body。无需在 n8n 主机上安装任何 SDK也不需要编写 Function 节点。问我的 Scrapeless API key 应该放到 n8n 的哪里放在 HTTP Request 节点的 headers 中——开启Send Headers新增一个名为x-api-token的头把你的密钥填进去或引用 n8n 的 credential这样密钥就不会直接存到节点里。工作流中对 Scrapeless 的所有调用都使用同一个头。问如何在一次运行中发送多条 prompt在 Schedule Trigger 之后接一个 Set 节点来输出提示词列表或从 Google Sheet 读取提示词。n8n 会把每个提示词当成独立的 item逐条通过 HTTP Request 节点处理因此一次运行就能采集整组提示词。问如果返回的答案是空的会发生什么ChatGPT 的回答是按会话计算的所以如果返回的task_result为空表示本次运行该查询没有得到答案。IF 节点的 empty 分支会记录该无操作并结束该分支下一个定时运行才是下一次尝试。工作流不会自动重发同一请求。问能否在同一个工作流里同时采集 Gemini 和 Perplexity可以。复制 HTTP Request 节点把 actor 字符串改成scraper.gemini或scraper.perplexity即可。端点、请求头以及返回的包裹结构{ status, task_id, task_result }都相同因此下游的 IF 和存储节点无需更改。问什么时候该用 MCP Client 节点而不是 HTTP Request 节点当是固定调度、提示词可预知的抓取场景使用 HTTP Request 节点更合适如果希望 n8n 内的 AI agent 自主决定是否发起查询以及查询内容就把 MCP Client 节点指向 Scrapeless 的 MCP 服务器此时 scraper 成为 agent 可调用的工具。问我的 n8n 主机需要运行代理或浏览器吗不需要。渲染、residential egress 和反机器人处理都在 Scrapeless 服务器端完成。n8n 主机仅发出外部的 HTTPS 请求请求体内的country字段用于选择出口市场。问采集 ChatGPT 的回答合法吗返回的数据是 ChatGPT 向任何用户展示的公开回答。与任何爬取行为一样合法性取决于司法辖区和具体用途——在构建之前请审查相关条款并咨询法律顾问只采集公开的回答与来源数据绝不采集个人数据。