上下文恢复

在会话压缩后，或当存在隐含的续写意图但上下文缺失时，自动恢复工作上下文。该能力支持 Discord、Slack、Telegram、Signal 及其他已接入的通信渠道。

适用场景：会话以被截断的上下文开始；用户提及先前工作但未提供具体细节；或出现压缩提示信号。

安全边界

• 本能力优先使用当前渠道/会话的 API 历史记录来恢复上下文。
• 默认情况下，不会执行广泛的文件系统扫描或 shell glob 搜索。
• 不会将恢复的上下文发送至任何外部服务。
• 不会向磁盘写入数据，除非用户明确要求持久化已恢复的状态。

触发条件

自动触发

• 会话以
  标签开始（检测到压缩）
• 用户消息中包含压缩提示词，例如：“Summary unavailable”、“context limits”、“truncated”

手动触发

• 用户说“continue”、“did this happen?”、“where were we?”、“what was I working on?”
• 用户提及“the project”、“the PR”、“the branch”、“the issue”，但未指明具体对象
• 用户暗示先前工作存在，但上下文不清晰
• 用户询问“do you remember...?” 或 “we were working on...”

执行协议

步骤 1：识别活跃渠道

从运行时上下文中提取：

• channel — discord | slack | telegram | signal | 等
• channelId — 具体的渠道/对话 ID
• threadId — 适用于线程化对话（如 Slack、Discord 的 thread）

步骤 2：获取渠道历史（自适应深度）

初始拉取：

message:read
  channel: 
  channelId: 
  limit: 50

自适应扩展逻辑：

1. 解析返回消息中的时间戳
2. 计算时间跨度：newest_timestamp - oldest_timestamp
3. 若时间跨度 < 2 小时 且 消息数量已达 limit：
   • 额外拉取 50 条消息（若平台支持，使用 before 参数）
   • 重复该过程，直至时间跨度 ≥ 2 小时 或 总消息数 ≥ 100
4. 硬性上限：最多 100 条消息（受 token 预算限制）

线程感知型恢复（Slack/Discord）：

# 若存在 threadId，则优先拉取该 thread 内的消息
message:read
  channel: 
  threadId: 
  limit: 50

# 再拉取父级渠道消息以获取更广范围的上下文
message:read
  channel: 
  channelId: 
  limit: 30

需解析的关键内容：

• 近期用户请求（用户提出了什么）
• 近期助手响应（已执行了什么）
• URL、文件路径、分支名、PR 编号
• 未完成的操作（已承诺但尚未履行的动作）
• 项目标识符与工作目录

步骤 3：获取会话上下文（安全模式）

仅调用平台/会话 API（不执行 shell 文件系统扫描）：

# 列出近期会话（若对应工具可用）
sessions_list:
  limit: 5

# 从最可能匹配的会话中拉取最近消息
sessions_history:
  sessionKey: 
  limit: 80
  includeTools: true

若会话 API 不可用，则跳过此步骤，仅基于渠道证据继续处理。

步骤 4：可选的记忆检查（显式限定范围）

仅在 agent 运行时已提供限定范围的记忆工具/路径时才进行检查。
不得在主目录下执行 shell glob 扫描。

步骤 5：合成上下文

生成结构化摘要：

## 已恢复上下文

**渠道：** # ()
**时间范围：**  至 
**分析消息数：** 

### 当前项目/任务
- **仓库：** 
- **分支：** 
- **PR：** # —