【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载导读在 Harbor 中每个适配器的 parity 实验结果都需要沉淀到共享的 Hugging Face 数据集harborframework/parity-experiments并回填到该适配器的parity_experiment.json中作为可追溯的parity_pr证据。本篇以仓库中的官方技能文档 skills/upload-parity-experiments/SKILL.md 为主体完整讲解创建/复用数据集 PR → 稀疏检出 → 复制结果 → Git LFS 跟踪 → raw git push → 记录讨论 URL的六步工作流并深入到配套脚本 scripts/create_pr.py 与 adapters/ADAPTER_CONTRIBUTING.md 的字段规范帮助你以最快的速度、最少的数据传输量完成一次可复现、可审计的 parity 实验发布。为什么需要这个上传技能Harbor 仓库中 60 个适配器如 adapters/aa-lcr、adapters/swebench、adapters/gaia2 等都在目录内维护parity_experiment.json记录适配器与原版 benchmark 之间的 parity 对比结果。这些结果需要统一上传到 Hugging Face 数据集harborframework/parity-experiments以便跨适配器汇总、复现与审计。官方技能文档总结了几条促使该技能诞生的核心痛点hf upload-large-folder不可靠它通过 Hub API 的 commit 循环推送文件对于包含模型权重、轨迹日志等大体积的 parity 产物来说既慢又容易中途失败完整 clone 数据集代价过高harborframework/parity-experiments是共享大仓常规git clone会拉下大量与当前适配器无关的历史数据Hugging Face 数据集 PR ref 易误用HF 的 PR 引用形式refs/pr/number与 GitHub 的 PR ref 完全不同直接照搬 GitHub 习惯会出错10 MiB 以上文件必须走 Git LFS超出阈值的文件若未在提交前完成 LFS 跟踪push 会被 HF 拒绝。因此该技能采用只取 PR ref 只检出所需路径的策略通过--depth 1 --filterblob:none避免完整 clone用sparse-checkout只落地当前适配器需要的目录再以 rawgit push直接推送 PR ref。对于大体积 parity 包这比hf upload-large-folder更快、更可靠因为绕开了 API 侧的 commit 循环也不要求克隆整个 parity 数据集。前置条件Prereqs在开始之前需要确认以下三项Hugging Face 认证可用且具备 discussion 写权限既可以是 classicwrite权限的 token也可以是开启了全局discussion.write的 fine-grained token在 Hugging Face 账户的 token 设置页生成。只读或权限过窄的 token 会导致create_pr.py在调用create_pull_request时返回HTTP 403。数据集仓库固定除非用户明确要求其他仓库否则目标数据集始终为harborframework/parity-experiments。这一点在脚本里也做了固化——scripts/create_pr.py 中DEFAULT_REPO_ID harborframework/parity-experiments--repo-id参数默认指向它。本地上传源已就绪接受任意包含最终待发布文件的本地目录技能不关心这些文件是怎么生成的例如可来自harbor run的原始/parity/oracle 结果目录。工作流总览整个上传过程被拆成六步环环相扣创建或复用数据集 PR为 PR ref 准备一个稀疏的本地 worktree将本地 parity 结果复制进稀疏检出目录提交前确保所有大于 10 MiB 的文件都被 Git LFS 跟踪用 rawgit push直接推送到 PR ref分享讨论 URL并将其记录为该适配器的parity_pr。官方建议对于大型 parity 包优先使用 raw git 路径hf upload-large-folder仅在 raw git 不可用或用户明确要求时才作为回退方案。第 1 步创建或复用数据集 PR如果用户手上已经有了该适配器的 parity PR 编号直接复用不要重复创建这也是 Guardrails 中的明确要求——避免产生一串无意义的重复 PR。否则使用技能自带的辅助脚本创建。该脚本位于 scripts/create_pr.py通过uv run执行uv run python scripts/create_pr.py create-pr \ --title Add parity experiments for adapter_name \ --description-file /path/to/pr-description.md脚本执行成功后输出一段 JSON包含pr_number新创建的 PR 编号discussion_url该 PR 对应的讨论页面地址形如https://huggingface.co/datasets/repo_id/discussions/numberrepo_id目标数据集仓库 ID默认harborframework/parity-experimentstitlePR 标题。源码视角create_pr.py 如何工作从 create_pr 函数 可以看到核心调用只有一行api.create_pull_request(repo_id..., title..., description..., repo_typedataset)。也就是说Hugging Face 数据集的 PR 本质上是huggingface_hub.HfApi基于discussion机制创建的所以它返回的是discussion对象其num属性即 PR 编号discussion_url也正是由此拼接而成。理解这一点有助于避免把 GitHub PR ref 的用法套用到 HF 上。此外脚本对参数的约束也值得注意--description与--description-file二选一同时传会抛出ValueError见 _read_description--title为必填项--repo-id可覆盖默认值通常不建议除非用户明确要求发布到别的仓库。第 2 步准备稀疏 PR 检出在临时目录中初始化一个全新的 git 仓库只为目标 PR ref 做深度为 1、不带 blob的拉取并用 cone 模式的 sparse-checkout 限制到当前适配器目录mkdir -p /tmp/parity-experiments-prnumber cd /tmp/parity-experiments-prnumber git init git remote add origin githf.co:datasets/harborframework/parity-experiments git config core.sparseCheckout true git sparse-checkout init --cone git sparse-checkout set adapters/adapter_name git fetch --depth 1 --filterblob:none origin refs/pr/number:pr/number git checkout pr/number这段命令的关键点--filterblob:none是partial clone的核心fetch 时只拿 commit 和 tree不下载文件内容blob真正需要时才按需拉取--depth 1只保留最新一条提交历史git sparse-checkout set adapters/adapter_name让工作区只检出该适配器目录refs/pr/number:pr/number把远端 HF 的 PR ref 映射到本地分支名随后git checkout pr/number切到该分支。这样整体数据量被压缩到极致既不需要克隆完整的数据集仓库也不需要下载无关适配器的任何文件。第 3 步复制本地结果本地结果目录有两种常见形态处理方式不同如果本地目录已经包含完整的仓库根布局即最外层就是adapters/直接原样复制即可如果本地目录只有适配器子树内容则需要复制进adapters/adapter_name/下rsync -a --delete \ --exclude .git \ --exclude .cache \ --exclude .DS_Store \ /path/to/local-folder/ \ adapters/adapter_name/注意--delete会删除目标目录中源目录不存在的文件确保稀疏检出里的内容与本地结果完全一致同时通过--exclude排除.git、.cache、.DS_Store等不该进入数据集的文件。从适配器贡献规范 adapters/ADAPTER_CONTRIBUTING.md 可以看到一个完整的 parity 上传目录结构通常形如adapters/ └── {adapter_name}/ ├── README.md ├── config.yaml ├── original_parity/ ├── harbor_parity/ ├── oracle/ └── results_collection/ ├── result_{original/harbor}_trial1.json ├── result_{original/harbor}_trial2.json └── result_{original/harbor}_trial{N}.json即原始 benchmark 侧与 Harbor 侧的结果分目录存放每次 trial 的结果独立成文件——这也是第 4 步扫描大文件时需要覆盖的目录范围。第 4 步确保大文件使用 Git LFS数据集仓库根目录的.gitattributes已经对常见二进制、模型、压缩包和媒体扩展名做了 LFS 跟踪*.bin、*.parquet、*.safetensors、图片、音频、视频、*.log、*.txt等。绝大多数 parity 产物会自动被覆盖无需人工干预。但仍建议在提交前扫描一遍稀疏检出目录抓出任何超过 10 MiB 却漏网的文件python - PY from pathlib import Path for path in sorted(Path(.).rglob(*)): if path.is_file() and .git not in path.parts and path.stat().st_size 10 * 1024 * 1024: print(path) PY如果发现被标记的文件没有被仓库根规则覆盖就需要在适配器目录内追加 LFS 规则——绝不要改仓库根的.gitattributes因为它是所有 in-flight PR 共享的合并冲突高发区Guardrails 也明确禁止。正确做法是在适配器目录下执行git lfs track让规则以相对路径的形式写进adapters/adapter_name/.gitattributes(cd adapters/adapter_name git lfs track pattern) git add adapters/adapter_name/.gitattributesGit LFS 会优先遵循嵌套的.gitattributes文件因此这种方式添加的规则只作用于该适配器不会与其他并行中的 parity PR 产生冲突。第 5 步提交与推送清理掉平台无关的隐藏文件后提交并推送find . -name .DS_Store -delete git add adapters/adapter_name git commit -m Add parity experiment artifacts for adapter_name GIT_SSH_COMMANDssh -o ServerAliveInterval30 -o ServerAliveCountMax10 \ git push origin pr/number:refs/pr/number值得留意的是GIT_SSH_COMMAND中两个 SSH 保活参数ServerAliveInterval30每 30 秒向服务器发送一次 keepalive 探测ServerAliveCountMax10连续 10 次探测无响应才判定连接断开。大体积 parity 包的 push 往往耗时很长这两个参数能在长传输过程中有效降低 SSH 连接被中间设备静默掐断的概率。推送的目标 ref 是refs/pr/number——这正是 Hugging Face 数据集 PR 的标准引用形式与 GitHub 的refs/pull/n/head完全不同不要混淆。第 6 步记录讨论 URL推送成功后把该 PR 的讨论 URL 写入适配器的parity_experiment.json的parity_pr字段。URL 格式固定为https://huggingface.co/datasets/harborframework/parity-experiments/discussions/number仓库内已有真实范例可对照在 adapters/aa-lcr/parity_experiment.json 中parity_pr的取值正是[https://huggingface.co/datasets/harborframework/parity-experiments/discussions/231]四条 agentmodel 记录共用同一个 PR 编号。根据 adapters/ADAPTER_CONTRIBUTING.md 的字段规范parity_pr的类型是string[]必填表示指向 HuggingFace parity 数据集的所有 PR 链接。同一适配器的完整 parity 记录结构大致如下外部链接以占位符示意[ { adapter_name: my-benchmark, agent: codex1.0, model: gpt-5-2025-06-01, date: 2025-06-15, adapted_benchmark_size: 500, parity_benchmark_size: 500, number_of_runs: 3, notes: None, original_parity_repo: original-benchmark-fork-url, adapter_pr: [adapter-pr-url], dataset_pr: [dataset-pr-url], parity_pr: [https://huggingface.co/datasets/harborframework/parity-experiments/discussions/number], metrics: [ { benchmark_name: my-benchmark, metric: pass1, original: 45.2 ± 1.3, harbor: 44.8 ± 1.1, original_runs: [44.0, 45.5, 46.1], harbor_runs: [43.8, 45.0, 45.6] } ] } ]按贡献规范original与harbor应报告为mean ± sample SEM并与原始original_runs/harbor_runs数组保持一致同时建议在适配器 README 中附上 parity 汇总表并包含指向原版 benchmark 仓库、fork 仓库、数据集 PR、HuggingFace parity PR 与适配器 PR 的链接。监控与重试rawgit push运行期间先看实时输出。大型推送通常会长时间停留在以下阶段之一git-lfs pre-pushLFS 预推送钩子扫描待上传对象单个 LFS 对象的上传大文件逐一走 HTTPS 分块上传packfile 压缩非 LFS 内容打包。两个实用的检查手段git ls-remote githf.co:datasets/harborframework/parity-experiments refs/pr/numberps -p pid -o pid,etime,commandgit ls-remote用于确认 PR ref 在远端的最新状态是否已收到提交ps用于观察正在执行的 git/LFS 子进程及其已运行时长判断推送是否仍在推进。如果 push 提前退出按以下顺序处理先原样重跑同一条git push命令——绝大多数瞬时失败网络抖动、服务端临时错误重跑即可恢复如果 Hugging Face 拒绝了某个大于 10 MiB 的文件说明该文件未被 LFS 跟踪补上对应的git lfs track规则重新git add该文件后重试如果连接在推送中途断开同样先重跑同一条 push 命令再做其他改动。备用方案hf upload-large-folder仅当 raw git 不可用或用户明确要求时才回退到hf upload-large-folder。仍然可以用配套脚本先创建 PR然后把文件上传到该 PR 的 revisionhf upload-large-folder harborframework/parity-experiments \ local-folder \ --repo-type dataset \ --revision refs/pr/pr-number \ --exclude .DS_Store \ --exclude **/.DS_Store \ --num-workers 8关键参数说明--repo-type dataset明确目标为数据集仓库而不是 model 或 space--revision refs/pr/pr-number上传目标是 PR revision而非默认分支--exclude双重排除.DS_Store顶层与任意子目录与主流程中的find . -name .DS_Store -delete目的一致--num-workers 8并行上传的 worker 数可结合带宽调整。Guardrails不可逾越的红线技能文档明确列出以下行为约束务必遵守不要误上传 Harbor 仓库本身只上传预期的本地结果目录不要回退到harborframework/parity-experiments的完整 clone稀疏检出 partial clone 是底线不要修改仓库根.gitattributes适配器专属 LFS 规则一律写入adapters/adapter_name/.gitattributes始终移除或排除.DS_Store推送前确认所有大于 10 MiB 的文件都已 LFS 跟踪用户已有 parity PR 编号时直接复用不要重复创建。与 Harbor 适配器贡献流程的衔接这个技能并非孤立存在它是适配器贡献流水线的最后一环。在 adapters/ADAPTER_CONTRIBUTING.md 中上传环节被定义为Step 7Upload Parity Results在 Step 6 完成parity_experiment.json的填写所有必填字段、mean ± sample SEM报告格式、run-score 区间重叠判定之后将 original/oracle 结果按规范目录结构上传到harborframework/parity-experiments并提交数据集 PR——贡献规范明确推荐使用本技能因为它处理了稀疏检出、LFS 跟踪与 HF 特有的 PR ref。上传完成后parity_pr等字段会随parity_experiment.json进入汇总链路仓库脚本 scripts/generate_parity_summary.py 会扫描所有适配器的parity_experiment.json解析original/harbor分数与original_runs/harbor_runs数组生成 adapters/parity_summary.csv。也就是说一次规范的上传不仅让结果可复现、可审计也直接支撑了 Harbor 全仓库 parity 结果的统一汇总与对比。赞分享【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载相关推荐离线语音合成新境界ChatTTS-ui无网络部署实战指南离线语音合成新境界ChatTTS ui无网络部署实战指南 在网络安全日益重要的今天离线语音合成系统成为许多场景的刚需。想象一下在涉密实验室里你需要将技术人工智能AI 技能/插件大模型AI 评测JSON Formatter 核心功能解析折叠导航与悬停预览技巧JSON Formatter 核心功能解析折叠导航与悬停预览技巧 JSON Formatter 是一款轻量级纯 JavaScript 工具能够将 JSON前端UI组件Harbor 任务与数据集发布指南使用 harbor publish 将 Task 和 Dataset 上传至 RegistryHarbor 任务与数据集发布指南使用 harbor publish 将 Task 和 Dataset 上传至 Registry 本篇技术指南围绕 Harbo上一篇iStoreOS固件升级核心流程从安全备份到系统验证的三步实战手册下一篇GoldHEN金手指管理器PS4游戏修改的终极完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考