Context Mode
理解 Context Mode：缩小工具响应、保留可检索证据，以及真正的边界
理解 Context Mode 把什么移出对话、检索与压缩有何不同，以及为什么必须结合任务正确率评价上下文节省。
你将学会
- Context Mode 选择证据，不会扩展模型窗口。
- 临时处理与持久索引解决不同需求。
- 同时检查任务准确性与响应大小。
开始前需要
- 基础 JSON 与 MCP 概念
- 隔离测试客户端和虚构数据
解释本章真实实现边界，并用明确的证据样例核验。
先看结论
- Context Mode 选择证据，不会扩展模型窗口。
- 临时处理与持久索引解决不同需求。
- 同时检查任务准确性与响应大小。
保留证据，选择进入模型的内容
Context Mode 是面向编程助手的 MCP 集成。它的核心思路是在对话之外处理或索引大量工具材料，再返回较小的答案或选中的证据。它并没有扩展模型的上下文窗口。响应变短也不能证明助手仍然掌握完成任务所需的全部事实：下一个问题可能还需要一次检索。
这里应区分两种工作流。执行工具可以根据临时输入计算答案，而 ctx_index 会建立供反复提问使用的可检索内容。所查服务器源码明确建议一次性日志优先走执行而不是持久索引。选择依据应是后续复用和保留要求，而不仅是文件大小。索引敏感文本本身就是存储决策，即使当前工具响应很小。
把有价值的主张与普遍保证分开
README 宣传较大的上下文缩减，并举出原始输入 315 KB、进入上下文约 5.4 KB 的例子。这是项目给出的样例，不是我们的实测，也不是对 token 缩减的保证。字节、模型 token、计费输入与正确答案是不同指标。如果响应字节减少了，却漏掉罕见错误码，对读者的排障任务可能反而更差。
合适的首次评估应使用包含已知事实的虚构材料，分别询问普通事实、罕见标识符和不存在的内容。核对检索证据，而不只是模型自信的总结；修改来源后再重复一次。这样才能看出它是否支持持续调查，而不只是返回一个简短的首次响应。
明确集成与许可边界
工具是否可用、是否自动路由，以及会话连续性，都取决于宿主集成。服务器出现在 MCP 工具列表中时，宿主仍可能把普通工具输出直接送入对话。因此部署章节分别验证注册和路由。本系列检查的是固定源码提交，不宣称安装了所有支持的宿主，也没有复现上游性能演示。
所查包的许可标识为 Elastic-2.0，LICENSE 包含与提供托管或代管服务有关的限制。这是源码可获取的软件，不能笼统承诺可按宽松许可任意复用。它可在本项目发现栏目中介绍，但必须显著说明这个区别。应针对拟议用途阅读实际许可，并在商业服务决策前获取适当意见。
实施步骤
- 1
选取包含三个已知事实的无敏感文档。
- 2
判断反复检索是否值得持久保存。
- 3
先对照原文核验证据，再评价节省。
可复制示例
{
"task": "找回发布决定",
"source": "虚构样例",
"requiredFacts": [
"发布标签",
"超时时间",
"回滚规则"
],
"correctFacts": null,
"responseBytes": null
}常见问题
这是对整个对话的无损压缩吗？
不是。证据可以保存在外部，但只有选中的结果进入上下文。助手实际看到哪些事实取决于检索质量。
建立 MCP 连接就启用所有宿主功能了吗？
没有。工具注册、钩子、路由和连续性是独立能力，需要按宿主分别检查。
资料来源
- README.md来源核查 2026-09-07
- package.json来源核查 2026-09-07
- LICENSE来源核查 2026-09-07
- src/store.ts来源核查 2026-09-07
- src/search/unified.ts来源核查 2026-09-07
- src/server.ts来源核查 2026-09-07
- src/executor.ts来源核查 2026-09-07
- src/security.ts来源核查 2026-09-07
- src/session/purge.ts来源核查 2026-09-07
- tests/store-bytecap.test.ts来源核查 2026-09-07