我做了一个会"自我进化"的小红书运营 Agent——它自己上网搜笔记、读图片、蒸馏知识

前言

先说结论：我开源了一个叫 rednote-bootstrap 的项目，它是一个运行在 AI Agent 上的小红书运营技能包。

但它不是又一份"小红书运营指南"的 Markdown 文档。它是一个活的知识系统——你问它一个运营问题，它会自己打开浏览器、去小红书搜索真实笔记、翻页截图读图片内容、交叉验证多篇来源，然后把知识蒸馏成一个结构化的可执行指南。下次你再问类似问题，它直接从知识库调用，不再重复研究。

GitHub 地址：github.com/MrMao007/re…

先来看一段实际运行效果——

我问了一句"小红书发布流程是什么"，它的执行过程是这样的：

1. 主题拆解：将"发布流程"拆解为 5 个子维度（准备、流程、审核、时间、运营）
2. 自动搜索：在小红书上执行 3 轮关键词搜索
3. 筛选高赞：按点赞数筛选出 6 篇头部笔记（最高 4479 赞）
4. 逐篇阅读：打开每篇笔记，翻页截图，用视觉理解提取图中文字
5. 知识蒸馏：去重 + 交叉验证 + 冲突消解，生成结构化的子 Skill
6. 注册复用：存入知识库，下次同类问题零延迟响应

最终产出了一份覆盖七步发布法、2026 年最新审核规则、各赛道黄金发布时间表、20 个限流危险行为的完整指南——全程无需人工整理，全部来自小红书上真实创作者的一手经验。

如果你做过小红书运营，或者对 AI Agent 的实际落地场景感兴趣，这篇文章可能对你有些启发。

---

为什么要做这个？

痛点：小红书运营知识的"三不靠"

做过自媒体运营的朋友应该都有这个体感——你想搞清楚一个运营问题（比如"新号怎么养"），通常需要：

1. 去小红书搜一圈
2. 翻十几篇笔记，发现内容都在图片里，还得一页页翻
3. 发现各家说法不完全一致，不知道该信谁
4. 自己整理成文档
5. 过了两个月，平台规则改了，文档作废

这个过程有三个根本问题：

不靠时间——平台规则更新快，你整理的文档三个月就过期。比如 2026 年小红书新增了 AI 内容强制标注要求、CES 评分权重大改，去年的指南直接不能用了。

不靠 LLM——直接问大模型"小红书怎么发笔记"，它会给你一个看起来合理但可能已经过时的回答。因为训练数据有截止日期，而且很多细节隐藏在创作者的实战经验里，不在任何官方文档上。

不靠效率——小红书笔记最大的特点是核心内容都在图片里，不是纯文本。你没法用爬虫直接抓文字，必须"看图"才能获取信息。

所以我在想：能不能让 Agent 自己去做这件事？像一个真实用户一样，打开浏览器、搜索、翻阅、阅读图片、整理知识？

核心思路："搜索优先"的知识自进化

rednote-bootstrap 的核心思路可以用一句话概括：

不预设知识，现搜现学，学完存下来，下次直接用。

具体来说就是三层：

┌─────────────────────────────────────────────────┐
│  路由层：理解意图 → 查注册表 → 命中就复用        │
├─────────────────────────────────────────────────┤
│  研究引擎：搜索 → 采集 → 评估 → 蒸馏 → 注册     │
├─────────────────────────────────────────────────┤
│  知识库：持续增长的子 Skill 集合                  │
└─────────────────────────────────────────────────┘

用户的每个问题，先走注册表路由。命中了就直接用，没命中就启动研究引擎。研究引擎跑完后把结果存到知识库，然后注册表就有了新的条目。下次类似问题就不用再研究了。

这意味着：你用得越多，它知道的越多，响应越快。

---

技术实现

五阶段研究引擎

这是整个项目的核心，我把它拆成了五个阶段：

Phase 1：主题分析与搜索词生成

收到一个主题后，先拆解成 3~5 个子维度。比如"小红书发布流程"会被拆成：发布前准备、完整发布步骤、审核规则、发布时间优化、发布后运营。

然后为每个维度生成搜索词，用了三种策略：

• 直接词：子维度本身（"小红书发布笔记流程"）
• 长尾词：加入场景或痛点（"小红书笔记发布后没流量怎么办"）
• 反向词：从失败角度搜索（"小红书发笔记常见错误"）

Phase 2：浏览器自动化采集

这里用的是 agent-browser，一个基于 Rust 的浏览器自动化 CLI。整个流程是：

打开小红书 → 搜索关键词 → 获取搜索结果的无障碍树快照
→ 按点赞数筛选 Top N → 逐一点击打开 → 翻页截图 → 视觉理解提取内容

这里有几个关键点：

1. 必须用真实浏览器：小红书没有公开搜索 API，反爬也做得很严格。agent-browser 通过 CDP 直接操控 Chrome，是以"正常用户"的身份在浏览。

2. 必须截图读图：这是最关键的一点。小红书笔记的核心内容几乎都嵌在图片里，DOM 里拿不到。所以每一页都需要截图，然后通过多模态模型来"看"图片内容。

3. 登录态管理：首次需要用户扫码登录，之后 agent-browser 会把认证状态持久化到 xhs-auth-state.json，后续自动复用。

4. 平台适配层：我在 reference/platforms.md 里定义了小红书的完整 DOM 交互映射——搜索框选择器、结果列表结构、笔记详情页结构、图片翻页机制。相当于给 Agent 写了一份"小红书操作手册"。

Phase 3：自适应深度控制

这是我觉得最有意思的部分。

一开始我是固定采集数量的——每个搜索词读 5 篇，共读 15 篇。但很快发现两个问题：有些主题 5 篇就够了（信息高度重叠），有些主题 15 篇还不够（每篇都有新信息）。

所以我设计了一个饱和度评估模型，用四个指标动态决定"够不够"：

指标	怎么算	阈值
信息新增率	本轮新增独立要点 / 总提取要点	< 20% → 饱和了
维度覆盖率	已有内容的维度数 / 总维度数	> 80% → 够了
矛盾检测	不同笔记间有没有互相矛盾	有矛盾 → 继续验证
权威性	有没有认证博主/官方内容	缺乏 → 补充

决策逻辑是：

新增率 < 20% 且 覆盖率 > 80% → 停止，进入蒸馏
新增率 < 20% 但 覆盖率 < 80% → 针对未覆盖维度生成新搜索词
存在矛盾 → 针对矛盾点搜索更多来源
都不满足 → 继续当前计划

同时有安全边界：最多 5 轮搜索、30 篇笔记、15 分钟。防止无限循环。

Phase 4：知识蒸馏

采集完成后，按照五条规则蒸馏：

1. 去重：不同笔记说的同一件事，合并
2. 交叉验证：被 3 篇以上笔记提及的要点，标记为"高置信度"
3. 冲突消解：有矛盾的观点，并列呈现，不强制裁决
4. 时效标注：标注信息基于哪个时间点的规则（"此为 2026 年 3 月规则"）
5. 可执行化：把"建议优化标题"这种笼统建议，转化为具体步骤

最终生成的子 Skill 不是一堆信息的堆砌，而是一份结构化的可执行指南，包含：领域概述、核心知识体系（按维度 + 置信度）、可执行工作流、工具资源、常见误区、时效说明、信息来源（可溯源到每篇笔记）、以及知识缺口（诚实标注没覆盖到的部分）。

Phase 5：注册与路由

生成的子 Skill 会被注册到 registry.json，记录 topic、keywords、置信度、分析笔记数等元数据。后续用户的问题会先匹配注册表：

• 精确匹配 topic → 直接复用
• keywords 覆盖 > 70% → 复用 + 检查是否需要增量更新
• 无匹配 → 启动研究引擎

对于增量更新，也有策略：如果新问题的子维度已有 Skill 没覆盖，只研究差异部分并增量合并，不从头来过。

子 Skill 模板

每个自动生成的子 Skill 都遵循统一模板：

---
name: xiaohongshu-publishing-guide
topic: 小红书发布流程及注意事项
researchDepth: standard（分析了 6 篇内容）
---

# 小红书发布流程及注意事项

> 信息来源：小红书平台 6 篇内容的交叉验证
> 置信度：高
> 上次更新：2026-04-23

## 领域概述
## 核心知识体系        ← 每个维度标注置信度
## 可执行工作流        ← 步骤化操作指南
## 工具与资源
## 常见误区与避坑
## 时效性说明          ← 哪些信息可能过期
## 信息来源            ← 溯源到每篇笔记
## 知识缺口            ← 诚实标注没覆盖的

我特别看重"信息来源"和"知识缺口"这两个部分——前者让知识可追溯可验证，后者避免了 AI 常见的"什么都知道"的幻觉问题。

---

实际生成案例

目前已经生成了两个子 Skill 作为示例：

📝 小红书笔记发布流程

这是我测试时生成的第一个子 Skill，分析了 6 篇高赞笔记（总点赞超过 7600），覆盖了：

• 七步发布法（重点：不要直接点 + 号，要通过创作者中心 → 笔记灵感入口）
• 2026 年最新审核规则（AI 标注强制要求、CES 评分权重调整、导流红线）
• 各赛道黄金发布时间表（美妆、美食、娱乐、学习、育儿等 15 个赛道）
• 20 个导致限流的危险行为清单
• 发布后冷启动关键期（2 小时内互动质量占流量分配权重 60%）
• 阶梯式处罚标准和申诉流程

🌱 小红书日常养号流程

分析了 4 篇笔记，覆盖了：

• 五边形权重体系（观看、互动、发文活跃度、主页访问、涨粉）
• 新号 7 天养号周期（Day 1-3 纯浏览 → Day 4-5 试发 → Day 6-7 稳定运营）
• 八大伤号禁忌行为
• 僵尸号复活流程

这些内容全部来自小红书上真实创作者的经验分享，经过多源交叉验证。比如"不要直接点 + 号发布"这个技巧，被 4 篇不同笔记同时提及，置信度标记为"高"。

---

架构设计的几个取舍

为什么不用 API 而用浏览器？

小红书没有公开的内容搜索 API，第三方 API 不稳定且可能违反 ToS。用 agent-browser 以真实浏览器操作是最合规、最稳定的方式。代价是速度稍慢（一次完整研究约 5-10 分钟），但对于"研究一次复用多次"的模式来说完全可以接受。

为什么不直接用 RAG？

RAG 需要先有一个语料库，而小红书的内容是图片为主的、动态更新的。你没法提前把所有笔记索引好。rednote-bootstrap 的做法是"按需检索、实时蒸馏"——需要什么就去搜什么，搜完蒸馏成可复用的知识。可以理解为一种"动态 RAG"。

为什么要生成 Skill 而不是直接回答？

三个理由：

1. 复用：生成一次，后续同类问题零延迟
2. 可编辑：用户可以审查、修改蒸馏结果
3. 可增量：新知识可以合并进已有 Skill，而不是从头来过

如果只是直接回答，那每次都要重新搜索 + 阅读，既慢又浪费。

为什么自适应深度而不是固定数量？

不同主题的信息密度差异极大。违禁词清单需要 15 篇才能覆盖全面，而一个具体操作流程可能 3 篇就够了。固定数量要么不够要么浪费，自适应深度让 Agent 自己判断"够不够"。

---

可扩展性

虽然目前主力支持小红书，但架构上预留了扩展空间：

reference/platforms.md 定义了平台适配层，包括 DOM 选择器、交互模式、内容质量信号等。理论上，为其他内容平台（抖音、B站、知乎）写一份类似的适配配置，就可以让研究引擎支持新平台。

子 Skill 模板和蒸馏规则也是与平台无关的——它们定义的是"如何组织知识"，不绑定具体平台。

---

快速上手

依赖

• QoderWork 桌面应用（Agent 运行环境）
• agent-browser：npm i -g agent-browser && agent-browser install
• Chrome / Chromium

安装

git clone https://github.com/MrMao007/rednote-bootstrap.git \
  ~/.qoderwork/skills/rednote-bootstrap

使用

在 QoderWork 里直接对话即可，Skill 自动加载：

你：小红书发布流程是什么？
你：新号怎么养号？
你：违禁词有哪些？

首次使用需要扫码登录小红书（一次性，之后自动复用认证状态）。

---

写在最后

rednote-bootstrap 本质上是在探索一个问题：Agent 能不能像人一样"现学现卖"，而不是只靠预训练知识？

我的答案是可以的——通过浏览器自动化获取实时信息，通过视觉理解突破图片内容的壁垒，通过知识蒸馏把碎片信息变成结构化知识，通过注册复用实现"越用越聪明"。

这个项目目前还在早期，有很多可以改进的地方（更多平台支持、更智能的搜索词生成、更精细的蒸馏规则）。如果你对这个方向感兴趣，欢迎来 GitHub 上看看，提 issue、贡献代码或者分享你生成的子 Skill。

GitHub 地址：github.com/MrMao007/re…

如果觉得有用，欢迎给个 Star ⭐️，这对开源作者来说是最好的鼓励。