在 AI 编程助手的世界里，有一个被严重低估的工程难题：工具输出的上下文膨胀。当 Claude Code、Cursor 或 Copilot 执行一个简单的 gh issue list 命令时，返回的 JSON 数据可能高达 59KB，约 15,000 个 token。这 15,000 个 token 不会只出现一次 —— 在后续的每一个对话轮次中，它们都会被重新发送给大语言模型。五十轮对话后，单这一个命令就消耗了 75 万个输入 token。这就是 context-mode 要解决的核心问题：通过输出沙箱化实现上下文窗口的极致优化。
上下文膨胀的量化模型
理解问题的严重性需要量化视角。以一个典型的开发会话为例，AI 代理在 20 次工具调用中平均每次产生 30KB 输出。这意味着会话中堆积了 600KB 的工具输出数据。如果对话持续 50 轮，这些数据会被重复发送 50 次，总计消耗 30MB 的输入 token。按照当前主流 API 的计价方式，这相当于每次会话仅在工具输出上就烧掉数美元。更糟糕的是，当上下文窗口接近满载时，代理会触发压缩机制，总结并丢弃之前的对话内容。这导致代理 “失忆”，忘记它曾经读取过的文件、做过的决策、遇到过的错误。实测数据显示，在 32K token 之后，11 个测试模型中有 10 个出现了决策准确率下降 50% 的情况。开发者不得不反复向模型解释代码库，每次重置后平均浪费 15 分钟重新建立上下文。对于一个 50 人的团队来说，如果使用频繁失忆的代理，每年会在重新解释上下文上烧掉 6 万美元。
五点拦截架构：Sandbox 的技术实现
context-mode 采用了在 MCP 服务器层面的五点拦截架构，在工具调用的生命周期中插入干预点。第一个拦截点是 PreToolUse，发生在工具调用之前。系统会检查该调用是否会产生大量输出，或者是否属于危险命令。curl、wget 以及内联 HTTP 请求会被直接拦截并重定向到沙箱执行。第二个拦截点是 PostToolUse，捕获工具执行后的结果。这里是真正的魔法发生的地方：大输出被写入本地 FTS5 全文搜索数据库，附带 BM25 排名算法，仅有摘要进入对话上下文。第三个拦截点是 SessionStart，负责在会话恢复时注入之前保存的状态快照，让代理能够 “记得” 上一次对话的内容。第四个拦截点是 PreCompact，在上下文压缩发生之前主动构建快照，保存所有关键决策和文件操作轨迹。第五个拦截点是 UserPromptSubmit，追踪用户的意图变化和修正历史。
98% 压缩率的实测数据
官方的测试数据展示了令人印象深刻的压缩效果。在 Playwright 测试场景中，56.2KB 的输出被压缩至 299 字节，压缩率达到 99.5%。GitHub Issues 查询场景中，58.9KB 压缩至 1.1KB，压缩率 98%。Access Logs 分析场景中，45.1KB 压缩至 155 字节，压缩率 99.7%。完整会话测试显示，315KB 的总输出被压缩至 5.4KB，压缩率 98%。换算成 token 成本：没有 context-mode 的情况下，20 次工具调用产生 600KB 数据，50 轮对话累计发送 30MB。有 context-mode 时，同样 20 次调用只产生 20KB 数据，50 轮对话累计仅发送 1MB。相同的工作量，30 倍的成本差异。
工程化配置参数
要在自己的项目中部署 context-mode，需要关注以下几个核心配置参数。首先是输出大小阈值，默认策略是对超过 10KB 的工具输出进行拦截和沙箱化。这个阈值可以通过环境变量 CONTEXT_MODE_OUTPUT_THRESHOLD 调整，建议范围在 5KB 到 20KB 之间，根据对话长度和模型上下文窗口大小权衡。其次是数据库路径配置，默认使用本地的 SQLite 数据库存储索引数据，通过 CONTEXT_MODE_DB_PATH 指定自定义路径，建议放在高速 SSD 上以获得更好的查询性能。第三是危险命令拦截列表，系统默认拦截 curl、wget、rm -rf 等高风险操作，可在配置中通过 CONTEXT_MODE_BLOCKED_COMMANDS 扩展黑名单。第四是环境变量过滤，60 多个包含敏感信息的环境变量会被自动从沙箱执行中剥离，包括 API_KEY、TOKEN、SECRET 等关键词匹配的环境变量。
Think in Code 范式：输入侧的优化
context-mode 的 1.0.64 版本引入了一个根本性的范式转变，称为 “Think in Code”。这源于一个观察：当代理需要分析 47 个文件时，它会逐个调用 Read () 读取每个文件，每个文件都进入上下文并永远留在那里。47 个文件可能消耗 700KB 的上下文空间。Think in Code 的解决方案是让代理写一段脚本在沙箱中执行，只返回执行结果。一个典型的场景是统计 src 目录下所有 TypeScript 文件的代码行数。传统做法：47 次 Read () 调用，700KB 上下文占用。优化做法：单次 ctx_execute () 调用，执行一个 Node.js 脚本遍历目录并统计行数，返回结果仅 3.6KB。200 倍的压缩率。这个范式的核心洞察是：与其让模型在上下文中处理数据，不如让模型生成处理数据的代码，让 CPU 执行它，让模型只读取结果。
连续性保障：上下文压缩后的恢复
传统的 AI 代理在上下文压缩时会丢失一切。context-mode 通过 SessionDB 解决了这个 Continuity 问题。系统追踪 26 种不同类型的事件，包括文件操作、Git 操作、错误与修复、决策轨迹、环境变量变化等等。每当 PreCompact 触发时，系统会构建一个包含所有这些事件快照的结构化记录。下一次 SessionStart 时，这个快照会被完整恢复，代理能够无缝衔接上一次的思考过程。开发者不再需要每次都重新解释代码库的结构、项目的构建方式、本次会话的目标。
安全性设计
作为一款处理代码和敏感数据的工具，安全性是核心考量。context-mode 采用了多层防御策略：危险命令在 PreToolUse 阶段就被拦截，curl、wget 和递归删除命令会被阻止或重定向。环境变量黑名单覆盖超过 60 个常见的密钥和令牌关键词，确保 API 凭证不会意外泄露到沙箱进程中。整个系统在本地运行，零网络传输，没有任何遥测或数据外发。代码采用 Elastic License 2.0 开源许可，用户可以审计每一行代码，验证安全声明。
context-mode 的实践验证了一个工程原理：在 AI 代理系统中，输出侧的上下文管理是和模型能力同等重要的工程挑战。通过在工具层引入沙箱拦截、本地索引和增量摘要机制，可以将上下文占用降低两个数量级，同时保持代理的决策质量不受影响。这不是模型架构的创新，而是系统工程的成功。
资料来源：context-mode 官方文档（https://context-mode.pages.dev）