在 OpenClaw 中，一条用户消息从进入系统到收到回复，完整链路是怎样的？

🏛 业务架构师

OpenClaw 中一条消息的完整链路，我按九步拆：

渠道接收：用户在 Telegram/Discord 发消息，Channel 插件通过 webhook/长连接收到原始事件；
标准化：Channel 把消息归一化为内部消息对象（发送者、会话 ID、文本、附件）；
Gateway 入口：鉴权（该用户/渠道是否允许）→ 幂等检查（消息 ID 去重，网络重发不重复处理）→ 限流；
路由匹配：按规则（渠道、群组、用户、关键词）决定交给哪个 Agent 处理；
会话装载：按会话隔离粒度（私聊/群组）加载历史上下文；
Agent Runner 执行：装配 System Prompt + 历史 + 用户消息 → 调 LLM → 若模型发起工具调用则执行工具、回填结果、继续循环，直至生成最终回复；
Hook 后处理：安全过滤、日志审计、格式转换在中间件管道执行；
回复下发：Gateway 把回复交回对应 Channel 插件；
状态持久化：会话历史、工具调用记录、成本计量落库。

业务视角看两个环节：第 4 步路由决定"业务编排能力"（不同客群不同 Agent）；第 6 步的循环步数和 token 计量决定"成本归属"——按 Agent、按渠道出成本报表，是 Agent 平台运营的财务基本功。

OpenClaw 一条消息的完整链路，我按八步走一遍（这也是所有 Agent 系统的通用时序）：

接收与归一化：Channel 插件收到渠道回调（Telegram webhook 等），解析为统一消息格式（发送者、会话 ID、内容、附件）；
网关处理：Gateway 鉴权（渠道 token/用户身份）→ 幂等检查（消息去重，渠道重试不重复处理）→ 路由匹配（按渠道、群组、用户规则选定目标 Agent）；
会话状态加载：拉取会话历史与任务状态（持久化存储），唤醒或新建 Agent 会话；
上下文组装：Context Engine 按预算拼装——System Prompt + 长期记忆检索结果 + 历史摘要 + 近期对话 + 本条消息，超预算先触发裁剪/Compaction；
推理循环：Agent Runner 调 LLM → 若输出工具调用：权限策略管道校验 → 执行工具（沙箱）→ 结果压缩回填 → 继续推理；无工具调用则产出最终回复；Hook 全程埋点审计；
回复投递：回复流式（或分片）经 Gateway 回 Channel 插件，适配成渠道消息格式发出；
状态持久化：更新会话历史、任务状态、记忆抽取（异步）；checkpoint 支持断点恢复；
后台任务分支：长任务转后台执行，完成后主动推送通知。

架构要点：链路上每步幂等 + 全链路 trace（消息 ID 贯穿），渠道重试、进程重启、LLM 超时三类故障才能不丢不重。

一条消息的完整链路（按我梳理的时序）：

渠道入站：用户在 Telegram 发消息 → 渠道 webhook 回调 OpenClaw；
Gateway 处理：验签 → 幂等检查（message_id 去重，渠道重试直接返回缓存结果）→ 路由匹配（渠道+群组/用户+规则 → 定位目标 Agent 和会话）→ 限流/黑名单检查；
会话加载：从 Store 取出会话历史与用户记忆；
Context Engine 组装：System Prompt + 会话窗口（必要时触发 Compaction：旧历史摘要化）+ 长期记忆检索注入 + 工具 schema 列表，按 token 预算裁剪；
Agent Runner 循环：调 LLM → 若返回 tool_call：过权限管道（allow/deny/confirm，confirm 则暂停等渠道按钮回调）→ 沙箱执行工具 → 结果（压缩后）回填 → 再调 LLM；循环至产出最终回复或触发预算刹车；
出站适配：回复文本经 Channel Plugin 转渠道格式（Markdown→飞书卡片），长消息分片、按钮附件生成；
收尾：流式/分段推送给用户；Hook 全程记录（审计日志、token 计费）；会话状态、新记忆写回 Store；
异常路径：LLM 超时降级备用模型；工具失败错误信息回喂模型自纠 N 次；全局失败返回兜底话术并告警。

排查这条链路的经验：打全链路 trace_id（Gateway 生成，透传到 LLM 调用和工具执行），否则「用户说没收到回复」这类问题要翻五个日志文件。