给智能体立闸门，规则却可能是坏的
接了工具的智能体，最稳妥的做法是在工具调用边界上立一道闸门：把书面策略编译成机器可校验的规则，交给确定性引擎执行，关键路径上不放大模型。这个思路人人都懂，可 arXiv 2610.11030 这篇 NOMOS 偏要追问一句——如果规则是 LLM 写出来的，而执行引擎没有判断能力，那这些规则到底有多少是坏的？
研究团队来自 Corners 公司，提交于 10 月 8 日。他们做的静态校验不依赖求解器、不依赖证明器、也不调大模型，只拿着候选规则、工具 schema 和两张谓词词汇表，就把原始规则修掉或否决掉。结果有点扎心：航空域里三成七的原始候选规则不可执行，零售域也有一成三；再加上约百分之四和百分之二被当成不稳定抽取直接丢弃。算下来，航空域 79 条里只有 10 条、零售域 53 条里只有 5 条能活到被强制执行。
问题不在幻觉，而在结构
典型的坑往往长这样：「任何操作前先认证用户」被写成一条规则后，反而把所有工具都堵了——包括那两个负责认证本身的查询工具，于是对话永远走不出死锁。又如把确认要求绑到八个只读工具上，查个航班状态都要用户批准；还有规则引用了目标工具根本不接受的参数，或者指向域里并不存在的启用工具。NOMOS 的 Resolve 阶段用五类结构检查——可达性、参数签名一致、域可满足、状态矛盾、写入范围——把这些坑挑出来。
更关键的是第二层行为预检：把编译后的规则在真实代理的历史轨迹上重放，找出那些结构正确、却拒绝合法工作的规则。某个绑定在开发域拒绝了九成五以上的调用。在 τ²-bench 上，状态变更调用的违规率从航空域的六成六降到百分之三、零售域的三成一降到百分之七。作者特意强调：提取器规模再大也替代不了校验——一个前沿级提取器照样写出了六类缺陷里的两类。
给做平台的人提个醒
凡是让模型写出、再由确定性系统执行的产物，校验都不能被提取器的体量取代。今天大家忙着接更多工具、堆更长上下文，却很少回头审一眼「规则本身对不对」。NOMOS 的价值不是某个百分比，而是把智能体治理里最容易被忽略的一环，从「信任模型生成」拉回「先验证再执行」。