小龙虾(OpenClaw)源码分析4：一条消息的完整路径（入站到回复）
文章目录
前面两篇把“怎么启动”讲了，这一篇正式回答最关键的问题：
用户发来一条消息，OpenClaw内部到底怎么跑起来的？
先看抽象链路
先别管具体渠道，我们抽象成统一流程：
渠道消息 -> Gateway接入 -> 路由/会话判定 -> Agent执行 -> 产出结果 -> 渠道发送
这个流程看起来很常规，但OpenClaw的价值就在于：
把多渠道差异尽量收敛到统一入口和统一出站模型。
入站：先“标准化”再处理
不同渠道（Telegram、Slack、Discord等）原始消息结构差异很大。
典型工程做法是先转成内部统一结构，再走后续流程，OpenClaw也是这个思路。
好处很直接：
- 下游会话和Agent逻辑不需要懂每个平台字段细节
- 新接渠道时，不必重写整套主流程
中间层：路由 + 会话
消息进入主流程后，核心是两件事：
- 路由到哪个Agent上下文
- 落到哪个Session
这个阶段会决定“它记忆的是哪段上下文”“回复发回哪里”。
如果这层没设计好，就会出现经典事故：串会话、串用户、串群聊。
执行层：Agent回合
进入Agent回合后，典型动作包括：
- 装配本轮上下文（系统提示 + 会话历史 + 当前消息）
- 调用模型
- 按需触发工具调用
- 组织最终回复
这一层在OpenClaw里是“可配置 + 可扩展”的，不是写死逻辑，这也是后面插件与工具体系的基础。
出站：按渠道能力分发
Agent产出的结果，最终还要回到具体渠道。
这个环节的难点在于“渠道能力差异”：
- 有的支持富文本，有的不支持
- 有的支持流式编辑，有的只能一次性发送
- 媒体、附件、按钮等能力各不相同
所以出站层通常会做能力适配和降级策略。
你在代码里可以重点看的点
建议重点观察这些“边界处”：
- 入站标准化位置（渠道适配层）
- session key如何决策
- queue mode如何影响消息时序
- 出站发送失败时的重试与降级
这些点比单纯看函数细节更容易形成全局理解。
一条实战阅读建议
你可以自己做个实验：
开启一个渠道，发两条连续消息（第二条紧跟第一条），再对照日志看是否进入队列/合并策略。
这样第6篇讲队列并发时，你会立刻有体感。
小结
这篇的核心不是记函数名，而是记住“消息生命周期”：
- 入站先标准化
- 中间靠路由和会话维持上下文正确性
- Agent回合负责推理和工具执行
- 出站做渠道能力适配
下一篇我们单独展开Session，看看上下文连续性到底是如何落地的。
