潮水褪去，你的龙虾还在么？

随机问问身边的朋友、同事这样一个问题：“你的小龙虾还养着不？”

得到的回答大多是 “忘记了”、“已经不养了”、“转投 Kimi Work/ Workbuddy”。

我最近正好听了篇播客。主要是聊全民养龙虾热潮褪去后，Tokens 作为一种新型“大宗商品” 在我们身边悄然发生的变化。

例如，让AI “替代”人类一部分工作的趋势正在加大，甚至已经改变了一些企业的开发模式和组织结构。

播客中有三个让我印象深刻的地方，这里稍微提一句：

AI的终点是算力，算力的终点是显卡，显卡的终点是电力，电力的终点是中国。
以前在那些坐在电脑前完成的工作，在有了AI 加持后，逐渐会呈现“哑铃化”的趋势：

中间环节的工作会慢慢被AI完成和取代。而上游和下游这两块，AI反而没什么机会。

上游就是跑客户、定需求、定指标、定框架 ——可能对应销售、产品经理、架构师的活。

下游就是，最后落地一公里的问题：应用健康度如何、有没有更低成本更高效的环境去支持这些应用

——可能对应咨询（关注组织变革）、新型集成商（关注打包）、FDE的角色（关注mvp）。
在AI 新兴概念的叙事角度上（HERMES 也好， Loop Engineering也好）中国和美国是不一样的：

从美国新兴资本的角度看，AI 是面向高端用户、高溢价、稀缺产品的叙事。

而从中国的角度看，AI 是面向生产、制造环节的普通大宗商品叙事（就像煤炭、电力一样）。

回头看龙虾在历史中的地位

可以说，“小龙虾"正好处在 LLM 能力变强、支持更长上下文的时代节点下，做出的一款更贴近用户端的智能助手产品。

它成功有这样几个要素：

用户不再依赖某个厂商的浏览器或客户端去完成某个孤立的任务。更像是一个有记忆的头脑。

哪怕这个任务和一周前聊过的另一个任务相关，智能体也可以自己补齐这两个任务的关联内容。

—— 技术实现：打通多客户端渠道 + 全局记忆功能

Agent 在任务执行过程中，大幅减少人工介入，终端用户体验更好。

常见的场景：Agent 在本地环境执行某个SKILL 时报错失败了。

之前的处理路径：人工粘贴报错信息给大模型 –>大模型推理最可能的原因 –> 给出解决办法A or B –> 人工去修改&再次执行 –> if 无报错; 问题修复。

而当 Agent 可以自主介入、观察到任务执行后的处理路径是这样：

1
2
3
4
5
6


//这里以一篇 md 格式的文章上传到微信公众号为例

### 10:46 — 内容发布: 微信公众号文章上传草稿箱 (Agent Loop)
- **决策**：首先分析文章内容并生成蓝图线稿风配图及 2.35:1 封面，写入文章 markdown 相对引用。随后采用 API 模式调用 `wechat-api.ts` 二次上传，避免沙箱中缺失 Chrome 导致浏览器方式发布失败的后备路径。
- **结果**：文章《Agent Loop Engineering: 智能体的闭环自演进之路》及配图、封面成功更新，且已成功上传至微信公众号草稿箱（`media_id: IrvpDN8EJPsmWkMx6i-ayc390Pz2J`）。
- **教训**：注意沙箱里由于 Chrome 缺损应首选 API 快速模式。图片像素大时上传会遇到 Format mismatch 等后置验证，wechat-api 自带压缩兜底逻辑比较健壮，能有效处理大图。

—— 技术实现：LLM 在长上下文中保持自主探索&工具调用执行的成功率大幅度提升，SKILLS + MCP 等本地真实环境工具加持也让大模型可以接触到一手的信源。

上述两者叠加后，用户欣喜地发现新一代Agent 对于通用的复杂任务的处理能力大幅提升了。

这对于普通用户来说是个很大的吸引：谁会拒绝只需说一句 “我想要个年度汇报PPT” ，然后 agent 一顿操作后做出个 80%的成品出来后的惊喜？

以上是小龙虾在产品上做得优秀的地方。

但是，它仍然没有回答：数据、规则从哪里来，以及如何在Agent执行前提前加工和约束的问题。

一些教训

OpenClaw产品设计之初，没考虑到要给这么多人使用。

一些早期设计上的问题在使用过程中也被放大了——

用户隐私和安全拦截
- 涉及用户隐私、密钥等敏感信息时不过率，高危命令执行不拦截。默认就是一把唆的状态：成功皆大欢喜，失败回头再说。
配置管理复杂
- 使用初期，OpenClaw 升级后，经常要花半天时间去修复它的配置文件。如果让它自己改自己的配置文件，又多半会把它自己的服务搞崩溃掉。

各种skills 工具不统一，命名混乱

社区版本和官方版本间会冲突和打架，普通用户分析和识别难度很大。

1
2
3
4
5
6
7
8
9


"""
3.24 版本后，openclaw 强化了安全配置。
结果飞书这个插件 就有4个版本，非常绕人。。。
"""
### 这里简单记录下：
- 版本1：这个是飞书官方插件新版本   openclaw plugins install @larksuite/openclaw-lark（ OpenClaw 飞书官方插件使用指南（公开版） - 飞书云文档）
- 版本2：这个是飞书官方插件3.8 的旧版本 openclaw plugins install @larksuiteoapi/feishu-openclaw-plugin  （openclaw-feishu/docs/feishu-official-plugin.md at main · AlexAnys/openclaw-feishu）
- 版本3：这个是之前openclaw 社区插件的老版本（不支持openclaw sdk接口）  openclaw plugins install @openclaw/feishu （OpenClaw 接入飞书机器人-腾讯云开发者社区-腾讯云）
- 版本4：这个是目前openclaw 社区插件的新版本 openclaw plugins install @m1heng-clawd/feishu (m1heng/clawdbot-feishu)，插件安装在 /home/node/.openclaw/extensions/feishu 中，但是在v4.15 版本中启动阶段报错

在任务执行过程中，OpenClaw 0 反馈。这就导致两个尴尬的局面：
- 用户不知道它什么情况：有没有误删除文件、执行过程中有没有异常。
  
  )
- 在面对复杂问题时，如果一直有报错，上下文会非常的长，它却不知道何时应该停下来。

越复杂的任务，需要消耗的Tokens 越大。这就又引申出一个多Agents的问题。

多Agent 可以有效控制上下文窗口、减少大量错误日志对 LLM 注意力的干扰。

虽然OpenClaw是支持多Agent 协作的，但具体如何协作，对普通用户来说这个门槛还是很高。

我自己实践下来，根据我的日常使用场景，整理出1主 + 3从 的多Agents 架构。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


"list": [
      {
        "id": "main",
        "default": true,
        "name": "主Agent",
        "workspace": "/home/node/.openclaw/workspace",
        "skills": [
          ...
        ],
        "subagents": {
          "allowAgents": [
            "coding",
            "feishu-manager",
            "media"
          ]
        },
        "tools": {
          "profile": "messaging"
        }
      },
      {
        "id": "coding",
        "workspace": "/home/node/.openclaw/projects",
        "skills": [
          ...
        ],
        "tools": {
          "profile": "minimal"
        }
      },
      {
        "id": "feishu-manager",
        "workspace": "/home/node/.openclaw/feishu",
        "skills": [
          ...
        ],
        "tools": {
          "profile": "full"
        }
      },
      {
        "id": "media",
        "name": "MediaBot",
        "workspace": "/home/node/.openclaw/mediawork",
        "skills": [
          ...
        ],
        "tools": {
          "profile": "minimal"
        }
      }
    ]

所以，想把小龙虾用好，真的还挺难的。。。

以下是我让小龙虾每天0:00，自动整理当天任务中涉及相关优化事项。

说说我的龙虾

我的龙虾目前还在使用，只不过用它时，已经有了明确的方向和入口。

例如：让它整理文章发布到公众号，我会从Mediabot 对话窗口进入；让它修复程序执行过程中的报错，我会从Coding 对话窗口进入；让它上传、备份配置文件到飞书，我会从feishu-manager 对话窗口进入。

不再是最初使用时那样，我自己都不知道用龙虾做些什么。

下面是我自己这套龙虾沉淀下来的知识和能力：

1. OpenClaw 部署&调优经验。

关于部署：之前文章有介绍过链接。

我还是推荐把龙虾安装到 docker 等虚拟环境中—— 备份和还原起来都会容易不少。

关于调优：其中最复杂、跨度时间最长的就是 三层记忆系统了——这点下文会稍微展开讲讲。

2. 好用的项目沉淀下来

例如，之前分享过的 A股行情助手 链接。

3. SOP —> SKILL 化

OpenClaw 中一些周期性的工作，可以交给 HEARTBEAT.md 也可以放在 定时任务 中。

例如，我这有个每5分钟检查 LLM 接口还活着不的脚本。如果接口死了，就自动切换到备用LLM 上去。

反之，如果主 LLM 接口恢复，会再次切换回主 LLM上。

另外，像”更新 A股行情数据“这种需要我手动拉取的任务，在多次踩坑后，可以把整个过程 SKILL化。

SKILL 化后，只需一句指令，就完成数据拉取、错误处理、数据合并的整个流程——

Q：我需要更新 A股票行情数据到今天，记得帮我合并数据到本地8501 服务中。

4. 多Agent 间分工合作

Agents 分工这块，除了上面提到的 OpenClaw 配置。它底层用到的是 sessions_spawn 技术——

技术对比：sessions_spawn vs 协程

维度	协程 (Coroutine)	OpenClaw `sessions_spawn`
隔离级别	共享相同的进程内存空间、变量和调用栈。	物理/逻辑隔离。子 Agent 拥有独立的 LLM 思考上下文、独立的提示词、工具白名单，甚至可以运行在不同的物理 Sandbox 中。
执行载体	依靠事件循环（Event Loop）在单线程内切换。	独立 Agent 推理环（Reasoning Loop）。主/子 Agent 分属不同的 API 会话，完全异步并行。
上下文继承	状态天然共享。	可选继承。默认是干净沙箱（`isolated`），只有显式指定 `context: "fork"` 时才会复制主 Agent 的对话历史。但它们共享同一个白盒文件工作区（Workspace）。
交接控制	协作式让出控制权（如 `yield`）。	非阻塞派发 + 事件驱动。主 Agent 通过 `sessions_spawn` 丢出任务，然后调用 `sessions_yield` 挂起自身，等待子 Agent 的完成事件（Push-based event）触发唤醒。

为什么不让主 Agent 直接干，非要 spawn？

解决上下文膨胀（Context Bloat）：

如果把“公众号文章发布”、“A股数据抓取”、“技术排错”全放在主 Agent 的一个对话里，Token 会迅速膨胀，大模型会因为注意力失焦而“胡言乱语”。spawn 相当于开了一个临时工作台。
工具链与权限沙箱隔离：

主 Agent 拥有全局高危权限，而在 spawn 时可以通过白名单给子 Agent 瘦身，防止失控的子 Agent 执行破坏性操作。
并发提效（并发编排）：

主 Agent 可以一次性 spawn 3个不同的子 Agent，执行并行任务，最后由主 Agent 汇总。

正是因为这样，才可以在主Agent 上去给相关子Agent 派发特定任务——

5. 建立三层记忆框架

当启用多Agent 后，随之而来就是跨对话、跨Agent 的记忆同步问题。

即我在 Mediabot 中的操作过程、踩过的坑如何通知主Agent 呢？并避免下次不再出现相同的错误。

在记忆系统实现上，没有使用RAG，而是参考图书馆文档管理体系：对日常产出的记忆内容分层提炼、管理。

记忆层级	定义与定位	存储媒介与路径	运作逻辑与规则
L1 (Hot)	短期活跃看板管理当前任务、优先级和实时状态。	`NOW.md`	仅允许在心跳时重写。提供实时的各Agent 状态视图。
L2 (Warm)	过程性流水日志记录每日发生的关键交互、操作细节和临时决策。	`memory/YYYY-MM-DD.md`	只增不删 (Append-only)。子 Agent 产生的过程日志会被自动聚合到本地和主Agent 指定的日志文件中。
L3 (Cold)	结构化长期知识沉淀出的高价值通用规则，供后续任务直接召回。	`memory/lessons/` (技术经验) `memory/decisions/` (规则/架构) `memory/people/` (人物画像)	常驻主工作区，绝不进行自动化归档。超过 30 天未更新会标记为 `[⚠️ STALE]`。

依靠 /home/node/.openclaw/workspace/scripts/ 下的自动化脚本，由心跳任务 heartbeat_executor.py 统一驱动：

1
2
3
4
5


[子 Agent 过程日志] ─(每30m心跳聚合)─> [L2 每日流水日志]
                                           │
                                     (每日AI反思提炼)
                                           ▼
[温/冷归档区] <──(安全阀归档校验)── [L3 结构化硬知识 (lessons/decisions)]

测试下记忆系统的效果——

Q：帮我找下上次openclaw 升级后遇到的问题

（可以看出这里压根没提具体升级的时间点）

并询问它: 你是从哪里找到上面这些历史信息的?

有了这套记忆系统，就可以基于 OpenClaw这套系统产生更多有价值的记录和信息。

关键是把之前踩过的坑、做出的决定沉淀下来，实现“左脚踩右脚”式的螺旋递进。

=================

好了，以上就是我的养虾小结。

欢迎评论区分享、交流自己的心得。