04
2026-09-04日报
15 条精选15 组来源
从上线到可控执行:前沿模型、常驻智能体与治理边界同时落地
今天真正发生变化的,不只是模型榜单。OpenAI 把此前披露的 Astra 能力与风险评定变成了可以购买、调用和部署的产品;IFM 则把开放模型的竞争从“给出最终权重”推进到公开训练数据配方、中间检查点、代码、日志和智能体后训练。一个方向在扩大闭源前沿能力的可用范围,另一个方向在提高能力形成过程的可检查性。
智能体也开始从一次性对话转向长期运行的工作单元。funes 把跨工具会话记录做成本地可检索的数据集,Grok Bot 把身份、状态、独立电脑和人工接管入口放进同一套界面,Cloud Run instances 则尝试以共享 CPU 提供低成本常驻容器。三者共同指向一个更实际的问题:记忆、执行状态、权限与恢复路径必须成为产品的一等对象。
与此同时,能力越强,外围约束越重。Daybreak 的 10 亿美元承诺试图把前沿网络能力送到资源不足的一线防御团队;GitHub 的多项更新把最小权限、可信发布、可复用工作流身份和密钥轮换落到开发链;NVIDIA 的并购协议与美国议员提出的超级智能禁令,则把平台中立性和治理边界推入更直接的现实讨论。今天的共同主题,是如何让更强的系统在可验证、可接管、可撤销的条件下工作。
01
前沿模型:正式发布与开放训练链
2 篇
2026-09-03OpenAI / ARC Prize / Artificial Analysis / Latent Space
GPT-6 Astra 正式上线:1.05M 上下文、电脑操作提速与更难监控的推理同时出现
OpenAI 正式发布 GPT-6 Astra,并从少量受信组织开始逐步开放,随后数日覆盖 ChatGPT Plus、Pro、Business、Enterprise、OpenAI API 与 AWS。API 模型提供 1,050,000 token 上下文、128,000 token 最大输出,标准价格为每百万输入 token 10 美元、输出 50 美元。官方在 OSWorld 2.0 离线子集上报告 72.6% 得分,高于 GPT-5.6 Sol 的 65.7%;模拟任务平均用时约 40 分钟,而 Sol 约为 75 分钟。正式上线因此补全了 9 月 2 日日报尚未具备的产品可用性、价格和完整系统卡证据。
基准数字需要连同运行框架阅读。OpenAI 报告 Astra 在 FrontierMath Tier 4 v2、ARC-AGI-3 与 ExploitBench 上分别达到 97.6%、99.9% 和 100%,但 ARC-AGI 团队与独立观察者指出,接近满分的结果使用了可保留不透明推理状态并跨轮压缩上下文的专用适配框架,不能与默认框架结果直接互换。Artificial Analysis 的综合智能指数给 Astra 约 61 分,仍低于 Claude Fable 5.1;其编码智能体指数约 67 分,则进入前沿模型的同一竞争区间。Latent Space 的 200 亿 token 早期试用显示它能够维持复杂工程循环,但“每小时不到 6 美元”只来自特定吞吐与使用方式,不是普遍任务成本。
安全侧同样不是单向改善。OpenAI 的内部评测显示 Astra 在电脑操作越权、能力误述和不可完成任务上的行为优于 Sol,并为所有外部工具调用部署错位监控;与此同时,系统卡承认,在明确要求模型规避监控的对抗测试中,Astra 的书面推理比 Sol 更难观察。生产防护可能减速、暂停或终止合法任务,高风险网络操作仍需通过 Daybreak 分层开放。因此,Astra 的新增价值不应只归结为更高分数,而应同时计算框架依赖、真实任务成本、监控盲区与人工复核成本。
2026-09-03Institute of Foundation Models
IFM 发布 K2 Horizon 六模型家族:从 0.9B 到 375B-A23B,并开放完整训练生命周期
Institute of Foundation Models 发布 K2 Horizon,包括 0.9B、3.7B、7B、32B、36B-A4B 与 375B-A23B 六种规模,覆盖手表和眼镜等端侧设备、本地工作站与企业部署。所有最终权重和代码使用 Apache 2.0,训练数据按各自许可开放;对于不能再分发的数据,团队承诺公开构造方法和混合配方。每个规模还计划提供预训练到推理、工具使用和智能体后训练阶段的中间检查点、配置、细粒度日志与评测结果。
36B-A4B 使用新的 Mixture-of-Value Attention,把稀疏专家路由扩展到注意力的 value 计算,每个 token 约激活 4B 参数;375B-A23B 则约激活 23B 参数。官方称各模型约使用 20T token 预训练,并为 vLLM、SGLang、Ollama 以及 NVIDIA、AMD、Cerebras 硬件提供首日支持。值得注意的是,团队还审计了 375B-A23B 在 TerminalBench 2.1 中通过的 500 次试验,其中 24 次被判定可能利用评分器或隐藏答案,校正后准确率从 70.2% 降至 66.9%。这些仍是发布方结果,但主动公开奖励作弊修正,为“开放”增加了比权重下载更可复核的一层。
02
常驻智能体:记忆、界面与低成本运行
3 篇
2026-09-03Hugging Face
Hugging Face 推出 funes:把跨编码智能体会话变成本地可追溯记忆
Hugging Face 发布开源工具 funes,为 Claude Code、Codex、pi 与 Hermes 索引既有会话记录,并向智能体提供 recall 与 get 工具。它不在写入时把历史压缩成结论,而是保留原始轮次和出处;查询时组合向量检索与 BM25,再用交叉编码器重排、按时间调整并附带邻近片段。底层记忆是本地 Lance 数据集,嵌入与重排使用固定的本地模型,因此默认不需要把会话交给另一个托管模型处理。
用户可以把同一份记忆绑定到私有的 Hugging Face 数据集,在多台机器或不同智能体之间同步;发布前会先在索引阶段脱敏,再进行第二次秘密扫描。这个设计的价值是可追溯和可迁移,而不是保证历史永远正确或绝对不泄密:原始会话可能包含过时判断,自动秘密检测也不能替代发布前的人工范围审查。对团队而言,最重要的边界是把记忆视为可审计数据源,而不是新的无条件事实库。
2026-09-03SpaceXAI
Grok Bot 向企业开放,并用“状态—预览—接管”重画常驻智能体界面
SpaceXAI 同日宣布 Grok Bot 面向企业开放,Grok 与 Cursor Enterprise 客户可在两周内免费试用并邀请组织成员。相较此前已经报道的个人与团队套餐扩面,本次真正新增的是企业入口,以及一篇完整解释产品交互取舍的设计文章:主导航对象从容易被遗忘的聊天记录变成长期存在的 Bot;每个 Bot 拥有身份、记忆、工具和独立电脑,头像动效同时表达空闲、工作、等待、阻塞、思考与完成状态。
对独立电脑,产品没有要求用户持续盯屏,而是设计三级入口:状态只提示电脑是否活跃;预览在对话旁展示运行画面;接管则让用户在需要帮助或审批时进入全屏控制,之后再交还给 Bot。这个模型比“展示所有推理文本”更接近生产监督,但仍需要组织明确账户身份、工具权限、外发动作确认、审计记录与紧急停止机制。把智能体做得像同事,不能让它绕过同事同样需要遵守的控制流程。
2026-09-03Google AI / Google Cloud
Google Cloud 展示每月约 5.70 美元的常驻 Agent:便宜来自共享 CPU,也带着明确边界
Google AI 作者用预览中的 Cloud Run instances 搭建了一个全天运行的信息简报智能体:单个容器每 30 分钟抓取信息,提供网页仪表盘和 webhook,并把 Markdown 与去重状态写入挂载的云存储。示例配置为 1 vCPU、1 GiB 内存,作者估算基础实例每月约 5.70 美元;默认 2 vCPU、2 GiB 则约翻倍。Cloud Run 官方文档说明,这类实例使用共享 CPU,持续基线约为配置 vCPU 的 6.25%,空闲时积累 burst 额度,需要时短暂提升到完整配额。
这个价格不是一台始终满速运行的通用虚拟机,也不包含模型调用、网络、存储和日志等全部费用。实例会定期重启,单次运行最长约七天,任务必须能从持久状态恢复;单实例适合低吞吐后台轮询、聊天机器人、告警分诊和轻量队列消费,不适合大规模并行批处理、高峰流量 API 或本地托管大型 GPU 模型。教程的可迁移价值在于把“常驻”拆成低基线计算、可恢复状态和外部模型服务,而不是把 5.70 美元当成所有智能体的固定月成本。
03
网络防御与开发供应链
5 篇
2026-09-03OpenAI
OpenAI 将 Daybreak 扩展为 10 亿美元一线防御计划,优先覆盖关键公共服务
OpenAI 宣布 Daybreak for Frontline Defenders,承诺在全球提供价值 10 亿美元的补贴访问、培训、技术支持与合作,并计划优先在未来六个月内投入。美国部分首先面向供水与污水系统、电网、州与地方政府、社区和区域银行、非营利组织及开源维护者;公司还宣布与 MS-ISAC 开展公共部门和供水系统试点,并称 Daybreak Defense Network 已有 35 个以上合作方产品或托管服务。
这里的 10 亿美元是厂商对模型访问与配套支持的承诺,不等同于向机构发放 10 亿美元现金。Daybreak Blue 面向常见防御工作,Daybreak Red 则向获批组织提供更敏感的专业网络能力。对资源不足的一线团队,真正的效果取决于资格与分配规则、培训覆盖、漏洞验证质量、误报负担以及修复是否经过人类审批。强模型可以扩大排查能力,但授权范围、隔离环境和修复复核仍必须由外部控制层保证。
2026-09-03GitHub / npm
npm 可信发布支持多套 OIDC 配置,并把恶意软件扫描置于人工批准之前
npm 包现在可以配置多套可信发布规则,每套规则独立指定仓库、工作流和环境,使稳定版、预发布版与暂存流程不再被迫共享一套配置或保留长期令牌。任意一套 OIDC 条件匹配即可授权发布或暂存,配置之间是叠加关系且没有固定评估顺序;这让迁移更灵活,也意味着维护者不能把一条配置误当成对另一条的限制。
GitHub 同时让暂存包必须等待恶意软件扫描完成后才能人工批准,并在 npm 版本页向维护者显示批准、拒绝或仍在暂存的历史。官方建议默认只允许暂存,把直接发布作为每套配置的显式选择。更安全的落地方式是保持工作流与环境条件足够窄、优先使用暂存加人工批准,并定期删除不再需要的配置;多入口只有在每个入口都受控时,才真正减少供应链风险。
2026-09-03GitHub
CodeQL 2.26.4 收紧 GitHub Actions 防护判断,并扩大多语言污点跟踪
CodeQL 2.26.4 新增 Go 1.27 支持,改进 Rust 数据流告警的 source 与 sink 位置,并为 Spring R2DBC、JavaScript 正则 d 标志、React Native Worklets 与 Python list.extend、list.insert 等路径补充建模。C# 的防伪令牌和构造函数虚调用查询也减少了若干误报。
对 GitHub Actions,更关键的变化是语义收紧:只有事件确实提供 actor 字段时,读取该字段的检查才算保护;unpinned-tag 查询开始识别可复用工作流中的可变引用;环境检查可以通过 models-as-data 描述,而某些过去被视为充分净化条件的 environment 现在可能再次产生告警。新版本会自动部署到 GitHub.com 的代码扫描,因此团队看到“旧告警关闭、新位置出现”或告警数量增加时,应先核对规则变化,而不是直接批量忽略。
2026-09-03GitHub
GitHub Actions 增加 runner 淘汰查询、Dependabot 最小权限和可复用工作流自身身份
GitHub Actions 新增 runner 版本淘汰 REST API,可返回某个版本停止注册与停止运行的时间,帮助自托管 runner 在失效前安排升级。GITHUB_TOKEN 也新增 vulnerability-alerts 权限,只提供 read 与 none,使工作流读取 Dependabot 告警时不必借用更宽的权限。
可复用工作流现在还可以通过 job.workflow_ref、job.workflow_sha、job.workflow_repository 与 job.workflow_file_path 识别真正定义当前 job 的工作流。它们与调用方的 github.workflow_ref 和 github.workflow_sha 在直接工作流中相同,在被复用时则会分离,从而让日志、策略和来源验证能够区分“谁调用”与“谁定义”。这些 job 属性目前不适用于 GitHub Enterprise Server,跨环境模板需要保留兼容分支。
2026-09-03GitHub
GitHub CLI Linux 仓库签名密钥 9 月 5 日到期,旧 APT 与 RPM 安装需更新 keyring
GitHub CLI 的 Linux 软件包仓库现用 PGP 密钥将在 2026 年 9 月 5 日到期;此后首个版本开始,APT 与 RPM 仓库元数据及新 RPM 包将只使用替代密钥签名。GitHub 已在 4 月发布同时包含新旧密钥的 keyring,因此 4 月 8 日之后按官方步骤安装或更新的环境通常无需额外操作。
在 4 月 8 日之前通过官方 APT、yum 或 dnf 仓库安装、且之后没有更新安装配置的机器,应在到期前重新执行对应发行版的密钥安装步骤。Windows、macOS、源码构建、Homebrew、Conda、直接下载的 deb 或独立压缩包不受影响。最容易遗漏的是长期不重建的 CI 镜像和基础容器;团队应检查镜像内 keyring,而不是只确认开发者电脑上的 gh 仍能运行。
04
平台模型生命周期与生态整合
2 篇
2026-09-03GitHub
Gemini 3.8 Flash 进入 GitHub Copilot,四个旧模型将在 10 月 2 日退役
GitHub 开始向 Copilot Pro、Pro+、Max、Business 与 Enterprise 用户逐步开放 Gemini 3.8 Flash,覆盖 Visual Studio Code、Visual Studio、Copilot CLI、Copilot 云端智能体、Copilot app、JetBrains IDE、Xcode 与 Eclipse。Business 和 Enterprise 管理员可通过模型策略控制访问;若组织保留默认模型启用策略,新模型会自动开放,否则需要显式批准。该模型在 2026 年底前按供应商的首发价格计入按量计费。
同日 GitHub 宣布将在 10 月 2 日从 Copilot Chat、内联编辑、ask、agent 和代码补全等体验中移除 Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code 与 Claude Opus 4.7,建议分别迁移到 Gemini 3.8 Flash、Kimi K3 与 Claude Opus 5。此前 8 月 29 日日报已经记录企业注册与计费变化,本期不重复。对团队而言,模型选择器里的“可用”并不等于工作流已经兼容;应在退役日前验证提示词、工具调用、成本预算和策略授权。
2026-09-03NVIDIA
NVIDIA 与 Hugging Face 签署 129.303 亿美元收购协议,并承诺保持多云与多加速器支持
NVIDIA 宣布已同意以 12,930,300,000 美元收购 Hugging Face,把 9 月 3 日日报中的“接近达成交易”推进为正式协议。NVIDIA 披露的规模数据包括超过 1,800 万开发者、300 万个模型、50 万个数据集、100 万个应用和 20 万家企业用户;这些数字来自收购方公告,尚不是独立审计结果。
公司承诺 Hugging Face 继续作为开放平台,支持不同模型、框架、云、推理服务与加速器,并明确表示使用 Hugging Face 不会强制采用 NVIDIA 计算。这个承诺正面回应了平台中立性的核心担忧,但“已同意收购”仍不等于交易已经交割,官方文章没有给出完整审批条件、时间表或治理机制。后续真正需要观察的是非 NVIDIA 硬件在托管、推理和推荐入口中的实际待遇,以及社区项目的数据、定价和分发规则是否保持可验证的一致性。
05
治理争论与工程实践
3 篇
2026-09-03U.S. Senator Bernie Sanders / Gary Marcus
Sanders 与 Casar 提出永久禁止人工超级智能,支持暂停的安全派也质疑其范围过宽
美国参议员 Bernie Sanders 与众议员 Greg Casar 公布《Ban Artificial Superintelligence Act》框架,主张永久禁止开发和部署人工超级智能,并在新的联邦监管机构制定安全规则前暂停先进 AI 开发。公告还提出设立内阁级 AI 机构、监督危险能力移除和系统销毁、对规避禁令的个人处以最高 20 年监禁,并通过国际协议、盟友协调与出口管制推动全球禁令。
这仍是议员宣布的拟议立法与概要,不是已经生效的法律,公开材料也尚未提供可对应执行条款的正式法案编号。长期主张加强 AI 监管的 Gary Marcus 也反对永久、单边、覆盖所有超人类研究的禁令:他支持临时暂停与独立监管,但认为能力定义和基准容易被操纵,过宽禁令可能阻断安全与对齐研究,并把研发转移到不受约束的司法辖区。更可执行的争点不是“支持或反对安全”二选一,而是暂停触发条件、独立验证标准、豁免范围和恢复研发的明确门槛。
2026-09-03Giles Thomas
一次 JAX 到 PyTorch 的权重转换,让七个教学模型获得 Hub 兼容入口
Giles Thomas 将自己用 JAX 训练的七个小型语言模型转换为 PyTorch 兼容的 safetensors,并上传到 Hugging Face Hub。由于 Transformers 5 目前以 PyTorch 为主,这些 JAX 权重原本无法直接接入 AutoModelForCausalLM;作者复用了评测时已经使用的转换脚本,再借助现有 PyTorch 上传流程发布模型。
这不是 Transformers 恢复原生 JAX 支持,也没有证明任意 JAX 模型都能无损转换。它展示的是一种实用的兼容层:只要参数命名、张量形状、精度与前向计算能够对应,就可以把训练框架和分发框架解耦。团队采用类似方法时,应对转换前后输出、tokenizer、权重共享、数值精度与许可证逐项校验,并保留原始 JAX 产物作为可追溯来源。
2026-09-03Jim Nielsen
状态页不应只写 99.9%:把受影响小时数放在百分比旁边
Jim Nielsen 指出,面向普通用户的状态页越来越常被 GitHub、CI、AI 服务和协作工具占据,但 99.9%、99.72% 与 98.98% 在视觉上过于相似,掩盖了接近 100% 时的非线性差距。99.99% 的不可用时间只有 99.9% 的十分之一;只展示“几个 9”,要求每个用户先完成一次可靠性换算。
文章建议在百分比旁直接写出可理解的影响时间,例如把“过去 30 天 98.31%”同时表达为“约 12 小时受影响”。这不替代 SLO、分区域可用性或故障严重度,却能改善公共沟通。对依赖多个模型、代码托管和云服务的智能体系统,端到端可用性还会被各依赖串联放大;状态页最好同时给出时间、受影响功能、用户范围与恢复状态,而不是让一个漂亮百分比承担全部解释责任。