oh-my-pi metaharness统一 Harbor、TypeScript edit 与 SnapCompact 的基准评测管理平台【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pipackages/metaharnessoh-my-pi/pi-metaharness是 oh-my-pi 的基准评测管理中枢benchmark harness它把 Harbor、TypeScript edit 与 SnapCompact 三类完全不同的评测任务统一进同一套experiment → run → trace数据模型用一份 SQLite 存储、一套 REST/SSE API 和一个实时 Web 仪表盘统一管理。阅读本文后你将掌握如何用bun run serve一键启动评测仪表盘与 API、通过POST /api/runs从同一张表单发起任意 benchmark、理解 Harbor 评测在容器内的三条关键设计本地源码挂载、凭据不进入容器、Harbor 拥有 trial并能使用bench:tb在 Vibemon KVM 微虚拟机上运行原生 Terminal-Bench 2.1以及用trace-report把单次 run 的 trace 转成可读的叙事性 Markdown 报告。一个 Manager 统一三类 Benchmark在 oh-my-pi 的评测体系里metaharness解决的核心问题是不同 benchmark 的原生产物格式完全不同但评测者关心的东西是一致的——进度、分数、token 消耗、成本与 trace。因此它引入了统一的抽象层experiment一次评测目标goal按 job 名前缀分组sb2-n8、sb2-gemini都归入 experimentsb2多个 arm 共享同一任务样本以便横向对比run一次具体的评测运行对应磁盘上的一个 job 目录tracerun 内每个 trial 的归一化轨迹。benchmark 原生的产物仍然保留在磁盘上adapter 负责把它们规范化为统一的 run 行、trial 行与指标。三种内置 benchmark 的指标定义见 benchmarks.tsBenchmarkLabel指标harborHarborsuccess_rate成功率percenteditTypeScript edittask_success_rate、edit_success_ratesnapcompactSnapCompactf1、exact_match指标定义带formatpercent/number/usd与higherIsBetter语义存储层与 UI 不硬编码任何 benchmark 语义因此新增 benchmark 只需新增一个 adapter。启动整个服务Dashboard API端口 4700只需一行命令bun run serve --port 4700所有 benchmark 都可以从同一个 new run 表单发起。对应脚本定义在 package.jsonserve/bench:edit/bench:tb/bench:tb-floor/dev/test。Harbor 评测的三条执行主线README 明确了 Harbor run 在 oh-my-pi 中的执行方式结合 runner.ts 的源码可以还原完整链路metaharnessrunner 进程src/runner.ts负责组装harbor run命令、注入环境变量、渲染实时仪表盘并最终写出报告。1. 本地 omp而非 npm默认情况下 runner 将仓库只读 bind-mount进每个任务容器--install source直接运行packages/coding-agent/src/cli.ts中的 omp——也就是说TypeScript 改动在下一个 trial 立即生效无需重新构建。其实现细节在prepareSourceDepsrunner.ts首次运行时或 lockfile 变化时runner 会在jobs-dir/_bench/_deps/下用oven/bun:版本镜像构建一份缓存的linuxnode_modules骨架树bun install --production --ignore-scripts用来遮蔽宿主机 darwin 平台的那一份同时把镜像里的 linuxbun二进制挂到/opt/omp/bin。这套缓存的构建用 manifest lockfile 的 sha256 指纹sourceDepsStamp决定是否需要重建TS 改动永远不会使其失效因此 trial 初始化阶段零出网。两种替代方案--install local每次 run 用bun pm pack打一个 tarballbuildTarball见 runner.ts--binary使用预构建的dist/omp-linux-*自包含二进制文件名需含arm64/x64以便推断架构见 runner.ts。2. 凭据永不进入容器生成的models.yml把 provider 的baseUrl全部指向宿主机 pm2 上的 auth-gateway凭据由网关在宿主机侧解析。writeModelsYamlrunner.ts为每个 provider 生成baseUrl: gateway-url、auth: oauth、transport: pi-native的配置runner 启动前还会对网关做一次/healthz健康检查gatewayHealthOk。在 Apple Container 环境下由于没有host.docker.internalrunner 会启动一个192.168.64.1:4000 → 127.0.0.1:4000的反向转发startVmnetGatewayForward见 runner.ts保证容器内只能访问到网关而接触不到真实密钥。如果你确实想直接把宿主机 provider key 传进容器可用--no-gateway。3. Harbor 拥有 trialsrunner/serve 层不干预 trial 的执行而是轮询每个 trial 的result.json获取进度、花费与结果。运行期间 runner 会渲染一个实时终端仪表盘进度条 / pass% / spend / tokens / ETA见 runner.ts对于仍在运行的 trial还会增量解析其agent/omp.txtJSONL 日志来实时累计 token 与成本probeTrialCost见 runner.ts只读取新增字节、跳过超大行避免大日志阻塞事件循环。ServerREST SSE API 全览服务入口是 src/server.tsbun run src/server.ts [--port 4700] [--jobs-dir path]。启动时执行discover()自动发现历史 CLI run 目录并回填为数据库行与syncAll()随后每 2 秒同步一次运行中的 runsyncActive并通过 SSE 广播 run 列表快照。完整端点清单实现见 server.ts方法路径说明GET/实验、run、归一化 trace以及所有 benchmark 的发起表单Web DashboardBun 直接打包 React/TSX单进程无 ViteGET/api/experiments[?q]跨所有 benchmark 类型的实验摘要q按 id/goal 子串过滤POST/api/experiments在第一个 arm 之前注册实验Body{ id: sb2, goal: ... }id 是无横线的 tokenjob 名按它分组sb2-n8→ experimentsb2GET/api/experiments/:idarm 列表、按任务的矩阵matrix以及校准投影PUT/api/experiments/:id更新 goal 与每个 run 的 role/note/labelPOST/api/experiments/:id/arms发起一个可对比的新 arm样本与配置从同级 arm 继承DELETE/api/experiments/:id删除所有 armDB 行和job 目录以及 goal 行有 arm 运行中时拒绝GET/api/runs[?experimentstatusbenchmark]统一 run 行benchmark、score、progress、spend、tokensPOST/api/runs通过 benchmark adapter 发起 runGET/api/runs/:name{ run, traces }读取时同步磁盘上的原生产物POST/api/runs/:name/cancel取消 manager 发起的 runDELETE/api/runs/:name永久删除已结束的 runDB 行 job 目录残留目录会在重启时被discover()重新发现运行中拒绝POST/api/runs/:name/resume原地恢复未完成的 Harbor run见下节GET/api/runs/:name/traces/:trace[?raw1]归一化或原生 traceGET/api/eventsSSE 流run 列表快照变化时推送POST /api/runs 的请求体发起任何 benchmark 的 run 使用统一的请求体{ benchmark: edit, model: anthropic/claude-opus-4-8, tasks: 20, concurrency: 4, attempts: 2, jobName: edit-baseline, role: baseline, goal: compare edit strategies }benchmark取harbor、edit或snapcompact之一各自的专属字段不同Harbor使用dataset、include、timeoutMultiplier、prewalkedit使用include作为任务 ID 列表SnapCompact使用conditions且tasks被当作段落数上限--limit-paras。请求体与 Harbor runner CLI argv 的映射逻辑在 launch-args.ts显式include列表就是样本本身不会被默认任务数截断prewalk会转换成--agent-arg --prewalk [--prewalk-into model]并自动补上--providersprebuiltBinaries会自动查找并传入dist/omp-linux-arm64/omp-linux-x64。三种 benchmark 的启动命令组装见ManagerServer.launchserver.tsedit 走adapters/edit/cli.tssnapcompact 走uv run src/adapters/snapcompact.pyharbor 走bun src/runner.ts。job 名缺省时按model-slug-timestamp生成并要求是单段安全 token防止路径逃逸见 server.ts。状态存储与恢复所有状态落在jobs-dir/_manager/metaharness.sqlite默认repo/runs/harbor见 server.ts。文件系统始终是事实来源——Harbor 每 job 每 trial 写result.jsonSQLite 只是镜像成可查询行并补充 manager 自有元数据启动 pid、请求的 config、生命周期状态。存储层实现见 store.ts三张表runs/trials/experiments启用 WAL journal 并对SQLITE_BUSY重试enableWalsyncRun会按磁盘快照 upsert trial 行、清除消失的 trial 幽灵行并对无主进程的 run 用result.json的finishedAt或目录新鲜度推断终态。历史 CLI run 会被自动发现discover()store.ts扫描 jobs 目录下没有 DB 行的子目录跳过_bench、_manager从config.json尽力回填 dataset/agent/models 后插入为running行再同步。Resume原地恢复未完成的 Harbor runPOST /api/runs/:name/resume只支持 Harbor run。已完成 trial及其花费会被复用被中断/挂起的 trial 重跑出错 trial 重试。请求体{ filterErrorTypes: [...] }可覆盖重试集合缺省时默认重试 job 的result.json里记录的所有异常类型reward-0 的失败是已决结果不会被重试。runner 从_bench/name/runner-config.json启动时快照的完整 Config或该 run 的manager.json恢复原始启动参数——无需重新指定任何 flagresolveResumeConfig见 runner.ts。resume 命令本身为harbor job resume -p jobDir且CancelledError恒被加入重试集合见buildResumeArgsrunner.ts。取消采用SIGTERM 优先、5 秒后 SIGKILL 升级的策略server.ts确保 runner 能把信号转发给 Harbor 子进程避免直接 SIGKILL 把 harbor 变成孤儿继续写 job 目录。实验对比与校准投影实验层在 experiments.tsjob 名的第一个-前的 token 即 experiment idexperimentOf新增 arm 时resolveArmLaunchserver.ts从样本最完整的同级 arm 继承 benchmark、dataset 与精确任务样本记录的include否则从该 arm 的 trial 任务反推从而保证 arm 之间直接可比。-fix/-backfill/-retry等重跑后缀会被折叠进基础 armcanonicalArmOf每任务取已决优先、最新优先的 trialpickMergedTrials。对仍在运行的 arm除了线性投影外实验详情页还会给出按难度校准的最终通过率投影calibratedFinalPassPctexperiments.ts把所有同级 arm 的结果当作每个任务的难度信号smoothed pass rate对当前 arm 拟合一个 log-odds 技能偏移再对剩余任务打分——避免已决子集碰巧全是简单任务导致 100% 的乐观误报。原生 Terminal-Bench 2.1 Runnerbench:tbbench:tb是独立于 Harbor 和 Docker 的另一种运行方式它把每个任务发布的 OCI 镜像作为 x86_64 KVM 微虚拟机microVM启动在 Vibemon 宿主机上通过vmon exec --pipe流式传输 omp 的--mode rpc协议在同一个被修改的 VM 里运行 verifier并把可恢复的 epoch 与产物写入runs/tb。实现位于 src/tb/cli、agent、dataset、store、trial、vmon、types 各司其职。bun run bench:tb \ --dataset /path/to/terminal-bench-2-1 \ --concurrency 4 --forever --budget 25工作站默认值的可恢复包装器对于 README 中说明的实测工作站默认值七模型池、:floor、concurrency 20使用可恢复的包装脚本bun --cwd packages/metaharness run bench:tb-floor它写入runs/tb-floor重复运行会恢复未完成的 epoch或在完成后开启下一个 epoch。环境变量覆盖TB_JOBS_DIR、TB_CONCURRENCY、TB_DATASET、TB_BUDGET_USD、TB_ATTEMPTS、TB_FOREVER1。额外 CLI flag 会透传并优先于包装器默认值。默认模型池与 OpenRouter 路由默认七模型池源码FLASH_POOL见 tb/cli.tsLing 3.0 FlashDeepSeek V4 Flash 两个路由0731 与未版本化/0423Nemotron 3.5 LightningLaguna S 2.1Tencent Hy3Step 3.7 Flash全部通过 OpenRouter 访问。请求默认使用 OpenRouter 的:floor最便宜 provider路由用--openrouter-variant default|nitro|online|exacto覆盖。用重复的--model provider/id替换整个模型池。基础设施参数默认目标为工作站的xeon.internalKVM 宿主与本地/work/vibevmmcheckout--vmon-url默认http://xeon.internal:17970。runner 在远端副本缺少 raw pipe 支持时会交叉构建并缓存打过补丁的vmon二进制运行期间自持一个特权 TAP broker并把回环的 omp auth 网关反向隧道化确保 provider 凭据永不进入任务 VM。trial agent 使用精简的终端工具 allowlist、edit.mode: replace与低成本的openrouter/qwen/qwen3.7-flashvision 角色benchmark prompt 中省略通用编排工具。基础设施覆盖参数--vmon-host --vmon-source --vmon-bin --vmon-home --vmon-kernel --vmon-agent --gateway-url完整参数表见 tb/cli.ts 的 HELP 文本。Harbor Runner 参数一览节选下表完整摘自 README配合 runner.ts 的 HELP 文本使用选项默认值说明-m, --model provider/modelanthropic/claude-sonnet-4-6可重复-l, --tasks N20最大任务数-n, --concurrency N4并发 trial 数-k, --attempts N1每任务尝试次数passk-d, --dataset nameterminal-bench2.0任意 Harbor dataset id-i/-x, --include/--exclude glob—任务过滤器可重复--timeout-multiplier x—缩放任务 agent/verifier 超时--agent-arg arg—原样转发给容器内 omp CLI 的额外参数可重复--env KEY[VALUE]—转发环境变量进 omp 容器可重复仅KEY时转发宿主值--binary path—预构建 omp 二进制arm64x64 各重复一次--install source\|local\|publishedsourcesource 仓库 bind-mountlocal tarball 打包published npmoh-my-pi/pi-coding-agent--environment docker\|apple-containerdockerapple-container用 Apple 的containerCLI 跑 trial无需 Dockersource/deps 挂载走harbor --mounts网关从192.168.64.1:4000自动转发到回环绑定的网关--gateway-url urlhttp://host.docker.internal:4000--environment apple-container下为http://192.168.64.1:4000--no-gateway关闭直接把宿主 provider key 传进容器-o, --jobs-dir pathrepo/runs/harbor与 server 共享--resume name\|path—通过harbor job resume恢复该 job 目录原始参数自动恢复--filter-error-type TCancelledError配合--resume对异常类型为T的已完成 trial 也重跑可重复--dry-run关闭打印 harbor 命令 models.yml 后退出补充说明源码层面环境变量注入规则见collectForwardEnv/buildHarborEnvrunner.ts所有宿主PI_*变量除目录/profile/session 等容器敌意白名单外自动转发显式--env始终优先配置与密钥通过OMP_BENCH_*环境变量传给agent/omp_local.py--thinking level可取off|minimal|low|medium|high|xhigh|max--web-search默认关闭无法经网关鉴权docker 后端还提供--cleanup安全清理退出/已建的 Harbor 容器与空闲 trial 网络与--cleanup-force强停并删除所有Harbor 容器与网络以及实验性的--host-network--install source是单架构的deps 树与 docker daemon 原生架构一致仿真镜像如 arm64 宿主跑 x64 任务会在 setup 阶段以架构不匹配报错此类场景应改用--binary。输出产物一次 Harbor run 结束后磁盘上会产生以下产物完整清单见 READMEjobs-dir/jobName/—— Harbor trial 目录每 trial 一个result.jsonjobs-dir/_bench/jobName/report.md—— markdown 汇总表数据集 / 模型 / tasks/attempts/concurrency / install 模式 / 通过率 / spend / tokens / 逐任务表生成逻辑见writeReportrunner.tsjobs-dir/_bench/jobName/harbor.log—— Harbor 完整输出jobs-dir/_manager/logs/jobName.log—— API 发起 run 的 runner 输出。此外--dry-run会打印将要执行的 harbor 命令、生成的models.yml与注入的 omp 环境变量值隐藏方便上线前核对配置。Trace 报告把一次 run 变成叙事文档scripts/trace-report.ts把单次 run 的 trace 转成叙事性 markdown 报告带编号的 Turn Log每个 assistant 回合配一句有依据的摘要harness notice 保留原位、Story Arc以及失败 run 的 failure analysis。它通过两个便宜的 OpenRouter 模型对归一化 trace 做 map/reduce默认每回合inclusionai/ling-2.6-flash、arc 用openai/gpt-oss-120b约 $0.001/报告API key 通过 omp 的 auth storage 解析。bun scripts/trace-report.ts run trace [--focus reviewer notes] [--out report.md] bun scripts/trace-report.ts sb3-ntg|django__django-12325__ddQroP4 # run|trace 也支持Flags--baseserver 地址默认http://localhost:4700、--tiny/--synthprovider/model-id覆盖、--focus额外 reviewer 上下文例如失败任务的已知正确修复、--concurrency默认 8。Caveats使用边界与注意事项网络策略Harbor 本地 Docker 后端只支持publicregistry任务容器经宿主网关访问模型。--install source即时反映本地 TS 改动无需重建但 Rust natives 从树内packages/natives/native/pi_natives.linux-*.nodeprebuild 加载——Rust 有改动时必须先重建workspace 加载会跳过版本 sentinel陈旧的.node会静默运行。source 模式是单架构的deps 树匹配 docker daemon 原生架构仿真镜像上的 trial 会以架构不匹配失败请改用--binary。source 模式下仓库在任务容器内可见只读对精选 benchmark 没问题但不要指向不受信任的任务。Apple Container 特例--environment apple-container需要brew install container container system startmacOS 26Apple silicon--host-network与--cleanup*仅限 dockerbind mount 是读写模式后端忽略read_only。--install local反映本地 TS 改动内联进dist/cli.js但不含未提交的 Rust natives——先按目标平台重建packages/natives版本 sentinel 必须匹配。相关测试与进一步阅读服务端 API、launch/resume/删除语义与实验分组均有对应测试test/server 相关用例、experiments.test.ts、manager.test.ts、runner.test.tsTB runner 测试tb-cli.test.ts、tb-dataset.test.ts、tb-store.test.tsHarbor 侧的容器内 agent 实现agent/omp_local.pyedit 基准的 adapter 与提示词在 adapters/edit/含 benchmark-task/system/retry 提示词与 runnerSnapCompact adapter 为 src/adapters/snapcompact.py。整体上metaharness把跑评测、看进度、对指标、出报告这条链路收敛到了一个服务里无论评测来源是 Harbor 容器、TypeScript edit 还是 SnapCompact 段落检索最终都以统一的 run 行、trial 矩阵与 trace 呈现历史 CLI run 也能被自动发现并纳入同一套查询与可视化体系。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-pi metaharness：统一 Harbor、TypeScript edit 与 SnapCompact 的基准评测管理平台
oh-my-pi metaharness统一 Harbor、TypeScript edit 与 SnapCompact 的基准评测管理平台【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pipackages/metaharnessoh-my-pi/pi-metaharness是 oh-my-pi 的基准评测管理中枢benchmark harness它把 Harbor、TypeScript edit 与 SnapCompact 三类完全不同的评测任务统一进同一套experiment → run → trace数据模型用一份 SQLite 存储、一套 REST/SSE API 和一个实时 Web 仪表盘统一管理。阅读本文后你将掌握如何用bun run serve一键启动评测仪表盘与 API、通过POST /api/runs从同一张表单发起任意 benchmark、理解 Harbor 评测在容器内的三条关键设计本地源码挂载、凭据不进入容器、Harbor 拥有 trial并能使用bench:tb在 Vibemon KVM 微虚拟机上运行原生 Terminal-Bench 2.1以及用trace-report把单次 run 的 trace 转成可读的叙事性 Markdown 报告。一个 Manager 统一三类 Benchmark在 oh-my-pi 的评测体系里metaharness解决的核心问题是不同 benchmark 的原生产物格式完全不同但评测者关心的东西是一致的——进度、分数、token 消耗、成本与 trace。因此它引入了统一的抽象层experiment一次评测目标goal按 job 名前缀分组sb2-n8、sb2-gemini都归入 experimentsb2多个 arm 共享同一任务样本以便横向对比run一次具体的评测运行对应磁盘上的一个 job 目录tracerun 内每个 trial 的归一化轨迹。benchmark 原生的产物仍然保留在磁盘上adapter 负责把它们规范化为统一的 run 行、trial 行与指标。三种内置 benchmark 的指标定义见 benchmarks.tsBenchmarkLabel指标harborHarborsuccess_rate成功率percenteditTypeScript edittask_success_rate、edit_success_ratesnapcompactSnapCompactf1、exact_match指标定义带formatpercent/number/usd与higherIsBetter语义存储层与 UI 不硬编码任何 benchmark 语义因此新增 benchmark 只需新增一个 adapter。启动整个服务Dashboard API端口 4700只需一行命令bun run serve --port 4700所有 benchmark 都可以从同一个 new run 表单发起。对应脚本定义在 package.jsonserve/bench:edit/bench:tb/bench:tb-floor/dev/test。Harbor 评测的三条执行主线README 明确了 Harbor run 在 oh-my-pi 中的执行方式结合 runner.ts 的源码可以还原完整链路metaharnessrunner 进程src/runner.ts负责组装harbor run命令、注入环境变量、渲染实时仪表盘并最终写出报告。1. 本地 omp而非 npm默认情况下 runner 将仓库只读 bind-mount进每个任务容器--install source直接运行packages/coding-agent/src/cli.ts中的 omp——也就是说TypeScript 改动在下一个 trial 立即生效无需重新构建。其实现细节在prepareSourceDepsrunner.ts首次运行时或 lockfile 变化时runner 会在jobs-dir/_bench/_deps/下用oven/bun:版本镜像构建一份缓存的linuxnode_modules骨架树bun install --production --ignore-scripts用来遮蔽宿主机 darwin 平台的那一份同时把镜像里的 linuxbun二进制挂到/opt/omp/bin。这套缓存的构建用 manifest lockfile 的 sha256 指纹sourceDepsStamp决定是否需要重建TS 改动永远不会使其失效因此 trial 初始化阶段零出网。两种替代方案--install local每次 run 用bun pm pack打一个 tarballbuildTarball见 runner.ts--binary使用预构建的dist/omp-linux-*自包含二进制文件名需含arm64/x64以便推断架构见 runner.ts。2. 凭据永不进入容器生成的models.yml把 provider 的baseUrl全部指向宿主机 pm2 上的 auth-gateway凭据由网关在宿主机侧解析。writeModelsYamlrunner.ts为每个 provider 生成baseUrl: gateway-url、auth: oauth、transport: pi-native的配置runner 启动前还会对网关做一次/healthz健康检查gatewayHealthOk。在 Apple Container 环境下由于没有host.docker.internalrunner 会启动一个192.168.64.1:4000 → 127.0.0.1:4000的反向转发startVmnetGatewayForward见 runner.ts保证容器内只能访问到网关而接触不到真实密钥。如果你确实想直接把宿主机 provider key 传进容器可用--no-gateway。3. Harbor 拥有 trialsrunner/serve 层不干预 trial 的执行而是轮询每个 trial 的result.json获取进度、花费与结果。运行期间 runner 会渲染一个实时终端仪表盘进度条 / pass% / spend / tokens / ETA见 runner.ts对于仍在运行的 trial还会增量解析其agent/omp.txtJSONL 日志来实时累计 token 与成本probeTrialCost见 runner.ts只读取新增字节、跳过超大行避免大日志阻塞事件循环。ServerREST SSE API 全览服务入口是 src/server.tsbun run src/server.ts [--port 4700] [--jobs-dir path]。启动时执行discover()自动发现历史 CLI run 目录并回填为数据库行与syncAll()随后每 2 秒同步一次运行中的 runsyncActive并通过 SSE 广播 run 列表快照。完整端点清单实现见 server.ts方法路径说明GET/实验、run、归一化 trace以及所有 benchmark 的发起表单Web DashboardBun 直接打包 React/TSX单进程无 ViteGET/api/experiments[?q]跨所有 benchmark 类型的实验摘要q按 id/goal 子串过滤POST/api/experiments在第一个 arm 之前注册实验Body{ id: sb2, goal: ... }id 是无横线的 tokenjob 名按它分组sb2-n8→ experimentsb2GET/api/experiments/:idarm 列表、按任务的矩阵matrix以及校准投影PUT/api/experiments/:id更新 goal 与每个 run 的 role/note/labelPOST/api/experiments/:id/arms发起一个可对比的新 arm样本与配置从同级 arm 继承DELETE/api/experiments/:id删除所有 armDB 行和job 目录以及 goal 行有 arm 运行中时拒绝GET/api/runs[?experimentstatusbenchmark]统一 run 行benchmark、score、progress、spend、tokensPOST/api/runs通过 benchmark adapter 发起 runGET/api/runs/:name{ run, traces }读取时同步磁盘上的原生产物POST/api/runs/:name/cancel取消 manager 发起的 runDELETE/api/runs/:name永久删除已结束的 runDB 行 job 目录残留目录会在重启时被discover()重新发现运行中拒绝POST/api/runs/:name/resume原地恢复未完成的 Harbor run见下节GET/api/runs/:name/traces/:trace[?raw1]归一化或原生 traceGET/api/eventsSSE 流run 列表快照变化时推送POST /api/runs 的请求体发起任何 benchmark 的 run 使用统一的请求体{ benchmark: edit, model: anthropic/claude-opus-4-8, tasks: 20, concurrency: 4, attempts: 2, jobName: edit-baseline, role: baseline, goal: compare edit strategies }benchmark取harbor、edit或snapcompact之一各自的专属字段不同Harbor使用dataset、include、timeoutMultiplier、prewalkedit使用include作为任务 ID 列表SnapCompact使用conditions且tasks被当作段落数上限--limit-paras。请求体与 Harbor runner CLI argv 的映射逻辑在 launch-args.ts显式include列表就是样本本身不会被默认任务数截断prewalk会转换成--agent-arg --prewalk [--prewalk-into model]并自动补上--providersprebuiltBinaries会自动查找并传入dist/omp-linux-arm64/omp-linux-x64。三种 benchmark 的启动命令组装见ManagerServer.launchserver.tsedit 走adapters/edit/cli.tssnapcompact 走uv run src/adapters/snapcompact.pyharbor 走bun src/runner.ts。job 名缺省时按model-slug-timestamp生成并要求是单段安全 token防止路径逃逸见 server.ts。状态存储与恢复所有状态落在jobs-dir/_manager/metaharness.sqlite默认repo/runs/harbor见 server.ts。文件系统始终是事实来源——Harbor 每 job 每 trial 写result.jsonSQLite 只是镜像成可查询行并补充 manager 自有元数据启动 pid、请求的 config、生命周期状态。存储层实现见 store.ts三张表runs/trials/experiments启用 WAL journal 并对SQLITE_BUSY重试enableWalsyncRun会按磁盘快照 upsert trial 行、清除消失的 trial 幽灵行并对无主进程的 run 用result.json的finishedAt或目录新鲜度推断终态。历史 CLI run 会被自动发现discover()store.ts扫描 jobs 目录下没有 DB 行的子目录跳过_bench、_manager从config.json尽力回填 dataset/agent/models 后插入为running行再同步。Resume原地恢复未完成的 Harbor runPOST /api/runs/:name/resume只支持 Harbor run。已完成 trial及其花费会被复用被中断/挂起的 trial 重跑出错 trial 重试。请求体{ filterErrorTypes: [...] }可覆盖重试集合缺省时默认重试 job 的result.json里记录的所有异常类型reward-0 的失败是已决结果不会被重试。runner 从_bench/name/runner-config.json启动时快照的完整 Config或该 run 的manager.json恢复原始启动参数——无需重新指定任何 flagresolveResumeConfig见 runner.ts。resume 命令本身为harbor job resume -p jobDir且CancelledError恒被加入重试集合见buildResumeArgsrunner.ts。取消采用SIGTERM 优先、5 秒后 SIGKILL 升级的策略server.ts确保 runner 能把信号转发给 Harbor 子进程避免直接 SIGKILL 把 harbor 变成孤儿继续写 job 目录。实验对比与校准投影实验层在 experiments.tsjob 名的第一个-前的 token 即 experiment idexperimentOf新增 arm 时resolveArmLaunchserver.ts从样本最完整的同级 arm 继承 benchmark、dataset 与精确任务样本记录的include否则从该 arm 的 trial 任务反推从而保证 arm 之间直接可比。-fix/-backfill/-retry等重跑后缀会被折叠进基础 armcanonicalArmOf每任务取已决优先、最新优先的 trialpickMergedTrials。对仍在运行的 arm除了线性投影外实验详情页还会给出按难度校准的最终通过率投影calibratedFinalPassPctexperiments.ts把所有同级 arm 的结果当作每个任务的难度信号smoothed pass rate对当前 arm 拟合一个 log-odds 技能偏移再对剩余任务打分——避免已决子集碰巧全是简单任务导致 100% 的乐观误报。原生 Terminal-Bench 2.1 Runnerbench:tbbench:tb是独立于 Harbor 和 Docker 的另一种运行方式它把每个任务发布的 OCI 镜像作为 x86_64 KVM 微虚拟机microVM启动在 Vibemon 宿主机上通过vmon exec --pipe流式传输 omp 的--mode rpc协议在同一个被修改的 VM 里运行 verifier并把可恢复的 epoch 与产物写入runs/tb。实现位于 src/tb/cli、agent、dataset、store、trial、vmon、types 各司其职。bun run bench:tb \ --dataset /path/to/terminal-bench-2-1 \ --concurrency 4 --forever --budget 25工作站默认值的可恢复包装器对于 README 中说明的实测工作站默认值七模型池、:floor、concurrency 20使用可恢复的包装脚本bun --cwd packages/metaharness run bench:tb-floor它写入runs/tb-floor重复运行会恢复未完成的 epoch或在完成后开启下一个 epoch。环境变量覆盖TB_JOBS_DIR、TB_CONCURRENCY、TB_DATASET、TB_BUDGET_USD、TB_ATTEMPTS、TB_FOREVER1。额外 CLI flag 会透传并优先于包装器默认值。默认模型池与 OpenRouter 路由默认七模型池源码FLASH_POOL见 tb/cli.tsLing 3.0 FlashDeepSeek V4 Flash 两个路由0731 与未版本化/0423Nemotron 3.5 LightningLaguna S 2.1Tencent Hy3Step 3.7 Flash全部通过 OpenRouter 访问。请求默认使用 OpenRouter 的:floor最便宜 provider路由用--openrouter-variant default|nitro|online|exacto覆盖。用重复的--model provider/id替换整个模型池。基础设施参数默认目标为工作站的xeon.internalKVM 宿主与本地/work/vibevmmcheckout--vmon-url默认http://xeon.internal:17970。runner 在远端副本缺少 raw pipe 支持时会交叉构建并缓存打过补丁的vmon二进制运行期间自持一个特权 TAP broker并把回环的 omp auth 网关反向隧道化确保 provider 凭据永不进入任务 VM。trial agent 使用精简的终端工具 allowlist、edit.mode: replace与低成本的openrouter/qwen/qwen3.7-flashvision 角色benchmark prompt 中省略通用编排工具。基础设施覆盖参数--vmon-host --vmon-source --vmon-bin --vmon-home --vmon-kernel --vmon-agent --gateway-url完整参数表见 tb/cli.ts 的 HELP 文本。Harbor Runner 参数一览节选下表完整摘自 README配合 runner.ts 的 HELP 文本使用选项默认值说明-m, --model provider/modelanthropic/claude-sonnet-4-6可重复-l, --tasks N20最大任务数-n, --concurrency N4并发 trial 数-k, --attempts N1每任务尝试次数passk-d, --dataset nameterminal-bench2.0任意 Harbor dataset id-i/-x, --include/--exclude glob—任务过滤器可重复--timeout-multiplier x—缩放任务 agent/verifier 超时--agent-arg arg—原样转发给容器内 omp CLI 的额外参数可重复--env KEY[VALUE]—转发环境变量进 omp 容器可重复仅KEY时转发宿主值--binary path—预构建 omp 二进制arm64x64 各重复一次--install source\|local\|publishedsourcesource 仓库 bind-mountlocal tarball 打包published npmoh-my-pi/pi-coding-agent--environment docker\|apple-containerdockerapple-container用 Apple 的containerCLI 跑 trial无需 Dockersource/deps 挂载走harbor --mounts网关从192.168.64.1:4000自动转发到回环绑定的网关--gateway-url urlhttp://host.docker.internal:4000--environment apple-container下为http://192.168.64.1:4000--no-gateway关闭直接把宿主 provider key 传进容器-o, --jobs-dir pathrepo/runs/harbor与 server 共享--resume name\|path—通过harbor job resume恢复该 job 目录原始参数自动恢复--filter-error-type TCancelledError配合--resume对异常类型为T的已完成 trial 也重跑可重复--dry-run关闭打印 harbor 命令 models.yml 后退出补充说明源码层面环境变量注入规则见collectForwardEnv/buildHarborEnvrunner.ts所有宿主PI_*变量除目录/profile/session 等容器敌意白名单外自动转发显式--env始终优先配置与密钥通过OMP_BENCH_*环境变量传给agent/omp_local.py--thinking level可取off|minimal|low|medium|high|xhigh|max--web-search默认关闭无法经网关鉴权docker 后端还提供--cleanup安全清理退出/已建的 Harbor 容器与空闲 trial 网络与--cleanup-force强停并删除所有Harbor 容器与网络以及实验性的--host-network--install source是单架构的deps 树与 docker daemon 原生架构一致仿真镜像如 arm64 宿主跑 x64 任务会在 setup 阶段以架构不匹配报错此类场景应改用--binary。输出产物一次 Harbor run 结束后磁盘上会产生以下产物完整清单见 READMEjobs-dir/jobName/—— Harbor trial 目录每 trial 一个result.jsonjobs-dir/_bench/jobName/report.md—— markdown 汇总表数据集 / 模型 / tasks/attempts/concurrency / install 模式 / 通过率 / spend / tokens / 逐任务表生成逻辑见writeReportrunner.tsjobs-dir/_bench/jobName/harbor.log—— Harbor 完整输出jobs-dir/_manager/logs/jobName.log—— API 发起 run 的 runner 输出。此外--dry-run会打印将要执行的 harbor 命令、生成的models.yml与注入的 omp 环境变量值隐藏方便上线前核对配置。Trace 报告把一次 run 变成叙事文档scripts/trace-report.ts把单次 run 的 trace 转成叙事性 markdown 报告带编号的 Turn Log每个 assistant 回合配一句有依据的摘要harness notice 保留原位、Story Arc以及失败 run 的 failure analysis。它通过两个便宜的 OpenRouter 模型对归一化 trace 做 map/reduce默认每回合inclusionai/ling-2.6-flash、arc 用openai/gpt-oss-120b约 $0.001/报告API key 通过 omp 的 auth storage 解析。bun scripts/trace-report.ts run trace [--focus reviewer notes] [--out report.md] bun scripts/trace-report.ts sb3-ntg|django__django-12325__ddQroP4 # run|trace 也支持Flags--baseserver 地址默认http://localhost:4700、--tiny/--synthprovider/model-id覆盖、--focus额外 reviewer 上下文例如失败任务的已知正确修复、--concurrency默认 8。Caveats使用边界与注意事项网络策略Harbor 本地 Docker 后端只支持publicregistry任务容器经宿主网关访问模型。--install source即时反映本地 TS 改动无需重建但 Rust natives 从树内packages/natives/native/pi_natives.linux-*.nodeprebuild 加载——Rust 有改动时必须先重建workspace 加载会跳过版本 sentinel陈旧的.node会静默运行。source 模式是单架构的deps 树匹配 docker daemon 原生架构仿真镜像上的 trial 会以架构不匹配失败请改用--binary。source 模式下仓库在任务容器内可见只读对精选 benchmark 没问题但不要指向不受信任的任务。Apple Container 特例--environment apple-container需要brew install container container system startmacOS 26Apple silicon--host-network与--cleanup*仅限 dockerbind mount 是读写模式后端忽略read_only。--install local反映本地 TS 改动内联进dist/cli.js但不含未提交的 Rust natives——先按目标平台重建packages/natives版本 sentinel 必须匹配。相关测试与进一步阅读服务端 API、launch/resume/删除语义与实验分组均有对应测试test/server 相关用例、experiments.test.ts、manager.test.ts、runner.test.tsTB runner 测试tb-cli.test.ts、tb-dataset.test.ts、tb-store.test.tsHarbor 侧的容器内 agent 实现agent/omp_local.pyedit 基准的 adapter 与提示词在 adapters/edit/含 benchmark-task/system/retry 提示词与 runnerSnapCompact adapter 为 src/adapters/snapcompact.py。整体上metaharness把跑评测、看进度、对指标、出报告这条链路收敛到了一个服务里无论评测来源是 Harbor 容器、TypeScript edit 还是 SnapCompact 段落检索最终都以统一的 run 行、trial 矩阵与 trace 呈现历史 CLI run 也能被自动发现并纳入同一套查询与可视化体系。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考