介绍
# Context Recovery
在会话压缩后，或者当隐含了续接但上下文缺失时，自动恢复工作上下文。适用于 Discord、Slack、Telegram、Signal 及其他支持的渠道。
**适用场景：** 会话以截断的上下文开始、用户在未指定细节的情况下引用了先前的工作，或出现压缩指示符。
---
## 触发器
### 自动触发器 - 会话以 `<summary>` 标签开始（检测到压缩） - 用户消息包含压缩指示符：“Summary unavailable”（摘要不可用）、“context limits”（上下文限制）、“truncated”（已截断）
### 手动触发器 - 用户说“continue”（继续）、“did this happen?”（这发生了吗？）、“where were we?”（我们刚才到哪了？）、“what was I working on?”（我在做什么来着？） - 用户在不指定具体内容的情况下引用“the project”（项目）、“the PR”（PR）、“the branch”（分支）、“the issue”（议题） - 用户暗示存在先前的工作但上下文不明确 - 用户问“do you remember...?”（你记得……吗？）或“we were working on...”（我们刚才在处理……）
---
## 执行协议
### 步骤 1：检测活动渠道
从运行时上下文中提取： - `channel` — discord | slack | telegram | signal | 等。 - `channelId` — 特定的渠道/对话 ID - `threadId` — 用于线程对话（Slack、Discord 线程）
### 步骤 2：获取渠道历史（自适应深度）
**初始获取：** ``` message:read channel: <detected-channel> channelId: <detected-channel-id> limit: 50 ```
**自适应扩展逻辑：** 1. 解析返回消息的时间戳 2. 计算时间跨度：`newest_timestamp - oldest_timestamp` 3. 如果时间跨度 < 2 小时 且 消息数量 == 限制： - 额外获取 50 条消息（如果支持，使用 `before` 参数） - 重复直到时间跨度 ≥ 2 小时 或 总消息数 ≥ 100 4. 硬性上限：最多 100 条消息（Token 预算约束）
**线程感知恢复（Slack/Discord）：** ``` # If threadId is present, fetch thread messages first message:read channel: <detected-channel> threadId: <thread-id> limit: 50
# Then fetch parent channel for broader context message:read channel: <detected-channel> channelId: <parent-channel-id> limit: 30 ```
**解析内容：** - 最近的用户请求（提出了什么） - 最近的助手响应（做了什么） - URL、文件路径、分支名称、PR 编号 - 未完成的操作（已承诺但未履行的） - 项目标识符和工作目录
### 步骤 3：获取会话日志（如果可用）
```bash # Find most recent session files for this agent SESSION_DIR=$(ls -d ~/.clawdbot-*/agents/*/sessions 2>/dev/null | head -1) SESSIONS=$(ls -t "$SESSION_DIR"/*.jsonl 2>/dev/null | head -3)
for SESSION in $SESSIONS; do echo "=== Session: $SESSION ===" # Extract user requests jq -r 'select(.message.role == "user") | .message.content[0].text // empty' "$SESSION" | tail -20 # Extract assistant actions (look for tool calls and responses) jq -r 'select(.message.role == "assistant") | .message.content[]? | select(.type == "text") | .text // empty' "$SESSION" | tail -50 done ```
### 步骤 4：检查共享内存
```bash # Extract keywords from channel history (project names, PR numbers, branch names) # Search memory for relevant entries grep -ri "<keyword>" ~/clawd-*/memory/ 2>/dev/null | head -10
# Check for recent daily logs ls -t ~/clawd-*/memory/202*.md 2>/dev/null | head -3 | xargs grep -l "<keyword>" 2>/dev/null ```
### 步骤 5：综合上下文
编译结构化摘要：
```markdown ## Recovered Context
**Channel:** #<channel-name> (<platform>) **Time Range:** <oldest-message> to <newest-message> **Messages Analyzed:** <count>
### Active Project/Task - **Repository:** <repo-name> - **Branch:** <branch-name> - **PR:** #<number> — <title>
### Recent Work Timeline 1. [<timestamp>] <action/request> 2. [<timestamp>] <action/request> 3. [<timestamp>] <action/request>
### Pending/Incomplete Actions - ⏳ "<quoted incomplete action>" - ⏳ "<another incomplete item>"
### Key References | Type | Value | |------|-------| | PR | #<number> | | Branch | <name> | | Files | <paths> | | URLs | <links> |
### Last User Request > "<quoted request that may not have been completed>"
### Confidence Level - Channel context: <high/medium/low> - Session logs: <available/partial/unavailable> - Memory entries: <found/none> ```
### 步骤 6：缓存恢复的上下文
**持久化到内存以供将来参考：**
```bash # Write to daily memory file MEMORY_FILE=~/clawd-*/memory/$(date +%Y-%m-%d).md
cat >> "$MEMORY_FILE" << EOF
## Context Recovery — $(date +%H:%M)
**Channel:** #<channel-name> **Recovered context for:** <project/task summary>
### Key State - <bullet points of critical context>
### Pending Items - <incomplete actions>
EOF ```
这确保上下文在未来的压缩中得以保留。
### 步骤 7：使用上下文响应
呈现恢复的上下文，然后提示：
> “上下文已恢复。您上次的请求是 [X]。此操作 [已完成/未完成]。我是应该 [继续/重试/澄清]吗？”
---
## 特定渠道说明
### Discord - 使用传入消息元数据中的 `channelId` - 服务器频道拥有完整的历史记录访问权限 - 线程恢复：检查消息元数据中的 `threadId` - 私信（DM）的历史记录可能有限
### Slack - 将 `channel` 参数与 Slack 频道 ID 一起使用 - 线程上下文需要 `threadId` — 始终首先检查线程上下文 - 父频道获取提供周围的对话上下文 - 可能需要工作区级别的权限才能获取完整历史记录
### Telegram / Signal / 其他 - 使用相同的 `message:read` 接口 - 历史记录深度可能因平台而异 - 群组与私信（DM）的上下文可能不同
---
## 约束
- **强制性：** 在响应“数据不足”或当上下文看起来缺失时提出澄清问题之前，必须执行此协议 - 自适应深度：从 50 条开始，最多扩展到 100 条 - 基于时间的目标：尽可能捕获至少 2 小时的上下文 - 会话日志提取：最多 3 个会话文件 - 内存缓存：追加到每日文件，不要覆盖 - 如果恢复失败，说明尝试了什么以及哪些数据源不可用
---
## 自动触发检测
在会话开始时，扫描压缩指示符：
```python # Pseudocode for trigger detection if message contains "<summary>": trigger_context_recovery() elif message contains any of ["Summary unavailable", "context limits", "truncated", "compacted"]: trigger_context_recovery() elif message matches continuation_patterns: # "continue", "where were we", "did this happen", etc. trigger_context_recovery() ```
**不要等待用户询问** — 如果检测到压缩，主动恢复并呈现上下文。
---
## 示例
**场景：** 会话以压缩摘要开始
``` User message: "<summary>Summary unavailable due to context limits...</summary>" User message: "did this happen?" ```
**代理执行：** 1. 通过 `<summary>` 标签检测到压缩 2. `message:read channel=discord channelId=1460342116516364533 limit=50` 3. 计算时间跨度：2.5 小时 — 足够，无需扩展 4. 解析消息，找到最后的操作：“Now let me extract the key orchestration decisions...”（现在让我提取关键编排决策……） 5. 检查会话日志 — 提取最近的用户请求 6. 将上下文摘要写入 `memory/YYYY-MM-DD.md` 7. 响应：
> “上下文已恢复。您上次的请求是从 Nexus 归档会话中提取 PR #137（技能与代理系统）的编排决策。此操作在上下文被截断前未完成。 > > **恢复的状态：** > - PR #137：15,053 行新增，91 个文件，冲突的合并状态 > - 规范位置：`content/spec-skills-agents-system.md`（2,067 行） > - Nexus 会话：`~/.clawdbot-duke-leto/archive/nexus-sessions/`（96 个文件） > > 我是否继续提取？”