Level 3 → Level 4：一次 Harness 升级的实录

—— 六个真实缺陷，和它们是怎么被抓住的

作者：小周

上一篇《Harness Engineering 从入门到实战》里，我按 Fowler 的方法论从零搭了一个带 Harness 的排班系统，走到了 Level 3。

但那篇的第三部分「Level 4 进阶实战」只有讲解，没有落地——我列出了四个实操，一个都没做。这篇是补课记录。

不过这篇文章不打算写成「我是怎么搭成功的」。那种文章没什么价值，因为真正的知识不在成功路径上。

我要写的是：这一路上我踩了哪些坑、每个坑是怎么被抓住的、以及为什么单靠"更努力"抓不住它们。

全文有 6 个真实缺陷，每一个都是：先做错 → 被抓住 → 修好 → 变成永久防护。

先说结论：这篇最有价值的部分，是我的错误

升级过程中，被抓住的问题按严重性排：

注意第 1、2、3 条的共同点：它们都不是"某个功能没实现"，而是"某个本该把关的东西，其实没在把关"。

这类缺陷最可怕，因为它让你以为自己是安全的。

第一部分：Level 3 → Level 4，要补什么

按 Fowler 文章第 22 章，Level 4（Agent Platform）的特特征有七项。对照我的排班项目盘点：

但开工之前，先发现地基是坏的。

第二部分：第 0 步 —— 修地基（顺便发现两条隐藏缺陷）

缺陷 1：验证闸门失败却返回成功

这个项目是两个月前在另一台机器上搭的，后来换了电脑。跑 verify.sh 时我看到：

════ 开始验证 ════
✅ [lint] 语法通过
✅ [architecture] 边界满足
scripts/verify.sh: line 16: /home/openclaw/.../python3: No such file or directory
→ EXIT=0

注意最后一行：测试根本没跑起来，退出码却是 0（成功）。

根因有两条叠加：

1. 脚本里写死了上一台机器的绝对路径（用户名都不对了）
2. verify.sh 用顺序调用 + set -e，但子脚本失败时没有正确传递退出码

所以这个"验证闸门"从来就没生效过——它永远说通过。

一个永远通过的 verify，比没有 verify 更糟。因为你会以为自己是安全的。

修法：改成"收集式"

原来的写法是：

bash scripts/lint.sh
bash scripts/architecture-check.sh
bash scripts/test.sh
echo "✅ 全部通过"

改成逐个跑、记录失败、全部跑完统一报：

SENSORS=("lint:scripts/lint.sh" "architecture:scripts/architecture-check.sh" "test:scripts/test.sh")
FAILED=()
for entry in "${SENSORS[@]}"; do
  name="${entry%%:*}"; script="${entry#*:}"
  if ! bash "$script"; then FAILED+=("$name"); fi
done

if [ ${#FAILED[@]} -ne 0 ]; then
  echo "❌ verify.sh 失败 — 任务未完成"
  echo "    失败的 sensor: ${FAILED[*]}"
  exit 1
fi

为什么改成收集式而不是遇错即停：失败的时候，你需要看到全部问题，而不是被第一个失败挡住。

缺陷 2：架构检查"说了不做"

architecture-check.sh 的注释写着：

# 架构边界检查：src/ 里禁止危险调用；service 不依赖 CLI

但实际上，它只检查了第一句（危险调用），第二句「service 不依赖 CLI」代码里根本没实现。

这是一条"说了但没做"的 sensor —— 比没有更糟，因为文档说它有。

我把它拆成三条可执行约束写进 ARCHITECTURE.md：

验收：对抗测试

改完后我做了第一次对抗测试——故意注入违规，看能不能被拦住：

干净代码              → ✅ EXIT=0
注入 A2 违规           → ❌ EXIT=1，点名 architecture   ← 拦住了
注入 A3 违规           → ✅ EXIT=0                       ← 漏了！

A3 漏检了。这是缺陷 2 的延续——我第一版 A3 用 grep 写：

grep "members.json" src/main.py | grep "open\|write_text"

而注入的违规长这样：

STATE_FILE = Path(...) / "state" / "members.json"
STATE_FILE.open("w").write("[]")        ← 这行里没有 "members.json" 字样！

路径早就存进变量了，grep 只认字面字符串，认不出经变量间接引用。

改用 AST

我重写成 Python 的 AST 解析：先找出「指向 state 的变量名」，再检查有没有对这些变量调用写方法。

# 收集指向 state 的变量
for node in ast.walk(tree):
    if isinstance(node, ast.Assign) and is_state_related(node.value, lines):
        for tgt in node.targets:
            if isinstance(tgt, ast.Name): state_vars.add(tgt.id)

# 检查写操作
if isinstance(node, ast.Call):
    name = getattr(node.func, "attr", None) or getattr(node.func, "id", None)
    if name in WRITE_METHODS: ...

重测：A3 违规 → ❌ EXIT=1，抓住了。

第一次教训：grep 只认字面字符串，认不出间接引用。（没想到，后面还会再栽一次）

第三部分：实操一 —— Review Agent（Inferential Sensor）

Fowler 第 9 章把 sensor 分成两类：

确定性检查抓不到"这段代码设计得好不好"，那是 Review Agent 的活。

实现：把 diff 发给 LLM

核心是 review-agent.sh：取 git diff → 发给模型 → 解析 VERDICT: PASS/FAIL。

凭据处理很关键：我没有在脚本里塞 API key，而是用 openclaw infer model run —— 凭据由 OpenClaw 管理，脚本里一个 key 都不出现。

两个重要设计决策

决策一：Review Agent 不进 verify.sh

如果把 AI 审查塞进日常验证：每次要等几十秒，还会随机失败。结果就是人会习惯性地绕过它——那比没有更糟。

所以拆成两层：verify.sh（快，必跑）和 verify-all.sh（含 AI 审查）。

决策二：解析逻辑必须自测

Inferential Sensor 有个隐蔽的失效模式：模型输出格式不符时，解析逻辑可能把它当成通过。

我第一版就是这么写的（解析不出 VERDICT 就放行）——这是错的。改成硬失败后，写了个 review-selftest.sh，用 mock 注入 6 种输出：

VERDICT: FAIL                        → 必须 exit 1  ✅
VERDICT: PASS                        → 必须 exit 0  ✅
垃圾输出（无 VERDICT）                → 必须 exit 1  ✅
空输出                                → 必须 exit 1  ✅
VERDICT:FAIL（无空格）                → 必须 exit 1  ✅
Stream ended without finish_reason   → 必须 exit 1  ✅

实测效果

注入三个真实 bug（SQL 注入 / 除零 / 硬编码密钥），Review Agent 自己找出来了：

VERDICT: FAIL
- [CRITICAL] rotator.py:51 — SQL 注入：用户输入直接拼接到 SQL 查询字符串中
- [CRITICAL] rotator.py:56 — 除零错误：分母恒为 0
- [CRITICAL] rotator.py:58 — 硬编码 API 密钥，存在凭证泄露风险

注意它不是模式匹配——"除零"这种问题靠语义判断，grep 抓不到。干净代码则返回 PASS，不误报。

这一节的意外收获：自测救了我

修 pathspec 的时候我引入了新 bug：

SELF_DIR=$(git rev-parse --show-prefix)   # → "duty-rotator/"
git diff -- "${SELF_DIR}*.py"             # → "duty-rotator/*.py" ✗ 匹配不到

从子目录跑 git diff 时，pathspec 是相对当前目录的，加了前缀反而匹配不到 → diff 为空 → 审查被静默跳过。

是 review-selftest.sh 当场抓出来的（它期望 FAIL 却得到 EXIT=0）。

又一次印证：sensor 自己的 bug，只有对抗测试能发现。

第四部分：实操二 —— 真正的权限（本节最重要）

先证明：文字约束毫无作用

AGENTS.md 里写着：

## 权限边界
- ❌ 无权修改 scripts/ 和 .github/（Harness 本体）

我做了一个实验：把验证闸门整体替换成永远通过：

cat > scripts/verify.sh <<'EOF'
#!/bin/bash
echo "✅✅ 全部通过"
exit 0
EOF

# 然后故意注入一个必定失败的测试
bash scripts/verify.sh
→ ✅✅ 全部通过          ← 测试明明挂了，闸门却说通过

结论：文字约束防不住任何东西。

Fowler 第 10 章：不让它做不到，而不是告诉它别做。

先诚实探明能力边界

动手之前我先查了这台机器能做到什么：

❌ 不能 chown 换属主（非 root）
❌ 不能 chattr +i（非 root）
❌ 只有一个用户
→ 内核级隔离做不到

真正的沙箱需要 独立用户 + 内核隔离（landlock / bwrap / seccomp），那是 Codex 的 linux-sandbox 那个级别。我这里做不到。

所以我不假装它是墙。能做到的是：提高门槛 + 留下痕迹。

落地：四层防护

第 2 层是把 Harness 本体的指纹（sha256）冻结在 agent/harness.sha256，verify.sh 第一关就校验它。

缺陷 3：自检式闸门是循环的（最重要的发现）

挂上完整性检查后，我跑了完整的对抗测试矩阵：

改 architecture-check.sh   → ✅ 拦住（EXIT=1）
往 scripts/ 加新文件        → ✅ 拦住（EXIT=1）
删 integrity-check.sh       → ✅ 拦住（EXIT=1）
整体替换 verify.sh          → ❌ 拦不住（EXIT=0）   ← ！
改闸门 + 重建基线掩盖        → ❌ 拦不住（EXIT=0）   ← ！

根因：verify.sh 在检查自己的完整性——它被替换时，内部检查自然不会执行。这是所有"自检式闸门"的固有局限：自己检查自己在逻辑上是循环的。

更麻烦的是第二条：攻击者改完闸门再重建基线，本地就完全看不出来了。

真正的防线必须在闸门之外

这两个漏洞，靠加固 verify.sh 是解决不了的。我在 CI 里加了两个独立于本地文件的检查：

检查一：直接对比 git 里的基线（不调用本地脚本）

while IFS= read -r line; do
  expected="${line%% *}"; file="${line#*  }"
  actual=$(sha256sum "$file" | cut -d' ' -f1)
  [ "$actual" != "$expected" ] && { echo "❌ 与基线不符: $file"; fail=1; }
done < agent/harness.sha256

攻击者改本地文件没用——CI 在干净的 checkout 上跑，用的是仓库里的基线。

检查二：闸门有效性探针

# 注入一个必定失败的测试，验证闸门确实会返回非 0
printf '\ndef test_ci_probe(): assert False\n' >> tests/test_rotator.py
bash scripts/verify.sh; code=$?
[ "$code" -eq 0 ] && { echo "❌ 闸门被掏空"; exit 1; }

这个探针能识破"闸门被换成永远通过"——因为它不看闸门说了什么，只看它对已知失败的响应。

把能力边界写进文档，不吹牛

最后我把这段诚实说明直接写进了 verify.sh 的注释：

# 【重要】本文件的防护能力边界（诚实说明，不要误解）
#
# 实测确认（2026-09-18 对抗测试）：
#   整体替换 verify.sh        → ❌ 拦不住（EXIT=0）
#   改闸门 + 重建基线（掩盖）  → ❌ 拦不住（EXIT=0）
#
# 真正拦住后两种的，是闸门之外的防线：
#   第 2 层  CI —— 在干净环境跑，直接对比 git 中的基线
#   第 3 层  人看 git diff
#
# 本层的作用是「提高门槛 + 留下痕迹」，不是不可绕过的墙。

这一节的价值不在于我做出了多强的防护，而在于我搞清楚了它拦不住什么。

❌ 没有 logs/ —— verify 跑 3 次零痕迹
❌ members.json 改动只靠 git，Agent 不提交就查不到
❌ progress.md 是人工手写的，会漏会忘

❌ [architecture] A1 违反：禁止 os.system/subprocess/eval
     src/service/rotator.py:6: 为什么用原生文件写入而不是 subprocess 调 scripts/audit.sh：

os.system                    → ✅ 拦截
subprocess.run               → ✅ 拦截
eval 调用                    → ✅ 拦截
import subprocess as sp      → ✅ 拦截（能识破别名绕过）
注释提及 subprocess           → ✅ 放行（不误报）
字符串含 "eval("              → ✅ 放行（不误报）

子任务 A → ✅ 过 verify
子任务 B → ✅ 过 verify
     ↓ 合并
  谁验过「A+B 合并后」的状态？    ← 没人

子任务申请 write:scripts   → ❌ 永久禁止（Harness 本体的写权限）
子任务申请 write:agent     → ❌ 永久禁止（不许伪造自己的进度）
子任务申请父级没有的能力    → ❌ 权限放大
合法子集                    → ✅ 通过

st-003 [coder]    → 加 swap 方法
st-004 [tester]   → 补单元测试（依赖 coder）
st-005 [reviewer] → 审查实现与测试（依赖前两者）

# ❌ 错：子 Agent 说完成就标 DONE
# ✅ 对：编排者自己跑 verify，通过了才标 DONE

弱断言（只查类型）+ 删掉 b 校验  →  13 passed   ← 变异溜过去了
强断言（钉住消息）+ 同一个变异   →  1 failed    ← 被抓住

文档说：audit.log 有「动作 + 时间 + 用户」
实际上：_audit() 从不写用户

我当时想的：   "只绑内网更安全"（我的意图是好的）
实际发生的：   我把主人正在用的东西弄坏了