小白向获取X内容攻略，跟着步骤走，你也能免费盯对标账号，抓取X全文文章

大家可能都遇到过这样的场景，能不能不花钱或者花很少的钱获取 X 的内容？

你在 X 上看到一篇几千字的长文，觉得写得很好，复制链接丢给手头的 Hermes 等智能体，让它存进本地文档再做个拆解。结果它忙活了半天，要么两手一摊，说撞上登录墙读不到，要么交回来一堆整整齐齐的标题和链接，点开本地文件一看，正文位置全是一片空白。

这种「链接抓回来一堆，正文一条都没有」的场面，几乎每个刚开始折腾 X 内容的人都会遇到。

其实这怪不得模型，更不怪你提示词写得不够好。根本原因是，除了付费的 X官方 api和各类付费网站之外，想免费获得，让 Hermes 这类智能体去抓 X 上的内容，必须把找人和取正文拆成两套完全独立的动作。

下面我从自己踩过的坑出发，总结一下免费实现步骤，希望可以帮助到刚入行的朋友，说的不对，欢迎批评指正。

脚本不报错，为什么抓回来的是空内容

有的时候，我们让 Hermes 免费抓 X 内容遇到困难后，让它自查代码，会发现脚本并没有错误，而是登陆墙或者服务器ip 被封导致无法实现。

这时候，我们可以把一件事拆成三件事来做，不要怕麻烦，因为你要的是免费方案。

在人的眼里，打开 X 网站，搜一个词、看一个人的主页、点开一篇长文，全是在同一个浏览器窗口里点两下鼠标的事。

但在智能体跑命令行时，这三件事应该走三条完全独立的通道：

1. 找人（这个号最近发了什么）
2. 找话题（谁在聊某个关键词）
3. 取正文（把一篇长文的完整文字拿下来）

这三件事背后是三个不同的接口，钥匙不一样，能不能用也不一样。

你让智能体一把梭哈混在一起做，它就会用找人的接口去硬套长文的正文，结果就是「链接抓回来一堆，正文什么内容都没有」，而且脚本不报错，看起来一切正常。

实际上官方那条路对普通人非常不友好。官方开发者接口按请求计费，账号额度用光后会直接返回 402「额度耗尽」，这时候换脚本、换密钥都没用，只能去开发者后台真金白银的充值。

这里贴出官方的价格：

读一条帖子 单价: 0.5 美分

读一个用户资料 单价: 1 美分

读一条粉丝、关注关系 单价: 1 美分

发一条帖子 单价: 1.5 美分

发一条带链接的帖子 单价: 20 美分

所以 5 美元只能读 1,000 条帖子，或者 500 个用户资料。

官方其实有查询用量和余额的接口，分别是 /2/usage/tweets 和 /2/usage/credits。但能不能正常调通，还得看账号权限和实际返回结果。

那普通人手头只有个会跑命令的智能体，到底该走哪条路？

大家先看下面这份通道对照表，这是现在几个主流的方式。

所以我们可以看出来，抓取侧几乎免费（镜像站不收钱），贵的是关键词搜索和后面的分析。

第一步：先让智能体探路，看通道是否可用？

先让智能体去探路，千万别上来就写几百行的抓取代码。

很多朋友一上来就让 Hermes 写个全自动监控脚本，结果调不通就在那里反复改代码。其实通道本身可能就已经堵死了，怎么改代码都是白费力气。

免费镜像站 fxtwitter（api.fxtwitter.com）可以做这几件事：读单条帖子、读某个账号最近的时间线、读某个账号发过的长文列表、读趋势榜、搜人。

但我测试时，同一个免费镜像的关键词搜索接口连续返回 404，中文、英文都没搜到。

如果你不先探路，智能体就会在那个 404 上死磕半个小时。

另外，如果你想顺手抓 X 上的热门长文榜单站（xzhishu 这类）当选题参考，它是前端渲染的页面，用普通抓取只拿到空页面，必须用无头浏览器把脚本跑完再取页面，实测 2.5 秒能拿到 20 篇榜单。而且榜单页的分类筛选是点击出来的，不是网址参数，加参数没用，只能抓全量再自己筛。

所以在动手搭架子之前，你直接复制下面这段话丢给智能体，让它把三条通道分别测试一遍。

你现在帮我做一次 X 内容获取的通道探路测试，先不要写完整的业务脚本。
请依次执行以下 3 个测试动作，并如实记录返回状态：

1. 找人通道测试：请求 https://api.fxtwitter.com/2/profile/<账号名>/statuses?count=12 ，看能不能拿到该账号最近的时间线数据，记下返回结果里的条数。
2. 取正文通道测试：请求 https://api.fxtwitter.com/2/status/<帖子编号> （请用一条已知的 X 长文编号测试），检查返回结果里有没有 article 字段，以及耗时多少秒。
3. 找话题通道测试：请求一次 https://api.fxtwitter.com/2/search?q=<关键词>&feed=latest ，确认它返回的状态码。如果你另外配了付费搜索密钥，再用 https://api.twitterapi.io/twitter/tweet/advanced_search?query=<关键词>&queryType=Latest 加请求头 X-API-Key 测一次，看能不能拿到帖子。

硬性要求：拿不到就说拿不到，不许编造正文，不许拿网页标题冒充正文。

验收：
跑完后向我交回一份探路清单，包含：
1. 三条通道各自返回的 HTTP 状态码和响应耗时（精确到 0.1 秒）。
2. 每条通道返回结果的顶层键名（Top-level keys）列表。
3. 取正文测试里，实际提取出来的文字总字数，以及前 100 个字的原文。

等它把结果返回来，你一眼就能看明白哪条路是通的，哪条路得加钱，接下来再动手写取正文的逻辑。

第二步：解决抓正文的问题，为什么抓下来的是链接不是正文？

因为你用了网页提取工具，或者在镜像接口里找错了顶层键名。

还记得开头那个场景吗？你把一篇长文链接丢给智能体，它平时读普通博客顺得很，偏偏读 X 长文就卡壳。我这次用普通网页正文提取工具和浏览器渲染都没拿到 X 长文正文，经常撞登录墙，后来换成镜像接口才拿到。

所以别让智能体一直死磕网页阅读工具，可以让它先试 api.fxtwitter.com 的接口。

拿到接口返回的数据后，正文藏在哪里？长文的文字一般在返回结构的 article.content.blocks 数组里，按顺序把 text 拼起来就能得到纯文字正文。图片、链接和复杂排版还得另外检查。速度非常快，实测一篇 3547 字的文章，0.2 秒返回。单篇落盘大小 27075 字节，是同一篇带排版空行的长度。

但是，这里藏着全流程里最容易忽略的一个细节，十个新手里有九个会栽在这上面。

同一个镜像，新旧接口返回的顶层键可能不一样。

新版路径（比如 /2/status/123456），顶层键通常叫 status； 旧版兼容路径（比如 /作者名/status/123456），顶层键通常叫 tweet。最终还得看接口实际返回的 JSON。

按错键去解析，拿到的是空内容，不报错，表现就是所有条目都没有正文。

Python 写脚本的时候，习惯用 .get("tweet") 这种安全写法去取值。如果智能体请求的是不带作者名的路径，再去取 tweet，拿到的就是空值。程序一丁点错都不会报，直接给你写出一个 0 字的空文件。

怎么避免？

你在提示词里让智能体兼容这两种返回结构，不要把某一种键名写死。

请帮我写一个提取单篇 X 长文完整正文的脚本，专门用来处理我丢给你的 <帖子链接> 或 <帖子编号>。

必须遵守以下技术规则：
1. 优先走 https://api.fxtwitter.com 的接口；接口失败就如实报告，不要用网页标题冒充正文。
2. 优先请求 /2/status/<帖子编号>，从返回的 status 取数据；如果碰到旧版接口返回的 tweet，也要兼容。先检查 HTTP 状态码和实际 JSON 结构，不能因为键名不对就悄悄写出空文件。
3. 如果该帖是 X 长文（包含 article 对象），读取 article.content.blocks 数组，把 text 按顺序拼成纯文字正文，段落之间保留空行；同时保存原始 JSON，遇到图片、链接或其他非文字块要记录，不能直接当作完整还原。如果是普通长帖，读取完整的 text 字段。
4. 拿不到就说拿不到，不许编造正文，如果 blocks 为空必须直接抛出异常提醒我。

验收：
请拿 <帖子链接> 跑一次脚本，向我交回：
1. 实际请求的接口完整网址，以及识别到的顶层键名（是 status 还是 tweet）。
2. 提取出的正文总字数、本地落盘的文件名和字节大小。
3. 正文开头第一段和结尾最后一段的原文文字，供我核对是否拿全。

把这一步调通了，你平时看到好文章随手丢给智能体，至少不会再因为解析错字段，拿到一个空文件还以为成功了。

下面三张是一次单篇全文落盘后的聊天记录截图：第一张能看到本地保存位置和返回的正文，后两张接续正文。

第三步：解决批量盯对标账号的问题，为什么有时候会漏抓？

在时间线之后必须补一次单篇请求，并且加上退避重试和文件去重。

单篇能拿下来了，自然会想让智能体每天早上自动去巡逻。比如你手里有一份 18 个高价值账号的名单，想看看他们过去一天半里发了什么干货。

这时候智能体去调账号时间线接口，新的坑又来了。

长文在时间线接口里，正文位置常常只有一行文章链接，必须再按编号请求一次才能拿到全文。不做这一步，抓到的还是空壳。

这就是为什么很多人明明调通了第二步，一上批量任务，抓回来的又是满屏的短链接。时间线接口为了省流量，不会把几千字的 blocks 数组塞在列表里，智能体只要发现这条帖子带了长文标记，或者正文只有一行链接，就得立刻拿着帖子编号再调一次单篇接口。

光补请求还不够。批量跑 18 个号，网络稍微晃一下就会丢数据。

免费镜像对个别账号会偶发 404 或 429，有时是上游抖动，有时是请求太频繁。那次我等了 4 秒、8 秒、12 秒再重试，失败账号从 4 个降到了 0 个。但 404 不一定是临时故障，429 也得先看接口有没有给出等待时间，不能所有错误都照一个办法死磕。

另外，落盘得记住已经成功保存的帖子编号，否则同一天重跑会重复收录。但正文没存好就不能先记成「已完成」，不然下次可能直接跳过，反而漏掉。

我那次实测批量盯 18 个账号、各取 12 条、回看 36 小时，46 秒跑完，异常 0 条，抓到 53 条内容，其中 34 条长文，最长一篇 5224 字。不过只取每个账号最近 12 条，并不能保证覆盖过去 36 小时；账号发得多，还得继续翻页。

大家可以直接把下面这段提示词交给智能体，把批量盯人的活儿彻底固化下来。

请帮我搭建一个批量盯 X 账号更新的脚本，监控名单为 <账号名列表>，先取每个账号最近的 12 条帖子；如果还没覆盖过去 36 小时，继续用 cursor 翻页，直到覆盖时间范围或确实没有下一页。只保留过去 36 小时内发布的内容。

脚本必须严格实现以下 4 个机制：
1. 长文二次补抓：遍历账号时间线时，如果发现某条帖子包含长文（article）或者正文只有一行文章链接，必须立刻用该帖子的编号，再去请求一次单篇详情接口，从 article.content.blocks 里把完整全文拼出来替换上去。
2. 抖动退避重试：遇到 429 优先按接口返回的 Retry-After 等待；没给时间就用逐次加长、带随机抖动的等待。遇到 5xx 等临时故障最多重试三次；404 先检查返回内容，确认可能是临时故障再有限重试，别无限循环。
3. 去重水位记录：在本地维护已成功保存的帖子编号记录文件（水位线）。正文保存并校验成功后，才能记为已完成；失败的帖子要留下编号供下次补抓。写文件时要防止中途断电或程序退出造成记录损坏。
4. 拿不到就说拿不到，不许编造正文。最终失败的账号和帖子都要列在失败清单里，下次继续补抓。

验收：
跑完一轮后，请向我交回：
1. 本次任务总耗时（秒）、巡检账号总数、首次请求失败但靠退避重试救回来的账号数、最终异常账号数。
2. 过滤去重后实际新落盘的帖子总数、其中长文的篇数、字数最长那一篇的字数。
3. 本地去重水位文件的路径，以及里面当前记录的帖子编号总个数。

我那次用 46 秒跑完这 18 个号，34 篇长文都存进了本地文件夹。至于有没有漏掉时间线更早的帖子，还得看分页有没有覆盖到位。

下图是另一轮批量测试：过去 24 小时、14 个账号，返回 77 条，打包后约 82 KB。它与上文的 18 个账号、36 小时测试不是同一轮。

第四步：解决按关键词搜全站的问题，为什么免费搜索老是出问题？

因为我测试时免费镜像的搜索接口连续返回 404，换付费中转能少折腾一些。

盯固定账号能解决日常跟进的问题，但有时候你想看看全站谁在聊某个新出的工具，或者某个热门事件。这时候你就得用关键词搜索。

很多人会让智能体继续去调 fxtwitter 的搜索接口，结果发现不管搜英文还是搜中文，全都是 404。智能体不明就里，还以为是自己网址拼错了，或者编码没转对，在那里没完没了地改参数。

但别把 404 直接理解成「查了，没有结果」。HTTP 404 本来是资源未找到；镜像接口即使同时返回空的 results，也可能是上游搜索故障，不能据此认定 X 上没有相关帖子。

为什么明明站内一搜一大把的词，镜像站却说没有结果？

这类故障和 X 的客户端交易标识变化有关。开源项目 FxEmbed 的工单 2303 就记录了同样的 404，维护者修复过，后来又有人报告失效；有用户换到别的机房能通几分钟，然后又挂。

如果你测试时也一直是 404，就别在这上面死磕了。

这时候可以改用付费中转服务，比如 twitterapi.io，按量计费：每 1000 条 0.15 美元，单个请求最低 0.00015 美元。按每天 6 条查询、每条取一页（最多 20 条）算，一天约 0.018 美元，一个月约 0.55 美元。

一个月 0.55 美元，也就不到四块钱人民币，比你每天盯着它反复报错、反复重试划算得多。

花钱买到的其实是搜索语法。这套查询跟 X 站内搜索是一个写法，你在提示词里就能直接卡死质量：

"一人公司" lang:zh -filter:retweets min_faves:30
(AI agent) lang:zh -filter:retweets min_faves:50

引号锁短语，lang:zh 只留中文，-filter:retweets 排掉转推，min_faves:30 是点赞门槛。这几条能筛掉一部分低互动内容，但点赞多不代表一定有价值，营销号也不会自动绝迹。 你把这些查询写成一个清单文件，一行一条，明天想加一个话题，加一行就行，脚本不用改。

不过，花钱买了中转服务，不代表你可以横冲直撞。付费服务也有免费档的每秒请求限制，撞上会返回 429「请求太频繁」。不一定隔二十秒就能恢复，脚本得按限流提示等待，没提示再做有限重试。我那次等了 5 秒、10 秒、15 秒，最后确实恢复了。

而且这里有个省钱的组合拳：你用付费中转接口把关键词搜出来，拿到那 20 条帖子的编号之后，如果里面有长文需要拿全文，千万别继续调付费接口。把搜出来的帖子编号转手交给第二步的免费镜像去取正文，搜话题花小钱，拿全文继续免费。

第五步：解决存储写作的问题，抓回来几十篇长文，怎么存才不会撑爆上下文？

清单只放截断后的几百字摘要，全文单独存文件，并且把抓取和写作拆成两个定时任务。

现在你不管是盯账号抓回来的 34 篇长文，还是搜关键词拿回来的几十条帖子，全都顺利进到本地硬盘了。接下来，你肯定想让智能体读一遍这些内容，给你挑出最值得看的几篇，写一份今日摘要。

这时候如果你直接让智能体把刚刚抓下来的所有长文一股脑全塞进上下文里，灾难就来了。

实测一篇 3547 字的长文落盘就有 27075 字节，遇到 5224 字的那种大长文体积更大。实测一份 67 条的关键词结果，正文全展开是 69KB，截断后只剩十几 KB。如果你每天把几十 KB 甚至几百 KB 的原文直接往模型嘴里硬塞，不仅仅是模型账单蹭蹭往上涨，还有它会因为上下文太长而注意力涣散，漏掉排在后面的好文章，甚至直接报错退出。

所以落盘的时候，必须分成两层来存。

批量结果写成给人看的清单时，正文只截前几百字（长文截 420 字、短推截 180 字），全文另存。这是为了让下游分析不被上下文撑爆。

智能体先读那份只有十几 KB 的截断清单，根据前 420 个字做初筛，再挑出值得细读的 3 到 5 篇，按文件编号去读完整全文。这样能省一些成本，但有的文章重点在中后段，也可能被初筛漏掉。

下面三张展示抓取结果进入选题分析后的回复，内容从账号更新归纳到可写角度。截图中的数据与判断是智能体当次输出。

还有一个特别容易踩的坑。很多人图省事，设一个早上 8 点的定时任务，让智能体「先去抓 18 个号，抓完立刻写总结发给我」。

我建议把抓取和写作拆成两个定时任务。

为什么非得拆开？因为抓取脚本不消耗模型费用，跑几十秒到几分钟；分析写作才调模型。合成一个大任务，抓取超时时可能把后面的分析也拖死。

你想想，万一今天遇到访客池抖动，触发了好几次 4 秒、8 秒、12 秒的退避重试，再加上关键词那边的 5 秒、10 秒、15 秒等待，抓取时间一下拉长到两三分钟。如果绑在一个大模型对话任务里，智能体的执行沙箱一旦判定命令超时，直接就把整个任务停止了，前面抓了 90% 的数据全白费。

我的做法是：7 点 50 分用系统的 cron 跑 Python 抓取，不唤醒大模型；8 点再让智能体分析。不过分析前要先检查当天的抓取任务有没有完成，没抓完就先别读，免得把半截数据或昨天的清单当成今天的结果。

用这 5 条标准检查真实性

脚本搭好了，定时任务也跑起来了，你作为主人，每天怎么花 10 秒钟检查智能体有没有在偷懒或者胡编乱造？大家对照这 5 条清单一条条打钩就行：

1. 看顶层键兼容：确认新版接口的 status 能正确解析；如果脚本还用旧版接口，也要兼容 tweet。字段缺失时必须报错，不能默默生成空文件。这一步可以让 Hermes 自己查。
2. 看长文长度：去全文目录里挑两篇长文，看看内容和原文能不能对上。前面那篇 3547 字的文章实测是 27075 字节，约 26.4 KiB；文件大小跟编码、排版都有关，不能只凭字节数判断抓没抓全。
3. 看重试日志：翻一下运行日志，确认遇到 429、5xx 等错误时有记录、有合理的重试。没出错时不需要硬凑几次等待；真正要防的是出错后被悄悄跳过。
4. 看水位文件：连续手动跑两次脚本。如果期间没有新帖子，第二次的新增条数应该是 0；如果第一次有正文保存失败，第二次还得能补抓，不能被水位线直接跳过。
5. 看清单体积：看一眼每日清单有没有按设定截断，比如长文预览 420 字、短推 180 字。大小不必死卡十几 KB，关键是别不小心把所有全文都塞进清单。

这 5 条都过关，至少说明基础流程能正常工作；后面还得偶尔抽查有没有漏抓。

这套方案拿不到的几类内容

把通道和脚本打磨得再精细，这套方案也不是万能的。有些内容受限于访问权限或接口形态，拿不到：

第一类，仅粉丝可见、已删除、受保护账号（锁推）的帖子。公共镜像站用的是外部访客身份，没有你的私人关注关系。

第二类，付费订阅内容。作者设置了每月交几美元才能看的专属帖子，镜像接口和付费搜索中转都拿不到正文，只能看到外面的引子。

第三类，图片和图表里的信息。单纯把 blocks 里的 text 拼起来，不能还原图片、图表和全部排版。如果作者把核心数据做成了长图，你抓下来的文字可能只剩一句「如下图所示」。真遇到这种帖子，你得自己点开原链接看图。

第四类，不稳定的免费全站关键词搜索。工单 2303 说明它确实反复出过问题，但不是说它永远不可能恢复。能不能用，还是以你当天的探路结果为准。

还有一点得说清楚：X 的服务条款限制未经许可的自动抓取。第三方镜像能用，不代表 X 授权你这样用；长期运行或公开传播抓到的内容前，要自己确认平台条款和版权边界。

省下的是体力，留下的是思考

搭这么一套流水线，前前后后也就花半个下午的时间。跑顺了之后，每天花不到两美分，几十秒就能把外面几万字的行业长文干干净净地搬进你的本地硬盘。

荀子说，君子生非异也，善假于物也。做内容也是一个道理，工具替你跑腿，判断还得自己来。

其实我们折腾 Hermes、折腾镜像接口，图的从来不是让硬盘里多堆几百兆没人看的文字垃圾，而是把杂活累活让机器去干，自己专注思考的时间。

把翻网页、撞登录墙、复制粘贴、去重排版的苦力活全教给自动脚本，你早上 8 点坐到电脑前，省下来的是到处搜集的时间，留下来的是你自己的判断。哪些证据真能站得住脚，哪些写法今天就能化用到自己的文章里，这才是智能体永远替不了你的事。