你在 OpenClaw 里输入一句话帮我打开后台检查昨天的订单异常并整理成一份报告。如果只看界面它像一次普通聊天。用户发消息助手回复。但在 OpenClaw 里这句话不会直接丢给模型。它会经过入口标准化、Session 解析、队列调度、上下文组装、模型推理、工具执行、流式返回、持久化等一整条链路。这条链路就是一次 OpenClaw 请求的完整生命周期。理解它非常重要。因为你后面遇到的大多数问题其实都可以放回这条链路里定位为什么我发了两句话Agent 合并成一次处理为什么某个工具没有出现在模型可调用列表里为什么浏览器已经点了按钮但最终回复还没出来为什么同一个问题在 CLI 和消息平台里的上下文不一样为什么 Agent 正在执行时我补充的一句话没有立刻生效这一篇不追求记住所有内部函数名而是建立一张能排错、能设计、能扩展的运行地图。先说结论一次请求不是一次模型调用OpenClaw 官方文档把 Agent loop 描述为一条完整运行链路intake → context assembly → model inference → tool execution → streaming replies → persistence翻成更容易理解的话就是接收输入 → 找到会话和工作区 → 排队或插入当前任务 → 准备模型能看到的上下文 → 调用模型 → 执行模型请求的工具 → 把工具结果送回模型 → 输出最终回复 → 写入会话和状态所以一次 OpenClaw 请求不是用户输入 → 模型回答而是用户输入 ↓ 入口层CLI / Dashboard / API / 消息平台 ↓ Gateway标准化、路由、Session 解析 ↓ 队列层followup / steer / collect / interrupt ↓ Agent Runtime组装上下文、选择模型、加载工具和 Skill ↓ 模型推理、回复或发起工具调用 ↓ 工具系统Shell / Browser / 文件 / MCP / Plugin ↓ Observation工具结果回到模型 ↓ 输出层流式、分块、渠道适配 ↓ 持久化transcript、metadata、usage、状态真正让 OpenClaw 成为 Agent Runtime 的是这条闭环。模型负责判断下一步。OpenClaw 负责把“下一步”变成可控、可观察、可恢复的真实执行。第一阶段入口接收不同渠道先被标准化OpenClaw 的请求可以来自很多入口CLI Dashboard HTTP API Telegram 企业微信 Slack / Discord WhatsApp Webhook 定时任务这些入口看起来都是“用户说了一句话”但实际带来的数据完全不同。CLI 通常只有当前工作目录、输入文本、会话参数。Dashboard 可能带有当前打开的项目、浏览器状态、用户界面中的选择。消息平台会带上 channel、account、peer、message id、群聊上下文、reply id、附件、图片、语音等信息。HTTP API 可能还有业务系统自己的 user id、task id、callback url、trace id。Gateway 的第一件事就是把这些不同形态的输入转换成 OpenClaw 内部可以理解的请求。你可以把它理解成外部世界的各种消息格式 ↓ Gateway 标准化 ↓ OpenClaw 内部统一的 agent request这一步看似普通但非常关键。如果没有入口标准化后面的 Session、队列、上下文、工具权限都无法稳定工作。第二阶段Gateway 解析 Session 和 Workspace一条消息进入后Gateway 要回答两个问题这是谁的请求 它属于哪个运行上下文这里的“运行上下文”至少包括两个核心概念Session这次对话属于哪条会话历史 Workspace这次任务可以看到和操作哪个工作区Session 决定模型能看到哪些历史。Workspace 决定工具能读写哪些文件、从哪个目录执行命令、注入哪些项目上下文。这就是为什么同一句话在不同入口里可能得到不同结果。比如你在 CLI 里说继续刚才那个修复。它可能能看到当前项目的文件、上一次命令输出、之前的代码修改。但你在 Telegram 群里说同一句话如果它映射到另一个 session就未必能看到 CLI 里的历史。OpenClaw 不是把所有地方的聊天都混成一锅。它会根据 channel、account、peer、session key、workspace 等信息组织边界。这个边界是 Agent 可控性的基础。第三阶段去重、合并和队列调度真实系统里消息不会总是干干净净地来一条。消息平台可能重试 Webhook。用户可能连续发几条短消息。Agent 可能正在执行上一轮任务。所以请求进入 Agent Runtime 前Gateway 还要处理三类问题。1. 去重消息平台经常会因为网络重试重复投递同一条消息。如果没有去重用户只发了一句生成日报。Agent 可能执行两次甚至重复发出两份报告。OpenClaw 会根据消息来源、会话、消息 id 等信息做短期去重避免重复触发 run。2. 合并用户经常这样发消息帮我看一下后台 昨天的订单 重点看退款异常 最后给我一个表格如果每一句都触发一次模型调用会浪费成本也会让 Agent 计划混乱。因此入口层可以把同一发送者短时间内的连续消息合并成一个 turn。合并后的输入更接近用户真正想表达的任务。3. 队列和 steering更复杂的是如果 Agent 正在执行任务用户又补充一句怎么办比如 Agent 正在浏览后台页面你突然说只看华东区别看全部区域。这句话不一定应该新开一个任务。它更可能应该作为 steering 进入当前 run 的下一轮模型调用。OpenClaw 的队列语义可以理解成几种模式followup 当前 run 完成后再处理 steer 当前 run 下一次模型调用时带进去 collect 先收集稍后一起处理 interrupt 中断当前 run转向新指令这部分决定了 Agent 的“连续协作感”。一个成熟的 Agent 系统不能只会一问一答。它要能处理用户在任务过程中补充、修正、打断和收束。第四阶段创建 run进入 Agent loop当请求被接受后OpenClaw 会创建一次 run。你可以把 run 理解成一个具体任务从开始到结束的执行实例同一个 session 可以有很多 run。但为了避免工具和会话历史互相打架OpenClaw 会对同一 session 的 run 做串行化。这意味着同一个 session 内 ↓ 一次只让一个主要 run 修改会话状态 ↓ 保证 transcript、工具结果、最终回复顺序一致这不是为了让系统变慢而是为了让结果可信。想象两个 run 同时执行Run A正在修改文件 Run B正在读取同一个文件并总结如果没有队列和写锁B 看到的可能是 A 改到一半的状态。对于聊天玩具来说这可能只是小问题。对于会操作文件、浏览器、业务系统的 Agent 来说这会直接造成错乱。第五阶段组装 Context不只是拼聊天记录准备调用模型之前OpenClaw 要构建 Context。官方文档里对 Context 的定义很直接它是 OpenClaw 在一次 run 中发送给模型的全部内容并受到模型上下文窗口限制。这包括System prompt Conversation history Tool list and tool schemas Skill metadata Workspace injected files Attachments Tool calls and tool results Compaction summaries Runtime metadata Channel context新手最容易误解的地方是Context ≠ 用户刚发的那句话 Context ≠ 长期记忆 Context ≠ 整个 workspaceContext 是“本次模型调用真正能看到的运行包”。它每次 run 都会重新组装。比如 OpenClaw 可能会把这些信息放进去当前时间和运行环境当前 workspace 路径注入的 AGENTS.md、SOUL.md、TOOLS.md 等项目文件可用 Skill 的名称、描述和路径可用工具及其 JSON schema历史对话和必要的摘要最近工具调用返回的 observation这一步决定模型“知道什么”和“不知道什么”。如果模型没有按你的预期行动很多时候不是模型不聪明而是 Context 里没有给到它需要的信息或者给了太多干扰信息。第六阶段解析模型和工具可见性Context 组装的同时OpenClaw 还要决定这次 run 用哪个模型以及模型能看到哪些工具。模型选择通常来自默认配置 会话设置 用户指令 Provider 认证状态 模型能力限制 插件 hook 降级或重试策略工具可见性也不是“系统里有什么模型就能随便用什么”。OpenClaw 要把工具描述和 schema 发给模型模型才知道可以调用它们。但哪些工具应该出现要根据当前运行环境和权限决定。例如Browser 工具需要浏览器能力可用 Shell 工具需要当前运行环境允许命令执行 文件工具需要工作区边界明确 MCP 工具需要对应 MCP server 已配置并可用 插件工具需要插件启用且权限通过这解释了一个常见问题“为什么我明明装了插件模型却没有调用”可能原因包括插件没有被启用工具没有暴露给当前 runschema 没进入本轮上下文权限策略不允许模型认为当前任务不需要调用相关 Skill 只列出了 metadata完整说明还没被读取所以排查工具问题时不要只问“工具在不在机器上”。要问工具是否进入了本轮模型可见上下文 工具是否能在当前 workspace 和权限下执行 工具结果是否正确回到了模型第七阶段模型推理不一定马上给最终答案调用模型后模型通常有两种选择直接回复 请求调用工具普通聊天应用主要处理第一种。OpenClaw 的重点在第二种。比如用户说打开后台检查昨天的异常订单。模型不应该直接编一个答案。它应该先判断我需要打开网页 我需要登录或确认页面状态 我需要筛选昨天 我需要读取表格或导出数据 我需要整理结果于是模型会请求调用 Browser、Shell、文件或业务插件。这里要注意一个边界模型本身不会真的打开浏览器。它只会产生一个结构化工具调用请求。真正执行工具的是 OpenClaw 的工具系统。第八阶段工具执行把现实世界变成 observation工具调用进入 OpenClaw 后运行时会执行它并把结果返回给模型。这个结果通常称为 observation。例如模型请求browser.click(selector#export) ↓ OpenClaw 执行点击 ↓ 工具返回点击成功页面出现下载按钮 ↓ Observation 回到模型Shell 也是类似模型请求执行测试命令 ↓ OpenClaw 运行命令 ↓ 返回 stdout、stderr、exit code ↓ 模型根据结果决定下一步一次 run 里可能会发生多轮工具调用模型推理 ↓ 调用工具 ↓ 得到 observation ↓ 模型继续推理 ↓ 再次调用工具 ↓ 再次得到 observation ↓ 最终回复这就是 Agent loop 的“loop”。它不是装饰词。它表示模型和工具之间会反复交替直到任务完成、失败、超时或被中断。第九阶段流式返回让用户看到执行过程OpenClaw 不会等所有事情结束后才一定给你一个黑盒结果。一次 run 过程中系统可以持续发出多类事件lifecyclestart / end / error assistant模型文本增量 tool工具开始、更新、结束 usagetoken 和成本相关信息这些事件会被不同入口用不同方式展示。CLI 可能直接把工具调用和输出显示在终端。Dashboard 可能把工具执行、浏览器画面、最终回复分区展示。消息平台可能因为消息长度、频率限制把结果分块发送。这就是为什么你有时会看到正在打开页面... 正在读取数据... 已生成报告。它不是模型在“假装进度”。更理想的情况下这些进度来自 Agent loop 的真实生命周期和工具事件。第十阶段持久化不只是保存最终回复一次 run 结束后OpenClaw 要把结果写回系统。持久化的内容可能包括用户消息 助手回复 工具调用记录 工具结果摘要 runId startedAt / endedAt 错误信息 usage metadata session metadata context report为什么这一步重要因为下一次请求要依赖它。如果 transcript 没写好后续模型就不知道刚才做过什么。如果工具结果没记录排错时就看不到失败点。如果 usage 和上下文报告没保留你就很难分析为什么请求变慢、变贵或超出窗口。这也是为什么 OpenClaw 要对 session 写入做保护。Agent 是会真实执行操作的系统。它不能只关心“这次有没有回一句话”。它还要保证状态可追踪。用一个真实场景串起来假设你在企业微信群里说帮我检查昨天退款异常发一份摘要到群里。完整生命周期大概是1. 企业微信把消息投递给 OpenClaw Gateway 2. Gateway 标准化消息识别企业、群聊、发送者和 message id 3. Gateway 去重避免 Webhook 重试导致重复执行 4. Gateway 根据群聊映射到一个 session key 5. 如果当前 session 有任务在跑新消息按队列策略进入 followup 或 steer 6. OpenClaw 创建 run确定 workspace 和可用能力 7. Runtime 加载系统提示词、会话历史、Skill metadata、工具 schema 8. Runtime 选择模型和 Provider 9. 模型判断需要查询业务系统发起工具调用 10. OpenClaw 执行 HTTP / Browser / MCP 工具拿到退款数据 11. Observation 回到模型模型继续分析异常类型 12. 模型生成摘要 13. 输出层根据企业微信消息限制分块发送 14. Transcript、工具结果和 run metadata 写回 session如果第 10 步业务系统接口失败用户看到的可能是“查询失败”。但排查时你应该回到生命周期里看入口是否收到消息 Session 是否解析正确 工具是否进入上下文 模型是否真的发起了工具调用 工具调用参数是否正确 工具返回的是网络错误、权限错误还是业务错误 错误有没有写入 transcript这比只问“模型为什么没做好”有效得多。普通 Agent 和 OpenClaw 的差异很多普通 Agent Demo 的请求生命周期是用户输入 ↓ 拼一个 prompt ↓ 调模型 ↓ 返回文本稍微复杂一点的 Demo 会加工具用户输入 ↓ 模型决定工具 ↓ 执行工具 ↓ 模型总结OpenClaw 要处理的是更完整的生产型生命周期多入口接入 Session 边界 Workspace 边界 队列和中断 Context 组装 模型与 Provider 解析 Skill / MCP / Plugin 扩展 工具权限和执行 流式事件 渠道适配 持久化和排错差异不在“是否能调用工具”。差异在是否能把一次请求稳定地接住、执行、观察、恢复和追踪。常见误解误解一请求慢就是模型慢不一定。慢可能发生在很多阶段入口等待 debounce 排队等待前一个 run 结束 上下文太大 模型响应慢 工具执行慢 浏览器页面加载慢 消息平台发送限速 transcript 写入等待锁排查慢请求时要先定位慢在哪一段。误解二工具装好了模型就一定会用不一定。工具要进入本轮上下文模型要理解工具用途权限要允许调用参数也要合理。工具“存在”和工具“可被本次 run 使用”是两件事。误解三Session 就是聊天窗口不完全是。聊天窗口只是入口表现。OpenClaw 内部的 session 是历史、状态、队列、写入和上下文边界的组织单位。同一个聊天入口也可能因为配置不同映射到不同 session。不同入口也可能被设计成共享某个 session。误解四最终回复就是全部结果不是。Agent run 的真实结果包括最终回复、工具过程、错误、usage、上下文报告、transcript 状态。只看最终回复很容易错过真正的失败原因。学习顺序接下来该怎么继续这一篇建立的是生命周期地图。后续学习可以按下面顺序拆Session 和消息 ↓ Context 和 System Prompt ↓ Gateway 和队列 ↓ 模型 Provider 和工具 schema ↓ Browser / Shell / Canvas ↓ Skill / MCP / Plugin ↓ 部署、日志和排错不要一开始就钻某个配置项。先知道它属于生命周期的哪一段。这样你后面学 Gateway、Context、Skill、MCP、部署排错时知识不会散。最后总结一次 OpenClaw 请求的完整生命周期可以压缩成一句话OpenClaw 先把外部输入变成可运行的 agent request 再在 Session 和 Workspace 边界内组装 Context 让模型和工具在 Agent loop 中交替工作 最后把输出、事件和状态写回系统。这里最重要的不是某个单点能力而是闭环。入口接得住。上下文组得准。工具执行可控。过程能观察。结果能持久化。这才是 OpenClaw 和普通聊天壳子的关键区别。本节作业画出你自己理解的一次 OpenClaw 请求流程至少包含入口、Gateway、Session、Context、模型、工具、输出、持久化。找一篇前面的文章标出它主要讲生命周期里的哪一段。假设用户说“帮我打开网页生成报告”写出这句话可能触发的 5 个内部步骤。思考一个排错场景如果最终回复没有出现你会沿着生命周期检查哪些节点在自己的 OpenClaw 使用场景里区分哪些信息属于 Session哪些属于 Workspace。下一节预告下一节我们继续往下拆会话、消息、上下文和任务状态如何组织也就是回答一个更具体的问题OpenClaw 如何知道“这句话属于谁、接着哪段历史、影响哪个任务”。参考资料OpenClaw DocsAgent loopOpenClaw DocsContextOpenClaw DocsSession managementOpenClaw DocsCommand QueueOpenClaw DocsSteering QueueOpenClaw DocsStreaming and chunking原文链接一次 OpenClaw 请求的完整生命周期 | Harries Blog™