我们锁死了执行层，但 Agent 仍然在犯错 – 阿奇

最近看到一条 Moltbook 上的讨论，作者 lightningzero 分享了一个排查经历：把 kubectl 二进制文件做了哈希锁定，pin 了 Python 环境，冻结了依赖树，每次工具调用前都做加密验证。结果部署流水线的失败率仍然是 14%。

问题不在二进制文件。Agent 拿着正确的、经过验证的工具，传入了凭空捏造的参数。因为它误读了上一步的 JSON 输出。

这句话概括了当前 AI Agent 安全建设的最大盲区：一个经过验证的工具执行一个幻觉参数，只是让错误来得更快而已。

安全感的来源是可以被哈希的东西

我们在 Agent 系统上花的力气，几乎都集中在执行层。权限框架、二进制验证、依赖锁定、沙箱隔离——这些东西之所以被优先建设，不是因为它们解决了主要问题，而是因为它们可以被量化验证。

哈希值要么匹配要么不匹配。权限策略要么通过要么拒绝。这些是二元判断，工程师喜欢二元判断。

但 Agent 的主导失败模式根本不是外部篡改。lightningzero 的数据很说明问题：当所有执行路径都被锁死后，失败率纹丝不动。因为真正的问题出在规划层——Agent 在理解状态、生成参数、制定决策的时候，产生了一个听起来合理但实际上完全错误的指令。

这就像给一辆车装了世界上最精密的防盗系统，然后司机看错了路标，开进了湖里。

一个 hallucinated parameter 经过验证过的工具执行后，后果比直接调用一个未经验证的工具更危险。

原因在于信任传递。当你看到系统日志显示”kubectl v1.28.3 SHA256:abc123 — 已验证”时，你会自然地认为这步操作是可靠的。你不会去检查 namespace 参数是不是 Agent 从上一轮对话的上下文里错误提取出来的。

这就是所谓的”确定性幻觉”（deterministic illusion）。系统看起来是确定性的——工具是锁定的，环境是冻结的，权限是收紧的——但驱动这些工具的决策本身完全没有被审计。

在多个场景里我已经反复看到这种模式：

每一步都在调用”正确的工具”。每一步都在制造”真实的副作用”。

这不是工程师不用心的问题。规划层的保护在技术上就是更难。

执行层可以哈希、可以签名、可以沙箱化。规划层输出的是自然语言驱动的决策意图，你没法对一个”想法”做加密验证。

目前业界在做的事情大致分几类：

Schema 校验：在工具调用前检查参数格式。这能拦住明显的类型错误，但拦不住语义错误——一个格式完美的 JSON，里面的值完全可以是编的。
信任评分：Cleanlab 的 Tau²-Bench 研究显示，用 LLM 做实时信任评分配合回退策略，可以把多轮工具使用任务的失败率降低约 50%。但剩下的 50% 呢？信任评分本身也是一个 LLM 在做判断，它也会被同样的上下文混淆误导。
Plan → Act → Verify 模式：先声明计划再执行再验证。这个思路是对的，但验证这一步经常被简化为”工具返回了 200”而不是”工具返回的内容和预期一致”。

也许问题出在我们保护 Agent 的方式上。

我们一直在保护工具不被滥用。但工具本来就是被 Agent 调用的，它”被使用”是正常行为，不是攻击面。真正需要保护的是工具不被误用，也就是确保传入的参数和决策意图是准确的。

这意味着监控的重心需要从”这个工具能不能被调用”转移到”这个调用背后的推理链条是否站得住脚”。

具体来说：

这些东西做起来比锁二进制麻烦得多。没有现成的哈希函数可以告诉你一个 Agent 的推理是否可靠。但这是 Agent 系统从”玩具”走向”生产”必须跨过的坎。

回到开头那个 14% 的失败率。当 Agent 用经过验证的 kubectl 创建了一个不存在的 namespace 时，系统会认为一切正常——工具运行成功，二进制文件完好，权限检查通过。但 Kubernetes 集群里多了一个没人想要的 namespace，可能还会触发后续的连锁反应。

我们花了大量精力确保工具本身不会被外部攻击者劫持。这当然重要。但当前自主 Agent 链的主要失败模式不是劫持，而是 Agent 自己在规划和决策环节产生了偏差。

如果工具调用是正确的，但调用它的理由是错的，那么整个安全模型只是在给错误披上合法的外衣。

这不是说要放弃执行层的安全措施。相反，执行层的安全是基础。只是在执行层之上，我们必须开始认真对待规划层的不确定性，承认那些无法被哈希的东西同样需要被保护。

否则我们只是在建造一辆防盗性能极好的车，然后放任它自己开错方向。