1. 为什么我盯上了 xhs-toolkit 这条自动化链路
做小红书运营的朋友大概率都经历过这种循环：白天写脚本、拍素材，晚上蹲在电脑前一条条手动发笔记，标题、正文、话题、图片位置来回切窗口，发完还要切到创作者中心看数据。单账号还能忍，一旦手上同时跑三五个账号，纯手工发布基本等于把自己焊在椅子上。
xhs-toolkit 这个项目解决的就是这段重复劳动。它是一个基于 MCP 协议的小红书自动化工具包，把「获取 Cookie、发布图文/视频笔记、采集创作者数据」这些动作封装成 MCP 工具，AI 客户端（Claude Desktop、Cherry Studio 等）通过对话就能调用。你只需要用自然语言说清楚标题、正文、图片地址和话题，剩下的浏览器操作、页面跳转、发布确认全部由工具链完成。
它适合谁？我梳理了三类：一是需要批量发布笔记和视频的运营同学；二是想把内容发布接进自己 Agent 工作流的开发者；三是想用 AI 对话方式管理多个小红书账号的团队。不适合纯小白拿来当「一键涨粉神器」，因为它本质是自动化执行层，内容质量还得你自己把控。
真正让我决定写这篇实战的，是另一个坑：MCP 客户端调用模型时需要 API Key，而不同客户端、不同模型的 Key 管理很碎。我这次用 TaoToken 的统一 Key 来收口，配合 xhs-toolkit 的 config.toml 和 settings.json，把「模型调用」和「发布执行」两条链路串成一条可复现的流程。下面按我实际跑通的顺序拆开讲。
2. TaoToken 前置准备：统一 Key 怎么拿、放哪
在动手配 xhs-toolkit 之前，先把模型侧的 Key 准备好。TaoToken 的定位是统一接入层，一个 Key 可以对接多个模型，省得你在 Cherry Studio、Claude Desktop、Coding Plan 之间来回换配置。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api （这个地址不加 UTM，配置里直接写）。
拿 Key 的路径很直接：进控制台，创建 API Key，复制出来。控制台地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，Key 管理页在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。如果你后面要跑长期编码或 Agent 任务，可以看下 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
这里有个容易踩的点：MCP 客户端里填的 Key 和 xhs-toolkit 本身没关系。xhs-toolkit 负责的是小红书侧的浏览器自动化，它不调用大模型；调用大模型的是 Cherry Studio 这类客户端。所以你的 Key 是填在客户端的模型配置里，不是填在 xhs-toolkit 的 .env 里。我第一次配的时候就把两者搞混了，在 .env 里找模型配置找了半天，其实那边只有 Cookie 和浏览器相关参数。
注意：Key 属于敏感凭证，不要写进会提交到 Git 的配置文件。建议放在客户端本地配置或环境变量里，仓库里的示例文件只做占位。
模型侧确认能通之后，再进入 xhs-toolkit 的安装和配置。顺序反了的话，你会在「工具装好了但 AI 调不动」的状态里卡很久。
3. xhs-toolkit 安装与 config.toml 骨架
3.1 环境先决条件
xhs-toolkit 依赖 Chrome 和匹配版本的 ChromeDriver。这里有个版本对齐的坑：ChromeDriver 的发布经常滞后于 Chrome 正式版，所以不要盲目装最新 Chrome，而是先去 Chrome for Testing 的可用性页面查当前能拿到的 driver 版本号，再装同版本 Chrome。
Windows 下可以用 winget 装 Chrome：
winget install --id Google.Chrome --source winget装完在浏览器地址栏输入chrome://version/查版本号。假设查到是 138.0.7204.94，那 ChromeDriver 也要装这个版本：
winget install --id Chromium.ChromeDriver --source winget --version 138.0.7204.94验证一下：
chromedriver --versionLinux 下更推荐用 webdriver-manager 自动匹配，省去手动对版本的麻烦：
uv venv .chrome_webdriver source .chrome_webdriver/bin/activate uv pip install webdriver-manager deactivate3.2 克隆与依赖安装
git clone https://github.com/aki66938/xhs-toolkit.git cd xhs-toolkit uv syncuv sync会自动创建虚拟环境并装依赖。装完先跑一次状态检查，确认工具本身可用：
uv run python xhs_toolkit.py status3.3 config.toml 骨架
xhs-toolkit 的配置分两块：一块是项目根目录的.env（Cookie、浏览器路径等运行时参数），一块是 MCP 客户端侧的settings.json（模型和 MCP server 注册）。先看.env的骨架，从示例文件复制：
cp env_example .env.env里我实际会关注这几项：
# 浏览器可执行文件路径，指向你装好的 Chrome CHROME_PATH=C:\Program Files\Google\Chrome\Application\chrome.exe # ChromeDriver 路径，版本必须和 Chrome 匹配 CHROMEDRIVER_PATH=C:\Program Files\Chromium\ChromeDriver\chromedriver.exe # Cookie 存储位置，登录后自动写入 COOKIE_FILE=./cookies/xhs_cookies.json # 无头模式，调试阶段建议 false，能看到浏览器操作过程 HEADLESS=false # 发布超时，网络慢可以调大 PUBLISH_TIMEOUT=120如果你更习惯用 TOML 组织，可以把上面这些整理成config.toml，字段名和.env保持一致，工具读取时会做映射。我实测下来，调试阶段把HEADLESS设成false非常关键——你能亲眼看到浏览器打开、跳转、填表、点发布，出问题时一眼就知道卡在哪一步。
3.4 登录获取 Cookie
配置好之后先登录，把 Cookie 拿到手：
./xhs cookie save或者走交互式菜单：
./xhs # 选择 4 -> Cookie管理 -> 1 -> 获取新的Cookies浏览器会弹出来，你手动登录小红书创作者中心，确认能正常访问后台功能后，回到终端按回车保存。Cookie 会写进COOKIE_FILE指定的路径。这一步只做一次，后续发布复用这份凭证。
4. settings.json 配置片段与 MCP server 启动
4.1 启动 MCP server
Cookie 就绪后启动 MCP server：
./xhs server start或者走菜单5 -> MCP服务器 -> 1 -> 启动服务器。启动后它会监听本地端口，等待客户端连接。
4.2 Cherry Studio 的 settings.json 片段
在 Cherry Studio 里注册这个 MCP server，配置片段大致长这样：
{ "mcpServers": { "xhs-toolkit": { "command": "uv", "args": [ "--directory", "D:/workspace/xhs-toolkit", "run", "python", "xhs_toolkit.py", "mcp" ], "env": { "CHROME_PATH": "C:/Program Files/Google/Chrome/Application/chrome.exe", "CHROMEDRIVER_PATH": "C:/Program Files/Chromium/ChromeDriver/chromedriver.exe", "HEADLESS": "false" } } } }同时，模型侧的 Key 配置在 Cherry Studio 的模型服务里，填 TaoToken 的 API 基址和你的 Key：
{ "provider": "taotoken", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的TaoToken密钥", "model": "claude-sonnet-4-5" }这里baseUrl就是前面说的 API 地址，不带 UTM 参数。模型名按你实际开通的填，模型对话入口在 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
4.3 勾选 MCP server
配置保存后，在 Cherry Studio 的对话界面里要确保勾选了xhs-toolkit这个 MCP server。没勾的话，AI 根本看不到这些工具，你发再多指令它也只能干聊。
注意：Cherry Studio 调用 MCP tool 时需要用户确认，右侧会出现一个勾选按钮，点一下才会真正执行。这是安全机制，不是 bug。
5. 一次发布任务的验证动作与成功结果
5.1 图文笔记发布
准备一张本地图片，然后在对话里用自然语言请求：
请发布一篇小红书笔记，标题："电梯中看到领养猫咪启示，莫名好笑哈哈"， 内容："今天在坐电梯时，看到了一张领养猫咪的启示，广东中山的朋友们， 如果想领养猫咪，可以联系猫主人哈"， 使用本地图片："D:/images/cat.jpg"， 话题：#分享、#铲屎官、#猫咪、#记录日常、#领养调用 MCP 时，Chrome 会自动打开，跳转创作者中心，填标题、正文、上传图片、设置话题，最后点发布，完成后自动关闭浏览器。如果之前登录过，Cookie 有效，全程无需人工干预。
话题格式是成功率的关键。我试过不加#号、用逗号分隔，结果话题没设置成功，AI 反复重试。正确写法是每个话题带#，话题之间用顿号「、」分隔，这样一次过的概率高很多。
5.2 网络图片发布
图片也可以走 URL。把图片放到可公开访问的地址，先验证 URL 在浏览器里能打开，再请求：
请发布一篇小红书笔记，标题："测试网络图片发布"， 内容："这是一条用网络图片发布的测试笔记"， 使用这个网络图片："https://example.com/test.jpg"， 话题：#测试、#自动化实测中会遇到 tool 调用提示失败，但 MCP server 内部会自动重试，最终往往发布成功。所以看到第一次失败提示时，先别急着取消，等它重试完再看结果。
5.3 视频笔记发布
视频发布流程和图文类似，把图片参数换成视频路径或 URL 即可。视频文件体积大，上传耗时长，建议把PUBLISH_TIMEOUT调大，比如 300 秒。发布完成后同样去创作者中心确认。
5.4 成功结果确认
发布成功后，登录小红书创作者中心，在「笔记管理」里能看到刚发的笔记，状态是已发布。我实测那次图文笔记发出去后还收到了两个赞，说明链路是通的。数据采集功能也能用，创作者中心的仪表板、内容分析、粉丝数据会被抓成中文表头的 CSV，AI 可以直接读。
6. 本篇常见错排查清单
6.1 ChromeDriver 版本不匹配
报错通常是session not created: This version of ChromeDriver only supports Chrome version XX。解决方法是查chrome://version/拿到 Chrome 版本，去 Chrome for Testing 页面找同版本 driver，重新安装。Linux 下用 webdriver-manager 可以自动对齐。
6.2 Cookie 失效
表现是浏览器打开后停在登录页，或者发布时提示未登录。重新跑./xhs cookie save登录一次即可。Cookie 有有效期，长期不用会过期。
6.3 MCP server 连不上
先确认./xhs server start在跑，再看 settings.json 里的--directory路径是不是指向你实际的仓库目录。路径写错是最常见的原因，Windows 下注意用正斜杠或双反斜杠。
6.4 话题设置失败
前面提过，话题必须带#，多个话题用「、」分隔。写成分享,铲屎官这种，工具解析不出来，会反复重试。
6.5 首次登录不成功、刷新后才进
我遇到过每次调用smart_publish_note时第一次登录不成功，自动刷新后才进创作者中心。可能和机器性能有关，也可能和用的是自动化测试专用 Chrome 有关。换成标准版 Chrome 试试，或者把HEADLESS设成false观察具体卡在哪。
6.6 图片 URL 不可访问
网络图片发布前，先在浏览器里直接访问那个 URL，能看到图才说明地址有效。钉钉文档这类需要权限的地址，要先设为公开。
6.7 发布超时
视频或大图上传慢，把PUBLISH_TIMEOUT调大。网络环境差的时候，无头模式反而容易超时，建议调试阶段保持有头模式。
排障时如果怀疑是模型侧的问题，可以去模型对话页单独测一下模型是否正常响应：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。接入相关的配置问题，文档里有更细的字段说明：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。Key 的管理和轮换在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
7. 把这条链路用顺的几个实操建议
跑通一次发布之后，我做了几件事让它更稳。第一，把常用的话题组合固化成提示词模板，每次只改标题和正文，减少格式错误。第二，Cookie 单独备份一份，换机器或重装时直接恢复，省去重新登录。第三，视频发布和图文发布分开跑，不要混在一个对话里，避免上下文干扰。第四，定期去创作者中心核对发布结果，自动化不等于免检，尤其是批量场景。
如果你要跑长期的内容发布 Agent，Coding Plan 那边有更完整的额度方案：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。控制台里可以看调用量和 Key 状态：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
最后说个我踩过的坑：不要一上来就批量发。先用一个测试账号、一条测试笔记把全链路走通，确认 Cookie、ChromeDriver、MCP server、模型 Key 四个环节都没问题，再逐步放量。自动化发布的价值在于省时间，但前提是链路稳定，否则排查问题花的时间比手动发还多。
