cost-booster-edit

成本增强编辑

直接封装 agent-booster.apply()（npm agent-booster v0.2.x，通过 agentic-flow/agent-booster 暴露）。当转换已被分类为符合 Tier 1 条件时使用——cost-booster-route 建议是否使用；此技能负责执行。

使用场景

• 跨多个文件进行批量转换（var → const、add-types、remove-console、add-error-handling、async-await、add-logging）。
• 任何简单的结构性编辑，否则需要调用 LLM 并产生费用。
• 在 CI 流水线中使用，确定性和零成本比自然度更重要。

当转换需要推理意图、命名或跨文件上下文时，请勿使用——这些属于 Tier 2/3 任务。

步骤

1. 获取输入——intent（6 种增强意图之一）和 file 路径。

2. 读取源文件到变量中，并根据意图推导出预期的 edit 文本（由调用方提供）。

3. 调用——从 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"
   

4. 检查置信度——默认阈值为 0.5。低于此阈值时，安全失败：不要写入文件；报告情况并升级到 Tier 2/3。

5. 写回 output 字段（条件为 success && confidence >= 0.5）。

6. 持久化结果——memory_store --namespace cost-tracking --key "booster-edit-..." --value '{"intent":..., "latency":..., "confidence":..., "strategy":..., "applied":true}'。通过 hooks_model-outcome 将结果提供给路由学习器（使用 cost-optimize 技能的第 8 步）。

实测基准（2026-05-04，此检出版本）

使用 AgentBooster.apply() 运行了 5 种代表性意图：

意图	延迟（ms）	实际耗时（ms）	置信度	策略	成功
var-to-const	5	5	0.65	fuzzy_replace	true
add-types	1	1	0.64	fuzzy_replace	true
remove-console	0	0	0.70	fuzzy_replace	true
add-error-handling	0	0	0.85	exact_replace	true
async-await	0	0	0.85	exact_replace	true

实测平均延迟约为 1.2 ms。以上 5 项的置信度均高于默认阈值 0.5。LLM 基准对比请参阅 docs/benchmarks/0002-baseline.md。

本地验证结果

声明	此处状态
100% 胜率	已验证 — 在 bench/booster-corpus.json 中为 12/12（参见 runs/latest.json）。Booster 和 Gemini 2.0 Flash 均得分 12/12——这是结构正确性语料库，并非高难度对抗性语料库。
亚毫秒级延迟	已验证 — 平均 0.67 ms，p50 为 0 ms，p99 为 6 ms，最大值为 6 ms。
每次编辑成本为 $0	结构上已验证 — 无 API 调用，也无 Token 计费。
基于 AST 的确定性合并	已验证 — 相同输入会产生相同的 output 和 strategy。
置信度 ≥ 0.5 ⇒ 正确	已在此语料库中验证 — 置信度高于 0.5 的有 12/12（最低为 0.551），且全部正确。
相较 LLM 提速 350×	**已验证——超过所有级别：**相较 Gemini 2.0 Flash 提速 1000.9×，相较 Claude Sonnet 4.6 提速 1838.7×，相较 Claude Opus 4.7 提速 2634.1×。运行 BENCH_LLM_BASELINE=1 BENCH_ANTHROPIC=1 node scripts/bench.mjs 可刷新数据。
每次编辑节省的成本	**实测：**相较 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。对于确定性转换，Booster 在结构上与 LLM 的准确率相当。

扩展语料库：向 bench/booster-corpus.json 添加用例，运行 ( cd v3 && node ../plugins/ruflo-cost-tracker/scripts/bench.mjs )（或添加 BENCH_LLM_BASELINE=1），然后提交 runs/latest.json。如果胜率低于 0.80，Smoke 步骤 23 会导致构建失败。

覆盖 LLM 模型：BENCH_LLM_MODEL='claude-sonnet-4'（接入 api.anthropic.com 时）或 BENCH_LLM_MODEL='models/gemini-2.5-flash'，用于与推理模型进行比较。定价标志：BENCH_LLM_PRICE_IN、BENCH_LLM_PRICE_OUT。

fuzzy_replace 采用尽力而为策略；生产转换优先使用会路由到 exact_replace 的用例（在我们的样本中置信度 ≥ 0.85）。

交叉引用

ADR-0002 §“决策 1”（路由分类器）和 §“风险最高的假设”（通过 Bash 调用） · cost-booster-route（分类器侧配套工具） · agent-booster npm README（3 种安装模式，MCP / npm / HTTP）。