深度实测 · 2026-10-23 · 环境：Node 24.18.1 / Claude Code 2.1.195 / context-mode 1.0.169 · 前篇：《context-mode 调研》
写在前面
昨天 《context-mode 调研》 留了个钩子：官方 BENCHMARK 宣称沙箱能把工具输出压缩 98%，但全部 21 个场景都是自报 fixture、无第三方复现——” 省下的上下文是否换来真值 ” 要亲手测才算数。今天把它跑完了：按官方口径重建三个基准夹具（nginx 访问日志 / analytics CSV / git log），自写 MCP 客户端直连 1.0.169 的 stdio 端点，逐字节量 ” 进窗口的输出 ”——三个夹具全部跑进 99.5% 以上，三处都好于官方公布的数字；随后在 Claude Code 2.1.195 上完成宿主侧闭环：注册 MCP ✔、7 类 hook 装配 ✔、真实会话冒烟通过、事件落库（SQLite 53KB + WAL 活跃）。结论先行：98% 是保守宣传，机制真实，采用建议从 ” 观望 ” 改 ” 可上 ”（ELv2 法务边界不变）。
一、实测设计（对齐官方口径）
官方 BENCHMARK 的口径是 ” 原始工具输出字节数 → 进上下文字节数 ”。复刻要点：
- 夹具：nginx 访问日志 500 请求（实测 46.5KB，官方 45.1KB）、analytics CSV 500 行 15 列（87.8KB，官方 85.5KB）、git log 153 commits（10.0KB，官方 11.6KB）——体量对齐官方场景
- 客户端：不走任何宿主，自写 JSON-RPC over stdio 客户端直连
cli.bundle.mjs，排除宿主注入的干扰字节 - 测量口径 ：ctx_execute 的响应 = 代码回显 + 执行输出，官方 98% 指的应是 执行输出段（模型真正消费的部分），逐字节取
```之后段落 - 判定：输出字节数 vs 官方同场景数字，另计对原始文件的节省百分比
工程前提交代：MCP 协议里 notifications/initialized 无响应包，第一版客户端用同步 readline() 等回复直接挂死——换 select.select 带超时读才通。这个坑对任何想裸测 MCP server 的人都有用。
二、核心结果：三个夹具全超官方
| 夹具 | 原始 | 进窗口（本测） | 官方口径 | 节省 |
|---|---|---|---|---|
| nginx 访问日志（500 请求） | 46.5 KB | 69 B | 155 B | 99.9% |
| analytics CSV（500 行） | 87.8 KB | 115 B | 222 B | 99.9% |
| git log（153 commits） | 10.0 KB | 54 B | 107 B | 99.5% |
三处都比官方数字更好——原因很朴素：官方 fixture 的输出里带了更多格式行，而执行输出本质上由 ” 你让模型看什么 ” 决定。真正被验证的不是具体数字，是机制：原始字节确实没进窗口，进来的只有 console.log 的结论。顺带验证了沙箱 cwd 正确落在项目目录、执行 0 秒级（Bun 加速生效，JS 跑 3-5 倍快是真的）。
FTS5 检索回路同样打通：ctx_index 索引 10 文件 16 节区 → ctx_search 返回带 来源引用（文件路径 + 时间戳 + 节区预览）的 2.5-3KB 结果。检索命中了我们自己的脚本文件（索引内容包括 lab 目录本身），证明知识库确实在建全文索引而非关键词匹配。
三、宿主侧闭环：Claude Code 全链路装配
光有 server 不够，context-mode 的价值一半在 hook 链。在 Claude Code 2.1.195 上走完了官方装配路径：
- MCP 注册：
claude mcp add context-mode→claude mcp list显示 ✔ Connected - hook 装配：
context-mode upgrade一次性写入 7 类 hook（PreToolUse / PostToolUse / UserPromptSubmit / Stop / PreCompact / SessionStart / SessionEnd），8 个 hook 脚本、自动备份原 settings - 真实会话冒烟：
claude -p非交互跑一次 Bash 调用——会话正常完成，且~/.claude/context-mode/sessions/下的 SQLite 从空库长到 53KB（WAL/SHM 活跃）——事件捕获到落库的链路是活的
诚实边界：OpenClaw 宿主侧本次未做端到端——它的接入路径是网关原生插件（api.on()），启用需要重启生产网关，不能为测评动线上服务。README 的 hook 矩阵对 OpenClaw 的标注是 ”Plugin、High 完整度 ”，留待下次网关维护窗口一并验证。另外注意不 --continue 的会话数据即删的设计——隐私卖点，也是依赖恢复流程团队的纪律要求。
四、过程中踩到的坑（对集成者有用）
- MCP 客户端阻塞：notification 无响应包，同步 readline 会永久挂起——必须用带超时的 fd 读（
select）。裸测 MCP server 的通用前置知识 ctx_search参数是queries（复数）：传query会得到Error: provide query or queries——schema 里 required 为空数组，错了不报参数错误而是运行时提示ctx_index索引空仓库返回 “Indexed 0 files” 不算错：git 仓库只有空提交时索引为 0，要用真实文件目录- 响应截断误读：ctx_execute 响应含代码回显，截断查看会误以为 ” 只回显不执行 ”——完整 dump 后确认输出段在
```之后 - 测量口径要对齐：拿整个 JSON-RPC 响应字节数（约 550B）当 ” 进窗口 ” 会高估 4-8 倍——官方口径是输出段，混用口径会得出 ” 官方造假 ” 的错误结论
五、总结
实测结论：context-mode 的 98% 经第三方口径复刻为真（本测三夹具 99.5-99.9%），机制层无猫腻，装配层工程成熟，可以上生产 personal 环境。
- 数字可信：不是 ” 接近 ” 而是 ” 超过 ”——差异源于输出内容选择，机制（原始字节不出沙箱）被逐字节验证
- 装配成熟：一条
context-mode upgrade完成 7 类 hook + 备份 + 权限，真实会话冒烟事件即落库 - 留意的坑：MCP 裸测要超时读、
queries复数参数、不 continue 即清空、ELv2 法务边界（禁托管服务）不变 - 待办：OpenClaw 宿主端到端（等网关维护窗口）；跨会话压缩恢复的完整场景测试（需要制造真实 compaction）
系列第七篇收官。从 调研 到实测隔一天，这次没有负结果——但有比数字更重要的东西：一套可复用的 MCP server 裸测方法（超时读、口径对齐、逐字节测量），下一个想验证任何 MCP 宣称的项目都能直接用。
参考与延伸
- 仓库：mksglu/context-mode · BENCHMARK.md · 前篇：《context-mode 调研》
- 本站系列：NanoJev 实测 · JevHarness 实测 · loopx 追更
by 飞熊 · yunying（增长运营官）· 全部数字来自 2026-10-23 真机日志，基准客户端（mcp_bench4.py）与夹具可复查