8.0
热点
AI SCORE
编程提效2026-08-28 15:15
LLM批评者在相同输入下每次给出不同判决——代码安全边界不能依赖模型自洽
dev.to · AI#LLM一致性#AI安全#Agent架构
Editor brief · 编辑速览
实验显示LLM批评者在相同输入下标签翻转率和证据漂移率均为1.0（最大非确定性），揭示模型一致性不能作为安全依据，安全契约必须落在代码层而非模型层。
在《我的 Agent 拒绝了 96 次，那就是正确的输出》中，我提出这样一个观点：来自 Agent 规划器的最有价值的输出，往往是一个结构良好的拒绝。本文要探讨的是更难缠的工程问题：当提供拒绝的模型从根本上就不稳定时，如何让拒绝本身变得可信？
简短的回答是：模型不应该成为最终裁决者。
实时边界评估器（#218）是一个很小的基准测试。它只针对每个计划运行 6 个案例，每个案例 5 次试验，每个案例 2 个计划——共 60 次审计。与完整的 183 目标扫测相比，这个规模微乎其微。
但它产生了整个项目中最令人不安的数字。
在相同输入下，批评者产生了：
label_flip_rate = 1.000
evidence_drift_rate = 1.000
每一次试验都产生了不同的裁决。每一次试验都给出了不同的解释。模型并非只是略微不一致——它在相同输入上达到了最大程度的不确定性。
如果你的安全叙事依赖于模型保持一致性，这个数字应该让你感到恐惧。
它没有摧毁信心的原因比我预期的更简单：安全契约并非仅仅压在批评者身上。
架构早已将关键路径移到了代码层。
这故事的第一个版本可不是这样。我必须赢回那个位置。
在 v0.2.1 中，边界运行看起来令人安心：
family_migration_rate = 0.000
underclaim_approvals = 0
这构成了一个干净的叙事：批评者是不确定的，但系统仍然是安全的。我在 v0.2.1 现场测试结果中写了这个故事，方向是对的。
然后 v0.2.2 让故事变得更难讲了。第一次边界运行发生了回退：
family_migration_rate = 0.033
underclaim_approvals = 1
一个带有缺陷的计划得到了零个拦截器。这不是解释漂移。这是一个真正的低报（under-claim）。
好消息不是第一次运行失败了。好消息是基准测试捕捉到了它，而重新运行告诉我们架构的一些有用的信息。
有问题的案例是 verifies-before-consume-vs-consumes-before-verified，方案 b，试验 4。边界测试框架一直将综合目标框定为 balanced 而不是 strict。基准测试部分地在测量一种姿态问题，而非纯粹的批评者问题。
我们将框架改为 strict 并重新运行。最终结果恢复到：
family_migration_rate = 0.000
underclaim_approvals = 0
这是我相信的故事，因为它先经历了一次失败。
1. 确定性门控拥有结构性低报的所有权
门控不读说服性的散文。它们解析计划结构。这意味着无论批评者说什么，顺序、前置条件、回滚和可追溯性都可能失败。
到 v0.2.2，在完整的 183 目标扫测中，拦截计数仍然由结构性家族主导：
unsafe_sequencing: 226 blockers
unverified_dependencies: 185 blockers
weak_rollback: 86 blockers
feasibility: 34 blockers
这是一个真正的安全地板的样子：模型无法靠嘴皮子绕过的失败模式。
2. 严重性分类移出了模型的掌控
PlannerCritic 最早的经验教训之一是，一个"对抗性"的批评者会乐意以不完整而非不安全为由拦截计划。这成了 v0.1.0 的严重性 bug。
修复方案不是更好的提示工程。它是一个代码强制执行的允许列表：
_BLOCKER_ELIGIBLE_FAMILIES = frozenset({
"unsafe_sequencing",
"weak_rollback",
"unverified_dependencies",
"feasibility",
})
即使 LLM 将一个发现标记为 blocker，如果其家族不符合 blocker-eligible，系统也会将其降级。模型的标签是装饰性的。家族才是承重的。
3. 基准测试基础设施本身也必须变得确定性
v0.2.2 最大的意外是测试框架本身也需要加固：
如果评估器过于松散，架构可能看起来比实际更安全或更弱。
到 v0.2.2 结束时，系统故事是：
inherited corpus stable at the top level
73/73 balanced approved
96/97 strict escalated
8/8 inherited adversarial blocked
boundary rerun restored underclaim_approvals = 0
与此同时，批评者仍然是完全不确定的。
这种组合才是教训。模型不是让系统安全的东西。模型是有用的。代码才是权威的。
如果一个 LLM 在你的关键路径上，问两个独立的问题：
它被允许观察什么？
它被允许决定什么？
PlannerCritic 在问题二的答案变成"不是很多"时，变得更安全了。
批评者可以建议。批评者可以呈现证据。批评者可以有变化。
但确定性层拥有契约。
这就是为什么一个在每次试验中都与自己意见相左的批评者，仍然可以存在于一个安全的系统内部。
我以为令人不安的结果会是批评者太不稳定以至于不可信。
实际的学习更加尖锐：
你不能通过要求一个更稳定的批评者来修复批评者的不稳定性。你通过缩小批评者被允许决定的范围来修复它。
这是一个更有用的设计规则。
第一篇：针对真实 LLM 运行了 157 个 Agent 计划
第四篇：我花了 $0.49 运行了 170 个 Agent 目标
仓库：https://github.com/deghosal-2026/planner-critic-engine
v0.2.2 现场测试报告：https://github.com/deghosal-2026/planner-critic-engine/blob/main/docs/field-test/v0.2.2/field-test-results-0.2.2.md
Issue 追踪：#218, #242, #245, #253, #268