脑袋被门夹得好痛上周有个做小红书账号的朋友在群里发了一段录屏：他的 AI 助手正一边打开某篇爆款笔记的评论区，一边逐条分析用户在抱怨什么，最后直接生成了一份选题建议。他用的不是手工复制粘贴，而是让 Claude 通过 MCP 协议直接连上了小红书数据服务。这个场景我看了挺有感触，一年前我还在写爬虫脚本手动拉数据，现在只需要把一个叫 MCP Server 的东西在本地跑起来就行。
但在 Windows 上把它跑起来这件事，远没有想象中顺利。我花了整整一个周末，前半天在装环境、配依赖，后半天全耗在 Windows Defender 的拦截问题上——不是防病毒把脚本文件删了，就是防火墙把一个看起来完全正常的端口规则藏起来，甚至 mpssvc 服务状态都出现异常。这篇文章就是把这次从零部署小红书 MCP 服务的完整过程复盘一遍，重点讲清楚 Windows Defender 的拦截逻辑到底是怎么回事、怎么排查、怎么在保持系统安全的前提下把服务跑通。无论你是内容创作者、运营，还是想研究 MCP 协议的开发者，这篇应该都有参考价值。
1. 为什么非要在 Windows 上搞小红书 MCP
1.1 一个真实的创作痛点
做小红书内容的人应该都有这种体验：找选题、分析竞品、看评论区反馈，这些操作极度依赖平台数据。常规做法是打开网页版小红书，一篇一篇翻，然后手工整理到表格里。效率低不说，信息还容易遗漏。我认识一个做美妆账号的博主，每周光做竞品分析就要花大概三个小时。
MCP 能改变的是这个瓶颈。它让 AI 助手可以直接"拿到"数据流，而不是靠你复制粘贴喂给它。比如让 AI 梳理某篇爆款笔记的热评观点、统计一个话题下高频出现的需求词、对比不同笔记的标题风格，这些以前需要手工采集的活，现在可以用自然语言直接吩咐 AI 完成。
我这次选定的目标就是在 Windows 11 上跑通小红书 MCP 服务，然后接到 Claude Desktop 和 Codex 里。之所以不用 Mac，是因为我主力机就是 Windows，而且据我所知很多内容创作者也是 Windows 用户，但网上能找到的部署教程几乎全是基于 macOS 和 Linux 的，Windows 的坑只能自己踩，所以我决定把整个流程记录下来。
1.2 MCP 到底是个什么东西
MCP 的全称是 Model Context Protocol，中文一般译作模型上下文协议。它解决的问题非常具体：AI 模型（比如 Claude、GPT）和外部工具、数据源之间怎么建立标准化连接。用大白话说，MCP 规定了"工具应该如何暴露给 AI 模型使用"，你可以把它理解成一个万能 USB-C 接口——不同的设备只要遵循同一个接口标准，插上就能通信。
具体到小红书场景，MCP Server 就是一个在本地运行的进程，它负责对接小红书平台的公开数据，然后把数据以标准化的 Tool（工具）形式暴露出来。AI 客户端（比如 Claude Desktop）启动时读取配置，发现本地有一个小红书 MCP Server，就会自动把这些工具注册到对话上下文中。之后你说"帮我看看这篇笔记的评论区",AI 就会调用这个工具去拉数据，然后基于返回结果继续和你对话。
这个链路里最关键的是"标准化"三个字。以前各家 AI 工具接入外部服务都是各搞各的，相当于每个设备都要专用的充电线。MCP 出现之后，模型侧和工具侧都按同一个协议对接，理论上一次接入，处处可用。
1.3 为什么不用 Skill / 传统脚本
最近社区里很多人讨论 agent skill 和 MCP 有什么区别，确实容易混淆。我自己这样理解：Skill 更像是一个"针对特定 Agent 定制的技能包"，它定义的是"怎么完成一个任务"，里面的内容可能包含提示词、工作流、代码片段，它和具体的 Agent 框架是绑定的。而 MCP 定义的是"工具怎么被模型发现和调用"，它是协议层面的事情，和具体的模型、客户端解耦。
打个比方：Skill 是给某个员工（某一个 Agent）专门写的岗位手册，MCP 是公司内部统一的项目协作接口标准。岗位手册换个人可能就没用了，但接口标准谁都能对接。
那为什么不直接写脚本？脚本当然能做数据采集，但问题是脚本和 AI 对话是割裂的。我写一个 Python 脚本拿到数据，还得把数据整理成文本再粘贴给 AI。MCP 的好处是 AI 自己就能发起调用、接收结果、继续推理，整个交互闭环是自动的。这也是我决定部署 MCP Server 而不是继续用脚本的核心原因。
这个章节的最后交代一下方案选型：我采用了 Python 技术栈，因为小红书 MCP 服务社区实现大多基于 Python，对 Windows 的兼容性相对成熟；虽然在 Windows 上部署 Python 项目遇到过各种环境变量问题，但比在 Windows 上强行跑 Docker 容器要省心得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从零部署：环境、依赖、启动一条龙
2.1 Python 环境准备和 PATH 那些坑
部署 MCP Server 前首先要装好 Python。Windows 上装 Python 有两个主流方式：一个是去 python.org 下载安装包，一个是直接用 winget 命令。我个人的建议是直接去官网下载，因为可以手动勾选“Add Python to PATH”，这一步非常关键。
我在第一次部署时就是踩了 PATH 的坑：Python 装完，打开终端敲 python 却提示不是内部或外部命令。原因很简单，安装时没勾选 Add to PATH，导致系统找不到可执行文件。解决办法是去系统设置里手动把 Python 的安装目录加入环境变量，或者重新运行安装包并勾选那个选项。
建议直接安装 Python 3.11 或 3.12 版本，不要太老也不要太新。MCP 社区的大部分依赖对 Python 3.11 的支持最稳定，3.13 刚发布时有些包还没适配好，容易遇到编译报错。装完之后在终端验证一下：
bash复制python --version
pip --version
如果能正确输出版本号，说明 Python 环境基本就位。
2.2 用 uv 管理依赖，替代 pip 的老旧体验
很多教程会直接让你用 pip 安装依赖，但用过一次你就会发现，pip 在 Windows 上有一个很烦人的特性：全局安装会让不同项目的依赖互相污染。比如项目 A 需要 requests 2.x，项目 B 需要 requests 3.x，如果都全局安装，版本冲突会让人抓狂。
所以我这次选择了 uv 来管理依赖。uv 是 Astral 团队出的现代 Python 包管理器，它比 pip 快非常多，而且内置了虚拟环境管理功能，一条命令就能创建虚拟环境、安装依赖。它的用法和 pip 有几分相似，但体验确实好上一个量级。
安装 uv 的方式有两种，一种是通过 pip：
bash复制pip install uv
另一种是直接用 PowerShell 执行官方脚本：
powershell复制powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
安装完成后，在当前目录创建项目并初始化虚拟环境：
bash复制mkdir xiaohongshu-mcp
cd xiaohongshu-mcp
uv init
uv venv
2.3 安装小红书 MCP Server 并完成初始配置
接下来是核心步骤：安装小红书 MCP Server 本体。因为我部署的是社区里的第三方实现，在不同仓库中包名可能不同，我用的这个是基于 Python 的实现，可以通过 uv 直接安装：
bash复制uv pip install xiaohongshu-mcp-server
当然，如果你使用的仓库提供的是 Node.js 实现，命令会变成 npm 相关，这里给的是我在实践中实际使用的方案。安装完成后，需要创建一个配置文件，用来告诉 MCP Server 你要访问哪些数据、运行在哪个端口。
我用的是 SSE（Server-Sent Events）传输模式，配置是 JSON 格式的：
json复制{
"server": {
"host": "127.0.0.1",
"port": 8000,
"transport": "sse"
},
"platform": {
"cookie": "你的小红书登录Cookie",
"ua": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
}
}
这个小节的补充说明：因为 MCP 服务需要以你的身份读取小红书内容，所以必须在配置中传入登录后的 Cookie，这样才能获取到公开笔记、评论等数据。Cookie 的获取方式是用 Chrome 或 Edge 打开小红书网页版，登录成功后按 F12 打开开发者工具，在 Network 面板里找到任意请求，在请求头里复制 Cookie 字段。注意 Cookie 是敏感凭证，配置好后不要把配置文件随便分享出去。
2.4 配置 Cookie 并首次启动
拿到 Cookie 后填入配置文件，然后启动服务：
bash复制uv run xiaohongshu-mcp-server --config config.json
启动成功后终端会显示一个类似这样信息：
text复制INFO: Started server process [12345]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://127.0.0.1:8000
看到 Uvicorn running 说明你的本地 MCP 服务已经成功监听在 8000 端口了。为了验证服务真的能用，可以试试访问健康检查接口：
bash复制curl http://127.0.0.1:8000/health
正常情况下会返回一段 JSON，里面有服务状态、版本号等信息。
就在我准备松一口气去配置客户端的时候，问题出现了。先是启动目录下多了一些奇怪的临时文件，再是重新执行同样的启动命令却提示"文件不存在"，我意识到事情没那么简单。
3. Defender 拦截全链路排查：从资源管理器到防火墙
3.1 第一波：文件被实时保护扫走了
第一次碰到 Defender 拦截，是在杀掉服务进程后准备重新启动时。我重新执行 startup 命令，终端直接报错找不到某个 Python 包的入口文件。我打开项目目录一看，uv 创建的虚拟环境里，几个可执行文件不见了，连带着一些 .pyd 动态库也没了踪影。
这是因为 Windows Defender 的实时保护功能在后台自动扫描文件，它把虚拟环境里的几个文件判定为可疑样本，直接隔离了。这其实是个很典型的误报场景：uv 包管理器创建虚拟环境时会生成隔离的可执行文件，这些文件没有数字签名，加上行为特征和某些脚本型木马相似，极易触发 Defender 的启发式检测。
在“Windows 安全中心”里可以看到隔离记录，如果确认是误报，可以手工“还原”文件。但更省事的方法是直接把项目目录加入 Defender 的排除列表。操作路径是：Windows 安全中心 -> 病毒和威胁防护 -> 管理设置 -> 排除项 -> 添加排除项，然后选择你的项目源码目录。排除之后，Defender 就再也不会扫描这个目录，虚拟环境里的文件也就不会被误删了。
这里有件事必须说清楚：排除目录等于信任该目录内所有文件的执行行为，所以尽量不要把随手下到临时目录的东西丢进项目目录里，更不要为了省事把整个 C 盘都排除掉。
3.2 第二波：防火墙规则为什么拦住了服务
文件问题解决后，我把 MCP Server 重新启动，结果在客户端配置时发现另一个诡异的现象：Claude Desktop 能连上服务器，但每次调用工具都超时，没有任何数据返回。
我第一反应是代码的传输层有问题，排查半天没找到头绪。后来用 PowerShell 查了一下监听端口：
powershell复制netstat -ano | findstr 8000
发现 8000 端口确实在监听，状态是 LISTENING，我以为服务没问题。但后来换了台局域网设备测试，请求完全被卡住，这才怀疑到了防火墙。
Windows Defender 防火墙的默认策略是：本机回环地址（127.0.0.1）的流量默认放行，但一旦服务监听在 0.0.0.0 或局域网地址上，入站连接就需要匹配防火墙规则。MCP Server 如果为了容器或其他设备访问，把 host 配成 0.0.0.0，那么防火墙就会拦截来自其他设备的连接，有时甚至会创建一条"已阻止"状态的事件记录。
解决方式有两种。如果你只用本机客户端，那么服务端配置里的 host 保持 127.0.0.1 就好，不用动防火墙。如果你需要局域网内其他设备访问这个 MCP 服务，或者你想从 WSL/容器中访问，那就得手动添加一条入站允许规则：
powershell复制New-NetFirewallRule -DisplayName "MCP Server 8000" -Direction Inbound -Protocol TCP -LocalPort 8000 -Action Allow
添加成功后，再用 Get-NetFirewallRule -DisplayName "MCP Server 8000" 验证规则状态。这一步做完，服务就能被外部设备访问了。
3.3 第三波：mpssvc 与 Microsoft Defender Firewall 服务状态异常
你以为这就完了？没有。后来我为了调试问题，打开“服务”管理窗口，准备手动查看 Firewall 相关服务的状态，结果发现 Windows Defender Firewall 服务（服务名 mpssvc）的状态是停止，启动类型显示“自动”，但点击启动按钮是灰色的，没法操作。
这就是很多 Windows 用户都遇到过的经典问题：mpssvc 服务的启动权限被安全策略锁住。具体表现是：服务状态为停止，但启动按钮不可用；用命令 net start mpssvc 会提示拒绝访问；去服务属性里改启动类型，下拉框也是灰色。如果我的防火墙服务一直起不来，那前面配置的防火墙规则其实根本没生效，防御完全处于真空状态，这样继续折腾下去等于在裸奔，隐患很大。
网上一搜，能找到不少用 Defender Control 之类的第三方小工具强制开启服务的方法，但我不建议你在没搞懂原理之前直接用这类工具。我的处理思路是先确认这个服务是不是真的被组策略锁定，再决定需要恢复到什么状态。先看注册表：
reg复制HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mpssvc
检查里面的 Start 值：0 表示启动，1 表示系统启动时加载，2 表示自动启动。正常情况应该是 2。如果你发现被改成了 4（禁用），那确实是被某些工具或优化软件关了。这里需要说明的是，通过注册表强行改回 2 之后，最好执行一次：
powershell复制sc config mpssvc start= auto
sc start mpssvc
如果 sc start 提示“服务无法启动”或“拒绝访问”，还有一种可能是第三方安全软件接管了系统防火墙，此时要先把相关管理工具卸载或暂停，再恢复 Windows 内置防火墙服务。
处理完 mpssvc 之后，我用 Get-Service mpssvc 确认服务状态变为 Running，再用 Get-NetFirewallProfile 确认三个配置文件（域、专用、公用）都处于开启状态。这样一来，防火墙服务才算真正恢复正常。
3.4 到底该不该彻底关闭 Defender
很多教程在遇到 Defender 拦截时，第一步就是教你彻底关闭 Windows Defender，包括实时保护、防火墙、安全中心，甚至有人推荐用 Defender Remover 直接把整个组件卸载掉。我的态度是不建议这样做，尤其是对一台还要日常使用的主机。
原因很简单：Defender 是 Windows 系统安全的最后一层兜底。你把它关了，短期内 MCP 服务确实跑得很顺，但后续如果下载或运行了恶意文件，系统基本没有任何防护。尤其在小红书 MCP 这个场景里，又要传 Cookie 又要连外部服务，安全边界本来就比普通浏览复杂得多，把系统防御彻底关掉是很得不偿失的。
正确的思路是“最小化干预”：能加排除项就不关实时保护，能配允许规则就不关防火墙，能临时暂停就用组策略做永久限制。我这次最终保留的状态是：Defender 实时保护保持开启，但把项目目录加入排除列表；防火墙保持启用，额外添加 8000 端口和 Python 解释器的放行规则。
如果你确实需要长期关闭 Defender，官方支持的方式是通过组策略配置，而不是用第三方工具强杀进程：
text复制计算机配置 -> 管理模板 -> Windows 组件 -> Microsoft Defender 防病毒 -> 关闭 Microsoft Defender 防病毒
将状态设置为“已启用”后，Defender 会进入受限模式。但注意，这仍然不是彻底卸载，而且组策略只对专业版、企业版 Windows 生效，家庭版默认没有这个入口。
3.5 一套相对稳妥的配置方案
经过三轮拦截和排查，我最终这套方案可以让 MCP Server 在 Windows 上稳定运行，同时不破坏系统安全体系：
| 拦截模块 | 问题现象 | 处理方式 |
|---|---|---|
| Defender 实时保护 | 虚拟环境内文件被隔离 | 项目源码目录加入排除列表 |
| 防火墙入站规则 | 外网/局域网无法访问 8000 端口 | New-NetFirewallRule 添加 TCP 8000 允许规则 |
| mpssvc 服务异常 | 服务停止、启动按钮灰色 | 检查注册表 Start 值，sc config 恢复 auto，sc start 启动 |
| Python 解释器执行 | 首次运行会触发 SmartScreen 提示 | 在“应用和浏览器控制”中选择“仍要运行”，或给解释器文件加签名 |
这份表也是我这次踩坑时间线里每一步的浓缩版。如果你也遇到 Defender 拦截，建议按这个顺序去排查：先看病毒隔离记录，再看防火墙事件，最后查服务状态，不要一上来就卸载安全组件。
4. 把服务接进 Claude Desktop 和 Codex，以及工具注册不上的问题
4.1 Claude Desktop 接入
MCP Server 跑起来之后，下一步就是接客户端。我用的是 Claude Desktop，配置很简单：在 Claude 的配置目录里有一个 claude_desktop_config.json 文件，Windows 上路径通常在这里：
text复制C:\Users\你的用户名\AppData\Roaming\Claude\claude_desktop_config.json
修改这个文件，添加 mcpServers 字段：
json复制{
"mcpServers": {
"xiaohongshu": {
"command": "uv",
"args": [
"run",
"xiaohongshu-mcp-server",
"--config",
"C:/path/to/config.json"
],
"env": {
"PATH": "C:/path/to/python/Scripts;C:/path/to/python;%PATH%"
}
}
}
}
这里有一个 Windows 特有的大坑：Claude Desktop 不会自动继承终端里的 PATH 环境变量。如果你用的是 uv 和 Python 虚拟环境，必须把 uv 所在目录显式写进 env 的 PATH 里，否则 Claude Desktop 启动 MCP 服务时会报“command not found”或直接黑屏退出。
保存配置后重启 Claude Desktop，然后在对话界面输入“你有哪些工具”，如果能列出小红书的笔记搜索、评论获取、话题分析等工具，就说明接入成功。
4.2 Codex 接入
配置 OpenAI Codex 桌面版也是一样的思路，无非是配置文件路径不一样。Codex 的配置文件在用户主目录下：
text复制C:\Users\你的用户名\.codex\config.toml
在 TOML 格式里添加 MCP 服务：
toml复制[mcp_servers.xiaohongshu]
command = "uv"
args = ["run", "xiaohongshu-mcp-server", "--config", "C:/path/to/config.json"]
启动 Codex 后，通过对话或开发者工具查看 tools 注册情况。如果出现工具列表，说明接入成功。
不过这里我要提一个搜索热词里的常见问题：figma mcp 在 codex 中总是工具注册不上。这个问题我在调试小红书 MCP 时也遇到过一模一样的表现，现象是 Codex 能看到服务进程在跑，但工具列表始终为空。原因大概率是 Codex 的 mcp_servers 配置中，command 指向了不存在的可执行文件，或者 args 里的路径带空格没有转义。TOML 配置里路径带空格时，直接用引号包住即可。
4.3 工具注册不上：排查链路
如果你配置完发现工具还是注册不上，不要急着怀疑 MCP 服务端。按我实际调试的经验，80% 的问题出在客户端侧，排查链路应该是这样的：
第一步，确认 MCP Server 进程确实存活。用任务管理器或 tasklist | findstr python 检查进程是否存在，如果进程没有启动，说明是客户端启动命令的问题。
第二步，确认服务健康检查能通过。用浏览器或 curl 访问 http://127.0.0.1:8000/health，如果连这个都超时，说明服务没起来或端口被占用。
第三步，看客户端日志。Claude Desktop 和 Codex 都有详细日志输出，Claude Desktop 的日志在 %APPDATA%\Claude\logs 目录，Codex 的日志在 %USERPROFILE%\.codex\logs。打开日志看到 MCP server connection failed 之类的信息就比较好定位了。我遇到最多的是因为 PATH 环境变量没传对，导致客户端启动 MCP Server 时找不到命令。
第四步，用 MCP Inspector 直接调试。MCP Inspector 是官方提供的调试工具，以独立网页形式运行，可以填 Server 的 URL 和端口，直接查看工具注册情况。用它可以快速区分问题出在服务端还是客户端。
4.4 其他 MCP server 的扩展思路
这个部署思路其实适用于所有 MCP Server，不只是小红书。搜索热词里提到的蓝湖 MCP、Figma MCP、Playwright MCP、Unity MCP 等，本质都是同一套东西：一个本地或远程的服务进程，通过 MCP 协议暴露工具给 AI 客户端。
所以在 Windows 上踩过的这些坑，换一个 MCP Server 大概率还会遇到，因为问题不在小红书，而在 Windows 的进程管理和安全机制。你如果之后部署别的 MCP，完全可以复用这套排查方法，这是这次部署最有价值的收获之一。
5. 复盘：踩坑时间线、习惯和边界
5.1 一整天踩坑的时间线
按照时间线复盘，我这次的部署过程大概是这样的：
上午十点开始，装 Python、配 uv、创建项目、安装依赖、配置 Cookie，整个过程大概花了四十分钟，还算顺利。
上午十一点，第一次启动服务成功，但发现虚拟环境里的可执行文件被 Defender 删掉了。排查隔离记录、添加排除项、恢复文件，这里花了大半个小时。
下午一点，配置完 Claude Desktop 后调用工具超时，开始怀疑网络层问题，最终定位到防火墙。添加端口规则后问题略有缓解，但没有完全解决，因为我又去翻服务状态，发现 mpsscv 异常，于是又花了一个多小时恢复防火墙服务。
下午四点，重启电脑后再次测试，发现启动项目时 SmartScreen 又来提示，应用程序被阻止。这是第四轮拦截，我用“应用和浏览器控制”里的“仍要运行”按钮放行后，才最终让整个流程稳定下来。
这四轮拦截有一个共性：每一轮都不报明显的错误信息，都是服务看起来正常，但行为不对。这种“隐性拦截”最消耗时间，这也是我写这篇文章最想强调的一点——遇到 Windows 上的服务异常，第一反应应该是查安全中心，而不是改代码。
5.2 我的几条反常识经验
经过这次实操，有几条经验可能和直觉不同，但对 Windows 用户特别有参考价值：
第一，排除目录比关闭实时保护安全得多，也有用得多。很多教程动不动就让你关实时保护，其实排除目录只需要加一条规则，效果相同，但风险完全可控。
第二，Windows 防火墙对 127.0.0.1 的流量是放行的，所以如果你的 MCP Server 只供本机客户端使用，完全不用配防火墙规则。一旦你为了容器或远程访问把监听地址改成 0.0.0.0，防火墙才会介入，而且默认只拦入站，出站不管。这个问题容易和“服务没起来”混淆。
第三，Defender 的几个模块是互相独立的。实时保护、防火墙、SmartScreen 各自独立运行，你解决了一个问题不代表其他问题不会出现。我这次就是实时保护、防火墙、SmartScreen 三个模块轮番上场，所以排查时不能只用一种方法就收工。
5.3 安全与合规提示
最后说一点关于使用边界的建议。小红书 MCP 服务本质上是在读取小红书平台的数据，虽然我部署时使用的是自己账号的公开数据访问权限，但在使用时仍然要注意：不要高频访问接口，不要批量采集用户隐私数据，不要用于任何商业灰产场景。MCP 作为 AI 时代的基础设施，本身没有任何问题，但工具的合理使用始终取决于使用者的自律。
关于 Cookie 的保管也一样，配置文件里包含你的登录凭证，不要提交到公开仓库，不要发给陌生人，也不要在博客截图里露出。建议在 GitHub 上新建一个私有仓库专门存储这类配置，公开仓库里只放不含敏感信息的默认配置模板。
我在实际部署中还有一个心得：如果你只想在本地试一下 MCP 生态，先用小红书这种轻量级服务练手非常合适。它能让你快速理解 MCP 工具的注册、调用、返回全流程，又不需要复杂的后端基础设施。我通过这次部署，成功的把 Claude、Codex 和本机数据源打通了，而这一切的起点只是周末一时兴起想看看 AI 能不能帮我做选题分析。把这些经验写出来，也是希望后来者不用再被 Defender 的隐性拦截磨掉耐心。