Harbor 任务中 Verifier 环境模式解析：从 shared-default 到多步混合矩阵的完整实践指南

【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载Harbor 的verifier-mode-matrix是一组运行时检查任务用于验证 verifier评分器环境路由机制的正确性。本文以其中的shared-default案例为主线结合 harbor 源码中environment_mode的解析实现系统讲解 verifier 的 shared / separate 两种环境模式、单步任务与多步任务的配置继承规则以及如何用harbor run一键验证整套矩阵。读完本文你将掌握在task.toml中为 verifier 配置独立容器的全部方法并能读懂 harbor 内部的环境路由决策链路。背景verifier 为什么要区分环境模式在 harbor 的任务模型中Agent 在[environment]描述的容器中执行任务而 verifier 负责在 Agent 运行结束后对产物进行评分。verifier 究竟运行在哪里直接影响评分的可信度与隔离性shared共享模式verifier 直接运行在 Agent 的同一个环境中可以看见Agent 运行期间留下的所有现场状态ambient state适合那些需要依赖 Agent 环境副作用的评分逻辑separate分离模式verifier 运行在一个独立容器中只接收显式声明的 artifacts 与日志挂载环境隔离更强适合需要干净、可复现评分的场景。harbor 通过task.toml中的[verifier]段来声明这一行为而examples/tasks/verifier-mode-matrix/下的 8 个示例任务则把每一种模式组合都固化为可运行的运行时检查。核心配置语义environment_mode 与 verifier.environment在 配置模型 中verifier 的环境模式由两个字段共同决定配置项类型含义[verifier].environment_modeshared/separate显式指定 verifier 运行在 Agent 环境shared还是独立容器separate[verifier.environment]与顶层[environment]同 schemaseparate 模式下独立容器使用的环境定义关键推断规则与 verifier_mode.py 中_resolve_mode的实现一致显式设置environment_mode时以显式值为准未显式设置environment_mode但配置了[verifier.environment]时隐式推断为separate两者都未配置时默认使用shared——这正是shared-default案例名称的由来。同时配置模型内置了一致性校验config.py若environment_mode shared却同时配置了[verifier.environment]会直接抛出ValueError提示二者互斥。shared-default 案例拆解默认共享模式的完整闭环shared-default是矩阵中最简单也最典型的案例其指令文件 instruction.md 只有一句话Create the marker files expected by the verifier.而真正的技术细节藏在三个配套文件中。task.toml省略即共享shared-default/task.toml 声明了schema_version 1.3的任务[verifier]段只设置了timeout_sec既没有environment_mode也没有[verifier.environment]schema_version 1.3 [task] name harbor/verifier-mode-shared-default description Runtime check for the default shared verifier environment. [agent] timeout_sec 30.0 [verifier] timeout_sec 30.0 [environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0根据上述推断规则该任务解析出的模式为sharedverifier 将与 Agent 共用同一个容器。solve.shAgent 侧产出标记文件solution/solve.sh 模拟 Agent 的解题行为核心逻辑是探测共享环境是否真的可用mkdir -p /logs/artifacts if [ ! -d /logs/verifier ]; then echo shared verifier log mount missing from agent environment /tmp/shared-default-failure.txt else echo shared-default /logs/artifacts/mode.txt echo shared verifier can see ambient agent state /tmp/shared-default-agent-only.txt fi这里验证了两个共享模式的典型特征/logs/verifier目录在 Agent 环境中直接可见harbor 会为共享 verifier 在 Agent 环境中挂载该日志目录Agent 写入/tmp/shared-default-agent-only.txt的现场文件后续 verifier 应当能直接读到。test.shverifier 侧的三重断言shared-default/tests/test.sh 是共享模式下的评分脚本输出reward前依次断言/logs/verifier目录存在否则说明共享挂载未生效/tmp/shared-default-agent-only.txt存在否则说明 verifier 无法看到 Agent 的环境状态/logs/artifacts/mode.txt内容为shared-default否则说明产物标记未正确写入。#!/bin/bash set -u reward1 fail() { echo $1; reward0; } if [ ! -d /logs/verifier ]; then fail shared verifier should run with /logs/verifier available fi if [ ! -f /tmp/shared-default-agent-only.txt ]; then fail shared verifier did not see ambient agent file fi if [ ! -f /logs/artifacts/mode.txt ]; then fail shared verifier did not see /logs/artifacts marker elif [ $(cat /logs/artifacts/mode.txt) ! shared-default ]; then fail unexpected /logs/artifacts marker fi echo $reward /logs/verifier/reward.txt三个断言全部通过才说明默认共享模式确实让 verifier 与 Agent 共享了环境、挂载与现场状态——这正是 shared 模式与 separate 模式的根本差异所在。separate 模式的三种配置形态矩阵中另外三个单步案例演示了 separate 模式的三种写法其 test.sh 都通过反向断言agent-only文件不得泄漏进 verifier 容器来验证隔离性。separate-explicit显式分离 专属环境separate-explicit/task.toml 显式声明environment_mode separate并给出独立的[verifier.environment]schema_version 1.3 artifacts [/tmp/separate-explicit-configured.txt] [verifier] timeout_sec 30.0 environment_mode separate [verifier.environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0注意顶层artifacts声明了/tmp/separate-explicit-configured.txtseparate 模式下Agent 容器中只有显式声明的 artifacts 才会被拷贝到 verifier 容器。tests/Dockerfile 把 test.sh 拷入镜像tests/test.sh 断言 artifacts 标记存在同时用[ -e ... ]断言 Agent 侧的agent-only文件不存在验证环境隔离。separate-implicit配置环境即隐含分离separate-implicit/task.toml 不写environment_mode只配置[verifier.environment]。按源码中的_resolve_mode逻辑环境配置的存在会自动把模式推断为separate——这正是implicit隐式的语义。separate-reuse-env复用顶层环境 tests/ 构建上下文separate-reuse-env/task.toml 是最值得注意的形态声明了environment_mode separate但没有[verifier.environment]。此时根据 resolve_effective_verifier_env_config 的查找顺序会回退到顶层[environment]的深拷贝作为 verifier 容器配置并且以tests/目录作为 verifier 镜像的构建上下文build context。其 test.sh 通过检查/image-context.txt内容为verifier-build-context来验证构建上下文确实来自tests/。多步任务模式继承与 step 级覆盖task.toml支持[[steps]]定义多步任务verifier 模式在每个 step 上可以独立覆盖。核心解析函数 resolve_step_verifier_mode 定义了优先级显式 step 模式 step 级[verifier.environment]隐含 separate 继承 task 级解析结果 默认 shared。矩阵中四个多步案例覆盖了全部组合multistep-all-shared顶层无模式默认 shared两个 step 均不声明全部共享验证multistep-all-separate顶层environment_mode separate所有 step 继承 separate且每个 step 可声明自己的artifactsmultistep-top-shared-mixed顶层environment_mode shared其中separate-step-env这个 step 通过[steps.verifier.environment]切换为独立容器形成顶层共享 step 级分离的混合形态multistep-top-separate-mixed顶层environment_mode separateshared-overridestep 用environment_mode shared覆盖回共享separate-step-envstep 再配置独立环境形成双向混合。例如 multistep-top-separate-mixed/task.toml 中step 级覆盖的写法为[steps.verifier] timeout_sec 30.0 environment_mode shared # 覆盖顶层的 separate # 另一个 step 则用 environment 隐式切回 separate [steps.verifier.environment] network_mode no-network cpus 1 memory_mb 2048 storage_mb 10240 gpus 0多步任务中 shared 与 separate 的任意混用是允许的这正是矩阵命名为 mode matrix 的原因。运行整套矩阵验证在仓库根目录执行矩阵 README 中给出的命令即可运行全部 8 个运行时检查verifier-mode-matrix/README.mdharbor run --path examples/tasks/verifier-mode-matrix -e daytona -a oracle --n-concurrent 1 -y--path examples/tasks/verifier-mode-matrix指向包含多个任务的目录harbor 会批量运行其中全部任务-e daytona选择 daytona 环境提供者-a oracle使用 oracle agent直接按solution/生成答案用于验证环境路由本身--n-concurrent 1串行执行避免并发干扰运行时检查-y跳过交互确认。源码视角环境路由的完整决策链路从源码结构看verifier 环境路由的决策集中在 verifier_mode.py 的几组函数中构成一条清晰的分层链路_resolve_mode对单个VerifierConfig做显式优先、环境推断、缺省为 None的初步解析resolve_task_verifier_mode单步任务场景将缺省值落到sharedresolve_step_verifier_mode多步任务场景先看 step 自身再看 task 级结果resolve_effective_verifier_env_config模式为 separate 时按step 环境 task 环境 顶层环境深拷贝的顺序确定容器配置resolve_verifier_environment_definition进一步决定 verifier 镜像与构建上下文优先 step/task 的tests/目录中的 Dockerfile 或docker_image否则回退到environment/目录task_has_any_shared_verifier/task_has_any_separate_verifier供执行层判断是否需要为 verifier 准备独立会话。执行侧trial.py 中的_run_shared_verifier约 L867、_run_separate_verifier约 L898与_separate_verifier_env约 L969分别对应两条运行路径shared 复用 Agent 会话与挂载separate 则为 verifier 建立独立的 session 与环境策略校验。矩阵中每个示例的 test.sh 正是针对这两条路径的运行时断言。配置要点小结编写带 verifier 的 harbor 任务时可遵循以下决策速查希望 verifier 直接复用 Agent 环境什么都不写默认 shared或显式写environment_mode shared希望 verifier 独立容器、且需要自定义环境写environment_mode separate[verifier.environment]希望独立容器但接受顶层环境配置只写environment_mode separate构建上下文将落在tests/希望省掉一行配置、依赖推断只写[verifier.environment]模式自动推断为 separate多步任务在[steps.verifier]下用同样的规则逐 step 覆盖别忘了environment_mode shared与[verifier.environment]互斥同时出现会导致配置校验失败separate 模式下Agent 环境中的文件只有被artifacts显式声明才会进入 verifier 容器。赞分享【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载相关推荐Harbor Verifier 环境模式矩阵shared 与 separate 路由解析的完整实战指南Harbor Verifier 环境模式矩阵shared 与 separate 路由解析的完整实战指南 Harbor 中验证器verifier可以选择复用Harbor 多步骤任务 Verifier 环境模式实战shared 与 separate 的配置、状态传递与源码解析Harbor 多步骤任务 Verifier 环境模式实战shared 与 separate 的配置、状态传递与源码解析 本文以仓库中的 separate veSurfSense for Obsidian 插件完全指南把 Obsidian 笔记库同步为 SurfSense 可检索知识源SurfSense for Obsidian 插件完全指南把 Obsidian 笔记库同步为 SurfSense 可检索知识源 本文以仓库内 surfsens上一篇PureScript与AWS Lambda无服务器函数的类型安全开发下一篇终极Android下载引擎指南如何用FileDownloader实现高效断点续传与多任务管理 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考