GitHub 今日热榜的榜首是一条熟悉的赛道：mksglu/context-mode，一个给编码 agent 做上下文优化的 MCP 服务器，单日新增 1900+ 星，总星数冲到 29785。README 上的徽章显示它曾拿下 HN 第一（570+ 分），使用方列表里有 Microsoft、Google、Meta、NVIDIA 的团队徽标（自行申报口径）。TypeScript 编写，ELv2 许可，2026 年 2 月建仓，迭代至今正好踩在「上下文工程」这个年度关键词的风口上。
问题只有一个：它真的值得装吗？读完源码结构和文档，我的答案是——如果你重度使用编码 agent，值得；如果只是轻度使用，先理解它的思想，不一定急着装。
它打的痛点，每个重度用户都经历过
Context Mode 的 README 开篇列的数字很扎心，而且与体感高度一致：
- 一次 Playwright 页面快照：56KB 进上下文
- 二十个 GitHub issue：59KB
- 一份访问日志：45KB
- 半小时的重度工作流之后：40% 的上下文窗口没了
上下文被吃掉的连锁反应比数字本身更痛苦：模型开始「近视」，忘记三步之前的决定；自动压缩触发后，正在编辑的文件、进行中的任务、上一条指令全被打包丢失；模型还要花输出 token 写客套话和冗长解释，从另一头继续烧窗口。
这就是作者所说的「上下文问题的另一半」——模型侧的优化（长窗口、更好的压缩）是厂商的事，工具侧的数据流治理是用户自己能动手的。
四个机制，一个控制面
Context Mode 作为 MCP 服务器插在 agent 与工具之间，做四件事：
第一，沙盒执行，原始数据不进上下文。 工具调用的返回值（页面快照、日志、issue 列表）留在沙盒里，只有 agent 提炼后的摘要进入对话。官方口径：315KB 的原始输出压缩到 5.4KB，节省 98%。
第二，SQLite 会话记忆。 每次文件编辑、git 操作、任务变更、报错、用户决策都作为事件落库。对话被压缩时，不回灌数据，而是建立 FTS5 全文索引，agent 按需用 BM25 检索相关事件。压缩后不丢状态，这是它与「裸压缩」的本质区别。
第三，think in code 范式。 这是整个项目最有主张的部分：LLM 应该「编程处理数据」而不是「读取数据再计算」。数 50 个文件的行数，不该是 50 次 Read，而是一段在沙盒里跑完、只打印结果的脚本——47 次 Read 的 700KB 变成一次调用的 3.6KB。这个范式在它支持的全部 17 个客户端里强制生效，还扩展到了 OpenClaw 网关集成。
第四，不管行文。 它明确不做「让模型少说话」的 prompt 干预——原始数据不进上下文，但模型怎么写最终答案是你和你的 CLAUDE.md 的事。这个边界划分在同类工具里算是清醒的。
上手成本：一条命令
npx @context-mode/cli支持 Claude Code、Cursor、Codex 等 17 个平台的 MCP + hooks 配置，首次 hook 触发时自动初始化项目级配置。验证方式也简单：在会话里输入 ctx stats 查看工具是否注册、节省了多少 token。
值得装的三个理由
- 账算得过来。重度用户一天烧掉百万级输入 token 很常见，其中工具输出占比可观。即便按 98% 的乐观口径打个对折，一个月的订阅或 API 账单节省也远超学习成本。
- 压缩恢复是真刚需。其他沙盒类工具只解决「进上下文太多」，没人把压缩后的状态恢复做得这么系统。长任务（重构、迁移、多文件调试）用户对此感受最深。
- 范式可迁移。think in code 不是必须装这个工具才能受益——理解了「让 agent 写脚本算结果」的思想，你在任何 agent 里都能手动实践。装它只是让这件事自动化、强制化。
三个保留意见
第一，沙盒是新的攻击面。 工具输出进沙盒执行代码（ctx_execute 跑 JavaScript），意味着你信任沙盒的隔离质量。在处理不可信数据（网页抓取、第三方仓库代码）时，这条链路的安全审计比传统的「只读进上下文」更关键。建议敏感环境先看清它的执行边界再放开权限。
第二，ELv2 不是 OSI 开源。 个人和公司内部使用没问题，但如果你想把它集成进自己的 SaaS 产品对外提供，许可证的三条限制需要法务过目。同类里纯 MIT 的替代品目前能力弱一截，这是个真实的权衡。
第三，行为差异需要调教期。 agent 的工具调用路径被改变后，前几个任务可能出现「模型还在按老习惯发起大读取」的过渡期摩擦，需要几轮调整 CLAUDE.md 的指引才能稳定收益。
实际工作流会怎么变
装上之后，日常的 agent 会话形态有几个可见的变化，提前有心理预期会顺滑很多：
读代码的方式变了。 以前让 agent「看看这个模块的结构」，它会连续发起几十次 Read，把文件内容灌进上下文再总结；现在它会写一段脚本遍历目录、统计行数、抽取导出符号，只把摘要结果打回来。你会在会话里看到更少的工具调用记录、更多的脚本执行记录。
长任务的断点续传变可靠了。 重构做到一半上下文爆了，这是过去最伤的场景。现在 SQLite 里有完整的事件流：改过哪些文件、跑过哪些命令、卡在哪一步，压缩后 agent 检索几条相关事件就能接上进度。据 README 的口径，全天会话不再需要中途压缩。
stats 是你的仪表盘。 会话里随时输入 ctx stats 能看到 token 节省量。建议第一周每周看一次，确认节省主要来自哪类工具调用——如果发现某类输出（比如测试日志）仍然大量进上下文，说明对应工具还没接进沙盒，需要补配置。
团队落地的一个经验法则：先在一个低风险项目上跑两周，把 CLAUDE.md 里的指引（何时用 ctx_execute、何时允许直接读文件）调稳定后再推广。上下文治理本质上是行为约束，约束太严会逼出模型的变通行为，太松又收不到收益，这个度要靠数据调出来。
把 context-mode 放进生态坐标里看更清楚：模型厂商在做长窗口与自动压缩（治已病），提示词社区在做摘要策略（缓解），context-mode 这类工具在做数据流治理（防未病）。三者不互斥，但边际收益递减的顺序恰好反过来——数据流治理最便宜、见效最快。
这也是为什么它能在两年内攒下近 3 万星：它不跟模型比聪明，只跟浪费做斗争。今天的热榜第一不是偶然，是「上下文成本」这个主题在 2026 年的冬天彻底主流化了。