ruflo-cost-tracker 成本基准测试实战:用bench.mjs验证 Agent Booster 的 measured-vs-claimed 表格【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflocost-benchmark是 ruflo 生态中ruflo-cost-tracker插件提供的一组技能,核心职责是运行结构性与对抗性语料库corpus基准,将 Agent BoosterTier 1 零成本直通路径的声称指标落成可验证指标,并把逐案例与汇总结果持久化到docs/benchmarks/runs/。读完本文你将掌握:如何从v3/目录一键运行 booster-only、Gemini 2.0 Flash、Sonnet 4.6 / Opus 4.7 三种基准模式;如何读懂winRate与escalationRate两个核心门禁指标;如何通过环境变量覆盖模型、端点与输出路径;以及cost-report、cost-trend与 smoke 门禁如何消费这些运行产物,让每次发版前的成本回归验证真正闭环。一、cost-benchmark 在成本体系中的定位ruflo-cost-tracker见 README的目标是追踪 token 用量、按 agent 归属模型成本、监控预算并给出优化建议。其中 Agent Booster 是 ADR-00020002-agentic-flow-and-agent-booster-integration.md引入的关键上游能力:对简单结构化代码变换,通过 WASM 引擎在不调用 LLM的前提下完成编辑,结构成本恒为 $0。cost-benchmark技能SKILL.md正是这条零成本路径的验证门禁——它运行scripts/bench.mjs对语料库做全量回归,并把measured实测vs claimed声称对照表写盘,支撑cost-booster-edit/cost-booster-route两个技能的每一个可量化声明。注意事实边界:仓库 README 明确标注,CLAUDE.md 根目录的百分比声明-32% 检索、-15% booster 编辑、352× 加速、95% 缓存命中是claimed upstream, not yet verified,本仓库只把 Tier 1 直通的 $0 结构成本作为实测节省上报。cost-benchmark的职责就是把这些声称逐步翻转成已验证。二、基准脚本与语料库:bench.mjs booster-corpus.json2.1 脚本结构基准入口是 scripts/bench.mjs,它做了三件事:解析语料库——读取 bench/booster-corpus.json当前 corpusversion: 3,25 个案例:18 个 Tier 1 7 个对抗性案例。跑 booster——从当前工作目录而非脚本目录解析agent-booster包createRequire(join(process.cwd(), package.json)).resolve(agent-booster),逐个调用booster.apply({ code, edit, language })。可选跑 LLM baseline——BENCH_LLM_BASELINE1走 OpenAI-compat 端点,BENCH_ANTHROPIC1走 Anthropic Messages API,逐案例对比正确率、延迟与每编辑成本。脚本对每个案例记录:是否正确correct规范化后与 goldenexpected精确比对、是否成功、置信度、策略exact_replace/fuzzy_replace/failed、latencyMs/wallMs、输入输出 token 数,失败时附带actualPrefix与expectedPrefix前缀片段便于诊断。2.2 语料库的两类案例booster-corpus.json的metrics块定义了三个口径,理解它们才能正确解读结果:winRateTier1correct / count(expectedTier1 true)——门禁指标;escalationRate(low-confidence OR incorrect) / count(expectedTier1 false)—— 对抗性案例上高升级率是期望信号booster 应识别自身能力边界并升级到 Tier 2/3;overallCorrectcorrect / total—— 仅诊断用途,不作门禁。Tier 1 案例如var-to-const、add-types、remove-console、add-error-handling、async-await、add-logging、var-to-let、add-readonly、remove-debugger等期望 booster 直接应用;对抗性案例如extract-function、type-narrowing、cross-method-rename、recursive-to-iterative、extract-class、callback-to-promise、deeply-nested-conditional在 JSON 中显式标注expectedTier1: false,要求 booster 要么产出错误、要么低置信度,正确升级才计为escalatedCorrectly。2.3 为什么必须从v3/运行bench.mjs的模块解析以process.cwd()为锚点,因此要求在有agent-booster可解析的目录下执行通常是v3/下的任意位置。从错误路径运行时,脚本会明确提示:agent-booster import failed: ... Run from a directory where the package resolves, e.g.: ( cd v3 node ../plugins/ruflo-cost-tracker/scripts/bench.mjs )三、三步跑通基准:booster-only → Gemini → Sonnet/Opus3.1 三条标准命令对应 SKILL.md 的 Steps 1,从v3/执行:# 1) booster only —— 免费,约 85 ms结构成本 $0,不触发任何 LLM 计费 ( cd v3 node ../plugins/ruflo-cost-tracker/scripts/bench.mjs ) # 2) 追加 Gemini 2.0 FlashOpenAI-compat,廉价 ( cd v3 BENCH_LLM_BASELINE1 node ../plugins/ruflo-cost-tracker/scripts/bench.mjs ) # 3) 追加 Sonnet 4.6 Opus 4.7Anthropic 基线 ( cd v3 BENCH_LLM_BASELINE1 BENCH_ANTHROPIC1 \ node ../plugins/ruflo-cost-tracker/scripts/bench.mjs )3.2 读 stdout 的 Markdown 汇总脚本在BENCH_QUIET ! 1时向 stdout 打印 Markdown 表格,关键行包括:Corpus size含 Tier 1 / adversarial 分拆;Win rate (Tier 1 cases)—— 门禁核心;Escalation rate (adversarial)—— 诊断信号;延迟分布:Avg / p50 / p99 / Max latency;置信度:Avg / Min confidence与Above 0.5 threshold;Structural cost: $0 (no LLM call);启用 LLM 基线时追加:LLM 模型、平均延迟、win rate、平均成本/编辑,以及Measured speedup (booster vs LLM)与Cost saved per edit (100%);Anthropic 基线启用时,按模型输出每行:延迟、win rate、平均 tokenin/out、平均成本/编辑、相对 booster 的speedup×与cost saved/edit;失败案例清单:每个未命中的案例给出actual... vs expected...前缀对比或错误信息。3.3 持久化产物脚本把完整 payloadsummaryresults 可选llmResults/anthropicResults写入两个位置:docs/benchmarks/runs/latest.json—— 指向最近一次运行的指针,供下游技能读取;docs/benchmarks/runs/ISO-timestamp.json—— 历史记录,时间戳由runAt派生replace(/[:.]/g, -)。仓库中的历史运行见 docs/benchmarks/runs,其中 latest.json 记录了最近一次完整跑批。四、解读实测结果:以 latest.json 为例以仓库内 latest.jsoncorpus v3,25 案例为样例,实测口径如下:指标实测值Tier 1 win rate100.0%18/18对抗性 escalation rate100.0%7/7 全部正确升级overall correct诊断72%booster 对 7 个对抗性案例按设计失败/低置信avg latency0.36 msp50 0 ms,p99 5 msavg confidence0.552全部 18 个 Tier 1 高于 0.5 阈值structural cost$0LLM 对照同语料:Gemini 2.0 Flash:winRate 84%,avg latency 807.56 ms,avg cost/edit $0.0000276,speedup 2243×;Claude Sonnet 4.6:winRate 80%,avg latency 1270.64 ms,avg cost/edit $0.00093;Claude Opus 4.7:winRate 92%,avg latency 1563.72 ms,avg cost/edit $0.00594。对照表揭示的核心事实是:对这类结构化正确性语料,booster 的准确率与前沿 LLM 持平甚至更稳,而延迟与成本低 3~4 个数量级。这正是cost-booster-edit技能中measured benchmark表格的数据来源cost-booster-edit/SKILL.md 的 5 意图实测:avg ≈ 1.2 ms,全部高于 0.5 置信度阈值。五、Smoke 门禁:winRate 是红线,escalationRate 是诊断cost-benchmark的验证门禁身份由 scripts/smoke.sh 落实:smoke step 23Tier 1 winRate ≥ 0.80:若runs/latest.json存在,则读取summary.winRate并断言 0.8,否则构建失败;文件不存在时跳过非阻塞。阈值可通过编辑scripts/smoke.sh调整。smoke step 24:corpus 结构约束——至少 18 个 Tier 1 案例、至少 6 个对抗性案例、总案例 ≥ 25当前 18/7/25 满足。smoke step 22:harness 可运行性——bench.mjs可执行、语法通过、corpus 可解析,且 case 数 ≥ 10。escalationRate上报但不设门禁:对抗性案例属于诊断维度,不被门禁拦截。另外,CI 工作流cost-tracker-smoke.yml在每次触及本插件的 PR 上运行 smoke booster-only bench 回归门禁Tier 1 winRate ≥ 0.80;LLM / Anthropic 基线不会在 CI 中执行——它们每次调用都产生真实费用,只适合手动或定时工作流。这解释了为什么三类基准命令中只有 booster-only 被 CI 采纳。六、环境变量覆盖:完整参数表SKILL.md 的 Env overrides 表格需完整继承,并与bench.mjs实现一一对应:Env var默认值用途BENCH_LLM_BASELINEunset1时运行 OpenAI-compat 基线BENCH_LLM_MODELmodels/gemini-2.0-flash覆盖 OpenAI-compat 模型BENCH_LLM_BASE_URLGemini OpenAI shimhttps://generativelanguage.googleapis.com/v1beta/openai/覆盖端点BENCH_ANTHROPICunset1时运行 Anthropic 基线Sonnet 4.6 Opus 4.7BENCH_ANTHROPIC_MODELSclaude-sonnet-4-6,claude-opus-4-7逗号分隔的 Claude 模型 IDBENCH_OUT时间戳文件覆盖输出 JSON 路径BENCH_QUIET1unset抑制 Markdown 汇总输出另有实现层覆盖参数源码头注释:Env var默认值用途BENCH_LLM_API_KEYgcloud secretGOOGLE_AI_API_KEYOpenAI-compat 端点 API KeyBENCH_LLM_PRICE_IN/BENCH_LLM_PRICE_OUT0.10/0.40$/1MGemini 2.0 Flash 定价覆盖BENCH_ANTHROPIC_API_KEYgcloud secretANTHROPIC_API_KEYAnthropic API KeyBENCH_ANTHROPIC_PRICING内置定价表JSON 格式按模型覆盖定价内置 Anthropic 定价表每 1M token,USD,见bench.mjs:Sonnet 4.6 3/15,Opus 4.7 15/75,Haiku 4.5 1/5。API Key 默认从gcloud secrets自动拉取,不存在时 LLM 基线会以no-api-key摘要记录并跳过,booster-only 部分不受影响。七、下游消费链:谁在读取 runs/ 产物cost-benchmark不是终点,它的产物被两个技能直接消费:cost-reportcost-report/SKILL.md step 1a/4:通过 Bash 读取docs/benchmarks/runs/latest.json的summary,用实测的 Tier 1 成本$0、平均延迟、win rate 以及 LLM 基线数据,替换估算值完成measured 层级分账Tier 1 / 2 / 3,并统计 Tier 1 bypass 次数——这是报告里最可执行的一行:告诉你有多少 Sonnet/Opus 花费本可路由到 Tier 1。cost-trendcost-trend/SKILL.md:读取docs/benchmarks/runs/*.json全量历史,输出 first→last 漂移汇总与逐 run 序列,并对 win rate 下降或 avg latency 上升 ≥ 1.5× 给出⚠ Regression标记——补上 smoke 二元门禁抓不到的100% 缓慢滑向 85%式渐进回归。八、把基准接入你的发布流程综合本技能与配套脚本,推荐的接入方式是:发版前:从v3/跑 booster-only bench,确认 Tier 1winRate ≥ 0.80对标 smoke step 23 门禁;扩语料后:向bench/booster-corpus.json追加案例后重跑,确认新案例路由正确,并提交runs/latest.jsoncost-booster-edit技能明确要求提交该文件;审计声称的上游标签:对 CLAUDE.md 根目录的百分比声明,以本基准的实测值决定是否将其从 claimed 翻转为 verified——例如cost-booster-edit中的测量表正是这样逐步固化下来的;成本问题回答如Sonnet 4.6 是否比 Opus 4.7 便宜:BENCH_ANTHROPIC1重跑,直接产出逐模型对比表。延伸参考:ADR-0002 §Decision 1 与 §Riskiest assumptionbooster 分类器与 Bash 调用方式的架构依据、cost-booster-route分类侧配套技能、README插件全貌与 23 个子命令。【免费下载链接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated项目地址: https://gitcode.com/GitHub_Trending/cl/ruflo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考