Context Mode（mksglu/context-mode）：把工具输出关进沙箱，用本地索引把编码智能体的上下文压掉 98%

一、导读

编码智能体正在被自己的工具输出拖垮。一次 Playwright 页面快照 56.2 KB、20 条 GitHub issue 58.9 KB、一份 500 条请求的访问日志 45.1 KB——按项目自己的口径，半小时的日常开发就能吃掉四成上下文窗口，随后触发压缩，模型开始忘记正在改哪个文件、任务进行到哪一步、你最后一次要求了什么。

Context Mode（mksglu/context-mode）打的是这个问题的「另一半」：Cloudflare 的 Code Mode 压缩的是工具定义（入口侧），它压缩的是工具输出（出口侧）。做法朴素到近乎粗暴——原始数据永远不进上下文，只在隔离子进程里跑脚本，只让 stdout 回来；需要细节时再从本地 SQLite FTS5 索引里按需检索。官方基准给出整会话 315 KB → 5.4 KB（约 98%）的压缩，并把会话时长从约 30 分钟拉到约 3 小时。

核心结论：它是一层「上下文网关」，既不是压缩器也不是 RAG。 收益集中在「大数据、小答案」的任务上；风险集中在过早过滤、检索质量与本地数据集中。而它最大的隐性产出，其实是一张把 17 个编码平台 hook 能力差异摊开的兼容性矩阵。

二、项目速览

项目	内容
仓库	`mksglu/context-mode`（原 `mksglu/claude-context-mode`，已改名，工具前缀统一为 `ctx_`）
作者	Mert Köseoğlu（@mksglu），伦敦独立开发者，10+ 年工程经验
主语言 / 许可	TypeScript / Elastic License 2.0（ELv2）
Star / Fork	31,819 / 2,194（GitHub API，2026-10-22 抓取）
一周涨星	2,968（Trending weekly，2026-10-22 抓取）
首次提交	2026-02-23；最近推送 2026-10-22
最新版本	v1.0.169（2026-06-29）
npm 下载	周下载 14,259（2026-10-12 ~ 10-18），月下载 97,779
开放 Issue	356
能力面	11 个 MCP 工具、12 种沙箱语言运行时、17 个编码平台适配
核心依赖	`@modelcontextprotocol/sdk`、`better-sqlite3`、`turndown`、`zod`

许可提醒：多篇第三方中文解读把它写成「MIT」，与仓库实际情况不符——LICENSE 为 Elastic License 2.0，明确禁止把本软件作为托管/管理服务提供给第三方。选型前请以仓库为准。

三、为什么是它：上下文问题的「另一半」

第一，它切中的是 MCP 生态被长期忽视的出口侧。 MCP 消耗上下文有两条路径：入口侧是工具定义，81 个以上工具挂上去，光 schema 就可能占掉约 143K token（200K 窗口的 72%）；出口侧是工具输出，每一次 gh issue list、每个日志文件、每张快照都会原样落进对话并逐轮被带着走。Code Mode 解决了入口侧，出口侧一直没人管——Context Mode 的立项叙事正是「nobody was solving the output side」。

第二，它把「压缩」做成了确定性的，而不是模型行为。 检索侧是纯本地的 FTS5 + BM25 + Porter 词干 + 三元组子串，加 RRF 融合与 Levenshtein 纠错，全程零 LLM 调用、零遥测。相比「让另一个模型去摘要」，确定性文本处理的压缩过程可复现、可检查，不会引入新的幻觉面。

第三，它踩中的是失忆，而非变慢。 上下文一满，Agent 压缩对话，压缩完就忘了自己在改哪个文件。它用「每项目一个 SQLite 事件库 + 压缩前生成 ≤2 KB 优先级快照」兜住工作状态，这个设计比省 token 更有产品价值。

第四，涨星动因里也有一半是争议。 它在 Hacker News 上曾冲到榜首（约 570 分、250+ 评论），支持者认可「完整结果保持可检索、只把更小的输出还给模型」，批评者质疑「模型在看数据之前怎么可能写出正确的抽取代码」。维护者本人承认了「拦截过于激进」并移除了该行为——一个愿意在公开讨论里改设计的项目，比一个只贴 benchmark 的项目更值得读。

四、【重点】架构原理

4.1 整体架构：插在工具输出路径上的旁路层

Context Mode 不碰模型、不改提示词，它是在「工具调用 → 输出进上下文」这条路上设了一个卡口。整体数据流如下：

graph TD
    U["用户 / 编码智能体<br/>Claude Code · Gemini CLI · Copilot · Codex · Cursor"] --> H["Hook 层<br/>PreToolUse · PostToolUse · UserPromptSubmit · PreCompact · SessionStart"]
    H --> R{"路由判定<br/>输出是否可能很大/可复现?"}
    R -->|小输出 / 文件编辑| N["原生工具<br/>Bash · Read · Edit"]
    R -->|大输出 / 日志 / 快照 / 网页| S["沙箱执行层<br/>ctx_execute · ctx_execute_file · ctx_batch_execute"]
    S --> P["隔离子进程<br/>12 种语言运行时 · 仅 stdout 回流"]
    S --> KB["知识库层<br/>SQLite FTS5 · BM25 · RRF"]
    KB --> Q["按需检索<br/>ctx_search · ctx_index · ctx_fetch_and_index"]
    Q --> C["上下文窗口"]
    P --> C
    H --> E["事件库<br/>文件/任务/git/错误/决策"]
    E --> SN["压缩快照 ≤2 KB<br/>session_resume"]
    SN --> C

最值得注意的不是沙箱，而是两条回流边：一条是「沙箱 → 只把 stdout 送进上下文」，另一条是「事件库 → 压缩后重建工作状态」。前者省 token，后者防失忆，两者共用同一个本地 SQLite 文件。

4.2 分层模块拆解

层	职责	关键接口
Hook 层	程序化拦截、阻止、重定向工具调用	`PreToolUse` / `PostToolUse` / `UserPromptSubmit` / `PreCompact` / `SessionStart`
沙箱执行层	隔离执行脚本，原始数据不出边界	`ctx_execute`、`ctx_execute_file`、`ctx_batch_execute`
知识库层	分块、索引、检索	`ctx_index`、`ctx_search`、`ctx_fetch_and_index`
元工具层	诊断与运维	`ctx_stats`、`ctx_doctor`、`ctx_upgrade`、`ctx_purge`、`ctx_insight`
持久化层	会话事件与快照	SQLite（`bun:sqlite` / `node:sqlite` / `better-sqlite3` 自适应）
适配层	17 个平台的 hook 与配置差异	`configs/<platform>/` 下的 hooks 配置与指令文件

适配层才是这个项目的主体工作量。 各客户端的 hook 名称、配置位置、工具前缀、压缩行为都不同：Claude Code 有完整五钩子；Codex 的 hook 藏在特性开关后且不能改写入参；Cursor 文档写了 sessionStart 但校验器拒绝；OpenCode 没有 SessionStart，只能拿 experimental.chat.system.transform 当替身；Zed 与 Antigravity IDE 无 hook，只能退回指令文件。一个项目要为十六七种运行时写不同接入路径，本身就说明了生态的碎片化程度。

4.3 核心机制一：沙箱隔离——原始数据永不进上下文

原理一句话：工具在隔离子进程里执行，只有 stdout 进入上下文，原始数据永远出不了沙箱。

// 反面：47 次 Read()，约 700 KB 进入上下文
// 正面：1 次 ctx_execute()，只有 3.6 KB 回来
ctx_execute("javascript", `
  const fs = require('fs');
  const files = fs.readdirSync('src').filter(f => f.endsWith('.ts'));
  files.forEach(f => console.log(
    f + ': ' + fs.readFileSync('src/' + f, 'utf8').split('\n').length + ' lines'
  ));
`);

每次调用拉起一个独立子进程，stdout 被捕获，只有 stdout 进入对话，完整输出被索引进本地 SQLite。支持 12 种语言运行时：JavaScript、TypeScript、Python、Shell、Ruby、Go、Rust、PHP、Perl、R、Elixir、C#；检测到 Bun 时 JS/TS 快 3–5 倍，否则要求 Node.js ≥ 22.5。两个细节：认证类 CLI 能正常用（gh、aws、gcloud、kubectl、docker 继承环境变量与配置路径，token 不进对话）；意图驱动过滤（输出超 5 KB 且提供 intent 时，把完整输出索引进知识库，只返回匹配片段与可继续检索的词表——没有信息被丢弃，只是换了个地方放）。

4.4 核心机制二：FTS5 知识库——确定性检索而非向量近似

索引侧用 SQLite FTS5 虚拟表，按标题分块但保持代码块完整。检索侧是一套组合拳：

双路并行：Porter 词干（caching 命中 cached / caches / cach）与三元组子串（useEff 命中 useEffect，authenticat 命中 authentication）；
RRF 融合：两路排序用 Reciprocal Rank Fusion 合并，两路都排得高的文档浮到前面——替代了早期「三元组只在词干无结果时才用」的级联回退；
邻近重排：多词查询额外重排，"session continuity" 中两词相邻的段落排名更高；
Levenshtein 纠错：kuberntes → kubernetes、autentication → authentication，纠错后重新检索。

作者在 Hacker News 上确认：这套检索是纯确定性文本处理，不涉及任何模型调用。 代价是擅长词汇匹配、不擅长语义匹配——你记得某个决策的「意思」但记不住当时的「用词」时，BM25 帮不上忙。

4.5 核心机制三：会话连续性——把上下文窗口当缓存，后面挂一个数据库

/compact 会丢掉原始对话历史，丢完之后模型就忘了它在改哪些文件。解法是持久化 + 优先级快照：

PreCompact 触发
  → 从 SQLite 读出全部会话事件
  → 构建优先级分层的 XML 快照（≤2 KB）
  → 存入 session_resume 表

SessionStart 触发（source: "compact"）
  → 取回快照
  → 写出结构化事件文件 → 自动索引进 FTS5
  → 构建 15 类 Session Guide
  → 注入 <session_knowledge> 指令
  → 模型从最后一次用户提示继续，带着完整工作状态

快照按优先级分层：预算紧张时先丢低优先级事件（会话意图、MCP 工具计数），关键状态（活跃文件、任务、规则、决策）永远保留。恢复后的 Session Guide 覆盖 15 类状态：最后请求、任务清单、关键决策、修改过的文件、未解决错误、git 操作、项目规则、用过的 MCP 工具与调用次数、子智能体任务、技能、环境、数据引用、会话意图、用户角色。

事件捕获分四档：Critical P1（文件 read/edit/write/glob/grep、任务 create/update/complete、项目规则文件、每条用户提示）、High P2（用户决策与偏好、git 操作、错误与非零退出码、环境变化）、Normal P3（MCP 工具调用与计数、子智能体、slash 命令、人设指令）、Low P4（会话模式分类、>1 KB 粘贴数据引用）。

一个值得留意的行为：不带 --continue 时，上一次会话的数据会被立即删除——新会话就意味着空白。这是合理的隐私取向，但需要团队在流程里明确。

4.6 核心机制四：路由强制——hook 能拦，指令文件只能劝

这是全项目最关键的一条工程纪律，也是它与其他「上下文优化提示词」的分水岭：

Hooks 能程序化拦截、阻止、重定向工具调用；指令文件只能通过提示引导模型，什么都拦不住。

官方给出的量化差异非常直白：有 hook 的平台约省 98%，没有 hook 的平台约省 60%。 原因很简单——没有 hook 时，一次未被路由的 curl 或 Playwright 调用就能灌进 56 KB，把省下来的全抵消掉。

另一个细节：路由指令文件早期会在首次会话启动时自动写进项目目录，后来被关闭了（issue #158、#164），以免污染 git 工作树。有 hook 的平台改为注入或强制路由，不落文件；只有 Zed 与 Antigravity IDE 这类无 hook 平台才需要手动复制一次路由文件。

4.7 性能优化手段与设计取舍

原生 SQLite 绑定自适应：Node ≥ 22.5 用 node:sqlite，Bun 用 bun:sqlite，老 glibc 自动编译 better-sqlite3（需 C++20 / GCC 10+）。代价是构建链复杂度。
渐进节流：同一会话内检索调用达到 9 次以上会被阻止并重定向到 ctx_batch_execute——把「一次查一个问题、反复进出工具」改成批量执行 + 批量检索。
TTL 缓存：默认 24 小时，可用 ttl / force 覆盖；14 天清理。
刻意不做的两件事：① 不强制文风——只控制数据去向，从不规定模型如何写最终答案。项目引用 Moonshot AI 在 kimi-k2.5 上的观察：激进的简洁提示会损害编码与推理基准表现。② 不做语义摘要——检索全程零 LLM 调用，避免引入新的不确定性。
取舍的代价：对「大数据、小答案」的任务收益极高，但对「必须完整读原文」的任务只能延迟成本、不能消除成本。如果 Agent 最终仍需读取完整材料（例如要安全地编辑代码），它必须先看到原文——这时压缩反而增加了往返。

4.8 与其他架构路线的差异

路线	代表	打的是哪一侧	相对 Context Mode 的取舍
工具定义压缩	Cloudflare Code Mode	入口侧（schema）	把百万 token 定义压到约 1,000；与 Context Mode 互补而非竞争
输出旁路沙箱	Context Mode	出口侧（输出）	只把 stdout 还给模型；但依赖 hook 平台，无 hook 时退化到 ~60%
直接截断 CLI 输出	rtk 类工具	出口侧	实现最简、零依赖；但截断有损且不可检索
动态修剪	Opencode-DCP 类	出口侧	平台内建，无需额外进程；但策略写死在客户端里
磁盘交接	自研 runner + `${RUN_DIR}`	出口侧	产物写盘、只传路径；确定性最强，但要自建整套编排
向量 RAG	通用向量库	检索侧	语义召回强；但需嵌入模型、有成本与不确定性

一句话：Code Mode 管「模型看到多少工具」，Context Mode 管「模型看到多少数据」，磁盘交接管「数据根本不进模型」——三者是同一问题的不同切面，不是替代关系。

五、【重点】应用场景

场景一：修 CI / 补测试——把失败日志关进沙箱

业务痛点。 修失败测试的典型循环是：读文件 → 跑命令 → 看日志 → 改文件 → 再跑命令。几轮之后，上下文里混着旧错误栈、重复的 Bash 输出、已经修掉的问题、无关的依赖安装日志。模型不是败在推理上，是败在上下文被低价值信息挤满。

做法。 让 Agent 写脚本分析日志，而不是把日志读进来。

claude mcp add context-mode -- npx -y context-mode     # 一条命令接入
/plugin marketplace add mksglu/claude-context-mode     # 或插件市场（含自动路由 skill）
/plugin install context-mode@claude-context-mode

ctx_execute("shell", `
  npm test 2>&1 | grep -E "FAIL|Error:" | sort | uniq -c | sort -rn | head -20
`);

收益。 官方基准：测试输出（30 套件）6.0 KB → 337 B（95%）；访问日志（500 条）45.1 KB → 155 B（100%）；分析 CSV（500 行）85.5 KB → 222 B（100%）。另一组对照是 47 次文件读取约 700 KB，对一次 ctx_execute 的 3.6 KB。

适用边界。 ①调试证据链敏感的仓库要谨慎——有团队在 ADR 里记录：2 项检查硬性要求原始字节（axe 违规对象要逐字嵌入、控制台错误要逐行 file:line 来源），而 ctx_execute_file 的 1–2 行摘要是「有损且非确定」的，会破坏指纹契约，他们最终选择不采纳。②任务本质是「读完整文件再改」时，压缩没有意义。

场景二：长会话不丢工作状态——用快照替代压缩失忆

业务痛点。 上下文一满，/compact 丢历史，模型忘记在改哪个文件、当前任务、你最后的请求，然后重复提问或跑偏。

做法。 装完即生效，无需额外配置。压缩时自动走 PreCompact → session_resume → SessionStart。

ctx_search(queries: ["decision"], source: "decision", sort: "timeline")
ctx_search(queries: ["constraint"], source: "constraint")

收益。 会话时长从约 30 分钟延长到约 3 小时；整会话 315 KB → 5.4 KB。恢复后注入的 Session Guide 覆盖 15 类状态。

适用边界。 ①快照预算只有约 2 KB，对真正纠缠的长会话是否够用是公开讨论里未回答的问题。②平台差异巨大：Claude Code 五钩子全开、会话支持完整；Gemini CLI / VS Code Copilot 缺 UserPromptSubmit，用户决策与纠正不会被捕获；OpenCode 缺 SessionStart，事件存了但压缩后不会自动恢复；Codex CLI 完全没有 hook，等于没有会话连续性。③不带 --continue 时旧会话数据立即删除。

场景三：网页抓取与文档查阅——原始 HTML 永不入上下文

业务痛点。 让 Agent 查文档、抓 API 响应，整页 HTML 或 JSON 直接落进对话，一次就是几十 KB。

做法。 用 ctx_fetch_and_index 替代 WebFetch，再用 ctx_search 取片段。

ctx_fetch_and_index({ url: "https://docs.example.com/api", source: "api-docs" });
ctx_search({ queries: ["rate limit", "pagination"], source: "api-docs" });

收益。 Context7 React 文档 5.9 KB → 261 B（96%）；抓取类操作 60 KB → 40 B。

适用边界。 ①网络抓取有加固：仅允许 http/https，阻止云元数据、link-local、多播与保留地址；默认允许 loopback 与 RFC1918，CTX_FETCH_STRICT=1 可收紧。②多 URL 抓取要显式设 concurrency（1–8），I/O 密集用 4–8，CPU 密集或共享状态（端口、锁文件、同仓库写入）保持 1；gh 调用封顶 4 以免触发限流。

场景四：多平台团队统一上下文策略

业务痛点。 团队里有人用 Claude Code、有人用 Copilot、有人用 Cursor，同一批材料被重复读取，上下文边界各不相同。

做法。 各平台按 hook 能力分别接入，ctx stats 做统一验收。

npm install -g context-mode
context-mode doctor          # 诊断
# 会话内输入 ctx stats 查看知识库大小、命中情况与主要来源

收益。 覆盖 17 个平台；有 hook 平台约省 98%，无 hook 平台约省 60%。

适用边界。 ①验收不要只看「安装成功」——要看 context-mode doctor 与 ctx stats 是否响应；README 明确说明 hook 版本过旧时会 fail open（工具不被阻断，但路由与捕获可能没生效）。②Zed 与 Antigravity IDE 无 hook，只能手动复制路由文件。③平台适配是持续维护负担——项目历史里出现过「OpenClaw 安装看起来健康、但 Agent 访问不到自己的工具」这类修复。

场景五（不建议）：需要完整原文的任务

①代码编辑——要安全改代码就必须读到相关代码原文，压缩只会增加往返；②合规审计与取证——需要逐字证据链时，任何有损摘要都是风险；③小输出任务——一次 health check 的极小响应不需要沙箱，套上路由规则只增加开销而无收益（这正是维护者在 HN 上承认并移除的「过度激进拦截」）；④一次性问答——只是让聊天机器人解释一段代码的人，这个工具会显得过重。

六、快速上手

/plugin marketplace add mksglu/claude-context-mode      # 路径 A：插件市场（推荐，含自动路由）
/plugin install context-mode@claude-context-mode

claude mcp add context-mode -- npx -y context-mode      # 路径 B：MCP-only（11 工具，无自动路由）

npm install -g context-mode                             # 路径 C：全局安装（Gemini CLI / Copilot / Cursor）
context-mode doctor
context-mode hook gemini-cli beforetool                 # 各平台 hook 子命令示例

最小验收清单：① context-mode doctor 正常返回；② 会话内 ctx stats 能响应；③ 故意跑一次大输出命令，确认它被路由进沙箱而不是直接入上下文。三条都过，才算真正生效。

七、横向对比

维度	Context Mode	Cloudflare Code Mode	直接截断（rtk 类）	自研磁盘交接	向量 RAG
打的一侧	工具输出	工具定义	工具输出	工具输出	检索侧
压缩方式	沙箱 + 索引，确定性	schema 压缩	有损截断	产物落盘、只传路径	嵌入 + 相似度
可检索性	强（FTS5 全文）	不适用	无	需自建	强（语义）
是否需 LLM	否（零调用）	否	否	否	是（嵌入）
会话连续性	有（快照 + 事件库）	无	无	视实现	无
平台覆盖	17 个（hook 能力不一）	平台内建	平台内建	自建	不限
许可	ELv2（禁止托管服务化）	不适用	各异	自建	各异
主要代价	过早过滤风险、平台适配维护	只解决入口侧	信息不可恢复	开发量最大	成本与不确定性

读法：Context Mode 在「确定性 + 可检索 + 会话连续性」三项上同时占优，代价是引入了 MCP server、hooks、SQLite 三个新故障点，且许可不是宽松型。如果你的平台没有 hook，收益会从 98% 掉到 60% 左右——这时磁盘交接可能反而是更划算的选择。

八、局限、风险与社区观察

第一，98% 是自报数字，没有独立复现。 官方基准覆盖 11–21 个场景，全部由作者自行测量。第三方评论明确指出「这些数字没有被独立基准验证过」。更关键的是方法学问题：benchmark 假设模型总能写出正确的抽取代码，但实践中并非如此。

第二，过早过滤是这套设计的内生风险。 Agent 必须在完全理解输出含义之前决定怎么处理它。如果脚本抽错了字段，返回的摘要看起来完整，却排除了决定性证据。原文虽然留在索引里，但Agent 必须先意识到「缺了什么」才会去重查——一个自信而不完整的摘要恰恰会阻止这种意识。

第三，检索质量受限于词汇匹配。 FTS5 + BM25 擅长精确匹配、不擅长语义。你记得某个决策的意思、却记不住当时用词时，检索会落空。

第四，本地数据集中是新的安全面。 工具输出里可能有源码、被误打进日志的凭据、客户记录、内部工单。搬进 SQLite 并不会降低敏感度。 团队需要就存储路径、访问权限、删除、保留期、备份与事件响应给出明确答案。项目提供了 ctx_purge，并声称不要求继续时会删除旧会话数据，但这些控制仍需在每个客户端环境里实测。MCP 的 tool_input 在持久化前会脱敏 authorization / token / password / api_key / cookie 等字段，存储目录可用 CONTEXT_MODE_DIR 指定。

第五，集成漂移与运行时复杂度。 各客户端 hook 名称、配置文件、工具前缀、压缩行为都不同，一个客户端升级就可能改掉路由行为或让 sidecar 消失。运行时上，原生 SQLite 绑定、Node.js 版本要求、沙箱运行时、hook 文件、插件缓存叠加，故障点明显增多——当前要求 Node.js ≥ 22.5。

第六，许可与营销边界。 ELv2 禁止把本软件作为托管或管理服务提供给第三方，也不得移除或绕过许可密钥功能。若计划在其上构建商业产品，必须逐条读许可。另需注意：多篇中文解读把许可写成 MIT、把「12 种语言」写成 11 或 10 种，均以仓库 LICENSE 与 package.json 为准。 另外 README 里列出了若干知名公司的徽章（标注为「used across teams」），这些徽章并不链接到相关组织的确认，不应视为客户背书——公开热度可以支撑一次评估，但不能替代安全审查、兼容性测试、性能测量与持续内部使用的证据。

第七，社区观察。 Hacker News 讨论里，支持者欣赏「完整结果保持可检索、只把更小输出还给模型」；批评者质疑模型能否在见数据前写对抽取代码，也有人认为子智能体或平台原生截断能解决同类问题。维护者承认了「拦截过于激进」并移除了该行为——这既显示适应能力，也暴露了产品核心的调参难题：上下文控制只有在系统能预测「哪些输出大、重复、可复原」时才最有效。

九、小结与行动建议

Context Mode 的价值不在那 98%，而在它把「上下文问题的另一半」变成了一个可安装的工程件：沙箱拦住输出，代码代替阅读，索引兜住记忆。 它证明了出口侧是可以被工程化治理的，而且是确定性的、零 LLM 调用的——这一点比压缩率更有长期意义。

先用最小验收清单确认它真的生效。 context-mode doctor + ctx stats + 一次大输出的路由验证，三条都过再谈收益。不要只看「安装成功」四个字——hook 版本过旧时它会 fail open，工具不阻断但路由可能没生效。
只在「大数据、小答案」的任务上启用。 修 CI、补测试、处理 PR、排查构建失败、跑 benchmark、分析多文件改动、迁移依赖版本、让助手在已有仓库连续工作超过半小时——这些是它的主场。代码编辑、合规取证、一次性问答，不要用。
为有损压缩设一条红线。 如果团队有依赖逐字证据的流程（指纹、审计、可复现报告），明确把这类检查排除在 ctx_execute_file 之外，或改用保真的 ctx_index + ctx_search 路径（官方口径下这类只有 50–93%，但可复现）。
把本地索引当成敏感数据资产来管。 明确存储路径（CONTEXT_MODE_DIR）、权限、保留期与清除流程（ctx_purge），在无 --continue 即删旧会话这一默认行为上对齐团队预期。
选型前先读 LICENSE。 ELv2 不是宽松许可，禁止把本软件作为托管/管理服务提供给第三方。若计划在其上构建商业产品，需逐条评估。

最后一个判断：2026 年编码智能体的竞争，正在从「模型多聪明」转向「工具环境多干净」。 Context Mode 不是这个问题的终局答案——它甚至可能被平台原生能力（子智能体、内建截断、原生沙箱）逐步吸收。但它把「工具输出必须被治理」这件事变成了默认预期，而这正是它真正的贡献。

资料来源（均抓取于 2026-10-22）：GitHub Trending daily/weekly 榜单与 GitHub REST API（mksglu/context-mode，★31,819 / 2,194 fork / 356 open issues）；仓库 README.md（94,434 字符）、LICENSE（Elastic License 2.0）、package.json（v1.0.169）、BENCHMARK.md、configs/cursor/context-mode.mdc；Releases API（v1.0.160–v1.0.169）；npm registry（周下载 14,259 / 月下载 97,779）；Contributors API（mksglu 1,372 commits）。第三方评估与讨论：DEV Community 的 MCP 输出沙箱评估、heatdrop.ai 特稿（2026-10-17）、Kanevry/session-orchestrator 的 ADR-0004、Hacker News 讨论（约 570 分、250+ 评论，含维护者回应）、remio.ai 六类风险分析、YOMXXX 速评及多篇中文技术解读。厂商自测数据已标注来源与样本量；第三方指出「未独立复现」与「有损摘要破坏指纹契约」等保留意见已并列展示；第三方转述与仓库事实不一致处（许可、语言数量）已按仓库为准更正。