Harbor Verifier 环境模式矩阵：shared 与 separate 路由解析的完整实战指南

【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载Harbor 中验证器verifier可以选择复用 Agent 所在容器shared或运行在独立容器separate中该路由行为由task.toml的[verifier]配置决定。本文以仓库内examples/tasks/verifier-mode-matrix下的运行时检查矩阵为骨架结合配置模型与解析函数源码系统讲解两种模式的判定规则、镜像选择优先级、多步multi-step任务中的继承与覆盖机制并给出每一步可复跑、可验证的完整task.toml示例。读完本文你将能准确预测任意任务配置下验证器最终运行的环境并能为自己的任务正确设计隔离的评分环境。矩阵任务概览用运行时检查验证路由规则[examples/tasks/verifier-mode-matrix/README.md](https://link.gitcode.com/i/59a6014b5e459048c2bcad8d7587a1d2)是一组针对验证器环境路由的运行时检查任务runtime checks覆盖了共享/分离两种模式在单步与多步任务中的所有组合形态。整套矩阵可以用一条命令在本地跑通harbor run --path examples/tasks/verifier-mode-matrix -e daytona -a oracle --n-concurrent 1 -y--path指定任务目录该目录下含多个独立task.toml-e daytona选择 daytona 作为环境提供者-a oracle使用 oracle agent--n-concurrent 1串行执行避免并发环境互相干扰-y跳过交互确认。矩阵共覆盖 8 种场景3 个单步任务shared-default、separate-explicit、separate-implicit、separate-reuse-env共 4 个加上 4 个多步任务。每个任务都是一个自校验任务Agent 的solve.sh写入标记文件验证器的test.sh检查这些标记是否存在、内容是否一致、Agent 环境文件是否泄漏进验证器容器最终把 reward 写入/logs/verifier/reward.txt。两种模式的定义shared 与 separate在 src/harbor/models/task/config.py 中验证器环境模式被定义为枚举class VerifierEnvironmentMode(str, Enum): Whether the verifier runs in the agents environment or its own. SHARED shared SEPARATE separateshared共享模式默认验证器直接复用在 Agent 执行阶段运行过的同一个容器。tests/目录会在验证阶段开始时上传到容器内的/tests/验证器能直接看到 Agent 遗留的所有文件系统状态。separate分离模式验证器在独立容器中运行拥有自己的镜像与资源配置。Agent 的临时文件系统改动不会被继承只有/logs/artifacts/目录以及任务声明的artifacts路径会被复制进验证器环境。分离模式的价值在于隔离评分边界Agent 无法篡改评分脚本、可将评分依赖预装进验证器镜像并提前构建以减少安装抖动、以及支持任务重评分trial regrading。模式解析的三条核心规则[verifier]段有两个相关字段environment_mode与environment。Harbor 的模式解析逻辑位于 src/harbor/models/task/verifier_mode.py核心规则如下显式优先若environment_mode显式设置直接采用该值隐式推断若省略environment_mode但声明了[verifier.environment]则推断为separate默认共享两者都省略时默认为shared。对应官方文档 docs-mintlify/tasks/separate-verifier.mdx 中的模式决议表environment_mode[verifier.environment]结果省略省略shared省略存在separate隐式shared省略sharedshared存在校验错误separate省略separate深拷贝顶层[environment]separate存在separate使用验证器专属环境shared与[verifier.environment]互斥这一点在配置模型中有硬性校验config.py二者同时出现会直接抛出ValueError提示要么删除environment要么改用separate。该决议逻辑在 tests/unit/models/test_verifier_mode.py 中有完整覆盖例如test_environment_without_mode_implies_separate、test_shared_with_environment_raises分别验证了隐式推断与非法组合。矩阵场景逐一拆解含完整配置1. shared-default省略模式即共享shared-default/task.toml 演示了默认行为——[verifier]段既不写environment_mode也不写environmentschema_version 1.3 [task] name harbor/verifier-mode-shared-default description Runtime check for the default shared verifier environment. [metadata] difficulty easy category test tags [verifier, shared, runtime] [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 0Agent 的 solve.sh 在/logs/artifacts写入mode.txt内容shared-default并额外创建/tmp/shared-default-agent-only.txt作为环境残留文件探针。共享模式的 test.sh 据此验证三点/logs/verifier目录存在验证器日志挂载点与 Agent 相同能看到/tmp/shared-default-agent-only.txt——证明共享模式下验证器能直接看到 Agent 的临时文件/logs/artifacts/mode.txt内容正确。注意共享模式不需要tests/Dockerfiletests/test.sh会在验证阶段开始时被上传到/tests/。这正是官方文档所述默认情况下验证器与 Agent 运行在同一容器tests/目录在验证阶段开始时上传到/tests/的运行时验证。2. separate-explicit显式声明分离separate-explicit/task.toml 通过environment_mode separate显式启用分离模式并提供专属[verifier.environment]schema_version 1.3 artifacts [/tmp/separate-explicit-configured.txt] [task] name harbor/verifier-mode-separate-explicit description Runtime check for explicit verifier.environment_mode separate. [metadata] difficulty easy category test tags [verifier, separate, runtime] [agent] timeout_sec 30.0 [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 [environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0关键点[verifier.environment]使用与顶层[environment]完全相同的 schema在 config.py 中environment字段类型就是EnvironmentConfig可声明docker_image、cpus、memory_mb、network_mode等顶层artifacts [/tmp/separate-explicit-configured.txt]声明要复制进验证器容器的文件tests/Dockerfile 单独构建验证器镜像FROM ubuntu:24.04并把test.sh拷入/tests/test.sh。test.sh 的检查逻辑体现分离模式的隔离语义if [ ! -f /logs/artifacts/mode.txt ]; then fail missing copied /logs/artifacts marker elif [ $(cat /logs/artifacts/mode.txt) ! separate-explicit ]; then fail unexpected /logs/artifacts marker fi if [ ! -f /tmp/separate-explicit-configured.txt ]; then fail missing configured artifact fi if [ -e /tmp/separate-explicit-agent-only.txt ]; then fail ambient agent file leaked into separate verifier fi/logs/artifacts/mode.txt与/tmp/separate-explicit-configured.txt必须存在——这是 Agent 阶段通过 artifact 机制主动传过去的/tmp/separate-explicit-agent-only.txtAgent 环境中的残留文件必须不存在——验证器容器是全新启动的不会继承 Agent 的临时文件系统。3. separate-implicit声明环境即隐含分离separate-implicit/task.toml 故意省略了environment_mode只声明[verifier.environment][verifier] timeout_sec 30.0 [verifier.environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0根据_resolve_mode逻辑verifier_mode.pyenvironment_mode为空而environment非空时自动返回SEPARATE。该场景验证的正是这条隐式推断规则运行时表现与separate-explicit完全一致Agent 残留文件不可见、artifacts 正常复制。4. separate-reuse-env复用顶层环境 tests 构建上下文separate-reuse-env/task.toml 演示分离模式下的环境复用路径——声明environment_mode separate但不写[verifier.environment]artifacts [/tmp/separate-reuse-configured.txt] [verifier] timeout_sec 30.0 environment_mode separate [environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0此时 Harbor 会深拷贝一份顶层[environment]配置作为验证器环境见 resolve_effective_verifier_env_config 的兜底分支task_cfg.environment.model_copy(deepTrue)单元测试test_separate_without_verifier_environment_returns_fresh_top_level_copy验证了该深拷贝不与原对象共享引用并以tests/目录作为验证器镜像的构建上下文。该任务 tests/ 下存在 Dockerfile因此验证器镜像由tests/Dockerfile构建镜像内带有/image-context.txt内容verifier-build-context。test.sh 据此断言if [ $(cat /image-context.txt) ! verifier-build-context ]; then fail separate verifier did not use tests/ as the build context fi同时复用顶层环境也意味着资源配置cpus、memory_mb、network_mode沿用[environment]但容器实例是全新启动的Agent 残留文件/tmp/separate-reuse-agent-only.txt依然不可见。镜像选择优先级验证器镜像从哪来当模式解析为separate后验证器容器使用哪个镜像由 resolve_verifier_environment_definition 决定。官方文档给出的优先级如下从上到下取第一个可用项优先级定义来源测试文件1[verifier.environment].docker_image必须预构建进镜像2tests/Dockerfile或tests/docker-compose.yaml必须预构建进镜像3[environment].docker_image运行时从tests/上传到/tests/4environment/Dockerfile或environment/docker-compose.yaml运行时从tests/上传到/tests/资源设置cpus、memory 等来自[verifier.environment]未提供时沿用[environment]继承自 Agent 的镜像永远不会覆盖验证器的构建定义。多步场景下优先级扩展为步骤镜像 → 步骤tests/构建定义 → 任务验证器镜像 → 任务tests/构建定义 → Agent 环境。步骤tests/目录若无构建定义则不会覆盖任务级验证器镜像。使用预构建验证器镜像优先级 1、2时镜像必须自带/tests/test.shWindows 为/tests/test.batHarbor 不会在运行时向这类镜像上传测试文件。只有回退到 Agent 环境优先级 3、4时才会把tests/上传到/tests/。矩阵中的separate-explicit与separate-reuse-env分别覆盖了优先级 2tests/Dockerfile 构建与 3/4复用环境路径而test_resource_only_override_still_uses_agent_image等单元测试则覆盖了仅覆盖资源仍使用 Agent 镜像的边界。多步任务继承、覆盖与混合多步任务中每个[[steps]]都可以通过[steps.verifier]覆盖验证器模式。解析顺序resolve_step_verifier_mode步骤级显式environment_mode优先步骤级[steps.verifier.environment]存在则隐含separate否则继承任务级解析结果任务级也缺省时默认shared。multistep-all-shared全部步骤共享multistep-all-shared/task.toml 任务级不声明任何模式两个步骤shared-one、shared-two均不带environment因此全部继承共享模式。每个步骤的tests/test.sh都位于各自的steps/name/tests/目录下如 shared-one/tests/test.sh验证器能读取到对应步骤 Agent 留下的环境文件/tmp/all-shared-step1.txt验证共享语义在每一步都成立。multistep-all-separate全部步骤继承分离multistep-all-separate/task.toml 任务级写environment_mode separate两个步骤separate-one、separate-two未做任何覆盖从而全部继承分离模式。步骤 Agent 的 solve.sh 只写各自的 artifacts/tmp/all-separate-step1.txt步骤验证器在全新容器中运行、只见声明过的 artifacts。multistep-top-shared-mixed顶层共享 步骤级分离multistep-top-shared-mixed/task.toml 是第一个混合用例任务级显式environment_mode shared但步骤separate-step-env声明了[steps.verifier.environment][verifier] timeout_sec 30.0 environment_mode shared [[steps]] name shared-inherited # 无 verifier 覆盖 → 继承 shared [[steps]] name separate-step-env artifacts [/tmp/top-shared-mixed-separate.txt] min_reward 1.0 [steps.verifier] timeout_sec 30.0 [steps.verifier.environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0运行时表现shared-inherited步骤的验证器与 Agent 同容器separate-step-env步骤的验证器在独立容器中只能看到通过artifacts声明的/tmp/top-shared-mixed-separate.txt而看不到共享步骤 Agent 留下的环境文件test.sh 中if [ -e /tmp/top-shared-mixed-agent-only.txt ]的失败分支正是为此设计。multistep-top-separate-mixed顶层分离 双向覆盖multistep-top-separate-mixed/task.toml 是覆盖最全的用例任务级environment_mode separate三个步骤分别演示三种派生关系[[steps]] name separate-inherited # 无覆盖 → 继承任务级 separate [[steps]] name shared-override [steps.verifier] environment_mode shared # 显式覆盖为 shared [[steps]] name separate-step-env [steps.verifier.environment] # 隐式推断 separate且用步骤专属环境其 test.sh 逻辑精巧分离模式下每个步骤的 Agent artifacts 互不可见因此验证器先探测两个步骤标记文件哪个存在再校验其内容与步骤名匹配并确保共享步骤留下的残留文件/tmp/top-separate-mixed-agent-only.txt不泄漏进分离容器。这一用例同时验证了resolve_step_verifier_mode的完整优先级链与[steps.verifier.environment]的独立镜像/资源能力。分离验证器的执行链路与网络策略从运行时代码看分离验证器的实际执行由 src/harbor/trial/trial.py 中的_run_separate_verifier完成调用resolve_verifier_environment_definition解析验证器环境定义镜像 构建目录 是否自带测试通过_separate_verifier_env启动独立环境带独立的 session 标识见_separate_verifier_session_id清空验证器目录后由_artifact_handler.upload_artifacts将/logs/artifacts/与声明的artifacts上传到验证器环境的对应路径。与之相对的_run_shared_verifier同文件 trial.py则直接复用self.agent_environment不启动新容器。单元测试 tests/unit/test_multi_step_run_step.py 中的test_mixed_verifier_modes_clean_only_after_shared_verification等用例进一步验证了混合模式下容器清理与生命周期管理的时序。值得注意的还有网络策略分离验证器拥有独立的网络计划。矩阵中所有任务的network_mode均为no-network这保证评分环境完全离线、不可被 Agent 阶段的网络行为影响。若任务需要验证器访问特定服务可在[verifier.environment]或[steps.verifier.environment]中配置network_mode allowlist与allowed_hosts允许域名、IP、CIDR 与前导通配符见 config.py 的NetworkMode枚举。验证与结果输出约定矩阵中的所有验证器脚本遵循同一套约定这也是 Harbor 验证器开发的通用模式reward 通过写入/logs/verifier/reward.txt返回内容1为通过、0为失败检查失败时通过echo $1输出原因到标准输出便于追踪Agent 通过/logs/artifacts/发布需要传给验证器的文件分离模式下只有/logs/artifacts/与artifacts字段声明的路径会被复制/logs/agent/、/logs/verifier/不会被自动复制除非显式声明为 artifacts例如轨迹评分场景artifacts [/logs/agent/trajectory.json]。小结如何为你的任务选择模式默认情况下不写任何配置验证器与 Agent 同容器运行适合评分脚本简单、信任 Agent 环境的场景需要隔离评分如 Agent 可能污染环境、评分依赖敏感时用environment_mode separate或直接声明[verifier.environment]启用独立容器评分依赖需要预装时用tests/Dockerfile构建验证器镜像或使用[verifier.environment].docker_image指向预构建镜像多步任务中不同步骤需要不同评分环境时按步骤声明[steps.verifier.environment]或environment_mode shared覆盖即可覆盖优先级为步骤显式模式 步骤环境隐式分离 任务级解析结果 默认共享。验证以上所有行为的两种方式直接运行矩阵命令harbor run --path examples/tasks/verifier-mode-matrix -e daytona -a oracle --n-concurrent 1 -y或阅读解析逻辑的单元测试 tests/unit/models/test_verifier_mode.py其中TestResolveTaskVerifierMode、TestResolveStepVerifierMode、TestResolveEffectiveVerifierEnvConfig与test_definition_precedence完整刻画了本文所述的全部决议规则。赞分享【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载相关推荐Harbor 多步骤任务 Verifier 环境模式实战shared 与 separate 的配置、状态传递与源码解析Harbor 多步骤任务 Verifier 环境模式实战shared 与 separate 的配置、状态传递与源码解析 本文以仓库中的 separate vePyWxDump一条命令提取微信数据库密钥免手动输入PyWxDump一条命令提取微信数据库密钥免手动输入 以前拿微信数据库密钥是件苦差事翻进程内存、猜偏移量最后还得手工敲那一长串 64 位 16 进制密钥在 MCP Toolbox 中接入 ScyllaDBSource 配置、CQL 工具与云/自托管实战指南在 MCP Toolbox 中接入 ScyllaDBSource 配置、CQL 工具与云/自托管实战指南 导读 本文聚焦于开源 MCP 服务器项目 MCP T上一篇30 Seconds of Interviews 贡献指南从问题模板到自动化构建的完整投稿流程下一篇HMCL启动器1.7.10-pre4版本Forge安装兼容性终极解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考