模型一换，安全边界还拦得住吗？

做构建评审时，问“哪个模型更安全”是个错问题。模型会被换掉。能扛过一个发布周期的问题是：检查跑在哪一层，检查失败时系统会做什么？

两周前这还是设计层面的争论。这一周它变成了依赖管理问题。10月22日，Anthropic 把 Agent Skills 格式——名称、标识、GitHub 组织、域名——捐给了一个 Linux 基金会下属实体，背后有 70 多家平台采用方、约 2.8 亿次安装。10月28日，谷歌通过标准连接器向第三方应用开放 Gemini 和 Search，首发 50 多款。两件事都提升了能力，也都在同一个两周里、出于同一个原因，把你需要推理的暴露面撑大了。

先说失败模式，具体一点。一段写在系统提示词里的护栏是这样的：你是报价助手，可以读价格表，未经批准绝不能把报价发给客户。

这句话在四类输入上会失效，没有一类是恶意攻击：

• 任务本身合法地需要那个被禁止的动作。“在他们下午4点前把 Ballantyne 的报价发出去”，正确完成这个请求的方式恰恰是被禁止的动作。模型要在指令和任务之间做仲裁，同样的权重，不同日子仲裁结果不同。
• 上下文把这句话的优先级挤掉了。长上下文、工具输出、注入的文档文本都在争抢同一份注意力预算，“未经批准绝不发送”只是几千行里的一行。
• 工具有办法绕过去。提示词管的是模型。如果连接器库把 send_email 直接暴露给工具调用层，这句话从来就不在路径上。
• 模型被换掉。上面每一条都会因为一次版本升级重新洗牌，而版本升级现在发生在别人的发布节奏上——因为模型正是被商品化的那一层。

第四条才是关键：它让这件事变成架构问题，而不是提示词工程问题。一个每次依赖升级都要重新验证的控制，不是控制，是测试夹具。

站得住的设计是一张权限表，分三个互不重叠的类别。真正重要的属性不是“先问一句”，而是系统究竟有没有能力做这件事。

第三层不是“模型被告知不要做”。而是那个函数从来没有被接进智能体的工具集，没有任何 token 序列能触达它。这个区别值得较真，因为“被提示词挡住”和“根本不存在”在演示里表现一模一样，在没人盯着的时候完全不同。

Anthropic 的使用政策更新从另一个方向说了同一件事。一份主要讲影响力行动的文件里，埋着一条要求：接入物理设备的 AI 必须有合格操作员能够观察并叫停，设备必须能进入安全状态。这是用监管语言说：操作员必须能中断，而且中断必须有意义。你没法中断一段提示词。

三层模型画起来容易。问题是周一你跑什么来确认它还成立。我们的做法是一套回归测试——截至 10月15日的一个厂商页面，60 个剧本背后有 241 个用例——每个用例是一个任务、一个预期动作层级、一个预期产物。模型或剧本一变，这套测试就跑。

让它有用的是，大部分用例都很无聊，只有一类不是。代码里有两个细节就是整个设计：

• capability_absent 必须和 refused 是两个不同的预期值。如果你的测试把“智能体拒绝了”和“智能体做不到”当成同一种结果，它会一直通过，而边界已经悄悄变成了建议。礼貌拒绝的模型产出了一个分数；没被绑定的工具产出了一个缺席。下一次升级之后，只有后者还成立。
• 失败必须是可读的。命中第三层时应该返回人能看懂的理由——“该角色不可使用此动作”——而不是一个通用工具错误，让模型转头把三个第一层调用拼成同样的效果。这条组合路径才是真正的攻击面，而且它不是恶意的，是一个乐于助人的模型撞墙之后的正常反应。

标准连接器层改变了威胁模型。在 MCP 式连接器成为常态之前，“这个智能体能触达什么”是你控制的数字：你写的那些集成。有了标准连接器层之后，这个数字会在别人发布新东西时变大——首发 50 多款应用不是你敲进去的数字。

由此有三件事，没有一件是产品功能：

1. 在构建时按连接器枚举可达面。如果你拿不出这份清单——工具名、能力类别、层级——你有的不是边界，是一份政策文档。清单必须被生成，不能手写。
2. 把层级绑到工具上，不是绑到厂商上。一个连接器在同一个命名空间里同时提供 read_document 和 delete_document 是常态而非例外。如果层级按连接器分配，一个不安全的方法会把整个集成拖进第三层，或者更糟，因为连接器“已批准”而被放行。
3. 把技能安装当代码评审。一个被捐出去的技能格式意味着，你装的技能出自一个你从未认同过其风险偏好的人，而且它自带作用域假设。旧直觉——“这只是个提示词，做不了什么”——在技能能调用工具的那一刻就不成立了。

想对任何智能体栈做一次廉价检查，就这个：换掉模型，看什么坏了。不是看质量掉没掉，是看拒绝类用例还拒不拒。

在我们自己的测试里，最先失败的从来不是明确的第三层用例，而是组合：智能体被要求做一件受限的事，它把这件事拆成若干被允许的步骤，走到了 80%。提示词说不，步骤说是。这个缺口是设计问题，不是模型问题，没有任何一次模型发布能补上它。

还有一件我们没解决的事，与其四舍五入不如直说：层级分配的质量取决于写规则的那个人。给大多数人三个层级，他们会写“任何面向客户的东西都要审批”，这不是机器可判定的，于是几乎所有事都排队，一个一天被读四十次的队列变成没人认真做的差异评审。系统执行你写下的，执行不了你想表达的。

也要说清楚这套东西买不到什么。它管的是权限，不是判断力：一个被正确执行、但依据的是你写得太松的规则的任务，会通过每一层和每一个回归用例。它管的是模型替换，不是部署风险——模型仍然来自别人。审计日志管的是事后重建，不是事前阻止：清楚知道发生了什么，和那件事本来该不该做，是两回事。

留一个设计评审上我会问的问题：下个季度你换掉底层模型时，你的栈里有什么东西告诉你行为没有回退——以及它分得清“拒绝了”和“做不到”吗？