如何用 OpenClaw + 本地模型搭建一个可复用的公众号发布 Agent

这篇文章要解决一个很具体的问题：

如何在 OpenClaw 里，用本地模型而不是使用云端大模型的 API，搭一个能写公众号文章、保存 Markdown 草稿、再通过微信 API 进入公众号草稿箱的发布 Agent。

这里说的“能用”，不是指 Demo 级别的“看起来像能用”，而是指下面这条链路已经被真实跑通，而且已经连续成功多次：

聊天指令
  -> 自建 content-publisher agent
  -> 生成公众号文章
  -> 保存到 articles/*.md
  -> 调用 baoyu-post-to-wechat
  -> 进入微信公众号草稿箱

这套方案有三个核心前提：

• 使用的是 OpenClaw + 自建 agent + baoyu-skills
• 使用的是本地模型

如果你想找的是“用最强 API 十分钟做一个聪明 Demo”，这篇文章不适合你。
如果你想搭的是“本地可控、可审计、可复用、能进真实工作流”的发布链路，这篇文章可以直接拿来做骨架。

一、运行环境基线

这套方案不是在云端完成的，运行基线是本地环境。

本文的参考环境如下：

• 电脑：Apple Silicon Mac
• 系统：macOS
• 本地模型运行所需软件：oMLX
• 实际使用模型：Qwen3.5-9B-MLX-4bit
• 工具：OpenClaw
• 发布能力 SKILLS：baoyu-skills
• 目标平台：微信公众号 API

这套方案里，oMLX 承担的是本地模型服务层，不是图片生成器，也不是发布脚本。它的职责是：

• 在 Mac 上提供本地模型推理
• 以 OpenAI-compatible 的方式对外暴露接口
• 作为 OpenClaw 背后的本地模型提供方

实际落地时，OpenClaw 不直接和某个“裸模型文件”对话，而是和 oMLX 提供的本地服务对话。
也就是说，模型层关系更准确的写法是：

OpenClaw
  -> oMLX
     -> 本地模型

如果你想复用这套方案，最低要满足下面这些条件：

• 一台 Apple Silicon Mac
• 本地启动好的 oMLX
• 一个可用的本地对话模型
• 已安装的 OpenClaw
• 已安装的 baoyu-skills
• 一个已经开通 API 能力的微信公众号

如果你不用 oMLX，理论上也可以换成其他 OpenAI-compatible 的本地模型服务；但本文分享的基线就是 Mac + oMLX + OpenClaw。

oMLX 和 Ollama 的差别，到底在哪里

如果只看“能不能在本地跑模型”，oMLX 和 Ollama 都能成立。
真正的差别不在“能不能跑”，而在官方定位的重心不同。

从官方 README 的写法看，oMLX 更像一个面向 Mac 和 Agent 场景的本地模型服务层；Ollama 更像一个通用本地模型运行器和 REST API 入口。

oMLX 官方首页一上来强调的是：

• optimized for your Mac
• continuous batching
• tiered KV caching
• managed directly from your menu bar

这说明它的重心不是“先把模型跑起来”，而是“怎么在 Mac 上把本地推理服务长期跑稳、跑顺”。

往下看它的官方能力说明，oMLX 进一步强调的是：

• Multi-Model Serving
  同一个服务里同时加载 LLM、VLM、embedding、reranker
• Admin Dashboard
  可以直接管理模型、聊天、下载、参数、性能测试
• OpenClaw / OpenCode / Codex integration
  管理面板里直接对接 Agent 工具
• OpenAI / Anthropic API compatibility
  不只是聊天接口兼容，还包括更多 Agent 常用接口
• Tool Calling & Structured Output
  对函数调用格式、工具调用输出、结构化结果有明确支持
• Mac 原生优化
  可以把 SSD 让你当内存使用，小内存电脑的福音

不扯别的，本人亲测，在 openclaw 中使用相同模型， Ollama 如果需要 1 分钟响应结果，而 oMLX 只需 10 秒。

这次方案里实际使用的本地模型是：

Qwen3.5-9B-MLX-4bit

选择这个模型，不是因为它是当前最强，而是因为它在我本机运行的成本、响应速度、中文写作能力和工具调用之间，给了一个更均衡的落点。对“内容生成 + skill 调度 + 微信公众号发布”这类任务来说，这种均衡比单纯追求模型上限更重要。

二、最短搭建步骤

如果你的目标是尽快照着搭出一条可用链路，建议按下面顺序来，不要跳步。

第一步：先把本地模型服务跑起来

先确认 oMLX 已经在 Mac 上正常运行，并且已经对外提供 OpenAI-compatible 接口。
这一层不需要先追求“大模型最强”，只需要满足两件事：

• OpenClaw 能连上 oMLX 提供的 OpenAI API
• 本地模型能稳定完成中文写作和基础工具调度

第二步：创建发布专用 agent

在 OpenClaw 里新建一个 agent，例如：

content-publisher

创建这个 agent 时，OpenClaw 会一并生成对应的 workspace。
例如这个 agent 的工作区可以是：

workspace-content-publisher/

这个 agent 只负责内容发布，不承担通用聊天、随手问答、代码执行等杂项任务。职责越单一，稳定性越高。
也不要把发稿规则混在通用聊天 agent 里。发布动作是外部真实动作，必须有单独 workspace 和单独契约。

第三步：安装并确认技能可见

至少确认下面这些 skills 在 OpenClaw 里是可见的：

• baoyu-post-to-wechat
• baoyu-format-markdown
• baoyu-markdown-to-html

如果 skill 只是存在于某个嵌套目录里，但 OpenClaw 没把它识别成顶层 skill，后面会出现“agent 明明应该会，实际上不会调用”的假象。

第四步：写好 agent 契约

至少准备这些文件：

• AGENTS.md
• SOUL.md
• USER.md
• MEMORY.md
• WECHAT_STYLE.md

其中最关键的是 AGENTS.md，必须写死下面这些规则：

• 先写文件，再发布
• 默认草稿，不直接外发
• 默认走 API
• API 失败不自动降级浏览器
• 缺前置条件就停并报错
• 不准空回复

第五步：配置微信发布默认参数

具体配置的详细解释可以去 baoyu-skills 查看

在 workspace 里准备：

.baoyu-skills/baoyu-post-to-wechat/EXTEND.md

最小可用内容：

default_theme: default
default_color: blue
default_publish_method: api
need_open_comment: 1
only_fans_can_comment: 0

这里最重要的一行是：

default_publish_method: api

它决定了整条主链路默认是 API，不是浏览器。

第六步：配置用户级密钥

准备用户级文件：

~/.baoyu-skills/.env

最小需要：

WECHAT_APP_ID=your_app_id
WECHAT_APP_SECRET=your_app_secret

同时确认微信公众号后台已经把当前出口 IP 加进 API 白名单。

第七步：准备默认封面图

在 workspace 里放一张默认封面，例如：

workspace-content-publisher/images/images.jpeg

然后把它作为默认兜底策略写入 agent 规则。
这样文章没显式封面时，也不会因为缺图而卡死。

第八步：给 WeChat API 加一层 workspace wrapper

不要让 agent 直接到 skill 仓库里乱猜脚本路径。
建议在 workspace 内准备一层统一入口：

.baoyu-skills/baoyu-post-to-wechat/scripts/wechat-api.ts

这层 wrapper 只做三件事：

• 固定执行入口
• 吸收常见错参
• 转发到真实的 baoyu-post-to-wechat 脚本

第九步：只做最小冒烟测试

第一次不要让 agent 同时做太多事。
建议只测下面这条链路：

1. 给一个主题
2. 生成公众号文章
3. 保存到 articles/*.md
4. 进入公众号草稿箱

先不要同时测：

• 自动配图
• 多平台同步
• 直接正式发布
• 批量发稿

把最小链路打通之后，再往上加。

三、为什么这套方案值得分享

在 Agent 领域，大家很容易高估模型能力，低估系统约束。

很多项目的默认路径都是：

• 先接一个最强云端模型
• 再给它接几个工具
• 然后在聊天里演示几轮
• 最后宣布“Agent 跑起来了”

但只要任务碰到真实发布、账号权限、平台 API、文件落盘、失败重试、结果审计，这种路径马上就会暴露问题。模型再强，也不会自动帮你解决：

• 技能目录有没有被系统正确加载
• 环境变量到底应该放在哪里
• 命令该怎么调用才不会跑偏
• 发布前到底要不要先落文件
• 失败时该不该自动降级到浏览器
• 缺封面图时要不要继续发
• 用户到底是在要“写稿”，还是“写稿并发草稿”

所以，这篇文章真正想分享的，不是“我们用本地模型也成功了”这句口号，而是：

在模型能力有限的情况下，怎样靠工程约束把一条真实发布链路做稳。

这个命题有三个实际价值。

1. 低成本

如果内容生产是高频任务，长期使用云端大模型会有持续成本。尤其是长文生成、反复改稿、工具调用、失败重试，这些都不是一次性支出。

2. 数据边界更清楚

公众号发布天然涉及草稿、标题、封面、账号、平台配置、甚至后续运营节奏。不是所有团队都愿意默认把这些环节交给第三方云端服务。

3. 方法可以复制

这套方案真正可迁移的是下面这些工程原则：

• 动作空间收窄
• 执行顺序固定
• 平台约束显性化
• 失败必须可诊断
• 发布边界必须保留人工确认

只要这几条成立，类似的方案不只可以用于公众号，也可以迁移到微博、X、内部知识库、邮件草稿、私有文档流转等场景。

四、最终方案长什么样

先给结论，再展开。

这套方案的最终结构分成四层：

OpenClaw
  -> 自建 content-publisher agent
     -> 文章风格规则
     -> 发布契约
     -> 输出保护
  -> baoyu-skills
     -> baoyu-post-to-wechat
     -> baoyu-format-markdown
     -> baoyu-markdown-to-html
  -> 微信公众号 API

每一层的职责都很明确。

1. OpenClaw：承载会话和 Agent 运行

OpenClaw 负责消息入口、会话、工具调用、Agent 工作区和技能发现。它不是这套方案的“写稿脑子”，而是执行框架。

2. content-publisher：自建的发布 Agent

content-publisher 不是 OpenClaw 自带的内置概念，而是这次在 OpenClaw 里新建的一个 agent。它的职责不是重新发明一套微信发布脚本，而是：

• 识别用户意图
• 选择正确的 skill
• 按固定顺序执行
• 维持“先草稿，后确认”的边界
• 在失败时给出明确反馈

3. baoyu-skills：真正完成平台动作

真正负责公众号发布的，不是 agent 自己临场拼出来的命令，而是 baoyu-post-to-wechat 这个现成 skill。类似地：

• baoyu-format-markdown 负责整理 Markdown
• baoyu-markdown-to-html 负责微信兼容 HTML
• baoyu-post-to-wechat 负责 API 发布或浏览器模式

4. 微信公众号 API：最终的草稿落点

当一篇文章真正进入草稿箱时，返回结果会是 API 的成功响应，而不是“看起来应该发成功了”的 UI 判断。

这件事很重要，因为平台层的成功和失败必须是可验证的。

五、为什么这套方案不用浏览器模式做主链路

一开始最自然的选择其实是浏览器模式。因为它看起来门槛低：

• 不一定要先配 API
• 不用先搞 AppID / AppSecret
• 只要能登录公众号后台，理论上就能让脚本帮你填草稿

但如果目标是“做一条长期可用的发布链路”，浏览器模式不是最优主链路。

原因很简单，它太依赖外部状态了：

• 登录态是否失效
• Chrome profile 是否正确
• 辅助功能权限是否放行
• 页面结构是否变化
• 管理员扫码是否超时
• 脚本是在“等待登录”还是“卡死”

浏览器模式不是不能用，而是不适合做默认路径。它更适合：

• 没有 API 凭证时的临时方案
• 首次冒烟测试
• 人工审核后手动点发布的流程

而如果目标是“聊天里一句话，稳定生成公众号草稿”，主链路应该尽量走 API。

所以这套方案最终定下了一个很明确的策略：

• 默认发布方式：API
• 默认结果：公众号草稿
• 禁止 API 失败后自动降级浏览器

这三条一旦写死，系统行为会稳定很多。

六、最小可复用目录结构

如果别人想复用这套方案，最有价值的不是一篇故事，而是一个最小目录骨架。

下面是这次落地后整理出来的最小结构：

workspace-content-publisher/
  AGENTS.md
  SOUL.md
  USER.md
  MEMORY.md
  WECHAT_STYLE.md
  WECHAT_API_PROMPT.md
  .baoyu-skills/
    .env                     # 可选：项目级覆盖
    baoyu-post-to-wechat/
      EXTEND.md
      scripts/
        wechat-api.ts        # workspace wrapper
  articles/
  images/
  output/
  memory/

除此之外，还有两个工作区之外的关键位置：

~/.agents/skills/
  baoyu-post-to-wechat/
  baoyu-format-markdown/
  baoyu-markdown-to-html/
  ...

~/.baoyu-skills/.env

这两个位置分别承担不同职责：

• ~/.agents/skills/：技能真实安装目录
• ~/.baoyu-skills/.env：用户级发布密钥

这个结构本身就体现了一个重要原则：

行为规则在 workspace，密钥在用户目录，执行能力在 skill 目录。

别把这三者混在一起。

七、这套方案真正依赖哪些文件

如果把“能否跑通”追到最细，核心其实只依赖 6 类文件。

1. AGENTS.md

这是 Agent 的执行契约，不是品牌文案。它至少要定义这些规则：

• 使用哪些 skill
• 默认发布策略是什么
• 先写文件还是先发稿
• 出错时是否允许自动降级
• 输出里禁止出现什么

一个可复用的最小版本，可以长这样：

## Mission

- Write WeChat articles from user topics
- Save canonical markdown to `articles/`
- Publish drafts via WeChat API only unless browser mode is explicitly requested

## Execution Rules

- Use installed skills instead of inventing new browser flows
- Always save markdown before calling the WeChat API
- Prefer `npx -y bun <absolute-script-path>`
- Do not call bare `bun`
- Do not guess script paths or env variable names

## Publishing Contract

- Draft first, confirm later
- If publish prerequisites are missing, stop and report the blocker
- Do not auto-fallback from API to browser

## Output Guard

- Never return an empty reply
- Never expose raw internal tool markup
- If a command fails, report the exact failure and stop

上面这段可以直接作为 AGENTS.md 的起步模板。

2. WECHAT_STYLE.md

这不是发布脚本配置，而是文章风格配置。它决定了 agent 写出来的内容像不像“能发的公众号稿”，而不是像一段 AI 八股文。

如果你的目标是做内容分发 agent，而不是单纯打通 API，这个文件必须单独存在。

至少应该定义：

写作要点：

• 口语化、故事感、有态度（不是 AI 八股文）
• 标题策略：悬念>结论，情感>理性
• 善用类比，让复杂的事简单化
• 数据支撑但不堆砌
• 核心观点怎么亮
• 副观点怎么展开
• 论证方式用哪些
• 情绪控制到什么程度
• 标题策略是什么
• 哪些表达明确禁止

3. EXTEND.md

这是 baoyu-post-to-wechat 的项目级默认配置。一个最小可用版本可以是：

default_theme: default
default_color: blue
default_publish_method: api
need_open_comment: 1
only_fans_can_comment: 0

如果目标是 API 主链路，default_publish_method 必须明确写成 api。

4. ~/.baoyu-skills/.env

用户级密钥建议放在这里，而不是散落在各个项目目录。

最小需要：

WECHAT_APP_ID=your_app_id
WECHAT_APP_SECRET=your_app_secret

注意，不需要手工维护 WECHAT_ACCESS_TOKEN。baoyu-post-to-wechat 的脚本会自己取 token。

5. articles/*.md

每一篇待发布文章必须先有一个真实 Markdown 文件。
这不是一个可选步骤，而是执行契约的一部分。

原因很简单：只要允许 agent 直接从“标题 + 摘要 + 想象中的正文”跳去发布，它就迟早会绕过文件落盘，导致调用错参、顺序混乱、结果不可审计。

6. 默认封面图

如果你的主链路走公众号文章 API，那封面图就不是优化项，而是前置条件。

这次方案里使用的做法是：

• 如果文章显式指定了封面图，优先使用文章自己的图
• 否则使用 workspace 内一张默认封面兜底

例如：

workspace-content-publisher/images/images.jpeg

八、核心执行链路：从一句话到公众号草稿

这条链路必须足够简单，才能让本地模型稳定执行。

最终采用的是下面这条固定顺序：

第一步：用户在聊天里提出请求

例如：

按理性洞察型写一篇不少于 1000 字的公众号文章，
先保存到 articles 目录，再用 API 模式发布到公众号草稿箱；
如果没有显式封面图，就使用默认封面；不要打开浏览器。

第二步：Agent 先生成文章并写入 articles/*.md

这个步骤完成后，应该已经能在本地看到一个真实文件。

如果这一步没发生，后面的发布都不应该继续。

第三步：Agent 调用固定的 WeChat API 入口

这里不要让 agent 自由发挥，而要把执行入口固定住。

这次最终稳定下来的方式是：

• 真实发布脚本来自 baoyu-post-to-wechat
• workspace 再包一层 wrapper
• agent 只调 wrapper，不直接猜真实 skill 路径

调用形态可以统一成：

npx -y bun /abs/workspace/.baoyu-skills/baoyu-post-to-wechat/scripts/wechat-api.ts \
  /abs/workspace/articles/example.md \
  --cover /abs/workspace/images/images.jpeg \
  --mode draft

第四步：API 返回明确结果

成功时应该返回：

• success: true
• media_id
• title

失败时应该返回真实阻塞原因，而不是模糊提示。

为什么需要一个 workspace wrapper

这套方案不是直接让 agent 去调 skill 自带脚本，而是在 workspace 里补了一层兼容包装。

这个脚本就在 workspace 里：

workspace-content-publisher/.baoyu-skills/baoyu-post-to-wechat/scripts/wechat-api.ts

而真正干活的主脚本仍然来自 baoyu-post-to-wechat：

~/.agents/skills/baoyu-skills/skills/baoyu-post-to-wechat/scripts/wechat-api.ts

这层 wrapper 不是重写发布逻辑，而是在真实脚本前面加一个统一入口和纠错层。

原因很现实：本地模型在命令拼装上并不稳定，它容易犯这些错：

• 用错脚本路径
• 调裸 bun
• 把 --markdown <file> 当成主输入
• 只传标题摘要，不传文件路径
• API 失败后自动切浏览器

最终做法不是继续放大模型自由度，而是补一层 wrapper，把最常见的命令错误统一吸收掉。

这层 wrapper 的职责不是重写微信发布逻辑，而是：

• 统一入口
• 规范参数
• 把非预期输入转成真实脚本能接受的格式

下面是一段精简后的实际逻辑示例：

import { spawnSync } from "node:child_process";
import path from "node:path";

const ACTUAL_SCRIPT =
  "/Users/user/.agents/skills/baoyu-skills/skills/baoyu-post-to-wechat/scripts/wechat-api.ts";

function normalizeArgs(argv: string[]): string[] {
  const forwarded: string[] = [];
  let fileArg = "";

  for (let i = 0; i < argv.length; i++) {
    const arg = argv[i]!;

    if ((arg === "--markdown" || arg === "--html") && argv[i + 1]) {
      fileArg = argv[++i]!;
      continue;
    }

    if (arg === "--api") continue;

    if (arg === "--mode") {
      if (argv[i + 1] && !argv[i + 1]!.startsWith("-")) i++;
      continue;
    }

    if (!arg.startsWith("-") && !fileArg) {
      fileArg = arg;
      continue;
    }

    forwarded.push(arg);
  }

  if (!fileArg) {
    console.error("Error: File path required");
    process.exit(1);
  }

  return [path.resolve(fileArg), ...forwarded];
}

const normalizedArgs = normalizeArgs(process.argv.slice(2));
spawnSync("npx", ["-y", "bun", ACTUAL_SCRIPT, ...normalizedArgs], {
  stdio: "inherit",
});

如果用一句大白话解释这层 wrapper，它的作用就是：

先把 agent 容易拼错的命令修正一遍，再转给真实发布脚本执行。

这件事特别重要。因为它代表一种非常实用的工程思想：

不要指望模型始终正确地下命令，要给它一个尽量不容易下错的入口。

九、我们实际踩过哪些坑，以及对应怎么修

下面这部分比“成功响应”更重要。因为真要复用这次的经验，最先碰到的不是 happy path，而是 error path。

1. Skill 明明在仓库里，Web 会话却看不见

现象

• baoyu-post-to-wechat 明明存在
• 但 web 里的 agent 似乎不会用
• 会去猜脚本路径，或者说 skill 不可用

根因

skill 放在嵌套目录里，OpenClaw 没把它当成顶层 skill 发现。

修法

把真正需要的 baoyu-* skills 提升到 ~/.agents/skills 下的顶层目录，并用 openclaw skills check --json 验证是否 eligible。

2. bun: command not found

现象

agent 明明知道要跑 TypeScript 脚本，但直接调裸 bun。

根因

这台机器没有把 bun 作为裸命令暴露在统一环境里。

修法

把所有 TypeScript skill 调用固定成：

npx -y bun <absolute-script-path>

不要给模型第二种写法。

3. File path required

现象

agent 直接拿标题、摘要、若干 flags 去调用 wechat-api.ts。

根因

没有把“先落文件、再发布”写成硬契约。

修法

在 Agent 规则里明确：

• 用户要求“写并发布”时
• 必须先生成 articles/*.md
• 再把这个真实文件路径作为第一个 positional 参数传给 API 脚本

4. invalid ip not in whitelist

现象

微信 API 认证失败，看起来像凭证错了。

根因

不是凭证问题，而是出口 IP 不在公众号后台白名单里。

修法

把当前出口 IP 加进微信公众平台的白名单。

这一步的启发是：

平台侧的安全设置，是系统真实依赖的一部分，不要把它当“部署后再看”的小事。

5. No cover image

现象

文章正文和标题都正常，发布却失败。

根因

公众号文章 API 需要封面图；没有封面图，脚本不会继续。

修法

加默认封面策略。
一篇文章如果没有显式封面，就统一落到默认图。

6. 会话空白、只 thinking、不继续回复

现象

• 聊天窗口里几分钟没反应
• 最后只有空白消息或内部 thinking

根因

Agent 没有被要求“必须给用户一个可见状态”。

修法

在 AGENTS.md 里写死：

• 不准空回复
• 不准只 thinking
• 不准把内部 tool markup 吐到可见消息里
• 每次工具调用之后，要么继续执行，要么明确汇报状态

7. API 失败后自动切浏览器

现象

明明已经配置了 API，agent 却擅自打开 Chrome。

根因

如果你直接说继续完成任务，agent 把“继续想办法完成任务”理解成“自动降级到浏览器模式”。

修法

把这条规则写死：

• 如果用户要求 API 模式
• 或项目默认就是 API 模式
• 那么 API 失败时必须直接报阻塞
• 不允许自动切浏览器

十、为什么本地小模型也能把这件事做成

这是整套方案的核心。

如果把问题问成“本地小模型能不能像最强云端模型一样自由规划、稳定调用几十个工具、顺手完成复杂多轮发布”，答案通常是不行。

但如果把问题改写成：

本地小模型能不能在一条被收窄、被约束、被显性规则保护的链路里，稳定完成公众号草稿发布？

答案是可以。

这套方案之所以成立，不是因为本地模型突然变强了，而是因为系统做了三件正确的事。

1. 把动作空间砍小

不是让 agent 想“怎么发布内容”，而是让它在固定边界内做：

• 只写公众号稿
• 只落 Markdown
• 只走 API
• 只发草稿
• 只调用固定入口

动作空间一旦变小，模型就更像调度器，而不是幻想家。

2. 把模糊目标翻译成显式契约

“帮我发公众号”太模糊。

“先写成 Markdown 文件，再调用固定 API 脚本生成草稿，缺封面时用默认图，失败时报告真实错误，不要打开浏览器”才是机器可执行的目标。

3. 把失败路径也产品化

一条可用链路，不是“永远不失败”的链路，而是“失败时知道自己卡在哪”的链路。

只要下面这些都明确了，系统就可恢复：

• 缺密钥
• 缺白名单
• 缺封面
• 命令错了
• skill 没加载
• 模型漂了

所以，本地模型能做成这件事，靠的是工程收口，而不是自由发挥。

十一 一些解释

1. Agent 契约模板

必须包含：

• 先写文件，再发布
• 默认草稿
• API 优先
• 缺前置条件就停
• 不准空回复
• 不准输出内部工具标记

2. 目录结构模板

把工作区目录、skill 目录、用户密钥目录分清。

3. .env.example

只保留变量名，不放真实值。

4. EXTEND.md 示例

把默认发布方式、评论策略、主题这些配置固定下来。

5. 默认封面策略

不要把封面图当成“后面再做”的功能项。对公众号文章 API 来说，它是必备配置。

6. 报错对照表

至少覆盖：skill 不可见、运行时错误、缺文件、缺白名单、缺封面、错误降级、模型输出漂移。

7. 组件之间的关系

• OpenClaw 是运行框架
• content-publisher 是这次自建的 agent
• baoyu-post-to-wechat 是公众号发布 skill
• oMLX 是本地模型服务层
• 微信 API 是最终草稿落点

8. 最小目录和配置位置

• workspace 目录里有哪些关键文件
• skill 的真实安装目录在哪里
• 用户级 .env 放在哪里
• EXTEND.md 放在哪里
• 默认封面图放在哪里
• Markdown 草稿放在哪里

9. 执行顺序

这套方案里真正有效的顺序是：

1. 本地模型服务先跑起来
2. 在 OpenClaw 里创建 agent
3. 确认 skills 可见
4. 写 agent 契约
5. 配微信默认参数
6. 配密钥和白名单
7. 配默认封面

十二、这套方案现在的边界在哪里

把话说满最容易，讲清边界更有价值。

截至目前，这套方案已经证明了下面这些事情：

• 本地模型可以驱动一个真实可用的公众号发布 Agent
• OpenClaw 适合作为 Agent 运行框架
• 自建 content-publisher agent 是可行路径
• baoyu-post-to-wechat 可以作为公众号 API 发布核心 skill
• 通过 wrapper 和规则约束，可以显著提升本地模型稳定性
• 连续多次发稿成功，说明主链路已经可用

但它也仍然有边界：

• 本地小模型在“长文生成 + 工具切换”上仍可能偶发漂移
• 一条坏掉的旧会话不值得硬救，应该重开新会话
• 这套方案目前主打公众号，不等于多平台链路已经全部同样稳定
• 图片生成能力还没有真正接进发布主链路

这不是缺点，而是正常工程状态。

真正危险的不是系统有边界，而是系统明明有边界，却假装自己没有。

十三、如果要继续往前走，下一步最值得做什么

这套方案已经把“写文 -> 落稿 -> 发公众号草稿”做通了。接下来最值得补的，不是更华丽的宣传，而是继续补齐两个非常实际的能力。

1. 本地图片生成接入

现在封面图已经有默认兜底，但还没有进入“根据文章自动生成封面”的阶段。

下一步可以做成：

文章主题
  -> 本地模型生成封面提示词
  -> 本地图像模型生成封面
  -> 默认写入文章 frontmatter 或发布参数

这样一来，发布链路会从“能发”升级到“发得完整”。

2. 多平台分发骨架

一旦公众号链路稳定，下一步就是把同一套方法迁移到：

• baoyu-post-to-weibo
• baoyu-post-to-x

但复制的不是“脚本名”，而是这次已经验证过的原则：

• 一个 canonical source
• 一个明确的发布契约
• 固定执行入口
• 明确失败反馈
• 人工确认边界

十四、结论：真正可复用的是规则、目录和执行纪律

如果要把整篇文章压缩成一句话，我会给出这个结论：

本地模型并不天然适合做开放式、全自动、自由规划的超级 Agent；但只要你把动作空间砍小、把执行顺序固定、把平台前置条件写清、把失败路径做成产品，它完全可以撑起一条真实可用的公众号发布链路。

这次方案最值得复用的，是下面这组工程纪律：

• 所有前置条件显性化
• 所有失败必须可诊断
• skill 负责执行，agent 负责决策，规则负责收口

当这几条同时成立时，本地小模型就不再只是一个“聊天能力一般的替代品”，而是可以被纳入真实工作流的执行核心。

这正是这套方案最值得分享的地方。

不是“我们终于把公众号发成功了”。

而是：

我们并没有因为 Token 的使用量而变得畏手畏脚，反而因为是本地模型，而可以肆无忌惮的乱试错。

本作品采用《CC 协议》，转载必须注明作者和本文链接