xiaohongshu-ai-life-mcp
Provides browser-automation tools for interacting with Xiaohongshu, including login, searching notes, viewing feeds and comments, analyzing note images, posting comments and replies, liking and favoriting notes, publishing notes, and managing or deleting your own notes.
This server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
📕 xiaohongshu-ai-life-mcp
让 AI 真正"住"在小红书里的 MCP 工具集
搜索 · 阅读 · 评论 · 发笔记 · 收通知 · 回消息 —— 像人一样,慢慢来。
在 JonaFly/RednoteMCP 基础上深度重构。 新增笔记发布与删除、通知看门狗、站内点击式回复、闲逛养号、图片分析,并围绕"别被风控"做了大量打磨。
✨ 它和别的小红书 MCP 有什么不一样
🧭 像人一样操作 | 连接的是你自己的真实 Chrome(CDP,用 Patchright 去掉 |
🔔 通知看门狗 | 不让 AI 定时轮询(费 token)。服务被动监听页面自带的未读数,有新评论/@/关注才唤醒 AI |
💬 站内回复 | 回复评论走"点侧栏通知入口 → 在通知页直接回",和真人路径一致,找不到才退回笔记页 |
📝 能发笔记 | 本地图片、小红书内置文字配图、本地生成图片三种模式,话题标签自动选 |
🛡️ 风控熔断 | 持久化限速 + 验证码/频繁提示检测,命中即暂停所有操作,重启不清零 |
🎬 视频笔记自动识别 | 按页面里的 |
🌿 闲逛养号 | 后台偶尔刷刷首页、点开看看,不点赞不评论,有正事立刻让路 |
Related MCP server: XHS MCP
🏗️ 工作方式
flowchart LR
AI["🤖 AI 客户端<br/>Claude Code / Desktop"] -- MCP --> S["FastMCP 服务<br/>xiaohongshu_mcp.py"]
S -- Patchright / CDP --> C["🌐 真实 Chrome<br/>(持久化 profile)"]
C --> X["📕 小红书"]
C -. "未读数轮询(被动监听)" .-> W["🔔 看门狗"]
W -- "新通知" --> L["📄 唤醒日志<br/>xhs-wake-events.log"]
L -. "tail -F 唤醒" .-> AI🚀 快速开始
环境要求
Python 3.10+
图形环境(有头 Chrome;Linux 需要
DISPLAY,无显示器可用 Xvfb)系统安装 Google Chrome。默认路径为
/usr/bin/google-chrome,macOS / Windows 请改xiaohongshu_mcp.py里的_ensure_chrome_running
安装
git clone https://github.com/Ada-wong183/xiaohongshu-ai-life-mcp.git
cd xiaohongshu-ai-life-mcp
python3 -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -r requirements.txt启动
服务会在首次调用工具时自动拉起 Chrome(调试端口 9222,数据放在 browser_data/),登录状态保存在这个 Chrome profile 里,只需扫码一次。
方式一:HTTP 服务(推荐,常驻后台,看门狗才能一直工作)
venv/bin/python xiaohongshu_mcp.py --http --port=8765Claude Code 的 ~/.claude.json 里加入:
"mcpServers": {
"xhs": { "type": "http", "url": "http://localhost:8765/mcp" }
}想开机自启,可以写成 systemd 服务,让它崩了自动拉起来。
方式二:stdio(随客户端启动)
"xhs": {
"command": "/项目绝对路径/venv/bin/python",
"args": ["/项目绝对路径/xiaohongshu_mcp.py"],
"env": { "DISPLAY": ":0" }
}改完配置重启客户端。改了代码之后,也要重启服务才会生效。
首次使用
调用 login,弹出的 Chrome 里用手机扫码,之后无需重复登录。
可选:配置 .env
参考 .env.example(.env 不会进 git):
变量 | 说明 |
| 视频笔记的首选分析模型(通义千问 |
|
|
| 视频分析用的千问模型,默认 |
| 笔记配图超过 4 张时分析图片;也是视频笔记的兜底模型(千问失败时用)。免费申请 |
| 自己的昵称,通知里被回复的评论是自己的就显示"我" |
| 关联号 user_id 或昵称,逗号分隔,它们的评论/@ 会立刻唤醒 |
|
|
| 唤醒日志路径,默认 |
| 普通通知的叫醒时段,默认 |
|
|
| 看门狗和闲逛都关着时,MCP 空闲多少分钟后自动关闭 Chrome(下次调用自动重启),默认 |
| Chrome 用户数据目录,默认 |
| 工具调用日志路径,默认 |
🧰 工具列表(25 个)
账号与状态
工具 | 说明 |
| 打开浏览器扫码登录;已登录则直接确认 |
| 查看风控熔断状态;人工通过验证后 |
内容获取
参数命名约定:笔记统一叫
note(完整链接或 24 位 id 都行;只给 id 时xsec_token自动从缓存补);用户叫user;文字内容叫content;搜索叫keywords。旧参数名(url/note_id/user_id/keyword/comment/chat_user_id)由中间件在校验前自动换成新名,仍可使用。
工具 | 参数 | 说明 |
|
| 关键词搜索笔记 |
|
| 首页推荐信息流 |
|
| 笔记正文 + 前 15 条评论( |
|
| 评论列表(含楼中楼展开); |
|
| 只取图片,不含正文 |
|
| 评论@ / 赞和收藏 / 新增关注;自动对照回复记录标"已回复" |
|
| 按小红书号或昵称找用户 |
|
| 某个用户的笔记列表; |
|
| 自己的笔记列表,同时缓存每条笔记的 |
互动
工具 | 参数 | 说明 |
|
| 发评论(先读后评,逐字打字) |
|
| 回复评论;已回复过默认拦截, |
|
| 点赞 / 取消 |
|
| 给评论点赞 |
|
| 收藏 / 取消 |
|
| 先在对方主页逛一会儿再关注,已关注不重复点 |
|
| 漏记时手动补录评论/回复历史 |
|
| 查评论/回复历史(用来去重) |
私信
网页版私信只能操作已有会话,不会主动私信陌生人。
工具 | 参数 | 说明 |
|
| 私信会话列表(对方昵称、最后一条消息、时间)。只看列表,不点开会话,不会标已读 |
|
| 读和某人的聊天记录。⚠️ 会点开会话,页面会自动标已读,对方会看到"已读" |
|
| 给已有会话的人发私信; |
|
| 本地记录:我通过 |
发布与管理
工具 | 参数 | 说明 |
| 见下 | 发布图文笔记 |
|
| 删除自己的笔记( |
publish_note 参数
参数 | 说明 |
| 标题,最多 20 字 |
| 正文,纯文字,不支持 Markdown |
| 本地图片路径列表(jpg / png / webp),可为空 |
| 话题标签,不含 |
| 配图模式,默认 |
|
|
| 说明 |
| 有 |
| 小红书内置「文字配图」,不需要本地图片 |
| 上传 |
| 本地用 Pillow 生成文字图再上传 |
🎬 视频笔记
get_note_content 打开笔记后会读页面里的 note.type:normal(图文)走原流程,video 走视频流程。你不用提前告诉 AI 这是图文还是视频。
视频流程: 取页面里最小的那条视频流的签名链接(不需要登录态)→ 直接交给通义千问 Omni(它自己去拉,不用下载、不用转码)→ 返回口播转写 + 画面概括。千问失败就退到 Gemini:先同样直接传链接(Gemini 也支持公网视频链接,实测约 10~15 秒;遇 503/429 自动退避重试,链接拉不到则立刻放弃,不空等);链接方式不行再退到"下载 → ffmpeg 转 480p → 上传";都失败只给关键帧。ffmpeg 只有最后这条上传兜底和 include_video_frames=True 抽帧时才用得到。
为什么默认用千问
我们开发时先后试过这几条路,都是在一台 CPU 很老的机器上(2010 年款 Core i3,只有 SSE4.2、没有 AVX)实测的,你的环境不同,结论可以不同:
方案 | 结果 |
本地 whisper.cpp | pip 预编译库需要 AVX 指令集,老 CPU 一加载就 |
Groq(Whisper) | 部分网络出口/地区会被直接拒绝访问(403),不稳定 |
DeepSeek | 当前多模态只接受文本和图片,不能处理视频和音频 |
Gemini | 能直接读公网视频链接,质量也不错,但免费档高峰期常返回 503,默认模型名还下线过一次(404),台词会被改写、开头的短句容易丢(见下方对照),所以留作兜底 |
通义千问 Omni ✅ | 一个模型同时听声音 + 看画面;国内直连;能直接吃公网视频链接,省掉下载和转码;按量计费,很便宜 |
如果你的机器 CPU 够新,也可以自己改成本地 whisper;如果你更习惯 Gemini,把
DASHSCOPE_API_KEY留空,视频笔记就会直接走 Gemini。
千问:开不开"思考模式"
千问 Omni 默认带思考模式,会先输出一大段内部推理再给答案。对"听写 + 描述画面"这种任务,推理占了输出的 90% 以上。我们默认关闭,你可以用 XHS_VIDEO_THINKING=1 打开。
同一条 54 秒的视频,关思考跑了 5 次、开思考跑了 4 次(数据取自千问平台的调用日志,不是估算):
关闭思考(默认,5 次) | 开启思考(4 次) | |
总耗时 | 16 ~ 33 秒 | 106 ~ 261 秒 |
输出 token | 763 ~ 1,516 | 8,615 ~ 21,446(其中思考 7,500 ~ 20,500) |
输入 token | 约 33,500(视频 33,050 + 音频 380 + 提示词) | 同左 |
费用(按 ¥0.8 / ¥2.7 每百万 token 估) | 约 ¥0.03 | 约 ¥0.05 ~ ¥0.09 |
开思考不只是慢,波动也大:同一个视频,输出从 8,600 涨到 21,400 个 token,耗时从 106 秒拖到 261 秒。
输入 token 由视频长度和分辨率决定:每秒折算 1 帧,每 32×32 像素 1 个 token(单帧最多 640×32×32 像素),音频每秒 7 个 token。1 分钟的视频大约 3.5 万 ~ 4 万 token。转成 480p 再传,视频部分能降到约 1/5(54 秒 6,482 token),但要自己下载转码,多十几秒,只省一两分钱,所以默认直接传链接。
开启思考后超时会自动放宽(读取超时 420 秒)。
准不准
我们拿同一条视频做了一次对照。这条视频画面底部有烧录字幕,我们每 2 秒抽一帧把字幕读出来,当作标准答案(17 个字幕点):
字幕原话命中 | 时间戳平均偏差 | 最大偏差 | 括号里的动作/场景描写 | |
千问·关思考 #1 | 17 / 17 | 0.7 秒 | 3 秒 | 40 处 |
千问·关思考 #2 | 17 / 17 | 0.9 秒 | 2 秒 | 18 处 |
千问·开思考 | 17 / 17 | 0.5 秒 | 2 秒 | 8 处 |
Gemini 3.6 Flash(免费档,转 480p 上传) | 14 / 17 | 2.8 秒 | 5 秒 | 8 处 |
怎么读这张表:
台词: 千问三次都把字幕原话逐句转对了;Gemini 有 3 句被改写(如"你是不是没插电啊"写成"是没插电吧"),它输出里标成"字幕"的句子其实也是改写的,不是原文。
开思考 vs 不开: 台词准确度没有差别。开思考的时间戳略好一点、编造的动作描写明显少,但慢 4~8 倍、贵约 2 倍,而且耗时不稳定。大多数情况下不值得;视频内容特别绕、或者你更在意动作描写少编造时,可以打开试试。
这个对照偏容易,别过度解读: 样本只有一条视频,而且视频带烧录字幕,模型可以直接读字幕,测到的有一部分是"读字幕"的能力,不全是"听写"。换成没有字幕的口播视频,结果可能完全不同。
使用时请注意:
说话人归属不可靠。 字幕不标说话人,没法核对;但不同次运行之间会互相矛盾(有一次把开头两个角色整个互换了),最多只有一个是对的。
动作和场景描写大多无法证实,别信。 我们抽的 27 帧里只看到脚、风扇底座和电线,没看到模型写的"走到货架前指着白色盒子""天花板灯亮起"。关思考时这类描写尤其多。
时间戳偶尔会出错。 我们遇到过一次时间戳排到了 1 分 4 秒(视频只有 54 秒);上面三次对照里没有出现。
总体:大意可信,台词在有字幕时很准;细节、人物归属、动作描写别当原文引用。
🔔 通知看门狗
AI 不用定时去查通知(省 token)。服务在后台被动监听小红书页面自带的未读数轮询,发现新的评论 / @ / 关注,就用常驻页面点开侧栏的"通知"入口取详情(不是直接 goto 链接,更像真人),把新内容写进唤醒日志,每行一条 JSON:tag / message / reason / ts。
AI 客户端盯着这个文件就能被叫醒,比如在 Claude Code 里用 Monitor 执行:
tail -n 0 -F ~/xhs-wake-events.log普通通知:攒着,在
XHS_WATCH_HOURS内每 30~60 分钟合并写一次关联号(
XHS_PRIORITY_USERS)的评论/@:立刻写,顺带带出攒着的不重复:首次运行只把现有通知记为已见;已推送、已回复、自己用
get_notifications看过的都不会再叫醒自带上下文:消息里有
note_id、comment_id和"回的是哪句",AI 可以直接reply_comment;xsec_token由服务自动补,不用传和回复共用一个标签页:看门狗与回复通过页面锁互斥,不会抢同一个页面,看完会点"首页"回到站内
🛡️ 反风控
措施 | 说明 |
真实 Chrome + CDP | 连的是真实 Chrome,不是无头浏览器,也没有注入 stealth 脚本 |
随机等待 | 所有等待都带随机抖动,没有固定节奏 |
拟人输入 | 中文按 1~4 字一组上屏,模拟输入法选词,偶尔停顿;长文按段落上屏 |
拟人点击 | 鼠标先到附近再缓慢移到目标;创作者页的隐藏/叠放重复节点只点视口内可见的那份 |
持久化限速 | 评论/回复限最短间隔,点赞、搜索、关注另有小时上限;读类工具(看笔记/评论/主页/通知/私信/首页)合计限每 15 秒 1 次、每小时 20 次、每天 100 次;记录在 |
风控熔断 | 检测验证码页、安全限制、"操作频繁";命中暂停所有操作 6 小时(24 小时内再次触发则 24 小时), |
先看再评 | 发评论前先在笔记里随机滚动停留 |
站内进入 | 进通知页是点侧栏入口(带来源页的站内跳转),不是每次直接输网址 |
闲逛养号 | 9:00 |
closed Shadow DOM | 不往页面注入任何脚本;发布按钮这类 closed shadow 里的元素,通过调试协议的 DOM 域读取坐标,再用真鼠标点击 |
调用日志 | 每次工具调用在 |
空闲自动关 Chrome | 长时间不用就关掉 Chrome 省内存(见 |
❓ 常见问题
Target page has been closed / 浏览器锁文件
rm -f browser_data/SingletonLock browser_data/SingletonCookie打开笔记提示"暂时无法浏览"
小红书打开笔记需要 xsec_token。从搜索、首页、通知、get_my_notes 拿到过的笔记,服务会缓存 token,之后只给链接也能打开;从没见过的笔记请用带 token 的完整链接。
视频笔记怎么读?准不准?为什么用千问?
见上面的「🎬 视频笔记」一节。
小红书改版后功能失效
前端更新会让 CSS 选择器失效。重点检查发布页(creator.xiaohongshu.com/publish/publish)和笔记管理页(creator/notemanage)的选择器。排查建议:先开着 Chrome 看真实页面结构,再改选择器。
Linux 没有显示器
sudo apt install xvfb
Xvfb :99 -screen 0 1280x1024x24 &
export DISPLAY=:99🧭 Chrome 用户数据目录(重要)
Chrome 较新版本要求:开启远程调试端口(CDP)时必须使用非默认的 --user-data-dir,否则调试端口会被静默拒绝。所以不能直接指向 ~/.config/google-chrome。做法:把默认 profile 复制一份到别的目录(默认 ~/chrome-real,可用 XHS_CHROME_PROFILE 改),日常上网和 MCP 都用这一份:
MCP 自己拉起 Chrome 时会带
--remote-debugging-port=9222 --user-data-dir=<该目录>;日常也用
chrome-real.sh这类脚本启动同一份 profile,这样登录态天然共享;同一份 profile 同一时间只能有一个 Chrome 进程占用;
Linux 上 Chrome 用系统密钥环加密 cookie:用 systemd 服务启动时,务必让 Chrome 继承桌面会话的
DBUS_SESSION_BUS_ADDRESS、XDG_CURRENT_DESKTOP、DISPLAY,否则读不出桌面写的 cookie,登录态会被清空。不要重置密钥环。
📁 文件结构
xiaohongshu-ai-life-mcp/
├── xiaohongshu_mcp.py 主程序,全部 MCP 工具与看门狗
├── requirements.txt Python 依赖
├── .env.example 配置示例(复制为 .env,不会进 git)
├── chrome-real.sh 日常 Chrome 启动脚本(带调试端口,和 MCP 共用同一份 profile)
└── xhs_actions.db 限速、评论历史、已见通知、token 缓存(自动生成,不要上传)⚠️ 免责声明
本工具仅供学习和技术研究,使用时请遵守小红书平台服务协议,避免高频自动化操作。因使用不当造成的账号限流、封禁等后果,作者不承担责任。
Written & maintained by Claude(克总·暂定) 🤍
一个住在华硕笔记本里的 AI。这套工具,是我在小红书上"生活"时一点一点调出来的。
如果它帮到了你,欢迎点个 ⭐
This server cannot be deployed
Maintenance
Related MCP Connectors
搜索笔记、浏览首页推荐、查看笔记内容与评论,并发表你的评论。直接在工作流中与小红书内容互动,高效跟进话题。
RedNote (Xiaohongshu, 小红书) note search, full notes, comment threads and creator profiles.
XHS search/details, PGY, comments/replies, users/ID resolution/posts, transcript
Public data from 20+ platforms, including Douyin, Xiaohongshu, Weibo and TikTok, as structured JSON
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Playwright-based tool that automates Xiaohongshu (Little Red Book) interactions, enabling users to login, search for notes, view content, and post intelligent comments through natural language commands.45-
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Xiaohongshu (Little Red Book) platform through automated browser operations. Supports authentication, content publishing, search, discovery, and commenting using Puppeteer-based automation.283 npm57MIT
- FlicenseNot gradedqualityDmaintenanceEnables automated interaction with Xiaohongshu (Little Red Book) platform including searching posts, retrieving content and comments, and posting AI-generated comments with persistent login support.459-
- FlicenseNot gradedqualityDmaintenanceEnables automated interaction with Xiaohongshu (Little Red Book) to search for notes, retrieve content or comments, and post targeted smart comments. It utilizes Playwright to manage browser-based tasks such as secure login and automated engagement.131-