给龙虾配了多 Agent，踩了一堆坑
这是「AI运维实验室」的第六篇文章。这次聊聊我在 OpenClaw 上配置多 Agent 的完整过程——哪些能用，哪些不能用，以及为什么。
为什么要拆 Agent
一开始我只用一个 Agent（main），所有事情都扔给它：AWS 巡检、成本查询、新闻推送、飞书文档、互联网搜索。
用了一个多月，问题来了：
- 上下文越来越长 — 巡检数据、新闻内容、文档操作混在一起，Gemini 频繁报
An unknown error occurred - 互相干扰 — 问完 Redis 巡检，接着问新闻，Agent 有时候会把巡检数据当成新闻内容回复
- 定时任务打架 — 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：
# 创建 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：
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 字段：
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 里加了规则：
## 重要规则
- 你是 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：
"feishu": {
"accounts": [
{"id": "default", "appId": "cli_原来的机器人"},
{"id": "devops", "appId": "cli_新机器人", "defaultAgent": "devops"}
]
}
两个机器人都能正常收发消息，我以为搞定了。
第二天早上，发现所有定时任务的飞书通知全部没收到。查日志：
Request failed with status code 400
排查过程：
- 先确认定时任务本身有没有执行 → 执行了，
status: ok - 再看 delivery 状态 →
not-delivered - 看 Gateway 错误日志 → 飞书 API 返回 400
- 对比改动 → 唯一的变化就是加了第二个飞书 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 里也没找到飞书群路由和定时任务分发的讨论。有几种可能：
- 我的配置方式不对 — 飞书群路由可能需要额外的配置步骤，我没找到文档
- 飞书 channel 的多 Agent 支持还没做完 — Slack 和 Telegram 的路由可能是好的，飞书是后加的
- 版本问题 — 2026.3.13 可能有 bug，后续版本可能已经修复
如果你成功配置了 OpenClaw 多 Agent + 飞书群路由，欢迎留言告诉我哪里配错了。踩坑不丢人，配错了更不丢人——至少能帮后来的人少走弯路。
经验总结
- 不要过早拆分 — 一个 Agent 8 个 Skills 完全够用，上下文满了清一次会话比拆 Agent 简单
- 群隔离够用 — 不同群的 session 天然隔离，不需要多 Agent 也能避免上下文干扰
- 给别人用要谨慎 — 记忆无法隔离，你的操作历史会被其他用户看到。要么跑独立 Gateway，要么等官方支持记忆隔离
- 定时任务别动 — 全部留在 main agent 上，动了就出问题
- 改配置前想影响范围 — 加一个飞书 account 看似无害，结果把所有定时通知搞挂了
- 版本很重要 — 以上结论基于 OpenClaw 2026.3.13，后续版本可能修复
对 OpenClaw 多 Agent 的期待
OpenClaw 的多 Agent 功能还在早期阶段。从架构设计上看，Agent 创建、workspace 隔离、路由绑定的框架都有了，但细节还没打磨好。
我最期待的三个改进：
- 记忆按 Agent 隔离 — 这是多 Agent 能否用于多人场景的前提
- 定时任务支持非 main agent — 让不同 Agent 各自管理自己的定时任务
- 飞书多 account 的 delivery 路由 — 指定定时任务通过哪个机器人发送
如果这三个问题解决了，OpenClaw 的多 Agent 就能从"个人多角色"升级到"团队多成员"，适用场景会大很多。
在那之前，我的建议是：一个 Agent + 多个群 + 清会话，简单粗暴但有效。
关注「AI运维实验室」，持续分享 OpenClaw 运维实战、企业级 AI 落地经验。
