小红书自动化运营 SOP:Hermes + MCP + OpenSpec(含全自动发布风险与回退)

基于 Hermes Agent 的可复用运营流水线:从选题到复盘的可执行细粒度步骤,给出可用 MCP/技能/工具、成本与调试清单,并明确全自动发布的合规与风控边界。

AI 摘要

这篇文章适合快速了解什么

基于 Hermes Agent 的可复用运营流水线:从选题到复盘的可执行细粒度步骤,给出可用 MCP/技能/工具、成本与调试清单,并明确全自动发布的合规与风控边界。

这是一篇偏使用指南方向的内容,适合想快速理解“小红书自动化运营 SOP:Hermes + MCP + OpenSpec(含全自动发布风险与回退)”核心脉络的读者。

文章先解释“TL;DR”,帮助你快速进入主题。

随后会展开“0. 先说清楚:全自动发布的边界与风险”,方便直接定位关键方法或判断标准。

核心看点

  • TL;DR
  • 0. 先说清楚:全自动发布的边界与风险
  • 1. Hermes 搭建(两条路径:官方 Quickstart / 本仓库 Docker)
  • 1.1 官方 Quickstart(适合本机 CLI/TUI)

你要的是“自动化运营”,但请先把目标从“全自动发出去”升级为“长期稳定跑起来”:内容质量可控、发布风险可控、调试成本可控、可持续迭代。

本文基于两类可验证事实写作:

OpenSpec 在本文中按“通用 Spec 流程”描述:你可以先用它把运营工作做成可验证交付;但 OpenSpec 的具体实现、命令与配置差异,本文会明确标为“待确认项”,不以确定性口吻给出不可验证配置。

TL;DR

  • Hermes 原生支持 MCP:在 ~/.hermes/config.yaml 的 mcp_servers 下配置 stdio 或 HTTP MCP server,启动时自动发现工具;可用 /reload-mcp 重载配置[1]。
  • 运营自动化的“可控闭环”是:选题池 → 事实/素材库 → 草稿 → 审稿门禁 → 发布 → 评论/私信 → 复盘 → 回写选题池(每一步都能回滚)。
  • 小红书全自动发布有明显合规与风控风险:建议默认走“半自动(推荐)”,全自动仅作为可选路径,并且必须提供失败回退(降级为人工发布)。
  • 模型“最优解”不存在一刀切:Hermes 只要求至少 64K context[2];剩下用任务集做基准测试,再选成本/稳定性/工具调用能力的平衡点。

0. 先说清楚:全自动发布的边界与风险

小红书的“全自动发布”通常会碰到:

  • 登录态/验证码/行为风控(自动化脚本容易触发)
  • 账号安全风险(被限流/封号/异常审核)
  • 合规风险(平台规则、内容合规、自动化行为限制)

因此本文的策略是:

  • 默认推荐:半自动发布(Hermes 自动产出“可直接发布的终稿+素材包”,发布动作由人工完成)
  • 提供可选:全自动发布(必须包含风控策略、审批/人工确认点、失败回退)

1. Hermes 搭建(两条路径:官方 Quickstart / 本仓库 Docker)

1.1 官方 Quickstart(适合本机 CLI/TUI)

Hermes Quickstart 的最小可跑流程是:

  1. 安装(Windows 需先装 WSL2,在 WSL2 里执行)[2]
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc
  1. 选模型与 Provider(交互式)[2]
hermes model
  1. 启动对话(CLI 或 TUI)[2]
hermes
hermes --tui

关键约束:Hermes 要求模型至少 64K tokens context,否则会拒绝启动[2]。

1.2 本仓库 Docker 部署(适合“长期跑”的运营/网关)

本仓库已提供 Hermes 独立编排目录:ai/hermes/,并把配置、技能、MCP、会话、日志、workspace 统一收口到 data/hermes/[3]。

  1. 填写环境变量
  • 复制并修改:ai/hermes/.env.example → ai/hermes/.env(注意不要提交真实 Key)
  • 重点变量(示例见 .env.example):LLM_API_KEY、LLM_MODEL、LLM_BASE_URL、HERMES_INFERENCE_PROVIDER、EXA_API_KEY/PARALLEL_API_KEY/FIRECRAWL_API_KEY/TAVILY_API_KEY、INTERNAL_HTTP_MCP_TOKEN 等[4]
  1. 初始化运行态目录(首次部署)[3]
python ai/hermes/init_runtime.py
  1. 启动容器(Hermes CLI 不会自动启动,容器会常驻等待你 exec 进去)[3][5]
cd ai/hermes
docker compose --env-file .env up -d --build --force-recreate
docker exec -it hermes-agent bash
hermes
  1. 你要让 Hermes 能读写哪些文件?

仓库已把 data/hermes/workspace 映射到容器内 /workspace[5]。运营产物(草稿、封面图、发布记录)建议写到这个目录,便于审计与回滚。

2. MCP:把“运营能力”拆成可组合的工具接口

Hermes 的 MCP 文档明确给出了:

  • stdio MCP server(command/args/env)
  • HTTP MCP server(url/headers)
  • per-server 工具过滤(tools.include/tools.exclude)
  • 工具命名前缀(mcp_<server_name>_<tool_name>)
  • /reload-mcp 重载[1]

2.1 先跑通两个“最小可验证” MCP

A) Filesystem(把素材/草稿当作文件资产管理)

Hermes MCP Quick start 示例(stdio)[1]:

mcp_servers:
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]

在本仓库 Docker 方案里,建议把 root 指向 /workspace,并让运营资产都落到这里(审计友好)。

B) GitHub(用 Issue/PR 管理“选题池/脚本/复盘”)

Hermes Quickstart 也给了 GitHub MCP 示例(stdio)[2]:

mcp_servers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"

你可以再加一个白名单过滤(只放出你愿意让模型看到的动作)[1]:

    tools:
      include: [list_issues, create_issue, update_issue]
      prompts: false
      resources: false

2.2 本仓库已提供 MCP 配置模板(建议从这里改)

本仓库的默认 MCP 模板在:data/hermes/config.yaml 的 mcp_servers 下,包含:

  • internal_http:远程 HTTP MCP 模板(默认 enabled: false)
  • docs_http:文档类 HTTP MCP(默认 enabled: false)
  • workspace_filesystem:本地文件系统 MCP(默认 enabled: false)
  • github:GitHub MCP(默认 enabled: false)

你只需要把要用的 server 改成 enabled: true,补齐 token 环境变量,然后在 Hermes 会话里执行 /reload-mcp(或重启 Hermes)data/hermes/config.yaml。

2.3 运营需要哪些 MCP 工具?(建议拆分)

以下是“运营流水线”常见能力模块。你不一定全做,但建议按模块拆成 MCP servers 或 toolsets,避免一锅粥:

  • 内容生产:选题检索、事实核验、结构化大纲、标题/封面文案生成
  • 素材处理:图片生成、图片压缩、字幕/音频(如有视频)
  • 账号与发布:排期、发布、失败重试、草稿保存
  • 数据回流:浏览/收藏/评论/转化指标抓取、周报
  • 风控:敏感词/违规风险检测、人工审批、回滚

Hermes 本身就有不少内置工具与 toolsets(web、browser、file、terminal、cronjob、skills 等),也支持 Tool Gateway 的订阅能力(web search / browser automation 等)——是否可用取决于你的平台与配置[6][7]。

3. Skills:把“运营 SOP”写成可复用技能(不是写死在 prompt)

Hermes Skills 目录与机制是可验证的:

  • 官方文档:技能目录在 ~/.hermes/skills/,并强调 progressive disclosure[8]
  • 本仓库 Docker 方案:技能目录挂载在 data/hermes/skills,容器内对应 /opt/hermes/skills[9]

本仓库已内置 4 个可直接复用的技能(都在 data/hermes/skills):

运营建议你再新增 3 个技能(写到 data/hermes/skills/,让容器自动挂载):

  1. xhs-topic-research:选题池更新与事实核验
  2. xhs-draft-writer:小红书风格草稿生成(你自己的品牌口吻)
  3. xhs-publish-checklist:合规/敏感/图片/标题门禁 + 回退策略

这些技能不需要写代码,本质是标准化的“流程文档 + 清单”,但它会显著降低你每天在 prompt 上的重复劳动。

4. OpenSpec 在运营场景怎么用(通用流程,不绑定实现)

你可以把每一篇内容当成一个“可验收交付”,而不是一次性灵感输出。推荐最小结构:

  • spec:Why / What Changes / Impact / Requirements(WHEN/THEN)
  • tasks:把一篇内容拆成 5~8 个可验证步骤
  • checklist:验收点(标题、结构、引用、素材、合规、发布、复盘)

待确认项(必须写进你的流程里,而不是靠记忆):

  • OpenSpec 的具体文件格式/CLI/运行方式(不同实现差异很大)
  • 你最终把 spec 存在 GitHub issue、Notion、还是本地 repo

建议先用最简单的载体:一个 GitHub repo 的 content/ 目录 + issue 作为任务系统,把 SOP 固化后再上更复杂的系统。

5. 运营流水线(细粒度可执行步骤)

下面给一套你可以直接照着做的“每天一轮/两轮”的流水线。括号里标注推荐的 Hermes 能力来源:内置工具 / MCP / skill。

5.1 选题池(每天/每周)

  1. 拉取近 24h / 7d 的外部信号:行业新闻、竞品更新、搜索热词(web_search/web_extract 或你的自建 MCP)[7]
  2. 把信号写入选题池(filesystem MCP 写到 /workspace/topics/*.md 或 GitHub issue)[1]
  3. 每条选题补三项:目标人群、核心结论、证据链接(skill:xhs-topic-research)
  4. 去重与合并:同类选题合并到一个“系列主题”(人工或 tool)

5.2 素材与证据(每篇必做)

  1. 事实核验:对关键结论至少 2 个来源交叉验证(web_extract + 规则)[7]
  2. 抽取证据:把关键段落、数据来源链接落到“证据卡片”(filesystem MCP)
  3. 标注“时间敏感信息”:价格/政策/版本(写“截至某日,以官方为准”)

5.3 草稿生成(可自动)

  1. 生成结构化大纲(TL;DR、要点、步骤、FAQ)
  2. 生成 3 个标题与 3 个封面文案备选(同一事实,不同角度)
  3. 输出“发布包目录结构”:
    • post.md:正文
    • title.txt:标题候选
    • cover.png:封面(可选)
    • sources.md:引用与证据
    • risk.md:合规/风控自检结果

5.4 审稿门禁(强烈建议保留人工确认)

  1. 合规检查:敏感词/不当承诺/夸大宣传(skill:xhs-publish-checklist)
  2. 事实检查:引用链接可打开,结论与证据一致
  3. 风控检查:涉及账号操作必须走“审批”或“人工确认点”[10]

5.5 排期与发布(半自动/全自动)

半自动(推荐默认)

  1. Hermes 生成发布包 → 人工复制粘贴到小红书发布界面
  2. 发布后把“发布链接/时间/标签/封面版本”写回 publish-log.md(filesystem MCP)

全自动(可选,但必须有回退)

全自动发布有两条路径,均需你自己评估合规与可行性:

A) 官方/开放接口(待确认)

  • 待确认:小红书是否向你的账号类型开放“内容发布 API”。
  • 若有:建议以 HTTP MCP server 方式封装成 xhs_api,只暴露最小动作(create_draft / publish / status),并用 tools.include 白名单限制[1]。

B) 浏览器自动化(高风险,可能失败)

  • Hermes 内置 browser 工具集支持 browser_navigate/browser_snapshot/browser_click/browser_type 等[6]。
  • 风险:登录态、验证码、风控、页面结构变更。
  • 最小可验证演示建议只做到“打开页面 + 截图 + 人工接管确认”,不要一上来直接点发布。

你可以把“发布”设计为必须人工 approve 的危险动作:Hermes 支持危险命令审批(approvals.mode: manual|smart|off)与 fail-closed 的超时拒绝策略[10]。即使你最终要全自动,也建议把“发布动作”设成单独的审批点。

5.6 评论/私信与复盘(自动 + 人工抽检)

  1. 抓取评论与私信(待确认:是否有可用 API;无则走浏览器/RPA 风险更高)
  2. 自动聚类:高频问题、争议点、转化点
  3. 产出每日复盘:
    • 哪些标题/封面更有效
    • 哪些信息点被误解(需要改写)
    • 哪些话题值得做系列
  4. 回写选题池与“写作风格偏好”(长期记忆/skills)

6. 成本与时间投入(不报固定价格,只给可计算模板)

6.1 模型成本(可计算)

Hermes 支持多 provider,并建议新手选择 Nous Portal 或 OpenRouter 作为低摩擦路径[2]。但“最优解”取决于你的任务集与预算。

建议用下面模板估算(按 1 天):

  • C_model_day = Σ_i (Tin_i * Pin + Tout_i * Pout) / 1e6
    • Tin_i:第 i 个任务输入 tokens
    • Tout_i:第 i 个任务输出 tokens
    • Pin/Pout:你所用模型的输入/输出单价(从官方定价页取数)

取数方法(不依赖猜测):

  1. 用 Hermes 跑 10 条“真实运营任务”
  2. 记录每条任务的 tokens(若 provider/日志可提供)
  3. 用中位数/分位数估算日均消耗,再乘单价

6.2 MCP 对接成本(工程投入)

把一个业务系统接成 MCP,一般要做:

  1. 明确工具契约:tool name、参数 schema、输出 schema(避免长文本)
  2. 选择 stdio 还是 HTTP server(Hermes 两者都支持)[1]
  3. 写最小 server:至少一个 health_check + 一个只读查询
  4. 在 mcp_servers 下配置并开启,使用 tools.include 做白名单
  5. Hermes 会话里 /reload-mcp,用“最小验证 prompt”跑通

你可以把这套工作当成“对接一个内部 API”的成本,而不是“写 prompt 的成本”。

6.3 每日时间投入(用步骤计时,不靠拍脑袋)

不要直接问“每天要花多久”,而是对每一步做计时:

  • 选题池整理:T_topic
  • 事实/素材核验:T_evidence
  • 草稿生成:T_draft(基本可自动)
  • 审稿门禁:T_review(建议保留人工)
  • 发布/排期:T_publish(全自动会把时间转移到“排障/风控”)
  • 复盘:T_retro

然后:

  • T_day = T_topic + T_evidence + T_draft + T_review + T_publish + T_retro

你可以先跑 1 周,用真实数据替换这些变量,再决定要不要把某一步“自动化升级”。

7. 调试与排障清单(把问题变成可复盘)

Hermes 官方 Quickstart 给了一套恢复工具链(hermes doctor、hermes model、hermes sessions list 等)[2];MCP 文档给了工具不出现时的排查步骤(检查 uv pip install -e ".[mcp]"、node/npx 版本、过滤规则等)[1]。

结合运营场景,建议你把排障分成 4 类:

  1. 模型层:输出质量波动、超时、上下文不够(检查 64K 要求)[2]
  2. 工具层:MCP server 连接失败、工具不出现、过滤配置误伤(enabled、tools.include/exclude、/reload-mcp)[1]
  3. 账号层:登录态失效、验证码、风控(必须准备回退)
  4. 流程层:没有门禁、没有日志、没有回滚(先补流程再谈全自动)

8. 模型选择“最优解”(决策矩阵 + 必须实测)

Hermes 的硬门槛是 64K context[2]。在此基础上,用下面矩阵做选择:

  • 稳定性:长链路 tool-calling 是否容易跑偏
  • 工具调用能力:对结构化工具输出的遵循程度
  • 成本:单价 + token 消耗
  • 速度:TUI/网关的可用性(延迟)
  • 安全与可控:是否支持更强的审计/可观测(取决于 provider)
  • 生态:OpenRouter 多模型路由是否方便(Hermes Quickstart 推荐它做多 provider)[2]

最小可复现实测(建议你自己跑一遍):

  1. 选题 → 草稿 → 合规门禁 → 发布包输出(10 条样本)
  2. 统计:成功率、人工返工次数、平均 tokens、平均耗时
  3. 换模型重复,按同一指标比较

待确认项清单(本文不替你编造)

  • 小红书是否对你的账号类型开放“发布 API”(若无,全自动只能走高风险自动化)
  • 你要用的 OpenSpec 具体实现与格式(本文只给通用流程)
  • 你准备接入哪些业务系统作为 MCP server(内部 CRM、选题数据源、素材库等)

参考与延伸阅读

站点信息

关于这篇内容的来源与维护方式

这篇文章由 ToolsHub 公开发布,站点持续维护 AI 工具、在线文档、技术教程和效率实践内容。

我们优先保证公开页面可直接阅读、可分享、可被搜索引擎与 AI 正确理解。