夜雨聆风前言
最近一段时间围绕 AI Agent 的讨论越来越热闹。一边是各种“AI 很快就会替代人类”的夸张想象，另一边则是把注意力放在一些并不重要的争论上，故意设计一些绕口的陷阱题，比如“走着去洗车，还是开车去”，来证明模型“并不聪明”。但只要你真的开始把 AI 用进日常工作，就会发现一个更现实的问题：它们在很多最基础的事情上，其实还远远没有做到足够好。
最常见的一件事：你读到一篇不错的微信公众号文章，把链接发给 AI，让它帮你总结、分析，或者和你讨论。听起来这几乎是最自然不过的使用场景了，但实际体验往往并不理想。我尝试了一下最新的Chatgpt 5.4 和 Gemini 3.5，结果如下：
网页之困
很多人以为，只要底层模型足够强，丢给它一个 URL，它就能像人类一样读懂背后的逻辑。但现实是Agent 经常根本拿不到真正有用的正文。有时它收到的是一个冷冰冰的 403 Forbidden。有时虽然抓到了内容，但里面混着导航栏、广告位、脚本碎片，最后变成一堆几乎无法使用的“电子垃圾”。对用户来说，这种体验很糟糕：不是抓不到，就是抓不准，或者抓回来一大堆噪音。
当大家的注意力焦点都在AI做研究员，AI写项目代码，AI生成PPT 这些大事的时候，网页抓取这件事看起来很小，实际上却是 AI Agent 落地过程中一个非常基础、也非常关键的问题。如果一个知识系统连我们真正关心的内容都无法稳定摄取，或者摄取进来的东西质量很差，那么后续无论是总结、检索，还是 RAG，都会建立在不干净的输入之上。输入一旦被污染，后面的结果自然也很难可靠。
因此我开始认真思考：OpenClaw 需要的，究竟是什么样的网页抓取工具？
现有方案短板
其实现在并不缺网页抓取工具，面向 AI Agent 的方案也已经不少。问题不在于有没有工具，而在于它们是否真的适合日常知识采集，尤其是否适合部署在资源有限的环境里。
以 OpenClaw 自带的 webfetch 为例，它本质上更接近 curl 加规则提取。在一些结构简单、静态内容为主的页面上，它可以工作；但一旦遇到微信公众号、现代博客，或者强依赖 JavaScript 渲染的站点，就很容易失效。
另一类工具则走向了另一个极端：它们确实具备更强的抓取能力，但代价是要启动一个完整浏览器，甚至带图形界面。这样的方案在本地高配机器上未必不能接受，但如果你的 OpenClaw 部署在一台只有 2 核 CPU、4GB 内存的 VPS 上，这种做法往往太重了。冷启动慢，常驻占资源，还可能因为依赖不齐、浏览器环境异常、内存不足等问题，让整条任务链中断。换句话说，问题不是“抓不到网页”，而是现有方案常常只能在“能力不够”与“资源过重”之间二选一。
而我真正想要的，是一个更适合 Agent 使用习惯的工具：它要足够轻，足够稳，而且要知道面对不同站点时，该走哪条更合理的路径。这就是 clawfetch 的出发点。
殊途不同归
clawfetch 并不是完全排斥浏览器方案。它会使用无头浏览器+轻量级的Playwright-core操控方式来处理需要渲染的页面。但它的关键不在于‘用了浏览器’，而在于它不会默认对所有网页都走最重的路径，而是先判断有没有更轻、更直接的入口。换句话说，clawfetch 不是一上来就强行模拟人类打开网页、执行脚本、等待渲染，而是先判断：这个站点有没有更适合机器读取的原生接口？有没有更直接的文本入口？有没有一种路径，能绕开登录墙、广告层和复杂前端，直接拿到高质量正文？如果有，就优先走那条路。
这个思路听起来朴素，但在实际使用中非常重要。因为对 Agent 来说，目标不是“像人一样浏览”，而是“尽快拿到可靠文本”。在开发 clawfetch 的过程中，我给一些高频站点做了针对性的提取路径。
比如 Reddit。与其让工具在复杂页面结构里挣扎，不如直接利用它现成的 RSS 入口。只要在原始链接后面追加 .rss，Reddit 就会返回结构更清晰的 XML 内容。这样一来，既可以绕开那些不必要的页面元素，也更容易稳定拿到主帖正文。在这个基础上，clawfetch 还可以通过 --max-comments 这样的参数，把评论区中真正有价值的内容一起提取出来。对很多技术讨论、经验贴、故障排查串来说，评论往往比正文更有信息量。把这部分一起打捞上来，才更符合真实使用场景。
GitHub 也是类似。很多时候，用户真正想让 Agent 先理解的，并不是网页本身，而是项目说明文档。既然如此，那就没有必要先去抓一个充满样式、导航和交互元素的 HTML 页面。更合理的做法，是直接识别并跳转到更干净的 raw.githubusercontent.com 原始内容路径，优先提取 README 这类文档内容。
这类策略背后的想法其实是一致的：不是一味追求“什么都能硬抓”，而是优先尊重站点原本就已经提供的更优读取方式。
自解释能力
如果说多路径抓取解决的是“怎么更稳地拿到内容”，那么 clawfetch 另一个让我很满意的地方，是它在失败时不会只是简单报错，而是会尽量告诉 Agent 下一步应该做什么。这意味着，当抓取失败时，用户面对的不是一条难懂的报错，而是一条可以继续推进任务的下一步提示。这一点在我看来非常重要。
很多命令行工具在出问题时，只会返回一个非零退出码，或者扔出一条技术性很强的报错信息。人类工程师也许还能自己判断，但对 Agent 来说，这样的信息往往不够友好。它知道失败了，却不知道该如何修。所以在 clawfetch 里，我加入了一套带有引导性质的错误输出。比如当系统发现环境里缺少某个依赖时，它不会只是终止，而是会直接输出带有 NEXT: 前缀的建议，明确告诉 Agent：下一步该安装什么、用什么命令修复、是否可以在受控环境下继续执行。如果浏览器抓取失败，或者内容不可靠，比如当 Readability + fallback 都抓不出有意义内容时，会打印 debug + 下一步。
这让工具不再只是一个“执行器”，而多了一层“导航器”的角色。它不仅完成任务，也在教 Agent 如何在当前环境中继续活下去。从工程角度说，这种透明度非常有价值。因为一个真正可维护的 Agent 系统，不只是要能跑通 happy path，更要在失败时可诊断、可恢复、可预测。
知识库入口
clawfetch 现在已经成了我知识库入口的一部分。它抓回来的内容，不会只是随便存成一段文本，而是会被整理进带有标准化元数据的 Markdown 容器中。文章标题、作者、来源链接、提取方式，都会被明确记录下来。尤其是“它是通过哪条路径被提取出来的”，这一点很重要，因为这相当于给内容加上了一层可追踪的来源标签。这样一来，后续无论是做归档、检索，还是接入 RAG，面对的都不再是网页残骸，而是经过清理、去噪、结构化后的正文内容。以后再回头看这篇内容时，我不仅知道它写了什么，还知道它来自哪里、是通过什么路径提取出来的，以及它是否经过了回退处理。
这件事的价值，并不只在于“抓网页更方便了”。更重要的是，它提高了整个知识系统输入端的确定性。而在我看来，所谓“第二大脑”真正要追求的，并不是炫技式的智能，而是对信息入口的掌控力。只有入口足够干净，后面的总结、联想、推理，才有可能站在更稳的基础上。clawfetch 解决的，正是这个最前面、也最容易被忽略的问题：先把网页可靠地拆开，把真正值得保留的内容带回来。
Skill 安装
现在我已经把它封装成 ClawHub 上可安装的 Skill。对 OpenClaw 用户来说，这意味着它不再只是一个单独的命令行工具，而是可以直接接进现有工作流，作为网页内容进入知识库的前置入口。 把这个网址发给OpenClaw, [Claw Web Fetch — ClawHub](https://clawhub.ai/ernestyu/clawfetch)，它就知道怎么安装。然后你就可以和OpenClaw一起畅游网络世界了。对我来说，这比又做了一个网页抓取工具更重要：它让 Agent 在面对网页时，终于不必总是硬碰硬了。
