OpenClaw 架构解析：多通道 AI Gateway 的设计思考

引言

当我们谈论 AI Agent 时，通常关注的是 Agent 本身的能力——如何推理、如何使用工具、如何完成复杂任务。但有一个关键问题经常被忽视：用户如何触达这个 Agent？

OpenClaw 是一个支持多通道的 AI Gateway，Agent 是它的核心能力。它让 AI Agent 能够通过任意渠道（WhatsApp、Telegram、Discord、飞书等）与用户交互。

本文深入分析 OpenClaw 的架构设计，探讨它在 Agent 实现、速度优化等方面的设计思考，以及通用型 Agent 进入 B 端市场后带来的新变化。

问题的本质：多通道 Gateway 面临的挑战

复杂性来源

构建一个多通道 Gateway 面临的核心挑战：

OpenClaw 的本质：Agent 优先的多通道 Gateway

核心理念

传统 Bot：接收命令 → 回复消息（被动）
OpenClaw：接收任务 → 自主执行 → 返回结果（主动 Agent）

OpenClaw 是一个支持多通道的 AI Gateway，Agent 是它的核心能力：

graph LR
    subgraph 用户端
        A[WhatsApp] --> G[Gateway]
        B[Telegram] --> G
        C[Discord] --> G
        D[飞书] --> G
    end
    
    subgraph OpenClaw
        G --> Agent[Agent 引擎]
    end
    
    subgraph 能力
        Agent --> T[Tools]
        Agent --> LLM[LLM]
        Agent --> S[Skills]
    end
    
    style G fill:#4dabf7,stroke:#1971c2,color:#fff
    style Agent fill:#51cf66,stroke:#2b8a3e,color:#fff

整体架构

graph TD
    subgraph 接入层
        WA[WhatsApp] --> CA[Channel Adapter]
        TG[Telegram] --> CA
        DC[Discord] --> CA
        FS[飞书] --> CA
    end
    
    subgraph 核心层
        CA --> R[Router]
        R --> SM[Session Manager]
        SM --> MH[Message Handler]
    end
    
    subgraph Agent层
        MH --> TO[Tool Orchestrator]
        TO --> AG[Agent Loop]
        AG -->|Tool Call| TO
        AG --> LLM[LLM]
    end
    
    subgraph 能力层
        TO --> T1[文件]
        TO --> T2[执行]
        TO --> T3[浏览器]
        TO --> T4[消息]
        TO --> T5[飞书]
    end
    
    style CA fill:#4dabf7,stroke:#1971c2,color:#fff
    style R fill:#4dabf7,stroke:#1971c2,color:#fff
    style SM fill:#4dabf7,stroke:#1971c2,color:#fff
    style MH fill:#4dabf7,stroke:#1971c2,color:#fff
    style TO fill:#4dabf7,stroke:#1971c2,color:#fff
    style AG fill:#51cf66,stroke:#2b8a3e,color:#fff

Agent 核心机制

单层循环 vs 多层编排

OpenClaw 的 Agent Loop：

sequenceDiagram
    User->>Gateway: 用户任务
    Gateway->>LLM: 消息 + Tools 描述
    LLM->>LLM: 推理
    LLM-->>Gateway: 响应/工具调用
    
    loop 工具调用
        Gateway->>Tool: 执行工具
        Tool-->>Gateway: 结果
        Gateway->>LLM: 结果 + 继续生成
    end
    
    Gateway-->>User: 最终回复

核心特点：

1. 单层循环 - 不预分析，收到任务直接执行
2. 按需 Spawn - 只在需要时才启动子 Agent
3. Function Calling 原生 - 直接调用工具，不走 ReAct

Function Calling vs ReAct

# ReAct 模式（OpenClaw 不推荐）
thought: "我需要查天气"
action: search("北京天气")
observation: "晴，25度"
thought: "现在可以回答用户"
final: "北京今天天气晴朗，25度"

# Function Calling（OpenClaw 原生）
{
  "tool_calls": [
    {"name": "weather", "args": {"city": "北京"}}
  ]
}
# → 执行后直接返回结果

工具系统设计

工具定义示例：

{
  "name": "read",
  "description": "读取文件内容，支持文本和图片",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {"type": "string", "description": "文件路径"},
      "lines": {"type": "number", "description": "读取行数"}
    },
    "required": ["path"]
  }
}

速度优化：OpenClaw 为什么响应快

优化策略

两阶段分析的问题

传统方案的通病：

用户任务 → 分析要不要拆 → 拆分任务 → 执行 → 汇总
              ↑            ↑
           1次LLM      1次LLM

OpenClaw 的做法：

用户任务 → 直接执行（有需要才 spawn）
           ↑
         0 次额外分析

复杂任务处理

Skills 封装

Skills 将多个工具组合成可复用的能力：

skills/
├── feishu-doc/      # 飞书文档
├── feishu-task/     # 飞书任务
└── weather/         # 天气查询

SKILL.md 示例：

# feishu-doc

## 描述
飞书文档操作技能

## 工具
- feishu_doc: 读取/写入/创建文档
- feishu_wiki: 操作知识库

## 使用场景
- 读取团队文档
- 创建新文档

Subagent 并行

当任务需要并行处理或隔离执行时：

# 按需 Spawn
if task.needs_isolation:
    spawn_subagent(task, workspace=isolated_workspace)
elif task.can_parallel:
    spawn_subagent(task_a)
    spawn_subagent(task_b)
    await all_results()
else:
    execute_in_loop(task)

MCP 扩展

graph LR
    Agent --> MCP[MCP Client]
    MCP --> E1[文件系统]
    MCP --> E2[数据库]
    MCP --> E3[企业系统]

B 端市场的新变化：从工作流到通用 Agent

以前的 B 端主流：Dify 类工作流方案

在通用型 Agent 火起来之前，B 端的 AI 方案主要是 Dify 这类工作流（Workflow）产品：

Dify 的特点：

• 预设流程：拖拽节点，固定执行路径
• 每一步都配置好，LLM 只负责其中特定环节
• 适合：审批流、查询流、固定流程
• 优势：可控、可预测、可调试

flowchart TD
    A([开始]) --> B{判断节点}
    B -->|条件1| C[LLM 处理]
    B -->|条件2| D[HTTP 调用]
    C --> E([结束])
    D --> E
    
    style A fill:#4dabf7,stroke:#1971c2,color:#fff
    style B fill:#feca57,stroke:#fbc02d,color:#000
    style C fill:#51cf66,stroke:#2b8a3e,color:#fff
    style D fill:#51cf66,stroke:#2b8a3e,color:#fff

Manus：通用型 Agent 的典范

如果说通用型 Agent 有个标志性产品，那就是 Manus。

Manus 的特点：

Manus 的工作模式：

sequenceDiagram
    participant User as 用户
    participant Manus as Manus
    
    Note over User,Manus: === 自主规划阶段 ===
    User->>Manus: "帮我分析这份数据"
    Manus->>Manus: 理解任务 → 拆解步骤 → 制定计划
    
    Note over User,Manus: === 执行阶段 ===
    loop 每个步骤
        Manus->>Manus: 调用工具
        Note over Manus: 浏览器/代码/文件
    end
    
    Note over User,Manus: === 交付阶段 ===
    Manus->>Manus: 整合结果 → 生成报告
    Manus-->>User: 完成报告

Manus 的架构想象：

graph TD
    subgraph Manus 云端
        U[用户请求] --> API[API 网关]
        API --> P[Planner]
        P --> E[执行引擎]
        
        E --> T1[浏览器]
        E --> T2[代码执行]
        E --> T3[文件处理]
        E --> T4[搜索]
        
        T1 --> V[验证器]
        T2 --> V
        T3 --> V
        T4 --> V
        
        V --> R[结果整合]
        R --> U
    end
    
    style P fill:#e599f7,stroke:#be4bdb,color:#fff
    style E fill:#51cf66,stroke:#2b8a3e,color:#fff
    style V fill:#feca57,stroke:#fbc02d,color:#000

Manus 的价值：

• 展示了通用 Agent 的可能性
• 让更多人看到了 “Agent” 能做什么
• 推动了市场对 Agent 的认知

OpenClaw vs Manus：本地部署的新时代

不是技术对比，而是时代演进：

一个有趣的时代趋势：

graph LR
    subgraph 时代演进
        A[早期: 闭源 API] --> B[现在: 云端 Agent]
        B --> C[未来: 本地 Agent]
    end
    
    A -.->|ChatGPT| A
    B -.->|Manus| B
    C -.->|OpenClaw| C
    
    style A fill:#ff6b6b,stroke:#d32f2f,color:#fff
    style B fill:#feca57,stroke:#fbc02d,color:#000
    style C fill:#51cf66,stroke:#2b8a3e,color:#fff

每个人都能拥有本地的通用 Agent：

• 以前：只有大公司能训练模型
• 后来：API 调用是人人可用
• 现在：本地部署 Agent 变成可能
• 未来：每个人都有自己的 AI 助手

这不是 “取代” 关系，而是技术普惠的过程：

• Manus 让大家看到通用 Agent 的可能
• OpenClaw 让每个人都能自己部署

市场正在发生变化

但随着通用型 Agent（如 Manus 这类）的出现，市场正在发生变化：

通用 Agent 的特点：

• 不预设流程：描述目标，Agent 自主判断步骤
• 灵活：能处理非结构化、复杂、多变的任务
• 适合：客服助手、业务查询、多轮对话

用户：帮我处理客户投诉
      ↓
Agent 理解意图 → 判断需要几步 → 动态执行 → 返回结果

C 端 vs B 端：关注点的本质差异

核心区别：

• C 端：关心 Agent “能做什么”
• B 端：关心 Agent “能否稳定、准确、可控地完成任务”

B 端需要什么能力：问题与解决思路

1. 准确性问题

B 端核心问题：结果能否用于生产环境？

解决思路：

graph TD
    A[用户请求] --> B{关键操作?}
    B -->|是| C[人工审批点]
    B -->|否| D[自动执行]
    
    C --> E[确认后执行]
    D --> F[执行]
    
    E --> G[记录日志]
    F --> G
    
    style C fill:#feca57,stroke:#fbc02d,color:#000
    style G fill:#74b9ff,stroke:#0984e3,color:#fff

• 工具精确描述：每个工具的 description 要清晰定义输入输出
• 知识库增强：RAG 接入企业知识，确保回答有据可查
• 审核机制：敏感操作需要人工确认

2. 可追溯性问题

B 端核心问题：出了问题，能否定位原因？

解决思路：

• 完整日志：每步操作、每个 Tool 调用都记录
• 执行轨迹：User → LLM → Tool → Result 全链路追踪
• 审计日志：谁在什么时候做了什么，完整留存

3. 安全问题

B 端核心问题：数据能否保障？操作是否合规？

安全机制体系：

graph TD
    subgraph 安全层
        S1[命令白名单] --> S2[工具权限]
        S2 --> S3[Workspace 隔离]
        S3 --> S4[沙箱执行]
        S4 --> S5[Docker 容器]
    end

命令白名单：

{
  "commands": {
    "deny": ["rm", "dd", "mkfs", "format"]
  }
}

工具权限控制：

{
  "tools": {
    "allow": ["read", "write", "exec"],
    "deny": ["browser", "canvas", "nodes"]
  }
}

Docker 沙箱：

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "session",
        "workspaceAccess": "none"
      }
    }
  }
}

4. 稳定性问题

B 端核心问题：能否承载大流量？能否 7×24 小时稳定运行？

稳定性保障：

gateway:
  rate_limit:
    requests_per_minute: 60
  timeout:
    default: 120s
    tool_execution: 60s
  retry:
    max_attempts: 3
    backoff: exponential
  circuit_breaker:
    enabled: true
    threshold: 10 failures

5. 企业集成问题

B 端核心问题：能否接入现有系统？

MCP 集成企业系统：

Agent → MCP → 企业系统
              ↓
         CRM / ERP / 工单

通用 Agent 进入 B 端的新思路

工作流 vs 通用 Agent

如何选择

混合方案

未来 B 端的主流可能是 工作流 + 通用 Agent 的混合：

flowchart TD
    U[用户请求] --> C{判断类型}
    
    C -->|简单标准化| W[Dify Workflow]
    C -->|复杂非标| A[通用 Agent]
    
    W --> R[返回结果]
    A --> R
    
    style W fill:#4dabf7,stroke:#1971c2,color:#fff
    style A fill:#51cf66,stroke:#2b8a3e,color:#fff

• 简单标准化任务：走 Dify 工作流
• 复杂非标任务：走通用 Agent
• Agent 无法处理：转人工 + 记录工单

总结

OpenClaw 是一个支持多通道的 AI Gateway，Agent 是它的核心能力。它的设计思考：

1. Agent 优先 - 不是 Bot，是能执行任务的 Agent
2. 速度优化 - 单层循环、Function Calling、按需 Spawn
3. 复杂任务 - Skills 编排、Subagent 并行、MCP 扩展

市场变化：

• Manus 展示了通用 Agent 的可能性
• OpenClaw 让每个人都能本地部署

不是技术对比，而是时代演进：

• 以前：只有大公司能训练模型
• 后来：API 调用人人可用
• 现在：本地部署 Agent 变成可能
• 未来：每个人都有自己的 AI 助手

B 端核心关注：

• 准确性：结果能否用于生产
• 可追溯：出了问题能否定位
• 安全：数据保障和合规
• 稳定：能否规模化承载
• 集成：能否接入企业系统

通用 Agent 的价值：

• 不是替代工作流，而是补充工作流无法覆盖的场景
• 适合复杂、非标、多变的业务需求
• 灵活性高，但需要配套的质量保障机制

把 Agent 能力通过任意渠道触达用户，同时保障质量和稳定性——这是 B 端部署的关键挑战。

参考资源： - OpenClaw GitHub - OpenClaw 文档 - Manus 官网 - Function Calling vs ReAct - Sandboxing