上下文恢复

在会话被压缩后，或当对话有延续性但上下文缺失时，自动恢复工作上下文。适用于 Discord、Slack、Telegram、Signal 及其他支持的平台。

使用时机：会话开始时上下文被截断，用户提及先前的工作但未详述，或出现压缩指示符。

安全边界

• 此技能优先通过频道/会话的API历史记录来恢复上下文。
• 默认情况下，它不会执行广泛的文件系统扫描或shell通配符搜索。
• 它不会将恢复的上下文发送到外部服务。
• 除非用户明确要求持久化恢复的状态，否则它不会写入磁盘。

触发条件

自动触发

• 会话以<摘要>标签开始（检测到压缩）
• 用户消息包含压缩指示符："摘要不可用"、"上下文限制"、"已截断"

手动触发

• 用户说"继续"、"这发生了吗？"、"我们刚才说到哪了？"、"我刚才在做什么？"
• 用户提及“项目”、“PR”、“分支”、“问题”但未具体指明
• 用户暗示存在先前工作但上下文不明确
• 用户询问“你还记得……吗？”或“我们之前在做……”

执行协议

步骤1：检测活动频道

从运行时上下文中提取：

• 频道— Discord | Slack | Telegram | Signal | 等
• 频道ID— 具体的频道/对话ID
• 线程ID— 用于线程化对话（Slack、Discord线程）

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

初始获取：

message:read
  channel: <detected-channel>
  channelId: <detected-channel-id>
  limit: 50

自适应扩展逻辑：

1. 解析返回消息中的时间戳
2. 计算时间跨度：最新时间戳 - 最早时间戳
3. 如果时间跨度 < 2小时 且 消息数量 == 限制：
   • 额外获取50条消息（使用之前参数（如果支持）
   • 重复直到时间跨度≥2小时或消息总数≥100
4. 硬性上限：最多100条消息（令牌预算限制）

线程感知恢复（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：获取会话上下文（安全模式）

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

# List recent sessions (if tool exists)
sessions_list:
  limit: 5

# Pull last messages from likely matching session
sessions_history:
  sessionKey: <candidate-session-key>
  limit: 80
  includeTools: true

如果会话API不可用，则跳过此步骤并仅使用渠道证据继续。

步骤4：可选内存检查（明确限定范围）

仅当代理运行时已提供限定范围的内存工具/路径时才检查内存。请不要

在home目录中运行shell通配符扫描。

编译一份结构化摘要：

## 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>"

### Last User Request
> "<quoted request that may not have been completed>"

步骤6：可选持久化（需先征得同意）

默认情况下不写入磁盘。如需持久化存储，请先询问：

“我可以将恢复的上下文缓存到内存中以供后续连续性使用。需要保存吗？”

步骤7：基于上下文进行回复

展示恢复的上下文，然后提示：

“上下文已恢复。您上次的请求是[X]。此操作[已完成/未完成]。是否[继续/重试/澄清]？”

特定渠道注意事项

Discord

• 使用channelId来自传入消息的元数据
• 公会频道拥有完整的历史记录访问权限
• 线程恢复：检查消息元数据中是否存在threadId来自消息元数据
• 私聊可能历史记录有限

Slack

• 使用channel参数配合Slack频道ID
• 需要线程上下文线程ID— 始终首先检查线程上下文
• 父频道获取提供周边对话上下文
• 可能需要工作区级权限以获取完整历史记录

Telegram / Signal / 其他平台

• 同理消息：读取接口
• 历史记录深度可能因平台而异
• 群组与私聊的上下文可能不同

约束条件

• 当上下文看似缺失时，优先采用此协议而非直接声明“数据不足”
• 自适应深度：从50条开始，最多扩展至100条
• 基于时间的目标：尽可能捕获至少2小时的上下文
• 若恢复失败，需说明已尝试的操作及哪些数据源不可用
• 未经用户明确同意，避免进行广泛的文件系统扫描或写入操作

自动触发检测

在会话开始时，扫描压缩指示符：

# 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. 消息：读取频道=discord 频道ID=1460342116516364533 限制=50
3. 计算时间跨度：2.5小时 — 足够，无需扩展
4. 解析消息，找到最后操作："现在让我提取关键编排决策……"
5. 检查会话上下文API — 提取最近的用户请求
6. 响应：

"上下文已恢复。您最后的请求是从Nexus归档会话中提取PR #137（技能与代理系统）的编排决策。此操作在上下文被截断前未完成。

恢复的状态：

• PR #137：15,053处添加，91个文件，合并状态为冲突
• 规范位置："content/spec-skills-agents-system.md（2067 行）

我是否应继续提取？