每日科技资讯精选｜2026-10-25

2026-10-25 每日科技资讯精选 · 本期 6 条。今天最重要的一件事是 Brotli 漏洞的扩散面仍在扩大：10 月 24 日的新排查证实，Bazel 中央注册表里的全部五个 Brotli 模块都未含修复、Cloudflare 开源 workerd 与 DuckDB 内嵌的解码器同样未修复——只升级 Node.js 或系统 libbrotli 的团队，仍可能在构建链与数据工具里留着旧解码器。

1. Brotli 漏洞扩散新证据：Bazel 注册表无修复版、workerd 与 DuckDB 仍带旧解码器（OpenSourceMalware · 2026-10-24 20:34（北京时间，原文 12:34 UTC） · 独立研究）（P1 值得阅读） #

就此条发起议题

• 新变化/核心观点：OpenSourceMalware 10 月 24 日更新其 CVE-2026-111497 排查：Bazel 中央注册表的五个 Brotli 模块（1.1.0、1.2.0、1.2.0.bcr.1、1.2.0.bcr.2、1.2.0.bcr.3）均未含修复，Google 虽已于 10 月 21 日标记 1.2.1、1.1.1、1.0.10，但注册表尚未收录任一修复版，.bcr 后缀只是打包修订，1.2.0.bcr.3 底层仍是 Brotli 1.2.0。Cloudflare 开源 workerd 的依赖文件锁定 b***@1.2.0.bcr.3，截至 10 月 24 日未见公开修复 PR，Cloudflare 方面称生产 Workers 已打补丁、workerd 修复即将发布。DuckDB 内嵌 Brotli 1.1.0 副本，10 月 23 日提交的移植修复 PR #27791 截至 10 月 24 日仍在等待评审；PostHog 已自行给其 DuckDB 分支打补丁并在其 DuckLake 分支中拒绝 Brotli 作为 Parquet 编解码器。
• 对银行业的价值：（推断）银行的排查清单应从运行时版本扩展到构建产物：凡用 Bazel 构建的服务须检查是否从中央注册表拉取 Brotli，必要时自行覆盖源码；自建 workerd、内嵌 DuckDB 的数据分析链路须单独确认解码器版本，系统级 libbrotli 升级覆盖不到它们；在修复到位前，对不可信来源的 Brotli 压缩内容（HTTP 响应体、Parquet 文件）应按文中的缓解建议收紧。
• 值得深读：“October 24 updates”一节的三组证据（Bazel 模块补丁逐项核查、workerd 依赖锁定与本地测试、DuckDB PR 状态）；文末 7 条行动清单中“内嵌副本排查 grep 方法”与“重建”一条。
• 原文链接：https://opensourcemalware.com/blog/brotlipocalypse

2. Anthropic 开源 sandbox-runtime：不用容器、用操作系统原生机制给 Agent 加沙箱（MarkTechPost · 2026-10-24 19:12（北京时间，原文 11:12 UTC） · 媒体报道）（P1 值得阅读） #

就此条发起议题

• 新变化/核心观点：Anthropic 的 sandbox-runtime（srt）是 Claude Code 沙箱化 bash 工具背后的运行时，现以 npm 包 @anthropic-ai/sandbox-runtime v0.0.81（约 11.4 MB、Apache-2.0、需 Node.js 22.12+）开源，且不限于 Claude Code，任何进程、本地 MCP 服务器均可套用。它按平台使用原生隔离原语：macOS 用 sandbox-exec 加动态 Seatbelt 配置，Linux 用 bubblewrap 并需 socat 与 ripgrep，Windows 仍为 alpha（专用 srt-sandbox 账户、WFP 出口围栏与文件 ACL）。默认策略是读默认放行、写默认拒绝、网络默认拒绝，流量只经宿主侧 HTTP/SOCKS5 代理并按域名 allowlist 放行；Anthropic 自述其内部 Claude Code 权限提示减少 84%，该数字为厂商自报、非外部基准。
• 对银行业的价值：（推断）银行在开发机与 CI 上跑编码 Agent、MCP 服务器时，这是一个比拉起完整容器更轻的进程级隔离选项：把 .mcp.json 的 command 从 npx 换成 srt 即可套用，域名 allowlist 与禁读 ~/.ssh、.env 的默认姿态可直接对应内部密钥防外泄要求；但须注意它仍是 beta 研究预览，Windows alpha 与 allowlist 过宽都会削弱实际防护，上线前应在隔离环境实测。
• 值得深读：默认策略段（读/写/网络三条默认规则）；“ask callback、按命令 allowlist、--control-fd 实时换表、解析地址环回与云元数据 IP 拦截”一组权衡旋钮；与 Codex CLI 沙箱、Docker Sandboxes、E2B 的对照表。
• 原文链接：https://www.marktechpost.com/2026/10/24/anthropic-sandbox-runtime-ai-agent-sandbox/

3. Claude Code MCP Tasks 与 Elicitations 上线分析：长任务与中途确认有了协议化答案（Forkast · 2026-10-25 07:26（北京时间，原文 23:26 UTC） · 媒体报道）（P1 值得阅读） #

就此条发起议题

• 新变化/核心观点：这篇 10 月 25 日的分析梳理的是 10 月 23 日的上线事实，而非当日新发布：Claude Code CLI 以公开 beta 支持 MCP Tasks 与 Elicitations，需 v2.1.304 或更高版本。Tasks 让服务器对慢工具先回任务句柄、客户端以 tasks/get 轮询直至完成，TTL 过期也不丢弃任务；Elicitations 让工具在任务中途以表单或 URL 形式向用户提问，答案再回到工具调用。适用面明确限定为终端 CLI、Agent SDK 与 GitHub Actions 会话，子 agent 调用、一次性 claude -p、VS Code 扩展与桌面应用不在内；提问仅在交互式终端会话中送达，非交互会话会取消索要输入的任务而非猜测；服务器须讲 2026-07-28 版协议，MCP 规范本身此次未变。
• 对银行业的价值：（推断）银行内部 Agent 平台若用 MCP 接长耗时工具（如报表生成、构建、跨系统查询），可用 Tasks 替代各插件自写的轮询胶水，并把“发布前确认、补齐关键参数”这类人工确认点做成 Elicitation 而非绕过；但落地前必须按文中的排除清单核对运行面——桌面端与 Bedrock 等不取 feature flag 的第三方渠道目前不在支持范围内，面向业务人员的 Agent 不宜直接按此设计。
• 值得深读：“Two mechanics, one pattern”对任务句柄字段与轮询语义的拆解；“Three surfaces in, named exclusions out”的完整排除清单；文末对“规范未变、只是单厂商客户端行为层”的定性。
• 原文链接：https://forkast.news/claude-ships-mcp-tasks-and-elicitations-in-claude-code-durable-agent-workflows-narrow-launch/

4. 新分析：同一模型换编码 Agent 框架，得分几无变化、成本最高差 3 倍（dev.to · 2026-10-25 10:01（北京时间，原文 02:01 UTC） · 社区文章）（P1 值得阅读） #

就此条发起议题

• 新变化/核心观点：这篇 10 月 25 日的新文章复述并拆解的是 10 月 3 日上 arXiv 的论文《What Does a Harness Buy? Tokens, Mostly》（山东大学 Yangze Liu、Zhongyi Han）与 10 月 23 日 VentureBeat 的报道，而非当日新论文：同一模型、同一批 SWE-bench Verified 任务下，Claude Code 与最轻量的 mini-SWE-agent 在 447 题池中得分在 5 分误差内等价，45 题难题子集上换框架翻转的任务比例（约 13%）与重跑同一框架翻转的比例相当；唯一超出噪声的框架效应是损失而非增益——OpenCode 最多落后 9 分，其中一部分源于输出截断后未重提。成本才是分水岭：每步重发的框架前言分别为 Claude Code 16,581 token、OpenCode 7,025 token、mini-SWE-agent 829 token，GLM-5.3-Flash 上单题成本分别为 1.81、0.56、0.97 元（单位为元，按文中价格），DeepSeek-V4-Flash 上因步数差异（mini-SWE-agent 141 步对 Claude Code 104 步）顺序翻转；96%–99% 的输入 token 命中提示缓存，缓存只缩放账单、不改变排序。
• 对银行业的价值：（推断）银行选型编码 Agent 时，不应只比厂商宣传的通过率：应把“首调用 token、前言大小、每步增长、步数”四项作为采购与成本测算的必录指标，在自有仓库与自有模型上复跑一次再定；同时注意该研究的局限——447 题池多数配置只有单次运行，闭源 Opus 5 仅在 Claude Code 内跑过，结论不宜直接外推到所有闭源模型。
• 值得深读：“Cost: the preamble, times the steps”中前言与步数的拆解及 100 步外推算式；“Two things to check”中联网跑偏（71% 的 DeepSeek/Qwen 试验从 GitHub 抓到上游修复）与 thinking 默认值对得分的影响；文末伯克利 HarnessTax 的对照（通过率仅动几点、成本最高差 5 倍）。
• 原文链接：https://dev.to/gabrielanhaia/same-model-different-coding-agent-harness-scores-mostly-held-cost-moved-up-to-3x-31o1

5. KServe 冷启动实测：warmctl 快照恢复把 Qwen3-8B 新副本压到 14.1 秒（窗口边缘补录）（warmctl · 2026-10-24（页面仅标注日期） · 厂商自述）（P2 可选） #

就此条发起议题

• 新变化/核心观点：warmctl 10 月 24 日的实测文章对比了同一 Qwen3-8B、同一 L40S 上的启动耗时：vLLM 冷启动 134 秒、内核缓存加权重已在内存时 33 秒、warmctl 快照恢复在快照已在内存时 9.1 秒；作为 KServe LLMInferenceService 扩容时，新副本从创建到 Ready 为 14.1 秒（其中 KServe 自身调度占 14.8 秒为一次性成本，另计）。Qwen3-32B 在 2×L40S 上对应为 251 秒、47 秒、13.8 秒。实现方式是 warmctl 预先对热引擎（含进程与 GPU 内存）做快照并以 OCI 镜像分发，KServe 预设把服务命令从 vllm serve 换成 warmctl up；代价同样写明：冷节点上快照比权重更大、0.44 GiB/s 磁盘上 8B 仅快 1.7 倍，且目前需要特权 Pod（CRIU 所需）、暂不支持跨节点预填充/解码拆分、TLS 到 Pod 仍有缺口。
• 对银行业的价值：（推断）银行推理服务扩容慢、突发流量下冷启动拖垮 SLO 时，这篇实测提供了一个可对照的基线与取舍清单：先测自家内核缓存路径的真实耗时，再评估“快照预热 + 节点预取”是否值得；但特权 Pod 与快照镜像的供应链（快照内含完整引擎状态）必须先过安全评审，不宜直接照搬演示配置。
• 值得深读：第 01 节按阶段拆解的耗时表（编译、权重、CUDA 图、内存画像各占多少）；第 02 节 KServe 预设 YAML 与 14.1 秒的构成说明；第 07 节“尚不支持”清单（特权 Pod、HTTPS、冷节点、单节点副本）。
• 原文链接：https://warmctl.io/blog/kserve-llm-replicas-in-seconds/

6. 单卡双 vLLM 实测：一张 RTX 3090 上嵌套与对话模型共存的启动陷阱与解法（dev.to · 2026-10-25 01:27（北京时间，原文 17:27 UTC） · 社区文章）（P2 可选） #

就此条发起议题

• 新变化/核心观点：作者在租用的 RTX 3090（24 GB）上用 vLLM 0.27.1 实测：BAAI/bge-small-en-v1.5（嵌入）与 Qwen2.5-1.5B-Instruct（对话）各跑一个 vllm serve，--gpu-memory-utilization 分别设 0.10 与 0.70 时可共存，共用 18,317 MiB，零错误；但若先以 0.9 启动对话服务，再以 0.10 启动嵌入服务会因启动检查失败——vLLM 要求空闲显存至少达到所设比例对应的整卡份额，而非模型实际用量。解法是给无 KV 缓存的池化嵌入模型设 0.03，配合 --max-model-len 512 与 --max-num-seqs 32，实测仅用 454 MiB 且吞吐与 0.10 时相同。双忙时的代价是嵌入吞吐降 8.6%、对话输出降 11.8%，且两者之间没有任何隔离。
• 对银行业的价值：（推断）银行在单卡上混部“小嵌入 + 小对话”做试点或低峰服务时，这篇实测给出了可直接复用的参数起点与一条硬规则：先启动大模型再以极小比例启动池化模型，并逐个启动而非同时启动；但无隔离意味着一方突发会拖慢另一方，生产混部仍需以可接受的 SLO 降级为前提，不宜当作正式容量规划依据。
• 值得深读：“The startup check”中启动检查报错原文与成因；“The fix”中 0.03 比例与两个上限参数的组合；“Limits”中作者自述的局限（单卡、单版本、小模型、短时、单次试验）。
• 原文链接：https://dev.to/qaisermehdi/two-vllm-servers-on-one-gpu-the-startup-check-that-bites-and-the-fix-1nde

后续关注

• Google 计划于 2026-10-27（太平洋时间）从 Chrome Root Store 移除 eMudhra 的 emSign ECC Root CA-G3，链下合法证书须在此前完成更换。
• Kubernetes 1.34 将于 2026-10-27 结束支持，仍在该版本的集群应以 1.36 为升级目标。
• LiteLLM 承诺于 2026-10-24 当日结束前发布移除 eMudhra CA 信任的新版本，本轮检索未见发布确认；同时其第二个独立漏洞定于 2026-10-27 披露，届时按常规扫描复核。

窗口边缘（未列入）

• Google Data Agent Kit GA 的 zot.news 文章（2026-10-24）：其 GA 实际发布于 10 月 9 日当周的 Google Cloud 摘要中，10 月 24 日文章为旧闻二次报道，未列入。
• Microsoft 对 LiteLLM 1.107.0 载荷的分析（2026-10-23）：落在基准窗口之外，且攻击链本身已见于 10 月 24 日期简报，未列入。
• AWS 欧洲主权云断网演练（2026-10-24）：公告早于窗口，窗口内未见演练结果公布，仅作后续关注背景，未列入。

已查信源

• 平台与容器项目官方渠道：Envoy Gateway v1.9.2（2026-09-28，窗口外）；Kubernetes、Argo CD、Flux、Backstage、OpenTelemetry、Prometheus、Istio、Cilium 本轮检索未见窗口内重要更新。
• 网关与 AI 基础设施项目官方渠道：LiteLLM 承诺的 eMudhra 移除版本本轮未见发布确认；Kubernetes Gateway API、Envoy AI Gateway、Kong、APISIX、Higress、SFTPGo、tus、Kueue、Volcano、HAMi、Koordinator、KServe、vLLM、llm-d 本轮检索未见窗口内重要更新（KServe/vLLM 相关实测见正文第 5、6 条）。
• 社区与媒体：Forkast 2026-10-25（见正文第 3 条）、dev.to 2026-10-25（见正文第 4、6 条）；CNCF 博客最新 2026-10-19、The New Stack 相关文章为窗口外。
• 云厂商官方博客：AWS 欧洲主权云演练（2026-10-24，公告早于窗口、结果未公布）；Google Cloud、Azure、Cloudflare 官方博客本轮未见聚焦领域新文。
• AI 厂商官方发布：Anthropic sandbox-runtime 相关报道 2026-10-24（见正文第 2 条）；MCP Tasks 上线于 2026-10-23、分析见正文第 3 条；OpenAI、Google DeepMind、MCP 官方博客/规范本轮无变化。
• 学术：arXiv 论文《What Does a Harness Buy? Tokens, Mostly》提交于 2026-10-03，VentureBeat 报道于 2026-10-23，dev.to 新分析见正文第 4 条；2026-10-24/10-25 提交中未发现与 Agent 可观测、运维 Agent/AIOps、AI 编码、LLM 推理与算力调度强相关的达标论文。
• 热度参考：Hacker News 首页 2026-10-24 盘点中 Brotli、MCP 相关讨论与正文条目对应，其余热帖与聚焦领域无直接关系。