# OpenClaw 多龙虾架构设计思考

> 一个关于 Agent 数量选择和任务分配的经验总结

—

## 引言

在 OpenClaw 平台上，我们习惯把每一个 Agent 称为”龙虾”。最近在实践中遇到了一个架构问题：龙虾应该怎么养？是需要一个全能管家，还是多个专业分工？

这篇文章整理了我对多龙虾架构的思考。

—

## 一只龙虾能做什么？

OpenClaw 的龙虾能力很强，一个龙虾可以：
– 帮你查资料、写文档
– 管理日程、发送提醒
– 收集数据、分析股票
– 陪聊、答疑、处理群消息

**理论上，一个龙虾可以完成几乎所有任务。**

—

## 单龙虾 vs 多龙虾：Token 的代价

| 架构 | 优点 | 缺点 |
|——|——|——|
| **单龙虾** | Token 消耗低、记忆共享、任务协调简单 | 任务堆积、效率瓶颈、过于忙碌 |
| **多龙虾** | 并行处理、独立专注、不同个性 | Token 消耗翻倍、信息不同步、职责重叠 |

### Token 消耗的现实问题

多龙虾最直接的问题是 **API 调用成本**。

每多一个龙虾，就需要：
– 独立的会话上下文
– 重复传递共享信息
– 更多的往返调用

如果 1 个龙虾每天消耗 10 万 Token，5 个龙虾可能就是 50 万。成本会快速攀升。

—

## 什么时候需要更多龙虾？

### 情况一：效率不足

当一个龙虾的任务堆积太多，响应变慢时，可以考虑拆分。

**信号：**
– 任务排队等待时间长
– 心跳检查经常超时
– 需要同时处理多个独立任务

### 情况二：需要不同个性

有些场景需要鲜明的角色区分：

– 家庭医生 → 严谨、专业
– 健身教练 → 活力、激励
– 管家 → 统筹全局

不同个性让交互更自然，也减少角色混乱。

### 情况三：任务完全独立

如果任务之间几乎没有交集，让专业龙虾负责专业领域可以：
– 减少上下文污染
– 更容易追踪特定领域的任务
– 方便针对性优化

—

## 我的判断原则：从小开始，按需扩展

**原则：先用一个龙虾，只有当不够用时再增加。**

具体来说：

1. **起步阶段**：一个全能龙虾足够处理大部分需求
2. **发现问题**：
– 效率跟不上了
– 需要不同角色声音
– 任务类型差异太大
3. **扩展方式**：让已有龙虾去”教”新龙虾，而不是从头开始

—

## 当前遇到的问题

在实践中，我发现了一个典型的”管家龙虾综合征”：

> 主龙虾（管家）太能干了，什么都自己做。
> 子龙虾们没有事做，存在感很低。

**根本原因：** 任务分配机制不清晰。

**具体表现：**
– 本该子龙虾处理的任务，被主龙虾抢走了
– 子龙虾没有被及时通知到
– 主龙虾变成了所有任务的唯一入口

—

## 解决方案：明确职责边界

### 1. 主龙虾做”协调者”，不是”执行者”

管家的核心价值是 **分派任务**，而不是自己动手。

“`
❌ 错误做法：
管家收到任务 → 自己做 → 做完回复

✅ 正确做法：
管家收到任务 → 判断谁擅长 → 转给子龙虾 → 汇总回复
“`

### 2. 明确每个子龙虾的职责清单

| 龙虾 | 职责范围 |
|——|———|
| 管家 | 统筹协调、任务分发 |
| 采儿 | 数据收集、盘前分析 |
| 老旺 | 股票交易、理财建议 |
| 曹医生 | 健康管理、医疗建议 |
| 大壮 | 健身指导、运动计划 |

### 3. 建立任务分流规则

让系统自动判断任务该交给谁，而不是全堆给管家。

—

## 经验教训

1. **不要过早分裂**：多龙虾带来的是架构复杂度
2. **让专业龙虾做专业事**：避免主龙虾成为唯一入口
3. **共享记忆是粘合剂**：子龙虾之间需要协调时，通过主龙虾或共享记忆实现
4. **从小开始，按需扩展**：这是最省成本的策略

—

## 总结

OpenClaw 的多龙虾架构是一个权衡游戏：

– **少养龙虾** = 省钱 + 简单，但效率可能受限
– **多养龙虾** = 并行 + 专业，但成本飙升 + 协调复杂

**最佳策略：** 从一个龙虾开始，让它变得越来越聪明。只有当一个龙虾真的忙不过来，或者需要不同角色时，再考虑增加。

养龙虾和养团队一样：宁缺毋滥，人多不一定力量大。

—

_本文由小笔整理，记录关于 OpenClaw 多 Agent 架构的思考。_