BotOf Tech — 技术与植物养护笔记

前沿 AI 安全最近的争论越来越尖锐：实验室为什么一边警告风险，一边继续发布更强模型？

这个问题很容易变成道德指控：到底是真担心，还是用安全话术制造监管壁垒。我的看法更工程化一点：真正要问的不是它们有没有警告，而是发布系统能不能被验证。

如果系统不可验证，警告只是公关材料；如果系统可验证，警告才可能变成治理机制。

Fable 5 把矛盾推到台前

这个矛盾在 Fable 5 上集中爆发：Anthropic 此前长期强调 Mythos-class 能力的发布风险，随后又推出了带 safeguards 的 Fable 5。

Anthropic 的解释是，Fable 5 有分类器、fallback 和限制，高风险请求会转到更保守的模型。支持者会说这是负责任的折中；批评者会说这证明商业压力最终会压过安全谨慎。

两边都有道理，但都不够具体。真正需要验证的是：

没有这些，用户只能相信实验室的自我描述。

前沿模型发布应该像生产系统上线，而不是像产品营销发布。

这条链路里，最关键的是可观测性。强模型不是发布后就结束，而是发布后才开始面对真实对抗和真实误用。

arXiv 上关于内部 AI 模型使用风险报告的论文提到，前沿公司通常会先把最强模型内部使用数周或数月，再考虑公开发布。这个阶段很关键，因为模型可能已经在自动化研发、安全评测、代码生成、数据分析里发挥巨大作用，但外界几乎看不到。

这带来两个风险：

所以，治理不该只盯着公开 API，还要覆盖内部 deployment。

围绕前沿模型发布的争论通常会分成三派：

我更接近第三派。单纯暂停很难长期成立，因为能力扩散不只来自一个模型；单纯加速也不够负责，因为前沿模型确实可能改变攻击、防御和自动化研发的边界。

即使你不是模型实验室，也不能把安全治理全部外包给上游。

应用层至少要做这些事：

上游模型的安全策略解决不了你的业务权限问题。一个被允许写数据库、发邮件、部署代码的 Agent，即使用的是“安全模型”，也可能因为产品权限设计差而造成事故。

“边警告边发布”不是前沿 AI 独有的伪善，也不是可以被一句“市场竞争”轻松解释的问题。它本质上是一个发布系统问题。

强模型可以发布，但发布系统必须越来越像高风险基础设施上线：有门禁、有分层、有审计、有事故报告、有外部验证、有降级路径。

未来用户和企业不应该只问“这个模型多强”，还应该问：

AI 安全讨论如果停留在口号上，会继续撕裂。落到发布系统、日志、权限和审计上，才有机会变成工程事实。