JavaScript/TypeScript 模式实战：用 ctx_execute 在沙箱中处理 API、JSON 与测试输出

JavaScript/TypeScript 模式实战用 ctx_execute 在沙箱中处理 API、JSON 与测试输出【免费下载链接】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 编码 Agent 的会话中上下文窗口是最宝贵的资源。context-mode 项目通过ctx_execute沙箱化工具输出项目描述中标注可将工具输出缩减约 98%让 Agent 用代码而非上下文来处理数据。本文以 patterns-javascript.md 为骨架完整继承其全部 8 个 JavaScript/TypeScript 实战模式并结合 src/server.ts 的实现与 SKILL.md 的决策规则做源码级扩充。读完你将掌握如何用原生 fetch 分析 API 响应、解析大型 JSON 配置、审计依赖、解析测试输出以及如何让每一份输出都以分析结果而非原始字节的形式进入上下文。前置条件与运行环境本文所有示例均面向ctx_execute的language: javascript运行时Node.js 运行时所有示例依赖原生fetch需要Node 18CommonJS 模块环境fs、child_process通过require引入JSON 可直接用require(./x.json)读取沙箱执行代码运行在独立子进程中console.log的输出是唯一进入上下文的通道详见下文Think-in-Code。context-mode 的ctx_execute工具在 src/server.ts 中注册支持 12 种运行时javascript、typescript、python、shell、ruby、go、rust、php、perl、r、elixir、csharp。各语言向 stdout 输出的方式不同——JS/TS 用console.logPython 用printShell 用echo——但原则一致只打印结论不倾倒原始数据。核心心智模型Think-in-Codectx_execute的工具描述中明确阐述了本项目的第一性原则见 src/server.tsThink-in-Code — the core philosophy: 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.代码处理的字节永远不会进入对话记忆只有console.log的输出会。直接读 700 KB 日志意味着你 700 KB 的推理容量被原始字节消耗在沙箱中跑代码处理同一份日志、打印 3 KB 摘要你就能省下 697 KB 容量用于真正的工作。这解释了本文件所有模式的共同形态读取 → 分析 → 只打印发现。例如分析 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.实现层面src/server.ts 会对 JS/TS 代码做闭包包装拦截http/https请求以追踪沙箱内的网络字节消耗bytesSandboxed见 src/server.ts这些字节永不进入上下文。ctx_execute 参数速查理解以下参数定义见 src/server.ts才能把模式用到实处参数类型默认值说明language枚举12 种必填运行时语言JS/TS 示例见本文codestring必填要执行的源码只打印摘要到上下文timeoutnumber (ms)由宿主 RPC 超时决定省略时不启动服务端计时器由 MCP 宿主 RPC 超时兜底长任务Gradle/Maven/SBT 构建需显式传入backgroundbooleanfalse超时后不杀进程用于 dev server / daemon返回部分输出cwdstring沙箱临时目录Shell 命令的工作目录非 Shell 语言仍从沙箱临时目录执行intentstring无你想从输出中找什么输出超过约 5KB 时自动索引进知识库只返回分节标题与预览随后用ctx_search(queries: [...])检索具体段落summary_prompt 约定patterns 文件中每个示例末尾都附有 summary_prompt注释部分还有 timeout_ms。这是本文件的元数据约定含义是这段代码执行后希望 LLM 如何总结输出。写得好坏直接决定上下文质量——anti-patterns.md 给出了具体建议具体指出需要哪些数据点数量、指标而非笼统描述请求可行动的洞察suggest fixes、identify patterns指明输出格式list as bullet points、group by category。例如本文件中的 summary_prompt: Report overall health, list any degraded services, and highlight errors就比 Summarize this 有效得多。模式一API 响应处理1.1 Fetch 并汇总 REST API// execute: Analyze API health endpoint const resp await fetch(https://api.example.com/health); const data await resp.json(); console.log( Service Health ); console.log(Status: ${data.status}); console.log(Uptime: ${data.uptime}); console.log(Timestamp: ${data.timestamp}); if (data.services) { console.log(\n Service Components ); for (const [name, info] of Object.entries(data.services)) { console.log( ${name}: ${info.status} (latency: ${info.latency_ms}ms)); } } if (data.errors data.errors.length 0) { console.log(\n Recent Errors ); data.errors.slice(0, 10).forEach(e { console.log( [${e.timestamp}] ${e.code}: ${e.message}); }); }summary_prompt: Report overall health, list any degraded services, and highlight errors要点拆解直接调用fetch这是 JS 模式优于 Shell 的核心场景。用 Bashcurl会把整份响应可能 50 KB灌进上下文见 SKILL.md 的 Anti-Patterns 一节先分析再打印不是console.log(JSON.stringify(data))而是按维度健康状态、组件延迟、近期错误组织输出主动截断slice(0, 10)限制错误数量避免海量错误列表反噬上下文。1.2 分页 API 收集// execute: Fetch all open issues from GitHub API const owner org; const repo project; let page 1; let allIssues []; while (true) { const resp await fetch( https://api.github.com/repos/${owner}/${repo}/issues?stateopenper_page100page${page}, { headers: { Accept: application/vnd.github.v3json } } ); const issues await resp.json(); if (issues.length 0) break; allIssues.push(...issues); page; } console.log(Total open issues: ${allIssues.length}\n); // Group by labels const byLabel {}; allIssues.forEach(issue { issue.labels.forEach(label { byLabel[label.name] (byLabel[label.name] || 0) 1; }); }); console.log( Issues by Label ); Object.entries(byLabel) .sort((a, b) b[1] - a[1]) .forEach(([label, count]) console.log( ${label}: ${count})); // Oldest issues console.log(\n 10 Oldest Issues ); allIssues .sort((a, b) new Date(a.created_at) - new Date(b.created_at)) .slice(0, 10) .forEach(i console.log( #${i.number} (${i.created_at.slice(0,10)}): ${i.title}));summary_prompt: Summarize issue distribution by label, highlight stale issues, suggest priorities timeout_ms: 30000这个模式展示了沙箱的完整价值分页可能拉取数百条 issue数十 KB 原始数据但经过标签聚合、时间排序后进入上下文的只有三个精炼视图总量、标签分布、最旧十条。注意两点 timeout_ms: 30000分页网络请求需要更宽裕的超时。参见 anti-patterns.md 的推荐值——单次 API 请求 15000–30000ms分页调用 30000–60000ms数据留在沙箱allIssues数组在沙箱内完成计算不会逐条进入对话。模式二JSON 数据分析2.1 分析大型 JSON 配置文件const fs require(fs); const data JSON.parse(fs.readFileSync(tsconfig.json, utf8)); console.log( TSConfig Analysis ); console.log(Target: ${data.compilerOptions?.target}); console.log(Module: ${data.compilerOptions?.module}); console.log(Strict: ${data.compilerOptions?.strict}); console.log(Paths aliases: ${Object.keys(data.compilerOptions?.paths || {}).length}); if (data.compilerOptions?.paths) { console.log(\n Path Aliases ); for (const [alias, targets] of Object.entries(data.compilerOptions.paths)) { console.log( ${alias} - ${targets.join(, )}); } } if (data.include) console.log(\nInclude: ${data.include.join(, )}); if (data.exclude) console.log(Exclude: ${data.exclude.join(, )}); if (data.references) { console.log(\nProject References: ${data.references.length}); data.references.forEach(r console.log( ${r.path})); }summary_prompt: Report compiler strictness, module system, and any unusual configuration技巧可选链?.与|| {}兜底。配置文件字段未必齐全data.compilerOptions?.paths与Object.keys(... || {}).length让脚本对缺失字段健壮避免未捕获异常导致 stderr 泄漏进上下文src/server.ts 的 RETURNS 说明警告过未捕获错误会进入 stderr可能泄漏超出预期的内容。2.2 对比两个 JSON 文件const fs require(fs); const a JSON.parse(fs.readFileSync(config.prod.json, utf8)); const b JSON.parse(fs.readFileSync(config.staging.json, utf8)); function diffObjects(obj1, obj2, path ) { const allKeys new Set([...Object.keys(obj1 || {}), ...Object.keys(obj2 || {})]); for (const key of allKeys) { const fullPath path ? ${path}.${key} : key; if (!(key in (obj1 || {}))) { console.log( ${fullPath}: ${JSON.stringify(obj2[key])}); } else if (!(key in (obj2 || {}))) { console.log(- ${fullPath}: ${JSON.stringify(obj1[key])}); } else if (typeof obj1[key] object typeof obj2[key] object) { diffObjects(obj1[key], obj2[key], fullPath); } else if (JSON.stringify(obj1[key]) ! JSON.stringify(obj2[key])) { console.log(~ ${fullPath}: ${JSON.stringify(obj1[key])} - ${JSON.stringify(obj2[key])}); } } } console.log( Config Diff: prod vs staging ); diffObjects(a, b);summary_prompt: List all configuration differences between prod and staging environments递归对比的要点三类变更符号新增键、-删除键、~值变化旧值 → 新值递归深度优先嵌套对象进入diffObjects递归fullPath用.拼接出可读的键路径值比较用JSON.stringify避免对象引用比较的陷阱。模式三package.json / 锁文件分析3.1 依赖审计const fs require(fs); const pkg JSON.parse(fs.readFileSync(package.json, utf8)); const deps Object.entries(pkg.dependencies || {}); const devDeps Object.entries(pkg.devDependencies || {}); console.log(Package: ${pkg.name}${pkg.version}); console.log(Dependencies: ${deps.length}); console.log(DevDependencies: ${devDeps.length}); // Find non-pinned versions console.log(\n Non-Pinned Dependencies ); [...deps, ...devDeps].forEach(([name, version]) { if (version.startsWith(^) || version.startsWith(~) || version *) { console.log( ${name}: ${version}); } }); // Find duplicated categories console.log(\n Scripts ); Object.entries(pkg.scripts || {}).forEach(([name, cmd]) { console.log( ${name}: ${cmd}); }); // Workspace detection if (pkg.workspaces) { console.log(\n Monorepo Workspaces ); const ws Array.isArray(pkg.workspaces) ? pkg.workspaces : pkg.workspaces.packages || []; ws.forEach(w console.log( ${w})); }summary_prompt: Report dependency health: unpinned versions, total count, any security concerns from package names这里的非锁定版本检测^、~、*开头是典型的在沙箱内做判断、只打印发现原始package.json可能只有几 KB但叠加package-lock.json后体积陡增anti-patterns.md 提到 20,000 行的 lock 文件案例逐行 Read 会浪费整个上下文。3.2 锁文件漂移检测const fs require(fs); const pkg JSON.parse(fs.readFileSync(package.json, utf8)); let lockExists { npm: false, yarn: false, pnpm: false }; try { fs.accessSync(package-lock.json); lockExists.npm true; } catch {} try { fs.accessSync(yarn.lock); lockExists.yarn true; } catch {} try { fs.accessSync(pnpm-lock.yaml); lockExists.pnpm true; } catch {} console.log( Lock File Status ); Object.entries(lockExists).forEach(([mgr, exists]) { console.log( ${mgr}: ${exists ? PRESENT : missing}); }); const activeLocks Object.entries(lockExists).filter(([, v]) v); if (activeLocks.length 1) { console.log(\nWARNING: Multiple lock files detected! This causes inconsistent installs.); } if (activeLocks.length 0) { console.log(\nWARNING: No lock file found! Dependencies are not reproducible.); } // Check engines if (pkg.engines) { console.log(\n Required Engines ); Object.entries(pkg.engines).forEach(([e, v]) console.log( ${e}: ${v})); }summary_prompt: Report lock file health and any warnings about package management要点fs.accessSync try/catch 探测文件存在性避免用 Read 工具逐个读锁文件yarn.lock 动辄上万行状态机式告警多个锁文件并存安装不一致或无锁文件不可复现构建是两种明确的风险状态脚本直接输出 WARNING让 LLM 的总结聚焦在风险而非文件内容上。模式四文件内容解析——解析并汇总大型 Markdownconst fs require(fs); const content fs.readFileSync(CHANGELOG.md, utf8); const lines content.split(\n); const sections []; let currentSection null; for (const line of lines) { if (line.startsWith(## )) { if (currentSection) sections.push(currentSection); currentSection { title: line.replace(## , ), items: 0, breaking: 0 }; } else if (currentSection line.startsWith(- )) { currentSection.items; if (line.toLowerCase().includes(breaking) || line.toLowerCase().includes(BREAKING)) { currentSection.breaking; } } } if (currentSection) sections.push(currentSection); console.log(Total versions: ${sections.length}\n); console.log( Recent Versions ); sections.slice(0, 10).forEach(s { const warn s.breaking 0 ? [${s.breaking} BREAKING] : ; console.log( ${s.title}: ${s.items} changes${warn}); }); const totalBreaking sections.reduce((sum, s) sum s.breaking, 0); if (totalBreaking 0) { console.log(\nTotal breaking changes across all versions: ${totalBreaking}); }summary_prompt: Summarize recent releases, highlight breaking changes, report release cadence解析策略按##划分版本章节统计每个版本的条目数与 breaking 变更数最终输出总量、最近 10 个版本、breaking 总数。这与 patterns-python.md 中的文档结构提取思路一致——都是结构扫描 摘要输出。若目标是长期查询而非一次性总结可改用ctx_execute_file(path, ...)文件内容以FILE_CONTENT预加载进沙箱SKILL.md 的决策树读取文件用于分析/汇总时用ctx_execute_file文件只进入沙箱、不进入上下文。模式五测试输出解析——运行测试并提取失败信息const { execSync } require(child_process); let output; try { output execSync(npx jest --json 2/dev/null, { encoding: utf8, maxBuffer: 50 * 1024 * 1024 }); } catch (e) { output e.stdout || ; } try { const results JSON.parse(output); console.log( Test Results ); console.log(Suites: ${results.numPassedTestSuites} passed, ${results.numFailedTestSuites} failed); console.log(Tests: ${results.numPassedTests} passed, ${results.numFailedTests} failed); console.log(Time: ${(results.testResults || []).reduce((s, t) s (t.endTime - t.startTime), 0)}ms); const failures (results.testResults || []).filter(t t.status failed); if (failures.length 0) { console.log(\n Failed Tests ); failures.forEach(suite { console.log(\nSuite: ${suite.name}); (suite.assertionResults || []) .filter(a a.status failed) .forEach(a { console.log( FAIL: ${a.ancestorTitles.join( )} ${a.title}); console.log( ${(a.failureMessages || []).join(\n ).slice(0, 200)}); }); }); } } catch { console.log(Could not parse JSON output. Raw output:); console.log(output.slice(0, 5000)); }summary_prompt: Report test pass/fail counts, list each failing test with its error message timeout_ms: 60000这个模式是沙箱内运行测试的标准姿势要点npx jest --json输出结构化结果相比直接npm test把完整测试输出灌进上下文SKILL.md 明确列为反模式JSON 模式让脚本精确提取数量与失败详情execSync抛错时读取e.stdout测试失败时 jest 可能非零退出此时 stdout 依然携带 JSON 结果maxBuffer: 50 * 1024 * 1024为超大测试输出预留缓冲错误消息截断slice(0, 200)每条失败只保留前 200 字符防止巨型堆栈反噬上下文兜底分支JSON 解析失败时只打印前 5000 字符原始输出 timeout_ms: 60000完整测试套件的推荐超时为 120000–300000ms见 anti-patterns.md60 秒是单套件场景的保守下限。语言选择什么时候用 JavaScriptSKILL.md 的语言选择表给出了明确依据场景语言理由HTTP/API 调用、JSONjavascript原生 fetch、JSON.parse、async/await数据分析、CSV、统计pythoncsv、statistics、collections、re管道式 Shell 命令shellgrep、awk、jq 原生工具文件模式匹配shellfind、wc、sort、uniq与 Python 模式的边界见 patterns-python.mdJSON/API 场景优先 JS数据统计优先 Python。若你的 Shell 脚本里出现了内联python3 -c、node -e、超过 3 个管道链或复杂jq就应改用 JS/Pythonanti-patterns.md。结合检索策略intent ctx_search当ctx_execute的输出可能超过约 5KB 且你只想按主题事后回忆时传入intent参数见 src/server.ts输出被自动索引进知识库工具只返回分节标题与预览随后用ctx_search(queries: [...])检索具体段落。ctx_search的入参契约定义在 src/search/ctx-search-schema.tsqueries数组一次性批量传入所有检索问题绝不多次单独调用BM25 使用 OR 语义命中词越多的结果排名越高单次查询 2–4 个具体技术词最佳source参数多文档索引时务必使用部分匹配即可如source: Node匹配Node.js v22 CHANGELOG避免跨源污染limit每查询默认 3 条结果sortrelevance默认BM25 排序仅当前会话或timeline跨当前会话、历史会话与 auto-memory 的时序检索。反模式清单五个必守纪律结合 anti-patterns.md 与 SKILL.md 的 Critical Rules使用 JS 模式时须遵守必须打印结论execute捕获 stdout脚本不输出则总结为空。计算完务必console.log结果结构化序列化对象/数组用JSON.stringify(data, null, 2)或表格化输出直接console.log(obj)会得到[object Object]别在上下文里处理大文件超过约 200 行的文件且只需特定数据时用ctx_execute/ctx_execute_file提取而非 Read 全文anti-patterns.md别用ctx_index(content: 大段数据)该参数会把数据作为工具参数再次送进上下文翻倍消耗。始终用ctx_index(path: ...)服务端读文件SKILL.md 的 Critical Rules #6超时与任务匹配文件解析 5–10s、单次 API 15–30s、分页 30–60s、构建/完整测试 120s。关联文档JavaScript/TypeScript Patterns本文底稿Python PatternsShell PatternsAnti-Patterns Common Mistakescontext-mode 主技能文档【免费下载链接】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），仅供参考