【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载导读Harbor 允许任务为 agent 阶段与 verifier 阶段配置不同的网络策略而verifier.environment_mode separate则进一步把验证器放到一个独立的容器环境中运行实现离线跑 Agent、在线做验证的典型评测隔离。本文以仓库中现成的演示任务network-policy-matrix/static/verifier-separate-mode为骨架完整拆解其task.toml配置、agent 阶段行为、artifact 传递机制与 verifier 验证逻辑并结合src/harbor源码解释shared/separate两种模式的解析规则与底层调用链。读完本文你将能够独立编写、配置并运行一个agent 断网 verifier 联网的 Harbor 任务并理解其背后的网络策略模型。一、先理解背景Harbor 的阶段级网络策略模型在深入这个任务之前需要先掌握 Harbor 网络策略的三层基本概念它们全部定义在 src/harbor/models/task/config.py 中NetworkMode枚举每个执行角色环境、agent、verifier都有一个网络访问策略取值为no-network完全断网、public允许公网、allowlist仅允许名单内的域名/IP/CIDR。环境基线baseline[environment]段的network_mode定义了整个任务环境的基础网络策略默认是public见 config.py 中BaselineNetworkPolicyConfig的resolve_baseline()。阶段覆盖phase override[agent]与[verifier]段可以显式覆盖各自阶段的网络策略PhaseNetworkPolicyConfig.explicit_phase_policy()。如果某个阶段没有显式覆盖则该阶段沿用环境基线。仓库的network-policy-matrix目录README.md正是围绕这一模型设计的网络策略矩阵把用例划分为静态static与动态dynamic两类静态用例各阶段的网络策略与基线一致Harbor 在agent.run()/verify()过程中不会调用set_network_policy做运行时切换。动态用例至少有一个阶段策略与基线不同需要 E2B 等支持dynamic_network_policy的 provider 在运行时动态切换策略。本文的主角verifier-separate-mode属于静态用例它的特殊性不在于切换而在于验证器运行在独立环境中从而让 agent 与 verifier 拥有完全不同的网络与文件系统。二、任务全景verifier-separate-mode 想验证什么关联文档 instruction.md 用极简的方式定义了这个演示任务的三个目标agent 阶段断网agent 阶段运行在network_mode no-network下尝试访问https://example.com/必须失败记录网络状态把结果写入/logs/artifacts/agent-network-status.txt失败写blocked成功写reachable写入隔离哨兵文件在/tmp/agent-only-sentinel.txt中写入agent-only。而 verifier 阶段运行在独立的、公网可达的环境中它应当接收到来自/logs/artifacts的产物、能够访问example.com、并且看不到agent 环境/tmp目录下的哨兵文件。一句话概括这个任务同时验证了Harbor 能在 agent 阶段真正断网、agent 与 verifier 的文件系统互相隔离、artifact 能在环境之间正确传递以及verifier 可以拥有比 agent 更宽的网络权限四件事。三、task.toml 全量解读separate 模式的配置要点任务的完整配置位于 task.toml值得逐段精读schema_version 1.3 [task] name harbor/network-policy-static-verifier-separate-mode description Demonstrates verifier.environment_mode separate with agent no-network and verifier public phases. authors [] keywords [network, verifier, environment, separate, demo] [metadata] difficulty easy category infrastructure tags [network, verifier, environment, separate, demo] [environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0 mcp_servers [] [verifier] network_mode public timeout_sec 60.0 environment_mode separate [verifier.environment] network_mode public build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0 mcp_servers [] [agent] network_mode no-network timeout_sec 120.0 [verifier.env] [environment.env] [solution.env]配置中的几个关键点逐一说明[environment].network_mode no-network任务环境的基线策略是断网build_timeout_sec 600.0表示构建超时 600 秒cpus 1、memory_mb 2048、storage_mb 10240、gpus 0定义了容器资源配额mcp_servers []表示不挂载任何 MCP 服务器。[verifier].environment_mode separate这是整个任务的核心声明 verifier 不在 agent 的环境里执行而是启动一个专用容器。[verifier].network_mode publicverifier 阶段的网络策略覆盖为公网可达与[environment]基线不同但由于是独立环境无需动态切换策略。[verifier.environment]独立 verifier 容器的完整环境定义schema 与顶层[environment]完全一致这里同样配置了network_mode public和一致的资源配额。[agent].network_mode no-networkagent 阶段显式覆盖为断网timeout_sec 120.0给 agent 120 秒完成操作。注意[verifier].timeout_sec 60.0与[agent].timeout_sec 120.0的差异验证阶段通常比 agent 阶段更短因为它只做确定性的检查。environment_mode 的取值与隐式推导根据 config.py 中VerifierEnvironmentMode与VerifierConfig的定义environment_mode有两个取值取值含义sharedverifier 直接运行在 agent 的环境中共享同一个容器/文件系统separateverifier 运行在专用容器中与 agent 环境隔离它的推导规则实现于 verifier_mode.py 的_resolve_mode()显式设置environment_mode时以显式值为准未显式设置但定义了[verifier.environment]时隐式推导为separate两者都未设置时推导结果为未指定最终回退为shared。此外[verifier.environment]的查找顺序是步骤级 verifier.environment 任务级 verifier.environment 顶层 [environment] 的深拷贝见resolve_effective_verifier_env_config()。这意味着即使不写[verifier.environment]只要显式声明environment_mode separateHarbor 也会基于顶层[environment]复制一份全新的环境给 verifier 用——这就是本任务中[verifier.environment]与[environment]字段高度重合的原因。同时shared与environment互斥[verifier].environment_modeshared搭配[verifier.environment]会直接触发配置校验错误config.py。四、agent 阶段行为在断网环境下探测并留下证据agent 阶段需要完成任务而本任务的解法参考 solve.sh恰好展示了如何在断网环境下自证断网#!/bin/bash set -euo pipefail mkdir -p /logs/artifacts python3 - PY from pathlib import Path from urllib.request import Request, urlopen try: request Request( https://example.com/, headers{User-Agent: harbor-network-policy-verifier-separate-agent}, ) with urlopen(request, timeout5) as response: response.read(1) status reachable except Exception: status blocked Path(/logs/artifacts/agent-network-status.txt).write_text(status) PY printf agent-only\n /tmp/agent-only-sentinel.txt这段脚本的核心设计值得学习用 Python 标准库探测网络urllib.request发起对https://example.com/的 GET 请求timeout5保证请求不会无限挂起任何异常DNS 解析失败、连接超时、代理拒绝等都会落入except Exception分支。结果写入 artifact 目录/logs/artifacts是 Harbor 约定的 artifact 收集目录agent-network-status.txt写入blocked或reachable两个确定性的状态值后续 verifier 只需比对字符串即可打分。写入隔离哨兵/tmp/agent-only-sentinel.txt只存在于 agent 环境的/tmp下用于后续验证环境隔离性。运行在no-network策略下时这次请求必然失败因此最终写入的应是blocked。这正是任务期望的标准答案。五、验证阶段独立环境中检查网络与隔离verifier 阶段执行 test.sh它在一个独立的、公网可达的容器里完成三项断言#!/bin/bash set -u mkdir -p /logs/verifier reward1 fail() { echo $1 reward0 } if [ ! -s /logs/artifacts/agent-network-status.txt ]; then fail missing agent network status artifact elif [ $(cat /logs/artifacts/agent-network-status.txt) ! blocked ]; then fail agent reached example.com despite [agent].network_mode no-network fi if [ -e /tmp/agent-only-sentinel.txt ]; then fail separate verifier environment unexpectedly sees agent-only /tmp sentinel fi if ! python3 - PY from urllib.request import Request, urlopen request Request( https://example.com/, headers{User-Agent: harbor-network-policy-verifier-separate-verifier}, ) with urlopen(request, timeout5) as response: body response.read().decode(errorsignore).lower() if example domain not in body: raise SystemExit(1) PY then fail verifier could not reach example.com despite [verifier].network_mode public fi echo $reward /logs/verifier/reward.txt逐段解读验证逻辑断言 1agent 确实断网。test.sh先检查/logs/artifacts/agent-network-status.txt是否存在且非空-s再比对内容必须严格等于blocked。这证明 agent 阶段的no-network策略被真实执行而不是形同虚设。断言 2环境隔离生效。检查/tmp/agent-only-sentinel.txt是否存在——在separate模式下它必须不存在因为 verifier 跑在独立的容器里看不到 agent 的/tmp。这条断言直接验证了environment_mode separate的文件系统隔离语义。断言 3verifier 可以联网。verifier 自己在公网环境下重新请求https://example.com/并校验响应正文包含example domain字样证明[verifier].network_mode public生效。结果输出所有断言通过时reward1否则reward0最终写入/logs/verifier/reward.txt。任何一条失败都会通过fail()打印原因并归零奖励便于调试。注意这里的/tmp检查与常见评测任务的差异多数任务只需检查agent 是否完成了动作而这个任务刻意利用/tmp哨兵验证separate 模式的副作用——agent 环境的临时文件不会泄漏给 verifier。这一点在 trial.py 中也有对应实现当模式为SEPARATE时走_run_separate_verifier()分支独立容器否则走_run_shared_verifier()分支复用 agent 容器并重置共享目录两种模式在代码层面就是完全不同的执行路径。六、artifact 传递环境隔离下的数据通道separate模式下 agent 与 verifier 文件系统互相隔离那 agent 的结果如何交给 verifier答案是 Harbor 的artifact 收集机制。agent 阶段把证据写入/logs/artifacts/这是 Harbor 默认的 artifact 收集目录对应 config.py 中ArtifactConfig的容器内 source 路径在 verifier 启动前Harbor 把这些文件从 agent 环境收集下来再挂载/注入到独立的 verifier 环境中的相同路径/logs/artifacts/于是test.sh可以直接读取/logs/artifacts/agent-network-status.txt无需任何额外协议。这种设计是证据链思想verifier 只信任收集到的 artifact不信任 agent 环境的当前状态。ArtifactConfigconfig.py还支持destination目标相对路径、exclude排除模式、servicecompose 服务收集等字段足以覆盖复杂场景。同样的模式也出现在矩阵中的其他任务里例如 static/e-ve[environment]为no-network[verifier.environment]为public其 test.sh 同样从/logs/artifacts读取 agent 的网络状态并自行联网验证——这就是 separate 模式的通用范本。七、源码级解析separate 模式是如何被决定与执行的要真正理解这个任务还应该知道 Harbor 底层是如何处理environment_mode的1. 模式解析配置层resolve_task_verifier_mode()与resolve_step_verifier_mode()位于 verifier_mode.py。前者处理单步任务后者按步骤级显式模式 步骤级 environment 隐式 separate 继承任务级 默认 shared的优先级解析多步任务中每个 step 的 verifier 模式。resolve_effective_verifier_env_config()则决定 separate 模式下的环境定义来源。2. 执行分支运行层在 trial.py 的_run_step_verifier()中mode VerifierEnvironmentMode.SEPARATE走_run_separate_verifier()否则走_run_shared_verifier()。前者为 verifier 创建独立容器并注入 artifact后者在 agent 容器内直接执行并重置共享目录。3. 记录与重判结果层trial 结果会记录解析出的verifier_environment_modetrial.pyregrade.py 则明确规定共享模式shared的 verifier 依赖仍然存活的 agent 环境无法用录制的 artifact 重判——如果需要基于 artifact 重判必须设置[verifier] environment_mode separate并从/logs/artifacts读取输入。这也解释了为什么本任务刻意把全部判断依据都放进/logs/artifacts它是可重判性regradability的前提。4. 测试保障tests/unit/trial/test_network_policy.py 中覆盖了[verifier] network_mode、[verifier.environment]与各阶段策略的组合解析断言静态用例阶段策略 基线策略时不会触发set_network_policy调用、动态用例则产生预期调用序列为本任务的配置语义提供了单元级验证。八、运行与验证如何实际执行这个任务在仓库根目录下可以直接用 Harbor CLI 运行整个静态矩阵或单个任务。根据 README.md在 E2B 上跑全部静态用例的命令是harbor run --path examples/tasks/network-policy-matrix/static -e e2b -a oracle --n-concurrent 20 -y只跑单个verifier-separate-mode任务则指向具体目录即可harbor run --path examples/tasks/network-policy-matrix/static/verifier-separate-mode -e e2b -a oracle -y其中-e e2b选择 E2B 环境 provider-a oracle使用 oracle agent即执行solution/solve.sh--n-concurrent 20控制并发数。如果使用本地 Docker需要注意 README 中列出的兼容性限制Docker 的no-network、allowlist与动态切换场景需要 Linux 容器Windows Docker 容器不支持这些网络策略模式。运行后可以从 trial 输出中核对三个事实agent-network-status.txt内容为blockedagent 断网生效、reward.txt为1verifier 联网与环境隔离均验证通过。九、延伸从本任务出发看懂整个矩阵verifier-separate-mode只是矩阵中的一个演示点理解了它就能快速读懂矩阵中其他相似用例static/e-veeno-network、vepublic、separate verifier、无阶段覆盖——与本任务几乎同构但没有显式的[agent]/[verifier]网络覆盖。static/e-ve-no-network方向相反epublic而veno-network验证独立验证环境可以比 agent 更封闭。static/e-a-v-samee a v全部显式no-network验证策略一致时的行为。static/sv-sve-same多步任务中的sv sve publicstep 级 separate verifier对应resolve_step_verifier_mode()的解析路径。这些用例共同构成了一张阶段 × 环境 × 网络模式的完整覆盖矩阵而verifier-separate-mode是理解它们的最佳切入点。十、小结通过network-policy-matrix/static/verifier-separate-mode这个任务可以完整掌握 Harbor 三个相互关联的能力阶段级网络策略[agent]、[verifier]可独立覆盖[environment]基线取值no-network/public/allowlist独立验证环境verifier.environment_mode separate让 verifier 在专用容器运行获得独立的网络与文件系统配置上可省略[verifier.environment]自动复制顶层环境artifact 传递 可重判性agent 将证据写入/logs/artifactsverifier 据此打分这也是 regrade 对 separate 模式的基本要求。对于评测平台设计者而言这个任务展示了一种非常实用的安全模式让能力边界不确定的 Agent 在完全隔离的沙箱里执行让确定性的验证逻辑在独立且可控的环境中运行两者之间只通过显式收集的 artifact 通信。赞分享【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载相关推荐探索现代化品牌图标解决方案Simple Icons 完全指南探索现代化品牌图标解决方案Simple Icons 完全指南 在当今的数字化产品开发中高效管理品牌图标资源已成为每个开发者面临的挑战。Simple Icon前端UI组件OptiScaler革命性游戏超采样技术桥接器 - 智能GPU兼容解决方案OptiScaler革命性游戏超采样技术桥接器 智能GPU兼容解决方案 在现代PC游戏体验中超采样技术已成为提升画质和性能的关键。然而显卡厂商的技术壁垒让图形学游戏开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载导读Harbor 允许任务为 agent 阶段与 verifier 阶段配置不同的网络策略而verifier.environment_mode separate则进一步把验证器放到一个独立的容器环境中运行实现离线跑 Agent、在线做验证的典型评测隔离。本文以仓库中现成的演示任务network-policy-matrix/static/verifier-separate-mode为骨架完整拆解其task.toml配置、agent 阶段行为、artifact 传递机制与 verifier 验证逻辑并结合src/harbor源码解释shared/separate两种模式的解析规则与底层调用链。读完本文你将能够独立编写、配置并运行一个agent 断网 verifier 联网的 Harbor 任务并理解其背后的网络策略模型。一、先理解背景Harbor 的阶段级网络策略模型在深入这个任务之前需要先掌握 Harbor 网络策略的三层基本概念它们全部定义在 src/harbor/models/task/config.py 中NetworkMode枚举每个执行角色环境、agent、verifier都有一个网络访问策略取值为no-network完全断网、public允许公网、allowlist仅允许名单内的域名/IP/CIDR。环境基线baseline[environment]段的network_mode定义了整个任务环境的基础网络策略默认是public见 config.py 中BaselineNetworkPolicyConfig的resolve_baseline()。阶段覆盖phase override[agent]与[verifier]段可以显式覆盖各自阶段的网络策略PhaseNetworkPolicyConfig.explicit_phase_policy()。如果某个阶段没有显式覆盖则该阶段沿用环境基线。仓库的network-policy-matrix目录README.md正是围绕这一模型设计的网络策略矩阵把用例划分为静态static与动态dynamic两类静态用例各阶段的网络策略与基线一致Harbor 在agent.run()/verify()过程中不会调用set_network_policy做运行时切换。动态用例至少有一个阶段策略与基线不同需要 E2B 等支持dynamic_network_policy的 provider 在运行时动态切换策略。本文的主角verifier-separate-mode属于静态用例它的特殊性不在于切换而在于验证器运行在独立环境中从而让 agent 与 verifier 拥有完全不同的网络与文件系统。二、任务全景verifier-separate-mode 想验证什么关联文档 instruction.md 用极简的方式定义了这个演示任务的三个目标agent 阶段断网agent 阶段运行在network_mode no-network下尝试访问https://example.com/必须失败记录网络状态把结果写入/logs/artifacts/agent-network-status.txt失败写blocked成功写reachable写入隔离哨兵文件在/tmp/agent-only-sentinel.txt中写入agent-only。而 verifier 阶段运行在独立的、公网可达的环境中它应当接收到来自/logs/artifacts的产物、能够访问example.com、并且看不到agent 环境/tmp目录下的哨兵文件。一句话概括这个任务同时验证了Harbor 能在 agent 阶段真正断网、agent 与 verifier 的文件系统互相隔离、artifact 能在环境之间正确传递以及verifier 可以拥有比 agent 更宽的网络权限四件事。三、task.toml 全量解读separate 模式的配置要点任务的完整配置位于 task.toml值得逐段精读schema_version 1.3 [task] name harbor/network-policy-static-verifier-separate-mode description Demonstrates verifier.environment_mode separate with agent no-network and verifier public phases. authors [] keywords [network, verifier, environment, separate, demo] [metadata] difficulty easy category infrastructure tags [network, verifier, environment, separate, demo] [environment] network_mode no-network build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0 mcp_servers [] [verifier] network_mode public timeout_sec 60.0 environment_mode separate [verifier.environment] network_mode public build_timeout_sec 600.0 cpus 1 memory_mb 2048 storage_mb 10240 gpus 0 mcp_servers [] [agent] network_mode no-network timeout_sec 120.0 [verifier.env] [environment.env] [solution.env]配置中的几个关键点逐一说明[environment].network_mode no-network任务环境的基线策略是断网build_timeout_sec 600.0表示构建超时 600 秒cpus 1、memory_mb 2048、storage_mb 10240、gpus 0定义了容器资源配额mcp_servers []表示不挂载任何 MCP 服务器。[verifier].environment_mode separate这是整个任务的核心声明 verifier 不在 agent 的环境里执行而是启动一个专用容器。[verifier].network_mode publicverifier 阶段的网络策略覆盖为公网可达与[environment]基线不同但由于是独立环境无需动态切换策略。[verifier.environment]独立 verifier 容器的完整环境定义schema 与顶层[environment]完全一致这里同样配置了network_mode public和一致的资源配额。[agent].network_mode no-networkagent 阶段显式覆盖为断网timeout_sec 120.0给 agent 120 秒完成操作。注意[verifier].timeout_sec 60.0与[agent].timeout_sec 120.0的差异验证阶段通常比 agent 阶段更短因为它只做确定性的检查。environment_mode 的取值与隐式推导根据 config.py 中VerifierEnvironmentMode与VerifierConfig的定义environment_mode有两个取值取值含义sharedverifier 直接运行在 agent 的环境中共享同一个容器/文件系统separateverifier 运行在专用容器中与 agent 环境隔离它的推导规则实现于 verifier_mode.py 的_resolve_mode()显式设置environment_mode时以显式值为准未显式设置但定义了[verifier.environment]时隐式推导为separate两者都未设置时推导结果为未指定最终回退为shared。此外[verifier.environment]的查找顺序是步骤级 verifier.environment 任务级 verifier.environment 顶层 [environment] 的深拷贝见resolve_effective_verifier_env_config()。这意味着即使不写[verifier.environment]只要显式声明environment_mode separateHarbor 也会基于顶层[environment]复制一份全新的环境给 verifier 用——这就是本任务中[verifier.environment]与[environment]字段高度重合的原因。同时shared与environment互斥[verifier].environment_modeshared搭配[verifier.environment]会直接触发配置校验错误config.py。四、agent 阶段行为在断网环境下探测并留下证据agent 阶段需要完成任务而本任务的解法参考 solve.sh恰好展示了如何在断网环境下自证断网#!/bin/bash set -euo pipefail mkdir -p /logs/artifacts python3 - PY from pathlib import Path from urllib.request import Request, urlopen try: request Request( https://example.com/, headers{User-Agent: harbor-network-policy-verifier-separate-agent}, ) with urlopen(request, timeout5) as response: response.read(1) status reachable except Exception: status blocked Path(/logs/artifacts/agent-network-status.txt).write_text(status) PY printf agent-only\n /tmp/agent-only-sentinel.txt这段脚本的核心设计值得学习用 Python 标准库探测网络urllib.request发起对https://example.com/的 GET 请求timeout5保证请求不会无限挂起任何异常DNS 解析失败、连接超时、代理拒绝等都会落入except Exception分支。结果写入 artifact 目录/logs/artifacts是 Harbor 约定的 artifact 收集目录agent-network-status.txt写入blocked或reachable两个确定性的状态值后续 verifier 只需比对字符串即可打分。写入隔离哨兵/tmp/agent-only-sentinel.txt只存在于 agent 环境的/tmp下用于后续验证环境隔离性。运行在no-network策略下时这次请求必然失败因此最终写入的应是blocked。这正是任务期望的标准答案。五、验证阶段独立环境中检查网络与隔离verifier 阶段执行 test.sh它在一个独立的、公网可达的容器里完成三项断言#!/bin/bash set -u mkdir -p /logs/verifier reward1 fail() { echo $1 reward0 } if [ ! -s /logs/artifacts/agent-network-status.txt ]; then fail missing agent network status artifact elif [ $(cat /logs/artifacts/agent-network-status.txt) ! blocked ]; then fail agent reached example.com despite [agent].network_mode no-network fi if [ -e /tmp/agent-only-sentinel.txt ]; then fail separate verifier environment unexpectedly sees agent-only /tmp sentinel fi if ! python3 - PY from urllib.request import Request, urlopen request Request( https://example.com/, headers{User-Agent: harbor-network-policy-verifier-separate-verifier}, ) with urlopen(request, timeout5) as response: body response.read().decode(errorsignore).lower() if example domain not in body: raise SystemExit(1) PY then fail verifier could not reach example.com despite [verifier].network_mode public fi echo $reward /logs/verifier/reward.txt逐段解读验证逻辑断言 1agent 确实断网。test.sh先检查/logs/artifacts/agent-network-status.txt是否存在且非空-s再比对内容必须严格等于blocked。这证明 agent 阶段的no-network策略被真实执行而不是形同虚设。断言 2环境隔离生效。检查/tmp/agent-only-sentinel.txt是否存在——在separate模式下它必须不存在因为 verifier 跑在独立的容器里看不到 agent 的/tmp。这条断言直接验证了environment_mode separate的文件系统隔离语义。断言 3verifier 可以联网。verifier 自己在公网环境下重新请求https://example.com/并校验响应正文包含example domain字样证明[verifier].network_mode public生效。结果输出所有断言通过时reward1否则reward0最终写入/logs/verifier/reward.txt。任何一条失败都会通过fail()打印原因并归零奖励便于调试。注意这里的/tmp检查与常见评测任务的差异多数任务只需检查agent 是否完成了动作而这个任务刻意利用/tmp哨兵验证separate 模式的副作用——agent 环境的临时文件不会泄漏给 verifier。这一点在 trial.py 中也有对应实现当模式为SEPARATE时走_run_separate_verifier()分支独立容器否则走_run_shared_verifier()分支复用 agent 容器并重置共享目录两种模式在代码层面就是完全不同的执行路径。六、artifact 传递环境隔离下的数据通道separate模式下 agent 与 verifier 文件系统互相隔离那 agent 的结果如何交给 verifier答案是 Harbor 的artifact 收集机制。agent 阶段把证据写入/logs/artifacts/这是 Harbor 默认的 artifact 收集目录对应 config.py 中ArtifactConfig的容器内 source 路径在 verifier 启动前Harbor 把这些文件从 agent 环境收集下来再挂载/注入到独立的 verifier 环境中的相同路径/logs/artifacts/于是test.sh可以直接读取/logs/artifacts/agent-network-status.txt无需任何额外协议。这种设计是证据链思想verifier 只信任收集到的 artifact不信任 agent 环境的当前状态。ArtifactConfigconfig.py还支持destination目标相对路径、exclude排除模式、servicecompose 服务收集等字段足以覆盖复杂场景。同样的模式也出现在矩阵中的其他任务里例如 static/e-ve[environment]为no-network[verifier.environment]为public其 test.sh 同样从/logs/artifacts读取 agent 的网络状态并自行联网验证——这就是 separate 模式的通用范本。七、源码级解析separate 模式是如何被决定与执行的要真正理解这个任务还应该知道 Harbor 底层是如何处理environment_mode的1. 模式解析配置层resolve_task_verifier_mode()与resolve_step_verifier_mode()位于 verifier_mode.py。前者处理单步任务后者按步骤级显式模式 步骤级 environment 隐式 separate 继承任务级 默认 shared的优先级解析多步任务中每个 step 的 verifier 模式。resolve_effective_verifier_env_config()则决定 separate 模式下的环境定义来源。2. 执行分支运行层在 trial.py 的_run_step_verifier()中mode VerifierEnvironmentMode.SEPARATE走_run_separate_verifier()否则走_run_shared_verifier()。前者为 verifier 创建独立容器并注入 artifact后者在 agent 容器内直接执行并重置共享目录。3. 记录与重判结果层trial 结果会记录解析出的verifier_environment_modetrial.pyregrade.py 则明确规定共享模式shared的 verifier 依赖仍然存活的 agent 环境无法用录制的 artifact 重判——如果需要基于 artifact 重判必须设置[verifier] environment_mode separate并从/logs/artifacts读取输入。这也解释了为什么本任务刻意把全部判断依据都放进/logs/artifacts它是可重判性regradability的前提。4. 测试保障tests/unit/trial/test_network_policy.py 中覆盖了[verifier] network_mode、[verifier.environment]与各阶段策略的组合解析断言静态用例阶段策略 基线策略时不会触发set_network_policy调用、动态用例则产生预期调用序列为本任务的配置语义提供了单元级验证。八、运行与验证如何实际执行这个任务在仓库根目录下可以直接用 Harbor CLI 运行整个静态矩阵或单个任务。根据 README.md在 E2B 上跑全部静态用例的命令是harbor run --path examples/tasks/network-policy-matrix/static -e e2b -a oracle --n-concurrent 20 -y只跑单个verifier-separate-mode任务则指向具体目录即可harbor run --path examples/tasks/network-policy-matrix/static/verifier-separate-mode -e e2b -a oracle -y其中-e e2b选择 E2B 环境 provider-a oracle使用 oracle agent即执行solution/solve.sh--n-concurrent 20控制并发数。如果使用本地 Docker需要注意 README 中列出的兼容性限制Docker 的no-network、allowlist与动态切换场景需要 Linux 容器Windows Docker 容器不支持这些网络策略模式。运行后可以从 trial 输出中核对三个事实agent-network-status.txt内容为blockedagent 断网生效、reward.txt为1verifier 联网与环境隔离均验证通过。九、延伸从本任务出发看懂整个矩阵verifier-separate-mode只是矩阵中的一个演示点理解了它就能快速读懂矩阵中其他相似用例static/e-veeno-network、vepublic、separate verifier、无阶段覆盖——与本任务几乎同构但没有显式的[agent]/[verifier]网络覆盖。static/e-ve-no-network方向相反epublic而veno-network验证独立验证环境可以比 agent 更封闭。static/e-a-v-samee a v全部显式no-network验证策略一致时的行为。static/sv-sve-same多步任务中的sv sve publicstep 级 separate verifier对应resolve_step_verifier_mode()的解析路径。这些用例共同构成了一张阶段 × 环境 × 网络模式的完整覆盖矩阵而verifier-separate-mode是理解它们的最佳切入点。十、小结通过network-policy-matrix/static/verifier-separate-mode这个任务可以完整掌握 Harbor 三个相互关联的能力阶段级网络策略[agent]、[verifier]可独立覆盖[environment]基线取值no-network/public/allowlist独立验证环境verifier.environment_mode separate让 verifier 在专用容器运行获得独立的网络与文件系统配置上可省略[verifier.environment]自动复制顶层环境artifact 传递 可重判性agent 将证据写入/logs/artifactsverifier 据此打分这也是 regrade 对 separate 模式的基本要求。对于评测平台设计者而言这个任务展示了一种非常实用的安全模式让能力边界不确定的 Agent 在完全隔离的沙箱里执行让确定性的验证逻辑在独立且可控的环境中运行两者之间只通过显式收集的 artifact 通信。赞分享【免费下载链接】harborFramework for evaluating and improving agents项目地址https://gitcode.com/gh_mirrors/harbor17/harbor点击查看免费下载相关推荐探索现代化品牌图标解决方案Simple Icons 完全指南探索现代化品牌图标解决方案Simple Icons 完全指南 在当今的数字化产品开发中高效管理品牌图标资源已成为每个开发者面临的挑战。Simple Icon前端UI组件OptiScaler革命性游戏超采样技术桥接器 - 智能GPU兼容解决方案OptiScaler革命性游戏超采样技术桥接器 智能GPU兼容解决方案 在现代PC游戏体验中超采样技术已成为提升画质和性能的关键。然而显卡厂商的技术壁垒让图形学游戏开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
