第 8 章：Task 的高级配置与安全边界
第 7 章的 Verifier 已经能够确定性地判断故障报告。现在把它交给另一台运行节点，却出现了更隐蔽的问题：Agent 以 root 身份运行，整个 Trial 都能访问公网；模型 API Key 被写进 task.toml；Verifier 与 Agent 共用文件系统，还直接执行了 Agent 生成的 Python 文件。测试逻辑没有错，评分边界却已经失守。
task.toml 不只是参数清单。它同时表达时间预算、执行身份、资源需求、网络能力和证据转移，是 Task 作者交给运行者的一份安全与可复现性契约。本章继续使用 llmkb/python-port-repair，把第 5～7 章的单容器任务改造成“Agent 可工作、证据可追踪、Verifier 与候选环境隔离”的版本。
读完本章，读者应当能够：
- 为构建、Agent、Verifier 和证据收集分别设置边界；
- 解释
[environment]、[agent]、[verifier]三类网络配置在生命周期中的实际作用； - 按最小暴露原则传递凭据，而不把密钥打包进 Task；
- 使用 Artifact 与 Sidecar 把运行时状态送入独立 Verifier；
- 通过静态解析、能力矩阵和故障注入验收 Task。
8.1 把配置读成生命周期
Harbor v0.18.0 的 Task 配置 schema 默认为 1.3。根级配置包含 task、metadata、agent、environment、solution、verifier 和 artifacts 等部分；旧字段 version 会迁移为 schema_version，但新任务应直接写新名称。schema_version 当前是普通字符串，而不是“自动拒绝所有未来 schema”的兼容性开关。1
这些区块的责任边界值得先写进设计评审：
| 区块 | 应回答的问题 | 不应承载的内容 |
|---|---|---|
[task]、[metadata] | 这个包是谁、用于检索和说明的属性是什么 | 凭据、运行节点私有路径 |
[environment] | 候选环境怎样启动、默认资源和 baseline 网络是什么 | Agent 专用 API Key、评分秘密 |
[agent] | 候选执行的时间、用户与阶段网络是什么 | Task 级 env——v0.18.0 没有这个字段 |
[solution] | Oracle 运行需要哪些变量 | 真实 Agent 凭据 |
[verifier] | 评分在哪运行、以谁运行、如何收集证据 | 候选可控制的测试逻辑 |
artifacts | 哪些不可信数据需要归档或转移 | 整个根文件系统、缓存和秘密 |
先从信任关系写配置，再填数值。metadata 即使可以放任意键，也只是描述信息；不要让运行脚本读取其中的“隐藏答案”。同样，兼容字段 allow_internet、memory、storage 虽会迁移或给出弃用警告，新任务仍应使用 network_mode、memory_mb、storage_mb。保留旧写法会让代码评审者难以判断是在兼容历史数据，还是误用了当前 schema。
先看贯穿本章的安全配置骨架。以下片段假定主镜像已经创建 UID 1000，tests/Dockerfile 已创建 UID 1001；environment/docker-compose.yaml 还声明了名为 audit 的 Sidecar，并在其中提供 /opt/audit/snapshot.py。没有这些镜像契约，TOML 虽能解析，Trial 仍会在运行时失败。
schema_version = "1.3"
artifacts = [
{ source = "/workspace/report.json", destination = "candidate/report.json" },
{ source = "/var/lib/audit/port-events.jsonl", destination = "audit/port-events.jsonl", service = "audit" },
]
[task]
name = "llmkb/python-port-repair"
description = "修复 Python 服务端口并提交结构化故障报告"
keywords = ["python", "configuration", "incident-report"]
[[task.authors]]
name = "LLMKB"
[metadata]
difficulty = "medium"
category = "system-configuration"
[environment]
build_timeout_sec = 600
os = "linux"
workdir = "/workspace"
cpus = 1
memory_mb = 512
network_mode = "no-network"
[environment.healthcheck]
command = "test -d /workspace"
timeout_sec = 5
interval_sec = 2
retries = 3
[agent]
timeout_sec = 300
user = 1000
network_mode = "allowlist"
allowed_hosts = ["api.openai.com"]
[verifier]
timeout_sec = 120
user = 1001
environment_mode = "separate"
network_mode = "no-network"
[[verifier.collect]]
service = "audit"
command = "python /opt/audit/snapshot.py --output /var/lib/audit/port-events.jsonl"
timeout_sec = 15
user = 1001
[verifier.environment]
os = "linux"
workdir = "/workspace"
cpus = 1
memory_mb = 512
network_mode = "no-network"
这个配置有意把职责分开：主环境启动时断网，Agent 仅在 run() 阶段连接一个 API 主机，Verifier 在另一容器中断网评分；主服务提交报告，Sidecar 冻结端口事件。主环境与 tests/Dockerfile 的基础镜像都应锁定经过验证的 digest，并把测试依赖固化在 Verifier 镜像中。
配置不能替代镜像权限。主镜像至少要提供对应用户和可写工作目录，例如：
RUN groupadd --gid 1000 agent \
&& useradd --uid 1000 --gid 1000 --create-home agent \
&& install -d -o 1000 -g 1000 /workspace
workdir 只选择命令的默认当前目录，不是访问控制边界；user 也只是 Harbor 执行命令时使用的默认用户名或 UID。镜像内的所有权、Linux capabilities、只读挂载和服务接口仍须分别设计。
8.2 时间、身份与资源不是一个旋钮
把所有超时都设成同一个数字很方便，却会丢失诊断信息。v0.18.0 至少有四类与本章相关的预算：
| 配置 | 覆盖范围 | 默认值或语义 |
|---|---|---|
[environment].build_timeout_sec | 主环境 start()；实现中同一解析后预算也用于独立 Verifier 环境启动 | 600 秒 |
[agent].timeout_sec | agent.run() | None 表示 Task 不设此限额 |
[verifier].timeout_sec | verifier.verify() | 600 秒 |
[[verifier.collect]].timeout_sec | 单条快照命令 | 60 秒 |
Agent 的 setup() 有 Trial 层的独立预算，不受 [agent].timeout_sec 控制；环境 healthcheck 的 timeout_sec 则限制单次探测。Job/Trial 还能设置 override、上限与 multiplier，所以结果记录中的有效预算可能小于或大于 Task 基值。源码的解析顺序是“选择 Task 或 override 基值，应用 max，再乘 multiplier”。2
预算应来自正常样本的分位数，而不是凭感觉缩到刚好通过。构建预算容纳冷缓存；Agent 预算容纳合理修复但限制无限循环；Verifier 通常更短且必须确定性结束；collect 只做状态冻结，不应借机执行长分析。出现超时时，先判断是哪一阶段，再增加预算。统一放大所有数字只会隐藏死锁和网络等待。
资源字段描述“Task 需要什么”，Provider capabilities 与 Job 的资源模式决定“是否以及怎样强制”。[environment] 与 [verifier.environment] 都可声明 cpus、memory_mb、storage_mb、gpus、gpu_types、tpu；v0.18.0 会对 GPU、TPU、网络等能力做显式校验，也会按 Provider 的 CPU/内存能力预检资源策略，但不能由此推断每个已解析字段都会被所有 Provider 强制。Docker 路径声明的资源能力只有 CPU limit 和 memory limit；storage_mb 不会因此变成磁盘配额，GPU 请求则会被能力检查拒绝。不要把“配置能解析”写成“资源已隔离”。3
用户也应分角色：Agent 只写 /workspace 和自己的日志目录；Verifier 只读候选 Artifact、写 Reward；Sidecar 只写自己的审计目录。不要让 Agent 对 /tests、/solution 或 Verifier 镜像内容有写权限。使用 shared Verifier 时，即使 UID 不同，同一文件系统中的宽松权限仍可能破坏边界；这正是高价值评分更适合 separate 模式的原因。
数值 UID 比用户名更便于跨镜像审计，但它不会自动在镜像中创建 passwd 记录。某些工具需要可用的 home、shell 或用户名解析，因此 CI 应分别以 UID 1000 和 1001 执行 id、pwd、工作目录写入、测试目录写入四项探针。预期是 Agent 能写 /workspace、不能改 /tests；Verifier 能读取恢复后的 Artifact、不能修改测试程序，并能在 Harbor 准备的 Verifier 日志目录写 Reward。若探针失败，修改镜像所有权和目录模式；不要改回 root 来“证明任务能跑”。
还要防止属主在 Artifact 传输后发生变化。候选文件原本可由 UID 1000 写入，上传到独立环境时应只作为输入读取；Verifier 若需要规范化数据，应写到自己的临时目录，而不是原地覆盖。这样，归档内容、评分输入和派生中间结果可以分别审计。
8.3 三段运行期网络，以及缺失的“构建段”
Harbor 的网络配置最容易被误读。v0.18.0 有三种模式：public、no-network 和 allowlist。allowed_hosts 只能与 allowlist 同用；条目可以是精确主机名、前导 *. 通配主机名、IPv4/IPv6 字面量或 CIDR，不能写 URL、端口或路径。裸 example.com 不自动包含 www.example.com。4
更重要的是阶段：
| 时间段 | 生效配置 | 本例 |
|---|---|---|
| 镜像 build/pull | 不由 Task 运行期网络 schema 控制 | 在受控 CI 中预构建、锁 digest |
主环境启动、healthcheck、agent.setup() | [environment] baseline | no-network |
agent.run() | 显式 [agent] override，否则继承 baseline | 只允许 api.openai.com |
shared verifier.verify() | [verifier] override，否则继承主 baseline | 本例不用 shared |
| separate Verifier 启动 | [verifier.environment] baseline | no-network |
separate verifier.verify() | [verifier] override，否则继承其 baseline | no-network |
官方网络文档明确指出 [agent] 只覆盖 agent.run()，不覆盖 agent.setup()；阶段结束后 Harbor 恢复 baseline。阶段 override 要求 Provider 支持动态切换。请求的模式或主机条目超出 capability 时，Trial 在验证阶段失败，不会自动降级成公网。5
这也解释了两个常见意外。第一，若 [environment] 是 no-network，需要在线安装的 Agent 会在 setup 失败，即使 [agent] 是 allowlist。安全做法是预装 Agent；若必须在线安装，则要明确接受 setup 使用更宽 baseline 的风险。第二，[environment].network_mode 不限制 Dockerfile 构建：Docker Provider 先执行 Compose build，再启动带运行期策略的服务。由此可以推断，依赖下载必须在 Task 之外治理，例如锁定基础镜像、使用内部 wheelhouse、生成依赖哈希并在隔离构建器中关闭非必要出口。6
Docker 的非公网策略还有运行环境前提：Linux container、Harbor egress-control Sidecar 需要的 nftables fib 能力，以及动态策略支持。本地 macOS Docker VM 可能缺少对应内核能力。兼容性验证应在实际 runner 上进行，而不是只看 TOML 能否解析。
以下是一个真实会发生的反例：
[environment]
network_mode = "public"
[agent]
network_mode = "allowlist"
allowed_hosts = ["https://api.openai.com/v1"]
它不会把 URL“智能拆解”为主机名，模型校验会报 allowed_hosts entries must be hostnames ... not URLs, ports, or paths。正确值是 api.openai.com。若随后得到 dynamic network policy 不支持的错误，应更换 Provider/runner 或取消阶段切换，而不是退回 public 后悄悄继续基准测试。
8.4 凭据：按角色注入，不按容器倾倒
Task 级 [agent] 没有 env 字段。Agent 密钥属于 Job/Trial 的 AgentConfig，可通过 harbor run 的 --agent-env（--ae）注入；Harbor 只在 Agent setup/run 的 scoped env 中使用它。Task 的 [environment.env] 是整个任务环境需要的变量，[verifier.env] 给 Verifier，[solution.env] 只给 Oracle Solution。三者不是同义别名。7
| 变量入口 | 典型使用者 | 暴露面 | 推荐内容 |
|---|---|---|---|
--agent-env | 安装型 Agent 的 setup/run | Agent 命令及其子进程 | 模型 API Key、Agent 专用 endpoint |
[environment.env] | Task 服务和环境命令 | 候选环境内的持久进程 | 无秘密的功能开关；必要时为服务短期凭据 |
[verifier.env] 或 --verifier-env | Verifier | shared 时仍在主环境；separate 时在裁判环境 | 评分服务配置、裁判专用短期凭据 |
[solution.env] | Oracle Solution | Oracle 路径 | 仅 Oracle 求解确实需要的变量 |
这张表描述的是 Harbor 的注入范围，不是进程级信息流保证。例如 Agent 可以读取自己的变量后写进报告；shared Verifier 的变量也处在同一环境的更大攻击面中。真正敏感的裁判最好不依赖在线秘密：把确定性 fixture 和判定代码烘焙进 separate 镜像，评分阶段断网，通常比给 Verifier 一个长期云端密钥更容易复现和撤销。
在 Task 目录的父目录执行真实 Agent 时，可这样传值：
export OPENAI_API_KEY='由密钥管理器注入的短期值'
uv run --project /private/tmp/harbor-framework-v0.18.0 harbor run \
-p ./python-port-repair \
-a <installed-agent> \
--agent-env 'OPENAI_API_KEY=${OPENAI_API_KEY}'
${VAR} 与 ${VAR:-default} 会在宿主环境解析；缺少无默认值的变量会报错。Harbor 会对名称含 KEY、SECRET、TOKEN 等字样的部分持久化值做模板化或遮盖，但这只是减少落盘暴露，不是秘密保险箱：Agent 本身仍可读取变量，也能把它打印进日志或写入 Artifact。8
警告：不要把真实密钥写进
task.toml、DockerfileARG/ENV、instruction、Solution、fixture 或 Artifact。使用短期、最小权限、可撤销的 per-run 凭据；限制日志收集并在泄漏演练后轮换。网络 allowlist 也不能阻止 Agent 把数据发送给“已允许”的 API 主机。
如果任务内服务确实需要凭据，使用 [environment.env] 的宿主模板，并接受它会暴露给该环境内进程这一事实。只用于裁判的值放进 [verifier.env]，配合 separate 环境。--env-file 便于批量载入宿主环境，但 .env 文件同样不能进入 Task 包或版本控制。
8.5 Artifact 是传输契约，不是可信声明
Harbor 会隐式收集 /logs/artifacts，也允许根级 artifacts 显式声明 source、宿主侧相对 destination、exclude 和 Compose service。source 与 destination 禁止 ..；destination 不能是绝对路径，也不能占用保留的 manifest.json。Sidecar Artifact 的 source 必须为绝对路径。配置模型还会拒绝相互覆盖的 Artifact 目标。9
本章的两个条目分别产生宿主文件：
<trial>/artifacts/candidate/report.json
<trial>/artifacts/audit/port-events.jsonl
这里有一个反直觉细节：destination 只组织宿主归档。上传到 separate Verifier 时，Harbor 按原始 source 重建，因此测试仍从 /workspace/report.json 和 /var/lib/audit/port-events.jsonl 读取。宿主的 manifest.json 记录每次收集状态，但不会自动上传给独立 Verifier。10
[[verifier.collect]] 在收集 Artifact 前进入指定 Compose service 执行快照命令。主服务 hook 在主 Artifact 之前运行；使用 separate 模式时，Harbor 随后停止 main，再运行 Sidecar hook 并下载 Sidecar Artifact。这样可以冻结数据库、代理或审计服务中的运行时状态，同时减少残留 Agent 进程在最后一刻篡改 Sidecar 文件的机会。11
不过，Sidecar 不是天然可信。Agent 或许不能直接写它的文件系统，却可能通过服务 API、共享网络或业务输入影响其状态。可信度来自受限接口、不可伪造的事件来源和 Verifier 的交叉核验，而不是来自 service = "audit" 这一行。collect hook 和 Artifact 下载还是 best effort：失败会写 warning/manifest，却不一定中止 Trial。Verifier 必须对缺失、空文件、错误 schema 和越界时间戳 fail closed，不能把“没有证据”当作通过。
Artifact 还应坚持最小集合。不要搬运整个 /workspace、shell history 或缓存；它们既扩大凭据泄露面，也让 separate Verifier 更容易误执行候选内容。所有来自 Agent 或 Sidecar 的文件都按敌对数据解析：限制大小与行数，固定 UTF-8/JSON schema，禁止 source、eval、动态 import 或执行候选脚本。
Sidecar 接入时需要同时满足三份契约。Compose 契约保证 audit 服务真实存在且 Provider 声明 docker_compose；快照契约保证 collect 命令幂等、在限时内把内存状态落到固定绝对路径；数据契约保证 Verifier 能区分“合法空结果”“快照失败”和“格式损坏”。只写 Artifact 条目而忘记 Compose service，会在 Trial 配置/环境校验阶段失败；只写 collect 而不声明对应 Artifact，则快照会留在即将销毁的容器里。
目录 Artifact 的 exclude 可以过滤缓存或大文件，但过滤规则也是评分契约的一部分。若 Verifier 需要的文件被排除，恢复阶段不会替作者猜测。发布时应保存一份最小预期文件树，并对 manifest.json 中每个条目的状态、实际宿主路径和大小设上限。这样既能发现“收集成功但内容为空”，也能防止候选通过生成巨大 Artifact 消耗宿主磁盘。
8.6 separate Verifier 的真正边界
未指定模式时，Verifier 默认 shared；设置 [verifier.environment] 会推断 separate，也可显式写 environment_mode = "separate"。shared 与 [verifier.environment] 同时出现会被模型拒绝。若只写 separate 而不提供环境，Harbor 会深拷贝顶层 [environment] 作为新环境；安全任务最好显式声明裁判所需的更小镜像、资源和网络，避免无意复制服务凭据与依赖。12
单步 separate 生命周期如下：
启动主环境 → healthcheck → Agent setup/run
→ 主服务 collect/Artifact
→ 停止 main
→ Sidecar collect/Artifact
→ 停止主环境
→ 启动独立 Verifier
→ 按原 source 路径恢复 Artifact
→ 运行镜像内置 tests → 写 Reward → 销毁 Verifier
Harbor 在独立环境中清空 Verifier 日志目录、恢复 Artifact，并以 skip_tests_upload=True 创建 Verifier；这意味着 tests/ 必须在 Verifier 的构建上下文或预构建镜像中，而不是临时从 Agent 环境搬过去。13 第 7 章的 test.sh 和 Python 校验器可原样放进 tests/，但必须只读取报告与审计数据，不能假定主服务仍在线。若评分必须查询 live service，选择 shared 是一种明确权衡：可观察性更强，隔离更弱；另一种做法是在停机前用 Sidecar 快照成不可执行数据，再保持 separate。
separate 也不是虚拟机级安全证明。它显著减少共享进程和可写测试文件的问题，但 Artifact 仍由不可信执行产生，Provider、宿主、镜像供应链仍在信任基座中。高风险场景还需要镜像签名、只读根文件系统、runner 隔离和外部审计。
8.7 验证、兼容性与打包门禁
先做不需要 Docker 的静态门禁。在 Harbor v0.18.0 仓库运行：
cd /private/tmp/harbor-framework-v0.18.0
uv run --frozen python - /path/to/python-port-repair <<'PY'
from pathlib import Path
import sys
from harbor.models.task.task import Task
task_dir = Path(sys.argv[1])
assert Task.is_valid_dir(task_dir), "不是完整的 Harbor Task 目录"
task = Task(task_dir)
print(Task.is_valid_dir(task_dir))
print(task.config.schema_version)
print(task.config.verifier.environment_mode)
print([a.source for a in task.config.artifacts])
PY
预期先看到 True，随后是 1.3、separate 和两个 source。Task.is_valid_dir(...) 与 Task(...) 共同检查 TOML、instruction、environment 目录以及适配当前 Verifier 模式的测试约定。v0.18.0 已移除 harbor task check；同名旧入口只会提示迁移到顶层 harbor check <task-dir>。后者会启动 Agent 按 rubric 做质量检查，有模型成本，也不等同于零成本 schema lint。14
发布前建立兼容性矩阵，而不是只写“支持 Docker”：
| 维度 | 本章声明 | 验收证据 |
|---|---|---|
| Harbor | v0.18.0 / 固定提交 | harbor --version、lock 与 Trial metadata |
| Python | 3.12+15 | CI 解释器版本 |
| OS/架构 | Linux/实际 CPU 架构 | 至少一次目标 runner 构建与 Trial |
| Provider | Docker + Compose | capability 校验、Compose service 存在 |
| 网络 | baseline no-network、Agent 动态 allowlist | setup/run 两阶段出口探针 |
| 资源 | CPU 1、内存 512 MB | Provider 实际限制与 OOM 反例 |
| Verifier | separate、断网、UID 1001 | Agent 环境先停；Artifact 原路径可读 |
矩阵必须绑定一次具体运行，而不是复制官方“支持列表”。记录宿主内核、Docker/Compose 版本、CPU 架构和网络能力探针；升级 Harbor、切换 runner 或更换基础镜像后重新执行。某项只完成静态解析时写“未验证”，某项由 capability 拒绝时写“不兼容”，不要把两者都模糊成“暂不支持”。这种区分决定后续是在补实验，还是修改 Task 的部署目标。
Task 打包内容也要验收。v0.18.0 的 Packager 只收集约定的配置、instruction、README、environment/、tests/、solution/、steps/，应用 .gitignore 或默认忽略规则，并按“相对路径 + 单文件 SHA-256”计算内容哈希。16 在发布 CI 中输出最终文件清单与 hash，扫描明文凭据、大文件和意外 fixture；不要假定“文件在 Task 目录之外”就一定不会被 Docker build context 或脚本复制进去。
下面的症状表把“最终得分为 0”拆回首次失效的阶段：
| 症状 | 优先证据 | 常见根因 | 修复方向 |
|---|---|---|---|
| 环境尚未启动就失败 | environment setup 日志 | build timeout、镜像拉取、Compose 名称错误 | 修构建输入或启动预算 |
| Agent setup 访问超时 | setup 日志与 baseline 网络 | 误以为 [agent] allowlist 已生效 | 预装 Agent，或审慎调整 baseline |
| Agent run 无法调用模型 | 阶段网络日志、DNS/出口探针 | host 未列入、runner 不支持动态策略 | 修正主机条目或换兼容 runner |
| 报告在宿主可见、Verifier 却找不到 | Artifact manifest 与原 source | 测试读取了 destination 路径 | 在裁判中按原 source 读取 |
| collect 报警但 Trial 继续 | warning、Sidecar 日志、manifest | hook 非零、超时或用户无权限 | 修快照并让 Verifier 对缺失失败 |
| separate 镜像启动后测试缺失 | Verifier build/start 日志 | 把 tests/ 当成运行时上传 | 把测试固化到其构建上下文/镜像 |
日志中较晚出现的错误常是连锁反应。例如 collect 权限错误会导致 Artifact 缺失，继而触发 Verifier schema 错误；根因仍是第一条权限失败。排障记录应保存每阶段的开始/结束时间、有效用户、有效网络策略和 Artifact 状态，而不是只截取最后一行 traceback。
完整验收至少包含以下故障注入：
- 删除宿主 API Key，确认启动在运行前失败且日志不含密钥；
- 把 allowlist 改成 URL，确认 schema 校验失败；
- 在不支持动态网络的 runner 上运行，确认 capability 拒绝而非公网降级；
- 让 collect hook 返回非零或删除 Sidecar Artifact，确认 Verifier 给 0 并留下 warning/manifest；
- 令 UID 1000 无权写
/workspace，确认失败归因于权限，而不是盲目增加 timeout； - 用 Nop、Oracle 和至少一个真实 Agent 各跑多次，比较 Reward、Artifact manifest 与阶段日志。
排障顺序应遵循生命周期：先解析配置和能力，再看环境 build/start，然后是 healthcheck 与 Agent setup，接着检查 Agent run 的网络/超时，最后检查 collect、Artifact manifest 和 Verifier 日志。这个顺序比从最终 Reward 反推全部原因更快，也更不容易把基础设施故障误判成模型失败。
注意：本章写作环境没有 Docker，因此安全配置完成了 v0.18.0 模型解析与源码/单元测试核验，但没有声称完成 Compose、nftables 和 separate Trial 的本机端到端实测。最终发布门禁必须在目标 Linux runner 补齐上述步骤。
8.8 本章小结
task.toml是生命周期契约；时间、身份、资源、网络和证据边界要分别表达。[environment]是启动 baseline，[agent]只覆盖agent.run()，[verifier]只覆盖 verify；镜像构建网络另行治理。- Agent 凭据从 Job/Trial 注入，任务服务和 Verifier 变量按角色分开；遮盖日志不能替代秘密管理。
- Artifact 只传数据，宿主
destination不改变独立 Verifier 中的原始source路径。 - Sidecar 可以冻结主服务外的状态，但不是天然可信；缺失证据必须 fail closed。
- separate Verifier 缩小共享状态与投机面，代价是不能直接观察已停止的 live service，并增加镜像与资源开销。
8.9 练习
- 把本章配置中的 Agent 网络改成只允许一个模型 API 的 apex 与子域，分别写精确条目和通配条目；构造 URL、端口、非前导通配符三个无效值并记录校验错误。
- 为
llmkb/python-port-repair创建 UID 1000/1001，收紧/workspace、/tests与/logs/verifier权限。分别以 Agent 和 Verifier 身份执行读写矩阵，证明最小权限成立。 - 让
auditSidecar 记录主服务端口探测，collect hook 把内存状态冻结为 JSONL。故意让 hook 超时，验证 Trial 继续、manifest 记录失败且 Verifier 返回 0。 - 比较 shared 与 separate 两个版本：在 Agent 退出后留下后台篡改进程，观察两种模式对候选报告和 Sidecar Artifact 的影响；说明哪些攻击仍可通过服务 API 完成。
- 在两种 Provider 或两种 Docker runner 上填写兼容性矩阵，至少覆盖动态网络、CPU/内存限制、Compose Sidecar 和独立 Verifier。任何无法实测的格子标记为“未验证”，不要写成“支持”。