OpenClaw 的上下文构建: Context Assembly 不是聊天记录拼接

OpenClaw 专题第四期

上下文是怎么构建出来的：OpenClaw 的 Context Assembly 不是聊天记录拼接

一条消息进入 OpenClaw 以后，不会直接被送进模型。

OpenClaw 的 Agent Loop 分成几个阶段：

intake-> context assembly-> model inference-> tool execution-> streaming replies-> persistence

`context assembly` 是模型推理之前的正式阶段。

OpenClaw 在让模型做判断之前，会先把本次运行需要的上下文装配出来。这里的上下文不是最近几轮聊天记录，也不是一段很长的 Prompt，而是 OpenClaw Runtime 围绕一次 Agent Run 组织出来的结构化运行现场。

一次 Agent Run 需要明确：

当前消息属于哪个 session

当前 Agent 的身份是什么

当前 Agent 的 workspace 在哪里

当前任务使用哪些配置

当前浏览器 profile 是什么

当前页面是否处于正确业务状态

当前工具能不能被调用

执行结果应该如何输出

本次运行结果如何持久化

这些信息共同构成 OpenClaw 的上下文。

一、Session Context：先确定本次运行属于哪个状态空间

OpenClaw 以 session 作为一次连续交互和任务执行的状态边界。

同一个用户可以同时在多个地方触发 Agent：

在一个群里处理周报

在另一个群里处理招聘

在私聊里询问任务进展

在浏览器任务里执行自动化操作

在定时任务里触发后台检查

这些运行不能混在一起。

OpenClaw 会先确定：

当前 run 属于哪个 session

这个 session 之前发生过什么

当前 session 是否已有任务在执行

本次输出要写回哪里

工具调用结果要归档到哪里

运行状态要如何持久化

Session Context 给本次 Agent Run 划定状态空间。没有这个边界，Agent 会串话、串状态、串工具结果。

所以 OpenClaw 的上下文装配第一步，是确定这次运行属于哪个 session。

二、Agent Context：确定 Agent 的身份、目录、工作区和运行约束

OpenClaw 不是让一个通用模型直接处理所有任务。

每个 Agent 都有自己的运行身份和工作边界。

在 Agent Context 中，OpenClaw 会确定：

当前 Agent 是谁

当前 Agent 的 workspace 在哪里

当前 runId 是什么

当前 session 文件在哪里

当前运行默认 thinking 策略是什么

当前运行允许执行多久

当前 Agent 能访问哪些运行时能力

这些信息不会被简单写进 Prompt，它们由 Runtime 解析并控制。

Agent 的能力边界不靠模型自觉，而靠 Runtime 管理。

比如一个负责周报的 Agent，不应该默认拥有招聘、审批、文件删除、系统变更等无关能力。一个运行在某个 workspace 下的 Agent，也不应该随意跨目录读写。

Agent Context 解决的是：谁在运行，在哪里运行，以什么边界运行。

三、Config Context：稳定规则不交给模型猜

OpenClaw 会把稳定的业务规则放进配置，而不是塞进 Prompt。

以周报自动化为例，配置里会定义：

{  "timezone": "Asia/Shanghai",  "browserProfile": "openclaw",  "targetUrl": "https://...",  "folderDateMode": "week-start",  "weekStartsOn": 1,  "folderNameStrategy": "week-range",  "rangeDatePattern": "MM.DD",  "folderNameSuffix": " 周报",  "parentDirectoryLabel": "2026",  "templateDirectoryLabel": "周报基础模板",  "members": [],  "pageModule": "./weekly-report.page.mjs"}

这些配置定义了当前任务的上下文策略：

使用哪个时区解释日期

周从星期几开始

目标页面在哪里

使用哪个浏览器 profile

页面适配模块是哪一个

预期成员列表从哪里来

这些信息交给模型猜，结果不稳定。

比如用户说“这周周报”，模型可以理解语义，但系统必须明确：

“这周”按哪个时区算

一周从哪一天开始

文件夹名称最终是什么

OpenClaw 的处理方式是：稳定规则配置化，运行时变量结构化，模型不负责猜业务规则。

四、Task Context：把模糊任务变成确定参数

用户输入通常是模糊的。

例如：

帮我看一下这周还有谁没交周报，并提醒一下。

这句话对人来说很好理解，但对系统来说还不够。

OpenClaw 会把它转换成确定的 Task Context：

timezonefolderNamefolderDateweekEndDatereferenceDatetargetUrlparentDirectoryLabeltemplateDirectoryLabelexpectedMembers

这些字段共同决定任务如何执行：

`timezone` 决定日期计算方式

`folderDate` 决定本周目录归属

`weekEndDate` 决定周范围

`folderName` 决定要创建或检查哪个目录

`targetUrl` 决定浏览器打开哪个页面

`parentDirectoryLabel` 决定父目录

`templateDirectoryLabel` 决定模板目录

`expectedMembers` 决定谁应该提交周报

OpenClaw 不会把“这周”直接交给模型自由解释。它会在 Runtime 里完成日期计算、命名策略、目录定位、成员列表等确定性处理。

Task Context 的职责，是把用户的模糊意图转换成系统可执行的确定参数。

五、Browser Context：浏览器现场也是上下文

OpenClaw 的一个重要能力是 Browser Agent。

Agent 不只是调用 API，也可以进入真实浏览器环境执行任务。

浏览器不是普通工具，浏览器本身就是上下文来源。

Browser Context 包括：

当前使用哪个 browser profile

当前 profile 是否隔离

当前页面 URL

当前页面 title

页面是否加载完成

当前是否处于登录页

登录态是否可用

页面是否能执行脚本

页面是否暴露业务数据

以周报自动化为例，OpenClaw 在真正执行任务前，会先检查页面状态。

如果当前页面进入登录页，任务会停止，并提示需要先在 OpenClaw 浏览器 profile 中完成登录。

如果页面中读不到业务上下文，比如没有 `bookId`，任务也会停止。

OpenClaw 不会让 Agent 在一个错误页面上继续执行。它会先确认 Agent 是否站在正确的浏览器现场。

Browser Context 解决的是执行前提问题。

六、Page Context：从页面里提取业务现场

Browser Context 确认浏览器可用。

Page Context 进一步提取页面里的业务状态。

在周报自动化里，OpenClaw 会从页面中读取：

当前 book

当前 group

当前 basePath

模板节点

文档 slug

文档内容长度

编辑页地址

最终文档链接

这些信息直接决定任务下一步怎么走：

本周目录已存在但内容为空，进入修复发布流程

Page Context 的职责，是把页面中的业务状态转换成 OpenClaw 可以使用的结构化上下文。

这也是 Browser Agent 能稳定工作的关键。

OpenClaw 不是只让模型看页面截图，也不是让模型自由点击页面。OpenClaw 通过页面适配模块提取业务状态，再让 Agent 基于结构化状态继续执行。

七、Tool Context：工具不是裸函数，而是受 Runtime 管理的能力

OpenClaw 的工具不是简单函数列表。

工具能力由 Runtime 注入，并且带有执行边界。

一次工具调用需要明确：

当前工具属于哪个 Agent

当前工具在哪个 session 中执行

当前工具使用哪个 workspace

当前工具需要哪些配置

当前工具是否有权限执行

当前工具是否需要等待页面加载

当前工具失败后如何报错

当前工具结果如何回流

当前工具调用如何记录日志

以浏览器页面能力为例，OpenClaw 不会把底层浏览器能力无限开放给业务代码。它会包装成明确的 API：

openUrlnavigatewaitForLoadwaitForNetworkIdlewaitForSelectorwaitForTextwaitForFunctiondelayevaluatesnapshot

这些 API 定义了 Agent 能怎样使用浏览器，而不是让 Agent 随意控制底层环境。

在 OpenClaw 里，工具上下文的核心不是“模型能调什么函数”，而是 Runtime 允许 Agent 在什么边界内执行什么能力。

八、Execution Context：OpenClaw 要知道任务执行到了哪一步

真实任务不是只有输入和输出，中间会有很多状态。

以周报任务为例，完整执行过程是：

打开目标页面-> 检查登录态-> 读取页面业务上下文-> 找到父目录-> 找到模板目录-> 判断本周目录是否存在-> 创建或修复目录-> 复制模板内容-> 发布文档-> 收集已提交成员-> 对比预期成员-> 生成通知内容-> 发送通知

每一步都会产生执行状态：

登录态失效

文档需要修复

成员提交为空

通知已发送

工具执行失败

这些状态不能只留在自然语言对话里。

它们必须成为 Execution Context。

只有结构化执行状态，OpenClaw 才能做到：

幂等

重试

失败恢复

错误定位

审计回放

后续任务衔接

普通聊天机器人只关心这一轮怎么回答。OpenClaw 必须关心任务执行到了哪一步。

九、Output Context：回复也受上下文约束

OpenClaw 的输出不是模型随便组织一句话。

输出同样受上下文约束。

以周报通知为例，配置中会定义通知模板：

{  "createMessage": "@所有人\n大家写周报了了！链接：{link}",  "auditMessage": "@所有人\n周报提交检查（{folderName}）\n已提交：{submitted}\n未提交：{missing}\n链接：{link}"}

输出要结合：

当前任务类型

已提交成员

未提交成员

最终链接

当前通知渠道

是否需要 @ 所有人

模板中的占位符

OpenClaw 的最终回复不是工具结果透传。它会把结构化执行结果渲染成当前渠道可发送、用户可理解的内容。

Output Context 解决的是执行结果如何变成正确的渠道输出。

十、Persistence Context：运行结果会进入下一轮上下文

OpenClaw 的 Agent Loop 最后一步是 persistence。

一次运行结束后，OpenClaw 会把关键结果保存下来。

保存内容包括：

session metadata

runId

输入消息

assistant 输出

工具调用过程

工具执行结果

错误信息

生命周期事件

usage 信息

final payload

这些持久化数据会成为后续运行的上下文来源。

下一次 Agent Run 进行 Context Assembly 时，可以基于之前保存的 session state、工具结果、任务状态继续装配上下文。

Persistence Context 让 OpenClaw 具备连续运行能力。

OpenClaw 的上下文不是一次性 Prompt，而是可持久化、可追踪、可继续使用的运行资产。

十一、OpenClaw 的上下文策略

1. Session 隔离

不同 session 的状态默认隔离。

群聊、私聊、thread、自动化任务、浏览器任务不能混用同一份上下文。

这保证 Agent 不串话、不串任务、不串工具结果。

2. 配置优先

稳定规则进入配置。

时区、日期规则、命名策略、页面模块、通知模板、成员列表这类规则，不交给模型猜。

3. 运行时构建

动态变量由 Runtime 构建。

当前日期、本周目录名、周开始日期、页面状态、任务执行结果，都在运行时生成。

4. 页面结构化

页面现场必须结构化提取。

OpenClaw 从页面里读取 book、group、目录树、文档状态，而不是只依赖截图或自然语言描述。

5. 工具受控注入

工具能力由 Runtime 暴露。

Agent 拿到的是受控 API，不是底层环境的无限权限。

6. 输出按渠道渲染

执行结果和渠道输出分开。

内部结果保持结构化，最终输出根据飞书、企微、Telegram、Webhook 等渠道策略渲染。

7. 运行可持久化

运行结果写回 session 和事件流。

这让 OpenClaw 可以追踪、审计、回放，也可以支持下一轮继续运行。

下期预告

下一期进入 OpenClaw 的决策与执行层：

《Prompt、Agent 与工具调用：系统提示词不是一段咒语，工具调用也不是随便开》

这一期会继续围绕 OpenClaw 展开，重点讲：

Prompt 在 OpenClaw 里如何配合 Runtime Context 工作

Agent 如何作为有边界的运行单元存在

工具为什么不是裸函数，而是 Runtime 管理的执行能力

Browser Tool 为什么是 OpenClaw 的关键工具形态

OpenClaw 如何把模型决策变成可控、可追踪、可恢复的真实动作