Anthropic 把外部评估者请进公司：AI 安全审查开始从“测模型”转向“查系统”# Anthropic 把外部评估

Anthropic 把外部评估者请进公司：AI 安全审查开始从“测模型”转向“查系统”

AI 安全评估走进实验室

10 月 15 日，Anthropic 宣布，已向非营利评估机构 METR 的 6 名成员开放接近公司风险评估团队的内部访问权限。对方获得公司设备、办公空间，以及部分内部工具和系统的访问能力。更重要的是，METR 可以独立发布对风险等级、事件和实践的分析，Anthropic 不能否决发布，只能依据事先划定的窄范围要求删去敏感信息。

这不是又一次常规的模型红队测试。真正的新变化是：外部评估者不再只拿到一个 API、一个候选模型或一组预设任务，而是被允许观察模型背后的组织流程、风险决策与内部证据。换句话说，审查对象从“模型在测试题上做了什么”，扩展到“公司如何知道风险、如何处置风险，以及哪些信息没有公开”。

对开发者和产品团队而言，这件事看似偏治理，实则会影响模型选型、供应商尽调、上线门槛和事故响应。它也提出了一个更现实的问题：当 AI 系统越来越依赖代理、工具调用和持续更新，仅靠发布前跑一次基准测试，还够不够？

这次开放了什么，又没有开放什么

根据 Anthropic 当天的公告，6 名 METR 成员获得的权限大致与 Anthropic 自己的风险评估团队相当。公司鼓励员工像对待从事对齐风险工作的同事一样，与这支团队共享信息。

但“准员工级访问”并不等于无限制访问。客户数据、受律师—客户保密特权保护的信息、模型架构等，仍属于明确排除或可删节的类别。参与项目的 METR 小团队还需要遵守可执行的协议，并与 METR 内部其他人员隔离。这些边界很重要：它说明该安排不是把实验室完整公开，而是在保密、安全和独立性之间搭建一条受控通道。

嵌入式独立评估架构图

发布权同样是判断独立性的关键。Anthropic 表示，METR 可以公开分析其风险水平、事件和实践，公司不能直接否决；若内容落入预定义的敏感类别，可以要求删节。METR 仍可公开说明发生过删节，并评价删节是否合理，只是不能泄露被删掉的信息。

TechCrunch 的独立报道核对了上述安排，并将其放在近期 AI 代理风险事件增多的背景下。不过需要区分：访问机制与发布权来自双方公开安排；它能否真正发现重大问题、能否在商业压力下保持独立，目前还没有结果可以证明。

为什么只做“黑盒测评”越来越不够

传统模型评估通常有三个假设：待测模型版本相对稳定；测试者可以用有限样本代表真实使用；风险主要体现在模型输出本身。进入代理系统后，这三个假设都在变弱。

第一，线上系统不是单一模型。真实产品还包括系统提示词、检索层、记忆、权限、工具、监控器、人工审批和回滚机制。相同基础模型接入不同权限后，风险完全不同。只测 API 输出，可能看不到系统在何种条件下允许代理读写文件、发送消息或执行代码。

第二，能力会被脚手架放大。一个在短任务中表现普通的模型，借助规划、重试、长上下文和外部工具，可能完成更长、更隐蔽的行动链。评估者若不知道内部监控覆盖了哪些步骤，也就很难判断“没有发现问题”究竟代表系统安全，还是观测不足。

第三，风险证据往往散落在组织内部。事故记录、近失事件、上线争议、被放弃的安全方案、评估失败样本以及管理层如何权衡发布时间，通常不会出现在模型卡中。它们却可能比一次公开榜单更能说明供应商的真实风险姿态。

Anthropic 在公告中把这种安排类比为大型银行的驻场检查：被监管者掌握的信息天然多于外部观察者，因此监督需要更接近风险生成的位置。这个类比有解释力，但不能过度延伸。METR 不是政府监管机构，参与是企业自愿的，也没有法定调查权、处罚权或统一行业标准。它更接近一次制度实验，而不是成熟监管的替代品。

三层评估机制，核心不是权限多少，而是谁控制结论

Anthropic 同时披露了计划中的三层外部评估结构：

层级	访问范围	发布权限	当前示例
第一层	针对特定风险的有限访问	发布需 Anthropic 同意	SecureBio
第二层	更多内部信息	无需批准，但敏感内容可要求移除	尚在推进
第三层	接近内部风险团队的持续访问	无需批准；可评价删节是否合理	METR

这套结构里最值得关注的并非“拿到多少内部文档”，而是四项制度设计：评估范围由谁确定，访问能否持续，负面结论能否独立发布，删节过程是否留下可见痕迹。若范围完全由被评估者指定，外部机构可能只是在验证企业已经知道的问题；若报告必须经过企业批准，独立评估也容易退化为合规背书。

METR 并非第一次接触 Anthropic 的内部安全工作。Anthropic 称，双方过去一年已围绕多份风险报告合作；METR 的网站也列出了此前对自动化研发风险、破坏风险及内部代理监控系统的外部审查。这些历史合作提供了经验基础，也带来利益独立性问题：长期合作越深入，评估者越懂系统，同时也越可能在资金、访问和关系上依赖被评估企业。

因此，“独立”不能只靠机构名称保证。未来报告至少应披露资金关系、评估周期、被拒绝的访问请求、方法限制、删节数量与类别，以及哪些结论基于企业提供的信息、哪些来自评估者自己的复现。

对开发者和企业采购，影响比监管讨论更直接

对于使用第三方大模型的团队，这件事给出了一套可以立即落地的供应商尽调问题。

第一，不要只问模型分数，要问评估者看到了什么。 同样写着“通过外部评估”，可能只是调用公开接口，也可能包含事故记录、训练后评估、监控策略和上线决策。两者证据强度不同。

第二，把发布独立性写进采购要求。 供应商是否能阻止报告发布，是否能无限扩大“商业机密”范围，评估者能否说明删节争议，决定了报告更像审计材料还是市场材料。

第三，将模型风险与部署风险分开。 基础模型的危险能力、产品的工具权限、企业自己的数据边界和人工审批，属于不同责任层。外部评估再深入，也不能替代调用方的最小权限、操作日志、沙箱、速率限制和紧急停用机制。

第四，为持续评估预留工程接口。 代理系统会更新模型、提示词、工具和策略。企业应记录版本、关键决策链与高风险工具调用，使内部或外部团队能够复盘，而不是事故发生后才发现没有证据。

第五，不把“受过评估”误写成“已被证明安全”。 评估只能在已知方法、已获权限和特定时间点内降低不确定性。模型能力增长、对抗者变化和部署环境差异，都会让结论过期。

仍需警惕的四个限制

其一，评估结果尚未发布。目前能够确认的是访问与治理安排，而不是 Anthropic 的风险水平已经得到外部认可。把公告直接解读为“通过审计”，属于超出证据。

其二，信息入口仍由企业控制。即便权限接近员工，账户范围、日志完整性、访谈对象和可见历史仍可能影响结论。真正有价值的报告应明确说明访问缺口，而不是只列已完成的测试。

其三，自愿机制存在选择偏差。愿意开放的公司可能得到信誉奖励，不愿开放的公司也未必承担同等成本。如果行业没有可比较的最低标准，三层机制很难横向比较。

其四，保密与透明存在真实冲突。公开模型架构、客户信息或可被攻击者利用的防护细节并不合理；但“安全”与“商业敏感”也可能成为隐藏坏消息的方便理由。允许评估者公开评价删节是否合理，是一个有用的制衡，但效果要等报告实践检验。

我的判断：这是治理基础设施的一次升级，但不是安全认证

Anthropic 此次安排的价值，不在于证明某个模型更安全，而在于承认一个事实：前沿 AI 风险已经无法只靠模型发布页、公开基准和企业自述来解释。外部评估若要跟上代理系统，就必须进入权限、监控、事故和决策流程。

这一步值得肯定，尤其是赋予 METR 相对独立的发布权，并允许其评价删节。但判断成败的标准应该非常具体：METR 最终是否能披露有信息量的负面发现；是否能说明访问被限制的地方；Anthropic 是否会根据结论改变产品、流程或发布时间；其他实验室是否采用可比较的机制。

对开发团队来说，最可执行的结论是：从现在开始，把“外部评估的访问深度与发布权”加入模型采购清单，同时把自己的代理权限、日志和回滚机制建设好。供应商的透明度可以降低不确定性，却不能替你承担部署责任。

AI 安全审查正在从一次性的“考试”变成持续的“驻场检查”。这可能是更接近现实系统的方向，也更考验评估机构是否真的独立。现在看到的是制度入口，真正的证据，要等第一批公开报告出现。

参考资料

本文仅代表作者观点，仅供参考