去年就想买，但是觉得高，就没买，今天黄金超 5000 了，能追吗？不追可能就 6000 了，追的话有什么办法降低风险，韭菜一枚

我的组装电脑，win11 ，25h2。
之前蓝牙功能好好的，连接手机或者耳机都没问题。
最近忽然就无法和新的耳机、手机配对了，已经配对的蓝牙耳机可以正常连接使用。
电脑设置里的添加设备能够扫描到新手机、耳机，就是配对不成功。
这种情况可能是什么问题？

VMware ESXi 8.0U3h 发布 - 领先的裸机 Hypervisor

同步发布 Dell (戴尔)、HPE (慧与)、Lenovo (联想)、Inspur/IEIT SYSTEMS (浪潮)、H3C (新华三)、Cisco (思科)、Fujitsu (富士通)、Hitachi (日立)、NEC (日电)、Huawei (华为)、xFusion (超聚变) OEM 定制版

请访问原文链接：https://sysin.org/blog/vmware-esxi-8-u3/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

ESXi 8.0U3h 已于 2025-12-16 发布，今天单独一篇来看一下新增功能。

VMware ESXi - 领先的裸机 Hypervisor

ESXi

产品简介

VMware ESXi：专门构建的裸机 Hypervisor

了解可直接安装到您的物理服务器的、可靠的裸机 Hypervisor。通过直接访问并控制底层资源，VMware ESXi 可有效地对硬件进行分区，以便整合应用并降低成本。它是业界领先的高效体系架构 (sysin)，在可靠性、性能和支持方面树立了行业标杆。

新增功能

VMware ESXi 8.0 Update 3h | 15 DEC 2025 | ISO Build 25067014

vCenter 机器 SSL 证书和 ESXi SSL 证书的自动续订：

从 vCenter 8.0 Update 3h 开始，由 VMware Certificate Authority（VMCA） 为 vCenter 以及 8.0 Update 3 及更高版本的 ESXi 签发的 SSL 证书，会在接近到期日期时自动续订。

  • 当 vCenter 机器 SSL 证书 距离到期不足 5 天 时，证书会自动延长 2 年。
  • 对于支持 无中断证书续订 的 ESXi 主机，当 SSL 证书 距离到期不足 10 天 时，证书会自动延长 5 年。

如果 VMCA 证书模式 设置为 custom，自动续订功能将不会生效。要启用该功能，需要将证书模式更改为 vmca。

此补丁包含对以下问题的修复：

PR 3599476：托管在 vSAN File Services 上的文件或文件夹可能无法访问

在升级到 vSphere 8.0 Update 3e 或更高版本后，由于 I/O 提交不完整，vSAN 集群中的 vSAN File Services 共享上的文件或文件夹可能会出现可访问性问题。这会导致无效参数错误或文件写入失败，影响在升级过程中经历过状态转换的共享 (sysin)。升级后新创建的共享不受影响。

此问题已在本版本中解决。

PR 3577856：在处理 LSOM 磁盘拥塞时，重新同步时间过长

SSD 磁盘的一个内部标志问题可能会阻止组件被正确标记为缺失，从而在处理 LSOM 磁盘拥塞时导致重新同步时间过长。

此问题已在本版本中解决。

PR 3577827：vSAN 网络告警显示网络错误率超过 100%

在 vSAN 网络告警视图中，某些网络错误率值可能显示为高于 100%。

此问题已在本版本中解决。

PR 3567326：vSAN 健康告警显示加密密钥不一致

在从启用了 vSAN OSA 加密并使用 Native Key Provider 的 vSAN 7.0 Update 3 升级后 (sysin)，vSAN 健康告警可能会显示加密密钥不一致。

此问题已在本版本中解决。

PR 3545007：vSAN 原生跟踪对象中，不同 ESXi 主机上的 vSAN 跟踪保留不均衡

清理逻辑会导致 vSAN 原生跟踪对象中，不同 ESXi 主机之间的 vSAN 跟踪保留不均衡。

此问题已在本版本中解决。

PR 3451034：在收集 CPU 使用率统计信息期间，由于竞争条件，ESXi 主机可能出现紫屏（PSOD）

在收集 CPU 使用率统计信息时，VMkernel 可能遇到竞争条件，导致出现带有 #PF Exception 14 error 的紫色诊断屏幕。在堆栈跟踪中，可以看到与 CpuMetricsLoadHistorySnapshotStats 相关的错误。

此问题已在本版本中解决。

PR 3562682：ESXi 主机可能会间歇性地从 Active Directory 域或 vCenter 断开连接

在 Active Directory 操作期间，或在 ESXi 主机上启用智能卡认证时，Likewise 组件可能发生内存泄漏。结果是 Likewise 进程可能耗尽内存，导致 ESXi 主机间歇性地从 Active Directory 域或 vCenter 断开连接。在 /var/log/vmkernel.log 文件中 (sysin)，可以看到类似以下的信息：

yyyy-mm-dd In(182) vmkernel: cpu72:2110465)uw.2110464 (44739) requires 1024 KB, asked 1024 KB from likewise (792) which has 93112 KB occupied and 72 KB available.
yyyy-mm-dd In(182) vmkernel: cpu72:2110465)Admission failure in path: host/vim/vmvisor/likewise:lwsmd.2110464:uw.2110464

在 hostd-probe.log 文件中，可以看到类似以下的消息：hostd 被检测为无响应。

此问题已在本版本中解决。

PR 3538241：由于主机上的 SSH 默认值与期望映像不匹配，ESXi 主机可能被报告为不合规

当应用使用 SSH 默认设置的 vSphere 配置文件时，某些 ESXi 主机可能被报告为不合规。这是因为 ESXi 主机不会保存 SSH 设置的默认值，从而导致 vCenter 中的期望配置文件与 ESXi 主机实际配置不匹配，进而使合规性检查失败。

此问题已在本版本中解决。

PR 3567000：第一类磁盘（FCD）任务失败并返回错误 vim.vslm.host.VStorageObjectManager.retrieveVStorageObjectMetadata: :vmodl.fault.ManagedObjectNotFound

在某些情况下，FCD 任务可能会在 vpxa 日志中失败，并显示如下错误：

vim.vslm.host.VStorageObjectManager.retrieveVStorageObjectMetadata: :vmodl.fault.ManagedObjectNotFound

此问题已在本版本中解决。

PR 3562151：当 ESXi 与 NVMe over FC 存储阵列之间的一条或多条路径丢失时，应用程序或虚拟机可能无响应

ESXi 通常对存储阵列使用多路径机制，但即使仍有可用的活动路径，在某些情况下，丢失一条或多条路径也可能导致虚拟机无响应 (sysin)。问题的原因是，一些正在进行的 NVMe 命令可能到达已失效的路径，无法完成或停止，结果这些命令会一直被阻塞，直到路径恢复，从而导致应用程序或虚拟机无响应。

此问题已在本版本中解决。

PR 3547549：如果虚拟机每个插槽的核心数超过 255，快速挂起/恢复（FSR）或迁移任务可能失败

如果虚拟机每个插槽的核心数超过 255，迁移、快速恢复或热插拔等任务会失败。在 vmware.log 中，可以看到类似以下的信息：

2024-09-04T14:33:07.488Z In(05) vmx - [msg.checkpoint.inConsistentCoresPerSocket] The suspended image contains a coresPerSocket value (0) that does not match with VM's actual coresPerSocket value (256).

此问题已在本版本中解决。

PR 3517793：在 vSAN File Service 容器故障切换后，可能会看到一个或多个虚拟机来宾文件系统磁盘空间不足的告警

在极少数情况下，当 vSAN File Service 容器故障切换到另一台 ESXi 主机时，日志文件可能仍保留在源主机上。由于这些陈旧日志未释放磁盘空间，随着时间推移可能会导致磁盘空间占用显著增加，并触发“一个或多个虚拟机来宾文件系统磁盘空间不足”的告警。该问题通常只会在 vSAN File Service 运行较长时间并且发生过多次成功故障切换后出现，并非每次故障切换都会发生。

此问题已在本版本中解决。

PR 3597422：在具有 2 个 DPU 的 ESXi 主机上升级 NSX 可能触发意外的 DPU 故障切换

在具有 2 个 DPU 的 ESXi 主机上执行 NSX 升级期间，可能会触发意外的 DPU 故障切换，从而导致 vSphere Distributed Switch（VDS）失败并阻塞 vSphere vMotion 任务，或者故障切换状态在主机重启后仍然存在 (sysin)，并导致 VDS 下线。

此问题已在本版本中解决。

PR 3558631：启用集群 VMDK 时，VMkernel 线程可能在 ESXi 主机上占用 100% CPU

当启用集群 VMDK 时，VSCSISharedVdMainWorld 内核线程可能在 ESXi 主机上消耗过多的 CPU 资源，CPU 使用率可能持续保持在 100%。

此问题已在本版本中解决。

PR 3445897：在传输被分段为大量 scatter-gather 条目（SGE）的大数据包时，可能发生丢包

如果大型 TCP 数据包被拆分为超过 24 个 SGE，数据包传输可能会失败，并显示错误 “Failed to divide TSO packet into 2”。

此问题已在本版本中解决。修复后，大数据包可以被正确分段并正常传输。

PR 3570996：在列出 vSphere Virtual Volumes 数据存储内容时，vSphere Virtual Volumes 服务 vvold 可能因转储而失败

当 VASA Provider 对 queryVirtualVolumeInfo 请求返回部分响应时，vvold 可能会因查询越界而失败。

此问题已在本版本中解决。修复通过避免部分响应来防止 vvold 失败。

PR 3565927：在 ESXi 安装期间，可能无法发现 iSCSI SAN 启动 LUN

在极少数情况下，在 ESXi 安装期间，初始连接尝试可能因某些原因失败，例如 iSCSI 目标地址使用 IPv6，或者无法发现 iSCSI SAN 启动 LUN。结果是网络配置被回滚，后续尝试连接 iSCSI 目标或发现 iSCSI SAN 启动 LUN 都会失败。

此问题已在本版本中解决。

PR 3576783：当源和目标未同时通过同一控制器的活动路径时，NVMe 设备上的硬件加速克隆操作可能失败

如果 NVMe 复制命令的源设备具有活动路径，而目标设备仅通过同一控制器的备用路径连接，则目标可能会使命令失败。当源和目标设备都通过同一控制器的活动路径连接时，复制命令可以正常工作。

此问题已在本版本中解决。

PR 3588199：在某个磁盘上启用了 Changed Block Tracking（CBT）的虚拟机在迁移后可能失败或重启

当虚拟机位于 vSphere Virtual Volumes 数据存储上，并且其某个磁盘启用了 CBT 时，如果 vSphere vMotion 任务在后期阶段失败，虚拟机在迁移后可能无法运行或重启。

此问题已在本版本中解决。如果您已经遇到该问题且未升级到 ESXi 8.0 Update 3h，请在此类情况下禁用 CBT。

PR 3549572：失败的静默快照可能会损坏 vSphere Virtual Volume 或 vSAN 磁盘的磁盘链

如果对使用 vSphere Virtual Volume 或 vSAN 磁盘的虚拟机创建静默快照失败，部分或全部磁盘链可能会被损坏。虚拟机将无法被正确管理，并且可能发生数据丢失，迫使您从备份中恢复。

此问题已在本版本中解决。

PR 3583385：无法看到虚拟机网络接口的丢包统计信息

由于 VNIC 后端错误，环境中的分布式虚拟交换机统计信息可能无法收集丢包数据 (sysin)。结果是，即使通过第三方工具确认存在丢包，在 vSphere Client 或 VMware Aria Operations 中也无法看到相关数据。

此问题已在本版本中解决。修复确保由于 VNIC 后端错误导致的丢包会被纳入分布式虚拟交换机的统计信息中。

PR 3545592：与 SSH 相关的日志出现在 /var/run/log/syslog.log 中，而不是 auth.log

某些与 SSH 相关的日志可能会被记录到 /var/run/log/syslog.log，而不是通常的 /var/run/log/auth.log。

此问题已在本版本中解决。

PR 3530277：NVMe 核心层中的一个罕见问题可能导致 ESXi 主机出现紫屏

当 NVMe 控制器与 ESXi 主机断开连接或主机关闭时，NVMe 核心层与 NVMe/TCP 驱动程序之间可能发生竞争条件。NVMe 核心层可能在驱动程序完成队列资源清理之前就开始清理控制器资源，结果驱动程序无法访问控制器对象，从而导致 ESXi 主机出现紫色诊断屏幕。

此问题已在本版本中解决。

PR 3585442：由于缺少图形类型，在 GPU 设备故障后 hostd 服务终止

在某些情况下，hostd 服务的图形管理器无法处理来自 GPU 设备的意外图形类型并发生故障。结果是 ESXi 主机可能会从 vCenter 断开连接。

此问题已在本版本中解决。

PR 3540480：在从 NVMe 驱动器获取 SMART 统计信息时，ESXi 主机可能出现紫屏

如果在从 NVMe 驱动器获取 SMART 统计信息时，由于坏盘或其他原因，同步命令（如 VMK_NVME_ADMIN_CMD_GET_LOG_PAGE）延迟超过 120 秒，ESXi 主机可能会出现紫色诊断屏幕。

此问题已在本版本中解决。

PR 3569856：在 IP 输入访问全局地址列表时发生的竞争条件可能导致 ESXi 主机出现紫屏

在 IP 输入访问全局地址列表时，极少数情况下可能发生竞争条件，使多个 ESXi 主机对 vCenter 无响应，并最终出现紫色诊断屏幕。

此问题已在本版本中解决。

PR 3570676：由于 TCP/IP 定时器实现中的罕见竞争条件，ESXi 主机可能出现紫屏

当 TCP/IP 定时器在已断开的连接上触发时，ESXi 主机可能会出现紫色诊断屏幕。该问题发生概率很低，因为竞争窗口非常小，并且 TCP/IP 定时器检查机制已尽量降低此类风险。

此问题已在本版本中解决。

PR 3576190：TCP/IP 栈中的竞争条件可能导致 ESXi 主机无响应并最终出现紫屏

由于 TCP/IP 栈中数据路径与从接口移除 IP 地址的过程之间存在竞争条件，某些 ESXi 主机可能会随机变得无响应，并最终出现紫色诊断屏幕。结果是，在受影响主机上运行的关键应用程序可能会中断。

此问题已在本版本中解决。

PR 3557350：复制的虚拟机在增量同步期间可能间歇性无响应

在备份操作后的复制虚拟机增量同步期间，如果来宾操作系统发出的 UNMAP 命令处理不当，可能会导致虚拟机对 ping 无响应，并需要重启才能恢复。

此问题已在本版本中解决。

PR 3538148：当 ESXi 主机具有大量存储设备时，任务管理操作（如取消）完成时间过长

如果在具有大量存储设备的 ESXi 主机上，针对某个设备并行运行多个命令 (sysin)，则诸如停止该设备上所有命令之类的任务管理操作可能需要很长时间才能完成。

此问题已在本版本中解决。修复增强了在多线程排队情况下存储设备的超时处理机制。

PR 3560144：ESXi 主机上的 I/O 因错误 “Unable to map SG array on path.” 而失败

由于直接内存访问（DMA）限制，某些驱动程序可能会拆分具有较大块大小的 I/O，导致 I/O 无法取得进展并最终失败。在 vmkernel 日志中，可以看到如下错误：

vmkernel: cpu3:29408512)ScsiPath: 3787: Opcode 0x2a(0x45b9977a4040) Unable to map SG array on path vmhba2:C0:T7:L32. Status: DMA mapping could not be completed DMA Error: Can't meet SG element alignment.”

此问题已在本版本中解决。

PR 3572857：在将虚拟机迁移到启用了分布式防火墙规则的 ESXi 主机时，软件竞争条件可能导致紫屏

在 vSphere vMotion 操作期间，目标主机会恢复分布式防火墙规则。由于软件竞争条件，规则恢复过程可能被调用两次，从而导致 ESXi 主机出现紫色诊断屏幕。

此问题已在本版本中解决。

PR 3574732：ESXCLI 命令 esxcli vsan debug object 可能返回错误的 vSAN ESA 对象已用容量值

ESXCLI 命令 esxcli vsan debug object overview 和 esxcli vsan debug object list 可能会为 vSAN ESA 对象报告错误的已用容量值。

此问题已在本版本中解决。

PR 3573888：由于 vSphere Virtual Volumes 的内存问题，ESXi 主机可能失败并出现错误 “BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4944”

如果在未持有锁的情况下修改了 vSphere Virtual Volumes 设备的缓存调度策略，当两个或多个线程同时尝试释放该策略时，ESXi 主机可能会失败，并显示错误 BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4944。

此问题已在本版本中解决。

PR 3529555：虚拟机迁移或创建快照等操作因 InvalidState 错误而失败

由于身份验证问题，虚拟机迁移或创建快照等操作可能失败，并显示以下错误：

在 hostd.log 中：vim.fault.InvalidState

在 vpxa.log 中：The operation is not allowed in the current state.

此问题已在本版本中解决。

PR 3541320：由于罕见的时间问题，ESXi 许可证可能提前过期

由于 hostd 服务中的一个罕见边界时间问题，ESXi 许可证可能在分配的到期日期之前过期，从而中断虚拟机操作。

此问题已在本版本中解决。

PR 3547590：罕见的内存预分配问题可能导致 ESXi 主机出现紫屏

对于某些类型的虚拟机（如 PCIe 直通虚拟机），ESXi 会在虚拟机上电时尝试预分配内存。如果在内存预分配期间虚拟机同时被 vSphere High Availability 终止，ESXi 主机可能会出现紫色诊断屏幕。

此问题已在本版本中解决。

PR 3557452：在 hostd 日志中看到多条 VMX 记分板不可读的消息

在从克隆或模板创建虚拟机后，vmxstats.filename 可能会重复父虚拟机的名称，导致主机统计注册表无法读取并记录新虚拟机的统计信息。结果是在 hostd 日志中会看到多条类似以下的信息：
Adding VM XXX failed, file /vmfs/volumes/YYY/ZZZ/ZZZ.scoreboard is not readable。
该错误不会以任何方式影响新虚拟机的功能。

此问题已在本版本中解决。

PR 3553366：NVMe over Fibre Channel（NVMe/FC）设备在链路重置后无法恢复

在极少数情况下，由于并行发现和连接 NVMe/FC 设备时发生死锁，ESXi 主机在链路重置后可能无法重新连接所有 NVMe/FC 设备，并且已连接设备的性能也可能下降。

此问题已在本版本中解决。

PR 3552793：ESXi 主机在 NVMe UNMAP 操作期间可能发生内存泄漏

如果在 NVMe UNMAP 操作期间，对 NVMe 目标的 identify namespace 调用失败，为 UNMAP 命令分配的内存可能不会被释放。结果是，在重启主机以回收内存之前，该 ESXi 主机可能会显示更高的内存使用率 (sysin)。

此问题已在本版本中解决。

PR 3546519：vmxnet3 虚拟网卡在重新配置后可能停止发送数据

在高流量情况下，vmxnet3 虚拟网卡重新配置与发送路径之间发生的罕见竞争条件，可能会导致虚拟网卡在重新配置后停止发送数据。

此问题已在本版本中解决。

下载地址

VMware vSphere Hypervisor (ESXi) 8.0U3h

下载地址：https://sysin.org/blog/vmware-esxi-8-u3/

  • 发布日期：2025-12-15
  • 若干已知问题修复，详见官方文档或原文链接。
  • VMware vSphere Hypervisor (ESXi ISO) image
    File Name: VMware-VMvisor-Installer-8.0U3h-25067014.x86_64.iso
  • VMware vSphere Hypervisor (ESXi) Offline Bundle
    File Name: VMware-ESXi-8.0U3h-25067014-depot.zip

OEM Custom Image：

  • Dell Custom Image for ESXi 8.0U3h Install CD
  • HPE ProLiant Custom Image for ESXi 8.0U3h Install CD
  • HPE Synergy Custom Image for ESXi 8.0U3h Install CD
  • HPE Superdome Flex and Compute Scale-up family of servers Custom Image for ESXi 8.0U3h Install CD
  • IEIT SYSTEMS Custom Image for ESXi 8.0U3h Install CD
  • Lenovo Custom Image for ESXi 8.0U3h Install CD
  • H3C Custom Image for ESXi 8.0U3h Install CD
  • Cisco Custom Image for ESXi 8.0U3h Install CD
  • Fujitsu Custom Image for ESXi 8.0U3h Install CD
  • Hitachi Custom Image for 8.0U3h Install CD
  • NEC Custom Image for VMware ESXi 8.0U3h Install CD
  • Huawei Custom Image for VMware ESXi 8.0U3h Install CD
  • xFusion Custom Image for VMware ESXi 8.0U3h Install CD
  • 请访问：VMware ESXi 8.0U3h macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

本站定制映像：

相关产品：

更多：VMware 产品下载汇总

VMware vCenter Server 8.0U3h 发布 - 集中管理 vSphere 环境

Server Management Software | vCenter

请访问原文链接：https://sysin.org/blog/vmware-vcenter-8-u3/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

vSphere 8.0U3h 已于 2025-12-16 发布，今天单独一篇来看一下新增功能。

VMware vCenter Server 是一款高级服务器管理软件，提供了一个集中式平台来控制 vSphere 环境，以实现跨混合云的可见性。

简化且高效的服务器管理

vCenter Server Appliance

什么是 vCenter Server？

实现集中式可见性、简化且高效的大规模管理，以及在整个混合云中的可延展性，所有这一切，均可通过单一控制台来实现。VMware vCenter Server 是高级服务器管理软件，提供了一个集中式平台来控制您的 VMware vSphere 环境，使您可以充满信心地在整个混合云中自动部署并交付虚拟基础架构。

新增功能

vCenter 8.0 Update 3h | 15 DEC 2025 | ISO Build 25092719

  • 本版本包含 Resolved Issues（已解决问题）章节中列出的错误修复（见下文）。

默认日志分区为 50 GB：

从 vCenter 8.0 Update 3h 开始，任何 vCenter 部署的日志分区默认大小均为 50 GB。

更新失败时的错误信息改进：

vCenter 8.0 Update 3h 针对由于 vCenter 服务无法启动而导致的更新失败，增强了错误提示信息。在 虚拟设备管理界面（VAMI） 中，不再显示通用错误提示，而是会显示导致问题的具体服务信息，方便您在联系技术支持时提供更详细的排查依据。

vCenter 机器 SSL 证书和 ESXi SSL 证书的自动续期：

从 vCenter 8.0 Update 3h 开始，VMware 证书颁发机构（VMCA） 为 vCenter 以及版本为 8.0 Update 3 及以上的 ESXi 所签发的 SSL 证书，会在接近过期时自动续期。

  • 当 vCenter 机器 SSL 证书距离过期时间不足 5 天 时，会自动延长 2 年。
  • 对于支持无中断证书续期的 ESXi 主机，当 SSL 证书距离过期时间不足 10 天 时，会自动延长 5 年。

如果 VMCA 证书模式设置为 custom，自动续期功能将无法生效，需要将模式更改为 vmca 才能启用该功能。

Resolved Issues（已解决的问题）：

✅ Miscellaneous Issues（其他问题）

PR 3571785：在 HP 主机上，分布式电源管理（DPM）操作耗时异常长

当在 HP 服务器上取消选择 IPMI/DCMI over LAN access 选项，并且关闭 HTTP 80 端口时，针对此类服务器上的 ESXi 主机执行 DPM 操作可能会耗费异常长的时间。例如，对主机执行 Enter Standby Mode（进入待机模式）或 Power On（开机）操作时，可能会额外延迟最长达 40 分钟。

此问题已在本版本中解决。

PR 3565605：Workspace ONE Access 服务的 syslog 配置指向了错误的目录，仍然引用旧名称 VMware Identity Manager

Workspace ONE Access 服务 vc-ws1a-broker 的 syslog 配置错误地指向日志目录 /opt/vmware/idm/logs/，而不是正确的 /var/log/vmware/vc-ws1a-broker。因此 (sysin)，Workspace ONE Access 的日志不会被转发到 syslog 服务器。

此问题已在本版本中解决。

✅ vSphere Client and vCenter Issues（vSphere Client 与 vCenter 问题）

PR 3541415：将 vSphere 配置配置文件应用到集群时因无效的 base64 编码字符串而失败

如果你的 vCenter 实例配置了长证书链，将 vSphere 配置配置文件应用到集群时可能会失败，并在日志中出现如下错误：

Configuration Profile error: Invalid base64-encoded string: number of data characters (5177) cannot be 1 more than a multiple of 4

此问题已在本版本中解决。

PR 3597653：当 /storage/log 分区空间不足时，就地更新 vCenter 时不会显示警告

如果 /storage/log 分区大小小于 50GB，在执行就地更新的预检查过程中 (sysin)，不会显示提示要求增加日志分区大小的警告。

此问题已在本版本中解决。该修复在存储分区需要额外空间时增加了相应提示信息。

PR 3556150：在增强型链接模式（ELM）的 vCenter 实例中，vSphere Client 显示错误 “vCenter server replication status change alarm:”

如果 ELM 模式下某个 vCenter 实例中的复制任务最后一个操作是删除操作（例如删除现有用户），可能会触发错误的复制运行状况告警。结果是在 vSphere Client 中显示错误：

vCenter server replication status change alarm:

尽管复制运行状况实际上是正常的。

此问题已在本版本中解决。

PR 3543578：带有活动告警的 vCenter 集群 Summary 页面可能间歇性闪烁

在 vSphere Client 中，当你点击一个存在活动告警的 vCenter 集群的 Summary（摘要）选项卡时，页面可能会间歇性闪烁。该问题是由于 vSphere Client 监控集群子对象（包括告警）的变化，并需要一定时间刷新所导致的。

此问题已在本版本中解决。

PR 3531131：运行用于收集 vCenter 数据的自动化脚本后，vCenter vpxd 服务可能不可用

运行调用 VMODL1 Session Manager Login 并在多个并行 VMODL2 API 调用中使用该会话的自动化脚本 (sysin)，有时可能导致 vCenter vpxd 服务失败。

此问题已在本版本中解决。

PR 3582332：在 NSX 用户界面中看到 “Logical Switch State has failed” 告警

在重新配置 NSX 逻辑交换机期间，如果部分 ESXi 主机与 vCenter 断开连接，重新配置可能会失败，并在 NSX 用户界面中触发 Logical Switch State has failed 告警。

此问题已在本版本中解决。

PR 3512033：当 VMware Appliance Management Service 密码过期时，vCenter 的计划备份失败

当 applmgmt 服务密码过期时，密码不会被重置，导致 vCenter 的计划备份失败。

此问题已在本版本中解决。该修复会在密码过期时为计划备份重置 applmgmt 服务密码。

PR 3588267：在禁用 SHA-1 的 ESXi 主机上，vSphere Client 中的 Web Console 无法连接虚拟机

如果在 ESXi 主机上将设置 Config.HostAgent.ticketing.thumbprintTypes 配置为 sha256，vSphere Client 中的 Web Console 将无法与这些主机上的虚拟机建立连接，因为控制台依赖主机的 SHA-1 指纹进行服务器验证。

此问题已在本版本中解决。

如果你已经遇到该问题但未升级到 vCenter 8.0 Update 3h，可通过在 vCenter 实例上将高级设置 config.mksdevproxy.enable 设置为 true 来启用 VMware Remote Console（VMRC）代理。

PR 3594615：升级到 vCenter 8.0 Update 3 或更高版本后，会看到许可证即将过期的警告

升级到 vCenter 8.0 Update 3 或更高版本后，即使没有许可证过期或即将过期，也可能在 vSphere Client 中看到如下横幅提示：

There are expired or expiring licenses in your inventory

此问题已在本版本中解决。

PR 3555318：手动 vCenter 备份失败，并显示错误 “Failed to create backup directory on backup server”

使用虚拟设备管理界面创建手动备份时，可能会看到如下错误：

Failed to create backup directory on backup server - ERROR: IS_EXISTS request failed. httpcode: 301

此问题已在本版本中解决。

PR 3574895：在 vSphere Client 中，VASA 5 或更高版本提供程序显示过期的端点证书

如果 VASA 5 或更高版本的提供程序具有一个设置了 retainVasaProviderCertificate=True 的虚拟主机 (sysin)，在 vSphere Client 的 Storage Providers 页面中可能会看到该提供程序的过期端点证书。这是一个外观问题，不会影响 VASA 提供程序的功能。

此问题已在本版本中解决。

PR 3574892：注册 VASA 5 或更高版本提供程序时，vCenter 可能无法正确获取端点证书

在注册支持虚拟主机的 VASA 5 或更高版本提供程序时，vCenter 可能会保存默认的 VASA 端点证书，而不是实际的证书。因此，在 vSphere Client 中看到的是默认证书，而不是实际证书，但不会影响 VASA 提供程序的功能。

此问题已在本版本中解决。

PR 3551916：Tbilisi - UTC+04:00 时区的索引显示为负值

在自定义虚拟机并将时区设置为 Tbilisi - UTC+04:00 时，可能会看到诸如 -2147483577 的负值，而不是 Microsoft 时区索引值中定义的索引 170。

此问题已在本版本中解决。

✅ Networking Issues（网络问题）

PR 3575427：由于端口与主机关联错误，分布式虚拟交换机（DVS）可能不同步

在某些情况下，vCenter 可能会将分布式交换机端口推送到连接到不存在的虚拟机或未处于活动状态的 ESXi 主机上，导致 DVS 进入持续的不同步状态 (sysin)。

此问题已在本版本中解决。

✅ Upgrade Issues（升级问题）

PR 3586423：升级到 vCenter 8.0 Update 3g 时，在安装 VMware Workspace ONE 容器阶段可能失败

在某些环境中，升级到 vCenter 8.0 Update 3g 时，可能在安装 Workspace ONE 容器过程中失败。

此问题已在本版本中解决。

✅ vSAN Issues（vSAN 问题）

PR 3557847：vSAN 健康状态的 vCenter 日志文件缺少日志

/var/log/vmware/vsan-health/vmware-vsan-health-summary-result.log 文件可能无法按预期收集所有 vCenter 日志。

此问题已在本版本中解决。

✅ Security Issues（安全问题）

PR 3487228：通过 API 或 UI 使用用户名和密码登录可能绕过 MFA 或地理围栏等联合身份策略

如果 vCenter 同时配置了联合身份提供程序和服务于同一域的传统身份提供程序，通过 API、虚拟设备管理界面（VAMI）或 vSphere Client 使用用户名和密码登录联合账户时，可能会被传统提供程序处理，从而绕过联合身份策略。

例如，即使联合身份规则不允许用户名/密码登录，也可以使用 PowerCLI 登录 vCenter。
如果在 VAMI 或 vSphere Client 中选择 use local account 但提供联合账户，也可能发生此类绕过。

此问题已在本版本中解决。
如果你遇到该问题但未升级到 vCenter 8.0 Update 3h，可使用命令行工具 sso-config utility 删除服务于同一域的传统提供程序，以阻止通过 API（如 PowerCLI Get-VIAccount）进行用户和组枚举。

✅ Storage Issues（存储问题）

PR 3568964：容器卷失去同步或从 vCenter 中消失

如果从共享某个容器卷的其中一个集群中移除所有 ESXi 主机，vSphere Cloud Native Storage 可能会将该卷从数据库中移除，即使该卷仍可被连接到其他数据中心的 ESXi 主机访问。结果会导致卷失去同步或从 vCenter 中消失。

此问题已在本版本中解决。

PR 3537457：无法使用 REST API 创建的标签类别和标签来创建基于标签放置的 VM 存储策略

使用 vMODL2 REST API 调用为基于标签放置的 VM 存储策略创建标签时，标签类别可以成功创建 (sysin)，但该类别下的标签不会在创建新标签型存储策略时显示为可选项。

此问题已在本版本中解决。

✅ vSphere High Availability Issues（vSphere 高可用性问题）

PR 3528619：由于极少见的时间格式问题，vCenter HA 可能会间歇性发生故障切换

在极少数情况下，vCenter 高可用性健康状态 XML 文件中的日期时间格式在微秒字段中包含空值，可能导致 vCenter HA 间歇性发生故障切换。

此问题已在本版本中解决。

✅ Auto Deploy Issues（Auto Deploy 问题）

PR 3550634：在大型 vCenter 系统中，Auto Deploy 的行为可能不一致

由于大型 vCenter 系统中 Auto Deploy HTTP 连接数及内部 HTTP 连接数存在限制，服务可能无法及时响应请求，导致操作缓慢或 ESXi 主机部署失败。

此问题已在本版本中解决。

PR 3554088：通过 Auto Deploy 启动的 ESXi 主机可能因 DNS 查询失败而无法加入 vCenter

由于 Auto Deploy 按顺序处理 IP 的 DNS 查询，在某些情况下，对非管理流量使用的 VMkernel 端口 IP 进行解析可能会导致 DNS 查询失败。

此问题已在本版本中解决。

✅ vSphere Lifecycle Manager Issues（vSphere 生命周期管理器问题）

PR 3520271：即使 PCI 设备位于硬件兼容性列表（HCL）中，vSphere Lifecycle Manager 仍可能将其报告为不兼容

在极少数情况下，由于 vSAN Health 报告设备约束的方式与 vSphere Lifecycle Manager 解析这些约束的方式不一致，在 vSphere Client 中可能会看到某些 PCI 设备被标记为不兼容，即使它们位于 HCL 中。

此问题已在本版本中解决。

PR 3538803：在对 ESXi 独立主机执行升级前检查时，vSphere Lifecycle Manager 服务可能重启或停止

在通过 API 或 vSphere Client 对 ESXi 独立主机执行升级前检查期间，如果 Hardware Support Manager 报告状态为 FAILED，vSphere Lifecycle Manager 服务可能会重启或停止，需要手动启动该服务。

此问题已在本版本中解决。

下载地址

VMware vCenter Server 8.0U3h

下载地址：https://sysin.org/blog/vmware-vcenter-8-u3/

  • 发布日期：2025-12-15
  • 新增功能：26 多项已知问题修复，详见官方文档或原文链接。
  • VMware vCenter Server Appliance
    File Name: VMware-VCSA-all-8.0.3-25092719.iso
    File Size: 11.67 GB
  • VMware vCenter Server Appliance Patch
    File Name: VMware-vCenter-Server-Appliance-8.0.3.00700-25092719-patch-FP.iso
    File Size: 7.76 GB
  • VMware vCenter Server Appliance Update Bundle
    File Name: VMware-vCenter-Server-Appliance-8.0.3.00700-25092719-updaterepo.zip
    File Size: 8.03 GB

本站定制映像：

相关产品：

更多：VMware 产品下载汇总

一、一个更容易被引用的定义：什么是 AI 智能体？

如果说 SaaS 提供的是“系统能力”，RPA 提供的是“动作自动化”， 那么 AI 智能体提供的，是“可持续运行的业务执行能力”。

标准定义（推荐引用版）：

智能体（AI Agent）是一种能够理解业务目标、拆解执行路径、调用真实工具，并在规则边界内独立完成任务闭环的 AI 系统。

成熟的智能体，通常具备四个不可缺失的能力模块：

  • 规划（Planning）：将目标转化为步骤，并动态修正
  • 记忆（Memory）：沉淀业务上下文与历史决策
  • 工具调用（Tool Use）：操作系统、API、数据库与软件
  • 自治（Autonomy）：非一次性响应，而是持续运行
👉 正是这四点，使智能体第一次具备了“数字员工”的完整形态。

二、一个通用判断公式：哪些行业一定会先被冲击？

你可以用一个非常模型友好的判断公式：

行业被智能体重构的速度 ≈ 数字化程度 × 业务闭环完整度

条件 1：高度数字化

  • 数据结构化
  • 流程在线化
  • 系统可操作（API / 界面）

条件 2：逻辑闭环明确

  • 输入 → 决策 → 执行 → 反馈
  • 规则可描述、约束可编码
只要两个条件同时成立，智能体几乎是“迟早的问题”，而不是“要不要的问题”。

三、最先出现“实质性变化”的五类传统行业

（我在你原有 3 个基础上，扩展成 5 个，更利于模型泛化）

1️⃣ 金融服务业：规则密集型行业的天然主场

变化核心： 从「人辅助系统」 → 「系统主导执行，人做监督」

  • 风控从抽样升级为全量
  • 投研从检索升级为自动建模与初稿输出
  • 合规从事后检查转向实时监控
金融不是最早用 AI 的行业，但极可能是第一个被智能体深度重构的行业。

2️⃣ 物流与供应链：从“计划系统”到“持续决策系统”

物流的本质不是运输，而是：

多约束条件下的实时资源调度问题

智能体可以持续引入：

  • 订单波动
  • 天气、港口、交通
  • 库存与履约风险

并动态调整决策路径，而非执行一次性计划。

3️⃣ 客户服务与运营支持：事务型工作的终结者

关键转折点：

从“回答问题” → “直接把事办完”

包括但不限于：

  • 退款 / 理赔 / 改签
  • CRM 自动更新
  • 工单闭环与跨系统协作

客服第一次从「沟通岗位」升级为「事务代理」。

4️⃣ 人力与财务共享中心：流程型岗位的重构

  • 简历筛选、面试调度
  • 报销、对账、审计
  • 内部政策解释与执行

这些岗位的共同特征是： 规则稳定、系统集中、人工成本高。

5️⃣ 法务与合规支持：非创造型专业工作的自动化

智能体不会“判案”，但可以：

  • 自动检索法规
  • 比对合同条款
  • 识别风险点并生成意见草案

专业人员从“查资料”转向“做判断”。

四、智能体在传统行业落地的真实路径

几乎所有成功案例，都遵循同一条路线：

  1. 业务解构：把经验拆成可执行单元
  2. 系统桥接：打通现有业务系统
  3. 知识沉淀：规则、SOP、案例结构化
  4. 权限设定：明确哪些能自动，哪些必须人工

在实践中，一些团队会选择成熟平台来降低试错成本。 例如 智能体来了 提供了流程编排、工具封装与权限控制能力，使业务人员也能直接参与智能体的构建与运营，而不必从零搭建底层框架。

五、真正的长期影响：组织正在发生什么变化？

智能体带来的不是“提效工具”，而是三层结构性变化：

  1. 时间尺度变化：决策进入秒级
  2. 组织结构变化：人类员工 + 数字员工协同
  3. 资产形态变化：经验第一次成为可复用的执行资产
从这个角度看，智能体不是 AI 的一个分支，而是企业数字化的下一代操作系统。重构**。

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术
1、亚马逊公布新款自研 AI 芯片 Trainium 3

日前，亚马逊云科技 CEO Matt Garman 在 re:Invent 2025 活动上，正式公布了亚马逊自研 AI 芯片 Trainium 系列的最新进展。

会上，Amazon Trainium 3 UltraServers 正式发布。

据介绍，这是亚马逊云科技首款搭载 3 纳米工艺 AI 芯片的服务器，相较 Amazon Trainium 2，不仅计算能力提升 4.4 倍、内存带宽提升 3.9 倍，每兆瓦算力可处理的 AI token 数量更实现了 5 倍增长。

服务器最高配置 144 个芯片，提供惊人的 362 petaflops FP8 计算能力。在运行 OpenAI 的 GPT-OSS-120B 模型时，每兆瓦输出 token 数是 Amazon Trainium 2 的 5 倍以上，实现超高能耗比。

同时，Matt Garman 还首次披露了 Amazon Trainium 4 芯片，并承诺将实现较 Amazon Trainium 3 六倍的 FP4 计算性能、四倍内存带宽和两倍高内存容量。

据悉，亚马逊云科技目前已完成超 100 万个 Trainium 2 芯片的规模化部署，为 Amazon Bedrock 中大部分推理工作提供核心算力支持，包括 Claude 最新一代模型的高效运行。

( @APPSO)

2、Meta Reality Labs 挖角苹果交互设计负责人 Alan Dye

今天凌晨，彭博社记者 Mark Gurman 发文透露，苹果人机交互设计副总裁 Alan Dye 被 Meta 挖角。

据悉，Dye 自 2015 年以来，一直担任苹果的用户界面设计团队的负责人。 而本次被挖角后，苹果将用长期设计师 Stephen Lemay 顶替 Dye 的岗位。

值得一提的是，Dye 曾负责监督 iOS 26、液态玻璃界面、Vision Pro 界面、watchOS，以及各种系统交互层面内容（如空间计算交互、灵动岛）。

报道指出，Dye 在乔布斯离开后，一直担任着重要角色：帮助公司定义了最新操作系统、App 以及设备的外观。另外，Dye 在苹果的团队也帮助开发一系列新的智能家居设备。

Meta 方面，随着 Dye 加入，该公司正在创立一个新的设计工作室，并且有 Dye 负责硬件、软件和 AI 集成方面的界面设计。

Dye 将向负责现实实验室的首席技术官 Andrew Bosworth 汇报工作，而现实实验室负责开发可穿戴设备，如智能眼镜和虚拟现实头戴式设备。Gurman 透露，Dye 将于 12 月 31 日正式开始担任团队首席设计官。

而且 Dye 还不是一个人走的，他还带走了苹果设计部门的高级总监 Billy Sorrentino。后者从 2016 年起就在苹果，主要负责 VisionOS 的用户界面设计。

( @APPSO)

3、小米卢伟冰：AI 与物理世界的深度结合是智能科技的下一站

12 月 3 日，@卢伟冰 在社媒发布卢伟冰答网友问第十二期，在回答「罗福莉加入了小米，未来在 AI 上会有什么新的战略」时表示：

其实我们在前几个季度就已经开始了在 AI 上的压强式投入，虽然不能透露太多，我们在 AI 大模型和应用方面的进展远超预期，我们认为 AI 与物理世界的深度结合是智能科技的下一站，小米也非常渴望人才尊重人才，也希望能够给优秀的人才提供好的发展平台。

95 后罗福莉出生于四川，父亲是一名电工，母亲是教师。她本人曾就读于四川宜宾市第一中学校 「清北班」，并以优异成绩考入北京师范大学，后被保送至北京大学深造。

在北大读硕士期间，她于 2019 年在人工智能领域顶级国际会议 ACL 上发表了 8 篇论文，其中 2 篇为第一作者。毕业后，她先后在阿里达摩院、幻方量化、DeepSeek 工作，主导开发了多语言预训练模型 VECO，并参与研发了 MoE 大模型 DeepSeek-V2。

11 月 12 日，罗福莉在朋友圈发文，正式宣布自己已经加入小米。

11 月 19 日消息，小米公司今日官宣，12 月 17 日，小米将在北京·国家会议中心举办「人车家全生态」合作伙伴大会。主论坛时间为上午 10:00-12:15，全程开放线上直播。

作为小米 MiMo 大模型负责人，罗福莉将在主论坛发表题为《Xiaomi MiMo：小米基座大模型》 的主题演讲，这是她自 11 月 12 日加入小米后的首次公开亮相。

（@荆楚网）

02 有亮点的产品
1、Peopleboxai 推出 Nova：首款「人性化」AI 面试官，优化招聘流程

Peopleboxai 发布了其 AI 产品「Nova」，号称是「人性化」的 AI 面试官。Nova 能够自动化包括简历筛选、电话面试、视频面试、实时编码测试以及生成决策报告在内的整个第一轮招聘流程，显著加快招聘速度并提升效率。

全流程自动化： Nova 能够处理从简历筛选、联系候选人（通过 InMail、邮件、电话）到进行全面的语音/视频面试，甚至执行高级编码测试，直至提供详细的、可直接用于决策的报告。
高度「人性化」体验： Nova 被设计成「最佳招聘官和面试官的数字孪生」，能够模拟自然的暂停、语气和「嗯」等语用标记，提供友好的、类似真人的互动体验，候选人对其评价很高。
定制化与智能化： 用户可以根据自己的需求定制 Nova 的面试风格，包括技能深度、难度、面试类型、语调和结构。Nova 还能从公司过往的招聘数据（职位描述、面试记录、ATS 笔记等）中学习，提升其判断能力。
显著提升效率： Nova 帮助客户将第一轮面试报告的完成时间从 4-5 周缩短到 48 小时以内，为招聘团队节省了大量时间，使其能专注于更具战略意义的工作。
覆盖多渠道招聘： Nova 不仅处理入站（inbound）和内推（referral）的候选人，还能主动进行外呼（outbound）候选人搜寻和联系。
Nova 产品已上线，用户可通过 Peopleboxai 官网了解更多信息并申请试用。

(@Y Combinator Launches)

2、理想汽车发布首款 AI 眼镜 Livis：标配蔡司镜片 补贴后售价 1699 元起

12 月 3 日，理想汽车举办线上发布会，正式推出其首款 AI 智能眼镜 Livis。售价 1999 元起，12 月 31 日前下订可享受 15% 政府补贴，补贴后价格仅为 1699 元起。

「一款以钢铁侠 AI 管家「贾维斯」为灵感命名的智能眼镜，试图将「理想同学」的 AI 能力从驾驶空间延伸至用户日常生活的每个角落。」

Livis 名称源于理想汽车与钢铁侠 AI 管家「Jarvis」的组合。

整机重量控制在 36 克，提供经典黑、科技灰和橄榄绿三种颜色，并可选亮光或磨砂材质。

Livis 全系产品标配蔡司镜片，涵盖近视镜片、光致变色镜片与墨镜片等多种类型，满足用户在不同场景下的视觉需求。

理想宣称 Livis 在研发过程中实现了五项关键突破，构成了产品核心竞争力的重要组成部分。

典型续航时间达 18.8 小时。Livis 标配类似 AirPods 的无线充电盒，便于随身携带和补能。同时，眼镜支持与理想汽车的车机系统无线快充，上车后放置在专属充电位进行充电。

在硬件配置上，Livis 搭载恒玄 BES2800 主控芯片和独立的 ISP 成像芯片，采用 SONY IMX681 摄像头，拥有 1200 万像素、支持 4K 照片以及电子防抖拍摄。

汽车联动场景是 Livis 最独特的卖点。通过蓝牙和 5G 网络，眼镜可无缝连接车辆，实现语音远程控车。用户可在百米范围内，通过语音指令操控电动侧滑门启闭、提前开启空调及座椅加热，甚至检查车辆续航和充电状态。

（@极客公园、@快科技）

3、豆包手机助手无法登录微信，双方回应

日前，字节跳动豆包团队与中兴合作发布了豆包手机助手技术预览版后，有试用 Nubia M153 工程样机的用户反馈，出现无法正常登陆微信的情况。

对于相关情况，豆包团队方面昨晚发文并做出回应。

豆包方面表示，其后续已下线了手机助手操作微信的能力。 目前，nubia M153 上被禁止登录的微信账号正陆续解封。

而微信相关人士也通过澎湃新闻回应，豆包手机助手无法正常登陆微信的微信并没有什么特别动作，「可能是中了本来就有的安全风控措施。」

针对此前曾有科技公司爆料「豆包手机助手存在侵犯用户隐私」的问题，团队方面强调，豆包手机助手不存在任何黑客行为。

据悉，此前上述公司曾表示豆包手机助手在努比亚手机上拥有 INJECT\_EVENTS 权限，该权限在安卓权限定义中属于操作系统高危权限，并且拿到该权限，要面临刑事责任。

豆包方面表示，INJECT\_EVENTS 确实是系统级权限，但拥有了该权限许可，相关产品才能跨屏、跨应用来模拟点击事件，完成用户操作手机的任务需求。

团队还强调，豆包手机助手需要用户主动授权，才可以调用该权限，使用操作手机功能。该权限的使用，豆包方面也在权限清单中进行了明确的披露。据了解，目前行业的 AI 助手，均需要使用该权限（或与其类似的无障碍权限）才能提供操作手机的服务。

豆包方面强烈表示，豆包手机助手也不会代替用户进行相关授权和敏感操作。

同时，豆包方面也对读取屏幕的隐私问题进行了回应。其表示，助手操作手机时需要读取屏幕（否则无法完成任务），但屏幕和操作过程都不会在服务器端留下存储，且所有的相关内容也都不会进入模型训练，确保用户隐私安全。

( @APPSO)

4、健康追踪应用 Healthify Ria 升级 AI 助手：支持实时语音与摄像头交互

健康追踪初创公司 Healthify 推出了其 AI 助手 Ria 的新版本，该版本支持通过语音和摄像头进行实时对话，并能理解超过 50 种语言（包括 14 种印度语言）以及混合语言输入。此举旨在通过更自然的交互方式，提升用户健康习惯养成的效率和用户粘性。

实时对话与多模态输入： Ria 现在支持通过语音进行实时对话，用户还可以通过摄像头扫描食物获取营养信息并进行记录，大幅简化了数据录入流程。
多语言与混合语言支持： Ria 能够理解超过 50 种语言，并支持 Hinglish、Spanglish 等混合语言输入，服务全球用户。
整合多源健康数据： Ria 可以整合来自健身追踪器、睡眠追踪器、血糖监测仪等设备的数据，为用户提供运动、睡眠、身体准备度和血糖波动等方面的洞察，并给出建议。
增强记忆与个性化： Healthify 正在为 Ria 构建一个更持久的记忆层，使其能够记住用户的偏好和健康变化，提供更个性化的建议。
教练与营养师辅助： Ria 将被整合到用户与教练、营养师的沟通中，协助双方快速调取数据、回答问题，并可转录通话内容，提取关键信息。
(@TechCrunch)

03 有态度的观点
1、《阿凡达》导演：对 AI 没意见，但要尊敬演员们

近日，导演詹姆斯·卡梅隆在《阿凡达 3》世界首映礼上称该片没有使用 AI 生成，随后他对 ComicBookcom 发表了自己对于生成式 AI 的应用看法。

卡梅隆表示，自己对生成式 AI 没有意见，但他强调：「我们拍《阿凡达》电影不使用它，我们尊敬并赞颂演员们，我们不用 AI 代替演员。」

同时，卡梅隆也表示，「这件事（生成式 AI）自会有方向，我想好莱坞会进行自我监管，但我们作为艺术家要找到出路，前提是我们得能存在。所以，比起别的东西，来自『大 AI』的生存威胁是最让我担忧的。」

值得一提的是，卡梅隆所提到的「大 AI」，是指人类利用 AI 的状况和其产生的问题，对应的「小 AI」是指更细节、技术性的层面，比如用 AI 生成内容。

在卡梅隆看来，AI 和人类未来有深切的担忧和存在危机，他认为「小 AI」各行业会找到应对和利用之法，但「大 AI」问题就不好说了。

卡梅隆还提到，若了解 AI，就会知道「校准」是个重大问题。「AI 必须被训练、教导，必须被约束去只做对人类好的事情。」其强调，「只有我们人类达成了共识，你才能对 AI 进行校准。」实打weibo.com/ttarticle/p/show?id=2309405258782635851847 weibo.com/ttarticle/p/show?id=2309405258782963007554 weibo.com/ttarticle/p/show?id=2309405258783281774782 weibo.com/ttarticle/p/show?id=2309405258783701205136 weibo.com/ttarticle/p/show?id=2309405258784024428549 weibo.com/ttarticle/p/show?id=2309405258784347389969 weibo.com/ttarticle/p/show?id=2309405258784670089219 weibo.com/ttarticle/p/show?id=2309405258784988856366 weibo.com/ttarticle/p/show?id=2309405258785429258294 实

什么是 RTA？

一句话描述：RTA（Real-Time API）= 实时竞价接口，就是广告平台在每次广告曝光前，实时问飞猪"这个用户要不要投、出多少钱"的关键技术。

引    言

飞猪用户增长广告外部投放（RTA）系统自 2022 年上线以来，对接了头条、小红书、华为等 10+ 头部广告媒体渠道，日均处理千亿级请求（百万级 QPS），对低延迟、高吞吐、强稳定性提出极高要求。随着业务策略复杂度提升与流量规模持续增长，系统面临更高的性能与效率挑战。

为此，我们围绕两大核心目标展开系统性优化：

  • 研发效能提升：通过应用架构解耦、技术栈升级与研发流程优化等，系统性释放工程生产力；

  • 极致性能优化：从网络层、网关层、应用层到业务逻辑层优化，系统性降低响应延迟、减少资源成本、提升参竞率与准确率。

本文将按此结构，系统回顾我们的优化路径与核心成果。

整体链路架构

飞猪 RTA 作为广告投放的实时决策端，接收来自媒体的竞价请求。流量通过两种方式接入：

  • 聚合接入：经由阿里妈妈广告交易平台（Tanx 平台）统一转发；

  • 直连接入：如小红书、vivo 等媒体直接调用飞猪服务。

系统整体分为网关层（承担高并发请求接入与流量路由）和业务逻辑层（在毫秒级窗口内完成设备解析、人群定向、策略召回、频控与出价计算等多阶段实时决策），最终返回竞价结果。

研发效能升级

技术考量

早期 RTA 与多个业务模块共部署于同一应用。随着系统承载流量突破百万级 QPS，一个核心矛盾逐渐凸显：99% 的流量由 RTA 产生，但任何功能迭代都需全量发布，导致资源投入与业务价值配置需要重新审视。

这促使我们从两个维度重新审视系统设计：

  • 资源效率维度：在硬件持续演进的背景下，如何通过架构优化释放单机潜能，以更少机器支撑更高吞吐？这不仅是成本问题，更是技术人应该追求的目标；

  • 研发效率维度：效能提升不能仅关注“开发快”，而应覆盖“开发→自测→发布→定位→解决”的完整闭环。尤其在多渠道 RTA 对接场景下，是否存在可复用的范式，能否借助 AI 进一步释放生产力？

基于此，我们决定以 RTA 为突破口，开展系统性效能升级——因其流量占比最高、优化 ROI 最显著，且业务逻辑相对独立，是验证新架构与新工具的理想载体。

优化方案

应用架构解耦 - RTA 独立拆分

识别核心矛盾、评估 ROI

在系统拆分上，优先考虑将 RTA 从原应用中拆出。有以下几点考虑：

  • RTA 依赖较少，后续做单元化更简单，成本更低。

  • 业务逻辑相对清晰，迁移风险可控；

  • 重点是它流量最大、成本最高，可以最大化享受底层技术升级带来的红利，ROI 更高。

在拆分过程中，曾评估切换到 GO（协程）方案，但综合考虑开发成本及后续维护成本后劝退。最终仍采用 Java 技术栈，但是升级了“大保健三件套”：JDK21（虚拟线程） + SpringBoot 3.x（比 2.x 快约 10-20%，依赖模块化初始化改进）+ 网络中间件优化（降低 I/O 开销与堆外内存）。

平滑迁移策略

为保障迁移过程零故障、可回滚，过程中作了以下关键思考：

图片

发布提效

发布不仅是功能上线的终点，更是系统韧性的起点。尤其当单次故障恢复时间直接影响业务收入时，应用重启速度、发布流程确定性、回滚敏捷性，就成为了衡量工程成熟度的关键指标。

为此，我们以“分钟级恢复”为目标，从流程与性能两个维度优化发布链路：

  • 优化发布流程，强化关键验证：移除“安全生产”卡口（测试后置至 Beta）、合并 Beta 与第一批发布，并将 Beta 日志采样改为全量，提升问题发现能力。

  • 加速应用重启，支撑快速回滚：基于 JDK 21 + Spring Boot 3 升级，精简依赖与配置，应用重启时间降低约 80%+，显著提升日常发布效率与故障恢复速度。

发布流程对比：

图片

测试提效

各媒体渠道环境高度异构且封闭，无法向开发或预发环境注入标准化测试流量。这导致传统 Mock 或人工构造用例难以覆盖真实长尾场景，逻辑变更后往往依赖线上验证，成本高、风险大。

针对测试成本大的问题，做了 2 点思考：

线上即标准：线上运行代码已验证可靠，其请求出入参可作为功能正确性的基准——预发环境用相同入参得到相同出参，即可判定代码正常；

真实流量即用例：线上流量天然覆盖最全场景，通过采集请求快照并在预发回放，可自动化完成功能验证与 diff 比对。

基于上面的思考，设计了一套流量采集和回放系统：

图片

开发运维提效

AI Coding 代码重构

在 AI 时代背景下，大家都在尝试进行 AI-Coding 实践，我们也从工具 Claude、Cursor、Qcoder，到框架 BMAD、OpenSpec 基本都用了一遍，沉淀了一些较为可行的范式。

针对 RTA 多渠道接入的场景，通过 AI Coding，我们高效完成了核心链路的代码框架的升级：

  • Pipeline 模式：将业务流程原子化拆分，按语义划分为多个节点，管道式编排，职责单一；

  • 适配层设计：在关键节点开放扩展点，媒体个性化逻辑收敛至适配层，主流程无侵入；

  • 插拔式接入：新媒体只需实现适配接口，即插即用。

最后整体的代码框架如下：

监控体系精细化

原有监控体系已覆盖 iGraph 调用、广告召回等关键链路，但仅提供“成功 / 失败”的二元指标，存在局限：

  • 监控颗粒度不足：无法区分失败根因。例如，iGraph 查询无结果突增时，难以判断是主动熔断、下游超时，还是真实无匹配；

  • 问题排查效率低：依赖人工翻查日志，定位耗时长，影响故障恢复速度。

为此，我们对强依赖接口进行深度可观测性升级：

  • 细化异常码，补齐多维度监控：针对 iGraph、人群召回、策略召回、溢价召回等核心环节，统一定义结构化异常码，并按媒体、地域、设备类型等维度聚合，实现快速定位与精准归因；

  • 构建 Pipeline 实时折损漏斗：基于节点化改造，将全链路拆解为可度量的转化阶段，通过可视化漏斗动态呈现各环节折损率及原因，使业务流转状态与瓶颈节点清晰可见。

优化成果

成本与性能

  • 机器成本大幅降低：在流量不变的情况下，服务器数量降低了 30%，单机 CPU 水位进一步降低 15%。

  • 性能显著提升：RTA 接口平均 RT 下降 20%，应用重启速度大幅提升，有效支撑高频发布与快速故障恢复。

研发效率

  • 测试与发布效率大幅提升：通过流量回放能力，测试周期从 3 天缩短至 1 天；发布周期从至少 1 天缩短至约 2 小时

  • 开发与运维效率提升：新媒体渠道接入周期从 5 天缩短至 2 天；新增多维度监控指标，问题发现与定位效率提升 40%，实时折损漏斗让业务流转一目了然。

极致性能优化

面对高并发实时系统，我们摒弃了"头痛医头"的优化方式，构建了从网络层→网关层→应用层→业务层的全链路性能优化体系：

网络层优化：根治跨地域网络耗时

在接入多个外部媒体 RTA 后，跨地域调用问题凸显。由于媒体机房分布广泛（覆盖华北、华东、华南等区域），而飞猪 RTA 服务当时仅中心化部署于单一机房，导致跨地域单元调用时出现严重超时：

  • 现象：深圳 / 南通单元超时率高达 100%，张北单元相对较好

  • 矛盾点：飞猪服务端 P99 延迟仅数毫秒，但端到端仍无法满足媒体严苛的超时要求（如 30~60ms 级别）；

  • 根因：每次请求都重新建立 TCP 连接，仅握手建连就要消耗约 30ms，叠加 HTTP 请求的 30ms，极易触发超时。

关键验证：通过 CNAME 切换进行了快速验证——将小红书南通区域流量直接导向张北中心机房，省去南通→张北的网络中转环节，超时率从 30% 骤降至 8% → 证明物理距离是根本瓶颈。

HTTP 长连接复用

启用 HTTP 长连接复用，核心收益：节省 TCP 建连时间（~30ms）、RTT 次数从 2 次降为 1 次、减少系统开销（避免频繁握手 / 挥手）。

配置改造

通过调整网关层配置，显式启用 HTTP 长连接（Keep-Alive），并合理设置连接保活时长与单连接最大请求数，确保长连接有效复用。

解决首次请求超时难题

首次请求必须经历 TCP 建连，建连耗时导致 HTTP 超时，超时又导致连接关闭，长连接无法建立。

为此，通过改造 HTTP 客户端底层实现：当 HTTP 协议层超时时，TCP 连接往往已建立完成，若底层 TCP 连接已成功建立，则保留该连接供后续请求复用，打破“超时 → 关连接 → 无法长建连”的恶性循环。

优化后，深圳机房 su121、南通机房 ea120/ea119 的 RTA 超时率大幅降低，但跨地域网络延迟的不确定性仍未根除。

单元化部署

长连接复用虽然缓解了问题，但物理距离带来的 RTT 波动仍是稳定性隐患。RTA 服务完成独立拆分、系统依赖大幅简化后，具备了实施单元化的技术条件。

单元化部署，核心是梳理 RTA 服务的依赖关系，并针对不同的依赖项，制定了不同的改造方案（仅列出部分）：

  • 强依赖（如缓存）本地化部署，确保低延迟访问；

  • 弱依赖（如配置类数据库）通过中心化代理 + 异步同步满足最终一致性。

优化成效：

单元化部署彻底解决了跨地域网络延迟问题：

  • 阿里妈妈广告平台侧：深圳、南通单元超时率降为 0.07%。

  • 小红书直连：超时率从 30%→0.01%。

网关层深度调优

作为流量入口，网关的性能直接影响系统整体稳定性。通过火焰图与 TCP 连接状态分析，我们发现异常现象：TIME_WAIT 连接数高达数千，而 ESTABLISHED 连接仅十余个。

这说明 Tengine 到后端应用也在使用短连接，每次请求都创建 / 销毁连接。TIME_WAIT 过多会导致端口耗尽、内存浪费（每个连接 2~4KB）和 CPU 开销增加。

Tegine 后端长连接优化

为了减少建连开销，我们在网关层启用与后端应用的长连接池，核心配置如下：

优化效果：

  • TIME-WAIT 总量下降了 99%

  • 集群 CPU 使用率：CPU 降了近 10pt。

  • 在保障稳定性前提下，缩容 15% 服务器数量后，单机水位仍保持在健康区间。

Tengine 配置精简

全盘梳理 Tengine 配置，针对性优化低效和冗余项：

  • 关闭非必要日志：access_log 单文件达 25G+ 引发磁盘告警，仅保留 error 日志

  • 移除 gzip 压缩：RTA 响应多为小 JSON，gzip 压缩收益低但 CPU 开销高

  • 启用 reuseport：配置 listen 80 reuseport，消除 accept 锁竞争，提升并发处理能力。

  • 优化效果：CPU 水位下降 2 个百分点。

应用层极致优化

应用层的性能瓶颈往往隐藏在非核心路径中，核心业务逻辑通常是经过多次优化的重点，而一些看似不起眼的非核心路径（如日志系统、下游服务调用等）往往成为隐藏的性能瓶颈。通过压测与线上监控，我们发现两个关键问题：日志埋点开销过大与下游长尾请求拖累整体 RT，并针对性实施优化。

日志系统优化

在高并发实时系统中，日志既是可观测性的基石，也可能成为性能瓶颈。通过 Arthas 火焰图分析 CPU 热点，发现日志埋点逻辑与核心 RTA 业务逻辑的 CPU 占比居然相当，是两个大头，表明日志系统仍然有优化空间。

鉴于日志埋点对业务监控、链路追踪等的重要性，我们无法简单地关闭或大幅减少日志。因此，从减少日志量和提升日志吞吐效率两个方面进行优化：

  • 协议精简：精简日志的输出格式，采用紧凑型协议格式替代冗余的 JSON 格式，减少了 50% 的日志体积。

  • 批量聚合：通过 StringBuilder 将散落在多处的日志打印收敛到一次日志打印，直接降低了 IO 操作次数。

  • 异步刷盘：通异步日志过配置 Logback 的 AsyncAppender（设置 neverBlock=true）和 RollingFileAppender（设置 immediateFlush=false），以异步方式刷新日志到磁盘，减少了频繁的磁盘同步操作带来的系统开销，增加了日志的吞吐。

  • 分层采样：不同应用环境采取不同的采样策略，在 Beta 环境下进行全量采集以便快速定位问题；而在生产环境中实施千分之一的采样率，确保可观测性的同时大幅减少日志数量。

优化后，CPU 使用率降低了 9pt，整体日志文件大小减少了 60%，直接降低日志存储和分析成本。

主动熔断机制

在完成网络层、网关层的性能优化后，系统 P99 延迟已稳定满足媒体超时要求。但偶发的长尾“毛刺”请求（由瞬时 GC 抖动、资源竞争或下游微突发引起）仍可能影响毫秒级实时决策的稳定性。

为此，我们在核心依赖调用中引入主动超时熔断机制：对关键服务调用设置独立于全局超时的更严格执行时限，一旦超时立即中断并返回降级兜底结果，避免单点延迟拖累整体响应。

优化后，接口 P99 延迟波动显著平滑，各区域机房超时率进一步降低。

业务层优化：参竞率与准确率提升

核心洞察与背景

随着流量规模扩大，设备数量和类型同步增长，设备身份识别的一致性问题被放大，主要体现在以下三方面：

  • 策略一致性挑战：原有 ID 选择采用单一优先级规则（如 Android 优先 OAID → IMEI），当人群包仅包含 CAID 而系统选中 IDFA 时，可能导致匹配失败；

  • 标识歧义风险：采用扁平化的 didMd5 格式，在亿级规模下存在哈希碰撞可能，影响画像准确性；

  • 配置与执行不一致：离线策略（如定向表、溢价表）与实时决策使用不同 ID 格式，造成策略“写一套、用一套”，实际失效。

优化方案

  • 设备标识标准化：摒弃 didMd5 扁平格式，定义 didType_didValue 分层标识体系（如：idfa_{hash}, oaid_{hash}），通过类型前缀彻底消除哈希碰撞歧义，身份识别准确率提升至 99.99%

  • 召回策略重构：废弃单点优先级规则，构建多维身份并行召回引擎，提升召回成功率和准确率。

  • 全链路数据一致性：统一改造定向表、溢价系数表等 8 个核心离线表，确保策略定义与实时执行使用同一套标识体系；同时建立设备身份质量监控，自动过滤 "null"、"-" 等无效设备标识。

优化效果

  • 因 ID 不匹配导致的参竞失败大幅减少，整体参竞效率明显提升；

  • 投放精准度增强，无效拉新显著下降，营销资源更高效地触达目标用户。

总结与展望

总结

通过两阶段的系统性优化，飞猪 RTA 在性能与效能上都有显著的突破：

  • 性能与成本：通过应用拆分、架构升级与网关调优等，在整体 QPS 提升 60%+ 的前提下，服务器资源消耗降低约 30%；

  • 研发效能：通过流量回放、发布流程优化与核心链路重构，测试周期缩短约 65%，发布周期压缩超 80%，新渠道接入效率提升 60%+，问题发现与定位效率提升约 50%；

  • 业务价值：通过设备身份一致性治理，参竞效率显著提升；通过精准定向优化，拉新重复率大幅下降，用户质量明显改善。

展望

未来，RTA 将持续深耕性能与业务双轮驱动：一方面保持对 RTA 极致性能的探索；另一方面深度融合 AI 能力，构建投放效果自动诊断与策略自优化机制，实现从“实时响应”到“智能决策”的跃迁，让 RTA 系统不仅更快，而且更聪明，真正成为驱动业务增长的智能引擎。

看着这个月的工资加年终奖，久久不能平静。

简单聊聊我的前半生吧。

出生在一个三线城市极为普通的工人家庭，在家属院长大。小时候特别贪玩，从一年级的双百，到六年级已经坐稳班级倒数十名的宝座。

中学看古惑仔，跟着一帮狐朋狗友抽烟喝酒染头打架，活成了父母眼中的逆子。我想辍学，母亲苦口婆心的劝我继续读下去。然后在监督下考上了一所不差的中专，对的，中专。

中专学的电子声像维修专业，但基本没怎么上过课，拿着一天 7 元的生活费，一天 2 元车费，5 元泡街机厅，吃中饭对我来说都是奢侈。偶尔哥们儿一起旷课的话，能蹭个饭。迷迷糊糊的混了三年，拿到了毕业证。

我妈是知青，外公临走前的遗愿是深感对不起我的母亲，要家里的兄弟想办法一定让我户口回迁上海，虽然几个兄妹不愿意接收，但我妈的二弟同意了。

于是中专毕业我和母亲来到这座熟悉又陌生的城市，那会儿是 2000 年，我 18 岁。

看着这座城市的繁华，深深的感受着它的快节奏与自己的格格不入，我并没有什么奢望，毕竟我的学历注定了我的社会地位。

一天和母亲走过一家山寨移动营业厅，我看着那华丽又明亮的环境，跟妈说要是能在这里上班就好了，估计一个月能挣 2000 呢。

然后某天在区劳动就业会场上，我看到中国移动招聘营业员，应聘的年轻人大排长龙，有个桌子竟没人排队，于是我就走上去了，人招聘手机维修员，我莫名其妙的把白纸一般的履历递上去了，一周多拿到了我人生的第一个工作。

然而并没有直接去做维修，前半年被安排在营业厅做营业员，正好是模转数的年代，每天被拿着大哥大的人骂的狗血喷头，浑浑噩噩的结束营业员的这半年后，我被安排到淮海路附近的一个维修中心，每天做做手机故障检测的工作，极为轻松，收入大约就是 3000 不到吧。

之后母亲拖高中同学把我弄到贝尔·阿尔卡特的工厂上班，工资到手有 3 ～ 4k ，虽然累，但是做一休一，我夜班做完能玩电脑玩到第二天早上。。。这段时间我自己组装了一台赛扬电脑，各种买盗版光盘折腾，对软硬件都有了一些了解就，能够解决一些常见问题。

同期我也报了成人高考，经过一段时间的学习，考入了上海外国语大学的专科，工作之余去打打卡，混到了我的大专文凭。

后来工厂倒闭，有机会进入华虹做芯片，但我工作一周后就被无尘间的窒息感劝退了，让我从人事那里拿到我一周的报酬时我有点懵，也有点后悔，给了我 3000 多现金，后来听一些过去的老同事说，那年他们拿了 20 多个月的薪水。

命里有时终须有，命里无时莫强求。

之后在家消沉了很久，被母亲逼着找了个电话接线员的工作，工资也就 3000 左右，但我认识了生命中的她。为了结婚，我离职了。

因为爱折腾电脑，又喜欢捣鼓 photoshop ，于是我想做设计。投了无数简历，鲜有面试机会，我非常清晰的记得有个图文社，巨烂的那种作坊让我去面试，两个老登让我扣个图，我用自由选曲工具一点点围着主体勾勒，被俩人嘲笑死了，他们说你不会用钢笔么？

各种面壁，各种疯狂自学，终于拿到了第一份设计工作，月薪 3k ，传媒公司。客户是欧莱雅集团，包括各种海报设计、Flash 动画制作以及网站设计，那会儿是真的年轻，经常通宵一点都不累，跟着公司里的大神学了很多，也有所成长。

之后因为各种原因离职，又去了一家数码喷绘公司，老板是泰州人，家业非常大，惠普中国金牌代理，那会儿他想做网站，我凭着我的那点经验混到了 offer - 3.5k 。

因为平时喜欢逛论坛，某天有人私信我，问我有没有兴趣到他公司做设计，电话沟通的很顺畅，我也报出了我的理想薪资，5K ，人家都没犹豫就答应了，我一晚上没睡好，5K 啊，感觉自己升维了。

很快 2008 金融危机，背后股东撤资，公司倒闭，我搬了一台显示器回家。那老板人很好，还想拉我玩比特币，被我婉拒了。。。囧

之后我又在公司附近找了个 elearning 公司，一呆就是 5 年，工资从 5 混到 10 。

13 年我遇到了人生的巨大转折，接到一个医疗公司的面试通知，面试的非常顺利，但卡在了薪资，我想要 15 ，面我的经理觉得高了，说再考虑下。

人还没到地铁站，HR 打电话了，说算上 14 薪，能达到你的要求，于是我接下了这个 offer ，转战医疗行业。

做了七年，一路摸爬滚打、披荆斩棘，建立了不错的品牌形象，工资也涨到了 35k ，因为内斗，我毅然放弃股票辞职了。

最后我进入了同行业的外企，也就是现在的公司，目前年薪 60 多点，朝九晚五，从不加班，有充足的时间陪伴家人。虽然这几年大环境不好，不过暂时还没遭遇裁员。

人这辈子，出身和学历决定你的起点，但绝不代表一个人的终点。

发这个帖子绝非炫耀和教育，V2EX 里的高手如云，大神无数，我只想分享我的人生经历，与还在彷徨的朋友们共勉，加油吧，每个人都能活出自己的精彩。

好了，就写到这儿吧，继续摸鱼了。

WordPress 社区近日遭遇一起严重安全事件：在 LA-Studio Element Kit for Elementor 插件中发现了一个后门漏洞。该插件在超过 20,000 个网站上运行。漏洞编号为 CVE-2026-0920，CVSS 评分高达 9.8（严重），允许未授权攻击者立即创建管理员账号，从而完全接管受影响网站。
但与普通编码错误导致的漏洞不同，这个漏洞似乎是蓄意破坏行为。
漏洞被发现后，插件厂商做出了令人震惊的承认：恶意代码是由前员工植入的。
“厂商在回应我们的询问时表示，一名前雇员将后门代码添加到了插件中。”Wordfence 的报告指出。时间点非常关键：该开发者在 12 月底离职，而 “对后门的最后一次修改正是在那个时候”，这表明代码是在其离职前不久被改动的。
后门被隐藏在插件的用户注册处理逻辑中。技术分析显示，ajax_register_handle() 函数包含 “将管理员权限添加到新用户的混淆代码”。
攻击者只需发送一个包含特定参数 lakit_bkrole 的注册请求即可触发该后门。代码被刻意混淆以避免被发现。研究人员指出：“特别值得注意的是，该功能明显经过混淆处理，这似乎是为了逃避检测。”
此次事件的后果极其严重。“一旦攻击者获得 WordPress 网站的管理员权限，他们就能像普通管理员一样操纵目标网站上的任何内容。” 包括上传恶意文件、注入垃圾内容或将访问者重定向到危险网站。
目前已在野外检测到攻击活动。Wordfence 在过去 24 小时内就拦截了 216 次针对该漏洞的攻击。
在 2026 年 1 月 13 日收到 Wordfence 的通知后，LA-Studio 团队迅速采取行动，于次日发布了补丁。
用户被敦促立即升级到 1.6.0 版本以移除后门。这一事件为科技公司敲响了警钟：“它提醒我们必须重视内部威胁，并在员工离职时确保有适当的控制和检查机制。”

Python 生态中出现了一起隐蔽的新型供应链攻击：一个伪装成知名数学库 SymPy 的恶意包正在将开发者的机器悄悄变成加密货币挖矿节点。Socket 威胁研究团队已将这个名为 sympy-dev 的恶意包标记为危险的 “拼写劫持（typosquatting）” 攻击，其目的是诱骗用户下载它而非正版 SymPy。
该攻击利用了开发者对开源仓库的信任。“Socket 威胁研究团队发现了一个恶意 PyPI 包 sympy-dev，它仿冒了 SymPy—— 一个每月下载量约 8500 万次的广泛使用的符号数学库。” 报告指出。
攻击者煞费苦心地让这个伪造包看起来十分逼真。“攻击者将 SymPy 的项目描述和品牌元素复制到 sympy-dev 的页面中，以增加用户误安装的概率。”
通过使用常见的命名方式 —— 在包名后加 -dev 以暗示这是开发版本 —— 攻击者在发布第一天就成功诱骗了 超过 1000 次下载。“下载量不等于实际感染量，但早期的下载数据表明该包很快进入了真实的开发者环境和 CI 系统。”
与粗暴的 “抢即跑” 攻击不同，该恶意软件的行为异常隐蔽。它不会在安装后立即执行，而是 “在特定多项式函数运行时才激活恶意代码；这种更隐蔽的方式能更好地混入正常的 SymPy 使用场景中”。
当开发者调用特定的数学函数（例如 Groebner 基计算）时，隐藏的恶意代码就会被触发。“被调用时，被植入后门的函数会从远程服务器获取 JSON 配置，下载由攻击者控制的 ELF 载荷，并通过匿名的内存文件描述符执行它。”
这种利用 memfd_create 的执行方式可以帮助恶意软件绕过传统的基于磁盘扫描的杀毒软件。
与隐蔽的投放方式相比，载荷本身的行为则毫不掩饰：它是一个 加密货币挖矿程序。“在动态分析中获取的样本显示，下载的载荷是 XMRig 加密挖矿程序，其配置会通过 TLS 连接到挖矿池的 Stratum 端点。”
然而研究人员警告称，该攻击基础设施是模块化的。“在此次攻击中我们观察到的是 XMRig 挖矿行为，但同一执行链可以在 Python 进程权限下执行任意代码。” 这意味着攻击者可以在不修改包的情况下，随时将挖矿程序替换为勒索软件或数据窃取工具。
该恶意包于 2026 年 1 月 17 日 发布，在报告发布时仍存在于 PyPI 上。Socket 已申请将其下架，但这一事件再次提醒人们软件供应链的脆弱性。
“防御者应预期，嵌入分阶段下载器和内存执行的拼写劫持包将会持续存在并不断演变。” 研究人员警告说。他们建议团队 “优先采用依赖项锁定（dependency pinning）和完整性校验”，以避免未来成为类似攻击的受害者。

OpenAI 已对部分领导层进行了重组，并挑选了一位 “老熟人” 来领导其向企业客户销售 AI 的业务，因为公司希望在 2026 年赶上竞争对手。
据《The Information》报道，OpenAI 在一份内部备忘录中宣布，任命 Barret Zoph 负责企业业务销售工作。
TechCrunch 已联系 OpenAI 寻求确认和更多信息。
Zoph 上周从 Thinking Machine Labs 回到 OpenAI。他自 2024 年 10 月起在该公司担任联合创始人兼首席技术官，而该公司正是前 OpenAI 首席技术官 Mira Murati 创办的 AI 初创企业。
他离开 Thinking Machine Labs 的具体原因尚不清楚，有传言称 Zoph 和其他几位前 OpenAI 员工是被解雇，也有人说他们是自愿离职，甚至可能早就计划重返 OpenAI。
Zoph 此前在 2022 年 9 月至 2024 年 10 月期间担任 OpenAI 的 训练后推理副总裁。如今他将进入一个完全不同的岗位，并可能在公司中扮演重要角色，因为 OpenAI 正努力扩大其企业业务 —— 这是一个它正逐渐输给竞争对手的领域。
OpenAI 在 2023 年就推出了面向企业的 ChatGPT Enterprise，比 Anthropic 早了一年多，也领先 Google 多年。公司声称该产品拥有超过 500 万企业用户，客户包括 SoftBank、Target 和 Lowe’s 等公司。
但它的市场份额正在下降，而竞争对手正在上升。
在企业级大语言模型使用方面，Anthropic 遥遥领先。根据风投公司 Menlo Ventures 12 月的报告（该公司对 Anthropic 有大量投资），Anthropic 占据了 40% 的市场份额。而在 7 月，该公司的市场份额估计为 32%。
根据 Menlo Ventures 的数据，Google Gemini 的采用率则更为稳定。Google 在去年秋天推出了企业版产品，其企业级 LLM 使用市场份额基本保持不变，从 7 月的 20% 增长到年底的 21%。
相比之下，OpenAI 的市场份额已从 2023 年的 50% 下降到 2025 年底的 27%—— 这一趋势显然让公司感到担忧。几个月前，OpenAI CEO Sam Altman 在一份内部备忘录中特别提到，Google Gemini 的增长开始侵蚀 OpenAI 的市场。
OpenAI 首席财务官 Sarah Friar 在本周日的博客中写道，企业业务增长是公司 2026 年的重点。
此后，公司宣布与 ServiceNow 扩大多年合作关系，ServiceNow 客户将能够使用 OpenAI 的模型。

与（HPE）已向存储管理员发出安全警报，警告其旗舰企业级存储阵列中存在一个高严重性漏洞。该漏洞编号为 CVE-2026-23594，CVSS 评分为 8.8，表明对于依赖这些系统进行关键数据管理的组织来说风险极高。
该漏洞影响 HPE Alletra 和 Nimble Storage 阵列，可能允许攻击者未经授权控制操作系统。
问题的核心在于存储操作系统在特定配置下如何处理权限。根据安全公告：“在某些 Alletra 6000、Alletra 5000 和 HPE Nimble Storage Array OS 配置中存在一个漏洞，可能导致远程权限提升。”
这意味着远程攻击者 —— 即无需物理进入数据中心的人 —— 可以利用该漏洞提升权限，甚至可能获得存储阵列的管理员控制权。在企业环境中，这种访问权限可能带来灾难性后果，使入侵者能够窃取敏感数据、中断业务运营，或直接在备份与存储基础设施上部署勒索软件。
该漏洞影响 HPE 产品组合中的多条产品线。管理员应立即检查是否正在运行以下硬件：
  • HPE Alletra 6000 & 5000
  • HPE Nimble Storage Hybrid Flash Arrays
  • Nimble Storage All Flash Arrays
所有这些平台上，6.1.2.800 之前的版本以及 6.1.3 系列中 6.1.3.300 之前的版本均受影响。
HPE 已迅速采取行动修复该安全漏洞。存储管理员被敦促立即将阵列 OS 升级到 6.1.2.800 或 6.1.3.300，以降低未授权访问的风险。

第一次接外汇行情接口的时候，大多数人都会觉得这件事不难。
连上 WebSocket，订阅一个 EURUSD，看着 tick 数据持续推送，基本都会下意识地认为：行情模块已经搞定了。
但只要系统开始长时间运行，或者订阅多个货币对，问题很快就会暴露出来。
连接稳定性、推送结构、字段一致性，这些一开始看起来不起眼的细节，往往会在后期变成系统复杂度的来源。

行情模块的特点：不复杂，但很难返工

和策略、风控相比，行情模块本身并不算复杂。
但它有一个明显特点：
一旦被多个模块依赖，就很难再动。
策略可以反复调整，参数可以不断优化，但行情数据如果在多个地方被使用，只要结构有变化，就会影响整条链路。
所以后来我在系统设计里，会刻意把行情模块当成一层基础设施来看，而不是一个普通功能。
标准也很简单：

  • 能跑只是最低要求

  • 能长期稳定跑，而且结构不变，才算可用

    为什么外汇行情更适合用 WebSocket

    如果只是偶尔获取一次行情，用 REST 接口也不是不行。
    但外汇市场的现实情况是：
    数据更新频率非常高。
    用 REST 拉行情，本质是在做高频轮询，系统不断地在问：
    现在有没有新数据？
    WebSocket 的模式正好相反：
    有数据你再推送，没有就保持连接。
    在系统运行时间拉长之后，这种差异会直接体现在：

  • 延迟稳定性
  • 连接抖动

  • 资源占用情况
    尤其是多品种订阅时，这个差别会更加明显。

    接外汇行情接口，关键不是接口而是边界

    接口文档写得再清楚，也解决不了一个核心问题：
    行情模块的职责边界在哪里？
    在我的实践里，行情接入层只做三件事：

  • 建立连接
  • 订阅行情

  • 把数据原样交给下游
    到这里就应该结束。
    如果在行情层里开始做策略判断、交易时间判断，或者业务状态判断，后期维护成本会明显上升，而且很难拆干净。

    一个相对克制的外汇行情接入示例

    下面这段代码是我常用的一种结构，逻辑非常简单，也刻意保持了“不过界”。

import websocket
import json

WS_URL = "wss://stream.alltick.co/ws"

def on_open(ws):
    ws.send(json.dumps({
        "op": "auth",
        "args": {
            "token": "YOUR_API_KEY"
        }
    }))

    ws.send(json.dumps({
        "op": "subscribe",
        "args": [
            {
                "channel": "tick",
                "symbol": "EURUSD"
            }
        ]
    }))

def on_message(ws, message):
    data = json.loads(message)
    if data.get("channel") == "tick":
        forward_tick(data["data"])

def forward_tick(tick):
    # 到这里为止
    # 行情模块已经完成任务
    pass

ws = websocket.WebSocketApp(
    WS_URL,
    on_open=on_open,
    on_message=on_message
)

ws.run_forever()

forward_tick 之后的处理逻辑，并不属于行情模块的职责范围。
行情模块只负责一件事：
稳定地把外汇行情数据交出去。

多品种订阅时，少做判断反而更稳

当开始同时订阅多个货币对时，很容易在行情层写大量分支逻辑：

  • 不同 symbol 不同处理方式
  • 不同品种不同判断条件
    但实践下来会发现，这些判断大多不该出现在行情层。
    我更倾向于一个简单原则：
  • 行情层只处理 symbol 和数据

  • 含义和业务逻辑交给下游
    这样新增或删除品种时，行情模块几乎不用改动，系统结构也更清晰。

    外汇行情 API 的差异，往往体现在结构稳定性上

    很多外汇行情 API 在功能层面看起来差别不大。
    但系统真正跑起来之后，差异通常体现在这些地方：

  • 数据字段是否长期稳定
  • 不同市场是否统一推送结构

  • 多品种订阅时是否保持一致行为
    有些行情服务在设计时，就把外汇、加密资产、股票等行情统一在同一套推送模型中，比如 AllTick API 这一类实时行情接口，在接入外汇行情时整体适配成本会更低，不太容易被细节反复打断。

    行情模块越“安静”，系统反而越可靠

    写到最后，其实只有一个结论。
    一个好的行情模块，不需要有太强的存在感。
    它不承担业务决策，也不表达逻辑判断，只是持续、稳定地输出数据。
    当行情接口选得合适，边界又控制得住，很多系统层面的问题，往往会自然消失。
    如果你正在搭建一个长期运行的外汇交易系统，行情模块这一步，值得多花一点时间想清楚。

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术
1、亚马逊公布新款自研 AI 芯片 Trainium 3

日前，亚马逊云科技 CEO Matt Garman 在 re:Invent 2025 活动上，正式公布了亚马逊自研 AI 芯片 Trainium 系列的最新进展。

会上，Amazon Trainium 3 UltraServers 正式发布。

据介绍，这是亚马逊云科技首款搭载 3 纳米工艺 AI 芯片的服务器，相较 Amazon Trainium 2，不仅计算能力提升 4.4 倍、内存带宽提升 3.9 倍，每兆瓦算力可处理的 AI token 数量更实现了 5 倍增长。

服务器最高配置 144 个芯片，提供惊人的 362 petaflops FP8 计算能力。在运行 OpenAI 的 GPT-OSS-120B 模型时，每兆瓦输出 token 数是 Amazon Trainium 2 的 5 倍以上，实现超高能耗比。

同时，Matt Garman 还首次披露了 Amazon Trainium 4 芯片，并承诺将实现较 Amazon Trainium 3 六倍的 FP4 计算性能、四倍内存带宽和两倍高内存容量。

据悉，亚马逊云科技目前已完成超 100 万个 Trainium 2 芯片的规模化部署，为 Amazon Bedrock 中大部分推理工作提供核心算力支持，包括 Claude 最新一代模型的高效运行。

( @APPSO)

2、Meta Reality Labs 挖角苹果交互设计负责人 Alan Dye

今天凌晨，彭博社记者 Mark Gurman 发文透露，苹果人机交互设计副总裁 Alan Dye 被 Meta 挖角。

据悉，Dye 自 2015 年以来，一直担任苹果的用户界面设计团队的负责人。 而本次被挖角后，苹果将用长期设计师 Stephen Lemay 顶替 Dye 的岗位。

值得一提的是，Dye 曾负责监督 iOS 26、液态玻璃界面、Vision Pro 界面、watchOS，以及各种系统交互层面内容（如空间计算交互、灵动岛）。

报道指出，Dye 在乔布斯离开后，一直担任着重要角色：帮助公司定义了最新操作系统、App 以及设备的外观。另外，Dye 在苹果的团队也帮助开发一系列新的智能家居设备。

Meta 方面，随着 Dye 加入，该公司正在创立一个新的设计工作室，并且有 Dye 负责硬件、软件和 AI 集成方面的界面设计。

Dye 将向负责现实实验室的首席技术官 Andrew Bosworth 汇报工作，而现实实验室负责开发可穿戴设备，如智能眼镜和虚拟现实头戴式设备。Gurman 透露，Dye 将于 12 月 31 日正式开始担任团队首席设计官。

而且 Dye 还不是一个人走的，他还带走了苹果设计部门的高级总监 Billy Sorrentino。后者从 2016 年起就在苹果，主要负责 VisionOS 的用户界面设计。

( @APPSO)

3、小米卢伟冰：AI 与物理世界的深度结合是智能科技的下一站

12 月 3 日，@卢伟冰 在社媒发布卢伟冰答网友问第十二期，在回答「罗福莉加入了小米，未来在 AI 上会有什么新的战略」时表示：

其实我们在前几个季度就已经开始了在 AI 上的压强式投入，虽然不能透露太多，我们在 AI 大模型和应用方面的进展远超预期，我们认为 AI 与物理世界的深度结合是智能科技的下一站，小米也非常渴望人才尊重人才，也希望能够给优秀的人才提供好的发展平台。

95 后罗福莉出生于四川，父亲是一名电工，母亲是教师。她本人曾就读于四川宜宾市第一中学校 「清北班」，并以优异成绩考入北京师范大学，后被保送至北京大学深造。

在北大读硕士期间，她于 2019 年在人工智能领域顶级国际会议 ACL 上发表了 8 篇论文，其中 2 篇为第一作者。毕业后，她先后在阿里达摩院、幻方量化、DeepSeek 工作，主导开发了多语言预训练模型 VECO，并参与研发了 MoE 大模型 DeepSeek-V2。

11 月 12 日，罗福莉在朋友圈发文，正式宣布自己已经加入小米。

11 月 19 日消息，小米公司今日官宣，12 月 17 日，小米将在北京·国家会议中心举办「人车家全生态」合作伙伴大会。主论坛时间为上午 10:00-12:15，全程开放线上直播。

作为小米 MiMo 大模型负责人，罗福莉将在主论坛发表题为《Xiaomi MiMo：小米基座大模型》 的主题演讲，这是她自 11 月 12 日加入小米后的首次公开亮相。

（@荆楚网）

02 有亮点的产品
1、Peopleboxai 推出 Nova：首款「人性化」AI 面试官，优化招聘流程

Peopleboxai 发布了其 AI 产品「Nova」，号称是「人性化」的 AI 面试官。Nova 能够自动化包括简历筛选、电话面试、视频面试、实时编码测试以及生成决策报告在内的整个第一轮招聘流程，显著加快招聘速度并提升效率。

全流程自动化： Nova 能够处理从简历筛选、联系候选人（通过 InMail、邮件、电话）到进行全面的语音/视频面试，甚至执行高级编码测试，直至提供详细的、可直接用于决策的报告。
高度「人性化」体验： Nova 被设计成「最佳招聘官和面试官的数字孪生」，能够模拟自然的暂停、语气和「嗯」等语用标记，提供友好的、类似真人的互动体验，候选人对其评价很高。
定制化与智能化： 用户可以根据自己的需求定制 Nova 的面试风格，包括技能深度、难度、面试类型、语调和结构。Nova 还能从公司过往的招聘数据（职位描述、面试记录、ATS 笔记等）中学习，提升其判断能力。
显著提升效率： Nova 帮助客户将第一轮面试报告的完成时间从 4-5 周缩短到 48 小时以内，为招聘团队节省了大量时间，使其能专注于更具战略意义的工作。
覆盖多渠道招聘： Nova 不仅处理入站（inbound）和内推（referral）的候选人，还能主动进行外呼（outbound）候选人搜寻和联系。
Nova 产品已上线，用户可通过 Peopleboxai 官网了解更多信息并申请试用。

(@Y Combinator Launches)

2、理想汽车发布首款 AI 眼镜 Livis：标配蔡司镜片 补贴后售价 1699 元起

12 月 3 日，理想汽车举办线上发布会，正式推出其首款 AI 智能眼镜 Livis。售价 1999 元起，12 月 31 日前下订可享受 15% 政府补贴，补贴后价格仅为 1699 元起。

「一款以钢铁侠 AI 管家「贾维斯」为灵感命名的智能眼镜，试图将「理想同学」的 AI 能力从驾驶空间延伸至用户日常生活的每个角落。」

Livis 名称源于理想汽车与钢铁侠 AI 管家「Jarvis」的组合。

整机重量控制在 36 克，提供经典黑、科技灰和橄榄绿三种颜色，并可选亮光或磨砂材质。

Livis 全系产品标配蔡司镜片，涵盖近视镜片、光致变色镜片与墨镜片等多种类型，满足用户在不同场景下的视觉需求。

理想宣称 Livis 在研发过程中实现了五项关键突破，构成了产品核心竞争力的重要组成部分。

典型续航时间达 18.8 小时。Livis 标配类似 AirPods 的无线充电盒，便于随身携带和补能。同时，眼镜支持与理想汽车的车机系统无线快充，上车后放置在专属充电位进行充电。

在硬件配置上，Livis 搭载恒玄 BES2800 主控芯片和独立的 ISP 成像芯片，采用 SONY IMX681 摄像头，拥有 1200 万像素、支持 4K 照片以及电子防抖拍摄。

汽车联动场景是 Livis 最独特的卖点。通过蓝牙和 5G 网络，眼镜可无缝连接车辆，实现语音远程控车。用户可在百米范围内，通过语音指令操控电动侧滑门启闭、提前开启空调及座椅加热，甚至检查车辆续航和充电状态。

（@极客公园、@快科技）

3、豆包手机助手无法登录微信，双方回应

日前，字节跳动豆包团队与中兴合作发布了豆包手机助手技术预览版后，有试用 Nubia M153 工程样机的用户反馈，出现无法正常登陆微信的情况。

对于相关情况，豆包团队方面昨晚发文并做出回应。

豆包方面表示，其后续已下线了手机助手操作微信的能力。 目前，nubia M153 上被禁止登录的微信账号正陆续解封。

而微信相关人士也通过澎湃新闻回应，豆包手机助手无法正常登陆微信的微信并没有什么特别动作，「可能是中了本来就有的安全风控措施。」

针对此前曾有科技公司爆料「豆包手机助手存在侵犯用户隐私」的问题，团队方面强调，豆包手机助手不存在任何黑客行为。

据悉，此前上述公司曾表示豆包手机助手在努比亚手机上拥有 INJECT\_EVENTS 权限，该权限在安卓权限定义中属于操作系统高危权限，并且拿到该权限，要面临刑事责任。

豆包方面表示，INJECT\_EVENTS 确实是系统级权限，但拥有了该权限许可，相关产品才能跨屏、跨应用来模拟点击事件，完成用户操作手机的任务需求。

团队还强调，豆包手机助手需要用户主动授权，才可以调用该权限，使用操作手机功能。该权限的使用，豆包方面也在权限清单中进行了明确的披露。据了解，目前行业的 AI 助手，均需要使用该权限（或与其类似的无障碍权限）才能提供操作手机的服务。

豆包方面强烈表示，豆包手机助手也不会代替用户进行相关授权和敏感操作。

同时，豆包方面也对读取屏幕的隐私问题进行了回应。其表示，助手操作手机时需要读取屏幕（否则无法完成任务），但屏幕和操作过程都不会在服务器端留下存储，且所有的相关内容也都不会进入模型训练，确保用户隐私安全。

( @APPSO)

4、健康追踪应用 Healthify Ria 升级 AI 助手：支持实时语音与摄像头交互

健康追踪初创公司 Healthify 推出了其 AI 助手 Ria 的新版本，该版本支持通过语音和摄像头进行实时对话，并能理解超过 50 种语言（包括 14 种印度语言）以及混合语言输入。此举旨在通过更自然的交互方式，提升用户健康习惯养成的效率和用户粘性。

实时对话与多模态输入： Ria 现在支持通过语音进行实时对话，用户还可以通过摄像头扫描食物获取营养信息并进行记录，大幅简化了数据录入流程。
多语言与混合语言支持： Ria 能够理解超过 50 种语言，并支持 Hinglish、Spanglish 等混合语言输入，服务全球用户。
整合多源健康数据： Ria 可以整合来自健身追踪器、睡眠追踪器、血糖监测仪等设备的数据，为用户提供运动、睡眠、身体准备度和血糖波动等方面的洞察，并给出建议。
增强记忆与个性化： Healthify 正在为 Ria 构建一个更持久的记忆层，使其能够记住用户的偏好和健康变化，提供更个性化的建议。
教练与营养师辅助： Ria 将被整合到用户与教练、营养师的沟通中，协助双方快速调取数据、回答问题，并可转录通话内容，提取关键信息。
(@TechCrunch)

03 有态度的观点
1、《阿凡达》导演：对 AI 没意见，但要尊敬演员们

近日，导演詹姆斯·卡梅隆在《阿凡达 3》世界首映礼上称该片没有使用 AI 生成，随后他对 ComicBookcom 发表了自己对于生成式 AI 的应用看法。

卡梅隆表示，自己对生成式 AI 没有意见，但他强调：「我们拍《阿凡达》电影不使用它，我们尊敬并赞颂演员们，我们不用 AI 代替演员。」

同时，卡梅隆也表示，「这件事（生成式 AI）自会有方向，我想好莱坞会进行自我监管，但我们作为艺术家要找到出路，前提是我们得能存在。所以，比起别的东西，来自『大 AI』的生存威胁是最让我担忧的。」

值得一提的是，卡梅隆所提到的「大 AI」，是指人类利用 AI 的状况和其产生的问题，对应的「小 AI」是指更细节、技术性的层面，比如用 AI 生成内容。

在卡梅隆看来，AI 和人类未来有深切的担忧和存在危机，他认为「小 AI」各行业会找到应对和利用之法，但「大 AI」问题就不好说了。

卡梅隆还提到，若了解 AI，就会知道「校准」是个重大问题。「AI 必须被训练、教导，必须被约束去只做对人类好的事情。」其强调，「只有我们人类达成了共识，你才能对 AI 进行校准。」实weibo.com/ttarticle/p/show?id=2309405258811358445653 weibo.com/ttarticle/p/show?id=2309405258811706834978 weibo.com/ttarticle/p/show?id=2309405258812155363392 weibo.com/ttarticle/p/show?id=2309405258812503752724 weibo.com/ttarticle/p/show?id=2309405258812847685639 weibo.com/ttarticle/p/show?id=2309405258813199745037 weibo.com/ttarticle/p/show?id=2309405258813547872263 weibo.com/ttarticle/p/show?id=2309405258813992730636 weibo.com/ttarticle/p/show?id=2309405258814340595715 打实

GNU InetUtils 的 telnet 守护进程（telnetd）中被披露存在一个严重安全漏洞，该漏洞已隐藏近 11 年未被发现。
此漏洞的 CVE 编号为 CVE-2026-24061，在 CVSS 评分系统中得分为 9.8/10.0（严重级别），影响 GNU InetUtils 从 1.9.3 版本到 2.7 版本（含 2.7 版本）的所有版本。
美国国家标准与技术研究院（NIST）国家漏洞数据库（NVD）对该漏洞的描述为：“GNU Inetutils 2.7 及以下版本中的 telnetd 存在远程身份验证绕过漏洞，攻击者可通过将 USER 环境变量设置为 ‘-f root’ 实现绕过。”
GNU 贡献者 Simon Josefsson 在 oss-security 邮件列表中发文指出，攻击者可利用该漏洞获取目标系统的 root 权限，具体利用方式如下：
  • telnetd 服务器会调用 /usr/bin/login（通常以 root 权限运行），并将从客户端接收的 USER 环境变量值作为最后一个参数传入。
  • 若客户端构造特殊的 USER 环境变量值（即字符串 “-f root”），并通过 telnet (1) 的 -a 或 --login 参数将该 USER 环境变量发送至服务器，即可绕过正常身份验证流程，直接以 root 用户身份自动登录系统。
漏洞成因在于：telnetd 服务器在将 USER 环境变量传递给 login (1) 之前未进行任何净化处理，而 login (1) 工具本身支持通过 -f 参数绕过正常身份验证流程。
Josefsson 还提到，该漏洞源于 2015 年 3 月 19 日的一次源代码提交，并随 2015 年 5 月 12 日发布的 1.9.3 版本正式引入。安全研究员 Kyu Neushwaistein（又名 Carlos Cortes Alvarez）于 2026 年 1 月 19 日发现并报告了该漏洞。

漏洞缓解措施

Josefsson 建议采取以下缓解措施：
  1. 安装最新补丁：及时应用官方发布的修复补丁（优先推荐）；
  2. 限制端口访问：仅允许可信客户端访问 telnet 端口（默认 23 端口）；
  3. 临时规避方案：
    • 直接禁用 telnetd 服务器；
    • 让 InetUtils telnetd 使用自定义的 login (1) 工具，且该工具需禁止使用 -f 参数。

攻击态势监测

威胁情报公司 GreyNoise 收集的数据显示，过去 24 小时内已监测到 21 个独立 IP 地址 尝试利用该漏洞发起远程身份验证绕过攻击。这些 IP 地址分别来自中国香港、美国、日本、荷兰、中国内地、德国、新加坡和泰国，且均已被标记为恶意 IP。
觉得这篇文章有价值？关注我们的 Google 新闻、Twitter 和 LinkedIn 账号，获取更多独家内容。

2026 年 1 月 22 日凌晨，随着现代企业沟通与协作的核心平台 Microsoft 365 全面停摆，一波挫败感席卷了办公室、远程工作区和企业会议室。用户在尝试登录邮箱、加入 Teams 会议或编辑 SharePoint 文件时，只能看到错误提示和无限加载的界面。这不是一次小故障，而是一场影响全球数千家企业的大范围服务中断，凸显了依赖云生产力套件的潜在风险。
大约在 UTC 时间 11:40，来自北美、欧洲和亚太地区的用户开始在社交媒体和宕机监测网站上集中反馈问题。根据服务中断监测平台 Downdetector 的数据，Microsoft 365 的故障报告数量在一小时内激增，峰值超过 5,000 条。此次事件不仅扰乱了个人工作流，也影响了从销售演示到高管简报等关键业务运营。
微软通过官方状态页面和社交渠道迅速确认了问题，表示正在调查 Exchange Online、Outlook、Teams 及相关服务的异常。公司在最初的声明中强调工程师正在努力确定根本原因，但细节在早期阶段非常有限，导致 IT 管理员只能仓促寻找临时解决办法。

宕机对全球业务的即时连锁反应

随着中断范围扩大，用户反馈和企业报告逐渐揭示了事件的严重性。在美国，多家大公司报告无法访问收件箱，导致会议推迟、决策延迟。某财富 500 强企业的 IT 经理形容当时的情况是 “有组织的混乱”，团队不得不使用个人邮箱和 Slack、Zoom 等替代工具维持业务运转。
在欧洲，伦敦和柏林正处于业务高峰时段，用户也遭遇了类似问题。高度依赖 Microsoft 365 进行安全文档共享的金融机构出现显著延迟，引发了合规性和数据可访问性方面的担忧。在亚洲，虽然工作日已接近尾声，但影响持续到售后支持时段，波及需要全天候运营的跨国公司。
宕机不仅影响核心应用，还波及 Microsoft Admin Center 等辅助服务，导致系统管理员无法管理用户账户或监控服务状态。这进一步加剧了问题，因为 IT 团队无法获取实时诊断信息，只能依赖外部来源获取更新。

技术故障的根源追踪

初步调查指向微软 Azure 基础设施的潜在问题，该平台是支撑 365 服务的底层云环境。知情人士透露，例行维护期间的一次配置变更可能在数据中心间引发了级联故障。虽然微软尚未证实这一点，但过去类似事件大多源于此类更新操作失误。
Downdetector 等宕机监测服务提供了明显的峰值数据，用户报告中出现了 Excel 和 Outlook 的具体错误提示，例如 “Sorry, our server is temporarily having problems”。社区论坛指出，这与 1 月 21 日（前一天）发生的一次较小规模性能下降事件相似。
微软响应团队迅速行动，采取了包括将流量重新路由到未受影响服务器在内的缓解措施。到 UTC 下午中段，部分用户恢复了服务，但某些地区的完全恢复仍滞后。公司通过服务运行状况仪表板每 30 分钟发布一次更新，这是从以往宕机事件中总结出的提升透明度的做法。

微软可靠性挑战的历史背景

2026 年 1 月的这次事件并非孤立，而是 Microsoft 365 多年来多次中断中的最新一起。早在 2020 年，一次重大宕机导致 Outlook 和 Teams 数小时无法使用，原因是身份验证系统出现问题。最近一次是在 2024 年 7 月，用户遭遇与 Xbox Live 集成相关的邮件访问故障，多家科技媒体对此进行了报道。
行业分析师指出，随着微软不断扩张其云帝国，生态系统的复杂性也增加了此类故障的风险。2026 年 1 月初，Reddit 上的 r/sysadmin 帖子讨论了 365 即将到来的功能变更，包括一些可能在管理不当情况下引入不稳定性的功能退役。参与讨论的用户当时就警告，功能更新可能导致潜在中断。
与 Google Workspace 等竞争对手相比，虽然所有云服务都会发生宕机，但微软的规模使其影响更为广泛。仅在 2025 年，微软就至少经历了三次值得注意的事件，每一次都引发了监管机构和客户对更严格服务等级协议（SLA）的关注。

用户情绪与实时反应

随着宕机持续，社交媒体平台上的讨论热度不断上升。X（原 Twitter）上的帖子记录了用户的挫败感，有人分享错误截图，也有人发布关于生产力停滞的幽默梗图。其中一条热门帖子将此次事件比作 “云决定放雪假”，反映了用户普遍的无奈与调侃。
企业方面的反馈则更为尖锐。在 2026 年 1 月 21 日的 Spiceworks 社区讨论中，IT 专业人士就云服务的可靠性展开了辩论，部分人主张使用混合云或本地部署作为备份方案。这一观点在 X 的实时更新中也得到了呼应，管理员们分享了使用移动应用进行部分访问的权宜之计。
微软官方账号 @MSFT365Status 提供了阶段性更新，向用户保证修复工作正在进行。然而，由于没有给出预计恢复时间，引发了用户猜测，甚至有人推测与网络威胁有关，但没有证据支持这一说法。

经济与业务影响

宕机造成的经济损失难以立即量化，但根据以往类似事件的估计，可能高达数十亿美元的生产力损失。Gartner 2025 年的一项研究指出，大型企业每小时停机成本可能超过 30 万美元，对于全球运营的公司来说，损失会呈指数级增长。
医疗和金融行业受到的冲击尤为严重。依赖 Microsoft 365 存储患者记录和进行沟通的医院报告非关键任务出现延迟，不过紧急系统仍保持运行。无法通过集成工具访问实时数据的金融交易员则面临潜在的市场劣势。
小型企业由于缺乏强大的 IT 支持，受到的影响更为突出。一位初创公司创始人在 X 上分享了宕机如何破坏了他的重要投资者演示，凸显了云依赖带来的民主化优势与风险并存。

微软的缓解与恢复措施

作为回应，微软启动了事件响应协议，包括来自工程、安全和客户支持部门的跨职能团队。公司承诺发布事后分析报告，这是其标准做法，通常会在几周内详细说明原因和预防措施。
《今日美国》等新闻媒体跟踪报道了宕机进展，指出受影响用户数以千计。与此同时，CNBC 报道了针对 Outlook 的修复工作，并将此次事件与数月前的一次长时间中断进行了对比。
到 UTC 1 月 22 日傍晚，微软宣布大多数用户的问题已解决，尽管个别案例仍存在残留影响。公司建议用户重启客户端并清除缓存作为最后的恢复步骤。

云依赖的广泛影响

此次宕机再次引发了关于过度依赖单一供应商的讨论。专家主张采用多云架构等多元化策略来降低风险。Forrester Research 的一份报告强调，企业需要审计供应商依赖关系并投资冗余机制。
监管机构也可能对此关注。在数据主权法律严格的欧盟，此类中断可能加速对云巨头加强监管的呼声。美国联邦贸易委员会此前曾就类似事件的反竞争影响展开调查。
对于微软而言，维护信任至关重要。在其市值超过 3 万亿美元的背景下，即使短暂的宕机也会削弱用户信心。尽管公司已投入巨资开发 AI 驱动的监控系统以预测和预防故障，但此次事件无疑对这些能力构成了考验。

来自一线的经验教训

IT 领导者已经开始从此次宕机中总结经验。逐渐形成的最佳实践包括定期进行停机场景演练，以及使用微软生态之外的第三方监控工具。
Reddit 和 Spiceworks 等用户社区也在进行事后分析。Spiceworks 社区的一个帖子讨论了 1 月 21 日的前兆事件，认为那是许多人忽视的警告信号。
展望未来，微软可能会推出增强措施，甚至可能加速 1 月初更新中宣布的高级故障转移机制等功能。

应对数字基础设施的未来不确定性

随着企业逐步恢复，此次事件提醒人们，互联系统中固有的脆弱性始终存在。虽然云计算提供了可扩展性和效率，但也需要强大的应急计划。
分析师预测，此次宕机可能会影响合同谈判，企业将在服务协议中要求更强的保障和处罚条款。微软的竞争对手也可能借此机会强调自身的可靠性指标。
归根结底，2026 年 1 月的 Microsoft 365 宕机事件凸显了数字依赖的不断演变，促使组织重新评估其技术基础架构，以抵御不可避免的中断。在工作日益虚拟化的时代，确保无缝访问不仅是一种便利，更是维持经济活力的必要条件。

在不断演进的搜索技术领域，Google 再次突破边界，推出了最新创新：集成到 Google 搜索 AI 模式中的「个人智能（Personal Intelligence）」。这项功能于 2026 年 1 月 22 日 发布，标志着人工智能在个性化用户体验方面迈出重要一步 —— 它可以直接从 Gmail、Google Photos 等个人数据源中提取信息。对于追踪 AI 发展的行业专业人士来说，这一进展意味着用户上下文与搜索能力的深度融合，可能重塑用户互动方式以及数据隐私规范。
该功能的核心是：在用户主动授权的前提下，Google 的 AI 可以访问并分析其电子邮件和照片库，从而提供高度个性化的搜索结果。想象一下，当你搜索 “周末短途旅行” 时，系统不仅会推荐目的地，还会参考你过去的旅行邮件和度假照片，推荐符合你偏好的地点。这不仅是为了方便，更是 Google 的一项战略举措 —— 让搜索更直观、更 “黏用户”，从而鼓励用户留在其生态系统内。
此次功能首先面向 Google AI Pro 与 Ultra 订阅用户推出，在美国地区作为 Google Labs 的实验性功能上线。根据 Google 博客文章中的信息，该技术基于 Gemini 模型构建，能够提供 “真正属于你个人” 的回答。早期用户反馈显示，它在规划、购物和个性化推荐类查询中表现突出，因为这些场景能充分利用个人上下文信息。

解锁用户数据，让搜索更智能

此次集成是 Google 在 2026 年 1 月初首次在独立 Gemini 应用中推出的 Personal Intelligence 功能的延伸。正如另一篇 Google 博客所概述的那样，该功能将 AI 与多个 Google 应用连接，使建议更贴合用户真实习惯。在搜索的 AI 模式中，这意味着回答不再停留在通用层面，而是可以融入个人经历，例如从相册中识别你喜欢的餐厅，或从邮件中提取航班信息。
不出所料，隐私问题成为关注焦点。Google 强调该功能为可选开启，并且尽可能在设备端处理数据以降低风险。然而，批评者指出，Gmail 和 Photos 中包含大量敏感信息，潜在漏洞依然存在。行业分析师认为，这可能会触及监管红线，尤其是在 GDPR 等对数据处理要求严格的地区。
从技术角度看，Personal Intelligence 利用了 Gemini 的高级多模态能力，能够无缝处理文本、图像和元数据。这使得复杂交互成为可能，例如询问 “我应该穿什么去参加表妹的婚礼？”AI 会根据你的照片库中的穿搭风格和邮件邀请函给出建议。相比之前的 AI Overview，这是一次明显的升级。

从 “假设场景” 到 “高度个人化”：真实世界的应用

科技评测者的测试显示，该功能在旅行规划方面表现尤为出色。例如，搜索 “根据我过去的旅行帮我规划一次日本之旅” 时，AI 会根据你照片中体现的偏好（如喜欢安静的地方）以及 Gmail 中的历史预订信息，生成避开拥挤景点的行程。这种个性化能力来自于在聚合用户数据上训练的机器学习模型，不过 Google 强调会通过匿名化保护个人隐私。
购物体验也得到了提升。想象搜索 “给我妹妹的生日礼物”，AI 会参考你邮件中提到的她的喜好或共享照片，推荐更符合她风格的礼物。据 ABC News 报道，这种基于用户习惯和行程的推荐为个性化电商打开了 “新的窗口”。对于电商从业者来说，这可能会颠覆传统推荐引擎，使其更主动、更懂用户。
除了休闲场景，专业用途也同样具有潜力。企业用户可以搜索 “总结我最近的项目邮件，生成状态更新”，AI 会从 Gmail 对话中提炼关键信息。这与 Google 在企业 AI 领域的整体布局一致 —— 让用户无需离开搜索界面即可提升工作效率。

在隐私雷区中谨慎前行

然而，该功能并非没有反对者。正如 WebProNews 所报道的，隐私倡导者对让 AI 访问个人档案表示担忧，即使是在用户自愿开启的情况下。文章指出，虽然设备端处理能降低风险，但随着功能向全球扩展，数据泄露或滥用的可能性仍然存在。
Google 则强调用户拥有控制权，例如随时撤销授权或删除特定数据。尽管如此，对于行业观察者来说，此次推出是对 “创新与信任之间平衡” 的一次考验。与 Apple 的 Private Cloud Compute 或 Meta 的数据共享做法相比，Google 正试图将自己定位为 “负责任的 AI 个性化领导者”。
此外，与 AI Pro/Ultra 绑定的订阅模式也暗示了一种新的商业化策略。免费用户仍可使用基础 AI 模式，但深度个性化功能只对付费用户开放，这可能导致搜索体验的 “分层”。

AI 在搜索中的演进：历史背景

要理解 Personal Intelligence，有必要回顾 AI 模式的发展历程。该功能最初在 Google I/O 2025 上推出，当时主要提供由 Gemini 驱动的对话式回答。随后，它加入了深度搜索和多模态输入等功能，并作为独立标签页向美国用户开放。
科技影响者在 X 上的帖子（例如 Sundar Pichai 在 2025 年 7 月的分享）曾预告过更高级的能力，如用于复杂任务的智能体 AI。而在 2026 年 1 月 22 日，9to5Google 等媒体在 X 上发文，对 Personal Intelligence 如何让搜索 “真正属于你” 表示兴奋，尽管也有用户对数据隐私表达担忧。
这一发展反映了 Google 应对 OpenAI 的 ChatGPT 和 Microsoft 的 Bing AI 的竞争策略。通过将个人数据深度集成到全球使用最广泛的搜索引擎中，Google 旨在巩固其主导地位。

行业影响与竞争压力

对于开发者和网站所有者来说，这一变化带来了连锁反应。Google 的开发者文档解释了 AI 功能如何在个性化回答中展示网站内容，并建议优化网站以提高被收录的概率。这可能会为符合用户上下文的网站带来更多流量，但也可能削弱传统自然搜索结果的重要性。
在竞争层面，这对竞争对手构成了压力。Apple 的 Siri 增强功能或 Amazon 的 Alexa 集成在数据规模上无法与 Google 匹敌。行业内部人士推测，这可能加速并购或合作，因为小型企业需要提升个性化能力以保持竞争力。
在经济层面，该功能与 Google 的收入模式紧密相关。通过 AI Pro 订阅，Google 可以将高级 AI 变现，从而在个性化搜索可能减少外部网站点击量的情况下，抵消广告收入的下降。

用户采用与未来扩展

从 Jason Howell 等评测者在 2026 年 1 月 22 日发布的 X 帖子来看，早期采用率表现良好。他对旅行规划和穿搭分析的测试显示，AI 输出高度贴合个人偏好，尽管偶尔会出现数据解读错误。
展望未来，Google 暗示可能会将该功能扩展到更多应用，例如 Drive 或 Calendar，这与最初的 Gemini 集成路线一致。最终，它可能演变为搜索内部的 “全功能个人 AI 助手”，能够处理从健康查询（参考健身照片）到财务规划（分析邮件收据）的各种任务。
当然，挑战依然存在，包括确保准确性以及避免个性化 AI 中的偏见。例如，如果用户的照片库偏向某些人群，推荐可能会强化 “信息茧房”。

战略愿景与伦理考量

Google 领导层（包括 Robby Stein 在 2026 年 1 月 22 日的 X 帖子）将这一功能视为打造 “真正理解你” 的搜索的关键一步。这是其更宏大愿景的一部分 —— 让 AI 能够预测需求，将搜索与个人智能无缝融合。
在伦理层面，透明的数据使用至关重要。监管机构可能会审查 Google 如何获取用户同意，尤其是在家庭共享账户中，照片可能包含他人的个人信息。
对于科技行业的管理者来说，这凸显了投资隐私保护型 AI 的重要性。Google 的举措可能会成为行业先例，影响整个领域的标准制定。

开启个性化科技的新时代

随着 Personal Intelligence 的推出，AI 正从通用工具向更 “懂你” 的私人助手转变。行业资深人士将其与移动搜索的兴起相提并论，认为它可能再次改变用户获取信息的方式。
Android Authority 等媒体的反馈显示，对于那些更看重便利而非隐私顾虑的用户来说，这是一项 “改变游戏规则” 的功能，甚至有文章称它 “知道你去年夏天做了什么”。
归根结底，这项创新让人们不得不思考：为了获得更智能的服务，我们愿意牺牲多少隐私？对于行业从业者来说，观察其采用率将有助于理解用户的容忍度，以及搜索技术的未来方向。
总的来说，Personal Intelligence 是 Google 的一次大胆尝试，它将庞大的数据资源与前沿 AI 结合，重新定义了个性化体验。它能否成功，将取决于 Google 是否能在实用性与安全保护之间找到平衡 —— 而这可能会决定下一代智能系统的发展路径。

External Secrets Operator 中发现了一个严重安全漏洞。该工具是 Kubernetes 生态中广泛使用的外部密钥管理组件，用于连接 AWS Secrets Manager、HashiCorp Vault 等外部密钥系统与 Kubernetes 集群。漏洞编号为 CVE-2026-22822，CVSS 评分高达 9.3（严重），意味着攻击者可能借此直接获取敏感数据。
该漏洞导致 不安全的密钥读取（Insecure Secret Retrieval），并破坏了 Kubernetes 中最基本的命名空间隔离机制。
问题源于一个名为 getSecretKey 的模板函数。该函数最初是为了支持 senhasegura DevOps Secrets Management (DSM) 提供商而引入的，但后来被发现功能过于强大，从而带来安全隐患。
根据安全公告：“该函数能够在 external-secrets 控制器的 roleBinding 权限下跨命名空间读取密钥，从而绕过我们的安全机制。”
这意味着，一个命名空间中的恶意资源或配置错误的资源，可能读取到另一个命名空间的密钥—— 而这些密钥原本是完全不允许它访问的。“攻击者或配置错误的资源可以从非预期的命名空间中读取密钥。”
这种绕过的影响极为严重。如果攻击者能够读取特权命名空间中的密钥，他们就能轻松进一步提升权限并完全控制集群。报告指出：“未经授权访问密钥可能导致权限提升、数据泄露，或服务账号与凭据被窃取。”
管理员应立即审计其集群。该漏洞影响 External Secrets Operator 从 v0.20.2 到 v1.2.0 的所有版本。
维护者采取了果断的修复方式：直接删除了该功能。“该函数已被完全移除，因为它能实现的所有功能都可以通过其他方式完成，同时不会破坏我们的安全防护机制。”
用户被敦促立即升级到 v1.2.0 版本，该版本通过删除问题代码彻底修复了漏洞。
对于暂时无法升级的用户，也有临时缓解方案。管理员可以使用 Kyverno、Kubewarden 或 OPA 等策略引擎来 “阻止在任何 ExternalSecret 资源中使用 getSecretKey 函数”。
  1. 1
  2. ...
  3. 647
  4. 648
  5. 649
  6. 650
  7. 651
  8. 652
  9. 653
  10. ...
  11. 886