小红书自动搜索评论工具（MCP Server 2.0）

想象这样一个场景：你是某美妆品牌的运营人员，每天需要在小红书上搜索竞品关键词，浏览数十篇笔记，手动回复评论——这枯燥的重复劳动占据了你大半天的时间。而现在，有一款工具可以帮你自动化这一切：只要告诉它「帮我搜索护肤相关的笔记，写一条专业型评论」，它就能自动完成从登录、搜索、内容抓取到评论生成的全部流程，而你只需喝杯咖啡等待结果。这就是 chenningling/Redbook-Search-Comment-MCP2.0 所做的事情。

项目起源：MCP 协议催生的社交媒体自动化浪潮

图1：项目作者 chenningling 在 GitHub 的头像

本项目诞生于 2024 年前后，是 MCP（Model Context Protocol）生态蓬勃发展的产物。MCP 是 Anthropic 在 2024 年底推出的一种大模型扩展协议，允许 AI 模型通过标准化的接口调用外部工具。相比传统的 Function Calling，MCP 的优势在于「一次配置，永久使用」——开发者只需编写一个 MCP Server，就能无缝接入 Claude Desktop、Cursor、Windsurf 等所有支持 MCP 的 AI 客户端。

该项目基于早期 JonaFly/RednoteMCP 进行了全面重构和功能扩展，由用户 chenningling（网名 windsurf）维护，目前已在 GitHub 获得 433 颗星，被 LobeHub、mcpservers.org 等多个 MCP 社区收录。截至 2025 年中，该项目已提交 19 次 commit，活跃度稳定。

核心架构：模块化 MCP Server 设计

技术栈概览

项目的代码规模不大，但架构清晰有序。仅包含以下核心文件：

• xiaohongshu_mcp.py：主入口文件，实现了所有 MCP 工具函数（约 400+ 行 Python）
• requirements.txt：依赖清单
• Dockerfile：容器化支持
• README.md / README_EN.md：中英文文档
• test_mcp.py：测试文件

技术栈非常务实：

• Playwright（>= 1.40.0）：浏览器自动化框架，替代了 Selenium 成为 Python 爬虫的新标准
• FastMCP（mcp[cli]）：由 FastMCP 库提供的 MCP Server 框架，简化了 MCP 协议的实现
• asyncio：全程异步编程，配合 Playwright 的异步 API
• pandas / numpy：数据处理，用于结构化输出搜索结果
• FastAPI + uvicorn：HTTP 服务层（MCP 本身走 stdio 协议）

三大核心模块

项目采用两步式评论流程，将功能分解为三个独立模块：

模块一：笔记分析（analyze_note）

get_note_content() 函数执行笔记内容抓取，集成四种不同的内容获取策略，确保能适应小红书页面结构的变化。具体流程是：页面加载 → 滚动触发懒加载 → 提取笔记标题、作者、正文、发布时间。该模块返回结构化的 JSON 数据，包含笔记所属领域和关键词，供下游 AI 评论生成使用。

模块二：评论生成（由 MCP 客户端实现）

项目的一个巧妙设计是将「生成」这一步交给 MCP 客户端的 AI 能力完成。post_smart_comment() 工具只负责返回笔记分析结果，实际的评论内容由 Claude 等大模型基于笔记上下文动态生成。这种设计避免了工具自身维护一套固定评论模板的尴尬——AI 生成的评论更自然、更贴合笔记内容。

支持四种评论类型：

• 引流型：引导关注或私信，适合品牌曝光
• 点赞型：简单友好互动，提升笔记热度
• 咨询型：以提问方式引发博主回复，增加互动深度
• 专业型：展示专业知识，建立账号权威性

模块三：评论发布（post_comment）

post_comment() 函数负责将生成的评论内容实际发布到小红书笔记下。流程包括：URL 解析 → 页面导航 → 评论框定位 → 内容填写 → 提交发布。

浏览器持久化上下文

项目使用 Playwright 的 chromium.launch_persistent_context() API 创建持久化浏览器上下文。与传统 Selenium/Firefox 不同，持久化上下文会保存用户登录状态的 Cookies 和 Session 数据，首次扫码登录后，后续运行无需重复认证。浏览器数据默认存储在项目根目录的 browser_data/ 文件夹中。

⚠️ 注意：代码中 headless=False（非无头模式），运行时会有真实浏览器窗口弹出。如果需要后台运行，需要手动修改代码。

部署体验：从安装到运行的完整流程

方式一：Docker 部署（推荐生产环境）

Dockerfile 基于 python:3.9-slim，安装了完整的 Playwright Chromium 依赖栈，镜像大小约 2-3GB。构建后只需运行容器即可：

docker build -t xiaohongshu-mcp .
docker run -v $(pwd)/browser_data:/app/browser_data xiaohongshu-mcp

容器方式的优点是环境隔离、依赖一致；缺点是首次启动需要手动扫码（除非挂载已有的 browser_data 卷）。

方式二：本地 Python 环境

git clone https://github.com/chenningling/Redbook-Search-Comment-MCP2.0.git
cd Redbook-Search-Comment-MCP2.0
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
playwright install chromium

安装完成后，需要在 Claude Desktop 或其他 MCP 客户端的配置文件中注册该 Server。配置文件格式为 JSON，在 mcpServers 字段下添加 xiaohongshu MCP 条目，指定虚拟环境中 Python 解释器的绝对路径，以及 xiaohongshu_mcp.py 的绝对路径。

硬件与性能需求

• CPU：任意 x86_64 / ARM64
• 内存：2-4GB（浏览器实例本身占用约 300MB，加上 Python 运行时）
• 磁盘：1-2GB（主要是 Playwright 浏览器二进制和 browser_data 持久化数据）
• GPU：不需要

平台兼容性：为什么没有 Web UI？

作为一款 MCP Server，该项目本质上是一个命令行工具，它被设计为通过 AI 客户端的中枢能力来驱动操作，而非独立提供图形界面。这意味着：

• 没有独立的 Web UI：所有操作都通过 MCP Client 发起
• 需要 AI 客户端配合：Claude Desktop / Cursor / Windsurf 任选其一
• MCP 协议限制：stdio 传输模式无法直接通过浏览器访问

这种设计的优势在于项目体积小、维护成本低，且天然借助 AI 的语言理解能力实现更智能的操作指令。劣势则在于门槛较高——用户必须先了解 MCP 生态，并拥有可用的 MCP 客户端。

局限与风险：透明地谈一谈

1. 平台反爬风险

小红书对自动化行为有严格检测机制。项目在 README 中明确建议：每天评论不超过 30 条，避免短时间内大量操作。使用时务必控制频率，长期高频操作可能导致账号被封禁。项目本身也附带了详细的平台变化适应方案（CSS 选择器调整等）。

2. Playwright 非无头模式

当前代码 headless=False，意味着运行时会弹出 Chrome 浏览器窗口。这在调试时有用，但在正式使用时可能不够优雅。如果需要完全后台运行，需要手动修改代码为 headless=True。

3. 平台结构依赖性

小红书的前端页面结构经常变化（CSS 类名、XPath 选择器），一旦平台更新，代码中的 DOM 选择器可能失效。项目采用了「多策略内容获取」（四种方法依次尝试）来增强鲁棒性，但仍需用户关注维护更新。

4. 登录状态管理

依赖浏览器持久化上下文保存 Cookie。如果 browser_data 目录被删除或 Cookie 过期，需要重新扫码登录。多设备登录会被小红书踢出（建议 MCP 登录后不再在其他浏览器登录同账号）。

在 MCP 生态中的定位

MCP 生态中，与小红书自动化相关的项目并不少见——有的侧重笔记发布，有的侧重数据采集，而本项目的独特价值在于将评论行为与 AI 生成能力深度结合。通过 MCP 协议，它利用 Claude 等大模型的语义理解能力生成更自然、更相关的评论，而不是简单的关键词模板替换。

随着 MCP 生态的持续扩张，这类工具的出现预示着一个趋势：AI Agent 不再只处理文本任务，而是开始介入真实世界的平台操作。从自动发帖到评论互动，AI 正在从「聊天伙伴」演变为「数字代理人」。本项目正是这一趋势的一个具体案例——小巧、专注，但切中了一个真实的业务需求。

如果你对 MCP 协议本身感兴趣，或者想构建类似的社交媒体自动化工具，这是一个值得研究的参考实现：代码体量适中（约 400 行核心逻辑），架构清晰，且文档完整。