AI Harness安装≠激活：Codex生命周期验证实践

安装不等于激活：为什么 AI 框架必须自证

安装一个系统和证明它在运行，这是两回事。

我们为此付出了代价。

项目最初的想法是给 Codex 配备一个从 Claude 衍生出来的大型框架：钩子、记忆系统、账本、安全门、自检，以及各种配套器官。第一个问题很简单：

这个框架真的能跑起来吗？

第一次回答令人鼓舞，但不够完整。

保留了一份只读副本。创建了一个独立的可写运行时来管理状态和账本。配置好的钩子注册表成功回放。器官电池测试跑出了 50 次通过和 2 次失败。行为探测产生了 8 次通过和 2 次失败。

这是有用的证据——但不是证明 Codex 已经成为了 Claude 生命周期的原生宿主。

这个框架可以当作外部外骨骼来运行。这和证明 Codex 本身原生执行了相同的生命周期是两回事。

同时还存在一些具体的缺口。

动作门拦截了递归 Unix 风格的删除，但漏掉了等价 PowerShell 形态。另一个良心检查漏掉了两个强声明用例。某个记忆测试包含了一个过时的 fixture 期望值。某个安全测试通过了断言，但之后在 Windows 清理阶段遇到了问题。

于是我要求再做一次测试。

新一轮的证明测试抓到了一个我自己测试中的问题：Sentinel 已从 RED 变成了 YELLOW，但我的探测器仍然期望它保持 RED。这意味着探测器测试的是一个冻结的假设，而不是测试实时的状态机。

修复很简单，但很重要：

一个有效的测试应该验证系统报告的是当前状态，而不是要求状态保持不变。

然后是更重要的请求：构建一个 Codex 原生版本。

Claude 的克隆体保留为标本。Codex 的适配版本运行在自己的工作空间里。它使用相同的原则，但配备了 Codex 和 PowerShell 感知的门控、显式的预检和最终检查入口点，以及针对第一轮暴露出的漏洞设计的测试。

第一次运行得分 9 / 10。

失败不是安全绕过。最终检查表达式过于僵化。它只在验证块以某种精确格式出现时才接受。修复方案在不削弱证据必须存在这一要求的前提下，扩大了可接受的证据形态。

第二次运行达到了 10 / 10。

这层适配层现在拦截了受保护框架的递归删除、远程获取并执行模式、强制推送 Git 分支，以及没有显式验证或收据块情况下的强完成声明。

这个结果是有意义的，但它仍然不意味着整个 Claude 有机体已经被复现。原始移植版本仍然有两个有意义的行为失败。Codex 原生层是 Codex 自己运行时的更小、更明确的强制执行面。

这个区别很重要。

一个通过的测试仍然可能具有误导性，如果测试已经过时的话。配置好的钩子仍然可能未激活。可见记忆文件仍然可能未被观察。包装器仍然可能在底层进程成功后声称失败。

configured 不等于 loaded

loaded 不等于 trusted

trusted 不等于 executed

executed 不等于 automatically correct

correct 在没有检查真实收据之前不等于 complete

因此，第二轮的报告比第一轮更加诚实。初始验证大部分是对的，但力度不足。它证明了移植的框架可以运行，并暴露了真实的缺口。新的自框架证明了 Codex 有自己的经过测试的强制执行层。

这是我带到每个 AI 系统中的教训：

一个特性不因为它的文件存在就是真实的。它是真实的，当运行时展示出行为时，当负面用例表现正确时，当最终声明有证据支撑时。

目标从来不是让系统听起来更有活力。目标是让它更加负责任。

而责任始于一条简单的规则：

不要告诉我它已经安装了。告诉我它运行了。