context-mode插件实测，宣称省98%token，实际在ClaudeCode中仅省89%，原因何在

开源插件 context-mode 近一周在 GitHub 获得超 4,400 颗星，其 README 与 npm 包描述均强调“可节省 98% 上下文 token”。这一数字迅速引发开发者关注，但实际效果是否如宣传所言？本文基于对 v1.0.169 版本源码的深度拆解，并绕过模型直接调用其 MCP server 进行复现测试，还原了该数据的真实来源与适用边界。

98% 的算法本质：预设脚本对比，非真实会话测量

所谓“98%”并非来自动态会话中的实时统计，而是作者通过一个预先编写的汇总脚本，将原始文件字节数与插件处理后进入上下文的字节数做静态比对得出的结果。其对照基线为“原始数据全部进入上下文”，即假设没有任何压缩机制存在——这在实际使用中并不成立。

关键问题在于：Claude Code 本身已内置四道输出闸门，对工具返回内容进行分层截流。根据官方文档（tools-reference 与 env-vars 页面）：

• Bash 工具：有效输出超过约 30,000 字符时，系统自动存为文件，仅向模型传递路径 + 前 2,000 字符预览；
• Read 工具：单次读取上限 25,000 token，整文件超 256KB 直接拒绝，仅提供第一页 + PARTIAL 提示，需手动分页；
• WebFetch 工具：虽无长度硬限，但抓取页面后会先经一次独立模型调用抽取摘要，再将结果送入主上下文；
• MCP 工具（如 Playwright、GitHub API）：默认 MAX_MCP_OUTPUT_TOKENS 为 25,000，超 10,000 token 即触发警告。

这意味着，真正可能“整块涌入”上下文的，是落在上述阈值之间的中等规模输出：例如 5,000–30,000 字符的构建日志、25,000 token 以内的 Read 返回、以及未被 WebFetch 预处理的中型网页快照。一份 57KB 的 Playwright 页面快照约含 14,000 token，低于 MCP 上限，会原样进入上下文——这正是 context-mode 能发挥价值的“漏口”区间。

插件三层机制：路由、沙箱与检索

context-mode 的核心能力由三层机制协同实现：

第一层：PreToolUse Hook 路由引导

位于 hooks/core/routing.mjs 的 hook 逻辑主要起建议作用，仅对少数命令实施改写或拦截：包括 stdout 输出的 curl/wget、内联 HTTP 请求（如 fetch(、requests.get(）、gradle/mvn/sbt 构建命令，以及 WebFetch。普通 Bash、Read、Grep 命令全部放行，仅在首次调用时附加提示语，建议改用 ctx_execute。实测表明，若模型不采纳提示（如直接执行 cat access.log），则仍按原路径传输完整输出——这也解释了为何 README 表格中注明：“有 hooks 约 98%，仅有说明文件约 60%”。收益高度依赖模型行为。

第二层：子进程沙箱隔离

ctx_execute 在独立子进程中运行模型生成的代码，ctx_execute_file 则将文件内容作为 FILE_CONTENT 注入。原始数据保留在子进程内存中，仅将 stdout 输出传回主上下文，外加一段代码回显。这实现了“Think in Code”范式：模型不再读取 50 个文件，而是编写统计脚本，仅消费脚本打印的结果。

stdout 回传策略进一步分三级（阈值见 src/server.ts）：

• 小于 5KB：原样返回；
• 大于 5KB 且带 intent 参数：全文切块入库，仅返回匹配段落标题、首行预览及可搜索词表；
• 大于 100KB 且无 intent：全文入库，仅提示“Indexed N sections，用 ctx_search 查询”；
• 5KB–100KB 之间且无 intent：原样返回——此情形极易被忽略，模型若编写低效脚本又未标注意图，几十 KB 仍会直接涌入上下文。

第三层：SQLite FTS5 按需检索

大输出内容被切块存入本地 SQLite 数据库（路径 ~/.claude/context-mode/content.db），支持全文检索。用户可通过 ctx_search 指令按关键词提取相关片段，避免一次性加载全文。

实测结果：56KB 快照省 89%，而非 98%

为验证实际收益，测试选取 Hacker News 首页快照（57,521 字节），在 Claude Code 中分别走原生 MCP 与 context-mode 路径：

• 不装插件：Playwright MCP 直接返回全文，低于 25,000 token 上限，完整进入上下文；
• 装插件后：ctx_execute 带 intent 执行脚本 → ctx_search 二次调用，共两次工具调用，最终进入上下文字节数为 6,277 字节，节省率达 89%。

值得注意的是，作者在 BENCHMARK.md 中预写的 HN 专用脚本仅输出 299 字节，理论节省 99%。但真实会话中，脚本由模型现场生成，其输出 token 与回显代码均未被计入“节省”，导致实测值与理想值产生偏差。换言之，98% 是“最优脚本+理想基线”下的理论上限，89% 才是典型工作流中的实际收益。

是否值得安装？取决于你的“漏口”大小

判断 context-mode 是否适用，关键看会话中是否存在大量“中等规模输出”——即处于 Claude Code 自带闸门之外、又未被其他机制压缩的内容。例如：

• 频繁调用 Playwright 抓取 20–50KB 的网页结构化数据；
• 模型生成的构建/测试日志在 5K–30K 字符区间；
• 使用 MCP 工具返回 10K–25K token 的中间结果。

若会话主体为小规模交互（如单次 Read <2K、Bash 输出 <5K），或已大量依赖 WebFetch（自带摘要压缩），则插件增益有限，反而增加工具调用次数与复杂度。

此外，插件当前依赖用户主动标注 intent 以触发切块入库，若模型未适配该约定，收益将大幅缩水。从工程角度看，它更像一个“增强型辅助层”，而非全自动压缩器。

行业启示：上下文压缩正走向分层协同

context-mode 的走红反映了一个趋势：随着 LLM 应用深入开发流程，上下文管理正从单一模型侧优化，转向“模型+工具链+插件”多层协同。Anthropic 在 Claude Code 中预置的输出闸门，本质上是将 token 成本前置到工具层；而 context-mode 则在工具层之上叠加语义感知路由与按需检索，形成“防御性压缩”体系。

这种分层思路已在多个平台显现：VS Code 的 Copilot 支持文件摘要预览，Cursor 引入本地索引缓存，甚至部分 IDE 开始集成轻量级向量数据库用于上下文召回。未来，高效上下文管理或将不再是某个插件的独家功能，而是开发环境的标配能力。

目前，context-mode 仍在快速迭代中，其设计思想——尤其是 FTS5 检索与沙箱隔离的组合——为长上下文场景提供了可复用的技术路径。但对于终端用户而言，理性评估自身工作流中的“漏口”规模，比追逐宣传数字更为重要。