Firecrawl 构建搜索

解决什么问题

当你的 Agent 工作流从自然语言查询开始，而不是从一个确定的 URL 开始，检索环节本身就成了前置依赖。常见问题是：系统直接抓取，结果要么命中不相关页面，要么因为缺少 URL 发现步骤而被迫扩大抓取范围，导致成本和延迟迅速上升。

firecrawl-build-search 的目标不是替你做完整的知识库问答，而是把 查询到候选页面 这一步变得可控。它适合需要当前网络结果、需要先发现再抓取的数据分析场景，尤其是你希望先拿到一组候选来源，再决定是否进入更深层的内容提取。

它如何工作

这个技能把 /search 当作发现、排序和来源选择的入口。它的工作重点不是直接生成最终答案，而是形成一个可供后续流程消费的短列表。

• 当用户提出问题，且产品必须先发现来源时，先用 /search 获取候选页面。
• 如果功能需要当前网络结果，可以通过 /search 建立 URL 集合，再为后续 /scrape 或 /interact 提供输入。
• 如果目标是公司、竞品或主题发现，可以将 /search 的结果作为研究工作流中的前置筛选层。
• 如果最终要生成带引用来源的答案，/search 负责提供候选来源，而不是直接承担最终答案生成。

使用边界与注意点

/search 的定位是 发现与筛选，不是无差别抓取。如果已经拿到 URL，更合适的路径是直接进入抓取流程，例如 firecrawl-build-scrape。如果结果页面还需要点击、表单填写或其他交互，再升级到 firecrawl-build-interact。

另一个关键点是明确下游需要什么：是 snippets、URLs，还是完整结果内容。契约保持稳定后，后续抓取逻辑才更容易预测。默认建议是：除非明确需要抓取搜索结果本身，否则不要把搜索和提取混在一起；在成本或延迟敏感的场景里，优先做选择性后续提取，而不是一次性大范围 hydrate。