一、引言：一条看不见的能力分水岭

过去一年，前沿大模型的迭代节奏明显加快：上下文窗口从数万 token 扩展到百万级，长输出、复杂推理与代码生成能力同步抬升。对开发者而言，这意味着可以在单次会话中载入整个代码仓库做通读分析，让模型完成跨文件的审计、重构与测试补全。

但真正值得关注的分水岭，不是上下文有多长、输出有多快，而是一个更尖锐的问题：模型能否在没有人类逐步指导的情况下，独立完成一次端到端的攻击任务，自己寻找未知漏洞、自己编写利用代码、自己把各个步骤串成完整攻击链。

一旦这个问题的答案趋近于“是”，模型发布就不再是单纯的产品决策，而是安全决策。近期行业的几起公开事件，恰好完整呈现了这条逻辑链：某前沿模型厂商的新旗舰被自家安全团队定为 Critical 级网络安全能力，先以小范围定向开放；第三方安全机构的模拟攻防测评显示，新一代模型在供应链攻击场景中的完成率达到上一代模型的数倍；随后，原定的迭代版本因安全原因被直接砍掉。这些事件拼在一起，就是当前大模型安全治理的完整图景。本文按“定级—评测—发布管控—企业落地”的顺序逐层拆解。

二、为什么网络安全能力要单独定级

2.1 同一套能力，两种用途

大模型的代码与推理能力天然是双刃的：

• 代码生成能力强：既能为已知漏洞产出修复补丁，也能为未公开缺陷构造可用的利用代码；
• 长上下文：既能通读大型代码库找出潜在逻辑缺陷，也可能被用于分析目标系统、定位薄弱环节；
• Agent 化与工具调用：模型从“问答者”变成“执行者”，能运行命令、访问网络、编排多步任务，自主性大幅提升；
• 跨领域知识融合：操作系统、网络协议、密码学实现的知识在同一权重内交融，使复杂攻击思路的组装成本显著下降。

正因如此，单一维度的“能力跑分”不足以刻画风险，需要针对网络安全场景单独定级。

2.2 定级维度与 Critical 级的含义

参照漏洞管理领域通行的“低危—中危—高危—严重”分级思想，行业对模型网络安全能力的评估通常覆盖以下维度：

1. 自主漏洞发现：能否在无提示逐步引导下，于陌生代码或系统中定位未知缺陷；
2. 利用代码构造：能否将缺陷转化为可验证的利用，而非仅停留在描述层面；
3. 攻击链编排：能否把侦察、突破、维持、横向移动等环节自主串联；
4. 检测规避：能否调整行为以绕过常见防御机制；
5. 人工干预程度：完成任务需要人类提示与纠偏的次数。

当模型在上述维度上都能达到“无需人类专家逐步指导即可完成”的水平，就会被定到最高档，即 Critical 级。这个定级不是营销标签，而是发布决策的直接输入：它决定模型以什么范围、什么约束、什么节奏对外开放。

2.3 与传统软件安全评审的本质差异

传统软件的安全评审建立在“行为确定”之上：同样的输入产生同样的输出，漏洞可以定位、修补、回归验证。模型则不同：

• 输出是概率性的，评测通过不代表换个提示词、换个工具链仍然安全；
• 能力会随系统提示词、外挂工具、微调数据而漂移，“测完即安全”不成立；
• 评测集是有限样本，而真实攻击面近乎无限。

这意味着模型安全不是一次性验收，而是持续治理，这也直接催生了下一节的评测方法与后文的发布机制。

三、安全评测怎么做：以模拟供应链攻击为例

3.1 场景构造：仿真环境而非真实攻击

负责任的评测不会让模型对真实系统发起攻击，而是搭建高仿真沙箱环境。以供应链攻击为例，典型构造包括：

• 模拟的包管理仓库与依赖解析环境；
• 模拟的构建流水线，覆盖依赖拉取、编译、打包、发布各环节；
• 模拟的更新通道与签名校验机制；
• 植入的“可被利用的弱点”，以及完整的流量与行为埋点。

评测者在环境中给模型设定目标任务（例如在模拟环境中完成一次依赖投毒并观察传播效果，或反向地检测并阻断这类投毒），随后全程记录模型行为。

3.2 关键指标设计

衡量结果不能只看“最终成没成”，业界通常综合以下指标：

• 任务完成率：在全部评测轮次中完成任务的比例；
• 轮次成功率：攻击链各环节的逐步成功率，用于定位能力短板；
• 人工干预次数：衡量自主性，次数越少自主性越高；
• 检测逃逸率：能否绕过环境中布置的防御机制；
• 资源与时间成本：完成攻击所需的轮次与计算开销。

3.3 一个值得警惕的结果形态

据公开报道，某国独立 AI 安全机构在模拟供应链攻击场景中对两代前沿模型做了对照测评：上一代模型的任务完成率只有个位数百分比，而新一代模型接近三成，达到前者的数倍。

两种读法都成立：从绝对值看，七成以上的场景仍以失败告终，距离“全自动攻击”尚有距离；但从相对跃迁看，短短一个版本周期内数倍的能力提升，说明自主攻击能力正在逼近实用门槛。这正是“模型越强，发布越像走钢丝”的由来——测评数据的每一次跳变，都在收紧发布的发条。

同时要清醒认识评测的局限：样本覆盖有限、环境仿真度有边界、结论未必能迁移到不同工具链。评测结论是发布决策的重要依据，但不是安全承诺。

四、从一次性放开到分级灰度：发布机制的重构

4.1 阶段化开放路径

对定级较高的模型，常见的开放路径是三级灰度：

1. 定向企业开放：面向签署安全协议、明确使用场景的一小批企业客户，配套更严格的准入审核与使用约束；
2. API 开放：在风控与配额体系就绪后，逐步向开发者开放接口，同时保留用量审查；
3. 消费级产品开放：最后才进入付费订阅的对话类产品，面向最广泛的人群。

公开信息显示，上述新旗舰模型目前就处在第一到第二阶段之间：对部分人可用，大部分人仍在等候名单中。排队不是营销策略，而是灰度控制，每一批扩量都以观测数据为前提。

4.2 版本裁剪：评测结果可以否决发布计划

更具标志性的事件是：有媒体报道，该厂商原定的迭代版本因安全原因被直接砍掉。这在工程上传递了一个明确信号——

安全评测已经成为发布流水线中的门禁（gate），评测不达标，发布计划直接阻断，无论商业节奏多么紧迫。

这要求组织层面给出三重保障：安全团队对发布拥有一票否决权；发布计划为安全评估预留时间窗；被否决的版本允许“回炉”而不是带病上线。

4.3 发布门禁的示意实现

门禁逻辑可以抽象成一段示意代码：

# 模型发布门禁（示意）
CRITICAL_THRESHOLD = 0.15  # 自主攻击完成率告警阈值，由安全委员会设定
def release_gate(model_version: str) -> str:
    cyber = run_cyber_benchmark(model_version)   # 网络安全能力评测
    safety = run_safety_suite(model_version)     # 通用安全评测
    if cyber.autonomous_attack_rate >= CRITICAL_THRESHOLD:
        # 命中高风险：限制开放范围，转人工复核
        return "RESTRICTED: 定向开放 + 安全委员会复核"
    if not safety.all_cases_passed:
        return "BLOCKED: 存在未通过用例，发布阻断"
    return "ALLOWED: 进入灰度池，分批扩量"

注意这里的输出不是“过/不过”的二元结果，而是“限制/阻断/放行”三态，与灰度策略直接衔接。

五、企业侧的安全实践：怎么安全地用高能力模型

对多数企业来说，问题不是“要不要发布模型”，而是“如何安全地接入这些越来越强的模型”。以下四条实践按优先级排列。

5.1 场景分层：防御性用途优先

优先在高价值、低风险的防御性场景落地：

• 代码审计与漏洞分诊：让模型通读代码库、标记可疑模式、为已知漏洞生成修复建议；
• 依赖风险分析：结合依赖清单做已知漏洞比对与升级建议；
• 防御侧自动化：日志研判、告警降噪、应急响应预案生成。

对需要联网执行、可触碰生产环境的自动化任务，保持默认关闭，逐项评审后再开放。

5.2 权限最小化与沙箱隔离

不要让模型直接持有生产凭证，推荐在模型与真实系统之间加一层代理：

# 模型代理层访问策略（示意）
access_policy:
  allowed_tools:            # 工具白名单
    - code_search
    - static_analysis
    - dependency_scan
  denied_tools:
    - shell_exec            # 默认禁止任意命令执行
    - network_request       # 默认禁止外联
  sandbox:
    network: isolated       # 网络隔离
    filesystem: read_only   # 文件系统只读
  credentials:
    scope: least_privilege  # 最小权限凭证
    rotation: 24h

高危操作（写文件、执行命令、访问外部网络）必须走人工审批通道：

# 高危工具调用的人工审批包装（示意）
def guarded_tool_call(tool: str, args: dict, risk: str):
    if risk == "high":
        if not request_human_approval(tool, args):
            audit_log("denied", tool, args)
            raise PermissionError("高危操作被拦截，等待人工审批")
    audit_log("executed", tool, args)
    return sandbox_exec(tool, args)

5.3 审计、监控与告警

全链路留痕是底线：提示词、工具调用参数、模型输出、审批记录都应落库。在此基础上做异常检测，例如短时间内高频调用高危工具、反复尝试越权、输出中出现攻击性代码片段等。以百度智能云为例，其大模型服务可以与日志服务、监控告警、密钥管理等通用组件配合使用，企业接入时建议默认开启全链路审计，并为安全团队开通独立的告警通道。

5.4 自身供应链加固

供应链攻击评测提醒我们：攻击者的目标往往是依赖与构建环节。企业应同步加固自身链条，依赖锁定与哈希校验、制品签名、构建流水线最小权限、构建来源证明。别忘了，模型本身也是供应链的一环：模型文件、工具插件、系统提示词都应纳入版本管理与完整性校验。

六、把安全评测纳入持续流水线

模型能力会随系统提示词、外挂工具、微调数据而漂移，因此评测必须常态化：

• 变更触发评测：模型版本、系统提示词、工具配置任一变更，自动触发安全回归评测，思路与 CI 一致；
• 红队常态化：内部红队按周期更新攻击剧本，覆盖新出现的攻击模式；
• 第三方评测互补：独立机构的外部视角能暴露内部盲区，前文提到的对照测评就是典型范例；
• 评测资产沉淀：把每次评测的场景、用例、结果纳入资产库，形成可复用的回归集。

结语

模型越强，发布越像走钢丝，钢丝的一端是能力上限，另一端是治理下限。对模型厂商而言，能力定级、对抗评测、分级灰度、版本裁剪正在构成一套新的发布纪律；对企业而言，正确的姿势是“假设模型可能出错、也可能被滥用”，用沙箱隔离、权限最小化、全链路审计和供应链加固把风险兜在工程手里。能力与治理的赛跑已经开跑，治理不能永远慢半拍。