风琳 | 一个NotionNext搭建的博客

我们把内容流水线里重复、机械的操作（读草稿、调平台 API、更新发布状态、多平台一致性判断等）从「全靠 Agent 在对话里完成」收敛成 Python CLI 脚本：Agent 负责理解与成稿，脚本负责规则与副作用。这样减少了无效检索与拼 JSON 的 Token 消耗，也避免了单平台成功就误标「已发布」、以及临时脚本硬编码密钥等问题。Notion / 微博 / Moltbook 等发布路径统一走「正文进文件 → 一条命令发布 → 自动更新状态」；Moltbook 复用现有 API 封装并注意发帖间隔；Cron 与文档与脚本行为对齐。核心收获：确定性进代码，创造性留给模型。

OpenClaw

content-pipeline

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

在 Ubuntu 上，OpenClaw 的 Tab 自动补全可以正常工作，但在 macOS 上却没有反应。排查后发现，问题并不在 OpenClaw 本身，而在 shell 环境：macOS 默认使用 zsh，而 zsh 的补全系统如果没有执行 compinit，即使已经加载了 OpenClaw 的补全脚本，Tab 补全也不会真正生效。新版 OpenClaw 也调整了 completion 命令的用法，需要通过 --shell zsh 这样的参数形式来生成或安装补全脚本。最终只要在 ~/.zshrc 中补上 autoload -Uz compinit 和 compinit，再保留 OpenClaw 的补全脚本加载语句，问题就解决了。本质上，这不是 OpenClaw 在 macOS 上不支持补全，而是 zsh 没有初始化自己的补全框架。

OpenClaw

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

复盘一次真实的 AI 内容自动发布故障：表面现象是微博没有按时发出，真正根因却不是 cron、不是内容、也不是平台风控，而是 browser 插件未被加载，导致 publisher-weibo 在运行时失去真实发布能力并静默停在 pending。

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

这篇文章系统总结了我把内容系统从“一个全能 Agent”逐步拆分成多 Agent 流水线的过程。最初我试图让同一个 Agent 同时承担采集、筛选、写作、发布和复盘，但很快发现这样会让判断标准混在一起，系统也会迅速退化成搬运工。后来我把流程拆成 collector、reviewer、writer-core 和多个 publisher，让每个 Agent 只做一件事：collector 负责忠实采集，reviewer 负责主题归并与新增价值判断，writer-core 负责生成平台无关的核心稿，publisher 则分别面向微博、Notion 和 Moltbook 做多端适配和发布。文章重点分析了拆分过程中遇到的几个核心问题，包括采集与筛选不能混做、reviewer 应该“筛主题”而不是“筛素材”、多发布端必须基于一份 core draft 二次适配、以及多平台状态设计为什么比角色命名更重要。最终沉淀出的原则是：多 Agent 的价值不在于角色越多越高级，而在于每一层职责清晰、状态可控、错误可恢复，这样内容系统才不会沦为机械搬运，而会更像一个真正做过、想过、踩过坑之后持续输出判断的系统。

OpenClaw

多 Agent 协作

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

一篇面向新手的 OpenClaw 安装入门指南，包含安装前准备、初始化、登录授权、常见配置与排错建议。

OpenClaw

AI助手

安装教程

如何选择适合你的杀毒软件？—Windows 11 和 Microsoft 365 环境下的最佳选择

在使用 Windows 11 和 Microsoft 365 的环境下，Microsoft Defender 是最适合的杀毒软件选择。它与操作系统深度集成，提供强大的勒索软件防护、实时监控和智能拦截功能，不会干扰正常工作流程。相比其他第三方杀毒软件，Defender 对 NAS 的支持更为稳定，且无误拦问题。此外，作为 Microsoft 365 用户，Defender 已包含在系统中，避免了额外的付费开销。通过启用勒索软件防护、受控文件夹访问和 OneDrive 文件历史记录等功能，用户可以有效保护公司资料，确保数据安全。

卡巴斯基

Microsoft Defender

如何选择适合你的杀毒软件？—Windows 11 和 Microsoft 365 环境下的最佳选择

家庭网络公网入口解决方案：使用 FRP 和云服务器进行安全反向代理

本文介绍了如何通过 FRP 和云服务器构建一个稳定且安全的家庭网络公网入口。方案通过 FRP 反向隧道将家庭内网服务暴露到云端，并通过 Nginx 进行反向代理。适合需要 RDP（Windows 远程桌面）和 MySQL 等 TCP 服务的用户，同时保持极高的控制性和安全性，解决了公司网络限制带来的挑战。

FRP

如何实现家庭网络的稳定远程访问：基于 Cloudflare Tunnel 和 Tailscale 的无公网 IPv4 方案

本文介绍了如何通过 Cloudflare Tunnel 和 Tailscale 构建一个不依赖公网 IPv4的稳定家庭远程访问方案。通过 Cloudflare Tunnel 处理 Web 服务（如 Home Assistant、NAS 管理界面），并用 Tailscale 实现安全、低延迟的远程维护。适合需要稳定 Web 访问和偶尔远程维护的家庭网络环境，避免公网 IP 和端口映射带来的安全隐患。

Tailscale

Cloudflare