Goose 基准测试脚本实战解析用 run-benchmarks.sh 在多 Provider/多模型上跑通并分析 benchmark【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose本文以仓库 scripts/README.md 为骨架围绕 Goose 仓库自带的基准测试脚本族展开run-benchmarks.sh负责一次串联多个 provider:model 组合批量运行 benchmark 并自动分析结果parse-benchmark-results.sh负责对单个 JSON 结果文件做失败判定。读完本文你将掌握如何用这两条命令完成多模型横向评测 → 结果落盘 → 失败定位 → 退出码判读 → 指标聚合的完整链路并理解其与仓库中evals/harbor、bench-postprocess-scripts等其他评测工具的关系与边界。一、脚本在仓库中的定位Goosecrates/goose-cli等组成的开源 AI Agent支持接入多种 LLM Provider。要在不同的 Provider 与模型组合上反复评测 Agent 能力、并把哪些指标挂了稳定地量化下来仓库在scripts/目录提供了两条配套脚本scripts/run-benchmarks.sh批量编排器。接受provider:model列表与 benchmark suite 列表逐对运行 CLI 内置的bench子命令收集 JSON 原始结果并用jq分析每条评测的通过/失败情况最终汇总到summary.md。scripts/parse-benchmark-results.sh单文件分析器。接收一个 benchmark JSON 结果文件输出结构化的逐 suite / 逐 evaluation 分析报告并用退出码表达整体成败。两者的分析口径略有差异见下文第六节这正是仓库中容易踩坑、也最值得注意的细节。二、运行前提根据 scripts/README.md 的 Prerequisites以及脚本源码中对二进制位置的探测逻辑运行前需要满足Goose CLI 已构建或已安装。run-benchmarks.sh会按以下顺序挑选要执行的命令见 scripts/run-benchmarks.sh 的GOOSE_CMD解析逻辑--debug时优先使用./target/debug/goose默认release优先使用./target/release/goose若对应目录下找不到二进制打印 Warning 并回退到系统 PATH 中已安装的goose因此从源码运行时建议先在仓库根目录执行cargo build --release或直接用已安装的 CLI。jq用于 JSON 处理。README 将jq标注为可选但强烈建议需要澄清实际行为以源码为准parse-benchmark-results.sh强依赖jq直接调用jq -r完成全部字段抽取run-benchmarks.sh会在分析阶段先执行command -v jq检测run-benchmarks.sh#L180-L183若缺失则跳过 JSON 解析并在 summary 中记录Could not parse results (jq not installed)结论想拿到完整分析报告务必安装jq。三、run-benchmarks.sh批量跑基准并汇总3.1 调用方式./scripts/run-benchmarks.sh [options]两个核心参数-p/--provider-models与-s/--suites均为必填。源码在参数校验阶段run-benchmarks.sh#L69-L80规定缺失任一参数即打印错误、输出 usage 并以退出码1终止。3.2 完整参数表README 的 Options 一节给出了基础选项对照脚本源码可以发现 README 未列的-t/--toolshim与-m/--toolshim-model两个开关run-benchmarks.sh#L10-L17下表合并两者、逐项说明选项说明默认值/备注-p, --provider-models逗号分隔的provider:model对列表如openai:gpt-4o,anthropic:claude-sonnet-4必填用:切分格式非法的 pair 会被跳过并打印 Warning-s, --suites逗号分隔的 benchmark suite 列表如core,small_models必填原样透传给goose bench --suites-o, --output-dir结果输出目录./benchmark-results脚本会mkdir -p创建-d, --debug使用 debug 构建./target/debug/goose而非 release 构建默认关闭-t, --toolshim启用 toolshim 模式即导出GOOSE_TOOLSHIM1默认关闭README 未提及见源码 run-benchmarks.sh#L49-L55-m, --toolshim-model指定 toolshim 使用的模型导出为GOOSE_TOOLSHIM_OLLAMA_MODEL仅配合-t生效-h, --help打印帮助并退出退出码 0—3.3 典型用法# release 构建 两组 provider:model 两个 suiteREADME 原始示例 ./scripts/run-benchmarks.sh --provider-models openai:gpt-4o,anthropic:claude-sonnet-4 --suites core,small_models # 单模型 debug 构建 ./scripts/run-benchmarks.sh --provider-models openai:gpt-4o --suites core --debug # 自定义输出目录 启用 toolshim 及其模型结合源码补充的示例 ./scripts/run-benchmarks.sh -p anthropic:claude-sonnet-4 -s core -o ./results -t -m openai:gpt-4o3.4 底层执行机制环境变量驱动而非交互配置run-benchmarks.sh最关键的实现细节是不使用goose configure之类的交互配置而是用环境变量直接注入 Provider/Modelrun-benchmarks.sh#L157-L159export GOOSE_PROVIDER$provider export GOOSE_MODEL$model当启用 toolshim 时追加run-benchmarks.sh#L162-L167export GOOSE_TOOLSHIM1 export GOOSE_TOOLSHIM_OLLAMA_MODEL$TOOLSHIM_MODEL # 仅在指定 -m 时导出随后对每一对 provider/model 执行核心命令$GOOSE_CMD bench --suites $SUITES --output $OUTPUT_FILE --format json即命令形式为goose bench --suites suite列表 --output json路径 --format json。这解释了为何本仓库其他 CLI 命令各自独立配置模型——批量评测场景下环境变量注入是最适合脚本化、可并发的做法。3.5 逐对循环 自动化失败分析外层for循环按序处理每一对 provider/modelrun-benchmarks.sh#L147-L320每对执行一个完整子流程打印分隔横幅在summary.md写入小节标题## Provider: p, Model: m导出环境变量并运行goose bench成功时打印 ✅ 并把结果写入{provider}-{model}.jsonJSON 有效性检查先jq empty校验run-benchmarks.sh#L185非法 JSON 直接标记失败用jq提取.provider、.start_time、.suites数组长度等元信息写入{provider}-{model}-analysis.txt逐 suite、逐 evaluation 遍历统计Boolean 指标metrics中值为{Boolean: ...}的对象形式条目凡是Boolean false / false / 0 / 0均计为失败见过滤条件 run-benchmarks.sh#L229-L232同时统计evaluation.errors中的错误条目数有失败或有错误的 evaluation 输出 ❌ 及其具体失败指标名、错误级别与消息errors[]含.level与.message全绿则输出 ✅做计数自检Passed Failed Other必须等于总指标数否则打印计数不一致的警告run-benchmarks.sh#L282-L286——这是防止分析逻辑本身出 bug 的护栏汇总任一 provider/model 有失败指标或有错误即置OVERALL_SUCCESSfalse。3.6 输出产物与退出码脚本在输出目录中生成三类文件README Output 一节 源码交叉验证summary.md一次批量运行的总汇总。头部含运行日期、suites、Release/Debug 模式、toolshim 状态随后按 provider/model 追加每个子分析文本{provider}-{model}.json每次goose bench --format json的原始输出{provider}-{model}-analysis.txt该组合的分析报告最终会被cat合并进summary.md。退出码约定run-benchmarks.sh#L328-L3340所有 benchmark 全部成功1任一 provider/model 存在失败指标、错误、JSON 非法或产物缺失。这套退出码让脚本可直接嵌入 CI 管道做硬门禁。四、parse-benchmark-results.sh单文件失败定位当你只想复查某个已有的{provider}-{model}.json例如跑挂了之后人工复盘使用单文件分析器./scripts/parse-benchmark-results.sh path/to/benchmark-results.json源码行为scripts/parse-benchmark-results.sh要点参数必须是恰好一个文件路径否则打印 usage 并以退出码1结束set -e下使用exit 1文件不存在时报错退出输出到 stdout顶部是provider、start_time、suites数量然后逐 suite 输出每个 evaluation 的 ✅/❌最后是 Summary 汇总行Total Evaluations / Total Metrics / Passed Metrics / Failed Metrics退出码0 全部指标通过1 存在失败。五、由分析脚本还原的 benchmark JSON 结果结构两个脚本都没有独立定义 JSON Schema但通过其jq抽取逻辑可以可靠还原结果文件的字段布局这正是拿到{provider}-{model}.json后自行解析的依据{ provider: provider名, start_time: 开始时间, suites: [ { name: suite名, evaluations: [ { name: 评测名, metrics: [ [指标名, { Boolean: true|false }], ... ], # 每项为 [name, value] 对value 常见为对象形式 errors: [ { level: 级别, message: 消息 }, ... ] } ] } ] }说明.metrics中的元素是[名称, 值]二元组run-benchmarks.sh只把值为{Boolean: ...}对象的条目当作布尔指标其余视为Other非布尔如整型/浮点/字符串指标判定失败的三类取值布尔false、字符串false、以及数字0/0四种形态在jq的select中都被显式兼容.errors[]暴露了level严重级别与message错误内容用于区分指标不达标与运行期错误两类失败。六、两套分析口径的差异实战必读仓库中两个脚本对什么算失败的判定并不完全一致run-benchmarks.sh内嵌分析凡是 Boolean 值取 false/0 的指标一律算失败无论指标名是什么parse-benchmark-results.sh仅当指标名匹配success|pass|correct忽略大小写且取值为 false/0时才判失败过滤条件见 parse-benchmark-results.sh#L52-L57其余布尔指标即便为 false 也只计入通过侧的METRIC_COUNT。也就是说同一个结果文件用两个工具分析失败数可能与汇总口径不同。README 中parse-benchmark-results.sh一节之所以声明假设名为 success/pass/correct 的布尔指标代表成败正是这种启发式过滤的写照。若某 suite 的指标命名不含这三个关键词建议以run-benchmarks.sh的全布尔扫描为准两套脚本同时存在恰好便于在全量布尔扫描与语义命名过滤两种粒度之间切换。七、更上层的指标后处理与生态工具run-benchmarks.sh产出的 JSON 主要回答哪些指标挂了。若要进一步做跨多次运行、跨模型的量化对比仓库在 scripts/bench-postprocess-scripts 提供配套 Python 工具链scripts/bench-postprocess-scripts/prepare_aggregate_metrics.py扫描 benchmark 目录下各模型子目录目录名按provider-model拆分汇总所有eval-results.json与 session.jsonl按provider/model/eval_suite/eval_name聚合成eval-results/aggregate_metrics.csv并顺带检测会话中的Server error / error_code / TEMPORARILY_UNAVAILABLE文本输出server_error标记scripts/bench-postprocess-scripts/generate_leaderboard.py读取各模型的aggregate_metrics.csv选出total_tool_calls_mean、prompt_execution_time_mean、total_tokens_mean、score_mean、prompt_error_mean、server_error_mean等列按provider model_name求均值生成leaderboard.csv按score_mean降序并对存在 server error 的模型打印警告提示重跑。二者配合可形成跑 bench → JSON/分析文本 → aggregate CSV → 排名 CSV的完整后处理链路且这些脚本与本文主角共用相同的provider-model目录命名习惯。此外仓库evals/harbor见 evals/harbor/README.md是另一套面向terminal-bench风格任务其文档提及覆盖完整terminal-bench/terminal-bench-2数据集的 89 个任务的评测工具定位与scripts/下的批量编排不同前者聚焦 CLI 批量串联与失败汇总后者更贴近数据集级别的实验管理二者可按需选用而非互斥。八、典型落地场景小结多模型横向对比把候选模型写成-p a:model1,b:model2,...一次跑完所有 suite用summary.md判断哪些组合全绿回归验证在 CI 中对固定provider:model对执行run-benchmarks.sh依赖退出码0/1决定构建是否通过debug 场景用-d快速验证未发布改动单点排障某个组合挂了之后先看{provider}-{model}-analysis.txt的 ❌ 行与失败指标名再拿同一 JSON 跑parse-benchmark-results.sh做二次确认规模化聚合多轮结果落盘后用prepare_aggregate_metrics.pygenerate_leaderboard.py产出可排名的 CSV并警惕server_error高企的模型需要重跑。需要再次强调的边界本文结论全部依据仓库当前快照中的 scripts/run-benchmarks.sh、scripts/parse-benchmark-results.sh 与 README 推得goose bench各 suite 的实际指标构成、命名规则取决于运行时的 Goose CLI 版本与 suite 定义分析口径上的差异第六节属于脚本设计使然并非缺陷。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考