严重级安全能力如何重塑大模型发布节奏

2025年9月初，一款前沿大模型正式对外发布。与以往围绕参数规模、评测分数和演示效果展开的讨论不同，这次舆论焦点很快转向两个问题：它拥有什么样的破坏性能力，以及开发方是否已经准备好安全地控制这种能力。

从已披露信息看，该模型的上下文窗口达到105万个token，单次输出上限为12.8万个token。定价为每百万输入token 10美元、每百万输出token 50美元。首批开放仅面向一小批企业客户，后续才计划逐步进入API和付费订阅渠道。这显然不是一次“无门槛发布”，而更像一次经过设计的受限上线。

能力定级：从参数竞赛到安全边界

对于普通用户，105万token上下文意味着可以一次性放入数十万字资料，让模型在超长代码仓库、合同合规审查、研究报告等场景中完成跨段落推理。12.8万token输出则支持一次性生成大型代码文件、完整技术方案或长篇幅报告。这些参数本身已经足够有吸引力，但开发方给出的“Critical级网络安全能力”定级，才真正改变了对该模型的评估框架。

在通用漏洞评级体系中，Critical通常代表最高严重等级。放在模型能力上，它表示模型已经能够自主发现未知漏洞，并自行编写利用代码，不需要人类专家像使用普通辅助工具那样一步一步指导。换句话说，模型不再只是“帮人写代码”的辅助工具，而是可以在特定目标上完成从侦察、分析到利用的完整攻击链。

需要强调的是，这个定级描述的是模型的能力，而非模型自身的漏洞。对防御方来说，这种能力可以用于自动化渗透测试、代码审计和应急响应；对攻击者而言，它则大幅降低了编写漏洞利用代码所需的知识门槛。自然语言指令可以直接转化为可执行攻击路径，过去需要数月经验积累的技能，现在可能被模型快速复现。

分批开放：控制风险的工程化手段

该模型没有第一时间面向所有用户，而是先进入一小批企业客户的沙箱环境，其他人只能排队等待。这种发布方式实际上是高能力模型落地过程中的工程化控制手段。

一方面，小范围真实流量可以帮助开发方观察模型在实际任务中的行为，例如是否出现越狱、注入、过度调用工具等情况；另一方面，企业客户可以在可控网络环境中测试模型与自身业务系统集成时的安全边界。对模型提供方来说，逐批放量相当于增加了一道安全观测窗口，若发现异常模式，可以在全量开放前调整护栏策略。

从定价结构看，输入token 10美元/百万、输出token 50美元/百万的差异也符合大模型推理成本分布的基本逻辑：输出token需要逐字自回归生成，对算力、显存和延迟的要求显著高于输入处理；百万级上下文还意味着预填充阶段要处理大量历史状态，基础设施成本和调度复杂度都更高。这一价格信号说明，模型定价更多是围绕实际消耗的算力资源展开，而非单纯按参数规模标价。

供应链攻击测试：能力跃升的直接证据

发布后近一个月，独立安全评测机构公布了一项对照测试结果。测试模拟供应链攻击场景，要求模型在限定轮次内与目标环境交互，完成从初始侦察到最终利用的完整攻击。结果显示，该模型在29.2%的轮次中成功完成攻击，而上一代模型的完成率仅为6.3%。两者相差约4.6倍。

供应链攻击之所以被选作评测场景，是因为它比单纯“找出一个已公开漏洞”更接近真实黑客行为：攻击者需要判断哪个组件值得投毒、如何构造不引起审查的恶意包、如何在构建过程中维持访问权限，以及如何规避基础安全检测。模型要在这些环节中自主做出决策，通常还需要调用扫描工具、读代码、修改文件、执行命令。

“轮次”这一指标尤其关键。它衡量的是模型与环境之间的多步交互：每次收到环境和工具返回结果后，模型都需要决定下一步动作。轮次越短，攻击越高效；成功率越高，人类介入需求越低。从6.3%到29.2%的提升，说明该模型已经能在相当一部分供应链攻击场景中形成完整的“规划—行动—反馈”闭环，而不再只是输出零散代码片段。

当然，模拟环境不等于真实互联网。真实环境中的防御机制（网络隔离、流量监控、账号权限、入侵检测等）会显著提高利用成本。但作为能力评估，这一对照已经足够说明问题：模型的安全影响正在呈非线性增长。

版本叫停：安全成为路线的“否决项”

几乎同一时间，有媒体报道称，开发方取消了原定发布的下一增强版本，理由直接指向安全。这个消息在开发者社区中引起的震动，甚至超过了模型本身发布时的讨论度。

从产品迭代角度看，叫停一个增强版本需要付出很高的机会成本：研发投入已经发生，商业化计划被迫调整，客户预期需要重新管理。但从安全角度看，这可能是一个理性决策。基础版本已经具备29.2%的供应链攻击成功率，那么增强版本如果继续提升自主性、上下文利用效率或工具调用准确率，可能让原本需要专业红队和复杂工程能力才能完成的攻击，变得像运行一个脚本一样简单。

安全因素开始真正成为大模型路线图的“否决项”，意味着模型能力增长不再只受算力、数据和算法限制，还受到社会承受能力和风险控制能力的约束。这种约束并不总是体现在模型结构上，更多体现在发布策略、使用边界、评测机制和法律责任划分上。

企业如何接入高能力模型

对于正在等待API放量的企业，与其抢“第一波试用”，不如提前设计一套接入安全基线。以下五个实践值得考虑。

第一，场景隔离。高能力模型不应直接挂载到生产环境或拥有高权限的内部网络。建议将其放入独立的私有网络或沙箱中，通过服务账号和最小权限原则控制它所能触达的资源，避免模型被提示注入后变成攻击跳板。

第二，输入输出双向过滤。输入侧需要防止敏感数据进入模型上下文，输出侧需要扫描模型生成的代码和文本，识别恶意URL、异常shell命令、违规密钥、后门模式等风险内容。过滤规则要结合业务场景持续更新，而不能只依赖静态关键词。

第三，操作审计与全链路日志。记录每一次请求、每一次工具调用、每一次外部请求，是事后溯源和改进安全策略的基础。配合日志服务和监控告警，可以在模型出现异常行为时及时阻断并定位原因。

第四，红队评估前置。企业应在正式上线前，针对自身业务系统让高能力模型执行模拟攻击，覆盖供应链投毒、凭据窃取、社会工程学等典型风险场景。评估应设定明确的“成功/失败”判定标准，并把结果纳入上线评审。

第五，灰度放量。与模型提供方的分批开放逻辑类似，企业内部也应先让少量安全团队和核心开发人员试用，再逐步扩展到普通员工。每个阶段都要有可退出的回滚方案，一旦发现安全问题，立即将模型切换为受限模式。

需要注意的是，这些实践并不依赖某一家特定厂商。使用云上通用的模型网关、容器平台、日志服务、监控告警等基础能力，同样可以构建起一条相对完整的安全链路。真正重要的不是“能不能调用到最新模型”，而是“调用之后是否有能力控制它”。

结论：越强，越需要谨慎

一个具有Critical级网络安全能力的模型，正在以“少量企业试点+排队等待”的方式走向市场。它的上下文长度和输出长度刷新了人们对大模型工作边界的预期，但更值得深思的是：发布本身已经成为一种安全机制。

模型越强，发布就越像在走钢丝。一方面，只有通过实际部署才能获得真实反馈，推动模型在安全可控的方向上成熟；另一方面，任何一次过早或过广的放量，都有可能让尚未被充分理解的风险提前暴露。未来的前沿模型发布，或许不再以“能否做到”为唯一标准，而是以“在什么条件下允许使用”为核心命题。对于开发者和企业决策者，理解这种节奏变化，比单纯追踪版本号更有价值。