KiloCode 集成 context-modeMCP 工具路由规则与上下文防洪水实战指南【免费下载链接】context-modeContext window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP hooks.项目地址: https://gitcode.com/GitHub_Trending/cl/context-modecontext-mode 是一套面向 AI 编码 Agent 的上下文窗口优化方案通过 MCP 服务器 平台钩子hooks的组合将工具输出沙箱化官方数据可达 98% 的上下文缩减并持久化会话记忆。在 KiloCodeKilo这一类采用 TypeScript 插件范式的宿主上本仓库在configs/kilo/AGENTS.md中提供了一份强制路由规则MANDATORY routing rules用于保护上下文窗口不被洪水式输出淹没。读完本文你将掌握Kilo 下如何配置 context-mode 插件、ctx_*MCP 工具的正确选型顺序、如何用 Think in Code 哲学把读原始数据变成写代码算答案以及如何规避 curl/wget 等被拦截的操作。一、context-mode 与 Kilo 的集成形态1.1 Kilo 在平台矩阵中的定位根据仓库的 平台支持矩阵context-mode 目前支持 17 个客户端平台 OpenClaw 网关横跨三种钩子范式范式平台JSON stdin/stdout 钩子Claude Code、Gemini CLI、VS Code Copilot、JetBrains Copilot、GitHub Copilot CLI、Cursor、Codex CLI、Qwen Code、Kimi Code、Antigravity CLIagy、KiroTS 插件OpenCode、KiloCode、OpenClaw仅 MCPAntigravity、Zed、Pi、OMPKiloCode 属于TS 插件范式与 OpenCode 走同一条插件路径通过kilo.json的plugin数组注册钩子等价物为tool.execute.before/tool.execute.after对应其他平台的 PreToolUse / PostToolUseexperimental.session.compacting对应 PreCompact。上下文记忆通过~/.config/kilo/context-mode/sessions/持久化MCP 工具以nativectx_*插件工具形式暴露而非mcp__server__tool命名。1.2 配置文件kilo.json仓库中的 configs/kilo/kilo.json 是最简可用的插件声明{ $schema: https://app.kilo.ai/config.json, plugin: [ context-mode ] }要点$schema指向 Kilo 官方配置 schema便于编辑器校验plugin数组列出要加载的插件这里只需一项context-mode前置条件是全局安装npm install -g context-modeKiloCode 与 OpenCode、OpenClaw 一样通过 npm 全局分发插件MCP 服务器命令为context-mode。二、AGENTS.mdKilo 下的强制路由规则configs/kilo/AGENTS.md 是本文的核心对象它在 Kilo 项目中充当 Agent 的路由宪法。其标题即点明定位MANDATORY routing rules强制路由规则第一段解释了存在理由context-mode MCP tools available. Rules protect context window from flooding.One unrouted command dumps 56 KB into context.一条未经路由的裸命令会把 56 KB 塞进上下文——这正是整个路由体系要解决的问题Agent 的上下文窗口是有限推理资源未经沙箱化的工具输出会直接吞掉推理容量。这也是项目描述的工具输出沙箱化98% 缩减要治理的场景。2.1 核心哲学Think in CodeAGENTS.md 的第一条强制规则是Think in CodeAnalyze/count/filter/compare/search/parse/transform data:write codeviacontext-mode_ctx_execute(language, code),console.log()only the answer. Do NOT read raw data into context. PROGRAM the analysis, not COMPUTE it.翻译成实操语言需要分析/计数/过滤/比较/搜索/解析/转换数据时不要Read原始数据进上下文而是写代码去算只把答案console.log出来。约束包括纯 JavaScript只用 Node.js 内置模块fs、path、child_process必须try/catch处理null/undefined一句脚本可以替代十次工具调用。这一哲学在服务端源码中有直接印证。查看 src/server.ts 中ctx_execute的官方描述The bytes your code processes never enter your conversation memory; only what you console.log() does. Reading a 700 KB log directly means 700 KB of your remaining reasoning capacity gets spent on raw bytes. Running code over that same log in this sandbox and printing a 3 KB summary leaves you with 697 KB of capacity for the actual work.配套的示例是分析 47 个源文件而一个都不读ctx_execute(language: javascript, code: const fs require(fs); const files fs.readdirSync(src).filter(f f.endsWith(.ts)); files.forEach(f { const lines fs.readFileSync(src/f,utf8).split(\\n).length; console.log(f : lines lines); }); ) // 47 files analyzed, 15,314 LoC summarized — output ~3.6 KB instead of 47 Read() calls ~700 KB.三、被拦截操作BLOCKED与正确替代AGENTS.md 明确列出三类不要尝试的操作拦截发生在钩子/防火墙层重试只会浪费时间3.1 curl / wget —— BLOCKEDShell 层的curl/wget会被拦截。正确替代是context-mode_ctx_fetch_and_index(url, source) context-mode_ctx_execute(language: javascript, code: const r await fetch(...))3.2 Inline HTTP —— BLOCKED代码里直接发起 HTTP 也会被拦截匹配模式包括fetch(http、requests.get(、requests.post(、http.get(、http.request(。替代方式是ctx_execute——只有 stdout 会进入上下文。3.3 直接 Web 抓取 —— BLOCKED正确的两步走context-mode_ctx_fetch_and_index(url, source) context-mode_ctx_search(queries)即先抓取并索引再搜索原始 HTML 永不进入上下文。四、被重定向的操作REDIRECTED与沙箱4.1 Shell输出超过 20 行Shell 只允许用于git、mkdir、rm、mv、cd、ls、npm install、pip install。其余场景改用ctx_batch_execute或ctx_execute只有在代码匹配宿主 shell 时才用language: shell。4.2 文件读取用于分析规则区分意图读取为了编辑→ 正常读取读取为了分析/探索/总结→ 用context-mode_ctx_execute_file(path, language, code)。4.3 grep / 搜索结果量大在沙箱里用ctx_execute(language: javascript, code: ...)做可移植的过滤与计数而不是把大结果集拉进上下文。五、工具选型顺序Tool selectionAGENTS.md 给出 0–5 的决策链这是全文最可操作的清单MEMORY记忆context-mode_ctx_search(sort: timeline)—— 恢复会话后先查历史上下文再问用户GATHER收集context-mode_ctx_batch_execute(commands, queries)—— 一次调用运行全部命令、自动索引并返回搜索结果一次调用替代 30 次每条命令形如{label: header, command: ...}FOLLOW-UP追问context-mode_ctx_search(queries: [q1, q2, ...])—— 所有问题组成数组一次调用默认相关性模式PROCESSING处理context-mode_ctx_execute(language, code)/context-mode_ctx_execute_file(path, language, code)—— 沙箱执行只有 stdout 进上下文WEB网页context-mode_ctx_fetch_and_index(url, source)后接context-mode_ctx_search(queries)INDEX索引context-mode_ctx_index(content, source)—— 存入 FTS5 供后续搜索。其中 GATHER 的一次调用替代 30 次在实现层有直接对应ctx_batch_execute的批量运行器runBatchCommands位于 src/server.ts支持串行共享超时预算、超时级联跳过与并行委托给runPool原语具备在途上限、异常隔离与顺序保持两条路径。六、并行 I/O 批次与并发度选择对多 URL 抓取或多 API 调用AGENTS.md 要求始终携带concurrency: N1–8context-mode_ctx_batch_execute(commands: [3 network commands], concurrency: 5)—— gh、curl、dig、docker inspect、多云查询context-mode_ctx_fetch_and_index(requests: [{url, source}, ...], concurrency: 5)—— 多 URL 批量抓取。并发度经验法则I/O 密集网络调用、API 查询→ 用concurrency 4–8CPU 密集npm test、build、lint或共享状态端口、锁文件、同一仓库写入→ 保持concurrency 1GitHub API 限流gh调用封顶4。从源码看并发语义由 src/runPool.ts 承载runBatchCommands的并行路径按concurrency约束在途任务数同时通过Promise.allSettled语义保证单个命令的异常不会拖垮整批。七、输出与会话延续规范写产物到文件绝不内联返回文件路径 一行描述给context-mode_ctx_search(source: label)提供有描述性的来源标签会话延续Skills、角色、决策在整个会话期间保持不因对话变长而丢弃。八、记忆与恢复先搜索再提问会话历史是持久化且可搜索的。恢复会话时先搜索再问用户需求命令我们之前决定了什么context-mode_ctx_search(queries: [decision], source: decision, sort: timeline)存在哪些约束context-mode_ctx_search(queries: [constraint], source: constraint)铁律不要问我们刚才在做什么——先搜索。如果搜索返回 0 条结果按全新会话处理。这套机制在实现层由 src/search/unified.ts 的searchAllSources支撑sortrelevance默认只做 ContentStore 的 BM25 相关性搜索sorttimeline则按时间线合并三个来源——当前会话的 ContentStore、prior-session的 SessionDB 事件、以及 auto-memory 的跨会话记忆最后统一时间戳格式并按时间排序单个来源出错只记日志、仍返回部分结果。搜索工具的入参 schemaqueries、limit、source、contentType、sort定义在 src/search/ctx-search-schema.ts其中queries支持把裸字符串自动提升为单元素数组修复 OpenCode 原生插件路径下部分供应商传queries: search term字符串的问题。值得注意的防滥用设计ctx_search带渐进式节流flood guard见 src/search/flood-guard.ts。它按每个 agent 上下文分桶计数滚动窗口内超过softCapAfter次则每查询只返回 1 条结果超过blockAfter次则硬性拒绝从而既阻止单一 actor 刷屏又不误伤 Claude Code Task/Workflow 并行多子代理的合法扇出。这与 AGENTS.md 要求所有问题一次调用、批量查询的训令相互配合。九、ctx 命令速查AGENTS.md 的ctx commands一节将自然语言命令映射到 MCP 工具命令动作ctx stats调用statsMCP 工具原样展示完整输出ctx doctor调用doctorMCP 工具执行返回的 shell 命令以清单形式展示ctx upgrade调用upgradeMCP 工具执行返回的 shell 命令以清单形式展示ctx purge调用purgeMCP 工具confirm: true清空知识库前会警告这些命令的 CLI 侧实现位于 src/cli.tscontext-mode doctor诊断运行时问题、钩子、FTS5 与版本context-mode upgrade修复钩子、权限与设置并支持--platform id指定目标平台避免升级走错适配器。purge是知识库唯一的重置机制会永久删除所有已索引内容。关于会话生命周期有一条重要约定/clear或/compact之后知识库与会话统计仍然保留只有ctx purge才会彻底清空、重新开始。十、常见坑与最佳实践小结别裸跑curl/wget/内联 HTTP——它们已被拦截直接把请求交给ctx_fetch_and_index或ctx_execute能写代码就算别读原文件——分析型读取一律走ctx_execute/ctx_execute_file只有 stdout 进上下文批量问题一次调用——queries传数组配合 flood guard 的设计意图并发度按负载类型选——I/O 密集给 4–8CPU 密集或共享状态给 1gh封顶 4恢复会话先搜索——ctx_search(sort: timeline)优于问用户我们进行到哪了产物写文件——返回路径 一行描述别把大输出内联进对话。结合 平台支持矩阵 中的 KiloCode 行可以确认Kilo 的钩子能力为tool.execute.before/tool.execute.after可改参数、可抛异常阻断工具、experimental.session.compacting对应上下文压缩前快照而会话 ID 字段为sessionIDcamelCase 大写 ID项目目录通过插件初始化时的ctx.directory获取。理解这些差异能帮助你在 Kilo 下正确预期 context-mode 的路由行为边界。十一、深入阅读路由规则本体configs/kilo/AGENTS.md插件声明configs/kilo/kilo.json平台能力矩阵与各平台细节docs/platform-support.md工具实现ctx_execute/ctx_batch_execute/ctx_index等注册于 src/server.tsctx_search多源合并见 src/search/unified.ts输入 schema 见 src/search/ctx-search-schema.ts防刷屏节流见 src/search/flood-guard.tsCLI 工具doctor/upgrade 等src/cli.ts【免费下载链接】context-modeContext window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP hooks.项目地址: https://gitcode.com/GitHub_Trending/cl/context-mode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KiloCode 集成 context-mode：MCP 工具路由规则与上下文防洪水实战指南
KiloCode 集成 context-modeMCP 工具路由规则与上下文防洪水实战指南【免费下载链接】context-modeContext window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP hooks.项目地址: https://gitcode.com/GitHub_Trending/cl/context-modecontext-mode 是一套面向 AI 编码 Agent 的上下文窗口优化方案通过 MCP 服务器 平台钩子hooks的组合将工具输出沙箱化官方数据可达 98% 的上下文缩减并持久化会话记忆。在 KiloCodeKilo这一类采用 TypeScript 插件范式的宿主上本仓库在configs/kilo/AGENTS.md中提供了一份强制路由规则MANDATORY routing rules用于保护上下文窗口不被洪水式输出淹没。读完本文你将掌握Kilo 下如何配置 context-mode 插件、ctx_*MCP 工具的正确选型顺序、如何用 Think in Code 哲学把读原始数据变成写代码算答案以及如何规避 curl/wget 等被拦截的操作。一、context-mode 与 Kilo 的集成形态1.1 Kilo 在平台矩阵中的定位根据仓库的 平台支持矩阵context-mode 目前支持 17 个客户端平台 OpenClaw 网关横跨三种钩子范式范式平台JSON stdin/stdout 钩子Claude Code、Gemini CLI、VS Code Copilot、JetBrains Copilot、GitHub Copilot CLI、Cursor、Codex CLI、Qwen Code、Kimi Code、Antigravity CLIagy、KiroTS 插件OpenCode、KiloCode、OpenClaw仅 MCPAntigravity、Zed、Pi、OMPKiloCode 属于TS 插件范式与 OpenCode 走同一条插件路径通过kilo.json的plugin数组注册钩子等价物为tool.execute.before/tool.execute.after对应其他平台的 PreToolUse / PostToolUseexperimental.session.compacting对应 PreCompact。上下文记忆通过~/.config/kilo/context-mode/sessions/持久化MCP 工具以nativectx_*插件工具形式暴露而非mcp__server__tool命名。1.2 配置文件kilo.json仓库中的 configs/kilo/kilo.json 是最简可用的插件声明{ $schema: https://app.kilo.ai/config.json, plugin: [ context-mode ] }要点$schema指向 Kilo 官方配置 schema便于编辑器校验plugin数组列出要加载的插件这里只需一项context-mode前置条件是全局安装npm install -g context-modeKiloCode 与 OpenCode、OpenClaw 一样通过 npm 全局分发插件MCP 服务器命令为context-mode。二、AGENTS.mdKilo 下的强制路由规则configs/kilo/AGENTS.md 是本文的核心对象它在 Kilo 项目中充当 Agent 的路由宪法。其标题即点明定位MANDATORY routing rules强制路由规则第一段解释了存在理由context-mode MCP tools available. Rules protect context window from flooding.One unrouted command dumps 56 KB into context.一条未经路由的裸命令会把 56 KB 塞进上下文——这正是整个路由体系要解决的问题Agent 的上下文窗口是有限推理资源未经沙箱化的工具输出会直接吞掉推理容量。这也是项目描述的工具输出沙箱化98% 缩减要治理的场景。2.1 核心哲学Think in CodeAGENTS.md 的第一条强制规则是Think in CodeAnalyze/count/filter/compare/search/parse/transform data:write codeviacontext-mode_ctx_execute(language, code),console.log()only the answer. Do NOT read raw data into context. PROGRAM the analysis, not COMPUTE it.翻译成实操语言需要分析/计数/过滤/比较/搜索/解析/转换数据时不要Read原始数据进上下文而是写代码去算只把答案console.log出来。约束包括纯 JavaScript只用 Node.js 内置模块fs、path、child_process必须try/catch处理null/undefined一句脚本可以替代十次工具调用。这一哲学在服务端源码中有直接印证。查看 src/server.ts 中ctx_execute的官方描述The bytes your code processes never enter your conversation memory; only what you console.log() does. Reading a 700 KB log directly means 700 KB of your remaining reasoning capacity gets spent on raw bytes. Running code over that same log in this sandbox and printing a 3 KB summary leaves you with 697 KB of capacity for the actual work.配套的示例是分析 47 个源文件而一个都不读ctx_execute(language: javascript, code: const fs require(fs); const files fs.readdirSync(src).filter(f f.endsWith(.ts)); files.forEach(f { const lines fs.readFileSync(src/f,utf8).split(\\n).length; console.log(f : lines lines); }); ) // 47 files analyzed, 15,314 LoC summarized — output ~3.6 KB instead of 47 Read() calls ~700 KB.三、被拦截操作BLOCKED与正确替代AGENTS.md 明确列出三类不要尝试的操作拦截发生在钩子/防火墙层重试只会浪费时间3.1 curl / wget —— BLOCKEDShell 层的curl/wget会被拦截。正确替代是context-mode_ctx_fetch_and_index(url, source) context-mode_ctx_execute(language: javascript, code: const r await fetch(...))3.2 Inline HTTP —— BLOCKED代码里直接发起 HTTP 也会被拦截匹配模式包括fetch(http、requests.get(、requests.post(、http.get(、http.request(。替代方式是ctx_execute——只有 stdout 会进入上下文。3.3 直接 Web 抓取 —— BLOCKED正确的两步走context-mode_ctx_fetch_and_index(url, source) context-mode_ctx_search(queries)即先抓取并索引再搜索原始 HTML 永不进入上下文。四、被重定向的操作REDIRECTED与沙箱4.1 Shell输出超过 20 行Shell 只允许用于git、mkdir、rm、mv、cd、ls、npm install、pip install。其余场景改用ctx_batch_execute或ctx_execute只有在代码匹配宿主 shell 时才用language: shell。4.2 文件读取用于分析规则区分意图读取为了编辑→ 正常读取读取为了分析/探索/总结→ 用context-mode_ctx_execute_file(path, language, code)。4.3 grep / 搜索结果量大在沙箱里用ctx_execute(language: javascript, code: ...)做可移植的过滤与计数而不是把大结果集拉进上下文。五、工具选型顺序Tool selectionAGENTS.md 给出 0–5 的决策链这是全文最可操作的清单MEMORY记忆context-mode_ctx_search(sort: timeline)—— 恢复会话后先查历史上下文再问用户GATHER收集context-mode_ctx_batch_execute(commands, queries)—— 一次调用运行全部命令、自动索引并返回搜索结果一次调用替代 30 次每条命令形如{label: header, command: ...}FOLLOW-UP追问context-mode_ctx_search(queries: [q1, q2, ...])—— 所有问题组成数组一次调用默认相关性模式PROCESSING处理context-mode_ctx_execute(language, code)/context-mode_ctx_execute_file(path, language, code)—— 沙箱执行只有 stdout 进上下文WEB网页context-mode_ctx_fetch_and_index(url, source)后接context-mode_ctx_search(queries)INDEX索引context-mode_ctx_index(content, source)—— 存入 FTS5 供后续搜索。其中 GATHER 的一次调用替代 30 次在实现层有直接对应ctx_batch_execute的批量运行器runBatchCommands位于 src/server.ts支持串行共享超时预算、超时级联跳过与并行委托给runPool原语具备在途上限、异常隔离与顺序保持两条路径。六、并行 I/O 批次与并发度选择对多 URL 抓取或多 API 调用AGENTS.md 要求始终携带concurrency: N1–8context-mode_ctx_batch_execute(commands: [3 network commands], concurrency: 5)—— gh、curl、dig、docker inspect、多云查询context-mode_ctx_fetch_and_index(requests: [{url, source}, ...], concurrency: 5)—— 多 URL 批量抓取。并发度经验法则I/O 密集网络调用、API 查询→ 用concurrency 4–8CPU 密集npm test、build、lint或共享状态端口、锁文件、同一仓库写入→ 保持concurrency 1GitHub API 限流gh调用封顶4。从源码看并发语义由 src/runPool.ts 承载runBatchCommands的并行路径按concurrency约束在途任务数同时通过Promise.allSettled语义保证单个命令的异常不会拖垮整批。七、输出与会话延续规范写产物到文件绝不内联返回文件路径 一行描述给context-mode_ctx_search(source: label)提供有描述性的来源标签会话延续Skills、角色、决策在整个会话期间保持不因对话变长而丢弃。八、记忆与恢复先搜索再提问会话历史是持久化且可搜索的。恢复会话时先搜索再问用户需求命令我们之前决定了什么context-mode_ctx_search(queries: [decision], source: decision, sort: timeline)存在哪些约束context-mode_ctx_search(queries: [constraint], source: constraint)铁律不要问我们刚才在做什么——先搜索。如果搜索返回 0 条结果按全新会话处理。这套机制在实现层由 src/search/unified.ts 的searchAllSources支撑sortrelevance默认只做 ContentStore 的 BM25 相关性搜索sorttimeline则按时间线合并三个来源——当前会话的 ContentStore、prior-session的 SessionDB 事件、以及 auto-memory 的跨会话记忆最后统一时间戳格式并按时间排序单个来源出错只记日志、仍返回部分结果。搜索工具的入参 schemaqueries、limit、source、contentType、sort定义在 src/search/ctx-search-schema.ts其中queries支持把裸字符串自动提升为单元素数组修复 OpenCode 原生插件路径下部分供应商传queries: search term字符串的问题。值得注意的防滥用设计ctx_search带渐进式节流flood guard见 src/search/flood-guard.ts。它按每个 agent 上下文分桶计数滚动窗口内超过softCapAfter次则每查询只返回 1 条结果超过blockAfter次则硬性拒绝从而既阻止单一 actor 刷屏又不误伤 Claude Code Task/Workflow 并行多子代理的合法扇出。这与 AGENTS.md 要求所有问题一次调用、批量查询的训令相互配合。九、ctx 命令速查AGENTS.md 的ctx commands一节将自然语言命令映射到 MCP 工具命令动作ctx stats调用statsMCP 工具原样展示完整输出ctx doctor调用doctorMCP 工具执行返回的 shell 命令以清单形式展示ctx upgrade调用upgradeMCP 工具执行返回的 shell 命令以清单形式展示ctx purge调用purgeMCP 工具confirm: true清空知识库前会警告这些命令的 CLI 侧实现位于 src/cli.tscontext-mode doctor诊断运行时问题、钩子、FTS5 与版本context-mode upgrade修复钩子、权限与设置并支持--platform id指定目标平台避免升级走错适配器。purge是知识库唯一的重置机制会永久删除所有已索引内容。关于会话生命周期有一条重要约定/clear或/compact之后知识库与会话统计仍然保留只有ctx purge才会彻底清空、重新开始。十、常见坑与最佳实践小结别裸跑curl/wget/内联 HTTP——它们已被拦截直接把请求交给ctx_fetch_and_index或ctx_execute能写代码就算别读原文件——分析型读取一律走ctx_execute/ctx_execute_file只有 stdout 进上下文批量问题一次调用——queries传数组配合 flood guard 的设计意图并发度按负载类型选——I/O 密集给 4–8CPU 密集或共享状态给 1gh封顶 4恢复会话先搜索——ctx_search(sort: timeline)优于问用户我们进行到哪了产物写文件——返回路径 一行描述别把大输出内联进对话。结合 平台支持矩阵 中的 KiloCode 行可以确认Kilo 的钩子能力为tool.execute.before/tool.execute.after可改参数、可抛异常阻断工具、experimental.session.compacting对应上下文压缩前快照而会话 ID 字段为sessionIDcamelCase 大写 ID项目目录通过插件初始化时的ctx.directory获取。理解这些差异能帮助你在 Kilo 下正确预期 context-mode 的路由行为边界。十一、深入阅读路由规则本体configs/kilo/AGENTS.md插件声明configs/kilo/kilo.json平台能力矩阵与各平台细节docs/platform-support.md工具实现ctx_execute/ctx_batch_execute/ctx_index等注册于 src/server.tsctx_search多源合并见 src/search/unified.ts输入 schema 见 src/search/ctx-search-schema.ts防刷屏节流见 src/search/flood-guard.tsCLI 工具doctor/upgrade 等src/cli.ts【免费下载链接】context-modeContext window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP hooks.项目地址: https://gitcode.com/GitHub_Trending/cl/context-mode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考