029、Web 搜索与抓取：WebFetch、WebSearch 在研究型任务中的策略与信息整合

029、Web 搜索与抓取WebFetch、WebSearch 在研究型任务中的策略与信息整合从一次“信息过载”的调试说起上周五凌晨两点我盯着终端里Claude Code输出的那一大坨HTML源码发呆。任务是让Agent自动调研某个开源项目的社区活跃度——按理说WebFetch抓个GitHub页面提取star数、issue响应时间、PR合并率再整合成报告就行。结果呢Agent把整个页面源码扔进了上下文token直接爆了后续分析逻辑全部瘫痪。更离谱的是它抓了三次一次用WebFetch抓了首页一次用WebSearch搜了“项目名issues”还有一次莫名其妙抓了README.md的渲染页面。三个结果互相重叠信息冗余度超过70%。我当时的反应是这玩意儿不是不会用工具是根本不懂“信息整合”这四个字怎么写。这个坑让我重新审视了Claude Code中WebFetch和WebSearch的设计哲学——它们不是简单的“爬虫”和“搜索引擎”而是研究型任务中信息获取的两个不同维度。用错了策略再强的模型也扛不住信息洪流。WebFetch vs WebSearch别把它们当兄弟很多人的第一反应是WebFetch是抓页面WebSearch是搜网页差不多嘛。差远了。WebFetch的本质是“定点精确打击”。你给它一个URL它返回该URL的文本内容通常是HTML解析后的正文。它的优势在于深度——你能拿到页面的完整结构包括表格、列表、代码块这些结构化信息。但代价是你事先得知道URL。这在研究型任务里是个悖论——我要是知道该看哪个页面我还研究个啥WebSearch的本质是“广域情报检索”。你给它一个查询词它返回一组搜索结果摘要通常包含标题、片段、URL。它的优势在于广度——能帮你发现你不知道的页面。但代价是信息密度低每个结果只有几句话而且搜索引擎的排序算法不一定符合你的研究目标。我踩过的坑是让WebSearch去抓“详细数据”。比如搜“React 19 性能提升 数据”结果返回的摘要里只有“提升了20%”这种模糊表述没有具体的benchmark数字。正确的做法是用WebSearch发现可能包含数据的页面比如“React 19 benchmark results site:github.com”然后用WebFetch去抓那个页面的完整内容。策略口诀WebSearch负责“找门”WebFetch负责“进门”。别让WebFetch去撞墙也别让WebSearch去挖井。研究型任务的信息获取策略三层漏斗模型在实际工程中我总结了一个“三层漏斗”策略专门对付那种“信息多但不知道哪些有用”的场景。第一层宽泛搜索建立地图用WebSearch做3-5个不同角度的搜索每个搜索返回前5-8个结果。角度要覆盖官方文档、社区讨论、技术博客、数据报告、竞品分析。比如研究“WebAssembly在边缘计算中的应用”我会同时搜“WebAssembly edge computing use cases 2024”“Wasm runtime performance benchmark edge”“Cloudflare Workers Wasm vs V8 isolates”“WebAssembly on IoT devices limitations”这一步的目标不是获取答案而是建立“信息地图”——知道有哪些关键页面、哪些社区在讨论、哪些数据源可用。把搜索结果中的URL整理成一个候选列表去重后大概20-30个。第二层关键页面深度抓取从候选列表中按优先级抓取。优先级判断标准官方文档 权威benchmark 社区高赞讨论 个人博客。这里有个技巧不要一次性抓完。先抓3-5个最高优先级的页面让Agent消化后再根据已获取的信息调整后续抓取目标。我遇到过的情况抓了官方文档后发现文档里引用了某个基准测试的PDF链接而这个PDF才是真正的数据源。如果一开始就无脑抓完所有页面这个PDF可能被淹没在信息堆里。第三层交叉验证与信息补全研究型任务最怕“单一信源”。用WebSearch验证关键数据点。比如官方文档说“延迟降低了40%”我会搜“WebAssembly latency 40% reduction benchmark”看看其他来源是否一致。如果发现矛盾再抓取矛盾方的页面进行对比。这个阶段还要注意“时效性”。WebSearch默认返回的是最新结果但有些技术文档的旧版本反而更有参考价值比如某个API的废弃原因。我习惯在搜索词里加年份限定或者用“site:archive.org”回溯历史版本。信息整合别让Agent当搬运工信息获取完了真正的挑战才开始。很多人的Agent写出来的报告就是“我抓了A页面它说了X我抓了B页面它说了Y”——这是搬运工不是研究员。整合的核心是“结构化冲突”。把不同来源的信息按维度拆解然后标注一致性或矛盾点。比如性能数据A页面说延迟50msB页面说80msC页面说60-70ms原因分析A认为是JIT编译优化B认为是内存管理改进适用场景A强调高并发B强调低功耗Agent需要做的不是罗列这些信息而是给出一个“综合判断”数据差异可能源于测试环境不同A用x86服务器B用ARM开发板建议在统一环境下复测。这才是研究型任务的价值所在。我常用的整合模板是“问题-证据-结论”三段式。每个研究问题下先列出所有相关证据标注来源然后给出Agent的推理过程最后输出结论和置信度。置信度低于70%的标记为“待验证”并给出验证方法。代码实现一个研究型Agent的WebFetch/WebSearch配置下面是我在实际项目中用的一段配置注释里写满了踩坑记录# 研究型任务的信息获取配置# 别问我为什么不用默认参数——默认参数是给“搜个天气”用的research_config{web_search:{max_results:8,# 每个搜索词返回8条结果多了上下文会炸search_depth:comprehensive,# 别用basicbasic只返回标题region:us,# 研究技术问题用us区域cn区域结果质量差很多freshness:month,# 研究型任务一般看最近一个月除非是历史分析# 这里踩过坑freshness设成day会导致漏掉重要周报},web_fetch:{max_chars:15000,# 每个页面最多抓15000字符够用了extract_mode:smart,# 别用fullfull会把导航栏、广告都抓进来timeout:30,# 30秒超时有些页面加载慢但内容有用# 别这样写把timeout设成5秒结果github issues页面没加载完就超时了},research_pipeline:{initial_searches:4,# 第一层搜索数量deep_fetches_per_search:3,# 每个搜索词抓取前3个高优先级页面cross_validate_queries:2,# 每个关键数据点做2次交叉验证搜索max_total_fetches:15,# 整个研究任务最多抓15个页面# 超过15个页面Agent的上下文就开始稀释了}}实际调用时我还会加一个“信息去重”步骤。WebFetch返回的内容里经常有重复的段落比如README.md里的“Features”部分在不同页面里被引用。用简单的文本相似度计算比如Jaccard相似度阈值设0.7重复内容只保留一份。一个真实案例调研“Rust在嵌入式领域的生态成熟度”这个任务我让Agent跑了三轮每轮都调整了策略。第一轮失败直接让WebSearch搜“Rust embedded ecosystem maturity”然后WebFetch抓了前10个结果。结果抓到的全是博客文章没有官方数据。Agent给出的结论是“生态很活跃但缺乏标准化”——废话博客当然说活跃。第二轮改进调整策略WebSearch加了限定词“site:rust-lang.org”和“survey 2024”。抓到了Rust官方年度调查中关于嵌入式使用的数据。同时用WebSearch搜了“Rust embedded HAL support matrix”找到了一个社区维护的硬件支持表格。这次信息质量明显提升。第三轮成功在第二轮基础上用WebSearch搜了“Rust vs C embedded benchmark”和“Rust embedded production issues”。抓到了几个公司的生产环境案例包括一个在无人机飞控上从C迁移到Rust的详细报告。最后整合时Agent自动对比了官方调查、社区表格、生产案例三个维度的信息给出了“生态成熟度评分7/10主要短板在实时性支持和工具链稳定性”的结论。这个案例说明研究型任务的信息获取不是一次性的而是迭代式的。每次获取的信息都会影响下一次搜索的方向。个人经验别让工具替你思考WebFetch和WebSearch是强大的工具但它们只是工具。我见过太多人把Agent当成“自动写报告机”结果写出来的东西要么是信息堆砌要么是错误百出。我的建议是永远保留人工审核环节。Agent抓取的信息中至少有10%是错的页面解析错误、搜索引擎返回了无关结果、信息过时。让Agent自己标注每个信息的置信度然后你重点审核低置信度的部分。给Agent一个“信息预算”。限制每次研究任务的总抓取量比如不超过20个页面、不超过5万字符。信息太多时Agent的推理能力会下降——它不是在思考而是在“信息洪流里挣扎”。教会Agent“什么时候该停”。很多Agent会陷入“再搜一个看看”的循环。设定终止条件要么找到了足够支撑结论的证据比如3个独立来源一致要么搜索了5轮都没有新信息出现。别让Agent变成信息松鼠。把研究过程也记录下来。不只是最终报告Agent的搜索路径、抓取顺序、信息筛选逻辑这些元信息往往比结果本身更有价值。下次做类似研究时可以直接复用这个“研究策略”。最后说一句WebFetch和WebSearch的终极目标不是“获取信息”而是“减少不确定性”。每次抓取、每次搜索都应该让你对研究问题的理解更清晰而不是更混乱。如果抓了10个页面后你反而更困惑了那一定是策略出了问题——停下来重新思考你的研究问题而不是继续抓第11个页面。