Gemini CLI 今日停止面向个人用户服务，Agent 工具链开始重做安全与运行底座

今日主线：AI 开发工具的竞争正在从“多一个模型入口”转向“重做整条运行链路”。入口被合并，默认安全策略被收紧，资源发现、持久执行、上下文管理和沙箱成本则开始形成更明确的工程方案。

今日重点

1. 1. Gemini CLI 今日停止面向个人用户提供请求服务：Google 将个人开发者迁移到 Antigravity CLI，AI Coding 入口进一步向统一的多 Agent 平台收拢。
2. 2. GitHub Actions 开始默认阻断常见 pwn request：actions/checkout v7 拒绝在高权限事件中检出来自 fork 的未审查代码，供应链安全从文档提醒走向产品强约束。
3. 3. Agent 运行底座继续拆层：Cloudflare 开放运行原语，阿里云用任务调度配合沙箱休眠，行业开始正面处理恢复、隔离和闲置成本。
4. 4. 开放生态补上“怎么找到能力”：ARD 试图为工具、Skill、MCP Server 和 Agent 建立跨组织的发现与信任层。

行业

阿里云在日本启用第五座数据中心，Model Studio 与 Qwen3.7-Plus 同步落地

阿里云宣布在东京启用日本第五座数据中心，使其全球基础设施扩展到 32 个地域、105 个可用区。除了计算、存储、容器、数据库等基础服务，Model Studio 也开始在日本地域提供服务，日本开发者可使用 Qwen3.7-Plus 和第三方模型，相关 AI 原生数据库与数据分析服务也一并上线。

这类扩张的关键不是再多一个机房，而是模型平台、推理服务和数据工具开始按地域成套落地。企业采用 Agent 时，数据驻留、时延、审计和模型供应往往比单次评测分数更能决定能否上线。模型公司的全球竞争，正在越来越像云平台竞争。

来源：https://www.alibabacloud.com/blog/alibaba-cloud-expands-ai-infrastructure-in-japan-with-launch-of-fifth-data-center-and-new-model-service-platform_603269

产品

Gemini CLI 今日停止面向个人用户服务，Google 将开发者迁移到 Antigravity CLI

按照 Google 此前公布的时间表，从 6 月 18 日起，Gemini CLI 和 Gemini Code Assist IDE 扩展不再为 Google AI Pro、Ultra 以及免费个人用户处理请求，Gemini Code Assist for GitHub 也停止接受新的组织安装。企业版与通过付费 API Key 使用的场景暂不受影响。个人开发者被引导至基于 Go 重写、支持异步多 Agent 工作流的 Antigravity CLI。

这不是简单改名，而是一次明确的产品收拢：Google 不再同时维护两个面向个人开发者的 Agent 入口，而是把终端、桌面端和服务端 harness 统一到 Antigravity。现有用户需要尽快检查插件、Hooks、Skills 和自动化脚本的迁移兼容性，尤其不要默认两套 CLI 已经实现 1:1 功能对齐。

来源：https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/

GitHub Actions 默认阻断常见 pwn request，actions/checkout v7 正式可用

GitHub 发布 actions/checkout v7。它会在 pull_request_target 等高权限工作流中，默认拒绝检出来自 fork PR 的 head 或 merge commit，以阻断最常见的 pwn request 攻击路径。7 月 16 日，这项保护还会回移到当前受支持的主要版本；固定到具体 SHA、次版本或补丁版本的工作流不会自动获得更新。

这项变化值得所有维护 GitHub Actions 的团队立即检查。pull_request_target 可以访问基础仓库的 GITHUB_TOKEN、Secrets 和缓存，一旦执行未审查的 fork 代码，就可能演变为供应链事件。新默认值能挡住常见误用，但通过 git、gh 或其他事件手动拉取不可信代码仍不在保护范围内，安全审查不能因此省掉。

来源：https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/

阿里云用任务调度配合 Agent Sandbox，让闲置 Agent 自动休眠

阿里云云原生团队发布 AI Task Scheduling 方案，将 OpenClaw、Hermes、Dify 等 Agent 的定时任务集中托管，再结合 Agent Sandbox 的休眠与唤醒能力动态释放计算资源。官方示例中，系统会在未来 15 分钟没有任务时休眠沙箱，并在任务前 10 分钟提前唤醒；一个每天实际工作 100 分钟的 Agent，计算成本可下降 90% 以上。

这个数字来自特定任务模型，不能直接套到所有生产环境，但它揭示了一个真实问题：Agent 为了保留文件、会话和执行状态，常常以独占沙箱常驻，资源利用率远低于传统无状态服务。把调度器与运行时解耦，再通过 checkpoint 和弹性唤醒恢复任务，可能会成为大规模 Agent 平台的基础能力。

来源：https://www.alibabacloud.com/blog/ai-task-scheduling-helps-agent-costs-drop-by-90%25_603271

模型

阿里发布 Qwen-Robot Suite，大模型开始从数字 Agent 走向物理执行

阿里发布首套 Qwen 机器人基础模型，包括面向机械操作的 Qwen-RobotManip、面向导航的 Qwen-RobotNav，以及用于预测物理世界后续轨迹的 Qwen-RobotWorld。官方披露，Manip 基于 Qwen3.5-4B VL 并使用超过 3.8 万小时开放数据训练；Nav 使用 1560 万条导航与视觉语言样本；World 则使用 860 万组视频文本对、超过 2 亿帧数据训练。目前该套件已在部分机器人行业客户中试点。

对开发者来说，值得关注的是“通用模型做规划、专用机器人模型做执行”的组合方式。数字 Agent 里的工具调用、分层规划和长任务执行，正在被带入真实环境；与此同时，仿真数据、硬件适配和安全边界会比普通软件 Agent 更难被模型能力本身掩盖。

来源：https://www.alibabacloud.com/blog/entering-the-physical-ai-era-introducing-the-qwen-robot-suite_603261

开源

Google 联合生态发布 ARD，试图给 Agent 建立开放的资源发现层

Google 与生态伙伴发布 Apache 2.0 许可的 Agentic Resource Discovery（ARD）规范，用于发布、发现和验证分散在不同组织中的工具、Skills、MCP Server、OpenAPI 服务和其他 Agent。组织可以在自己的域名下发布 ai-catalog.json，注册表负责索引，客户端则利用发布者身份与信任元数据验证能力来源，再通过原生协议直接连接。

MCP 解决了“如何调用工具”，A2A 解决了部分 Agent 间通信，而 ARD 瞄准的是调用之前的“去哪里找、该选哪个、能不能信”。如果规范能形成多家实现，它可能把今天封闭在各个平台里的 Agent Registry，推进成类似软件包索引和 Web 搜索的开放基础设施。

来源：https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/

项目：https://github.com/ards-project/ard-spec

Flue 1.0 Beta 发布，Agent 框架开始与 harness、runtime 明确分层

Astro 团队推出开源 Agent 框架 Flue 1.0 Beta，并以 Pi 作为底层 harness。Flue 用声明式项目结构描述模型、Skills、沙箱和指令，可接入 Slack、GitHub、Linear、Discord，也能部署到 Node.js、容器或 Cloudflare。Cloudflare 同时把持久执行、动态代码执行、虚拟文件系统和动态工作流等能力下沉到 Agents SDK，供不同 harness 和框架复用。

这次发布给出了一个很有参考价值的三层结构：框架负责开发体验与集成，harness 负责 Agent loop，runtime 负责状态、存储和计算。团队选型时不必再把“Agent 框架”当作一个大而全的黑盒，而可以分别评估编排体验、模型循环质量和生产运行能力。

来源：https://blog.cloudflare.com/agents-platform-flue-sdk/

项目：https://github.com/withastro/flue

Code Context Hologres 开源，用 MCP 为 AI Coding 提供共享持久上下文

阿里云介绍开源项目 Code Context Hologres，它通过 MCP 向 Claude Code、Qwen Code 等工具提供代码库检索。项目使用 AST 感知切分、向量与 BM25 混合检索、RRF 重排和基于 Merkle Tree 的增量索引，将团队级代码上下文放在外部持久层，而不是反复塞进单次模型窗口。官方项目评测称，在保持检索质量的前提下可减少约 40% 的上下文 Token。

这个方向比单纯追逐更长上下文更务实：模型窗口适合当前任务的工作记忆，架构约束、代码索引和团队规则则应该有独立的持久存储与治理。真正困难的部分会是权限隔离、索引新鲜度和检索评测，而不只是“把仓库做成向量库”。

来源：https://www.alibabacloud.com/blog/stop-treating-your-ai-like-a-hard-drive-why-your-team-needs-a-persistent-context-layer-in-2026_603274

项目：https://github.com/aliyun/code-context-hologres

讨论

GitHub 开始在发布说明中同时标注 Copilot 与任务发起者

GitHub 调整自动生成的 Release Notes：当 Copilot Cloud Agent 创建的 Pull Request 被合并时，发布说明会同时标注发起任务的开发者和 @copilot，而不再只把贡献归给机器人。该能力已面向所有仓库和套餐开放。

这只是一个很小的界面变化，却触及了 Agent 协作中的长期问题：代码由 Agent 提交，不等于责任、意图和贡献都属于 Agent。随着自动生成的 PR 越来越多，平台需要同时记录“谁提出任务、谁执行、谁审查、谁批准”，否则贡献统计与责任链都会被自动化账号稀释。

来源：https://github.blog/changelog/2026-06-18-generated-release-notes-credit-you-for-copilot-pull-requests/

今日判断

今天最值得关注的不是某个模型又刷新了多少分，而是 Agent 工具链开始集中补基础设施欠账：入口要统一，默认权限要收紧，能力要能发现和验证，执行状态要能恢复，闲置资源要能休眠，团队上下文要能持久化。下一阶段的竞争，会越来越像一场分布式系统与开发者平台能力的竞争。