图像
价值 1 万刀的稳定的小红书“API”，现在完全免费
12万
2026 年 5 月 10 日，FundaAI 的 AI 工程师面包（
@himself65
）在 X 上发了一条求助：
Bread🍞
@himself65
怎么拿到稳定的小红书API？我愿意一个月花一千刀
18万
这条帖子当天浏览十几万。回复区里牛马AI创始人
@yangyi
直接接话：
1000 美元 × 10 = 每月 1 万美元，这是当前中文 AI 圈里最贵的一份心愿清单。
小红书没有官方公开的稳定 API，这件事大家都心知肚明。社区里被翻来覆去提到的方案是开源的如 xiaohongshu-mcp 几乎每一种都会在某个时刻撞上风控、IP 封禁、滑块、设备指纹这几道关，再多钱也拿不到真正稳定的。
图像
本文要拆解的利器的核心定位是：可以操控手机App的云端Agent，它还公开了 Claude Code / Codex 插件，可以结合Claude Code或者Codex使用。
下面是结果预览。
图像

一、云端操控手机App的AI Agent

下图工具跟API形态最大的差别在这里：LLM agent 操作一台真正的安卓——所有点击都发生在屏幕上，所有数据来自界面渲染后的元素树。
图像
对于一个手机端 AI Agent，能在后台监控应用并执行任务十分重要，架构分三层：
图像
还能直接跳过网页界面，从Claude Code、Codex、甚至Hermes等我们熟悉的AI Agent来操控。这个可选路径背后是同一份 SKILL，同一个
airtap.py
CLI（封装 9 个子命令），同一个 REST 后端。CLI 提供的 9 个子命令是这个工具的实际"API 面"：
图像
模型当前两档：airtap-1.0-flash（默认，低延迟）、airtap-1.0（更可靠，单 task 慢一档）。Debug 用户可以看到 airtap-1.0-lite。

二、拆解一条 task，等于拆解一次API 调用

下面这条 task 来自 2026-05-12 的真实运行（在Claude Code完成）：
plaintext
python3 scripts/airtap.py task create \
  --receiver-id "receiver-0bcde074c1997f26" \
  --model-id "airtap-1.0" \
  --message "帮我打开小红书（red note）app，整理关于'量化交易'主题相关的最热门的10篇note，总结其风格"
返回：
plaintext
{ "status": "Success", "taskId": "task-T2RllMEPp42fCNIImtKtf", "message": "Task created successfully" }
121 秒后状态变成 COMPLETED。中间产生了 1 条 user message + 12 条 agent message。完整轨迹：
task-T2RllMEPp42fCNIImtKtf  ·  121s  ·  5 截图
│
├─  0  user       prompt: 量化交易 Top 10
├─  1  agent      Preparing
├─  2  Planning   拆出 5 步执行计划
├─  3  Operating  GetAndroidState
├─  4  Operating  Tap 搜索框                    [+img]
├─  5  Operating  Searching for top 10
├─  6  Operating  InputText "量化交易"          [+img]
├─  7  Operating  Tap 搜索按钮                  [+img]
├─  8  Operating  Tap "最火" 标签               [+img]
├─  9  Operating  Viewing results
├─ 10  Operating  提取单帧文字                  [+img]
├─ 11  Operating  scroll_capture 5 页 → 拼接长图
└─ 12  Summary    markdown 总结（1939 字）
每条 agent message 都是一个 parts 数组，常见的 parts.type 有三种：
  • text：自然语言进度更新或最终输出
  • image：单帧屏幕截图，URL 形如
    https://airtap.ai/content/live/img/2026-05-12/
    <account-id>/screenshot-task-<task-id>-<epoch-ms>.jpeg，公网可直接访问
  • 拼接长图（在 scroll_capture 步骤）：URL 形如 .../scroll_capture-task-<task-id>_step-<step-id>-<epoch-ms>.jpeg，附带 Merged visible text 和 Merged interactable elements 两段结构化文本
这里有一个关键发现：Merged interactable elements 段直接暴露了 Android 节点树，包含 Android resource-id。例如这次 task 里小红书 App 的关键字段：
android.widget.TextView: com.xingin.xhs:id/noteTitle, <笔记标题>
android.widget.TextView: com.xingin.xhs:id/authorName, <作者名>
android.widget.TextView: com.xingin.xhs:id/infoBelowAuthorName, <发布日期>
android.widget.TextView: com.xingin.xhs:id/interactionText, <互动量>
android.widget.TextView: com.xingin.xhs:id/itemText, <标签：Top / Latest / 策略 / 最火>
也就是说，Airtap 在执行任务的过程中顺带把小红书的字段定位规则全公开了。下游做爬虫的人可以用这份节点树反推 XPath / UiAutomator 选择器；下游做 LLM 应用的人可以把这段拼接图喂给另一个模型做二次结构化。这一层信息在传统 API 里通常是被屏蔽的，反而在 Airtap 这种"agent 操作真机"的形态里完全裸奔。
任务最后还附带一个 followOnSuggestions 字段：
[
  "Export this analysis to a report document",
  "Show me the engagement patterns between these top 10 notes",
  "Find similar successful note formats across other finance topics"
]
这是 Airtap 自己根据已完成任务推荐的下一步动作，可以理解为产品内置的 "Continue" 选项，对接 task 的 add-user-message 即可继续。

三、稳定性真相：n=2 的对照

同一个 prompt、同一台物理 Receiver、同一个 airtap-1.0 模型，在 2026-05-12 上下相差约 18 分钟跑了两次。两次结果对照：
图像
两次跑出来的 Top 10 作者：
Round 0:  叮当学财经, 数字游牧人, 大海哥的AI发电厂, 马哥做量化, 小圆量化,
          原力量化, 露娜派得, 多半要涨, Vanta TechLab, 高顿CQF量化培训
Round A:  数字游牧人, AI星星酱, 祎洺, Robin同学, 露娜派得,
          AI野路子交易员, 小鱼蛋卷, 小圆量化, 量化瑞贝卡卡, 量化实验室
重合：    数字游牧人, 露娜派得, 小圆量化   →  30%
第二组里 7 个新作者，第一组里 7 个消失。两次都说自己取的是"最火"标签下的 Top 10。
这条数据需要被分两层理解：
结构层 100% 稳定。两次的 agent 调用链一模一样：Plan → GetAndroidState → Tap 搜索框 → InputText → Tap 搜索 → Tap "最火" 过滤器 → 视窗截图 → scroll_capture 5 页 → 总结。步数、截图数、scroll 触发条件全部相同。从接入 SDK 的视角看，它是一个 schema 稳定的接口。
数据层 30% 重合。原因不在 Airtap，在小红书自己——"最火"是个个性化推荐流，受登录态、地理位置、时段、账号画像影响。同一个用户、同一台设备，两次刷新看到的"最火 Top 10"本来就不一样。
这一点对"API"这个词的定义至关重要。OpenAI 的 GET /v1/models 一周内可能加进 5 个模型再下掉 2 个；Twitter 的 GET /search 一秒之内两次调用结果不一样。API 从来不承诺数据不变，承诺的是接口契约不变。按这个口径，Airtap 在小红书这条管道上确实达到了"API"的工程下限：CLI 命令稳定、JSON schema 稳定、Android resource-id 稳定。
但要把这套东西当成传统爬虫意义上的"稳定 API"，会遇到这几个问题：
  1. 单次 task 121–178 秒级延迟，不适合实时检索
  2. 数据来源是 LLM 看屏幕 + OCR + 节点抽取，不是直连数据库
  3. 内容层受推荐算法主导，重跑同 query 拿到的具体笔记会变

四、SDK 边界：容易遇到的错误

跑 Round A 的时候，本地 task poll 命令中途收到一次错误并主动退出：
Error: Airtap API request failed for /task/v1/taskGetDetails.
Get an updated version of the Airtap skill before retrying.
但服务端 task 没有被这个错误打断——再发一次 task get-details 拿到的状态已经是 COMPLETED，messages 完整，截图 URL 可用。
也就是说，SDK 客户端的 transient failure 与 task 自己的生命周期是解耦的。任务一旦创建就在云端独立推进，本地轮询失败只影响"你能不能拿到中间进度"，不影响最终能不能拿到结果。
这个解耦对于把 Airtap 当 API 用是个利好——意味着 client 重连、跨进程恢复、跨设备查询都可行，taskId 是足以恢复一切状态的唯一句柄。

五、1 万美元订单里 Airtap 能覆盖多少？

回到那条 1 万刀求购帖。如果把
@himself65
这种买家的真实需求拆开，大致可以归到四类：
图像
第一、二类需求覆盖最干净。Round 0 那条 task 直出的总结，已经接近一份能交付的"小红书趋势报告"。如果客户买的是"每天一份某关键词下的最火 Top 10"，Airtap + 一条 cron 就能跑。
第三类是当前数据缺口。原计划里有一组实测要点进 #1 笔记拿正文，但 Seeker 的 tap 出现异常，那组数据没跑成。后续补足后会单独成文。
第四类是暂时还无法解决的问题。

六、如何用？

基础配置：
https://airtap.ai/
Skill（可选）：
https://github.com/airtap-ai/airtap-skill
部分具体操作可交给Codex、Claude Code。
云手机不需要登录态就能跑的场景：YouTube 热门、Google Maps 路线、Wikipedia 搜索、安装 App 后的初始化界面截图。要做小红书 / 微信 / 美团这类需要登录的，必须配置物理机。
想发布自己的文章？
升级为 Premium
  • WquGuru🦀
    @wquguru
    AI+量化+工程 掌握Vibe Coding 12原则 12factor.me/zh 从会用Agent，到做出Agent PoC agentway.dev/zh 欢迎 DM👋