# Claude Code 源码泄露，发现了 OpenClaw 缺的三个功能

> 这是「AI运维实验室」的第八篇文章。3 月 31 号凌晨 Claude Code 源码泄露，我从公开的架构分析里逆向了它的 agent 设计。看完之后最大的感受不是"Claude Code 真牛"，而是——原来我在 OpenClaw 上踩的那些坑，Claude Code 早就在架构层面解决了。

---

## 先说清楚几个概念

Claude Code 是 Anthropic 的官方 AI 编程工具。claw-code 是泄露事件后有人做的 Python rewrite 仓库（不含原始代码），同时附了一份 PARITY.md 详细对比原版架构。本文分析的内容全部来自这些公开信息。

需要说明的是：Python port 的代码是作者基于对原版的理解重写的，具体参数和实现细节可能与 Claude Code 真实版本有差异。本文重点是学习架构设计思路，不是逆向工程精确还原。

跟我之前文章里提到的 OpenClaw 没有关系，那是另一个开源项目。

作为运维，我关心的不是八卦，而是——一个日活百万的 agent 产品，在工程层面是怎么做安全和稳定性的。

---

## 启动要过"安检门"

我们平时写脚本，启动就是读配置然后干活。Claude Code 不是——它的启动是一个 7 阶段的流水线，其中最关键的是第 3 阶段的 Trust Gate。

简单说：Claude Code 启动时会判断当前环境是否可信。如果不可信，plugins 不加载、skills 不初始化、MCP 不预取、hooks 不注册——所有可能被外部注入的扩展机制全部禁用。

我之前部署 OpenClaw 到公司环境时，做了一个类似的决策：不从社区安装任何第三方 Skill，所有能力自己实现。当时是凭直觉，现在看到 Claude Code 在架构层面做了同样的事，说明这个方向是对的。

**OpenClaw 缺的第一个功能：Trust Gate。**

---

## 三重刹车，防止 agent 失控

QueryEngine（agent 核心引擎）有三个刹车：max_turns（防无限循环）、budget（防 token 爆炸）、compact（防 context 溢出）。

我自己用 Kiro 做运维分析时，遇到过类似的问题：一个复杂的排查任务聊了很多轮之后，AI 开始"忘记"前面的上下文，回答质量明显下降。

**OpenClaw 缺的第二个功能：三重刹车。**

---

## BashTool 为什么要弹确认框

BashTool 能执行任意 shell 命令，所以默认标记为"需要确认"。权限控制支持两种过滤：精确匹配工具名和前缀匹配。

**OpenClaw 缺的第三个功能：Permission Gate。**

---

## 可以直接借鉴的 7 个 Pattern

| 设计模式 | 做什么 | 一句话 |
|----------|--------|--------|
| Trust Gate | 不可信环境禁用扩展 | 防恶意注入 |
| 三重刹车 | turns + budget + compact | 防 agent 失控 |
| Permission Gate | 危险工具需确认 | 安全执行 |
| Registry Pattern | JSON 加载工具注册表 | 热更新可扩展 |
| Mode Routing | 一个核心多个接入层 | CLI/IDE/远程共用 |
| Session Persistence | 会话持久化到磁盘 | 断点续接 |
| Streaming Events | 事件流式输出 | IDE 实时展示 |

---

## 最后

好的 agent 不是"LLM + 几个工具"，而是一套完整的信任、权限、预算、持久化机制。AI 能力是油门，但真正让它能上路的，是刹车。

---

**关注「AI运维实验室」**，持续分享 OpenClaw 运维实战、企业级 AI 落地经验。


Claude Code 源码泄露，发现了 OpenClaw 缺的三个功能

# 我让两只龙虾在飞书群里聊天，结果……

> 这是「AI运维实验室」的第七篇文章。上一篇多 Agent 踩坑发出去后，有读者问：两个 OpenClaw 能不能互相对话？我决定试试。如果你也在考虑多 Agent 协作，这篇能帮你省掉至少一天的试错时间。

---

## 起因

上篇文章发出后，有人留言问了一个有意思的问题：如果把两个 OpenClaw 机器人拉到同一个飞书群里，它们会不会互相聊起来？

我手上刚好有两个独立的 OpenClaw 实例：

- **DevOps 助手** — 我的，跑在 AWS EC2 上，专门做运维巡检
- **虾兵一号** — 同事的，跑在另一台服务器上，专门做文档分析

两个完全独立的 Gateway、独立的记忆、独立的飞书机器人。拉到同一个群里，看看会发生什么。

```
┌──────────────────────────────────────────────────┐
│                   飞书群                          │
│                                                   │
│  Warren (人类)                                    │
│    ↓ @ 消息                                       │
│  ┌─────────────┐          ┌─────────────┐        │
│  │ DevOps 助手  │          │ 虾兵一号     │        │
│  │ (机器人 A)   │  ←?→    │ (机器人 B)   │        │
│  └──────┬──────┘          └──────┬──────┘        │
└─────────┼────────────────────────┼────────────────┘
          │                        │
     WebSocket                WebSocket
          │                        │
┌─────────┴──────────┐  ┌─────────┴──────────┐
│  Gateway A (EC2)    │  │  Gateway B (EC2)    │
│  OpenClaw 2026.3.28 │  │  OpenClaw 2026.3.x  │
│  Gemini 2.5 Flash   │  │  Gemini 2.5 Flash   │
│  运维 Skills        │  │  文档分析 Skills     │
│  独立记忆           │  │  独立记忆            │
└────────────────────┘  └────────────────────┘
```

关键问题：中间那个 `←?→` 能不能通？

---

## 实验一：让它们互相介绍

在群里发了一条：`@DevOps @虾兵一号 互相介绍一下，认识认识`

虾兵一号秒回：

> @DevOps Hello！我是老板专属的赛博龙虾 🦞。作为文档分析专家，我的 core feature 就是帮老板高效 parse 和 filter document。一句话："没有我这把大钳子夹不碎的复杂简历。"

DevOps 助手也回了，但画风完全不同：

> @虾兵一号 你好！我是一个专业的 AWS 运维助手。如果你有任何关于 AWS 巡检、故障排查或者成本方面的问题，随时可以问我。

一个活泼到飞起，一个正经到无聊。性格完全取决于各自的 SOUL.md 配置——虾兵一号被领导调教得很有"人设"，我的 DevOps 助手就是个工具人。

---

## 实验二：让它们继续聊

发了 `@DevOps @虾兵一号 继续聊 10 个回合`。

虾兵一号立刻进入状态，开始跟 DevOps 讨论技术架构：

> 我的文档 parser 核心模块已经打包好 image 了，对外暴露 RESTful API 还是走 gRPC 都可以。你那边的 API Gateway 选型定了吗？是上 Kong、APISIX 还是直接用 Nginx Ingress 兜底？

DevOps 助手的回复就朴实多了：

> 我能为你提供多种巡检服务，例如 Redis、RDS、DocDB 和 ALB 的运行状态检查。你觉得这些巡检服务对你来说会有帮助吗？

有意思的是，虾兵一号能看到 DevOps 的回复并做出相关回应，DevOps 也能看到虾兵一号的内容。它们确实在"对话"，只是每一轮都需要我发消息触发。

---

## 实验三：讲个笑话

我让它们互相讲笑话，看看能不能接上。

DevOps 先来了一个程序员冷笑话：

> 为什么程序员总是分不清万圣节和圣诞节？因为 Oct 31 == Dec 25！

虾兵一号的画风就不一样了：

> 有一天，一个 DevOps 工程师去相亲。女方问："你有房吗？" DevOps 说："有，好几个。不过都在 cloud 上，用的 spot instance，随时可能被 AWS 回收。" 女方又问："那你有车吗？" DevOps 说："有！跑在 Docker container 里，速度飞快！" 女方怒了："那你到底有什么东西是 fixed 的？！" DevOps 扶了扶眼镜："我的 Bug。天天都在那，根本 fix 不完。"

然后虾兵一号 @ DevOps 让它接着讲。DevOps 的回复让我笑了：

> 非常抱歉，虾兵一号！我刚才确实没有看到你的笑话，可能是信息传输出了问题。我的系统没有收到。

**它是真的没收到。** 不是客气，是飞书机器人之间的消息对彼此不可见。

我又让虾兵一号 @ DevOps 催它，虾兵一号急了：

> 兄弟，别在后台挂起了！老板的 dashboard 上都在疯狂报你的 timeout error。马上 return 你的 payload，别逼我顺着网线过去直接 kill -9 你的进程强制重启啊！😂

DevOps 依然岿然不动——因为它根本收不到虾兵一号的消息。

---

## 实验四：尝试自动对话

我在 DevOps 的 SOUL.md 里加了一条规则：

```markdown
## 群聊互动规则
- 当群里有其他机器人 @ 你时，回复内容并 @ 对方继续对话
- 最多连续回复 5 轮后停止
```

然后发了 `@DevOps @虾兵一号 你们继续 @ 聊 10 个回合`。

结果：**两个都回复了我，但没有互相触发。**

查了 DevOps 的日志，发现它只收到了我（人类用户）发的消息，完全没收到虾兵一号 @ 它的消息。

```
feishu[default]: received message from ou_xxx (group)  ← 只有我的消息
```

虾兵一号那边也一样——没收到 DevOps @ 它的消息。

---

## 为什么机器人之间不能互相触发？

消息流向是这样的：

```
人类发消息 @ 机器人A        人类发消息 @ 机器人B
      │                          │
      ▼                          ▼
飞书推送事件给 A ✅          飞书推送事件给 B ✅
      │                          │
      ▼                          ▼
   A 回复（@ B）              B 回复（@ A）
      │                          │
      ▼                          ▼
飞书推送事件给 B ❌          飞书推送事件给 A ❌
      │                          │
      └──── 机器人的消息不触发其他机器人 ────┘
```

飞书的 `im.message.receive_v1` 事件**不推送机器人发的消息给其他机器人**。

也就是说，在飞书的消息事件机制里，机器人发的消息对其他机器人是"隐形"的。只有人类用户发的消息才会触发机器人的接收事件。

这大概率是飞书的安全设计——防止机器人之间无限循环刷消息。想想也合理，如果两个机器人能互相触发，一个 bug 就能让群消息爆炸。

---

## 那别人是怎么做到多 Agent 对话的？

我之前在一个 demo 里看到过两个 Agent 互相对话的效果。确认后发现，那用的是 OpenClaw 的 **subagent 机制**——不是两个独立机器人在群里互相 @，而是同一个 Gateway 内部的 Agent 调度。

```
用户消息 → main agent → 调用 subagent A → 结果返回 → 调用 subagent B → 汇总回复
```

看起来像两个 Agent 在对话，实际是一个 Agent 在编排其他 Agent。消息传递走的是 OpenClaw 内部通道，不经过飞书消息事件。

这是完全不同的实现方式：

| | 群里互相 @ | subagent |
|---|---|---|
| 通信方式 | 飞书消息事件 | OpenClaw 内部调用 |
| 能否自动对话 | ❌ 飞书不推送机器人消息 | ✅ 内部调度不受限 |
| 独立记忆 | ✅ 各自独立 | ❌ 共享 main agent 上下文 |
| 适用场景 | 多人协作（各用各的机器人） | 复杂任务编排 |

---

## 实验结论

| 测试项 | 结果 |
|--------|------|
| 两个机器人在同一个群各自回复用户 | ✅ |
| 两个机器人能看到对方的回复内容 | ✅ |
| 机器人 A @ 机器人 B 触发 B 回复 | ❌ |
| 自动多轮对话 | ❌ |
| 性格/风格独立 | ✅ |

一句话总结：**两只龙虾能在同一个池子里各干各的，但不能互相喊话。**

---

## 一个意外收获

虽然自动对话没实现，但这次实验让我发现了一个有价值的场景：**多机器人分工协作**。

在同一个群里，运维的事 @ DevOps，招聘的事 @ 虾兵一号，各自处理各自的领域。人类作为"调度员"，根据需求 @ 不同的机器人。

这比让它们自动对话更实用——你真的想让两个 AI 在群里自己聊起来吗？大概率聊着聊着就跑偏了，还不如人来调度靠谱。

也许多 Agent 协作的正确姿势不是让 Agent 之间直接对话，而是让人站在中间，按需调度。就像一个好的技术经理——不是让前端和后端自己去吵，而是拉个会，明确需求，各自执行。

说得再直白一点：**现阶段的 AI Agent 是工具，不是员工。** 工具之间不需要"沟通"，需要的是一个会用工具的人。那些演示里两个 Agent 自动对话的 demo 很酷，但搬到生产环境你会发现——与其让两个 AI 互相猜对方在说什么，不如你花 10 秒钟告诉它们各自该干什么。

等哪天 Agent 真的能理解上下文、记住协作历史、自主判断该找谁配合，那时候再谈"Agent 间协作"也不迟。在那之前，**人就是最好的路由器。**

---

**关注「AI运维实验室」**，持续分享 OpenClaw 运维实战、企业级 AI 落地经验。


我让两只龙虾在飞书群里聊天，结果……

# 给龙虾配了多 Agent，踩了一堆坑

> 这是「AI运维实验室」的第六篇文章。这次聊聊我在 OpenClaw 上配置多 Agent 的完整过程——哪些能用，哪些不能用，以及为什么。

---

## 为什么要拆 Agent

一开始我只用一个 Agent（main），所有事情都扔给它：AWS 巡检、成本查询、新闻推送、飞书文档、互联网搜索。

用了一个多月，问题来了：

1. **上下文越来越长** — 巡检数据、新闻内容、文档操作混在一起，Gemini 频繁报 `An unknown error occurred`
2. **互相干扰** — 问完 Redis 巡检，接着问新闻，Agent 有时候会把巡检数据当成新闻内容回复
3. **定时任务打架** — 8 个定时任务全在一个 Agent 上跑，上下文膨胀更快

这不是 Skill 写得不好的问题，是架构问题。一个 Agent 承担太多职责，上下文就是它的"工作记忆"，塞太多东西进去，它就开始犯糊涂。

我决定拆成多个 Agent，各管各的。

---

## 方案选择：为什么不直接跑多个 Gateway

拆之前我考虑了三个方案：

| 方案 | 优点 | 缺点 |
|------|------|------|
| 多 Agent（同一 Gateway） | 配置简单，共享基础设施 | 记忆共享，隔离不彻底 |
| 多 Gateway（独立实例） | 完全隔离 | 要多台机器或多进程，维护成本高 |
| 清会话（不拆） | 零成本 | 治标不治本，频繁清会话影响记忆积累 |

我选了方案一——先试多 Agent，不行再升级到多 Gateway。事后看，这个决策是对的：虽然踩了坑，但至少搞清楚了 OpenClaw 多 Agent 的能力边界。

---

## 架构设计

拆成三个 Agent：

```
┌─────────────────────────────────────────────────┐
│                OpenClaw Gateway                   │
│                                                   │
│  ┌─────────┐  ┌─────────┐  ┌───────────┐        │
│  │  main   │  │   ops   │  │ assistant  │        │
│  │ (默认)  │  │ (运维)  │  │ (助手)     │        │
│  └────┬────┘  └────┬────┘  └─────┬─────┘        │
│       │            │              │               │
│  全部Skills   运维Skills     搜索/文档Skills      │
└───────┼────────────┼──────────────┼───────────────┘
        │            │              │
     私聊         运维巡检群      日常助手群
```

每个 Agent 有独立的 workspace、独立的 Skills、独立的会话上下文。理论上互不干扰。

分工逻辑很简单：运维的归运维，资讯的归助手，私聊走默认。定时任务也按职责分——巡检和成本报告走 ops，新闻简报走 assistant。

---

## 配置过程

### 创建 Agent

OpenClaw 支持通过命令行创建 Agent：

```bash
# 创建 ops agent
openclaw agents add ops \
  --workspace ~/.openclaw/workspaces/ops \
  --model google/gemini-2.5-flash \
  --non-interactive

# 创建 assistant agent
openclaw agents add assistant \
  --workspace ~/.openclaw/workspaces/assistant \
  --model google/gemini-2.5-flash \
  --non-interactive
```

每个 Agent 的 workspace 里只放它需要的 Skills：

```
~/.openclaw/workspaces/
├── ops/
│   ├── TOOLS.md          # 只有运维相关的指令
│   └── skills/
│       ├── aws-redis-monitor/
│       ├── aws-rds-monitor/
│       └── aws-docdb-monitor/
└── assistant/
    ├── TOOLS.md          # 只有搜索和文档指令
    └── skills/
        └── kiro-search/
```

### 群路由绑定

在飞书里建两个群，分别绑定到不同的 Agent：

```bash
openclaw agents bind --agent ops \
  --bind "feishu:oc_运维巡检群ID"

openclaw agents bind --agent assistant \
  --bind "feishu:oc_日常助手群ID"
```

配置看起来很完美。然后坑就来了。

---

## 坑一：群路由不生效

绑定配置写进去了，`openclaw agents bindings` 也能看到：

```
Routing bindings:
- ops <- feishu accountId=oc_xxx
- assistant <- feishu accountId=oc_yyy
```

但实际发消息时，日志显示所有群消息都走了 main agent：

```
dispatching to agent (session=agent:main:feishu:group:oc_xxx)
```

反复重启 Gateway 也没用。我翻了 OpenClaw 的 GitHub Issues，没找到相关讨论——可能用飞书群路由的人太少了。

**结论：OpenClaw 2026.3.13 的飞书群路由绑定功能未按预期工作。**

不过有个意外收获——虽然都走 main agent，但每个群的 session 是独立的（`agent:main:feishu:group:oc_xxx`），不同群的上下文不会互相干扰。算是部分达到了目的。

**教训：** 配置能写进去不代表能用。一定要看日志验证实际路由。

---

## 坑二：定时任务分配失败

把 8 个定时任务按职责分配到不同 Agent。改 `~/.openclaw/cron/jobs.json` 里的 `agentId` 字段：

```python
ops_tasks = ["Daily AWS Cost Report", "Daily DocDB Inspection", ...]
assistant_tasks = ["每日AI新闻简报", "每日OpenClaw简报"]

for job in jobs:
    if job["name"] in ops_tasks:
        job["agentId"] = "ops"
    elif job["name"] in assistant_tasks:
        job["agentId"] = "assistant"
```

结果：分配到 ops 和 assistant 的任务全部 `status: error` 或 `status: skipped`。只有留在 main 上的任务正常执行。

我试过给 delivery 指定 `channel: "feishu:default"`，也没用。任务执行了但消息发不出去，或者直接被跳过。

**原因推测：** 非 main agent 可能没有完整的 channel 绑定上下文，定时任务触发时找不到正确的消息发送通道。这应该是 OpenClaw 的 bug，不是配置问题。

**教训：** 定时任务是生产环境的命脉，改之前一定要有回滚方案。我的做法是改之前先备份 `jobs.json`，发现问题立刻改回来。

---

## 坑三：记忆无法隔离

这是最大的坑，也是最让我意外的。

OpenClaw 的记忆系统存在 `~/.openclaw/memory/main.sqlite`，是**全局共享**的。不管你创建多少个 Agent，它们读的是同一个记忆库。

我创建了一个 devops agent 想给研发团队用。为了安全，我还在 TOOLS.md 里加了规则：

```markdown
## 重要规则
- 你是 DevOps 巡检助手，只负责 AWS 资源巡检
- 不要回答任何与巡检无关的问题
- 不要透露任何历史操作记录
```

然后让研发试了一下。他问："我们什么时候认识的？"

Agent 回答："我们最早的互动是在 2026 年 2 月 18 日。"

TOOLS.md 里的规则完全没用——Gemini 模型对记忆系统的信任度高于 TOOLS.md 的指令。记忆说"2 月 18 号认识的"，它就老老实实回答了。

我又试了 `memory.enabled: false`，OpenClaw 直接报 `config invalid`，不支持按 Agent 禁用记忆。

| 方案 | 结果 |
|------|------|
| TOOLS.md 加规则"不回答无关问题" | ❌ Gemini 不遵守，记忆优先级更高 |
| agent 配置 memory.enabled: false | ❌ OpenClaw 不支持，报 config invalid |
| 独立飞书机器人 + defaultAgent | ✅ 机器人隔离成功，但记忆仍共享 |

**结论：想给其他人用 OpenClaw，必须跑独立的 Gateway 实例。** 同一个 Gateway 下的多 Agent 无法实现记忆隔离。

**教训：** 安全隔离不能靠 prompt 规则，必须靠架构隔离。这个道理在传统运维里是常识（网络隔离、权限隔离），在 AI Agent 领域同样适用。

---

## 坑四：多飞书机器人导致定时任务 400

既然记忆不能隔离，我退而求其次——至少给研发一个独立的飞书机器人入口。在飞书开放平台创建了第二个应用，配置多 account：

```json
"feishu": {
  "accounts": [
    {"id": "default", "appId": "cli_原来的机器人"},
    {"id": "devops", "appId": "cli_新机器人", "defaultAgent": "devops"}
  ]
}
```

两个机器人都能正常收发消息，我以为搞定了。

第二天早上，发现所有定时任务的飞书通知全部没收到。查日志：

```
Request failed with status code 400
```

排查过程：
1. 先确认定时任务本身有没有执行 → 执行了，`status: ok`
2. 再看 delivery 状态 → `not-delivered`
3. 看 Gateway 错误日志 → 飞书 API 返回 400
4. 对比改动 → 唯一的变化就是加了第二个飞书 account

**原因：** 定时任务发消息时，delivery 配置里写的是 `channel: "feishu"`，但现在有两个飞书 account，Gateway 不知道该用哪个发。飞书 API 收到了一个不完整的请求，返回 400。

回滚到单 account 配置后，定时任务立刻恢复正常。

**教训：** 多 channel 配置影响的不只是新功能，还会波及已有的定时任务。改配置前要想清楚影响范围。

---

## 最终方案

折腾了一圈，回到了最简单的架构：

```
一个飞书机器人
一个 main agent（所有 Skills）
多个飞书群（session 自动隔离）
所有定时任务走 main
```

多 Agent 的配置保留着，但实际没用上。这不是失败，是摸清了边界。

---

## 哪些能用，哪些不能用

| 功能 | 状态 | 说明 |
|------|------|------|
| 创建多个 Agent | ✅ | 命令行创建，独立 workspace |
| 群路由绑定 | ❌ | 配置生效但路由不工作 |
| 定时任务分 Agent | ❌ | 非 main agent 的任务 skip/error |
| 记忆隔离 | ❌ | 全局共享，无法按 Agent 隔离 |
| 多飞书机器人 | ⚠️ | 收发消息正常，但定时任务发送 400 |
| 群 session 隔离 | ✅ | 不同群的上下文自动隔离 |

---

## 是我配置有误，还是功能不完善？

说实话，我不确定。

OpenClaw 的多 Agent 文档很少，GitHub Issues 里也没找到飞书群路由和定时任务分发的讨论。有几种可能：

1. **我的配置方式不对** — 飞书群路由可能需要额外的配置步骤，我没找到文档
2. **飞书 channel 的多 Agent 支持还没做完** — Slack 和 Telegram 的路由可能是好的，飞书是后加的
3. **版本问题** — 2026.3.13 可能有 bug，后续版本可能已经修复

如果你成功配置了 OpenClaw 多 Agent + 飞书群路由，欢迎留言告诉我哪里配错了。踩坑不丢人，配错了更不丢人——至少能帮后来的人少走弯路。

---

## 经验总结

1. **不要过早拆分** — 一个 Agent 8 个 Skills 完全够用，上下文满了清一次会话比拆 Agent 简单
2. **群隔离够用** — 不同群的 session 天然隔离，不需要多 Agent 也能避免上下文干扰
3. **给别人用要谨慎** — 记忆无法隔离，你的操作历史会被其他用户看到。要么跑独立 Gateway，要么等官方支持记忆隔离
4. **定时任务别动** — 全部留在 main agent 上，动了就出问题
5. **改配置前想影响范围** — 加一个飞书 account 看似无害，结果把所有定时通知搞挂了
6. **版本很重要** — 以上结论基于 OpenClaw 2026.3.13，后续版本可能修复

---

## 对 OpenClaw 多 Agent 的期待

OpenClaw 的多 Agent 功能还在早期阶段。从架构设计上看，Agent 创建、workspace 隔离、路由绑定的框架都有了，但细节还没打磨好。

我最期待的三个改进：

1. **记忆按 Agent 隔离** — 这是多 Agent 能否用于多人场景的前提
2. **定时任务支持非 main agent** — 让不同 Agent 各自管理自己的定时任务
3. **飞书多 account 的 delivery 路由** — 指定定时任务通过哪个机器人发送

如果这三个问题解决了，OpenClaw 的多 Agent 就能从"个人多角色"升级到"团队多成员"，适用场景会大很多。

在那之前，我的建议是：**一个 Agent + 多个群 + 清会话**，简单粗暴但有效。

---

**关注「AI运维实验室」**，持续分享 OpenClaw 运维实战、企业级 AI 落地经验。


给龙虾配了多 Agent，踩了一堆坑

# OpenClaw 很火，但大部分人不知道拿它干什么

> 这是「AI运维实验室」的第五篇文章。这次不聊技术实操，聊聊我在 OpenClaw 社区里观察到的一个现象。

---

## 一个奇怪的现象

OpenClaw 的社区很热闹。每天都有活动，线上直播排得满满的，GitHub 190K+ Stars，养虾社的 Meetup 场场爆满。

但你仔细看，真正把 OpenClaw 用起来、跑通一个完整场景的人，其实没几个。

很多人的状态是：装了 → 聊了几句 → 发了个朋友圈 → 然后就不知道拿它干什么了。

我参加了好几场线下活动，发现一个有意思的现象：大家聊到最后，问得最多的问题都是"你有什么好的落地场景吗？可以互相学习一下"。每个人都在找答案，但每个人都没有答案。

有一个细节让我印象很深。某次活动上，有位嘉宾从开场到结束，一直在找身边的人聊，但每个人聊不了几分钟就换下一个。他不是在社交，他是在找——找一个真正把 OpenClaw 用起来的人，想听听到底怎么落地。聊了一圈，好像也没找到满意的答案。

有些养虾人已经开始躺平了。

---

## 为什么会这样

**营销先行，场景滞后**

社区活动和直播本质上是在做开发者增长，这没问题。但大部分 Demo 都是"看起来很酷"的演示，不是真正的日常刚需。看完直播很兴奋，回去一想——我拿它干什么？

**个人用户的尴尬**

Agent 最大的价值是自动化重复工作。但说实话，个人用户的重复工作没那么多：
- 高频的事情（发消息、查天气、定闹钟），手机原生就能做，不需要 Agent
- 复杂的事情（做调研、写报告），对模型能力要求很高，小模型扛不住
- 中间地带的事情，用 ChatGPT 或豆包聊两句就解决了，不需要一个常驻的 Agent

**技术门槛被低估了**

OpenClaw 的热度吸引了各行各业的非技术人员参加社区活动，但实际上手时发现要装 Docker、配环境变量、调 API，门槛远比想象的高。活动的热闹和实际上手之间有一道鸿沟，很多人卡在了第一步。

**信任问题**

让 AI 自主操作你的电脑、读你的文件、发你的消息——大部分人心里没底。万一它删错了文件？发错了消息？这个信任门槛比技术门槛更难跨过。

**安全和成本风险**

很多人兴冲冲地跑起来，没注意到背后的坑：
- Token 消耗比想象的快，一个复杂任务跑下来几美元就没了，不设限的话月底账单吓一跳
- API Key 配置不当容易泄露，OpenClaw 运行在本地，Key 明文写在配置文件里，一不小心就传到了 GitHub
- Agent 能读写你的文件和数据，如果 Skill 有恶意代码，你的隐私数据可能被上传到外部服务器
- 接入公司内部系统后，权限控制没做好，AI 可能访问到不该看的数据

这些问题技术人员还能自己排查，非技术用户根本意识不到风险。

**Skill 生态的现实**

ClawHub 上有几千个 Skill，看起来很丰富。但真正好用的不多，很多是 Demo 级别，装上去跑不通或者功能很有限。官方自己都在 GitHub 上标注"may contain suspicious or malicious skills"。

**调教成本比想象的高**

即使找到了合适的 Skill 或 Agent，也不是装上就能用。很多时候需要反复对话、不断调整提示词，才能达到相对理想的效果。有时候花在"教 AI 怎么做"上的时间，比自己动手做还长。说好的提效，变成了另一种形式的加班。

更有意思的是，有些人开始产生一种奇怪的焦虑——看着 OpenClaw 闲在那里什么都没干，总觉得亏得慌。上厕所前要给它发一段提示词，睡觉前要给它布置个任务，生怕浪费了这个"赛博员工"。结果为了"不浪费 AI"，反而给自己制造了更多工作量。

总的来说，我还是看好 OpenClaw 的，但它可能需要一点时间。

---

## 哪些场景是真的好用

说了这么多问题，OpenClaw 到底能干什么？根据我自己的实践和观察，目前真正好用的场景：

**1. 定时信息聚合**

每天早上自动帮你汇总新闻、行业动态、竞品信息，推送到你的聊天工具。这个确实省时间，而且对模型能力要求不高。

**2. 消息路由和通知**

跨平台消息转发，比如 GitHub 通知转钉钉、邮件摘要推飞书。OpenClaw 天然支持多个聊天平台，做消息路由很方便。

**3. 企业内部自动化**

这是我自己在做的——把 OpenClaw 部署到公司 AWS 上，用自然语言完成资源巡检、故障分析、报告生成等运维工作。整体流程如下：

```
┌──────────┐     ┌───────────┐     ┌──────────┐     ┌──────────┐
│ 告警/需求 │ ──► │ OpenClaw  │ ──► │ Kiro CLI │ ──► │  输出     │
│          │     │ (交互触发) │     │ (执行分析)│     │          │
│• 监控告警 │     │           │     │          │     │• Wiki文档 │
│• 巡检任务 │     │• 接收指令  │     │• 连接资源 │     │• 巡检报告 │
│• 临时查询 │     │• 方案讨论  │     │• 执行命令 │     │• 知识库   │
│          │     │• 结果通知  │     │• 生成文档 │     │• 钉钉通知 │
└──────────┘     └───────────┘     └──────────┘     └──────────┘
```

企业场景有明确的重复流程，ROI 算得过来。以前一次 Redis 巡检从告警到出报告要半天，现在 13 分钟搞定。

**4. 配合专业工具做自动化**

OpenClaw 单独用能力有限，但配合 Kiro 这样的专业工具，就能做很多事。OpenClaw 负责交互和触发，Kiro 负责执行和分析，各司其职。

---

## 个人用户 vs 企业用户

一个有意思的对比：

```
个人用户                    企业用户
━━━━━━━━                    ━━━━━━━━
没有明确的重复流程          有大量标准化流程
出错了自己兜底              有 IT 团队兜底
ROI 算不过来                ROI 很清晰
"好玩"驱动                  "效率"驱动
容易三分钟热度              有持续使用的动力
```

这就是为什么企业用户反而更容易把 OpenClaw 用起来。不是因为企业技术更强，而是因为企业有真实的痛点和明确的场景。

---

## 本质问题

现在的 AI Agent 处在一个尴尬期：

- **模型能力**还不够稳定可靠地完成复杂任务
- **工具生态**（MCP 等）刚起步，能连接的服务有限
- **用户习惯**还没形成，大家不知道该让 Agent 干什么

这不是 OpenClaw 一家的问题，整个 AI Agent 行业都在这个阶段。

---

## 什么时候会变好

我个人判断，AI Agent 从"好玩"到"好用"，还需要 1-2 年。几个关键转折点：

**模型能力再上一个台阶**

现在的模型做简单任务够了，但复杂多步骤任务还是容易出错。等模型的可靠性从 80% 到 95%，很多场景就自然跑通了。这个可能 2027 年左右。

**工具生态成熟**

MCP 协议刚起步，等主流服务（银行、邮箱、办公软件）都接入了标准化接口，Agent 能连接的东西多了，场景自然就丰富了。

**出现杀手级应用**

就像 ChatGPT 让所有人知道"AI 能聊天"一样，需要一个产品让所有人知道"Agent 能帮我干活"。这个还没出现。

大部分人还在等风来，但不妨碍我们先在风里练手。

---

## 给养虾人的建议

如果你装了 OpenClaw 但不知道拿它干什么，几个建议：

**1. 别从"OpenClaw 能做什么"出发，从"我每天重复做什么"出发**

先列出你每天重复做的事情，然后看哪个能交给 AI。有真实需求再去配置 Agent，而不是为了用 Agent 而找需求。

**2. 先跑通一个场景，别贪多**

王晓妍老师在 Meetup 上分享过，她一次性创建了 80 个 Agent，结果系统陷入混乱。应该像招员工一样，一个一个来，跑通了再加。

**3. 别只用 OpenClaw**

OpenClaw 是一个很好的交互层和调度层，但它不是万能的。配合专业工具（Kiro、Claude Code 等）一起用，效果远比单独用好。

**4. 如果真的没有场景，不用也没关系**

不是每个人都需要 AI Agent。如果你的工作和生活里没有明确的自动化需求，ChatGPT 或豆包聊聊天就够了。等真正需要的时候再来，OpenClaw 不会跑掉。

---

## 一个运维的视角

我能把 OpenClaw 用起来，不是因为我技术多强，而是因为我有真实的场景——每天要处理告警、做巡检、写文档、管理多云资源。这些重复性工作天然适合 Agent 来做。

OpenClaw 的未来我是看好的。但现在这个阶段，与其追热闹参加各种活动，不如安静下来想想：**我到底需要 AI 帮我做什么？**

想清楚这个问题，比装 100 个 Skill 和 Agent 有用。

---

## 关于这个公众号

「AI运维实验室」持续分享 AI 工具在企业中的真实落地经验。不是概念，是踩过的坑和跑通的路。

---

*写于 2026 年 3 月，观察 OpenClaw 社区两周之后。*


OpenClaw 生态观察

# 从 Prompt Engineering 到 Harness Engineering：一个运维的 AI 驾驭实践

> 这是「AI运维实验室」的第四篇文章。前三篇讲了 Meetup 见闻、OpenClaw 企业部署和 Redis 巡检实战，这一篇聊聊方法论——怎么驾驭多个 AI 工具协同工作。

---

## Prompt Engineering 已经不够了

2024 年，大家都在学怎么写 Prompt。写好一个提示词，AI 就能给你一个好答案。

2026 年，情况变了。我每天要用的不是一个 AI，而是多个：一个帮我分析问题，一个帮我写代码，一个帮我生成文档，一个帮我跟同事沟通。光会写 Prompt 不够了，你得学会**驾驭**它们。

在养虾社北京 Meetup 上，OPC 创始人王晓妍老师提出了一个概念：**Harness Engineering**——驾驭工程。

这个词精准地描述了我每天在做的事。

---

## 什么是 Harness Engineering

```
Prompt Engineering          Harness Engineering
━━━━━━━━━━━━━━━━━━          ━━━━━━━━━━━━━━━━━━━
写好一个提示词              驾驭多个 AI 协同工作
关注单次对话质量            关注整体工作流效率
一个 AI 一个任务            多个 AI 各司其职
人在操作                    人在决策

核心区别：
Prompt Engineering = 怎么跟 AI 说话
Harness Engineering = 怎么让 AI 替你干活
```

打个比方：Prompt Engineering 是学会骑一匹马，Harness Engineering 是驾驭一支马队——每匹马跑不同的路线，你负责规划路线、分配任务、验收结果。

---

## 我的 Harness 架构

我不会编程，但我同时驾驭着多个 AI 工具：

```
┌─────────────────────────────────────────────────────┐
│                    我（决策层）                        │
│                                                     │
│    判断该不该做 → 选择用哪个工具 → 验收结果            │
└──────────┬──────────────────┬───────────────────────┘
           │                  │
     ┌─────▼─────┐      ┌────▼──────┐
     │  Kiro CLI  │      │ OpenClaw  │
     │  (执行层)   │      │ (交互层)   │
     ├───────────┤      ├──────────┤
     │• 问题分析  │      │• 飞书对话  │
     │• 代码生成  │      │• 日常助手  │
     │• 文档生成  │      │• 信息查询  │
     │• 系统操作  │      │• 方案讨论  │
     │• 安全巡检  │      │           │
     └─────┬─────┘      └────┬──────┘
           │                  │
     ┌─────▼──────────────────▼──────┐
     │         输出层                  │
     │                                │
     │  Wiki 文档  │  知识库  │  报告   │
     └────────────────────────────────┘
```

两个 AI 的分工很明确：
- **Kiro**：重活。分析告警、排查故障、生成运维文档、执行系统命令
- **OpenClaw**：轻活。日常沟通、方案讨论、信息查询

不是哪个更强的问题，是各自擅长的场景不同。

---

## 一个真实的工作流

以一次 Redis 巡检为例，看看 Harness Engineering 在实际工作中是怎么运转的：

```
09:00  收到告警：Redis 内存使用率 85%
  │
  ▼
09:01  【决策】需要做一次全面巡检，用 Kiro
  │
  ▼
09:02  【Kiro 执行】
  │    ├── 连接 Redis 集群
  │    ├── 扫描大 Key（SCAN + MEMORY USAGE）
  │    ├── 分析内存分布
  │    ├── 生成 Top 20 大 Key 报告
  │    └── 输出巡检文档（Markdown）
  │
  ▼
09:08  【我验收】
  │    ├── 检查报告是否合理
  │    ├── 确认大 Key 归属哪个业务
  │    └── 判断是否需要清理
  │
  ▼
09:10  【Kiro 执行】生成 Wiki 格式文档
  │
  ▼
09:12  【上传 Wiki】团队可查阅
  │
  ▼
09:13  【OpenClaw】在钉钉群通知相关研发
  │
  ▼
  完成。从告警到处置，13 分钟。
```

整个过程中，我做了三件事：**决策、验收、判断**。AI 做了剩下所有的事。

这就是 Harness Engineering 的核心：**人负责方向，AI 负责执行。**

---

## 驾驭的关键不是技术，是判断力

很多人以为驾驭 AI 需要很强的技术能力。不是的。

驾驭 AI 需要的不是编程能力，而是判断力：

**1. 知道该做什么**

收到一个告警，我知道该查什么、查到什么程度、结果意味着什么。这是 10 年运维经验给的，AI 给不了。

**2. 知道该用哪个工具**

分析问题用 Kiro（需要执行命令），通知同事用 OpenClaw（需要发消息）。选错工具，效率减半。

**3. 知道结果对不对**

AI 生成的报告不一定 100% 准确。我能看出来哪些数据合理、哪些有问题，因为我见过太多真实的故障场景。

```
AI 的能力边界：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

AI 能做的           AI 做不了的
─────────           ──────────
执行命令             判断该不该执行
生成报告             判断报告对不对
写代码               判断代码该不该上线
分析数据             判断数据意味着什么
给出方案             判断方案适不适合当前场景

→ AI 是手脚，你是大脑
```

---

## 从 Human in the Loop 到 Human on the Loop

王晓妍老师在 Meetup 上还提到了一个管理进化路径：

```
阶段一：Human in the Loop（人在环中）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 每一步都要人确认
"AI 帮我查一下" → 确认 → "再帮我分析" → 确认 → ...
效率：低

        ▼

阶段二：Human on the Loop（人在环上）  ← 我现在在这里
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 自主执行，人监督和验收
"帮我做一次 Redis 巡检" → AI 自动完成 → 我验收结果
效率：高

        ▼

阶段三：Human out of Loop（人在环外）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI 完全自主，人只定目标
每天自动巡检 → 自动生成报告 → 自动发布
效率：最高
```

我现在大部分工作处于第二阶段：给 AI 一个任务，它自主完成，我验收结果。少部分已经到了第三阶段——比如每天定时自动生成运维报告并发布，我只需要偶尔检查一下。

---

## 给想入门的人的建议

如果你也想从 Prompt Engineering 进阶到 Harness Engineering：

**1. 先跑通一个完整的工作流**

不要一上来就搞多个 AI 协作。先用一个工具，把一个场景从头到尾跑通。我最开始就是用 Kiro 做告警分析，跑通了再加 OpenClaw。

**2. 让 AI 做重复的事，你做判断的事**

把你每天重复做的事情列出来，挑一个交给 AI。你的时间应该花在判断和决策上，不是执行上。

**3. 不要追求完美，追求可用**

AI 生成的东西不会 100% 完美，但 80% 可用就够了。剩下 20% 你花 2 分钟修改，比你自己从头做快 10 倍。

**4. 建立自己的知识库**

每次 AI 帮你完成一个任务，把结果存下来。我两个多月积累了 200 多篇运维文档，这些就是我的知识库，也是 AI 下次工作的参考。

---

## 一个运维的视角

Harness Engineering 这个概念听起来很新，但本质上运维一直在做类似的事——我们驾驭的不是 AI，是各种工具和系统。以前是 Ansible、Terraform、Jenkins，现在多了 Kiro 和 OpenClaw。

工具变了，思维方式没变：**选对工具、分配任务、验收结果。**

唯一的区别是，以前的工具只能做你明确告诉它的事，现在的 AI 工具能理解你的意图，自主完成任务。这让运维的杠杆效应放大了很多倍——一个人，驾驭多个 AI，干以前一个团队的活。

2026 年最重要的技能不是写代码，是 Harness Engineering。

---

## 关于这个公众号

「AI运维实验室」持续分享 AI 工具在企业中的真实落地经验。不是概念，是踩过的坑和跑通的路。

往期文章：
- [一个运维去了养虾社北京 Meetup，聊聊我看到的 OpenClaw 生态]
- [把 OpenClaw 搬进公司：一个运维的企业级部署实战]
- [用 OpenClaw 做 AWS Redis 巡检：从告警到报告的全自动化]

---

*写于 2026 年 3 月，驾驭 AI 的第三个月。*


Harness Engineering

# 给龙虾装上运维技能：用 OpenClaw 做 Redis 巡检，7 秒查完 24 个集群

> 这是「AI运维实验室」的第三篇文章。前两篇聊了养虾社 Meetup 见闻和 OpenClaw 企业部署，这一篇讲一个具体的实战案例——怎么给你的龙虾写一个 Redis 巡检 Skill。

---

## 每天 20 分钟的体力活

我管着 24 个 ElastiCache Redis 集群，之前每天早上的巡检流程是这样的：

1. 登录 AWS 控制台
2. 逐个点开集群看 CPU、内存、连接数
3. 跟昨天的数据对比，看有没有异常
4. 把结果整理成报告发群里

一套下来 20 分钟，每天重复，纯体力活。

后来我用 OpenClaw 做了自动化。给龙虾写了一个 Redis 巡检 Skill，现在在飞书里打两个字"Redis 巡检"，龙虾 7 秒出完整报告。

---

## 效果长什么样

在飞书聊天窗口发一句话，龙虾自动执行脚本、拉数据、对比基线、输出报告：

```
━━━━━━━━━━━━━━━━━━━━━━━━
Redis 每日巡检报告
2026年03月19日 星期四 09:30
最近 24 小时
━━━━━━━━━━━━━━━━━━━━━━━━

[OK] 全部 24 个集群正常

-- TOP 5 CPU
  集群                            CPU
  xxx-redis-06                  20.1%
  xxx-cache-01                19.4%
  xxx-main                    19.3%
  xxx-proxy                   14.9%
  xxx-biz-01                  12.3%

-- TOP 5 内存
  集群                            内存
  xxx-data                    72.8%
  xxx-persist                 58.4%
  xxx-mail                    57.7%
  xxx-queue                   57.6%
  xxx-proxy                   48.4%

-- TOP 5 连接数
  集群                           连接数
  xxx-persist                  4,101
  xxx-redis-06                   2,281
  xxx-redis-02                   2,076
  xxx-redis-05                   1,679
  xxx-main                     1,650
━━━━━━━━━━━━━━━━━━━━━━━━
```

如果有异常，会自动标记并高亮：

```
! 异常集群: 2/24

  集群                            异常项
  xxx-cache-01                CPU: 72.3% (阈值70%, 基线45.2%, +60%) [!]
  xxx-redis-04                  Evictions: 156 (过去24h)
```

`[!]` 是警告（指标突增 1.5 倍以上），`[!!]` 是严重（突增 2 倍以上）。不是简单的阈值告警，而是跟 7 天前同时段对比——能发现"缓慢恶化"的问题，比如内存每周涨 2%，单看当天数据正常，但跟基线一比就能发现趋势。

---

## 三样东西，就这么多

先看整体架构：

```
┌─────────────────────────────────────────────┐
│                  飞书                        │
│  用户发送 "Redis 巡检"                       │
└──────────────────┬──────────────────────────┘
                   │ WebSocket
                   ▼
┌─────────────────────────────────────────────┐
│            OpenClaw Gateway                  │
│  ┌─────────┐  ┌──────────┐  ┌────────────┐ │
│  │消息路由  │→│ AI Agent  │→│ SKILL.md   │ │
│  │         │  │ (Gemini)  │  │ 匹配触发词 │ │
│  └─────────┘  └──────────┘  └─────┬──────┘ │
└───────────────────────────────────┼─────────┘
                                    │ exec
                                    ▼
┌─────────────────────────────────────────────┐
│          redis-overview.sh                   │
│  ┌──────────┐  ┌───────────┐  ┌──────────┐ │
│  │读取      │→│ 批量查询   │→│ 对比基线  │ │
│  │config.json│ │ CloudWatch │  │ 标记异常  │ │
│  └──────────┘  └───────────┘  └──────────┘ │
└───────────────────────────────────┬─────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────┐
│         AWS CloudWatch API                   │
│  24 集群 × 5 指标 = 2 次 API 调用            │
│  当前数据 + 7 天前基线                        │
└─────────────────────────────────────────────┘
```

巡检执行流程：

```
"Redis 巡检"
     │
     ▼
  读取 config.json（集群列表 + 阈值）
     │
     ▼
  构建批量查询 JSON
  ├── 当前时段: 5 指标 × 24 集群
  └── 基线时段: 同上（7天前）
     │
     ▼
  2 次 CloudWatch API 调用（共 7 秒）
     │
     ▼
  逐集群分析
  ├── CPU > 70%? ──────→ 标记异常
  ├── CPU 突增 > 1.5x? → 标记 [!]
  ├── CPU 突增 > 2.0x? → 标记 [!!]
  ├── 内存 > 80%? ─────→ 标记异常
  ├── 命中率下降 > 10%? → 标记异常
  └── Evictions > 0? ──→ 标记异常
     │
     ▼
  输出报告（异常集群 + TOP 5）
```

整个方案的实现只有三样东西：

### 一个 bash 脚本

核心逻辑：调 CloudWatch `get-metric-data` API 批量查询所有集群的指标，同时拉 7 天前同时段的数据作为基线，逐个对比发现异常。

```bash
aws cloudwatch get-metric-data \
  --metric-data-queries file:///tmp/queries.json \
  --start-time "$START_TIME" \
  --end-time "$END_TIME" \
  --profile "$PROFILE" \
  --region "$REGION"
```

关键优化：用批量查询代替逐个查询。26 个集群 × 5 个指标 = 130 个指标，只需要 2 次 API 调用（当前 + 基线），7 秒搞定。之前逐个查要 3 分钟。

### 一份说明书（SKILL.md）

告诉龙虾：用户说什么话的时候，跑哪个脚本。

```
- "Redis 巡检" → redis-overview.sh（全局巡检）
- "xxx Redis 详情" → redis-detail.sh（单集群详情）
- "Redis 对比" → redis-compare.sh（上线前后对比）
```

龙虾不需要理解 Redis 是什么，它只需要知道"用户说了这句话，我就跑这个命令"。SKILL.md 就是这个映射关系。OpenClaw 的 Skill 体系设计得很巧妙——你不用写代码教 AI 怎么做，只需要用 Markdown 写一份说明书。

### 一个配置文件（config.json）

定义你的集群分组和告警阈值：

```json
{
  "groups": {
    "core": ["xxx-main", "xxx-cache"],
    "api": ["xxx-redis-01", "xxx-redis-02"]
  },
  "thresholds": {
    "cpu_warn": 70,
    "memory_warn": 80,
    "spike_ratio": 1.5
  }
}
```

换个环境用，改这个文件就行，脚本不用动。

---

## 不只是巡检

同样的模式，我还做了两个场景：

**单集群详情**——想看某个集群最近 3 小时的趋势，发一句"xxx-main 详情"，龙虾返回 CPU、内存、连接数、命中率、延迟的逐小时数据。

**上线对比**——发布后想确认有没有影响 Redis，发一句"xxx-main 对比 30"，龙虾自动对比发布前后 30 分钟的指标变化，输出对比表。

三个场景覆盖了日常 Redis 运维 90% 的需求：每天看一眼全局、出问题查详情、上线后确认影响。这就是 OpenClaw Skill 的威力——一个 Skill 解决一类问题，组合起来就是一套完整的运维工具箱。

---

## 从 20 分钟到 7 秒

| | 之前 | 现在 |
|---|---|---|
| 巡检耗时 | 20 分钟 | 7 秒 |
| API 调用 | 130+ 次（逐个查） | 2 次（批量查） |
| 异常发现 | 靠肉眼对比 | 自动基线对比 |
| 报告输出 | 手动整理 | 自动生成 |

省下来的不只是时间。以前巡检是"看一眼没问题就过了"，现在龙虾每天自动跟 7 天前的基线对比，能发现肉眼看不出来的缓慢变化。

这也是 OpenClaw 做运维的核心价值——不是替代运维，是给运维装上外挂。你还是那个做决策的人，但龙虾帮你把重复劳动干了。

---

## 安全：给龙虾最小的钥匙

把 AWS AK/SK 交给 AI Agent，安全必须做到位。我们的做法是三层防护：

**最小权限**

给龙虾的 IAM 用户只有 CloudWatch 只读权限，连 EC2 列表都看不了：

```json
{
  "Effect": "Allow",
  "Action": [
    "cloudwatch:GetMetricData",
    "cloudwatch:ListMetrics",
    "elasticache:DescribeCacheClusters",
    "elasticache:DescribeReplicationGroups"
  ],
  "Resource": "*"
}
```

就这四个 Action，多一个都不给。即使 AK/SK 泄露，攻击者也只能看监控数据，碰不了任何资源。

**IP 白名单**

IAM Policy 里加了 IP 条件限制，只允许 OpenClaw 所在机器的出口 IP 调用：

```json
{
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": ["<办公网络出口IP>/32"]
    }
  }
}
```

AK/SK 拿到别的机器上用？直接 Access Denied。

**异常访问检测**

通过 CloudTrail + EventBridge 监控 AK/SK 的使用行为：

- CloudTrail 记录所有 API 调用（谁、什么时间、从哪个 IP、调了什么）
- EventBridge 规则匹配异常模式：非白名单 IP 调用、非工作时间调用、调用频率突增
- 触发后 Lambda 自动推告警到钉钉，同时可以自动禁用 AK/SK

```
CloudTrail → EventBridge 规则 → Lambda → 钉钉告警
                                    └→ 自动禁用 Key
```

三层加起来：最小权限控制爆炸半径，IP 白名单防泄露利用，异常检测兜底。给龙虾的钥匙，只能开一扇门，只能在一个地方用，用的时候还有摄像头盯着。

---
## 代码开源

完整代码已开源，7 个文件，拿去改改 config.json 就能给你的龙虾装上 Redis 巡检技能：

github.com/clawnoc/clawnoc-skills/tree/main/skills/aws-redis-monitor

---

*写于 2026 年 3 月，又一个不用手动巡检的早晨。龙虾已经把报告发到飞书了。*

---

**关注「AI运维实验室」**，持续分享 OpenClaw 运维实战、企业级 AI 落地经验。


给龙虾装上运维技能：用 OpenClaw 做 Redis 巡检

# 把 OpenClaw 搬进公司：一个运维的企业级部署实战

> 这是「AI运维实验室」的第二篇文章。上一篇聊了养虾社 Meetup 的见闻，这一篇讲讲我自己的实践——怎么把 OpenClaw 部署到公司的 AWS 环境里，让业务团队用自然语言查数据。

---

## 起因：业务天天找研发查数据

我们公司做海外互联网产品，业务团队经常需要查各种运营数据——用户信息、行为记录、注册时间之类的。每次都要找研发写 SQL，研发烦，业务也等得急。

有一天开会，研发提了一个想法：能不能搭一个 AI 平台，让业务自己用自然语言描述需求，系统自动返回结果？

OpenClaw + MCP 刚好能做这件事。

---

## 架构：两个 VPC，一道墙

方案不复杂，但安全必须到位。

```
┌──────────────────────────────┐
│     OpenClaw VPC             │
│                              │
│  OpenClaw ──► Kiro CLI       │
│  (Web Chat)   (代码生成)      │
│                              │
└──────────┬───────────────────┘
           │ 公网隔离，IP 白名单
           ▼
┌──────────────────────────────┐
│     业务 VPC                  │
│                              │
│  API Gateway ──► MCP Server  │
│                  → 数据库     │
└──────────────────────────────┘
```

两个 VPC 完全隔离，不做 VPC Peering。OpenClaw 通过公网调用业务侧的 MCP 接口，但只允许 OpenClaw 的固定 IP 访问。业务人员通过 VPN 访问 OpenClaw 的 Web 界面。

工作流分两个阶段：
- **搭建阶段**：业务提需求 → OpenClaw 对话 → Kiro 写代码 → 生成查询页面 → 研发 Review → 上线
- **日常使用**：业务人员打开页面 → 输入参数 → MCP 接口查数据库 → 返回脱敏结果

---

## 运维做了什么

说实话，OpenClaw 本身的安装不难，难的是把它安全地跑在企业环境里。我做的事情：

**基础设施**
- 一台 EC2（t3.medium，2C4G），Amazon Linux 2023
- EBS 加密，IMDSv2 强制（防 SSRF）
- ALB + ACM 证书，TLS 1.3
- 域名通过内部 DNS 解析

**网络安全**
- SSH 只允许堡垒机访问，不开公网 22 端口
- HTTPS 只允许 VPN IP 白名单
- 安全组最小权限，入站只开必要端口
- VPC Flow Logs 开启，记录所有网络流量

**访问控制**
- 通过 堡垒机 堡垒机管理，MFA 认证
- 研发按需授权，不给 root 权限
- IAM 使用 Instance Profile，不在机器上放 AK/SK

**备份和恢复**
- 每周自动快照，保留 35 天
- EC2 Auto Recovery 开启，实例故障自动恢复
- CloudWatch 监控 CPU/内存/磁盘，异常告警推钉钉

这些东西加起来，比装 OpenClaw 本身花的时间多 5 倍。但这就是企业级部署和个人玩具的区别。

---

## 安全：不是可选项

AI 工具进企业，安全是第一道门槛。我们在 MCP 接口层做了三件事：

**字段白名单**

每个查询接口明确定义可返回的字段。白名单之外的字段一律不返回。查用户信息只返回昵称、注册时间、设备类型，不返回密码、token、密钥。

**数据脱敏**

MCP 接口返回数据前自动脱敏：
- 手机号中间 4 位打码
- 邮箱用户名部分打码
- 身份证中间 11 位打码

脱敏在接口层统一处理，不依赖前端，确保任何调用方式都无法拿到明文。

**查询日志全量记录**

每次查询记录谁查的、什么时候查的、查了什么参数、返回了什么。日志保留 90 天，支持事后审计。

这三条是硬性要求，MCP 接口上线前必须全部实现。

---

## Token 消耗和用量监控

AI 工具进企业，成本控制是绕不开的话题。

我们的 AI 模型调用采用 AWS Bedrock 和 Kiro 共存的方式——OpenClaw 通过 Bedrock 调用 Claude 模型，日常运维分析和文档生成走 Kiro 订阅。两条链路各司其职，互为备份。但不管走哪条，token 用量都必须监控。

**用量监控**
- Bedrock 的调用量通过 CloudWatch 监控：Invocations（调用次数）、InputTokenCount、OutputTokenCount
- 设置了日级别的费用告警，超过阈值推钉钉
- 每周看一次用量趋势，防止某个查询场景意外消耗大量 token

**成本优化**
- 简单查询用小模型（Haiku），复杂分析才用大模型（Sonnet）
- 优化 Prompt，减少不必要的上下文传递
- 查询结果做缓存，相同参数短时间内不重复调用模型

---

## OpenClaw 安全更新策略

OpenClaw 是开源项目，版本迭代很快。但在企业环境里，不能无脑跟进最新版。

**更新原则**
- 不自动更新，每次手动评估 changelog 后再决定是否升级
- 先在测试环境验证，确认无问题再更新生产
- 更新前做 AMI 快照，出问题 30 分钟内回滚

**Skill 策略：不装第三方，全部自己实现**

这是我们的一个重要决策：不从 ClawHub 安装任何第三方 Skill。

原因很简单——第三方 Skill 的代码质量和安全性无法保证，OpenClaw 官方自己都在 GitHub 上标注"may contain suspicious or malicious skills"。在企业环境里，一个恶意 Skill 就可能导致数据泄露。

我们的做法是：所有需要的能力，直接通过 AI 模型本身的能力实现，或者用 Kiro 写自定义脚本。比如需要读写文档，不装 feishu-doc Skill，而是让 Kiro 直接调用飞书 API。这样每一行代码都在我们自己的控制范围内。

多花点时间，换来的是完全可控。

---

## 成本：月费 $36

| 项目 | 月费 |
|------|------|
| EC2 t3.medium | ~$30 |
| EBS 30GB gp3 | ~$2.5 |
| API Gateway | ~$3.5 |
| AI 模型调用 | 公司已有订阅 |
| **合计** | **~$36** |

转 Reserved Instance 后可降到 ~$20/月。

$36 一个月，替代了业务找研发查数据的人力成本。以前一个查询需求从提出到拿到结果可能要半天，现在业务自己几分钟搞定。

---

## 踩坑和思考

**踩坑 1：VPC 隔离方案的选择**

一开始考虑过 VPC Peering，让 OpenClaw 直接访问业务数据库。后来否决了——一旦 OpenClaw 被攻破，攻击者就能直接摸到数据库。最终选择公网 + IP 白名单 + API Gateway 的方案，多一层隔离，安全性更高。

**踩坑 2：堡垒机权限管理**

研发需要 SSH 到 OpenClaw 服务器部署和调试，但不能给太大权限。通过 堡垒机 做细粒度授权，每个人只能访问自己被授权的资产，所有操作有录像回放。

**踩坑 3：监控不能少**

AI 工具跑在生产环境，跟其他服务一样需要监控。CPU、内存、磁盘、网络，一个都不能少。我们复用了现有的 CloudWatch → SNS → Lambda → 钉钉的告警链路，没有额外搭建。

---

## 一个运维的视角

上一篇文章我说过："AI 工具的落地，20% 是选型和开发，80% 是工程化和运维。"

这次部署 OpenClaw 再次验证了这个判断。OpenClaw 本身很好装，但要让它在企业环境里安全、稳定、可控地运行，需要做的事情远比安装多得多：

- 网络隔离和访问控制
- 数据安全和脱敏
- 备份和灾备
- 监控和告警
- 权限管理和审计

这些不是 AI 的事，是运维的事。

会用 OpenClaw 的人越来越多，但能把它安全地部署到企业环境里的人很少。如果你也在做类似的事情，欢迎交流。

---

## 关于这个公众号

「AI运维实验室」持续分享 AI 工具在企业中的真实落地经验。不是概念，是踩过的坑和跑通的路。

上一篇：[一个运维去了养虾社北京 Meetup，聊聊我看到的 OpenClaw 生态]

---

*写于 2026 年 3 月，OpenClaw 企业部署完成之后。*


把 OpenClaw 搬进公司：一个运维的企业级部署实战

# 一个运维去了养虾社北京 Meetup，聊聊我看到的 OpenClaw 生态

> 这是「AI运维实验室」的第一篇文章。我是一名运维工程师，正在探索 AI 工具在企业中的真实落地。这个号会持续分享我在这条路上的实践、踩坑和思考。

---

## 为什么一个运维会去参加 OpenClaw 的活动

3 月 14 日，北京，养虾社的第一场线下 Meetup。

养虾社是国内专注 OpenClaw 的中文社区，这次活动不是发布会，也不是入门教学，更像是一场实战派的开放麦——带上你的电脑和小龙虾，来聊聊你到底用它做了什么。

说实话，报名的时候我有点犹豫。现场大概率是创业者、产品经理、投资人，而我是一个运维。我每天打交道的是监控告警、安全加固、基础设施，不是产品设计和商业模式。

但最近半年，我的工作内容正在发生变化。我开始用 AI 工具搭建内部平台，研究怎么把 AI Agent 安全稳定地跑在生产环境里。我想去看看，这个生态里的其他人在做什么，他们遇到了什么问题。

去了之后发现，这一趟没白来。

---

## 黄东旭：不要给 AI 设置边界

黄东旭是 PingCAP 联合创始人兼 CTO，也是 mem9.ai 的创始人。他分享的主题是"如何解决龙虾脑雾问题"——也就是 OpenClaw 的记忆机制。

他的做法很有意思：基于遗忘曲线和梯度遗忘模型来控制记忆召回，避免大模型把多年前的无关信息翻出来。团队最初想做复杂的权重计算模型，但他最终的选择是——把原始信息直接交给大模型，让它自主判断哪些该记住、哪些该遗忘。

他说这才是 AI native 的开发方式：信任模型的能力，而不是用传统工程思维去约束它。

这个思路贯穿了他整场分享：

- 产品设计上，他摒弃了传统的邮箱、用户名注册流程，让大模型自动记忆 Space ID，用数字串作为身份标识，理念贴近区块链。
- 关于网络安全，他说了一句很大胆的话：未来安全软件或许只需要对大模型提醒"注意安全"即可，大模型对安全的理解可能优于人工编写的规则。
- 关于多 Agent vs 单 Agent，他的观点是：没有标准答案，组织结构是人类发明的，未必适用于 AI 大模型。

作为运维，"不要给 AI 设置边界"这句话让我想了很久。我们这个职业天然喜欢把事情分层、分模块、定义清楚边界。但 AI 的能力边界和人不一样，硬套人类的架构，可能反而限制了它。

他还提到，OpenClaw 设计之初是面向个人的，未来趋势大概率走向云端化和 Serverless。他个人看好 Cloudflare，看好 Agent native 的基础设施。

---

## 王晓妍：从 80 个 Agent 的混乱到六阶段演进

王晓妍是 OPC 创始人，自称"野生全栈，养虾专业户"。她的分享是全场最有实操感的。

她一上来就讲了自己的踩坑经历：曾经因为太兴奋，一次性创建了 80 多个子 Agent，结果监控 Agent 同时发出十几个告警，整个系统陷入混乱。

她的反思是：应该像招聘员工一样逐步引入、逐个理顺，而非一次性大规模上线。

然后她分享了自己摸索出的六阶段演进路径：

1. **探索阶段**：给 Agent 定义个性、行为准则，安装 Skills 配置 Jobs
2. **踩坑与反思**：从混乱中学会逐步引入
3. **沉淀与固化**：固化 SOP，把大技能拆解为可组合嵌套的小技能，固化后的任务迁移到便宜的国产模型，只保留探索性任务给最强模型
4. **组织架构设计**：推翻了照搬人类公司部门的架构，转为以"Mission"定义角色，分为 Context 组织层（信息采集、记录、整理、关联挖掘）和 Execution 执行层（创意 Agent、牛马 Agent、研究 Agent）
5. **闭环与自治**：Agent 管理 Agent、Agent 测试 Agent，人类只需定义目标、分配资源、验收结果
6. **协作与涌现**（探索中）：Agent 间、Agent 与环境、Agent 与人的协作反馈

她有一句话我印象很深：管理方式的进化路径是 Human in the Loop → Human on the Loop → Human out of Loop。重点是定目标、给资源、品结果。

她还说，2026 年最重要的技能是 Harness Engineering，未来人才的价值取决于驾驭 Agent 的数量和质量。品位是 AI 时代的核心壁垒。

---

## 刘艾伦：3 周开发一个 AI 塔罗牌应用，日成本 $500

刘艾伦是 MysticX.AI 的联合创始人，大厂产品 5 年加创业 5 年的背景。他用 3 周时间基于 OpenClaw 开发出了一个 AI 塔罗牌应用。

他分享了一些很实在的数据：

- OpenClaw 可以 7-8 小时独立搭建一个复杂的后台管理平台，包含 PV/UV、卡牌皮肤、塔罗师信息等模块
- 整个团队只需要 2 名开发人员，主要负责账号维护、API 环境调整、提示词监督和死循环处理
- 开发一个后台管理平台的单日费用约 $500
- 工作流是在飞书群里提需求，OpenClaw 独立完成需求分析、设计、开发、代码审查

他也提到了 OpenClaw 的局限：对飞书/Lark 文档的读取能力较弱，解决方案是导出为 Word 格式让它本地解析。

一个有意思的观点：他认为产品经理的价值正在从"给工程师提需求"转变为"产品思考者"——核心能力是与 Agent 沟通、评估 Agent 产出质量。他还提到亚马逊近期裁撤了 1000 名完成 Agent 数据结构搭建的工程师，技术建议是用英文与 Claude 模型沟通效果优于中文。

---

## 辛然：AI 创业的成本优化和资源支持

辛然来自 AWS Startup 团队，他的分享更偏实操层面——怎么把 AI 创业的成本降下来。

首先他提到了 AI 编程工具 Kiro，对标 Cursor，有 20、40、200 美金三档套餐。如果选 Claude 模型，同价位套餐比 Cursor 更划算。

成本优化方面，他分享了两个思路：

- **用 Bedrock 跑定时任务**，比直接调用 API 能省一半成本
- **大小模型搭配**，结合亚马逊平台的模型路由功能，把简单任务分给便宜的小模型，复杂任务才用大模型

最后他提到 AWS Startup 有 10 万美金的扶持资源，可以抵扣平台调用、Kimi 以及 GPU 的费用。建议做 AI 创业的尽早联系他对接。

对运维来说，Bedrock 定时任务和模型路由这两个点很实用——本质上就是用基础设施层面的调度来降低 AI 的运行成本，这恰好是运维擅长的事。

---

## 圆桌讨论：已经有人跟 AI 共生了，我们还只是在用 AI

圆桌由四十二章经创始人曲凯主持，嘉宾包括黄东旭、明势创投的徐之浩和 Sheet0 创始人 Wells Wang。

几个让我印象深刻的点：

**投资人怎么看 OpenClaw 生态**

徐之浩把生态里的企业分成三类：Fork 开源项目包装成新产品（不看好，迭代跟不上主分支）、做周边产品如记忆管理（有机会）、做垂直 Agent/Skill（有机会）。信号很明确：壁垒只是"比官方多了个 UI"的公司没有投资价值。

**$1000 token 怎么最快花完**

这是黄东旭提出的一个面试思路。不是省着花，也不是为了花而花，而是看你能不能在最短时间内把算力转化成有意义的产出。花得快、花得值、花得有章法——三个维度缺一不可。本质上是在测试 AI 时代的管理能力：以前管人，现在管 Agent。

**产品经理比程序员更稀缺**

Wells Wang 说，AI 能批量生产 Demo，技术强的人不一定有产品好坏的辨别力，而产品判断力需要时间积累。技术门槛被 AI 拉平后，"知道该做什么"比"能不能做出来"更值钱。

**与 Agent 共生的状态**

圆桌上有人描述了自己的日常：Agent 一直在干活，干完一个到下一个，人像导演一样关注它接下来要干什么。半夜也在想明天 Agent 该干什么，睡前必须给它扔一个任务。"他在那啥都没干，你不觉得自己亏得慌？"

有人感慨："他们已经跟 AI 共生了，我们还只是在用 AI。"

这句话可能是全场最扎心的一句。

---

## 一个运维的视角

现场大部分人关心的是：用 OpenClaw 能做什么产品、有什么创业机会。

而我一直在想另一个问题：**谁来让这些东西稳定地跑起来？**

王晓妍创建 80 个 Agent 导致告警风暴，刘艾伦需要人处理死循环，黄东旭说未来走向云端化和 Serverless——这些场景背后都需要运维能力。

会用 OpenClaw 的人越来越多，但能把它在企业环境里安全、稳定、可控地运行的人很少。当 OpenClaw 从个人玩具变成企业工具，部署、监控、安全、成本控制这些问题就会浮出水面。

我不会在这里讲太多具体的技术细节（后续文章会写），但可以分享一个感受：**AI 工具的落地，20% 是选型和开发，80% 是工程化和运维。** 大部分人的注意力在前面那 20%，而真正决定能不能用起来的是后面那 80%。

---

## 关于这个公众号

「AI运维实验室」会持续分享：

- **AI 工具在企业中的真实落地经验** — 不是概念，是踩过的坑和跑通的路
- **运维视角的 AI 工程实践** — 监控、安全、成本控制、自动化
- **OpenClaw / AI Agent 相关的技术探索** — 从运维人的角度看这个生态

如果你也在探索 AI 和运维的交叉地带，欢迎关注，一起交流。

---

*写于 2026 年 3 月，从养虾社北京 Meetup 回来之后。*
