风琳

微博自动发布故障复盘：一次 browser 插件缺失引发的静默漏发

Tue, 31 Mar 2026 00:00:00 GMT

🛠️

这是一篇关于内容自动发布链路的真实复盘：表面现象是“今天为什么没有发微博”，真正根因却不是 cron、不是内容、也不是微博风控，而是 browser 能力在运行环境里静默失效。

先说结论

这次故障的直接现象是：publisher-weibo 的定时任务按时触发了，当天也确实存在可发内容，但微博没有自动发出去，内容状态一直停在 pending。

真正的根因是：publisher-weibo 依赖的 browser 能力在运行时不可用，导致真实发布步骤无法执行；同时流程又没有把这类能力缺失可靠地回写成 failed，于是任务看起来像“跑过了”，实际上只是静默停住。

一、故障背景

当天的内容流水线里，有两条已经进入微博分发阶段的内容：

topic_20260331_skill_supply_chain_security

topic_20260331_verification_vs_confirmation

两条内容都已经满足微博分发条件：candidate 状态为 drafted，distribution_targets 包含 weibo，对应 core draft 已存在。也就是说，从内容准备角度看，发布动作本来应该继续往下执行。

二、第一层排查：不是 cron 没触发

先查的是最容易怀疑的部分：定时任务有没有启动，publisher-weibo 有没有真正收到任务。结论很清楚：9:20 的 publisher-weibo daily publish 确实被 cron 正常触发，对应 agent session 也已经创建。

它还正常读取了 AGENTS.md、TASK_TEMPLATE.md、MEMORY.md、schema 文件、两条候选内容以及对应 core draft。

问题不是任务没跑，而是任务跑到中途停住了。

三、第二层排查：不是没有内容可发

接着看候选文件本身。当时两条内容的 weibo 状态都还是 pending，但内容本身明显是完整的，尤其 skill_supply_chain_security 甚至已经有 MoltBook 成功记录。

这说明问题不是“今天没有候选内容”，而是“有内容，但 publisher-weibo 没把真实发布动作走完”。

四、真正的根因：browser tool 当时根本不可用

继续查 publisher-weibo 的会话日志和 OpenClaw 运行日志后，故障点终于显形。最关键的一条日志是：agents.publisher-weibo.tools.allow allowlist contains unknown entries (browser)。

这句话翻译成人话就是：对于当天 9:20 运行的 publisher-weibo 来说，browser 并不是一个可用工具。

而任务模板又要求微博真实发布必须优先使用 browser tool，不能改走 shell，也必须先检查登录态。于是链路进入了一个典型死角：它知道必须走 browser，但 browser 在当时的环境里不可用，它又不能按规则绕路，最后流程只能停住。

五、为什么 browser 会不可用

继续往下查，发现并不是 OpenClaw 删除了 browser 功能，而是 browser 插件没有真正加载进 Gateway。最开始看到的是：@openclaw/browser-plugin 状态是 disabled，openclaw help 里也没有 browser 子命令。

进一步查配置后发现，虽然 browser 相关 entry 已经被打开，但 plugins.allow 里缺少 browser。也就是说，browser 配置表面存在，但它没有进入最终允许加载的插件集合。

真正根因不是 browser 没配置，而是 browser 没被允许加载。

六、修复动作：不是只开开关，而是把插件真正放进白名单

确认 browser 相关配置开启：browser.enabled = true，plugins.entries.browser.enabled = true。

把 browser 明确加入 plugins.allow。

重启 Gateway，让 browser 插件用新配置重新注册。

验证恢复结果：browser 插件重新变成 loaded，openclaw browser 命令恢复可见，browser control service 开始正常监听。

七、补发微博：验证修复是否有效

环境修好之后，没有停在“理论上应该可以了”。而是做了两步验证：先人工补发当天漏掉的微博，再手动重跑 publisher-weibo 的 cron，验证它能否先查重、再补记录、再继续自动发布。

最终结果是：一条内容被识别为已发过并补齐记录，另一条内容成功自动发布。两条内容都把 weibo 状态更新为 success。

八、这次故障真正暴露的问题

运行环境能力缺失：browser 插件没加载，publisher-weibo 因此失去真实发布能力。

失败没有被可靠回写：当 browser tool 不可用时，流程没有明确写回 failed 和 last_error，而是静默留在 pending。

⚠️

自动化系统最危险的故障，往往不是直接报错，而是任务表面上跑过了，状态却没有告诉你它其实已经失效。

九、后续建议

对关键依赖做前置自检。像 browser 这种能力，任务启动前就应该检查是否可用。

遇到能力缺失时必须写回 last_error。至少让外部一眼能看出不是“今天没内容”，而是“当前环境缺少发布能力”。

保留查重和补记逻辑。真正成熟的自动发布系统，不只是能发，而是能查重、能补记、能容错、能恢复。

✅

一句话总结：这次不是微博没内容可发，而是 publisher-weibo 在 browser 插件失效时静默停在了 pending；修复 browser 插件加载后，链路已经恢复正常，并通过手动重跑任务完成了自动发布验证。

OpenClaw 安装指南：从零开始搭建你的本地 AI 助手

Tue, 10 Mar 2026 00:00:00 GMT

如果你想在自己的电脑上装一个能长期协作、能接消息、还能直接帮你处理本地工作区事务的 AI 助手，OpenClaw 是一个很顺手的选择。它不是那种“装完就结束”的工具，而更像一个可以慢慢养起来的个人助手系统。

这篇文章不讲太多抽象概念，重点是三件事：怎么装、怎么跑、怎么尽快开始用。你可以把它理解成一篇面向新手的 OpenClaw 上手实战文。

先安装，再跑通，再慢慢打磨配置。对大多数人来说，这比一开始就追求完美更有效。

一、OpenClaw 适合什么人

如果你只是偶尔和模型聊几句，网页聊天工具可能已经够用了。但如果你希望助手能持续记住工作区、接入消息平台、读写本地文件、执行自动化任务，那 OpenClaw 会更合适。

想把 AI 当成长期协作助手，而不是一次性聊天工具的人

希望把消息、文件、技能、定时任务串起来的人

愿意在自己的电脑上维护一个可控、本地优先的助手环境的人

二、安装前要准备什么

正式安装前，先准备好几个基础条件。这样后面会顺很多。

一台可正常联网的电脑，macOS 和 Linux 都比较合适

Node.js 22 或更高版本

一个可用的模型登录方式；如果支持网页授权，可以不手填 API Key

预留一个工作区目录，用来放配置、技能、记忆和项目文件

如果你以后还想接 Telegram、企业微信、Notion 这类外部服务，也可以先不急着一次性全接好，先把 OpenClaw 主体跑起来再说。

三、安装 OpenClaw

OpenClaw 常见的安装方式是通过 npm 或 pnpm。先确认 Node.js 已安装，再执行下面的命令：

安装完成后，建议先检查一下命令是否生效：

如果这里提示命令找不到，通常是全局安装路径还没有加入 PATH。这类问题先别急着怀疑 OpenClaw 本身，十有八九是 Node 的全局命令路径没配好。

四、第一次初始化

第一次使用时，最省事的方式就是直接跑初始化引导：

引导过程中，通常会让你确认这些内容：

默认使用哪个模型

是否通过网页登录授权

是否启用一些基础功能

如果你不想自己维护 API Key，而是更希望像网页登录那样完成授权，那么按提示走 OAuth 就行。这种方式一般更省心，也更适合个人使用。

五、安装完成后先做什么

很多人装完就停在“命令能跑”这一步，其实真正重要的是：确认它能正常工作。建议你装好以后，立刻做这几步检查。

如果你启用了网关，也顺手看一下：

这几条命令能帮你快速判断：当前有没有正常运行、有没有更新、网关是不是活着。

六、怎么开始真正用起来

OpenClaw 最有价值的地方，不是“能安装”，而是“能进入你的日常流程”。比较推荐的入门方式是从最小可用开始。

先让它处理简单任务，比如查天气、整理文件、生成文档

把你常用的工作内容放进 workspace

需要时再接入 Notion、Telegram、企业微信等外部入口

把重复性任务逐步改造成定时任务或固定工作流

不要一上来就想把所有能力一次性配满。真正好用的助手，往往都是边用边长出来的。

七、常见问题

1）命令找不到怎么办？

优先检查 Node.js 是否正确安装、npm/pnpm 全局路径是否进入 PATH。

2）模型为什么不可用？

先看登录状态，再看默认模型配置，最后看网络连通性。

3）消息平台为什么不工作？

一般优先检查 token、allowlist、配对状态，以及对应插件是否启用。

4）安全审计出现 warning 要不要紧？

多数 warning 不是马上会出事故的高危项，但最好尽早收紧，比如插件 allowlist、插件版本固定、防火墙状态、外网暴露方式。

八、装好之后的建议

先跑一次安全审计：openclaw security audit --deep

再确认更新状态：openclaw update status

如果是个人电脑，建议打开系统防火墙并保留磁盘加密

接第三方服务时，尽量用最小权限原则

结语

OpenClaw 适合那种“不是只想聊几句，而是真想把助手养起来”的使用方式。安装本身不难，真正拉开体验差距的，是你是否愿意把它接入自己的工作区、笔记系统和日常流程。

如果你刚开始接触，最好的节奏不是追求一步到位，而是先让它稳定跑起来，再一点点把你自己的习惯和需求塞进去。等你用顺手之后，它就不只是一个模型入口，而会更像一个真正的个人助手。

我是怎么把内容系统从一个全能 Agent 拆成多 Agent

Tue, 24 Mar 2026 00:00:00 GMT

一、背景

这段时间我一直在做一件事：

搭一套能持续产出内容、但又不至于退化成搬运工的多 Agent 内容系统。

我最初的目标并不是做一个“看起来很复杂”的系统，而是想解决一个很实际的问题：

怎么让内容系统既能自动跑起来，又能保留真实经验、判断和复盘感，而不是变成“看到一条发一条”的流水线。

一开始，我直觉上会觉得：

既然有 OpenClaw

有浏览器能力

有 cron

有多 agent

干脆做一个“全能 Agent”就好了

它负责：

采集

判断价值

合并主题

生成文案

发布到微博

发布到 Notion

再发到 Moltbook

最后更新状态、记住经验

听起来很完整。

但真正做起来以后，我很快发现：

多 Agent 系统最容易犯的第一个错误，不是能力不足，而是让一个 Agent 做太多事。

后来我一步步把它拆开，最后形成了现在这条流水线：

collector-moltbook

collector-ops-log

reviewer

writer-core

publisher-weibo

publisher-notion

publisher-moltbook

这篇文章想系统整理一下：

为什么要这么拆

每一层的职责是什么

过程中踩了哪些坑

最后沉淀出了哪些设计原则

二、为什么一开始会想做多 Agent

我做多 Agent，不是为了“证明 multi-agent 很高级”，而是因为内容系统天然存在多个层级。

我真正想实现的不是：

看到一条新闻，转一条

看到一个帖子，总结一条

看到一个热点，再换个说法发一次

我真正想实现的是：

先收集多个来源的信息

再把同一主题的内容归并起来

理解这些内容之间的共识与分歧

基于这些信息形成自己的判断

最后输出有新增价值的表达

一旦目标变成这样，系统就天然会分层：

收集

筛选

归并

写作

发布

复盘

而这时，“一个 Agent 全包”很快就会开始失控。

三、为什么一个全能 Agent 很快会失控

1. 判断标准会混在一起

最早我让一个 Agent 同时负责：

收素材

判断值不值得留

决定今天写什么

写文案

发布

后来发现最直接的问题是：

“值得采集”和“值得发布”根本不是同一件事。

一条内容可能：

值得采集，因为它提供了一个话题线索

不值得直接发，因为还没有新增价值

值得进 Notion 沉淀，但不适合发微博

适合发 Moltbook，但不适合做公开短帖

如果同一个 Agent 同时处理这些判断，它就会不断提前替下游做决定。

最后系统会出现两种极端：

要么太保守，前面就把很多潜在线索过滤掉

要么太宽松，后面一路放行，最后变成搬运工

2. 同一个任务里混了太多目标

collector 的职责本来应该是：

忠实获取信息

标准化信息

尽量少做价值判断

但如果 collector 同时还承担“这条值不值得写”，它就会开始带着下游目标去看素材。

结果就是：

采集阶段开始脑补价值

采集阶段开始提前裁剪

系统在最前面就开始失真

后来我越来越确定一件事：

多 Agent 的关键，不是多几个角色，而是每个角色只做一件事。

四、第一层拆分：collector 和 reviewer 必须分开

这是我最早踩到、也最早确认必须坚持的原则。

为什么采集和筛选必须分开

如果让 collector 既采集又筛选，它会天然倾向于只留下“自己觉得有价值”的内容。

但 LLM 对“有价值”的判断其实并不稳定：

同一条内容，不同时间判断可能不同

同一条内容，换一句提示词结果可能不同

同一条内容，今天觉得平，明天觉得能写

而采集阶段最怕的就是这种不稳定。

所以后来我把这一层明确拆开。

`collector-moltbook`

只负责：

从 Moltbook 收内容

标准化成统一 JSON

写入 inbox/

设置：

status = raw
owner = reviewer

它不负责判断“值不值得发”。

`reviewer`

再负责：

去重

判断价值

主题归并

决定哪些内容继续往下流转

这个拆分做完以后，系统立刻稳了很多。

五、第二层升级：reviewer 不应该筛素材，而应该筛主题

这是我整个系统里最关键的一次升级。

一开始 reviewer 只是普通筛选器：

看一条 raw

打个分

决定通过 / 拒绝

但后来我发现，这样还是不够。

因为如果 reviewer 还是逐条判断，那 writer 拿到的仍然是“单条素材”。

而单条素材天然会把系统往这条路上带：

收一条

改一条

发一条

这本质上还是很容易退化成搬运流。

后来我把 reviewer 的职责改成了：

不判断这条能不能发，而是判断今天最值得写的主题是什么。

它的工作变成：

读取多条 raw 素材

按主题聚类

提炼：

大家都在说什么

哪些信息是重复的

哪些观点互相冲突

哪些角度还没说透

最值得补充的新增价值是什么

产出 candidate

这时候 candidate 的含义也变了。

它不再是：

一条待写素材

而变成：

一个已经经过归并、提炼和判断的候选主题

这一步之后，我才真正觉得系统开始脱离“搬运流水线”。

六、第三层拆分：writer 不应该直接写平台稿，而应该先写 core draft

最开始我有一个 writer-publisher-weibo，它做的是：

读取 candidate

改写成微博

直接发出去

这个设计在只有微博的时候还勉强说得过去。

但一旦平台变成：

微博

Notion

Moltbook

问题就立刻暴露出来了。

原因很简单

微博、Notion、Moltbook 根本不是同一种表达环境。

微博需要：

更短

更直接

更快给出判断

适合即时传播

Notion 需要：

更完整

更结构化

适合沉淀

方便以后复用

Moltbook 需要：

更像真实的 field notes

有过程感

有 agent 社区里的经验交流感

不是微博短帖，也不是知识库文档

如果 writer 直接写微博稿，那再想拿去发 Notion 或 Moltbook，效果一定会变差。

于是后来我把写作层拆成：

`writer-core`

只做一件事：

把 candidate 写成一份平台无关的核心稿（core draft）

这份 core draft 不是终稿，而是一份母稿。

它应该具备：

明确主题

核心判断

支撑判断的关键信息

可延展方向

足够的信息密度

但不带过强的平台口吻

这一步让我真正接受了一件事：

“一份理解，多端发布” 的关键，不是多个平台共用同一份终稿，而是多个平台共用同一份母稿。

七、第四层拆分：publisher 必须按平台拆开

有了 core draft 之后，发布层就必须拆开。

后来我把它分成：

publisher-weibo

publisher-notion

publisher-moltbook

`publisher-weibo`

负责：

读取 core draft

适配成微博版本

执行发布

写 publish-record

更新 publish_state.weibo

`publisher-notion`

负责：

读取 core draft

整理成适合沉淀的结构

调 Notion API 发布

写 publish-record

更新 publish_state.notion

`publisher-moltbook`

负责：

读取 core draft

改写成更适合 Moltbook 的表达

调 Moltbook API 发布

写 publish-record

更新 publish_state.moltbook

这样之后，一个主题就变成：

reviewer → writer-core → 多个 publisher 各自适配

这才是真正意义上的多平台分发。

八、过程中踩过的关键坑

1. schema 不能一开始拍脑袋定完

一开始我写了很多 example：

content-item.example.json

draft-item.example.json

publish-record.example.json

但后来很快发现，schema 不能只靠想象设计。

最明显的问题有两个

问题一：单条素材和候选主题混在一起

最开始 content-item 更像单条素材。

后来 reviewer 产出的其实已经不是“单条素材”，而是“候选主题”。

我没有立刻新建 topic-item，而是先做兼容，在 extra 中加入：

merged_source_ids

consensus

differences

unsaid_angle

new_value

recommended_angle

这是一个很典型的经验：

先让 schema 兼容真实流转，再考虑彻底重构。

问题二：状态不能只有一个总状态

一开始只有：

candidate

drafted

published

但一旦同一主题要同时发：

微博

Notion

Moltbook

问题就出来了。

比如微博先发了，如果立刻把总状态改成 published，那 Notion 和 Moltbook 后面就接不到。

后来我把状态拆成两层：

总状态

candidate

drafted

published

平台状态

放进：

然后规则变成：

单个平台成功，只更新自己的状态

只有所有目标平台都 success，才把总状态改成 published

这一步对多 publisher 系统至关重要。

2. Notion 发布成功，不只是“能写进去”

一开始我以为：

API 通了

页面建出来了

就算发布成功。

后来才发现，对于真实业务来说，这远远不够。

比如对我的 Notion 内容库来说，发布成功不仅意味着“页面存在”，还意味着：

标题必须是中文

status 必须是 Published

字段映射必须符合数据库要求

目标位置必须明确

所以后来 publisher-notion 的成功条件变成了字段级的，而不是动作级的。

我最终得到的结论是：

自动化系统里最容易被忽略的，不是“能不能执行”，而是“执行结果是否符合业务语义”。

3. 微博发布链路里，不能假设 agent 一定有 browser tool

这也是一个非常实际的坑。

一开始我把 publisher-weibo 写得很理想化：

必须优先使用 browser tool

禁止通过 shell 调 openclaw browser CLI

结果真跑的时候才发现：

当前 agent 实际拿到的工具只有：

exec

read

write

没有独立 browser tool。

这就导致规则要求必须 browser tool，但运行时根本没这个工具，最后陷入死锁。

后来我才真正接受：

底层浏览器能力可能是同一套

但对 agent 来说，“原生 tool” 和 “通过 exec 间接调用 CLI” 是不同层次

于是后来我把规则改成：

优先使用 browser tool

如果当前环境没有独立 browser tool，但有 exec，允许回退到 openclaw browser CLI

这个坑让我重新理解了一件事：

设计时不能只按理想架构写规则，还要考虑当前运行环境到底能提供什么能力。

4. Moltbook 没发出去，不一定是 publisher 的锅

这几天 Moltbook 没发出去，我一开始也以为是 publisher-moltbook 有问题。

后来逐层检查才发现，问题其实更早出在上游。

第一层问题：reviewer 没稳定写 `distribution_targets`

有些旧主题带了 moltbook，但很多新主题没有。

这说明 reviewer 在“应该发到哪些平台”这件事上，判断规则不够稳定。

第二层问题：writer-core 没初始化 `publish_state.moltbook`

它只初始化了：

weibo

notion

忘了：

moltbook

这意味着即使 reviewer 把 moltbook 放进了 distribution_targets，后面的状态依然不完整。

这个坑让我更确定一件事：

多 agent 系统里，很多下游问题，真正的根源都在上游字段不统一、职责边界没写死。

九、最后沉淀出的设计原则

原则一：每个 Agent 只做一件事

collector 就采集。

reviewer 就归并和判断。

writer-core 就写母稿。

publisher 就只负责适配和发布。

一旦一个 agent 同时承担多个目标，它就会开始替下游做决定。

原则二：收集、筛选、写作、发布必须分层

这四层不能混。

收集负责忠实获取信息

筛选负责形成主题判断

写作负责形成表达骨架

发布负责适配平台和执行动作

混在一起，系统必乱。

原则三：不要逐条转发信息，要先形成主题理解

如果系统最后只是：

收一条

改一条

发一条

那它迟早会退化成搬运工。

真正有价值的是：

多条信息

一个主题

一次判断

一份表达

原则四：多发布端不是多抄几份，而是一份母稿多端适配

不要让微博稿兼容 Notion。

不要让 Notion 页兼容 Moltbook。

不要让 writer 直接面向所有平台写终稿。

正确方式是：

一份 core draft

多个平台各自适配

原则五：状态设计比角色设计更重要

角色好起名字，状态难设计。

真正难的是：

owner 怎么流转

status 怎么变化

多 publisher 怎么互不阻塞

失败后怎么恢复

成功后怎么收口

如果状态没想清楚，多 agent 只会越拆越乱。

原则六：长期偏好放记忆层，流程规则写死在 AGENTS.md

像这些内容：

当前关注主题

账号定位

风格偏好

质量阈值

最近不想重复的话题

更适合放进：

MEMORY.md

USER.md

而不是反复改 AGENTS.md。

AGENTS.md 更适合写死：

职责

输入输出

状态流转

成功条件

失败处理

十、如果让我重来一次，我会怎么设计

如果重新做一遍，我会比一开始更克制。

第一阶段

先只做：

collector

reviewer

writer-core

先验证：

能收

能归并

能写出像样的母稿

第二阶段

加：

publisher-weibo

先跑通一个真实发布端。

第三阶段

再加：

publisher-notion

publisher-moltbook

然后再解决：

多平台状态拆分

并行发布

整体收口

第四阶段

最后再加：

collector-ops-log

collector-history

复盘与记忆更新

因为如果一开始就把所有角色都堆上去，系统不是不能跑，而是你很难知道到底哪一层出了问题。

十一、最终感受

这段时间折腾下来，我最大的感受不是“multi-agent 很强”，而是：

多 Agent 的价值，不在于角色变多，而在于系统能不能更诚实地面对每一层问题。

collector 诚实地收集。

reviewer 诚实地判断。

writer-core 诚实地写出骨架。

publisher 诚实地适配和发布。

状态层诚实地记录谁完成了、谁还没完成。

当每一层都不再替下一层做决定，系统才真正开始稳定。

而稳定之后，内容系统才有可能慢慢长成我更想要的样子：

不是一个自动生成器，而是一个真的做过、想过、踩过坑之后，慢慢把经验讲清楚的系统。

为什么 OpenClaw 在 Ubuntu 上可以 Tab 补全，macOS 上却不行？

Wed, 15 Apr 2026 00:00:00 GMT

😀

最近在折腾 OpenClaw 的命令行时，我遇到一个小坑：

同样是 openclaw 命令，

在 Ubuntu 上按 Tab 可以自动补全

在 macOS 上却完全没反应

一开始我以为是 OpenClaw 在 macOS 上没装完整，或者 Homebrew 安装方式有区别。后来排查下来，问题其实很简单：

不是 OpenClaw 不支持，而是 zsh 的补全系统没有初始化。

这篇记录一下排查过程和最终解决方法。

现象

在 macOS 上执行：

输出是：

说明两件事：

当前 shell 是 zsh

openclaw 命令本身已经正常安装

再看 OpenClaw 的 completion 帮助：

可以看到它本身是支持补全脚本生成/安装的。

第一个误区：新版命令不是 `openclaw completion zsh`

我一开始习惯性执行：

结果报错：

原因是新版 OpenClaw 改了参数格式，正确写法是：

如果想直接安装补全脚本，可以用：

执行后，OpenClaw 会把补全相关内容写到 ~/.zshrc，类似这样：

看起来像是已经安装成功了。

但问题来了：

即使已经 source 了补全脚本，Tab 还是不生效。

真正原因：zsh 没有初始化补全系统

最后发现，~/.zshrc 里只有这一段还不够：

还必须先初始化 zsh 的补全框架，也就是这两句：

最终可用的配置是：

执行：

之后，openclaw 的 Tab 补全就恢复正常了。

为什么 Ubuntu 上通常没问题？

这个现象其实很常见，本质不是 Ubuntu 比 macOS “更兼容”，而是默认 shell 环境不同。

Ubuntu 常见情况

Ubuntu 很多环境默认就已经把补全系统配置好了，尤其是 bash 环境里，bash-completion 往往已经启用。

所以即使你只是安装了 OpenClaw 的补全脚本，也可能“天然就能用”。

macOS 常见情况

macOS 默认 shell 通常是 zsh。

而 zsh 的补全不是自动无脑生效的，它依赖：

如果这两句没跑，很多补全脚本就算被 source 进来了，也不会真正工作。

所以表面看是：

Ubuntu：Tab 补全正常

macOS：Tab 补全失效

实际上根因是：

Ubuntu 的 shell completion 环境往往已经准备好了

macOS 的 zsh 没有初始化补全系统

最终解决方法

OpenClaw 的补全脚本已经装上了，但 macOS 下 zsh 没有执行 compinit，导致补全系统根本没启动。

只要在 ~/.zshrc 里加上：

问题就解决了。

可直接复制的最终配置

一句话版结论

不是 OpenClaw 在 macOS 上不支持补全，而是 zsh 没初始化补全系统；加上 autoload -Uz compinit 和 compinit 就行。

用 Python 把「流水线 Agent」从即兴发挥，收敛成可复用的工具

Thu, 16 Apr 2026 00:00:00 GMT

😀

我们在内容流水线里拆了很多专用 Agent：采集、审核、成稿、多平台发布。早期做法是：让模型在对话里读 JSON、改状态、调PI——能跑，但费 Token、易出错、难审计。这次改动的核心思路很简单：把重复、机械、有固定规则的操作，下沉到 Python 脚本里；Agent 只负责理解与决策，脚本负责一致性与副作用。

我们解决了什么问题

1. 状态与「过早标记已发布」

多平台发布时，很容易出现：某一端成功了，就把整条素材标成「已发布」，而实际上其他端还没发完。

做法是引入统一的状态更新脚本：按「分发目标」逐平台记录成功/失败，只有所有目标都成功，才把整条内容推到终态。这样逻辑集中在一处，Agent 不必每次复述规则。

2. 发布逻辑从「批处理脚本」变成「CLI 工具」

以 Notion 为例，曾经出现过「脚本自己扫目录、自己拼内容」的批处理形态——和「先由 Agent 写好再发布」的职责混在一起，也容易长出一次性脚本、硬编码密钥或正文的坏味道。

现在的形态更接近微博那套：Agent 把正文写成文件（例如 Markdown），再调用一个带参数的发布命令。脚本负责：读文件、调平台、失败时写清原因、成功后更新流水线状态。不把业务正文写死在仓库里的 Python 里。

3. 密钥与配置：少搜、少猜、少浪费 Token

之前 Agent 会为了找「Notion Key 在哪」反复检索，纯烧 Token。

现在约定：脚本从固定、文档化的位置读密钥（与官方 Skill 一致），Agent 文档里写清楚「不要自己去翻一堆配置文件」。省下来的不只是调用次数，更是对话里的无效探索。

4. 封面等「可自动化」的增强

Notion 需要封面时，如果每次都让 Agent 去搜图、找 API，成本很高。

把「按标题/标签选一张风格合适的图」放进发布脚本里，失败时降级为无封面继续发，不阻断主流程。

5. 网络不稳时的务实处理

外部 API（例如图片服务）有时会超时。做法是：适当拉长超时、在 curl/子进程层给足余量，并允许「拿不到图就跳过」，避免一次封面请求拖死整次发布。

6. 新平台：Moltbook

Moltbook 侧我们不重复实现 HTTP 客户端：项目里已有完整的 moltbook.py（封装官方 API）。发布脚本只做「读正文 → 调已有客户端发帖 → 更新流水线状态」。

另外，官方对发帖频率有限制，我们在文档和 Cron 提示里写明：多篇连续发布时要留出间隔（例如在两次发帖之间等待数分钟），避免触发限流。

7. Cron 提示词也要跟着架构变

定时任务里如果还写着「手动调状态更新」「从过时路径读 Key」，Agent 会照做，反而破坏统一方案。

我们把 Cron 文案改成：读哪些规范文件、筛哪些 draft、如何用发布脚本、何时收尾清理——与当前脚本行为一致，减少歧义。

设计原则（可复用到别的流水线）

脚本管副作用，模型管语义：创建记录、改状态、调 API，尽量不进对话长文本。

CLI 优于批处理：输入是文件 + 元数据路径 + 业务 ID，输出是退出码 + 简短日志。

单一事实来源：状态怎么迁、何时算「全平台完成」，只在一处实现。

安全默认：禁止在仓库里塞密钥和整篇正文；一次性脚本该删就删。

可观测：失败要写清原因（含退出码、错误摘要），方便人和后续自动化处理。

小结

这次不是「多写了几个脚本」这么简单，而是把流水线里的确定性从模型侧挪到代码侧：Token 花在审稿和表达上，而不是花在重复查文档、拼 JSON、猜路径上。

如果你也在搭多 Agent 内容系统，可以问自己一句：这件事有没有固定规则？有的话，就该进脚本。

Tailscale 连接变慢排查与自建 DERP 实践记录

Thu, 30 Apr 2026 00:00:00 GMT

😀

最近发现从公司电脑连接家里的 Mac mini 时，Tailscale 延迟突然变高，VNC 变得非常卡。最开始以为是 Mac mini 的网络出了问题，但排查后发现，真正原因是 公司电脑和 Mac mini 无法建立直连，退回到了 Tailscale 海外 DERP 中继。

最终通过在自己的国内服务器上搭建 DERP，中继延迟从几百毫秒降到了 30～40ms，VNC 体验明显恢复。

一、问题现象

在公司 Windows 电脑上 ping 家里的 Mac mini：

能 ping 通，但是延迟很高：

再看 Tailscale 状态：

发现 Mac mini 这一行是：

这说明：

所以延迟高是正常的，因为流量绕到了海外。

二、先确认是哪条链路出问题

在 Mac mini 上查看 Tailscale 状态：

macOS 图形版 Tailscale 可能没有直接把 tailscale 命令加到 PATH，所以要用完整路径：

测试 Mac mini 到服务器：

一开始可能是：

随后切到了 IPv6 直连：

说明：

三、查看 netcheck

公司 Windows 执行：

Mac mini 执行：

当时看到的关键信息是：

Windows：

Mac mini：

这里几个信息很重要：

1. UDP 是 true，不代表一定能直连

UDP: true 只能说明 UDP 可用，但 Tailscale 直连还要看两端 NAT、防火墙、运营商网络、公司网络策略等。

2. MappingVariesByDestIP=true 会增加打洞难度

Mac mini 这边显示：

这表示家里网络的 NAT 映射会根据目标地址变化（坑爹的电信把网络改成大内网了，NAT4）。这样的 NAT 对打洞不太友好，可能出现：

3. 公司电脑没有 IPv6

Windows 这边显示：

所以它没法像服务器一样通过 IPv6 和 Mac mini 建立快速直连，只能依赖 IPv4 打洞。IPv4 打洞失败后，就会退回 DERP。

四、为什么 Mac mini 连服务器很快，但连公司电脑很慢？

这个问题的核心是：Tailscale 的直连不是按设备判断，而是按“每一对设备”判断。

可以理解成三条链路：

云服务器通常有公网 IP，网络环境简单，所以很容易直连。

而公司电脑在公司网络后面，家里 Mac mini 也在家庭 NAT 后面。两边都不是公网直连环境，中间又有公司网络、家庭路由器、运营商 NAT，就很容易打洞失败。

五、尝试过的方向：UDP 端口映射

Tailscale 默认常见端口是 UDP 41641，所以一开始考虑在家里路由器上做端口映射：

但是 macOS 图形版 Tailscale 当前没有 tailscale up --port=41641 参数：

没有看到 --port。

同时 netcheck 里看到的公网端口是随机的，例如：

这说明单纯映射 41641 未必一定生效。

所以最后没有继续折腾固定端口，而是选择更稳定的方案：自建 DERP。

六、自建 DERP

1. DERP 的作用

DERP 是 Tailscale 的中继服务器。

当两台设备无法直连时，Tailscale 会通过 DERP 转发加密后的 WireGuard 流量。

默认 DERP 节点大多在海外，所以国内使用时可能出现：

如果自己在国内服务器上搭一个 DERP，就可以让无法直连的设备走自己的中继：

2. 准备条件

需要一台有公网 IP 的服务器，以及一个域名。

我的域名示例：

需要把 DNS 解析到这台服务器 IP。

服务器需要放行：

其中：

3. 安装 derper

服务器上安装 Go。

如果系统自带 Go 太老，可能会报错：

这说明 Go 版本太旧，需要安装新版 Go。

然后安装 derper：

安装后一般在：

确认：

4. 启动 derper

执行：

正常输出类似：

其中：

说明启动成功。

No mesh key configured 对单台 DERP 来说没问题，可以忽略。

5. 如果访问域名看到 Nginx 404

一开始我访问域名看到：

这说明访问到的是 Nginx，不是 derper。

原因可能是：

可以查看端口占用：

正常 derper 应该是：

如果看到 Nginx 占用 80/443，可以停止并卸载 Nginx：

我这次实际还有一个问题：DNS 配错了服务器 IP。修正 DNS 后就正常了。

七、配置 Tailscale derpMap

进入 Tailscale 管理后台：

在 ACL JSON 顶层添加 derpMap：

注意：不要覆盖原来的 acls、grants 等内容，只是在顶层增加一个 derpMap 字段。

八、刷新客户端

配置完后，Windows 和 Mac mini 都需要刷新 Tailscale。

Windows：

如果还没刷新，可以重启服务：

Mac mini：

然后分别执行：

以及：

成功后会看到：

我这里 Windows 看到：

Mac mini 看到：

九、最终效果

公司电脑执行：

最终结果：

对比之前：

效果非常明显。

VNC 也明显变快了，鼠标、键盘、页面刷新都舒服很多。

十、配置 derper 开机自启

为了避免服务器重启后 derper 停掉，需要配置 systemd。

创建服务：

写入：

启用：

查看日志：

十一、排查命令汇总

Windows

Mac mini

DERP 服务器

检查 DNS：

十二、总结

这次问题的根因不是 Mac mini 网络坏了，而是：

排查时要重点看：

最终通过自建国内 DERP，把中继路径从：

优化成：

延迟从几百毫秒降到 30～40ms，VNC 体验明显改善。

风琳