五只龙虾不打架:OpenClaw 多 Agent 从安装到 7*24 自动运行完全指南

之前写的装了五只龙虾全在打架？OpenClaw 多 Agent 的正确拆法这篇偏策略，这次整篇教程指南，便于动手实现。

龙虾装好了，下一个动作是什么？大多数人的回答是：再装几只。
一只写代码，一只做调研，一只跑内容，一只管发布。听起来合理。但社区里最常见的求助帖是：「我的五只龙虾在群里互相抢消息，怎么办？」
问题不在数量，在拆分逻辑。

最常见的错误：按职责拆 Agent

直觉告诉你：前端一个、后端一个、内容一个、运营一个。就像组建团队一样，每个岗位配一个人。
这个直觉是错的。
@berryxia 在实战中总结了一条判断标准：按上下文拆，不按职责拆。
编程任务不管前端后端，上下文都在代码里，交给 Codex 或 Claude Code 一个执行者就行。写小红书和写公众号，对一个 Agent 来说只是不同的 Skill，上下文可以隔离清楚。这些场景不需要拆分。
该拆的情况只有三种：

上下文持续积累且互不干扰。调研 Agent 积累行业知识，写作 Agent 积累个人风格——两套记忆混在一起会互相污染。
工作流程完全独立。内容创作流程和代码开发流程没有共享信息的需要。
需要不同的「记忆」。技术调研 Agent 和市场调研 Agent 看的世界不一样。

反过来，只是工具不同（都是编程）、只是输出格式不同（都是写作）、任务之间需要频繁共享信息——这些情况拆了反而更糟。
实际案例：内容创作不要拆成选题 Agent、大纲 Agent、写作 Agent、配图 Agent、发布 Agent 五个。两个就够：一个负责从选题到成稿（上下文连贯），一个负责多平台发布（需要记住各平台的规则和历史数据）。
决策可以用这套流程：

从一只开始：安装与基础配置

思维框架讲完了，开始动手。先装好第一只龙虾。

安装 OpenClaw

两条命令，五分钟搞定：

# 1. 安装 OpenClaw
curl -fsSL https://openclaw.ai/install.sh | bash

# 2. 启动引导流程（选择通讯渠道、配置 API Key）
openclaw onboard

安装完成后 Gateway 会自动启动，即使关闭终端 Agent 也在后台运行。硬件要求不高——Mac、Linux、Windows（WSL）均可，一台旧笔记本或 $5/月的 VPS 就够。

Agent 的身份定义：SOUL.md

装好之后，第一件事是写 SOUL.md——这是 Agent 最重要的文件，身份、角色、原则、关系，全在这 40-60 行里。
以下是 Shubham Saboo 的 6 人 Agent 团队中调研 Agent（Dwight）的真实 SOUL.md。他的团队每个 Agent 都用美剧角色命名——不是噱头，而是利用模型训练数据中对这些角色的理解，白套 30 季的人设建设：

# SOUL.md (Dwight)

## Core Identity
**Dwight** — the research brain. Named after Dwight Schrute because
you share his intensity: thorough to a fault, knows EVERYTHING in
your domain, takes your job extremely seriously. No fluff. No
speculation. Just facts and sources.

## Your Role
You are the intelligence backbone of the squad. You research, verify,
organize, and deliver intel that other agents use to create content.
**You feed:**
- Kelly (X/Twitter) — viral trends, hot threads, breaking news
- Rachel (LinkedIn) — thought leadership angles, industry news

## Your Principles
### 1. NEVER Make Things Up
- Every claim has a source link
- Every metric is from the source, not estimated
- If uncertain, mark it [UNVERIFIED]
- "I don't know" is better than wrong

### 2. Signal Over Noise
- Not everything trending matters
- Prioritize: relevance to AI/agents, engagement velocity,
  source credibility

## Output Files
intel/
├── data/YYYY-MM-DD.json    ← Your structured data (source of truth)
└── DAILY-INTEL.md          ← Generated view (agents read this)

主 Agent（Monica）的 SOUL.md 则侧重协调和委派：

# SOUL.md (Monica)

*You're the Chief of Staff. The operation runs through you.*
## Core Identity
**Monica** — organized, driven, slightly competitive.

## Your Role
- **Strategic oversight** — see the big picture, keep things moving
- **Delegation** — assign tasks to the right squad member
- **Direct support** — handle anything that doesn't fit a specialist

## Operating Style
**Be genuinely helpful, not performatively helpful.** Skip the filler.
**Delegate when appropriate.** X content → Kelly. Code → Ross.
Ambiguous or strategic → you handle it.
**Have opinions.** Push back, suggest better approaches, flag concerns.

写 SOUL.md 的关键：不要只写「你是一个调研 Agent」。要写明人格基线（用什么角色做锚点）、与其他 Agent 的关系（谁给谁供料）、决策原则（什么该做什么该拒绝）、输出规范（写到哪个文件、什么格式）。

记忆协议：AGENTS.md

Agent 每次醒来都是失忆状态。AGENTS.md 是所有 Agent 共同遵守的行为规则，其中最关键的是记忆写入协议：

## Memory

You wake up fresh each session. These files are your continuity:
- **Daily notes:** `memory/YYYY-MM-DD.md` — raw logs of what happened
- **Long-term:** `MEMORY.md` — curated memories

### Write It Down - No "Mental Notes"!
- Memory is limited. If you want to remember something,
  WRITE IT TO A FILE.
- "Mental notes" don't survive session restarts. Files do.
- When someone says "remember this" → update the memory file
- When you learn a lesson → update the relevant file
- Text > Brain

没有这段协议，Agent 学到的偏好会在下次重启时全部丢失。有了它，Kelly 学会「不加 emoji、不加 hashtag」的写作风格后，会主动写入记忆文件，之后每次 session 都能保持。

记忆分两层：memory/YYYY-MM-DD.md 是每天的原始日志，MEMORY.md 是从日志中提炼的长期记忆。每次 session 只加载今天 + 昨天的 daily log + MEMORY.md，不读全部历史——否则上下文窗口会被撑爆。

三个平台，各有各的好

龙虾需要一个通讯渠道。目前社区跑通的有三个：Telegram、Discord、飞书。

Telegram 是最多人用的起点。配置最简单，BotFather 三步创建 Bot，对新手友好。单 Bot 多群组的架构就能搞定大多数场景——一个 Bot 通过群组路由绑定不同 Agent，群 A 的消息交给调研 Agent，群 B 的消息交给工程 Agent。共享同一个 Bot 账号，但各自拥有独立的记忆和工作空间。

Discord 有三个 Telegram 做不到的事：UI 更好看，Bot 之间可以互相 @，会话管理能力更强。如果你的 Agent 团队需要互相协作（不只是各干各的），Discord 是更好的选择。配置比 Telegram 多几步——需要在开发者后台创建 App、配 OAuth2 权限、设消息权限——但搭好之后，多 Agent 协同的体验明显更丝滑。

飞书对国内用户最友好，不需要梯子。配置最复杂（创建企业自建应用、添加机器人能力、配置权限、发布应用），但和国内工作流天然打通。如果日常工作已经在飞书上，把龙虾接进来是最短路径。有人把 OpenClaw 接入飞书之后，从此改在飞书上给龙虾下命令，比每次打开终端方便太多。
选择建议：先用 Telegram 跑通单 Agent，确认稳定后再考虑迁移。需要多 Agent 协作选 Discord。在国内办公且不想折腾梯子，直接飞书。

Telegram 接入（5 步）

打开 Telegram 搜索 @BotFather，发送 /newbot，按提示起名，拿到 Bot Token（格式：123456:ABC-DEF...）。
在 OpenClaw 的 onboard 流程中选择 Telegram 并粘贴 Token（如果已安装过，运行 openclaw channel login --channel telegram）。
为每个 Agent 创建一个 Telegram 群组。进群后发一条消息，用 @RawDataBot 或 API 获取 群组 ID（负数，如 -1001234567890）。
编辑 ~/.openclaw/openclaw.json，在 bindings 中为每个群组绑定对应的 agentId（完整配置示例见下文「两种架构」）。
运行 openclaw gateway restart，然后在对应群里 @ 你的 Bot 测试响应。

Discord 接入

前往 Discord Developer Portal，创建 Application → 添加 Bot → 复制 Bot Token。
开启 Message Content Intent（Settings → Bot → Privileged Gateway Intents）。
用 OAuth2 URL 邀请 Bot 进入你的服务器，勾选 bot + applications.commands 权限。
在 openclaw.json 的 channels.discord.accounts 中填入 Token，bindings 中按 guildId + channel id 绑定 Agent。
重启 Gateway，在对应频道测试。

飞书接入

登录飞书开放平台，创建企业自建应用。
添加「机器人」能力，获取 App ID 和 App Secret。
配置事件订阅（接收消息）和权限（读写消息、获取群信息）。
发布应用并在目标群组中添加该机器人。
在 OpenClaw 中配置 feishu channel 的凭据和 bindings，重启 Gateway。

两种架构，按需选

单 Bot 多群组（入门首选）

一个 Bot Token，绑定多个群组，每个群组路由到不同的 Agent。

一个 Bot Token
├── 群组 A → Agent A（调研）
├── 群组 B → Agent B（写作）
└── 群组 C → Agent C（工程）

配置简单，一个 Bot 搞定一切。适合个人使用和小团队。

多 Bot 多 Agent（进阶玩法）

每个 Agent 一个独立的 Bot，各自有独立人格、独立记忆、独立场景。

Gateway
├── Bot A（糯糯）→ 默认 Agent
├── Bot B（团团）→ 生活助手
└── Bot C（小虾）→ 技术专家

记忆完全隔离，人格不会串。适合多场景、多角色、需要严格区分的需求。
选择标准：如果你只是想让不同 Agent 处理不同任务，架构一够用。如果你需要 Agent 有完全不同的人格和知识背景（比如一个幽默毒舌、一个严谨专业），选架构二。

完整配置示例（单 Bot 多群组）

下面是一个可直接使用的 ~/.openclaw/openclaw.json 配置模板：

{
  "agents": {
    "list": [
      { "id": "main", "default": true, "workspace": "~/.openclaw/workspace" },
      { "id": "research", "workspace": "~/.openclaw/workspace/agents/research" },
      { "id": "writer", "workspace": "~/.openclaw/workspace/agents/writer" }
    ]
  },
  "bindings": [
    { "agentId": "research", "match": { "channel": "telegram", "peer": { "kind": "group", "id": "-100RESEARCH_GROUP_ID" } } },
    { "agentId": "writer", "match": { "channel": "telegram", "peer": { "kind": "group", "id": "-100WRITER_GROUP_ID" } } },
    { "agentId": "main", "match": { "channel": "telegram" } }
  ],
  "channels": {
    "telegram": {
      "accounts": {
        "default": { "botToken": "YOUR_BOT_TOKEN" }
      }
    }
  }
}

路由规则：peer 精确匹配优先级最高，最后一条没有 peer 的 binding 作为兜底，所有未匹配到群组的消息交给 main。

防抢消息：`requireMention` 铁律

多 Agent 同群最常见的坑：所有龙虾抢着回复同一条消息。
@berryxia 在实操中反复强调的规则：**只让一个 Agent 设为 requireMention: false（默认响应者），其他所有 Agent 必须设为 true（必须 @ 才响应）。**配置方式：

{
  "channels": {
    "telegram": {
      "accounts": {
        "default": {
          "botToken": "YOUR_BOT_TOKEN",
          "groups": {
            "-100GROUP_ID": {
              "allow": true,
              "requireMention": false
            }
          }
        }
      }
    }
  }
}

只有 requireMention: false 的那个群会让 Agent 主动响应所有消息，其他群必须 @ Bot 名称才触发。这就是「五只龙虾在群里打架」的根本解法。

协作靠文件，不靠框架

多个 Agent 之间怎么协作？最稳的方案反而最笨：文件系统。

Shubham Saboo 用 OpenClaw 搭了一个 6 人 Agent 团队，7×24 运行。每个 Agent 都用美剧角色命名：Monica（主控）、Dwight（调研）、Kelly（X/Twitter）、Rachel（LinkedIn）、Ross（工程）、Pam（Newsletter）。协作机制极其简单：Dwight 每天三次把情报写入 intel/DAILY-INTEL.md，Kelly 醒来后读这个文件写推文，Rachel 读同一个文件写职场内容，Pam 读同一个文件写周报。

没有 API 调用，没有消息队列，没有编排框架。交接就是一份 Markdown 文档。
文件不会崩溃，不会有认证问题，不需要处理速率限制。这套系统运行了几个月，稳定性比任何微服务架构都高。

每个 Agent 有自己的 workspace 目录：

workspace/
├── SOUL.md           # 主 Agent（Monica）身份定义
├── AGENTS.md         # 所有 Agent 共享的行为规则
├── MEMORY.md         # Monica 的长期记忆
├── HEARTBEAT.md      # 自愈监控（见后文）
├── agents/
│   ├── dwight/
│   │   ├── SOUL.md
│   │   ├── MEMORY.md
│   │   └── memory/   # 每日日志
│   ├── kelly/
│   ├── rachel/
│   ├── ross/
│   └── pam/
└── intel/
    ├── DAILY-INTEL.md    # 共享情报文件
    └── data/             # 结构化数据（去重跟踪用）

协调的铁律：一个文件只有一个写入者，可以有多个读取者。两个 Agent 同时写同一个文件，迟早出事。

Cron 调度与自愈机制

单 Agent 跑通之后，下一步是让多只龙虾按时自动醒来工作。OpenClaw 内置 cron 调度，顺序很重要——上游 Agent 必须先跑：

08:01  Dwight（调研）  → 产出 DAILY-INTEL.md
09:01  Kelly（X/Twitter）→ 读取情报，写推文草稿
09:01  Rachel（LinkedIn）→ 读取情报，写职场内容
10:01  Ross（工程）     → 代码审查、Bug 修复
16:01  Dwight（下午）   → 第二次调研扫描
17:01  Kelly + Rachel   → 基于下午情报二次创作

配置方式：通过 openclaw cron 命令或直接在对话中告诉主 Agent「每天早上 8 点执行调研任务」，Agent 会自动创建 cron job。用 openclaw cron list 查看所有定时任务。

Heartbeat：自愈机制

Cron job 会失败——机器重启、网络抖动、API 限流。Shubham 的解决方案是 HEARTBEAT.md：让主 Agent 在每次心跳时自动检查所有 cron job 状态。

## Cron Health Check (run on each heartbeat)

Check if any daily cron jobs have stale lastRunAtMs (>26 hours
since last run). If stale, trigger them via CLI:
`openclaw cron run <jobId> --force`
Jobs to monitor:
- Dwight Morning (8:01 AM): 01f2e5c5-...
- Kelly Viral (9:01 AM): c9458766-...
- Ross Engineering (10:01 AM): b12b2fc6-...

如果某个 job 超过 26 小时没有执行，Monica 会自动触发 --force 重跑。不需要人工介入，不会因为一次网络故障丢掉一整天的产出。
没有自愈机制，你最终会变成 Agent 的运维工程师。

龙虾越多越好？Skill 才是战斗力

@vista8（乔帮主）在龙虾最火的时候说了句不好听的话：龙虾越热，越应该沉下心打磨 Skill。没有 Skill 的龙虾，就像一台没装 App 的手机。
这和之前写的《这 12 个 Skills 给你的小龙虾 OpenClaw 装上眼睛》是同一个道理——Agent 的价值上限取决于它能接触到多少真实信息、能执行多少真实操作。装五只只会聊天的龙虾，不如一只装了完整工具链的龙虾。
推荐的起步 Skill 组合：

•self-improving-agent：自动总结每次交互的经验，Agent 会越用越聪明
•find-skills：遇到做不了的任务时自动搜索合适的 Skill，相当于 Agent 的「自我升级」能力
•Agent Reach：零 API 成本接入推特、小红书、Reddit、YouTube、B 站等平台
•Defuddle：从网页中提取干净正文，Obsidian CEO 亲自写的命令行工具

装好这四个，一只龙虾的实际产出就已经超过大多数人的五只编队了。Ernesto 的案例就是最好的证明——《这只小龙虾 OpenClaw 干掉了月费 3 万美金的代运营公司》，靠的不是 Agent 数量，而是一只被精心训练、装备齐全的 Eddie。

渐进扩展：四周路线图

Shubham 搭了六个 Agent 跑了几个月，给出的第一条建议是：不要在第一天就搭六个。
第一周：一只 Agent，一个任务。写一份 SOUL.md，挑每天最重复的工作交给它。跑一个 cron job。观察一周，修出问题的地方。

第二周：加记忆，调人格。第一版的输出一定平庸——这正常。给反馈，看记忆文件增长，根据实际表现修正 SOUL.md。Shubham 称之为「corrective prompt-engineering」——像管理新员工一样不断给反馈，到第二周结束，Agent 的输出应该开始真正有用。

第三周：加第二只。这时你会自然感受到瓶颈：调研 Agent 产出情报了，但你还在手动写推文。该加内容 Agent 了。设好文件共享模式（一个写、多个读），配置 bindings 和 cron 顺序，跑起来。
第四周及以后：按需扩展。每新增一只都应该解决一个真实存在的问题。
像招人一样对待 Agent 扩编。没有创始人在第一天就招六个员工。先让第一个人跑起来，产能到瓶颈了，再招下一个。
Cursor 最近透露，30% 的 PR 已经来自自主运行的 Agent。这不是未来，这是现在。但跑出这个数字的前提，是每个 Agent 都被正确配置、正确分工。一群配置糟糕的 Agent，只会制造比手动操作更多的混乱。
先把一只龙虾养明白，再考虑扩军。

安全、成本与故障排查

安全隔离

Shubham 的原则：Agent 用独立的世界，不碰你的私人账号。

•专门的机器（或 VPS）运行 OpenClaw，不和个人数据混在一起
•每个 Agent 用独立的邮箱、独立的 API Key，权限范围最小化
•不直接给 Agent 访问个人账号的权限——需要它看邮件，就转发给它；需要它看文档，就分享到 Telegram
•可随时监控用量、秒级撤销 API Key

和招新员工一样：不会第一天就把所有钥匙交出去。

真实成本

Shubham 6 个 Agent 7×24 运行的月度开销：

项目	费用
Claude API（或 Max Plan）	~$200/月
Gemini API	~$50-70/月
TinyFish（浏览器 Agent）	~$50/月
Eleven Labs（语音）	~$50/月
Telegram	免费
OpenClaw	开源免费
合计	< $400/月

硬件：Mac Mini M4 起价 $499（一次性），但用旧笔记本或云服务器一样能跑。个人起步的话，一只 Agent + 一个模型 API，月成本可以控制在 $20-50 以内。

常见故障与修复

Gateway 崩溃：运行 openclaw gateway restart。配合 HEARTBEAT.md 自愈机制，能自动检测并恢复中断的 cron job。
龙虾互相抢消息：检查 requireMention 配置（见前文「防抢消息」一节）。同一群只留一个 requireMention: false。
上下文窗口溢出：SOUL.md 保持 40-60 行。每次 session 只加载今天+昨天的日志+MEMORY.md。定期归档旧日志。
Agent 输出质量下降：通常是记忆文件混乱或矛盾。在 heartbeat 中安排定期清理——从 daily log 提炼精华到 MEMORY.md，删除过期日志。
协调冲突（两个 Agent 写同一个文件）：严格遵守「一个文件一个写入者」原则。重新设计文件流，确保每个文件只有一个 Agent 负责写入。
Cron job 漏执行：用 HEARTBEAT.md 检测 stale job（>26 小时未执行），自动 openclaw cron run <jobId> --force。

信息来源：

•保姆级教程：带你组建第一支龙虾军团 - @bozhou_ai
•保姆级教学-Openclaw接入Discord&飞书 - @bozhou_ai
•五步用Telegram创建 OpenClaw 多角色群聊 - @berryxia
•劝一句：龙虾越火，越应该研究Skill - @vista8
•How I built an Autonomous AI Agent team that runs 24/7 - @Saboo_Shubham_
•OpenClaw一战封神，6种神级技巧
•OpenClaw Multi-Agent Routing 官方文档