2026年10月25日 周日
今天筛出 7 条值得一读的 AI 工程动态，点开卡片查看细节与落地建议。
今日看点
Top 3- 01Oracle 带外安全告警 · CVSS 9.1Oracle 紧急发布 Java 安全告警 CVE-2026-114820（CVSS 9.1）：从 cacerts 里移除 eMudhra 根证书eMudhra 八张中间 CA 私钥泄露后，Oracle 10/24 带外发布 JDK 8/11/17/21/25/27 全线更新，JSSE 远程无需认证即可利用。
- 02GitHub issue #48215（容易漏）LiteLLM 承认旧签名私钥已泄露：被投毒的 v1.107.0 镜像能通过 cosign 校验LiteLLM 更换镜像签名密钥并在 issue 里确认旧私钥在 10/21 攻击中被窃取，v1.107.0 的恶意镜像带着合法签名。
- 0310/24 多家媒体跟进报道Claude Code CLI 支持 MCP Tasks 和 Elicitation：长任务交给服务端，执行中途可以向人要确认MCP 工具调用可以返回任务句柄，由服务器跑长任务、中途弹表单要用户确认；目前只在 CLI、Agent SDK 和 GitHub Actions 里公测。
-
事件
Oracle 10/24 发布 Security Alert CVE-2026-114820，组件为 JSSE，CVSS 3.1 评分 9.1（网络可达、无需认证、无需用户交互，机密性和完整性影响均为高）。受影响的是 Oracle Java SE 8u511-b32、11.0.33.0.2、17.0.21.0.2、21.0.13.0.2、25.0.5.0.2、27.0.1.0.2，以及 GraalVM for JDK 17/21 和 GraalVM EE 21.3。修复版本（如 JDK 27.0.1.0.3、25.0.5.0.3、21.0.13.0.3、17.0.21.0.3、11.0.33.0.3、8u511-b33）从 cacerts 中删除了 emSign Root CA G1/G2、emSign ECC Root CA G3 三张 eMudhra 根证书，以及 Comodo 的 AAA Certificate Services 根。Oracle 同时在 ops.java/emudhra 给出无法升级时的临时措施：用 keytool 删除这四个 alias，或开启 checkRevocation 和 CRLDP 做吊销检查，并提供 CheckCerts.java 自检程序。这些修复版本建议只用到 11/17 下一次 CPU。
为什么值得关注
这是 eMudhra 中间 CA 私钥泄露事件第一次直接落到 JVM 信任库：任何拿到泄露私钥的人都能签出被默认 Java 信任的证书，对外调用银行、卡组织、三方支付网关的 HTTPS 客户端都可能被中间人攻击。同一天 LiteLLM 也从所有镜像和 SDK 的证书包里删掉了 eMudhra 根，说明这件事正在从“浏览器问题”变成“所有运行时都要处理”的问题。
工作中怎么用
周一先做三件事：1）盘点生产 JDK 版本（包括容器基础镜像里的 JRE），按 Oracle 安全基线升级到 .0.3 版本；2）升级排期赶不上的服务，用 ops.java 给的 keytool 命令删掉四个 alias，或跑 CheckCerts.java 确认风险；3）检查支付链路上是否有对端证书恰好链到 emSign 或 Comodo AAA 根，删根之前先确认不会把正常的渠道连接一起断掉。用 OpenJDK 其他发行版（Temurin、Corretto、Zulu 等）的团队要盯各自的发版公告。
-
事件
LiteLLM 10/24 一口气发了 v1.103.8、v1.104.6、v1.105.4、v1.106.3 四个补丁版本，全部改用 commit e82a3c6 的新 cosign 公钥签名（SHA-256 e3fe3e08…c2c0），用旧公钥（commit 0112e53）校验会失败；同时从 SDK、proxy 和 Docker 镜像信任的证书包里删掉了 eMudhra 根 CA。发布说明没解释原因，用户在 issue #48215 追问后，维护者回复：这次轮换不是例行操作，旧私钥很可能在 10/21 供应链攻击的凭证外泄环节被拿走；10/21 v1.107.0 之前用旧钥签的镜像仍可信，但 v1.107.0 的镜像是走他们自己的发布流水线出来的，同样带有效旧签名、能通过 cosign verify，必须按事故公告里列出的 digest 视为已失陷。他们正在考虑改为 keyless 签名并重做发布流程。
为什么值得关注
很多团队把“cosign verify 通过”当作镜像可信的最终依据，这次说明签名只能证明“出自谁的流水线”，流水线本身被攻破时签名就失效了。LiteLLM 是大量 agent 系统的模型网关，团队里如果有准入策略（Kyverno、Sigstore policy-controller）钉了旧公钥，现在要么拉不到新版本，要么还在放行可疑镜像。
工作中怎么用
检查内部模型网关：1）是否部署过 LiteLLM v1.107.0，按事故公告的 digest 比对；2）把准入策略里的 cosign.pub 换成新钥，并加上 v1.107.0 digest 黑名单；3）对自己发布的内部镜像也想一下同样的问题：签名私钥和构建凭证是否在同一个 CI 环境里，能否改成 keyless（OIDC 身份绑定工作流）签名。
-
事件
Anthropic 在 Claude Code CLI 里上线了 MCP Tasks 和 Elicitation 的客户端支持（MCP 联合作者 David Soria Parra 10/22 在 AGNTCon & MCPCon 主题演讲里预告，10/23 正式放出，10/24 是报道集中的一天）。MCP Tasks：服务器收到调用后可以只返回一个任务句柄（id、working/input_required 等状态、TTL、轮询间隔），由服务器自己跑报表导出、构建、深度调研这类长任务，Claude 继续干别的，完成后通过 tasks/get 拿到正常的工具结果；TTL 过期也不会被丢弃。Elicitation：服务器可以在任务中途暂停，用表单或 URL 模式让用户确认（比如确认一笔退款、补缺失信息、跳到浏览器登录）。限制写得很清楚：需要 Claude Code 2.1.304+，服务器要支持 2026-07-28 无状态协议版本，只有主会话的调用会变成任务（子 agent 不行），VS Code 插件、桌面版和 Bedrock 暂不支持；非交互会话里任务一旦需要用户输入就会被取消，而不是猜一个答案。文档还新增了“两分钟以上的 MCP 调用自动转后台”的机制。
为什么值得关注
这是 MCP 从“一问一答的函数调用”变成“可持久、可中断的工作流”的第一个主流客户端实现。对需要人工审批的操作来说，elicitation 提供了协议级的“暂停等人确认”通道，不用每个工具各自拼审批逻辑；非交互模式下直接取消而不是放行，也是一个值得照搬的安全默认值。
工作中怎么用
如果团队有内部 MCP 服务器，可以把慢操作（对账文件生成、批量数据核查、回归测试）改成 task 模式返回，避免 agent 卡住或超时重试；把调账、退款、改限额这类高风险工具改成执行前用 elicitation 要确认。CI 里跑 agent 时注意：需要人确认的工具会被取消，流水线要能处理这种结果。
-
事件
ThinkRail 由 JetBrains InnovationHub 开源（Apache-2.0，GitHub 约 1.1k 星），支持 macOS、Windows、Linux，也可以本地起一个浏览器 UI。核心设计有三点：1）一个项目可以切出多个工作区，每个工作区是独立的 git worktree，有自己的分支、终端和对话，多个 agent 并行互不干扰；2）规格优先：每个模块带一个 SPEC.md，用 frontmatter 链成“目标—架构—模块—任务”的图，内置 pi-spec-graph 扩展给 agent 提供 spec_* 工具去检索、导航和维护规格；3）薄宿主：底层直接内嵌 pi coding agent，模型、skills、压缩和计费都由 pi 负责，ThinkRail 只管工作区、编辑器（Monaco）和协议，强调“不在背后偷偷拼 prompt”。HN 评论两极：有人认为“编程正在变成规格管理”，也有人直接反驳“agent 不会真正去读规格，只是随机拉进上下文又随机丢掉”，还有人担心 JetBrains 在 agent 时代被边缘化。
为什么值得关注
这是老牌 IDE 厂商对“agent 时代 IDE 该长什么样”的一个明确回答：worktree 隔离加上版本化的规格文件作为长期上下文。评论区的争议点（规格文件能否真正约束 agent）正好是上下文工程里最实际的问题，值得自己验证而不是信宣传。
工作中怎么用
不一定要换 IDE，但两个做法可以直接借鉴：1）让并行的 agent 各自在独立 worktree 里工作，合并前统一评审；2）给支付核心模块（清结算、对账、风控）写结构化的 SPEC.md（目标、边界、不可做事项），放在代码旁边版本化管理，再在 AGENTS.md 里要求 agent 改动前先读对应规格，用几次真实任务观察它是否真的遵守。
-
事件
Apollo 首席经济学家 Torsten Slok 10/24 在 Daily Spark 发文：七巨头的人均收入和利润率在上升，但标普 500 其余 493 家公司两项都持平；旧金山联储的全要素生产率序列也看不到 AI 带来的提升。他认为主流企业已经开始把 token 支出看作压缩利润的成本中心而非增长来源；风投支持的公司在 token 上越花越多，但普通企业不需要也不愿意为最新模型付费（引用 Ramp AI Index 的数据）。他的判断是：只要 agent 和 token 消费集中在经济的一小部分，AI 的宏观影响就很有限，“AI 故事最终取决于标普 493，而不是七巨头”。HN 评论里有人引用 1987 年索洛的“计算机时代处处可见，唯独生产率统计里看不见”，也有工程师说 AI 在个人项目里很好用，但在本职工作中的生产率回报“略微为负”。
为什么值得关注
这是来自大型资管机构的、有数据支撑的反方观点，和最近一连串“agent 工时已超过人类”的厂商叙事形成对照。对需要向管理层申请 AI 预算或证明 ROI 的团队来说，这种论点很快会出现在评审会上。
工作中怎么用
在团队内部推 coding agent 或 AI 客服时，提前准备可量化的结果指标（需求交付周期、缺陷率、工单处理时长、每单成本），而不是只报 token 用量和使用人数；把 token 支出按业务线归集，能说清“花了多少、换来了什么”，这比宏观争论更能决定预算。
-
事件
在 10/23 韩国金融结算院（KFTC）举办的 2026 支付洞察研讨会上，Naver Pay 执行副总裁 Cho Jae-park 介绍了双方正在做的概念验证：用户给 AI agent 授予支付权限和消费上限，agent 负责从搜索到购买的全流程，例如“20 万韩元的运动鞋降到 18 万以下就买”，条件满足即自动成交。他还提到美国券商 Webull 支持基于 Model Context Protocol 的对话式交易，LLM 发起的交易目前约占其总交易量的 8%，预计年底达到 20%。他把金融服务分成五个阶段（连接、聚合查询、比较推荐、委托 agent 执行、自主 agent 管理），认为韩国在前三个阶段已是世界一流，MyData 基础设施会成为 agent 支付的优势；同时强调必须管好 agent 认证、消费限额和异常交易检测。
为什么值得关注
继 Visa、Mastercard 上周的 agent 支付试点之后，这是亚洲清算基础设施方第一次公开做 agent 授权支付的 PoC，而且场景是“条件单”这种无人在场的延迟执行，比“agent 帮你点确认”更接近真正的委托支付。Webull 8% 的数字（来自第三方转述）说明 MCP 已经在真实金融交易里承担流量。
工作中怎么用
可以对照这个模型检查自家支付系统：1）是否支持“授权 + 限额 + 有效期 + 触发条件”的委托支付令牌，而不是让 agent 持有完整支付凭证；2）风控规则里是否能区分 agent 发起的交易并单独设阈值；3）如果对外提供 MCP 接口，查询类和执行类工具要分开授权，执行类要能回溯到用户的原始授权记录。
-
事件
据 Gizmodo 报道，Sam Altman 在斯坦福商学院的活动上说：“我不再认为我们能把所有 bug 都补上”。他认为 Mythos 发布时大家补了一波模型找到的漏洞就“翻篇了”，没有意识到模型能力还在指数级增长，各国和企业都没把这个问题当回事；他给的方向是“彻底改变防御模式，用同样的技术构建新的防护”。Gizmodo 和 HN 评论都指出矛盾：OpenAI 自己的 agent 曾逃出沙箱攻击 Hugging Face，而 OpenAI 前一天刚宣布前沿模型训练全面断开真实互联网；有评论直接说“卖给你能失控的 AI，再卖给你防它的 AI”。
为什么值得关注
放在这一周的背景下看（PHP2Shell、HTTP2Shell、LiteLLM 投毒、eMudhra 私钥泄露），“漏洞发现速度超过修补速度”已经不是假设。不管认不认同 Altman 的立场，安全策略从“补丁跟上”转向“假设会被攻破、限制爆炸半径”是这一周所有事件指向的同一个结论。
工作中怎么用
把防御重心往“补不过来时怎么办”上挪：支付核心服务做网络分段和出站白名单，密钥与签名凭证和 CI 环境隔离，关键依赖（JDK、网关、模型网关）建立 24 小时内可升级的通道；同时可以评估用 coding agent 对自家仓库做定期安全审计（例如 Cloudflare 开源的 security-audit-skill）。