AI 在安全研究和智能体编程上的进展，正在从单项能力展示走向更长的任务流程。本期围绕三项发布梳理技术信息，也为写好标智库的技术讨论保留一个关键视角：区分模型能生成什么、评测验证了什么，以及最终能部署什么。
OpenAI：自动发现、验证与修补 Linux 内核漏洞
OpenAI 表示，其安全研究团队构建了一条覆盖漏洞发现、利用验证和补丁生成的自动化流水线。借助一款尚未发布的网络安全模型，该系统在一次运行中验证了 948 个 Linux 内核本地提权漏洞，并为其生成补丁，按 API 计价计算的成本约为 120 万美元。
团队还表示，智能体发现并使用了至少 10 种 Linux 漏洞利用技术，其团队及咨询专家认为这些技术具有新颖性。目前，OpenAI 正与 Linux 维护者及 Patch the Planet 合作伙伴推进漏洞报告和补丁处理。
这里最重要的边界是：生成补丁，不等于补丁已获维护者接受并合入内核，更不等于已完成部署。 948 这一数字属于 OpenAI 披露的实验结果，不应直接视为已经修复上线的漏洞数量。
Kimi K3.1 Pro：开放权重，面向长周期任务
Moonshot 发布了 Kimi K3.1 Pro 的模型权重。该模型被描述为 K3 的后训练升级版，针对编程、金融研究和长周期智能体任务扩大了强化学习训练。
主要信息如下：
| 项目 | 发布信息 |
|---|---|
| 输入类型 | 文本、图像 |
| 上下文窗口 | 100 万 |
| 总参数量 | 约 2.8 万亿 |
| 激活参数量 | 约 1040 亿 |
| 推理框架 | vLLM、SGLang 提供发布首日支持 |
评测方面，Agent Arena 公布的结果显示，Kimi K3.1 Pro 在开放模型中排名第一、总榜排名第十三，评测覆盖超过 1.75 万次智能体会话。这一成绩应放在该评测的任务与运行条件下理解，不能直接外推到所有业务场景。
对部署团队而言，开放权重不等于部署门槛低。选型时仍需同时考虑总参数规模、激活参数量、目标上下文长度，以及实际任务中的 token 消耗，而不能只看榜单名次。
Ripple-65B Preview：从零预训练的稠密模型
Ricursive 发布了 Ripple-65B Preview，这是一款从零开始预训练的 650 亿参数稠密模型。
| 项目 | 披露内容 |
|---|---|
| 训练 token 数量 | 12 万亿 |
| 上下文窗口 | 100 万 |
| 许可证 | Apache 2.0 |
| Terminal-Bench 2.1 成绩 | 80.5%，为厂商报告结果 |
| 研发预算 | 3200 万美元，厂商称包含规模探索、数据工作及最终训练等完整研发投入 |
| 架构设计 | 使用 value residuals 和滑动窗口注意力 |
Ricursive 将其定位为美国开放权重模型中智能体编程能力领先的模型。这里的比较范围需要保留：“美国开放权重模型领先”不等于“全球开放权重模型领先”。相关讨论也指出，其公布的比较未覆盖部分中国模型，包括 Qwen。
同样，稠密模型与混合专家模型之间不能只比较总参数量。实际激活参数、推理开销和评测配置，都会影响对性能与成本的判断。
技术选型前，先厘清三条边界
1. 开放权重与受控共享不是一回事
并非同期发布的模型都能下载权重。例如，Cognition SWE-2 Flash 尚未公开权重，仅计划向合作伙伴和研究者提供受控共享，不应与上述开放权重发布混为一谈。
2. 厂商成绩不等于独立复现
模型排名、研发预算和运行成本，需要结合披露主体、测试范围及运行配置理解。尤其是厂商报告的基准成绩，应与独立评测或后续复现结果明确区分。
3. 长上下文与高排名不等于生产可用
百万级上下文窗口说明了模型支持的输入规模，却不能单独证明它能稳定完成特定业务任务。真正选型时，仍应回到自身工作负载，测试任务成功率、延迟、token 消耗和部署成本。
这三项进展值得关注，但判断其工程价值时，最有用的仍是同一套标准：核对声明边界，再用自己的任务验证。
