Context Recovery 深度评测
核心用法
Context Recovery 是一个协议型 Skill，专为解决大模型对话中的上下文断裂问题而设计。当检测到会话压缩（session compaction）或用户暗示需要延续之前的工作时，它会自动执行七步恢复协议：
1. 智能触发检测 —— 自动识别 <summary> 标签、"context limits" 等压缩标记，或响应 "continue"、"where were we" 等 continuation 话术
2. 频道历史获取 —— 通过平台 API（Discord/Slack/Telegram/Signal）读取最多 100 条消息，采用自适应深度策略（先 50 条，若时间跨度<2小时则扩展）
3. 会话上下文拉取 —— 调用安全的 session API 获取工具调用历史
4. 可选内存检查 —— 仅在 agent runtime 提供明确作用域内存路径时执行
5. 结构化合成 —— 输出包含活跃项目、分支/PR、最近工作流、未完成事项的标准化摘要
6. 显式持久化询问 —— 默认不写盘，如需缓存会征得用户同意
7. 主动续接询问 —— 明确告知恢复结果后，询问 "Shall I continue/retry/clarify?"
显著优点
✅ 零代码执行风险
- 纯 Markdown 文档型 Skill，无任何可执行代码
- 所有 "代码" 均为 YAML 示例或 Python 伪代码，仅作协议说明
- 安全扫描六项全通（静态分析、动态行为、依赖审计、网络分析、隐私合规、威胁情报）
✅ 隐私优先设计
- 严格遵守 "channel/session API history only" 原则，不执行 broad filesystem scans
- 不向外部服务发送恢复的数据
- 默认不写盘，持久化需显式用户同意
- 符合 GDPR 数据最小化原则
✅ 多平台适配
- 原生支持 Discord（含 threads）、Slack（thread-aware）、Telegram、Signal
- Thread 场景优先获取 thread 消息，再补充父频道上下文，避免信息丢失
✅ 资源感知
- 硬限制 100 条消息上限（token 预算约束）
- 自适应扩展逻辑避免不必要的 API 调用
- 清晰的时间跨度目标（≥2小时）保证上下文完整性
✅ 透明度与可控性
- 恢复失败时会明确报告尝试了哪些数据源、哪些不可用
- 所有操作可追溯、可审计
潜在缺点与局限性
⚠️ 依赖平台 API 可用性
- 若
message:read 或 sessions_history API 未实现，恢复能力降级为仅基于当前可见消息 - 部分平台（如 Telegram Secret Chats、Signal）历史深度可能受限
⚠️ 纯文档型带来的功能边界
- 本身不执行实际的 API 调用，依赖宿主 agent runtime 实现
message:read 等工具 - 恢复质量取决于 runtime 提供的工具能力
⚠️ 上下文重建的固有不确定性
- 100 条消息/2小时窗口可能无法覆盖长周期任务
- 高度依赖消息内容的明确性（如是否提及分支名、PR 号），模糊引用可能导致误恢复
⚠️ 无许可证声明
适合人群
| 场景 | 匹配度 |
|------|--------|
| 高频使用 Discord/Slack 与 AI 协作的开发者团队 | ⭐⭐⭐⭐⭐ |
| 长周期编程任务（需跨会话维持项目状态） | ⭐⭐⭐⭐⭐ |
| 对数据隐私敏感、拒绝文件系统扫描的用户 | ⭐⭐⭐⭐⭐ |
| 需要明确协议文档进行安全审计的企业 | ⭐⭐⭐⭐⭐ |
| 离线环境或无平台 API 支持的 runtime | ⭐⭐☆☆☆ |
常规风险与使用建议
风险：API 权限过度授予
- 若 runtime 实际实现的
message:read 工具权限过大（如可读取私密频道），可能被滥用 - 建议: 在受限 scope 下运行，确保 API token 仅授权必要频道
风险：恢复内容误判
- 自动触发机制可能将包含 "summary" 的普通对话误判为 compaction
- 建议: 关键操作前人工确认恢复摘要的准确性
风险：长期记忆缺失
- 超过 2 小时/100 条的历史无法通过此 Skill 恢复
- 建议: 对于关键项目，定期显式保存状态到持久化存储（如 git commit、issue 更新）
---
总结: Context Recovery 是上下文管理领域的安全标杆型 Skill，以零代码执行、隐私优先、多平台适配为核心优势。适合需要可靠会话连续性的团队协作场景，但需确保底层 runtime 提供稳定的平台 API 支持。