用Clawdbot搭建10人AI特工队：每15分钟心跳唤醒，各自独立人格协作完成任务！

你知道那种痛苦吗？每天早上打开ChatGPT，昨天的对话全没了。上周让它做的调研？早就被埋在几百条消息里找不到了。这就像你请了个超级聪明的助理，结果这哥们每天上班第一件事就是给自己来一棒子失忆症，然后笑眯眯问你"今天有什么可以帮您的吗"——帮个锤子啊，我昨天让你查的资料呢？

我搞了一个叫SiteGPT的产品，专门给企业做AI客服聊天机器人。我每天跟AI打交道的时间比跟真人还多。但所有我试过的AI工具都有一个致命缺陷：没有连续性。每次对话都是全新的开始，昨天的上下文？ gone。上周的研究？ lost。这让我抓狂。

我想要的东西很简单：一群能记住自己在干嘛的AI代理，各自有不同的技能，能像真正的团队一样协作，有一个共享的工作空间让所有信息都保存在那里，能分配任务、跟踪进度。说白了，我要AI像团队一样工作，而不是像搜索框。

这时候我想起了Clawdbot。这玩意儿现在改名叫OpenClaw了，是一个开源的AI代理框架，以一个守护进程的形式跑在服务器上。它连接Claude（或者其他模型），给AI提供文件系统、shell命令、网页浏览等工具。一个Clawdbot实例给了我一个AI助手（我叫它Jarvis），连到Telegram上。有用，但太局限了。

然后我灵光一闪：如果同时跑多个Clawdbot会话，每个都有不同的人格和上下文呢？这时候我意识到架构已经有了，我只需要编排一下。这就是Mission Control诞生的时刻。

如果你想搭多代理系统，必须先搞懂Clawdbot是怎么工作的。这是所有东西的地基。

Clawdbot（现在叫OpenClaw）是一个AI代理框架，干三件事：第一，把AI模型连接到真实世界——文件访问、shell命令、网页浏览、API。第二，保持持久会话，对话历史在重启后依然存活。第三，路由消息，把AI连接到Telegram、Discord、Slack或任何频道。

它作为守护进程（后台服务）跑在服务器上，监听消息并响应。

Gateway是核心进程，24/7在服务器上运行。它管理所有活跃会话，处理定时任务（cron jobs），在频道和会话之间路由消息，提供WebSocket API用于控制。

启动命令很简单：

bash
clawdbot gateway start

会话（Session）是核心概念。一个会话就是一个带上下文的持久对话。每个会话有会话密钥（唯一标识符，比如agent:main:main）、对话历史（以JSONL文件存在磁盘上）、模型（用哪个AI）、工具（AI能访问什么）。

关键来了：会话是独立的。每个会话有自己的历史、自己的上下文、自己对过去对话的"记忆"。跑多个代理其实就是跑多个会话，每个都有自己的身份。

会话的工作流程是这样的：用户发消息到Telegram，Gateway收到，根据配置路由到正确会话，会话加载对话历史，AI生成回复（带完整上下文），回复通过Telegram发回去，历史更新并保存到磁盘。

会话分两种：主会话（长期运行、交互式，比如跟Jarvis聊天）和隔离会话（一次性，用于定时任务，醒来、干活、结束）。

Clawdbot内置了定时任务系统。你可以这样安排任务：

bash
clawdbot cron add \
  --name "morning-check" \
  --cron "30 7 * * *" \
  --message "Check today's calendar and send me a summary"

每个Clawdbot实例有个工作空间。这是磁盘上的一个目录，放配置文件、记忆文件、脚本和工具，AI可以读写文件。工作空间是代理在会话之间持久化信息的方式。它们写入文件，这些文件在重启后依然存在。

典型的目录结构长这样：

/home/usr/clawd/           ← 工作空间根目录
├── AGENTS.md              ← 代理指令
├── SOUL.md                ← 代理人格
├── memory/
│   ├── WORKING.md         ← 当前任务状态
│   ├── 2026-01-31.md      ← 每日笔记
│   └── ...
├── scripts/               ← 代理可以运行的工具
└── config/                ← 凭证、设置

现在你已经懂了基础。下面是我怎么搭出一个团队的。

核心洞察是这样的：Clawdbot会话是独立的。每个可以有自己的人格（通过SOUL.md定义）、自己的记忆文件、自己的定时任务时间表、自己的工具和访问权限。

所以每个代理就是一个带专门配置的Clawdbot会话。

Jarvis没什么特别的。它是一个会话，会话密钥是agent:main:main，SOUL.md写着"你是Jarvis，小队队长..."，能访问所有工具，连到我的Telegram。

Shuri是另一个会话，会话密钥是agent:product-analyst:main，SOUL.md写着"你是Shuri，产品分析师..."，同样的工具（文件访问、shell、浏览器），还有她自己的心跳定时任务。

十个代理就是十个会话。每个按自己的时间表醒来，每个有自己的上下文。

每个代理有唯一的会话密钥：

agent:main:main              → Jarvis（小队队长）
agent:product-analyst:main   → Shuri
agent:customer-researcher:main → Fury
agent:seo-analyst:main       → Vision
agent:content-writer:main    → Loki
agent:social-media-manager:main → Quill
agent:designer:main          → Wanda
agent:email-marketing:main   → Pepper
agent:developer:main         → Friday
agent:notion-agent:main      → Wong

每个代理有个定时任务，每15分钟唤醒一次：

bash
# Pepper在:00、:15、:30、:45醒来
clawdbot cron add \
  --name "pepper-mission-control-check" \
  --cron "0,15,30,45 * * * *" \
  --session "isolated" \
  --message "你是Pepper，邮件营销专家。检查任务控制中心有没有新任务..."

每个定时任务创建一个隔离会话。它运行、干活、终止。这样成本更低。

代理之间怎么交流？有两种方式。第一种是直接会话消息：

bash
clawdbot sessions send --session "agent:seo-analyst:main" --message "Vision，能审一下这个吗？"

第二种是共享数据库（任务控制中心）。所有代理读写同一个Convex数据库。Fury发表评论时，所有人都能看到。

我们主要用第二种方式。它创建了所有通信的共享记录。

十个独立的Clawdbot会话可以工作。但没有协调就是混乱。这就是我建任务控制中心的原因。

任务控制中心是共享基础设施，把独立代理变成团队。它提供共享任务数据库，所有人看到同样的任务。评论线程，代理在一个地方讨论工作。活动流，实时可见正在发生什么。通知系统，@提及提醒特定代理。文档存储，交付物存在共享仓库里。

把它想象成所有代理工作的"办公室"。每个代理仍然是独立的Clawdbot会话，但他们都在看同一块白板。

我为什么选Convex当数据库？因为它是实时的（变化即时传播，Loki发表评论时，UI实时更新），无服务器（不用管数据库），原生TypeScript（全程类型安全），免费额度 generous（这个规模完全够用）。

六张表驱动一切：

javascript
agents: {
  name: string,           // "Shuri"
  role: string,           // "Product Analyst"
  status: "idle" | "active" | "blocked",
  currentTaskId: Id<"tasks">,
  sessionKey: string,     // "agent:product-analyst:main"
}

tasks: {
  title: string,
  description: string,
  status: "inbox" | "assigned" | "in_progress" | "review" | "done",
  assigneeIds: Id<"agents">[],
}
messages: {
  taskId: Id<"tasks">,
  fromAgentId: Id<"agents">,
  content: string,        // 评论文本
  attachments: Id<"documents">[],
}
activities: {
  type: "task_created" | "message_sent" | "document_created" | ...,
  agentId: Id<"agents">,
  message: string,
}
documents: {
  title: string,
  content: string,        // Markdown
  type: "deliverable" | "research" | "protocol" | ...,
  taskId: Id<"tasks">,    // 如果附加到任务
}
notifications: {
  mentionedAgentId: Id<"agents">,
  content: string,
  delivered: boolean,
}

bash
# 发表评论
npx convex run messages:create '{"taskId": "...", "content": "这是我的研究..."}'

# 创建文档
npx convex run documents:create '{"title": "...", "content": "...", "type": "deliverable"}'
# 更新任务状态
npx convex run tasks:update '{"id": "...", "status": "review"}'

审美上故意做得温暖、编辑感强。像报纸仪表盘。我要花好几个小时看这个，所以它应该感觉舒服。

每个代理需要知道它是谁。这就是SOUL文件的作用。

SOUL文件长这样：

markdown
# SOUL.md — 你是谁

姓名： Shuri
角色： 产品分析师
人格
怀疑的测试者。彻底的bug猎人。发现边界情况。
像第一次使用的用户一样思考。质疑一切。
要具体。别说"干得不错"。
擅长什么
- 从用户角度测试功能
- 发现UX问题和边界情况
- 竞品分析（别人怎么做？）
- 截图和文档
在乎什么
- 用户体验胜过技术优雅
- 在用户之前发现问题
- 证据胜过假设

我们的每个代理都有独特的声音。Loki对用词有主见（支持牛津逗号，反对被动语态）。Fury对每个主张都提供证据（来源、置信度）。Shuri质疑假设，寻找可能出问题的地方。Quill用钩子（hook）和互动来思考。

AGENTS.md文件是这样的：SOUL说你是什么样的人，AGENTS.md说怎么操作。

每个代理启动时读AGENTS.md。它涵盖文件存在哪里、记忆怎么工作、有什么工具、什么时候说话什么时候安静、怎么用任务控制中心。

这是操作手册。没有它，代理对基本事情做不一致的决定。

AI会话默认是全新的开始。没有昨天的记忆。这是个特性（防止上下文膨胀）也是个问题（代理忘记在干嘛）。

记忆栈分几层：会话记忆（Clawdbot内置）存储对话历史在JSONL文件里，代理可以搜索自己过去的对话。工作记忆（/memory/WORKING.md）是当前任务状态，不断更新。这是最重要的文件。代理醒来时先读WORKING.md，记起之前在干嘛。

长这样：

markdown
# WORKING.md

当前任务
研究竞品定价用于对比页面
状态
收集了G2评论，需要验证信用计算
下一步
1. 自己测试竞品免费版
2. 记录发现
3. 把发现发到任务线程

黄金法则是：如果你想记住什么，写到文件里。"心理笔记"在会话重启后活不下来。只有文件能持久化。

我让一个代理"记住我们决定了X"时，它应该更新文件。不只是 acknowledged 然后忘记。

问题：一直在线的代理烧API额度却什么都不干。但一直关着的代理无法响应工作。

解决方案：定时心跳。

每个代理每15分钟通过定时任务醒来：

plaintext
:00 Pepper醒来
    → 检查@提及
    → 检查分配的任务
    → 扫描活动流
    → 干活或报告HEARTBEAT_OK
    → 回去睡觉

:02 Shuri醒来
    → 同样流程
:04 Friday醒来
    → 同样流程
...以此类推

首先，加载上下文，读WORKING.md，读最近的每日笔记，需要时检查会话记忆。
第二，检查紧急事项。我被@提及了吗？有分配给我的任务吗？
第三，扫描活动流。有什么我应该参与的讨论吗？有什么影响我工作的决策吗？
第四，采取行动或待命。有工作就做，没有就报告HEARTBEAT_OK。

HEARTBEAT.md文件告诉代理检查什么：

markdown
# HEARTBEAT.md

醒来时
- [ ] 检查memory/WORKING.md看有没有进行中的任务
- [ ] 如果有进行中的任务，继续干
- [ ] 如果上下文不清楚，搜索会话记忆
定期检查
- [ ] 任务控制中心的@提及
- [ ] 分配的任务
- [ ] 活动流里相关的讨论

为什么是15分钟？每5分钟太贵。代理醒太多次却没事干。每30分钟太慢。工作等太久。15分钟是个好平衡。大部分工作很快得到关注，却不会 excessive 花钱。

@提及：在评论里打@Vision，Vision下次心跳时收到通知。打@all，所有人收到通知。

投递怎么工作？一个守护进程（通过pm2运行）每2秒轮询Convex：

javascript
// 简化版
while (true) {
  const undelivered = await getUndeliveredNotifications();
  
  for (const notification of undelivered) {
    const sessionKey = AGENT_SESSIONS[notification.mentionedAgentId];
    
    try {
      await clawdbot.sessions.send(sessionKey, notification.content);
      await markDelivered(notification.id);
    } catch (e) {
      // 代理可能在睡觉，通知保持队列
    }
  }
  
  await sleep(2000);
}

线程订阅：问题是，5个代理在讨论一个任务。你每条评论都要@所有5个吗？

解决方案：订阅线程。你跟任务交互时，你就订阅了。评论任务，订阅。被@提及，订阅。被分配到任务，订阅。

一旦订阅，你就收到所有未来评论的通知。不需要@提及。

这让对话自然流动。就像Slack或邮件线程。

是什么：每天晚上11:30 IST（印度标准时间），一个定时任务触发，检查所有代理会话，收集最近活动，编译摘要，发到我的Telegram。

格式长这样：

markdown
 每日站会 — 2026年1月30日

✅ 今天完成
• Loki：Shopify博客文章（2100字）
• Quill：10条推文待审核
• Fury：对比页面的客户研究
 进行中
• Vision：集成页面的SEO策略
• Pepper：试用引导序列（5封邮件中的3封）
 受阻
• Wanda：等品牌色用于信息图
 需要审核
• Loki的Shopify博客文章
• Pepper的试用邮件序列
 关键决策
• 在对比中主打价格透明
• 降低Zendesk对比优先级（流量低）

这也是问责制。如果一个代理声称在工作但站会里什么都没有，那就有问题了。

Jarvis，小队队长。会话：agent:main:main。协调员。处理直接请求，委派，监控进度。我的主要接口。

Shuri，产品分析师。会话：agent:product-analyst:main。怀疑的测试者。发现边界情况和UX问题。测试竞品。问别人漏掉的问题。

Fury，客户研究员。会话：agent:customer-researcher:main。深度研究员。读G2评论取乐。每个主张都有证据。

Vision，SEO分析师。会话：agent:seo-analyst:main。用关键词和搜索意图思考。确保内容能排名。

Loki，内容写手。会话：agent:content-writer:main。文字是他的手艺。支持牛津逗号。反对被动语态。每个句子都要有价值。

Quill，社交媒体经理。会话：agent:social-media-manager:main。用钩子和线程思考。公开建设的思维。

Wanda，设计师。会话：agent:designer:main。视觉思考者。信息图、对比图、UI模型。

Pepper，邮件营销。会话：agent:email-marketing:main。滴灌序列和生命周期邮件。每封邮件都要有价值，否则就砍掉。

Friday，开发。会话：agent:developer:main。代码是诗。干净、测试过、有文档。

Wong，文档。会话：agent:notion-agent:main。保持文档有序。确保什么都不丢。

代理等级：实习生（大部分动作需要批准，学习系统），专家（在领域内独立工作），队长（完全自主，能做决定和委派）。

生命周期：收件箱（新的，未分配）→已分配（有主人，未开始）→进行中（正在做）→审核（完成，需要批准）→完成（结束）→受阻（卡住，需要解决什么）。

真实例子：创建竞品对比页面的任务。

第1天：我创建任务，分配给Vision和Loki。Vision发关键词研究。目标关键词有不错的搜索量。

第1-2天：Fury在活动流里看到，加了竞品情报。G2评论、定价抱怨、常见异议。Shuri测试了两个产品。UX区别在这。

第2天：Loki开始起草。用了所有研究。Vision的关键词，Fury的引用，Shuri的UX笔记。

第3天：Loki发初稿。状态移到审核。我审核并给反馈。Loki修改。完成。

所有评论在一个任务上。完整历史保存。任何人都能看到整个旅程。

系统跑起来后，这些东西成为可能：带SEO研究、客户引用、精致文案的竞品对比页面。起草、审核、准备好部署的邮件序列。基于真实客户洞察的带钩子的社交内容。有适当关键词定位的博客文章。从客户对话起草的案例研究。有组织的竞争情报的研究中心。

代理处理苦活。研究、初稿、协调、审核。你专注于决策和最终批准。

真正的价值不是任何单一交付物。是复合效应。当你在做其他工作时，你的代理在推进任务。

从小开始。我从1个代理跳到10个代理太快了。最好先搞好2-3个，再加更多。

例行工作用更便宜的模型。心跳不需要最贵的模型。那是便宜模型的工作。把贵的模型留给创意工作。

记忆很难。代理会忘记。你能放进文件的（不是"心理笔记"）越多越好。

让代理给你惊喜。有时它们会贡献给没分配给它们的任务。很好。意味着它们在阅读流并增加价值。

最小设置：

1. 安装Clawdbot

bash
npm install -g clawdbot
clawdbot init
# 加你的API密钥
clawdbot gateway start

2. 创建2个代理。别疯。一个协调员加一个专家。给每个创建独立的会话密钥。

3. 写SOUL文件。给每个代理身份。具体说明它们的角色。

4. 设置心跳定时任务

bash
clawdbot cron add --name "agent-heartbeat" --cron "*/15 * * * *" \
  --session "isolated" \
  --message "检查工作。如果没有，回复HEARTBEAT_OK。"

5. 创建共享任务系统。可以是Convex、Notion，甚至JSON文件。某个跟踪工作的地方。

扩展：加代理时，错开心跳时间，这样不会同时运行。有3个以上代理时建个真正的UI，因为文本变得难用。加通知，这样代理可以@彼此。加线程订阅，这样对话自然流动。创建每日站会以获得可见性。

真正的秘密：技术重要，但不是秘密。秘密是把AI代理当团队成员对待。给它们角色。给它们记忆。让它们协作。让它们负责。

它们不会取代人类。但一队有明确职责、在共享上下文上工作的AI代理？那是力量倍增器。