[Feature] 在飞书/Telegram 对话中支持 "/history" 与 "/resume"，实现跨终端工作流无缝接力

[WanderWang]

Problem / Use Case

用户故事 1：通勤路上继续写代码

我是一名工程师，上午在公司 MacBook 上用 claude CLI 与 AI 讨论了一小时的项目重构方案。午饭后我需要坐地铁通勤，想掏出手机继续让 AI 执行刚刚定好的重构计划。

现在的痛点：我的 claude CLI 会话只存在于笔记本电脑上。手机上打开飞书后，只能对着一个全新的空会话发呆，之前的上下文全部丢失，必须重新口述一遍方案。

用户故事 2：团队群里接力排查线上故障

某 SRE 团队正在飞书群里用 MetaBot 排查线上故障。工程师 A 正在和 Bot 对话分析日志，突然收到电话需要去开会。工程师 B 想继续刚才的对话进度，而不是从头复述故障现象。

现在的痛点：群聊里一旦有人发了 /reset，或者工程师 A 的 session 24 小时后过期，群里的上下文就断了。团队只能反反复复地给 Bot 发同样的错误日志和背景信息。

用户故事 3：远程服务器上的 AI 会话，希望能通过手机随时接管

我的 AI 会话跑在一台远程 Linux 服务器上的 MetaBot 中。白天在 VS Code 里通过 claude CLI 驱动它写代码，晚上躺在沙发上想用手机�迥飞书查看进度、追加需求。

现在的痛点：手机和服务器上的会话是两个完全独立的世界。我必须回到电脑前，才能继续之前的工作。

核心问题

MetaBot 的核心理念是"让 Claude Code 突破终端的边界"，但当前的 session 机制存在一道无形的墙：

• PC 与手机之间无法接力：通过 claude CLI 创建的会话对 MetaBot 来说是"不可见的"，用户无法在手机端恢复电脑上的工作。
• session 不可发现：用户没有任何方式在 IM 内查看"我有哪些历史会话可以恢复"，只能记住一串 UUID，或者跑到服务器上翻文件系统。
• 上下文丢失成本高：当 session 因 /reset 或 24 小时过期中断后，用户需要花费大量时间重新建立上下文、重复粘贴需求文档。

这直接削弱了 MetaBot "随时随地控制 AI" 的产品价值。

Proposed Solution

在 所有 IM 平台（飞书 / Telegram / 微信） 的聊天窗口中，提供两个对话命令：

1. /history —— 发现历史会话

用户在聊天中发送 /history，Bot 回复一张列表卡片（或文本列表），展示最近可恢复的历史会话，包括：

• 在 MetaBot 内创建的会话；
• 在服务器上通过 claude CLI 独立创建的会话。

列表中应显示会话的简要信息（标题/时间/working directory），以及用于下一步 /resume 的 session ID。

2. /resume <session-id> —— 恢复指定会话

用户在聊天中发送 /resume da9d9f9a-f7f0-4646-aba3-0441bedb21d8，Bot 将当前聊天绑定到该 session。
绑定后，用户发送的下一条消息就会延续该 session 的完整上下文。

关键体验要求

• 零 CLI 操作：全程在 IM 内完成，不需要用户 ssh 到服务器或记住任何命令行工具。
• 自动导入外部 session：如果目标 session 是 claude CLI 创建且尚未被 MetaBot 记录，系统应能自动识别并注册它，无需用户手动干预。
• 群聊友好：在群里执行 /resume 后，群内所有成员的后续 @ 消息都共享恢复后的上下文，便于团队接力。

建议的实现方向（供参考）

• src/bridge/command-handler.ts：新增 /history 和 /resume 分支。
• src/session/session-registry.ts：扩展查询能力，支持从 DB + ~/.claude/projects/ 双源聚合会话列表。
• src/feishu/card-builder.ts：新增列表卡片和成功/失败反馈卡片。
• src/bridge/message-bridge.ts：将 sessionRegistry 注入 CommandHandler，使其具备注册/恢复 session 的能力。

Alternatives Considered

替代方案 1：提供 CLI 命令 mb sessions + mb resume

这个方案要求用户先 ssh 到服务器，通过命令行查看 session 列表，然后再回到飞书里发送 /resume。

为什么不选：违背了"手机优先"的使用场景。用户不应该为了 resume 一个飞书会话而去打开电脑或 ssh 到服务器。Feature Request 的核心诉求就是让一切在 IM 内闭环完成。

替代方案 2：自动同步所有 claude CLI session 到 MetaBot 数据库

在 MetaBot 启动时或定时任务中，扫描 ~/.claude/projects/ 并把所有 .jsonl 文件批量导入 SessionRegistry。

为什么不选：

• 会混入大量用户可能不想在 IM 中看到的测试/废弃 session；
• 工作目录反解可能存在误差（尤其是路径编码和_os差异）；
• lazy import（按需导入）更轻量、更安全，只在用户显式 /resume 时才处理。

替代方案 3：Web UI 的 Session Picker

在 MetaBot 的 Web UI (/web) 里做一个 session 列表页面，用户可以在浏览器里点击恢复。

为什么不选：

• 对飞书用户来说增加了额外步骤（要先打开浏览器、登录、找到页面）；
• 没有解决"在 IM 内一键完成"的核心诉求；
• 可以作为未来的补充，但不应该替代 IM 侧的 /history + /resume。

Additional Context

带来的价值

• 用户体验：真正实现"打开电脑写代码，拿起手机继续"的无缝跨端体验。
• 团队协作：群里可以像接力棒一样传递 AI 会话，A 离开、B 接上。
• 产品心智：强化 MetaBot = "所有 Claude 会话的统一入口" 这一定位。

边界条件与说明

• 安全性：/resume 只能恢复本地已存在的 .jsonl 文件，不能指向任意路径，防止目录遍历风险。
• 群聊行为：由于 MetaBot 的 session 按 chatId 隔离，群聊中 /resume 会改变整个群的当前 session，这与现有 /reset 的语义一致。
• 路径推导：对于外部 claude CLI 会话，系统从 ~/.claude/projects/ 下的目录结构自动推断 working directory，覆盖绝大多数 Linux/macOS 场景。

最小可验收标准（Acceptance Criteria）

1. 在飞书单聊中发送 /history，Bot 返回包含最近会话的列表卡片；
2. 列表中至少能显示 MetaBot 原生 session 和 claude CLI 创建的 session；
3. 发送 /resume <有效 session-id> 后，Bot 返回成功提示，随后用户的新消息能够延续该 session 的上下文；
4. 发送 /resume <无效 session-id> 后，Bot 返回清晰的错误提示；
5. 在群聊中执行 /resume 后，群内成员后续 @ Bot 的消息均走同一恢复后的 session；
6. 现有命令（/help, /reset, /stop, /status）不被破坏。

[floodsung]

感谢这份非常详尽的提案 🙏

PR #227（feat: add /api and /resume commands for remote management）已经实现了 /resume 命令，使用 Agent SDK 的 listSessions() API 来枚举和恢复本地 Claude Code CLI 会话，覆盖了本 issue 的核心诉求（跨终端接力、零 CLI 操作）。

为避免重复跟踪，先将本 issue 关闭为 duplicate。如果 PR #227 合并后发现还缺少 /history 列表展示等本提案中提到但未覆盖的部分，欢迎在 PR 下评论或新开一个聚焦的 follow-up issue。