夜雨聆风本系列有三篇：
• 上篇：消息怎么找到它的会话 • 本篇：找到会话之后的启动准备 • 第三篇：LLM 调用时的容错管理
上一篇解决了路由问题：一条消息到达后，怎么定位到正确的会话。到这一步，系统手里有了一个确定性的 Session Key——比如 agent:my-assistant:telegram:group:12345。这个字符串对应磁盘上两个文件。源码docs/concepts/session.md在"Where state lives"章节定义了会话数据的存储结构：Store和Transcripts。
Store 是索引，Transcript 是正文。系统先查 Store 找到 sessionId，再用 sessionId 打开对应的 Transcript 文件读取完整对话历史。
• Store（索引）：一个 JSON 文件，按 Session Key 记录每个会话的元信息。你可以在 OpenClaw 安装目录下找到它，路径是 ~/.openclaw/agents/ /sessions/sessions.json。真实的记录长这样：
{
"agent:deepframe-study:main":{
"sessionId":"12d23643-1eb4-4a21-9b57-45c64050cb9d",
"sessionStartedAt":1782133293560,
"lastInteractionAt":1782139522512,
"updatedAt":1782139670436,
"status":"done"
}
}sessionId 指向 transcript 文件名，sessionStartedAt 用于判断是否需要重置（上一篇说过，重置就是结束当前会话、开始一个新的 sessionId），lastInteractionAt 用于 idle reset（空闲超时重置）判断——如果距离最后一次真人发消息已经超过了配置的时长，也会触发重置。注意这个字段只有人发消息才会更新，heartbeat、cron job 等系统事件不会——这样系统自己的定时任务不会把会话“续命”。系统用这几个字段就能快速决定“这个会话是否还活着，要不要重置”，不需要打开完整的对话历史。
• Transcript（正文）：路径是 ~/.openclaw/agents/ /sessions/ .jsonl，Store 里的 sessionId 就是这个文件名。文件里是这个会话的完整对话内容，每行一条 JSON 记录，按时间顺序排列。下面是一个本地 transcript 文件的开头几行：
{"type":"session","version":3,"id":"12d23643-1eb4-4a21-9b57-45c64050cb9d","timestamp":"2026-06-21T13:01:34.832Z"}
{"type":"model_change","provider":"custom-customee","modelId":"Claude Opus 4.6","timestamp":"2026-06-21T13:01:34.877Z"}
{"type":"message","message":{"role":"user","content":[{"type":"text","text":"我希望能看下代码库中源码的 Memory 体系是怎样的"}]},"timestamp":"2026-06-21T13:01:34.986Z"}
{"type":"message","message":{"role":"assistant","content":[...]},"timestamp":"2026-06-21T13:02:15.123Z"}
{"type":"message","message":{"role":"toolResult","content":[...]},"timestamp":"2026-06-21T13:02:16.456Z"}第一行是会话头（session header），记录 sessionId 和创建时间。后面依次是模型配置、用户消息、Agent 回复、工具调用结果——所有事件按发生顺序记录，这就是 Agent 的“对话记忆”。
这一篇的问题是：有了 Session Key 之后，系统怎么准备 LLM 的输入? 因为发给 LLM 的不只是用户刚发的那句话，还有 Agent 的身份定义、之前的对话历史、规则等。这些内容分散在不同文件里，需要在会话时让LLM都感知到。
下面这张图是本篇的大纲——一条消息从到达到提交给 LLM，经历的准备过程：
第一步：去 Session Store 里查
有了 Session Key，下一步是去 Session Store 里查：这个 key 对应的会话是否已经存在，以及是什么状态
查询结果决定了下一步走哪条路：
条目不存在 → 说明是个新会话。那么就分配 sessionId，创建空白 JSONL transcript 文件，写入 store，然后进入 Bootstrap（下一环节）。
条目存在，且未触发重置条件 → 恢复已有会话。直接加载已有的 transcript 文件继续。
条目存在，但触发了重置条件 → 需要重置。生成新的 sessionId，更新 store 条目（sessionStartedAt 刷新为当前时间），旧 transcript 保留在磁盘上。新会话进入 Bootstrap。
条目存在，status 为异常状态 → 对于子代理会话，status 可能是 "failed" 或 "timeout"。主会话通常不设 status，而是通过重置条件来管理生命周期。
重置判断的逻辑在上一篇已经讲过，就是擦除后，重新开始。
第二步：Bootstrap--注入信息
到这一步，系统拿到了一个会话——可能是新建的空白会话，也可能是刚重置的。
Bootstrap 做的事情就是：把 workspace 目录下的文件读出来，注入到 system prompt 里。具体来说：
~/.openclaw/workspace/
├── AGENTS.md → Agent 的行为准则（"你是谁、该怎么做"）
├── SOUL.md → 人格和语气
├── USER.md → 用户信息（"叫大鹏、时区 Asia/Shanghai"）
├── TOOLS.md → 本地工具备忘（"SSH 别名"）
├── MEMORY.md → 长期记忆（"上周决定了 X 方案"）
└── memory/
└── 2026-07-05.md → 近期日记这些文件的内容被拼装进 system prompt 的不同段落，成为 Agent 这一轮对话的"初始知识"。
为什么不把上下文写死在配置里？因为 workspace 文件是动态的——你随时可能更新 MEMORY.md、改 AGENTS.md 的规则、装新 skill。Bootstrap 的作用是在每次冷启动时，去读取当前最新的文件并注入。这也是为什么上一篇说"重置有刷新作用"——重置后重新 Bootstrap，Agent 能看到你在两次对话之间做的所有更新。
源码里 Bootstrap 的入口是 resolveBootstrapContextForRun：
// src/agents/bootstrap-files.ts
exportasyncfunctionresolveBootstrapContextForRun(params: {
workspaceDir: string;
config?: OpenClawConfig;
sessionKey?: string;
sessionId?: string;
agentId?: string;
contextMode?: BootstrapContextMode;
runKind?: BootstrapContextRunKind;
}): Promise<{
bootstrapFiles: WorkspaceBootstrapFile[];
contextFiles: EmbeddedContextFile[];
}> {
const bootstrapFiles = awaitresolveBootstrapFilesForRun(params);
const contextFiles = buildBootstrapContextForFiles(bootstrapFiles, params);
return { bootstrapFiles, contextFiles };
}这个函数做了三件事：
1. 收集文件列表。从 workspace 目录里读取所有注册的 bootstrap 文件: AGENTS.md、SOUL.md、USER.md、IDENTITY.md、TOOLS.md、MEMORY.md、HEARTBEAT.md 等。
2. 过滤和适配。根据会话类型和运行模式决定哪些文件需要注入：
• contextMode: "lightweight" 时（比如 cron job），只保留 HEARTBEAT.md 或直接清空——轻量级任务不需要完整的身份上下文 • heartbeat 运行只注入 HEARTBEAT.md • 已完成 workspace setup 的会话跳过 BOOTSTRAP.md（初始化向导文件）
3. 截断控制。通过 resolveBootstrapMaxChars 和resolveBootstrapTotalMaxChars 限制单文件和总文件的字符数上限，避免 workspace 文件太大把上下文窗口占满。
不是每轮都做 Bootstrap
Bootstrap 开销挺大，相当于一次性把大量内容传到了会话中，如果每轮对话都做一次，浪费 token 且增加延迟。
源码里有一个contextInjection 配置控制这个行为：
// src/agents/bootstrap-files.ts
exportfunctionresolveContextInjectionMode(
config?: OpenClawConfig,
agentId?: string | null,
): AgentContextInjection {
const agentMode =
config && agentId ? resolveAgentConfig(config, agentId)?.contextInjection : undefined;
if (agentMode === "always" || agentMode === "continuation-skip" || agentMode === "never") {
return agentMode;
}
return config?.agents?.defaults?.contextInjection ?? "always";
}配置提供了三种模式：
• "always"（默认）：每轮都注入。即使 transcript 被 compaction 截断了也不会丢失身份上下文。• "continuation-skip"：第一轮注入，后续轮次通过检查 transcript 里是否有FULL_BOOTSTRAP_COMPLETED_CUSTOM_TYPE标记来决定跳过。省 token，但 compaction（上下文压缩，当对话历史太长时系统会截断早期内容）后标记可能丢失。• "never"：完全不注入。用于裸模型调用或者外部系统自己管理 prompt 的场景。
Bootstrap 完成后，系统会在 transcript 里写入一条标记——类型为 openclaw:bootstrap-context:full 的自定义条目。
• 源码：attempt.ts中调用 activeSessionManager.appendCustomEntry(FULL_BOOTSTRAP_COMPLETED_CUSTOM_TYPE, ...)
这条标记的作用是：后续轮次可以通过它判断"这个会话已经 bootstrap 过了"。
判断逻辑在 hasCompletedBootstrapTurn 函数， transcript 文件尾部向前扫描，扫描范围有两个上限：
// src/agents/bootstrap-files.ts
constCONTINUATION_SCAN_MAX_TAIL_BYTES = 256 * 1024;
// 最多读取文件末尾 256KB
constCONTINUATION_SCAN_MAX_RECORDS = 500;
// 最多检查 500 条记录在这个范围内，如果找到这条标记且之后没有发生 compaction，就跳过注入。如果标记被 compaction 截掉了（早期内容被压缩丢弃），系统会重新做一次完整的 Bootstrap。
第三步：会话锁，防并发写
经过 Session Store 查询和 Bootstrap 之后，会话准备好了。但在真正提交 prompt 之前，还有一个并发问题。
假如你在 Openclaw的飞书端快速连发两条消息"帮我查下天气"和"还有明天的日程"。两条消息几乎同时到达，都路由到同一个 session key"agent:my-assistant:telegram:group:12345"，找到了同一个 transcript 文件 "session-9283746501234.jsonl"，然后写内容。如果不加保护，可能出现第一条消息的 Agent 回复被第二条消息的上下文截断，或者两条回复交错写入同一个文件，产生不可理解的对话历史。
attempt.session-lock.ts 是一个 2000+ 行的文件，它解决的核心问题是：同一时刻只有一个请求能写入同一个会话。
物理写锁
最底层是文件系统级别的排他锁（acquireSessionWriteLock）——对 transcript 文件加锁，防止多进程并发写入：
const acquireLock = async (): Promise<SessionLock> =>
await params.acquireSessionWriteLock({
sessionFile: params.lockOptions.sessionFile,
timeoutMs: params.lockOptions.timeoutMs,
staleMs: params.lockOptions.staleMs,
maxHoldMs: params.lockOptions.maxHoldMs,
});锁有三个超时参数：timeoutMs（等多久放弃获取）、staleMs（锁文件多久没更新就认为持有者已崩溃）、maxHoldMs（单次最长持有时间）。
Prompt Release 机制
但 LLM 调用可能需要 30-60 秒。如果整个等待期间都持有写锁，其他消息会排队等很久。所以有一个"Prompt Release"机制——在 prompt 提交后、等待 LLM 响应期间，临时释放锁：
// installPromptSubmissionLockRelease 的核心逻辑
constwrappedStreamFn = async (...args) => {
await params.releaseForPrompt(); // 提交 prompt 前释放锁
try {
returnawaitoriginalStreamFn(...args); // LLM 调用（可能 30-60s）
} finally {
await params.reacquireAfterPrompt(); // 响应回来后重新获取锁
}
};这样整个写入流程就变为了：获取锁 → 准备 prompt → 释放锁 → LLM 调用（30-60s）→ 重新获取锁 → 写入响应。
释放期间有人写了怎么办？
锁释放的那 30-60 秒里，另一个请求可能已经往 transcript 里写了内容（比如另一条消息处理完了）。重新获取锁之后，系统需要判断下文件是否被修改。
做法是记录释放前的文件痕迹SessionFileFingerprint，由文件大小 + 创建时间 + 内容做了哈希，重新获取锁后再取一次做对比。如果两次一样，说明没人动过，正常写入。
如果不一样，系统会分析变更类型（classifySessionFenceChange）——如果只是无害的系统写入（比如一条心跳记录），可以继续；如果是另一条消息的完整回复，就需要重新加载 transcript，在新的末尾位置写入。这个做法是为了更细致的处理冲突，而不会抛出异常。
到这里，一条消息走完了从"找到会话"到"可以提交给 LLM"的全部准备工作。Session Store 确认会话状态，Bootstrap 让 Agent 传入信息，写锁保证并发安全。
下一步才是真正的 LLM 调用——但 LLM 调用可能超时、可能返回错误、可能连续失败把 token 烧光。这些运行时的健康保护机制，下一篇展开。
