2026-08-13 22:23:18
DeepSeek 官方 X 账号于 2026 年 8 月 13 日宣布，DeepSeek Harness v0.1 进入 Developer Preview，向全球构建 agent harness 的开发者开放。这是 DeepSeek 首个官方智能体框架，采用 MIT 许可开源。
官方称 Harness 基于 Cordis 元框架，设计核心是 Everything is a plugin：模型、工具、skills、sessions、sandboxes、文件系统、loops、orchestration 和 UI 都作为插件实现，可组合、替换和扩展。
官方 GitHub 仓库 README 明确警告，目前仍是快速迭代的开发者预览版，未来会有破坏兼容性的改动。仓库根 package.json 当前版本为 0.1.0-rc.5，要求 Node.js ^22.19.0 或 >=24.0.0，这支持其候选版定位。
官方 README 给出的最低体验方式是安装 Node.js 后运行 npx @deepseek-ai/dsh web，默认在本机 127.0.0.1:3080 启动 Web UI；也可克隆仓库后用 pnpm 从源码构建。
r/DeepSeek 和 r/LocalLLaMA 的讨论显示，开发者反复询问官方 Harness 与 OpenCode、Pi、Codex、Claude Code 相比是否更适配 DeepSeek，以及是否能开箱即用。发布后的讨论关注插件化架构能否让工具、记忆后端等组件替换，以及这一架构相对现有 agent harness 的实际收益。
也有用户质疑 DeepSeek 是否有必要自建 Harness，认为成熟度与 IDE 集成可能需要较长时间，模型团队应优先改善模型能力。
当前一手材料没有提供与 Codex、Claude Code、OpenCode 或 Pi 的可靠对比测试，也没有证明该 Harness 会提升 DeepSeek 模型本身能力；相关优劣只能作为待实测问题。GitHub 热度、社区期待和第三方体验只能说明关注度，不能证明稳定性、安全性、缓存效率或生产可用性。
官方明确提示会有破坏兼容性的变化，开发者需要权衡早期试用收益与未来迁移成本。
2026-08-13 09:02:45
Google 美国商店在 8 月 12 日把 Pixel 11、Pixel 11 Pro/Pro XL 与 Pixel 11 Pro Fold 标为新品并开放预订。Pixel 11 起售价 899 美元，Pro 与 Pro XL 分别为 1099 和 1299 美元，Pro Fold 为 1899 美元；所有机型搭载 Tensor G6 芯片，Google 承诺七年系统和安全更新。
Pixel 11 配备 6.3 英寸 Actua 屏幕、3000 尼特峰值亮度、12GB RAM、48MP 主摄、13MP 超广角与 10.8MP 长焦，最高支持 30 倍变焦。Pro 与 Pro XL 升级至 6.3 或 6.8 英寸、3600 尼特屏幕、最高 16GB RAM、50MP+48MP+48MP 后置三摄、42MP 前摄、8K 视频录制与最高 120 倍变焦。Pro Fold 配备 6.5 英寸外屏与 8 英寸内屏，峰值亮度 3600 尼特，16GB RAM，48MP 主摄与最高 30 倍变焦；Google 称机身更薄更轻，强度提升至三倍。
Google 将 HiLight 通知灯限定在 Pixel 11 Pro 系列。手机面朝下时，HiLight 会为重要联系人来电或与 Gemini 对话发光；这一功能的实际价值取决于用户是否经常把手机面朝下放置、是否设置重要联系人以及 Gemini 使用频率，不能仅凭发布演示断言它会改变通知习惯。
Google 表示 Tensor G6 的计算能力最高提升 50%；这是厂商口径，不等于独立性能结论。Reddit 上的 Pixel 用户反复讨论 899/1099 美元起价是否值得，尤其与打折后的 Pixel 10 Pro 相比升级幅度是否足够。Tensor G6、相机与亮度升级提供明确硬件增量，Pro 系列的 120 倍变焦与 8K 视频针对远摄和高清录制场景，但现有 Pixel 10 用户未必因此获得足够换机理由；价格和折扣后的上代旗舰构成直接替代。
Pro Fold 在折叠屏市场延续 Google 的硬件存在，更薄更轻的机身与号称三倍强度提升回应了上代用户对耐用性的担忧，但 1899 美元起价仍让它停留在小众市场。发布优惠、旧机折抵和 Google AI Pro 免费期长度会影响实际购买判断。所有 Pixel 11 系列机型已在 Google 美国商店开放预订，正式发售日期与国际市场时间表尚未公布。
2026-08-12 22:54:10
Semrush 在 2026 年 6 月 23 日更新了它的技术 SEO 清单，作者 Tushar Pol，页面标注约 15 分钟阅读。和 2025 年 7 月 31 日的旧版相比，最明显的变化写在标题里：这份清单现在同时面向搜索引擎和 AI 搜索，正文里多出了 AI grounding 与 agent readiness 两块内容。
对做站的人来说，值得先弄清的不是新增了哪几个勾选项，而是这些项目里哪些有官方机制兜底，哪些只是「可能有帮助」。这两类混在同一个清单里，很容易被读成同一强度的要求。
Semrush 这版清单按抓取与索引、用户体验、网站结构、代码与配置、AI grounding 与 agent readiness 分块，具体条目包括索引状态、重复站点版本、robots.txt、重定向、断链、5xx、移动体验、Core Web Vitals、内链、面包屑、孤立页面、HTTPS、hreflang、结构化数据、AI 抓取访问和语义 HTML。Core Web Vitals 的良好阈值它给的是 LCP 2.5 秒以内、INP 200 毫秒以内、CLS 低于 0.1，检查工具建议用 Search Console 和 PageSpeed Insights。
前面几块基本能在 Google 的抓取与索引文档里找到对应机制：robots.txt 管的是抓取请求，noindex 管的是索引，sitemap 的作用是告知 Google 有新增或更新页面，canonical 用来声明重复或相似页面的首选版本。这里有个容易搞错的强弱差别，Google 关于合并重复网址的说明把重定向和 rel=canonical 算作强信号，把「收进 sitemap」只算较弱信号，而且 Google 保留自己另选 canonical 的权利。也就是说，靠 sitemap 表达偏好和靠 301 表达偏好，不是一个量级的动作。
新增的 AI 部分需要更谨慎地读。Google 的生成式 AI 搜索指南的表述是：传统 SEO 最佳实践仍然是 Google AI 功能的基础，页面要能被抓取、被索引、并且有资格显示摘要；但同一份文档紧接着写明，满足这些要求并不保证被抓取、索引或展示。更直接的一条是，Google 说生成式 AI 搜索不要求特殊 schema，也不要求完美的语义 HTML。结构化数据依然对普通搜索的富媒体结果有用，语义 HTML 对可读性和辅助技术有价值，但把它们写成「AI 可见性的门槛」，超出了官方给出的口径。Semrush 提到 schema 可能帮助 AI 提取信息，按 Google 的说法，这只能停在可能性上。
还有一处不该被清单简化的地方：不同 AI 服务的检索抓取器、训练抓取器和用户触发的代理并不是同一类系统。它们对 robots.txt 的支持程度和实际执行行为需要按各服务的官方文档逐一核对，无法从一条通用建议推出来。
r/TechSEO 最近的一场讨论主题是「你不再推荐的技术 SEO 建议」，反复出现的质疑正是通用清单容易让人把 sitemap、页面速度这类项目当成排名保证；参与者更在意 canonical 选择、渲染差异、索引资格，以及具体站点的具体故障。r/SEO 上另一场关于 LLM SEO 的讨论，结论接近：索引、可抓取性、内链和页面速度确实是传统搜索和 AI 搜索的共同基础，但不少打着 AI SEO 名义的服务，本质是给旧清单换个标签。
一个具体案例更能说明清单该往哪儿用。有用户在 r/TechSEO 报告，他们的 SaaS 首页在浏览器里显示正常，但不执行 JavaScript 的 AI 抓取器只能读到很少文本。这是原始 HTML 与渲染结果不一致的典型排查题，值得照着查一遍；但它是单个站点的报告，不能推广成所有 AI 抓取器都不执行 JavaScript。社交平台的帖子只代表原帖和读者讨论，事实仍要回到官方文档和自己站点的数据。
所以这份清单更接近一个诊断顺序：先确认页面能被抓取和索引，再看体验和结构，最后处理原始 HTML 是否包含实质内容这类新问题。它不是完成即达标的承诺书，Google 自己已经把这句话写进文档。
各自还得去查的是，你在意的那几个 AI 抓取器分别怎么声明自己的抓取规则和渲染能力。这部分没有统一答案，清单也给不了。
2026-08-12 22:37:22
OpenAI 在 8 月 11 日宣布 ChatGPT 桌面应用登陆 Linux，官方公告里的用词是 preview。消息进入 r/linux 之后，检索时已经堆到数百票，出现频率最高的追问不是什么时候能装，而是它比终端里的 Codex CLI 多了什么。
先把支持范围说清。官方随后补充的帖子列出首批覆盖 Ubuntu 24.04 LTS 与 26.04 LTS、Debian 13、Fedora 43 与 44，提供 x64 和 ARM64 的 .deb 与 .rpm 安装包。这是五个具体的发行版版本，不等于“Linux 支持”。用 Arch、openSUSE、NixOS 或更老的 Ubuntu LTS 的人，这一轮拿不到官方包。
应用本身的变化比平台名单更值得注意。OpenAI 的桌面应用说明在 7 月 9 日就确认 Chat、Work 和 Codex 被收进同一个客户端：Work 在获得授权后可以读取本地文件、调用桌面上的其他应用，Codex 面向软件开发。下载页也写明原先单独安装 Codex app 的用户更新到 ChatGPT 后即可打开 Codex。落到 Linux 上的因此是一个把账号、项目、代码任务和本地文件权限收在一起的客户端，聊天窗口只是其中一层。
差别在交互形态。CLI 擅长处理能写成命令和补丁的工作；图形客户端多出来的是截图与文件拖拽形成的上下文、多个任务并行时的可视管理，以及登录后跨设备同步的会话历史。r/linux 的讨论里的分歧也在这里：有人认为这些正是通读一份不熟悉的代码库时最缺的，有人认为浏览器加终端已经够用，再多一个 Electron 客户端只是多占内存。两种都是个人使用判断，不构成对产品的结论。
分发方式是另一个被反复提起的点。官方只给 DEB 和 RPM，没有 Flatpak、Snap 或 AppImage，也没有 AUR 与 Nix 的官方渠道。在 Linux 桌面生态里，包格式常常决定一个闭源客户端能走多远——沙箱化的格式至少给出可见的权限边界，而直接落进系统的安装包，让“专有软件加本地文件访问”这组组合在讨论中显得更敏感。
有一处需要纠正传播中的说法。中文社交平台的转述提到桌面版“支持远程控制”，但 OpenAI 现有相关说明此前只把 Mac 和 Windows 列为可被远程控制的主机，本轮公开材料没有确认 Linux 主机进入这一范围。r/codex 的讨论中还有用户报告 computer use 在 Linux 版上尚不可用——这是社区报告而非官方口径，但足以说明，把它当成已交付功能去安装是有风险的。
时间点上，OpenAI 把官方客户端推向 Linux，服务的是它最想守住的那批人。Codex 面对的竞争在编码工具，而这类工具的重度用户大量在 Linux 上工作，此前的选择只有 Codex CLI 或第三方封装。官方包把更新、登录和企业账号策略收回同一条链路，对 To B 场景来说，这比多一个界面重要。
preview 会停留多久、包格式是否扩展、Linux 主机能否拿到 Remote Control 与 computer use，这三件事决定它是开发机上的常驻工具，还是试装一次就卸载。
2026-08-12 22:09:02
微信官方 X 账号 8 月 12 日发布 WeLM，称其为微信团队打造、以资源效率为核心的大语言模型家族。官方说明图列出 WeLM-80B 和 WeLM-617B 两个型号，前者已部署在微信原生 AI 助手小微中，后者仍在开发。
公告下方有用户直接追问 WeLM 是否就是小微所用模型，也有中文回复质疑为何需要在 X 上获知微信自家模型发布，而微信内缺少同等明显的信息。截至核验时，该帖显示约 1.09 万次浏览、85 个赞、20 条回复。
官方第二张说明图称 WeLM-80B 有 800 亿总参数、每次推理激活 30 亿参数，并已部署在微信原生 AI 助手小微中，可用于聊天与搜索、调用微信原生功能和访问小程序服务。800 亿是总参数，30 亿是激活参数；后者代表单次推理实际计算量，不能把总参数直接当作推理开销。官方没有说明 WeLM-80B 在小微中的覆盖地区、账号范围或全量上线时间。
官方第三张说明图称 WeLM-617B 有 6170 亿总参数、每次推理激活 230 亿参数，采用 MoE 架构且仍在开发；官方列出的方向包括增强通用理解与推理、智能小程序开发和小微工具生成。WeLM-617B 被官方明确标为 In Development，不能视为已上线或已部署。6170 亿总参数与 230 亿激活参数的比例约为 27:1，接近 WeLM-80B 的约 26.7:1。总参数与激活参数是不同口径：前者是模型全部参数规模，后者是单次推理实际调用的计算量。官方只确认 617B 采用混合专家（MoE）架构，没有说明 80B 的具体架构。
WeLM 这个名称并非首次出现：微信 AI 团队在 2022 年论文中曾发布一个 100 亿参数中文预训练语言模型。本轮公告应以 2026 年 8 月 12 日官方发布的 80B/617B 模型家族为对象，两者参数规模、架构与部署状态完全不同，不应混写。
官方只提供三张概览图，未公布训练数据、上下文长度、基准成绩、权重许可、API、价格或完整技术报告。目前只能确认 WeLM-80B 已部署在小微中，但具体可用范围、与微信现有功能的集成深度，以及 WeLM-617B 的实际上线时间仍不明确。
2026-08-12 21:03:51
Microsoft 于 8 月 11 日发布本月安全更新,其中一个 Windows 内核驱动漏洞已被攻击者利用。该漏洞位于负责网络套接字操作的 Windows Ancillary Function Driver for WinSock,已在本机通过身份验证的攻击者可运行特制应用并赢得竞争条件,成功后取得 SYSTEM 权限。微软将其标记为 Exploited: Yes,这是本轮唯一确认主动利用的漏洞。
漏洞编号为 CVE-2026-68820,类型为 use-after-free,CVSS 3.1 基础分 7.0,攻击向量为本地、高复杂度、低权限、无需用户交互。微软说明,攻击者需要已在目标机器运行代码,再通过该漏洞提升至 SYSTEM;这不是无需前置条件即可从互联网接管任意 Windows 电脑的远程入侵入口。微软未公开攻击者归因。
微软官方 CVRF 数据列出多个受影响的受支持 Windows 客户端和 Windows Server 产品,用户与管理员应通过 Windows Update、组织补丁系统或 Microsoft Update Catalog 安装适配其版本的 8 月安全更新。
Zero Day Initiative 独立统计本轮为 398 个新 CVE,其中 62 个 Critical;这是第三方按其口径得出的新漏洞数量,微软 CVRF 包含跨产品、重复发布或历史条目的数据结构,不能简单以对象总数替代本月新 CVE 数。
The Hacker News 列出四个 CVSS 9.8、无需认证或用户交互的远程代码执行漏洞:Windows DNS Server CVE-2026-62878、Windows Deployment Services CVE-2026-62893、Microsoft QUIC CVE-2026-62815、HPC Pack CVE-2026-59124。这些漏洞的实际优先级取决于对应服务是否安装并可从网络访问。
r/sysadmin 的 8 月 Patch Tuesday 讨论首先强调应在测试或试点环境部署并准备回滚,反映管理员同时担心主动攻击风险与大批补丁带来的兼容性、重启和业务中断。社区反复区分 CVSS 分数与实际优先级:已被利用的 7.0 本地提权漏洞通常应先于未见利用的 9.8 漏洞,但暴露的 DNS、WDS、QUIC 或 HPC 服务仍需按资产可达性加急。高 CVSS 不自动等于最高部署优先级,是否已被利用、服务是否安装和网络可达性、测试与回滚能力共同决定顺序。
对个人用户,CVE-2026-68820 要求攻击者已在本机执行代码,因此应优先关注其他可能导致初始感染的攻击面,包括浏览器、邮件客户端和常用软件;但该漏洞已被利用,建议尽快安装 8 月更新。对企业管理员,已被利用的本地提权漏洞可能与其他漏洞或凭据盗取手段组合使用,应结合实际资产清单和威胁情报确定测试与推送顺序。
