用 OpenClaw 打造你的 AI 助手军团：Gateway -> Agent -> Session 多 Agent 架构完全拆解与实战

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 27 篇，OpenClaw 最佳实战「2026」系列 第 10 篇 大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。 我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、Milvus 向量数据库的技术实践者与开源布道者！ Talk is cheap, let's explore。无界探索，有术而行。

封面图

图 1：OpenClaw 多 Agent 架构全景图

前段时间我在做一个有意思的尝试：想让 AI 助手同时跑在 WhatsApp 和 Telegram 上，白天用 WhatsApp 回复家人消息，晚上用 Telegram 处理工作事务。

听起来不难对吧？我先是找了几个现成的框架，折腾了一周，结果配置文件写了上百行，各种连接问题层出不穷。WhatsApp 连上了，Telegram 掉了；Session 管理一团糟，不同聊天记录混在一起；最头疼的是，我想给家人群用"温和版"Agent，给工作群用"专业版"Agent，结果根本没法路由。

就在我准备放弃的时候，朋友推荐了 OpenClaw。用了一个下午，所有问题都解决了。更让我惊喜的是，它不仅解决了我的需求，还打开了一扇通往多 Agent 架构的大门。

今天就来聊聊这个让我眼前一亮的工具。

一句话定义 OpenClaw

OpenClaw 是一个自托管网关，连接多个聊天应用（WhatsApp、Telegram、Discord、飞书、企微 等）与 AI Agent，让你的一套 AI 能力同时服务多个渠道。

说得更直白一点：

• 你有一个 AI 助手 • 你想在 WhatsApp、Telegram、Discord、Slack 上都能用它 • 你不想为每个平台单独部署一套 • 你还想要不同平台用不同的"人格"

OpenClaw 就是干这事的。

核心概念：Gateway、Agent、Session

在深入架构之前，先搞清楚三个核心概念。它们的关系可以这样理解：

聊天应用（WhatsApp/Telegram/Discord）
         ↓
      Gateway（网关守护进程）
         ↓
    ┌────┼────┐
    ↓    ↓    ↓
 Agent  Agent  Agent（多个独立人格）
    ↓    ↓    ↓
 Session Session Session（各自的对话上下文）

Gateway：大管家

Gateway 是运行在你自己机器或服务器上的守护进程。它的职责：

• 维护连接：保持与 WhatsApp、Telegram 等平台的长连接 • 消息路由：根据规则把消息分发到对应的 Agent • 协议转换：把各平台的消息格式统一成标准格式 • 安全验证：通过 JSON Schema 验证入站消息

一个 Gateway 可以同时服务十几个 Agent，每个 Agent 独立运行，互不干扰。

Agent：独立人格

一个 Agent 就是一个"完整的大脑"，拥有自己的：

• Workspace（工作区）：文件、笔记、人格配置（AGENTS.md、SOUL.md） • State Directory（状态目录）：认证配置、模型设置，路径在 ~/.openclaw/agents/<agentId>/agent/• Session Store（会话存储）：聊天历史，路径在 ~/.openclaw/agents/<agentId>/sessions/

这里有个关键点：每个 Agent 的认证配置是独立的。你的主 Agent 用你的 Claude 账号，家人的 Agent 可以用另一个账号，绝对不会串。

千万别跨 Agent 重用 agentDir——我第一次配置时踩了这个坑，结果会话全乱了。

Session：上下文管理器

Session 是管理对话上下文的核心机制。每个 Session 有独立的：

• Session Key（会话键）：标识唯一会话

• 直接聊天：agent:<agentId>:main
• 群组：agent:<agentId>:whatsapp:group:<id>
• Sub-Agent：agent:<agentId>:subagent:<uuid>

• DM Scope（私聊作用域）：控制不同用户的消息是否共享上下文

• main：所有私聊共享一个会话（默认，保持对话连续性）
• per-peer：每个联系人独立会话
• per-channel-peer：按渠道 + 联系人隔离（多用户场景推荐）

• 生命周期：可以设置每日重置、空闲重置，或手动 /reset

说实话，Session 机制是我见过设计得非常优雅的部分。后面实战部分会详细讲。

架构拆解：OpenClaw 是怎么跑起来的

架构图

图 2：OpenClaw 三层架构图

整体架构

┌─────────────────────────────────────────────────────────────┐
│                        聊天应用层                              │
│  WhatsApp | Telegram | Discord | iMessage | Slack | Signal  │
└────────────────────────┬────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────────┐
│                      Gateway (守护进程)                        │
│  • 维护 Provider 连接                                          │
│  • 暴露 WebSocket API                                         │
│  • 消息路由 + 事件分发                                          │
└────────────────────────┬────────────────────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
  ┌──────────┐     ┌──────────┐     ┌──────────┐
  │ Client   │     │  Agent   │     │  Nodes   │
  │ (CLI/Web)│     │ Runtime  │     │(iOS/安卓)│
  └──────────┘     └──────────┘     └──────────┘

Agent 运行循环

当一条消息进来时，Agent 会经历这样一个循环：

Intake（接收消息）
    ↓
Context Assembly（组装上下文）
    ↓
Model Inference（模型推理）
    ↓
Tool Execution（工具执行）
    ↓
Streaming Replies（流式回复）
    ↓
Persistence（持久化）

这个循环通过 WebSocket 协议与 Gateway 通信：

• Request：{type:"req", id, method, params}• Response：{type:"res", id, ok, payload|error}• Event：{type:"event", event, payload}

事件类型包括 lifecycle（生命周期）、assistant（助手回复）、tool（工具调用）。

上下文管理

Context 是 OpenClaw 发送给模型的全部内容：

• System Prompt：OpenClaw 自动构建，包含规则、工具列表、时间信息 • 对话历史：用户消息 + 助手回复 • 工具调用和结果：命令输出、文件读取、图片等

上下文窗口管理有两个机制：

1. Compaction（压缩）把较旧的对话总结成摘要，保持最近消息完整。支持手动 /compact 命令。

2. Session Pruning（修剪）只修剪旧的工具结果（占用空间大），保留对话文本。

还有一个 Memory System：

• memory/YYYY-MM-DD.md：每日日志 • MEMORY.md：长期记忆（可选）

当 Session 接近自动压缩时，会触发静默的"记忆刷新"——让模型把重要信息写入持久记忆。

多 Agent 协作：路由和隔离

多Agent协作流程图

多Agent协作流程图

图 3：Agent 运行循环流程图

这是我之前说的那个需求的核心：不同渠道用不同 Agent。

路由规则（Bindings）

路由是确定性的，最具体优先：

1. peer 匹配（精确的群组/频道 ID）
2. guildId（Discord 服务器）
3. teamId（Slack 团队）
4. accountId（账号级别）
5. 频道级别匹配（accountId: "*"）
6. 回退到默认 Agent

配置示例：

{
  bindings: [
    {
      agentId: "family",
      match: {
        channel: "whatsapp",
        peer: { kind: "group", id: "120363424282127706@g.us" },
      },
    },
    { agentId: "chat", match: { channel: "whatsapp" } },
    { agentId: "opus", match: { channel: "telegram" } },
  ],
}

效果：

• 特定 WhatsApp 群组 → family Agent（受限权限） • 其他 WhatsApp 私聊 → chat Agent（日常助手） • Telegram 所有消息 → opus Agent（深度工作）

Agent 隔离

每个 agentId 是一个完全隔离的人格：

• 不同的电话号码/账号（每频道 accountId） • 不同的个性（通过 AGENTS.md 和 SOUL.md 配置） • 独立的认证和 Session（除非明确共享）

这意味着你可以让同一个 Gateway 管理十几个 Agent，每个都有独立的工作区、工具权限、模型配置。

Sub-Agent：后台任务

这是我最喜欢的功能之一。

Sub-Agent 允许你启动后台任务，不阻塞主对话：

用户："帮我研究一下最新的 Node.js 发布说明"
    ↓
主 Agent 调用 sessions_spawn 工具
    ↓
创建新 Session：agent:main:subagent:<uuid>
    ↓
Sub-Agent 在后台运行研究任务
    ↓
完成后向主聊天公告结果

主 Agent 会立即返回 {status: "accepted", runId}，然后 Sub-Agent 自己跑。你可以继续和主 Agent 聊其他事情，等任务完成后再查看结果。

配置示例：

{
  agents: {
    defaults: {
      subagents: {
        model: "minimax/MiniMax-M2.1",  // 用更便宜的模型
        thinking: "low",
        maxConcurrent: 4,
        archiveAfterMinutes: 30,
      },
    },
  },
}

实战配置：从零开始搭建

说了这么多，来点实际的。

场景 1：个人助手 + 家庭 Agent

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        name: "Personal Assistant",
        workspace: "~/.openclaw/workspace",
        sandbox: { mode: "off" },  // 主 Agent 不沙箱化
      },
      {
        id: "family",
        name: "Family Bot",
        workspace: "~/.openclaw/workspace-family",
        sandbox: { mode: "all", scope: "agent" },  // 完全沙箱化
        tools: {
          allow: ["read"],
          deny: ["exec", "write", "edit", "apply_patch"],  // 只读
        },
      },
    ],
  },
  bindings: [
    {
      agentId: "family",
      match: {
        channel: "whatsapp",
        peer: { kind: "group", id: "your-group-id@g.us" },
      },
    },
  ],
}

效果：

• main Agent：在你的机器上运行，完全工具访问 • family Agent：在 Docker 容器里运行，只读权限

场景 2：工作 Agent + 日常 Agent

{
  agents: {
    list: [
      {
        id: "chat",
        name: "Everyday",
        workspace: "~/.openclaw/workspace-chat",
        model: "anthropic/claude-sonnet-4-5",  // 快速响应
      },
      {
        id: "opus",
        name: "Deep Work",
        workspace: "~/.openclaw/workspace-opus",
        model: "anthropic/claude-opus-4-6",  // 深度思考
      },
    ],
  },
  bindings: [
    { agentId: "chat", match: { channel: "whatsapp" } },
    { agentId: "opus", match: { channel: "telegram" } },
  ],
}

效果：

• WhatsApp 日常聊天 → 用 Sonnet，响应快 • Telegram 深度工作 → 用 Opus，思考深

常用命令

# 查看状态
openclaw status

# 列出所有 Session
openclaw sessions --json

# 查看上下文使用
/status

# 压缩上下文
/compact Focus on decisions and open questions

# Sub-Agent 管理
/subagents list
/subagents stop <id>
/subagents log <id> 10 tools

与其他方案的对比

方案对比图

方案对比图

图 4：AI 框架特性对比

OpenClaw 的独特优势

1. 开箱即用的多渠道支持

你不需要研究 WhatsApp API、Telegram Bot API、Discord Gateway——OpenClaw 都帮你搞定了。

2. 生产级的 Session 管理

多种作用域、自动压缩、生命周期管理，这些在其他框架里都需要自己实现。

3. 强大的多 Agent 路由

确定性路由、完全隔离、独立配置，让多 Agent 场景变得简单。

4. 自托管优先

数据完全在自己手里，适合隐私敏感场景。

当然，OpenClaw 也有局限：

• 学习曲线比 LangChain 陡（需要理解 Gateway 架构） • 部署需要自己的服务器 • 社区相对较小

如果你的需求是快速原型开发，LangChain 可能更合适。但如果你要部署一个真正可用的多渠道 AI 助手，OpenClaw 是更好的选择。

最佳实践：踩坑总结

用了一段时间，总结几个经验。

Session 设计

• 主 Session 专用于 1:1 流量：让群组保持自己的 Session Key • **多用户场景必须启用 dmScope**：否则所有人的消息会混在一起 • 定期压缩：用 /compact 保持上下文新鲜

多 Agent 路由

• 最具体优先：Peer 匹配 > Account 匹配 > Channel 匹配 • 明确绑定：不要依赖隐式默认，写清楚 • 每个 Agent 独立工作区：不要共享 agentDir

安全建议

• 默认启用沙箱：non-main 模式保护非主 Session • 限制工具权限：特别是 exec、write、edit• 备份工作区：放入私有 git 仓库

记忆管理

• 每日日志：memory/YYYY-MM-DD.md• 长期记忆：MEMORY.md 用于持久事实 • 启用自动刷新：让模型在压缩前写入重要信息

写在最后

OpenClaw 给我的感觉，像是一把精心设计的瑞士军刀——不是每个功能都行业领先，但组合在一起，解决了一个真实存在的问题。

更重要的是，它让我看到了多 Agent 架构的一个清晰范式：

• Gateway 统一接入• Agent 独立隔离• Session 精细管理• 路由灵活配置

这套范式，可能会成为未来 AI Agent 平台的标准架构。

如果你也在做多渠道 AI 助手，或者对多 Agent 协作感兴趣，强烈建议试试 OpenClaw。上手成本不高，收益却很大。

毕竟，在这个 AI 遍地的时代，能不能让 AI 无处不在，可能是下一个竞争焦点。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！