【203篇系列】046 基于openclaw的agent swarm

前言

openclaw 不用介绍了，现在正大红大紫中。openclaw的出现，也标志着大模型工具从较为专业的人群使用，到了更广泛的非专业人士使用，一下子用户群大了很多，也成了既chatgpt之后又一个现象级产品。

最初llm是用来问答交流的，后来开始升级为api调用，进行大量数据基建。再之后，llm开始有了function calling、memory这些，然后开始迈向第一站专业挣钱的工具：辅助编程。cursor是最早出名的，后面还有很多。现在的openclaw，我认为是辅助流程，已经不限于单个领域，而是多领域，集成性更强了。（其价值在于更多的替代人的流程工作）

春节期间我也研究了一下，之前我的很多开发，一个重要的汇聚点和openclaw是一样的。最核心的AEE需要花点时间，但我也可以用langchain先顶上。未来左手andybot(自研，全python栈），右手openclaw(借力，js栈），所以我现在是把openclaw当老师来的。

Agent Swarm 基本概念

Agent Swarm（智能体蜂群）是一种多智能体协同架构（multi-agent architecture）。核心思想来源于群体智能（swarm intelligence）：不是依赖一个强大的单体 Agent，而是由多个功能专一的小 Agent 协同完成复杂任务。

Agent Swarm 本质是：

多个独立 Agent + 任务分解 + 协作通信

每个 Agent 通常具有：

独立的 prompt / role
独立的工具集（tools）
独立的上下文
独立的决策能力

系统通过某种 **编排机制（orchestrator）**让它们协作。

bash 复制代码

User Task
   │
   ▼
Coordinator Agent
   │
   ├── Research Agent
   ├── Coding Agent
   ├── Planning Agent
   ├── Review Agent
   │
   ▼
Result Aggregation

典型结构

bash 复制代码

┌───────────────────────────┐
│        User Interface      │
└─────────────┬─────────────┘
              │
┌─────────────▼─────────────┐
│     Orchestrator / Router │
│      (任务调度 / 分发)     │
└─────────────┬─────────────┘
              │
     ┌────────┴────────┐
     ▼                 ▼
┌────────────┐   ┌────────────┐
│ Agent Pool │   │ Agent Pool │
│ Research   │   │ Coding     │
│ Planner    │   │ Critic     │
└────────────┘   └────────────┘
     │                 │
     ▼                 ▼
        Shared Memory / Tools

核心组件：

1 Orchestrator（调度器）

负责：任务分解
Agent 调用
执行流程控制

实现方式：

workflow DAG
planner agent
rule based router

2 Agent Pool（Agent 集群）

每个 Agent 是：Agent = LLM + Prompt + Tools + Memory

例如：

Research Agent

bash 复制代码

role: research expert
tools:
- search
- browse
- summarize

Coder Agent

bash 复制代码

role: software engineer
tools:
- code executor
- file system

3 Communication（通信）

Agent 之间通过：

message passing
shared memory
event bus

典型数据结构：

bash 复制代码

{
 "from": "planner",
 "to": "researcher",
 "task": "collect information about X"
}

4 Shared Memory

常见两种：

短期 memory

bash 复制代码

conversation state
task state

长期 memory

vector DB

knowledge base

常见实现：

Redis

Weaviate

Chroma

5 Tool Layer

Agent 调用工具：

bash 复制代码

search()
execute_code()
query_db()
call_api()

工具调用通常使用：

function calling
MCP
tool schema

Swarm 的运行机制

Step1 用户输入任务

"分析 AI agent 架构并给出方案"

Step2 Planner Agent 分解任务

Planner 生成 plan：

复制代码

1 collect research
2 analyze architecture
3 generate solution
4 review output

Step3 分配 Agent

research_agent -> step1
analysis_agent -> step2
writer_agent -> step3
critic_agent -> step4
Step4 Agent 并行执行

research_agent
└─ search

analysis_agent
└─ reasoning

writer_agent
└─ generate report

可以：串行、并行（本质上应该是执行图）

Step5 汇总结果

Coordinator 汇总：

复制代码

final_result = merge(agent_outputs)

Swarm 的实现方式

目前主要有 4 种技术路线。

1 Router 模式（最简单）

Router 根据任务选择 agent。

bash 复制代码

User
  │
Router
  ├─ coding agent
  ├─ research agent
  └─ math agent

典型实现：LangChain、LlamaIndex

2 Planner 模式

LLM 先生成执行计划。

bash 复制代码

LLM -> Plan
        │
        ▼
  Execute Steps

典型：

BabyAGI

3 Graph / Workflow 模式

任务作为 DAG workflow。

bash 复制代码

task
 ├─ research
 │   └─ summarize
 └─ coding
     └─ test

典型：LangGraph

4 Fully Decentralized Swarm

Agent 自主通信。

复制代码

Agent A ↔ Agent B ↔ Agent C

类似：swarm robotics、distributed AI

代表项目：CrewAI

Swarm 的优势

1 模块化：每个 agent 负责一个领域。
2 可扩展：新增 agent 非常容易。
3 并行执行
4 prompt 更稳定：单 agent prompt 不需要非常复杂。

示例

python 复制代码

agents = {
    "research": ResearchAgent(),
    "coder": CodingAgent(),
    "critic": CriticAgent()
}

plan = planner.create_plan(user_task)

for step in plan:
    agent = agents[step.agent]
    result = agent.run(step.task)
    memory.store(result)

final = critic.review(memory)

核心理念

为什么要用swarm，我想从核心理念上来简单说明。

1 能力受限的智能体

虽然现在的大模型不断的迭代，但是在实际的过程中，我仍然感受到了从背后的本质上看，大模型的能力是相对有限的。

我想或许可以用逻辑复杂度来定义模型的能力。当逻辑复杂度高于一定级别，大模型通常是无法完成任务的。例如，当你要它设计一个很复杂的程序逻辑结构，它基本会失败；当你要它做一个简单项目，通常会成功。单个脚本的编程成功率，通常可以one take；而整个项目的编写通常不能；针对一个对象的逻辑编写通常可以一次成功，而对于批量处理的逻辑就不太行。

一个基本的认知是：在未来较长的时间里（如1-2年），大模型本身的逻辑复杂度仍然不足以替代高级程序员。甚至极端一点，也许永远不能。

我的感觉是，一个大模型，类似于一个有非常多参数的函数。而我们的prompt，相当于是给到偏置(partial)，然后去使用函数。大模型本身是具有多种能力的，但是只有偏置（把力量以某种方式集中）才能有效发挥这些能力。这些能力的发挥不再是呈现无限多样化，而是在某个领域的发挥，类似于人类"专注"时表现的特征：在一方面可以提高非常多，但是其他方面会加大削弱。例如狙击手，在瞄准目标，准备进攻时，他会放大他在注意力，肌肉协调的能力，但是对周围环境的感知大幅下降了（很容被偷袭）。

所以在应用智能体，分化智能体要考虑第一原则是：这个智能体是否可以胜任当前任务的复杂度。

2 群体智慧

这个最初我是在看一本游戏设计的书接触到的：个体本身很简单，但群体通过协作能产生复杂、智能的行为。

**群体智慧（Swarm Intelligence）**是一个研究多个简单个体通过局部交互产生整体智能行为的概念，属于 Artificial Intelligence 和 Complex Systems 的交叉领域。

群体智慧通常具有三个特征：

1 分布式个体：系统由大量个体组成（多个agent)

每个个体: 信息有限、规则简单、不知道全局状态

2 局部交互: 个体只与邻居或环境交互,没有中央控制。
3 全局涌现（Emergence）
当大量个体交互时，会出现宏观智能行为,这种现象称为涌现（emergence），是复杂系统的核心特征。

简单规则
↓
局部行为
↓
复杂系统行为

群体智慧的理解我觉得从游戏的角度是最好的，想想星际争霸，或者塞尔达传说。我们真正期待的是群体智慧的涌现，而其最大的限制是算力和时间。如果从取代人编程工作的角度来看，这些限制并不大。

实践

在进一步讨论openclaw的 agent swarm之前，我先说一下最近养虾的体会。

1 虾聊天的时候非常活泼，提供了很多情绪价值 - 所以模型偏置了多少能力在和人对接上？
2 由于IM通道，例如飞书，这让虾有了一个更加接近真实工作环境的机会 - Good
3 整体上虾做日常任务还可以，比如定时提醒等。 - 但是容易出现配置偏差，有时候会失效
4 虾能够自我配置，如果还不具备对应skill可以自己添加，也可以让它再创建新的agent，配置新的大模型等。 - 这种操作很不稳定，轻的问题是配置有偏差，重的话整个服务会崩溃。这种问题很频繁，我觉得偏置后的智能体（虾），在执行这个级别的任务（中等逻辑复杂度）已经不能胜任了；另外，如果要自我配置，应该有内核和外层的设计概念。我经常会用code buddy进行配置和软件问题修复，我感觉openclaw应该有个类似的agent内核，处理这些更新问题，用户在一般情况下访问的虾应该是外层应用。

总体上说，openclaw更多的体现了一种原型产品，而非最终产品的姿态。功能都有，但是需要不断debug，或者说不断偏置化，这个过程称为"养虾"。我认为理念都是对的，但是实现上是有改进空间，甚至重构必要的，所以我会在未来构建andybot。

Openclaw Agent Swarm

好了，前面前置的东西说完，我们先假定就必须用openclaw了，接下来看如何去实现Agent Swarm (Prototype)。

从模式上，openclaw的方式更像是半去中心化的。

bash 复制代码

           ┌─────────────┐
           │   Gateway   │  ← 中央协调平面
           └──────┬──────┘
                  │
    ┌─────────────┼─────────────┐
    │             │             │
    ▼             ▼             ▼
Agent A    ←→  Agent B    ←→  Agent C
                  │
                  ▼
            可以直接通信
            (通过 sessions_* 工具)

Agent 间可以直接对话 --- 不需要用户作为中介
支持自主任务委派 --- 通过 sessions_spawn 派生子 Agent
分布式协作 --- 多个 Agent 可以并行处理不同任务

但它不是完全的去中心化（没有 P2P 直连），而是 Gateway 协调下的去中心化通信，这在安全性和可控性之间取得了平衡。

然后要进行agent swarm, 一定会有两个基本问题：

1 首先，一个协调者肯定是存在的，这个协调者可以产生新的agent 吗？
2 其次，要进行协作，除了在一个主题下有若干agent，这些agent怎么通信？

Agent

agent是openclaw里的核心元素，每个agent会有自己独立的存储空间，会有几个核心的文件：

这些是决定智能体底层特性，或者维护基本交互（USER.md)的基础。这也是一种偏置，如果用过python的partial包，看下面这段应该会比较认可。

所以，每个agent可以看成一个人。一个openclaw只会有一个主agent(default)，这个主agent会有点特殊，应该是只有他才能创建新agent(这个我没有求证过，但目前我成功的示例来看是这样）。通过主agent可以创建其他agent，但是风险很高，我在上面已经说过了。（轻则串台，重则服务甚至机器崩溃）

最好通过命令行来操作，这个也算低频操作

bash 复制代码

列出所有 Agent
openclaw agents list

列出 Agent 及绑定关系
openclaw agents list --bindings

创建 Agent
openclaw agents add <agentId>

# 创建一个名为 "work" 的 Agent
openclaw agents add work

删除 Agent
openclaw agents remove <agentId>

我现在不在那台电脑身边，让主agent帮我查了一下。查询还是安全的操作。另外我注意到了，形成智能体模型也是一个重要的变量，这个应该会极大影响到智能体的表现。 偏置(IDENITY、SOUL) + 基础函数(LLM) = Agent

加入我要让zoe做编排者，看起来是ok的。另外，下面的问题就有点可怕，我要让主agent（当前飞书绑定）真的修改binding，搞不好会出问题。（这个也是我说的，openclaw应该有个内核，有少部分基础运行的操作不应该让所有智能体都能操作 - 自己修改自己 ~ 服务崩溃）

要让agent能有spawn的能力，需要进行设置。我问了cody buddy和openclaw自己，回复都是一样的（但我记得我试验时好像还有个啥设置）

code buddy:

openclaw:

到这里，也就可以回答前面的问题

复制代码

然后要进行agent swarm, 一定会有两个基本问题：
- 1 首先，一个协调者肯定是存在的，这个协调者可以产生新的agent 吗？
- 2 其次，要进行协作，除了在一个主题下有若干agent，这些agent怎么通信？

我们再来看下，在openclaw中agent相关的一些信息，然后再过一个实验，验证一下

1 agent的基本资源/能力

创建了一个agent之后，会在基本配置文件中反应 ~/.openclaw/openclaw.json

json 复制代码

# 创建一个名为 "work" 的 Agent
openclaw agents add work

{
  agents: {
    list: [
      {
        id: "work",
        workspace: "~/.openclaw/workspace-work",
        agentDir: "~/.openclaw/agents/work/agent"
      }
    ]
  }
}

这里我是有点疑问的，之前我使用主agent直接创建，没用命令行；但我认为如果用了命令行，应该是可以直接在配置文件里修改，而不是需要手动改的。否则还不如直接用code buddy创建。

这个倒是验证的，每多创建一个agent，都多了一个文件夹

从这里可以看出来，workspace应该就是我们能操控的部分，包括设定agent的特点。

还有一个是agentDir, 存放runtime的相关内容。

位置藏的更深一些，一个agent一个文件

有趣的是，主agent的这个丢失了，但是没有影响使用。丢失的原因我估计就是之前让它自己配置，产生了毁坏性操作。

我让智能体自己修复了（这仍然是有操作安全隐患的，等于让智能体有干掉自己的机会）

这是cody buddy的内容，总结的应该比较好。

bash 复制代码

用户想了解 agentDir 的具体作用。根据之前的对话，我已经提到了它主要存放认证信息、模型配置和会话历史。让我更详细地解释一下。
## agentDir 的作用

`agentDir` 是 Agent 的**运行时状态目录**，存放 Agent 运行所需的核心数据：

### 存放内容

| 内容 | 说明 |
|-----|------|
| **auth-profiles.json** | API 认证凭据（API Key、OAuth token 等） |
| **models/** | 模型注册和配置信息 |
| **sessions/** | 会话历史记录（聊天记录） |

---

### 核心作用

1. **身份认证**
   - 存储连接各个渠道（飞书、Telegram、WhatsApp）所需的认证信息
   - 每个 Agent 独立的认证，避免串号

2. **会话隔离**
   - 每个 Agent 的聊天历史独立存储
   - 不会混淆不同 Agent 的对话上下文

3. **模型配置**
   - 存储该 Agent 使用的模型配置
   - 可以为不同 Agent 配置不同的模型

---

### 简单理解

agentDir = Agent 的"身份证 + 档案袋"

├── 身份证 → auth-profiles.json (认证凭据)

├── 档案袋 → sessions/ (历史记录)

└── 工作证 → models/ (模型配置)

复制代码

---

### 为什么需要隔离

假设你有两个 Agent：
- **work**：用 Claude Opus，处理工作事务
- **home**：用 Claude Sonnet，处理生活问题

如果没有独立的 `agentDir`：
- ❌ 认证会串号
- ❌ 聊天历史会混在一起
- ❌ 模型配置会冲突

有了独立的 `agentDir`：
- ✅ 每个 Agent 有自己的认证
- ✅ 历史记录清晰隔离
- ✅ 可以用不同模型

我又看了下，基本可以认为agentDir是放智能体的认证信息和模型信息的，以及保存会话历史。

这块可以认为是智能体对内（openclaw)和对外（外部网站、api)的渠道。

小总结

bash 复制代码

workspace（用户区）
    │
    ├── AGENTS.md      ← 用户编写 Agent 的"人设"
    ├── skills/        ← 用户安装/编写技能
    ├── notes/         ← 用户笔记
    └── *.md           ← 用户文件
                    ↑
              用户可以自由编辑

agentDir（系统区）
    │
    ├── auth-profiles.json  ← API 认证（飞书/Telegram等）
    ├── sessions/          ← 聊天历史
    └── models/            ← 模型配置
                    ↑
           OpenClaw 读写，用户不要乱动

2 核心机制-会话隔离

会话是连接两端节点(Agent)的，相当于一条边

我看资料有这四种，理论上除了hook，我应该都用了。hook这个我还没想明白。

只要建立了一个智能体，那么在webchat上就会有一个对应的专属channel，默认是连接agent和用户的。然后这个会话如果隔一段时间没消息，就会休眠。

群组会话应该就是类似飞书的方式，把agent加到一个组里聊天，当被at到的时候，对应的agent就会被触发。这个应该是应用了IM软件的事件，某种程度上说也是hook。比较有意思的是，大约是因为IM软件的机器人相当于一个应用服务，通过ws和openclaw智能体建立的长期的双向连接，所以这个会话似乎是不会退出的。

定时任务我也跑了，这个我倒没想那么多，不明白这个会话指的是什么：难道是执行任务期间，所有的日志都留在里面？还是说任务的描述？

我让deepseek解释了一下，说的挺好：