么罗博客

么罗博客 https://blog.gaomeluo.com/ zh-CN 不要问我搞么罗，我都不知道要搞么罗~ Mon, 22 Jun 2026 22:49:47 +0800 Mon, 22 Jun 2026 22:49:47 +0800 用GitHub Pages建站，如何绑定自定义域名 + 开启 HTTPS https://blog.gaomeluo.com/archives/GitHub-ssl/ https://blog.gaomeluo.com/archives/GitHub-ssl/ Mon, 22 Jun 2026 22:49:47 +0800 光山人

大家使用 GitHub Pagas 部署网站后，可能需要绑定自己的域名，其实这个操作非常简单。另外，GitHub Pages 还免费提供了 HTTPS，开启也很简单。
##一、DNS 配置
###顶级域名
在云服务厂商的 DNS 配置下，分别创建 IPV4 和 IPV6 的解析记录，指向 GitHub Pages 的 IP 地址，这个地址是不会变化的。

####IPV4
A记录，将域名解析指向 GitHub Pages 的 IP 地址。

185.199.108.153
    185.199.109.153
    185.199.110.153
    185.199.111.153

####IPV6
AAAA记录，请将顶点域指向 GitHub Pages 的 IP 地址。

2606:50c0:8000::153
    2606:50c0:8001::153
    2606:50c0:8002::153
    2606:50c0:8003::153

这里以阿里云为例：

![](https://image.gaomeluo.com/blog/2026/06/1782138995.png)

![](https://image.gaomeluo.com/blog/2026/06/1782139026.png)

###子域名
如果有多个网站，希望给子域名，如`www.example.com`、`blog.example.com`，需要创建将子域名指向`<user>.github.io`的CNAME记录。

![](https://image.gaomeluo.com/blog/2026/06/1782139503.png)

![](https://image.gaomeluo.com/blog/2026/06/1782139542.png)

##二、GitHub Pages 配置
在仓库的Setting->Pages里，在自定义域名里输入 DNS 配置好的域名，点击保存，GitHub 会自动进行 DNS 校验，这个过程需要一点时间。

![](https://image.gaomeluo.com/blog/2026/06/1782139657.png)

当校验通过以后，就可以勾选下面的强制开启 HTTPS ，没错，是不需要申请 SSL 证书的，GitHub 会自动帮申请（虽然是免费的 Let's Encrtpy ）。

再过一会儿，刷新一下，就可以看到个人站点部署完成了，可以进行访问。

##三、CNAME 配置
配置完后，以后要是更新代码，推送提交到 GitHub 的情况，这时候会发现 GitHub Pages 绑定的域名失效了。

这是因为页面配置自定义域名本质上是在部署目录下创建了一个名为CNAME的文件，里面存着自定义域名，每次 push 重新构建后会被覆盖，然后丢失。

因此需要保证在打包的输出目录，能够有 CNAME 文件，这样就不用每次打包都再指定一遍。

对于 vue 项目来说，只需要将 CNAME 文件放在 public 文件夹下即可，这样构建后 CNAME 文件会保留在产物的根目录下。

![](https://image.gaomeluo.com/blog/2026/06/1782139781.png)

]]> 0 https://blog.gaomeluo.com/archives/GitHub-ssl/#comments https://blog.gaomeluo.com/feed/archives/GitHub-ssl/ 在OpenClaw里，用大模型构建一个真正能用起来的个人Wiki模式知识库 https://blog.gaomeluo.com/archives/OpenClaw-Wiki/ https://blog.gaomeluo.com/archives/OpenClaw-Wiki/ Fri, 12 Jun 2026 22:05:02 +0800 光山人

![](https://image.gaomeluo.com/blog/2026/06/1781271409.png)

以前大家搞知识管理基本都是死循环：读一篇文章 → 点收藏 → 需要时搜索 → 重新从头到尾读一遍。等于每次都要从原始材料里重新挖信息，啥沉淀都留不下。

Andrej Karpathy 在 2026 年 4 月提出了一个更聪明的模式——**LLM Wiki Pattern**。他的核心洞察特别戳人：

> AI知识库应该是结构化、可迭代、持久化，不是每次查问题的时候才临时凑出来的零散碎片。

说人话就是：你看过的内容AI会提前帮你整理好重点、串清楚关联，永久存到知识库里，下次要用直接拿，不用每次问问题都得把之前的原文翻出来重新读一遍重头捋。

这就是本文要分享的内容：如何用大模型构建一个真正能用起来的个人知识库，不用自己天天整理，AI帮你把脏乱差的知识库理得明明白白。

> 技术栈: OpenClaw + SearXNG + crawl4ai + Obsidian + Gitea (NAS Self-hosted)

![](https://image.gaomeluo.com/blog/2026/06/1781271477.png)

这套方法，我用了一周后的样子

![](https://image.gaomeluo.com/blog/2026/06/1781271494.png)

##前题
已经配置好可用的 OpenClaw（这个部分可以参考之前的教程：[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")）

我有NAS，本教程基于NAS，云服务器同理，成本会更低一些，建议上云。

##一、方法论：LLM Wiki Pattern

###1、核心思想

传统的 RAG（检索增强生成）模式是这样的：

> 用户提问 → 检索原始文档 → LLM 拼凑答案 → 答案用完就丢

每次问答都是**从零开始**，没有任何积累。LLM 每次都要找并拼凑相关片段，但什么都留不下。

Wiki 模式完全不同：

> 用户提问 → LLM 基于已有 Wiki 回答 → Wiki 持续更新扩充 → 越积累越丰富

**知识编译一次，然后保持最新**。跨引用已经存在，矛盾已被标记，综合内容已反映你读过的所有内容。每添加一个源，Wiki 就变得更丰富。

###2、三层架构
Karpathy 提出了经典的三层架构：

![](https://image.gaomeluo.com/blog/2026/06/1781271593.png)

三层职责：

![](https://image.gaomeluo.com/blog/2026/06/1781271684.png)

类比：
- Obsidian = IDE
- LLM = 程序员
- Wiki = 代码库

###3、两种知识库的对比

![](https://image.gaomeluo.com/blog/2026/06/1781271749.png)

###4、Wiki 模式的操作流程

Ingest（摄取）：把新源丢到 raw 集合，告诉 LLM 处理它

LLM 读取源
与你讨论关键要点
在 wiki 写摘要页
更新索引
更新相关实体和概念页
添加日志条目
单个源可能涉及 10-15 个 wiki 页面。

Query（查询）：针对 wiki 提问

LLM 搜索相关页面、读取、合成答案并引用
答案可以是 markdown、比较表、幻灯片、图表
好答案可以归档回 wiki 作为新页面
Lint（检查）：定期让 LLM 做健康检查

页面间的矛盾
被新源取代的陈旧主张
没有入站链接的孤立页面
缺失的交叉引用
###5、应用场景
这个模式可以应用到很多场景：

![](https://image.gaomeluo.com/blog/2026/06/1781271806.png)

###6、两种导航文件
随着 wiki 增长，两个特殊文件帮助 LLM（和你）导航：

**index.md（内容导向）**

- wiki 的目录——每个页面列出链接、一行摘要、可选元数据（日期、来源数）
- 按类别组织（实体、概念、来源等）
- LLM 每次摄取时更新
- 回答查询时，LLM 先读索引找相关页面，再深入阅读
- 在中等规模（~100 来源、~数百页面）下效果出奇好，不需要 RAG 基础设施

**log.md（时间顺序）**

- 只追加的操作记录——摄取、查询、lint
- 每条以一致前缀开头（如 `## [2026-04-02] ingest | Article Title`）
- 可用简单 unix 工具解析：`grep "^## \[" log.md | tail -5`
- 日志是 wiki 演进的时间线，帮助 LLM 理解最近做了什么

###7、Obsidian 技巧
**Obsidian Web Clipper：**浏览器扩展，将网页文章转为 markdown，快速将来源加入 raw 集合。

**图片本地化：**设置 → 文件和链接 → 附件文件夹路径设为 `raw/assets/`，绑定热键（Ctrl+Shift+D）下载所有图片。LLM 可以直接查看和引用本地图片，而不是依赖可能失效的 URL。

**Graph View：**查看 wiki 的形状——哪些页面互联了、谁是中心页面、谁是孤立页面。

**Marp：**基于 markdown 的幻灯片格式，Obsidian 有插件，可以直接从 wiki 内容生成演示文稿。

**Dataview：**对 frontmatter 运行查询的插件，如果 LLM 添加了 YAML frontmatter（标签、日期、来源数），Dataview 可以生成动态表格和列表。

###8、可选 CLI 工具
当 wiki 增长时，你可能需要一些小工具帮助 LLM 更高效地操作 wiki：

**qmd：**本地 markdown 搜索引擎，混合 BM25/向量搜索 + LLM 重排，全部本地运行。有 CLI（LLM 可以调用）和 MCP 服务器（作为原生工具）。

**自己 vibe-code 一个简单搜索脚本**也是可以的——LLM 可以帮你快速搭建。

###9、为什么 LLM 维护 Wiki 是革命性的
维护知识库繁琐的部分不是阅读或思考——是记账（bookkeeping）：

- 更新交叉引用
- 保持摘要最新
- 注意新数据何时与旧主张矛盾
- 维护数十个页面间的一致性

**人类放弃 wiki 是因为维护负担增长快于价值。**

LLM 不会无聊、不会忘记更新交叉引用、一次可以触及 15 个文件。维护成本接近零。

- **人类的工作：**管理源、指导分析、提出好问题、思考一切意味着什么
- **LLM 的工作：**其他一切

###10、与 Vannevar Bush Memex 的关系
这个想法在精神上与 Vannevar Bush 的 Memex（1945） 相关——一种个人策划的知识存储，文档间有关联 Trails。Bush 的愿景更接近这个而非 Web 变成的样子：私人、积极策划，文档间的连接与文档本身一样有价值。

**他无法解决的部分是谁来维护，LLM 解决了。**

##二、采集工具实践
###1、采集链路全景
采集是知识库的"源头活水"。没有持续的高质量输入，再好的知识库也会枯竭。

我的采集链路分为三层，各司其职：

![](https://image.gaomeluo.com/blog/2026/06/1781272135.png)

###2、为什么不用 Firecrawl？
最初考虑过 Firecrawl，但它太重了：

![](https://image.gaomeluo.com/blog/2026/06/1781272163.png)

Firecrail 的问题：

- 需要部署 5 个独立服务
- NAS 资源有限，跑不动
- 维护成本高

最终选择：crawl4ai，单容器，无外部依赖。

###3、SearXNG：搜索聚合引擎
**SearXNG** 是一个开源的元搜索引擎，聚合 99 个搜索引擎：

- Wikipedia、arXiv、Google Scholar
- GitHub、GitLab
- 各种新闻站、技术博客

**为什么用 SearXNG？**

- **不依赖单一搜索 API**：分布式搜索，避免被封
- **支持指定引擎**：可以只搜学术资料或只搜 GitHub
- **开源可控**：部署在自己 NAS上
- **MCP 协议支持**：可以接入 OpenClaw 作为工具

工作流程：

![](https://image.gaomeluo.com/blog/2026/06/1781272260.png)

###4、crawl4ai：轻量级网页采集
**crawl4ai **是一个开源的网页采集工具，特点：

- 单容器部署：只需要一个 Docker 镜像
- 内置 Playwright：自动渲染 JS 页面
- LLM Markdown 优化：自动提取正文，生成高质量 Markdown
- 异步设计：支持大规模并发采集

**适用场景：**

- 技术博客（结构清晰）
- 文档站点
- GitHub 项目页
- 没有强反爬的网站

###5、CloakBrowser：复杂站点采集
**CloakBrowser** 是一款反检测浏览器，适合采集"难缠"的站点：

**核心能力：**

- 多 Profile 管理：每个站点独立 Cookie 环境
- 登录态保持：一次登录，后续自动携带 Cookie
- Web UI 可视化：能看见浏览器在做什么，方便调试
- CDP 协议：支持远程控制

**适用场景：**

- 微信公众号：需要微信 UA + 登录态
- Cloudflare 拦截站：需要绕过浏览器指纹检测
- 需要验证码的站点：手动过验证码后自动采集

###6、三层采集对比

![](https://image.gaomeluo.com/blog/2026/06/1781272415.png)

###7、采集后的处理
采集只是第一步，更重要的是结构化：

![](https://image.gaomeluo.com/blog/2026/06/1781272436.png)

raw/ → wiki/ 的转换由 OpenClaw 自动完成：

- 读取 raw/ 中的 Markdown
- LLM 提取关键概念
- 生成结构化 wiki 页面
- 建立双向链接
- 更新索引和日志

##三、实践：我的双库架构
###1、Obsidian 双库设计
我的方案是用 Obsidian 分两个库，职责分离：

**Personal 库（个人笔记主库）**

- 使用 PARA 组织法（Projects, Areas, Resources, Archives）
- 存放自己的创作、项目笔记、随手记录
- 以人类写作为主

**AI 库（AI 采集知识库）**

- 存放 AI 采集和编译的内容
- 内部再分 raw/ 和 wiki/ 两个目录
- LLM 主要维护，人类可参与

**为什么分开？**

- 关注点分离：个人创作 vs 信息摄入
- 避免 AI 生成内容污染个人思考空间
- 两个库可以有完全不同的同步策略

###2、数据同步架构
这是一个多端协同的架构，涉及 **PC、NAS、Gitea、OpenClaw** 四个角色：

![](https://image.gaomeluo.com/blog/2026/06/1781272545.png)

**同步流程详解：**

- 用户本地创作
- PC 上用 Obsidian 编辑 Personal 库和 AI 库
- Git Plugin 自动 commit

**Git 插件推送**

- 定时 push 到 Gitea（Personal.git 和 AI.git）

**Gitea Action Runner 自动部署**

- 检测到 AI.git 提交
- 自动执行脚本 pull 到 NAS 服务器

**OpenClaw 采集写入**

- OpenClaw 运行在 NAS 上
- 执行采集任务后，写入 AI 库的 raw/ 和 wiki/
- 完成后 push 到 Gitea

**本地 Obsidian 同步**

- Git Plugin 定时 pull Gitea
- 获取 OpenClaw 的最新采集结果

###3、为什么这样设计？
**优点：**

- 零手动同步：一切都是自动的，Git 就是同步中枢
- 版本可控：所有改动都有 commit history，可回滚
- 多端一致：PC、NAS、Gitea 三端永远同步
- 隔离安全：Personal 库和 AI 库独立，不互相干扰

**适合人群：**

- 有NAS或者云服务器的群体
- 愿意用 Obsidian + Git 管理笔记
- 希望 AI 能自动采集和整理信息

##四、工具部署：Ansible 自动化
为了方便管理和迁移，我用 Ansible Playbook 管理所有工具：

# 核心 playbook 结构
    ├── searxng.yml        # SearXNG 部署 + MCP 配置
    ├── crawl4ai.yml        # crawl4ai Docker 部署
    ├── cloakbrowser.yml    # CloakBrowser + Profile 管理
    └── update.yml         # 增量更新脚本

**优势：**

- 一键部署 / 升级
- 修改后同步到多台机器
- 版本可控，可回滚
- 基础设施即代码

##五、实验计划
**目标：**用 2 个月验证 LLM Notebook 的可行性

**核心指标：**

- 知识库条目数
- 交叉链接数
- 实际提问使用率
- Wiki 被 LLM 引用的频率

**当前进展：**

- 采集链路打通（SearXNG + crawl4ai + CloakBrowser）
- Git 同步流打通（PC ↔ Gitea ↔ NAS）
- OpenClaw 定时任务配置（每天 3:00 / 12:00 自动调研）
- 持续采集中

##六、总结
**核心理念**：

> 我只负责给 URL，AI 负责采集和构建。
搞通这个数据流程，就玩转起来了。
天光云影共徘徊,唯有源头活水来。

**技术栈总结**：
![](https://image.gaomeluo.com/blog/2026/06/1781272883.png)

参考

- Karpathy LLM Wiki Pattern
- crawl4ai GitHub
- SearXNG
- CloakBrowser

#####更多OpenClaw的玩法
#####关注教程：[玩转OpenClaw丨OpenClaw手把手的教程合辑](https://blog.gaomeluo.com/archives/wan-OpenClaw/ "玩转OpenClaw丨OpenClaw手把手的教程合辑")

]]> 0 https://blog.gaomeluo.com/archives/OpenClaw-Wiki/#comments https://blog.gaomeluo.com/feed/archives/OpenClaw-Wiki/ 谷歌大牛手把手教你“养虾”，月薪3000雇6个AI全能专家，每天让你睁眼就躺赢 https://blog.gaomeluo.com/archives/OpenClaw-tangying/ https://blog.gaomeluo.com/archives/OpenClaw-tangying/ Tue, 09 Jun 2026 23:36:00 +0800 光山人

授人以鱼不如授人以渔，希望本文能够打开你的思路，走向财富的大门。

谷歌AI专家教你用6个AI智能体打造自动化团队，月薪3000元实现躺赢人生！

####核心内容：
1. 谷歌大牛分享低成本搭建AI智能体团队的经验
2. 六个AI专才各司其职处理日常工作的实战案例
3. 从失败的全能AI到成功分工协作的关键转变

###前提条件：
如果你对养虾感兴趣，前题就是要学会或者有一台装虾的机器，**参考教程：[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")**

-----------------------------

最近国内科技圈最火的黑话，莫过于“养虾”(部署OpenClaw智能体)。随着这股热潮彻底爆发，无数普通人都在疯狂“建缸”、“下苗”，但真正能让“虾群”全自动协同打工的却寥寥无几。

如果你也想在这场“养虾”狂欢中少走弯路，谷歌高级AI产品经理舒巴姆·萨布(Shubham Saboo)这份极具性价比的实操经验，绝对是不容错过的顶级“养殖手册”。

凌晨三点，当你还在熟睡时，六个虚拟“员工”就已经开始工作了。它们扫描全球AI动态、撰写推文、审查代码、编辑新闻简报。等早晨你睁开眼，手机里躺着的是六份已经完成的待办事项清单。这正是萨布的真实日常。

萨布没有三头六臂，只是组建了一支由6个AI智能体构成的“自动化团队”。这套基于开源平台OpenClaw搭建的系统，已经稳定运行了一个月，每天帮他处理六项琐碎但必须完成的重复性工作，让他每天能多出4到5个小时，去处理真正需要人脑思考的事务。

最让人折服的是，这套听起来极其硬核的系统，他仅用一台普通的Mac Mini电脑，花着每月不到400美元(约合人民币2760元)的“实习生工资”，就彻底跑通了。他在社交平台X上发布长文，详细披露了整个搭建思路、文件结构，甚至踩过的坑，浏览量迅速突破百万。

![](https://image.gaomeluo.com/blog/2026/06/1781103430.png)

##一、与其招一个全才，不如雇六个专才

萨布的身份有点特殊。他不仅是谷歌的高级产品经理，还是编程社区Unwind AI的创始人，同时维护着一个在GitHub上拥有99.5k颗星的超火代码库Awesome LLM Apps。

![](https://image.gaomeluo.com/blog/2026/06/1781103469.png)

这意味着，萨布每天得同时干六件事：研究AI动态、写推文、写领英帖子、编新闻简报、审查代码、处理社区问题。每件事至少耗时30到60分钟。萨布发现，在开始真正重要的工作前，他的整个白天就已经被这些事耽搁了。

他试过用一个超级智能体解决问题。在一个巨大的提示词里，让它同时负责研究、写作和审查。结果很惨，这个智能体什么都干不好。上下文一多，模型就懵了，质量直线下降。一个智能体的脑子里，根本装不下六种截然不同的工作。

于是萨布换了个思路：**不招一个全才，而是雇佣六个专才。这个转变很关键。与其让一个工具做所有事，不如让一个团队各司其职。这为他后续能像管理真人团队一样管理AI打下了基础。**

萨布给这6个AI智能体起了名字，不是随便起的代号，而是美剧里的经典角色。这听起来像个噱头，但他说这比写提示词管用多了。当他告诉Claude“你要有德怀特·施鲁特(Dwight Schrute，美剧《办公室》中角色)的能量”时，模型从训练数据里就知道这意味着什么：彻底、专注、极其认真。这等于免费获得了长达30季的角色塑造。

一位网友在看过这套系统后感叹：“这简直是为我这种不知道如何定义多智能体边界的人量身定做的，就像学会了如何向CEO汇报一样。”

![](https://image.gaomeluo.com/blog/2026/06/1781103521.png)

另一位网友则说得更直接：“这篇帖子太棒了！是我目前在X上看到的回答‘我已经安装了OpenClaw，接下来该做什么？’这个问题的最佳文章之一。”

![](https://image.gaomeluo.com/blog/2026/06/1781103542.png)

##二、智能体要有“灵魂”，模仿美剧角色设定性格

这支全明星团队的分工是这样的：

![](https://image.gaomeluo.com/blog/2026/06/1781103556.png)

莫妮卡(Monica)是幕僚长，团队的核心，也是萨布在Telegram上聊得最多的一个。她负责协调其他智能体，处理战略决策，分派任务。就像《老友记》里的莫妮卡·盖勒(Monica Geller)，她好胜、有条理，不容忍马虎的工作。她的“人设文件”(SOUL.md)里写着一句灵魂指令：“你是那个确保每件事都做对的人。”

德怀特(Dwight)负责研究岗，每天进行三次研究扫描，紧盯X、黑客新闻、GitHub趋势、Google AI博客。他产出结构化的情报报告，供团队其他成员使用。就像《办公室》里的德怀特·施鲁特(Dwight Schrute)，专注、彻底，从不漏掉任何信号。

凯莉(Kelly)负责X平台写手，她阅读德怀特的研究报告，然后用萨布的口吻撰写推文草稿。就像《办公室》里的凯莉·卡普尔(Kelly Kapoor)，它的人设是知道什么会在流行前就流行起来。

瑞秋(Rachel)负责领英内容，和凯莉共享同一份情报，但平台不同，语气也截然不同。就像《老友记》里的瑞秋·格林(Rachel Green)，它侧重思想领袖的角度，而不是热门观点。

罗斯(Ross)负责工程岗，处理代码审查、错误修复。就像《老友记》里的罗斯·盖勒(Ross Geller)，书呆子气，喜欢深入探索，他的指令里写着：“当你处理一个问题时，要完全理解它。不要只修复症状。”

帕姆(Pam)负责新闻通讯编辑，设定与《办公室》中的帕姆·比斯利(Pam Beesly)相似，负责将德怀特的每日情报转化成通俗易懂的新闻通讯摘要。

每个智能体只有一项工作，职责清晰，绝不混淆。**萨布强调，一个有主见的智能体，比一个只会取悦人的智能体做出的决定要敏锐得多。**当罗斯提出一个坏主意时，萨布不会去调试提示词，他会直接告诉莫妮卡：“罗斯最近状态不佳。”而莫妮卡作为幕僚长，会立刻去重写罗斯的指令，更新他的记忆，调整他的优先级。

这种管理方式非常直观。因为我们都了解这些角色，知道莫妮卡管理严格，德怀特一丝不苟，罗斯喜欢钻牛角尖。这种熟悉感就是作弊码。

##三、智能体协作的尽头是文件读写

这套系统最反直觉的地方在于它的协调机制。智能体之间没有复杂的API调用，没有消息队列，没有编排框架。只有一样东西，那就是md文件。

![](https://image.gaomeluo.com/blog/2026/06/1781103798.png)

德怀特进行研究，把结果写进一个叫intel/DAILY-INTEL.md的文件里。凯莉醒来后，直接读取这个文件，从中提炼信息写推文。瑞秋和帕姆也一样，读取同一个文件，各干各的活。**整个团队的沟通，就是靠读写磁盘上的Markdown文档完成的。**没有中间件，没有认证问题，不会因为API速率限制而崩溃。文件就在那里，稳定、简单、有效。

有网友原本觉得OpenClaw没什么用，认为直接写个cron定时任务也能跑脚本。但看到这套基于文件的协作模式后，他才明白过来，原来智能体还能这么玩。当需要处理更结构化的数据时，比如要去重或长期追踪，他们会用JSON文件作为事实来源，而人类可读的摘要则保留在Markdown里，方便其他智能体读取。

![](https://image.gaomeluo.com/blog/2026/06/1781103826.png)

AI每次醒来都是一次全新的对话，不记得昨天发生过什么。这是个问题，也是个特性。为了让智能体们“长记性”，萨布设计了一套双层记忆系统。

每日日志：每次会话的原始记录都会被保存下来，比如发生了什么，起草了什么内容，收到了什么反馈。这些文件按日期归档，像一本工作日记。

长期记忆：智能体会定期回顾自己的每日日志，把最重要的经验、用户偏好、注意到的模式提炼出来，写进一个叫MEMORY.md的文件里。

![](https://image.gaomeluo.com/blog/2026/06/1781103846.png)

举个例子，凯莉一开始写的草稿全是表情符号和话题标签，但这不符合萨布的风格。他直接反馈：“没有表情符号。没有话题标签。短小精悍的句子。”凯莉把这个反馈记在了长期记忆里。一周后，她的风格就完全稳定下来了。

德怀特一开始也抓取了太多信息，每个小更新都不放过。萨布告诉他：“不是所有趋势都重要。我需要信号，不是噪音。”德怀特更新了他的原则，现在他产出的情报报告重点突出，极具可操作性。

![](https://image.gaomeluo.com/blog/2026/06/1781103867.png)

萨布把这种反复迭代的过程称为纠正性提示工程。任何智能体的第一个版本都是平庸的，但第十个版本是好的，第三十个版本是伟大的。**真正塑造它们的，不是预设的指令，而是数周以来存储在记忆文件里的每一次修正。**这就像一个不断复利增长的知识库，让每个智能体都在自己的岗位上越干越出色。

##四、智能体自己会排班，自己会修bug

要让智能体团队在无人值守时自动运转，光有角色和记忆还不够，还得有科学的排班表和紧急预案。

萨布给每个智能体都设定了定时任务，也就是cron调度。顺序很重要：德怀特最先开始研究，因为他产出的是原料。几小时后，凯莉和瑞秋这些内容加工者再开始工作。整个流程就像一条流水线，环环相扣。

![](https://image.gaomeluo.com/blog/2026/06/1781103935.png)

但机器总会出问题。任务卡住、网络断连、API调用失败，这些都是家常便饭。为此，萨布设计了一个名为心跳(HEARTBEAT)的安全网。

主智能体莫妮卡会在固定时间点检查，确认所有定时任务是否都按计划运行了。如果发现某个任务错过了运行窗口，她会立刻强制重新运行。**这个机制实现了自我修复，完全不需要人工干预。**当需要处理批量检查和容错时用“心跳”，当需要精确到分钟级别的调度时用cron。

![](https://image.gaomeluo.com/blog/2026/06/1781103964.png)

这套系统没有华丽的网页仪表盘，也没有复杂的后台管理面板。萨布和智能体交流的唯一界面，就是手机上的Telegram。这是一个刻意的选择。他不想特意登录一个网站去检查工作，手机24小时在身边，Telegram始终在线。

智能体在他最常用的地方与他相遇。每天早上，萨布醒来打开Telegram，德怀特已经发来一份带链接的研究摘要，凯莉有三条推文草稿等着审批，瑞秋也准备好了领英帖子。他喝着咖啡，花十分钟审阅、给反馈、点击确认，一个上午的工作就完成了大半。

把这么多任务交给AI，安全怎么保证？**萨布的方法很简单：给AI它们自己的世界，不给它们访问真实世界的权限。**那台Mac Mini是AI专用的电脑，它们有自己的电子邮件账户、自己专用的API密钥。那台机器上没有任何东西连接到萨布的个人账户。

如果想查看一封邮件，他会转发给AI；如果需要审阅文档，他会在Telegram上分享给AI。它们只看到他想让它们看到的东西。这和雇佣新员工是一样的道理，不会在第一天就把所有钥匙都交出去。给他们自己的工作空间和凭证，再根据需要分享信息。

##五、不到400美元的“梦之队”

让我们来算一笔账：

硬件：一台Mac Mini M4起步价499美元，但任何一台一直开着的电脑都行，旧笔记本甚至每月5美元的云服务器也可以。

软件：OpenClaw开源免费，Telegram免费使用。

AI模型成本是主要开销。萨布每月花200美元订阅Claude的Max计划，Gemini API花费50至70美元，加上TinyFish和Eleven Labs的费用，总计不到400美元。

用每月不到400美元的成本，换来的是一个从不睡觉、从不请假、并且每天都在进步的6人团队。德怀特每天为他节省2到3小时的研究时间，凯莉和瑞秋再省下1到2小时的起草时间，罗斯处理那些需要熬夜干的工程任务。每天净省4到5小时，一年下来就是一笔巨大的时间财富。

有网友算了笔账：每月不到400美元，换来六个24小时在线的员工，而且这六个人还一天比一天能干。在他看来，这才是真正的护城河。不是模型本身，而是这套能自我进化的系统。

![](https://image.gaomeluo.com/blog/2026/06/1781104066.png)

最近关于OpenClaw的讨论越来越热。英伟达CEO黄仁勋在摩根士丹利会议上发言时，专门提到了这个框架。他说：“看看OpenClaw及其采用速度，Linux大概用了30年才达到这个水平，OpenClaw只用了3周。它现在是历史上下载量最高的开源软件！”

![](https://image.gaomeluo.com/blog/2026/06/1781104085.png)

与此同时，随着GPT-5.4的推出，把OpenClaw和最新模型结合起来也成了热门话题。GPT-5.4在处理结构化指令、长对话稳定性、工具调用方面有明显改进。

许多尝试使用AI智能体或自动化框架的开发者最终都会遇到同样的问题：模型本身可能非常强大，但如何将其可靠地连接到消息平台、API和工作流工具，很快就会变得非常复杂。这正是OpenClaw发挥作用的地方。

**当开发者把OpenClaw当成网关层，把GPT-5.4接到Telegram、Discord、Slack这些真实通信渠道上时，整个系统变得既稳定又好维护。**不少团队已经开始用这套组合做客户支持机器人、生产力助手，甚至社区里的AI角色扮演。用统一的API平台聚合多个模型，也让成本控制变得更灵活。

##六、要不要实践一下？

实践出真理，热潮之下，很多人都跃跃欲试。

第一周，只招一个人。安装OpenClaw，给它写一个简单的SOUL.md文件。选择你每天做得最重复的那一件事，比如研究或写草稿。设置好Telegram，创建一个定时任务。就让它先跑一周，观察它，修复遇到的各种问题。

####参考教程：[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")

第二周，教它长记性，让它变好。最初的输出会很平庸，这太正常了。给它反馈，看着它的记忆文件慢慢增长。根据你的反馈修正它的人设。到第二周结束时，它应该能产出真正有用的东西了。

第三周，招第二个人。这时你会感到需要了。研究智能体产出了情报，但你还在手动写推文，是时候添加一个内容智能体了。按照“一写多读”的文件共享模式，让它们协作起来。

第四周及以后，按需扩张。当感到需要时才添加新角色，而不是为了加而加。每个新智能体，都应该能解决你工作流程中一个真实的痛点。

这不是一个周末就能完成的玩具项目，而是一个持续进化的系统。萨布说，当这个系统运行了一个月后，他发现自己会不自觉地在睡前对手机里的团队说晚安。“这听起来很傻。但在经过一个月的日常互动、反馈循环、看着它们进步之后，智能体和人类之间的界限变得模糊了。”

模型本身是公开的资源，每个人都能用Claude、GPT、Gemini。真正的优势，是你为这个团队打造的灵魂，包括SOUL.md文件、记忆系统、调度模式，以及数周以来存储在文件里的每一次纠正性反馈。那个系统，只属于你。而且它每天都在复利增长。每一次研究扫描都让德怀特的记忆更丰富，每一轮反馈都让凯莉的草稿更精准，罗斯修复的每个bug都教给他更多关于你代码库的知识。

这才是真正的护城河。不是模型，是那个不断学习的系统。

如果你也想拥有属于自己的数字护城河，今天就从一个智能体、一项工作、一个计划开始吧。

]]> 0 https://blog.gaomeluo.com/archives/OpenClaw-tangying/#comments https://blog.gaomeluo.com/feed/archives/OpenClaw-tangying/ 只需一个指令，让 OpenClaw 安排 TRAE 干活 https://blog.gaomeluo.com/archives/OpenClaw-ganhuo/ https://blog.gaomeluo.com/archives/OpenClaw-ganhuo/ Tue, 09 Jun 2026 23:34:00 +0800 光山人

一句话远程指挥TRAE干活，解放你的双手！来看看开发者如何通过OpenClaw轻松实现远程任务调度。

####核心内容：
1. OpenClaw与TRAE的协同工作原理
2. 配置前的必要准备条件
3. 一句话指令实现远程任务调动的具体操作步骤

今天为大家带来一个 TRAE 友自己的实践，看他是如何通过一个指令，就安排 TRAE 帮他干活的～

##一、方案介绍

在开始之前，我们先简单理解一下这个方案。

- OpenClaw：你可以把它想象成一个超级聪明的大脑，一个全能的 AI 助手。它能理解你的话，帮你思考和决策。

- TRAE：这则是一个任劳任怨的“动手专家”，一个安装在你电脑里的 AI 驱动的集成开发环境（IDE）。它熟悉你电脑里的所有文件和项目，能真正地编写代码、执行任务。

- TRAEClaw 插件（来自 TRAE 友开发），就像连接大脑和双手的“神经”。它的作用，就是把你在任何地方（例如飞书）对 OpenClaw 下达的命令，精准地“翻译”并传递给你自己电脑里的 TRAE，让 TRAE 这个最熟悉你工作环境的“本地专家”来完成实际操作。

**整个过程就像这样：你（在任何地方） → 对话 OpenClaw → TRAEClaw 插件（传递指令） → 你电脑上的 TRAE（执行任务）**

##二、配置前准备工作

在正式开始配置之前，你需要保证自己完成了以下操作：

- 你的机器上已经安装 TRAE 国际版（https://www.trae.ai/）
<这个网站你要是打不开，不妨看一下这篇文章**《[魔戒VPN——节点多、速度快、稳定，推荐！！！](https://inurl.top/archives/mojie/ "魔戒VPN——节点多、速度快、稳定，推荐！！！")》**>

- 至少完成过一次 TRAE 登录

- 已经配置好可用的 OpenClaw（这个部分可以参考之前的教程：[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")）

##三、一句话配置

只需要对你的 OpenClaw 发出一句指令，对，就是这么简单。

如果你还没有将 OpenClaw 对接到 飞书，你也可以直接在 OpenClaw 的对话页面（`http://xxx.xxx.xxx:1878`）发出指令，如果你配置了飞书，你可以直接在飞书聊天框发出这句指令。（参考教程：[【教程】手把手教你OpenClaw对接飞书教程](https://blog.gaomeluo.com/archives/openclaw-feishu/ "【教程】手把手教你OpenClaw对接飞书教程")）

> 
请先阅读 https://github.com/firerlAGI/TraeClaw 仓库里的 AgentS.md 和 AI_INSTALL.zh-CN.md， 然后在 macOS 上通过 npm 安装并启用 TRAEclaw（TRAE-ide）， 验证 openclaw plugins info TRAE-ide 和 openclaw config validate， 提醒我重启 OpenClaw Gateway，再执行一次 TRAE_status，并告诉我接下来怎么用 TRAE_delegate。

通过飞书部署的 OpenClaw 发出

![](https://image.gaomeluo.com/blog/2026/06/1781102591.png)

通过 OpenClaw 后台发出

![](https://image.gaomeluo.com/blog/2026/06/1781102638.png)

> **特别说明**：如果在使用过程中遇到问题可以直接让你的 OpenClaw 帮你修复。自然语言对话即可。

##四、安装后展示

因为 OpenClaw 的可玩性和高权限，无论是本地、飞书、discord，都能通过这个插件调用电脑上的的 TRAE IDE。

> 因为 OpenClaw 的可玩性和高权限，无论是飞书、discord，都能通过这个插件调用TRAE IDE。

> 数据安全也很重要，这个要时刻记得！数据安全也很重要，这个要时刻记得！

![](https://image.gaomeluo.com/blog/2026/06/1781102774.png)

![](https://image.gaomeluo.com/blog/2026/06/1781102786.png)

####案例一：用 OpenClaw 指挥 TRAE 制作一个官方论坛前端网页

提示词如下：
> 使用TRAE模仿`https://forum.TRAE.cn/` 这个网站，开发一个静态网页。注意在TRAE- project 这个文件夹中进行开发。

####案例二：用飞书指挥 OpenClaw 作为项目经理，不断打磨案例一中的论坛前端

提示词如下：
> 现在任命你为这个项目的项目经理 不断打磨这个前端页面的项目，直到和`https://forum.trae.cn/` （这个是TRAE的中文社区）做到一致，遇到问题及时向我报告。

模仿的前端页面，该说不说，还是挺还原的

![](https://image.gaomeluo.com/blog/2026/06/1781102978.png)

你也可以告诉你的 OpenClaw：

> “让 TRAE 给刚才那个网页加一个更好看的导航栏。”

> “让 TRAE 调整一下字体和颜色，风格要更活泼一点。”

##五、TRAEClaw GitHub包地址

####项目地址
GitHub 仓库：`https://github.com/firerlAGI/TraeClaw`

<这个网站你要是打不开，不妨看一下这篇文章**《[魔戒VPN——节点多、速度快、稳定，推荐！！！](https://inurl.top/archives/mojie/ "魔戒VPN——节点多、速度快、稳定，推荐！！！")》**>

目前，这个插件会优先适配 macOS 端。这背后主要并不是功能取舍的问题，而是出于稳定性和复现成本的综合考虑。

相较而言，macOS 在 TRAE IDE 的启动方式、调试端口、窗口管理、路径结构以及自动化行为等方面，都表现出更高的一致性。这样的系统环境，更有利于问题定位、链路调试和方案收敛，也更容易打磨出一条稳定、可控、可复现的接入路径。

]]> 0 https://blog.gaomeluo.com/archives/OpenClaw-ganhuo/#comments https://blog.gaomeluo.com/feed/archives/OpenClaw-ganhuo/ 卖 Skill、卖服务、卖产能——靠 OpenClaw 赚钱的三种姿势 https://blog.gaomeluo.com/archives/Skill-OpenClaw/ https://blog.gaomeluo.com/archives/Skill-OpenClaw/ Tue, 09 Jun 2026 23:33:00 +0800 光山人

OpenClaw生态中的赚钱新思路：卖Skill、卖服务、卖产能，月入数万不是梦。
####核心内容：
1. Skill经济的市场机会与供需差分析
2. 三个真实赚钱案例拆解（ClawMart、商品价差监控等）
3. 普通人如何复刻成功路径的实操建议

ClawMart（openclaw-skills-store[1]）是 OpenClaw 生态的第三方技能商店。月收入 $80,526，订阅用户 163 人。

他们卖的不是什么高深技术，是打包好的行业自动化流程——也就是 Skill。

#### 这篇文章拆三件事：谁在靠 Skill 赚钱、他们怎么赚的、你能不能复刻。

##前提条件：
如果你对OpenClaw 赚钱感兴趣，前题就是要学会或者有一台装虾的机器，**参考教程：[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")**

##一、先搞懂 Skill 经济的钱从哪来

Skill = 给 AI 的岗位 SOP，一个 Markdown 文件就能写。技术细节不展开，一句话：**你把一个工作流程写成结构化的操作手册，OpenClaw 按你的手册自动执行。**

关键不是怎么写，而是写什么能卖钱。

ClawHub 上有 3000+ 免费 Skill——搜索、翻译、代码审查，通用工具已经卷到极致。但搜"竞品监控"、"合同审查"、"选品分析"，几乎空白。

垂直行业 Skill 不到 50 个。 3000 vs 50，这就是供需差。

![](https://image.gaomeluo.com/blog/2026/06/1781101262.png)

2026 年全球 Agent 市场 2000 亿美元，垂直行业占 44.5%。钱在"专"里，不在"通用"里。

##二、三个真实的赚钱案例

####案例 1：ClawMart——月入 $80,526 的 Skill 商店
这是目前 OpenClaw 生态里变现最成功的案例。ClawMart 不开发 Skill 本身，它把别人的 Skill 打包成产品卖。

定价结构：

![](https://image.gaomeluo.com/blog/2026/06/1781101367.png)

**赚钱逻辑**：Skill 本身在 ClawHub 上是免费的，但"调好的组合 + 预配置 + 持续维护 + 技术支持"是付费的。

> 这就像 Linux 免费，但 Red Hat 靠卖企业支持年入几十亿。Skill 免费，服务收费。

163 个订阅用户 × 7,987/月，光订阅收入就快 8000 美金。加上一次性销售和工具包，合计 $80,526/月。

**你能复刻的部分**：不需要做一个商店。选一个你熟的行业，做一套"行业 Skill + 预配置模板 + 使用教程"，以 ¥99-299 的价格在自己的渠道卖。

####案例 2：商品价差监控——月赚 3000+，成本不到 150
掘金上一个开发者分享了他的自动化系统。核心模块：**自动监控淘宝、拼多多、京东、亚马逊的商品价格，发现价差超过 50 元时自动提醒。**

整个系统的经济账：

![](https://image.gaomeluo.com/blog/2026/06/1781101426.png)

####赚钱逻辑拆解：

**第一层：自用省钱 + 信息差服务**。系统 24 小时盯着淘宝、拼多多、京东、亚马逊的价格波动。比如 AirPods Pro 在拼多多搞活动降到 1200 元，京东还挂 1380 元——他自己买到低价，也把这种"限时低价"信息打包推送给需要的人（代购群、买手群）。靠信息差收"情报费"，每条 5-20 元。

**第二层：卖监控服务**。把系统包装成"电商价差监控订阅"，卖给电商卖家和选品团队。卖家需要实时知道竞品的价格变动和促销动态，但自己盯太累。收费 ¥300-1000/月/客户。

**第三层：卖技能包**。把核心脚本打包成 ¥99 的"AI 搞钱 Agent"，在 Skills Store 上卖。开发时间 2 小时，卖 7 单就回本，利润率 83%。

####案例 3：B 站 UP 主——月入从 5000 涨到 18000
CSDN 上有篇拆解：一个 B 站 UP 主用 OpenClaw 搭了内容自动化系统，更新频率提升 3 倍，月收入从 ¥5,000 涨到 ¥18,000。

**赚钱逻辑**：他不是在卖 Skill，他是用 Skill 提高自己的产能。

之前手动做一期视频要 2 天——找选题、写脚本、剪辑、发布。现在用 OpenClaw 自动化了前两步（选题扫描 + 脚本初稿生成），一期视频只要半天。同样的时间，产出从每月 4 期变成 12 期。

收入来源不是 Skill，是因为 Skill 带来的产能提升：更多视频 → 更多播放 → 更多广告收入和商单。

> 不是每个人都要卖 Skill。用 Skill 提升自己本业的效率，赚的可能比卖 Skill 更多。

##三、OpenClaw 生态的变现全景

TrustMRR 数据平台的统计：OpenClaw 生态下共 153 个商业化项目，近 30 天合计收入约 35.86 万美元。

几个关键结论：

**前 30 名占总收入的 97.3%**。 这是典型的头部效应——做到品类前几名才有肉吃。

**超过 70% 的收益来自"卖铲子"**：部署服务（¥99-3000/单）、托管维护、企业定制。Skill 本身是免费的获客工具。

变现路径从低到高：

![](https://image.gaomeluo.com/blog/2026/06/1781101547.png)

掘金开发者的实战数据：

![](https://image.gaomeluo.com/blog/2026/06/1781101567.png)

##四、发布到 ClawHub 和 ClawMart

Skill 写好之后（本质就是一个 Markdown 文件+可选脚本，10 分钟能搞定），发布到 ClawHub 三条命令：

npm i -g clawhub
    clawhub login
    clawhub skill publish ./my-skill \
      --slug your-skill-name \
      --name "你的Skill名称" \
      --version 1.0.0

发完了，全球 OpenClaw 用户都能搜到安装。ClawHub 会做安全扫描（VirusTotal + OpenClaw 双重检测）。

如果你想直接卖——参考 ClawMart 的模式，把 Skill 打包成产品，挂到自己的商店页面或用 Gumroad/微信支付收款：

> ClawMart 地址：openclaw-skills-store[2]
定价参考：入门 ¥29 / 高级 ¥49-99 / 企业 ¥299-999

**站外引流比站内等着被搜有效 10 倍**。 写教程文章文末带安装命令，B 站录 3 分钟演示视频，小红书发实操贴配报告截图——**直接贴一张 Skill 生成的报告截图，比任何文案都强。**

##五、坑和局限

说了这么多赚钱的，也得说说现实：

**头部效应极强**。 153 个项目里前 30 名拿走了 97.3% 的收入。做不到品类前几名，收入会很少。但反过来说——垂直行业不到 50 个 Skill，你做的行业可能连竞争对手都没有。

**恶意 Skill**。 Snyk 扫出了 386 个恶意 Skill，有偷私钥的，有重定向交易的。装任何第三方 Skill 之前先检查 scripts 目录。

**维护成本不是零**。 行业规则变了、平台改版了，Skill 就要更新。3 个月不更新的 Skill 用户不敢装。

**安装/部署服务的天花板很低**。 ¥99-299 一单，一天做不了几单，时间换钱不可持续。真正的规模化靠订阅制和企业定制。

**写在最后**

ClawMart 月入 8 万美金靠的不是多高深的技术，靠的是**比别人早半步发现需求，然后把解决方案打包卖出去**。

商品价差监控月赚 3000 靠的也不是 AI 多厉害，靠的是**把人工流程自动化之后的效率差**。

B 站 UP 主月入翻 3 倍靠的更不是卖 Skill，靠的是**用 Skill 提升自己产能**。

三个案例，三种赚法，但底层逻辑一样：**你在某个领域有经验，把这个经验结构化，让 AI 替你执行或替你卖**。

你在哪个行业？那个行业里有什么每天都在重复做的事？

![](https://image.gaomeluo.com/blog/2026/06/1781101771.png)

]]> 0 https://blog.gaomeluo.com/archives/Skill-OpenClaw/#comments https://blog.gaomeluo.com/feed/archives/Skill-OpenClaw/ 从 OpenClaw 到 Hermes Agent：安装、迁移、配置、实战演示 https://blog.gaomeluo.com/archives/OpenClaw-HermesAgent/ https://blog.gaomeluo.com/archives/OpenClaw-HermesAgent/ Tue, 09 Jun 2026 23:33:00 +0800 光山人

##Hermes Agent 是什么
在正式迁移之前，有必要了解一下 Hermes Agent 到底是什么。它是 Nous Research 打造的自进化 AI Agent，也是目前唯一一个内置学习闭环的 Agent 框架——它能从经验中创建技能，在使用过程中持续改进，主动保存知识，搜索自己的历史对话，并在跨会话中不断加深对用户的理解。

它的核心在于真正的记忆系统。Agent 维护着两个精心管理的文件：MEMORY.md 用于记录环境事实、惯例和经验教训，USER.md 用于记录用户偏好和沟通风格。这些文件会在每次会话开始时注入系统提示词。同时，Agent 还具备基于 SQLite 的全文搜索能力，可以回溯数周前的对话。

它内置了 40 多个技能，涵盖 MLOps、GitHub 工作流、研究等领域，并且 Agent 能在使用过程中自动创建新技能，通过开放的 agentskills.io 格式进行分享。在部署灵活性方面，它支持六种终端后端——本地、Docker、SSH、Daytona、Singularity 和 Modal，可以运行在 5 美元的 VPS 上，也可以跑在 GPU 集群或按需休眠的 Serverless 基础设施上。

消息平台方面，Telegram、Discord、Slack、WhatsApp、Signal 和 CLI 都可以通过一个统一的网关进程来连接。模型选择上没有任何锁定，支持 Nous Portal、OpenRouter（200+ 模型）、MiniMax、OpenAI 等，通过 hermes model 随时切换。

##Hermes 与 OpenClaw 的架构差异
这两个工具表面上非常相似，但底层设计理念存在关键区别。OpenClaw 是围绕一个中央控制平面（Gateway）来组织的，由一个长期运行的进程负责会话管理、路由、工具执行和状态维护。而 Hermes 则把 Agent 自身的执行循环作为核心——一个可重复的"执行-学习-改进"周期，整个系统围绕这个循环来构建。

最本质的区别在于技能系统。OpenClaw 的技能主要是人工编写的、可复用的工具和工作流指令。而 Hermes 的理念完全不同：Agent 在完成复杂任务后会自主评估哪些方法有效、哪些无效、用户做了哪些修正，然后将成功的方法提取为可复用的技能。换句话说，Hermes 的技能是"长"出来的，而不是写出来的。

这意味着，Hermes 更适合需要长期运行、通过使用不断提升的场景，而 OpenClaw 更适合需要精细手动控制和工作区原生集成的场景。

##迁移前的调研过程
我这次没有直接去翻 Hermes 的仓库文档，而是先和 Grok 聊了聊我的需求，让它帮我解读官方帖子的含义、梳理迁移的关键问题。

Grok 告诉我，hermes claw migrate 这行命令可以把 OpenClaw 里的记忆、配置、技能一键导入到 Hermes，基本实现无缝切换。这意味着手动配置的工作量会大大减少。我接着问了几个关键问题：模型配置能不能迁移？API keys 怎么处理？OpenClaw 原有的数据会不会被修改？

根据官方文档的确认，迁移工具会读取 ~/.openclaw/ 目录，默认检查 ~/.openclaw/、~/.clawdbot/、~/.moldbot/ 三个路径。模型配置会映射到 Hermes 的 config.yaml 文件。API keys 默认不迁移（即 user-data 预设），但使用 full 预设可以一并导入。而且整个迁移过程是只读的，不会修改 OpenClaw 的原始文件。

官方还推荐在正式迁移前先运行 hermes claw migrate --dry-run 进行预览，查看哪些内容会被迁移、哪些会被跳过、哪些存在冲突。

我还让 Grok 列出了两者在编程语言、安装难度、消息平台支持、技能系统、记忆体系等方面的详细对比。虽然由于 OpenClaw 更新很快，对比可能有不完全准确的地方，但总体结论是两者非常相似，迁移后现有的大部分工作流都能正常运作。

关于 token 消耗——这也是很多用户关注的问题。社区分享的数据虽然不够严格科学，但大致的共识是 Hermes 长期使用反而更省 token，原因在于技能系统的积累效应减少了重复推理的开销。

##正式迁移步骤
调研完成后，我决定动手迁移。以下是我在终端中执行的完整流程。

**安装 Hermes Agent**。 只需一行命令：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安装脚本会自动处理 Python、Node.js、依赖以及 hermes 命令的配置，除了 git 之外不需要任何前置条件。Hermes 的安装界面做得非常美观，它会自动检测操作系统、检查 UV 包管理器，然后依次安装所需依赖。

**配置文件结构**。 Hermes 的核心配置放在 ~/.hermes/config.yaml 中，对应 OpenClaw 的 openclaw.json。API keys 则存储在 ~/.hermes/.env 文件里。

**健康检查**。 安装完成后运行 hermes doctor，它会检查环境配置、文件结构、外部工具依赖等，并报告发现的问题。

**执行迁移**。 先用 dry run 模式预览：

hermes claw migrate --dry-run

确认无误后正式迁移：

hermes claw migrate

迁移支持多种预设：full 表示完整迁移包括密钥，user-data 表示仅迁移用户数据不含密钥。技能冲突可以通过 --skill-conflict 参数控制处理方式：skip 保留已有的 Hermes 技能，overwrite 覆盖，rename 创建带 -imported 后缀的副本。

**配置模型和参数**。 运行 hermes setup 进入配置向导。在这个过程中我遇到了一个小问题——可能是因为之前在 OpenClaw 里做过较大改动，导致 hermes model 提示找不到对应的模型名。后来用 Opus 4.6 帮忙排查，很快就解决了。

配置向导中有几个值得注意的设置：单次对话中工具调用迭代的最大次数；工具调用行为的展示详情级别（建议选择 "all" 以获得最完整的信息）；TTS 模型（我配置了 MiniMax TTS）。

#### 因为是从 OpenClaw 迁移过来的，聊天平台等配置可以直接沿用，比如我原来配好的 Telegram 渠道就不需要重新设置。

##迁移后的文件变化
有几个重要的细节需要说明。迁移命令执行后，原来的 OpenClaw 文件夹会被重命名为 .openclaw.pre-migration，所有原始内容都完好保留。如果对 Hermes 不满意，可以随时切换回去。

Hermes 在兼容性上也做了细致的考虑。即使原来的 workspace 位于 OpenClaw 文件夹下，迁移后 Hermes 在工作时会自动新建一个 .openclaw 目录并在其中创建 workspace。

不过有一点需要注意：定时任务（Cron Jobs）在我的迁移中没有被自动带过来，需要手动重新配置。

##实际使用体验
迁移完成后，我用几个实际任务测试了 Hermes 的表现。

**音乐生成**。 我让 Hermes 生成一首轻音乐，它调用了之前在 OpenClaw 中创建的 MiniMax Music skill。尽管 skill 内部的路径仍然指向 OpenClaw 的目录结构，Hermes 依然能正确识别和调用，兼容性令人印象深刻。整个过程中，它清晰地展示了调用的 skill 名称和终端执行的每一条命令。当需要运行 Python 脚本时，会弹出确认框让我选择是否永久允许。

**LLM Wiki 知识库**。 通过输入 /llm-wiki 指令，Hermes 帮我创建了一份大语言模型发展史的知识库，存放在 Wiki 文件夹中。值得一提的是，它在回复中还自然地引用了之前对话中的上下文。

**Manim 动画制作**。 这是最能体现 Hermes 工作流透明度的一个任务。我输入 /manim-video，让它演示勾股定理的完整证明过程。Manim video 是 Hermes 的内置 skill，无需额外安装。整个执行过程中，每一步操作都会实时显示在界面上——调用了哪些工具、执行了哪些命令、当前进度如何，全部一目了然。这种逐步递进的展示方式比 OpenClaw 目前的实现要好不少。

十几分钟后，它交付了一个包含四个场景、时长 51 秒的动画视频。Manim 本身依赖复杂、安装麻烦，能一次性生成已经相当不错。之后我还给它提供了一份设计风格指导文档，让它按照指定风格重新生成动画，再配合 MiniMax Speech skill 生成解说配音，最终合成了一个完整的视频。虽然成品还有不少改进空间，但整个工作流的可行性已经得到验证。

**Remotion 视频制作**。 我还尝试让 Hermes 制作 Remotion 视频。过程中它一开始抓取了错误的页面，我输入 "stop" 试图让它停下来但没有反应，改成 /stop 才生效。纠正链接后它重新工作，最终的排版效果可以接受。

**定时任务配置**。 最后，我重新配置了从 Hacker News 定时抓取 AI 新闻的任务。Hermes 会先调用相关 skill，然后设置 Cron 定时任务，最后生成新闻摘要并推送。

##常用命令速查
迁移和日常使用中会频繁用到以下命令：

hermes                    # 启动交互式 CLI 对话
    hermes setup              # 运行完整配置向导
    hermes model              # 选择 LLM 提供商和模型
    hermes tools              # 配置启用的工具
    hermes gateway            # 启动消息网关（Telegram、Discord 等）
    hermes claw migrate       # 从 OpenClaw 迁移
    hermes update             # 更新到最新版本
    hermes doctor             # 诊断问题

总结
从 OpenClaw 迁移到 Hermes Agent 的过程比预期顺利。技能、记忆、消息渠道等核心资产都能通过一条命令完成导入，兼容性表现出色。Hermes 在工具调用的透明度和实时进度展示方面明显优于 OpenClaw，而自进化的技能系统也让它在长期使用中越来越顺手。

]]> 0 https://blog.gaomeluo.com/archives/OpenClaw-HermesAgent/#comments https://blog.gaomeluo.com/feed/archives/OpenClaw-HermesAgent/ 养虾实战教程：一个人、一台 Mac、六个 AI Agent — 从"能聊天"到"能干活"的工程实战 https://blog.gaomeluo.com/archives/OpenClaw-6agent/ https://blog.gaomeluo.com/archives/OpenClaw-6agent/ Tue, 09 Jun 2026 23:32:11 +0800 光山人 AI Agent 如何从"能聊天"进化到"能干活"？这篇文章揭秘了作...]]>

![](https://image.gaomeluo.com/blog/2026/05/1780148998.png)

> AI Agent 如何从"能聊天"进化到"能干活"？这篇文章揭秘了作者用6个AI Agent构建自动化工作流的实战经验。

####核心内容：
1. 6个AI Agent如何接管日常工作，实现24小时自动化运转
2. Agent自主进化的关键技术：通信协议设计、技能沉淀与共享机制
3. 作者作为"框架搭建者"而非"执行者"的工程实践心得

##你的一天被接管了

你睡着的时候，交易蜘蛛已经出了股市收盘报告。你醒来之前，宏观分析师已经写完了 A 股晨报。你还没刷手机，管家蜘蛛已经推来了天气、日程和今日待办。与此同时，AI 哨兵已经扫完了 GitHub Trending、arXiv 最新论文和 100+ 个信息源——18+ 条技术情报按重要性排好序等你看。内容蜘蛛已经在跟踪 54 个平台的热榜和 X 热点。

这是我最关心的部分——AI 动态和技术趋势的自动追踪。哨兵发现有价值的开源项目或论文后，不仅推送新闻，还会评估对我们现有系统的影响，给出 P0/P1/P2 行动建议。有价值的发现会进入 Zoe 的 Tech Radar，走评估 → 决策 → 委派编码落地的完整链路。

从凌晨 3 点的自动备份到 23:45 的全团队反思，52 个 cron 任务每天自动轮转。而且 Agent 在自己进化——犯过的错会被记住，同类问题的复发率显著下降。这不是我写的规则，是 Agent 自己从.learnings/promote 到MEMORY.md的自主迭代。

![](https://image.gaomeluo.com/blog/2026/06/1781017099.png)

1 个编排者 + 5 个专业 Agent + 6 类 ACP 编码专家（最大 6 并发）、52 个 cron 定时任务、118 个 Skills（33 全局共享 + 85 Agent 专属）、29 个注册 LLM 模型、每天几千次 LLM 调用、2086 行运维脚本 + 半个月 23 次自动恢复。

Agent 自己在进化才是真正有意思的部分：

自己设计通信协议— 两个 Agent "收到/确认"刷了十几轮，Zoe 自主诊断根因，设计三态协议（request → confirmed → final → 静默），smoke test 通过后沉淀到 AGENTS.md

自研 Skill 并发布到 ClawHub— Content 调研 7 个"去 AI 味"工具、A/B 测试、固化为 Skill 发布到 ClawHub，全团队次日自动共享

圆桌讨论产出策略报告— Macro 和 Trading 按协议进行下周 A 股策略讨论，产出含数据快照、仓位建议、止损纪律的完整报告

Task Watcher 异步监控— Agent 承诺"审核通过后通知你"但实际做不到异步回调，Zoe 设计了 cron 级 Task Callback Event Bus 下沉监控

**我的角色是搭好框架、设好约束、在关键节点确认方向——具体的需求发现、方案调研、协议设计、代码实现，都是 Agent 自己完成的。**

##团队：1+5+6 阵型

![](https://image.gaomeluo.com/blog/2026/06/1781017155.png)

#####Zoe（大龙虾）— CTO / 首席编排者

不只是"管理员"。Zoe 负责技术方案设计、任务编排、圆桌主持、系统运维和记忆系统维护——每天 3 次巡检（10:00/14:00/22:00），检查所有 Agent 的 cron 执行状态、workspace 磁盘使用、session 健康度。每周分析各 Agent 的 MEMORY.md 是否超限并执行分层压缩。更关键的是，Zoe 会消费 ainews 提供的技术发现，评估哪些值得应用到我们的系统上，征得我同意后指派 ainews 深入调研，然后自行设计方案、委派 ACP 编码专家实现——从技术发现到方案落地的完整链路。

![](https://image.gaomeluo.com/blog/2026/06/1781017261.png)

每次巡检覆盖 6 大维度：cron 任务执行状态（是否有失败/跳过的任务）、workspace 磁盘使用（文件增长异常检测）、session 大小与健康度、Chrome CDP 进程是否泄露、.learnings/中是否有待处理条目、shared-context/时间戳是否正常（检测 Agent 是否"静默失联"）。

Zoe 最有价值的能力是方案设计——三态通信协议、Task Watcher、通信 Guardrail 框架，都是 Zoe 发现问题后自主设计的。下面是 Zoe 设计 Task Watcher 时的方案讨论：

![](https://image.gaomeluo.com/blog/2026/06/1781017278.png)
#####AI 哨兵（ainews）— 情报中枢

这是我最关心的 Agent。它不是"推新闻"——每天从 100+ 个信息源（GitHub Trending、arXiv、RSS、HackerNews、Reddit 等）采集信息，按 5 星制评估后产出晨报、午间论文解读、晚间趋势分析。7 个 cron 任务覆盖晨午晚三报（08:30/12:00/20:00），每份报告末尾都预留了「改写要点（供 Content 参考）」接口。

更关键的能力是主动评估技术发现对我们系统的影响——本周就发现了 ReMe（记忆管理框架），主动向 Zoe 提出评估建议，从发现到决策到落地，我只需要在关键节点确认，执行全部由 Agent 完成。每日趋势分析中的有价值项目会自动更新到shared-context/tech-radar.json，供 Zoe 每周 Tech Radar 审查：

![](https://image.gaomeluo.com/blog/2026/06/1781017299.png)
![](https://image.gaomeluo.com/blog/2026/06/1781017320.png)

核心采集工具链：github_trending.py（--ai-only过滤 +--since weekly周趋势）、rss_aggregator.py（多源并发采集）、arxiv_papers.py（多关键词搜索）、Tavily（AI 优化搜索首选）、agent-browser（Playwright 驱动，JS 渲染页面采集）。防幻觉硬约束：每条新闻 MUST 带原文 URL，发布前自检可达性，无法交叉验证的标注「单源，建议核实」。

#####交易蜘蛛（Trading）— 量化分析师

团队中任务最密集的 Agent——21 个 cron 任务。20 个原子量化工具（quant.pyCLI）、15 个专属 Skills（68000+ 行代码）、65/35 混合评分模型（65% 工具量化 + 35% AI 判断）。覆盖 A 股全时段（集合竞价→盘中每 10 分钟扫描→尾盘速报）+ 美股（盘前→盘中每 30 分钟→盘后夜报）+ 大宗商品（每小时白天+夜盘）。

核心方法论是四步分析框架：读取 Macro 宏观因子 → 多维评分（技术面 25% / 资金面 30% / 基本面 10% / 情绪面 20% / 市场面 15%）→ 逆向检验（与共识一致吗？若错最可能原因？）→ 输出标的+评分(0-100)+止损位+置信度。硬性规则：NEVER 给出没有止损的买入建议，NEVER 编造数据（工具失败时直接报告原因），置信度 < 60% 标注「低置信度，建议观望」。

![](https://image.gaomeluo.com/blog/2026/06/1781017439.png)

#####Macro（首席经济学家）— 数据驱动的四层映射

提供宏观→传导→国内→市场四层映射因子包，供 Trading 直接引用。9 个 cron 任务覆盖晨报(07:50)→午间(12:30)→财经晚报(18:00)→美股盘前(22:00)→美股收盘(次日05:20)。周日 18:30 率先产出周度宏观复盘，Trading 19:30 引用其结论做市场复盘——形成宏观→微观→技术的递进链路。

分析纪律：每个判断标注数据来源和时效性，区分事实（有数据）和判断（有逻辑无直接数据），标注置信度（高>70%/中50-70%/低< 50%），每个判断提出反面论据。真实案例——伊朗局势分析时，传统框架预测"地缘→避险→黄金涨"，实际油价+14%但黄金-5%。Macro 的分析指出"油价涨幅>10%，通胀逻辑主导，市场交易的是通胀而非避险"。这个洞察被沉淀到 MEMORY.md 成为持久知识。

#####内容蜘蛛（Content）— 内容策略师

不是自己"想"内容，而是从团队情报链中提取素材——ainews 提供改写要点、Macro 提供深度分析、Trading 提供市场观点。9 个 cron 任务驱动 Research→Ideate→Write→Reflect 四阶段流水线：09:00 从 54 个平台热榜（微博/知乎/B站/抖音/百度/头条...）+ X 热点抓取 → 10:30 消费 ainews 改写要点生成创意 → 14:00 产出初稿经 Ripple 传播预测引擎评分后投递 → 22:10 反思。

最有意思的是自主进化能力——发现 AI 味太重后，Content 自行调研"去 AI 味"工具，编写 Skill，发布到 ClawHub，并沉淀为全团队通用能力。从发现问题到解决方案再到发布，Agent 自己走完了整个流程：

![](https://image.gaomeluo.com/blog/2026/06/1781017531.png)

另一个自主进化的产物是X 五篮子热点雷达——Content 最初只抓 AI 热点然后摘抄，经过一次反馈后，它自己设计了覆盖五个维度的情报采集框架，并交叉读取其他 Agent 的当日情报：

![](https://image.gaomeluo.com/blog/2026/06/1781017598.png)

关键约束：**AI/科技部分不超过整份输出的 40%**。这不是我写在 SOUL.md 里的硬编码，是 Content 自己在反思中迭代出来的——它发现产出全是 AI 内容后，主动给自己加了配额限制。

####管家蜘蛛（Butler）— 生活管家

不只是"喝水提醒"——深度集成 Apple 生态（Reminders / Calendar / Health / Notes / Shortcuts），是真正的个人生活助理。7 个 cron 任务：早安问候(08:00)→日程规划(08:30)→5 次喝水提醒（每次换花样：温馨/幽默/知识科普/名人名言/emoji 五种风格随机切换）→健康检查(20:00)→晚安总结(22:00)。

核心理念是不多不少，刚刚好——单次提醒 < 50 字，间隔 ≥1.5 小时，23:00–07:00 仅发送紧急事项。如果用户没回复，不会连续催促：

![](https://image.gaomeluo.com/blog/2026/06/1781017654.png)

####ACP 编码专家阵型

Pi / Claude Code / Codex / OpenCode / Gemini / GPT-5.3-Codex，通过 ACP 协议按需委派，最大 6 并发实例、120min TTL。分析 Agent 不写代码，编码全部通过sessions_spawn委派给专家——每种编码 Agent 都可以开多个并发实例。

![](https://image.gaomeluo.com/blog/2026/06/1781017679.png)

![](https://image.gaomeluo.com/blog/2026/06/1781017692.png)

####团队设计教训

一个关键决策是不要让分析 Agent 直接编码。早期我额外设了 coding、architect、PM 三个技术角色，结果发现这几个角色基本没什么实际产出——它们的能力和 Zoe + ACP 编码专家的组合高度重叠，反而增加了通信复杂度和调试成本。后来全砍了，编码通过 ACP 委派给 Claude Code 等专业工具。PM 和架构师？Zoe 兼任就够了。

复杂度随人数快速上升。3 个 Agent = 3 对交互关系，6 个 = 15 对。整个系统从零到 6 个 Agent 稳定运行，花了大约半个月的下班时间——每加一个新 Agent 都需要半天到一天的调试，处理和现有 Agent 的通信冲突、共享资源竞争、规则兼容。

##一天是怎么过的

从凌晨 03:00 的自动备份到 23:45 的全团队反思，52 个 cron 任务覆盖 A 股 + 美股双时区自动轮转。周日还有 Macro → Trading → Trading 的三级递进周报。

每天结束时，每个 Agent 独立反思当天的.learnings/待审条目，Zoe 最后汇总全团队产出：

![](https://image.gaomeluo.com/blog/2026/06/1781017751.png)

从凌晨 03:00 的自动备份到 23:45 的全团队反思，52 个 cron 任务覆盖 A 股 + 美股双时区自动轮转。周日还有 Macro → Trading → Trading 的三级递进周报。

每天结束时，每个 Agent 独立反思当天的 .learnings/ 待审条目，Zoe 最后汇总全团队产出：

![](https://image.gaomeluo.com/blog/2026/06/1781017789.png)

##让这套系统跑起来：三个核心工程问题

上面展示的是最终效果。但从"装好 OpenClaw"到"系统流畅运作"，再到"Agent 自主进化"——中间有巨大的鸿沟。三个核心工程问题，每一个都不是"写好 prompt"能解决的。

##核心问题一：上下文是 Agent 的操作系统

####问题：Agent 系统的热力学第二定律

不加约束，entropy 只增不减。持续运行的 Agent 系统会确定性地走向崩溃——不是"可能"，是"一定"。

Agent 就像一个没有操作系统的进程：它能处理输入、产出输出，但谁来管理它的内存（上下文）？谁来做垃圾回收（Session 清理）？谁来防止 OOM（膨胀保护）？不设计就没有人管。

三个真实事故，按严重度排序：

######P0 — 全团队瘫痪 8 小时

ainews 的 session 因为连续处理新闻和论文累积到235K tokens。Gateway 启动时对所有 session 做 compaction，这个 session 永远超时 → crash → macOS 守护进程ThrottleInterval=1每秒重启 → 无限循环。所有 Agent 全部离线。

修复要四层：手动清理膨胀 session →ThrottleInterval1→10 →idleMinutes180→30 →exec.securityfull→allowlist。这不是某一个参数的问题，是四个独立的防线全部缺失。

######P1 — 3500 字报告被框架"优化"到 800 字

交易蜘蛛的收盘速报包含完整的数据表格、资金流向、个股评分。OpenClaw 在文本超过textChunkLimit时自动做 content compaction（LLM summarize），数据表格被"智能压缩"掉了。框架认为"帮你优化了"——但在数据密集场景下，AI 的"智能"是灾难。

######P2 — 信息过载后关键规则失效

当 SOUL.md 里堆满了各种操作规范、当 session 膨胀到几万 tokens，Agent 开始"选择性遵守"规则。管家蜘蛛越界做投资分析。交易蜘蛛忽略数据验证规则。不是模型变笨了，而是关键信息被噪声淹没了——这是 Context Engineering 要解决的根本问题。

解决：双层控制 — Context Engineering + Harness

两层协同，两个都不能少。

#####第一层 — Context Engineering（设计 Agent 的信息架构）

设计 Agent 每次推理时看到的完整信息结构——系统级的信息架构设计：

SOUL.md放在 system prompt 最前面，是 Agent 的"宪法"——身份定义、决策框架、绝对禁止项。保持精简，只放最核心的约束

AGENTS.md跟在 SOUL.md 后面，定义操作规范和协作协议

Skills通过extraDirs配置按需加载——Trading 有 15 个 Skills 共 68000+ 行内容，不可能全放在 system prompt 里。只在 Agent 需要用到某个 Skill 时才注入上下文

shared-context/是跨 Agent 的共享状态，Agent 通过工具主动读取

Obsidian Vault是冷存储，归档产出但不参与推理

LLM 的上下文窗口不是等价的。system prompt 前面的信息权重远高于后面的。session 膨胀到几万 tokens 后，早期消息的影响力被稀释——类似操作系统的内存管理：热数据放缓存，冷数据放磁盘，关键数据常驻内存。

Trading 的 15 个 Skills 中，stock_analysis（技术面评分）在每日扫描时才需要，bilateral_analysis（龙虎榜分析）只在异动时触发。全部常驻上下文的话，噪声淹没了真正重要的规则。通过extraDirs按需注入，每次推理只加载相关的 1-3 个 Skill。

规则措辞必须面向最弱的模型。多模型 fallback 环境下（GPT-5.4 超时 → Qwen3.5+ → Ollama qwen 3:8b） ，规则遵循率随模型能力递减：

"建议不要编造数据"→ GPT-5.4 基本遵守，Qwen3.5+ 偶尔遵守，qwen3:8b 几乎无视

"MUST: 不编造数据"→ 各模型遵守率显著提升

"MUST + P0 + NON-NEGOTIABLE"→ 即使弱模型也能保持较高的遵守率

多模型 fallback 时，不知道哪次推理会用弱模型，所以所有关键规则都要按最弱模型的理解能力来写。显式 > 隐式，硬规则 > 软建议。

#####第二层 — Harness（框架自动管理）

Agent 7×24 运行，session 会持续膨胀——你设计得再好，运行一天之后上下文就变了。框架替 Agent 管，OpenClaw 的 harness 配置提供自动化的上下文生命周期管理：

![](https://image.gaomeluo.com/blog/2026/06/1781017956.png)

只有 Context Engineering 没有 Harness，session 膨胀到 235K tokens 后一样崩溃；只有 Harness 没有 Context Engineering，所有信息堆在一起、关键规则被噪声淹没。Context Engineering 定义信息的结构，框架管理信息的生命周期。

实际的openclaw.json配置（每个参数背后都是真实事故）：

{  "compaction": {    "mode": "safeguard",    "memoryFlush": {      "enabled": true,      "softThresholdTokens": 40000,      "prompt": "Distill to memory/YYYY-MM-DD.md. Focus: decisions, state changes, lessons, blockers."    }  },  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },  "session": {    "reset": { "mode": "daily", "atHour": 5, "idleMinutes": 30 },    "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 }  },  "hooks": {    "bootstrap": ["self-improving-agent"]  }}

四个机制的执行顺序很重要——compaction 先于 contextPruning，确保有价值的内容先被提取到memory/，再被清理。self-improving-agent 的 bootstrap hook 在新 session 启动时触发，把.learnings/和MEMORY.md注入上下文——这是 Agent"记住上次学到的东西"的关键机制。

跨会话记忆恢复链（Agent 重启后如何"想起来自己是谁"）：

> 新 session 启动  ↓ self-improvement hook: 读 SOUL.md → AGENTS.md → MEMORY.md → .learnings/  ↓ memorySearch: 从 memory/ + sessions 中检索与当前任务相关的历史上下文  ↓ 读取 shared-context/ (团队实时状态)Agent 恢复到"知道自己是谁、做过什么、团队现在在干什么"的状态

Agent 不需要"记住"所有对话——memoryFlush 提取的是 decisions/lessons/state changes，不是完整对话。memory/中的文件通常只有几百行，而原始 session 可能有几万 tokens。

##核心问题二：让 Agent 真正"记住"并"成长"

####问题：Agent 今天犯的错，明天还会犯

这是一个比上下文管理更深层的问题。chatbot 每次对话从零开始，所以它每次都犯同样的错是正常的。但如果你的 Agent 7×24 运行、每天处理几千次 LLM 调用，你会无法接受它反复犯同一个错误。

交易蜘蛛5 次把龙虎榜 API 字段名搞错——BILLBOARD_BUY_AMT写成BUY_AMT，每次 session 重置后记忆丢失，下一次又犯。用户纠正"昨天建议买军工，今天跌了就转空"，Agent 当场改了，但三天后遇到类似场景又给出同样的单向建议。

chatbot 和 Agent 的分水岭就在这里：Agent 应该能从错误中学习，并且下次不犯。但怎么实现？

####解决：五层记忆 — 从人类认知模型中借鉴

![](https://image.gaomeluo.com/blog/2026/06/1781018059.png)

设计记忆系统时，我参考了人类记忆的分层模型：工作记忆（短期）→ 长期记忆（经验）→ 程序性记忆（技能）。Agent 的记忆也应该有不同的时间尺度和管理方式：

![](https://image.gaomeluo.com/blog/2026/06/1781018094.png)

层与层之间的衔接才是关键——这形成了一个完整的自主进化循环。

记忆自主迭代——6 步循环

这是整个系统最核心的机制。没有这个循环，Agent 只是 chatbot；有了这个循环，Agent 才是真正的 Agent。

记忆自主迭代 — 6 步循环
1）触发事件
操作失败 · 用户纠正 · 发现更优做法 · 需要新能力
任意一种都会触发即时记录
2）.learnings/ 即时记录
ERRORS.md · LEARNINGS.md · FEATURE_REQUESTS.md
状态: pending — 低成本、高频率、不审查直接写入
3）每日反思 Cron (23:00-23:45)
扫描 .learnings/ 所有 pending 条目 → 评估复现频率和重要性 → 验证 ≥3 次？
✓ ≥ 3 次 promote 到 MEMORY.md
✗ < 3 次 保留 pending，继续观察
4）promote 到 MEMORY.md
长期记忆 · < 3000 tokens 硬上限 · 超限时 Agent 自主精简（合并相似、删除过时）
5）下次 Session 加载
self-improvement hook · bootstrap 注入 · 检查 .learnings/ · 引用历史经验
6）Agent 行为改进
下次遇到同样问题时自动避免 — 迭代完成
SOUL.md 修改— 需要用户确认（Agent 不能自己改自己的"宪法"）

![](https://image.gaomeluo.com/blog/2026/06/1781018135.png)

Agent 可以自主更新.learnings/、MEMORY.md、memory/、knowledge/——但绝对不能改 SOUL.md。SOUL.md 是身份和硬约束，修改需要用户确认。我们真的遇到过 Agent 把自己的"人格"改松的情况——行为立刻变得不可控。

Zoe 每周还会做记忆系统维护——分析各 Agent 的 MEMORY 状态，做归档和压缩：

![](https://image.gaomeluo.com/blog/2026/06/1781018156.png)

L5 的 ontology 知识图谱记录实体关系（Agent/Task/MarketInsight/Decision），vector_store.db提供语义级检索——Agent 不需要记住精确措辞，通过向量相似度找到相关历史决策。

####真实进化案例

> 
用户纠正: "昨天建议买军工，今天跌了就转空"  ↓即时记录 (.learnings/):  "[LRN-20260303-001] correction | priority: high | status: pending   军工策略在地缘利好场景下未充分强调短线拥挤与顶背离风险   Suggested Action: 条件单模板 — 入场带失效位 + bullish/base/bear 三情景"  ↓每日反思 cron (23:30): promote 到 MEMORY.md  ↓MEMORY.md: "❌ 事件驱动标的必须用条件单模板"  ↓三周后遇到类似板块轮动:  交易蜘蛛直接引用了这条经验

这不是我写的规则——是 Agent 从纠正中自己提炼出方案，自己写入长期记忆。每日反思 cron 会审查.learnings/中的 pending 条目并决定是否 promote：

![](https://image.gaomeluo.com/blog/2026/06/1781018190.png)

更多真实进化记录：

![](https://image.gaomeluo.com/blog/2026/06/1781018211.png)

记忆系统还在进化

记忆系统不是"设计好就不变的"。最近的一个例子：

Zoe 每周生成Tech Radar 报告，从 ainews 的情报中提取技术趋势，分为 Adopt/Trial/Assess 三级。本周报告中，ainews 发现了（Agent 记忆管理框架），Zoe 立刻评估其与现有系统的对比：

![](https://image.gaomeluo.com/blog/2026/06/1781018230.png)

![](https://image.gaomeluo.com/blog/2026/06/1781018242.png)

结论：ReMe 架构优秀（223K → 1.1K tokens，99.5% 压缩率），但与 AgentScope 深度绑定，直接接入不划算。走"参考设计自研"——先实现收益最高的tool_result 压缩（超长工具输出自动截断 + 外存，上下文占用降 80%+），再逐步引入结构化摘要模板和异步持久化。

用户同意后，Zoe 立即通过 ACP 协议委派 Claude Code 做架构评审：

![](https://image.gaomeluo.com/blog/2026/06/1781018260.png)

这个过程本身就是多 Agent 协作的真实案例：ainews 情报发现 → Zoe Tech Radar 评估 → 用户确认 → ACP 委派编码专家 → 分阶段落地，涉及 3 个 Agent + 1 个 ACP 编码专家。

####假设驱动的迭代 — 从修 Bug 到科学方法

记忆系统最有深度的进化不是修某个具体的 Bug，而是 Agent 学会了主动提出假设并验证——这是从"被动修复"升级到"主动改进"的关键一步。

每日反思中，Agent 会基于当天的工作提出 3-5 条可验证假设，晚间反思时用实际数据评估：

![](https://image.gaomeluo.com/blog/2026/06/1781018304.png)

验证通过的假设被固化为规则或 Skill，验证失败的被标注原因并淘汰。Agent 不只是"犯错后改正"，而是在主动寻找改进空间——从 reactive 到 proactive 的跃迁。

####自主进化机制：哪些是 OpenClaw 自带的，哪些是我们加的

理解这套记忆系统需要区分框架能力和运营优化——很多人问"OpenClaw 是不是开箱即用"，答案是"框架能力开箱可用，但要跑好需要大量运营层设计"。

![12132.png](https://image.gaomeluo.com/blog/2026/06/12132.png)

##核心问题三：多 Agent 协作是协议问题，不是群聊问题

####问题：把 Agent 放进群聊 ≠ 协作

大多数人对 Multi-Agent 的直觉是"给几个 Agent 一个聊天群，它们就能协作"。实际上，这和把几个工程师拉到一个没有流程规范的群聊里没有区别——有沟通能力不等于有协作能力。

Macro 和 Trading 在"伊朗局势对 A 股影响"上互相"收到/确认/感谢"刷了十几轮。分析早就做完了——Macro 判断"油价涨幅 >10% → 通胀逻辑主导 → 黄金反跌"（实际走势：油价 +14%，黄金 -5%，判断准确）——但分析之后两个 Agent 客套的 token 比分析本身还多。

根因不是"Agent 太客套"。根因是缺乏终态协议。Discord 配置中requireMention=true表示 Agent 只在被 @ 时才回复。当两个 Agent 互相 @，A → B → A → B......这就是经典的 ACK storm，和 TCP 协议早期遇到的问题是一样的。

解法也是一样的：设计协议。不是告诉 Agent "少说话"——实际观察中"建议"式规则在弱模型上几乎不起作用——而是设计一个有状态机的通信协议。

解决：协议级设计 → 真实案例

实例：下周 A 股策略圆桌讨论

Zoe 发起圆桌 → Macro 提供宏观研判 → Trading 回应策略建议 → 按固定三态协议有序收敛：

Step 1 — Zoe 发起议题 + Macro/Trading 按协议 confirmed：

![](https://image.gaomeluo.com/blog/2026/06/1781018452.png)

Step 2 — Trading 基于 Macro 研判给出详细策略（confirmed 输出）：

![](https://image.gaomeluo.com/blog/2026/06/1781018475.png)

Step 3 — Trading 输出 final（DRI 结论 + 完整推理过程）：

![](https://image.gaomeluo.com/blog/2026/06/1781018492.png)

Step 4 — 协议收敛（final 后全员静默）：

![](https://image.gaomeluo.com/blog/2026/06/1781018508.png)

协议设计

固定三态通信协议 + V1 线程协议（被刷屏教训后设计，已迭代到 V1 版本，沉淀到 AGENTS.md）：

> 固定三态协议（强制）━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━[request]    @对方 + ack_id + 期望动作 + 截止时间             模板: @agent [state=request] [ack_id=topic-v1-202603081430][confirmed]  @发起方 + 相同 ack_id + 版本号/生效时间/关键结论             模板: @requester [state=confirmed] [ack_id=...] 版本=v2[final]      @相关方 + 相同 ack_id + 终态收敛（全线程仅 1 条）             发出后全员进入静默，"收到/感谢/OK" → NO_REPLYV1 线程协议（2026-03-08 起）━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━• 同一线程只允许一个 ack_id，新一轮必须新开• final 后禁止续话；必须补充时优先 edit 既有消息• sessions_send 超时 ≠ 失败 → 同一 ack_id 不得重试• 同一内容最多重试 1 次；第二次超时 → shared-context/ 文件投递⏰ 5 分钟无 confirmed → 催办 1 次 · 10 分钟仍无 → 升级 Zoe 仲裁

子线程策略：多轮协作的内容任务默认开专用子线程（命名:<主题>-<负责人>-<日期>），主频道只同步三次状态：[Dispatch]→[ACK]→[DraftReady]。

三种通信机制：

![](https://image.gaomeluo.com/blog/2026/06/1781018593.png)

shared-context/的核心价值：从消息驱动升级到状态驱动。Trading 不需要每次问 Macro"今天宏观怎么样"，直接读intel/finance_news_latest.json。sessions_send 适合实时触发，但不可靠（超时、重复）——关键数据走文件才可追溯。

Zoe 主导了shared-context/的标准化——从最初零散的文件目录，演进为结构化的跨 Agent 协作基础设施：

> shared-context/├── agent-sessions/       # ACP 编码专家的 session 状态（30 个 claude/codex session）├── agent-runs/           # Agent 运行记录├── monitor-tasks/        # Task Watcher 持久化存储│   ├── tasks.jsonl       # 任务注册（小红书审核/ACP完成/cron健康等）│   ├── watcher.log       # 轮询日志│   ├── audit.log         # 审计追踪│   ├── dlq.jsonl         # 死信队列（处理失败的任务）│   └── notifications/    # 通知记录├── intel/                # 情报共享（finance_news_latest.json 等）├── roundtable/           # 圆桌讨论记录├── decisions/            # 重大决策存档├── job-status/           # cron 任务状态├── knowledge-base/       # 共享知识├── status/               # 各 Agent 当前状态 JSON├── tech-radar.json       # 技术雷达（Adopt/Trial/Assess 三级）├── memory-maintenance-latest.json  # 最近一次记忆压缩报告└── PROJECT_STATUS.md     # 项目全局状态（Zoe 维护）

这不是一次性设计出来的——是 Zoe 在实际运营中逐步标准化的。每增加一个新的协作场景（ACP 编码、Task Watcher、Tech Radar），Zoe 就在shared-context/中增加对应的标准化目录和文件格式。

DRI 原则：一个问题只有一个 Directly Responsible Individual 出最终结论。非 DRI 只能补充，不能覆盖。Zoe 组织和归档，不替代专业 Agent 出专业意见。

协议优化后的自主反思

协议落地后，Agent 不只是"按规则执行"——它们会主动反思效果并提出改进方向：

![](https://image.gaomeluo.com/blog/2026/06/1781018699.png)

![](https://image.gaomeluo.com/blog/2026/06/1781018713.png)

从初版"禁止客套"到 V1"线程级收敛"，每一步协议优化都来自 Agent 的.learnings/经验沉淀——这正是五层记忆系统的价值所在。

最新进展（2026-03-08）：Zoe 刚完成了一次全员通信标准下沉——修改了 26 个文件（6 个 Agent 的 AGENTS.md + SOUL.md + 相关 Skill 文档），把通信硬规则统一写入每个 Agent 的本地配置。同时执行了全员通信路径审计，识别出main/SOUL.md与圆桌 Thread 规则的冲突并修复。

#####五条联动链路

Agent 之间不是各干各的，是上游主动为下游准备接口：

![](https://image.gaomeluo.com/blog/2026/06/1781018758.png)

Tech Radar 真实示例——ainews 每日维护的技术雷达，分为 Adopt（已验证可用）、Trial（值得尝试）、Assess（持续观察）三级：

`{  "adopt": [    { "name": "MCP Protocol", "reason": "MCP 2.0 发布，三大框架推进标准化" }  ],  "trial": [    { "name": "OpenAI Skills Catalog", "reason": "582→947 星，可参考 Skill 格式" },    { "name": "ReMe Agent 记忆管理", "reason": "独立记忆工具包，评估替代方案" }  ]}`

Zoe 消费 Tech Radar 后做源码级评估，判断对现有系统的影响——本周就基于此发起了 ReMe 评估并委派 Claude Code 落地 PoC。

安全边界 — Agent 能改什么、不能改什么

安全在于限制 Agent 能触碰的范围：

![](https://image.gaomeluo.com/blog/2026/06/1781018802.png)

####Task Watcher — 解决"Agent 说了会做但实际没做"

Agent 最难发现的问题不是崩溃或报错，而是**"说了会做但实际没做"**。Content 蜘蛛发完小红书说"审核通过后通知你"——但 session 已经结束了，它根本做不到异步回调。更隐蔽的是 cron 任务"执行了"但零产出——反思也说"一切正常"。

Zoe 主导设计了一套Task Callback Event Bus——插件式架构，5 个组件各司其职，把异步监控下沉到 cron 级别：

> 注册任务 → tasks.jsonl（shared-context/monitor-tasks/）                ↓Cron (*/3 min) → Watcher → Adapter 检查状态 → 状态变化？                                                   ↓ Yes                                      Policy 决策 → Notifier 发 Discord

Adapter 插件：小红书审核状态、GitHub PR、ACP 编码任务——想监控什么加一个 Adapter

Policy 策略：通知频率、升级、重试都可配

6 小时超时保护（默认），3 次投递失败自动升级，不会死循环、不会卡死

这套系统由 Zoe 自行设计 → 委派 Claude Code 实现 →130 个单元测试→ 开源发布为 OpenClaw Skill。从需求到代码到测试到发布，我只在方案评审时介入，其余由 Agent 团队完成。

通信 Guardrail + 异步状态链（最新进展）

Task Watcher 解决了"异步任务有没有产出"的问题，但更深层的问题是：Agent 之间的通信本身缺乏系统级约束。message被误用为内部控制面、timeout不等于失败却被当作失败处理、completed和delivered无法区分——这些都不是靠文档规则能解决的。

Zoe 自主设计并委派 ACP 编码专家实现了一套通信 Guardrail + 请求生命周期状态链（~3000 行 Python），核心组件：

![](https://image.gaomeluo.com/blog/2026/06/1781018858.png)

设计决策：

timeout ≠ failed：超时只是控制面观察结果，任务可能已经在执行——引入ambiguous_success语义

completed ≠ delivered：工作完成 ≠ 结果送达，分离两个状态避免投递失败覆盖工作成果

通信生命周期独立于业务 TaskState：不污染现有 Task Watcher 的submitted → completed → failed状态机

文件级状态源：先用shared-context/agent-requests/跑通，不依赖 Redis/MQ 等重量级设施

这套系统从"Zoe 发现问题 → 设计方案 → 委派编码 → 代码实现 → 测试验收"，我只在方案确认环节介入，其余环节由 Agent 自主完成——是 Agent 从"执行者"进化为"系统设计者"的典型案例。

整体架构总结 — 五层工程视角
回过头看，整个系统的核心设计可以归结为五个层次：

![](https://image.gaomeluo.com/blog/2026/06/1781018882.png)

这五层不是独立的——它们相互依赖、相互强化。通信层的三态协议是 Zoe 在编排层中发现问题后设计的。记忆层的压缩策略是自愈层的一部分。进化层的 Skill 自研能力来自通信层的跨 Agent 协作。

##跑了半个月之后的认知变化

1. 90% 的时间花在工程问题上，不是 AI 问题上。Session 膨胀、消息风暴、配置被改坏——解法在分布式系统和 SRE 经典知识中，不在 AI 论文里。Agent 系统的瓶颈不是模型能力，是基础设施的成熟度。模型升级是锦上添花，通信协议、记忆架构、自愈机制才是决定成败的底座。

2. AI 的"智能"在生产环境中经常是灾难。Discord 消息被"智能压缩"砍掉了数据表格，Agent "智能修复"自己的配置改坏了工具名，管家蜘蛛在 session 膨胀后"智能地"越界做投资分析。在需要精确、可预测输出的场景下，"智能"反而是负面特性。显式 > 隐式，硬规则 > 软建议，可预测 > 可解释。

3. 持续运行的系统必然退化——不是 bug，是热力学。配置堆积、记忆过长、session 膨胀、磁盘撑满——这些会确定性地发生。对策不是"一次设置好"，而是建立反退化机制栈：compaction 管 session，maintenance 管记忆，heartbeat-guardian 管配置，巡检管行为漂移。用 Agent 运维 Agent，用 cron 监控 cron——每层兜底机制都需要自己的兜底。

4. 协作是协议问题，不是 prompt 问题。两个 Agent 放在同一个 Thread 里不写协议，等价于两个进程共享内存不加锁。Macro 和 Trading 用同一个模型、同一个知识库，刷屏时每条回复都言之有物——加上三态协议后产出从十几轮废话变成了一份可执行策略文档。模型没变，变的是规则。

5. Agent 最大的价值不是执行力，而是"参与设计"。当 Agent 从"你让我做什么我就做什么"进化到"我发现了问题，调研了三种方案，推荐 B，你确认我就落地"——这时它才真正成为团队成员。十个进化案例里，大多数的起因不是"我让它做什么"，而是"它遇到了问题然后自己想办法"。系统设计的目标不是让 Agent 听话，而是让它有能力自己解决问题。

##如果你也想试试

不需要照搬 6 个 Agent。从 1 个开始。整个系统从零到 6 个 Agent 稳定运行花了大约半个月的下班时间——不是开发时间，是调试和填坑时间。

####第 1-2 天：先让 1 个 Agent 稳定运行

最重要的三件事：

1. SOUL.md 保持精简，只放核心约束。把它当"宪法"不是"操作手册"——非核心规则放 Skills 按需加载

2. Session 管理参数第一天就设好：idleMinutes=30、pruneAfter=7d、maxDiskBytes=100MB。不设 = 定时炸弹

3. 从第一天就启用.learnings/+ 反思 cron。没有反思的 Agent 只是 chatbot，不是 Agent

####第 3-5 天：加第 2 个，开始处理协作

4. Discord 配置比你想的复杂 10 倍。每个 Agent 需要独立 Bot 账号。requireMention、textChunkLimit、delivery.mode、子 Thread 创建、Bot 权限——每个都有坑，而且组合起来的症状让你根本猜不到是哪个配置的问题

5. 协作需要协议，不是群聊。两个 Agent 在群聊里会互相 ACK 到死。固定三态协议 + ack_id + 超时升级，两个都不能少

####第 2 周起：逐步扩展到完整阵型

6. 规则用最强措辞，面向最弱模型。LLM 对"建议"式规则的遵循率远于"MUST"，尤其在长上下文和弱模型上

7. "成功"要严格定义。投递成功 ≠ 归档成功，无报错 ≠ 有产出，Agent 说"正常" ≠ 真正正常

8. Agent 不回复是常态——准备好 Task Watcher 和重试机制

9. shared-context/ 是协作基石——sessions_send不可靠（超时、重复），关键数据走文件才可追溯

10. 每加一个 Agent 都需要半天到一天的调试。急于求成 = 浪费更多时间在排查上

装好不难，跑通也不难。难的是：让 6 个 Agent 在没有你盯着的时候也能稳定产出、自我修正、协作不打架。这不是 prompt 问题，是系统工程问题。

从理解原理开始

如果你想先理解 OpenClaw 的核心原理再动手，可以看看——~2700 行 Python 实现了 OpenClaw（43 万行 TypeScript）的 11 个核心架构模式：Gateway Hub-and-Spoke、Workspace 契约文件、Agent Loop、Skills 触发、Compaction 上下文管理、Multi-Agent & Spawn、Heartbeat、Cron、Hooks EventBus、自动反思。不需要看原始代码就能理解"为什么要这么设计"。

##附录：技术栈快速参考

> 以下是正文中提到的技术组件的集中索引，方便快速查阅。详细说明见正文对应章节。

LLM 模型分层

![](https://image.gaomeluo.com/blog/2026/06/1781019008.png)

Fallback 链：gpt-5.4 → k2.5 → qwen3.5-plus → ollama/qwen3:8b

核心 Harness 配置

```
{  "compaction": { "mode": "safeguard", "memoryFlush": { "softThresholdTokens": 40000 } },  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },  "session": { "reset": { "atHour": 5, "idleMinutes": 30 }, "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 } },  "acp": { "maxConcurrentSessions": 6, "ttlMinutes": 120 }}
```

数据源

![](https://image.gaomeluo.com/blog/2026/06/1781019057.png)

部署配置

![](https://image.gaomeluo.com/blog/2026/06/1781019097.png)

]]> 0 https://blog.gaomeluo.com/archives/OpenClaw-6agent/#comments https://blog.gaomeluo.com/feed/archives/OpenClaw-6agent/ 养虾实战教程：教你如何用 OpenClaw 搭建一套完整的、闭环的跨境运营工作流 https://blog.gaomeluo.com/archives/OpenClaw-work/ https://blog.gaomeluo.com/archives/OpenClaw-work/ Tue, 09 Jun 2026 22:49:00 +0800 光山人跨境运营不再碎片化！OpenClaw帮你一键串联引流、识别、承接、分析、闭环五大环节，实现全自动工作流。 **核心内容：** 1. OpenClaw如何突破传统RPA局限，用理解能力实现智...]]>

> 跨境运营不再碎片化！OpenClaw帮你一键串联引流、识别、承接、分析、闭环五大环节，实现全自动工作流。

**核心内容：**
1. OpenClaw如何突破传统RPA局限，用理解能力实现智能跨境运营
2. 五大环节详细拆解：从Phantombuster批量获客到SaleSmartly智能清洗
3. 完整指令示例与实战效果对比：人工操作VS智能自动化

做跨境的人大概都有这个感受：工具很多，但每个工具都是只能处理其中一个环节，无法去真正实现闭环。

这篇文章要做的，就是用OpenClaw 把五个环节串成一条真正跑得动的链路：

**引流获客 → 客户识别 → 客户承接 → 数据分析 → 自动化闭环**

整套流程跑通之后的状态就是：你只需要说一句话，OpenClaw就在后台把活干完了。

下面逐个环节拆开来讲，每一步用什么工具、怎么下指令、能解决什么问题，一次性讲清楚。

##前题工作
你需要一台装了OpenClaw的机器，我这里选择的是云服务器，参考教程《[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")》

##为什么选择OpenClaw？

传统 RPA 的逻辑是录制操作路径。因此界面一更新、流程一变，脚本就得重新维护。

这类工具能做触发和连接，但没有理解能力，遇到没预设到的情况只能跳过或报错。

OpenClaw 的不同在于它带着理解能力在跑。分析聊天记录、判断客户意向这件事，RPA 做不了，而OpenClaw 一句话搞定！

![](https://image.gaomeluo.com/blog/2026/06/1781015780.png)

##OpenClaw 如何跑通跨境工作流？

五个环节，四个Skill，直接给你一套能真正落地的方案。

###环节 1：引流获客

跨境获客的核心需求是能批量触达、又不用一个个手动去找的方法。

这一步用的是 Phantombuster，一个支持从 LinkedIn、Instagram、Facebook Group 等平台 批量抓取公开信息的社媒采集工具，覆盖主页、联系方式、发帖内容。

####安装指令：

> "帮我安装 Phantombuster 的技能包：https://clawhub.ai/gora050/phantombuster-integration"

接入 OpenClaw 后，你可以直接对它说：

> "去抓一下这个 Facebook Group 里过去一周发过'寻找供应商'或'looking for manufacturer'的帖子，整理成表格，把用户名和主页链接给我。"

OpenClaw 会调用 Phantombuster 完成采集，返回一份可以直接用的线索列表。

如果你做的是独立站 或 B2B，还可以让它监控竞品品牌词下面的评论区，把主动提问的用户筛出来 —— 这些人本来就有采购意向，获客成本要低得多。

这一环节的价值在于： 把过去靠人肉刷帖、靠运营团队一条条记录的工作，压缩成一句指令。线索质量不变，时间成本直接砍掉。

![](https://image.gaomeluo.com/blog/2026/06/1781015869.png)

###环节 2：客户识别与线索清洗

线索进来之后，最头疼的事不是数量不够，是真假难分。

高意向客户 和 随手发来"how much"就消失的僵尸询盘混在一起，光靠人工筛选，一天能处理的量很有限。

这一步接入 SaleSmartly Skill，让 OpenClaw 直连你的 WhatsApp / Facebook / Instagram 多渠道客户池，自动做第一轮清洗。

####安装指令：

> "帮我安装这个 SaleSmartly 的技能包：https://github.com/Sale-Smartly/salesmartly-api-skills.git”

接入OpenClaw之后，指令可以这样写：

> "每小时拉一次 SaleSmartly 里新进线的客户。分析聊天内容，如果提到了具体产品规格、MOQ、目标市场或物流时效，打上【高意向-B端】标签，分配给销售 A；如果只有打招呼、乱码或单个词的消息，打【低价值】标签，转机器人接管。"

整个过程不需要盯着后台，OpenClaw 在后台持续跑，完成拉取、分析、打标、分配四步操作。

***还有一个很实用的场景：让它扫描近期聊天记录，把"提到竞品但还没下单"的客户单独圈出来，这批人是最值得重点跟进的潜在转化。***

**这一环节的价值在于**： 销售不再需要在杂乱的进线里自己做判断，OpenClaw 已经替你把精准线索单独摆出来了。

![](https://image.gaomeluo.com/blog/2026/06/1781016003.png)

###环节 3：客户承接

线索分好了，接下来是怎么接住。

跨境运营有两个典型的承接难题：

一是时差导致响应慢

二是 WhatsApp 封号导致对话中断

时差问题：可以用 Twilio 解决，让OpenClaw在无人值守时自动接管。

####安装指令：

> "帮我安装这个 Twilio 的技能包：https://clawhub.ai/byungkyu/twilio-api”

完成安装后，对 OpenClaw 说：

> "识别每个进线客户的所在时区。如果客户发消息时当前是北京时间 22:00 到 09:00 之间，自动用 Twilio 回复一条本地化消息：'Hi! Our team is currently offline but will get back to you by [客户本地时间的下一个工作日早上 9 点]. We'll make sure not to miss you.' 同时把这条会话加入待跟进列表，等团队上线后优先处理。"

客户收到的不是石沉大海，而是一个明确的预期时间。团队上线后也不会遗漏，优先处理名单已经备好了。

![](https://image.gaomeluo.com/blog/2026/06/1781016078.png)

####封号风控：

这一步可以直接复用 环节2 已经接入的SaleSmartly，无需额外安装。

####示范指令：

> 持续监控所有 WhatsApp 设备的在线状态。一旦设备 003 掉线，立刻从 SaleSmartly 拉取该设备上所有'沟通中'状态的客户，查他们是否留有 Facebook Messenger 或 Email，有的话自动发送转移消息：'Hi, our WhatsApp line is under maintenance, please continue here.' 没有的话，单独列一份名单给我人工跟进。"

封号发生的瞬间，流量就已经在往备用渠道转了，不需要等你反应过来再去手动操作。

这一环节的价值在于： 客户接得住、接得快，就算渠道出问题客户也不会丢。

###环节 4：数据分析与洞察

数据跑了一段时间，最常见的需求是两类：

一是广告效果回溯
二是团队绩效查看

####广告回溯：

做投放的人都有这个痛点——广告后台只能看点击和展示，看不到进线之后发生了什么。

接入 SaleSmartly 之后，这个断层可以在 OpenClaw 被打通。

####示范指令：

> "导出过去 14 天通过【TK - 黑五】分流链接进线的所有客户。交叉分析他们的聊天记录，整理出这批客户最常提到的三类抗拒点，以及最终成单和未成单客户在对话上的差异，生成一份简报。"

这份简报可以直接反哺你的广告素材和落地页文案，形成投放 → 进线 → 分析 → 优化的真正闭环。

####绩效查看：

> "拉取上周所有客服在 WhatsApp 和 FB Messenger 的平均首次响应时长和会话完结率。把响应最快的前三名，和平均响应超过 5 分钟的客服名单分别列出来，直接生成报表。"

"拉取上周所有客服在 WhatsApp 和 FB Messenger 的平均首次响应时长和会话完结率。把响应最快的前三名，和平均响应超过 5 分钟的客服名单分别列出来，直接生成报表。"

###环节 5：自动化与定时任务

前四个环节如果还需要每次手动触发，严格来说还不算闭环。这一步要做的，是让整套流程自动跑起来。

这一步用 Zapier 来驱动。

####安装指令：

> "帮我安装这个 Zapier的技能包：https://clawhub.ai/ivangdavila/zapier"

定时触达指令如下：

> "在 Zapier 里设置一个定时任务：每周一早上 10 点，自动给打了【高意向-B端】标签但 7 天内没有成单的客户，发送一条跟进消息：'Hi, just checking in — have you had a chance to review our quote? Happy to adjust based on your needs.'""在 Zapier 里设置一个定时任务：每周一早上 10 点，自动给打了【高意向-B端】标签但 7 天内没有成单的客户，发送一条跟进消息：'Hi, just checking in — have you had a chance to review our quote? Happy to adjust based on your needs.'"

可以再设置一个月度任务：

> "每月 1 号，给过去 30 天内有过购买记录的客户触发一条复购提醒，消息模板用【复购-通用版】。"

这一环节价值：触达、报表、数据沉淀全部定时自动跑，工作流从"你去触发"变成"它自己转"，你只需要看结果。

![](https://image.gaomeluo.com/blog/2026/06/1781016268.png)

##注意事项与避坑指南

在跑通这套工作流之前，有几个注意事项你要知道。

**先安装Skill-Vetter**

它的作用是：识别 Skill 插件是否在申请不合理的系统权限，自动揪出代码中的危险信号（如尝试访问敏感文件）。

后续你在安装任何 Skill之前都可以先让他帮忙审查一遍，防止个别开发者无意中留下的后门 或者 不安全代码。

###不要一开始就把所有权限全放开

OpenClaw 接入 API 之后，理论上可以直接对你的客户数据执行写操作——打标签、发消息、分配会话。建议在初期让它执行关键操作之前先经过你的确认，跑稳了再逐步放权。

效率重要，但数据安全更重要。

###API Key 不要出现在任何公开记录里

API Key 、Project ID 和 API Secret是你账户的访问凭证，一旦泄露等于把客户数据库的钥匙交出去了。不要把它粘贴在截图、公开文档或团队共享的记录里，配置完成后及时清除聊天记录中的明文信息。

###Zapier 免费版有任务次数上限

Zapier 免费版每月只有 100 次任务额度，如果你设置了多个定时触达任务，很快就会触顶。跑量稍大的业务建议在正式上线前确认好套餐，避免任务静默失败却没有任何提示。

###定时任务上线前先手动跑一次

不管是 Zapier 的定时触达还是 SaleSmartly 的数据拉取，正式启用之前建议先手动触发一次，确认指令逻辑和数据返回都符合预期，再切换到自动模式。

##常见问题

###没有技术背景，能用 OpenClaw 吗？

可以。OpenClaw 的核心交互方式就是自然语言，你不需要写代码，直接说你想做什么就行。本文里所有的示范指令都可以直接复制使用。

###OpenClaw 的指令支持中文吗？

支持。你可以直接用中文下指令，OpenClaw 能理解并执行。本文里部分指令用英文是因为发给客户的消息需要用英文，指令本身中英文都可以。

###SaleSmartly 的 API Key 在哪里找？

![](https://image.gaomeluo.com/blog/2026/06/1781016432.png)

]]> 0 https://blog.gaomeluo.com/archives/OpenClaw-work/#comments https://blog.gaomeluo.com/feed/archives/OpenClaw-work/ 玩转OpenClaw丨OpenClaw手把手的教程合辑 https://blog.gaomeluo.com/archives/wan-OpenClaw/ https://blog.gaomeluo.com/archives/wan-OpenClaw/ Tue, 09 Jun 2026 22:27:00 +0800 光山人

如何拥有属于24小时服务自己的小龙虾？

推荐上云部署OpenClaw，本教程大多基于云服务器部署运营。

##一、(新手必看) OpenClaw部署教程
1、[【教程】手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "【教程】手把手教你在云服务器上安装openclaw")
2、[阿里云轻量云服务器一键配置OpenClaw](https://blog.gaomeluo.com/archives/aliyunqingliang-OpenClaw/ "阿里云轻量云服务器一键配置OpenClaw")
3、[腾讯轻量云服务器一键配置OpenClaw](https://blog.gaomeluo.com/archives/tengxunqingliang-OpenClaw/ "腾讯轻量云服务器一键配置OpenClaw")
4、[【教程】老Mac安装OpenClaw](https://blog.gaomeluo.com/archives/Mac-OpenClaw/ "【教程】老Mac安装OpenClaw")
5、[OpenClaw 怎么装？这几种方式，总有一款适合你](https://blog.gaomeluo.com/archives/OpenClaw-anzhuang/ "OpenClaw 怎么装？这几种方式，总有一款适合你")

##二、(实操必看) OpenClaw接入聊天应用
1、[【教程】手把手教你怎么把个人微信接入OpenClaw](https://blog.gaomeluo.com/archives/weixin-OpenClaw/ "【教程】手把手教你怎么把个人微信接入OpenClaw")
2、[【教程】手把手教你怎么把QQ接入OpenClaw](https://blog.gaomeluo.com/archives/QQ-OpenClaw/ "【教程】手把手教你怎么把QQ接入OpenClaw")
3、[【教程】手把手教你怎么把企业微信接入OpenClaw](https://blog.gaomeluo.com/archives/QW-OpenClaw/ "【教程】手把手教你怎么把企业微信接入OpenClaw")
4、[【教程】手把手教你OpenClaw对接飞书教程](https://blog.gaomeluo.com/archives/openclaw-feishu/ "【教程】手把手教你OpenClaw对接飞书教程")
5、[腾讯轻量云服务器配置的OpenClaw如何接入微信？](https://blog.gaomeluo.com/archives/tx-OpenClaw-weixin/ "腾讯轻量云服务器配置的OpenClaw如何接入微信？")

##三、OpenClaw使用场景及案例
1、[养虾实战教程：我用OpenClaw做了个能盯盘，也能深度复盘的投资agent](https://blog.gaomeluo.com/archives/OpenClaw-agent/ "养虾实战教程：我用OpenClaw做了个能盯盘，也能深度复盘的投资agent")
2、[养虾实战教程：教你如何用 OpenClaw 搭建一套完整的、闭环的跨境运营工作流](https://blog.gaomeluo.com/archives/OpenClaw-work/ "养虾实战教程：教你如何用 OpenClaw 搭建一套完整的、闭环的跨境运营工作流")
3、[养虾实战教程：一个人、一台 Mac、六个 AI Agent — 从](https://blog.gaomeluo.com/archives/OpenClaw-6agent/ "养虾实战教程：一个人、一台 Mac、六个 AI Agent — 从")
4、[从 OpenClaw 到 Hermes Agent：安装、迁移、配置、实战演示](https://blog.gaomeluo.com/archives/OpenClaw-HermesAgent/ "从 OpenClaw 到 Hermes Agent：安装、迁移、配置、实战演示")
5、[卖 Skill、卖服务、卖产能——靠 OpenClaw 赚钱的三种姿势](https://blog.gaomeluo.com/archives/Skill-OpenClaw/ "卖 Skill、卖服务、卖产能——靠 OpenClaw 赚钱的三种姿势")
6、[只需一个指令，让 OpenClaw 安排 TRAE 干活](https://blog.gaomeluo.com/archives/OpenClaw-ganhuo/ "只需一个指令，让 OpenClaw 安排 TRAE 干活")
7、[谷歌大牛手把手教你“养虾”，月薪3000雇6个AI全能专家，每天让你睁眼就躺赢](https://blog.gaomeluo.com/archives/OpenClaw-tangying/ "谷歌大牛手把手教你“养虾”，月薪3000雇6个AI全能专家，每天让你睁眼就躺赢")
8、[在OpenClaw里，用大模型构建一个真正能用起来的个人Wiki模式知识库](https://blog.gaomeluo.com/archives/OpenClaw-Wiki/ "在OpenClaw里，用大模型构建一个真正能用起来的个人Wiki模式知识库")

]]> 0 https://blog.gaomeluo.com/archives/wan-OpenClaw/#comments https://blog.gaomeluo.com/feed/archives/wan-OpenClaw/ 【教程】手把手教你怎么把企业微信接入OpenClaw https://blog.gaomeluo.com/archives/QW-OpenClaw/ https://blog.gaomeluo.com/archives/QW-OpenClaw/ Tue, 09 Jun 2026 22:00:00 +0800 光山人

##一、前期准备：
1、对接前你需要已经安装好了OpenClaw，安装教程参考《[手把手教你在云服务器上安装openclaw](https://blog.gaomeluo.com/archives/openclaw/ "手把手教你在云服务器上安装openclaw")》

2、拥有一个企业微信账号。

***提示**：云上OpenClaw接入企业微信场景推荐使用国内的云服务器和模型服务。*
##二、在企微里创建机器人

打开企业微信客户端，进入工作台，点「智能机器人」，再点「创建机器人」

进入创建页面后，底部有一行小字：「如需使用自有系统获取成员与机器人的聊天并输出回复，可切换至 API 模式创建」。点「API 模式创建」

![](https://image.gaomeluo.com/blog/2026/06/1781012341.png)

连接方式选「使用长连接」。长连接的好处很实在：不需要域名，不需要公网 IP，本地电脑就能接收消息并返回结果

选好之后，页面上会显示两个东西：Bot ID 和 Secret。把这两个值复制下来，后面要用

![](https://image.gaomeluo.com/blog/2026/06/1781012363.png)

##三、安装企微插件，关联OpenClaw

针对企业微信对接OpenClaw，对于一些新手小白来说，我推荐购买阿里云或者腾讯云的应用轻量服务器。

因为这两家的轻量应用服务器，可以一键对接。
参考教程：[手把手教你怎么把QQ接入OpenClaw](https://blog.gaomeluo.com/archives/QQ-OpenClaw/ "手把手教你怎么把QQ接入OpenClaw")

上面的教程里面教大家一键对接，非常简单，这里不再赘述。

下面的是教大家怎么在普通的弹性服务器里面对接。

打开终端（macOS 上叫 Terminal，Windows 上叫命令提示符或 PowerShell），输入：

openclaw plugins install @wecom/wecom-openclaw-plugin

等它跑完，看到 `Installed plugin: openclaw-wecom` 和 `Restart the gateway to load plugins`. 就算装好了

![](https://image.gaomeluo.com/blog/2026/06/1781012769.png)

接着重启 OpenClaw：
`openclaw gateway start`

然后添加渠道：
`openclaw channels add`

终端会弹出一个列表，让你选 channel。往下翻，找到「企业微信（WeCom）」，选它

![](https://image.gaomeluo.com/blog/2026/06/1781012804.png)

然后终端会依次让你输入两个东西：Bot ID 和 Secret。就把刚才从企微那边复制的值粘贴进去

![](https://image.gaomeluo.com/blog/2026/06/1781012819.png)

选完之后，选「Finished」

![](https://image.gaomeluo.com/blog/2026/06/1781012833.png)

##四、配对

终端会问你配对方式，选「Pairing」

![](https://image.gaomeluo.com/blog/2026/06/1781012861.png)

配置完成后，终端会显示渠道配置成功

![](https://image.gaomeluo.com/blog/2026/06/1781012875.png)

现在回到企业微信。找到刚才创建的机器人，保存它，然后给它发一条消息，随便发个「你好」就行

机器人会回复一段文字，里面有一个配对码（Pairing code），最后一行长这样：

openclaw pairing approve openclaw-wecom ABFJ22X8

![](https://image.gaomeluo.com/blog/2026/06/1781012899.png)

把这行命令完整复制，粘贴到终端里，回车

![](https://image.gaomeluo.com/blog/2026/06/1781012911.png)

配对完成。回到企微，再发一次「你好」，这次机器人会正常回复了

![](https://image.gaomeluo.com/blog/2026/06/1781012928.png)

到这里，基础的接入就全部跑通了

##五、进阶用法

企微这次给的文档里，附了两个进阶用法

####第一个，智能表格 Webhook

OpenClaw 可以通过 Webhook 直接往企微的智能表格里写数据。在智能表格中开启「接收外部数据」后，系统会生成一个唯一的 Webhook 地址，通过标准的 HTTP POST 请求就能新增或更新记录

适用场景包括：外部系统数据自动同步、客户信息自动录入、工单状态自动更新等等

![](https://image.gaomeluo.com/blog/2026/06/1781013004.png)

详细配置可以参考企微开发者文档：接收外部数据到智能表格https://developer.work.weixin.qq.com/document/path/101239

####第二个，调用企微 API

如果想让 OpenClaw 做更多事情（比如创建文档、读写日程、管理通讯录），需要再多拿两个参数：企业 ID（corpid）和应用 Secret

获取方式也简单。企业 ID 在管理后台的「我的企业」页面底部能看到

![](https://image.gaomeluo.com/blog/2026/06/1781013024.png)

应用 Secret 在「应用管理」里，进入自建应用，点「查看」，Secret 会发到你的消息列表里

![](https://image.gaomeluo.com/blog/2026/06/1781013039.png)

拿到这两个值之后，发给已经关联 OpenClaw 的机器人，它就能发起获取 access token 的请求，具体文档在这：
https://developer.work.weixin.qq.com/document/path/91039

再通过 access token 调用企微的各类 API，比如文档 API

接下来你就可以开始进一步探索OpenClaw接入企业微信之后的更多使用场景。

##六、总结

如果你只是实验玩玩，本地部署一下就可以了；如果需要 7×24 小时在线，建议用云服务器或者轻量应用服务器部署，保持进程常驻。

]]> 0 https://blog.gaomeluo.com/archives/QW-OpenClaw/#comments https://blog.gaomeluo.com/feed/archives/QW-OpenClaw/