Level 3 → Level 4：一次 Harness 升级的实录
Level 3 → Level 4：一次 Harness 升级的实录 —— 六个真实缺陷，和它们是怎么被抓住的 作者：小周 上一篇《Harness Engineering 从入门到实战》里，我按 Fowler 的方法论从零搭了一个带 Harness 的排班系统，走到了 Level 3。 但那篇的第三部分「Level 4 进阶实战」只有讲解，没有落地——我列出了四个实操，一个都没做。这篇是补课记录。 不过这篇文章不打算写成「我是怎么搭成功的」。那种文章没什么价值，因为真正的知识不在成功路径上。 我要写的是：这一路上我踩了哪些坑、每个坑是怎么被抓住的、以及为什么单靠"更努力"抓不住它们。 全文有 6 个真实缺陷，每一个都是：先做错 → 被抓住 → 修好 → 变成永久防护。 先说结论：这篇最有价值的部分，是我的错误 升级过程中，被抓住的问题按严重性排： #问题危险在哪谁抓到的1验证闸门失败却返回成功闸门形同虚设，给虚假安全感手工排查2架构检查漏检（用 grep）以为在检查，其实没检查到位对抗测试3闸门被整体替换，自检拦不住所有防护一夜失效对抗测试4架构检查误报（还是 grep）噪声让人绕过检查正常运行暴露5测试假覆盖测试全绿，但删掉代码也不报错子 Agent 变异测试6死代码 + 文档撒谎安全推理建立在假前提上子 Agent 审查 注意第 1、2、3 条的共同点：它们都不是"某个功能没实现"，而是"某个本该把关的东西，其实没在把关"。 这类缺陷最可怕，因为它让你以为自己是安全的。 第一部分：Level 3 → Level 4，要补什么 按 Fowler 文章第 22 章，Level 4（Agent Platform）的特特征有七项。对照我的排班项目盘点： Level 4 特征升级前状态这篇做了什么Review agents❌ 未做✅ AI 代码审查（Inferential Sensor）Permissions⚠️ 只有文字约束✅ 校验和基线 + CI 独立比对Observability❌ 未做✅ 验证历史 + 变更审计Orchestration❌ 未做✅ 多 Agent 编排状态机MCP⬜ 可选—Sandboxes⬜ 受限诚实说明做不到（见下文）Multiple agents❌ 未做✅ 真实跑了 Coder/Tester/Reviewer 但开工之前，先发现地基是坏的。 ...