03、OpenClaw 消息流转的完整链路

前面知道了 Gateway 负责通信，Agent 负责干活。

那么问题来了：

我们在飞书里 @ 一下机器人，这条消息到底是怎么跑到 Agent，再把答案送回来的？

整个链路可以概括成 5 步。

一、消息流转的 5 个步骤

用户发送消息
     ↓
① 飞书事件订阅
     ↓
② Gateway 解析消息
     ↓
③ bindings 路由 Agent
     ↓
④ Agent + 大模型执行任务
     ↓
⑤ Gateway 返回结果
     ↓
   飞书用户

1. 飞书推送消息

首先需要在飞书开放平台配置事件订阅，例如接收消息事件：

im.message.receive_v1

当用户在飞书中发送消息或 @机器人后，飞书将对应事件推送给 OpenClaw。

2. Gateway 解析消息

Gateway 收到消息后，会提取关键信息，例如：

谁发的？
    ↓
从哪个群发的？
    ↓
消息内容是什么？
    ↓
应该交给谁处理？

Gateway 本身主要负责接收、解析和调度，真正执行任务的是 Agent。

3. 路由到 Agent

接下来根据 bindings 等路由配置，将消息分发给对应 Agent。

例如：

飞书群 A → Agent A
飞书群 B → Agent B
私聊用户 → Agent C

因此一套 OpenClaw 可以配置多个 Agent，让不同 Agent 分别处理不同业务。

4. Agent 执行任务

Agent 收到任务后，再调用大模型以及相应的 Skills、Tools 等能力完成任务。

简单问题可能直接回答：

Agent → LLM → Answer

复杂任务则可能变成：

Agent
  ↓
理解任务
  ↓
调用模型
  ↓
调用工具 / Skills
  ↓
继续推理
  ↓
生成最终结果

所以真正的“干活核心”是 Agent，而不是 Gateway。

5. 返回飞书

任务完成后，结果重新交给 Gateway：

Agent
  ↓
Gateway
  ↓
飞书接口
  ↓
用户收到回复

至此，一次完整的消息处理结束。

---

二、多轮对话为什么不会串？

实际使用中，用户不可能只问一句。

因此 OpenClaw 还需要维护会话上下文。

可以简单理解为：

用户消息
   ↓
Session
   ↓
Agent
   ↓
上下文 / Memory

不同会话通过相应的会话标识进行区分，这样多个用户同时聊天时，Agent 才知道：

这句话应该接着谁的上一句话继续处理。

---

三、同时很多人发消息怎么办？

Gateway 需要同时面对多个用户请求。

可以把它理解成：

用户 A ─┐
用户 B ─┼→ Gateway → Agent
用户 C ─┤
用户 D ─┘

Gateway 负责接住和分发消息，Agent 负责实际执行。

如果 Agent 响应越来越慢，通常可以从几个方向优化：

• 使用响应更快的模型
• 精简 Agent 的系统指令和上下文
• 减少不必要的工具调用
• 使用流式返回改善等待体验
• 将耗时任务改成异步任务

---

四、一张图看懂完整链路

        飞书用户
           │
           ↓
      飞书事件订阅
           │
           ↓
        Gateway
      接收 + 解析消息
           │
           ↓
        bindings
        路由分发
           │
           ↓
         Agent
     ┌─────┼─────┐
     ↓     ↓     ↓
    LLM  Skills Tools
     └─────┼─────┘
           ↓
        执行结果
           │
           ↓
        Gateway
           │
           ↓
         飞书
           │
           ↓
          用户

最后只需要记住这一条主线：

飞书负责把消息送进来 → Gateway 负责接收和路由 → Agent 负责调用模型和工具干活 → Gateway 再把结果送回飞书。

搞懂这条链路之后，再遇到“机器人不回复”的问题，就可以顺着 飞书 → Gateway → bindings → Agent → 模型/工具 → Gateway → 飞书 一层层排查，而不是上来就重装 OpenClaw。