1. 凌晨两点的小红书谁在替你发笔记先说清楚这篇要解决的事用 OpenClaw 接入 TaoToken 的统一 API 通道把小红书笔记的定时自动发布跑通包括 config.toml 怎么写、Cookie 怎么拿和怎么刷新、以及怎么手动触发一次发布并检查返回状态。适合已经在用 OpenClaw 做自动化、但卡在「模型调用不稳定」或「Cookie 过期就断更」这两步的人。我自己的场景很典型白天要写稿、回评论、盯数据真正能安静排版发笔记的时间只有深夜。但人不是机器凌晨两点爬起来发内容这件事坚持三天就崩了。后来我把发布流程拆成两段——内容生成交给模型发布动作交给 OpenClaw 定时任务——中间用 TaoToken 做统一 API 通道模型调用不再东一个 Key 西一个 Key。实测下来凌晨无人值守发笔记这件事是能稳定跑起来的前提是 Cookie 验证和返回状态检查这两步别偷懒。需要先明确一个边界OpenClaw 负责调度和发布动作TaoToken 负责把模型请求收敛到一个入口小红书平台侧的规则和风控是另一回事。这篇只讲配置和验证不承诺流量结果也不建议你把账号密码直接塞进任何脚本里——用 Cookie 就够了。2. TaoToken 前置为什么把它放在 OpenClaw 和模型之间OpenClaw 本身是个自动化调度框架它能调模型、能执行 Skill、能定时触发。但只要你同时用两三个模型问题就来了每个模型的 Key 不一样、计费方式不一样、接口路径不一样config.toml 里塞一堆 base_url 和 api_key改一次错一次。TaoToken 在这里的角色是统一 API 通道你只配一个入口地址和一把 Key模型切换在通道侧完成OpenClaw 这边不用动。具体来说TaoToken 的 API 入口是https://taotoken.net/api兼容 OpenAI 风格的请求格式。也就是说OpenClaw 里凡是走 OpenAI 兼容协议的地方把 base_url 指过去、把 Key 换成 TaoToken 的 Key 就能用。官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册和拿 Key 都在控制台完成。拿 Key 的路径很直接进控制台找到 API Keys 页面新建一把 Key复制出来。这里有个习惯建议——给 OpenClaw 单独建一把 Key别和别的项目混用后面要排查「到底是模型调用失败还是发布失败」的时候日志干净很多。控制台地址是https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 页面是https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。如果你后面要长期跑编码类或 Agent 类任务比如让 OpenClaw 自己写文案、自己改封面文案可以看下 Coding Plan它更适合高频调用的场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。只是想先验证模型通不通用模型对话页面最快https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite。注意TaoToken 是 API 通道不是编辑器也不替代 OpenClaw 的调度能力。它的价值在于让你少维护几套 Key 和 base_url。3. 可复制的 config.toml 骨架下面这份 config.toml 是我实际在用的骨架字段名按 OpenClaw 的常见结构写你按自己版本微调。核心是三块模型通道指向 TaoToken、小红书 Skill 的 Cookie 存放、定时任务的时间表达式。# OpenClaw 主配置 [app] name xhs-auto-publish timezone Asia/Shanghai # 模型通道统一指向 TaoToken [llm] provider openai-compatible base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model gpt-4o-mini timeout_seconds 60 max_retries 2 # 小红书 Skill 配置 [skills.xhs] enabled true cookie_file ./secrets/xhs_cookie.txt cookie_refresh_hint_hours 72 publish_mode note default_visibility public # 定时任务每天凌晨 2:10 触发一次发布 [[tasks]] name xhs_nightly_publish schedule 10 2 * * * skill xhs action publish_from_queue queue_file ./queue/notes.jsonl on_failure log_and_continue # 日志 [logging] level info file ./logs/openclaw.log几个参数值得单独说。base_url后面不要带/v1OpenClaw 的 openai-compatible 适配层一般会自己拼路径带了容易 404。max_retries 2是给凌晨网络抖动留的余量但别设太大否则一次失败会拖很久。cookie_refresh_hint_hours 72不是自动刷新只是提醒你超过 72 小时该检查了真正的刷新逻辑在下一节。queue_file指向一个 jsonl 文件每行一条待发笔记结构大概是这样{title: 秋冬干皮救星, content: 正文内容……, images: [./assets/cover1.png], tags: [护肤, 干皮]}内容生成可以提前用模型跑好写进队列也可以让 OpenClaw 在任务里现调模型。我倾向提前生成因为凌晨调模型万一超时发布任务会跟着卡住。生成这一步单独跑用 TaoToken 的模型对话或 API 都行。4. Cookie 获取与刷新别把账号密码写进脚本Cookie 是这套流程里最容易过期的一环。获取方式不复杂但细节决定它能不能撑过一周。第一步在本地浏览器正常登录小红书网页版。第二步按 F12 打开开发者工具切到 Network 面板刷新页面。第三步在请求列表里随便点一个发往小红书域名的请求找到 Request Headers 里的 Cookie 字段整段复制。第四步把复制的内容存到./secrets/xhs_cookie.txt一行不要换行不要加引号。这里有个坑我踩过直接复制开发者工具里显示的 Cookie有时会带上省略号或者被截断。稳妥做法是右键那个请求 → Copy → Copy as cURL然后从 cURL 命令里把-H Cookie: ...那段完整抠出来。长度对不上后面登录必失败。刷新逻辑有两种做法。一种是手动发现发布返回未登录就重新走一遍上面的步骤覆盖文件。另一种是半自动在 OpenClaw 里加一个检测任务发布前先调一次「检查登录态」的接口返回未登录就发通知给你你手动换。我不建议做全自动刷新因为那通常意味着要存账号密码风险和收益不成正比。# 检查 Cookie 文件是否存在且非空 if [ ! -s ./secrets/xhs_cookie.txt ]; then echo cookie 文件为空请先写入 2 exit 1 fi # 去掉可能的首尾空白和换行 tr -d \n ./secrets/xhs_cookie.txt ./secrets/xhs_cookie.clean.txt mv ./secrets/xhs_cookie.clean.txt ./secrets/xhs_cookie.txt这段清理脚本建议放在发布任务前面跑成本极低但能挡掉一类「明明复制了却登录失败」的问题。5. 手动触发一次发布并检查返回状态配置写完别急着等凌晨。先手动触发一次把返回状态看清楚。触发命令按 OpenClaw 的 CLI 习惯大概是这样openclaw task run xhs_nightly_publish --dry-runfalse --verbose--verbose会打印模型调用和 Skill 执行的详细日志。重点看三段第一段是模型通道是否连通日志里应该有发往https://taotoken.net/api的请求和 200 响应第二段是 Cookie 是否被识别通常会打印「login state: ok」之类的字样第三段是发布结果成功会返回笔记 ID 或链接。如果不想跑完整任务只想验证模型通道可以单独发一个最小请求curl -s https://taotoken.net/api/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 回复 ok}] }返回里有choices字段就说明通道没问题。这一步能帮你快速区分是模型调用挂了还是小红书发布挂了。我试过有一次凌晨任务失败查了半天以为是 Cookie结果是 Key 额度用完了日志里其实写得很清楚只是没细看。发布成功后建议在日志里 grep 一下笔记 ID存下来做对账grep note_id ./logs/openclaw.log | tail -n 56. 本篇常见错排查报错一401 Unauthorized来自 taotoken.net。大概率是 Key 写错或额度耗尽。先去控制台确认 Key 状态再检查 config.toml 里有没有多余空格。注意api_key那行不要加引号包裹后再带空格。报错二发布返回「未登录」或「登录态失效」。Cookie 过期或被平台判定异常。重新走第 4 节的获取步骤覆盖文件后手动触发一次。如果换完立刻又失效检查是不是同一账号在多设备频繁登录。报错三任务到点没触发。先确认timezone设置对不对再确认 OpenClaw 进程本身在跑。定时任务依赖常驻进程进程挂了任务不会自己醒。可以用openclaw task list看任务状态。报错四模型调用超时。把timeout_seconds调到 90max_retries保持 2。如果还是超时换一个更轻的模型先跑通流程别一上来就用大模型。报错五图片上传失败。检查images路径是不是相对路径OpenClaw 的工作目录和你以为的可能不一致。用绝对路径最稳。报错六日志里出现乱码。多半是 Cookie 文件带了 BOM 或换行跑一遍第 4 节的清理脚本。排查顺序建议固定成先 curl 验通道 → 再手动触发验 Cookie → 最后看定时任务。这样每次都能快速定位到是哪一层的问题不用从头猜。7. 把流程收进一个入口整套跑通之后你手里其实就三样东西一份 config.toml、一个 Cookie 文件、一个待发队列。日常维护动作只有两个——定期检查 Cookie、往队列里补内容。模型调用那层被 TaoToken 收敛成一个 base_url 和一把 Key换模型不用改 OpenClaw 的调度逻辑。如果你还在验证阶段先用模型对话页面确认通道通不通https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite。准备正式接入 OpenClaw就去 API Keys 页面建一把专用 Keyhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。接入过程中遇到请求格式或路径问题接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。长期跑编码和 Agent 类任务再考虑 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite。最后留一个我自己的习惯每次改完 config.toml先跑一次--dry-run确认解析没问题再放开真发。凌晨无人值守的稳定靠的不是运气是白天把这几步验证做扎实。