西安网站推广建设,网站报价单模板,wordpress插件的意义,九号公司如果你用 Claude Code、Cursor 或其他 AI 编码工具#xff0c;你一定经历过这种绝望#xff1a;切换标签页#xff0c;整个会话没了。Prompt太长#xff0c;应用崩溃。早期说的需求#xff0c;AI早就忘得一干二净。 GitHub: YaBoom/ContextRoller-zyt ⭐ Star 支持一下&am…如果你用 Claude Code、Cursor 或其他 AI 编码工具你一定经历过这种绝望切换标签页整个会话没了。Prompt太长应用崩溃。早期说的需求AI早就忘得一干二净。GitHub: YaBoom/ContextRoller-zyt⭐ Star 支持一下我是怎么发现这个痛点的这周我在做一个 AI 项目连续用了 3 天 Claude Code。这期间我经历了第一次崩溃我在一个复杂的功能上跟 Claude 聊了 2 小时上下文已经建立得很完整——它知道我要做什么、代码结构是怎样的、之前踩过哪些坑。这时候我不小心点了一下浏览器的另一个标签页回来时发现整个会话没了。没有警告没有恢复按钮2 小时的上下文灰飞烟灭。第二次崩溃我学聪明了用终端版的claude命令。这次聊得更久大概 4 小时Prompt 累积得很大。突然报错Prompt is too long然后直接退出。没有自动压缩没有优雅的降级只有冷冰冰的错误。第三次崩溃我试着用CLAUDE.md文件来持久化一些规则。但问题是这个项目越做越复杂CLAUDE.md 越来越长每次启动时 Claude 都要先读完这个文件反而占用大量上下文窗口。而且CLAUDE.md 只是静态的规则没法保存动态的会话状态。我受不了了。上 GitHub 搜了一圈发现我不是一个人。为什么现有方案不够用在 anthropic/claude-code 仓库里关于「会话丢失」「上下文失忆」的 Issue 有几十个Issue #28511: “Session lost when switching between Code/Chat/Cowork tabs”Issue #21105: “Context truncation causes loss of conversation history”Issue #1110: “Prompt is too long without warning”Stack Overflow 的 2025 开发者调查显示45% 的开发者表示调试 AI 生成的代码比预期更耗时其中很大一部分原因是「上下文丢失导致的重复沟通」。我研究了一下现有的解决方案方案问题CLAUDE.md静态文件无法保存动态会话状态太长会占用上下文tmux/screen只保持进程运行不保存 AI 对话历史Git版本控制代码不保存 AI 交互过程手动复制粘贴太累容易遗漏没有一个工具能真正解决「AI 会话生命周期管理」这个问题。我是怎么设计解决方案的我决定自己写一个工具核心需求很明确自动捕获能自动或手动保存完整会话包括对话历史、文件状态、环境变量智能压缩当接近上下文限制时自动压缩历史保留关键决策点快速恢复能在任意时刻恢复到任意会话的状态AI 友好最好能作为 MCP 工具被 AI Agent 自己调用我把它命名为ContextRoller上下文滚轮意思是让会话上下文像滚轮一样顺滑地流转。架构设计┌─────────────────────────────────────────────────────────────┐ │ ContextRoller Core │ ├─────────────────────────────────────────────────────────────┤ │ Session Parser │ Parse Claude/Cursor session files │ │ ️ Compression │ Token-aware context compression │ │ Storage │ Local SQLite optional cloud sync │ │ MCP Server │ Expose as MCP tool for any AI agent │ └─────────────────────────────────────────────────────────────┘三个压缩级别我设计了三种压缩策略应对不同场景Lossless无损: 只合并重复消息、清理空白适合需要完整历史的场景Semantic语义: 保留代码块、错误信息、关键决策压缩普通对话我的默认推荐Summary摘要: 生成高层次总结只保留最后几条消息适合紧急救场踩了什么坑坑 #1: Claude 的会话文件格式Claude Code 在~/.claude/目录下保存会话但格式是 JSON Lines每行一个 JSON 对象而且字段名在不同版本有变化。我花了半天时间逆向工程才搞明白怎么正确解析。坑 #2: Token 估算要智能压缩必须先知道当前用了多少 token。但 TiktokenOpenAI 的 tokenizer不支持异步加载而且不同模型的 tokenizer 不一样。最后我用了简化算法token ≈ 字符数 / 4虽然不完美但够用。坑 #3: MCP Server 的 stdio 模式MCP 协议用 stdio 传输数据这意味着我的 Server 不能用普通的console.log调试否则会污染 JSON 消息流。我改了三次日志方案才搞定。坑 #4: SQLite 在 Node.js 的兼容性sqlite3包有原生依赖在某些环境下编译会失败。我加了better-sqlite3作为 fallback但打包体积又变大了。最后决定先用sqlite3让用户自己处理环境问题。最终实现效果CLI 使用体验# 在项目根目录初始化$ ctxr init ✓ ContextRoller 初始化成功# 捕获当前 Claude Code 会话$ ctxr capture--name用户认证模块重构✓ 会话已保存: 用户认证模块重构 ID: session_1741401600000_a1b2c Token使用:12,345# 查看所有会话$ ctxr list 保存的会话:1. 用户认证模块重构[claude-code]2026/3/810:00:00 ·12,345tokens session_1741401600000_a1b2c2. 数据库表设计[manual]2026/3/718:30:00 ·8,900tokens session_1741315200000_d4e5f# 会话太大压缩一下$ ctxr compress session_1741401600000_a1b2c--levelsemantic ✓ 压缩完成 原始Token:45,678压缩后Token:18,234节省:60.1%MCP Server 集成配置好后Claude 自己就能调用 ContextRoller用户: 我昨天做的那个功能现在想继续优化 Claude: 让我先查看您的历史会话... [调用 contextroller/list_sessions] 找到了几个相关会话 1. 用户认证模块重构 (12,345 tokens) 2. API 性能优化 (8,900 tokens) 您想恢复哪个 用户: 第一个 Claude: [调用 contextroller/restore_session] 好的我已经恢复了 用户认证模块重构 的上下文。 关键决策点 - 使用 JWT Refresh Token 方案 - 密码用 bcrypt 加密salt rounds 设为 12 - 已实现 /login 和 /register 接口 我们可以继续了代码实现核心代码在这里感兴趣可以看看GitHub: YaBoom/ContextRoller-zyt⭐几个关键模块// 智能压缩器exportclassContextCompressor{compress(session:SessionSnapshot,options:CompressionOptions):CompressedContext{// 三种压缩策略...}}// 会话解析器支持 Claude/CursorexportclassSessionParser{asyncparseClaudeSession():PromiseParsedSessionFile|null{// 解析 ~/.claude/ 下的会话文件}}// MCP ServerexportclassContextRollerMCPServer{asynchandleToolCall(name:string,args:Recordstring,unknown):Promiseunknown{// 暴露 capture_session, restore_session, compress_session 等工具}}项目结构ContextRoller-zyt/ ├── src/ │ ├── core/ │ │ ├── types.ts # 类型定义 │ │ ├── storage.ts # SQLite 存储 │ │ ├── parser.ts # 会话解析 │ │ └── compressor.ts # 智能压缩 │ ├── cli.ts # 命令行界面 │ └── mcp/ │ └── server.ts # MCP Server ├── tests/ # 测试套件 └── examples/ # 使用示例还有哪些不足这个项目还很早期有很多地方需要完善只支持 Claude Code: Cursor、Copilot Chat 的格式还没适配压缩算法很初级: 没用 LLM 生成摘要只是基于规则的压缩没有团队同步: 目前只是本地 SQLite多人协作时无法共享上下文Token 估算不准: 不同模型 tokenizer 不同估算会有偏差缺少 GUI: 纯 CLI不够直观如果你对这个方向感兴趣欢迎来 GitHub 提 Issue 或 PR为什么选这个方向做这个工具不只是为了解决我自己的问题。2025-2026 是 AI Agent 爆发的一年但开发者工具明显滞后。我们有了越来越强的 AI却还在用「手动复制粘贴」的方式来管理上下文。我觉得Context 管理会成为 AI 原生开发的核心基础设施之一就像 Git 是代码协作的基础设施一样。ContextRoller 是我的一个实验性尝试。如果你也有类似的痛点或者对这个方向有想法欢迎交流GitHub: YaBoom/ContextRoller-zyt— 求 Star ⭐ 求 Fork