【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载导读本文围绕 Harbor 仓库中的 GSO → Harbor Adapter 展开系统讲解 GSOGlobal Software Optimization全局软件优化评测基准如何被转换为 Harbor 标准任务格式以及如何通过 Harbor 的harbor run/harbor trial/harbor job命令完成整数据集评测、单任务调试与基准一致性Parity验证。读完本文你将掌握GSO 适配器的任务目录结构与生成流程、任务配置文件task.toml与模板文件的定制逻辑、Opt1性能判定指标的精确含义以及如何复现适配器作者公布的 102 任务 Parity 实验结果。GSO 基准是什么为 SWE-Agent 量身定制的性能优化挑战GSOGlobal Software Optimization是一个用于评估语言模型开发高性能软件能力的基准。它从多个领域与编程语言的 10 个代码库中筛选出102 个高难度优化任务。每个任务都提供一个带有明确性能瓶颈的代码库如 numpy、pandas、transformers、llama-cpp-python、pillow、tornado、pydantic 等真实开源项目的历史提交一个作为精确规格说明的性能测试脚本prob_script描述目标使用场景一个 Agent 必须生成的补丁patch目标是提升运行时效率以专家开发者优化提交opt_commit为基准的成败判定。从源码看该基准的原始数据通过 HuggingFacedatasets加载适配器在 adapter.py 中调用load_dataset(gso-bench/gso, splittest)拉取全部测试集记录每条记录以instance_id唯一标识。Harbor 适配器把这一整套评测逻辑正确性等价检查 性能计时对比原样保留仅做基础设施层面的适配这正是 Harbor 适配器的核心设计原则。适配器特性与工作原理GSO 适配器评估的是语言模型在软件性能优化上的能力任务链路可概括为给定代码库 性能测试脚本规格 → Agent 生成优化补丁 → 与基线(base)及专家提交(opt_commit)三方计时对比 → 判定是否达标适配器并不改动原基准的评分语义而是负责三件事转换任务格式把 GSO 数据集记录转换为 Harbor 标准任务目录task.tomlinstruction.mdenvironment/solution/tests/保留原始评价逻辑复用原 GSO 的gso_evaluate.py评分脚本与 eval 脚本生成逻辑见 utils.py适配运行基础设施为每个任务生成带预构建镜像的 Dockerfile、资源配额与超时配置以便在 Docker / Daytona 等运行时中稳定执行。生成的任务目录结构运行适配器后每个 GSO 任务会生成一个独立目录整体结构如下以{task_id}为gso-numpy--numpy-09db9c7这样的规范命名gso/ ├── {task_id}/ │ ├── task.toml # 任务配置资源、超时、元数据 │ ├── instruction.md # 给 Agent 的任务说明 │ ├── environment/ # 容器定义 │ │ └── Dockerfile │ ├── solution/ # Oracle/金标准解法 │ │ └── solve.sh │ └── tests/ # 测试资产与脚本 │ ├── test.sh │ ├── eval.sh │ ├── gso_evaluate.py │ └── gso_test_{N}.py其中eval.sh与gso_test_{N}.py是由适配器在生成阶段动态写入的eval.sh由 get_eval_script() 依据实例的install_commands、base_commit、opt_commit、reset_repo_commands、test_count等字段拼装gso_test_{N}.py则由apply_patches(instance.instance_id, instance.tests)生成见 adapter.py。适配器代码目录harbor/adapters/gso/ ├── adapter_metadata.json # 结构化元数据任务数、支持 Agent、Parity 规模 ├── adapter.py # GSOAdapter 核心加载数据、生成任务目录 ├── parity_experiment.json # Parity 实验记录原始分数与 Harbor 分数 ├── README.md ├── run_adapter.py # CLI 入口--output-dir / --task-ids / --ids-file / --limit ├── run_gso.yaml # 参考运行配置Daytona 环境 OpenHands ├── template/ # 任务模板生成时复制并做占位符替换 │ ├── environment/Dockerfile │ ├── instruction.md │ ├── solution/solve.sh │ ├── task.toml │ └── tests/gso_evaluate.py │ └── tests/test.sh └── utils.py # GSOInstance 转换、install 命令清洗、eval.sh 生成在 Harbor 中运行 GSO 评测方式一直接使用数据集注册表推荐在 Harbor 根目录执行即可对整个数据集发起评测# 使用 oracle agent参考解法用于验证适配器正确性 uv run harbor run -d gso # 使用指定 Agent 和模型 uv run harbor run -d gso -a agent_name -m model_name-d gso直接解析注册表registry.json 中的gso数据集条目其中已注册全部 102 个任务如gso-numpy--numpy-09db9c7、gso-pandas-dev--pandas-061c2e9、gso-huggingface--transformers-211f93a等。方式二使用任务配置Job 配置如果希望在本地准备任务目录或用自定义版本/子集评测可改用harbor run的-c配置文件或-p本地数据集路径参数# 从仓库根目录用适配器自带的配置 YAML 运行 uv run harbor run -c adapters/gso/run_gso.yaml -a agent_name -m model_name # 或者不使用配置 YAML改用本地已生成的数据集路径 uv run harbor run -p datasets/gso -a agent_name -m model_name # 恢复一个此前中断的 job uv run harbor job resume -p /path/to/jobs/directory评测结果默认保存在jobs/目录下可通过配置 YAML 中的jobs_dir字段调整。适配器自带的 run_gso.yaml 是一个可复现的参考配置jobs_dir: jobs n_attempts: 1 timeout_multiplier: 1.0 n_concurrent_trials: 10 quiet: false environment: type: daytona delete: true agents: - name: openhands model_name: gpt-5.1 kwargs: version: 1.4.0 datasets: - path: datasets/gso该配置同时体现了原作者对评测环境的建议Daytona 云运行时、n_concurrent_trials: 10控制并发以降低资源争抢详见后文降低性能波动。方式三单任务运行Trial快速测试或调试单个任务时使用# 用 oracle预写解法运行单个任务 uv run harbor trial start -p datasets/gso/task_id # 用指定 Agent 和模型运行单个任务 uv run harbor trial start -p datasets/gso/task_id -a agent_name -m model_name单次运行的输出默认保存在trials/目录下可通过--trials-dir参数调整。该参数与默认行为在 src/harbor/cli/trials.py 中有明确实现--trials-dir的 help 文本即注明Directory to store trial results (default: ./trials)。手动生成任务目录Usage如果选择本地准备任务目录从适配器目录执行# 从适配器目录 cd adapters/gso # 方式一Python 直接运行 python run_adapter.py # 方式二uv 运行并指定输出目录、任务 ID 子集与数量上限 uv run run_adapter.py \ --output-dir ../../datasets/gso \ --task-ids id1 id2 \ --limit 50任务将写入datasets/gso/每个任务一个目录结构见上文生成的任务目录结构。CLI 参数在 run_adapter.py 中定义参数默认值说明--output-dirdatasets/gso仓库根下生成任务的写入目录--task-ids全部空格分隔的源任务 ID 列表--ids-file无每行一个源 ID 的文本文件#开头行视为注释忽略--limit无仅生成前 N 个任务运行前脚本会自动安装gsobench依赖优先uv pip install失败回退python -m pip install见 run_adapter.py。任务 ID 命名规则GSO 的源 ID如instance_123会被转换为 Harbor 本地任务 IDinstance_123 → gso-instance-123具体实现见 GSOAdapter.make_local_task_id()统一小写、下划线替换为连字符、前缀gso-。注册表中可见的实际命名如gso-numpy--numpy-09db9c7其中仓库名中的/被替换为__提交哈希作为后缀保证全局唯一且稳定。任务生成流程的源码级解析GSOAdapter 核心流程GSOAdapter 的generate_task()依次执行创建task_dir / local_task_id输出目录复制template/全部模板文件_copy_template按instance_id匹配数据记录执行_customize_task()做占位符替换。_customize_task()adapter.py的定制内容覆盖五个文件instruction.md替换{prob_script}性能测试脚本内容、{install_commands}清洗后的安装命令由get_install_commands过滤掉git clean -xfd、which python、python --version、uv venv等环境无关命令见 utils.py、{workspace_dir_name}repo中/替换为__environment/Dockerfile替换{docker_image}为slimshetty/gso:gso.eval.x86_64.{instance_id}预构建镜像小写化并替换工作区目录名task.toml写入固定资源配额4 CPU / 8192 MB 内存 / 10240 MB 存储tests/test.sh写入{instance_id}solution/solve.sh写入{patch}即该任务的专家补丁gt_difforacle 金标准。此外还会生成两个文件eval.sh调用get_eval_script()生成与gso_test_{N}.py调用apply_patches()从测试补丁还原出各测试脚本并做路径修正/gso_test_→/tests/gso_test_。task.toml任务资源与超时配置模板 task.toml 定义了任务的完整配置语义version 1.0 [metadata] author_name Manish Shetty, Naman Jain, Jinjian Liu, Vijay Kethanaboyina, Koushik Sen, Ion Stoica author_email manishsberkeley.edu difficulty hard category performance_optimization tags [optimization, python] [verifier] # 验证评测允许的最大时间秒 timeout_sec 3600 [agent] # Agent 完成任务允许的最大时间秒 timeout_sec 10800 [environment] # Docker 镜像构建允许的最大时间秒 build_timeout_sec 600 # 容器资源限制生成时由适配器写入 cpus {cpu_count} gpus 0 memory_mb {memory_mb} storage_mb {storage_mb}从配置可见 GSO 任务的定位difficulty hard、category performance_optimizationAgent 超时高达3 小时10800 秒验证超时 1 小时这是因为性能优化任务往往需要多次构建与重新计时。注意{cpu_count}、{memory_mb}、{storage_mb}是模板占位符由适配器在生成时替换为 4 / 8192 / 10240。instruction.mdAgent 任务说明模板 instruction.md 展示了任务的提示词设计先向 Agent 提供上传的代码仓库目录与示例测试脚本再给出四条核心指南只修改/workspace中非测试文件以提升test_script性能保持仓库与原始功能等价不要只针对test_script的特定输入过度优化应针对展示的使用场景做通用性能改进改动后可能需要重建仓库重建可能耗时需耐心等待。推荐的工作流程是先探索仓库结构 → 在/workspace创建复现计时脚本如test_opt.py→ 修改源码 → 用给定的{install_commands}重建并重新计时确认性能提升。Dockerfile预构建镜像 工具链模板 environment/Dockerfile 的关键点FROM {docker_image} ENV VIRTUAL_ENV/testbed/.venv ENV PATH/testbed/.venv/bin:$PATH ENV UV_NO_CACHE1 ENV PIP_NO_CACHE_DIR1 RUN set -eux; \ curl -LsSf https://astral.sh/uv/install.sh | UV_INSTALL_DIR/bin sh; \ mkdir -p /workspace; \ ln -sf /testbed /workspace/{workspace_dir_name}; \ ... uv venv /opt/gso-venv --python 3.12; \ uv pip install --python /opt/gso-venv/bin/python gsobench githttps://github.com/gso-bench/gso.git; \ rm -rf /root/.cache /tmp/*每个任务都基于 GSO 官方预构建的 x86_64 评测镜像镜像内通过符号链接把/testbed暴露为/workspace/{workspace_dir_name}并额外安装gsobench到独立的/opt/gso-venv供gso_evaluate.py评分使用。缓存全部关闭UV_NO_CACHE1、PIP_NO_CACHE_DIR1以保证构建确定性。solution/solve.shoracle 补丁应用template/solution/solve.sh 实现了一个健壮的apply_patch函数依次尝试git apply --verbose→git apply --ignore-space-change→git apply --reject→patch --batch --fuzz5 -p1四级回退并排除.venv/*、.git/*、__pycache__/*、*.egg-info/*及常见数据文件。随后把适配器注入的{patch}专家提交gt_diff写入/tmp/patch.diff并应用作为评测的参考解法。tests/test.sh从 Agent 改动提取补丁并驱动评测template/tests/test.sh 是验证入口职责包括对/testbed的改动做git add -A移除二进制文件用git diff --no-color --cached HEAD生成 Agent 的补丁/tmp/patch.diff并做 CRLF/二进制清理若补丁为空直接写reward.txt为0、result.json标记empty_patch并退出否则git reset --hard HEAD后执行/tests/eval.sh把输出写入/logs/verifier/test_output.txt调用/opt/gso-venv/bin/python /tests/gso_evaluate.py --instance-id {instance_id} --test-log ... --output ... --result ...完成评分。评分器 gso_evaluate.py 复用 GSO 原生的get_eval_report()输出状态机包括empty_patch、base_failed、patch_failed、test_failed、passed五种状态并产出opt_base、opt_commit、reward0/1与time_stats、opt_stats。Harbor 约定测试脚本必须把数值奖励写入/logs/verifier/reward.txt这一约定在 adapters/ADAPTER_CONTRIBUTING.md 中有完整说明GSO 适配器遵循相同约定。性能判定指标 Opt1精确语义Opt1是 GSO 的核心指标其精确判定规则如下原文出处adapters/gso/README.mdOpt1是单次 rollout 被判定达到专家优化标准的任务百分比。对每个任务harness 会对三个版本分别计时base commit基线、模型补丁版本、参考优化提交opt_commit专家提交。补丁必须先通过正确性/等价性检查即测试必须通过。满足以下条件才得到opt_baseTrue补丁比基线更快且对基线的几何平均加速比四舍五入保留一位小数至少为 1.2x。在opt_baseTrue基础上再满足对专家提交的调和平均加速比高于 0.95即达到专家性能的约 95% 以内才得到opt_commitTrue进而Opt1计为达标。该逻辑与 gso_evaluate.py 中opt_commit的读取与reward 1 if opt_commit else 0的映射完全对应。从源码可以进一步看到eval.sh的计时编排utils.py脚本依次执行基线计时 → 应用补丁后计时 → 输出两段结果 → 切换专家提交计时并通过对reset_repo_commands中的git remote add origin追加|| true做 fail-safe 处理、通过UV_BUILD_CONSTRAINT固定setuptools82为兼容 legacy setup.py 项目的pkg_resources、以及HF_HUB_DISABLE_XET1规避 HF Hub 服务端问题。为什么性能波动不可避免README 明确说明这是一个 wall-clock墙钟时间基准且采样量很小每个测试使用timeit且number1大多数仓库只重复 5 次重型仓库有时仅 1 次。CPU 负载、资源争抢或降频都可能让计时跨越 1.2x 或 0.95 这两个硬阈值从而翻转opt_commit与Opt1。这也是本文后面降低波动建议的由来。Parity 验证与原基准的一致性对比为了验证适配器没有改变评测语义作者用OpenHands1.4.0 gpt-5.1-2025-11-13 (high)在原始 GSO 基准与 Harbor 适配器两侧各跑 2 次完整 102 任务100% 采样结果如下AgentModelMetricNumber of RunsDataset SizeOriginal Benchmark PerformanceHarbor Adapter PerformanceOpenHands1.4.0gpt-5.1-2025-11-13 (high)Opt12102 tasks (100% of full set)13.7% ± 1.0%13.2% ± 1.5%两侧分数区间原始 13.7% ± 1.0% vs Harbor 13.2% ± 1.5%存在重叠按 adapters/ADAPTER_CONTRIBUTING.md 中定义的 Parity 匹配准则两侧 run 分数范围相交即视为匹配可以判定性能在原始版本与适配版本之间保持一致。细粒度运行数据记录在 parity_experiment.json 中{ agent: OpenHands1.4.0, model: gpt-5.1-2025-11-13 (high), adapted_benchmark_size: 102, parity_benchmark_size: 102, number_of_runs: 2, metrics: [ { benchmark_name: GSO, metric: Opt1, original: 13.7% ± 1.0%, harbor: 13.2% ± 1.5%, original_runs: [14.71, 12.75], harbor_runs: [14.71, 11.76] } ] }两侧的逐次运行分数original_runs/harbor_runs是核对依据其中±表示**样本标准误sample SEM**而非标准差计算方法为sqrt( Σ (xᵢ - x̄)² / (n(n-1)) )。此外 adapter_metadata.json 记录了该适配器的整体元数据adapted_benchmark_size、parity_benchmark_size、registry_benchmark_size均为 102parity_sampling_rate为 1.0Parity 实验成本约 600 美元。复现 Parity 实验在 Harbor 侧直接运行uv run harbor run -c adapters/gso/run_gso.yaml如需在原始基准一侧复现原作者使用的命令配置 OpenHands scaffold 并填充config.toml为[llm.test] model gpt-5.1 reasoning_effort highuv run \ --with openhands-ai githttps://github.com/OpenHands/OpenHands.git1.4.0 \ --project . \ python -m openhands_gso.run_infer \ --llm-config llm.test \ --config-toml ./config.toml \ --dataset gso-bench/gso \ --split test \ --max-iterations 150Parity 实验的配套环境变量为export OPENHANDS_AGENT_ENABLE_JUPYTERfalse export OPENHANDS_MAX_ITERATIONS150注意事项与已知边界Notes Caveats1. Oracle 并非 100% 通过GSO 的 oracle 运行在 Harbor harness 中不一定总能达到 100% 通过率因为部分任务的 oracle 相对基线在计时上存在不一致性。适配器作者的 oracle 测试结果为102 个任务中通过 89 个通过率 87.3%。因此在用 oracle 验证适配器时个别任务失败不应直接归因于适配错误而应先核对是否属于计时波动。2. 性能测量差异已知存在因运行时环境差异、测量随机性等因素导致的性能差异。由于这是 wall-clock 基准且采样数少timeit number1重复 5 次或重型仓库 1 次阈值附近的计时翻转会直接影响Opt1。3. 降低波动的实操建议为减少波动README 给出如下建议多次运行并取平均多跑几个 trial 后聚合结果使用资源充足的机器推荐 64 CPU、256GB RAM 的配置或使用 Daytona 等云运行时固定同一台机器所有运行与 Agent 对比尽量在同一机器上完成降低并发通过--n-concurrent减少并行度以降低资源争抢保持环境一致性确保运行期间没有其他重负载进程。安装与前置条件Docker已安装并处于运行状态Harbor已按主仓库 README 安装并可用Python 依赖uv sync --extra devAgent/模型 API 密钥以环境变量方式导出至少设置LLM_API_KEY与LLM_BASE_URLParity 实验专用环境变量export OPENHANDS_AGENT_ENABLE_JUPYTERfalse export OPENHANDS_MAX_ITERATIONS150故障排查如果使用 Daytona 云环境OpenHands 启动时偶发Connection refused错误此时只需重新运行该任务即可属瞬时连接问题非适配器缺陷。引用与致谢该适配器由 Harbor 团队的 Ruofan Lu 开发维护问题与贡献请提交至主仓库。如需引用 GSO 基准本身原作者给出的 BibTeX 条目如下inproceedings{ shetty2025gso, title{{GSO}: Challenging Software Optimization Tasks for Evaluating {SWE}-Agents}, author{Manish Shetty and Naman Jain and Jinjian Liu and Vijay Kethanaboyina and Koushik Sen and Ion Stoica}, booktitle{The Thirty-ninth Annual Conference on Neural Information Processing Systems Datasets and Benchmarks Track}, year{2025}, url{https://openreview.net/forum?idI5qDL315bQ} }Parity 实验的 API 推理算力由 2077AI 赞助支持。若希望进一步深入可继续阅读本仓库的 ADAPTER_CONTRIBUTING.mdHarbor 适配器完整规范任务命名、reward.txt约定、Parity 匹配准则与 SEM 报告格式以及 registry.jsonGSO 数据集的完整任务注册列表。赞分享【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载相关推荐Harbor 适配器实战将 SWE-bench Pro 多语言软件工程基准接入 Harbor 评估框架Harbor 适配器实战将 SWE bench Pro 多语言软件工程基准接入 Harbor 评估框架 SWE bench Pro 是覆盖 Python、JaHarbor BixBench 适配器实战把计算生物学智能体基准接入统一评测框架Harbor BixBench 适配器实战把计算生物学智能体基准接入统一评测框架 本文围绕 Harbor 仓库中 BixBench 适配器文档 https:/Eigent 基准测试 Harbor 适配器实战将 Eigent Bench 任务接入标准化 Agent 评估体系Eigent 基准测试 Harbor 适配器实战将 Eigent Bench 任务接入标准化 Agent 评估体系 本篇技术指南围绕开源仓库 Eigent 中人工智能AI Agent多智能体大模型本地部署MCP 服务桌面应用工作流自动化上一篇Ursa.Avalonia中文显示终极解决方案跨平台字体兼容完整指南下一篇PyTorch语义分割迁移学习技巧如何利用预训练模型加速开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考