简介面向 OpenClaw、Codex、CC 等智能体生态的小红书自动化 Skill 资源包专为需要在小红书平台批量发布、自动评论、关键词检索与数据采集的开发者设计。整套工具基于 Chrome 远程调试协议实现浏览器自动化支持无头模式运行、多账号 Cookie 隔离、远程调试端口连接也支持仅启动测试浏览器而不发布方便在正式操作前安全验证。压缩包共 20 个文件以 7 个 Python 脚本和 6 个 Markdown 文档为核心脚本覆盖发布管道、账号管理、图片下载、内容抓取等模块文档包含使用说明与集成指引另附示例配置、依赖清单和许可证整体仅 181KB结构轻量、易于改造。功能上除了自动填写标题正文、上传图片、话题标签逐步写入还包括登录二维码导出、登录状态本地缓存、首页推荐流抓取、笔记详情与评论数据读取、一级评论与回复、点赞收藏、用户主页快照、数据看板导出 CSV 等同时适配了 2026 年 2-3 月小红书创作者中心发布页的结构变动降低后续维护成本。docs 与 scripts 目录划分清晰既有 claude-code-integration 等集成说明也有运行锁、发布管道等工程脚本便于二次开发部署。目前已有 144 人学习下载适合具备脚本基础、希望在小红书自动化和智能体工具链联调中快速落地的中高级开发者。1. 小红书自动发布、评论、检索一个 Skill 全包的时候到了做小红书运营的人每天至少有三分之一的时间耗在重复操作上发笔记、回评论、搜竞品、扒链接、存图片。我见过太多人把这套流程拆成四五个工具来回切最后数据没涨多少人先累垮了。这个标题给出的东西就是把这些动作收敛成一个Skill——一段带描述、带脚本、能被 Agent 按需调用的能力包压缩成 .zip 分发装进 OpenClaw、Codex、CC 这类 Agent 环境里就能用。它解决的不是「多一个爬虫脚本」的问题而是让 Agent 在对话里就能完成「帮我把这篇笔记发出去」「盯一下这篇笔记的评论区」「搜一下某个关键词的最新笔记」这类指令。适合谁做内容矩阵、管多个账号、需要定期做竞品监控的运营和独立开发者。不适合谁只想拿现成 GUI 点点鼠标的人——这玩意天生是给命令行和 Agent 用的。2. Skill 的构成一个 zip 里到底装了什么2.1 先搞懂 Skill 和普通脚本的区别很多人第一次接触「Skill」这个词是从 OpenClaw 的文档里看到。它和普通脚本最大的区别在于脚本是你主动调用的Skill 是 Agent 根据你的描述自主决定调用的。这就需要一个机器可读的说明文件OpenClaw 里叫SKILL.mdCodex 的 Skill 机制也沿用了类似结构。这个文件的开头是一段 YAML frontmatter里面写清楚这个 Skill 叫什么、能干什么、在什么场景下触发。Agent 读到了描述再对照用户当前的需求决定要不要把这个 Skill 加载进来执行。一个典型的 Skill zip 解压后大致长这样xiaohongshu-skill/ ├── SKILL.md # 技能描述Agent 的“使用说明书” ├── scripts/ │ ├── publish.py # 自动发布 │ ├── comment.py # 自动评论 │ ├── search.py # 关键词检索 │ └── utils/ │ ├── auth.py # 登录态管理 │ └── parser.py # 笔记解析、图片提取 ├── config/ │ ├── accounts.json # 多账号配置按需 │ └── prompts.yaml # 评论话术模板 └── requirements.txt # Python 依赖这里要注意SKILL.md 是灵魂脚本只是手脚。如果你的 zip 里只有脚本没有 SKILL.mdOpenClaw 和 Codex 会把它当成一个普通目录Agent 不会主动去碰它。2.2 一份能跑的 SKILL.md 长什么样以 OpenClaw 的约定为例frontmatter 里最关键的是name和description。description写得越具体Agent 越不容易误判调用时机。我见过最差的写法是「小红书自动化工具」这种描述在 Agent 眼里等于没说。下面这份模板是我常用的--- name: xiaohongshu_automation description: - 用于小红书笔记的自动发布、自动评论与关键词检索。 当用户要求“发布一篇小红书笔记”“回复这篇笔记的某个评论” 或“搜索/检索某关键词下的小红书笔记”时使用。 可配合图片提取、笔记ID解析一起调用。 version: 1.0.0 agent: OpenClaw --- # 小红书自动化 Skill ## 能力边界 - 发布图文笔记支持标题、正文、多图、话题标签。 - 评论互动支持回复指定笔记下的评论或主动发布评论。 - 关键词检索返回笔记标题、链接、作者、点赞数输出 JSON。 ## 使用前检查 1. 确认登录态 cookie 是否有效utils/auth.py --check。 2. 确认当前账号今日发布/评论频次未超限。 ## 注意 - 本 Skill 不绕过小红书风控高频操作会导致账号被限流。 - 所有写操作默认开启 30~90 秒随机延迟。注意description里的触发词写法。OpenClaw 的 Agent 是拿这段描述去跟用户消息做语义匹配的所以要把「发布」「评论」「检索」这些动作词写进去并附带「小红书」这个平台限定词避免它拿这个 Skill 去回抖音的问题。2.3 三个平台加载 Skill 的路径差异OpenClaw、Codex、CC一般指 CC Switch 这类 Claude Code 配置工具对 Skill 的发现机制不完全一样。OpenClaw默认扫描~/.openclaw/skills/目录把 zip 解压后丢进去重启服务即可。OpenClaw 的 Agent 在每次会话开始时扫描可用 Skill把描述注入上下文。如果你改了SKILL.md想生效需要在 OpenClaw 里重开一个会话或者执行技能重载命令。CodexOpenClaw 兼容 Codex 的 Skill 格式Codex 项目里也有类似机制。常见做法是在项目根目录建.codex/skills/或者在AGENTS.md里显式引用你的 Skill 路径。Codex 对 Skill 的触发更保守它倾向于在任务描述里找不到明确工具时才翻 Skill 列表所以description字段的措辞要更贴近真实任务。CCCC Switch本质上是管理 Claude Code 配置的 GUI 工具它本身不直接「运行」 Skill但可以帮你管理多个 Claude Code 实例的配置目录。所以在这个环境下Skill 的安装路径取决于你用的 Agent 客户端——如果你通过 CC 切换到某个 OpenClaw 配置目录那 Skill 照样往.openclaw/skills/放如果你切到 Codex 配置就放.codex/skills/。这也是为什么很多人问「CC 到底把 Skill 装哪」答案不是 CC 决定的是你切过去的那套环境决定的。提示装 Skill 前先执行一次openclaw --version或codex --version确认 Agent 版本对 Skill frontmatter 的字段要求。不同版本对agent字段的取值有校验填错直接不加载。3. 小红书三件套的实现发布、评论、检索怎么落地3.1 自动发布构造 web 端请求别碰客户端逆向小红书没有开放内容发布 API所以自动发布只有一个靠谱方向模拟 web 端请求。具体接口路径和签名参数在不同时期会有调整以你抓包拿到的为准这里给的是稳定的处理骨架。import requests import time import json from pathlib import Path def publish_note(cookie: str, title: str, content: str, image_paths: list[str], topics: list[str]) - dict: 发布图文笔记。 cookie: 从浏览器复制的完整 cookie 串。 image_paths: 待上传的图片路径列表建议不超过 9 张。 topics: 话题词如 [技能, 效率工具]。 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Cookie: cookie, Origin: https://www.xiaohongshu.com, Referer: https://www.xiaohongshu.com/, } # 第一步上传图片拿到返回的 image_id 列表 upload_ids [] for img_path in image_paths: with open(img_path, rb) as f: files {file: (Path(img_path).name, f, image/jpeg)} # 接口路径以实际抓包为准常见为 /api/sns/web/v1/upload resp requests.post( https://edith.xiaohongshu.com/api/sns/web/v1/upload, headersheaders, filesfiles, timeout30 ) resp.raise_for_status() upload_ids.append(resp.json()[data][image_id]) time.sleep(2) # 上传间隔避免触发上传风控 # 第二步组装笔记内容并提交 note_data { title: title, desc: content .join([f#{t} for t in topics]), image_ids: upload_ids, post_time: int(time.time()), } resp requests.post( https://edith.xiaohongshu.com/api/sns/web/v1/note/publish, headersheaders, jsonnote_data, timeout30 ) result resp.json() return result这段代码的核心是先传图拿 ID再带 ID 发正文。两个接口必须分步走不能合并。post_time建议取当前时间戳不要填未来时间小红书会校验发布时间的合法性。topics拼进desc尾部并用空格分隔比单独传话题参数更稳。注意Origin头不能省小红书 web 端会校验来源。关于 cookie强烈建议用浏览器登录后复制不要用账号密码模拟登录。账号密码登录涉及验证码、设备指纹、滑块等多道风控脚本维护成本极高。cookie 有效期通常几天到几周失效后重新复制即可。3.2 自动评论先拿到评论 ID再回复评论分两种场景回复别人在你笔记下的评论以及主动去别人的笔记下发评论。前者需要拿到评论 ID 和笔记 ID后者只需要笔记 ID。统一走评论接口。def reply_comment(cookie: str, note_id: str, comment_id: str, content: str) - dict: 回复笔记下某条评论或主动发布新评论。 note_id: 笔记 ID可以从分享链接里解析也可以从检索结果里拿。 comment_id: 要回复的评论 ID主动发评论时传空串。 content: 评论内容建议带 1~2 个话题或 一个相关账号。 headers { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X), Cookie: cookie, Origin: https://www.xiaohongshu.com, Referer: fhttps://www.xiaohongshu.com/explore/{note_id}, } payload { note_id: note_id, comment_id: comment_id or , content: content, at_users: [], } # 常见路径为 /api/sns/web/v1/comment/batch_post resp requests.post( https://edith.xiaohongshu.com/api/sns/web/v1/comment/batch_post, headersheaders, jsonpayload, timeout30 ) return resp.json()这里我故意把 User-Agent 换成 iPhone 的。原因是 web 端对评论接口的校验比发布更严格部分账号在 Web 端根本没有评论入口模拟移动端反而更容易过基础校验。at_users留空即可如果要 人传对方的用户 ID 而不是昵称接口只认 ID。主动评论的最大风险是内容重复。同一句话复制粘贴发 50 条不封你封谁。我的做法是维护一个话术模板文件每条评论从模板里随机拼接再掺入当前笔记的标题关键词。比如模板里写「这个观点很有意思尤其喜欢你说的{{keyword}}」实际发送时把{{keyword}}替换成笔记标题里的 2~3 个词。3.3 自动检索搜索词换结构化结果检索是三个能力里最稳的不涉及写操作风控力度也小。核心是把搜索结果解析成结构化 JSON方便 Agent 做后续决策——比如发现某关键词下点赞最高的笔记然后自动分析它的标题写法。def search_notes(cookie: str, keyword: str, page: int 1, page_size: int 20) - list[dict]: 按关键词检索笔记返回结构化结果列表。 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64), Cookie: cookie, } params { keyword: keyword, page: page, page_size: page_size, sort: general, # general: 综合, time_desc: 最新 } # 常见路径为 /api/sns/web/v1/search/notes resp requests.get( https://edith.xiaohongshu.com/api/sns/web/v1/search/notes, headersheaders, paramsparams, timeout30 ) data resp.json().get(data, {}) notes [] for item in data.get(items, []): note item.get(note_card, {}) notes.append({ note_id: note.get(note_id), title: note.get(display_title), author: note.get(user, {}).get(nickname), likes: note.get(interact_info, {}).get(liked_count), url: fhttps://www.xiaohongshu.com/explore/{note.get(note_id)}, }) return notessorttime_desc在监控竞品时非常有用能拿到最新发布的笔记而不是永远被顶在最前面的爆文。检索接口通常不需要Origin头因为它本质是 GET 请求。如果你只需要图片素材可以在拿到note_id后请求笔记详情接口从中解析image_list字段直接拿到原始图片地址。这就是热词里「小红书图片提取」的落地做法——不是截图识别是直接从详情接口拿原图 URL。4. 把 Skill 装进 OpenClaw、Codex、CC逐个平台跑通4.1 OpenClaw目录放对描述写好OpenClaw 的安装热词里常出现openclaw windowshub安装、openclaw部署说明在 Windows 上部署的人不少。Windows 路径是%USERPROFILE%\.openclaw\skills\Linux 是~/.openclaw/skills/。把 zip 解压到该目录后需要确认目录名和SKILL.md里的name字段一致否则部分版本会报警告。# Linux / macOS mkdir -p ~/.openclaw/skills cd ~/.openclaw/skills unzip xiaohongshu_skill.zip # 验证目录结构 ls ~/.openclaw/skills/xiaohongshu_skill/ cat ~/.openclaw/skills/xiaohongshu_skill/SKILL.md | head -20装完 Skill 后OpenClaw 能不能正确调用还取决于当前 agent 的 channel 配置。热词里有人问「openclaw agent怎么选择channel」简单说OpenClaw 支持多种消息通道Skill 的调用和 channel 没有直接关系但如果你走的是非 CLI 通道比如接入 Microsoft Teams 或飞书需要确认该 channel 的配置里没有禁用工具调用。我遇到过一次 Teams 通道下 Agent 只回文字、不执行脚本的情况最后发现是 channel 配置里allow_tools: false没改。4.2 Codex让 Skill 被自动发现Codex 使用教程里问得最多的是「codex skill 装哪」。OpenAI Codex 对 Skill 的支持偏向项目级不像 OpenClaw 那样有全局目录。我推荐的做法是在项目根目录建.codex/skills/然后在AGENTS.md里写一句引用## Available Skills - 小红书自动化位于 .codex/skills/xiaohongshu_skill/可用于发布笔记、回复评论、关键词检索。Codex 在解析AGENTS.md时会把这段描述注入上下文用户一旦提出相关需求Codex 就会去读那个目录下的SKILL.md并执行里面的脚本。这样做的一个额外好处是Skill 随项目仓库走团队成员 clone 下来就能用不用每个人都手动装一遍。Codex 接入 DeepSeek 这类第三方模型时Skill 加载逻辑不变但要注意模型对工具调用的指令遵循能力差异。DeepSeek 在复杂多步任务里偶尔会跳过 Skill 直接给建议这时可以在用户的 prompt 里加一句「调用小红书自动化 Skill 执行」显式触发指令比依赖模型自觉可靠得多。4.3 CC用 CC Switch 管理多套配置热词里cc switch出现频率不低还有cc switch local proxy failed while handling codex endpoint这种报错。我用 CC Switch 的典型场景是一台机器上同时维护 Claude Code 和 Codex 两套环境按项目切换。CC Switch 本身不管 Skill它管的是各 Agent 的全局配置目录。那 Skill 装在哪取决于 CC Switch 当前激活的 Profile 指向哪套目录。如果你给 Codex 建了独立 Profile那这个 Profile 的目录里就该有.codex/skills/。切 Profile 之后 Skill 不生效绝大多数情况是目录放错了位置或者切过去的那套 Agent 版本不支持 Skill 扫描。先用codex skills list或openclaw skills list验证当前环境能不能看到这个 Skill比瞎猜目录快得多。macOS 上用 CC Switch 没有特殊坑唯一要注意的是首次启动会请求「完全磁盘访问权限」不给授权的话它读不到~/.codex和~/.claude下的配置报错还只提示「directory not found」很容易让人误判成 Skill 路径写错。5. 避坑手册小红书风控和三平台兼容问题5.1 登录态频繁失效cookie 被风控标记现象昨天还能正常发布今天所有请求返回unexpected status 401 unauthorized重新复制 cookie 后恢复但过几小时又失效。原因同一 cookie 在多台机器或多种 User-Agent 下交替使用触发了设备指纹校验。小红书会把频繁更换 UA、频繁异地登录的会话标记为风险会话缩短其有效期。解决固定使用同一份 User-Agent不要 web 端和移动端混用。把 cookie、UA、IP 三者绑定在配置文件里每次请求从配置读取而不是写死在脚本里。这样即使失效也能快速定位是哪部分变了。另外给脚本加 cookie 预检逻辑每次执行写操作前先调一次轻量接口比如获取用户主页信息返回 401 就立即停手并告警不要等发笔记失败才发现。5.2 发布/评论频率过高导致限流现象笔记发布成功但流量异常低或者评论发出去只有自己可见别人看不到。原因触发了小红书的内容风控。发布和评论在短时间内频率过高或者评论内容大量重复会被系统判定为营销号进入「仅自己可见」或「限流观察期」。解决写操作之间必须加随机延迟我的经验是发布间隔 180~300 秒评论间隔 30~90 秒并且每个账号每天的总写操作控制在 20 次以内。评论话术要保证足够的多样性至少准备 10 套模板随机拼接。还有一条血泪经验不要在凌晨 3~5 点做写操作测试这个时段风控模型对异常行为的敏感度最高。5.3 OpenClaw 报 session file locked现象同时开两个 OpenClaw 会话第二个会话执行 Skill 时报agent failed before reply: session file locked (timeout 60000ms)。原因OpenClaw 的会话文件默认加锁多进程同时写同一个 session 文件导致锁等待超时。这跟 Skill 代码无关是 OpenClaw 自身的并发限制。解决避免在多个终端同时操作同一个 OpenClaw 实例。如果确实需要并发给每个会话显式指定不同的 session 文件名或者直接把 Skill 里的耗时操作如批量检索改成后台执行、结果落盘而不是在会话里同步等待。我一般把检索逻辑改成先写结果到output/目录再让 Agent 读取文件这样即使会话锁了也不影响数据产出。5.4 CC 切换 Codex 配置后报 local proxy failed现象CC Switch 里从 Claude Code 切到 Codex Profile启动时报local proxy failed while handling codex endpoint /responses类似错误。原因CC Switch 的本地服务端口被上一次的进程残留占用或者切换时本地服务没有完全重启。新进程连不上旧端口然后直接抛错退出。解决切换 Profile 后先把旧的 Agent 进程完全退出再执行pkill -f cc-switchmacOS 上注意确认进程名清理残留然后重新启动。如果是端口占用查一下该端口被哪个进程占用杀掉后让 CC Switch 自动重启本地服务。这个问题跟 Skill 本身无关但很容易被误报成 Skill 加载失败浪费时间排查。5.5 图片下载成功但发布失败临时目录权限和图片格式现象检索到笔记后顺利下载了图片但发布时报参数错误或图片解码失败。原因小红书对上传图片有隐藏校验WebP 格式经常被拒部分截图保存的 PNG 带透明通道也会触发校验异常。解决统一在发布前把图片转成 JPEG并压缩到长边不超过 4096 像素。推荐的做法是在utils/parser.py里加一步 Pillow 预处理from PIL import Image def normalize_image(src: str, dst: str, max_side: int 4096) - None: img Image.open(src) if img.mode in (RGBA, P): img img.convert(RGB) w, h img.size if max(w, h) max_side: scale max_side / max(w, h) img img.resize((int(w * scale), int(h * scale))) img.save(dst, JPEG, quality90)发布前对每张图跑一遍这个函数能消灭 80% 的图片类报错。6. 进阶把 Skill 从「能跑」做成「可信」这一步我想聊聊验证和可靠性。Skill 装上能跑只是起点真正好用要解决两个问题结果可验证、失败可恢复。先加 dry-run 模式。发布和评论脚本都支持--dry-run传这个参数时不实际调接口只打印将要发送的完整 payload。我每次改完代码都会先跑一次 dry-run核对标题拼接、话题格式、cookie 是否被正确读取。Agent 在调用 Skill 时也建议保留这个参数OpenClaw 的 Agent 可以先 dry-run 再正式执行成本低得多。再做检索结果的增量更新。关键词检索会反复返回相同笔记浪费大量 token。我的做法是在search.py里加一个state/目录用 SQLite 存已见过的 note_id每次检索只返回新增部分。这样 Agent 拿到的是真正的增量信息而不是每一轮都看一遍旧数据。实现上只需在返回前查一次库插入时用INSERT OR IGNORE并发安全由 SQLite 的锁机制兜底。最后做小流量灰度。不要第一天就在主力账号上跑自动发布。先拿小号连续跑三天观察限流和封禁情况再逐步放大。我自己的习惯是灰度期间每天手动检查一次账号状态看笔记是否正常进入推荐流、评论是否被别人看到。这套验证做完Skill 才算真正可以托管给 Agent 日常使用。回顾这个 Skill 的整个落地过程最大的教训不是接口怎么调、风控怎么过而是把对平台的敬畏写进代码里。小红书的风控算法在快速迭代今天能跑的接口明天可能就换签名与其追求一劳永逸的绕过不如把频率控制、话术多样性、失败告警做扎实。希望这个方案能帮你在小红书自动化上少走弯路也希望你用它的时候记得给每个账号留一条人工干预的后路。本文还有配套的精品资源点击获取