网页内容喂给大模型，总是又脏又抓不到？一套从正文提取、反爬绕过到 MCP 接入的完整拆解

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

如果你正在搭检索增强（RAG）或者 AI 智能体，被"网页抓回来一堆垃圾、有些站点干脆抓不到、抓回来的 HTML 又不适合塞给模型"这三件事折磨过，那这篇能帮你把整条链路理顺。核心结论先放这儿：给大模型喂网页的真正瓶颈不在"会不会写爬虫"，而在三道关——抓得到（要能绕过现代风控）、抓得净（要把导航、广告、脚本这些噪声剥掉，只留正文）、抓了能用（要把结果转成紧凑、结构化、对 token 友好的格式）。这三关里，最被低估的是第二关和第三关：一个原始网页里真正有价值的正文，常常只占总体量的很小一部分，剩下全是在白白消耗模型的上下文额度。

我自己折腾下来的做法是：用基于文本密度与标签语义的正文评分算法把噪声筛掉，用 TLS 指纹层面的"扮演浏览器"来代替又慢又重的无头浏览器，再用 MCP 这个开放协议把抓取能力直接挂到 AI 工具里，让智能体自己调用。本文会把每一关的底层原理讲清楚，并以一款 Rust 写的开源提取工具 webclaw 为例，把安装、用法、输出格式、爬站、页面比对到 SDK 调用都走一遍。

想看完整拆解，往下翻。

一、给 AI 喂网页，难就难在这三关

先说说我是怎么撞上这堵墙的。

前段时间我在搭一套面向技术文档的检索系统，思路很朴素：把一批在线文档抓下来，切成小段，灌进向量库，再让模型基于检索到的片段回答问题。听起来是个再标准不过的流程，可真正动手才发现，"把网页抓下来"这一步就足够让人头疼一整周。

我第一版用的是最常规的写法——发个 HTTP 请求，拿回 HTML，简单清洗一下就往下走。结果抓回来的东西惨不忍睹：顶部导航条、侧边栏、页脚版权、一大堆 JavaScript、内联样式、社交分享按钮、相关推荐、评论区……全混在一起。我粗略统计了一下，一个体量不小的页面，真正属于正文的文字占比低得吓人，剩下的全是结构性噪声。这些东西对着浏览器看的人是有用的，可对一个只认文字的模型来说，纯粹是负担。

更糟的是上下文额度的浪费。大模型一次能读多少内容是有上限的，这个上限按 token（可以粗暴理解为"模型眼里的最小文字单位"）计。我把那一坨脏 HTML 直接塞进去,大半的额度都耗在了导航和脚本上，留给正文的空间反而被挤没了。检索质量自然好不到哪去——模型读到的"上下文"里一半是噪声，它怎么可能答得准。

这是第一道坎，我把它叫抓不净。

紧接着撞上第二道坎：抓不到。

有些站点用了商业级的风控（像 Cloudflare、Akamai、DataDome 这类），我那个朴素的 HTTP 请求过去，要么直接吃一个 403，要么被丢到一个人机校验页面，正文连影子都见不着。我一开始以为是 User-Agent（请求头里标明"我是谁"的那个字段）没伪装好，换了个浏览器的 UA，没用；又挂了代理换 IP，还是没用。后来才搞明白，现代风控早就不只看请求头那点表面文章了，它会盯着更底层的握手特征——这个后面专门讲。

我退而求其次，搬出了无头浏览器（headless browser，就是没有界面、在后台跑的真实浏览器内核，常见的有 Playwright、Selenium 这套）。它确实能扛住大部分风控，因为它本来就是货真价实的浏览器。但代价是慢和重：每个请求都要拉起一整套渲染引擎、JS 引擎、CSS 解析器，单次耗时动不动两到三秒，吃内存也凶。对一个需要频繁抓页面的智能体来说，这种延迟是致命的——用户问一句话，得干等好几秒才有反应，体验直接崩盘。

第三道坎更隐蔽：抓了也不好用。

就算前两关都过了，拿到的还是 HTML。HTML 是给浏览器渲染的标记语言，里面充斥着嵌套标签、属性、转义字符，并不是给模型读的"干净文本"。你得再做一轮转换，把它变成 Markdown 或者纯文本，还得顺手把重复链接、空段落、零碎的样式残留清掉。这一步做不好，前面抓得再干净也白搭。

我把这三关画成一张图，方便理解它们之间的递进关系：

flowchart LR
    A[一个网页 URL] --> B{第一关<br/>抓得到吗?}
    B -- 被风控拦截 --> X1[403 / 人机校验]
    B -- 顺利拿到 --> C{第二关<br/>抓得净吗?}
    C -- 噪声没剥干净 --> X2[导航/广告/脚本<br/>挤占上下文]
    C -- 只留正文 --> D{第三关<br/>抓了能用吗?}
    D -- 还是原始 HTML --> X3[格式不适合模型]
    D -- 转成紧凑结构 --> E[可直接喂给大模型]

这张图基本就是我那一周的真实心路：每往前走一步，都有一个新的坑在等着。市面上的老牌正文提取库我几乎试了个遍，效果都差点意思——它们大多只解决了第二关里偏英文新闻类页面的提取，对结构复杂的中文页面、对反爬、对输出格式这些事要么不管，要么管得很粗。

后来我把思路彻底掉了个头：与其东拼西凑，不如找一个从底层就是冲着"给大模型喂网页"这个目标设计的工具。顺着这个方向，我翻到了 webclaw——一款用 Rust 写的开源网页提取工具。它最打动我的地方在于，它不是"先做个爬虫再顺便清洗一下"，而是把三道关当成一个整体来设计：底层用指纹模拟扛反爬，中间用一套评分流水线剥噪声，出口直接给你 Markdown、纯文本、JSON 还有专为模型优化的紧凑格式。

接下来这几章，我会顺着这三关，把背后的原理一关一关讲透，再拿 webclaw 当具体的例子带着你上手。先从最核心、也最被低估的"正文是怎么被洗干净的"开始。

二、网页正文是怎么被"洗"干净的

要让模型只读到正文，前提是机器得先能分辨出"哪段是正文、哪段是噪声"。这件事说起来简单，做起来是个经典难题——从一堆嵌套标签里自动抠出主体内容，学术界和工程界折腾了很多年。我把主流思路梳理一下，你就明白一套好的提取引擎到底在干什么了。

先把网页变成一棵"树"

浏览器拿到 HTML 后，会把它解析成一棵 DOM 树（Document Object Model，文档对象模型）。你可以把它想象成一个层层嵌套的文件夹结构：最外层是整个文档，往里是 <body>，再往里是各种 <div>、<article>、<p>、<a>……每一个标签都是树上的一个节点，节点之间有父子、兄弟关系。

提取正文的本质，就是在这棵树上做判断：哪些节点该留，哪些节点该砍。所有的算法，归根结底都是在给这棵树上的节点"打分"，然后保留高分、砍掉低分。

文本密度：噪声区和正文区的分水岭

最经典、也最好用的一个信号，叫文本密度。

观察一下任何一篇文章页就会发现一个规律：正文那一块，文字是密密麻麻连成片的；而导航栏、侧边栏、页脚那些区域，是"一点点文字 + 一大堆链接和标签"的稀疏结构。换句话说，正文区域单位面积里的纯文字含量，远高于噪声区域。

把这个直觉量化，就得到文本密度这个指标：对每个节点，算一算"它内部的纯文本字符数"占"它整段 HTML 字符数"的比例。比例高的，大概率是正文；比例低的、塞满标签和链接的，大概率是噪声。早期很多正文提取方案就是死磕这一个指标：设一个阈值，逐块扫描，密度超过阈值的连续区域就判定为正文起止位置。这套思路对偏英文、结构规整的页面相当有效。

链接密度：识别"导航伪装成正文"

光看文本密度还不够，因为有一类噪声很狡猾——导航和相关推荐区，文字其实也不少，但它们有个共同点：几乎每个字都被包在链接里。

于是就有了第二个关键指标——链接密度：一个节点里，被 <a> 标签包裹的文字，占它全部文字的比例。正文里偶尔会引用几个链接，但绝大部分文字是裸的；而导航区恰恰相反，几乎全是链接文字。所以链接密度一高，基本可以判定这块是导航、菜单或者推荐位，直接砍掉。

文本密度负责找出"哪里文字多"，链接密度负责排除"文字多但全是链接"的伪正文。两个指标一配合，识别准确率立刻上一个台阶。

标签语义与属性：HTML 自己会"招供"

HTML 标签本身就携带了语义信息，这是另一类强信号。<article>、<main>、<h1> 到 <h6> 这些标签，天生就是用来装正文和标题的；而 <nav>、<footer>、<aside>、<script>、<form> 这些，天生就跟正文无关。

更进一步，很多页面的 class 和 id 属性会直接"自报家门"——里面带着 content、article、post 这类词的，多半是正文容器；带着 nav、sidebar、comment、ad、footer 这类词的，多半是要剔除的。成熟的算法会维护一套正负权重词表，节点的属性里命中正向词就加分，命中负向词就减分。

位置、上下文与综合评分

除了上面这些，还有几个辅助信号常被用上：

• 位置信息：一篇文章的正文通常在页面中部偏上的主体区域，过于靠边、靠顶、靠底的节点，是噪声的概率更高。
• 上下文相关性：把节点内容和页面标题（<title> 或 <h1>）做相关性比对，和标题主题贴得近的，更可能是正文。
• 文本长度：太短的零碎片段（比如一个"分享""登录"按钮的文字）往往不是正文。

真正靠谱的提取引擎，不会只靠单一指标拍板，而是把文本密度、链接密度、标签语义、属性权重、位置、长度这些维度加权综合成一个总分，再决定每个节点的去留。webclaw 的提取核心走的就是这条路——官方把它描述为一条九步的内容优化流水线：先解析建树，再逐层做可读性评分、噪声过滤、CSS 选择器筛选，最后做 Markdown 转换和面向模型的优化。整条流水线是纯提取逻辑，不带任何网络请求，所以它能独立运行，甚至被编译成 WebAssembly（一种能在浏览器和各种环境里跑的可移植字节码）在别处复用。

我画一张简化的评分流程，帮你建立整体印象：

flowchart TD
    H[原始 HTML] --> P[解析成 DOM 树]
    P --> S[逐节点打分]
    S --> S1[文本密度]
    S --> S2[链接密度]
    S --> S3[标签语义 / class·id 权重]
    S --> S4[位置 / 长度 / 与标题相关性]
    S1 & S2 & S3 & S4 --> W[加权综合得分]
    W --> F{得分高于阈值?}
    F -- 是 --> KEEP[保留: 正文/标题/图说]
    F -- 否 --> DROP[剔除: 导航/广告/页脚/评论]
    KEEP --> M[转 Markdown / 纯文本 / 紧凑格式]

中文页面的特殊麻烦

这里我得插一句自己踩过的坑：上面这些方法，在中文页面上往往要打个折扣。

原因在于，很多基于文本密度的经典算法是冲着英文页面调的。英文单词之间有空格，分词、计长都好办；中文是连续书写、没有天然分隔的，加上中文站点普遍噪声更杂（各种推广位、浮窗、相关阅读），纯密度法很容易把"正文区域识别得过大"，把一堆推荐位也算进正文里。所以一套真正能打的提取引擎，得在密度之外，更重地依赖标签语义和属性权重来兜底，光靠"数文字"是不够的。我自己测下来，对中文技术文档，配合手动指定一下正文容器的选择器，效果会稳很多——这个用法下一章实操会讲到。

两类主流思路，各有各的脾气

我顺便把业界正文抽取的两大流派给你点一下，理解了它们的差别，你挑工具、调参数时会更有方向感。

第一类是基于 DOM 结构的方法，也就是上面一路讲下来的思路：先建 DOM 树，再靠标签语义、class/id 权重、文本密度给节点打分。它的好处是能较好地保留正文的缩进、层级、链接这些结构信息，适合那种结构规整、标签语义清晰的页面。前面提到的可读性评分系列方案，走的都是这一路。

第二类是基于行块分布的方法。它的思路更"暴力"也更轻：干脆不建 DOM 树，直接把 HTML 标签全剥掉，剩下纯文字之后，按行去统计文字的疏密分布——正文那一段，连续好几行都是密集文字；噪声区则是稀稀拉拉。靠这个"行块密度"的起伏，直接定位正文的起止行号。它的优势是不依赖 DOM 解析，速度快、实现轻；短板是对图片型、表格型、列表型内容比较吃力，结构信息也基本丢光了。

实际工程里，成熟的引擎往往是两类思路融合：用 DOM 法保结构、判语义，用密度类指标做兜底判断。webclaw 的九步流水线偏向 DOM 结构法这一脉，同时把密度、链接比例这些密度类信号也揉了进来——这也是为什么它既能剥得干净，又能保住 Markdown 那层结构。

一句话收束这一关

把正文洗干净的本质，就是给 DOM 树上的每个节点做一次多维度打分，然后只留高分的主体内容。理解了这层，你再去用任何提取工具，心里都有底：它在帮你干的，就是把这套打分自动化了。莫潇羽@无忆研习社这一年折腾下来最大的体会是——别迷信某个单一"神器参数"，提取质量从来是多个信号综合出来的结果，能让你手动补一刀选择器的工具，才是真正可控的工具。

正文洗干净了，可前提是你得先把页面抓回来。下一章就来啃最硬的那块骨头：为什么换了 UA、换了 IP 还是被拦，现代风控到底在盯着你的什么。

三、反爬这关：换 UA 为什么没用，TLS 指纹到底是什么

这一章是我个人觉得最长见识的部分。在搞明白 TLS 指纹之前，我对"反爬"的理解还停留在"改改请求头、换换 IP"的石器时代。

先看一次正常的 HTTPS 访问发生了什么

你在浏览器里打开一个 https:// 网址，背后并不是直接就把网页内容传过来了，而是先做了一轮"握手"。这轮握手叫 TLS 握手（TLS 是给网络通信加密的协议，HTTPS 里的那个 S 就靠它），目的是双方先协商好"待会儿用什么加密方式聊天"。

握手的第一步，是客户端（你的浏览器）向服务器发一个叫 ClientHello 的报文。这个报文里塞了一堆信息：我支持哪些 TLS 版本、我能用哪些加密套件（cipher suites）、我支持哪些扩展（extensions）、我接受哪些椭圆曲线算法……一长串。

关键就在这儿：不同的程序，在拼这串信息时，顺序和组合是相对固定、各不相同的。Chrome 有 Chrome 的拼法，Firefox 有 Firefox 的拼法，Python 的 requests 库、Go 的标准库，又各有各的拼法。这就好比每个人的笔迹都不一样——哪怕写同样的字，落笔的习惯也藏不住。

JA3 与 JA4：把"握手笔迹"算成一个指纹

风控系统正是抓住了这个特征。它把 ClientHello 里那几个字段（TLS 版本、加密套件列表、扩展列表、椭圆曲线等）按规则拼成一个字符串，再算个哈希值，就得到一个能标识"这是哪个客户端"的指纹。这套早期方案叫 JA3，算出来是一串哈希。后来又出了升级版 JA4，引入了更多上下文（比如是不是走 HTTP/2、SNI、ALPN 等），刻画得更精细，而且可读性更好。

有了这东西，风控的逻辑就变得很直接：真实浏览器的指纹长什么样，它心里有数；常见爬虫库（Python requests、Go net/http 之类）的指纹长什么样，它也有黑名单。一个请求进来，握手阶段它就先看指纹——对不上真实浏览器的，可能在 TCP 层就直接把连接重置了，根本轮不到你的请求头登场。

这下你就明白，为什么我当初改 UA、换 IP 全都没用了：User-Agent 是 HTTP 应用层的字段，得等握手完成、连接建好之后才发得出去。可风控在更底层的握手阶段就已经凭 TLS 指纹把我拦下了。更要命的是，风控还会做交叉校验：你的 UA 自称是 Chrome，可你的 TLS 指纹却是某个爬虫库的——这种"表里不一"反而是更明显的作弊信号，拦得更干脆。

我把这个对比画出来，一眼就懂：

sequenceDiagram
    participant C as 你的程序
    participant W as 风控/服务器
    C->>W: ClientHello(TLS 版本/加密套件/扩展...)
    Note over W: 提取字段算出 JA3 / JA4 指纹
    alt 指纹像真实浏览器
        W-->>C: 继续握手, 正常返回网页
    else 指纹像爬虫库
        W--xC: TCP 层直接重置, 连请求头都没机会发
    end

无头浏览器为什么慢，又为什么不是必选项

既然真实浏览器的指纹是"正版"，那直接用真实浏览器内核（无头浏览器）不就完了？确实能过关，但前面说过，它的代价是又慢又重——拉起一整套渲染引擎、JS 引擎，单请求两到三秒，资源占用高。对偶尔抓几个页面无所谓，对要做高频抓取的智能体来说，这个延迟扛不住。

那有没有第三条路？有。既然风控认的是握手指纹，那我不启动整个浏览器，只在 TLS 握手这一层把自己伪装成浏览器，不就行了？ 这就是 webclaw 选的路子：它不跑无头浏览器，而是在传输层做浏览器级的指纹模拟——TCP 握手、加密套件、扩展信息、指纹特征都对齐主流 Chrome 的行为，让风控以为来的是个真实用户。

这里有个技术细节值得一提（也顺便纠正一下网上一些旧资料）。webclaw 早期版本是靠魔改一批 Rust 网络库来对齐指纹的，但维护一堆分叉库太吃力，后来它换成了基于 BoringSSL 的方案——BoringSSL 正是 Chrome 自己在用的那套 TLS 库，再配上专门处理 HTTP/2 指纹的组件，对齐的是较新的 Chrome 版本（JA4 能做到精确匹配）。用 Chrome 同款的底层库去握手，指纹自然就和真 Chrome 高度一致，这比"手搓伪造每一个字段"要稳得多。

效果上，官方给的数据是：静态页面平均响应大约 118 毫秒，本地提取一个十几 KB 的页面是亚毫秒级，整体比基于 Chrome 内核的方案快出一个量级。对于那种"页面是纯 JS 动态渲染、不跑浏览器就拿不到内容"的情况，它也会自动识别并切到渲染路径，不用你手动配。

把反爬手段分个层，应对就有谱了

讲到这儿，我顺手把现代风控常见的几个层次和对应的应对思路整理成一张表。理解了它们各在哪一层，你被拦时就能快速判断卡在哪个环节，而不是像我当初那样瞎换 UA、瞎换 IP。

你看，我当初的错误在于只在最上面两层打转——换 UA、换 IP，可真正把我拦住的是第三层的 TLS 指纹。这就是为什么前面我反复强调：搞不懂握手层，再怎么折腾上面两层都是隔靴搔痒。 webclaw 的价值，恰恰是把第三层这块最硬的骨头用"浏览器同款底层库"给啃下来了，同时对第四层的动态渲染也留了自动切换的后路。

至于代理池（第二层那一项），webclaw 也支持配置——既能用单个代理，也能用一个代理文件做轮换，支持标准的 HTTP/HTTPS 或 SOCKS5 代理。需要把一次大规模爬取分散到多个出口、或者做区域化内容采集时会用得上。但还是那句话，用代理是为了分散压力和满足合规采集需要，不是为了规避站方明确的禁止——边界在哪，心里要有数。

合规这根弦得绷住

技术能绕过风控，不代表什么都能抓。这一点我必须把话说在前面。

网站的风控、robots.txt（站点放在根目录、用来声明"哪些路径欢迎/不欢迎被自动访问"的约定文件）、用户协议，都是站方明确表达的边界。能不能抓、抓了能不能用、用在什么地方，这些是合规问题，不是技术问题。 我自己的原则是：只抓公开可访问的内容，严格遵守目标站点的 robots.txt 和服务条款，控制好访问频率别给人家服务器添堵，绝不碰需要登录、付费或涉及个人隐私的数据。技术上"能做到"和合规上"该不该做"是两码事，这根弦千万别松。

涉及把抓来的内容二次发布、商用，更要留意版权与授权——很多内容是有版权的，转载、引用都得遵守相应规范。关于抓取的合规边界，后面我专门拿一章来聊。

搞定了"抓得到"和"抓得净"，还差最后一块拼图：怎么让这套能力顺滑地接进我的 AI 工具里，让智能体自己会用。这就轮到 MCP 出场了。

四、MCP：让外部工具接进 AI 的"万能转接口"

如果说前两关解决的是"抓取本身"，那 MCP 解决的是"怎么把抓取能力交到模型手里"。这是把一个工具从"我手动命令行调用"升级成"智能体自动调用"的关键一跃。

模型为什么"够不着"外部工具

先说清楚一个事实：大语言模型本质上是个"文字接龙引擎"——它擅长理解你的意图、生成文字，但它本身碰不到真实世界。它不能自己去访问一个网址、查一个数据库、调一个接口。它能做的，是判断"这件事需要用某个工具"，然后吐出一段规范的调用指令，由外部程序去真正执行，再把结果喂回给它。

这个"让模型会调用工具"的机制，早期叫函数调用（Function Calling）。它能用，但有个老大难问题：各家不通用。不同模型平台的函数调用接口实现各不一样，你为一个平台写的工具适配代码，换个平台就得重写。每接一个新工具、每换一个新模型，都是一堆重复的脏活累活，这就是所谓的"N×M 集成困境"。

MCP 是什么：给 AI 装一个"标准接口"

MCP 的全称是 Model Context Protocol（模型上下文协议），是 Anthropic 在 2024 年 11 月提出并开源的一套开放标准。打个最贴切的比方：它之于 AI，就像 Type-C 接口之于电子设备——以前每个设备一种充电口，现在统一成一个口，既能充电又能传数据。MCP 想干的，就是把"模型连接外部数据和工具"这件事，统一成一套大家都认的标准协议。

它的角色分三层，理清楚就不绕了：

它们之间用一种轻量的 JSON-RPC 消息格式通信。流程大致是：客户端先问服务器"你都有哪些工具"，服务器用自然语言把每个工具的用途和调用格式回过去；这些信息交给模型后，模型一旦判断"我需要这个工具"，主机就指挥客户端去调，服务器执行完把结果传回，主机再把结果塞回模型的对话里。

flowchart LR
    LLM[大模型] <--> Host[MCP 主机/AI 应用]
    Host <--> Client[MCP 客户端]
    Client <-->|JSON-RPC| Server[MCP 服务器: 网页抓取]
    Server <--> Web[(目标网站)]

MCP 好在哪：一次实现，到处可用

理解了角色，它的好处就很顺了。工具提供方只要按 MCP 协议把服务器实现一次，所有支持这套协议的 AI 应用都能直接接入；工具的"使用说明书"由最懂它的提供方来写和维护，AI 应用按协议订阅就行。这带来三个实在的好处：一是一次开发到处可用，不用为每个模型平台重写；二是架构解耦，业务逻辑封装在独立的服务器进程里，像拼积木一样自由组合；三是动态发现、按需加载，改个配置指向不同服务器就能换工具，不用动核心代码。

这套协议这一年多发展得很快，OpenAI 在 2025 年也正式支持了它，等于让它坐实了"行业标准"的位置；到 2025 年底，相关治理还被捐给了一个 Linux 基金会下的中立组织来维护，生态越来越开放。

落到 webclaw 上：一行命令就接上了

具体到 webclaw，它内置了一个 MCP 服务器。这意味着它能直接挂到那些支持 MCP 的 AI 编程工具和桌面应用上，不用你写一行适配代码。官方提供了一个一键安装的命令：

npx create-webclaw

这条命令会自动探测你本机装了哪些支持 MCP 的客户端，逐个生成对应的配置文件。配完重启你的 AI 工具，webclaw 的抓取、爬站、内容比对、品牌信息提取这些能力就自动可用了——之后你只要用自然语言吩咐一句"把这几个页面抓下来整理成干净的上下文"，智能体就会自己去调。

小提醒：npx 是 Node.js 生态里的一个命令行工具，能临时拉起并运行一个 npm 包而不用先全局安装。所以跑上面这条命令的前提，是你本机装了 Node.js 环境。

到这儿，"抓得到、抓得净、抓了能用、还能让智能体自己用"这条完整链路的原理就全部讲透了。下一章我们不谈原理，纯实操——把这工具从装到用走一遍。

五、上手实操：安装、基础提取、格式与选择器

讲完原理，这一章带你把工具真正用起来。我按"装上 → 抓一页 → 选格式 → 精修 → 爬整站 → 比对变化 → 写进代码"的顺序走，每一步都给可直接复制的命令。

装上：四种方式挑一个

webclaw 是 Rust 写的开源工具（采用 AGPL-3.0 协议，这点后面合规章节会提醒一句），装法很灵活，按你的环境挑顺手的：

方式一，MCP 一键安装（想让 AI 工具直接用，推荐这个）：

npx create-webclaw

如上一章所说，它会自动探测并配好支持 MCP 的客户端。

方式二，Homebrew（macOS 用户最省心）：

brew tap 0xMassi/webclaw
brew install webclaw

方式三，预编译二进制： 到项目的 GitHub Releases 页面，下载对应你系统（macOS / Linux / Windows）的二进制文件，放进 PATH 里就能用。

方式四，Docker（不想污染本机环境）：

docker run --rm ghcr.io/0xmassi/webclaw https://example.com

方式五，从源码编译（想自己改或尝鲜最新版）：

cargo install --git https://github.com/0xMassi/webclaw.git webclaw-cli
cargo install --git https://github.com/0xMassi/webclaw.git webclaw-mcp

名词快速解释：cargo 是 Rust 的包管理兼构建工具，类似 Node.js 的 npm、Python 的 pip。从源码编译时如果报缺少本地编译工具，按它提示装一下系统的编译依赖即可。

抓一页：最基础的用法

装好之后，抓一个页面就一行：

# 抓单页，默认输出 markdown
webclaw https://example.com

它会把那一页的正文提取、清洗、转成干净的 Markdown 打印出来。这一条命令背后跑的，就是前面两章讲的全套——指纹模拟拿页面、评分流水线剥噪声、转格式。

选格式：这是给模型用的关键一步

webclaw 支持多种输出格式，这块我建议你重点看，因为喂给模型用哪种格式，直接影响 token 消耗和检索质量。我整理成一张表：

指定格式用 --format：

webclaw https://example.com --format markdown
webclaw https://example.com --format llm
webclaw https://example.com --format json

我自己灌 RAG 基本只用 llm 格式。它会在 Markdown 的基础上进一步把重复链接、空段落这些边角料再清一遍，输出更紧凑——同样的内容，占的 token 更少，留给模型的有效信息密度更高。

精修：只要主内容 + 手动指定选择器

自动评分已经能干掉绝大多数噪声，但碰到结构特别刁钻的页面，你可以手动再补一刀。

只保留主内容区：

webclaw https://example.com/blog/post --only-main-content

自己指定"要哪块、不要哪块"——用 CSS 选择器（一种定位网页元素的语法，比如 article 选所有文章标签、.content 选 class 是 content 的元素）：

webclaw https://example.com \
  --include "article, main, .content" \
  --exclude "na