2026-07-26 AI 新闻汇总

nuo534202

237人浏览 · 2026-07-26 20:24:57

nuo534202 · 2026-07-26 20:24:57 发布

1. Kimi K3 智能体自主发现 Redis 零日漏洞：32 个 Agent 在 90 分钟内挖出 19 个漏洞并构建 RCE 利用链

7 月 23 日，安全研究员 Chaofan Shou（X 账号 @Fried_rice，隶属 Bera Buddies）发布实验结果：32 个 Kimi K3 自主智能体在约 90 分钟内发现 Redis 中 19 个零日漏洞，其中一条针对 Redis 8.8.0 的认证 RCE 利用链仅耗时 27 分钟即完成构建。Redis 项目当日紧急发布 7 个安全版本进行修复，覆盖 6.2.23、7.2.15、7.4.10、8.2.8、8.4.5、8.6.5 和 8.8.1 多个分支。

32 个 Agent 的分工流程与传统安全研究高度对应：克隆 Redis 源码并插桩、生成针对性 fuzzer 探测内存处理子系统、用 GDB 自动化调试崩溃、从崩溃点推导完整利用链。整个流程启动后无需人工介入。漏洞分两类：

Redis Streams 共享 NACK 双重释放： 损坏的 RDB 对象使两个消费者指向同一条 pending-entry 记录，移除两个消费者后同一块堆内存被释放两次。利用链通过 RESTORE + EVAL + XGROUP 命令将双重释放转化为任意内存访问，最终调用 system()。影响 Redis 6.2.22、7.4.9 和 8.6.4。
RedisBloom TDigest RDB 加载器堆溢出： 加载器根据序列化压缩值分配内存，却信任攻击者控制的容量字段决定写入量，造成越界写。利用链通过 RESTORE + EVAL 泄漏 Redis 和 libc 地址，篡改数据库哈希函数使特定 GET 调用 system()。影响 Redis 8.8.0。

四条利用链均需认证权限且依赖 RESTORE 命令，未展示未认证利用。需要说明的是，19 个漏洞的数量和自主程度均为 Shou 自行报告，Redis 官方记录确认了漏洞和修复，但未验证漏洞总数或 Agent 独立工作程度。研究者 Lyutoon 同日独立发布了相同根因的 Redis 8.8.0 RCE 利用链，但未指明所用模型。Redis 方面表示该底层漏洞最早于 2025 年 12 月 29 日被提交，数份后续报告被标记为重复。

此事的前置背景是 2026 年 5 月 Redis 已修补过一个由 AI 发现的 RCE 漏洞。Shou 此前在 4 月发表的 AgentFlow 预印本中描述了用于安全测试的多 Agent 工作流设计系统，该系统使用 Kimi K2.5 测试 Google Chrome 时发现 10 个未知漏洞，其中两个沙箱逃逸被分配 CVE 编号。

2. xAI 发布 Grok Build Workflows：单条指令最多调度 1024 个并行 Agent，内置独立质疑者验证

7 月 23 日，xAI 为其编程命令行工具 Grok Build 推出 Workflows 功能。开发者用自然语言描述一个大型任务后，Grok 自动规划工作流脚本——包括工作阶段、每阶段的 Agent 分配及结果汇总方式——将任务分发给数百个并行 Agent 在后台执行，执行期间不占用用户会话。

核心机制如下：

并行规模： 单次运行默认预算 128 个 Agent，大型任务最高可扩展至 1024 个。每个 Agent 以干净、聚焦的上下文启动，避免长上下文带来的注意力稀释。
独立质疑者验证： 工作流可在计划中嵌入检查环节——每个发现需经过独立 skeptic Agent 验证后才能进入最终报告，这一设计针对单轮扫描无法覆盖的误报问题。
断点续跑： 执行进度实时保存，暂停和恢复不会重做已完成的工作。/workflows 命令可实时查看运行状态，包括每个 Agent 的 token 消耗。
可复用模板： Grok 根据用户请求自动编写工作流脚本，运行前做冒烟检查，并在多次运行间迭代优化。成功的工作流保存在 .grok/workflows/（团队共享）或 ~/.grok/workflows/（个人全局），保存后成为可传参的 slash 命令——例如保存 PR 审查工作流后，下次只需输入 /pr-review 5137。

内置的 /deep-research 命令即是一个预置工作流：将研究问题分发给并行调查者，逐条验证每个声明与其来源的一致性，返回带引用的报告。

适用场景明确指向单轮对话无法承载的复杂任务：审查大型 PR 中的每个功能、分流最近 100 个 issue、审计代码库中某类 bug。与 Cursor 的 Agent Swarm（Planner + Worker 树状分解）和 Claude Code 的单 Agent 深度推理不同，Grok Build Workflows 的差异化在于大规模并行 + 内置质疑验证 + 工作流模板化复用。

来源： xAI 官方公告 | 2026-07-23

3. OpenAI 三线齐崩：API、ChatGPT、Codex 同时宕机 111 分钟，连续 17 天无完全正常日

北京时间 7 月 25 日 17 时 17 分，OpenAI 状态页挂出"Investigating"，多项服务错误率升高。受影响面覆盖三条产品线：API 12 个组件、ChatGPT 15 个组件、Codex 4 个组件，合计 31 个服务组件性能下降。18 时 02 分进入"Monitoring"阶段，19 时 08 分宣布全部恢复，总计中断约 1 小时 51 分钟。第三方监测站 Bifrost 记录的事故起点为 UTC 09 时 17 分，与状态页吻合。

单次故障本身并非最严重的问题。第三方监测平台 Bifrost 的记录显示，自 7 月 9 日以来，OpenAI 没有一天处于"完全正常"状态：7 月 12 日和 16 日发生两次 Major Outage，其余日期在 Degraded Performance 和 Partial Outage 之间反复。另一个监测站 incidenthub 的记录同样密集——仅 7 月 23 日一天就挂出四起独立事故，涉及 ChatGPT 错误率和延迟；24 日 Codex Review 报错；25 日轮到三线齐崩。OpenAI 官方尚未公布根因，合理推测方向包括夏季推理负载持续爬坡叠加新模型与新功能发布节奏，基础设施长期压线运行。

Codex 中招值得单独关注。编程 Agent 执行任务动辄运行数十分钟，服务中断发生在任务中间，正在跑的大型项目可能整体烂尾。这与两年前 ChatGPT 宕机仅影响聊天体验的性质完全不同——2026 年的 API 背后是生产系统：客服机器人、代码流水线、自动化审计、Agent 工作流。服务中断 111 分钟，断的是生产线。监测页下方"OpenAI 挂了？自动把请求路由到健康的替代模型"的广告语本身即是市场信号——多模型容灾已做成一门生意。

对行业选型的影响指向两个方向：其一，多云多模型路由将从加分项变成企业 AI 架构标配，单家依赖的风险敞口会被重新定价；其二，每次海外旗舰故障都是国产模型承接溢出需求的窗口，但前提是自身的稳定性先扛住同样的负载曲线。模型能力榜周更易主，可靠性却按天计分——能力差距按百分比算，宕机损失按 $100\%$ 算。

来源： 腾讯新闻 / 象先志 | vibe coding 日报 / 腾讯新闻 | AI 大模型动态 / 腾讯新闻 | 2026-07-25

4. 阿里巴巴开源 open-code-review：确定性工程与 LLM 混合架构，token 消耗仅为通用 Agent 的 $\frac{1}{9}$

7 月 25 日，阿里巴巴开源内部 AI 代码审查工具 open-code-review（Apache-2.0 许可），GitHub 已获 12.7k Star。该工具在阿里集团内部作为官方 AI 代码审查助手运行两年，服务数万名开发者，识别数百万代码缺陷，内部活跃用户超 2 万，采用率超过 $30\%$ ，累计处理超 100 万次任务。

核心设计理念是"确定性工程 $\times$ Agent 混合"——对绝不能出错的审查环节用工程逻辑保证正确性，对需要动态判断的环节交给 LLM：

确定性工程层（硬约束）： 精确的文件选择（确定哪些文件需要审查、哪些应过滤）、智能文件捆绑（将相关文件分组为单一审查单元，如 message_en.properties 与 message_zh.properties 捆绑，每个 bundle 作为独立子 Agent 运行）、细粒度规则匹配（通过模板引擎将审查规则匹配到文件特征，比纯语言驱动的规则引导更稳定）、独立的位置定位和反思模块（系统性提升 AI 反馈的位置准确度和内容准确度）。
Agent 层（动态决策）： 深度优化代码审查场景的提示模板和工具集——工具集从大规模生产数据的工具调用轨迹分析中提炼，包括调用频率分布、每工具重复率和新增工具对整体调用链的影响。

基准测试基于 50 个开源仓库、200 个真实 PR、10 种编程语言、80 余名资深工程师交叉验证、1505 条标注 ground truth。结果显示：与通用 Agent（Claude Code）相比，open-code-review 在相同底层模型下实现更高的 Precision 和 F1，token 消耗仅约 $\frac{1}{9}$ ，审查速度更快。Recall 低于通用 Agent——这是刻意取舍，优先减少误报而非捕获所有可能问题。

工具支持三种模式：ocr review（审查 Git diff）、ocr scan（全文件扫描，支持非 Git 目录）、ocr delegate（委托模式，让 Claude Code、Codex、Cursor 等 AI 编程 Agent 自行执行审查，OCR 仅负责文件选择和规则解析，无需 LLM 配置）。已集成 Claude Code（Plugin + Skill）、Codex、Cursor、OpenCode、VS Code 扩展、GitHub Actions、GitLab CI、Gerrit 等主流平台。内置安全规则集覆盖 NPE、线程安全、XSS、SQL 注入。供应链安全方面，发布产物通过 Sigstore 构建来源证明，标签使用签名格式，附带 ASSURANCE_CASE.md 威胁模型文档。

该工具直接回应了通用 Agent 在代码审查中的三个痛点：大型变更集覆盖不全（Agent 倾向于"偷工减料"只审查部分文件）、位置漂移（报告的问题行号或文件引用偏离实际位置）、质量不稳定（纯语言驱动的 Skills 难以调试，审查质量随提示词微小变化大幅波动）。

来源： GitHub: alibaba/open-code-review | AI/TLDR | 2026-07-25

5. OpenAI 发布 Presence 企业级 Agent 平台：与 Anthropic CMA 正面交锋，Codex 驱动持续改进闭环

7 月 22 日，OpenAI 发布 Presence——面向企业的 AI Agent 部署平台，支持语音和聊天两类实时场景，如客户支持、外呼销售和高风险内部流程。Presence 并非自助产品，而是由 OpenAI Forward Deployed Engineers（FDE）及合资格系统集成商主导部署的限定通用可用产品。

Presence 的核心定位是"让 AI Agent 在生产环境可靠工作"。每个部署从一个具体任务出发（如处理账单问题、支持保险理赔、解决员工 IT 工单），Agent 仅获得完成该任务所需的知识和系统访问权限。企业设定策略：Agent 能做什么、何时需要审批、何时转人工。部署后，生产会话和转人工记录暴露 Agent 的能力缺口，Codex 通过 Presence 插件分析这些信号并提出更新建议，团队可在测试环境中验证后批准受控发布。

Presence 已在 OpenAI 自身的英语电话支持渠道（1-888-GPT-0090）运行，处理开放式请求、验证来电者身份、使用账户上下文并执行审批操作。数周内即达到或超过 OpenAI 用于评估一线人工支持质量的基准，当前 $75\%$ 的呼入问题无需人工即可解决。Codex 驱动的改进循环在 10 天内将人工转接率降低了 15 个百分点。

首批企业客户包括 BBVA（墨西哥银行业语音支持探索）、SoftBank（日语自然语言客户对话测试）和 IAG（高峰事件如恶劣天气时的及时支持探索）。部署前测试覆盖常见请求、边缘案例和高风险场景，模拟和评分器检查 Agent 是否达成正确结果、是否遵循策略、是否正确使用工具、是否在适当时机转人工。Guardrails 可在交互超出企业边界时介入。

Presence 与 7 月 22 日 Anthropic 发布的 Claude Managed Agents（CMA）更新形成直接竞争。两者的路径差异在于：Anthropic 押注 OS 级深度（托管沙盒 + 全栈 Agent 控制 + 思考力度五档调速 + 技能上限 500），OpenAI 押注场景闭环（具体任务出发 + Codex 驱动改进循环 + 语音/聊天双渠道 + FDE 主导部署）。两家都将"Agent 上线后的持续改进"作为核心卖点，区别在于 Anthropic 用 CMA 平台工具链赋能企业自管，OpenAI 用 FDE 团队深度共建。

来源： OpenAI 官方公告 | AI Daily Digest / dev.to | AI/TLDR | 2026-07-22 ~ 07-23