北京时间 2026 年 6 月 13 日，在 Claude Fable 5 仅仅上线三天后，Anthropic 在社交平台上发布了一则令人震惊的 声明： 因美国政府援引国家安全授权下达出口管制指令，要求禁止任何外国公民访问 Fable 5 和 Mythos 5 ，公司为确保合规，不得不紧急对所有客户全面停用这两款模型。

The US government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees.

The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance.

Access to all other Claude models is not affected.

在 Anthropic 的官网 声明 中表示，美国政府是基于发现了一种绕过或破解 Fable 5 限制（即大模型的 越狱）的方法而发布了禁令。

虽然其他 Claude 模型暂未受波及，但这则短短的声明，却无异于在生成式 AI 领域投下了一枚重磅炸弹。它不仅宣告了一个特定模型的下线，更标志着整个行业底层逻辑的根本性转折。

核心剧变：从“算力霸权”向“模型主权”的转移

过去，大国博弈与行业竞争的焦点一直停留在硬件层面——谁掌握了最先进的 GPU 和芯片制造工艺，谁就扼住了 AI 发展的咽喉。

然而，Fable 5 事件证明，到了 2026 年，最先进 AI 的核心价值已经从“训练基础设施”正式转移到了“模型本身”。当一个前沿模型具备了以下特征时，它便不再仅仅是商业软件，而是名副其实的国家战略级技术资产：

• 顶级的科研与科学发现能力
• 深度的自主编程与除错能力
• 长周期的复杂任务规划与执行能力
• 自动化的网络攻防与安全渗透能力

美国政府对 Fable 5 的封锁逻辑，与当年限制高端芯片出口的逻辑如出一辙。因为在国家安全视域下，具备上述能力的软件，其杀伤力与重要性已与尖端军工硬件无异。

致命悖论：Anthropic 被自己的“安全牌”反噬

这起事件中最具戏剧性的一幕，在于 Anthropic 一直以来的人设。作为业界最著名的“AI 安全路线”倡导者，Anthropic 经常在公开场合展示其模型在网络安全、生物科学辅助、自动化代理等领域的强大乃至“危险”的能力。

这种策略在商业上曾无比成功：

• 对投资者： 证明了自己拥有逼近 AGI 的技术实力。
• 对监管者： 彰显了企业对潜在风险的重视与透明度。

但也这是一个致命的悖论：
为了证明模型足够强大，企业必须充分展示其潜在的破坏力；而当这种危险性被反复强调并被广泛认可后，必然会精准踩中监管机构的红线。Anthropic 近期对 Fable 5 和 Mythos 5 危险能力的渲染，最终成为了促使监管重锤落下的核心背书。

行业新常态：互联网“无国界时代”的终结

Fable 5 的下线只是一个开始，它真正值得警惕的是其开创的政策先例。如果政府可以直接介入并限制特定 AI 模型的全球访问权，那么我们很可能即将迎来一个“技术边境”森严的新时代。

未来，全球统一的 AI 软件服务模式可能走向瓦解，取而代之的将是高度分化的访问机制：

• 基于国籍的隔离： 不同国家的用户只能访问被阉割或完全不同的模型版本。
• 模块化的权限管控： 科研、编程等关键能力模块受到严格的许可限制。
• 身份层级分化： 个人用户、普通企业与具有特殊资质的科研/政府机构获得截然不同的访问权限。

过去的焦点是数据主权，而未来的核心博弈将是模型主权。

悬念犹存：GPT-5.5 会步其后尘吗？

面对 Claude 的遭遇，用户的焦虑很快蔓延至其竞争对手：OpenAI 的 GPT-5.5 会不会成为下一个管制目标？ 尤其是在 Anthropic 的官网 声明 中包含了下面的内容：

我们已经审查了一份据信是政府下达该指令依据的报告。我们已经核实，报告中所展示的能力水平在其他模型（包括 OpenAI 的 GPT-5.5）中广泛存在，并且每天都在被维护系统安全的防御者们所使用。

Anthropic 认为，这场风波本质上是一场误解。所谓“越狱”并非体现模型具备普遍性、高风险能力，而只是某些狭窄、非通用的漏洞；类似能力在其他公开模型中也普遍存在，并不应被单独放大为管制依据。

从声明全文来看，Anthropic 对相关管制政策持明确反对态度。其核心诉求显然是自救，而不是将其他竞争对手一并拖入困境。它真正希望推动的，是监管层重新评估 Claude Fable 5 的风险判断，并最终解除对其访问限制。

毕竟，如果两家 AI 巨头的旗舰模型都相继被限制，那将不只是某一家公司的危机，而可能成为整个技术开放生态的至暗时刻。

结语：AI“开放时代”的落幕

回顾过去三年，大模型行业经历了一场狂飙突进的全球化盛宴。模型能力呈指数级跃升，使用成本不断逼近底线，全球用户几乎能够跨越地理界限，同步享受到人类最前沿的智慧结晶。

但 6 月 13 日的 Fable 5 事件，是一道冰冷的历史分水岭。

它宣告了先进 AI 正式脱离单纯的“消费级科技产品”范畴，被摆上了与核武器、航空航天、先进制程芯片同等的战略博弈棋盘。对于普通人而言，最大的震撼不在于某一个聊天窗口的暂时失效，而是我们终于看清了未来的残酷现实：

由技术全球化所构筑的“普惠 AI”乌托邦正在消散，取而代之的，是数字铁幕时代下，被权力、国籍和安全政策严格切割的智能世界。

一句话认识两位选手

• Nginx：2004 年诞生，C 语言编写，事件驱动架构的鼻祖级实现。占据全球 Web 服务器市场的头部份额，几乎是”反向代理”的代名词。
• Caddy：2015 年发布，Go 语言编写，主打”默认 HTTPS”和极简配置。Caddy 2 重写后以模块化架构和 JSON 配置 API 为核心。

配置体验：最直观的差距

先看一个最常见的需求：把 example.com 反向代理到本地 8080 端口，并启用 HTTPS。

Caddy（Caddyfile，3 行）：

1
2
3

example.com {
    reverse_proxy localhost:8080
}

证书自动申请、自动续期、HTTP 自动跳转 HTTPS——全部默认完成。

Nginx（约 25 行 + certbot）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

还需要额外跑 certbot 申请证书并配置定时续期。

但要公平地说：Nginx 的冗长换来的是显式与精细。proxy_set_header 每一行都看得见摸得着；而 Caddy 帮你做的事藏在默认值里，出问题时你需要知道它默认做了什么。对于配置规模庞大、需要精确控制每个 header、buffer、timeout 的场景，Nginx 的配置语言虽然啰嗦，但表达力和社区可参考的范例数量是压倒性的。

HTTPS 与证书管理

这是 Caddy 的主场：

• 自动 HTTPS：通过 ACME（Let’s Encrypt / ZeroSSL）自动签发、续期、轮换证书，包括 OCSP 装订，零配置。
• 按需 TLS（On-Demand TLS）：在 TLS 握手时才为新域名签证书，是 SaaS 自定义域名（客户绑定自己的域名）场景的杀手锏。Nginx 体系要实现同样的效果通常得上 OpenResty + lua-resty-auto-ssl，复杂度完全不在一个量级。
• 内部 CA：内置本地 CA，localhost 开发环境也能用受信任的 HTTPS。

Nginx 这边，证书管理依赖外部工具（certbot、acme.sh、lego），工作得也很成熟，但本质上是”胶水方案”：多一个进程、多一个 cron、多一个 reload 钩子，多一处可能坏的地方。

性能：差距比你想象的小

网络上流传”C 写的肯定比 Go 快”，实际测试中：

• 静态文件与常规反向代理：两者在绝大多数真实负载下吞吐量处于同一量级。Nginx 在极限 RPS 和内存占用上通常仍有优势（C + 精细的内存管理 vs Go runtime + GC），尤其是数十万并发连接的极端场景。
• 尾延迟：Go 的 GC 在高压下可能带来轻微的 P99 抖动，但对绝大多数业务无感。
• HTTP/3：两者都已支持 QUIC/HTTP3，Caddy 默认启用，Nginx 需要显式配置。

结论：除非你在做 CDN 边缘节点或单机要扛几十万并发，性能不应该是你们之间的决定因素。 瓶颈几乎总在上游应用，而不是代理层。

运维与生态

几个值得展开的点：

• 扩展性：Caddy 的插件体验显著更好。xcaddy build --with github.com/... 一条命令就能编出带 Cloudflare DNS 验证、限流、安全模块的定制二进制。Nginx 编第三方 C 模块的痛苦，折腾过的人都懂（这也是 OpenResty 存在的原因）。
• 配置即 API：Caddy 的本质是一个 JSON 配置引擎，Caddyfile 只是人类友好的前端。这让它天然适合被程序驱动——平台型产品动态增删站点不需要生成配置文件再 reload。
• 久经考验：Nginx 的边缘案例处理、与各种奇怪客户端/上游的兼容性，是二十年生产流量喂出来的。保守的大型生产环境选它，不会有人质疑。

选型建议

选 Caddy，如果你是：

• 个人项目、中小团队、初创公司——把省下来的证书运维时间拿去写业务
• SaaS 平台需要客户自定义域名（On-Demand TLS 几乎是唯一省心方案）
• 需要通过 API 动态管理大量站点配置
• 团队没有专职运维，希望配置文件三行能看懂

选 Nginx，如果你是：

• 已有大量 Nginx 配置和团队经验——迁移收益撑不起迁移成本
• 极端高并发 / 边缘节点 / 对内存和尾延迟敏感的场景
• 重度依赖 Kubernetes ingress-nginx 或 OpenResty/Lua 生态
• 需要 Nginx Plus 的商业特性与支持，或所在组织要求”最保守的选择”

也可以都要：不少团队用 Caddy 做边缘 TLS 终结（享受自动证书），后面挂 Nginx/原有架构不动。架构上完全成立。

写在最后

Nginx 和 Caddy 的关系，有点像 Vim 和 VS Code：前者无所不能但要求你懂它，后者把 90% 的常见需求做成了开箱即用。2026 年的今天，对于新项目我会默认从 Caddy 开始——直到遇到它解决不了的问题再换，而这一天对大多数项目来说不会到来。但如果你手里已经有一套运转良好的 Nginx，请记住运维界的第一定律：If it works, don’t fix it.

Anthropic 于美国时间 2026 年 6 月 9 日 宣布推出 Claude Fable 5 和 Claude Mythos 5 。其中，Claude Fable 5 被定位为 Anthropic 迄今 “最强的广泛发布模型” ，面向普通用户和开发者开放；Claude Mythos 5 则与 Fable 5 共享底层模型能力，但在部分安全限制上更少，当前仅向 Project Glasswing 中获批的网络安全防御方和基础设施合作伙伴有限开放。

Claude Fable 5 被 Anthropic 定位为面向最高能力需求的 Mythos-class 模型，能力层级高于现有 Opus 4.8，主要面向复杂推理、长周期智能体任务、软件工程、知识工作、视觉理解和科学研究等高难度场景。官方表示，在任务越长、越复杂的情况下，Fable 5 相比此前 Claude 模型的优势越明显。

模型基准测试得分情况

Anthropic 公布了 Claude Fable 5 与 Claude Mythos 5 在基准测试中的得分情况，表现出了全方位的优势：

模型信息

在开发者能力方面，Claude API 文档显示，Fable 5 的 API 模型 ID 为 claude-fable-5，支持 1M token 上下文窗口、最高 128K token 输出，并默认启用自适应思考能力。该模型自 2026 年 6 月 9 日起已在 Claude API、Claude Platform on AWS、Amazon Bedrock、Google Vertex AI 和 Microsoft Foundry 上正式可用。

价格方面可以查看表格对比，Claude Fable 5 和 Claude Mythos 5 的标准 API 价格约为 Claude Opus 4.8 的两倍；其中 Fable 5 在批量处理场景下价格减半。

表格价格为每 100 万 token 的计费标准，参考： 模型定价 - Claude API Docs

限制信息

内置请求审核

Claude Fable 5 的发布伴随更严格的安全机制。 Anthropic 表示，若模型检测到涉及 网络安全、生物、化学或模型蒸馏 等高风险主题的请求，Claude Fable 5 可能不会直接回答，而是回退至 Claude Opus 4.8 或返回拒答结果。官方称，安全分类器在推出初期被有意调得较为保守，可能误伤部分无害请求；但 Anthropic 表示，超过 95% 的 Fable 会话不会触发回退。

使用限制

Anthropic 表示 Claude Fable 5 将在 6 月 9 日 至 6 月 22 日 期间包含在 Pro、Max、Team 和席位制 Enterprise 计划中；自 6 月 23 日起，除非容量允许延长，继续使用 Claude Fable 5 将需要消耗 usage credits 或是在 API 中进行调用，即需要额外付费才可以使用。

数据留存与隐私限制

由于 Anthropic 在新模型中引入了更强的安全监测机制，对使用数据的保存时间也存在限制，Claude API 文档 显示，Claude Fable 5 与 Claude Mythos 5 被列为 Covered Models，要求保留 30 天的使用数据，不支持零数据保留（ZDR）安排；不符合该要求的组织请求将返回 400 invalid_request_error。

使用方法

Claude Fable 5 模型在 Anthropic 的网页、API 与 Claude Code 中已立即可用，Claude Code 需要更新至 v2.1.170 以上的版本，如果打开 Claude Code 没有自动更新可以执行下面的命令手动更新

1

claude update

然后运行 /model 即可切换，信息页面已显示了预计使用量消耗为 Opus 模型的 2 倍。

发布福利

为了庆祝 Claude Fable 5 发布，Anthropic 对用户的 Claude 使用额度进行了临时重置，包括 5 小时使用限额和每周使用限额，让用户可以在新模型上线初期获得更多体验机会。

总结

总体来看，Claude Fable 5 的发布，标志着 Anthropic 开始把此前仅在受控项目中验证的 Mythos-class 能力推向大众市场。它的主要卖点不是更快或更便宜，而是在长上下文、复杂代码、知识工作和视觉任务中的更强上限。但与此同时，更高 API 价格、安全机制回退、订阅端临时开放机制，以及与安全监测相关的数据留存安排，也意味着企业和重度开发者在采用前需要重新评估成本、合规与产品体验。

适用对象：个人开发者、独立产品、开源项目、中小团队 PoC、低成本出海/全球访问场景

重要提醒：免费额度、区域可用性、服务条款和滥用限制会变化。本文基于公开页面整理，生产上线前请以 Cloudflare 与竞品的官方定价/限制页面为准。

一句话结论

Cloudflare 的免费级别已经不只是“免费 CDN”。它更像一套覆盖 域名 DNS、TLS、基础 DDoS/CDN/WAF、静态托管、边缘函数、对象存储、Serverless 数据库、队列、表单/机器人防护、网站分析、邮件转发、Zero Trust 访问、隧道、以及部分 AI 能力 的入门级互联网应用平台。

和 Vercel、Netlify、AWS、Fastly、Tailscale、ngrok、reCAPTCHA、hCaptcha 等竞品相比，Cloudflare Free 最大的优势是：免费服务覆盖面极广，很多能力天然集成在同一个边缘网络和控制台里。它的弱点也很明确：免费层没有商业级 SLA/支持保障，部分额度是硬限制，复杂框架体验不一定比 Vercel/Netlify 顺滑，重计算/重数据库/重媒体场景很快会撞上限制或需要付费。

1. Cloudflare 免费级别能用什么？

下面按使用场景整理。具体限额建议上线前再次核对官方文档。

1.1 网站基础设施：DNS、TLS、CDN、DDoS

评价： 如果只是把一个网站放到全球网络前面，Cloudflare Free 的门槛很低：改 DNS、开代理、开 HTTPS，就能获得基础加速和安全收益。这是 Cloudflare 免费层最有竞争力的入口能力。

1.2 Web 安全：WAF、规则、速率限制、热链防护

Cloudflare WAF 相关文档显示，免费计划可用的安全能力包括但不限于：

• WAF 自定义规则；
• 1 条 Rate Limiting 规则；
• Free Managed Ruleset；
• Email Obfuscation；
• Hotlink Protection；
• IP Access Rules；
• User Agent Blocking；
• Zone Lockdown；
• Security Analytics；
• 采样的 Security Events 日志。

适合场景：

• 个人网站防爬、防热链；
• 小型 API 做基础速率限制；
• WordPress、文档站、营销站做基础 WAF；
• 在没有预算采购独立 WAF 的情况下先建立安全底线。

注意点： 免费层是“够用的基础防护”，不是完整的企业级 Web 安全平台。Bot Management、更多高级托管规则、更多速率限制、高级日志和安全分析通常要升级。

1.3 前端托管：Cloudflare Pages

Cloudflare Pages 是免费层里非常值得关注的一项服务，适合静态站、Jamstack、文档站、落地页、前端应用和轻量全栈项目。

适合场景：

• 个人博客、知识库、开源文档；
• 公司官网、产品落地页；
• React/Vue/Svelte/Astro/Hugo 等静态构建项目；
• 带少量 API 的前端项目，例如表单提交、Webhook、登录回调。

和 Vercel / Netlify 的差异：

• Cloudflare Pages 的免费静态资源请求和带宽口径非常慷慨，适合流量不稳定的静态站；
• Vercel 对 Next.js 的开发体验通常更强，尤其是 Next.js 原生功能、预览部署、生态集成；
• Netlify 的表单、部署工作流、插件生态成熟，但免费层采用信用额度模型，需要关注 credit 消耗。

1.4 边缘函数：Cloudflare Workers

Workers 是 Cloudflare 开发者平台的核心。免费层当前包括：

适合场景：

• API 网关、轻量接口、Webhook；
• A/B test、重定向、鉴权、Header 改写；
• 静态站旁边的少量动态逻辑；
• 代理第三方 API、做缓存、做边缘安全校验；
• 与 KV、D1、R2、Queues、Durable Objects 组合成轻量后端。

不适合：

• 长时间 CPU 计算；
• 大型后端单体迁移；
• 重任务、重数据库事务、复杂后台作业；
• 对 Node.js 运行时兼容性要求非常完整的项目。

1.5 数据与存储：KV、D1、R2、Durable Objects、Queues、Hyperdrive

Cloudflare 的免费层已经可以搭出一个小型全栈应用。

架构建议：

• KV 用来读多写少，不要拿它做强一致数据库；
• D1 适合小型关系数据和原型，但要设计好索引和写入频率；
• R2 是 Cloudflare 免费层里对标 S3 的关键服务，尤其是“无出口流量费”对下载型场景很有吸引力；
• Queues 适合把用户请求和后台处理拆开；
• Durable Objects 适合需要按对象聚合状态的实时/协作场景，但要理解它的编程模型；
• Hyperdrive 适合你已经有 Postgres/MySQL 等外部数据库，希望从 Workers 更高效访问。

1.6 机器人防护与隐私分析：Turnstile、Web Analytics、Zaraz

评价：

• Turnstile 很适合替换传统 CAPTCHA，减少用户体验损耗；
• Web Analytics 适合只需要 PV、访客、来源、页面路径等轻量指标的站点；
• Zaraz 适合把第三方脚本移到边缘执行，减少前端性能损耗。

1.7 邮件转发：Email Routing

Email Routing 是一个免费的自定义域名邮件转发服务，可以把 hello@example.com、support@example.com 等地址转发到你的现有邮箱。Cloudflare 官方强调它不存储或访问邮件内容，并提供与 DNS 记录相关的配置。

适合场景：

• 个人域名邮箱转发；
• 开源项目/小产品的联系邮箱；
• 不想购买完整企业邮箱，但希望域名邮箱看起来更专业。

注意点： 它主要是转发，不是完整邮箱托管；发信、团队邮箱、归档、合规等能力仍需要 Gmail/Google Workspace、Microsoft 365、Fastmail、Zoho Mail 等服务。

1.8 Zero Trust、Access 与 Tunnel

Cloudflare Zero Trust 免费层适合小团队和 PoC。官方页面将 Free Plan 标为 $0 forever，适合 50 人以下团队或企业 PoC；Cloudflare Access 可用于保护自托管、SaaS、非 Web 应用访问，减少传统 VPN 依赖。Cloudflare Tunnel 可用出站连接把源站接入 Cloudflare，避免暴露公网入站端口。

适合场景：

• 保护 /admin、Grafana、内部工具、预发布环境；
• 家庭实验室/NAS/内网服务安全暴露；
• 替代简单 VPN 或跳板机；
• 临时演示本地服务。

1.9 AI 相关：Workers AI、AI Gateway、AI Search、Browser Run、Workflows

Cloudflare 免费层也开始覆盖 AI 与自动化相关能力。

注意点： AI Search 仍处在 beta/变化较快的阶段；AI 推理、模型选择、日志保留、数据合规和供应商成本都需要单独评估。

1.10 免费层不等于所有 Cloudflare 服务都免费

下列能力通常不应被当作“免费核心能力”来规划：

• Argo Smart Routing；
• Load Balancing；
• Advanced Certificates；
• Images、Stream 等媒体产品；
• APO for WordPress；
• 高级 Bot Management；
• 企业级日志、SLA、支持；
• Containers：官方定价页显示 Containers 在 Workers Paid 下计费，Free 不提供对应 CPU/内存/磁盘额度；
• Vectorize：Cloudflare 文档页面存在“仅 Workers Paid 可用”的表述，同时表格也列出部分 Free 行，建议上线前特别核对，不要把它作为稳定免费的基础依赖。

2. 和竞品怎么对标？

2.1 Cloudflare Pages vs Vercel Hobby vs Netlify Free

选择建议：

• 你要 低成本静态站、文档站、全球访问、免费带宽口径更宽：优先 Cloudflare Pages；
• 你要 Next.js 最新能力、预览部署、Vercel 生态：优先 Vercel；
• 你要 Netlify Forms、插件、成熟 Jamstack 工作流：优先 Netlify。

2.2 Cloudflare Workers vs AWS Lambda

选择建议：

• API 网关、轻量业务逻辑、边缘改写、低延迟全球入口：Workers 很合适；
• Python/Java/.NET、长一点的任务、复杂 AWS 资源联动：Lambda 更合适；
• 大规模生产系统：应按真实请求、CPU、日志、数据库、出口流量分别测算。

2.3 Cloudflare R2 vs AWS S3 / CloudFront

Cloudflare R2 的免费层包含对象存储容量和操作次数额度，并且核心卖点是 无互联网出口流量费。AWS S3/CloudFront 则是生态最成熟的组合：CloudFront 有持续可用的免费流量/请求额度，S3 和 AWS Free Tier 的规则则会随账户新旧、credits、区域和服务政策变化。

选择建议：

• 个人产品、大文件下载、静态资源分发：R2 免费层很有吸引力；
• 企业级对象存储治理、跨 AWS 服务集成、复杂 IAM：S3 仍是事实标准。

2.4 Cloudflare CDN/WAF vs AWS CloudFront/WAF、Fastly

选择建议：

• 预算为零且要 DNS+TLS+CDN+基础 WAF 一体化：Cloudflare；
• 已经深度 AWS 化：CloudFront + AWS WAF；
• 有专业 CDN 调优/边缘计算需求：Fastly；

2.5 Cloudflare Access/Tunnel vs Tailscale vs ngrok

选择建议：

• 要把内部 Web 应用挂到域名下并加身份验证：Cloudflare Access + Tunnel；
• 要像 VPN 一样访问所有设备：Tailscale；
• 要快速给本地服务一个公网地址做 demo：ngrok。

2.6 Turnstile vs reCAPTCHA vs hCaptcha

选择建议：

• 个人站、小产品、希望减少 CAPTCHA 打扰：Turnstile 优先；
• 已经在 Google 风控体系内：reCAPTCHA；
• 想要 reCAPTCHA 替代品且额度口径合适：hCaptcha。

3. Cloudflare Free 最适合的 8 类项目

1. 个人博客 / 文档站 / 开源项目官网
   Pages + DNS + SSL + Web Analytics 基本够用。

2. 静态营销站 / 落地页
   Pages + CDN + Turnstile + Email Routing 可以快速上线。

3. 小型 API / Webhook 网关
   Workers + KV/D1 + WAF + Rate Limiting 适合低成本运行。

4. 轻量全栈应用原型
   Pages 前端、Workers API、D1 数据库、R2 文件存储、Queues 异步任务。

5. 下载型资源站 / 附件存储
   R2 的免费容量和无出口流量费很有价值，但要关注操作次数和滥用规则。

6. 内部工具 / 后台管理系统
   Cloudflare Access + Tunnel 可以减少公开暴露源站的风险。

7. 反垃圾表单 / 注册保护
   Turnstile 替代传统 CAPTCHA，用户体验通常更轻。

8. AI 应用原型
   Workers AI + AI Gateway + AI Search beta 可以做轻量 RAG、模型代理、观测和缓存。

4. 免费层使用建议

4.1 架构上尽量“静态优先、边缘补动态”

Cloudflare Free 最适合静态内容和轻量边缘逻辑。能静态生成的页面尽量静态生成；能缓存的数据尽量缓存；动态 API 尽量保持短小。

4.2 把大文件放 R2，不要塞进 Pages 构建产物

Pages 单个静态资源大小有限制，更大的图片、附件、下载包建议用 R2，并通过 Workers 或自定义域名分发。

4.3 KV、D1、Durable Objects 分工要清楚

• KV：读多写少、最终一致、配置/缓存；
• D1：关系数据、小型业务表；
• Durable Objects：按对象聚合状态、协作、锁、会话；
• Queues：异步任务和削峰；
• R2：对象/文件。

4.4 生产前做额度预算

至少估算：

• 每日 Workers 请求量；
• 每次请求 CPU 时间；
• D1 行读取/写入；
• KV 读写次数；
• R2 Class A / Class B 操作；
• Pages 构建次数；
• Turnstile widget 数；
• Web Analytics/Zaraz 事件量；
• Zero Trust 用户数。

4.5 免费层要有“降级策略”

免费额度一旦触顶，常见结果不是自动扩容，而是报错、暂停、等待下个周期或需要升级。建议：

• 给 Workers 设置告警；
• 对写入操作做限流；
• 对日志采样；
• 大流量静态内容强缓存；
• 有付费升级预案；
• 关键业务不要只依赖免费层。

5. 总结：Cloudflare Free 的真实定位

Cloudflare 免费级别的价值在于：它让开发者用接近零成本获得一套现代互联网应用的基础能力：

• 域名解析；
• HTTPS；
• CDN；
• DDoS 与基础 WAF；
• 静态托管；
• 边缘函数；
• Serverless 数据库和对象存储；
• 队列与状态对象；
• Bot 防护；
• 隐私友好的分析；
• 邮件转发；
• Zero Trust 访问；
• AI 原型能力。

如果你的目标是 个人项目、开源项目、小型商业验证、低成本全球部署、快速 PoC，Cloudflare Free 是当前最值得优先评估的平台之一。

如果你的目标是 商业 SLA、完整支持、复杂后端、重计算、大规模数据库、重媒体处理、复杂合规、安全审计、企业采购，Cloudflare 免费层应该只作为入口方案，后续需要升级到 paid plan 或选择更合适的云服务组合。

6. 资料来源与核对入口

Cloudflare 官方资料

• Cloudflare Free Plan: https://www.cloudflare.com/plans/free/
• Cloudflare Plans FAQ: https://www.cloudflare.com/plans/faq/
• Cloudflare DNS: https://www.cloudflare.com/products/dns/
• Cloudflare SSL: https://www.cloudflare.com/products/ssl/
• Cloudflare WAF Docs: https://developers.cloudflare.com/waf/
• Cloudflare Pages Limits: https://developers.cloudflare.com/pages/platform/limits/
• Cloudflare Pages Functions Pricing: https://developers.cloudflare.com/pages/functions/pricing/
• Cloudflare Pages Product Page: https://www.cloudflare-cn.com/developer-platform/products/pages/
• Cloudflare Workers Pricing: https://developers.cloudflare.com/workers/platform/pricing/
• Workers KV Pricing: https://developers.cloudflare.com/kv/platform/pricing/
• Cloudflare D1 Pricing: https://developers.cloudflare.com/d1/platform/pricing/
• Cloudflare R2 Pricing: https://developers.cloudflare.com/r2/pricing/
• Durable Objects Pricing: https://developers.cloudflare.com/durable-objects/platform/pricing/
• Queues Pricing: https://developers.cloudflare.com/queues/platform/pricing/
• Hyperdrive Pricing: https://developers.cloudflare.com/hyperdrive/platform/pricing/
• Turnstile Plans: https://developers.cloudflare.com/turnstile/plans/
• Cloudflare Web Analytics: https://www.cloudflare.com/web-analytics/
• Zaraz Pricing: https://developers.cloudflare.com/zaraz/pricing/
• Email Routing: https://www.cloudflare.com/products/email-routing/
• Cloudflare Access: https://www.cloudflare.com/sase/products/access/
• Cloudflare Zero Trust Network Access: https://www.cloudflare-cn.com/products/zero-trust/zero-trust-network-access/
• Cloudflare Tunnel: https://www.cloudflare-cn.com/products/tunnel/
• Workers AI Pricing: https://developers.cloudflare.com/workers-ai/platform/pricing/
• AI Gateway Pricing: https://developers.cloudflare.com/ai-gateway/reference/pricing/
• AI Search Limits & Pricing: https://developers.cloudflare.com/ai-search/platform/limits-pricing/
• Browser Run Pricing: https://developers.cloudflare.com/browser-run/pricing/
• Workflows Pricing: https://developers.cloudflare.com/workflows/reference/pricing/
• Containers Pricing: https://developers.cloudflare.com/containers/pricing/

竞品资料

• Vercel Hobby Plan: https://vercel.com/docs/plans/hobby
• Netlify Pricing: https://www.netlify.com/pricing/
• Netlify Manage Billing / Usage Limits: https://docs.netlify.com/manage-billing/overview/
• AWS Lambda Pricing: https://aws.amazon.com/lambda/pricing/
• AWS Free Tier: https://aws.amazon.com/free/
• AWS CloudFront Free Tier Announcement: https://aws.amazon.com/about-aws/whats-new/2021/11/aws-price-reduction-data-transfers-internet/
• AWS WAF Pricing: https://aws.amazon.com/waf/pricing/
• Fastly Pricing: https://www.fastly.com/pricing
• Tailscale Pricing: https://tailscale.com/pricing
• ngrok Pricing: https://ngrok.com/pricing
• Google reCAPTCHA Billing: https://docs.cloud.google.com/recaptcha/docs/billing-information
• hCaptcha Plans: https://www.hcaptcha.com/plans

当你想让 AI 帮你实现一段动画时，最大的障碍往往不是技术，而是”词不达意”。你脑子里有画面，却说不出它叫什么。这篇文章整理了一套 Web 动画的通用词汇——掌握它们，你就能用一个词替代一整段含糊的描述，让人（和 AI）一听就懂。

做动画这件事，难的从来不是写几行 CSS 或调一个库，而是知道自己到底想要什么，并能精准地把它说出来。

很多人提需求时只能说”让它动得自然一点””加个酷炫的过渡”,这种描述既无法落地，也无法沟通。而真正懂行的人会说:”这里用一个 ease-out 的 scale in,配合 stagger 入场;切换时做 shared element transition。”——同样一句话,后者把模糊的感觉变成了可执行的方案。

下面这套词汇,按场景分门别类,涵盖了 UI 动画中绝大多数常见模式。建议收藏,提需求或写 prompt 时随手对照。

一、入场与退场（Entrances & Exits）

元素如何出现、如何消失。

二、编排与时序（Sequencing & Timing）

如何协调多个元素、多个瞬间。

三、移动与变换（Movement & Transforms）

改变元素的位置、大小或角度。

四、状态间的过渡（Transitions Between States）

把一个状态、视图或元素连接到另一个。

五、滚动（Scroll）

与滚动或视图切换绑定的动效。

六、反馈与交互（Feedback & Interaction）

回应用户的操作。

七、缓动（Easing）

速度在动画过程中如何变化。

八、弹簧动画（Spring Animations）

以物理为基础的运动，是固定时长缓动之外的选择。

九、循环与环境动效（Looping & Ambient Motion）

那些自顾自运行的动画。

十、打磨与特效（Polish & Effects）

把”好”和”卓越”区分开来的小细节。

十一、性能（Performance）

是什么让动效保持顺滑而不卡顿。

十二、值得了解的原则（Principles to Know）

指导”何时动、如何动”的理念。

写在最后

这套词汇真正的价值,不在于背下每一个名字,而在于它帮你建立起一种对动效的拆解视角:任何一段让你眼前一亮的交互,都可以被分解为”入场方式 + 缓动曲线 + 时序编排 + 收尾细节”的组合。

下次当你想说”让它动得高级一点”时,试着换成:”入场用 scale in 配 ease-out,多个元素 stagger 进场,hover 时加一点 spring 反馈”——你会发现,能说清楚的需求,才是能被实现的需求。

参考链接

Animation Vocabulary

NVIDIA 在台北的 Computex 2026 正式发布了面向 PC 的 RTX Spark SoC ，定位为 AI PC 平台，面向轻薄本、AI 开发、创意工作站和高端 Windows PC。

RTX Spark 最新发布重点

参数信息

GPU 的 6144 个 CUDA Core 规格接近桌面级 Nvidia RTX 5070，官方宣称 FP4 AI 算力达到 1 PFLOPS， 略高于 RTX 5070 的 AI 算力指标。

官方卖点

NVIDIA 宣称其是“史上能效最高的 PC 芯片”，发布会并未公布功耗信息，根据 泄漏信息 显示 TDP 约为 65-120W。

NVIDIA 强调的卖点：

• 本地运行 AI Agent
• 本地推理保护隐私
• 视频编辑、3D 渲染、AI 创作加速
• 高性能但低功耗的轻薄本体验

产品信息

微软、Dell、HP、Lenovo、ASUS 等厂商已宣布采用 RTX Spark 平台推出新的产品。

其中微软宣布 Surface Laptop Ultra 将在 2026 年秋季上市

总结

RTX Spark 标志着在云端 AI 生成占据统治地位的 NVIDIA 正式进入面向个人 AI 的 PC SoC 市场。

与传统 Windows PC 的 x86 + 独立显卡方案不同，RTX Spark 试图通过 ARM CPU、Blackwell GPU 与统一内存架构，打造类似 Apple Silicon 的高性能 AI PC 平台。

如果 NVIDIA 能兑现其能效与 AI 性能承诺，RTX Spark 有望成为未来高端 Windows AI PC 的重要选择。

参考链接

• NVIDIA 携手微软，在个人 AI 时代重塑 Windows PC
• NVIDIA GTC 台北 2026 主题演讲回放

通过 Claude Code 实现

如果要让 Claude Code 显示 5H \ 7 Day 额度以及上下文窗口使用情况只需要使用执行一下下面的命令:

1

/statusline show 5h quota, 7d quota, context usage

Claude Code 就会自己创建对应的脚本，更新 ~/.claude/settings.json

手动实现 macOS

Claude Code 会调用模型分析需求并自动生成脚本，因此会消耗一次正常的模型请求额度。

这里提供了我已经创建了的代码，还额外增加了 git branch 显示，可以直接复制使用

脚本依赖 jq，如果系统未安装，可以通过 Homebrew 安装：

1

brew install jq

创建 statusline-command.sh 文件

首先需要创建 ~/.claude/statusline-command.sh 文件，填入下面的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

#!/bin/sh
input=$(cat)

# Model display name
model=$(echo "$input" | jq -r '.model.display_name // empty')
# Git branch (skip optional locks to avoid hangs)
branch=$(git -C "$(echo "$input" | jq -r '.workspace.current_dir // empty')" \
  --no-optional-locks symbolic-ref --short HEAD 2>/dev/null)
# 5-hour quota
five=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
# 7-day quota
week=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
# Context used percentage
ctx=$(echo "$input" | jq -r '.context_window.used_percentage // empty')

parts=""

if [ -n "$model" ]; then
  parts="${parts}${model}"
fi

if [ -n "$branch" ]; then
  [ -n "$parts" ] && parts="${parts}  "
  parts="${parts}branch:${branch}"
fi

if [ -n "$five" ]; then
  [ -n "$parts" ] && parts="${parts}  "
  parts="${parts}5h:$(printf '%.0f' "$five")%"
fi

if [ -n "$week" ]; then
  [ -n "$parts" ] && parts="${parts}  "
  parts="${parts}7d:$(printf '%.0f' "$week")%"
fi

if [ -n "$ctx" ]; then
  [ -n "$parts" ] && parts="${parts}  "
  parts="${parts}ctx:$(printf '%.0f' "$ctx")%"
fi

printf "%s" "$parts"

编辑 ~/.claude/settings.json

然后编辑 ~/.claude/settings.json，在最后 } 前加入下面的内容
macOS:

1
2
3
4

"statusLine": {
  "type": "command",
  "command": "sh /Users/<User>/.claude/statusline-command.sh"
} 

需要把 <User> 替换为实际的路径

手动实现： Windows + Powershell7

创建 statusline-command.ps1

首先需要创建 ~/.claude/statusline-command.ps1 文件，填入下面的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# statusline-command.ps1
# 读取 stdin 的 JSON 输入
$input_raw = [Console]::In.ReadToEnd()
$data = $input_raw | ConvertFrom-Json

$parts = [System.Collections.Generic.List[string]]::new()

# Model display name
$model = $data.model.display_name
if ($model) { $parts.Add($model) }

# Git branch (skip optional locks to avoid hangs)
$branch = git --no-optional-locks symbolic-ref --short HEAD 2>$null
if ($branch) { $parts.Add("branch:$branch") }

# 5-hour quota（注意:用 $null 判断字段是否存在,使 0% 也能正常显示）
$five = $data.rate_limits.five_hour.used_percentage
if ($null -ne $five) {
    $parts.Add("5h:{0:N0}%" -f [double]$five)
}

# 7-day quota
$week = $data.rate_limits.seven_day.used_percentage
if ($null -ne $week) {
    $parts.Add("7d:{0:N0}%" -f [double]$week)
}

# Context used percentage
$ctx = $data.context_window.used_percentage
if ($null -ne $ctx) {
    $parts.Add("ctx:{0:N0}%" -f [double]$ctx)
}

# 用两个空格连接各部分,不输出换行
[Console]::Out.Write(($parts -join "  "))

编辑 ~/.claude/settings.json

然后编辑 ~/.claude/settings.json，在最后 } 前加入下面的内容
Windows :

1
2
3
4

"statusLine": {
  "type": "command",
  "command": "\"C:\\Program Files\\PowerShell\\7\\pwsh.exe\" -NoProfile -File \"C:\\Users\\<User>\\.claude\\statusline-command.ps1\""
}

需要把 <User> 替换为实际的路径

预览效果

macOS:

Windows:

新打开的窗口不生效

打开新窗口时，会发现没有额度使用信息，这是因为需要对话一下才会刷新。

调整显示信息

只需要打开 Claude Code 后，输入 /statusline 调整内容 即可让 Claude Code 自己进行调整了。

直接使用第三方包实现

如果不希望手动设置，有很多第三方包可以实现这个效果，比如很流行的查看模型使用情况的 ccusage 就提供这个功能。

https://ccusage.com/guide/statusline

ccusage 除了提供状态栏显示外，还能统计历史 Token、模型使用量以及额度消耗情况。

不过目前 Google 已推出一系列补救措施：

• 新版本增加数据导入提醒
• 永久提升 9 倍 每周额度

找回 Antigravity 代码编辑器

很多用户更新后发现，熟悉的 Antigravity 代码编辑器不见了：再次打开 Antigravity，看到的却是一个更接近 Codex 形态的独立 Agent 应用。

这并不是旧编辑器被直接移除，而是 Google 将原来的 Antigravity 编辑器更名为 Antigravity IDE，并和新版 Antigravity App 做了区分。因此，如果你想继续使用原来的代码编辑器体验，需要单独下载 Antigravity IDE。

下载链接：Download Google Antigravity IDE

Antigravity 旧版数据丢失问题

Antigravity IDE 不只是更新了软件名称、软件包名、配置路径也一同进行了修改，但是初版居然没有做数据导入指引，导致用户打开新的 IDE 后，像是直接丢失了全部数据。

目前版本打开后已增加了数据导入提醒，更新到新的版本再打开 Antigravity IDE 即可。

额度大降(补偿：周额度已永久增加 9 倍)

Antigravity 刚发布时额度是非常充足，后来不断降低额度，引入五小时限制、引入周限制，甚至直接高级模型移除五小时额度，额度一度降低到无法使用的程度。

后续略有恢复，没想到在 Google I/O 2026 大型更新时，月费 20 美元的 AI Pro 用户的额度居然只有免费额度的 4 倍：

甚至还取消了套餐内赠送的 AI 点数，对此 Google 解释：

但在我们即将推出的新用量限额模式下，您的使用体验应该不会受到影响。

然而实际情况却基本难以适应，社区反馈非常负面。

对此，Google 终于也坐不住了，连续两次宣布每周额度永久增加 3 倍，重置每周限额，相比最初限制，现在每周额度已增加九倍，也说明了一开始的额度限制有多么离谱。

对此 Google CEO Sundar Pichai 也不得不发 推文 声明。

Excited to see what you are building with Antigravity, We just 3xed the Antigravity limits again, but this time, the weekly quotas. Don’t stop building!
– 下午12:01 · 2026年5月22日

3 x 3 = 9 倍叠加提升已得到开发团队确认。

Varun Mohan @_mohansolo@X.com building @antigravity @GoogleDeepMind

不过目前规则下的额度与 Gemini APP 共享。

新版本优势

虽然这次更新带来了不少糟糕的体验，但并不是所有变化都对用户不利，Google 也确实加入了一些值得关注的新能力和套餐权益。

更快的 Gemini 3.5 Flash

超快的 Gemini 3.5 Flash，Antigravity 在 Gemini 3.5 Flash 4x 基础上进行专项优化，让输出速度提升至 12x ，不过这是 限时体验。

YouTube Lite 加入套餐权益

每月 20 美元的 AI Pro 套餐用户将获得 YouTube Lite 会员，可以免除广告: Get YouTube Premium Lite with Google AI Pro

结语

Antigravity 2.0 这次更新最大的问题，不是产品方向从 IDE 走向 Agent，而是迁移过程过于粗糙：旧编辑器入口突然变化、配置数据没有平滑继承、额度规则也在关键发布节点大幅收紧。

好在 Google 的补救来得还算及时，Antigravity IDE 已经重新明确入口，旧数据导入也补上了提醒，每周额度更是连续提升到原来的 9 倍。对于已经被这次更新折腾到的用户来说，现在最直接的处理方式就是重新下载 Antigravity IDE，并升级到最新版。

至于 Antigravity 2.0 本身能不能撑起 Google 所说的 Agents 驱动体验，还要看后续稳定性、额度政策和真实开发体验能不能跟上。至少这次事件已经说明再先进的 AI 产品，也不能把基础迁移和用户信任当成小问题。

“最前沿的 Agent 可能只触达过世界上 0.1% 的人。真正的问题，是怎么把这种前沿能力规模化交付给更广泛的用户。”
——Sundar Pichai

Google 这次要自己来做这件事。下面是它给出的答案。

一图速览：本次 I/O 七大重磅

一、3.5 Flash：把”Agent 经济账”摆上桌

Gemini 3.5 系列的第一款 3.5 Flash，在几乎所有基准上超越自家上代 Gemini 3.1 Pro。Pichai 特意点名的 GDPval（衡量”具有真实经济价值的任务”）上提升尤其明显。

但真正让它登上 keynote C 位的，是另一组数据：

• 速度：输出速度是其它前沿模型的 4 倍；在 Antigravity 2.0 中内置的优化版本可达 12 倍，质量不变。
• 价格：不到同档前沿模型的 一半。

Pichai 直接把性价比换算成账单摆给 CIO 们看：

“如果一家头部企业一天处理一万亿 token，把其中 80% 的负载从其它前沿模型迁到 3.5 Flash，一年能省下 超过 10 亿美元。”

Google 自己已经是这套打法最大的受益者。今年 3 月，Google 内部每天处理 5000 亿 token；现在每天超过 3 万亿，每隔几周翻一番。增长来源，是工程团队全面切换到 Antigravity 2.0 + 3.5 Flash 之后释放出来的需求。

更强大的 Gemini 3.5 Pro 没在这次发布 —— 预计将在下个月 2026 年登场，Pichai 透露：”内部在用，效果很好，但还在打磨”。

二、Gemini Spark：Google 的个人 Agent 终于落地

Spark 是这次回答”Agent 怎么走出 0.1%”最直接的产品：一个 7×24 跑在云端的个人 Agent，把 Google 全家桶串了起来。

它运行在 Google Cloud 的专用虚拟机上，底层是 Gemini 3.5，框架用的是 Google 内部的 Antigravity Harness。也就是说，笔记本合上、手机锁屏，它也能继续在后台跑长周期任务。

Google 给 Spark 设定的第一批场景并不科幻：从 Gmail、Docs、Sheets、Slides 里拉事实，写状态汇报；帮学生更新学习指南；替家长追踪学校时间表；给小企业盯收件箱，避免漏掉客户问题。

真正重要的不是这些 demo，而是它的落点：Spark 是 Google 把 Agent 从”聊天窗口”推进”真实数字生活”的第一只脚。它先接 Google 自家工具，随后开放第三方 MCP；入口先在 Gemini app，之后会进入邮件、聊天、Chrome，Android 上还有 Android Halo 显示执行进度。

节奏也很明确：先给受信任测试者，下周作为 beta 推给美国 Google AI Ultra 订阅用户。敏感操作前停下来确认，用户可以看到执行过程并随时打断——这套信任设计，是 Google 试图让普通人敢把任务交给 Agent 的前提。

三、Antigravity 2.0：正面对位 Claude Code 与 Codex

Antigravity 1.0 大约半年前（2025 年 11 月）发布，目前已有”数百万开发者在用”。2.0 的关键变化是定位转移——从”编程环境”升级为”多 Agent 编排平台”。

三层架构：

1. 桌面 App：与 Agent 交互的中央枢纽，可同时编排多个 Agent——一个写网站代码、一个生成品牌素材、第三个规划产品架构，互不打架
2. Antigravity CLI：命令行接口，留给想待在终端里的开发者
3. Antigravity SDK：最关键的一层——让程序可编程地访问驱动 Google 自家产品的同一套 Agent harness，与 Gemini 模型协同优化

一个内部案例：在尚未发布的 Gemini 3.5 Pro 支持下，让 93 个不同 Agent 协作，消耗 26 亿 token，从零搭建起一个复杂系统项目。

换句话说，Google 试图把内部正在使用的 Agent harness 以 SDK 形式开放给开发者。这是对 Claude Code 和 Codex 的正面对位。

Pichai 在沟通中的判断：

“开发者这个群体的好处是，你把东西做出来，如果真的好用，他们就会真的用。Antigravity 加 3.5 Flash 是相当魔幻的体验，特别是它有多快 —— 3.5 Flash 已经是其它前沿模型的 4 倍，在 Antigravity 里大约是 12 倍。”

更有说服力的支撑来自内部测试：用 3.5 Flash + Antigravity 2.0 跑多 Agent 协同，让 Agent 完全从零搭出了一个能跑的操作系统，API 耗费在 1000 美金以内。

附带发布：安全 Agent CodeMender

CodeMender 用 Gemini 的高级推理自动找出并修复关键代码漏洞，直接下笔补漏洞，等于接管”人来打补丁”那一步。当前邀请少数专家测试 API，更广泛开放”很快”推出。

Google 的逻辑：随着 Agent 写越来越多代码，cybersecurity 会更关键，agentic workflow 也是这个领域的必由路径。

四、Gemini app：彻底换新 + 全面降价

Gemini app 过去一年月活从 4 亿涨到 9 亿，日请求量翻 7 倍，覆盖 230 个国家、70 种语言。Google 把它定义为”世界上覆盖最广的 AI 助手”。

这次 Gemini app 的改版，表面上是新设计语言 Neural Expressive：动效、色彩、字体、触感反馈全换，回答也不再是一整面文字墙，而是图片、时间线、图表和 Gemini Live 混在一起的动态页面。

但它真正的变化，是从”问答 app”变成 Agent 的前台。Gemini Omni 直接进 app，用户可以上传照片或视频，套模板、改风格、生成视频，甚至创建一个看起来和听起来都像自己的 AI 化身。

Daily Brief 则是第一个开箱即用 Agent：每天早上整理 Gmail、日历和当天任务，排优先级，给下一步建议。它的前身是 2025 年 12 月在 Google Labs 上线的实验 CC，这次被收编进正式产品线。这个路径很能说明 Google 的打法：Labs 里跑通，Gemini app 里规模化。

5 月 19 日起，Neural Expressive 全球开放；Daily Brief 在美国面向 Google AI 订阅用户开放。

订阅价调整

2025 年 5 月 Google 才把顶级 Ultra 定在 249.99 美元，一年时间实际**降价 20%**，中间还加了一档。意图很清楚：把 Spark 这种重度 Agent 服务的通道铺宽，让普通付费用户也能摸到。

五、Gemini Omni：把 Veo 和 Nano Banana 揉进 Gemini 主架构

如果说 3.5 Flash 是为”让 Agent 跑起来”准备的，那么 Gemini Omni 是为”让 world model 真的成型”准备的。这部分由 Demis Hassabis 亲自发布。

Google 给 Omni 的定位是 **”能从任何输入生成任何输出模态的模型”**，先做视频输出，未来扩展到图像和文字。

• 第一款上线：Gemini Omni Flash，5 月 19 日起向 Google AI 订阅用户开放
• 入口：Gemini app、Google Flow、YouTube Shorts
• 水印：所有 Omni 生成或编辑的内容自带 SynthID
• Omni Pro：即将推出

Omni 与 Veo、Nano Banana 的关系

按 Google 自己的描述：

Omni 是 Gemini 主架构的进化，是 Gemini 一开始原生多模态底层设计的延伸——让原生多模态从输入端扩展到输出端。视频生成是切入点（离 Veo 最近），再把 Nano Banana 的编辑能力带进 Veo，让你像剪辑那样自然修改视频。本质上 Omni 是 Gemini 主线进化，Veo 和 Nano Banana 是它身上的能力组件。

Nano Banana 累计已生成超过 500 亿张图，Omni 这次把这个能力同等带到视频里。玩法包括纯文本生成视频，也包括上传自己的视频做改风格、换角色、保持时间一致性的连续编辑。

六、搜索 + 全家桶：Agent 进入 Google 每个角落

搜索框 25 年来最大一次升级

AI Mode 一周岁了——2025 年 I/O 才推出，现在月活超 10 亿，”上线以来每季度查询量翻倍”。

这次 AI Mode 升级到 Gemini 3.5 Flash 驱动。Google 搜索团队的判断是：用户已经开始把搜索当成更长、更具体、更跨模态的任务入口，而不是几个关键词。

所以 Google 改了那个最核心的入口——搜索框。新的智能搜索框会扩展，能容纳更口语化的长问题；AI 查询建议取代传统自动补全；文字、图片、文件、视频、Chrome 标签页都可以作为输入。AI Overviews 和 AI Mode 也被打通，用户可以从一个概览回答直接继续追问。

更关键的是，搜索框里开始长出 Agent。

Information Agents 让搜索从”查一次”变成”后台持续盯一件事”：用户可以创建 24/7 跑的 Agent，让它监控市场、房源、体育、购物或任何特定问题，条件触发后合成更新推送。

Generative UI 和搜索里的 mini-app，则是另一条线：把 Antigravity 和 Gemini 3.5 Flash 的 agentic coding 能力接进搜索现场。用户问一个复杂问题，搜索不只是返回答案，还能实时生成交互图表、模拟器、仪表盘甚至可持续使用的小工具。

这才是 Google 最可怕的分发能力：别人要教育用户去打开一个 Agent 产品，Google 只需要让搜索框多长出一层能力。

七、虽迟但到的 Google，用全栈布局对卷 Agent 赛道

过去一段时间 Google 在 Agent 的竞争里几乎缺席。这场 I/O 可以看出它的焦虑——它给出的答案是一套全栈布局：

• 模型层：3.5 Flash 用速度和价格把 Agent 的边际成本压到企业可接受的位置；Omni 把 world model 再推一步
• 产品层：
  • Spark 给所有人
  • Daily Brief 给所有 AI 订阅用户
  • Information Agents 与 Generative UI 让 Agent 进入 Google 最广泛的”渠道”——搜索框
  • Antigravity 2.0 给开发者提供 Claude Code 的直接”平替”
• 商业层：UCP、AP2、Universal Cart 让 Agent 进入真实交易场景
• 基础设施层：第八代 TPU 首次走”双芯片”分工——TPU 8T 专做训练，TPU 8I 专做推理。配合 JAX 与 Pathways，训练任务可跨多个数据中心、全球分布到超过 100 万颗 TPU——“世界最大的训练集群”

几个让 Anthropic 和 OpenAI 忌惮的数字

• Google 的 AI 在各个主要产品里的用户量级全部是十亿级别
• 5 个产品已各自有 30 亿用户
• 今年 capex 预计 1800–1900 亿美元，是 2022 年（310 亿）的 6 倍
• 每月跨自家产品处理的 token 达到 3.2 千万亿（quadrillion），是 2025 年 I/O 时 480 万亿的 7 倍

总结

把这些点连起来，Google 这次真正要证明的不是”我们也有 Agent”，而是：我们有能力把 Agent 变成默认入口。

模型足够快，边际成本才能压下来；Spark 跑在云端，Agent 才能真正离开用户设备；Gemini app 和搜索框提供日常入口，用户不用重新养成习惯；订阅价格下探，重度 Agent 服务才有机会从少数极客扩散到普通付费用户。

对开发者工具战场也是同一个逻辑。Antigravity 2.0 不是简单复制 Claude Code 或 Codex，而是在把竞争从”谁的代码补全更聪明”推向”谁能提供模型、运行环境、工具调用、sub-agent 编排和分发入口的一整套 Agent harness”。

如果这个判断成立，下一轮开发者工具竞争的单位就不再是 IDE 插件，而是平台级 Agent 编排系统。Claude Code、Codex、Antigravity 争的也不只是程序员的编辑器，而是谁能成为开发者让一群 Agent 持续工作的控制台。

所以，这场 I/O 更像是一个信号：Google 没有退出 AI 主战场，它只是选择用自己最熟悉的方式参战——把模型、产品、入口、基础设施和商业系统一起压上来。

Agent 赛道接下来不会只比谁的模型更聪明，也会比谁能把能力稳定、便宜、可信地送到最多人手里。Google 的优势正在这里重新变得清晰。

对普通用户来说，这反而是最好的局面：顶级大模型厂商越焦虑，工具就会越强、越便宜、越触手可及。每一次”轰炸式发布”背后，都是另一家公司被迫拿出更好的产品、定一个更低的价格。

Antigravity 2.0 与 IDE 下载页面：Download Google Antigravity

Antigravity CLI 安装方法

macOS / Linux

1

curl -fsSL https://antigravity.google/cli/install.sh | bash

Windows PowerShell

1

irm https://antigravity.google/cli/install.ps1 | iex

Windows CMD

1

curl -fsSL https://antigravity.google/cli/install.cmd -o install.cmd && install.cmd && del install.cmd

启动与登录方法

启动 Antigravity CLI

在终端中运行 agy 即可启动 Antigravity CLI。

登录方法

使用 Antigravity CLI 之前，如果已在 Antigravity 或 Antigravity IDE 中登录了 Google 账户，系统将自动进行认证。

初次启动需要选择代码主题，同意用户协议后即可打开 CLI 界面：

界面预览：

或者，您也可以选择以下认证方法手动登录：

• Google OAuth
• Use a Google Cloud project

选择 Google OAuth 后，如果没有自动跳转，可以通过粘贴认证代码的方法进行确认，因此也可以在其他设备上使用。

可选模型

Google AI Pro 用户在 Antigravity CLI 中可选的模型与 Antigravity IDE 一致：

• Gemini 3.5 Flash (High) (current)
• Gemini 3.5 Flash (Medium)
• Gemini 3.1 Pro (High)
• Gemini 3.1 Pro (Low)
• Claude Sonnet 4.6 (Thinking)
• Claude Opus 4.6 (Thinking)
• GPT-OSS 120B (Medium)

Antigravity CLI 介绍

Google 表示为了性能表现，使用 Go 语言完成了 Antigravity 的构建，同时 Google 也强调了 Antigravity CLI 的三个演进方向：更快执行、异步工作流，以及与 Antigravity 2.0 共用统一的 agent harness。

Antigravity CLI 优势：

• 执行速度更快：Antigravity CLI 使用 Go 语言编写，速度更快，响应更迅速。
• 异步工作流：Antigravity CLI 在后台协调多个代理来执行复杂任务，让您可以运行大规模重构或研究多个主题，而不会锁定您的终端会话。
• 统一架构：Antigravity CLI 与 Antigravity 2.0（新的 Antigravity 桌面应用程序）共享相同的代理框架，确保核心代理的所有未来改进都会自动应用到您使用它们的任何地方。

Gemini CLI 将终止服务

在推出了 Antigravity CLI 后，Google 表示，自 2026 年 6 月 18 日起，Gemini CLI 和 Gemini Code Assist IDE 扩展程序将停止为 Google AI Pro 和 Ultra 用户提供服务。

企业用户仍可继续使用。

总结

Antigravity 2.0 的发布，说明 Google 并没有把 AI 编程工具只当作 Gemini 模型的附属功能，而是在重新争夺“下一代代码编辑入口”。这次更新的重点，不是给传统 IDE 再加一个聊天侧边栏，而是把 Antigravity 从 agent-first IDE 升级成更完整的 agentic development platform：桌面端、CLI、SDK 和 API 一起构成新的开发者工作台。

对用户来说，这种竞争无疑是好事。无论是 Google、OpenAI、Anthropic 还是 Cursor，都在推动代码工具从“补全助手”走向“开发伙伴”。竞争越激烈，开发者能获得的选择越多，价格、体验、模型能力和工作流整合也会被不断拉高。最终受益的，还是每天真正写代码、调试和交付产品的用户。

不过一般攻击窗口时间都很短暂，只要不在相关时间内安装对应软件包即可避免。 pnpm 就提供了这一特性，minimumReleaseAge 是 pnpm 用来降低 npm 供应链攻击风险的配置。它的作用是：一个包的新版本发布后，必须经过指定分钟数，pnpm 才允许解析和安装它。

pnpm 官方说明该配置适用于所有依赖，包括传递依赖；它从 pnpm v10.16.0 开始加入，在 pnpm v11 中默认值变为 1440，也就是 1 天。

建议 pnpm 用户升级至 v11 ： pnpm - 从 v10 迁移到 v11

1. 为什么需要 minimumReleaseAge

很多供应链攻击的套路是：攻击者盗取维护者账号或发布流程，立刻发布一个恶意版本。恶意版本通常会在社区、平台或安全工具发现后被下架。pnpm 官方也建议通过 “延迟更新依赖” 降低安装受污染版本的概率，并说明延迟 24 小时通常可以避开许多高风险窗口。

1

minimumReleaseAge: 1440

表示只安装发布时间至少超过 1440 分钟，也就是 24 小时 的版本：

2. 前置条件：确认 pnpm 版本

minimumReleaseAge 从 pnpm v10.16.0 开始支持。

先检查当前版本：

1

pnpm -v

目前 pnpm 已发布 v11.1.3 版本，该配置默认就是 1440 。

如果项目里还没有固定 pnpm 版本，可以在 package.json 中添加：

1
2
3

{
  "packageManager": "pnpm@11.1.0"
}

注意 pnpm v11 要求 Node.js 22+

3. 把时间设置为一周

pnpm v11 在项目根目录会创建 pnpm-workspace.yaml 文件，可以直接修改该文件进行配置。

我们可以把时间设置为一周的时间 1440*7 = 10080

1

minimumReleaseAge: 10080

4. 常见取值

minimumReleaseAge 的单位是 分钟 。

5. 为特定依赖设置例外

有些包可能需要紧急升级，比如安全修复、内部包、框架核心包。这时可以使用 minimumReleaseAgeExclude 。

5.1 排除指定包

1
2
3
4
5

minimumReleaseAge: 1440

minimumReleaseAgeExclude:
  - webpack
  - react

这表示：大多数依赖必须发布满 1 天才能安装，但 webpack 和 react 可以立即安装。pnpm 官方文档 说明，minimumReleaseAgeExclude 会按包名排除，并作用于该包的所有版本。

5.2 排除组织作用域包

从 pnpm v10.17.0 开始， minimumReleaseAgeExclude 支持模式匹配。

例如，允许公司内部包立即安装：

1
2
3
4

minimumReleaseAge: 1440

minimumReleaseAgeExclude:
  - "@myorg/*"

5.3 只排除特定版本

从 pnpm v10.19.0 开始，minimumReleaseAgeExclude 支持精确版本，也支持用 || 写多个版本。

1
2
3
4
5

minimumReleaseAge: 1440

minimumReleaseAgeExclude:
  - nx@21.6.5
  - webpack@4.47.0 || 5.102.1

这比直接排除整个包更安全，适合临时放行某个已验证版本。

6. 推荐的项目配置模板

下面是一份适合团队项目直接落地的配置：

1
2
3
4
5
6
7
8
9
10
11
12
13

packages:
  - "apps/*"
  - "packages/*"

# 新发布版本至少等待 24 小时再安装
minimumReleaseAge: 1440

# 显式开启严格模式：如果没有满足发布时间要求的版本，则安装失败
minimumReleaseAgeStrict: true

# 私有包或已验证的紧急修复版本可以临时放行
minimumReleaseAgeExclude:
  - "@your-company/*"

minimumReleaseAgeStrict 是 pnpm v11 新增的行为控制项。官方文档说明：当没有版本满足 minimumReleaseAge 约束时， true 会让解析失败， false 则允许回退到不满足约束的版本；如果你显式配置了 minimumReleaseAge ，严格模式默认开启。

7. 在 CI 中引入

CI 里建议同时做两件事：

第一，固定 pnpm 版本：

1
2
3

{
  "packageManager": "pnpm@11.1.0"
}

第二，使用锁文件安装：

1

pnpm install --frozen-lockfile

这样 CI 不会随意解析新版本， minimumReleaseAge 主要会在新增依赖、更新依赖、刷新 lockfile 时发挥作用。

典型 GitHub Actions 示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

name: CI

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm

      - run: pnpm install --frozen-lockfile
      - run: pnpm test

8. 如何验证配置是否生效

可以尝试安装一个刚发布不久的版本：

1

pnpm add 某个刚发布的包@latest

如果该包版本发布时间没有达到配置的分钟数，pnpm 会避免解析该版本，或者在严格模式下直接失败。

更常见的验证方式是在更新依赖时观察 lockfile：

1

pnpm update

如果最新版本太新，pnpm 不会马上把它写入 pnpm-lock.yaml。

9. 常见问题

Q1： minimumReleaseAge 会影响传递依赖吗？

会。pnpm 官方文档明确说明该配置适用于所有依赖，包括传递依赖。

Q2 ：pnpm v11 还需要手动配置吗？

pnpm v11 默认 minimumReleaseAge: 1440，也就是默认延迟 1 天。
如果你想更严格，需要手动改成 2880 或 10080；如果你想关闭，可以设置为：

1

minimumReleaseAge: 0

pnpm 官方供应链安全文档也说明，在 pnpm v11 中该值默认是 1440，如需退出该行为，可在 pnpm-workspace.yaml 中设置为 0。

Q3 ：急需升级安全补丁怎么办？

推荐只临时放行具体版本：

1
2
3
4

minimumReleaseAge: 1440

minimumReleaseAgeExclude:
  - vite@x.y.z

处理完成后，再删除这个例外。

Q4：私有 registry 没有发布时间怎么办？

pnpm v11 提供了 minimumReleaseAgeIgnoreMissingTime。当为 true 时，如果 registry 元数据没有 time 字段，pnpm 会跳过该包的 minimumReleaseAge 检查；如果设为 false，则在缺失时间信息时失败。

更严格的配置：

1
2

minimumReleaseAge: 1440
minimumReleaseAgeIgnoreMissingTime: false

10. 最佳实践总结

推荐从这个配置开始：

1
2

minimumReleaseAge: 1440
minimumReleaseAgeStrict: true

如果是 monorepo 或企业项目，可以加上内部包例外：

1
2
3
4
5
6
7
8
9

packages:
  - "apps/*"
  - "packages/*"

minimumReleaseAge: 1440
minimumReleaseAgeStrict: true

minimumReleaseAgeExclude:
  - "@your-company/*"

11. 其他包管理器如何设置

• npm : 在 .npmrc 中， min-release-age=X 。X 是 天 的数量。需要 npm v11.10.0 或更高版本。
• Yarn : 在 .yarnrc.yml 中，设置 npmMinimalAgeGate: X。
  X 是持续时间（支持的日期单位是 ms, s, m, h, d, w，例如 7d）。如果没有指定持续时间，则解析为分钟（即 npmMinimalAgeGate: 1440 等于 npmMinimalAgeGate: 1440m）。需要 Yarn v4.11 或更高版本
• Bun : 在 bunfig.toml 中，设置：

  1 2 3

  [install] minimumReleaseAge = X

  X 是秒数。需要 Bun v1.3.0 或更高版本。

参考链接

• 缓解供应链攻击 - pnpm
• 设置（pnpm-workspace.yaml） - pnpm

2025 年至今，针对 npm、PyPI、GitHub Actions、Docker Hub 的供应链攻击事件持续走高：被污染的依赖、被劫持的 CI Token、被钓鱼的维护者账号……攻击者越来越偏好「绕过你的代码、直接拿你的凭证」的低成本路径。

而开发者最容易忽略的一处 “凭证仓库” ，恰恰是每天都在用、却几乎从不审计的：Shell 历史记录文件。

• macOS / Linux：~/.zsh_history、~/.bash_history
• Windows PowerShell：%APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

这些文件以 明文 保存你输入过的所有命令——包括误粘贴的 API Key、带密码的 URL、订阅链接、数据库连接串。一旦你的电脑被恶意 npm 包、伪装 VSCode 插件、或被入侵的 CLI 工具读取到这些路径，攻击者无需提权就能直接打包带走。

但是有时也的确会需要在命令中输入密钥，比如 export API_KEY=，本文给出两件可立刻落地的小事：

1. 写命令时：让敏感命令一开始就不进历史。
2. 写完之后：定期扫一遍历史文件，看看自己是不是早就漏过。

一、macOS / Linux：在命令前加一个空格

bash 和 zsh 都支持 HISTCONTROL / HIST_IGNORE_SPACE —— 一旦开启，以空格开头的命令不会被写入历史文件，也不会出现在 ↑ 历史回溯里。

很多发行版或 shell 框架可能已经启用启用了这个特性。验证一下：

1
2
3
4
5

# bash - 期望包含 ignorespace 或 ignoreboth
echo "$HISTCONTROL"   

# zsh - 期望看到 histignorespace
setopt | grep histignorespace   

如果没有，加入你的 ~/.bashrc 或 ~/.zshrc：

1
2
3
4
5

# bash
# ignorespace + ignoredups
export HISTCONTROL=ignoreboth   
# zsh
setopt HIST_IGNORE_SPACE

之后，敏感命令前面加一个空格即可：

1
2

 export OPENAI_API_KEY="sk-..."
curl -H "Authorization: Bearer $TOKEN" https://api.example.com

退后退出本次终端(将命令写入历史记录文件)，重新打开，使用下面的命令验证：

1

tail -n 5 ~/.zsh_history

1

tail -n 5 ~/.bash_history

二、Windows PowerShell：用 AddToHistoryHandler 自己实现

PowerShell 没有内置「前导空格不入历史」的开关，但 PSReadLine 提供了 AddToHistoryHandler，可以自定义哪些命令进历史。

配置步骤

打开（或创建）你的 PowerShell profile：

1

notepad $PROFILE

写入：

1
2
3
4
5
6
7
8
9

Set-PSReadLineOption -AddToHistoryHandler {
    param([string]$Line)

    if ($Line.StartsWith(' ')) {
        return $false
    }

    return $true
}

保存后，重启 PowerShell。之后像这样以空格开头输入的命令，不会写入当前会话历史，也不会落盘到 ConsoleHost_history.txt：

1
2

# ...
  curl https://example.com/secret-url 

PSReadLine 文档明确说明：handler 返回 $false 等同于 SkipAdding，当前会话和历史文件都不会保留这条命令。

这只影响之后输入的新命令；已经写进 ConsoleHost_history.txt 的内容不会被清理。

三、回头审计：你的历史里早就有什么？

加了开关只是治未病。下一步是翻账——很多人第一次扫描自家 ~/.zsh_history 都会被吓到。

下面这一组命令面向 zsh，bash 用户把路径换成 ~/.bash_history 即可。

1. 先看文件大小，心里有数

1

ls -lh ~/.zsh_history

2. 排查常见密钥/密码关键词

1

grep -nEi 'api[_-]?key|apikey|secret|token|password|passwd|pwd|authorization|bearer|credential|client_secret|access[_-]?key|private[_-]?key|OPENAI_API_KEY|ANTHROPIC_API_KEY|GITHUB_TOKEN|GH_TOKEN|NPM_TOKEN|AWS_ACCESS_KEY_ID|AWS_SECRET_ACCESS_KEY|DATABASE_URL|MONGODB_URI|REDIS_URL' ~/.zsh_history

3. 排查典型 Token 格式

1

grep -nE 'sk-[A-Za-z0-9_-]{20,}|github_pat_[A-Za-z0-9_]{20,}|gh[pousr]_[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}' ~/.zsh_history

覆盖：OpenAI / Anthropic 风格 sk-…、GitHub Fine-grained PAT、Classic PAT、AWS Access Key、Google API Key。

4. 排查带账号密码的 URL

1

grep -nEi 'https?://[^[:space:]/@:]+:[^[:space:]/@]+@' ~/.zsh_history

形如 https://user:password@host/... —— 在 git clone、curl、psql 里非常常见。

5. 排查环境变量赋值

1

grep -nEi '(\$?[A-Z0-9_]*(KEY|TOKEN|SECRET|PASSWORD|PASS|PWD|URL|URI|AUTH|CREDENTIAL)[A-Z0-9_]*=|export [A-Z0-9_]+=)' ~/.zsh_history

抓 export FOO_TOKEN=...、API_KEY=... 这类一行式赋值。

6. 排查 curl / 请求头泄漏

1

grep -nEi '(curl|wget|httpie|http) .*(Authorization|Bearer|X-API-Key|api-key|token)' ~/.zsh_history

7. 排查云服务 / 部署工具的登录与密钥命令

1

grep -nEi '\b(aws|az|gcloud|vercel|netlify|supabase|firebase|docker|npm|pnpm|gh)\b.*\b(login|auth|token|secret|credentials|env)\b' ~/.zsh_history

8. 排查订阅 / 科学上网链接

1

grep -nEi '(subscription|shadowrocket|clash|mihomo|vless://|vmess://|trojan://|ss://|trojan|proxy)' ~/.zsh_history

9. 排查 URL 中的 UUID（常见于订阅链接）

1

grep -nEi 'https?://[^[:space:]]*[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}[^[:space:]]*' ~/.zsh_history

四、命中了之后怎么办？

主动审查后，可以选择删除本地的历史记录，如果担心凭证存在泄漏风险。 可以按照优先级建议排查：

1. 真实的 token / API key（OpenAI、Anthropic、GitHub PAT、NPM Token……）—— 立刻去对应平台 revoke 并重新签发。
2. 订阅 URL / VPN 节点链接 —— 重置 UUID 或 token，旧链接会一直被滥用流量。
3. 数据库连接串、Redis / MongoDB URI —— 改密码，必要时调整网络访问白名单。
4. 带密码的 HTTP(S) URL —— 改密码，并检查 git remote、~/.netrc 等地方是否同步残留。
5. 云服务凭证（AWS Access Key、GCP Service Account JSON 内容）—— 走云厂商的 rotate 流程，并检查 CloudTrail / Audit Log 是否有异常调用。

五、把好习惯固化下来

• 行首加空格这件事，要练成肌肉记忆：复制任何含密钥的命令，先按一下 Space 再粘贴。
• 能用文件读取的就不要写在命令行：curl --header @auth.txt、gh auth login --with-token < token.txt、docker login --password-stdin 都是更好的形态。
• 真敏感的密钥，长期方案是放进 **macOS Keychain / Windows Credential Manager / pass / 1Password CLI / gh secret**，让命令行里只出现引用名，不出现明文。
• 给自己设一个每月一次的「翻历史」提醒——供应链事件大多在事发后才被披露，定期回头审计比一次性清理更重要。

终端历史不是你的备忘录，是攻击者的字典。少留一点东西在里面，下次出事的时候，你就少一份要连夜轮换的清单。

这不是一次普通的恶意包投放事件。攻击者并未简单依赖窃取 npm 凭据，而是利用 GitHub Actions、缓存污染、OIDC Token 滥用、恶意依赖、持久化守护进程以及多通道 C2 基础设施，构建了一条完整的供应链入侵链路。

TanStack 相关恶意版本发布具体时间：北京时间 5 月 12 日凌晨 3:20 至 3:26（UTC+8）

一、事件概览

本次攻击影响了 npm 与 PyPI 两大生态中的多个高价值包。

主要受影响的软件包：

• @tanstack 下的软件包，例如 @tanstack/react-router，这是 React 生态中最广泛使用的路由库之一，每周下载量约 1200 万次， @tanstack/vue-router 也受到影响。
• @uipath 下的软件包，包括 UiPath 企业自动化平台相关工具、CLI 与 Agent SDK
• @mistralai/mistralai，即 Mistral AI 官方 TypeScript 客户端
• @opensearch-project/opensearch
• PyPI 上的 mistralai: 2.4.6
• PyPI 上的 guardrails-ai : 0.10.1

npm 团队已经注意到该攻击活动，并快速移除了恶意版本。

可以在文章结尾查看已知的具体受影响的软件包。

二、TanStack 攻击链：GitHub Actions 成为突破口

TanStack 的失陷源于一条针对 GitHub Actions 的复杂漏洞利用链（包含三个漏洞）：

攻击链大致如下：

1. 攻击者 fork 了 TanStack/router 仓库。
2. 攻击者将 fork 后的仓库重命名为 zblgg/configuration 规避了 Fork 列表的审查。
3. 攻击者提交 Pull Request，触发目标仓库中的 pull_request_target 工作流。
4. 该工作流错误地 checkout 并执行了攻击者 fork 中的代码。
5. 攻击者借此污染 GitHub Actions 缓存，将恶意 pnpm store 写入缓存。
6. 后续合法维护者的 PR 被合并到 main 分支时，release workflow 恢复了被污染的缓存。
7. 攻击者控制的二进制文件从 GitHub Actions Runner 的进程内存中读取 OIDC Token。
8. 攻击者使用这些 Token 发布恶意 npm 包版本。

这一链路最值得关注的地方在于：攻击者无需窃取 npm 凭据，也能完成恶意包发布。

这说明在现代软件供应链中，包管理账号本身已不再是唯一的关键资产。CI/CD 工作流、缓存、OIDC Token、发布权限和工作流边界同样是高价值攻击面。

UiPath 的感染变种

在 @tanstack 受到攻击后不久，@uipath 也宣告失陷。这些包使用一个预安装脚本（node setup.mjs）下载 Bun 运行时环境并执行恶意 payload。这与之前 SAP 失陷事件中的交付机制相同。UiPath 变种使用了重新混淆过的 payload 和不同的 Campaign Key，但连接的是相同的 C2（命令与控制）基础设施。

三、恶意 Payload：凭证窃取与蠕虫式传播

本次恶意 payload 具备自我传播能力，主要窃取以下类型的凭据和身份材料：

它主要锁定以下目标：

• CI/CD 令牌（GitHub Actions OIDC、GitLab、CircleCI）
• 云服务凭证（AWS IMDSv2、GCP、Azure）
• Kubernetes 服务账号
• HashiCorp Vault
• Package registry tokens

蠕虫行为：恶意软件会使用窃取来的 npm 令牌和 GitHub Actions OIDC 令牌，进一步向受害者拥有写入权限的其他包发布投毒版本，从而在 npm 生态系统中像蠕虫一样迅速蔓延。

破坏性的本地守护进程

如果恶意软件发现了有效的目标 ghp_ 开头的 GitHub Personal Access Token 或 gho_ 开头的 OAuth Token，它在本地会安装一个持久化守护进程：

macOS：

1

~/Library/LaunchAgents/com.user.gh-token-monitor.plist

Linux：

1

~/.config/systemd/user/gh-token-monitor.service

如果它因 GitHub 令牌被撤销而收到 40X 错误，该进程会尝试执行 rm -rf ~/，直接清空用户主目录！ 不过该守护进程会在运行 24 小时后自动退出。

注：与之前的 Mini Shai-Hulud 变种一样，该恶意软件会检查系统是否配置为俄语，如果是，则直接终止运行，不窃取任何数据。

四、检查指南

1. 排查软件包：搜索 lockfiles 和 CI 日志，是否出现受影响的软件包版本。检查包根目录下是否存在 router_init.js 或 setup.mjs。
2. 检查并清除持久化威胁：在开发者机器上搜索 gh-token-monitor 守护进程并将其删除（路径见下方指标）。
3. 轮换所有凭证：如果怀疑受到影响，请立即轮换 GitHub 令牌、npm 令牌、AWS 凭证、Vault 令牌、Kubernetes 服务账号和 CI/CD 机密信息。

   警告：在吊销 GitHub 令牌之前，请务必先检查并移除持久化守护进程，以免触发恶意软件的（rm -rf ~/）命令。

4. 检查 IDE 目录：检查 .claude/ 和 .vscode/ 目录中是否残留 router_runtime.js 或 setup.mjs。这些文件在执行 npm uninstall 后仍可能驻留。
5. 屏蔽 C2 目标域名：在 DNS/代理层面拦截 git-tanstack.com 以及 *.getsession.org。

文件

网络 IOC

其他特征

五、受影响的软件包

PyPI

• guardrails-ai@0.10.1
• mistralai@2.4.6

NPM

结语

这次攻击展示了供应链攻击的新趋势：攻击者不再只盯着包管理器账号，而是将 GitHub Actions、缓存、OIDC、开发者终端、CI/CD Secret 和开源包发布流程串联成完整攻击链。

对于安全团队而言，单纯“升级依赖”已经不够。真正有效的防护需要覆盖从代码提交、CI 执行、凭据签发、包发布到开发者本地环境的全链路。

这次事件也再次提醒我们：CI/CD 是生产系统的一部分，依赖包是执行代码的一部分，开发者机器也是供应链边界的一部分。

参考资料

• Mini Shai-Hulud Strikes Again: TanStack + more npm Packages Compromised
• Supply Chain Attack Affecting Numerous npm and PyPI Packages
• TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply-Chain Attack

同时使用两个 ChatGPT 账户的方法(CC-Switch)

同时使用两个账户时，我们可以使用 CC-Switch 快速切换账户，而不必重新登陆。

登录了一个账户后，在 CC-Switch 的 Codex 应用中添加一个新的 OpenAI Offical 供应商即可，不过我们启用新的供应商后，再执行 codex 可能会遇到账户错误的提示:

1

Error: account/read failed during TUI bootstrap: account/read failed: email and plan type are required for chatgpt authentication (code -32600)

可以直接执行下面的命令，使用设备代码为第二个账户进行登录认证。

1

codex login --device-auth

但是基于安全原因，设备代码认证默认是关闭的，可以参考下面的方法开启。

启用设备代码身份验证

团队的管理员在网页上访问 工作空间设置 > 权限与角色 ，在右侧开启 为 Codex CLI 启用设备代码身份验证 的选项即可。

https://chatgpt.com/admin/permissions

然后就可以正常使用使用设备代码完成认证了。

Anthropic 表示这是一个全新的通用语言模型，该模型在各个方面都表现出色，尤其在计算机安全任务方面更是卓越非凡。

在 Anthropic 的测试中，新的模型在网络安全领域展现了超凡能力，能够在用户指示下，识别并利用所有主流操作系统和主流浏览器中的零日漏洞。

以下是 Anthropic 提供的应用示例：

• 发现了一个在 OpenBSD 中存在了 27 年的漏洞 (OpenBSD 是一个以其安全性著称的操作系统) 。
• 编写了一个 Web 浏览器漏洞利用程序，将四个漏洞串联起来，绕过了浏览器的沙箱保护。
• Mythos Preview 自主识别出 FFmpeg 最流行的编解码器之一 H.264 中一个存在了 16 年的漏洞。
• Mythos Preview 完全自主地识别并利用了 FreeBSD 中一个存在了 17 年的远程代码执行漏洞，该漏洞允许任何人获取运行NFS 的机器的 root 权限。
• Mythos Preview 发现了一些 Linux 内核漏洞，这些漏洞允许攻击者进行越界写入（例如，通过缓冲区溢出、释放后使用或双重释放漏洞）。

具体内容可以查看原文链接：Assessing Claude Mythos Preview’s cybersecurity capabilities

根据 Mythos Preview 在测试中表现的能力，Anthropic 表示这揭示了一个严峻的事实：人工智能模型的编码能力已经达到了极高的水平，在发现和利用软件漏洞方面，它们几乎可以超越除最熟练的人类之外的所有人。

因此 Anthropic 启动了 Glasswing 项目，汇集所有顶尖企业包含 Amazon、Anthropic、苹果、博通、思科、CrowdStrike、谷歌、摩根大通、Linux 基金会、微软、英伟达等企业，旨在保护世界上最关键的软件。

如果事实真如 Anthropic 所言，这将标志着 AI 正在重写网络安全的底层规则，我们构建了几十年的数字防线正面临前所未有的危机，“识别漏洞” 将从从人类专家的漫长审计变为 AI 模型的本能。

而我们普通用户在短期内将无法接触到这一模型，这不免也是一种遗憾。

2026 年 3 月 12 日，Google 再一次收紧了 AI Pro 用户的 Antigravity 高级模型调用额度，给 Gemini 3.1 Pro 模型也添加了每周刷新限制，不过达到限制时可以通过消耗 Google AI Credits 继续使用，本文将介绍如何查看 Antigravity 不同模型的剩余额度与 Google AI Credits 的剩余点数。

网页上访问 https://one.google.com/ai/activity 即可查看 AI 点数的剩余情况。

查看 Antigravity IDE 剩余额度

如果你没有安装查看额度的插件，可以在 Antigravity IDE 中的右上角点击齿轮图标，选择 Open Antigravity IDE User Settings，在打开的窗口左侧点击 Models 即可查看不同模型的当前额度剩余情况。

Update: 3 月 13 日，打开 Antigravity IDE 设置页面可以看到已重新恢复高级模型的五小时刷新机制，但根据观察使用额度超出 40% 即会变为一周刷新。

Update: 5 月 20 日，编辑器改名 Antigravity IDE 后优化了额度刷新机制，不再是 5 小时内使用过多后直接变为一周刷新。

查看 Google AI Credits 剩余额度

在模型额度界面，我们可以看到有一个开关选项 Enable AI Credit Overages，开启后可以通过消耗 AI Credits 来使用模型。

When toggled on, Antigravity will use your AI credits to fulfill model requests once you’re out of model quota. Antigravity will always use your model quota first before using AI credits.

如果你是 Google AI Pro / Ultra 会员，除了自带了额度以外，每月还可以固定获取一定的 AI 积分。

其中 Pro 会员每月可以获得 1000 点， Ultra 会员则是 25000 点。

2026 年 5 月 Google 在 Google IO 2026 宣布套餐内不再赠送 AI 点数。

如果你想查看点数的剩余情况，开启选项即可查看:

如果是家庭组用户，这个点数是所有家庭成员共享的。

在使用 Google Antigravity 通过 SSH 连接运行在 PVE 的 Linux 虚拟机 时，会直接崩溃，报错信息如下：

Antigravity server crashed unexpectedly. Please restart to fully restore AI features.

解决方案

在 PVE 中将 Linux 虚拟机的 CPU 类型 设置为 host，再尝试连接就可以了。

参考： Antigravity crashes on Linux, but works on Windows

今天 Anthropic 发布了最新的 Claude Opus 4.6 ，官方表示 Claude Opus 4.6 在编码能力上超越了前代产品。它规划更周密，能够更长时间地执行代理任务，在大规模代码库中运行更可靠，并且拥有更强大的代码审查和调试能力，可以更有效地发现自身错误。

并且在 Beta 版本中 Opus 模型首次支持 1M tokens 上下文，API 价格方面保持不变。

Claude Opus 4.6 目前已在 API、Claude Code 中可用。

更新 Claude Code

运行下面命令即可：

1

npm install -g @anthropic-ai/claude-code

Anthropic 赠送付费用户 50 美元

在推出新模型的同时，Anthropic 还提供给已订阅 Claude Pro / MAX 的用户 50 美元的 福利，用于体验最新的模型。

需要手动领取，只需访问 https://claude.ai/settings/usage 点击 Claim 即可。

领取条件

领取 50 美元满足下面的条件：

• 在 2 月 4 日之前开通了 Claude Pro / MAX 订阅套餐
• 在 2 月 16 日之前开启 extra usage

所以如果你 在 2 月 4 日之前没有订阅 Claude Pro，无法领取优惠。

有效期

领取的 50 美元余额有效期为 60 天。

截止日期

在 2 月 16 日之前都可以领取，如果你正在订阅 Claude Pro / MAX，领取你的优惠吧。

Kimi 是 月之暗面 (Moonshot AI) 推出的系列模型，最新版本是 Kimi K2.5，点击这里查看 Kimi K2.5 模型介绍

Kimi K2.5 版本是原生的多模态架构设计，同时支持视觉与文本输入、思考与非思考模式、对话与 Agent 任务。最新版本主要特色：

• 代码能力跨越式提升
• 超长上下文支持
• 长思考能力

Kimi K2.5 版本获得了广泛的好评，尤其是在代码编辑方面，在付费使用之前，我们可以在 OpenCode 中 免费 使用 Kimi K2.5 版本。

Update: 2025.03 OpenCode Kimi 2.5 的免费体验已经结束，现在可以免费使用的是 MiniMax 2.5

什么是 OpenCode

OpenCode 是一款开源的代码助理软件，终端版本类似 Claude Code，可帮助您使用任何 AI 模型编写和运行代码。它提供基于终端的界面(TUI)、桌面应用程序或 IDE 扩展三种形式。

安装更新 OpenCode

如果你尚未安装 OpenCode 或是没有更新到最新的版本，执行下面的命令

1

npm i -g opencode-ai

然后运行 opencode 即可打开 TUI 界面

1

opencode

切换模型为 Kimi K2.5

在 OpenCode 的 TUI 界面，执行 /models ，即可打开模型选择列表

然后选择 Kimi K2.5 Free 即可开始体验。

然后就可以开始对话了！

不过毕竟是免费，使用时可能会遇到 rate limit... 的提示，通常等一下会自动重新尝试，因此只能作为免费体验。

价格

如果使用 API ，每 100 万(1M) tokens 价格为：

汇率按照 7 计算，Kimi K2.5 的价格与 Gemini 3 Flash 接近。

Kimi Code Plan

Moonshot 提供 Kimi Code Plan 包月套餐，价格可以看这里 会员权益说明。

如果访问的是国际版，价格贵了非常多，看描述额度多一些。

在付款前可以看看 我花了4.99元，测了一把Kimi新出的「代码神器」

Claude Code 相关

开通 KimiCode 后是可以直接在 控制台 获取 API Key ，用于在 Claude Code 中使用，官方明确 说明 不禁止在 Claude Code 中使用，但不支持其他产品。

目前，该应用已率先登陆 macOS 平台，Windows 版本也正在准备中。

核心功能：让 AI 深度介入工作流

Codex App 的推出标志着 OpenAI 从“对话式 AI”向“协作式/自动化 AI”的重大跨越。其核心亮点包括：

• 多任务并行（Multitask Effortlessly）：
  用户可以同时运行多个智能体处理不同任务。通过 Worktrees（工作树） 机制，系统能确保不同智能体所做的更改相互隔离，互不干扰，像管理代码分支一样管理 AI 的产出。

• 技能封装（Create & Use Skills）：
  用户可以将特定的工具组合与操作规范打包成通用的 Skills 。这些 Skill 可以被重复调用，赋予智能体更强的专业执行力，Codex APP 安装后即内置了很多 Skill，可以做到开箱即用。
  

• 后台自动化（Set up Automations）：
  通过设置定时工作流（Scheduled Workflows），用户可以将重复性的繁琐工作完全委托给 Codex。即使在后台，智能体也能根据预设逻辑自主完成任务。
  

发布福利：限时免费与额度翻倍

为了庆祝 Codex App 的上线，OpenAI 首席执行官 Sam Altman 宣布了为期 2 个月 的重磅福利政策：

• 门槛降低： 免费用户（Free）及入门级用户（Go）在未来两个月内也可获得使用权限，体验最新的智能体构建功能。
• 付费用户额度翻倍： 所有付费订阅用户（Plus、Pro）的 Rate Limits（速率限制/额度）直接翻倍。

To celebrate the launch of the Codex app, we doubled all rate limits for paid plans for 2 months!
And added access for free/go.
— @Sam Altman

下载地址

访问 https://openai.com/zh-Hans-CN/codex/get-started/ 即可获取。

支持模型

目前 Codex APP 中支持 GPT 5.2 与 GPT 5.2-Codex 模型，都包含 Medium、High、Extra High 等各种模式。

与 Codex Web 联动

如果打开 Github 的项目，Codex APP 可以与 Codex Web 联动，选择在云端执行任务。

Codex 生态：全场景的 AI 开发闭环

随着桌面版的发布，OpenAI 终于补齐了最后一块拼图，构建起了一个覆盖云端、终端与桌面的全方位 AI 开发生态。无论你的工作习惯如何，Codex 都能无缝融入：

• Codex Web (ChatGPT) —— 随时随地的云端协作 深度集成于 ChatGPT 网页端与 App 中。连接 GitHub 后，无需配置任何本地环境，即可直接读取仓库、审查代码或提交轻量级修改。非常适合 Code Review 或快速修复 Bug。
• Codex CLI —— 极客的终端利器 专为开发者打造的命令行工具。将 AI 注入终端，让你无需离开熟悉的 Shell 环境，仅凭自然语言指令即可完成代码生成、文件编辑和脚本执行，完美契合现有的命令行工作流。
• Codex App —— 终极“指挥中心” 生态的核心枢纽。作为功能最完整的桌面客户端，它不仅拥有最强的本地读写权限，更是调度多智能体（Agents）并行协作、运行后台自动化任务的“总控台”，专门应对复杂的工程级挑战。

Codex Web 与 Codex CLI 仍然是代码编写工具，Codex App 作为易用的 GUI 客户端，凭借 Agent Skill 加持，生态不再仅仅是辅助写代码的 Copilot，而是扩展到通用领域，致力于成为能听懂意图、自动执行、全天候待命的“硅基合伙人”，并且也让更多的人可以体验使用到 AI Agents。