Cost Booster Edit 是 agent-booster 的 WASM 引擎的直接封装，调用 agent-booster.apply()（npm agent-booster v0.2.x，通过 agentic-flow/agent-booster 暴露）。它的定位是执行端：当某个转换已被 cost-booster-route 判定为 Tier 1 合格时，由本技能实际执行该转换。
用途
用于批量转换大量文件，例如 var → const、add-types、remove-console、add-error-handling、async-await、add-logging。也适用于任何简单的结构化编辑——这些编辑如果交给 LLM 处理就会产生调用与计费。还适合放在 CI 流水线中，因为此时确定性与零成本比自然度更重要。
不适用场景：当转换需要推理意图、命名或跨文件上下文时，不应使用本技能，这些属于 Tier 2/3 任务。
主要能力
本技能围绕 agent-booster.apply() 提供执行流程，支持 6 种 booster intent。它读取源码到变量，由调用方根据 intent 提供目标编辑文本，然后调用引擎并返回 success、output、latency、confidence、strategy、tokens 等字段。默认置信度阈值为 0.5，低于该阈值时失败关闭：不写入文件，报告并升级到 Tier 2/3。只有在 success 且 confidence >= 0.5 时才写回 output 字段。
使用方式
输入为 intent（6 种 booster intent 之一）和文件路径。读取源码后，从 intent 推导出目标编辑文本（由调用方提供）。在 v3/ 下任意位置运行以下命令，以便 agent-booster 能被解析：
node --input-type=module -e ' import("agent-booster") .then(async ({ AgentBooster }) => { const booster = new AgentBooster(); const r = await booster.apply({ code: process.argv[1], edit: process.argv[2], language: process.argv[3] || "javascript", }); console.log(JSON.stringify({ success: r.success, output: r.output, latency: r.latency, confidence: r.confidence, strategy: r.strategy, tokens: r.tokens, })); }) .catch(e => console.log(JSON.stringify({ success: false, error: String(e.message) }))); ' -- "$CODE" "$EDIT" "$LANG"
随后检查置信度，若 success 且 confidence >= 0.5 则写回 output。最后持久化结果：memory_store --namespace cost-tracking --key "booster-edit-..." --value '{"intent":..., "latency":..., "confidence":..., "strategy":..., "applied":true}'，并通过 hooks_model-outcome 反馈给路由学习器（使用 cost-optimize 技能的第 8 步）。
适用场景
适合批量、结构化的代码转换，以及 CI 流水线中需要确定性和零成本的环节。资料中的实测基准（2026-05-04，本检出）显示，5 个代表性 intent 通过 AgentBooster.apply() 运行：var-to-const 延迟 5ms、置信度 0.65、fuzzy_replace、成功；add-types 延迟 1ms、置信度 0.64、fuzzy_replace、成功；remove-console 延迟 0ms、置信度 0.70、fuzzy_replace、成功；add-error-handling 延迟 0ms、置信度 0.85、exact_replace、成功；async-await 延迟 0ms、置信度 0.85、exact_replace、成功。平均实测延迟约 1.2ms，全部 5 个都高于默认 0.5 置信度阈值。
限制
fuzzy_replace 是尽力而为；对于生产转换，优先选择路由到 exact_replace 的用例（在样本中置信度 ≥0.85）。资料中列出的本地验证结论包括：100% 胜率（在 bench/booster-corpus.json 上 12/12，Booster 与 Gemini 2.0 Flash 均为 12/12，该语料是结构正确性语料而非强对抗语料）；亚毫秒延迟（平均 0.67ms，p50 0ms，p99 6ms，最大 6ms）；每次编辑 $0（结构上验证，无 API 调用、无 token 计费）；确定性 AST 合并（相同输入复现相同输出与策略）；置信度 ≥ 0.5 即正确（在该语料上 12/12 高于 0.5，最低 0.551，全部正确）；相对 LLM 的加速（对 Gemini 2.0 Flash 为 1000.9×，对 Claude Sonnet 4.6 为 1838.7×，对 Claude Opus 4.7 为 2634.1×）；每次编辑节省成本（相对 Gemini 为 $0.000020，相对 Sonnet 4.6 为 $0.000722，相对 Opus 4.7 为 $0.004720，booster 侧均为 $0）；与前沿 LLM 的胜率持平（Booster、Gemini 2.0 Flash、Sonnet 4.6、Opus 4.7 在该语料上均为 12/12）。
扩展方式：向 bench/booster-corpus.json 添加用例，运行 ( cd v3 && node ../plugins/ruflo-cost-tracker/scripts/bench.mjs )（或带 BENCH_LLM_BASELINE=1），提交 runs/latest.json。Smoke 第 23 步在胜率低于 0.80 时会使构建失败。可通过 BENCH_LLM_MODEL='claude-sonnet-4'（对接 api.anthropic.com 时）或 BENCH_LLM_MODEL='models/gemini-2.5-flash' 覆盖 LLM 模型；定价标志为 BENCH_LLM_PRICE_IN、BENCH_LLM_PRICE_OUT。
交叉引用：ADR-0002 §"Decision 1"（路由分类器）与 §"Riskiest assumption"（Bash-shelled 调用）· cost-booster-route（分类器侧配套）· agent-booster npm README（3 种安装模式：MCP / npm / HTTP）。